linux-kernel - Re: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 15 Jul 2008 11:36:32 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	jens.axboe@...cle.com, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, davem@...emloft.net,
	linux-parisc@...r.kernel.org
Subject: Re: [PATCH] block: fix q->max_segment_size checking in
	blk_recalc_rq_segments about VMERGE

On Tue, 2008-07-15 at 12:20 -0400, Mikulas Patocka wrote:
> On Tue, 15 Jul 2008, James Bottomley wrote:
> 
> > On Tue, 2008-07-15 at 11:58 -0400, Mikulas Patocka wrote:
> >> You are mixing two ideas here:
> >>
> >> (1) virtual merging --- IOMMU maps discontinuous segments into continuous
> >> area that it presents to the device.
> >>
> >> (2) virtual merge accounting --- block layer tries to guess how many
> >> segments will be created by (1) and merges small requests into big ones.
> >> The resulting requests are as big that they can't be processed by the
> >> device if (1) weren't in effect.
> >
> > No ... I'm not ... the virtual merge implementation requires the block
> > layer to get this accounting right, otherwise the iommu code can end up
> > doing the wrong thing.
> 
> The virtual merge (1) can work even without accounting (2). IOMMU can 
> always create less sg entries then the block layer expects.

It can, but it's not optimal ... and depends on max_phys_segments ==
max_hw_segments.

> > You're proposing to eliminate the difference between max_phys_segments
> > and max_hw_segments without actually removing them.
> 
> Yes. Only for alpha and pa-risc, there is difference between these values. 
> And both of these architectures are being discontinued.
> 
> >> That's why I'm proposing to remove virtual merge accounting (2), but leave
> >> virtual merging (1) itself. The accounting doesn't reduce number of sg
> >> slots.
> >
> > Yes, but it's gains very little ... architectures that don't want it can
> > already turn it off, and it's useful for those, like parisc, who do.
> 
> It increases maintainability of the code, reduces bloat and bugs.

That's not really a good reason.  You can eliminate code because it's
unused and unikely to be used or you redo it to better or fix it to be
less buggy.  You don't simply eliminate useful functionality that
currently has in-tree users, however marginal you might opine those
users to be.

James


--
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/