linux-kernel - Re: [PATCH AUTOSEL 5.0 011/262] tracing: kdb: Fix ftdump to not sleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=UzS8qfC2yxep9vhp2QYw9Jy+RHsOgGF5ND2vV1OhYK5Q@mail.gmail.com>
Date:   Thu, 28 Mar 2019 12:45:18 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Sasha Levin <sashal@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH AUTOSEL 5.0 011/262] tracing: kdb: Fix ftdump to not sleep

Hi,

On Thu, Mar 28, 2019 at 3:13 AM Pavel Machek <pavel@....cz> wrote:
>
> > From: Douglas Anderson <dianders@...omium.org>
> >
> > [ Upstream commit 31b265b3baaf55f209229888b7ffea523ddab366 ]
> >
> > As reported back in 2016-11 [1], the "ftdump" kdb command triggers a
> > BUG for "sleeping function called from invalid context".
> >
> > kdb's "ftdump" command wants to call ring_buffer_read_prepare() in
> > atomic context.  A very simple solution for this is to add allocation
> > flags to ring_buffer_read_prepare() so kdb can call it without
> > triggering the allocation error.  This patch does that.
>
> I see solution is simple, but now we have a loop with GFP_ATOMIC
> allocations inside. How many "tracing spus" is this expected to loop
> over? Will not it exhaust atomically available pages and reliably fail
> in common configurations?
>                                                                 Pavel

Each one of these allocations is ~32 bytes and you do one per CPU.
Even with systems with a lot of CPUs that's not going to be tons.
...and you only do it with GFP_ATOMIC when you're actively dropped
into kdb and debugging.  It seems like going for simplicity is the
right call here, but of course if Steven or Daniel say that it has to
be done a different way then they're the true authorities.

-Doug