linux-kernel - Re: Linux 2.6.36-rc7

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: <1286473768.2656.21.camel@dhcp231-98.rdu.redhat.com>
Date:	Thu, 07 Oct 2010 13:49:28 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	agruen@...e.de
Subject: Re: Linux 2.6.36-rc7

On Thu, 2010-10-07 at 19:07 +0100, Alan Cox wrote:
> > I see two possibilities off the top of my head:
> > 
> > I could just slap an (unused) priority field onto the end of the
> > fanotify_init() syscall (assuming Linus doesn't murder me) so we can
> > build that support out with explicit priorities down the line, which I
> > think might be overkill, or
> > 
> > The other option (without breaking ABI as it stands today) is to define
> > some set of the fanotify_init() flags to be a priority field, we've got
> > 32 bits and only use 2 of them so giving 4-8 bits of that as a priority
> > (next cycle) isn't an issue and can be easily backwards compatible.
> 
> Except you've then got a magic release that works differently to every
> other release afterwards and which sods law says will get shipped by some
> big vendor. Both your proposals are "we got the API wrong,

Correct.

>  lets have one
> kernel that is special", that isn't good in the bigger scheme of things
> and will have if kernel 2.6.blah then crap forced into bits of app/lib
> code forever.

Not sure I understand this logic completely.  I see both of those
options as: we'd have a 2.6.36 kernel which don't have a priority
feature (and would reject apps that try to use it) and that feature
could be built into 2.6.37.  Apps built against 2.6.36 kernels would
still work on 2.6.37 (with a priority of 0 since that's all they could
set in 2.6.36)

> Given two chunks of "oh dear" last minute stuff would it be safer to
> simply punt and just pull the syscall/prototype itself (leaving the rest)
> for the release. That can go into the first pass of the next kernel tree,
> and if it the fixes and priority bits all work out may well then be tiny
> enough for -stable.

The safest thing would probably be to punt the syscalls to 2.6.37.
Which is sad since I know a number of people are already working against
them, but maybe that proves it's the best approach?

-Eric

--
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/