linux-kernel - Re: linux-next: duplicate patch in the mm 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: <20230131122314.umasrmx2hwe2epdx@quack3>
Date:   Tue, 31 Jan 2023 13:23:14 +0100
From:   Jan Kara <jack@...e.cz>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, Jan Kara <jack@...e.cz>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: duplicate patch in the mm tree

Hello!

On Tue 31-01-23 14:56:54, Stephen Rothwell wrote:
> The following commit is also in the ext3 tree as a different commit
> (but the same patch):
> 
>   05a4851d2729 ("fs: gracefully handle ->get_block not mapping bh in __mpage_writepage")
> 
> This is commit
> 
>   7010839ccfd4 ("fs: gracefully handle ->get_block not mapping bh in __mpage_writepage")
> 
> in the ext3 tree.

Yes, as we already discussed with Andrew, I've merged the patch to my tree
because otherwise UDF fixes result in triggering this problem and crashing
machine left-and-right (which results in a flood of emails from testing
infrastructure). So carrying the patch in my tree seems like by far
the simplest option (otherwise I'd have to either rebase on top of MM tree
or pull MM tree into my tree, neither of which looks particularly
attractive).
								Honza

[1] https://lore.kernel.org/all/20230127133213.su4cl6zuiuuv2p35@quack3

-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR