All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Korty <joe.korty@concurrent-rt.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: John Ogness <john.ogness@linutronix.de>, linux-rt-users@vger.kernel.org
Subject: Re: [5.4-rt] kdb: push 'bt' command output to console immediately.
Date: Fri, 26 Jun 2020 09:05:44 -0400	[thread overview]
Message-ID: <20200626130544.GA37967@zipoli.concurrent-rt.com> (raw)
In-Reply-To: <20200526165502.GA36846@zipoli.concurrent-rt.com>

On Tue, May 26, 2020 at 12:55:02PM -0400, Joe Korty wrote:
> On Tue, May 26, 2020 at 06:44:49PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-05-20 17:33:25 [+0200], John Ogness wrote:
> > > On 2020-05-20, Joe Korty <joe.korty@concurrent-rt.com> wrote:
> > > > [5.4-rt] kdb: push 'bt' command output to console immediately.
> > > >
> > > > The rt patch for 5.4 and 5.2 broke kdb slightly.  The kdb
> > > > 'bt' command now prints a single line then returns to the
> > > > kdb prompt.  There is no stack trace being shown.
> > > ...
> > > >
> > > > I have attached a small patch that Seems To Work.  It
> > > > taps earlier into printk than the official tap does.
> > > 
> > > On LKML a similar patch was recently posted[0]. It would probably be
> > > better to follow that (patching vprintk_func and using
> > > KDB_MSGSRC_PRINTK).
> > 
> > Should I do here anything?
> 
> Hi John,
> Probably not.
> 
> Since the bug is in mainline, not rt, ideally rt should
> just wait for the fix you so graciously found for me to
> enter mainline and propagate down to the various stable
> trees.
...



Hi Sebastian,
Oops, my mistake .. the bug is in rt, not mainline.  The
status of the long-term rt's w.r.t. this patch is:

       5.6-rt    -- already has fix
       5.4-rt    -- needs fix
       4.19-rt   -- needs fix
       4.14-rt   -- needs fix
       4.9-rt    -- needs fix
       4.4-rt    -- needs fix

For your convenience, I've attached the needed patch.

Regards,
Joe

> From: Matt Fleming <matt@codeblueprint.co.uk>
> To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: linux-rt@vger.kernel.org, linux-kernel@vger.kernel.org,
>	Daniel Wagner <wagi@monom.org>,
>	Matt Fleming <matt@codeblueprint.co.uk>
>Subject: [PATCH RT] signal: Prevent double-free of user struct
>Date: Tue,  7 Apr 2020 10:54:13 +0100

The way user struct reference counting works changed significantly with,

  fda31c50292a ("signal: avoid double atomic counter increments for user accounting")

Now user structs are only freed once the last pending signal is
dequeued. Make sigqueue_free_current() follow this new convention to
avoid freeing the user struct multiple times and triggering this
warning:

 refcount_t: underflow; use-after-free.
 WARNING: CPU: 0 PID: 6794 at lib/refcount.c:288 refcount_dec_not_one+0x45/0x50
 Call Trace:
  refcount_dec_and_lock_irqsave+0x16/0x60
  free_uid+0x31/0xa0
  ? schedule_hrtimeout_range_clock+0x104/0x110
  __dequeue_signal+0x17c/0x190
  dequeue_signal+0x5a/0x1b0
  do_sigtimedwait+0x208/0x250
  __x64_sys_rt_sigtimedwait+0x6f/0xd0
  do_syscall_64+0x72/0x200
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Reported-by: Daniel Wagner <wagi@monom.org>

Index: b/kernel/signal.c
===================================================================
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -494,8 +494,8 @@ static void sigqueue_free_current(struct
 
 	up = q->user;
 	if (rt_prio(current->normal_prio) && !put_task_cache(current, q)) {
-		atomic_dec(&up->sigpending);
-		free_uid(up);
+		if (atomic_dec_and_test(&up->sigpending))
+			free_uid(up);
 	} else
 		  __sigqueue_free(q);
 }

      reply	other threads:[~2020-06-26 13:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 15:16 [5.4-rt] kdb: push 'bt' command output to console immediately Joe Korty
2020-05-20 15:33 ` John Ogness
2020-05-20 15:40   ` Joe Korty
2020-05-26 16:44   ` Sebastian Andrzej Siewior
2020-05-26 16:55     ` Joe Korty
2020-06-26 13:05       ` Joe Korty [this message]

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=20200626130544.GA37967@zipoli.concurrent-rt.com \
    --to=joe.korty@concurrent-rt.com \
    --cc=bigeasy@linutronix.de \
    --cc=john.ogness@linutronix.de \
    --cc=linux-rt-users@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.