* Xunlei Pang wrote:
> Hi Ingo,
>
> On 12/04/2015 at 04:09 PM, Ingo Molnar wrote:
> > * Xunlei Pang wrote:
> >
> >>> Hm, is the alloc_cpumask_var() done in alloc_sched_domains() safe?
> >> Until now, I haven't found any other similar issues, but I will check
> >> further.
> >>
> >>> At least
* Peter Zijlstra wrote:
> On Fri, Dec 04, 2015 at 09:09:01AM +0100, Ingo Molnar wrote:
> > and then this code:
> >
> > > > cpumask_andnot(doms_cur[0], cpu_map, cpu_isolated_map);
> >
> > uses it without first clearing it.
> >
> > So is this another such bug, or am I missing something?
Hi Ingo,
On 12/04/2015 at 04:09 PM, Ingo Molnar wrote:
> * Xunlei Pang wrote:
>
>>> Hm, is the alloc_cpumask_var() done in alloc_sched_domains() safe?
>> Until now, I haven't found any other similar issues, but I will check
>> further.
>>
>>> At least the usage pattern in init_sched_domains() lo
On Fri, Dec 04, 2015 at 09:09:01AM +0100, Ingo Molnar wrote:
> and then this code:
>
> > > cpumask_andnot(doms_cur[0], cpu_map, cpu_isolated_map);
>
> uses it without first clearing it.
>
> So is this another such bug, or am I missing something?
It uses it as destination, it does a comp
* Xunlei Pang wrote:
> > Hm, is the alloc_cpumask_var() done in alloc_sched_domains() safe?
>
> Until now, I haven't found any other similar issues, but I will check further.
>
> >
> > At least the usage pattern in init_sched_domains() looks unsafe:
> >
> > doms_cur = alloc_sched_domai
Hi Ingo,
On 12/03/2015 at 04:28 PM, Ingo Molnar wrote:
> * Xunlei Pang wrote:
>
>> Hi Peter,
>>
>> On 12/03/2015 at 12:25 AM, Peter Zijlstra wrote:
>>> On Wed, Dec 02, 2015 at 09:12:30PM +0800, Xunlei Pang wrote:
Hi Peter,
On 12/02/2015 at 08:34 PM, Peter Zijlstra wrote:
> On W
On Thu, Dec 03, 2015 at 10:44:08AM +0800, Xunlei Pang wrote:
> > Nice, will you be looking for similar issues elsewhere in the scheduler
> > too?
>
> Sure :-)
Thanks!
> >>> in alloc_rootdomain() ?
> >> There is a "memset(rd, 0, sizeof(*rd))" in init_rootdomain(),
> >> so I don't think we need t
* Xunlei Pang wrote:
> Hi Peter,
>
> On 12/03/2015 at 12:25 AM, Peter Zijlstra wrote:
> > On Wed, Dec 02, 2015 at 09:12:30PM +0800, Xunlei Pang wrote:
> >> Hi Peter,
> >>
> >> On 12/02/2015 at 08:34 PM, Peter Zijlstra wrote:
> >>> On Wed, Dec 02, 2015 at 07:52:59PM +0800, Xunlei Pang wrote:
> >
Hi Peter,
On 12/03/2015 at 12:25 AM, Peter Zijlstra wrote:
> On Wed, Dec 02, 2015 at 09:12:30PM +0800, Xunlei Pang wrote:
>> Hi Peter,
>>
>> On 12/02/2015 at 08:34 PM, Peter Zijlstra wrote:
>>> On Wed, Dec 02, 2015 at 07:52:59PM +0800, Xunlei Pang wrote:
The patch cleans the garbage by using
On Wed, Dec 02, 2015 at 09:12:30PM +0800, Xunlei Pang wrote:
> Hi Peter,
>
> On 12/02/2015 at 08:34 PM, Peter Zijlstra wrote:
> > On Wed, Dec 02, 2015 at 07:52:59PM +0800, Xunlei Pang wrote:
> >> The patch cleans the garbage by using zalloc_cpumask_var()
> >> instead of alloc_cpumask_var() for roo
Hi Peter,
On 12/02/2015 at 08:34 PM, Peter Zijlstra wrote:
> On Wed, Dec 02, 2015 at 07:52:59PM +0800, Xunlei Pang wrote:
>> The patch cleans the garbage by using zalloc_cpumask_var()
>> instead of alloc_cpumask_var() for root_domain::rto_mask
>> allocation, thereby addressing the issues.
> How di
On Wed, Dec 02, 2015 at 07:52:59PM +0800, Xunlei Pang wrote:
> The patch cleans the garbage by using zalloc_cpumask_var()
> instead of alloc_cpumask_var() for root_domain::rto_mask
> allocation, thereby addressing the issues.
How did you notice this? Also do we want to do the same for the kmalloc
root_domain::rto_mask allocated through alloc_cpumask_var()
contains garbage data, this may cause problems. For instance,
When doing pull_rt_task(), it may do useless iterations if
rto_mask retains some extra garbage bits. Worse still, this
violates the isolated domain rule for clustered scheduling
13 matches
Mail list logo
