On Wed, Jun 26, 2019 at 04:51:51AM +0100, Al Viro wrote: > On Tue, Jun 25, 2019 at 07:33:31PM -0700, Darrick J. Wong wrote: > > --- a/fs/attr.c > > +++ b/fs/attr.c > > @@ -236,6 +236,9 @@ int notify_change(struct dentry * dentry, struct iattr * attr, struct inode **de > > if (IS_IMMUTABLE(inode)) > > return -EPERM; > > > > + if (IS_SWAPFILE(inode)) > > + return -ETXTBSY; > > + > > if ((ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID | ATTR_TIMES_SET)) && > > IS_APPEND(inode)) > > return -EPERM; > > Er... So why exactly is e.g. chmod(2) forbidden for swapfiles? Or touch(1), > for that matter... Oops, that check is overly broad; I think the only attribute change we need to filter here is ATTR_SIZE.... which we could do unconditionally in inode_newsize_ok. What's the use case for allowing userspace to increase the size of an active swapfile? I don't see any; the kernel has a permanent lease on the file space mapping (at least until swapoff)... > > diff --git a/mm/swapfile.c b/mm/swapfile.c > > index 596ac98051c5..1ca4ee8c2d60 100644 > > --- a/mm/swapfile.c > > +++ b/mm/swapfile.c > > @@ -3165,6 +3165,19 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags) > > if (error) > > goto bad_swap; > > > > + /* > > + * Flush any pending IO and dirty mappings before we start using this > > + * swap file. > > + */ > > + if (S_ISREG(inode->i_mode)) { > > + inode->i_flags |= S_SWAPFILE; > > + error = inode_drain_writes(inode); > > + if (error) { > > + inode->i_flags &= ~S_SWAPFILE; > > + goto bad_swap; > > + } > > + } > > Why are swap partitions any less worthy of protection? Hmm, yeah, S_SWAPFILE should apply to block devices too. I figured that the mantra of "sane tools will open block devices with O_EXCL" should have sufficed, but there's really no reason to allow that either. --D ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/