public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Koen Vandeputte <koen.vandeputte@ncentric.com>
To: Richard Weinberger <richard.weinberger@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>
Cc: "linux-mtd @ lists . infradead . org"
	<linux-mtd@lists.infradead.org>, stable <stable@vger.kernel.org>
Subject: Re: ubifs: regression since "ubifs: xattr: Don't operate on deleted inodes"
Date: Sun, 16 Sep 2018 21:52:48 +0200	[thread overview]
Message-ID: <957f48b5-cc45-ce9b-0a48-cab8534ad570@ncentric.com> (raw)
In-Reply-To: <CAFLxGvyz6oPbeS4KmG-O6vs26P4kB8rMwbukRVgbN-PKvcgcTA@mail.gmail.com>



On 15-09-18 09:15, Richard Weinberger wrote:
> Koen,
>
> On Thu, Sep 13, 2018 at 12:09 PM gregkh@linuxfoundation.org
> <gregkh@linuxfoundation.org> wrote:
>> adding stable@ for stable kernel issues...
>>
>> On Thu, Sep 13, 2018 at 09:58:35AM +0200, Koen Vandeputte wrote:
>>> Hi all,
>>>
>>> I'm currently in the process of updating the kernel version within OpenWrt.
>>> (4.14.68 to 4.14.69)
>>>
>>> Testing shows some issues on devices using specifically UBIFS.
>>> Altering a perfect valid writable file shows weird errors:
>>>
>>>
>>> [ Node 2 | node-2 ] ls -l /root/custom/scripts/banner.sh
>>> -rwxr-xr-x    1 root     root           283 Sep 11 09:52
>>> /root/custom/scripts/banner.sh
>>>
>>> [ Node 2 | node-2 ] cat /root/custom/scripts/banner.sh
>>> #!/bin/sh
>>>
>>> if [ ! -f /root/.banner_ok ]
>>> then
>>>      RELEASE=$(cat /root/build_date)
>>>      VERSION=$(cat /root/version)
>>>
>>>      echo "Generating banner: $VERSION $RELEASE"
>>>      sed s/VERSION/$VERSION/g /root/custom/banner > /etc/banner
>>>      sed -i s/RELEASE/$RELEASE/g /etc/banner
>>>
>>>      touch /root/.banner_ok
>>> fi
>>>
>>> [ Node 2 | node-2 ] echo "test" > /root/custom/scripts/banner.sh
>>> -ash: can't create /root/custom/scripts/banner.sh: nonexistent directory
>>>
>>>
>>>
>>> I'm also noticing other apps fail because /etc doesn't exists yet after
>>> UBIFS boot loading.
>>> these 2 issues were not seen on 4.14.68.
>>>
>>> The bootlog doesn't show any error:
>>> https://pastebin.com/raw/dJx47uBp
>>>
>>>
>>> I'm only seeing these issues on UBIFS enabled volumes.
>>> Reverting ("ubifs: xattr: Don't operate on deleted inodes") fixes these
>>> weird issues.
> Please see my answer to the other thread.
> Always keep the patch author on CC and don't start multiple threads for the
> same issue on two mailing lists.
> Yes, I didn't answer for three days, I had no internet connection...
>
Richard,

I indeed posted here too as we passed the 3 days marker, and I noticed 
4.14.70 RC2 got staged.
Also, a lot of developers tend to ignore questions unless the initial 
question got posted to the official mailinglist.

Let's continue on the OpenWrt list as you propose, were the initial 
question was raised.

Apologies for the (double) noise.


Thank you,

Koen

  reply	other threads:[~2018-09-16 19:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-13  7:58 ubifs: regression since "ubifs: xattr: Don't operate on deleted inodes" Koen Vandeputte
2018-09-13  9:46 ` gregkh
2018-09-15  7:15   ` Richard Weinberger
2018-09-16 19:52     ` Koen Vandeputte [this message]
2018-09-17  9:38       ` Greg KH
2018-09-17  9:41         ` 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=957f48b5-cc45-ce9b-0a48-cab8534ad570@ncentric.com \
    --to=koen.vandeputte@ncentric.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.weinberger@gmail.com \
    --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