On 02.10.19 23:37, Qian Cai wrote:
> On Tue, 2019-09-24 at 16:36 +0200, David Hildenbrand wrote:
>> Since commit 3f906ba23689 ("mm/memory-hotplug: switch locking to a percpu
>> rwsem") we do a cpus_read_lock() in mem_hotplug_begin(). This was
>> introduced to fix a potential deadlock between
On Tue, 2019-09-24 at 16:36 +0200, David Hildenbrand wrote:
> Since commit 3f906ba23689 ("mm/memory-hotplug: switch locking to a percpu
> rwsem") we do a cpus_read_lock() in mem_hotplug_begin(). This was
> introduced to fix a potential deadlock between get_online_mems() and
> get_online_cpus() -
On 26.09.19 15:02, Qian Cai wrote:
> On Thu, 2019-09-26 at 13:52 +0200, Michal Hocko wrote:
>> On Thu 26-09-19 07:19:27, Qian Cai wrote:
>>>
>>>
On Sep 26, 2019, at 3:26 AM, Michal Hocko wrote:
OK, this is using for_each_online_cpu but why is this a problem? Have
you checked
On Thu, 2019-09-26 at 13:52 +0200, Michal Hocko wrote:
> On Thu 26-09-19 07:19:27, Qian Cai wrote:
> >
> >
> > > On Sep 26, 2019, at 3:26 AM, Michal Hocko wrote:
> > >
> > > OK, this is using for_each_online_cpu but why is this a problem? Have
> > > you checked what the code actually does?
On Thu 26-09-19 07:19:27, Qian Cai wrote:
>
>
> > On Sep 26, 2019, at 3:26 AM, Michal Hocko wrote:
> >
> > OK, this is using for_each_online_cpu but why is this a problem? Have
> > you checked what the code actually does? Let's say that online_pages is
> > racing with cpu hotplug. A new CPU
> On Sep 26, 2019, at 3:26 AM, Michal Hocko wrote:
>
> OK, this is using for_each_online_cpu but why is this a problem? Have
> you checked what the code actually does? Let's say that online_pages is
> racing with cpu hotplug. A new CPU appears/disappears from the online
> mask while we are
On Thu 26-09-19 09:26:13, David Hildenbrand wrote:
[...]
> I'd like to hear what Michal thinks. If we do want the cpu hotplug lock,
> we can at least restrict it to the call paths (e.g., online_pages())
> where the lock is really needed and document that.
Completely agreed. Conflating cpu and
On Wed 25-09-19 14:20:59, Qian Cai wrote:
> On Wed, 2019-09-25 at 19:48 +0200, Michal Hocko wrote:
> > On Wed 25-09-19 12:01:02, Qian Cai wrote:
> > > On Wed, 2019-09-25 at 09:02 +0200, David Hildenbrand wrote:
> > > > On 24.09.19 20:54, Qian Cai wrote:
> > > > > On Tue, 2019-09-24 at 17:11 +0200,
On 25.09.19 22:32, Qian Cai wrote:
> On Wed, 2019-09-25 at 21:48 +0200, David Hildenbrand wrote:
>> On 25.09.19 20:20, Qian Cai wrote:
>>> On Wed, 2019-09-25 at 19:48 +0200, Michal Hocko wrote:
On Wed 25-09-19 12:01:02, Qian Cai wrote:
> On Wed, 2019-09-25 at 09:02 +0200, David
On Wed, 2019-09-25 at 21:48 +0200, David Hildenbrand wrote:
> On 25.09.19 20:20, Qian Cai wrote:
> > On Wed, 2019-09-25 at 19:48 +0200, Michal Hocko wrote:
> > > On Wed 25-09-19 12:01:02, Qian Cai wrote:
> > > > On Wed, 2019-09-25 at 09:02 +0200, David Hildenbrand wrote:
> > > > > On 24.09.19
On 25.09.19 20:20, Qian Cai wrote:
> On Wed, 2019-09-25 at 19:48 +0200, Michal Hocko wrote:
>> On Wed 25-09-19 12:01:02, Qian Cai wrote:
>>> On Wed, 2019-09-25 at 09:02 +0200, David Hildenbrand wrote:
On 24.09.19 20:54, Qian Cai wrote:
> On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko
On Wed, 2019-09-25 at 19:48 +0200, Michal Hocko wrote:
> On Wed 25-09-19 12:01:02, Qian Cai wrote:
> > On Wed, 2019-09-25 at 09:02 +0200, David Hildenbrand wrote:
> > > On 24.09.19 20:54, Qian Cai wrote:
> > > > On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko wrote:
> > > > > On Tue 24-09-19
On Wed 25-09-19 12:01:02, Qian Cai wrote:
> On Wed, 2019-09-25 at 09:02 +0200, David Hildenbrand wrote:
> > On 24.09.19 20:54, Qian Cai wrote:
> > > On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko wrote:
> > > > On Tue 24-09-19 11:03:21, Qian Cai wrote:
> > > > [...]
> > > > > While at it, it
On Wed, 2019-09-25 at 09:02 +0200, David Hildenbrand wrote:
> On 24.09.19 20:54, Qian Cai wrote:
> > On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko wrote:
> > > On Tue 24-09-19 11:03:21, Qian Cai wrote:
> > > [...]
> > > > While at it, it might be a good time to rethink the whole locking over
>
On Tue 24-09-19 14:54:04, Qian Cai wrote:
> On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko wrote:
> > On Tue 24-09-19 11:03:21, Qian Cai wrote:
> > [...]
> > > While at it, it might be a good time to rethink the whole locking over
> > > there, as
> > > it right now read files under
On 24.09.19 20:54, Qian Cai wrote:
> On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko wrote:
>> On Tue 24-09-19 11:03:21, Qian Cai wrote:
>> [...]
>>> While at it, it might be a good time to rethink the whole locking over
>>> there, as
>>> it right now read files under /sys/kernel/slab/ could
On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko wrote:
> On Tue 24-09-19 11:03:21, Qian Cai wrote:
> [...]
> > While at it, it might be a good time to rethink the whole locking over
> > there, as
> > it right now read files under /sys/kernel/slab/ could trigger a possible
> > deadlock anyway.
> >
On 24.09.19 17:03, Qian Cai wrote:
> On Tue, 2019-09-24 at 16:36 +0200, David Hildenbrand wrote:
>> Since commit 3f906ba23689 ("mm/memory-hotplug: switch locking to a percpu
>> rwsem") we do a cpus_read_lock() in mem_hotplug_begin(). This was
>> introduced to fix a potential deadlock between
On Tue 24-09-19 11:03:21, Qian Cai wrote:
[...]
> While at it, it might be a good time to rethink the whole locking over there,
> as
> it right now read files under /sys/kernel/slab/ could trigger a possible
> deadlock anyway.
>
[...]
> [ 442.452090][ T5224] -> #0
On Tue, 2019-09-24 at 16:36 +0200, David Hildenbrand wrote:
> Since commit 3f906ba23689 ("mm/memory-hotplug: switch locking to a percpu
> rwsem") we do a cpus_read_lock() in mem_hotplug_begin(). This was
> introduced to fix a potential deadlock between get_online_mems() and
> get_online_cpus() -
On 24.09.19 16:48, Michal Hocko wrote:
> On Tue 24-09-19 16:36:15, David Hildenbrand wrote:
>> Since commit 3f906ba23689 ("mm/memory-hotplug: switch locking to a percpu
>> rwsem") we do a cpus_read_lock() in mem_hotplug_begin(). This was
>> introduced to fix a potential deadlock between
On Tue 24-09-19 16:36:15, David Hildenbrand wrote:
> Since commit 3f906ba23689 ("mm/memory-hotplug: switch locking to a percpu
> rwsem") we do a cpus_read_lock() in mem_hotplug_begin(). This was
> introduced to fix a potential deadlock between get_online_mems() and
> get_online_cpus() - the memory
Since commit 3f906ba23689 ("mm/memory-hotplug: switch locking to a percpu
rwsem") we do a cpus_read_lock() in mem_hotplug_begin(). This was
introduced to fix a potential deadlock between get_online_mems() and
get_online_cpus() - the memory and cpu hotplug lock. The root issue was
that
23 matches
Mail list logo