David Miller <[EMAIL PROTECTED]> wrote:
> Is it possible for your changes to be purely networking
> and not need those changes outside of the networking?
See my latest patchset release. I've reduced the dependencies on
non-networking changes to:
(1) Oleg Nesterov's patch to change cancel_dela
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Ah yes, it says nothing about what the returned value means...
Yeah... If you could amend that as part of your patch, that'd be great.
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTE
On 04/25, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Yes sure. Note that this is documented:
> >
> > /*
> > * Kill off a pending schedule_delayed_work(). Note that the work
> > callback
> > * function may still be running on return from cancel_delayed_
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Yes sure. Note that this is documented:
>
> /*
>* Kill off a pending schedule_delayed_work(). Note that the work
> callback
>* function may still be running on return from cancel_delayed_work().
> Run
>* flush_workqueue(
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Sure, I'll grep for cancel_delayed_work(). But unless I missed something,
> > this change should be completely transparent for all users. Otherwise, it
> > is buggy.
>
> I guess you will have to make sure that cance
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Sure, I'll grep for cancel_delayed_work(). But unless I missed something,
> this change should be completely transparent for all users. Otherwise, it
> is buggy.
I guess you will have to make sure that cancel_delayed_work() is always
followed by a flush
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Great. I'll send the s/del_timer_sync/del_timer/ patch.
>
> I didn't say I necessarily agreed that this was a good idea. I just meant
> that
> I agree that it will waste CPU. You must still audit all uses of
> ca
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> > > The current code uses del_timer_sync(). It will also return 0. However,
> > > it will spin waiting for timer->function() to complete. So we are just
> > > wasting CPU.
> >
> > That's my objection to using cancel_delayed_work() as it stands, although
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > The current code uses del_timer_sync(). It will also return 0. However, it
> > will spin waiting for timer->function() to complete. So we are just wasting
> > CPU.
>
> That's my objection to using cancel_delayed_wor
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Let's look at (2). cancel_delayed_work() (on top of del_timer()) returns 0,
> and this is correct, we failed to cancel the timer, and we don't know whether
> work->func() finished, or not.
Yes.
> The current code uses del_timer_sync(). It will also retu
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > > > We only care when del_timer() returns true. In that case, if the timer
> > > > function still runs (possible for single-threaded wqs), it has already
> > > > passed __queue_work().
> > >
> > > Why do you assume
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> > > We only care when del_timer() returns true. In that case, if the timer
> > > function still runs (possible for single-threaded wqs), it has already
> > > passed __queue_work().
> >
> > Why do you assume that?
Sorry, I should have been more clear. I
On 04/23, David Howells wrote:
>
> > We only care when del_timer() returns true. In that case, if the timer
> > function still runs (possible for single-threaded wqs), it has already
> > passed __queue_work().
>
> Why do you assume that?
If del_timer() returns true, the timer was pending. This m
> We only care when del_timer() returns true. In that case, if the timer
> function still runs (possible for single-threaded wqs), it has already
> passed __queue_work().
Why do you assume that?
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
On 04/20, Andrew Morton wrote:
>
> On Fri, 20 Apr 2007 11:41:46 +0100
> David Howells <[EMAIL PROTECTED]> wrote:
>
> > There are only two non-net patches that AF_RXRPC depends on:
> >
> > (1) The key facility changes. That's all my code anyway, and shouldn't be
> > a
> > problem to merge
On Fri, 20 Apr 2007 11:41:46 +0100
David Howells <[EMAIL PROTECTED]> wrote:
> There are only two non-net patches that AF_RXRPC depends on:
>
> (1) The key facility changes. That's all my code anyway, and shouldn't be a
> problem to merge unless someone else has put some changes in there th
David Miller <[EMAIL PROTECTED]> wrote:
> Now that Herbert cleared up the crypto layer issues
> the only problem left is that there are generic changes
> in there which are not strictly networking but which
> your subsequent networking changes depend upon.
>
> This is a mess, and makes merging you
From: David Howells <[EMAIL PROTECTED]>
Date: Fri, 20 Apr 2007 09:02:07 +0100
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > I applied already the patches I thought were appropriate,
> > you had some crypto layer changes that you need to work
> > out with Herbert Xu before the rest can be applie
David Miller <[EMAIL PROTECTED]> wrote:
> I applied already the patches I thought were appropriate,
> you had some crypto layer changes that you need to work
> out with Herbert Xu before the rest can be applied.
Should the rest of it go via Andrew's tree then?
David
-
To unsubscribe from this li
David Miller <[EMAIL PROTECTED]> wrote:
>
> I applied already the patches I thought were appropriate,
> you had some crypto layer changes that you need to work
> out with Herbert Xu before the rest can be applied.
He has already fixed it by using the scatterlist interface for now.
So the last set
From: David Howells <[EMAIL PROTECTED]>
Date: Thu, 19 Apr 2007 15:18:23 +0100
> Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> > What is the ETA on your patches?
>
> That depends on Dave Miller now, I think. I'm assuming they need to go
> through the network GIT tree to get to Linus. Certain
David Howells <[EMAIL PROTECTED]> writes:
> Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> Ok. I don't see any patches in -mm so I was assuming these patches have
>> not been queued up anywhere.
>
> They haven't been quite yet. Is it your intention to kill these features in
> 2.6.22?
That is
Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ok. I don't see any patches in -mm so I was assuming these patches have
> not been queued up anywhere.
They haven't been quite yet. Is it your intention to kill these features in
2.6.22?
David
-
To unsubscribe from this list: send the line "unsubs
David Howells <[EMAIL PROTECTED]> writes:
> Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> What is the ETA on your patches?
>
> That depends on Dave Miller now, I think. I'm assuming they need to go
> through the network GIT tree to get to Linus. Certainly Andrew Morton seems
> to think so.
Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> What is the ETA on your patches?
That depends on Dave Miller now, I think. I'm assuming they need to go
through the network GIT tree to get to Linus. Certainly Andrew Morton seems
to think so.
David
-
To unsubscribe from this list: send the line "
25 matches
Mail list logo
