On (20/06/23 13:07), Alan Maguire wrote:
> struct sk_buff *skb = alloc_skb(64, GFP_KERNEL);
>
> pr_info("%pT", BTF_PTR_TYPE(skb, "struct sk_buff"));
>
> ...gives us:
>
> (struct sk_buff){
> .transport_header = (__u16)65535,
> .mac_header = (__u16)65535,
> .end = (sk_buff_data_t)192,
>
On (20/06/30 12:21), Petr Mladek wrote:
> > So... Do we need to hold uart->port when we disable port->irq? What do we
> > race with? Module removal? The function bumps device PM counter (albeit
> > for UART_CAP_RPM ports only).
>
> Honestly, I do not see where a PM counter gets incremented.
Cc-ing more people
https://lore.kernel.org/lkml/cahp75vd8ntzmzdnhptdchdc11zycasfeigbxacpowz1lv9z...@mail.gmail.com
On (20/06/22 20:37), Andy Shevchenko wrote:
> > [ 279.759811] -> #2 (_desc_lock_class){-.-.}:
> > [ 279.759813]_raw_spin_lock_irqsave+0x61/0x8d
> > [ 279.759813]
On (20/06/19 13:26), Petr Mladek wrote:
> On Fri 2020-06-19 19:21:32, Sergey Senozhatsky wrote:
> > On (20/06/19 12:47), Andy Shevchenko wrote:
> > > On Fri, Jun 19, 2020 at 11:39:18AM +0200, Petr Mladek wrote:
> > > > On Thu 2020-06-18 19:47:45, Andy Shevchenko wrot
Use the 'common' foo_console_setup() naming scheme. There are 71
foo_console_setup() callbacks and only one foo_setup_console().
Signed-off-by: Sergey Senozhatsky
Cc: Andy Shevchenko
Cc: Steven Rostedt
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
---
drivers/tty/hvc/hvc_xen.c | 4 ++--
1 file
On (20/06/19 12:47), Andy Shevchenko wrote:
> On Fri, Jun 19, 2020 at 11:39:18AM +0200, Petr Mladek wrote:
> > On Thu 2020-06-18 19:47:45, Andy Shevchenko wrote:
[..]
> > I am going to push it the following week via printk tree unless
> > anybody complains.
>
> Thanks, Petr, I guess you may also
On (20/06/18 19:47), Andy Shevchenko wrote:
> Some of the console providers treat error code, returned by ->setup() hook,
> differently. Here is the unification of the behaviour.
>
> The drivers checked by one of the below criteria:
> 1/ the driver has explicit struct console .setup assignment
>
On (20/06/16 18:42), Nicolas Saenz Julienne wrote:
> On Tue, 2020-06-16 at 19:31 +0300, Andy Shevchenko wrote:
> > time64_t is 64-bit width type, we are not supposed to supply lesser ones
> > as in the case of rpi_firmware_print_firmware_revision() after the commit
> > 4a60f58ee002 ("ARM: bcm2835:
fixed this moving the type definitions lockdep.h into the
> new lockdep_types.h.
>
> Signed-off-by: Herbert Xu
FWIW,
Reviewed-by: Sergey Senozhatsky
-ss
On (20/06/10 17:41), Daniel Thompson wrote:
> > Thanks for the link. I'm slightly surprised it took so many years
> > to notice the addition of printk_nmi/printk_safe :)
>
> Rather by coincidence (at least I think its a coincidence) the problem
> has recently become much more obvious.
>
>
On (20/06/10 12:17), Tomasz Figa wrote:
[..]
> > Is it OK with you if I fold this patch into the original patch series and
> > make a
> > new PR for it? I prefer to have a series merged without a bug, rather than
> > fixing
> > it in a final patch.
>
> I believe this didn't introduce any real
Hi Hans,
On (20/06/10 11:54), Hans Verkuil wrote:
>
> Is it OK with you if I fold this patch into the original patch series and
> make a
> new PR for it? I prefer to have a series merged without a bug, rather than
> fixing
> it in a final patch.
Absolutely!
-ss
se
and we never clear the stale consistency attribute.
Re-implement set_queue_consistency() - it must always clear
queue's non-consistency attr and set it only if (1) and (2).
Signed-off-by: Sergey Senozhatsky
---
drivers/media/common/videobuf2/videobuf2-core.c | 7 +++
1 file changed, 3 i
/kdb_io.c | 72
> ++-
> 5 files changed, 64 insertions(+), 50 deletions(-)
Reviewed-by: Sergey Senozhatsky
-ss
On (20/06/03 14:19), Cheng Jian wrote:
> A deadlock caused by logbuf_lock occurs when panic:
>
> a) Panic CPU is running in non-NMI context
> b) Panic CPU sends out shutdown IPI via NMI vector
> c) One of the CPUs that we bring down via NMI vector holded logbuf_lock
> d)
On (20/06/02 14:24), Hans Verkuil wrote:
[..]
> For vim2m (but looks the same for vivid/vimc/vicodec):
>
> Streaming ioctls:
> test read/write: OK (Not Supported)
> test blocking wait: OK
> Video Capture: Captured 8 buffers
> test MMAP (no poll): OK
> Video
On (20/06/02 12:27), Hans Verkuil wrote:
[..]
> > Sorry, Hans, do you suggest to have something like this:
> >
> > if (q->memory == VB2_MEMORY_DMABUF) {
> > vb->need_cache_sync_on_finish = 0;
> > vb->need_cache_sync_on_prepare = 0;
> > b->flags &=
Hi Hans,
On (20/06/02 11:51), Hans Verkuil wrote:
> Hi Sergey,
>
> While doing final testing for this patch series (together with the v4l-utils
> patch)
> I found one remaining issue:
Thanks for the report.
> > +static void set_buffer_cache_hints(struct vb2_queue *q,
> > +
On (20/05/25 19:43), Tetsuo Handa wrote:
> >> On Sun 2020-05-24 23:50:34, Tetsuo Handa wrote:
> >>> syzbot found a NULL pointer dereference bug inside mptcp_recvmsg() due to
> >>> ssock == NULL, but this bug manifested inside selinux_socket_recvmsg()
> >>> because pr_debug() was no-op [1].
> >>>
>
On (20/05/25 10:42), Petr Mladek wrote:
> On Sun 2020-05-24 23:50:34, Tetsuo Handa wrote:
> > syzbot found a NULL pointer dereference bug inside mptcp_recvmsg() due to
> > ssock == NULL, but this bug manifested inside selinux_socket_recvmsg()
> > because pr_debug() was no-op [1].
> >
> >
oe Perches
Acked-by: Sergey Senozhatsky
-ss
On (20/05/21 11:40), Joe Perches wrote:
> Make the printk output maximum line length globally available.
>
> This can be used to emit logging messages lines that exceed
> the single printk maximum length line.
>
> e.g.: the kernel boot command on ARM can be up to 2048 chars
Speaking of the
On (20/05/20 21:40), Andrew Morton wrote:
> > On (20/05/20 18:00), Andrew Morton wrote:
> > [..]
> > > I'm wondering if we shold add a kernel puts() (putsk()? yuk) which can
> > > puts() a string of any length.
> > >
> > > I'm counting around 150 instances of printk("%s", ...) and pr_foo("%s",
>
On (20/05/20 18:00), Andrew Morton wrote:
[..]
> I'm wondering if we shold add a kernel puts() (putsk()? yuk) which can
> puts() a string of any length.
>
> I'm counting around 150 instances of printk("%s", ...) and pr_foo("%s",
> ...) which could perhaps be converted, thus saving an argument.
On (20/05/20 13:36), Joe Perches wrote:
> > We can split command line in a loop - memchr(pos, ' ') - and
> > pr_cont() parts of the command line. pr_cont() has overflow
> > control and it flushes cont buffer before it overflows, so
> > we should not lose anything.
>
> It doesn't matter much here,
On (20/05/19 21:58), Joe Perches wrote:
[..]
> > Maybe we can
> > use here something rather random and much shorter instead. E.g.
> > 256 chars. Hmm. How
>
> min(some_max like 132/256, PRINTK_LOG_LINE_MAX)
>
> would work.
An alternative approach would be to do what we do in the
rlycon(). Therefore I am afraid that every setup()
> function has to handle this on its own and this patch makes sense.
Hmm, OK.
FWIW,
Acked-by: Sergey Senozhatsky
-ss
ained and the patches look good to
> me. If we allowed %ptR then it makes sense to allow %ptT as well.
>
> For all three patches:
>
> Rewieved-by: Petr Mladek
Acked-by: Sergey Senozhatsky
-ss
gt; It is obvious that it is not fully safe. But it does not make things
> worse. The console drivers are already called in this context by
> db_printf() direct calls.
>
> Reported-by: Sumit Garg
> Tested-by: Sumit Garg
> Signed-off-by: Petr Mladek
Acked-by: Sergey Senozhatsky
-ss
On (20/05/19 12:42), Joe Perches wrote:
> +static void __init print_cmdline(char *line)
> +{
> +#ifdef CONFIG_PRINTK
> + const char *prefix = "Kernel command line";
> + size_t len = strlen(line);
> +
> + while (len > PRINTK_LOG_LINE_MAX) {
> + char *pos = line;
> +
On (20/05/18 11:21), Petr Mladek wrote:
[..]
> > > Is this guaranteed that we never execute this path from NMI?
>
> Good question!
>
> > Absolutely not.
> >
> > The execution context for kdb is pretty much unique... we are running a
> > debug mode with all CPUs parked in a holding loop with
Hi Hans,
On (20/05/18 17:18), Hans Verkuil wrote:
> Hi Sergey,
>
> On 14/05/2020 18:01, Sergey Senozhatsky wrote:
> > Hello
> >
> > v6 changes:
> > The design has been slightly reworked. The cache-hints capability has
> > been renamed to SUPPORTS_MMAP_CAC
On (20/05/15 17:32), Sumit Garg wrote:
> > Can I please have some context what problem does this solve?
>
> You can find the problem description here [1] which leads to this fix.
[..]
> [1] https://lkml.org/lkml/2020/5/12/213
Thanks for the link. I'm slightly surprised it took so many years
to
On (20/05/15 14:48), Daniel Thompson wrote:
> On Fri, May 15, 2020 at 07:33:08PM +0900, Sergey Senozhatsky wrote:
> > On (20/05/15 10:50), Petr Mladek wrote:
[..]
> > Is this guaranteed that we never execute this path from NMI?
>
> Absolutely not.
>
> The executio
On (20/05/15 10:50), Petr Mladek wrote:
> kdb is able to stop kernel even in NMI context where printk() is redirected
> to the printk_safe() lockless variant. Move the check and redirect to kdb
> even in this case.
Can I please have some context what problem does this solve?
I can see that
ing LPC2019 in Lisbon, with 1 exception: support for dictionaries
> will not be discontinued [4]. Dictionaries are stored in a separate
> buffer so that they cannot interfere with the human-readable buffer.
I'm willing to bless this. The code looks good to me, nice job guys.
Acked-by: Sergey Senozhatsky
-ss
From: Sergey Senozhatsky
We moved cache management decision making to the upper layer and
rely on buffer's need_cache_sync flags and videobuf2 core. If the
upper layer (core) has decided to invoke ->prepare() or ->finish()
then we must sync.
For DMABUF ->need_cache_sync_o
From: Sergey Senozhatsky
That if-statement seems to be unneeded.
Signed-off-by: Sergey Senozhatsky
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
b/drivers
From: Sergey Senozhatsky
Add a cache_hints module param to control per-queue user space cache
hints support.
Signed-off-by: Sergey Senozhatsky
---
Documentation/admin-guide/media/vivid.rst | 9 +
drivers/media/test-drivers/vivid/vivid-core.c | 9 +
2 files changed, 18
From: Sergey Senozhatsky
Provide begin_cpu_access() and end_cpu_access() dma_buf_ops
callbacks for cache synchronisation on exported buffers.
V4L2_FLAG_MEMORY_NON_CONSISTENT has no effect on dma-sg buffers.
dma-sg allocates memory using the page allocator directly, so
there is no memory
From: Sergey Senozhatsky
Provide begin_cpu_access() and end_cpu_access() callbacks for
cache synchronisation on exported buffers.
The patch also adds a new helper function - vb2_dc_buffer_consistent(),
which returns true is if the buffer is consistent (DMA_ATTR_NON_CONSISTENT
bit cleared), so
From: Sergey Senozhatsky
Extend vb2_buffer and vb2_queue structs with cache management
members.
V4L2 UAPI already contains two buffer flags which user-space,
supposedly, can use to control buffer cache sync:
- V4L2_BUF_FLAG_NO_CACHE_INVALIDATE
- V4L2_BUF_FLAG_NO_CACHE_CLEAN
None
From: Sergey Senozhatsky
By setting or clearing V4L2_FLAG_MEMORY_NON_CONSISTENT flag
user-space should be able to set or clear queue's NON_CONSISTENT
->dma_attrs. Queue's ->dma_attrs are passed to the underlying
allocator in __vb2_buf_mem_alloc(), so thus user-space is able
to reque
From: Sergey Senozhatsky
This patch lets user-space to request a non-consistent memory
allocation during CREATE_BUFS and REQBUFS ioctl calls.
= CREATE_BUFS
struct v4l2_create_buffers has seven 4-byte reserved areas,
so reserved[0] is renamed to ->flags. The struct, thus, now
has
From: Sergey Senozhatsky
This simplifies the code a tiny bit and let's us to avoid
unneeded ->prepare()/->finish() calls.
Signed-off-by: Sergey Senozhatsky
---
drivers/media/common/videobuf2/videobuf2-core.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/d
From: Sergey Senozhatsky
Switch from 'unsigned' to 'unsigned int' so that checkpatch doesn't
complain.
Signed-off-by: Sergey Senozhatsky
---
include/media/videobuf2-core.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/media/videobuf2-core.h b
From: Sergey Senozhatsky
Set video buffer cache management flags corresponding to V4L2 cache
flags.
Both ->prepare() and ->finish() cache management hints should be
passed during this stage (buffer preparation), because there is
no other way for user-space to tell V4L2 to avoid ->finis
From: Sergey Senozhatsky
Skip ->prepare() or/and ->finish() cache synchronisation if
user-space requested us to do so (or when queue dma direction
permits us to skip cache syncs).
Signed-off-by: Sergey Senozhatsky
---
drivers/media/common/videobuf2/videobuf2-core.c | 14 ++
For the time being, only one consistency attribute is supported:
DMA_ATTR_NON_CONSISTENT.
[0] https://www.mail-archive.com/linux-media@vger.kernel.org/msg112459.html
Sergey Senozhatsky (14):
videobuf2: use explicit unsigned int in vb2_queue
videobuf2: add cache management members
videobuf2: ha
From: Sergey Senozhatsky
Preparations for future V4L2_FLAG_MEMORY_NON_CONSISTENT support.
Extend vb2_core_reqbufs() parameters list to accept requests'
->flags, which will be used for memory consistency configuration.
An attempt to allocate a buffer with consistency requirements
which do
From: Sergey Senozhatsky
Factor out the code, no functional changes.
Signed-off-by: Sergey Senozhatsky
---
.../media/common/videobuf2/videobuf2-core.c | 52 +++
1 file changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b
On (20/04/28 16:47), Hans Verkuil wrote:
> Hi Sergey,
>
> On 24/04/2020 11:29, Sergey Senozhatsky wrote:
[..]
> I missed that. What should happen is that q->allow_cache_hints is set by the
> driver before vb2_queue_init is called. And the documentation should be
On (20/04/30 01:35), Tetsuo Handa wrote:
> Below is the default rules for rsyslog-8.24.0-52.el7 (userspace syslog
> daemon).
> Of course administrators can modify as needed, but notice that KERN_INFO is
> saved
> to /var/log/messages but KERN_DEBUG is saved to nowhere.
>
> --
> # Log
On (20/04/30 19:14), Alper Nebi Yasak wrote:
[..]
> +int update_console_to_preferred(void)
> +{
> + struct console_cmdline *c = NULL;
> + struct console *con = NULL;
> + struct console *tmp = NULL;
> +
> + if (preferred_console >= 0)
> + c = _cmdline[preferred_console];
On (20/05/10 13:24), Kees Cook wrote:
> The pstore subsystem already had a private version of this function.
> With the coming addition of the pstore/zone driver, this needs to be
> shared. As it really should live with printk, move it there instead.
Acked-by: Sergey Senozhatsky
-ss
On (20/05/04 15:17), Pavel Tatashin wrote:
> AFAIK, there is no way to have different log levels for
> different consoles.
There was a patch set from facebook several years ago to make
loglevels per-console, but it didn't land. Perhaps we need to
refresh it.
-ss
On (20/05/05 00:21), Pavel Tatashin wrote:
> > > I changed it to make code cleaner: for such basic operation there are
> > > too many conditions if we will keep it inside the kmsg_dump().
> > > However, if being able to set always_kmsg_dump dynamically during
> > > runtime is deemed important, I
On (20/05/02 10:35), Pavel Tatashin wrote:
[..]
> +static bool always_kmsg_dump;
> +module_param_named(always_kmsg_dump, always_kmsg_dump, bool, S_IRUGO |
> S_IWUSR);
>
> /**
> * kmsg_dump_register - register a kernel log dumper.
> @@ -3106,6 +3108,12 @@ int kmsg_dump_register(struct
On (20/04/30 19:14), Alper Nebi Yasak wrote:
> Currently, add_preferred_console sets a preferred console, but doesn't
> actually change /dev/console to match it. That part is handled within
> register_device, where a newly registered console driver will be set as
> /dev/console if it matches the
On (20/04/30 19:14), Alper Nebi Yasak wrote:
> | "console=tty0"|(no console arg) |
> --+---+---+
> QEMU VM | tty0 -WU (EC p ) | ttyAMA0 -W- (EC a) |
> (w/ SPCR) | ttyAMA0 -W-
On (10/10/19 20:23), Joe Perches wrote:
> On Fri, 2019-10-11 at 10:52 +0900, Sergey Senozhatsky wrote:
> > Hi Joe,
>
> Hi Sergey.
Hi Joe,
For some reason your reply triggered gmail spam filter; took
me a while to notice and "recover" it from spam folder.
[..]
&g
On (10/14/19 13:52), Vitaly Wool wrote:
> On Mon, Oct 14, 2019 at 12:49 PM Sergey Senozhatsky
> wrote:
> >
> > On (10/10/19 23:20), Vitaly Wool wrote:
> > [..]
> > > static const char *default_compressor = "lzo-rle";
> > >
> > > +#defi
On (10/10/19 23:20), Vitaly Wool wrote:
[..]
> static const char *default_compressor = "lzo-rle";
>
> +#define BACKEND_PAR_BUF_SIZE 32
> +static char backend_par_buf[BACKEND_PAR_BUF_SIZE];
We can have multiple zram devices (zram0 .. zramN), I guess it
would make sense not to force all devices
On (10/10/19 23:11), Vitaly Wool wrote:
[..]
> +static unsigned long zs_zpool_get_compacted(void *pool)
> +{
> + struct zs_pool_stats stats;
> +
> + zs_pool_stats(pool, );
> + return stats.pages_compacted;
> +}
So zs_pool_stats() can become static?
-ss
Hi,
On (10/10/19 23:04), Vitaly Wool wrote:
[..]
> The coming patchset is a new take on the old issue: ZRAM can
> currently be used only with zsmalloc even though this may not
> be the optimal combination for some configurations. The previous
> (unsuccessful) attempt dates back to 2015 [1] and is
Hi Joe,
I noticed that this code
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 18, 0)
triggers checkpatch's warning:
"WARNING: Comparisons should place the constant on
the right side of the test"
Both LINUX_VERSION_CODE and KERNEL_VERSION are constants, so
I'm
On (10/10/19 10:21), Petr Mladek wrote:
[..]
> > > Considering that console.write is called from essentially arbitrary code
> > > path IIUC then all the locks used in this path should be pretty much
> > > tail locks or console internal ones without external dependencies.
> >
> > That's a good
On (10/10/19 09:40), Michal Hocko wrote:
[..]
> > > Considering that console.write is called from essentially arbitrary code
> > > path IIUC then all the locks used in this path should be pretty much
> > > tail locks or console internal ones without external dependencies.
> >
> > That's a good
On (10/09/19 16:26), Michal Hocko wrote:
> On Wed 09-10-19 15:56:32, Peter Oberparleiter wrote:
> [...]
> > A generic solution would be preferable from my point of view though,
> > because otherwise each console driver owner would need to ensure that any
> > lock taken in their console.write
Hi,
On (09/30/19 06:33), Sodagudi Prasad wrote:
> From Qualcomm side, we would like to check with upstream team about adding
> Raw time stamp value to printk records. On Qualcomm soc, there are various
> DSPs subsystems are there - for example audio, video and modem DSPs.
> Adding raw timer
On (09/26/19 10:58), Petr Mladek wrote:
[..]
> > - spin_lock(>port.lock);
> > -
> > + uart_port_lock_irqsave(>port, flags);
>
> uart_port_lock_irqsave() does not exist.
... Oh. Good catch! Apparently I still carry around my patch set
which added printk_safe to TTY/UART locking API.
>
On (09/23/19 14:58), Petr Mladek wrote:
>
> If I understand it correctly then this is the re-appearing problem.
> The only systematic solution with the current approach is to
> take port->lock in printk_safe/printk_deferred context.
It probably is.
We have a number of reverse paths. TTY invokes
On (09/23/19 18:45), He Zhe wrote:
> I think it is NOT necessary to inform user-space, when it just wants to read
> from the beginning of the buffer, that the buffer has changed since the time
> point when it issues the action of reading.
The point here is not to notify user space that the logbuf
On (09/18/19 12:10), Qian Cai wrote:
[..]
> > So you have debug objects enabled. Right? This thing does not behave
> > when it comes to printing. debug_objects are slightly problematic.
>
> Yes, but there is an also a similar splat without the debug_objects. It looks
> like anything try to
On (09/18/19 21:31), zhe...@windriver.com wrote:
>
> When users read the buffer from start, there is no need to return -EPIPE
> since the possible overflows will not affect the output.
>
[..]
> - if (user->seq < log_first_seq) {
> + if (user->seq == 0) {
> + user->seq =
On (09/20/19 14:25), Kefeng Wang wrote:
> There are pr_warning and pr_warng to show WARNING level message,
> most of the code using pr_warn, number based on next-20190919,
Looks good to me.
Reviewed-by: Sergey Senozhatsky
-ss
A correction:
On (09/19/19 00:51), Sergey Senozhatsky wrote:
[..]
>
> zone->lock --> console_sem->lock
>
> So then we have
>
> zone->lock --> console_sem->lock --> pi_lock --> rq->lock
>
> vs. the reverse chain
>
> rq-&
On (09/18/19 10:39), Qian Cai wrote:
> > Perhaps for a quick fix (and a comment that says this needs to be fixed
> > properly). I think the changes to printk() that was discussed at
> > Plumbers may also solve this properly.
>
> I assume that the new printk() stuff will also fix this deadlock
On (09/18/19 11:05), John Ogness wrote:
> On 2019-09-18, Sergey Senozhatsky wrote:
> >> Each console has its own iterator. This iterators will need to
> >> advance, regardless if the message was printed via write() or
> >> write_atomic().
> >
> > Grea
On (09/18/19 10:26), 'Greg KH' wrote:
> On Wed, Sep 18, 2019 at 03:33:04PM +0900, Sergey Senozhatsky wrote:
> > On (09/18/19 08:16), 'Greg KH' wrote:
> > [..]
> > > > Note, that Samsung is still improving sdfat driver. For instance,
> > > > what will b
On (09/18/19 09:42), John Ogness wrote:
> > It's going to be a bit harder when we have per-console kthread.
>
> Each console has its own iterator. This iterators will need to advance,
> regardless if the message was printed via write() or write_atomic().
Great.
->atomic_write() path will make
On (09/18/19 09:33), John Ogness wrote:
>
> I expect sysrq to be the only valid use of "synchronous state" other
> than oops/panic. Although I suppose PeterZ would like a boot argument to
> always run the consoles in this state.
Yes, there might be more cases when we need sync printk(). Like
On (09/18/19 09:11), Uwe Kleine-König wrote:
> I rechecked and indeed fd5f7cde1b85's parent has the problem, too, so I
> did a mistake during my bisection :-|
>
> Redoing the bisection (a bit quicker this time) points to
>
> dbdda842fe96 ("printk: Add console owner and waiter logic to load
On (09/18/19 08:16), 'Greg KH' wrote:
[..]
> > Note, that Samsung is still improving sdfat driver. For instance,
> > what will be realeased soon is sdfat v2.3.0, which will include support
> > for "UtcOffset" of "File Directory Entry", in order to satisfy
> > exFAT specification 7.4.
>
[..]
> If
On (09/18/19 11:36), Sergey Senozhatsky wrote:
[..]
> For instance, tty/sysrq must be able to switch printk emergency on/off.
> That already means that printk emergency knob should be visible to the
> rest of the kernel. A long time ago, we had printk_emergency_b
On (09/17/19 22:08), Steven Rostedt wrote:
> > On (09/13/19 15:26), John Ogness wrote:
> > > 2. A kernel thread will be created for each registered console, each
> > > responsible for being the sole printers to their respective
> > > consoles. With this, console printing is _fully_ decoupled from
On (09/17/19 16:10), Uwe Kleine-König wrote:
> Hello,
>
> Today it saw sysrq on an UART driven by drivers/tty/serial/imx.c report
> a lockdep issue. Bisecting pointed to
>
> fd5f7cde1b85 ("printk: Never set console_may_schedule in
> console_trylock()")
Hmmm...
I don't see how this patch
On (09/13/19 15:26), John Ogness wrote:
> 2. A kernel thread will be created for each registered console, each
> responsible for being the sole printers to their respective
> consoles. With this, console printing is _fully_ decoupled from printk()
> callers.
sysrq over serial?
What we currently
On (09/16/19 12:46), Petr Mladek wrote:
> Hmm, it seems that journalctl is able to filer device specific
> information, for example, I get:
>
> $> journalctl _KERNEL_DEVICE=+usb:2-1
> -- Logs begin at Tue 2019-08-13 09:00:03 CEST, end at Mon 2019-09-16 12:32:58
> CEST. --
> Aug 13 09:00:04
On (09/16/19 10:42), Steven Rostedt wrote:
[..]
> >
> > This will also fix the hang.
> >
> > Sergey, do you plan to submit this Ted?
>
> Perhaps for a quick fix (and a comment that says this needs to be fixed
> properly).
I guess it would make sense, since LTS and -stable kernels won't get new
Cc-ing Ted, Arnd, Greg
On (09/10/19 11:22), Qian Cai wrote:
> [ 1078.283869][T43784] -> #3 (&(>lock)->rlock){-.-.}:
> [ 1078.291350][T43784]__lock_acquire+0x5c8/0xbb0
> [ 1078.296394][T43784]lock_acquire+0x154/0x428
> [ 1078.301266][T43784]_raw_spin_lock_irqsave+0x80/0xa0
On (09/10/19 01:59), Kees Cook wrote:
> On Tue, Sep 10, 2019 at 01:05:39AM +0900, Sergey Senozhatsky wrote:
> > On (08/20/19 09:47), Kees Cook wrote:
> > [..]
> > > + /*
> > > + * BUG() and WARN_ON() families don't print a custom debug message
> > > +
On (09/06/19 16:01), Peter Zijlstra wrote:
> In fact, i've gotten output that is plain impossible with
> the current junk.
Peter, can you post any of those backtraces? Very curious.
-ss
On (08/10/19 07:53), Thomas Gleixner wrote:
>
> Right now we have an implementation for serial only, but that already is
> useful. I nicely got (minimaly garbled) crash dumps out of an NMI
> handler. With the current mainline console code the machine just hung.
>
Thomas, any chance you can post
On (08/20/19 09:47), Kees Cook wrote:
[..]
> @@ -181,6 +181,15 @@ enum bug_trap_type report_bug(unsigned long bugaddr,
> struct pt_regs *regs)
> }
> }
>
> + /*
> + * BUG() and WARN_ON() families don't print a custom debug message
> + * before triggering the
On (09/06/19 17:32), Petr Mladek wrote:
> > [..]
> > > I mean, really, do we need to keep calling wake up if it
> > > probably never even executed?
> >
> > I guess ratelimiting you are talking about ("if it probably never even
> > executed") would be to check if we have already called wake up on
On (09/06/19 16:01), Peter Zijlstra wrote:
> > 2. The simple approach works only with lockless consoles. We need
> >something else for the rest at least for NMI. Simle offloading
> >to a kthread has been blocked for years. People wanted the
> >trylock-and-flush-immediately approach.
>
On (09/06/19 16:55), Petr Mladek wrote:
> > I think we can queue significantly much less irq_work-s from printk().
> >
> > Petr, Steven, what do you think?
> >
> > Something like this. Call wake_up_interruptible(), switch to
> > wake_up_klogd() only when called from sched code.
>
> Replacing
On (09/06/19 12:49), Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 07:09:43PM +0900, Sergey Senozhatsky wrote:
>
> > ---
> > diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
> > index 139c310049b1..9c73eb6259ce 100644
> > --- a/kernel/printk/
On (09/06/19 11:06), Peter Zijlstra wrote:
> Another approach is something like:
>
> DEFINE_PER_CPU(int, printk_nest);
> DEFINE_PER_CPU(char, printk_line[4][256]);
>
> int vprintk(const char *fmt, va_list args)
> {
> int c, n, i;
> char *buf;
>
> preempt_disable();
> i =
301 - 400 of 6882 matches
Mail list logo
