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 and
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 (atomic_read(&part
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 mak
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 + stat
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
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,
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 we'll
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 am
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
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,
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 implementations
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
[f2fs folks Cc'd]
There's something very odd in f2fs_rename();
this:
f2fs_down_write(&F2FS_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 */
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
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;
> +
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 negativ
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 upd
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 t
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
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
> >
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
> > >
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
> t
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 tha
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 place
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 a
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
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);
>
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 #no-rebase-d_revalidate
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_revalidat
[folks involved into d_invalidate()/submount eviction stuff Cc'd]
On Sun, Nov 26, 2023 at 04:52:19AM +0000, 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 w
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
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 d_rev
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
>
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, if
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 calling
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 go
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.
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 moved.
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
> -
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
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,
>st
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,
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 its
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 the
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 is_creation
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
On Fri, Jul 19, 2013 at 12:40:47PM +0900, Kim Jaegeuk wrote:
> Hi,
>
> 2013. 7. 18. 6:22?? "Al Viro" :
> >
> > On Thu, Jul 18, 2013 at 06:11:23PM +0900, Jaegeuk Kim wrote:
> > > The error is reproducible by:
> > >
> > >
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 = B
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 i
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(
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) w
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;
> > + }
>
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
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
On Fri, Jan 24, 2020 at 10:12:54AM -0800, Eric Biggers wrote:
> > Thanks for your web reference, I will look into it. I think there
> > is no worry about dentry->d_parent here because of this only one
> > dereference on dentry->d_parent.
> >
> > You could ignore my words anyway, just my little th
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 str
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
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 un
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 s
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.
> >
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
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 (i
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 mea
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
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 c
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. A
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)
> +{
> + retu
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
-
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.
-
On Wed, Jun 24, 2015 at 08:42:02PM -0700, Linus Torvalds wrote:
> On Wed, Jun 24, 2015 at 1:25 PM, Jaegeuk Kim wrote:
> >
> > New features are:
> > o per-file encryption (e.g., ext4)
>
> The new encrypted symlinks needed fixups for the changes that happened
> meanwhile to the symlink handling. I
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
On Wed, Jun 24, 2015 at 10:50:10PM -0700, Jaegeuk Kim wrote:
> Right, I missed merging the fix-up patch in linux-next into my pull-request.
> At a glance, I think there is no problem; except 80 column width, though.
>
> Also, agreed that I need to take a look at deleting the dentry to deal with
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)
> {
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 al
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&#
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 ca
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.
N
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
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. This
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 symlink
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
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 that
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 trav
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
> > f
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 fscrypt
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
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 pr
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 have any common hel
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() prett
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)) {
> > > +
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 also
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) was
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()- mntput
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...
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
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
> devi
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 -EB
On Mon, Jun 16, 2025 at 08:33:19PM +0100, Lorenzo Stoakes wrote:
> REVIEWER'S NOTES
>
>
> I am basing this on the mm-new branch in Andrew's tree, so let me know if I
> should rebase anything here. Given the mm bits touched I did think perhaps
> we should take it through the mm tre
98 matches
Mail list logo
