> > > Anyway, I understand that Intel has been ignoring kernel.org instead of
> > > sending forwarding their patches properly so you're doing a difficult
> > > and thankless job... Thanks for that. I'm sure it's frustrating to
> > > look at these patches for you as well.
> >
> > Thank you for
On Wed, 2018-05-16 at 09:12 +, Dilger, Andreas wrote:
> On May 16, 2018, at 02:00, Dan Carpenter wrote:
> >
> > On Tue, May 15, 2018 at 04:02:55PM +0100, James Simmons wrote:
> > >
> > > > > /*
> > > > >* Allocate new object. This may result in rather
On Tue, May 15, 2018 at 04:02:55PM +0100, James Simmons wrote:
> > > /*
> > >* Allocate new object. This may result in rather complicated
> > >* operations, including fld queries, inode loading, etc.
> > >*/
> > > o = lu_object_alloc(env, dev, f, conf);
> > > - if (IS_ERR(o))
> > >
On May 16, 2018, at 02:00, Dan Carpenter wrote:
>
> On Tue, May 15, 2018 at 04:02:55PM +0100, James Simmons wrote:
>>
/*
* Allocate new object. This may result in rather complicated
* operations, including fld queries, inode loading, etc.
On Tue, May 15, 2018 at 04:02:55PM +0100, James Simmons wrote:
>
> > > /*
> > >* Allocate new object. This may result in rather complicated
> > >* operations, including fld queries, inode loading, etc.
> > >*/
> > > o = lu_object_alloc(env, dev, f, conf);
> > > - if (IS_ERR(o))
>
> > /*
> > * Allocate new object. This may result in rather complicated
> > * operations, including fld queries, inode loading, etc.
> > */
> > o = lu_object_alloc(env, dev, f, conf);
> > - if (IS_ERR(o))
> > + if (unlikely(IS_ERR(o)))
> > return o;
> >
>
> >> On Wed, May 02 2018, James Simmons wrote:
> >>
> >> > From: Lai Siyao
> >> >
> >> > Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want
> >> > to remove object from cache, but this may lead to deadlock, because
> >> > when other process lookup such object,
On Tue, May 15 2018, James Simmons wrote:
>> On Wed, May 02 2018, James Simmons wrote:
>>
>> > From: Lai Siyao
>> >
>> > Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want
>> > to remove object from cache, but this may lead to deadlock, because
>> > when other
> On Wed, May 02 2018, James Simmons wrote:
>
> > From: Lai Siyao
> >
> > Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want
> > to remove object from cache, but this may lead to deadlock, because
> > when other process lookup such object, it needs to wait for
> /*
>* Allocate new object. This may result in rather complicated
>* operations, including fld queries, inode loading, etc.
>*/
> o = lu_object_alloc(env, dev, f, conf);
> - if (IS_ERR(o))
> + if (unlikely(IS_ERR(o)))
> return o;
>
This
On Wed, May 02, 2018 at 02:21:48PM -0400, James Simmons wrote:
> From: Lai Siyao
>
> Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want
> to remove object from cache, but this may lead to deadlock, because
> when other process lookup such object, it needs to
On Wed, May 02 2018, James Simmons wrote:
> From: Lai Siyao
>
> Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want
> to remove object from cache, but this may lead to deadlock, because
> when other process lookup such object, it needs to wait for this
> object
From: Lai Siyao
Currently we set LU_OBJECT_HEARD_BANSHEE on object when we want
to remove object from cache, but this may lead to deadlock, because
when other process lookup such object, it needs to wait for this
object until release (done at last refcount put), while that
13 matches
Mail list logo