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
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 linux-kernel" in
the body of a message to [EMAIL
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
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
>*
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() or
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_work().
Run
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 linux-kernel in
the body of a message to [EMAIL
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
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
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
>
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
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
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.
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 meant the
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 that?
Sorry, I
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 return 0.
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_work() as it
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 in
most cases
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
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 of
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
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
> 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 linux-kernel" in
the body of a
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 linux-kernel in
the body of a message
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 means it
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
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
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
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
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 list:
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 applied.
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 your work
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 that I
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 unless someone
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
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.
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
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
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
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
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.
Ok. I
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
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 my goal,
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. Certainly Andrew
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 of
50 matches
Mail list logo
