From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF79323E358 for ; Wed, 27 May 2026 01:20:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779844817; cv=none; b=JbBHwirfMDQWERWt45TMVSYt56qK19WsZ9o37JjCmdZO5y3DjpvnPNBJkH9+9MjU061DhaKEErka33cq3El5WbdQvGjuiin/MyWwWjBT3HSAkXEpXftor0OYCpl6X3RZ121XSykP2Tky1v3m4BAqt44IL5tGAgoHebAXJetxmpY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779844817; c=relaxed/simple; bh=zZFnGIBULEQhg8FFEYFwPaffueN2j/MQSoOCifUrvdE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dZwXLbnrP/YZFDK2+Z9rgDq33d57Maa/1xqwQj+ya5FozDzOf8386rTUA027eeB3YvwOJ2iRNICOWnYkxvn3/OX9M9648SnYde6KQZX17QXXrIAmU88VP1UVssPuadcLjiVispr2HOhgIId/xY5nZxLoN+ZtmEXCRUXsNfkAenM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WLZ1PPS9; arc=none smtp.client-ip=209.85.160.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WLZ1PPS9" Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-516d61baff3so55490091cf.0 for ; Tue, 26 May 2026 18:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779844815; x=1780449615; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mlmC4XR4gxPVFC+3IrEsRTTaSk3Dm8cvG0pTcfli6zg=; b=WLZ1PPS9k9IZrVn25H8e/ZPMAKqINazlPctdkjlpPnSayPqfBE7WGPuIKzPx9d0bio 8W62l78jxUQCBctHFNX2b9ASP2/8TWSkMyhYYX/MwMs9t9TiAsl/u+IG0IXlQJf3DDhM S5Q1u1yRuzeRCQop12INnlvBMnZh1f16IAOo4YgWJYbHHNi5iEi3JI3mlsVQ5Cx9M83p v3IbJAoadO/1bDkWt2eCkPrpr5pO02zqOOL67wT5s9I3ouniIQlkhyrUs94N3ZiAaqUr RgpGIMGHB6Ev/UQktUX+3jG8u67iELUNX8Ntb2YaX1CqZRVvLbjMFELXP8b40rO1zzCh nXjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779844815; x=1780449615; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mlmC4XR4gxPVFC+3IrEsRTTaSk3Dm8cvG0pTcfli6zg=; b=qGVmMVWg1zDcIJsE+e7ViHqRSC8tTBYBenbgpppjV5V6hPByBQ8gEu+7yMA7amx5s6 57UZn2RI8jLxLPJhSGk9pWS6r7RMSu+SQ7xtrNY9An8V66k2s97o6LS3OjFGRE8HTbVH QwQwxdqapBNJGu2RwuQI+I7nS2ELIQ6OcgRK/mDqhxXHX4hrLKWGXokyB4OZzxvyhFwf dVl5ZlnHVFHeufPDkezwNrZIiYT8LyvMvI+P06Zf2WP2H6a1GOjJbbKrXEPmReODs9ju 4x8gTW5ZpD9IX0Xfua1WFNTcA7twQCosvDz91+S3K9CmnKXWmS3a5hBz0eIx6Ehoei8n DP/w== X-Forwarded-Encrypted: i=1; AFNElJ/Jmen21BNJxpFdkD/G0OQaAcdKuMDnXlZcYg/HVz5sUJAonW0daqXfUCzNfxfDmxvwAuvu7HwrhOwRHQI=@vger.kernel.org X-Gm-Message-State: AOJu0YxtG/ojmYYTSCfGA798t45z4TmK0dBLeD87Pb2KBXUvOmg2VHed 3bm7QBaNH1tvKnqHtXLutCGq6dz4xvBEbo+rPEEQxS0EcyDcSiRBlUjQ X-Gm-Gg: Acq92OFY125yxzMXwga8iGho6BwZBmoSM1HtzxPjP718gOs+FAXrzZObtuY0T97pc5s 7Uv0ZCll0E3zzsY/zo2uMnayEbPog8VpuS8kHnUkF+C5s3rV5zvpyfi70NZNpSqyDjmxGydNo2C Spo4rvxkJLsTEdlkPWMWhnWfgBZWrEmVYj7C3cyXyUeJq6ICni/CSiaMzztwHVyUemyPvH6iL3y XAYdTXGXJDcmdNX6919eTFuzhxCqFzBvpA/0GBeZalWJ+Po7tUhwPVoV0FXrLMOGB5anYaMTqYf OdEtgOkfQomx+bse8mvLCAZPL3AixRfx/u99xXP+VVkDO2KNVnsOTfDpn9B63R//oaHjJuSYJ9s PAdDEHa8jt0SCGeTyqC/Tx54yx3VvQMqoU6vTBI2GSxcu5xjzPrW120BqR6gLudzK8Af8InmuHy zwF5PG6sY40hFOGDNgA0gXDBgWkzpibC8tt4ghjCiJ6OOfo4KMDjmlh4gJMnpWAdN+J6ddDxUrq 7JYMu3fcxOxrsHDmjzrwxj4nOTPaCsbs3KBPIm2hlI= X-Received: by 2002:ac8:7e93:0:b0:50d:66b6:1564 with SMTP id d75a77b69052e-516d42e4250mr296025671cf.14.1779844814473; Tue, 26 May 2026 18:20:14 -0700 (PDT) Received: from fedora ([172.245.82.59]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51706af1328sm35061051cf.20.2026.05.26.18.20.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2026 18:20:14 -0700 (PDT) Date: Tue, 26 May 2026 20:20:06 -0500 From: Ming Lei To: Tetsuo Handa Cc: Jens Axboe , Bart Van Assche , Christoph Hellwig , Damien Le Moal , linux-block , LKML , Andrew Morton , Linus Torvalds , linux-btrfs@vger.kernel.org, David Sterba Subject: Re: [PATCH v3] loop: Fix NULL pointer dereference in lo_rw_aio() Message-ID: References: <20260518174013.4b72dd50a5bcb89daaed1f62@linux-foundation.org> <94076bc9-2c09-4bb6-8468-b6b8af419cb9@I-love.SAKURA.ne.jp> <1ab8c579-eb76-4227-8a72-6ec819135219@I-love.SAKURA.ne.jp> <1a9f53d4-6f48-4df8-a3d8-2b0e442a163a@I-love.SAKURA.ne.jp> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a9f53d4-6f48-4df8-a3d8-2b0e442a163a@I-love.SAKURA.ne.jp> On Tue, May 26, 2026 at 09:25:30AM +0900, Tetsuo Handa wrote: > On 2026/05/26 0:19, Ming Lei wrote: > > On Mon, May 25, 2026 at 12:40:19PM +0900, Tetsuo Handa wrote: > >> Some commit which was merged in the merge window for 7.1 broke the loop > >> driver; a race window where lo_release() clears the backing file via > >> __loop_clr_fd() despite some I/O requests are pending was introduced [1][2]. > >> > >> The exact commit which changed the behavior is not known due to lack of > >> reproducer and timing dependent behavior, but it seems that we need to > >> solve this problem in the loop driver despite there was no change for the > >> loop driver during this merge window. > >> > >> To close this race, try to flush pending I/O requests. However, calling > >> drain_workqueue() from __loop_clr_fd() with disk->open_mutex held causes > >> lockdep warnings [3][4]. We need to flush pending I/O requests without > >> disk->open_mutex held. > > > > No, please don't workaround before root cause. > > > > No proof shows that the issue is in block layer or loop driver, the IO isn't > > expected, you need to figure out why btrfs still issues IO after this loop > > disk is closed by everyone and writeback is done. > > > > https://syzkaller.appspot.com/x/log.txt?x=101e4702580000 > > > > Of course we should try to figure out the root cause first, but how can we do? Definitely unexpected write IO(after umount & loop closed) from btrfs is more serious, which may cause data loss, so CC btrfs list and maintainer. ... > Possible approaches for finding the exact commit that is causing this problem: > > (a) Revert all changes in the block layer from linux.git and monitor for one week for whether this > problem is still happening (because linux.git is more frequently hitting this problem than > linux-next.git ). > > (b) Revert all changes in the block layer from linux-next.git and monitor for two weeks for > whether this problem is still happening (less reliable than linux.git but a candidate). > > (c) Let sashiko review all changes between v7.0 and v7.1 that may cause this problem. > (Human developers have no time to review. But is investigation with moving baseline commit > possible for sashiko ?) > > (d) Any ideas? > > P.S. Since the loop driver is a critical infrastructure for testing filesystems by syzbot, > I want this problem be addressed before 7.1 is released. syzbot is for finding real problem, here the real trouble is unexpected write IO from btrfs. So please do not try to paper over real bug by 'fixing' loop. Thanks, Ming