svn commit: r272505 - in head/sys: kern sys

[Stefan Farfeleder]

On Sun, Oct 05, 2014 at 08:16:17PM +0300, Konstantin Belousov wrote:
> On Sun, Oct 05, 2014 at 06:39:54PM +0200, Stefan Farfeleder wrote:
> > On Sat, Oct 04, 2014 at 02:21:54PM +0000, Bjoern A. Zeeb wrote:
> > > 
> > > On 04 Oct 2014, at 08:08 , Mateusz Guzik <mjg at FreeBSD.org> wrote:
> > > 
> > > > Author: mjg
> > > > Date: Sat Oct  4 08:08:56 2014
> > > > New Revision: 272505
> > > > URL: https://svnweb.freebsd.org/changeset/base/272505
> > > > 
> > > > Log:
> > > >  Plug capability races.
> > > > 
> > > >  fp and appropriate capability lookups were not atomic, which could result in
> > > >  improper capabilities being checked.
> > > > 
> > > >  This could result either in protection bypass or in a spurious ENOTCAPABLE.
> > > > 
> > > >  Make fp + capability check atomic with the help of sequence counters.
> > > > 
> > > >  Reviewed by:	kib
> > > >  MFC after:	3 weeks
> > > > 
> > > > Modified:
> > > >  head/sys/kern/kern_descrip.c
> > > >  head/sys/sys/filedesc.h
> > > > ???
> > > 
> > > 
> > > This file is included from user space.  There is no opt_capsicum.h there.
> > > Including an opt_* in the header file seems wrong in a lot of ways usually.
> > > 
> > > I tried to add a bandaid for the moment with r272523 which (to be honest) makes it worse.
> > > 
> > > This needs a better fix.
> > 
> > Hi,
> > 
> > this also breaks the nvidia-driver port (also with your fix).
> 
> Is the breakage due to missing opt_capsicum.h file ?
> If yes, what I proposed, i.e. making the new member unconditional,
> should fix it without changes to the module build system.

Yes, it breaks due to the missing file.

Stefan