[PATCH v3] block: add verifier for cmdline partition

I meet strange filesystem corruption issue recently, the reason is there are overlaps partitions in cmdline partition argument. This patch add verifier for cmdline partition, then if there are overlaps partitions, cmdline_partition will log a warning. Signed-off-by: Wang YanQing

[PATCH v2] block: add verifier for cmdline partition

I meet strange filesystem corruption issue recently, the reason is there are overlaps partitions in cmdline partition argument. This patch add verifier for cmdline partition, then if there are overlaps partitions, cmdline_partition will log a warning. We don't treat overlaps partition as a error:

Re: [PATCH V4 0/7] nvme: pci: fix & improve timeout handling

On Sat, 2018-05-05 at 19:31 -0400, Laurence Oberman wrote: > On Sat, 2018-05-05 at 19:11 -0400, Laurence Oberman wrote: > > On Sat, 2018-05-05 at 21:58 +0800, Ming Lei wrote: > > > Hi, > > > > > > The 1st patch introduces blk_quiesce_timeout() and > > > blk_unquiesce_timeout() > > > for NVMe,

Re: [PATCH V4 0/7] nvme: pci: fix & improve timeout handling

On Sat, 2018-05-05 at 19:11 -0400, Laurence Oberman wrote: > On Sat, 2018-05-05 at 21:58 +0800, Ming Lei wrote: > > Hi, > > > > The 1st patch introduces blk_quiesce_timeout() and > > blk_unquiesce_timeout() > > for NVMe, meantime fixes blk_sync_queue(). > > > > The 2nd patch covers timeout for

Re: [PATCH V4 0/7] nvme: pci: fix & improve timeout handling

On Sat, 2018-05-05 at 21:58 +0800, Ming Lei wrote: > Hi, > > The 1st patch introduces blk_quiesce_timeout() and > blk_unquiesce_timeout() > for NVMe, meantime fixes blk_sync_queue(). > > The 2nd patch covers timeout for admin commands for recovering > controller > for avoiding possible deadlock.

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

On Sat, 2018-05-05 at 12:39 +0200, Paolo Valente wrote: > > BTW, if you didn't run out of patience with this permanent issue yet, > I was thinking of two o three changes to retry to trigger your failure > reliably. Sure, fire away, I'll happily give the annoying little bugger opportunities to

[PATCH V4 7/7] nvme: pci: support nested EH

When one req is timed out, now nvme_timeout() handles it by the following way: nvme_dev_disable(dev, false); nvme_reset_ctrl(>ctrl); return BLK_EH_HANDLED. There are several issues about the above approach: 1) IO may fail during resetting Admin IO timeout may be

[PATCH V4 6/7] nvme: pci: prepare for supporting error recovery from resetting context

Either the admin or normal IO in reset context may be timed out because controller error happens. When this timeout happens, we may have to start controller recovery again. This patch holds the introduced reset lock when running reset, so that we may support nested reset in the following patches.

[PATCH V4 4/7] nvme: pci: freeze queue in nvme_dev_disable() in case of error recovery

When nvme_dev_disable() is used for error recovery, we should always freeze queues before shutdown controller: - reset handler supposes queues are frozen, and will wait_freeze & unfreeze them explicitly, if queues aren't frozen during nvme_dev_disable(), reset handler may wait forever even though

[PATCH V4 5/7] nvme: core: introduce 'reset_lock' for sync reset state and reset activities

NVMe PCI may start a new reset context to run nested reset for recovering from reset context, and we may not change the rule of state machine until other kinds of NVMe controller support that, so use the 'reset_lock' to sync the state change here. Cc: Jianchao Wang

[PATCH V4 2/7] nvme: pci: cover timeout for admin commands running in EH

When admin commands are used in EH for recovering controller, we have to cover their timeout and can't depend on block's timeout since deadlock may be caused when these commands are timed-out by block layer again. Cc: Jianchao Wang Cc: Christoph Hellwig

[PATCH V4 3/7] nvme: pci: only wait freezing if queue is frozen

In nvme_dev_disable() called during shutting down controler, nvme_wait_freeze_timeout() may be done on the controller not frozen yet, so add the check for avoiding the case. Cc: Jianchao Wang Cc: Christoph Hellwig Cc: Sagi Grimberg Cc:

[PATCH V4 0/7] nvme: pci: fix & improve timeout handling

Hi, The 1st patch introduces blk_quiesce_timeout() and blk_unquiesce_timeout() for NVMe, meantime fixes blk_sync_queue(). The 2nd patch covers timeout for admin commands for recovering controller for avoiding possible deadlock. The 3rd and 4th patches avoid to wait_freeze on queues which aren't

[PATCH V4 1/7] block: introduce blk_quiesce_timeout() and blk_unquiesce_timeout()

Turns out the current way can't drain timout completely because mod_timer() can be triggered in the work func, which can be just run inside the synced timeout work: del_timer_sync(>timeout); cancel_work_sync(>timeout_work); This patch introduces one flag of 'timeout_off' for

[PATCH] bcache: display rate debug parameters to 0 when writeback is not running

When writeback is not running, writeback rate should be 0, other value is misleading. And the following dyanmic writeback rate debug parameters should be 0 too, rate, proportional, integral, change otherwise they are misleading when writeback is not running. Signed-off-by: Coly Li

Re: INFO: rcu detected stall in blkdev_ioctl

If various stall reports regarding loop_set_fd() are hitting below sequence, a patch was proposed at https://groups.google.com/d/msg/syzkaller-bugs/5pzXJ8yQFR0/vWeRytaQBAAJ . -- #include #include #include #include #include int main(int argc, char *argv[]) { const int fd =

Re: [PATCH] loop: remember whether sysfs_create_group() succeeded

Milan Broz wrote: > On 05/04/2018 04:40 PM, Tetsuo Handa wrote: > > The loop module ignores sysfs_create_group() failure and pretends that > > LOOP_SET_FD request succeeded. I guess that the author of commit > > ee86273062cbb310 ("loop: add some basic read-only sysfs attributes") > > assumed that

Re: [PATCH] loop: remember whether sysfs_create_group() succeeded

On 05/04/2018 04:40 PM, Tetsuo Handa wrote: > The loop module ignores sysfs_create_group() failure and pretends that > LOOP_SET_FD request succeeded. I guess that the author of commit > ee86273062cbb310 ("loop: add some basic read-only sysfs attributes") > assumed that it is not a fatal error

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

> Il giorno 05 mag 2018, alle ore 10:19, Mike Galbraith ha > scritto: > > On Fri, 2018-05-04 at 21:46 +0200, Mike Galbraith wrote: >> Tentatively, I suspect you've just fixed the nasty stalls I reported a >> while back. > > Oh well, so much for optimism. It took a lot, but

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

On Fri, 2018-05-04 at 21:46 +0200, Mike Galbraith wrote: > Tentatively, I suspect you've just fixed the nasty stalls I reported a > while back. Oh well, so much for optimism. It took a lot, but just hung.