Prateek Sood 于2019年5月14日周二 下午7:00写道：
>
> On 5/14/19 4:26 PM, Mukesh Ojha wrote:
> > ++
> >
> > On 5/4/2019 8:17 PM, Muchun Song wrote:
> >> Benjamin Herrenschmidt 于2019年5月2日周四 下午2:25写道：
> >>
> > The basic idea yes, the whole bool *locked is horrid though.
> > Wouldn't it
> > work to h
On 5/14/19 4:26 PM, Mukesh Ojha wrote:
> ++
>
> On 5/4/2019 8:17 PM, Muchun Song wrote:
>> Benjamin Herrenschmidt 于2019年5月2日周四 下午2:25写道：
>>
> The basic idea yes, the whole bool *locked is horrid though.
> Wouldn't it
> work to have a get_device_parent_locked that always returns with
>
++
On 5/4/2019 8:17 PM, Muchun Song wrote:
Benjamin Herrenschmidt 于2019年5月2日周四 下午2:25写道：
The basic idea yes, the whole bool *locked is horrid though.
Wouldn't it
work to have a get_device_parent_locked that always returns with
the mutex held,
or just move the mutex to the caller or something
Thanks for the comment, will check the patch and update.
Regards
Gaurav
On 5/10/2019 4:52 AM, Benjamin Herrenschmidt wrote:
On Thu, 2019-05-09 at 20:08 +0530, Gaurav Kohli wrote:
Hi ,
Last patch will serialize the addition of child to parent directory,
won't it affect performance.
I doubt t
On Thu, 2019-05-09 at 20:08 +0530, Gaurav Kohli wrote:
> Hi ,
>
> Last patch will serialize the addition of child to parent directory,
> won't it affect performance.
I doubt this is a significant issue, and there's already a global lock
taken once or twice in that path, the fix is purely to make
Hi ,
Last patch will serialize the addition of child to parent directory,
won't it affect performance.
Regards
Gaurav
On 5/4/2019 9:04 PM, Greg KH wrote:
On Sat, May 04, 2019 at 10:47:07PM +0800, Muchun Song wrote:
Benjamin Herrenschmidt 于2019年5月2日周四 下午2:25写道：
The basic idea yes, the who
On Sat, May 04, 2019 at 10:47:07PM +0800, Muchun Song wrote:
> Benjamin Herrenschmidt 于2019年5月2日周四 下午2:25写道：
>
> > > > The basic idea yes, the whole bool *locked is horrid though.
> > > > Wouldn't it
> > > > work to have a get_device_parent_locked that always returns with
> > > > the mutex held,
Benjamin Herrenschmidt 于2019年5月2日周四 下午2:25写道：
> > > The basic idea yes, the whole bool *locked is horrid though.
> > > Wouldn't it
> > > work to have a get_device_parent_locked that always returns with
> > > the mutex held,
> > > or just move the mutex to the caller or something simpler like this
On Sun, 2019-04-28 at 22:49 +0800, Muchun Song wrote:
> Hi Greg and Rafael:
>
>
> Benjamin Herrenschmidt 于2019年4月28日周日
> 下午6:10写道：
> >
> > The basic idea yes, the whole bool *locked is horrid though.
> > Wouldn't it
> > work to have a get_device_parent_locked that always returns with
> > the mu
Hi Greg and Rafael:
Benjamin Herrenschmidt 于2019年4月28日周日 下午6:10写道：
>
> The basic idea yes, the whole bool *locked is horrid though. Wouldn't it
> work to have a get_device_parent_locked that always returns with the mutex
> held,
> or just move the mutex to the caller or something simpler like t
On Thu, 2019-04-25 at 23:44 +0800, Muchun Song wrote:
> I agree with you that the looking up of the glue dir and creation of its child
> should be protected by the same lock of gdp_mutex. So, do you agree with
> the fix of the following code snippet?
The basic idea yes, the whole bool *locked is h
Hi Cheers,
Benjamin Herrenschmidt 于2019年4月25日周四 下午5:24写道：
>
> On Tue, 2019-04-23 at 22:32 +0800, Muchun Song wrote:
> > There is a race condition between removing glue directory and adding a new
> > device under the glue directory. It can be reproduced in following test:
> >
>
> .../...
>
> > In
On Tue, 2019-04-23 at 22:32 +0800, Muchun Song wrote:
> There is a race condition between removing glue directory and adding a new
> device under the glue directory. It can be reproduced in following test:
>
.../...
> In order to avoid this happening, we we should not call kobject_del() on
> pa
There is a race condition between removing glue directory and adding a new
device under the glue directory. It can be reproduced in following test:
path 1: Add the child device under glue dir
device_add()
get_device_parent()
mutex_lock(&gdp_mutex);
/*find parent fr
14 matches
Mail list logo
