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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 26 Sep 2007 17:57:55 +0900
From:	FUJITA Tomonori <tomof@....org>
To:	hare@...e.de
Cc:	tomof@....org, open-iscsi@...glegroups.com, hch@...radead.org,
	jeff@...zik.org, davem@...emloft.net, mchristi@...hat.com,
	netdev@...r.kernel.org, anilgv@...adcom.com, talm@...adcom.com,
	lusinsky@...adcom.com, uri@...adcom.com,
	fujita.tomonori@....ntt.co.jp
Subject: Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.

On Tue, 25 Sep 2007 10:39:17 +0200
Hannes Reinecke <hare@...e.de> wrote:

> Hi Tomo,
> 
> FUJITA Tomonori wrote:
> > On Sat, 8 Sep 2007 13:00:36 +0100
> > Christoph Hellwig <hch@...radead.org> wrote:
> > 
> >> On Sat, Sep 08, 2007 at 07:32:27AM -0400, Jeff Garzik wrote:
> >>> FUJITA Tomonori wrote:
> >>>> Yeah, iommu code ignores the lld limitations (the problem is that the
> >>>> lld limitations are in request_queue and iommu code can't access to
> >>>> request_queue). There is no way to tell iommu code about the lld
> >>>> limitations.
> >>>
> >>> This fact very much wants fixing.
> >>
> >> Absolutely.  Unfortunately everyone wastes their time on creating workarounds
> >> instead of fixing the underlying problem.
> > 
> > Any ideas on how to fix this?
> > 
> > I chatted to Jens and James on this last week.
> > 
> > - we could just copies the lld limitations to device structure. it's
> > hacky but device structure already has hacky stuff.
> > 
> > - we could just link device structure to request_queue structure so
> > that iommu code can see request_queue structure.
> > 
> > - we could remove the lld limitations in request_queue strucutre and
> > have a new strucutre (something like struct io_restrictions). then
> > somehow we could link the new structure with request_queue and device
> > strucutres.
> > 
> I'd prefer the latter. These struct io_restrictions could then be used
> by dm (which has it's own version right now) to merge queue capabilities.

Yeah, we could nicely handle lld's restrictions (especially with
stacking devices). But iommu code needs only max_segment_size and
seg_boundary_mask, right? If so, the first simple approach to add two
values to device structure is not so bad, I think.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists