From: Jarek Poplawski <jarkao2@o2.pl>
To: "Maciej W\. Rozycki" <macro@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Andy Fleming <afleming@freescale.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jeff Garzik <jgarzik@pobox.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
Date: Fri, 19 Oct 2007 16:39:21 +0200 [thread overview]
Message-ID: <20071019143921.GB2598@ff.dom.local> (raw)
In-Reply-To: <Pine.LNX.4.64N.0710191229510.13279@blysk.ds.pg.gda.pl>
On Fri, Oct 19, 2007 at 12:38:29PM +0100, Maciej W. Rozycki wrote:
> On Thu, 18 Oct 2007, Maciej W. Rozycki wrote:
>
> > > 1) phy_change() checks PHY_HALTED flag without lock; I think it's
> > > racy: eg. if it's done during phy_stop() it can check just before
> > > the flag is set and reenable interrupts just after phy_stop() ends.
> >
> > I remember having a look into it, but it was long ago and I cannot
> > immediately recall the conclusion. Which means it is either broken or
> > deserves a comment as non-obvious. I will have a look into it again, but
> > I am resource-starved a little at the moment, sorry.
>
> Well, I have now recalled what the issue is -- we just plainly and simply
> want to avoid a hardirq spinlock for the very reason we do not do all the
> processing in the hardirq handler. The thing is we make accesses to the
> MDIO bus with the phydev lock held and it may take ages until these
> accesses will have completed. And we cannot afford keeping interrupts
> disabled for so long.
>
> So the only way is to make the check for the HALTED state lockless and
> make sure any race condition is handled gracefully and does not lead to
> inconsistent behaviour. Which I think as of what we have in the
> net-2.6.24 tree is the case, but there are never too many eyes to look at
> a piece of code, so if anybody feels like proving me wrong, then just go
> ahead!
Actually I'm not convinced with this explanation. It seems to me that
since there are such serious locking problems (especially with rntl),
there could be once more considered a private workqueue. You've
written earlier about being a lonely user of this code. But, since
Benjamin offered his help with changing to mutexes, which looks like
very reasonable idea to me (probably I miss most of the points...),
maybe it's very good opportunity to both: make this code better and
double the user base! I'm interested in looking for such solution
if Benjamin thinks there could be too few problems for him... So,
let somebody tell us what could be wrong with this idea?
Cheers (till Monday),
Jarek P.
next prev parent reply other threads:[~2007-10-19 14:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-19 14:38 Maciej W. Rozycki
2007-09-20 23:53 ` Andrew Morton
2007-09-21 12:51 ` Maciej W. Rozycki
2007-09-21 18:42 ` Andrew Morton
2007-10-15 12:53 ` Jarek Poplawski
2007-10-15 17:03 ` Maciej W. Rozycki
2007-10-16 6:21 ` Jarek Poplawski
2007-10-16 17:19 ` Maciej W. Rozycki
2007-10-17 8:58 ` Jarek Poplawski
2007-10-17 9:08 ` Benjamin Herrenschmidt
2007-10-17 9:09 ` Jarek Poplawski
2007-10-18 6:31 ` Jarek Poplawski
2007-10-18 7:05 ` [PATCH] flush_work_sync vs. flush_scheduled_work " Jarek Poplawski
2007-10-18 15:48 ` Oleg Nesterov
2007-10-18 15:58 ` Maciej W. Rozycki
2007-10-19 7:50 ` Jarek Poplawski
2007-10-19 8:01 ` Jarek Poplawski
2007-10-22 6:11 ` Jarek Poplawski
2007-10-22 18:02 ` Oleg Nesterov
2007-10-23 6:59 ` Jarek Poplawski
2007-10-23 9:21 ` Jarek Poplawski
2007-10-19 8:00 ` Johannes Berg
2007-10-18 11:37 ` Maciej W. Rozycki
2007-10-18 11:30 ` Maciej W. Rozycki
2007-10-18 14:37 ` Jarek Poplawski
2007-10-18 15:31 ` Maciej W. Rozycki
2007-10-19 8:17 ` Jarek Poplawski
2007-10-19 12:57 ` Maciej W. Rozycki
2007-10-19 11:38 ` Maciej W. Rozycki
2007-10-19 14:39 ` Jarek Poplawski [this message]
2007-10-19 17:58 ` Maciej W. Rozycki
2007-10-19 21:46 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071019143921.GB2598@ff.dom.local \
--to=jarkao2@o2.pl \
--cc=afleming@freescale.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®