Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <29fcea18-d720-d5df-0e00-eb448e6bbfcf@suse.com>
Date:   Thu, 1 Jun 2023 17:22:54 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Content-Language: en-US
To:     Roberto Sassu <roberto.sassu@huaweicloud.com>,
        Paul Moore <paul@paul-moore.com>,
        syzbot <syzbot+8fb64a61fdd96b50f3b8@syzkaller.appspotmail.com>
Cc:     hdanton@sina.com, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, reiserfs-devel@vger.kernel.org,
        roberto.sassu@huawei.com, syzkaller-bugs@googlegroups.com,
        peterz@infradead.org, mingo@redhat.com, will@kernel.org
References: <0000000000007bedb605f119ed9f@google.com>
 <00000000000000964605faf87416@google.com>
 <CAHC9VhTZ=Esk+JxgAjch2J44WuLixe-SZMXW2iGHpLdrdMKQ=g@mail.gmail.com>
 <1020d006-c698-aacc-bcc3-92e5b237ef91@huaweicloud.com>
From:   Jeff Mahoney <jeffm@suse.com>
Subject: Re: [syzbot] [reiserfs?] possible deadlock in open_xa_dir
In-Reply-To: <1020d006-c698-aacc-bcc3-92e5b237ef91@huaweicloud.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eTdnZkVIaWdWNHdEOFJBT25QbkFGZjJDOEMrMzdOaUpIaVFSRUtHWk93RUtn?=
 =?utf-8?B?UlJXNFJ1aFdOUTFaeVl0MlAvd01BQUlQMGNxaDhwSkVOSndaMDZwVWg3NUdh?=
 =?utf-8?B?T0R1R3Y5bkc5cEl3akNNcUFPME1WQVM2QjhyWGNUdWZaWk84aUNFMzRkaGdv?=
 =?utf-8?B?UWl5ekxxSEpGdGpPeU5xcFgvbU5GYWQvQkVIMHlMWU91RXJ0VlFudHlaczdo?=
 =?utf-8?B?Vkp4a1Y3aHA1WkdjQkFWVy9NamhkZVZvNWdncWszV2xSZmxRQXBCT3UvQ3F3?=
 =?utf-8?B?bTA5VjRtZlF0QXNCRXQxTEpoVHA0SDRlOUpsclNtbUlnMElaMGduY1Z6VG1w?=
 =?utf-8?B?SHp1L3Q4RFNpUUNUQzgvZlJLU2RJLzVDdFpIMG1NUDNKT3h5ejdPTlJWQm5D?=
 =?utf-8?B?Y1BWNUFWUHdoN0lNVUJyUHVORUhHTmVUaWF4cEl1ODRhWDZlQ0RkNmxUYmpY?=
 =?utf-8?B?VmJ3dHNDUk1kclpMaDdQTXp3Wm1WOVdSQmxqTzJsV3h4UjhhY2lVUDRTUEtt?=
 =?utf-8?B?RTVpN1hQSmpsMUc3SS9TUVhJVVlnSkl5d3drM1M4dzdZei95VyswdytGbnE5?=
 =?utf-8?B?WllaU1VQeDBEMUxNN2pXWTBlb2tNQVgwNDZ1ajJXTDFxMm9RdEIwVWJXK1Er?=
 =?utf-8?B?RGNyL3NYa2VHUE5ndzBHNVR2MksvT3NPUnFIS3NMc2ZBVyt4MGlMcGF6bXdz?=
 =?utf-8?B?ZTc4TGYzblVJV2xnV1YxQTJLZXJNcUxUZUpvZlBNZGlCV2lVQWw0alZPNllT?=
 =?utf-8?B?cFI4ak9OMUVtNlJMSFIyTDNNRWhzZXRDcUFTY3BERjhUQnY2WFNpcUZZY3RB?=
 =?utf-8?B?cTBUeVZueDQ4cjMyZzl0RUtZb1hYUkxhdXoxUnU1L09yYVZ6QVJHeFNKZ1o0?=
 =?utf-8?B?d2IrZjBKNHB1QUVrWXJuUngybllCMUVxVGlPVUtNbDJ5MzFGVW1RVjdhSkVJ?=
 =?utf-8?B?ZS9JcC9UQmpUT0RobkJ1WE00K21TUDl0Z00xUGFHVHlKT0RPRDhsZEptQi9D?=
 =?utf-8?B?Y1BVSXdSL08vM3R4M0FKRllhSzk3U21scTYydWpURlNOSXR4dlRobDc1SmpS?=
 =?utf-8?B?bnVvNlkxL1Vja1NqK3VaamZXMW80OGkrTFhJNDRUU0dETE1mbmtwL2ZvS1l2?=
 =?utf-8?B?L1NlNW9wclJ2V3oycUUwRVp1L3k1SEo4RmZTTllxcGRHd1FvV2NGNThyQjFV?=
 =?utf-8?B?RDVFY2JXRnZjL09hT3dOVVZQMjQxeTk0NzRZUGlQTWpQZDJDZlkxdzVDN3hG?=
 =?utf-8?B?OTg4RlhjQ0dGemErMllzNXhlclgybThibnprb0ZlSHhTcmdaSkJPZ242N2ln?=
 =?utf-8?B?bC9VdE5GRnJtN2RKeHdmRWZIc3dGWW5JazRGUnQ3bnRxQ2NFVkNDUHFvaGh3?=
 =?utf-8?B?b3ROOFFGcW9uVWw4ZnVZMjNrdnZLVE9jaEJyUVgraHVscGlkT2VEekE2cVVa?=
 =?utf-8?B?bHJSczZsNGRhOU1GYkRTNEp4bGFIOTkvUTIxWm1GYm42Uk43U21hL3l4NCtj?=
 =?utf-8?B?c3krK3AvbkVKVGhuZEhEU0J5TW9kY3FzWTZDVXFiY3B4MGU4RU1BTkp0VS9X?=
 =?utf-8?B?QUdXZ0FZQWxkQnJ6SFlTaHFCWUwvdjhZd29ZVzN2L0tlWThjSG1yNUFUVE9n?=
 =?utf-8?B?ak9ieHVtQ0FmbWltQlN5QWhkU0FwRVUzRDNPYmlsYWFBZllFYzVFU2FUV25N?=
 =?utf-8?B?WDJuU0Y2Y3BoV2p3VDhGY1Fka2hpa3AyYUZFdUczMkQ1YXd0bno1WHhnWHVS?=
 =?utf-8?B?T0V1OTlLQ1VsN0s2WHcyeTlML1VXc25tUC81NFVhWSs4WllycWp5czNSTkUr?=
 =?utf-8?B?NVBLa2J4dTNxZEprTnBzNkZEQW9Kc2NwdHVzOTR5VkYwd3hCcyttVDk3V2hO?=
 =?utf-8?B?U1dCRmJMdm5RWVJ6YktZdnBSY3ZZT1dkckFzaXQ4S1dHSXhoOHNKUnBMYWk5?=
 =?utf-8?B?azRUQ0Z0VjNMaTdFdlh3UFNKM3RYUmxLdU1oZmZBZWhGdFRXYXorVjlVam1Q?=
 =?utf-8?B?dnFQR1JUY2tNSU1mZEJtcCtuK0g5ZnV3WUpBejNqYjB1TVZXbTJ4MDRzZzUw?=
 =?utf-8?B?STh3U3RGN3MxK2ZmVitUekpzYWlhZ1N1K1RtZkxETGE1U0pEcjBVWmZ3WlVN?=
 =?utf-8?B?N20vQXZRbzBVSC9oc0daT3V1TzEyUktrRmNUV0dPUVYyeWtYcnpKb01Jbk93?=
 =?utf-8?B?QkE9PQ==?=
X-OriginatorOrg: suse.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e9d1e18-dd12-435a-39b0-08db62e660d4
X-MS-Exchange-CrossTenant-AuthSource: PAXPR04MB9155.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2023 21:23:01.2483
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: lnXNwl4w9GJeIifbVOBoRPp9Yqigs3uUx6v0xXaBBHC7leYzcDZM39oY1a3T9Ek5
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB7104
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 5/31/23 05:49, Roberto Sassu wrote:
> On 5/5/2023 11:36 PM, Paul Moore wrote:
>> On Fri, May 5, 2023 at 4:51 PM syzbot
>> <syzbot+8fb64a61fdd96b50f3b8@syzkaller.appspotmail.com> wrote:
>>>
>>> syzbot has bisected this issue to:
>>>
>>> commit d82dcd9e21b77d338dc4875f3d4111f0db314a7c
>>> Author: Roberto Sassu <roberto.sassu@huawei.com>
>>> Date:   Fri Mar 31 12:32:18 2023 +0000
>>>
>>>      reiserfs: Add security prefix to xattr name in 
>>> reiserfs_security_write()
>>>
>>> bisection log:  
>>> https://syzkaller.appspot.com/x/bisect.txt?x=14403182280000
>>> start commit:   3c4aa4434377 Merge tag 'ceph-for-6.4-rc1' of 
>>> https://githu..
>>> git tree:       upstream
>>> final oops:     
>>> https://syzkaller.appspot.com/x/report.txt?x=16403182280000
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=12403182280000
>>> kernel config:  
>>> https://syzkaller.appspot.com/x/.config?x=73a06f6ef2d5b492
>>> dashboard link: 
>>> https://syzkaller.appspot.com/bug?extid=8fb64a61fdd96b50f3b8
>>> syz repro:      
>>> https://syzkaller.appspot.com/x/repro.syz?x=12442414280000
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=176a7318280000
>>>
>>> Reported-by: syzbot+8fb64a61fdd96b50f3b8@syzkaller.appspotmail.com
>>> Fixes: d82dcd9e21b7 ("reiserfs: Add security prefix to xattr name in 
>>> reiserfs_security_write()")
>>>
>>> For information about bisection process see: 
>>> https://goo.gl/tpsmEJ#bisection
>>
>> I don't think Roberto's patch identified above is the actual root
>> cause of this problem as reiserfs_xattr_set_handle() is called in
>> reiserfs_security_write() both before and after the patch.  However,
>> due to some bad logic in reiserfs_security_write() which Roberto
>> corrected, I'm thinking that it is possible this code is being
>> exercised for the first time and syzbot is starting to trigger a
>> locking issue in the reiserfs code ... ?
> 
> + Jan, Jeff (which basically restructured the lock)
> 
> + Petr, Ingo, Will
> 
> I involve the lockdep experts, to get a bit of help on this.

Yep, looks like that's been broken since it was added in 2009.  Since 
there can't be any users of it, it'd make sense to drop the security 
xattr support from reiserfs entirely.

> First of all, the lockdep warning is trivial to reproduce:
> 
> # dd if=/dev/zero of=reiserfs.img bs=1M count=100
> # losetup -f --show reiserfs.img
> /dev/loop0
> # mkfs.reiserfs /dev/loop0
> # mount /dev/loop0 /mnt/
> # touch file0
> 
> In the testing system, Smack is the major LSM.
> 
> Ok, so the warning here is clear:
> 
> https://syzkaller.appspot.com/x/log.txt?x=12403182280000
> 
> However, I was looking if that can really happen. From this:
> 
> [   77.746561][ T5418] -> #1 (&sbi->lock){+.+.}-{3:3}:
> [   77.753772][ T5418]        lock_acquire+0x23e/0x630
> [   77.758792][ T5418]        __mutex_lock_common+0x1d8/0x2530
> [   77.764504][ T5418]        mutex_lock_nested+0x1b/0x20
> [   77.769868][ T5418]        reiserfs_write_lock+0x70/0xc0
> [   77.775321][ T5418]        reiserfs_mkdir+0x321/0x870
> 
> I see that the lock is taken in reiserfs_write_lock(), while lockdep says:
> 
> [   77.710227][ T5418] but task is already holding lock:
> [   77.717587][ T5418] ffff88807568d090 (&sbi->lock){+.+.}-{3:3}, at: 
> reiserfs_write_lock_nested+0x4a/0xb0
> 
> which is in a different place, I believe here:
> 
> int reiserfs_paste_into_item(struct reiserfs_transaction_handle *th,
>                               /* Path to the pasted item. */
> [...]
> 
>          depth = reiserfs_write_unlock_nested(sb);
>          dquot_free_space_nodirty(inode, pasted_size);
>          reiserfs_write_lock_nested(sb, depth);
>          return retval;
> }
> 
> This is called by reiserfs_add_entry(), which is called by 
> reiserfs_create() (it is in the lockdep trace). After returning to 
> reiserfs_create(), d_instantiate_new() is called.
> 
> I don't know exactly, I take the part that the lock is held. But if it 
> is held, how d_instantiate_new() can be executed in another task?
> 
> static int reiserfs_create(struct mnt_idmap *idmap, struct inode *dir,
>                          struct dentry *dentry, umode_t mode, bool excl)
> {
> 
> [...]
> 
>          reiserfs_write_lock(dir->i_sb);
> 
>          retval = journal_begin(&th, dir->i_sb, jbegin_count);
> 
> [...]
> 
>          d_instantiate_new(dentry, inode);
>          retval = journal_end(&th);
> 
> out_failed:
>          reiserfs_write_unlock(dir->i_sb);
> 
> If the lock is held, the scenario lockdep describes cannot happen. Any 
> thoughts?

It's important to understand that the reiserfs write lock was added as a 
subsystem-specific replacement for the BKL.  Given that reiserfs was 
dying already back then, it made more sense from a time management 
perspective to emulate that behavior internally rather than use new 
locking when practically nobody cared anymore.

See reiserfs_write_unlock_nested and reiserfs_write_lock_nested paired 
throughout the code.  It drops the lock when it passes a point where 
it's likely to schedule, just like the BKL would have.

Yes, it's a mess.  Just let it die quietly.

-Jeff

-- 
Jeff Mahoney
VP Engineering, Linux Systems