Re: [f2fs-dev] [GIT PULL] f2fs update for 6.8-rc1

On Thu, Jan 11, 2024 at 09:05:51PM -0800, Linus Torvalds wrote: > On Thu, 11 Jan 2024 at 10:28, Jaegeuk Kim wrote: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git > > tags/f2fs-for-6.8-rc1 > > Hmm. I got a somewhat confusing conflict in f2fs_rename(). > > And honestly,

Re: [f2fs-dev] [PATCH v2 8/8] fscrypt: Move d_revalidate configuration back into fscrypt

On Fri, Dec 15, 2023 at 04:16:08PM -0500, Gabriel Krisman Bertazi wrote: > +static const struct dentry_operations fscrypt_dentry_ops = { > + .d_revalidate = fscrypt_d_revalidate, > +}; > + > int __fscrypt_prepare_lookup(struct inode *dir, struct dentry *dentry, >

Re: [f2fs-dev] [PATCH v2 2/8] fscrypt: Drop d_revalidate if key is available

On Thu, Dec 21, 2023 at 07:14:02AM +, Al Viro wrote: > On Fri, Dec 15, 2023 at 04:16:02PM -0500, Gabriel Krisman Bertazi wrote: > > fscrypt dentries are always valid once the key is available. Since the > > key cannot be removed without evicting the dentry, we don't need to ke

Re: [f2fs-dev] [PATCH v2 2/8] fscrypt: Drop d_revalidate if key is available

On Fri, Dec 15, 2023 at 04:16:02PM -0500, Gabriel Krisman Bertazi wrote: > fscrypt dentries are always valid once the key is available. Since the > key cannot be removed without evicting the dentry, we don't need to keep > retrying to revalidate it. > > Signed-off-by: Gabriel Krisman Bertazi >

Re: [f2fs-dev] fun with d_invalidate() vs. d_splice_alias() was Re: [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, Nov 27, 2023 at 06:38:43AM +, Al Viro wrote: > > FWIW, I suspect that the right answer would be along the lines of > > * if d_splice_alias() does move an exsiting (attached) alias in > > place, it ought to dissolve all mountpoints in subtree being move

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Fri, Nov 24, 2023 at 10:20:39AM -0500, Gabriel Krisman Bertazi wrote: > I'm not sure why it changed. I'm guessing that, since it doesn't make > sense to set fscrypt_d_revalidate for every dentry in the > !case-insensitive case, they just kept the same behavior for > case-insensitive+fscrypt.

Re: [f2fs-dev] fun with d_invalidate() vs. d_splice_alias() was Re: [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, Nov 27, 2023 at 12:19:09PM -0600, Eric W. Biederman wrote: > Either we should decide it is useless and remove it and all of it's > children. > > Or we should decide it was renamed and just handle it that way. How? An extra roundtrip to server trying to do getattr on the fhandle we've

Re: [f2fs-dev] fun with d_invalidate() vs. d_splice_alias() was Re: [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, Nov 27, 2023 at 05:25:44PM +, Al Viro wrote: > On Mon, Nov 27, 2023 at 10:01:34AM -0600, Eric W. Biederman wrote: > > "Eric W. Biederman" writes: > > > > > I am confused what is going on with ext4 and f2fs. I think they > > > are call

Re: [f2fs-dev] fun with d_invalidate() vs. d_splice_alias() was Re: [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, Nov 27, 2023 at 10:01:34AM -0600, Eric W. Biederman wrote: > "Eric W. Biederman" writes: > > > I am confused what is going on with ext4 and f2fs. I think they > > are calling d_invalidate when all they need to call is d_drop. > > ext4 and f2f2 are buggy in how they call d_invalidate,

Re: [f2fs-dev] fun with d_invalidate() vs. d_splice_alias() was Re: [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, Nov 27, 2023 at 04:03:18PM +, Al Viro wrote: > On Mon, Nov 27, 2023 at 09:47:47AM -0600, Eric W. Biederman wrote: > > > There is a lot going on there. I remember one of the relevant > > restrictions was marking dentries dont_mount, and inodes S_DEAD >

Re: [f2fs-dev] fun with d_invalidate() vs. d_splice_alias() was Re: [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, Nov 27, 2023 at 09:47:47AM -0600, Eric W. Biederman wrote: > There is a lot going on there. I remember one of the relevant > restrictions was marking dentries dont_mount, and inodes S_DEAD > in unlink and rmdir. > > But even without out that marking if d_invalidate is called > from

Re: [f2fs-dev] fun with d_invalidate() vs. d_splice_alias() was Re: [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Sun, Nov 26, 2023 at 06:41:41PM +, Al Viro wrote: > d_invalidate() situation is more subtle - we need to sort out its interplay > with d_splice_alias(). > > More concise variant of the scenario in question: > * we have /mnt/foo/bar and a lot of its descendents in d

[f2fs-dev] fun with d_invalidate() vs. d_splice_alias() was Re: [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

[folks involved into d_invalidate()/submount eviction stuff Cc'd] On Sun, Nov 26, 2023 at 04:52:19AM +, Al Viro wrote: > PS: as the matter of fact, it might be a good idea to pass the parent > as explicit argument to ->d_revalidate(), now that we are passing the > name as

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Sat, Nov 25, 2023 at 10:01:36PM +, Al Viro wrote: > On Fri, Nov 24, 2023 at 10:22:49AM -0500, Gabriel Krisman Bertazi wrote: > > > ack. I'll base the other changes we discussed on top of your branch. > > Rebased to v6.7-rc1, fixed up (ceph calls fscrypt_d_revalidate() d

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Fri, Nov 24, 2023 at 10:22:49AM -0500, Gabriel Krisman Bertazi wrote: > ack. I'll base the other changes we discussed on top of your branch. Rebased to v6.7-rc1, fixed up (ceph calls fscrypt_d_revalidate() directly, and D/f/porting entry had been missing), pushed out as

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Thu, Nov 23, 2023 at 02:06:39PM -0500, Gabriel Krisman Bertazi wrote: > > > > 4. d_move() and d_exchange() would ignore the value returned by __d_move(); > > __d_unalias() turn > > __d_move(alias, dentry, false); > > ret = 0; > > into > > ret = __d_move(alias, dentry, Splice);

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Thu, Nov 23, 2023 at 07:53:27PM +, Al Viro wrote: > Huh? If it really depends only upon the superblock, just set it in ->s_d_op > when you set the superblock up. > > Again, whatever setup you do for dentry in ->lookup(), you either > * have a filesystem that ne

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Thu, Nov 23, 2023 at 02:06:39PM -0500, Gabriel Krisman Bertazi wrote: > > A paragraph above you've said that it's not constant over the entire > > filesystem. > > The same ->d_op is used by every dentry in the filesystem if the superblock > has the casefold bit enabled, regardless of whether

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Thu, Nov 23, 2023 at 12:37:43PM -0500, Gabriel Krisman Bertazi wrote: > > That's the problem I'd been talking about - there is a class of situations > > where the work done by ext4_lookup() to set the state of dentry gets > > completely lost. After lookup you do have a dentry in the right

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Thu, Nov 23, 2023 at 10:57:22AM -0500, Gabriel Krisman Bertazi wrote: > Linus Torvalds writes: > > > Side note: Gabriel, as things are now, instead of that > > > > if (!d_is_casefolded_name(dentry)) > > return 0; > > > > in generic_ci_d_revalidate(), I would suggest

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Wed, Nov 22, 2023 at 04:18:56PM -0800, Linus Torvalds wrote: > On Wed, 22 Nov 2023 at 13:19, Al Viro wrote: > > > > The serious gap, AFAICS, is the interplay with open-by-fhandle. > > So I'm obviously not a fan of igncase filesystems, but I don't think > this ser

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Thu, Nov 23, 2023 at 01:12:08AM +, Al Viro wrote: > On Wed, Nov 22, 2023 at 09:19:01PM +0000, Al Viro wrote: > > On Tue, Nov 21, 2023 at 02:27:34AM +, Al Viro wrote: > > > > > I will review that series; my impression from the previous iterations > > >

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Wed, Nov 22, 2023 at 09:19:01PM +, Al Viro wrote: > On Tue, Nov 21, 2023 at 02:27:34AM +0000, Al Viro wrote: > > > I will review that series; my impression from the previous iterations > > had been fairly unpleasant, TBH, but I hadn't rechecked since April > > or

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Tue, Nov 21, 2023 at 02:27:34AM +, Al Viro wrote: > I will review that series; my impression from the previous iterations > had been fairly unpleasant, TBH, but I hadn't rechecked since April > or so. The serious gap, AFAICS, is the interplay with open-by-fhandle. It's not

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Tue, Nov 21, 2023 at 12:12:15AM -0500, Theodore Ts'o wrote: > Yeah, agreed, that would be a nice optimization. However, in the > unfortunate case where (a) it's non-ASCII, and (b) the input string is > non-normalized and/or differs in case, we end up scanning some portion > of the two strings

Re: [f2fs-dev] [PATCH v6 3/9] fs: Expose name under lookup to d_revalidate hooks

On Wed, Aug 16, 2023 at 01:07:57AM -0400, Gabriel Krisman Bertazi wrote: > From: Gabriel Krisman Bertazi > > Negative dentries support on case-insensitive ext4/f2fs will require > access to the name under lookup to ensure it matches the dentry. This > adds the information on d_revalidate and

Re: [f2fs-dev] [PATCH v6 4/9] fs: Add DCACHE_CASEFOLDED_NAME flag

On Wed, Aug 16, 2023 at 01:07:58AM -0400, Gabriel Krisman Bertazi wrote: > From: Gabriel Krisman Bertazi > > This flag marks a negative or positive dentry as being created after a > case-insensitive lookup operation. It is useful to differentiate > dentries this way to detect whether the

Re: [f2fs-dev] [PATCH v6 5/9] libfs: Validate negative dentries in case-insensitive directories

On Wed, Aug 16, 2023 at 01:07:59AM -0400, Gabriel Krisman Bertazi wrote: > +static int generic_ci_d_revalidate(struct dentry *dentry, > +const struct qstr *name, > +unsigned int flags) > +{ > + const struct dentry *parent; > +

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, Nov 20, 2023 at 10:07:51AM -0800, Linus Torvalds wrote: > Well, we all know - very much including Al - that Al isn't always the > most responsive person, and tends to have his own ratholes that he > dives deep into. FWIW, the right now I'm getting out of one of those - rename() deadlocks

[f2fs-dev] [RFC] weirdness in f2fs_rename() with RENAME_WHITEOUT

[f2fs folks Cc'd] There's something very odd in f2fs_rename(); this: f2fs_down_write(_I(old_inode)->i_sem); if (!old_dir_entry || whiteout) file_lost_pino(old_inode); else /* adjust dir's i_pino to pass fsck check */

Re: [f2fs-dev] [PATCH v6 1/7] fs: pass the request_mask to generic_fillattr

On Tue, Aug 29, 2023 at 08:43:31PM -0400, Jeff Layton wrote: > On Wed, 2023-08-30 at 01:02 +0100, Al Viro wrote: > > On Tue, Aug 29, 2023 at 06:58:47PM -0400, Jeff Layton wrote: > > > On Tue, 2023-08-29 at 23:44 +0100, Al Viro wrote: > > > > On Tue, Jul 25, 2023 at

Re: [f2fs-dev] [PATCH v2 08/92] fs: new helper: simple_rename_timestamp

On Wed, Jul 05, 2023 at 02:58:11PM -0400, Jeff Layton wrote: > + * POSIX mandates that the old and new parent directories have their ctime > and > + * mtime updated, and that inodes of @old_dentry and @new_dentry (if any), > have > + * their ctime updated. APPLICATION USAGE Some

Re: [f2fs-dev] [PATCH v6 1/7] fs: pass the request_mask to generic_fillattr

On Tue, Aug 29, 2023 at 06:58:47PM -0400, Jeff Layton wrote: > On Tue, 2023-08-29 at 23:44 +0100, Al Viro wrote: > > On Tue, Jul 25, 2023 at 10:58:14AM -0400, Jeff Layton wrote: > > > generic_fillattr just fills in the entire stat struct indiscriminately > > > today,

Re: [f2fs-dev] [PATCH v6 1/7] fs: pass the request_mask to generic_fillattr

On Tue, Jul 25, 2023 at 10:58:14AM -0400, Jeff Layton wrote: > generic_fillattr just fills in the entire stat struct indiscriminately > today, copying data from the inode. There is at least one attribute > (STATX_CHANGE_COOKIE) that can have side effects when it is reported, > and we're looking at

Re: [f2fs-dev] [PATCH 03/12] filemap: update ki_pos in generic_perform_write

On Mon, Aug 28, 2023 at 02:30:23PM +0200, Christoph Hellwig wrote: > On Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote: > > That part is somewhat fishy - there's a case where you return a positive > > value > > and advance ->ki_pos by more than that amount.

Re: [f2fs-dev] [PATCH 03/12] filemap: update ki_pos in generic_perform_write

On Mon, Aug 28, 2023 at 02:32:59PM +0200, Christoph Hellwig wrote: > On Sun, Aug 27, 2023 at 10:45:18PM +0100, Al Viro wrote: > > IOW, I suspect that the right thing to do would be something along the lines > > of > > The idea looks sensible to me, but

Re: [f2fs-dev] [PATCH 03/12] filemap: update ki_pos in generic_perform_write

On Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote: > That part is somewhat fishy - there's a case where you return a positive value > and advance ->ki_pos by more than that amount. I really wonder if all callers > of ->write_iter() are OK with that. Speaking of which, in c

Re: [f2fs-dev] [PATCH 03/12] filemap: update ki_pos in generic_perform_write

On Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote: > On Thu, Jun 01, 2023 at 04:58:55PM +0200, Christoph Hellwig wrote: > > All callers of generic_perform_write need to updated ki_pos, move it into > > common code. > > > @@ -4034,7 +4037,6 @@ ssize_t __generic_file

Re: [f2fs-dev] [PATCH 03/12] filemap: update ki_pos in generic_perform_write

On Thu, Jun 01, 2023 at 04:58:55PM +0200, Christoph Hellwig wrote: > All callers of generic_perform_write need to updated ki_pos, move it into > common code. > @@ -4034,7 +4037,6 @@ ssize_t __generic_file_write_iter(struct kiocb *iocb, > struct iov_iter *from) > endbyte = pos +

Re: [f2fs-dev] [PATCH v2 0/29] block: Make blkdev_get_by_*() return handle

On Fri, Aug 25, 2023 at 03:47:56PM +0200, Jan Kara wrote: > I can see the appeal of not having to introduce the new bdev_handle type > and just using struct file which unifies in-kernel and userspace block > device opens. But I can see downsides too - the last fput() happening from > task work

Re: [f2fs-dev] [PATCH 01/30] block: also call ->open for incremental partition opens

On Thu, Jun 08, 2023 at 01:02:29PM +0200, Christoph Hellwig wrote: > --- a/block/bdev.c > +++ b/block/bdev.c > @@ -683,9 +683,6 @@ static int blkdev_get_part(struct block_device *part, > fmode_t mode) > struct gendisk *disk = part->bd_disk; > int ret; > > - if

Re: [f2fs-dev] [PATCH v2 0/29] block: Make blkdev_get_by_*() return handle

On Fri, Aug 11, 2023 at 01:04:31PM +0200, Jan Kara wrote: > Hello, > > this is a v2 of the patch series which implements the idea of > blkdev_get_by_*() > calls returning bdev_handle which is then passed to blkdev_put() [1]. This > makes the get and put calls for bdevs more obviously matching

Re: [f2fs-dev] [PATCH 3/7] libfs: Validate negative dentries in case-insensitive directories

On Wed, Jun 22, 2022 at 03:45:59PM -0400, Gabriel Krisman Bertazi wrote: > +static inline int generic_ci_d_revalidate(struct dentry *dentry, > + const struct qstr *name, > + unsigned int flags) > +{ > + int

Re: [f2fs-dev] [PATCH 1/7] fs: Expose name under lookup to d_revalidate hook

On Sat, Mar 25, 2023 at 09:33:10AM -0400, Theodore Ts'o wrote: > On Thu, Mar 23, 2023 at 10:33:20AM -0400, Theodore Ts'o wrote: > > On Wed, Jun 22, 2022 at 03:45:57PM -0400, Gabriel Krisman Bertazi wrote: > > > Negative dentries support on case-insensitive ext4/f2fs will require > > > access to

Re: [f2fs-dev] [PATCH] Documentation: filesystems: correct possessive "its"

On Mon, Aug 29, 2022 at 04:54:29PM -0700, Randy Dunlap wrote: > compress_log_size=%u Support configuring compress cluster size, the size > will > - be 4KB * (1 << %u), 16KB is minimum size, also it's > + be 4KB * (1 << %u), 16KB is minimum size, also

Re: [f2fs-dev] [PATCH 1/3] fs/dcache: Add d_clear_dir_neg_dentries()

On Sun, Mar 28, 2021 at 11:43:54AM -0300, André Almeida wrote: > +/** > + * d_clear_dir_neg_dentries - Remove negative dentries in an inode > + * @dir: Directory to clear negative dentries > + * > + * For directories with negative dentries that are becoming case-insensitive > + * dirs, we need to

Re: [f2fs-dev] [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()

On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote: > static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned > int size) > { > char *vto = kmap_atomic(to); > > memcpy(vto, vfrom, size); > kunmap_atomic(vto); > } > > in linux/highmem.h ? You

Re: [f2fs-dev] [PATCH] ext4: avoid utf8_strncasecmp() with unstable name

On Sat, May 30, 2020 at 10:35:47AM -0700, Eric Biggers wrote: > On Sat, May 30, 2020 at 10:18:14AM -0700, Matthew Wilcox wrote: > > On Fri, May 29, 2020 at 11:02:16PM -0700, Eric Biggers wrote: > > > + if (len <= DNAME_INLINE_LEN - 1) { > > > + unsigned int i; > > > + > > > + for

Re: [f2fs-dev] [RFC PATCH V2 1/9] include/linux/pagemap.h: introduce attach/clear_page_private

On Thu, Apr 30, 2020 at 03:13:38PM -0700, Matthew Wilcox wrote: > > +/** > > + * clear_page_private - clear page's private field and PG_private. > > + * @page: page to be cleared. > > + * > > + * The counterpart function of attach_page_private. > > + * Return: private data of page or NULL if page

Re: [f2fs-dev] [RFC PATCH V2 1/9] include/linux/pagemap.h: introduce attach/clear_page_private

On Fri, May 01, 2020 at 02:42:29AM +0100, Al Viro wrote: > On Thu, Apr 30, 2020 at 03:13:38PM -0700, Matthew Wilcox wrote: > > > > +/** > > > + * clear_page_private - clear page's private field and PG_private. > > > + * @page: page to be cleared. > > &

Re: [f2fs-dev] [PATCH v8 2/8] fs: Add standard casefolding support

On Fri, Mar 06, 2020 at 06:36:05PM -0800, Daniel Rosenberg wrote: > +/** > + * generic_ci_d_hash - generic implementation of d_hash for casefolding > + * @dentry: Entry whose name we are hashing > + * @len: length of str > + * @qstr: name of the dentry, safely paired with len > + * @str: qstr to

Re: [f2fs-dev] [PATCH v7 6/8] f2fs: Handle casefolding with Encryption

On Tue, Feb 11, 2020 at 09:10:13PM -0800, Eric Biggers wrote: > How about: > > int f2fs_ci_compare(const struct inode *parent, const struct qstr *name, > u8 *de_name, size_t de_name_len, bool quick) > { > const struct super_block *sb = parent->i_sb; > const struct

Re: [f2fs-dev] [PATCH v7 2/8] fs: Add standard casefolding support

On Mon, Feb 10, 2020 at 03:11:13PM -0800, Daniel Rosenberg wrote: > On Fri, Feb 7, 2020 at 6:12 PM Al Viro wrote: > > > > On Fri, Feb 07, 2020 at 05:35:46PM -0800, Daniel Rosenberg wrote: > > > > > > Again, is that safe in case when the contents of the string

Re: [f2fs-dev] [PATCH v7 2/8] fs: Add standard casefolding support

On Fri, Feb 07, 2020 at 05:35:46PM -0800, Daniel Rosenberg wrote: > +int generic_ci_d_compare(const struct dentry *dentry, unsigned int len, > + const char *str, const struct qstr *name) > +{ > + const struct dentry *parent = READ_ONCE(dentry->d_parent); > + const

Re: [f2fs-dev] [PATCH v3 5/9] vfs: Fold casefolding into vfs

On Fri, Jan 17, 2020 at 01:42:42PM -0800, Daniel Rosenberg wrote: > Ext4 and F2fs are both using casefolding, and they, along with any other > filesystem that adds the feature, will be using identical dentry_ops. > Additionally, those dentry ops interfere with the dentry_ops required > for fscrypt

Re: [f2fs-dev] [PATCH v5] fs: introduce is_dot_or_dotdot helper for cleanup

On Wed, Dec 11, 2019 at 11:59:40AM +0800, Tiezhu Yang wrote: > static inline bool is_dot_or_dotdot(const unsigned char *name, size_t len) > { > if (len == 1 && name[0] == '.') > return true; > > if (len == 2 && name[0] == '.' && name[1] == '.') >

Re: [f2fs-dev] [PATCH v4] fs: introduce is_dot_or_dotdot helper for cleanup

On Tue, Dec 10, 2019 at 11:19:13AM -0800, Eric Biggers wrote: > > +static inline bool is_dot_or_dotdot(const unsigned char *name, size_t len) > > +{ > > + if (unlikely(name[0] == '.')) { > > + if (len < 2 || (len == 2 && name[1] == '.')) > > + return true; > > + }

Re: [f2fs-dev] [PATCH v3] fs: introduce is_dot_dotdot helper for cleanup

On Sat, Dec 07, 2019 at 07:35:48PM +0800, Tiezhu Yang wrote: > There exists many similar and duplicate codes to check "." and "..", > so introduce is_dot_dotdot helper to make the code more clean. Umm... No objections, in principle, but... you try to say that name (e.g. in a phone conversation)

Re: [f2fs-dev] [PATCH 5/5] vfs: don't allow writes to swap files

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

Re: [f2fs-dev] [PATCH 1/5] vfs: create a generic checking and prep function for FS_IOC_SETFLAGS

On Tue, Jun 25, 2019 at 07:32:10PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong > > Create a generic function to check incoming FS_IOC_SETFLAGS flag values > and later prepare the inode for updates so that we can standardize the > implementations that follow ext4's flag values. Change

Re: [f2fs-dev] [PATCH 2/5] vfs: create a generic checking function for FS_IOC_FSSETXATTR

On Tue, Jun 25, 2019 at 07:32:18PM -0700, Darrick J. Wong wrote: > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -373,10 +373,9 @@ static int check_xflags(unsigned int flags) > static int btrfs_ioctl_fsgetxattr(struct file *file, void __user *arg) > { > struct btrfs_inode *binode =

Re: [f2fs-dev] [PATCH v2 1/2] vfs: use READ_ONCE() to access ->i_link

On Wed, Apr 10, 2019 at 04:15:48PM -0700, Eric Biggers wrote: > On Wed, Apr 10, 2019 at 10:06:57PM +0100, Al Viro wrote: > > On Wed, Apr 10, 2019 at 01:21:14PM -0700, Eric Biggers wrote: > > > From: Eric Biggers > > > > > > Use 'READ_ONCE(inode->i_link)' to

Re: [f2fs-dev] [PATCH v2 1/2] vfs: use READ_ONCE() to access ->i_link

On Wed, Apr 10, 2019 at 01:21:14PM -0700, Eric Biggers wrote: > From: Eric Biggers > > Use 'READ_ONCE(inode->i_link)' to explicitly support filesystems caching > the symlink target in ->i_link later if it was unavailable at iget() > time, or wasn't easily available. I'll be doing this in

Re: [f2fs-dev] [PATCH] fscrypt: cache decrypted symlink target in ->i_link

On Tue, Apr 09, 2019 at 09:04:15PM -0700, Eric Biggers wrote: > > What's to stop you from doing just that right now? You'd need to take > > care with barriers, but you'd need that anyway... As soon as ->i_link is set > > you'll get no more ->get_link() on that sucker, using the cached value > >

Re: [f2fs-dev] [PATCH] fscrypt: cache decrypted symlink target in ->i_link

On Tue, Apr 09, 2019 at 07:58:08PM -0700, Eric Biggers wrote: > It could check a flag IOP_GET_LINK in ->i_opflags instead, so it would be the > same number of checks. See patch below. With that patch ->i_link is completely unused if ->get_link() is non-NULL, so you get a method call on each

Re: [f2fs-dev] [PATCH] fscrypt: cache decrypted symlink target in ->i_link

On Tue, Apr 09, 2019 at 06:22:49PM -0700, Eric Biggers wrote: > > Non-NULL ->get_link() => DCACHE_SYMLINK_TYPE in ->d_flags => > > d_is_symlink() true => step_into() progresses to pick_link(). > > > > IOW, non-NULL ->get_link() is what tells you that we have > > a symlink there. > > I think

Re: [f2fs-dev] [PATCH] fscrypt: cache decrypted symlink target in ->i_link

On Tue, Apr 09, 2019 at 05:45:54PM -0700, Eric Biggers wrote: > On Wed, Apr 10, 2019 at 01:33:46AM +0100, Al Viro wrote: > > On Tue, Apr 09, 2019 at 04:35:44PM -0700, Eric Biggers wrote: > > > From: Eric Biggers > > > > > > Path lookups that traverse encryp

Re: [f2fs-dev] [PATCH] fscrypt: cache decrypted symlink target in ->i_link

On Tue, Apr 09, 2019 at 04:35:44PM -0700, Eric Biggers wrote: > From: Eric Biggers > > Path lookups that traverse encrypted symlink(s) are very slow because > each encrypted symlink needs to be decrypted each time it's followed. > > Make encrypted symlinks faster by caching the decrypted

Re: [f2fs-dev] [PATCH v4 07/17] fs/dcache.c: add shrink_dcache_inode()

On Tue, Apr 02, 2019 at 08:45:50AM -0700, Eric Biggers wrote: > From: Eric Biggers > > When a filesystem encryption key is removed, we need all files which had > been "unlocked" (had ->i_crypt_info set up) with it to appear "locked" > again. This is most easily done by evicting the inodes.

Re: [f2fs-dev] [PATCH 1/5] fscrypt: clean up and improve dentry revalidation

On Mon, Mar 18, 2019 at 01:29:49PM -0700, Eric Biggers wrote: > On Sun, Mar 17, 2019 at 08:38:22PM +0000, Al Viro wrote: > > On Sun, Mar 17, 2019 at 01:04:40PM -0700, Eric Biggers wrote: > > > + /* > > > + * Ciphertext name; valid if the directory

Re: [f2fs-dev] [PATCH 1/5] fscrypt: clean up and improve dentry revalidation

On Sun, Mar 17, 2019 at 01:04:40PM -0700, Eric Biggers wrote: > + /* > + * Ciphertext name; valid if the directory's key is still unavailable. > + * > + * Note: since fscrypt forbids rename() on ciphertext names, it should > + * be safe to access ->d_parent directly here.

Re: [f2fs-dev] [PATCH v2] vfs: don't decrement i_nlink in d_tmpfile

On Fri, Feb 15, 2019 at 02:39:25PM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong > > d_tmpfile was introduced to instantiate an inode in the dentry cache as > a temporary file. This helper decrements the inode's nlink count and > dirties the inode, presumably so that filesystems could

Re: [f2fs-dev] [PATCH v1 0/4] fs: fix race between llseek SEEK_END and write

On Thu, Nov 22, 2018 at 02:40:50PM +0900, Eiichi Tsukata wrote: > 2018年11月21日(水) 13:54 Al Viro : > > > > On Wed, Nov 21, 2018 at 11:43:56AM +0900, Eiichi Tsukata wrote: > > > Some file systems (including ext4, xfs, ramfs ...) have the following > > > problem as I'v

Re: [f2fs-dev] [PATCH v1 0/4] fs: fix race between llseek SEEK_END and write

On Wed, Nov 21, 2018 at 11:43:56AM +0900, Eiichi Tsukata wrote: > Some file systems (including ext4, xfs, ramfs ...) have the following > problem as I've described in the commit message of the 1/4 patch. > > The commit ef3d0fd27e90 ("vfs: do (nearly) lockless generic_file_llseek") > removed

Re: [f2fs-dev] [PATCH v2] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Wed, Sep 20, 2017 at 05:34:09PM -0700, Jaegeuk Kim wrote: > > flush_delayed_fput() > > does nothing, the list is empty > > how about waiting for workqueue completion here? > > > > > If all the __fput()s are not finished, do_umount() will return

Re: [f2fs-dev] [PATCH v2] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Wed, Sep 20, 2017 at 10:38:31AM -0700, Jaegeuk Kim wrote: > This patch introduces UMOUNT_WAIT flag for umount(2) which let user wait for > umount(2) to complete filesystem shutdown. This should fix a kernel panic > triggered when a living filesystem tries to access dead block device after >

Re: [f2fs-dev] [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Fri, Sep 15, 2017 at 04:29:11PM -0700, Jaegeuk Kim wrote: > The mntput() in delayed_fput() is the last function call. So before that > moment, > sys_umount() may see mnt_get_count() as 2, so it avoids EBUSY condition. I'm > not > sure why it check over 2 tho. Because it has just grabbed a

Re: [f2fs-dev] [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Thu, Sep 14, 2017 at 08:45:18PM -0700, Jaegeuk Kim wrote: > > Which filesystem it is? With root I would've expected remount ro done > > by sys_umount(); with anything else... How has it managed to avoid > > -EBUSY? If it was umount -l (IOW, MNT_DETACH), I can see that happening, > > but...

Re: [f2fs-dev] [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Thu, Sep 14, 2017 at 05:19:39PM -0700, Jaegeuk Kim wrote: > Instead, I put more traces in the reboot procedure, and got a clue to suspect > the below flow. > > delayed_fput() init >- umount > - mntput() > - mntput_no_expire()-

Re: [f2fs-dev] [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > Android triggers umount(2) by init process, which is definitely not a kernel > > thread. But, we've seen some kernel panics which say umount(2)

Re: [f2fs-dev] [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > Android triggers umount(2) by init process, which is definitely not a kernel > thread. But, we've seen some kernel panics which say umount(2) was succeeded, > but ext4 triggered a kernel panic due to EIO after then like below. I'm

Re: [f2fs-dev] [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Wed, Sep 13, 2017 at 04:31:16PM -0700, Jaegeuk Kim wrote: > Hi Al, > > On 09/14, Al Viro wrote: > > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > > > + if (!retval && (flags & UMOUNT_WAIT)) { > > > +

Re: [f2fs-dev] [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > + if (!retval && (flags & UMOUNT_WAIT)) { > + if (likely(!(current->flags & PF_KTHREAD))) > + task_work_run(); This is complete crap. The same damn thing will be done by caller of sys_umount()

Re: [f2fs-dev] [RFC PATCH] mm: introduce kv[mz]alloc helpers

On Fri, Dec 09, 2016 at 12:44:17PM +1100, Dave Chinner wrote: > On Thu, Dec 08, 2016 at 11:33:00AM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > Using kmalloc with the vmalloc fallback for larger allocations is a > > common pattern in the kernel code. Yet we do not

Re: [f2fs-dev] [RFC PATCH] mm: introduce kv[mz]alloc helpers

On Fri, Dec 09, 2016 at 07:22:25AM +0100, Michal Hocko wrote: > > Easier to handle those in vmalloc() itself. > > I think there were some attempts in the past but some of the code paths > are burried too deep and adding gfp_mask all the way down there seemed > like a major surgery. No need to

Re: [f2fs-dev] [PATCH 1/3] fscrypto: use dget_parent() in fscrypt_d_revalidate()

On Tue, Apr 12, 2016 at 10:27:20AM -0700, Jaegeuk Kim wrote: > This patch updates fscrypto along with the below ext4 crypto change. > > Fixes: 3d43bcfef5f0 ("ext4 crypto: use dget_parent() in ext4_d_revalidate()") > static int fscrypt_d_revalidate(struct dentry *dentry, unsigned int flags) > {

Re: [f2fs-dev] [GIT PULL] f2fs updates for v4.2

On Thu, Jun 25, 2015 at 05:33:34AM +0100, Al Viro wrote: Said that, f2fs_symlink() looks odd - we create a directory entry *before* doing page_symlink(). And if it (or encryption) fails, I don't see anything that would remove that new directory entry. What are we ending up with in such case

Re: [f2fs-dev] [PATCH 16/18] f2fs crypto: add symlink encryption

On Fri, May 08, 2015 at 09:20:51PM -0700, Jaegeuk Kim wrote: This patch implements encryption support for symlink. The codes refered the ext4 symlink path. ext4 symlink patches are seriously misguided - don't mix encrypted and unencrypted cases in the same inode_operations. NAK.

Re: [f2fs-dev] [RFC PATCH 0/5] Remove rw parameter from direct_IO()

On Mon, Mar 16, 2015 at 04:33:48AM -0700, Omar Sandoval wrote: Hi, Al, here's some cleanup that you mentioned back in December that I got around to (https://lkml.org/lkml/2014/12/15/28). Applied. See #for-next --

Re: [f2fs-dev] [RFC PATCH 1/5] new helper: iov_iter_rw()

On Tue, Mar 17, 2015 at 10:31:51AM +0100, David Sterba wrote: Agreed, but the proposed define is rather cryptic and I was not able to understand the meaning on the first glance. #define iov_iter_rw(i) ((0 ? (struct iov_iter *)0 : (i))-type RW_MASK) This worked for me, does not compile

Re: [f2fs-dev] [RFC PATCH 0/5] Remove rw parameter from direct_IO()

On Mon, Mar 16, 2015 at 04:33:48AM -0700, Omar Sandoval wrote: Hi, Al, here's some cleanup that you mentioned back in December that I got around to (https://lkml.org/lkml/2014/12/15/28). In summary, the rw parameter to a_ops-direct_IO() is redundant with .type in struct iov_iter.

Re: [f2fs-dev] [RFC PATCH 1/5] new helper: iov_iter_rw()

On Mon, Mar 16, 2015 at 04:33:49AM -0700, Omar Sandoval wrote: Get either READ or WRITE out of iter-type. Umm... + * Get one of READ or WRITE out of iter-type without any other flags OR'd in + * with it. + */ +static inline int iov_iter_rw(const struct iov_iter *i) +{ + return

Re: [f2fs-dev] [PATCH] f2fs: update file name in the inode block during f2fs_rename

On Thu, Jul 18, 2013 at 06:11:23PM +0900, Jaegeuk Kim wrote: The error is reproducible by: After this, when we retrieve the inode-i_name of test2 by dump.f2fs, we get test1 instead of test2. This is because f2fs didn't update the file name during the f2fs_rename. Er... Correct me if I'm