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: <20151210092025.7c356624@canb.auug.org.au>
Date:	Thu, 10 Dec 2015 09:20:25 +1100
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Mike Marshall <hubcap@...ibond.com>
Cc:	Al Viro <viro@...iv.linux.org.uk>, linux-next@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Andreas Gruenbacher <agruenba@...hat.com>
Subject: Re: linux-next: build failure after merge of the vfs tree

Hi Mike,

On Wed, 9 Dec 2015 16:30:34 -0500 Mike Marshall <hubcap@...ibond.com> wrote:
>
> I'm having a chicken-and-egg moment here...

not really ...

> I think "posix acls: Remove duplicate xattr name definitions" got into
> linux-next after
> Linus committed  Linux 4.4-rc4.

Yes

> Unless I merge my for-next with Linus' tree at the current (arbitrary)
> point, I need to wait
> until I can merge with rc5 before I can apply this fix.
> 
> I know Linus hates to get pull requests for stuff that's not based on
> a discrete tag,
> I'm not sure what's appropriate for linux-next... ?

That commit is *not* in Linus' tree and won't be until the next merge
window.  There is nothing you can do about it until then.  I will carry
the merge resolution patch in linus-next and then someone needs to let
Linus know what needs to be done when the latter of the two trees is
merged into his.  This is pretty standard when there is a conflict like
this that cannot be automatically resolved by git.

OK, I wrote all that and then I realised that the preferred names
(XATTR_NAME_POSIX_ACL_..) have been in Linus' tree for a long time (in
include/uapi/linux/xattr.h), so you could just change the orangefs tree
to use those already. i.e. my patch should apply cleanly to the
orangefs tree and build and work correctly independently of the vfs
tree change (I think).

BTW, there is also a section just above the bit this patch affects that
could be removed completely (it has "#if 0" around it).
-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ