linux-kernel - Re: [PATCH 4.19 19/71] btrfs: extent_io: add proper error handling to lock_extent_buffer_for

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: <20201112160615.GC403069@sasha-vm>
Date:   Thu, 12 Nov 2020 11:06:15 -0500
From:   Sasha Levin <sashal@...nel.org>
To:     Ben Hutchings <ben.hutchings@...ethink.co.uk>
Cc:     Pavel Machek <pavel@....cz>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Qu Wenruo <wqu@...e.com>, David Sterba <dsterba@...e.com>
Subject: Re: [PATCH 4.19 19/71] btrfs: extent_io: add proper error handling
 to lock_extent_buffer_for_io()

On Wed, Nov 11, 2020 at 02:39:34PM +0000, Ben Hutchings wrote:
>On Wed, 2020-11-11 at 13:44 +0100, Pavel Machek wrote:
>> Hi!
>>
>> > Thankfully it's handled by the only caller, btree_write_cache_pages(),
>> > as later write_one_eb() call will trigger submit_one_bio().  So there
>> > shouldn't be any problem.
>>
>> This explains there should not be any problem in _the
>> mainline_. AFAICT this talks about this code. Mainline version is:
>>
>>  prev_eb = eb;
>>  ret = lock_extent_buffer_for_io(eb, &epd);
>>  if (!ret) {
>>  	free_extent_buffer(eb);
>>  	continue;
>>  } else if (ret < 0) {
>>  	done = 1;
>>  	free_extent_buffer(eb);
>>  	break;
>>  }
>>
>> But 4.19 has:
>>
>>  ret = lock_extent_buffer_for_io(eb, fs_info, &epd);
>>  if (!ret) {
>>   	free_extent_buffer(eb);
>>  	continue;
>>  }
>
>That was changed in mainline two releases after this commit, though.
>
>> IOW missing the code mentioned in the changelog. Is 0607eb1d452d4
>> prerequisite for this patch?
>
>I think it's a separate fix, but probably worth picking too.

I'll take it in too, thanks!

-- 
Thanks,
Sasha