Date: Mon, 10 May 2010 08:26:08 -0700 From: Sam Leffler <sam@errno.com> To: Patrick Lamaiziere <patfbsd@davenulle.org> Cc: freebsd-hackers@freebsd.org Subject: Re: hifn(4) DMA fix for review Message-ID: <B937FBA2-4967-4977-BDEA-0B46D5A3E0F5@errno.com> In-Reply-To: <20100510001637.2a564cd5@davenulle.org> References: <4BE46650.7010008@bluezbox.com> <20100510001637.2a564cd5@davenulle.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 9, 2010, at 3:16 PM, Patrick Lamaiziere wrote: > Le Fri, 07 May 2010 12:13:20 -0700, > Oleksandr Tymoshenko <gonzo@bluezbox.com> a =E9crit : > > Hi, > >> Proposed patch addresses hifn(4) problems on FreeBSD/mips. >> Current implementation keeps some of the state information (indexes =20= >> in >> buffers, etc) in DMA-mapped memory and bus_dma code invalidates them >> during sync operations. This fix moves data that doesn't belong to =20= >> DMA >> ring to softc structure. > > I do not have any comment but I will try on my Soekris (the next > weekend) if it can help. > > I noticed several things in hifn, if you want to look: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/130286 > > IMHO some locks are missing in the use of sc->sc_sessions (the array > containing the sessions) : in hifn_newsession(), if there is no space > left in sc->sc_sessions, a new array is allocated and the sessions are > copied to it. Unfortunaly, sc->sc_sessions is used in hifn_process > without any lock and we use some pointers on the array (my patch =20 > should > addresses this if I remember...). Isn't this just the glx locking? (no offense intended) I've said =20 before I think we to move session management up into the crypto layer =20= since it's implemented in many drivers (usually w/ c&p of the same =20 code as you noted here sometimes a bit different). Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B937FBA2-4967-4977-BDEA-0B46D5A3E0F5>