Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 13 May 2020 09:41:19 -0700
From:   "Darrick J. Wong" <darrick.wong@oracle.com>
To:     Jens Axboe <axboe@kernel.dk>
Cc:     "Xu, Yanfei" <yanfei.xu@windriver.com>,
        LKML <linux-kernel@vger.kernel.org>, linux-block@vger.kernel.org,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: BUG:loop:blk_update_request: I/O error, dev loop6, sector 49674
 op 0x9:(WRITE_ZEROES)
Message-ID: <20200513164119.GD1984748@magnolia>
References: <dac81506-0065-ee64-fcd1-c9f1d002b4fb@windriver.com>
 <c51460e0-1abb-799d-9ee9-de9c39315eda@windriver.com>
 <8f3eeb22-2e85-aa3f-6287-b3c467d39a8e@kernel.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8f3eeb22-2e85-aa3f-6287-b3c467d39a8e@kernel.dk>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

[add fsdevel to cc]

On Tue, May 12, 2020 at 08:22:08PM -0600, Jens Axboe wrote:
> On 5/12/20 8:14 PM, Xu, Yanfei wrote:
> > Hi,
> > 
> > After operating the /dev/loop which losetup with an image placed in**tmpfs,
> > 
> > I got the following ERROR messages:
> > 
> > ----------------[cut here]---------------------
> > 
> > [? 183.110770] blk_update_request: I/O error, dev loop6, sector 524160 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > [? 183.123949] blk_update_request: I/O error, dev loop6, sector 522 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > [? 183.137123] blk_update_request: I/O error, dev loop6, sector 16906 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > [? 183.150314] blk_update_request: I/O error, dev loop6, sector 32774 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > [? 183.163551] blk_update_request: I/O error, dev loop6, sector 49674 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > [? 183.176824] blk_update_request: I/O error, dev loop6, sector 65542 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > [? 183.190029] blk_update_request: I/O error, dev loop6, sector 82442 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > [? 183.203281] blk_update_request: I/O error, dev loop6, sector 98310 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > [? 183.216531] blk_update_request: I/O error, dev loop6, sector 115210 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > [? 183.229914] blk_update_request: I/O error, dev loop6, sector 131078 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio class 0
> > 
> > 
> > I have found the commit which introduce this issue by git bisect :
> > 
> > ??? commit :efcfec57[loop: fix no-unmap write-zeroes request behavior]
> 
> Please CC the author of that commit too. Leaving the rest quoted below.
> 
> > Kernrel version: Linux version 5.6.0
> > 
> > Frequency: everytime
> > 
> > steps to reproduce:
> > 
> > ? 1.git clone mainline kernel
> > 
> > ? 2.compile kernel with ARCH=x86_64, and then boot the system with it
> > 
> > ??? (seems other arch also can reproduce it )
> > 
> > ? 3.make an image by "dd of=/tmp/image if=/dev/zero bs=1M count=256"
> > 
> > ? *4.**place the image in tmpfs directory*
> > 
> > ? 5.losetup /dev/loop6 /PATH/TO/image
> > 
> > ? 6.mkfs.ext2 /dev/loop6
> > 
> > 
> > Any comments will be appreciated.

Hm, you got IO failures here because shmem_fallocate doesn't support
FL_ZERO_RANGE range.  That might not be too hard to add, but there's a
broader problem of detecting fallocate support--

The loop driver assumes that if the file has an fallocate method then
it's safe to set max_discard_sectors (and now max_write_zeroes_sectors)
to UINT_MAX>>9.  There's currently no good way to detect which modes are
supported by a filesystem's ->fallocate function, or to discover the
required granularity.

Right now we tell application developers that the way to discover the
conditions under which fallocate will work is to try it and see if they
get EOPNOTSUPP.

One way to "fix" this would be to fix lo_fallocate to set RQF_QUIET if
the filesystem returns EOPNOTSUPP, which gets rid of the log messages.
We probably ought to zero out the appropriate max_*_sectors if we get
EOPNOTSUPP.

--D

> > 
> > 
> > Thanks,
> > 
> > Yanfei
> > 
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Jens Axboe
>