On Tue, 16 Sep 2014, Petr [iso-8859-1] Ml�dek wrote:
> Anyway, the solution for the race between kick_hub_wq() and
> hub_event() might be to get the reference already in kick_hub_wq().
Yes, this probably would work.
> I mean something like:
>
> static void kick_hub_wq(struct usb_hub *hub)
> {
On Tue 16-09-14 11:10:31, Petr Mládek wrote:
> Anyway, the solution for the race between kick_hub_wq() and
> hub_event() might be to get the reference already in kick_hub_wq().
> I mean something like:
>
> static void kick_hub_wq(struct usb_hub *hub)
> {
> if (hub->disconnected ||
On Fri 12-09-14 11:44:14, Alan Stern wrote:
> On Fri, 12 Sep 2014, Petr Mladek wrote:
>
> > > I don't think you can eliminate the lock quite so easily. This patch
> > > introduces some nasty races.
> > >
> > > > @@ -577,18 +571,20 @@ static int hub_port_status(struct usb_hub *hub,
> > > > int
On Fri 12-09-14 11:44:14, Alan Stern wrote:
On Fri, 12 Sep 2014, Petr Mladek wrote:
I don't think you can eliminate the lock quite so easily. This patch
introduces some nasty races.
@@ -577,18 +571,20 @@ static int hub_port_status(struct usb_hub *hub,
int port1,
On Tue 16-09-14 11:10:31, Petr Mládek wrote:
Anyway, the solution for the race between kick_hub_wq() and
hub_event() might be to get the reference already in kick_hub_wq().
I mean something like:
static void kick_hub_wq(struct usb_hub *hub)
{
if (hub-disconnected ||
On Tue, 16 Sep 2014, Petr [iso-8859-1] Ml�dek wrote:
Anyway, the solution for the race between kick_hub_wq() and
hub_event() might be to get the reference already in kick_hub_wq().
Yes, this probably would work.
I mean something like:
static void kick_hub_wq(struct usb_hub *hub)
{
On Fri, Sep 12, 2014 at 02:21:05PM +0200, Petr Mladek wrote:
> There is no need to have separate kthread for handling USB hub events.
> It is more elegant to use the workqueue framework.
>
> The workqueue is allocated as unbound, cpu intensive, and freezable.
I'd just go with WQ_FREEZABLE. As a
On Fri, 12 Sep 2014, Petr Mladek wrote:
> > I don't think you can eliminate the lock quite so easily. This patch
> > introduces some nasty races.
> >
> > > @@ -577,18 +571,20 @@ static int hub_port_status(struct usb_hub *hub, int
> > > port1,
> > >
> > > static void kick_khubd(struct
On Fri 2014-09-12 10:16:21, Alan Stern wrote:
> On Fri, 12 Sep 2014, Petr Mladek wrote:
>
> > There is no need to have separate kthread for handling USB hub events.
> > It is more elegant to use the workqueue framework.
> >
> > The workqueue is allocated as unbound, cpu intensive, and freezable.
On Fri, 12 Sep 2014, Petr Mladek wrote:
> There is no need to have separate kthread for handling USB hub events.
> It is more elegant to use the workqueue framework.
>
> The workqueue is allocated as unbound, cpu intensive, and freezable.
> There does not seem to be any big advantage to run it
There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.
The workqueue is allocated as unbound, cpu intensive, and freezable.
There does not seem to be any big advantage to run it on the same CPU.
The handler is taking a lock and
There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.
The workqueue is allocated as unbound, cpu intensive, and freezable.
There does not seem to be any big advantage to run it on the same CPU.
The handler is taking a lock and
On Fri, 12 Sep 2014, Petr Mladek wrote:
There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.
The workqueue is allocated as unbound, cpu intensive, and freezable.
There does not seem to be any big advantage to run it on the
On Fri 2014-09-12 10:16:21, Alan Stern wrote:
On Fri, 12 Sep 2014, Petr Mladek wrote:
There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.
The workqueue is allocated as unbound, cpu intensive, and freezable.
There
On Fri, 12 Sep 2014, Petr Mladek wrote:
I don't think you can eliminate the lock quite so easily. This patch
introduces some nasty races.
@@ -577,18 +571,20 @@ static int hub_port_status(struct usb_hub *hub, int
port1,
static void kick_khubd(struct usb_hub *hub)
{
On Fri, Sep 12, 2014 at 02:21:05PM +0200, Petr Mladek wrote:
There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.
The workqueue is allocated as unbound, cpu intensive, and freezable.
I'd just go with WQ_FREEZABLE. As a
16 matches
Mail list logo
