linux-kernel - Re: 2.6.23-rc6-mm1: IPC: sleeping function called ...

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:	Thu, 20 Sep 2007 15:19:00 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Nadia Derbey <Nadia.Derbey@...l.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Alexey Dobriyan <adobriyan@...ru>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.23-rc6-mm1: IPC: sleeping function called ...

On Thu, Sep 20, 2007 at 10:52:43AM +0200, Nadia Derbey wrote:
> Jarek Poplawski wrote:
...
> >which seems to suggest "out" is an RCU protected pointer, so, I
> >thought these refcounts were for something else. But, after looking
> >at how it's used it turns out to be ~90% wrong: probably 9 out of 10
> >places use refcouning around this,
> 
> Actually, ipc_lock() is called most of the time without the 
> ipc_ids.mutex held and without refcounting (maybe you didn't look for 
> the msg_lock() sem_lock() and shm_lock() too).

Yes, you are 100% right and I'm 90% lier, 10% blind (maybe backward
too).

> So I think disabling preemption is needed, isn't it?

Do I've to tell the truth...?

> 
> >so, these rcu_read_locks() don't
> >work here at all. So, probably I miss something again, but IMHO,
> >these rcu_read_locks/unlocks could be removed here or in
> >ipc_lock_by_ptr() and it should be enough to use them directly, where
> >really needed, e.g., in msg.c do_msgrcv().
> >
> 
> I have to check for the ipc_lock_by_ptr(): may be you're right!

Since this whole locking scheme is really quite a puzzle, and needs
more than one or two looks to figure it out, I'd better try stop to
discredit myself more.

Anyway it looks to me like the most sophisticated way of achieving
locklessness I've seen so far. I hope, there is still some gain after
this RCU + refcounting vs. simple locking. (It seems somebody had
similar doubts writing the "Lockless receive, part 1:" comment in
do_msgrcv(); and probably again I'm very wrong, but this checking of
validity of RCU protected structure with an r_msg value, which is
done to avoid refcounting, looks like not very different and has
some cost too).

Regards,
Jarek P.
-
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/