All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Vandeputte <koen.vandeputte@ncentric.com>
To: Richard Weinberger <richard@nod.at>
Cc: OpenWrt Development List <openwrt-devel@lists.openwrt.org>,
	linux-mtd@lists.infradead.org
Subject: Re: UBIFS issues within kernel 4.14.69?
Date: Sun, 16 Sep 2018 22:11:07 +0200	[thread overview]
Message-ID: <14d0c8dc-111d-57e1-e86b-ca28544933b3@ncentric.com> (raw)
In-Reply-To: <1680286.R2LEE90rvs@blindfold>


On 16-09-18 21:39, Richard Weinberger wrote:
> Koen,
>
> Am Samstag, 15. September 2018, 09:13:09 CEST schrieb Richard Weinberger:
>> Koen,
>>
>> Am Dienstag, 11. September 2018, 16:26:34 CEST schrieb Koen Vandeputte:
>>> On 2018-09-11 15:46, Koen Vandeputte wrote:
>>>> Hi Richard,
>>> ...
>>>
>>>> I'm only seeing these issues on UBIFS enabled volumes.
>>>>
>>>> It seems it's related to one of your 5 commits, but I'm still in the
>>>> process of bisecting to find the actual culprit.
>>>> As soon as I've found it, I'll let you know, but maybe you already
>>>> have an idea here?
>>>>
>>> Reverting ("ubifs: xattr: Don't operate on deleted inodes") fixes the
>>> weird issues.
>> Thanks for finding that bad commit!
>> I fear by fixing one bug I've uncovered another one.
>>
>> So, I guess you are using overlayfs?
>> Which overlayfs features are you using?
> I guess I've figured myself.
> overlayfs is using temp files (O_TMPFILE), and a recent overlayfs
> feature uses xattrs to indicate directory redirects.
> So it can happen that a temp file, which has link count 0, gains
> xattrs.
>
> UBIFS models xattrs like regular files in directories. Since you cannot
> add new files to a unlinked directory, UBIFS kind of enforced that for
> xattrs too.
> I say "kind of" because technically it works but can trigger an assertion
> in UBIFS's journal code.
> Recently I saw this assertion but failed to conclude that xattr operations on
> unlinked files are perfectly fine and "fixed" the assert.
>
> The right solution is reverting "ubifs: xattr: Don't operate on deleted inodes"
> and removing the false positive asserts from UBIFS' journal code.
>
> Sadly xfstests does not test for that, I'll prepare a new test case.
> Maybe other file systems got this wrong too.
>
> Thanks,
> //richard
>
Hi Richard,

Apologies for the late reply.
It was a busy weekend with the kids ..

I'm very pleased to read you already have a good idea of what is going 
on here.

Can I conclude you will provide a patch upstream to revert this specific 
commit?
Please keep me in CC in case you do, so I can backport it properly into 
OpenWrt on the next kernel bump. (until it is present in a future stable)

Once again, I highly appreciate you fast response in trying to get this 
fixed.

Thank you Richard,

Koen



Reported-by: Koen Vandeputte <koen.vandeputte@ncentric.com>

  reply	other threads:[~2018-09-16 20:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d3f55a2a-dd98-1bc6-272a-9a7b9a318b76@ncentric.com>
     [not found] ` <daa753bf-8572-f2d4-847a-e7a87e49333d@ncentric.com>
2018-09-15  7:13   ` UBIFS issues within kernel 4.14.69? Richard Weinberger
2018-09-16 19:39     ` Richard Weinberger
2018-09-16 20:11       ` Koen Vandeputte [this message]
2018-09-16 21:58         ` Richard Weinberger

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=14d0c8dc-111d-57e1-e86b-ca28544933b3@ncentric.com \
    --to=koen.vandeputte@ncentric.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=openwrt-devel@lists.openwrt.org \
    --cc=richard@nod.at \
    /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.