Messages in this thread | | | Date | Tue, 1 Mar 2022 18:01:04 -0800 | From | Ira Weiny <> | Subject | Re: [PATCH V8 40/44] memremap_pages: Add pgmap_protection_flag_invalid() |
| |
On Mon, Jan 31, 2022 at 05:37:17PM -0800, Edgecombe, Rick P wrote: > On Thu, 2022-01-27 at 09:55 -0800, ira.weiny@intel.com wrote: > > +/* > > + * pgmap_protection_flag_invalid - Check and flag an invalid use of > > a pgmap > > + * protected page > > + * > > + * There are code paths which are known to not be compatible with > > pgmap > > + * protections. > > This could get hopefully get stale. Maybe the comment should just > describe what the function does and leave this reasoning to the commit > log?
Thanks for the review but based on the thread with Dan this patch is dropped.
Thanks, Ira
> > > pgmap_protection_flag_invalid() is provided as a 'relief > > + * valve' to be used in those functions which are known to be > > incompatible. > > + * > > + * Thus an invalid use case can be flaged with more precise data > > rather than > > + * just flagging a fault. Like the fault handler code this abandons > > In the commit log you called this "the invalid access on fault" and it > seemed a little clearer to me then "just flagging a fault". > > > the use of > > + * the PKS key and optionally allows the calling code path to > > continue based on > > + * the configuration of the memremap.pks_fault_mode command line > > + * (and/or sysfs) option. > > It lets the calling code continue regardless right? It just warns if > !PKS_MODE_STRICT. Why not warn in the case of PKS_MODE_STRICT too? > > Seems surprising that the stricter setting would have less checks. > > > + */ > > +static inline void pgmap_protection_flag_invalid(struct page *page) > > +{ > > + if (!pgmap_check_pgmap_prot(page)) > > + return; > > + __pgmap_protection_flag_invalid(page->pgmap); > > +}
| |