Re: Getting the new RxRPC patches upstream
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 cancel_work_sync() to wait on it. */ No, it isn't documented. It says that the *work* callback may be running, but does not mention the timer callback. However, just looking at the cancellation function source made it clear that this would wait for the timer handler to return first. However, is it worth just making cancel_delayed_work() a void function and not returning anything? I'm not sure the return value is very useful. David - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 * flush_workqueue() or cancel_work_sync() to wait on it. */ No, it isn't documented. It says that the *work* callback may be running, but does not mention the timer callback. However, just looking at the cancellation function source made it clear that this would wait for the timer handler to return first. Ah yes, it says nothing about what the returned value means... However, is it worth just making cancel_delayed_work() a void function and not returning anything? I'm not sure the return value is very useful. cancel_rearming_delayed_work() needs this, tty_io.c, probably somebody else. Oleg. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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_delayed_work() to use del_timer() rather than del_timer_sync() [patch 02/16]. This patch can be discarded without compilation failure at the expense of making AFS slightly less efficient. It also makes AF_RXRPC slightly less efficient, but only in the rmmod path. (2) A symbol export in the keyring stuff plus a proliferation of the types available in the struct key::type_data union [patch 03/16]. This does not conflict with any other patches that I know about. (3) A symbol export in the timer stuff [patch 04/16]. Everything else that remains after the reduction is confined to the AF_RXRPC or AFS code, save for a couple of networking patches in my patchset that you already have and I just need to make the thing compile. I'm not sure that I can make the AF_RXRPC patches totally independent of the AFS patches as the two sets need to interleave since the last AF_RXRPC patch deletes the old RxRPC code - which the old AFS code depends on. David - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 assumption that we only care about a true return from del_timer(). If del_timer() returns true, the timer was pending. This means it was started by work-func() (note that __run_timers() clears timer_pending() before calling timer-function). This in turn means that delayed_work_timer_fn() has already called __queue_work(dwork), otherwise work-func() has no chance to run. But if del_timer() returns 0, then there may be a problem. We can't tell the difference between the following two cases: (1) The timer hadn't been started. (2) The timer had been started, has expired and is no longer pending, but another CPU is running its handler routine. try_to_del_timer_sync() _does_, however, distinguish between these cases: the first is the 0 return, the second is the -1 return, and the case where it dequeued the timer is the 1 return. BTW, can a timer handler be preempted? I assume not... But it can be delayed by interrupt processing. David - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 should have been more clear. I meant the assumption that we only care about a true return from del_timer(). If del_timer() returns true, the timer was pending. This means it was started by work-func() (note that __run_timers() clears timer_pending() before calling timer-function). This in turn means that delayed_work_timer_fn() has already called __queue_work(dwork), otherwise work-func() has no chance to run. But if del_timer() returns 0, then there may be a problem. We can't tell the difference between the following two cases: (1) The timer hadn't been started. (2) The timer had been started, has expired and is no longer pending, but another CPU is running its handler routine. try_to_del_timer_sync() _does_, however, distinguish between these cases: the first is the 0 return, the second is the -1 return, and the case where it dequeued the timer is the 1 return. Of course, del_timer() and del_timer_sync() are different. What I meant the latter buys nothing for cancel_delayed_work() (which in fact could be named try_to_cancel_delayed_work()). 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. 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. I guess I misunderstood you. Perhaps, you propose a new helper which use try_to_del_timer_sync(), yes? Unless I missed something, this doesn't help. Because the return value == -1 should be treated as 0. We failed to stop the timer, and we can't free dwork. IOW, currently we should do: if (!cancel_delayed_work(dwork)) cancel_work_sync(dwork)); The same if we use del_timer(). If we use try_to_del_timer_sync(), if (cancel_delayed_work(dwork) = 0) cancel_work_sync(dwork)); (of course, dwork shouldn't re-arm itself). Could you clarify if I misunderstood you again? BTW, can a timer handler be preempted? I assume not... But it can be delayed by interrupt processing. No, it can't be preempted, it runs in softirq context. Oleg. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 stands, although in
most cases it's a relatively minor waste of time. However, if the timer
expiry routine gets interrupted then it may not be so minor... So, yes, I'm
in full agreement with you there.
Great. I'll send the s/del_timer_sync/del_timer/ patch.
I guess I misunderstood you. Perhaps, you propose a new helper which use
try_to_del_timer_sync(), yes? Unless I missed something, this doesn't help.
Because the return value == -1 should be treated as 0. We failed to stop
the timer, and we can't free dwork.
Consider how I'm using try_to_cancel_delayed_work(): I use this when I want to
queue a delayed work item with a particular timeout (usually for immediate
processing), but the work item may already be pending.
If try_to_cancel_delayed_work() returns 0 or 1 (not pending or pending but
dequeued) then I can go ahead and just schedule the work item (I'll be holding
a lock to prevent anyone else from interfering).
However, if try_to_cancel_delayed_work() returns -1 then there's no usually no
point attempting to schedule the work item because I know the timer expiry
handler is doing that or going to do that.
The code looks like this in pretty much all cases:
if (try_to_cancel_delayed_work(afs_server_reaper) = 0)
schedule_delayed_work(afs_server_reaper, 0);
Aha, now I see what you mean. However. Why the code above is better then
cancel_delayed_work(afs_server_reaper);
schedule_delayed_work(afs_server_reaper, 0);
? (I assume we already changed cancel_delayed_work() to use del_timer).
If delayed_work_timer_fn() is not running - both variants (let's denote them
as 1 and 2) do the same.
Now suppose that delayed_work_timer_fn() is running.
1: lock_timer_base(), return -1, skip schedule_delayed_work().
2: check timer_pending(), return 0, call schedule_delayed_work(),
return immediately because test_and_set_bit(WORK_STRUCT_PENDING)
fails.
So I still don't think try_to_del_timer_sync() can help in this particular
case.
To some extent, try_to_cancel_delayed_work is
int try_to_cancel_delayed_work(dwork)
{
ret = cancel_delayed_work(dwork);
if (!ret work_pending(dwork-work))
ret = -1;
return ret;
}
iow, work_pending() looks like a more precise indication that work-func()
is going to run soon.
Oleg.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 it's a relatively minor waste of time. However, if the timer
expiry routine gets interrupted then it may not be so minor... So, yes, I'm
in full agreement with you there.
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
cancel_delayed_work().
Aha, now I see what you mean. However. Why the code above is better then
cancel_delayed_work(afs_server_reaper);
schedule_delayed_work(afs_server_reaper, 0);
? (I assume we already changed cancel_delayed_work() to use del_timer).
Because calling schedule_delayed_work() is a waste of CPU if the timer expiry
handler is currently running at this time as *that* is going to also schedule
the delayed work item.
If delayed_work_timer_fn() is not running - both variants (let's denote them
as 1 and 2) do the same.
Yes, but that's not the point.
Now suppose that delayed_work_timer_fn() is running.
1: lock_timer_base(), return -1, skip schedule_delayed_work().
2: check timer_pending(), return 0, call schedule_delayed_work(),
return immediately because test_and_set_bit(WORK_STRUCT_PENDING)
fails.
I don't see what you're illustrating here. Are these meant to be two steps in
a single process? Or are they two alternate steps?
So I still don't think try_to_del_timer_sync() can help in this particular
case.
It permits us to avoid the test_and_set_bit() under some circumstances.
To some extent, try_to_cancel_delayed_work is
int try_to_cancel_delayed_work(dwork)
{
ret = cancel_delayed_work(dwork);
if (!ret work_pending(dwork-work))
ret = -1;
return ret;
}
iow, work_pending() looks like a more precise indication that work-func()
is going to run soon.
Ah, but the timer routine may try to set the work item pending flag *after* the
work_pending() check you have here. Furthermore, it would be better to avoid
the work_pending() check entirely because that check involves interacting with
atomic ops done on other CPUs. try_to_del_timer_sync() returning -1 tells us
without a shadow of a doubt that the work item is either scheduled now or will
be scheduled very shortly, thus allowing us to avoid having to do it ourself.
David
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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
cancel_delayed_work().
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.
Aha, now I see what you mean. However. Why the code above is better then
cancel_delayed_work(afs_server_reaper);
schedule_delayed_work(afs_server_reaper, 0);
? (I assume we already changed cancel_delayed_work() to use del_timer).
Because calling schedule_delayed_work() is a waste of CPU if the timer expiry
handler is currently running at this time as *that* is going to also schedule
the delayed work item.
Yes. But otoh, try_to_del_timer_sync() is a waste of CPU compared to
del_timer(),
when the timer is not pending.
1: lock_timer_base(), return -1, skip schedule_delayed_work().
2: check timer_pending(), return 0, call schedule_delayed_work(),
return immediately because test_and_set_bit(WORK_STRUCT_PENDING)
fails.
I don't see what you're illustrating here. Are these meant to be two steps in
a single process? Or are they two alternate steps?
two alternate steps.
1 means
if (try_to_cancel_delayed_work())
schedule_delayed_work();
2 means
cancel_delayed_work();
schedule_delayed_work();
So I still don't think try_to_del_timer_sync() can help in this particular
case.
It permits us to avoid the test_and_set_bit() under some circumstances.
Yes. But lock_timer_base() is more costly.
To some extent, try_to_cancel_delayed_work is
int try_to_cancel_delayed_work(dwork)
{
ret = cancel_delayed_work(dwork);
if (!ret work_pending(dwork-work))
ret = -1;
return ret;
}
iow, work_pending() looks like a more precise indication that work-func()
is going to run soon.
Ah, but the timer routine may try to set the work item pending flag *after*
the
work_pending() check you have here.
No, delayed_work_timer_fn() doesn't set the _PENDING flag.
Furthermore, it would be better to avoid
the work_pending() check entirely because that check involves interacting with
atomic ops done on other CPUs.
Sure, the implementation of try_to_cancel_delayed_work() above is just for
illustration. I don't think we need try_to_cancel_delayed_work() at all.
try_to_del_timer_sync() returning -1 tells us
without a shadow of a doubt that the work item is either scheduled now or will
be scheduled very shortly, thus allowing us to avoid having to do it ourself.
First, this is very unlikely event, delayed_work_timer_fn() is very fast unless
interrupted.
_PENDING flag won't be cleared until this work is executed by run_workqueue().
In generak, work_pending() after del_timer() is imho better way to avoid the
unneeded schedule_delayed_work().
But again, I can't undertand the win for that particular case.
Oleg.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 the workqueue, otherwise you might get this situation:
CPU 0 CPU 1
=== ===
timer expires
cancel_delayed_work(x) == 0 --delayed_work_timer_fn(x)
kfree(x); --do_IRQ()
y = kmalloc(); // reuses x
--do_IRQ()
__queue_work(x)
--- OOPS ---
That's my main concern. If you are certain that can't happen, then fair
enough.
Note that although you can call cancel_delayed_work() from within a work item
handler, you can't then follow it up with a flush as it's very likely to
deadlock.
Because calling schedule_delayed_work() is a waste of CPU if the timer
expiry handler is currently running at this time as *that* is going to
also schedule the delayed work item.
Yes. But otoh, try_to_del_timer_sync() is a waste of CPU compared to
del_timer(), when the timer is not pending.
I suppose that's true. As previously stated, my main objection to del_timer()
is the fact that it doesn't tell you if the timer expiry function is still
running.
Can you show me a patch illustrating exactly how you want to change
cancel_delayed_work()? I can't remember whether you've done so already, but
if you have, I can't find it. Is it basically this?:
static inline int cancel_delayed_work(struct delayed_work *work)
{
int ret;
- ret = del_timer_sync(work-timer);
+ ret = del_timer(work-timer);
if (ret)
work_release(work-work);
return ret;
}
I was thinking this situation might be a problem:
CPU 0 CPU 1
=== ===
timer expires
cancel_delayed_work(x) == 0 --delayed_work_timer_fn(x)
schedule_delayed_work(x,0) --do_IRQ()
keventd scheduled
x-work()
--do_IRQ()
__queue_work(x)
But it won't, will it?
Ah, but the timer routine may try to set the work item pending flag
*after* the work_pending() check you have here.
No, delayed_work_timer_fn() doesn't set the _PENDING flag.
Good point. I don't think that's a problem because cancel_delayed_work()
won't clear the pending flag if it didn't remove a timer.
First, this is very unlikely event, delayed_work_timer_fn() is very fast
unless interrupted.
Yeah, I guess so.
Okay, you've convinced me, I think - provided you consider the case I
outlinded at the top of this email.
If you give me a patch to alter cancel_delayed_work(), I'll substitute it for
mine and use that that instead. Dave Miller will just have to live with that
patch being there:-)
David
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 cancel_delayed_work() is always
followed by a flush of the workqueue, otherwise you might get this situation:
CPU 0 CPU 1
=== ===
timer expires
cancel_delayed_work(x) == 0 --delayed_work_timer_fn(x)
kfree(x); --do_IRQ()
y = kmalloc(); // reuses x
--do_IRQ()
__queue_work(x)
--- OOPS ---
That's my main concern. If you are certain that can't happen, then fair
enough.
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 cancel_work_sync() to wait on it.
*/
This comment is not very precise though. If the work doesn't re-arm itself,
we need cancel_work_sync() only if cancel_delayed_work() returns 0.
So there is no difference with the proposed change. Except, return value == 0
means:
currently (del_timer_sync): callback may still be running or scheduled
with del_timer: may still be running, or scheduled, or will be scheduled
right now.
However, this is the same from the caller POV.
Can you show me a patch illustrating exactly how you want to change
cancel_delayed_work()? I can't remember whether you've done so already, but
if you have, I can't find it. Is it basically this?:
static inline int cancel_delayed_work(struct delayed_work *work)
{
int ret;
- ret = del_timer_sync(work-timer);
+ ret = del_timer(work-timer);
if (ret)
work_release(work-work);
return ret;
}
Yes, exactly. The patch is trivial, but I need some time to write the
understandable changelog...
I was thinking this situation might be a problem:
CPU 0 CPU 1
=== ===
timer expires
cancel_delayed_work(x) == 0 --delayed_work_timer_fn(x)
schedule_delayed_work(x,0) --do_IRQ()
keventd scheduled
x-work()
--do_IRQ()
__queue_work(x)
But it won't, will it?
Yes, I think this should be OK. schedule_delayed_work() will notice
_PENDING and abort, so the last x-work() doesn't happen.
What can happen is
timer expires
cancel_delayed_work(x) == 0
--delayed_work_timer_fn(x)
__queue_work(x)
keventd scheduled
x-work()
schedule_delayed_work(x,0)
the work is scheduled again
, so we can have an unneeded schedule, but this is very unlikely.
Oleg.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 was started by work-func() (note that __run_timers() clears timer_pending() before calling timer-function). This in turn means that delayed_work_timer_fn() has already called __queue_work(dwork), otherwise work-func() has no chance to run. When del_timer() returns true and delayed_work_timer_fn() doesn't run we are safe, this doesn't differ from del_timer_sync(). Oleg. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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. Should the rest of it go via Andrew's tree then? 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 into the net-2.6.22 tree more difficult. Is it possible for your changes to be purely networking and not need those changes outside of the networking? I guess one of them was just a symbol export which I could add to the net-2.6.22 tree, but weren't there some more involved non-networking bits in there? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 into the net-2.6.22 tree more difficult. 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 don't know about. (2) try_to_cancel_delayed_work(). I suppose I could use cancel_delayed_work() instead, but that's less efficient as it waits for the timer completion function to finish. And one that AFS depends on: (3) Cache the key in nameidata. I still don't have Al's agreement on this, but it's purely caching, so I could drop that patch for the moment and excise the stuff that uses it from my AFS patches if that would help. Do you class the AFS patches as networking changes? Do you want me to consolidate my patches to make things simpler for you? Do you want me to rebase my patches onto net-2.6.22? I have the following patches, in order, available now, though I haven't yet released the last few (they can all be downloaded from my RH people pages): move-skb-generic.diff (you've got this) timers.diff keys.diff af_rxrpc.diff afs-cleanup.diff af_rxrpc-kernel.diff af_rxrpc-afs.diff af_rxrpc-delete-old.diff af_rxrpc-own-workqueues.diff af_rxrpc-fixes.diff afs-callback-wq.diff afs-vlocation.diff afs-multimount.diff afs-rxrpc-key.diff afs-nameidata-key.diff afs-security.diff afs-doc.diff netlink-support-MSG_TRUNC.diff (you've got this) afs-get-capabilities.diff afs-initcallbackstate3.diff afs-dir-write-support.diff David - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 don't know about. (2) try_to_cancel_delayed_work(). I suppose I could use cancel_delayed_work() instead, but that's less efficient as it waits for the timer completion function to finish. There are significant workqueue changes in -mm and I plan to send them in for 2.6.22. I doubt if there's anything in there which directly affects cancel_delayed_work(), but making changes of this nature against 2.6.21 might lead to grief. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 else has put some changes in there that I don't know about. (2) try_to_cancel_delayed_work(). I suppose I could use cancel_delayed_work() instead, but that's less efficient as it waits for the timer completion function to finish. There are significant workqueue changes in -mm and I plan to send them in for 2.6.22. I doubt if there's anything in there which directly affects cancel_delayed_work(), but making changes of this nature against 2.6.21 might lead to grief. I think it is better to use cancel_delayed_work(), but change it to use del_timer(). I belive cancel_delayed_work() doesn't need del_timer_sync(). 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(). Oleg. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Getting the new RxRPC patches upstream
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 unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 don't see any patches in -mm so I was assuming these patches have not been queued up anywhere. As long as these things happen in a reasonably timely manner so I can remove the export of kernel_thread and kill daemonize I really don't care. If you have written them they are quite likely better then my minimal patches which were quite restrained because of my limited ability to test these things. Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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, and I have patches that should do it. We will see what happens. Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 Morton seems to think so. 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. Let me know what the status is of that stuff. Either way, I don't think it should block Eric's work here. If his stuff is more ready first, it should go in and then you have a little bit of patch merging to do that's all. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting the new RxRPC patches upstream
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 patches he posted is ready for merging into
net-2.6.22.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
