[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bc50acea-ebc9-5be8-0fcc-9b96031a7348@linux.intel.com>
Date: Fri, 7 Sep 2018 14:51:02 -0700
From: Dave Hansen <dave.hansen@...ux.intel.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>,
linux-kernel@...r.kernel.org
Cc: peterz@...radead.org, tglx@...utronix.de, x86@...nel.org,
luto@...nel.org
Subject: Re: [RFC][PATCH 5/8] x86/mm: fix exception table comments
>> + * Only do the expensive exception table search when we might be at
>> + * risk of a deadlock:
>> + * 1. We failed to acquire mmap_sem, and
>> + * 2. The access was an explicit kernel-mode access
>> + * (X86_PF_USER=0).
>
> Might be worth reminding the reader that X86_PF_USER will be set in
> sw_error_code for implicit accesses. I saw "explicit" and my mind
> immediately jumped to hw_error_code for whatever reason. E.g.:
>
> * 2. The access was an explicit kernel-mode access (we set X86_PF_USER
> * in sw_error_code for implicit kernel-mode accesses).
Yeah, that was not worded well. Is this better?
> * Only do the expensive exception table search when we might be at
> * risk of a deadlock:
> * 1. We failed to acquire mmap_sem, and
> * 2. The access was an explicit kernel-mode access. An access
> * from user-mode will X86_PF_USER=1 set via hw_error_code or
> * set in sw_error_code if it were an implicit kernel-mode
> * access that originated in user mode.
Powered by blists - more mailing lists