linux-kernel - Re: [PATCH v1 5/7] xfs: Add device retry

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: <b24bdf13-e5b3-3793-54fe-5eca5b10915a@oracle.com>
Date:   Wed, 28 Nov 2018 09:47:13 -0700
From:   Allison Henderson <allison.henderson@...cle.com>
To:     Bob Liu <bob.liu@...cle.com>,
        Christoph Hellwig <hch@...radead.org>,
        Dave Chinner <david@...morbit.com>
Cc:     linux-block@...r.kernel.org, linux-xfs@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        martin.petersen@...cle.com, shirley.ma@...cle.com
Subject: Re: [PATCH v1 5/7] xfs: Add device retry



On 11/28/18 5:41 AM, Bob Liu wrote:
> On 11/28/18 3:35 PM, Christoph Hellwig wrote:
>> On Wed, Nov 28, 2018 at 04:08:50PM +1100, Dave Chinner wrote:
>>> So the first time through this loop the block layer devices what
>>> device to read from, then we iterate devices 1..n on error.
>>>
>>> Whihc means if device 0 is the only one with good information in it,
>>> we may not ever actually read from it.
>>>
>>> I'd suggest that a hint of "-1" (or equivalent max value) should be
>>> used for "device selects mirror leg" rather than 0, so we can
>>> actually read from the first device on command.
>>
>> Yes.  For one thing I think we really need to split this retry counter
>> of sorts from the write hints.  I.e. make both u8 types and keep them
>> separate.  Then start out with (u8)-1 as initialized by the block layer
>> for the first attempt.  The device then fills out which leg it used
>> (in the completion path, so that another underlying driver doesn't
>> override it!), and then the file system just preserves this value on
>> a resumit, leaving the driver to chose a new value when it gets a
>> non -1 value.
>>
> 
> Will update as suggested, thank you for all your feedback :)
> 
> -Bob
> 

Yes, thanks everyone for your feed back.  Maybe Bob and I can come up 
with some test cases that recreate the problem scenarios described here 
and see if we can work out a solution to the multi bio complexities. 
Thanks!

Allison