Re: [dm-devel] Patch "dm: ensure bio submission follows a depth-first tree walk" has been added to the 4.15-stable tree

On Thu, Mar 22 2018 at 9:06am -0400, gre...@linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > dm: ensure bio submission follows a depth-first tree walk > > to the 4.15-stable tree which can be found at: >

Re: [dm-devel] Patch "dm: ensure bio submission follows a depth-first tree walk" has been added to the 4.15-stable tree

On Thu, Mar 22, 2018 at 09:47:59AM -0400, Mike Snitzer wrote: > On Thu, Mar 22 2018 at 9:06am -0400, > gre...@linuxfoundation.org wrote: > > > > > This is a note to let you know that I've just added the patch titled > > > > dm: ensure bio submission follows a

[dm-devel] [PATCH] dm/mpath: flush workqueue only in necessary

The workqueue are shared by many multipath devices, we just need to flush whole workqueue when it is necessary. Otherwise, we just flush works. Signed-off-by: wuzhouhui --- drivers/md/dm-mpath.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

Re: [dm-devel] Patch "dm: ensure bio submission follows a depth-first tree walk" has been added to the 4.15-stable tree

I agree. The patch "dm: ensure bio submission follows a depth-first tree walk" doesn't really fix any bug (and it may introduce new bugs), so it isn't applicable to the stable kernel branches. The kernel 4.15 and below have a "dm_offload" mechanism that avoids the possible deadlocks in dm,

Re: [dm-devel] [PATCH] multipathd: check and cleanup zombie paths

On Thu, 2018-03-22 at 03:40 +, Chongyun Wu wrote: > I did a test. Below command can remove the residual device: > *echo "scsi remove-single-device 3 0 0 3" > /proc/scsi/scsi* > Is it safe? Hello Chongyun, Are you aware of the linux-scsi mailing list? I think this question would be more

[dm-devel] [PATCH] dm table: add support for secure erase forwarding [was: Re: Adaptation secure erase forwarding for 4.1x kernels]

On Tue, Mar 13 2018 at 5:23am -0400, Denis Semakin wrote: > Hello. > Here is fixed patch for modern 4.1x kernels. > The idea is to forward secure erase request within device mapper layer to > block device driver which can support secure erase. > Could you please review?

[dm-devel] [PATCH v2] dm raid: fix parse_raid_params() variable range issue

This v2 addresses Mikulas' point about the variable range and folds in "[PATCH] dm raid: use __within_range() more in parse_raid_params()": parse_raid_parames() compared variable "int value" with INT_MAX to prevent overflow of mddev variables set. Change type to "long long value". Whilst on it,

Re: [dm-devel] [PATCH v2] dm raid: fix parse_raid_params() variable range issue

On Thu, Mar 22 2018 at 1:21pm -0400, Heinz Mauelshagen wrote: > This v2 addresses Mikulas' point about the variable range and folds in > "[PATCH] dm raid: use __within_range() more in parse_raid_params()": > > parse_raid_parames() compared variable "int value" with > INT_MAX

Re: [dm-devel] [PATCH v2] dm raid: fix parse_raid_params() variable range issue

On 03/22/2018 08:41 PM, Mike Snitzer wrote: On Thu, Mar 22 2018 at 1:21pm -0400, Heinz Mauelshagen wrote: This v2 addresses Mikulas' point about the variable range and folds in "[PATCH] dm raid: use __within_range() more in parse_raid_params()": parse_raid_parames()

Re: [dm-devel] [RFC PATCH] multipath: flush workqueue only in necessary

Hi Zhouhui, Your patch is not a formatted one. At least, it should include Signed-off-by Thanks, Changwei On 2018/3/12 15:47, wuzhouhui wrote: > When flush works belong a specific multipath, we flush workqueue only > in necessary. > > (That's my first time to send a patch, please remind me if

Re: [dm-devel] [PATCH] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Wed, Mar 21, 2018 at 01:40:31PM -0500, Christopher Lameter wrote: > On Wed, 21 Mar 2018, Mikulas Patocka wrote: > > > > > F.e. you could optimize the allcations > 2x PAGE_SIZE so that they do > > > > not > > > > allocate powers of two pages. It would be relatively easy to make > > > >

Re: [dm-devel] [PATCH] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Wed, Mar 21, 2018 at 12:25:39PM -0400, Mikulas Patocka wrote: > Now - we don't want higher-order allocations for power-of-two caches > (because higher-order allocations just cause memory fragmentation without > any benefit) Higher-order allocations don't cause memory fragmentation. Indeed,

Re: [dm-devel] [PATCH] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Wed, Mar 21, 2018 at 12:39:33PM -0500, Christopher Lameter wrote: > One other thought: If you want to improve the behavior for large scale > objects allocated through kmalloc/kmemcache then we would certainly be > glad to entertain those ideas. > > F.e. you could optimize the allcations > 2x

Re: [dm-devel] [PATCH 2/2] multipathd: handle errors in uxlsnr as fatal

On Tue, Mar 20, 2018 at 05:50:10PM +0100, Martin Wilck wrote: > The ppoll() calls of the uxlsnr thread are vital for proper functioning of > multipathd. If the uxlsnr thread can't open the socket or fails to call > ppoll() > for other reasons, quit the daemon. If we don't do that, multipathd may

Re: [dm-devel] [PATCH v2 1/2] libmultipath: don't reject maps with undefined prio

On Wed, Mar 21, 2018 at 10:34:18AM +0100, Martin Wilck wrote: > libmultipath's prio routines can deal with pp->priority == PRIO_UNDEF > just fine. PRIO_UNDEF is just a very low priority. So there's > no reason to reject setting up a multipath map because paths have > undefined priority. > The