linux-kernel - Re: [RFC v2 5/5] block: revert back to synchronous request

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: <64c9212d-aaa3-d172-0ab9-0fc0e25a019a@acm.org>
Date:   Sat, 11 Apr 2020 16:21:17 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     Jens Axboe <axboe@...nel.dk>, Al Viro <viro@...iv.linux.org.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>, Jan Kara <jack@...e.cz>,
        Ming Lei <ming.lei@...hat.com>,
        Nicolai Stange <nstange@...e.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>, yu kuai <yukuai3@...wei.com>,
        linux-block@...r.kernel.org,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Omar Sandoval <osandov@...com>,
        Hannes Reinecke <hare@...e.com>,
        Michal Hocko <mhocko@...nel.org>
Subject: Re: [RFC v2 5/5] block: revert back to synchronous request_queue
 removal

On 2020-04-10 14:27, Luis Chamberlain wrote:
> On Fri, Apr 10, 2020 at 2:50 PM Luis Chamberlain <mcgrof@...nel.org> wrote:
>>
>> On Fri, Apr 10, 2020 at 8:34 AM Luis Chamberlain <mcgrof@...nel.org> wrote:
>>> On Thu, Apr 09, 2020 at 08:12:21PM -0700, Bart Van Assche wrote:
>>>> Please add a might_sleep() call in blk_put_queue() since with this patch
>>>> applied it is no longer allowed to call blk_put_queue() from atomic context.
>>>
>>> Sure thing.
>>
>> On second though, I don't think blk_put_queue() would be the right
>> place for might_sleep(), given we really only care about the *last*
>> refcount decrement to 0. So I'll move it to blk_release_queue().
>> Granted, at that point we are too late, and we'd get a splat about
>> this issue *iff* we really sleep. So yeah, I do suppose that forcing
>> this check there still makes sense.
> 
> I'll add might_sleep() to both blk_release_queue() *and* blk_cleanup_queue().

Since there is already an unconditional mutex_lock() call in
blk_cleanup_queue(), do we really need to add a might_sleep() call in
blk_cleanup_queue()?

Thanks,

Bart.