On Tue, Sep 25, 2007 at 01:47:05PM +0200, Jarek Poplawski wrote:
> On Mon, Sep 24, 2007 at 11:50:23AM +0200, Nadia Derbey wrote:
> > Jarek Poplawski wrote:
> ...
> > >2. I'm not sure this refcounting with ipc_rcu_getref/putref is SMP
> > >safe (memory barriers): it's not atomic, so locking is neede
On Mon, Sep 24, 2007 at 11:50:23AM +0200, Nadia Derbey wrote:
> Jarek Poplawski wrote:
...
> >2. I'm not sure this refcounting with ipc_rcu_getref/putref is SMP
> >safe (memory barriers): it's not atomic, so locking is needed, but
> >e.g. in do_msgsnd() kern_ipc_perm lock is used for this, while
>
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 03:08:42PM +0200, Nadia Derbey wrote:
Nadia Derbey wrote:
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
...
Actually, ipc_lock() is called most of the time without the
ipc_ids.mutex held and without r
Jarek Poplawski wrote:
On Fri, Sep 21, 2007 at 01:03:47PM +0200, Jarek Poplawski wrote:
...
I hope not! But, then it would be probably another logical trick:
ipc_rcu_getref/putref() seems to prevent kfreeing of a structure, so
if it's used in do_msgsnd() there should be a risk something can do
On Mon, Sep 24, 2007 at 08:54:07AM +0200, Jarek Poplawski wrote:
> After rethinking, this scenario seems to be wrong or very unprobable
> (I'm not sure of all ways "if (--container...)" could be compiled),
> so there should be no such risk - double kfree/vfree is more probable,
> so no danger. More
On Fri, Sep 21, 2007 at 01:03:47PM +0200, Jarek Poplawski wrote:
...
> I hope not! But, then it would be probably another logical trick:
> ipc_rcu_getref/putref() seems to prevent kfreeing of a structure, so
> if it's used in do_msgsnd() there should be a risk something can do
> this kfree at this
On Fri, Sep 21, 2007 at 01:03:47PM +0200, Jarek Poplawski wrote:
...
> any of them does ipc_rcu_getref() a bit later and sees old (cached)
Should be:
"any of them does ipc_rcu_putref() a bit later and sees old (cached)"
Sorry,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe l
On Fri, Sep 21, 2007 at 12:11:15PM +0200, Nadia Derbey wrote:
> Jarek Poplawski wrote:
...
> >2. I'm not sure this refcounting with ipc_rcu_getref/putref is SMP
> >safe (memory barriers): it's not atomic, so locking is needed, but
> >e.g. in do_msgsnd() kern_ipc_perm lock is used for this, while
>
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 03:08:42PM +0200, Nadia Derbey wrote:
Nadia Derbey wrote:
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
...
Actually, ipc_lock() is called most of the time without the
ipc_ids.mutex held and without r
Andrew Morton wrote:
On Tue, 18 Sep 2007 16:55:19 +0200 Nadia Derbey <[EMAIL PROTECTED]> wrote:
This patch fixes the missing rcu_read_(un)lock in the ipc code
Thanks. Could you please check the code comments in ipc/util.c for
accuracy and completeness sometime?
Done - see attachment.
Ho
On Thu, Sep 20, 2007 at 03:08:42PM +0200, Nadia Derbey wrote:
> Nadia Derbey wrote:
> >Jarek Poplawski wrote:
> >
> >>On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
...
> >Actually, ipc_lock() is called most of the time without the
> >ipc_ids.mutex held and without refcounting (mayb
On Thu, Sep 20, 2007 at 03:08:42PM +0200, Nadia Derbey wrote:
...
> So, here is the ipc_lock_by_ptr() status:
> 1) do_msgsnd(), semctl_main(GETALL), semctl_main(SETALL) and find_undo()
> call it inside a refcounting.
> ==> no rcu read section needed.
>
> 2) *_exit_ns(), ipc_findkey() and sysvip
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 1
Nadia Derbey wrote:
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
Jarek Poplawski wrote:
On 18-09-2007 16:55, Nadia Derbey wrote:
...
Well, reviewing the code I found another place where the
rcu_read_unlock() was missing.
I'm so sorry for the inconv
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
Jarek Poplawski wrote:
On 18-09-2007 16:55, Nadia Derbey wrote:
...
Well, reviewing the code I found another place where the
rcu_read_unlock() was missing.
I'm so sorry for the inconvenience. It's true tha
On Thu, Sep 20, 2007 at 09:28:21AM +0200, Jarek Poplawski wrote:
> On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
...
> > Before Calling msg_unlock() they call ipc_rcu_getref() that increments a
> > refcount in the rcu header for the msg structure. This guarantees that
> > the the
On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
> Jarek Poplawski wrote:
> >On 18-09-2007 16:55, Nadia Derbey wrote:
> >...
> >
> >>Well, reviewing the code I found another place where the
> >>rcu_read_unlock() was missing.
> >>I'm so sorry for the inconvenience. It's true that I sho
Jarek Poplawski wrote:
On 18-09-2007 16:55, Nadia Derbey wrote:
...
Well, reviewing the code I found another place where the
rcu_read_unlock() was missing.
I'm so sorry for the inconvenience. It's true that I should have tested
with CONFIG_PREEMPT=y :-(
Now, the ltp tests pass even with this
On 18-09-2007 16:55, Nadia Derbey wrote:
...
>
> Well, reviewing the code I found another place where the
> rcu_read_unlock() was missing.
> I'm so sorry for the inconvenience. It's true that I should have tested
> with CONFIG_PREEMPT=y :-(
> Now, the ltp tests pass even with this option set...
On Tue, 18 Sep 2007 11:29:24 -0700 "Paul E. McKenney"
<[EMAIL PROTECTED]> wrote:
> On Tue, Sep 18, 2007 at 09:57:15AM -0700, Andrew Morton wrote:
> > On Tue, 18 Sep 2007 09:13:37 -0700 "Paul E. McKenney" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Tue, Sep 18, 2007 at 02:24:51PM +0200, Peter Zij
On Tue, Sep 18, 2007 at 09:57:15AM -0700, Andrew Morton wrote:
> On Tue, 18 Sep 2007 09:13:37 -0700 "Paul E. McKenney" <[EMAIL PROTECTED]>
> wrote:
>
> > On Tue, Sep 18, 2007 at 02:24:51PM +0200, Peter Zijlstra wrote:
> > > On Tue, 18 Sep 2007 03:34:00 -0700 Andrew Morton
> > > <[EMAIL PROTECTED]
On Tue, 18 Sep 2007 09:13:37 -0700 "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 18, 2007 at 02:24:51PM +0200, Peter Zijlstra wrote:
> > On Tue, 18 Sep 2007 03:34:00 -0700 Andrew Morton
> > <[EMAIL PROTECTED]> wrote:
> >
> > > Well, it was an optimisation. spin_lock() implies rcu_r
On Tue, 18 Sep 2007 16:55:19 +0200 Nadia Derbey <[EMAIL PROTECTED]> wrote:
> This patch fixes the missing rcu_read_(un)lock in the ipc code
Thanks. Could you please check the code comments in ipc/util.c for
accuracy and completeness sometime?
-
To unsubscribe from this list: send the line "unsub
On Tue, Sep 18, 2007 at 02:24:51PM +0200, Peter Zijlstra wrote:
> On Tue, 18 Sep 2007 03:34:00 -0700 Andrew Morton
> <[EMAIL PROTECTED]> wrote:
>
> > Well, it was an optimisation. spin_lock() implies rcu_read_lock(). That's
> > a bit dirty and we might choose to not do that.
>
> Not true for th
Andrew Morton wrote:
On Tue, 18 Sep 2007 13:17:28 +0400 Alexey Dobriyan <[EMAIL PROTECTED]> 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
On Tue, 18 Sep 2007 12:30:52 +0200 Nadia Derbey <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Tue, 18 Sep 2007 13:17:28 +0400 Alexey Dobriyan <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> >>I'm getting tons of this, and X fails to start
> >>
> >>CONFIG_SYSVIPC=y
> >>CONFIG_SYSVIPC_SYSCTL=
On Tue, Sep 18, 2007 at 03:27:27AM -0700, Andrew Morton wrote:
> On Tue, 18 Sep 2007 13:17:28 +0400 Alexey Dobriyan <[EMAIL PROTECTED]> 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
> > # CONFI
On Tue, 18 Sep 2007 13:17:28 +0400 Alexey Dobriyan <[EMAIL PROTECTED]> 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
> CONF
Andrew Morton wrote:
On Tue, 18 Sep 2007 13:17:28 +0400 Alexey Dobriyan <[EMAIL PROTECTED]> 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
On Tue, 18 Sep 2007 13:17:28 +0400 Alexey Dobriyan <[EMAIL PROTECTED]> 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
> CONF
On Tue, 18 Sep 2007 13:17:28 +0400 Alexey Dobriyan <[EMAIL PROTECTED]> 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
> CONF
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_at
32 matches
Mail list logo
