linux-kernel - Re: linux-next: build failure after merge of the block tree

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: <b2418ce5-839d-43d4-e5ea-416be9f63b1a@kernel.dk>
Date:   Tue, 26 May 2020 07:53:34 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     David Sterba <dsterba@...e.cz>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Goldwyn Rodrigues <rgoldwyn@...e.com>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        Christoph Hellwig <hch@....de>
Subject: Re: linux-next: build failure after merge of the block tree

On 5/25/20 10:36 PM, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 25 May 2020 13:03:44 -0600 Jens Axboe <axboe@...nel.dk> wrote:
>>
>> On 5/24/20 11:08 PM, Stephen Rothwell wrote:
>>>
>>> After merging the block tree, today's linux-next build (arm
>>> multi_v7_defconfig) failed like this:
>>>
>>> mm/filemap.c: In function 'generic_file_buffered_read':
>>> mm/filemap.c:2075:9: error: 'written' undeclared (first use in this function); did you mean 'writeb'?
>>>  2075 |     if (written) {
>>>       |         ^~~~~~~
>>>       |         writeb
>>>
>>> Caused by commit
>>>
>>>   23d513106fd8 ("mm: support async buffered reads in generic_file_buffered_read()")
>>>
>>> from the block tree interacting with commit
>>>
>>>   6e66f10f2cac ("fs: export generic_file_buffered_read()")
>>>
>>> from the btrfs tree.
>>>
>>> [Aside: that btrfs tree commit talks about "correct the comments and variable
>>>     names", but changes "written" to "copied" in the function definition
>>>     but to "already_read" in the header file declaration ...]
>>>
>>> I ave applied the following merge fix patch:  
>>
>> Looks like a frivolous change... Thanks for fixing this up Stephen.
> 
> The variable name change has been removed from the btrfs tree.

Thanks - I'd encourage that name changing late in the merge window
instead. The change is obviously fine, but a) it should not be done in
an unrelated change, and b) it can be done without risking causing silly
merge issues.

-- 
Jens Axboe