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] [day] [month] [year] [list]
Date:	Mon, 4 Dec 2006 13:54:45 -0600
From:	Andy Fleming <>
To:	"Maciej W. Rozycki" <>
Cc:	Andrew Morton <>, Jeff Garzik <>,
	Ralf Baechle <>,,
Subject: Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes

On Nov 30, 2006, at 12:07, Maciej W. Rozycki wrote:

> On Mon, 23 Oct 2006, Maciej W. Rozycki wrote:
>>> I'm not too enthusiastic about requiring the ethernet drivers to  
>>> call
>>> phy_disconnect in a separate thread after "close" is called.   
>>> Assuming there's
>>> not some sort of "squash work queue" function that can be invoked  
>>> with
>>> rtnl_lock held, I think phy_disconnect should schedule itself to  
>>> flush the
>>> queue.  This would also require that mdiobus_unregister hold off  
>>> on freeing
>>> phydevs if any of the phys were still waiting for pending  
>>> flush_pending calls
>>> to finish.  Which would, in turn, require mdiobus_unregister to  
>>> schedule
>>> cleaning up memory for some later time.
>>  This could work, indeed.
>>> I'm not enthusiastic about that implementation, either, but it  
>>> maintains the
>>> abstractions I consider important for this code.  The ethernet  
>>> driver should
>>> not need to know what structures the PHY lib uses to implement  
>>> its interrupt
>>> handling, and how to work around their failings, IMHO.
>>  Agreed.
>  So what's the plan?
>  Here's a new version of the patch that addresses your other concerns.

So I think the problem is we still don't understand the problem, and  
the solution to the problem, except that it's causing your driver to  
lock up.  Most of the changes below are fine with me.  The confusing  
one is still the check for current_is_keventd().  This is related in  
some way to why the driver code invokes phy_disconnect from a  
work_queue.  I admit, though, I'm not familiar enough with the work  
queue infrastructure to understand the problem.  But I'm very certain  
that creating a work queue for the sole purpose of disconnecting from  
the PHY is crufty.

Can you try again to convey how this solves your problem, so we can  
try to figure out if there's a better way?


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists