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]
Date:	Tue, 18 Sep 2007 03:34:00 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Nadia Derbey <Nadia.Derbey@...l.net>
Cc:	Alexey Dobriyan <adobriyan@...ru>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.23-rc6-mm1: IPC: sleeping function called ...

On Tue, 18 Sep 2007 12:30:52 +0200 Nadia Derbey <Nadia.Derbey@...l.net> wrote:

> Andrew Morton wrote:
> > On Tue, 18 Sep 2007 13:17:28 +0400 Alexey Dobriyan <adobriyan@...ru> wrote:
> > 
> > 
> >>I'm getting tons of this, and X fails to start
> >>
> >>CONFIG_SYSVIPC=y
> >>CONFIG_SYSVIPC_SYSCTL=y
> >># CONFIG_PREEMPT_NONE is not set
> >># CONFIG_PREEMPT_VOLUNTARY is not set
> >>CONFIG_PREEMPT=y
> >>CONFIG_PREEMPT_BKL=y
> >>CONFIG_DEBUG_PREEMPT=y
> >>
> >>BUG: sleeping function called from invalid context at kernel/rwsem.c:47
> >>in_atomic():1, irqs_disabled():0
> >>no locks held by X/5879.
> >> [<c012bcb1>] down_write+0x15/0x50
> >> [<c01b53af>] do_shmat+0x235/0x3a0
> >> [<c0106be2>] sys_ipc+0x146/0x263
> >> [<c0102892>] sysenter_past_esp+0xa7/0xb5
> >> [<c0102856>] sysenter_past_esp+0x6b/0xb5
> >> =======================
> > 
> > 
> > Here's a bug:
> > 
> > --- a/ipc/util.c~ipc-integrate-ipc_checkid-into-ipc_lock-fix-2
> > +++ a/ipc/util.c
> > @@ -691,7 +691,7 @@ struct kern_ipc_perm *ipc_lock(struct ip
> >  		rcu_read_unlock();
> >  		return ERR_PTR(-EINVAL);
> >  	}
> > -
> > +	rcu_read_unlock();
> >  	return out;
> >  }
> >  
> 
> Andrew,
> 
> Actually the rcu_read_lock is released in ipc_unlock().

I agree it should be, but it isn't.

> So I think we 
> shouldn't add an rcu_read_unlock() before leaving ipc_lock().
> This is a part that has not changed since the ref code.
> 

Well, it was an optimisation.  spin_lock() implies rcu_read_lock().  That's
a bit dirty and we might choose to not do that.

Would be interested in knowing the locking rules in there.  For example,
this:

/**
 *	ipc_findkey	-	find a key in an ipc identifier set	
 *	@ids: Identifier set
 *	@key: The key to find
 *	
 *	Requires ipc_ids.mutex locked.
 *	Returns the LOCKED pointer to the ipc structure if found or NULL
 *	if not.
 *	If key is found ipc contains its ipc structure
 */

appears to be hopelessly out of date?

-
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