All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: "Ernesto A. Fernández" <ernesto.mnd.fernandez@gmail.com>,
	linux-fsdevel@vger.kernel.org,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/2] hfsplus: update timestamps on truncate()
Date: Mon, 15 Oct 2018 14:02:01 -0700	[thread overview]
Message-ID: <1539637321.3133.2.camel@slavad-ubuntu-14.04> (raw)
In-Reply-To: <20181013024256.GI32577@ZenIV.linux.org.uk>

On Sat, 2018-10-13 at 03:42 +0100, Al Viro wrote:
> On Fri, Oct 12, 2018 at 02:57:21PM -0700, Viacheslav Dubeyko wrote:
> 
> > Looks good.
> > 
> > Reviewed-by: Vyacheslav Dubeyko <slava@dubeyko.com>
> 
> Looking at the vicinity of that code has brought something that looks
> fishy: suppose we have the file opened and close() races with unlink()
> and open()
> 
> 1) unlink() finds the victim and locks it
> 
> 2) in hfsplus_file_release():
>         if (atomic_dec_and_test(&HFSPLUS_I(inode)->opencnt)) {
> got to 0
>                 inode_lock(inode);
> block waiting for unlink
> 
> 3) open() finds the sucker in dcache and hits hfsplus_file_open(), where
> we do
>         atomic_inc(&HFSPLUS_I(inode)->opencnt);
> and now opencnt is 1.
> 
> 4) on the unlink side:
>         if (inode->i_ino == cnid &&
>             atomic_read(&HFSPLUS_I(inode)->opencnt)) {
>                 str.name = name;
>                 str.len = sprintf(name, "temp%lu", inode->i_ino);
>                 res = hfsplus_rename_cat(inode->i_ino,
>                                          dir, &dentry->d_name,
>                                          sbi->hidden_dir, &str);
>                 if (!res) {
>                         inode->i_flags |= S_DEAD;
>                         drop_nlink(inode);
>                 }
>                 goto out;
>         }
> nlink is zero now, the sucker got renamed and marked S_DEAD
> 
> 5) ->release() finally got through inode_lock() and
>                 hfsplus_file_truncate(inode);
>                 if (inode->i_flags & S_DEAD) {
>                         hfsplus_delete_cat(inode->i_ino,
>                                            HFSPLUS_SB(sb)->hidden_dir, NULL);
>                         hfsplus_delete_inode(inode);
>                 }
>                 inode_unlock(inode);
> ... and now we have killed everything we used to have associated with that
> inode on disk.  While it's still open.  What's to stop CNID to be reused,
> etc. and what's to preserve sanity in that situation?
> 
> What am I missing there?

OK. If you believe that the patch is in the bad shape then what's your
suggestion for improving the patch?

Thanks,
Vyacheslav Dubeyko.

  reply	other threads:[~2018-10-16  4:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-12  4:22 [PATCH 1/2] hfsplus: update timestamps on truncate() Ernesto A. Fernández
2018-10-12  4:23 ` [PATCH 2/2] hfs: update timestamp " Ernesto A. Fernández
2018-10-12 21:57   ` Viacheslav Dubeyko
2018-10-12 21:57 ` [PATCH 1/2] hfsplus: update timestamps " Viacheslav Dubeyko
2018-10-13  2:42   ` Al Viro
2018-10-15 21:02     ` Viacheslav Dubeyko [this message]
2018-10-15 21:24       ` Al Viro
2018-10-17  2:01         ` Viacheslav Dubeyko
2018-10-18  2:09         ` Viacheslav Dubeyko
2018-10-16 23:15     ` Ernesto A. Fernández

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1539637321.3133.2.camel@slavad-ubuntu-14.04 \
    --to=slava@dubeyko.com \
    --cc=akpm@linux-foundation.org \
    --cc=ernesto.mnd.fernandez@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.