On 2020/8/5 10:46, Ming Lei wrote:
> On Wed, Aug 05, 2020 at 09:54:00AM +0800, Coly Li wrote:
>> On 2020/8/5 07:58, Ming Lei wrote:
>>> On Tue, Aug 04, 2020 at 10:23:32PM +0800, Coly Li wrote:
When some buggy driver doesn't set its queue->limits.discard_granularity
(e.g. current loop
On Wed, Aug 05, 2020 at 09:54:00AM +0800, Coly Li wrote:
> On 2020/8/5 07:58, Ming Lei wrote:
> > On Tue, Aug 04, 2020 at 10:23:32PM +0800, Coly Li wrote:
> >> When some buggy driver doesn't set its queue->limits.discard_granularity
> >> (e.g. current loop device driver), discard at LBA 0 on such
On 2020/8/5 07:58, Ming Lei wrote:
> On Tue, Aug 04, 2020 at 10:23:32PM +0800, Coly Li wrote:
>> When some buggy driver doesn't set its queue->limits.discard_granularity
>> (e.g. current loop device driver), discard at LBA 0 on such device will
>> trigger a kernel BUG() panic from
Ming,
> What we need to fix is loop driver, if it claims to support discard,
> q->limits.discard_granularity has to be one valid value.
Yep!
--
Martin K. Petersen Oracle Linux Engineering
On Tue, Aug 04, 2020 at 10:23:32PM +0800, Coly Li wrote:
> When some buggy driver doesn't set its queue->limits.discard_granularity
> (e.g. current loop device driver), discard at LBA 0 on such device will
> trigger a kernel BUG() panic from block/blk-mq.c:563.
>
> [ 955.565006][ C39]
On 04/08/2020 16:45, Coly Li wrote:
> Yes, Ming just posts a patch with a very similar change to loop device
> driver.
Ah ok. I'll go and have a look at Ming's patch then.
On 2020/8/4 22:39, Johannes Thumshirn wrote:
> On 04/08/2020 16:37, Johannes Thumshirn wrote:
>> On 04/08/2020 16:34, Coly Li wrote:
>>> On 2020/8/4 22:31, Johannes Thumshirn wrote:
On 04/08/2020 16:23, Coly Li wrote:
> This is the procedure to reproduce the panic,
> # modprobe
On 2020/8/4 22:37, Johannes Thumshirn wrote:
> On 04/08/2020 16:34, Coly Li wrote:
>> On 2020/8/4 22:31, Johannes Thumshirn wrote:
>>> On 04/08/2020 16:23, Coly Li wrote:
This is the procedure to reproduce the panic,
# modprobe scsi_debug delay=0 dev_size_mb=2048 max_queue=1
#
On 04/08/2020 16:23, Coly Li wrote:
> This is the procedure to reproduce the panic,
> # modprobe scsi_debug delay=0 dev_size_mb=2048 max_queue=1
> # losetup -f /dev/nvme0n1 --direct-io=on
> # blkdiscard /dev/loop0 -o 0 -l 0x200
losetup -f /dev/sdX isn't it?
On 04/08/2020 16:37, Johannes Thumshirn wrote:
> On 04/08/2020 16:34, Coly Li wrote:
>> On 2020/8/4 22:31, Johannes Thumshirn wrote:
>>> On 04/08/2020 16:23, Coly Li wrote:
This is the procedure to reproduce the panic,
# modprobe scsi_debug delay=0 dev_size_mb=2048 max_queue=1
#
On 04/08/2020 16:34, Coly Li wrote:
> On 2020/8/4 22:31, Johannes Thumshirn wrote:
>> On 04/08/2020 16:23, Coly Li wrote:
>>> This is the procedure to reproduce the panic,
>>> # modprobe scsi_debug delay=0 dev_size_mb=2048 max_queue=1
>>> # losetup -f /dev/nvme0n1 --direct-io=on
>>> #
On 2020/8/4 22:31, Johannes Thumshirn wrote:
> On 04/08/2020 16:23, Coly Li wrote:
>> This is the procedure to reproduce the panic,
>> # modprobe scsi_debug delay=0 dev_size_mb=2048 max_queue=1
>> # losetup -f /dev/nvme0n1 --direct-io=on
>> # blkdiscard /dev/loop0 -o 0 -l 0x200
>
> losetup
When some buggy driver doesn't set its queue->limits.discard_granularity
(e.g. current loop device driver), discard at LBA 0 on such device will
trigger a kernel BUG() panic from block/blk-mq.c:563.
[ 955.565006][ C39] [ cut here ]
[ 955.559660][ C39] invalid opcode:
13 matches
Mail list logo