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: <alpine.DEB.2.21.1806221537570.2402@nanos.tec.linutronix.de>
Date:   Fri, 22 Jun 2018 15:39:16 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Al Viro <viro@...IV.linux.org.uk>
cc:     David Howells <dhowells@...hat.com>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: manual merge of the tip tree with the vfs tree

On Fri, 22 Jun 2018, Al Viro wrote:
> On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote:
> > Reinette Chatre <reinette.chatre@...el.com> wrote:
> > 
> > > Thomas and David, please let me know what I can do from my side to help
> > > with this.
> > 
> > You could try basing on Al Viro's for-next tree which has the mount API
> > changes in it.
> 
> Umm...  That would be a massive headache for everyone involved; the changes
> in there have very little in common with what you are doing in rdt_mount(),
> so it might make sense to start with a minimal never-rebased branch that
> would
> 	* define rdt_pseudo_lock_init as 0
> 	* define rdt_pseudo_lock_release as empty
> 	* do the rdt_mount() part of a3dbd01e6c9d
> 	* have commit message along the lines of
> "hooks in rdt_mount() for rdt_pseudo_lock to use
> 
> Functionally a no-op right now; the only reason for having that
> as a never-rebased branch to get rdt_pseudo_lock and mount series
> out of each other's hair"
> 
> Base that on -rc1, then pull it into your rdt branch and David could pull the
> same into his.

Yes, that works.

Reinette, can you please look into creating that ordering. Then we just zap
the existing branch and redo it with this scheme.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ