Hi all,
On 09/24/2013 02:04 AM, Davidlohr Bueso wrote:
(In reality, I suspect the reference count is never elevated in
practice, so there is only one case that calls the security freeing
thing, so this may all be pretty much theoretical, but at least from a
logic standpoint the code clearly
Hi Linus,
On 09/24/2013 03:22 AM, Linus Torvalds wrote:
On Mon, Sep 23, 2013 at 5:04 PM, Davidlohr Bueso wrote:
Ok, so here's the code - again I've tested it with LTP on the resources
I have.
This looks good to me.
Manfred, mind giving this a look-over and see if this resolves your
race
Hi Linus,
On 09/24/2013 03:22 AM, Linus Torvalds wrote:
On Mon, Sep 23, 2013 at 5:04 PM, Davidlohr Bueso davidl...@hp.com wrote:
Ok, so here's the code - again I've tested it with LTP on the resources
I have.
This looks good to me.
Manfred, mind giving this a look-over and see if this
Hi all,
On 09/24/2013 02:04 AM, Davidlohr Bueso wrote:
(In reality, I suspect the reference count is never elevated in
practice, so there is only one case that calls the security freeing
thing, so this may all be pretty much theoretical, but at least from a
logic standpoint the code clearly
On Mon, Sep 23, 2013 at 5:04 PM, Davidlohr Bueso wrote:
>
> Ok, so here's the code - again I've tested it with LTP on the resources
> I have.
This looks good to me.
Manfred, mind giving this a look-over and see if this resolves your
race concerns too?
Linus
--
To unsubscribe from
On Mon, 2013-09-23 at 09:54 -0700, Linus Torvalds wrote:
> On Sun, Sep 22, 2013 at 11:42 PM, Davidlohr Bueso wrote:
> >>
> >> More importantly, it's wrong. You do the call_rcu() unconditionally,
> >> but it might not be the last use! You need to do it with the same
> >> logic ipc_rcu_putref(),
On Sun, Sep 22, 2013 at 11:42 PM, Davidlohr Bueso wrote:
>>
>> More importantly, it's wrong. You do the call_rcu() unconditionally,
>> but it might not be the last use! You need to do it with the same
>> logic ipc_rcu_putref(), namely at the dropping of the last reference.
>
> This is the way IPC
On Sat, 2013-09-21 at 11:58 -0700, Linus Torvalds wrote:
> On Sat, Sep 21, 2013 at 11:30 AM, Davidlohr Bueso wrote:
> >
> > IPC uses security_xxx_free() at two levels: for freeing the structure
> > (ie: shm_destroy()) and cleaning up upon error when creating the
> > structure (ie: newseg()). For
On Sat, 2013-09-21 at 11:58 -0700, Linus Torvalds wrote:
On Sat, Sep 21, 2013 at 11:30 AM, Davidlohr Bueso davidl...@hp.com wrote:
IPC uses security_xxx_free() at two levels: for freeing the structure
(ie: shm_destroy()) and cleaning up upon error when creating the
structure (ie:
On Sun, Sep 22, 2013 at 11:42 PM, Davidlohr Bueso davidl...@hp.com wrote:
More importantly, it's wrong. You do the call_rcu() unconditionally,
but it might not be the last use! You need to do it with the same
logic ipc_rcu_putref(), namely at the dropping of the last reference.
This is the
On Mon, 2013-09-23 at 09:54 -0700, Linus Torvalds wrote:
On Sun, Sep 22, 2013 at 11:42 PM, Davidlohr Bueso davidl...@hp.com wrote:
More importantly, it's wrong. You do the call_rcu() unconditionally,
but it might not be the last use! You need to do it with the same
logic ipc_rcu_putref(),
On Mon, Sep 23, 2013 at 5:04 PM, Davidlohr Bueso davidl...@hp.com wrote:
Ok, so here's the code - again I've tested it with LTP on the resources
I have.
This looks good to me.
Manfred, mind giving this a look-over and see if this resolves your
race concerns too?
Linus
--
To
On Sat, Sep 21, 2013 at 11:30 AM, Davidlohr Bueso wrote:
>
> IPC uses security_xxx_free() at two levels: for freeing the structure
> (ie: shm_destroy()) and cleaning up upon error when creating the
> structure (ie: newseg()). For both I believe we can actually use RCU.
> What do you think of the
Hi Eric,
On Fri, 2013-09-20 at 14:08 -0400, Eric Paris wrote:
> > > Note that Linus suggested a good alternative to patches 1 and 3: use
> > > kfree_rcu() and delay the freeing of the security structure. I would
> > > much prefer that approach to doing security checks with the lock held,
> > >
Hi Eric,
On Fri, 2013-09-20 at 14:08 -0400, Eric Paris wrote:
Note that Linus suggested a good alternative to patches 1 and 3: use
kfree_rcu() and delay the freeing of the security structure. I would
much prefer that approach to doing security checks with the lock held,
but I want to
On Sat, Sep 21, 2013 at 11:30 AM, Davidlohr Bueso davidl...@hp.com wrote:
IPC uses security_xxx_free() at two levels: for freeing the structure
(ie: shm_destroy()) and cleaning up upon error when creating the
structure (ie: newseg()). For both I believe we can actually use RCU.
What do you
On Thu, 2013-09-19 at 14:22 -0700, Davidlohr Bueso wrote:
> On Sun, 2013-09-15 at 20:04 -0700, Davidlohr Bueso wrote:
> > This patchset deals with the selinux and rmid races Manfred found on
> > the ipc scaling work that has been going on. It specifically addresses
> > shared mem and msg queues.
On Thu, 2013-09-19 at 14:22 -0700, Davidlohr Bueso wrote:
On Sun, 2013-09-15 at 20:04 -0700, Davidlohr Bueso wrote:
This patchset deals with the selinux and rmid races Manfred found on
the ipc scaling work that has been going on. It specifically addresses
shared mem and msg queues. While
On Sun, 2013-09-15 at 20:04 -0700, Davidlohr Bueso wrote:
> This patchset deals with the selinux and rmid races Manfred found on
> the ipc scaling work that has been going on. It specifically addresses
> shared mem and msg queues. While semaphores still need updated, I want
> to make sure these
On Sun, 2013-09-15 at 20:04 -0700, Davidlohr Bueso wrote:
This patchset deals with the selinux and rmid races Manfred found on
the ipc scaling work that has been going on. It specifically addresses
shared mem and msg queues. While semaphores still need updated, I want
to make sure these are
This patchset deals with the selinux and rmid races Manfred found on
the ipc scaling work that has been going on. It specifically addresses
shared mem and msg queues. While semaphores still need updated, I want
to make sure these are correct first. Also, Manfred had already sent out
a patchset
This patchset deals with the selinux and rmid races Manfred found on
the ipc scaling work that has been going on. It specifically addresses
shared mem and msg queues. While semaphores still need updated, I want
to make sure these are correct first. Also, Manfred had already sent out
a patchset
22 matches
Mail list logo
