From: Adrian Hunter <adrian.hunter@intel.com>
To: Richard Weinberger <richard@nod.at>, linux-mtd@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, dedekind1@gmail.com,
stable@vger.kernel.org,
Ralph Sennhauser <ralph.sennhauser@gmail.com>,
Amir Goldstein <amir73il@gmail.com>
Subject: Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link()
Date: Thu, 30 Mar 2017 14:57:40 +0300 [thread overview]
Message-ID: <646ae733-5037-3072-7151-b055a8fa1521@intel.com> (raw)
In-Reply-To: <4c7a176b-6132-7936-a04f-d4def5e56320@nod.at>
On 30/03/17 13:23, Richard Weinberger wrote:
> Am 30.03.2017 um 11:49 schrieb Richard Weinberger:
>> Am 30.03.2017 um 11:32 schrieb Adrian Hunter:
>>>> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
>>>> index 0858213a4e63..0139155045fe 100644
>>>> --- a/fs/ubifs/dir.c
>>>> +++ b/fs/ubifs/dir.c
>>>> @@ -748,6 +748,11 @@ static int ubifs_link(struct dentry *old_dentry, struct inode *dir,
>>>> goto out_fname;
>>>>
>>>> lock_2_inodes(dir, inode);
>>>> +
>>>> + /* Handle O_TMPFILE corner case, it is allowed to link a O_TMPFILE. */
>>>> + if (inode->i_nlink == 0)
>>>> + ubifs_delete_orphan(c, inode->i_ino);
>>>
>>> Isn't there also a deletion inode in the journal? If the recovery sees that
>>> won't it delete the file data?
>>
>> Yes, but ubifs_link() adds a new journal entry which revives the inode.
>> This should cancel out the deletion, right?
>> You know the UBIFS journal better than I do. :-)
>
> Reading deeper into the proved that I was wrong.
> AFAIKT UBIFS' journal has currently no way to revive a deleted inode.
> So, we have to think about a new solution.
Deleting the orphan looks right. Just need to understand whether the
recovery would do the right thing - actually it looks like O_TMPFILE might
be OK and in other case we might be failing to remove nodes with sequence
numbers greater than the deletion inode.
next prev parent reply other threads:[~2017-03-30 12:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 8:56 Richard Weinberger
2017-03-30 8:59 ` Amir Goldstein
2017-03-30 9:03 ` Richard Weinberger
2017-03-30 9:07 ` Amir Goldstein
2017-03-30 9:09 ` Richard Weinberger
2017-03-30 9:10 ` Ralph Sennhauser
2017-03-30 9:32 ` Adrian Hunter
2017-03-30 9:49 ` Richard Weinberger
2017-03-30 10:23 ` Richard Weinberger
2017-03-30 10:35 ` Amir Goldstein
2017-03-30 10:51 ` Richard Weinberger
2017-03-30 11:57 ` Adrian Hunter [this message]
2017-03-30 12:27 ` Richard Weinberger
2017-04-06 12:06 ` Amir Goldstein
2017-04-06 12:09 ` Richard Weinberger
2017-04-06 12:26 ` Richard Weinberger
2017-04-11 10:20 ` Amir Goldstein
2017-04-11 10:50 ` Richard Weinberger
2017-04-11 15:04 ` Amir Goldstein
2017-04-17 15:27 ` Ralph Sennhauser
2017-04-17 15:54 ` Richard Weinberger
2017-03-30 10:34 ` Hyunchul Lee
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=646ae733-5037-3072-7151-b055a8fa1521@intel.com \
--to=adrian.hunter@intel.com \
--cc=amir73il@gmail.com \
--cc=dedekind1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=ralph.sennhauser@gmail.com \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®