Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 20 Jan 2020 10:03:27 -0500 (EST)
From:   Byron Stanoszek <gandalf@winds.org>
To:     jeffm@suse.com
cc:     linux-kernel@vger.kernel.org
Subject: Re: reiserfs broke between 4.9.205 and 4.9.208
Message-ID: <alpine.LNX.2.21.1.2001200956220.14639@winds.org>
User-Agent: Alpine 2.21.1 (LNX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 15 Jan 2020, Jeff Mahoney wrote:
>On 1/9/20 7:12 AM, Jan Kara wrote:
>>
>> Hello,
>>
>> On Wed 08-01-20 15:42:58, Randy Dunlap wrote:
>>> On 1/8/20 11:36 AM, Michael Brunnbauer wrote:
>>>> after upgrading from 4.9.205 to 4.9.208, I get errors on two different
>>>> reiserfs filesystems when doing cp -a (the chown part seems to fail) and
>>>> on other occasions:
>>>>
>>>>  kernel: REISERFS warning (device sda1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
>>>>
>>>>  kernel: REISERFS warning (device sdc1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
>>>>
>>>> This behaviour disappeared after a downgrade to 4.9.205.
>>>>
>>>> I understand there have been changes to the file system code but I'm not
>>>> sure they affect reiserfs, e.g.
>>>>
>>>>  https://bugzilla.kernel.org/show_bug.cgi?id=205433
>>>>
>>>> Any Idea?
>>>>
>>>> Regards,
>>>>
>>>> Michael Brunnbauer
>>>>
>>>
>>> Looks to me like 4.9.207 contains reiserfs changes.
>>>
>>> Adding CC's.
>>
>> Looks like a regression from commit 60e4cf67a582 "reiserfs: fix extended
>> attributes on the root directory". We are getting -EOPNOTSUPP from
>> reiserfs_for_each_xattr() likely originally from open_xa_root(). Previously
>> we were returning -ENODATA from there which error reiserfs_for_each_xattr()
>> converted to 0. I don't understand reiserfs xattrs enough to quickly tell
>> what should actually be happening after the Jeff's change - naively I'd
>> think we should just silence the bogus warning in case of EOPNOTSUPP. Jeff,
>> can you have a look?
>>
>> Also Michael, I'd like to clarify: Does 'cp -a' return any error or is it
>> just that the kernel is spewing these annoying warnings?  Because from the
>> code reading I'd think that it is only the kernel spewing errors but
>> userspace should be fine...
>
>This error occurs when extended attributes are not enabled on the file
>system *and* the module is not built with extended attributes enabled.
>I've sent out the fix for it just now.
>
>-Jeff

Hi Jeff,

Can you share the patch with us for testing? I haven't seen this hit mainline
yet.

Thanks,
  -Byron