On Fri, Nov 29, 2024 at 04:03:44PM +0000, Matthew Wilcox wrote: > On Fri, Nov 29, 2024 at 03:31:34PM +0000, Lorenzo Stoakes wrote: > > While it is not ideal to use a VM_PFNMAP here, doing anything else will > > result in the page_mkwrite() hook need to be provided, which requires the > > same page->mapping hack this patch seeks to undo. > > Or we could map the first page read-write to begin with ... ? This would sort of be a rejig, as then you'd just make pfn_mkwrite() always fail and be doing essentially the same thing, only varying what prot you set on map (you can't just set the other pages read-only in prot and not provide pfn_mkwrite(), if you do the kernel will simply make them writable on write fault in wp_page_reuse() :) > Or we could implement a page_mkwrite handler, but do the permissions > change in the driver and return VM_FAULT_NOPAGE. Yeah interesting, that's possible, but wouldn't we need to be careful about TLB etc. in that case since the mapping will have already been established? I suppose we could zap then set, but that's icky... Even if you don't pre-map this will be the case as it faults in first before invoking page_mkwrite()... > > I don't think we should do the second option in this driver, but > mentioning it because we're going to need to have A Talk about fb_defio. > Yes I think we're good with the current solution for perf, despite its warty nature it works (TM). I fear that this Talk may involve much gnashing of teeth...
