On Wed 2021-03-03 16:43:25, Petr Mladek wrote:
> On Mon 2021-02-22 13:39:56, Matthew Wilcox wrote:
> > On Mon, Feb 22, 2021 at 01:38:17PM +0100, Petr Mladek wrote:
> > > Another question where to push this change. It is pity the we
> > > finalized it in the middle
On Mon 2021-03-08 13:22:40, Geert Uytterhoeven wrote:
> Hi Petr,
>
> On Mon, Mar 8, 2021 at 11:16 AM Petr Mladek wrote:
> > On Fri 2021-03-05 20:42:06, Marco Elver wrote:
> > > Move the no_hash_pointers warning string into __initconst section, so
> > > that i
On Wed 2021-03-03 16:34:19, Petr Mladek wrote:
> On Wed 2021-03-03 11:15:13, John Ogness wrote:
> > Hello,
> >
> > Here is v4 of a series to remove @logbuf_lock, exposing the
> > ringbuffer locklessly to both readers and writers. v3 is
> > here [0].
>
> Th
y with v2 as is or a v3 if you want to
> update s/shadow variables to only/shadow variables for only/ but knowing
> me, I probably repeated the same phrasing elsewhere. Up to you, thanks.
I could fix these when pushing unless anyone is against it.
> Acked-by: Joe Lawrence
Acked-by: Petr Mladek
Best Regards,
Petr
On Fri 2021-03-05 20:42:06, Marco Elver wrote:
> Move the no_hash_pointers warning string into __initconst section, so
> that it is discarded after init. Remove common start/end characters.
> Also remove repeated lines from the array, since the compiler can't
> remove duplicate strings for us
On Fri 2021-03-05 20:42:05, Marco Elver wrote:
> Do not show no_hash_pointers message multiple times if the option was
> passed more than once (e.g. via generated command line).
>
> Signed-off-by: Marco Elver
Reviewed-by: Petr Mladek
Best Regards,
Petr
p_shadow_get_or_alloc() call can be used to attach
> shadow variables to parents already in-flight.
It might make sense to move the "In" to the next line. It sticks out
even more now.
Eitherway:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Mon 2021-02-22 13:39:56, Matthew Wilcox wrote:
> On Mon, Feb 22, 2021 at 01:38:17PM +0100, Petr Mladek wrote:
> > Another question where to push this change. It is pity the we
> > finalized it in the middle of the merge window. It has to spend
> > at least few days in l
On Wed 2021-03-03 11:15:13, John Ogness wrote:
> Hello,
>
> Here is v4 of a series to remove @logbuf_lock, exposing the
> ringbuffer locklessly to both readers and writers. v3 is
> here [0].
The series look ready. I am going to push it into printk/linux.git
the following week unless anyone
On Wed 2021-03-03 15:34:09, Petr Mladek wrote:
> Hi,
>
> the following warning is filling my kernel log buffer
> with 5.12-rc1+ kernels:
>
> [ 941.070598] WARNING: CPU: 0 PID: 11 at drivers/gpu/drm/ttm/ttm_bo.c:139
> ttm_bo_move_to_lru_tail+0x1ba/0x210
> [ 94
Hi,
the following warning is filling my kernel log buffer
with 5.12-rc1+ kernels:
[ 941.070598] WARNING: CPU: 0 PID: 11 at drivers/gpu/drm/ttm/ttm_bo.c:139
ttm_bo_move_to_lru_tail+0x1ba/0x210
[ 941.070601] Modules linked in:
[ 941.070603] CPU: 0 PID: 11 Comm: kworker/0:1 Kdump: loaded
oval of @logbuf_lock.
>
> Signed-off-by: John Ogness
> Reviewed-by: Kees Cook # pstore
Reviewed-by: Petr Mladek
Best Regards,
Petr
y: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
Hi John,
On Wed 2021-03-03 11:15:13, John Ogness wrote:
> Hello,
>
> Here is v4 of a series to remove @logbuf_lock, exposing the
> ringbuffer locklessly to both readers and writers. v3 is
> here [0].
Have you got some reply from lkml that it has not delivered there,
please?
I am not able to
On Mon 2021-03-01 09:47:47, Stephen Boyd wrote:
> The %pS printk format (among some others) is used to print kernel
> addresses symbolically. When the kernel prints an address inside of a
> module, the kernel prints the addresses' symbol name along with the
> module's name that contains the
On Tue 2021-03-02 14:49:42, Geert Uytterhoeven wrote:
> Hi Vlastimil, Petr,
>
> On Tue, Mar 2, 2021 at 2:37 PM Vlastimil Babka wrote:
> > On 3/2/21 2:29 PM, Petr Mladek wrote:
> > > On Tue 2021-03-02 13:51:35, Geert Uytterhoeven wrote:
> > >> > > >
On Tue 2021-03-02 14:20:51, John Ogness wrote:
> On 2021-03-01, Petr Mladek wrote:
> >> diff --git a/arch/powerpc/kernel/nvram_64.c
> >> b/arch/powerpc/kernel/nvram_64.c
> >> index 532f22637783..5a64b24a91c2 100644
> >> --- a/arch/powerpc/kernel/nvram_64.c
On Tue 2021-03-02 13:51:35, Geert Uytterhoeven wrote:
> Hi Marco,
>
> On Tue, Mar 2, 2021 at 1:45 PM Marco Elver wrote:
> > On Tue, 2 Mar 2021 at 12:51, Geert Uytterhoeven
> > wrote:
> > > On Sun, Feb 14, 2021 at 5:17 PM Timur Tabi wrote:
> > > > If the no_hash_pointers command line parameter
On Tue 2021-03-02 11:45:27, John Ogness wrote:
> On 2021-03-01, Petr Mladek wrote:
> >> The kmsg_dumper can be called from any context and CPU, possibly
> >> from multiple CPUs simultaneously. Since the writing of the buffer
> >> can occur from a later scheduled wo
d-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Tue 2021-03-02 09:06:07, John Ogness wrote:
> On 2021-03-01, Petr Mladek wrote:
> >> > diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_dump.c
> >> > index 6516ef1f8274..4869e2cc787c 100644
> >> > --- a/arch/um/kernel/kmsg_dump.c
On Thu 2021-02-25 21:24:35, John Ogness wrote:
> Rather than storing the iterator information in the registered
> kmsg_dumper structure, create a separate iterator structure. The
> kmsg_dump_iter structure can reside on the stack of the caller, thus
> allowing lockless use of the kmsg_dump
- arch/powerpc/xmon/xmon.c
> - kernel/debug/kdb/kdb_main.c
Great summary!
> Therefore, @active can be removed.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
@syslog_lock for this
> purpose.
>
> @syslog_lock is a raw_spin_lock for now. This simplifies the
> transition to removing @logbuf_lock. Once @logbuf_lock and the
> safe buffers are removed, @syslog_lock can change to spin_lock.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Mon 2021-03-01 17:16:35, Petr Mladek wrote:
> On Thu 2021-02-25 21:24:24, John Ogness wrote:
> > The kmsg_dumper can be called from any context and CPU, possibly
> > from multiple CPUs simultaneously. Since a static buffer is used
> > to retrieve the kernel logs, this buf
g if another context is already
> dumping.
>
> Signed-off-by: John Ogness
> Reviewed-by: Petr Mladek
> ---
> arch/um/kernel/kmsg_dump.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_dump.c
&g
sure. You did not use spin lock to prevent problems
with eventual double unlock in panic(). Do I get it correctly,
please?
> Signed-off-by: John Ogness
Anyway, it looks good to me.
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Fri 2021-02-26 09:36:21, John Ogness wrote:
> On 2021-02-25, Petr Mladek wrote:
> > IMHO, a better design would be:
> >
> > 1. dumper->dump() callback should have only one parameter @reason.
> >The callback should define its own iterator, buffer, and
> >
our of %p
> (with the new boot parameter when debugging), and stress that %pK should be
> only used for procfs and similar files, not dmesg buffer. This patch clarifies
> the documentation in that regard.
>
> Signed-off-by: Vlastimil Babka
Nice!
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Wed 2021-02-24 13:27:42, John Ogness wrote:
> On 2021-02-19, Petr Mladek wrote:
> > This is likely beyond the scope of this patchset.
>
> It would be beyond the scope of this patchset because it is not related
> to logbuf_lock removal.
>
> > I am sti
On Tue 2021-02-23 14:29:37, Yiwei Zhang wrote:
> > > which is not cool because it will make the
> > > asynchronous effort a no-op. Is there a way we can include caller
> > > thread metadata(task_struct pointer?) when it enqueues the work so
> > > that the RT worker thread won't preempt the caller
On Mon 2021-02-22 16:58:46, Yiwei Zhang wrote:
> Since you awesome guys are here, I do have another kthread related
> question, and hopefully to get some suggestions:
>
> Below are the conditions:
> 1. The caller threads queuing the work are normal threads(non-RT).
> 2. The worker thread is a
h is a followup of the patchset
> "mm, vsprintf: dump full information of page flags in pGp" [1]
>
> [1].
> https://lore.kernel.org/linux-mm/20210215155141.47432-1-laoar.s...@gmail.com/
> Signed-off-by: Yafang Shao
> Cc: Petr Mladek
> Cc: Matthew Wilcox
> Cc: Andy Shevchen
On Mon 2021-02-22 17:43:56, John Ogness wrote:
> On 2021-02-22, Petr Mladek wrote:
> >>>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> >>>> index 20c21a25143d..401df370832b 100644
> >>>> --- a/kernel/printk/printk.c
>
On Tue 2021-02-23 13:22:22, Helge Deller wrote:
> On 2/22/21 5:28 PM, Petr Mladek wrote:
> > On Sun 2021-02-21 22:39:42, Helge Deller wrote:
> > > On 2/19/21 5:33 PM, John Ogness wrote:
> > > > Added CC: linux-par...@vger.kernel.org
> > > >
;
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Thu 2021-02-18 09:18:16, John Ogness wrote:
> kmsg_dump() is open coding the kmsg_dump_rewind(). Call
> kmsg_dump_rewind() instead.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
chosen because they are already
> exported to kernel modules.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
t;
> @console_seq, @exclusive_console_stop_seq, @console_dropped are
> protected by @console_lock.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Thu 2021-02-11 18:37:52, John Ogness wrote:
> If message sizes average larger than expected (more than 32
> characters), the data_ring will wrap before the desc_ring. Once the
> data_ring wraps, it will start invalidating descriptors. These
> invalid descriptors hang around until they are
On Sun 2021-02-21 22:39:42, Helge Deller wrote:
> On 2/19/21 5:33 PM, John Ogness wrote:
> > Added CC: linux-par...@vger.kernel.org
> >
> > On 2021-02-19, John Ogness wrote:
> > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > > > index 20c21a25143d..401df370832b 100644
>
On Fri 2021-02-19 15:45:21, John Ogness wrote:
> On 2021-02-19, Petr Mladek wrote:
> >> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> >> index 20c21a25143d..401df370832b 100644
> >> --- a/kernel/printk/printk.c
> >> +++ b/kernel/printk/pri
Linus,
please pull the latest livepatching changes from
git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching.git
tags/livepatching-for-5.12
==
- Practical information how to implement reliable stacktraces needed by
the livepatching
rintk: fix deadlock when kernel panic
Petr Mladek (2):
Merge branch 'for-5.12-no_hash_pointers' into for-linus
Merge branch 'printk-rework' into for-linus
Timur Tabi (3):
lib: use KSTM_MODULE_GLOBALS macro in kselftest drivers
kselftest: add support for skipped tests
li
*pff[i].spec);
> +
> + append = true;
> + }
> +
> + return buf;
> +}
Otherwise, the patch looks to me. The issue is cosmetic and might be
fixed either by re-spinning just this patch or by a followup patch.
Either way, feel free to use:
Re
On Thu 2021-02-18 09:18:12, John Ogness wrote:
> Rather than store the iterator information into the registered
> kmsg_dump structure, create a separate iterator structure. The
> kmsg_dump_iter structure can reside on the stack of the caller,
> thus allowing lockless use of the kmsg_dump
(private)
> + * @next_seq:Points after the newest message to dump (private)
"(private)" might be removed.
Anyway, the issues are only cosmetic:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Thu 2021-02-18 09:18:11, John Ogness wrote:
> The global variables @syslog_seq, @syslog_partial, @syslog_time
> and write access to @clear_seq are protected by @logbuf_lock.
> Once @logbuf_lock is removed, these variables will need their
> own synchronization method. Introduce @syslog_lock for
return error when data has vanished underneath us */
> - if (info.seq != user->seq)
> + if (info.seq != atomic64_read(>seq))
> ret = EPOLLIN|EPOLLRDNORM|EPOLLERR|EPOLLPRI;
> else
> ret = EPOLLIN|EPOLLRDNORM;
With the above fix:
Reviewed-by: Petr Mladek
Best Regards,
Petr
evert the size increase
when anyone complains.
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Thu 2021-02-18 09:18:07, John Ogness wrote:
> The logic for finding records to fit into a buffer is the same for
> kmsg_dump_get_buffer() and syslog_print_all(). Introduce a helper
> function find_first_fitting_seq() to handle this logic.
>
> Signed-off-by: John Ogness
Re
On Sun 2021-02-14 00:06:11, Yiwei Zhang wrote:
> The existing kthread_mod_delayed_work api will queue a new work if
> failing to cancel the current work due to no longer being pending.
> However, there's a case that the same work can be enqueued from both
> an async request and a delayed work, and
On Thu 2021-02-18 22:29:24, Yiwei Zhang wrote:
> > 2. User triggered clean up races with the clean up triggered by
> > timeout. You try to handle this scenario by this patch.
> Yes, exactly.
>
> > 3. User does clean up after the clean up has already been done
> > by the timeout.
> This case
On Thu 2021-02-18 09:18:05, John Ogness wrote:
> struct kmsg_dumper still contains some fields that were used to
> iterate the old ringbuffer. They are no longer used. Remove them
> and update the struct documentation.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
is a flood
of messages. And this limit looks like a reasonable point where
to start filling the provided buffer.
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Thu 2021-02-18 12:41:39, Chris Down wrote:
> Petr Mladek writes:
> > > - See if it's safe to pass a printk_fmt_sec to seq_file instead of a
> > > module
> >
> > Also it might be needed to store the pointer to struct module.
>
> You mean, have a `st
On Wed 2021-02-17 15:50:00, Andy Shevchenko wrote:
> On Wed, Feb 17, 2021 at 01:15:43PM +0100, Enrico Weigelt, metux IT consult
> wrote:
> > Under rare circumstances it may happen that a device node's name is NULL
> > (most likely kernel bug in some other place).
>
> What circumstances? How can
On Thu 2021-02-18 12:21:55, Chris Down wrote:
> Thanks for all your feedback, Petr and Steven. :-)
>
> Petr, I believe this is a comprehensive checklist of everything we discussed
> for v5 -- any chance you could double check I'm not missing anything you
> folks wanted? Thanks!
>
> - Use
On Wed 2021-02-17 15:28:24, Chris Down wrote:
> Petr Mladek writes:
> > I guess that you already use it internally and have its own tooling
> > around it.
>
> Hmm, we're actually not using it yet widely because I don't want to backport
> it to our prod kernel until
On Wed 2021-02-17 15:56:38, Chris Down wrote:
> Petr Mladek writes:
> > > > How about config PRINTK_INDEX?
> > >
> > > Ah yes, I also like that. PRINTK_INDEX is fine from my perspective and is
> > > more straightforward than "enumeration&q
On Wed 2021-02-17 16:32:21, Chris Down wrote:
> Chris Down writes:
> > open(f);
> > debugfs_file_get(f);
> > fops->open();
> >inode->private = ps;
> > debugfs_file_put(f);
> >
> > remove_printk_fmt_sec(); /* kfree ps */
> >
> > read(f);
> > debugfs_file_get(f);
> > fops->read();
> >
On Tue 2021-02-16 17:27:08, Chris Down wrote:
> Petr Mladek writes:
> > > +/*
> > > + * Stores .printk_fmt section boundaries for vmlinux and all loaded
> > > modules.
> > > + * Add entries with store_printk_fmt_sec, remove entries with
> > > + *
On Tue 2021-02-16 21:05:48, Chris Down wrote:
> Johannes Weiner writes:
> > On Tue, Feb 16, 2021 at 05:27:08PM +, Chris Down wrote:
> > > Petr Mladek writes:
> > > > I wonder if we could find a better name for the configure switch.
> > > > I have t
On Tue 2021-02-16 17:18:58, Chris Down wrote:
> Petr Mladek writes:
> > > +static size_t printk_fmt_size(const char *fmt)
> > > +{
> > > + size_t sz = strlen(fmt) + 1;
> > > +
> > > + /*
> > > + * Some printk formats don't start wi
On Tue 2021-02-16 16:52:39, Chris Down wrote:
> Hey Petr,
>
> Petr Mladek writes:
> > This produces something like:
> >
> > 3Warning: unable to open an initial console.
> > 3Failed to execute %s (error %d)
> > 6Kernel memory protection disabled.
> > 3
On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote:
> +Cc: Sakari and printk people
>
> On Mon, Feb 15, 2021 at 4:28 PM Christian König
> wrote:
> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > > We have already few similar implementation and a lot of code that can
> > > benefit
> > > of
On Tue 2021-02-16 10:58:36, Yiwei Zhang wrote:
> On Mon, Feb 15, 2021 at 5:28 AM Petr Mladek wrote:
> >
> > On Sun 2021-02-14 00:06:11, Yiwei Zhang wrote:
> > > The existing kthread_mod_delayed_work api will queue a new work if
> > > failing to cancel the cu
Hi,
this is from Nitpicker's department.
On Fri 2021-02-12 15:30:16, Chris Down wrote:
> We have a number of systems industry-wide that have a subset of their
> functionality that works as follows:
>
> 1. Receive a message from local kmsg, serial console, or netconsole;
> 2. Apply a set of
On Fri 2021-02-12 15:30:16, Chris Down wrote:
> We have a number of systems industry-wide that have a subset of their
> functionality that works as follows:
>
> 1. Receive a message from local kmsg, serial console, or netconsole;
> 2. Apply a set of rules to classify the message;
> 3. Do
%d)\n
<6> init/main.c:1398: Kernel memory protection disabled.\n
<3> init/main.c:1366: Starting init: %s exists but couldn't execute it (error
%d)\n
The way how to store the filename and line number might be found
in the dynamic_debug code.
> +
> +out_unlock:
> +
On Mon 2021-02-15 20:22:34, Paul Menzel wrote:
> Dear Linux folks,
>
>
> Using Linux 5.10.13 (and before), looking at the Linux kernel warnings, the
> CPU numbers show up. For example with 12 cpus/threads:
>
> ```
> $ sudo dmesg --level=warn
> [0.216103] #2
> [0.220105] #3
> [
On Tue 2021-02-16 09:37:45, Thomas Zimmermann wrote:
> Hi
>
> Am 15.02.21 um 12:40 schrieb Sakari Ailus:
> > Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
> > large number of temporary variables at the same time.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> >
On Mon 2021-02-15 13:40:30, Sakari Ailus wrote:
> Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
> large number of temporary variables at the same time.
>
> Signed-off-by: Sakari Ailus
Reviewed-by: Petr Mladek
I wonder if I could this via printk tree.
On Mon 2021-02-15 13:40:29, Sakari Ailus wrote:
> Now that we can print FourCC codes directly using printk, make use of the
> feature in V4L2 core.
>
> Signed-off-by: Sakari Ailus
Reviewed-by: Petr Mladek
I am curious whether I could take this via printk tree or if Mauro
would pr
gt; I count in numbers... albeit the hexadecimal number there starts from zero.
> >
> > I guess both would work though.
> >
> > 0123 would be consistent.
>
> Since letters can be printed the above is confusing a bit. I think XY12 is
> closer to the reality than 0123.
Ailus, are you going to send v8 with the two small changes? I mean a
selftest with the space and the above sample code.
Anyway, feel free to add:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Sun 2021-02-14 00:06:11, Yiwei Zhang wrote:
> The existing kthread_mod_delayed_work api will queue a new work if
> failing to cancel the current work due to no longer being pending.
> However, there's a case that the same work can be enqueued from both
> an async request and a delayed work, and
On Sun 2021-02-14 10:18:39, Timur Tabi wrote:
> On 2/14/21 10:13 AM, Timur Tabi wrote:
> > Although hashing addresses printed via printk does make the
> > kernel more secure, it interferes with debugging, especially
> > with some functions like print_hex_dump() which always uses
> > hashed
On Fri 2021-02-12 13:28:56, Sakari Ailus wrote:
> On Thu, Feb 11, 2021 at 06:14:28PM +0100, Petr Mladek wrote:
> > On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> > > Hi Andy,
> > >
> > > On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> &
Hi,
I have realized that I did not comment the two ideas.
On Wed 2021-02-10 11:27:45, Timur Tabi wrote:
>
>
> On 2/10/21 7:41 AM, Petr Mladek wrote:
> >
> > The option causes that vsprintf() will not hash pointers. Yes, it is
> > primary used by printk(). But it
On Wed 2021-02-10 15:34:52, Timur Tabi wrote:
> Update the kselftest framework to allow client drivers to
> specify that some tests were skipped.
>
> Signed-off-by: Timur Tabi
Reviewed-by: Petr Mladek
Tested-by: Petr Mladek
Best Regards,
Petr
On Thu 2021-02-11 17:20:26, Matthew Wilcox wrote:
> On Thu, Feb 11, 2021 at 11:08:12AM -0600, Timur Tabi wrote:
> >
> >
> > On 2/11/21 6:31 AM, Pavel Machek wrote:
> > > Can we make this something shorter? Clearly you don't want people
> > > placing this in their grub config, so they'll be most
s ringbuffer")
> Reported-by: kernel test robot
> Reported-by: J. Avila
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
I am going to push the patch later today. I would prefer to do it
later and give a chance others to react. But the merge window
will likely start the following week and Sergey was fine
with this approach.
Best Regard,
Petr
et.
>
> Signed-off-by: Timur Tabi
> Acked-by: Petr Mladek
> Acked-by: Randy Dunlap
> Acked-by: Sergey Senozhatsky
> Acked-by: Vlastimil Babka
> ---
> .../admin-guide/kernel-parameters.txt | 15
> lib/test_printf.c
On Thu 2021-02-11 11:08:12, Timur Tabi wrote:
>
>
> On 2/11/21 6:31 AM, Pavel Machek wrote:
> > Can we make this something shorter? Clearly you don't want people
> > placing this in their grub config, so they'll be most likely typing
> > this a lot...
> >
> > debug_pointers or debug_ptrs would
On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
> Hi Andy,
>
> On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
> > > On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Feb 8, 2021 at
On Mon 2021-02-08 22:09:02, Sakari Ailus wrote:
> Now that we can print FourCC codes directly using printk, make use of the
> feature in V4L2 core.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++-
> 1 file changed, 21 insertions(+),
.
>
> Note that where a very large number is used to mean "unlimited", the value
> INT_MAX is used for consistency with the behaviour of vsnprintf().
>
> Signed-off-by: Richard Fitzgerald
Reviewed-by: Petr Mladek
The patchset looks ready for upstream from my POV.
Best Regards,
Petr
ald
> Acked-by: Andy Shevchenko
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Thu 2021-02-11 13:55:26, Petr Mladek wrote:
> On Mon 2021-02-08 17:38:29, Richard Fitzgerald wrote:
> > On 08/02/2021 15:18, Andy Shevchenko wrote:
> > > On Mon, Feb 08, 2021 at 02:01:52PM +, Richard Fitzgerald wrote:
> > > A nit-pick: What if we rewrite a
On Mon 2021-02-08 17:38:29, Richard Fitzgerald wrote:
> On 08/02/2021 15:18, Andy Shevchenko wrote:
> > On Mon, Feb 08, 2021 at 02:01:52PM +, Richard Fitzgerald wrote:
> > > The existing code attempted to handle numbers by doing a strto[u]l(),
> > > ignoring the field width, and then
On Wed 2021-02-10 19:32:10, John Ogness wrote:
> On 2021-02-09, Petr Mladek wrote:
> >> @@ -1629,9 +1631,13 @@ int do_syslog(int type, char __user *buf, int len,
> >> int source)
> >>/* Number of chars in the log buffer */
> >
ss ring buffer.
>
> Fixes: cf9b1106c81c ("printk/nmi: flush NMI messages on the system panic")
> Signed-off-by: Muchun Song
> Reviewed-by: Petr Mladek
> Cc:
The patch is committed on printk/linux.git, branch for-5.12.
Best Regards,
Petr
bled.
> Unhashed pointers, while useful for debugging, expose kernel
> addresses which can be a security risk.
>
> Also update test_printf to skip the hashed pointer tests if the
> command-line option is set.
>
> Signed-off-by: Timur Tabi
> Acked-by: Petr Mladek
> Ac
On Tue 2021-02-09 23:18:12, Timur Tabi wrote:
> Instead of defining the total/failed test counters manually,
> test_printf should use the kselftest macro created for this
> purpose.
>
> Signed-off-by: Timur Tabi
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Wed 2021-02-10 00:21:37, Yafang Shao wrote:
> On Tue, Feb 9, 2021 at 9:53 PM Petr Mladek wrote:
> >
> > On Tue 2021-02-09 18:56:13, Yafang Shao wrote:
> > > Currently the pGp only shows the names of page flags, rather than
> > > the full information including
Hello,
just for record.
On Tue 2021-02-09 13:49:25, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed a -5.9% regression of unixbench.score due to commit:
>
>
> commit: a91bd6223ecd46addc71ee6fcd432206d39365d2 ("Revert "init/console: Use
> ttynull as a fallback when there is no
On Fri 2021-02-05 15:23:28, John Ogness wrote:
> If message sizes average larger than expected (more than 32
> characters), the data_ring will wrap before the desc_ring. Once the
> data_ring wraps, it will start invalidating descriptors. These
> invalid descriptors hang around until they are
On Tue 2021-02-09 16:16:01, Andy Shevchenko wrote:
> On Tue, Feb 09, 2021 at 02:53:53PM +0100, Petr Mladek wrote:
> > On Tue 2021-02-09 18:56:13, Yafang Shao wrote:
>
> ...
>
> > I am sorry for my ignorance. I am not familiar with MM.
> > But it is pretty hard to
On Tue 2021-02-09 18:56:13, Yafang Shao wrote:
> Currently the pGp only shows the names of page flags, rather than
> the full information including section, node, zone, last cpupid and
> kasan tag. While it is not easy to parse these information manually
> because there're so many flavors. Let's
intk_safe buffers have been
obsoleted by the lockless ring buffer.
> Fixes: cf9b1106c81c ("printk/nmi: flush NMI messages on the system panic")
> Signed-off-by: Muchun Song
With an updated commit message:
Reviewed-by: Petr Mladek
Best Regards,
Petr
101 - 200 of 5065 matches
Mail list logo
