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]
Date:   Sat, 25 Feb 2023 08:13:55 +0100
From:   Christian Brauner <brauner@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Charan Teja Kalla <quic_charante@...cinc.com>,
        Giuseppe Scrivano <gscrivan@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the mm tree with Linus' tree

On Fri, Feb 24, 2023 at 06:04:43PM -0800, Andrew Morton wrote:
> On Sat, 25 Feb 2023 10:39:51 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > Today's linux-next merge of the mm tree got a conflict in:
> > 
> >   mm/shmem.c
> > 
> > between commit:
> > 
> >   7a80e5b8c6fa ("shmem: support idmapped mounts for tmpfs")
> 
> mm/shmem.c is under, umm, mm/.
> 
> Said patch was not made available to the linux-mm subscribers or to the
> shmem.c developers.  It doesn't have a Link: tag and doesn't appear to
> have been cc:linux-kernel and a google search for the title doesn't tell
> me much.

Hey Andrew,

Sorry, I picked up that patch because it deals with a vfs only feature
we maintain. It has no implications for mm and just deals with per-mount
file ownership changes (Detailed documentation under
Documentation/filesystems/idmappings.rst. It needs updates as of v6.3
but is correct otherwise.). While Hugh was Cced I didn't pay more
attention to what lists were Cced. Sorry about that. But again, it
really has no consequences for mm otherwise I'd never have taken it.

Re Link: Patches I pick up don't have Link [1] tags pointing to the
submission on lore as Linus had said in a discussion in 2022 that he
prefers to not have the lore links in the commit message at all.

[1]: https://lore.kernel.org/linux-fsdevel/20230120094346.3182328-1-gscrivan@redhat.com

Thanks!
Christian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ