Re: [LSF/MM/BPF TOPIC] Generic page write protection

[Gao Xiang <hsiangkao@aol.com>]

On Tue, Jan 21, 2020 at 10:09:51PM -0800, Jerome Glisse wrote:
> On Wed, Jan 22, 2020 at 01:52:26PM +0800, Gao Xiang wrote:
> > On Tue, Jan 21, 2020 at 09:21:18PM -0800, Jerome Glisse wrote:
> > 
> > <snip>
> > 
> > > 
> > > The block device code only need the mapping on io error and they are
> > > different strategy depending on individual fs. fs using buffer_head
> > > can easily be updated. For other they are different solution and they
> > > can be updated one at a time with tailor solution.
> > 
> > If I did't misunderstand, how about post-processing fs code without
> > some buffer_head but page->private used as another way rather than
> > a pointer? (Yes, some alternative ways exist such as hacking struct
> > bio_vec...)
> 
> The ultimate answer is that page write protection will not be allow
> for some filesystem (that's how the patchset is designed in fact so
> that things can be merge piecemeal). But they are many way to solve
> the io error reporting and that's one of the thing i would like to get
> input on.
> 
> > 
> > I wonder the final plan on this from the community, learn new rule
> > and adapt my code anyway.. But in my opinion, such reserve way
> > (page->mapping likewise) is helpful in many respects, I'm not sure
> > we could totally get around all cases without it elegantly...
> 
> I still need to go read what it is you are trying to achieve. But i
> do not see any reason to remove page->mapping

I could say it's a huge project :) and I mean there may be some other
options to "insert a pointer directly or indirectly to struct page. "

However, I agree the current page->mapping rule is complicated to be
sorted out in words and make full use it :)

Thanks,
Gao Xiang