Re: Is it OK to pass non-acquired objects to kfree?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 10, 2015 at 10:13:33AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 10, 2015 at 11:55:35AM +0200, Dmitry Vyukov wrote:
> > On Thu, Sep 10, 2015 at 1:31 AM, Christoph Lameter <cl@xxxxxxxxx> wrote:
> > > On Wed, 9 Sep 2015, Paul E. McKenney wrote:

[ . . . ]

> > There are memory allocator implementations that do reads and writes of
> > the object, and there are memory allocator implementations that do not
> > do any barriers on fast paths. From this follows that objects must be
> > passed in quiescent state to kfree.
> > Now, kernel memory model says "A load-load control dependency requires
> > a full read memory barrier".
> > >From this follows that the following code is broken:
> > 
> > // kernel/pid.c
> >          if ((atomic_read(&pid->count) == 1) ||
> >               atomic_dec_and_test(&pid->count)) {
> >                  kmem_cache_free(ns->pid_cachep, pid);
> >                  put_pid_ns(ns);
> >          }
> > 
> > and it should be:
> > 
> > // kernel/pid.c
> >          if ((smp_load_acquire(&pid->count) == 1) ||
> 
> If Will Deacon's patch providing generic support for relaxed atomics
> made it in, we want:
> 
> 	  if ((atomic_read_acquire(&pid->count) == 1) ||
> 
> Otherwise, we need an explicit barrier.

And atomic_read_acquire() is in fact now in mainline, so it is the
best choice here.

							Thanx, Paul

> >               atomic_dec_and_test(&pid->count)) {
> >                  kmem_cache_free(ns->pid_cachep, pid);
> >                  put_pid_ns(ns);
> >          }
> > 
> > 
> > 
> > -- 
> > Dmitry Vyukov, Software Engineer, dvyukov@xxxxxxxxxx
> > Google Germany GmbH, Dienerstraße 12, 80331, München
> > Geschäftsführer: Graham Law, Christine Elizabeth Flores
> > Registergericht und -nummer: Hamburg, HRB 86891
> > Sitz der Gesellschaft: Hamburg
> > Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat
> > sind, leiten Sie diese bitte nicht weiter, informieren Sie den
> > Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
> > This e-mail is confidential. If you are not the right addressee please
> > do not forward it, please inform the sender, and please erase this
> > e-mail including any attachments. Thanks.
> > 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]