Thread (8 messages) 8 messages, 3 authors, 2020-01-22

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

From: Gao Xiang <hidden>
Date: 2020-01-22 06:21:52
Also in: linux-fsdevel, linux-mm

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:
quoted
On Tue, Jan 21, 2020 at 09:21:18PM -0800, Jerome Glisse wrote:

<snip>
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help