linux-kernel - Re: [PATCH] mm: mmap_lock: fix use-after-free race and css ref leak in tracepoints

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: <1eb44e95-1fae-5d64-d114-d305c9b8ef63@suse.cz>
Date:   Fri, 4 Dec 2020 17:36:20 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Shakeel Butt <shakeelb@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>
Cc:     Axel Rasmussen <axelrasmussen@...gle.com>,
        Tejun Heo <tj@...nel.org>, Greg Thelen <gthelen@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Chinwen Chang <chinwen.chang@...iatek.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        David Rientjes <rientjes@...gle.com>,
        Davidlohr Bueso <dbueso@...e.de>,
        Ingo Molnar <mingo@...hat.com>, Jann Horn <jannh@...gle.com>,
        Laurent Dufour <ldufour@...ux.ibm.com>,
        Michel Lespinasse <walken@...gle.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Yafang Shao <laoar.shao@...il.com>,
        "David S . Miller" <davem@...emloft.net>, dsahern@...nel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jakub Kicinski <kuba@...nel.org>, liuhangbin@...il.com,
        LKML <linux-kernel@...r.kernel.org>,
        Linux MM <linux-mm@...ck.org>
Subject: Re: [PATCH] mm: mmap_lock: fix use-after-free race and css ref leak
 in tracepoints

On 12/2/20 2:11 AM, Shakeel Butt wrote:
> On Tue, Dec 1, 2020 at 5:07 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>>
>> On Tue, 1 Dec 2020 16:36:32 -0800
>> Shakeel Butt <shakeelb@...gle.com> wrote:
>>
>> > SGTM but note that usually Andrew squash all the patches into one
>> > before sending to Linus. If you plan to replace the path buffer with
>> > integer IDs then no need to spend time fixing buffer related bug.
>>
>> I don't think Andrew squashes all the patches. I believe he sends Linus
>> a patch series.
> 
> I am talking about the patch and the following fixes to that patch.
> Those are usually squashed into one patch.

Yeah, if there's a way forward that doesn't need to construct full path on each
event and the associated complexity and just use an ID, let's convert to the ID
and squash it, for less churn. Especially if there are other existing
tracepoints that use the ID.

If there's further (somewhat orthogonal) work to make the IDs easier for
userspace, it can be added on top later, but really shouldn't need to add the
current complex solution only to remove it later?

Thanks,
Vlastimil