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: <20081204112959X.fujita.tomonori@lab.ntt.co.jp>
Date:	Thu, 4 Dec 2008 11:30:16 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	agk@...hat.com
Cc:	fujita.tomonori@....ntt.co.jp, mbroz@...hat.com,
	jens.axboe@...cle.com, neilb@...e.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: fix setting of max_segment_size and
 seg_boundary mask

On Wed, 3 Dec 2008 12:06:16 +0000
Alasdair G Kergon <agk@...hat.com> wrote:

> On Wed, Dec 03, 2008 at 02:32:00PM +0900, FUJITA Tomonori wrote:
> > On Mon, 01 Dec 2008 00:42:09 +0100
> > Milan Broz <mbroz@...hat.com> wrote:
>  
> > > @@ -314,6 +317,7 @@ void blk_queue_stack_limits(struct request_queue *t, struct request_queue *b)
> > >  	/* zero is "infinity" */
> > >  	t->max_sectors = min_not_zero(t->max_sectors, b->max_sectors);
> > >  	t->max_hw_sectors = min_not_zero(t->max_hw_sectors, b->max_hw_sectors);
> > > +	t->seg_boundary_mask = min_not_zero(t->seg_boundary_mask, b->seg_boundary_mask);
> > >  
> > >  	t->max_phys_segments = min(t->max_phys_segments, b->max_phys_segments);
> > >  	t->max_hw_segments = min(t->max_hw_segments, b->max_hw_segments);
>  
> > Theoretically, blk_queue_stack_limits() better use min_not_zero
> > instead of min for max_phys_segments, max_hw_segments, and
> > max_segment_size?
> 
> But does zero have any valid use there?

I think that zero is invalid for all the parameters.

Setting max_phys_segments to zero means that we can't do any data
transfer... Ditto for max_hw_segments, and max_segment_size.

I think that the lowest layer (scsi in this case) needs to setup them
properly and the upper layers should inherit them.


> We left those alone for now, feeling that BUG_ON() might be more appropriate.

Yeah, the patch is fine for now.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ