lkml.org 
[lkml]   [2017]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks
From
Date
Am 12.12.2017 um 22:28 schrieb David Rientjes:
> On Tue, 12 Dec 2017, Dimitri Sivanich wrote:
>
>>> --- a/drivers/misc/sgi-gru/grutlbpurge.c
>>> +++ b/drivers/misc/sgi-gru/grutlbpurge.c
>>> @@ -298,6 +298,7 @@ struct gru_mm_struct *gru_register_mmu_notifier(void)
>>> return ERR_PTR(-ENOMEM);
>>> STAT(gms_alloc);
>>> spin_lock_init(&gms->ms_asid_lock);
>>> + gms->ms_notifier.flags = 0;
>>> gms->ms_notifier.ops = &gru_mmuops;
>>> atomic_set(&gms->ms_refcnt, 1);
>>> init_waitqueue_head(&gms->ms_wait_queue);
>>> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
>> There is a kzalloc() just above this:
>> gms = kzalloc(sizeof(*gms), GFP_KERNEL);
>>
>> Is that not sufficient to clear the 'flags' field?
>>
> Absolutely, but whether it is better to explicitly document that the mmu
> notifier has cleared flags, i.e. there are no blockable callbacks, is
> another story. I can change it if preferred.

Actually I would invert the new flag, in other words specify that an MMU
notifier will never sleep.

The first reason is that we have 8 blocking notifiers and 5 not blocking
if I counted right. So it is actually more common to sleep than not to.

The second reason is to be conservative and assume the worst, e.g. that
the flag is forgotten when a new notifier is added.

Regards,
Christian.

\
 
 \ /
  Last update: 2017-12-13 10:35    [W:0.096 / U:1.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site