[linux-next:master 6188/10009] h8300-linux-ld: section .softirqentry.text VMA overlaps section .bss VMA

[linux-next:master 6188/10009] h8300-linux-ld: section .softirqentry.text VMA overlaps section .bss VMA

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   de2e69cfe54a8f2ed4b75f09d3110c514f45d38e
commit: 896fbe20b4e2333fb55cc9b9b783ebcc49eee7c7 [6188/10009] printk: use the lockless ringbuffer
config: h8300-randconfig-c022-20200720 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout 896fbe20b4e2333fb55cc9b9b783ebcc49eee7c7
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   h8300-linux-ld: section .init.text LMA [00000000005eaf40,000000000062100b] overlaps section .text LMA [000000000000025c,00000000007942cf]
   h8300-linux-ld: section .data VMA [0000000000400000,00000000005eaf3f] overlaps section .text VMA [000000000000025c,00000000007942cf]
>> h8300-linux-ld: section .softirqentry.text VMA [00000000007942d0,0000000000794597] overlaps section .bss VMA [000000000062c340,0000000000847b4f]

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 24199 bytes --]

Re: [linux-next:master 6188/10009] h8300-linux-ld: section .softirqentry.text VMA overlaps section .bss VMA

[John Ogness]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On 2020-07-22, kernel test robot <lkp@intel.com> wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   de2e69cfe54a8f2ed4b75f09d3110c514f45d38e
> commit: 896fbe20b4e2333fb55cc9b9b783ebcc49eee7c7 [6188/10009] printk: use the lockless ringbuffer
> config: h8300-randconfig-c022-20200720 (attached as .config)
> compiler: h8300-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout 896fbe20b4e2333fb55cc9b9b783ebcc49eee7c7
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300 
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
>    h8300-linux-ld: section .init.text LMA [00000000005eaf40,000000000062100b] overlaps section .text LMA [000000000000025c,00000000007942cf]
>    h8300-linux-ld: section .data VMA [0000000000400000,00000000005eaf3f] overlaps section .text VMA [000000000000025c,00000000007942cf]
>>> h8300-linux-ld: section .softirqentry.text VMA [00000000007942d0,0000000000794597] overlaps section .bss VMA [000000000062c340,0000000000847b4f]

The .bss section for the h8300 is relatively small. A default
CONFIG_LOG_BUF_SHIFT value of 20 will create a static printk ringbuffer
that is too large. This is a problem with the new printk ringbuffer
because it now occupies double the .bss space.

Is it enough to ignore this problem and require h8300 users to use a
smaller CONFIG_LOG_BUF_SHIFT value (which they probably are anyway)? Or
should we change the default for CONFIG_H8300? I am open for ideas.

John Ogness

Re: [linux-next:master 6188/10009] h8300-linux-ld: section .softirqentry.text VMA overlaps section .bss VMA

[Petr Mladek]

[-- Attachment #1: Type: text/plain, Size: 3997 bytes --]

On Mon 2020-07-27 14:00:00, John Ogness wrote:
> On 2020-07-22, kernel test robot <lkp@intel.com> wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head:   de2e69cfe54a8f2ed4b75f09d3110c514f45d38e
> > commit: 896fbe20b4e2333fb55cc9b9b783ebcc49eee7c7 [6188/10009] printk: use the lockless ringbuffer
> > config: h8300-randconfig-c022-20200720 (attached as .config)
> > compiler: h8300-linux-gcc (GCC) 9.3.0
> > reproduce (this is a W=1 build):
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         git checkout 896fbe20b4e2333fb55cc9b9b783ebcc49eee7c7
> >         # save the attached .config to linux build tree
> >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300 
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > All errors (new ones prefixed by >>):
> >
> >    h8300-linux-ld: section .init.text LMA [00000000005eaf40,000000000062100b] overlaps section .text LMA [000000000000025c,00000000007942cf]
> >    h8300-linux-ld: section .data VMA [0000000000400000,00000000005eaf3f] overlaps section .text VMA [000000000000025c,00000000007942cf]
> >>> h8300-linux-ld: section .softirqentry.text VMA [00000000007942d0,0000000000794597] overlaps section .bss VMA [000000000062c340,0000000000847b4f]
> 
> The .bss section for the h8300 is relatively small. A default
> CONFIG_LOG_BUF_SHIFT value of 20 will create a static printk ringbuffer
> that is too large. This is a problem with the new printk ringbuffer
> because it now occupies double the .bss space.
> 
> Is it enough to ignore this problem and require h8300 users to use a
> smaller CONFIG_LOG_BUF_SHIFT value (which they probably are anyway)? Or
> should we change the default for CONFIG_H8300? I am open for ideas.

In theory, it should be safe to lower the default value by one on all
architectures. The dictionary and metadata are stored separately
so more messages can be stored into the data ring.

Let's look at my test system using the original log buffer[*]:

text: 30 kB
metadata: 14 kB
dict: 9 kB

The text takes more than half of the space. But the difference is not
too huge. So decreasing CONFIG_LOG_BUF_SHIFT by one might be acceptable.

Also it might make sense to decrease the size of the dict ring by
two. I mean to have size of text:dict rings as 2:1.

Well, it would be nice to check the statistic on more systems.


That said, I am fine also with reducing the default only on h8300.
It should be enough to define it in in arch/h8300/Kconfig. I see
that, for example, PGTABLE_LEVELS variable is redefined on some
architectures.

=====================

[*] Below is how I got the above numbers:

$> pahole -y printk_log kernel/printk/printk.o
struct printk_log {
        u64                        ts_nsec;              /*     0     8 */
        u16                        len;                  /*     8     2 */
        u16                        text_len;             /*    10     2 */
        u16                        dict_len;             /*    12     2 */
        u8                         facility;             /*    14     1 */
        u8                         flags:5;              /*    15: 3  1 */
        u8                         level:3;              /*    15: 0  1 */
        u32                        caller_id;            /*    16     4 */

        /* size: 20, cachelines: 1, members: 8 */
        /* last cacheline: 20 bytes */
};

$> dmesg | wc -l
701

$> echo $((701 * 20))
14020

# => metadata: 14 kB

$> cat /dev/kmsg >/tmp/dev_kmsg
$> cat /tmp/dev_kmsg | grep caller= | cut -d: -f2- | sed -e "s/^.*caller=T1;//" | wc -c
30997

# => text: 30 kB

$> cat /tmp/dev_kmsg | grep -v caller= | wc -c
9293

# => dict: 9 kB

Best Regards,
Petr

Re: [linux-next:master 6188/10009] h8300-linux-ld: section .softirqentry.text VMA overlaps section .bss VMA

[John Ogness]

[-- Attachment #1: Type: text/plain, Size: 3688 bytes --]

[Added CC: Sergey and Steven]

I do not know which direction we want to take here. In this email I
state my stance.

On 2020-08-05, Petr Mladek <pmladek@suse.com> wrote:
> On Mon 2020-07-27 14:00:00, John Ogness wrote:
>> The .bss section for the h8300 is relatively small. A default
>> CONFIG_LOG_BUF_SHIFT value of 20 will create a static printk
>> ringbuffer that is too large. This is a problem with the new printk
>> ringbuffer because it now occupies double the .bss space.
>> 
>> Is it enough to ignore this problem and require h8300 users to use a
>> smaller CONFIG_LOG_BUF_SHIFT value (which they probably are anyway)?
>> Or should we change the default for CONFIG_H8300? I am open for
>> ideas.
>
> In theory, it should be safe to lower the default value by one on all
> architectures. The dictionary and metadata are stored separately
> so more messages can be stored into the data ring.

I assume adjusting config defaults is a serious issue since it
implicitly affects all defconfigs.

Originally I considered having CONFIG_LOG_BUF_SHIFT represent the size
of the text _and_ dict buffers combined. This would more closely
represent its current meaning in mainline.

> Let's look at my test system using the original log buffer[*]:
>
> text: 30 kB
> metadata: 14 kB
> dict: 9 kB
>
> The text takes more than half of the space. But the difference is not
> too huge. So decreasing CONFIG_LOG_BUF_SHIFT by one might be
> acceptable.
>
> Also it might make sense to decrease the size of the dict ring by
> two. I mean to have size of text:dict rings as 2:1.

Yes, I thought about that as well. Although it would be hard to justify
any particular ratio since it depends on the system.

> Well, it would be nice to check the statistic on more systems.
>
> That said, I am fine also with reducing the default only on h8300.
> It should be enough to define it in in arch/h8300/Kconfig. I see
> that, for example, PGTABLE_LEVELS variable is redefined on some
> architectures.

If it was my decision, I would choose to have CONFIG_LOG_BUF_SHIFT
represent the _combined_ size of text and dict buffers. I expect with
this interpretation, most systems will wrap similar to when they are
wrapping now.

At some point we could consider *replacing* CONFIG_LOG_BUF_SHIFT with
CONFIG_LOG_TEXT_BUF_SHIFT and CONFIG_LOG_DICT_BUF_SHIFT config
options. But I don't see an immediate need for new replacement options.

John

> =====================
>
> [*] Below is how I got the above numbers:
>
> $> pahole -y printk_log kernel/printk/printk.o
> struct printk_log {
>         u64                        ts_nsec;              /*     0     8 */
>         u16                        len;                  /*     8     2 */
>         u16                        text_len;             /*    10     2 */
>         u16                        dict_len;             /*    12     2 */
>         u8                         facility;             /*    14     1 */
>         u8                         flags:5;              /*    15: 3  1 */
>         u8                         level:3;              /*    15: 0  1 */
>         u32                        caller_id;            /*    16     4 */
>
>         /* size: 20, cachelines: 1, members: 8 */
>         /* last cacheline: 20 bytes */
> };
>
> $> dmesg | wc -l
> 701
>
> $> echo $((701 * 20))
> 14020
>
> # => metadata: 14 kB
>
> $> cat /dev/kmsg >/tmp/dev_kmsg
> $> cat /tmp/dev_kmsg | grep caller= | cut -d: -f2- | sed -e "s/^.*caller=T1;//" | wc -c
> 30997
>
> # => text: 30 kB
>
> $> cat /tmp/dev_kmsg | grep -v caller= | wc -c
> 9293
>
> # => dict: 9 kB

Re: [linux-next:master 6188/10009] h8300-linux-ld: section .softirqentry.text VMA overlaps section .bss VMA

[Petr Mladek]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

On Wed 2020-08-05 17:35:16, Petr Mladek wrote:
> On Mon 2020-07-27 14:00:00, John Ogness wrote:
> > On 2020-07-22, kernel test robot <lkp@intel.com> wrote:
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > > head:   de2e69cfe54a8f2ed4b75f09d3110c514f45d38e
> > > commit: 896fbe20b4e2333fb55cc9b9b783ebcc49eee7c7 [6188/10009] printk: use the lockless ringbuffer
> > > config: h8300-randconfig-c022-20200720 (attached as .config)
> > > compiler: h8300-linux-gcc (GCC) 9.3.0
> > > reproduce (this is a W=1 build):
> > >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > >         chmod +x ~/bin/make.cross
> > >         git checkout 896fbe20b4e2333fb55cc9b9b783ebcc49eee7c7
> > >         # save the attached .config to linux build tree
> > >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300 
> > >
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot <lkp@intel.com>
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > >    h8300-linux-ld: section .init.text LMA [00000000005eaf40,000000000062100b] overlaps section .text LMA [000000000000025c,00000000007942cf]
> > >    h8300-linux-ld: section .data VMA [0000000000400000,00000000005eaf3f] overlaps section .text VMA [000000000000025c,00000000007942cf]
> > >>> h8300-linux-ld: section .softirqentry.text VMA [00000000007942d0,0000000000794597] overlaps section .bss VMA [000000000062c340,0000000000847b4f]
> > 
> > The .bss section for the h8300 is relatively small. A default
> > CONFIG_LOG_BUF_SHIFT value of 20 will create a static printk ringbuffer
> > that is too large. This is a problem with the new printk ringbuffer
> > because it now occupies double the .bss space.
> > 
> > Is it enough to ignore this problem and require h8300 users to use a
> > smaller CONFIG_LOG_BUF_SHIFT value (which they probably are anyway)? Or
> > should we change the default for CONFIG_H8300? I am open for ideas.
> 
> In theory, it should be safe to lower the default value by one on all
> architectures. The dictionary and metadata are stored separately
> so more messages can be stored into the data ring.

> That said, I am fine also with reducing the default only on h8300.
> It should be enough to define it in in arch/h8300/Kconfig. I see
> that, for example, PGTABLE_LEVELS variable is redefined on some
> architectures.

A good compromise might be to lower the default only on systems
that unset BASE_FULL.

We already do this for LOG_CPU_MAX_BUF_SHIFT.
Note that BASE_SMALL is defined as negation of BASE_FULL.

Best Regards,
Petr

Re: [linux-next:master 6188/10009] h8300-linux-ld: section .softirqentry.text VMA overlaps section .bss VMA

[Petr Mladek]

[-- Attachment #1: Type: text/plain, Size: 2841 bytes --]

On Mon 2020-08-10 23:36:20, John Ogness wrote:
> [Added CC: Sergey and Steven]
> 
> I do not know which direction we want to take here. In this email I
> state my stance.
> 
> On 2020-08-05, Petr Mladek <pmladek@suse.com> wrote:
> > On Mon 2020-07-27 14:00:00, John Ogness wrote:
> >> The .bss section for the h8300 is relatively small. A default
> >> CONFIG_LOG_BUF_SHIFT value of 20 will create a static printk
> >> ringbuffer that is too large. This is a problem with the new printk
> >> ringbuffer because it now occupies double the .bss space.
> >> 
> >> Is it enough to ignore this problem and require h8300 users to use a
> >> smaller CONFIG_LOG_BUF_SHIFT value (which they probably are anyway)?
> >> Or should we change the default for CONFIG_H8300? I am open for
> >> ideas.
> >
> > In theory, it should be safe to lower the default value by one on all
> > architectures. The dictionary and metadata are stored separately
> > so more messages can be stored into the data ring.
> 
> I assume adjusting config defaults is a serious issue since it
> implicitly affects all defconfigs.

Honestly, I do not have much experience with changing these defaults.
I could imagine that people hacking small devices might complain.
But I think that most people would not mind. And the default is
too small from my POV.

Accidentally, there is an independent proposal to increase the
default, see
https://lore.kernel.org/r/20200811092924.6256-2-pmenzel(a)molgen.mpg.de

It is motivated by lost messages, see
https://lore.kernel.org/lkml/264bfbae-122d-9c41-59ea-6413f91bd866(a)molgen.mpg.de/

I think that the solution with two defaults for BASE_FULL and BASE_SMALL.


> If it was my decision, I would choose to have CONFIG_LOG_BUF_SHIFT
> represent the _combined_ size of text and dict buffers. I expect with
> this interpretation, most systems will wrap similar to when they are
> wrapping now.

Hmm, I am not sure. It might help people that care about the used memory.
Well, it will still not cover the non-trivial size of the desc ring.

IMHO, most people are not aware of the dictionary. They are more
interested how many messages might get stored into the ring buffer.
For them, the current solution is good. Because the config option
describes the size of the pure text (ignoring id) that might be
stored there.

We might just better describe the meaning in the config description.


> At some point we could consider *replacing* CONFIG_LOG_BUF_SHIFT with
> CONFIG_LOG_TEXT_BUF_SHIFT and CONFIG_LOG_DICT_BUF_SHIFT config
> options. But I don't see an immediate need for new replacement options.

I guess that we will end with this. Maybe we will even need to add
CONFIG_LOG_DESC_BUF_SHIFT. But let's keep the single option for now
until people complains.

Best Regards,
Petr

Re: [linux-next:master 6188/10009] h8300-linux-ld: section .softirqentry.text VMA overlaps section .bss VMA

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Tue, 11 Aug 2020 12:32:12 +0200
Petr Mladek <pmladek@suse.com> wrote:

> > At some point we could consider *replacing* CONFIG_LOG_BUF_SHIFT with
> > CONFIG_LOG_TEXT_BUF_SHIFT and CONFIG_LOG_DICT_BUF_SHIFT config
> > options. But I don't see an immediate need for new replacement options.  
> 
> I guess that we will end with this. Maybe we will even need to add
> CONFIG_LOG_DESC_BUF_SHIFT. But let's keep the single option for now
> until people complains.

I agree, and I also think it is fine to have h8300 have a different
default config than the rest of the archs.

-- Steve

Re: [linux-next:master 6188/10009] h8300-linux-ld: section .softirqentry.text VMA overlaps section .bss VMA

[Sergey Senozhatsky]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On (20/08/10 23:36), John Ogness wrote:
> > Let's look at my test system using the original log buffer[*]:
> >
> > text: 30 kB
> > metadata: 14 kB
> > dict: 9 kB
> >
> > The text takes more than half of the space. But the difference is not
> > too huge. So decreasing CONFIG_LOG_BUF_SHIFT by one might be
> > acceptable.
> >
> > Also it might make sense to decrease the size of the dict ring by
> > two. I mean to have size of text:dict rings as 2:1.
> 
> Yes, I thought about that as well. Although it would be hard to justify
> any particular ratio since it depends on the system.

I think there will be some users of CONFIG_PRINTK_DICT_SIZE=0

	-ss