linux-kernel - Re: [PATCH] goldfish_pipe: use GFP

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: <CA+yUs=zSALn=gr3w-4mHDkHea66r2Zg8PFrK=hSF8QWS1tz+0Q@mail.gmail.com>
Date:   Fri, 9 Jun 2017 12:15:42 -0700
From:   Jin Qian <jinqian@...roid.com>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Michal Hocko <mhocko@...nel.org>, Wei Yongjun <weiyj.lk@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        lstoakes@...il.com, jack@...e.cz, christian.koenig@....com,
        Wei Yongjun <weiyongjun1@...wei.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] goldfish_pipe: use GFP_ATOMIC under spin lock

Reviewed-by: Jin Qian <jinqian@...gle.com>

Can we merge this to stable?

Thanks!
jin

On Mon, May 22, 2017 at 11:48 AM, Alan Cox <gnomes@...rguk.ukuu.org.uk> wrote:
> On Mon, 22 May 2017 13:51:52 +0200
> Michal Hocko <mhocko@...nel.org> wrote:
>
>> On Sun 21-05-17 09:48:36, Michal Hocko wrote:
>> > On Sun 21-05-17 00:45:46, Wei Yongjun wrote:
>> > > From: Wei Yongjun <weiyongjun1@...wei.com>
>> > >
>> > > The function get_free_pipe_id_locked() is called from
>> > > goldfish_pipe_open() with a lock is held, so we should
>> > > use GFP_ATOMIC instead of GFP_KERNEL.
>> >
>> > Why is GFP_NOWAIT insufficient? Does this path needs an access to memory
>> > reserves?
>>
>> And now when looking at the code more deeply, wouldn't it be much better
>> to simply do the allocation outside of the spin lock and do assignments
>> with the lock held?
>
> That's far from trivial and certainly for backporting and an immediate
> fix this seems better. The allocations are not that large and any fail
> would be in open() not anywhere weird.
>
> Alan