On 11/12/2017 08:36 AM, Thomas Gleixner wrote:
> On Fri, 10 Nov 2017, Andi Kleen wrote:
All of that works. There is no way to make sure that a lookup is fully
serialized against a concurrent update. Even if the lookup holds
cpu_read_lock() the new package might arrive right after
On 11/12/2017 08:36 AM, Thomas Gleixner wrote:
> On Fri, 10 Nov 2017, Andi Kleen wrote:
All of that works. There is no way to make sure that a lookup is fully
serialized against a concurrent update. Even if the lookup holds
cpu_read_lock() the new package might arrive right after
On Fri, 10 Nov 2017, Andi Kleen wrote:
> > > All of that works. There is no way to make sure that a lookup is fully
> > > serialized against a concurrent update. Even if the lookup holds
> > > cpu_read_lock() the new package might arrive right after the unlock.
> > >
> >
> > Thanks Thomas.
> >
On Fri, 10 Nov 2017, Andi Kleen wrote:
> > > All of that works. There is no way to make sure that a lookup is fully
> > > serialized against a concurrent update. Even if the lookup holds
> > > cpu_read_lock() the new package might arrive right after the unlock.
> > >
> >
> > Thanks Thomas.
> >
> Andi's idea would work and the code would become much cleaner, if
> smp_store_cpu_info() only overwrote cpu_data for new physically hotplugged
> cpus.
Can always just use a separate per_cpu variable for this that is not cleared.
-Andi
> Andi's idea would work and the code would become much cleaner, if
> smp_store_cpu_info() only overwrote cpu_data for new physically hotplugged
> cpus.
Can always just use a separate per_cpu variable for this that is not cleared.
-Andi
On 11/10/2017 10:01 AM, Andi Kleen wrote:
>>> All of that works. There is no way to make sure that a lookup is fully
>>> serialized against a concurrent update. Even if the lookup holds
>>> cpu_read_lock() the new package might arrive right after the unlock.
>>>
>>
>> Thanks Thomas.
>>
>> Andi,
On 11/10/2017 10:01 AM, Andi Kleen wrote:
>>> All of that works. There is no way to make sure that a lookup is fully
>>> serialized against a concurrent update. Even if the lookup holds
>>> cpu_read_lock() the new package might arrive right after the unlock.
>>>
>>
>> Thanks Thomas.
>>
>> Andi,
> > All of that works. There is no way to make sure that a lookup is fully
> > serialized against a concurrent update. Even if the lookup holds
> > cpu_read_lock() the new package might arrive right after the unlock.
> >
>
> Thanks Thomas.
>
> Andi, do you want to take a look at this?
I was
> > All of that works. There is no way to make sure that a lookup is fully
> > serialized against a concurrent update. Even if the lookup holds
> > cpu_read_lock() the new package might arrive right after the unlock.
> >
>
> Thanks Thomas.
>
> Andi, do you want to take a look at this?
I was
On Fri, 10 Nov 2017, Thomas Gleixner wrote:
> On Fri, 10 Nov 2017, Prarit Bhargava wrote:
> > On 11/09/2017 07:43 PM, Thomas Gleixner wrote:
> > > On Sun, 5 Nov 2017, Prarit Bhargava wrote:
> > >> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
> > >> virtual machines.
>
On Fri, 10 Nov 2017, Thomas Gleixner wrote:
> On Fri, 10 Nov 2017, Prarit Bhargava wrote:
> > On 11/09/2017 07:43 PM, Thomas Gleixner wrote:
> > > On Sun, 5 Nov 2017, Prarit Bhargava wrote:
> > >> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
> > >> virtual machines.
>
On Fri, 10 Nov 2017, Prarit Bhargava wrote:
> On 11/09/2017 07:43 PM, Thomas Gleixner wrote:
> > On Sun, 5 Nov 2017, Prarit Bhargava wrote:
> >> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
> >> virtual machines.
> >
> > What has this to do with virtual machines? The
On Fri, 10 Nov 2017, Prarit Bhargava wrote:
> On 11/09/2017 07:43 PM, Thomas Gleixner wrote:
> > On Sun, 5 Nov 2017, Prarit Bhargava wrote:
> >> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
> >> virtual machines.
> >
> > What has this to do with virtual machines? The
On 11/09/2017 07:43 PM, Thomas Gleixner wrote:
> On Sun, 5 Nov 2017, Prarit Bhargava wrote:
>> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
>> virtual machines.
>
> What has this to do with virtual machines? The very same issue is on
> physcial hardware because this
On 11/09/2017 07:43 PM, Thomas Gleixner wrote:
> On Sun, 5 Nov 2017, Prarit Bhargava wrote:
>> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
>> virtual machines.
>
> What has this to do with virtual machines? The very same issue is on
> physcial hardware because this
On Sun, 5 Nov 2017, Prarit Bhargava wrote:
> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
> virtual machines.
What has this to do with virtual machines? The very same issue is on
physcial hardware because this is called from the early CPU bringup code
with interrupts
On Sun, 5 Nov 2017, Prarit Bhargava wrote:
> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
> virtual machines.
What has this to do with virtual machines? The very same issue is on
physcial hardware because this is called from the early CPU bringup code
with interrupts
18 matches
Mail list logo
