Linux Kernel https://git.etezian.org/cgit.cgi/linux.git/atom?h=master 2016-12-19T16:23:53+00:00 2016-12-19T16:23:53+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-12-19T16:23:53+00:00 urn:sha1:e93b1cc8a8965da137ffea0b88e5f62fa1d2a9e6 Pull quota, fsnotify and ext2 updates from Jan Kara: "Changes to locking of some quota operations from dedicated quota mutex to s_umount semaphore, a fsnotify fix and a simple ext2 fix" * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: quota: Fix bogus warning in dquot_disable() fsnotify: Fix possible use-after-free in inode iteration on umount ext2: reject inodes with negative size quota: Remove dqonoff_mutex ocfs2: Use s_umount for quota recovery protection quota: Remove dqonoff_mutex from dquot_scan_active() ocfs2: Protect periodic quota syncing with s_umount semaphore quota: Use s_umount protection for quota operations quota: Hold s_umount in exclusive mode when enabling / disabling quotas fs: Provide function to get superblock with exclusive s_umount 2016-12-19T13:01:39+00:00 Jan Kara jack@suse.cz 2016-12-19T13:01:39+00:00 urn:sha1:2700e6067c72a99d1b7037692da0145ac44623c4 dquot_disable() was warning when sb_has_quota_loaded() was true when invalidating page cache for quota files. The thinking behind this warning was that we must have raced with somebody else turning quotas on and this should not happen because all places modifying quota state must hold s_umount exclusively now. However sb_has_quota_loaded() can be also true at this point when we are just suspending quotas on remount read-only. Just restore the behavior to situation before commit c3b004460d77 ("quota: Remove dqonoff_mutex") which introduced the warning. The code in dquot_disable() can be further simplified with the new locking of quota state changes however let's leave that to a separate commit that can get more testing exposure. Fixes: c3b004460d77bf3f980d877be539016f2df4df12 Signed-off-by: Jan Kara <jack@suse.cz> 2016-12-18T02:44:00+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-12-18T02:44:00+00:00 urn:sha1:0110c350c86d511be2130cb2a30dcbb76c4af750 Pull more vfs updates from Al Viro: "In this pile: - autofs-namespace series - dedupe stuff - more struct path constification" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (40 commits) ocfs2: implement the VFS clone_range, copy_range, and dedupe_range features ocfs2: charge quota for reflinked blocks ocfs2: fix bad pointer cast ocfs2: always unlock when completing dio writes ocfs2: don't eat io errors during _dio_end_io_write ocfs2: budget for extent tree splits when adding refcount flag ocfs2: prohibit refcounted swapfiles ocfs2: add newlines to some error messages ocfs2: convert inode refcount test to a helper simple_write_end(): don't zero in short copy into uptodate exofs: don't mess with simple_write_{begin,end} 9p: saner ->write_end() on failing copy into non-uptodate page fix gfs2_stuffed_write_end() on short copies fix ceph_write_end() nfs_write_end(): fix handling of short copies vfs: refactor clone/dedupe_file_range common functions fs: try to clone files first in vfs_copy_file_range vfs: misc struct path constification namespace.c: constify struct path passed to a bunch of primitives quota: constify struct path in quota_on ... 2016-12-06T00:03:06+00:00 Al Viro viro@zeniv.linux.org.uk 2016-11-21T00:49:34+00:00 urn:sha1:8c54ca9c6882f5a68d19a82fd063b74f91d4c22b Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 2016-11-30T07:38:07+00:00 Jan Kara jack@suse.cz 2016-11-23T13:04:55+00:00 urn:sha1:c3b004460d77bf3f980d877be539016f2df4df12 The only places that were grabbing dqonoff_mutex are functions turning quotas on and off and these are properly serialized using s_umount semaphore. Remove dqonoff_mutex. Signed-off-by: Jan Kara <jack@suse.cz> 2016-11-30T07:37:11+00:00 Jan Kara jack@suse.cz 2016-11-23T12:52:19+00:00 urn:sha1:ee1ac541a2446b13b2525929e719e84b63d5e5da All callers of dquot_scan_active() now hold s_umount so we can rely on that lock to protect us against quota state changes. Signed-off-by: Jan Kara <jack@suse.cz> 2016-11-24T14:27:16+00:00 Jan Kara jack@suse.cz 2016-11-23T12:35:14+00:00 urn:sha1:9d1ccbe70e0b14545caad12dc73adb3605447df0 Writeback quota is protected by s_umount semaphore held for reading because every writeback must be protected by that lock (grabbed either by the generic writeback code or by quotactl handler). Getting next available ID in quota file, querying quota state, setting quota information, getting quota format are all quotactl operations protected by s_umount semaphore held for reading grabbed in quotactl handler. This also fixes lockdep splat about possible deadlock during filesystem freezing where sync_filesystem() is called with page-faults already blocked but sync_filesystem() calls into dquot_writeback_dquots() which grabs dqonoff_mutex which ranks above i_mutex (vfs_load_quota_inode() grabs i_mutex under dqonoff_mutex) which clearly ranks below page fault freeze protection (e.g. via mmap_sem dependencies). The reported problem is not a real deadlock possibility since during quota on we check whether filesystem freezing is not in progress but still it is good to have this fixed. Reported-by: Ted Tso <tytso@mit.edu> Reported-by: Eric Whitney <enwlinux@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> 2016-11-24T14:26:53+00:00 Jan Kara jack@suse.cz 2016-11-23T12:16:10+00:00 urn:sha1:7d6cd73d33b62021111a469b6a454ec357be295f Currently we hold s_umount semaphore only in shared mode when enabling or disabling quotas and use dqonoff_mutex for serializing quota state changes on a filesystem and also quota state changes with other places depending on current quota state. Using dedicated mutex for this causes possible deadlocks during filesystem freezing (see following commit for details) so we transition to using s_umount semaphore for the necessary synchronization whose lock ordering is properly handled by the filesystem freezing code. As a start grab s_umount in exclusive mode when enabling / disabling quotas. Signed-off-by: Jan Kara <jack@suse.cz> 2016-10-27T20:16:09+00:00 Johannes Berg johannes.berg@intel.com 2016-10-24T12:40:05+00:00 urn:sha1:56989f6d8568c21257dcec0f5e644d5570ba3281 Now genl_register_family() is the only thing (other than the users themselves, perhaps, but I didn't find any doing that) writing to the family struct. In all families that I found, genl_register_family() is only called from __init functions (some indirectly, in which case I've add __init annotations to clarifly things), so all can actually be marked __ro_after_init. This protects the data structure from accidental corruption. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2016-10-27T20:16:09+00:00 Johannes Berg johannes.berg@intel.com 2016-10-24T12:40:03+00:00 urn:sha1:489111e5c25b93be80340c3113d71903d7c82136 Instead of providing macros/inline functions to initialize the families, make all users initialize them statically and get rid of the macros. This reduces the kernel code size by about 1.6k on x86-64 (with allyesconfig). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>