linux-kernel - Re: [RFC PATCH] block: change max_segments default to USHRT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20111129193335.GA6827@redhat.com>
Date:	Tue, 29 Nov 2011 14:33:36 -0500
From:	Mike Snitzer <snitzer@...hat.com>
To:	"Martin K. Petersen" <martin.petersen@...cle.com>
Cc:	linux-kernel@...r.kernel.org, Jens Axboe <jaxboe@...ionio.com>,
	Shuichi Ihara <sihara@....com>, dm-devel@...hat.com
Subject: Re: [RFC PATCH] block: change max_segments default to USHRT_MAX

On Tue, Nov 29 2011 at 12:59pm -0500,
Martin K. Petersen <martin.petersen@...cle.com> wrote:

> >>>>> "Mike" == Mike Snitzer <snitzer@...hat.com> writes:
> 
> Mike> The reported problem was that a DM multipath device's max_segemnts
> Mike> was constrained to BLK_MAX_SEGMENTS (128) even though the
> Mike> underlying paths' max_segments were larger.  For example, SCSI
> Mike> establishes a max_segments of SCSI_MAX_SG_CHAIN_SEGMENTS (2048).
> 
> I'd rather that we revisited the patches I posted a while back where we
> have different defaults for LLDs and stacking drivers.

Don't think I ever saw those patches.  But it isn't immediately clear to
me why we'd want to have to continue to think in different terms
depending on whether we're LLD or stacked (especially for max_segments).

Though I do understand why we need it in some cases, e.g.: the existing
conflicting default for discard_zeroes_data (block vs DM).  It is
unfortunate yet necessary given the current limits stacking.

(We _could_ make dzd=0 the uniform default if DM were made to look at
all devices in a table and decide whether dzd should be enabled,
something like we do for discards with dm_table_supports_discards())

Thing is we have the block layer doing the stacking of limits.. so
ideally the stacking drivers wouldn't need to work so hard to keep the
block layer non-committal on differentiating between LLD vs stacked.

I'd imagine your patches will formalize an interface that gets us away
from what may seem, to the uninitiated, like adhoc twiddling of certain
limits.

> I'll freshen those up and post them later today.

Great (please cc dm-devel when you post them).

Long story short, I look forward to seeing your patches ;)

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/