On Mon, Oct 22, 2007 at 10:02:59PM +0400, Oleg Nesterov wrote:
...
> If this work doesn't rearm itself - yes. (otherwise, the same ->func
> can run twice _at the same time_)
>
> But again, in this case wait_on_work() after try_to_grab_pending() == 1
> doesn't block, so we can just do
>
>
On Mon, Oct 22, 2007 at 10:02:59PM +0400, Oleg Nesterov wrote:
> On 10/22, Jarek Poplawski wrote:
...
> > OK, I know I'm dumber and dumber everyday,
>
> You are not alone. I have the same feeling about myself!
Feeling is not the same, only true knowledge counts!
>
> > these all flushes are
> >
On Mon, Oct 22, 2007 at 10:02:59PM +0400, Oleg Nesterov wrote:
On 10/22, Jarek Poplawski wrote:
...
OK, I know I'm dumber and dumber everyday,
You are not alone. I have the same feeling about myself!
Feeling is not the same, only true knowledge counts!
these all flushes are
rtnl
On Mon, Oct 22, 2007 at 10:02:59PM +0400, Oleg Nesterov wrote:
...
If this work doesn't rearm itself - yes. (otherwise, the same -func
can run twice _at the same time_)
But again, in this case wait_on_work() after try_to_grab_pending() == 1
doesn't block, so we can just do
if
On 10/22, Jarek Poplawski wrote:
>
> On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
> > On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
> > > On 10/18, Jarek Poplawski wrote:
> > > >
> > > > +/**
> > > > + * flush_work_sync - block until a work_struct's callback
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
> On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
> > On 10/18, Jarek Poplawski wrote:
> > >
> > > +/**
> > > + * flush_work_sync - block until a work_struct's callback has terminated
> >
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
On 10/18, Jarek Poplawski wrote:
+/**
+ * flush_work_sync - block until a work_struct's callback has terminated
On 10/22, Jarek Poplawski wrote:
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
On 10/18, Jarek Poplawski wrote:
+/**
+ * flush_work_sync - block until a work_struct's callback has
terminated
On Thu, 2007-10-18 at 19:48 +0400, Oleg Nesterov wrote:
> > +void flush_work_sync(struct work_struct *work)
> If we really the new helper, perhaps we can make it a bit better?
>
> 1. Modify insert_work() to take the "struct list_head *at" parameter instead
>of "int tail". I think this patch
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
...
> sched_work_sync() with rtnl_lock(). It's only less probable to lockup
> with this than with flush_schedule_work().
...But, not much less...
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
> On 10/18, Jarek Poplawski wrote:
> >
> > +/**
> > + * flush_work_sync - block until a work_struct's callback has terminated
> ^^^
> Hmm...
>
> > + * Similar to
On Thu, 2007-10-18 at 19:48 +0400, Oleg Nesterov wrote:
+void flush_work_sync(struct work_struct *work)
If we really the new helper, perhaps we can make it a bit better?
1. Modify insert_work() to take the struct list_head *at parameter instead
of int tail. I think this patch will also
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
...
sched_work_sync() with rtnl_lock(). It's only less probable to lockup
with this than with flush_schedule_work().
...But, not much less...
Jarek P.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
On 10/18, Jarek Poplawski wrote:
+/**
+ * flush_work_sync - block until a work_struct's callback has terminated
^^^
Hmm...
+ * Similar to
On Thu, 18 Oct 2007, Oleg Nesterov wrote:
> If we can't just cancel the work, can't we do something like
>
> if (cancel_work_sync(w))
> w->func(w);
>
> instead?
We do an equivalent of this -- all that we care about that w->func(w)
would do is enable_irq() and the rest we
On 10/18, Jarek Poplawski wrote:
>
> +/**
> + * flush_work_sync - block until a work_struct's callback has terminated
^^^
Hmm...
> + * Similar to cancel_work_sync() but will only busy wait (without cancel)
> + * if the work
After reading this and earlier threads about phylib's way of using
workqueue I think such a lighter and safer wrt. locking alternative
for flush_scheduled_work should be useful, but maybe it's only my
imagination.
So, let's ask Oleg Nesterov, whose solutions are here only
copy-cut-pasted &
After reading this and earlier threads about phylib's way of using
workqueue I think such a lighter and safer wrt. locking alternative
for flush_scheduled_work should be useful, but maybe it's only my
imagination.
So, let's ask Oleg Nesterov, whose solutions are here only
copy-cut-pasted
On 10/18, Jarek Poplawski wrote:
+/**
+ * flush_work_sync - block until a work_struct's callback has terminated
^^^
Hmm...
+ * Similar to cancel_work_sync() but will only busy wait (without cancel)
+ * if the work is
On Thu, 18 Oct 2007, Oleg Nesterov wrote:
If we can't just cancel the work, can't we do something like
if (cancel_work_sync(w))
w-func(w);
instead?
We do an equivalent of this -- all that we care about that w-func(w)
would do is enable_irq() and the rest we want to
20 matches
Mail list logo
