On Tue, Apr 02, 2024 at 04:25:10PM -0700, Eric Biggers wrote: > On Fri, Mar 29, 2024 at 05:43:06PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > Create an experimental ioctl so that we can turn off fsverity. > > The concept of "experimental ioctls" seems problematic. What if people start > relying on them? Linux tends not to have "experimental" system calls, and > probably for good reason... They're trapped in my enormous backlog of patches. They get this special treatment so that I can show them to developers without anyone getting any fancy ideas about merging them. Once I get close enough to actually consider merging it, I'll move it out from under EXPERIMENTAL. IOWs: I'm not planning to push xfs_fs_staging.h itself to upstream ever. > Also, what is the use case for this ioctl? Is it necessary to have this when > userspace can already just replace a verity file with a copy that has verity > disabled? That's less efficient, but it does not require any kernel support and > does not require CAP_SYS_ADMIN. No, of course it isn't needed if replacing the file is easy. That however assumes that replacing /is/ easy. The use case for this is: "I enabled fsverity on my backup volume so I could detect bitrot, then the primary disk died, and when I went to restore the primary, I got a verity error." Being able to read known-bad corrupted contents are less bad than losing the entire file or having to do surgery with xfs_db to turn off fsverity. Just for my own convenience, this would enable me to try out fsverity in a few places while being able to undo it quickly if <cough> we end up changing the ondisk format during review. > And of course, if do we add this ioctl it shouldn't be XFS-specific. Yes, this is a proof of concept. I'd lift it to fs/verity/ if you accept the premise. --D > - Eric >
