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: <20140514153042.40e75ab7b63c0d32afa1e10c@linux-foundation.org>
Date:	Wed, 14 May 2014 15:30:42 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Davidlohr Bueso <davidlohr@...com>
Cc:	Manfred Spraul <manfred@...orfullife.com>,
	Davidlohr Bueso <davidlohr.bueso@...com>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, 1vier1@....de
Subject: Re: [PATCH 6/6] ipc/sem.c: make semctl(,,{GETNCNT,GETZCNT})
 standard compliant

On Wed, 14 May 2014 07:52:38 -0700 Davidlohr Bueso <davidlohr@...com> wrote:

> > --- a/ipc/sem.c
> > +++ b/ipc/sem.c
> > @@ -993,38 +993,33 @@ static void do_smart_update(struct sem_array *sma, struct sembuf *sops, int nsop
> >  }
> >  
> >  /*
> > - * check_qop: Test how often a queued operation sleeps on the semaphore semnum
> > + * check_qop: Test if a queued operation sleeps on the semaphore semnum
> >   */
> >  static int check_qop(struct sem_array *sma, int semnum, struct sem_queue *q,
> >  			bool count_zero)
> >  {
> > -	struct sembuf *sops = q->sops;
> > -	int nsops = q->nsops;
> > -	int i, semcnt;
> > +	struct sembuf *sop = q->blocking;
> >  
> > -	semcnt = 0;
> > +	BUG_ON(sop->sem_flg & IPC_NOWAIT);
> > +	BUG_ON(sop->sem_op > 0);
> 
> Hmm in light of Linus' recent criticism about randomly sprinkling
> BUG_ONs in the kernel I'm not sure we want this. Yes, all those calls
> are correct from a logical pov and should never occur, however, would
> WARN be more suitable instead? I don't know. 

Well, this BUG_ON is so old that a decent approach would be to just
delete the thing, if only Manfred wasn't changing stuff.

Yes, if we can reasonably warn-then-recover then I guess that's worth
doing.

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