From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
pierre kuo <vichy.kuo@gmail.com>, Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
rostedt@goodmis.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC V2] printk: add warning while drop partial text in msg
Date: Mon, 18 Sep 2017 19:08:49 +0900 [thread overview]
Message-ID: <20170918100849.GC1514@jagdpanzerIV.localdomain> (raw)
In-Reply-To: <1505728803.12022.8.camel@perches.com>
On (09/18/17 03:00), Joe Perches wrote:
[..]
> > which is not a real world example, isn't it?
> >
> > printk_deferred("%s", local_string[2048]) makes no sense anyway,
> > since we limit the message size to 1024 - HEADER chars in
> > vprintk_emit() // see static char textbuf[LOG_LINE_MAX].
> >
> > I'm not quite following what were you trying to prove, sorry.
> > does any function in the upstream kernel printk()-s buffers
> > larger than LOG_LINE_MAX? which one?
> >
> >
> > - the longest line in my dmesg output is 260 bytes in total (including timestamp)
>
> try a kernel with a few modules loaded
>
> For instance:
>
> $ dmesg | awk '{ print length($0), $0 }'|sort -rn | head -1
> 827 [337318.968616] Modules linked in: snd_usb_audio snd_usbmidi_lib ccm rfcomm bnep snd_hda_codec_hdmi dell_led snd_hda_codec_realtek snd_hda_codec_generic hid_multitouch binfmt_misc nls_iso8859_1 arc4 i2c_designware_platform i2c_designware_core dell_wmi snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_sst_match snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel dell_laptop intel_rapl snd_hda_codec dell_smbios dcdbas x86_pkg_temp_thermal snd_hda_core intel_powerclamp snd_hwdep coretemp kvm_intel snd_pcm kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq_midi snd_seq_midi_event aesni_intel aes_x86_64 crypto_simd snd_rawmidi glue_helper cryptd intel_cstate intel_rapl_perf snd_seq iwlwifi snd_seq_device uvcvideo videobuf2_vmalloc
linked modules are not printed as a single line - printk("module linked in ................................").
it's a bunch of pr_cont() calls:
printk(KERN_DEFAULT "Modules linked in:");
list_for_each_entry_rcu(mod, &modules, list) {
pr_cont(" %s%s", mod->name, module_flags(mod, buf))
}
when pr_cont() buffer is getting full, we just flush it (log_store())
if (cont.len + len > sizeof(cont.buf))
cont_flush();
but the point is -- we don't truncate anything
here, and don't lose the content. don't we?
-ss
next prev parent reply other threads:[~2017-09-18 10:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-30 13:37 pierre Kuo
2017-08-01 2:43 ` Sergey Senozhatsky
2017-08-10 16:26 ` pierre kuo
2017-08-10 16:55 ` pierre kuo
2017-08-16 9:21 ` Petr Mladek
2017-08-17 1:05 ` Sergey Senozhatsky
2017-09-12 6:07 ` pierre kuo
2017-09-18 9:39 ` Sergey Senozhatsky
2017-09-18 10:00 ` Joe Perches
2017-09-18 10:08 ` Sergey Senozhatsky [this message]
2017-09-27 13:59 ` pierre kuo
2017-09-30 3:14 ` Sergey Senozhatsky
2017-10-04 13:28 ` Petr Mladek
2017-10-17 17:10 ` pierre kuo
2017-10-18 1:07 ` Sergey Senozhatsky
2017-10-04 13:17 ` Petr Mladek
2017-10-17 17:07 ` pierre kuo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170918100849.GC1514@jagdpanzerIV.localdomain \
--to=sergey.senozhatsky.work@gmail.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=vichy.kuo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®