linux-kernel - Re: [PATCH -next] rsxx: Convert to DEFINE_SHOW

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] [day] [month] [year] [list]

Message-ID: <cf90611a-799e-c1d9-f1d0-15e7f5868637@huawei.com>
Date:   Sat, 19 Sep 2020 10:14:55 +0800
From:   miaoqinglang <miaoqinglang@...wei.com>
To:     Jens Axboe <axboe@...nel.dk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Joshua Morris <josh.h.morris@...ibm.com>,
        Philip Kelleher <pjk1939@...ux.ibm.com>
CC:     <linux-block@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next] rsxx: Convert to DEFINE_SHOW_ATTRIBUTE



在 2020/7/17 10:16, Jens Axboe 写道:
> On 7/16/20 7:37 PM, miaoqinglang wrote:
>>
>> 在 2020/7/16 23:45, Jens Axboe 写道:
>>> On 7/16/20 3:04 AM, Qinglang Miao wrote:
>>>> From: Liu Shixin <liushixin2@...wei.com>
>>>>
>>>> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>>> None of these apply against the 5.9 block tree, looks like some
>>> read -> read_iter conversion has happened in another branch that
>>> I'm not privy to.
>>
>> Hi Jens,
>>
>>       Sorry I didn't mention it in commit log, but this patch is based
>> on linux-next where commit <4d4901c6d7> has switched over direct
>> seq_read method calls to seq_read_iter, this is why there's conflict in
>> your apply.
>>
>>       Do you think I should send a new patch based on 5.8rc?
> 
> That'll just create a needless conflict. But I don't even know what tree
> is carrying the patch that changes it to use seq_read_iter, so hard to
> make other suggestions.
> 
Hi Jens,

I resent a new patch against linux-next(20200917), and it can
be applied to mainline cleanly now.

Thanks.

> Alternatively, I can hang on to them until the other change hits
> mainline, and then queue them up after that.
>