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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 10 Jan 2008 09:51:44 -0500
From:	Andy Gospodarek <andy@...yhouse.net>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Jay Vosburgh <fubar@...ibm.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Krzysztof Oledzki <olel@....pl>, netdev@...r.kernel.org,
	Jeff Garzik <jgarzik@...ox.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24

On Thu, Jan 10, 2008 at 11:58:09AM +1100, Herbert Xu wrote:
> On Wed, Jan 09, 2008 at 03:19:10PM -0800, Jay Vosburgh wrote:
> >
> > >No that's not the point.  The point is to move the majority of the code
> > >into process context so that you can take the RTNL.  Once you have taken
> > >the RTNL you can disable BH all you want and I don't care one bit.
> > 
> > 	I'm not sure how we could move more code into a process context;
> > much of the bonding driver is at the mercy of its callers, as in this
> > case.  The monitoring stuff and enslave / deslave is all in a process
> > context now (workqueue).  The transmit processing functions, for
> > example, can't be assumed to be in any particular context as they're
> > called by dev_queue_xmit.
> 
> No I'm not calling for you to move any more code into process context.
> I was replying to the comment that changing the read_lock calls in
> process context to read_lock_bh somehow undoes the benefit of moving
> softirq code into process context.  It does not since the point of the
> move is to be able to take the RTNL, which you can still do as long as
> you do it before you disable BH.
> 

That wasn't the only purpose, Herbert.  Making sure that calls to
dev_set_mac_address were called from process context was important at
the time of the coding as well since at least the tg3 driver took locks
that could not be taken reliably in soft-irq context.  Michael Chan
fixed this here:

commit 986e0aeb9ae09127b401c3baa66f15b7a31f354c
Author: Michael Chan <mchan@...adcom.com>
Date:   Sat May 5 12:10:20 2007 -0700

    [TG3]: Remove reset during MAC address changes.

so if wasn't as much of an issue after that, but moving as much of the
code to process context was important for that as well (hence the move
to not continue to try to not use bh-locks everywhere).


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