Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 20:06:12 John Baldwin wrote:
On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote:
On Friday 05 November 2010 19:48:05 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky hsela...@c2i.net
wrote:
On Friday 05 November 2010 19:39:45 Matthew Fleming wrote:
True, but no taskqueue(9) code can handle that. Only the caller can
prevent a task from becoming enqueued again. The same issue exists
with taskqueue_drain().
I find that strange, because that means if I queue a task again while
it is running, then I doesn't get run? Are you really sure?
If a task is currently running when enqueued, the task struct will be
re-enqueued to the taskqueue. When that task comes up as the head of
the queue, it will be run again.
Right, and the taskqueue_cancel has to cancel in that state to, but it
doesn't because it only checks pending if !running() :-) ??
You can't close that race in taskqueue_cancel(). You have to manage that
race yourself in your task handler. For the callout(9) API we are only
able to close that race if you use callout_init_mtx() so that the code
managing the callout wheel can make use of your lock to resolve the races.
If you use callout_init() you have to explicitly manage these races in your
callout handler.
Hi,
I think you are getting me wrong! In the initial 0001-Implement-
taskqueue_cancel-9-to-cancel-a-task-from-a.patch you have the following code-
chunk:
+int
+taskqueue_cancel(struct taskqueue *queue, struct task *task)
+{
+ int rc;
+
+ TQ_LOCK(queue);
+ if (!task_is_running(queue, task)) {
+ if ((rc = task-ta_pending) 0)
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ } else
+ rc = -EBUSY;
+ TQ_UNLOCK(queue);
+ return (rc);
+}
This code should be written like this, having the if (!task_is_running())
after checking the ta_pending variable.
+int
+taskqueue_cancel(struct taskqueue *queue, struct task *task)
+{
+ int rc;
+
+ TQ_LOCK(queue);
+ if ((rc = task-ta_pending) 0) {
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ }
+ if (!task_is_running(queue, task))
+ rc = -EBUSY;
+ TQ_UNLOCK(queue);
+ return (rc);
+}
Or completely skip the !task_is_running() check. Else you are opening up a
race in this function! Do I need to explain that more? Isn't it obvious?
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libstc++ (?) problem on CURRENT?
I had a problem running the IcedTea java plugin on CURRENT i386, while it works on 8_STABLE. But maybe it's not a problem related to the port. Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. In the part of the code causing the crash, a std::map is read with an iterator in a for loop, and if a condition is met, an entry is erased. The following is the bt I'm getting: #0 0x29e36247 in kill () from /lib/libc.so.7 #1 0x29e361a6 in raise () from /lib/libc.so.7 #2 0x282424f6 in XRE_LockProfileDirectory () from /usr/local/lib/firefox3/libxul.so #3 signal handler called #4 0x29c8f1b2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 #5 0x2ef92402 in IcedTeaPluginUtilities::invalidateInstance () from /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so ... I wrote a patch for the IcedTea plugin, replacing the for loop with a while and increasing the iterator before erasing from the map, and it seems working. Then I wrote a simple program that do something similar to IcedTea, so there is no need to build the whole java/openjdk6 port to do some testing. Running it on 8_STABLE it works, on CURRENT it crashes. You can find more details in this discussion on the freebsd-java ml: http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html You can find the patch and the sample code in the discussion above, anyway I'm reporting them here too: icedtea patch: http://pastebin.com/b2KKFNSG test case: http://pastebin.com/Amk4UJ0g I hope that the crash is not caused by a bad environment, can anyone else test it? Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
* Barbara barbara.xxx1...@libero.it, 20101106 10:57: Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. I am a real STL newbie, so I could be wrong. Maybe it's not allowed to remove an element in the map you're currently iterating. Therefore you're accessing memory which has been deallocated. This may crash on HEAD and not on 8-STABLE for various reasons. For example, malloc() in HEAD has all sorts of debugging options enabled, while 8-STABLE does not. Greetings, -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpVzkBGkeJh8.pgp Description: PGP signature
R: Re: libstc++ (?) problem on CURRENT?
* Barbara barbara.xxx1...@libero.it, 20101106 10:57: Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. I am a real STL newbie, so I could be wrong. Maybe it's not allowed to remove an element in the map you're currently iterating. Therefore you're accessing memory which has been deallocated. I'm sure you're not worse than me! :) Anyway that's what I was thinking when I wrote the patch. This may crash on HEAD and not on 8-STABLE for various reasons. For example, malloc() in HEAD has all sorts of debugging options enabled, while 8-STABLE does not. So you think that the problem is really in the original source code, but exposed only on CURRENT. That could be an option. Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu d...@dudu.ro wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
Or, better yet: cars.erase(punto); I see no reason in iterating
through the whole map unless you want to relate the deletion to the
matched type, in which case you should use the previous example.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
Yes, I believe CURRENT's malloc zeroes out the memory upon deletion,
whereas STABLE doesn't. So in STABLE you get an old copy of the
invalidated iterator, hence it works.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:32 AM, Vlad Galu d...@dudu.ro wrote:
On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu d...@dudu.ro wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
Or, better yet: cars.erase(punto); I see no reason in iterating
through the whole map unless you want to relate the deletion to the
matched type, in which case you should use the previous example.
Sorry, I meant mapped type.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting on
CURRENT, considering also that AFAIK the gcc version in both the base systems
is the same.
In the part of the code causing the crash, a std::map is read with an iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a while
and increasing the iterator before erasing from the map, and it seems working.
Then I wrote a simple program that do something similar to IcedTea, so there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R: Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's
segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above,
anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch
so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
Yes, I believe CURRENT's malloc zeroes out the memory upon deletion,
whereas STABLE doesn't. So in STABLE you get an old copy of the
invalidated iterator, hence it works.
Very nice explanation.
Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:44 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's
segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above,
anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch
so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
Yes, I believe CURRENT's malloc zeroes out the memory upon deletion,
whereas STABLE doesn't. So in STABLE you get an old copy of the
invalidated iterator, hence it works.
Very nice explanation.
Thanks
I hope I'm right, I don't have CURRENT installed, it's just an
assumption. However, the C++ code is most definitely buggy.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Sat, Nov 6, 2010 at 1:37 AM, Hans Petter Selasky hsela...@c2i.net wrote:
On Friday 05 November 2010 20:06:12 John Baldwin wrote:
On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote:
On Friday 05 November 2010 19:48:05 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky hsela...@c2i.net
wrote:
On Friday 05 November 2010 19:39:45 Matthew Fleming wrote:
True, but no taskqueue(9) code can handle that. Only the caller can
prevent a task from becoming enqueued again. The same issue exists
with taskqueue_drain().
I find that strange, because that means if I queue a task again while
it is running, then I doesn't get run? Are you really sure?
If a task is currently running when enqueued, the task struct will be
re-enqueued to the taskqueue. When that task comes up as the head of
the queue, it will be run again.
Right, and the taskqueue_cancel has to cancel in that state to, but it
doesn't because it only checks pending if !running() :-) ??
You can't close that race in taskqueue_cancel(). You have to manage that
race yourself in your task handler. For the callout(9) API we are only
able to close that race if you use callout_init_mtx() so that the code
managing the callout wheel can make use of your lock to resolve the races.
If you use callout_init() you have to explicitly manage these races in your
callout handler.
Hi,
I think you are getting me wrong! In the initial 0001-Implement-
taskqueue_cancel-9-to-cancel-a-task-from-a.patch you have the following code-
chunk:
+int
+taskqueue_cancel(struct taskqueue *queue, struct task *task)
+{
+ int rc;
+
+ TQ_LOCK(queue);
+ if (!task_is_running(queue, task)) {
+ if ((rc = task-ta_pending) 0)
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ } else
+ rc = -EBUSY;
+ TQ_UNLOCK(queue);
+ return (rc);
+}
This code should be written like this, having the if (!task_is_running())
after checking the ta_pending variable.
+int
+taskqueue_cancel(struct taskqueue *queue, struct task *task)
+{
+ int rc;
+
+ TQ_LOCK(queue);
+ if ((rc = task-ta_pending) 0) {
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ }
+ if (!task_is_running(queue, task))
+ rc = -EBUSY;
+ TQ_UNLOCK(queue);
+ return (rc);
+}
Or completely skip the !task_is_running() check. Else you are opening up a
race in this function! Do I need to explain that more? Isn't it obvious?
I think you're misunderstanding the existing taskqueue(9) implementation.
As long as TQ_LOCK is held, the state of ta-ta_pending cannot change,
nor can the set of running tasks. So the order of checks is
irrelevant.
As John said, the taskqueue(9) implementation cannot protect consumers
of it from re-queueing a task; that kind of serialization needs to
happen at a higher level.
taskqueue(9) is not quite like callout(9); the taskqueue(9)
implementation drops all locks before calling the task's callback
function. So once the task is running, taskqueue(9) can do nothing
about it until the task stops running. This is why Jeff's
implementation of taskqueue_cancel(9) slept if the task was running,
and why mine returns an error code. The only way to know for sure
that a task is about to run is to ask taskqueue(9), because there's
a window where the TQ_LOCK is dropped before the callback is entered.
Thanks,
matthew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
Hi,
On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote:
I think you're misunderstanding the existing taskqueue(9) implementation.
As long as TQ_LOCK is held, the state of ta-ta_pending cannot change,
nor can the set of running tasks. So the order of checks is
irrelevant.
I agree that the order of checks is not important. That is not the problem.
Cut paste from suggested taskqueue patch from Fleming:
+int
+taskqueue_cancel(struct taskqueue *queue, struct task *task)
+{
+ int rc;
+
+ TQ_LOCK(queue);
+ if (!task_is_running(queue, task)) {
+ if ((rc = task-ta_pending) 0)
+ STAILQ_REMOVE(queue-tq_queue, task, task,
ta_link); + task-ta_pending = 0;
+ } else {
+ rc = -EBUSY;
What happens in this case if ta_pending 0. Are you saying this is not
possible? If ta_pending 0, shouldn't we also do a STAILQ_REMOVE() ?
+ }
+ TQ_UNLOCK(queue);
+ return (rc);
+}
As John said, the taskqueue(9) implementation cannot protect consumers
of it from re-queueing a task; that kind of serialization needs to
happen at a higher level.
Agreed, but that is not what I'm pointing at. I'm pointing at what happens if
you re-queue a task and then cancel while it is actually running. Will the
task still be queued for execution after taskqueue_cancel()?
taskqueue(9) is not quite like callout(9); the taskqueue(9)
implementation drops all locks before calling the task's callback
function. So once the task is running, taskqueue(9) can do nothing
about it until the task stops running.
This is not the problem.
This is why Jeff's
implementation of taskqueue_cancel(9) slept if the task was running,
and why mine returns an error code. The only way to know for sure
that a task is about to run is to ask taskqueue(9), because there's
a window where the TQ_LOCK is dropped before the callback is entered.
And if you re-queue and cancel in this window, shouldn't this also be handled
like in the other cases?
Cut paste from kern/subr_taskqueue.c:
task-ta_pending = 0;
tb.tb_running = task;
TQ_UNLOCK(queue);
If a concurrent thread at exactly this point in time calls taskqueue_enqueue()
on this task, then we re-add the task to the queue-tq_queue. So far we
agree. Imagine now that for some reason a following call to taskqueue_cancel()
on this task at same point in time. Now, shouldn't taskqueue_cancel() also
remove the task from the queue-tq_queue in this case aswell? Because in
your implementation you only remove the task if we are not running, and that
is not true when we are at exactly this point in time.
task-ta_func(task-ta_context, pending);
TQ_LOCK(queue);
tb.tb_running = NULL;
wakeup(task);
Another issue I noticed is that the ta_pending counter should have a wrap
protector.
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: laptop Acer Aspire One D250 / snd_hda(4) internal mic not recording
El día Friday, November 05, 2010 a las 01:13:15AM +0200, Alexander Motin escribió: # mixer -f /dev/mixer1 Mixer rec is currently set to 100:100 Mixer monitor is currently set to 100:100 Recording source: monitor That's strange. I would expect it working. Would you be so kind and give me the lines for reconfigure CODEC using hints? I'm really lost in this. OK, try this: hint.hdac.0.cad0.nid18.config=as=2 seq=1 I've tried this and a lot of other hint.hdac for which I now have some kind of understanding... all with no luck; it is only recording noice (not silense, but noise). I think there is something wrong either with the hardware or something in the driver, because searching in Google for acer aspire one mic I found a lot of complaints about the internal mic not working, for example in Ubuntu it needs some special tweaking: http://ubuntuforums.org/showthread.php?t=952568 https://help.ubuntu.com/community/AspireOneAOD250 (the last one speaks about some alsa driver) What do you think about? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: man(1) no longer understands manpages like .so man3/printf.3
On Fri, Nov 5, 2010 at 8:57 AM, Anonymous swel...@gmail.com wrote:
A few examples from ports tree
devel/automake111: automake-1.11(1)
devel/gettext: dcgettext(3), dcngettext(3), dgettext(3), dngettext(3)
devel/nasm: rdf2com(1), rdf2ihx(1), rdf2ith(1), rdf2srec(1)
textproc/gnugrep: egrep(1), fgrep(1)
www/neon29: ne_get_{request,session}_flag(3), ne_set_connect_timeout(3)
x11/libX11: BlackPixel(3), XArc(3), etc
x11/libXext: XShmAttach(3), XmbufDisplayBuffers(3), etc
[+ more x11 libs]
Thanks for the report. I'll look into adding the feature.
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
siftr LOR: PFil hook read/write mutex vs. tcp
1st 0x80990308 PFil read/write mutex (PFil hook read/write mutex @ /usr/src/head/sys/net/pfil.c:77 2nd 0x80991528 tcp (tcp) @ /usr/src/head/sys/modules/siftr/../../netinet/siftr.c:702 KDB: stack backtrace: db_trace_self_wrapper() kdb_backtrace() _witness_debugger() witness_checkorder() _rw_rlock() siftr_chkpkt() pfil_run_hooks() ip_input() netisr_dispatch_src() ether_demux() ether_input() msk_handle_events() msk_intr() intr_event_execute_handlers() ithread_loop() fork_exit() fork_trampoline() --- trap 0, rip = 0, rsp = 0xff8123559cf0, rbp = 0 --- -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: invalid PDPE on recend amd64
Hi, I got a similar panic on amd64. Looking into the source it hit KASSERT((base (len - 1))) in pmap_demote_DMAP(). I replaced it with a printf to see what triggered the assertion and here is the output. Combined with memcontrol output 'bogus' keyword it seems buggy BIOS violated some kind of spec and caused this. Is it fatal? It looks fine on my machine without the assertion. ---8--boot message -8 mem: memory base 0xfffdc000 len 0x0002 base 0xc000 len 0x4000 base 0x len 0x8000 base 0x8000 len 0x4000 base 0xbff0 len 0x0010 base 0x0001 len 0x4000 null: null device, zero device ---8--memcontrol output -8 r...@jsli-nb:~ # memcontrol list 0x0/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x1/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x2/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x3/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x4/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x5/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x6/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x7/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x84000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x88000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x94000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x98000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0xa/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xac000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xca000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xce000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcf000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xda000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdc000/0x1000 BIOS
Ctrl-alt-delete in syscons pause/scrollback mode breaks system
Today I came back to my computer and realised I'd left ttyv0 in history/scrollback mode, with scroll-lock enabled. To see what would happen I pressed Ctrl-Alt-Delete to reboot and was surprised to see that it seemed to get partway through the process but it never rebooted: the other ttys were killed and I could still break into the debugger but otherwise the system was unresponsive. Trying to repeat it after rebooting I ended up with a system that won't even break into the debugger. Is this expected? -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ctrl-alt-delete in syscons pause/scrollback mode breaks system
On 11/6/10, Bruce Cran br...@cran.org.uk wrote: Today I came back to my computer and realised I'd left ttyv0 in history/scrollback mode, with scroll-lock enabled. To see what would happen I pressed Ctrl-Alt-Delete to reboot and was surprised to see that it seemed to get partway through the process but it never rebooted: the other ttys were killed and I could still break into the debugger but otherwise the system was unresponsive. Trying to repeat it after rebooting I ended up with a system that won't even break into the debugger. Is this expected? Last issue, was reported my me long ago and only workaround was commited, which actually did not solved problem for me. I'm still looking forward for complete syscons rewrite. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: invalid PDPE on recend amd64
On 11/6/10, Jia-Shiun Li jiash...@gmail.com wrote: Hi, I got a similar panic on amd64. Looking into the source it hit KASSERT((base (len - 1))) in pmap_demote_DMAP(). I replaced it with a printf to see what triggered the assertion and here is the output. Combined with memcontrol output 'bogus' keyword it seems buggy BIOS violated some kind of spec and caused this. Is it fatal? It looks fine on my machine without the assertion. Send uname output. The fix for this issue got commited few days ago. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: invalid PDPE on recend amd64
Paul B Mahol wrote:
On 11/6/10, Jia-Shiun Li jiash...@gmail.com wrote:
Hi,
I got a similar panic on amd64. Looking into the source it hit
KASSERT((base (len - 1))) in pmap_demote_DMAP(). I replaced it with
a printf to see what triggered the assertion and here is the output.
Combined with memcontrol output 'bogus' keyword it seems buggy BIOS
violated some kind of spec and caused this. Is it fatal? It looks fine
on my machine without the assertion.
Send uname output. The fix for this issue got commited few days ago.
This is a different type of BIOS misconfiguration than your machine had.
I'm attaching a possible patch for this one.
Regards,
Alan
Index: amd64/amd64/amd64_mem.c
===
--- amd64/amd64/amd64_mem.c (revision 214679)
+++ amd64/amd64/amd64_mem.c (working copy)
@@ -583,7 +583,7 @@ amd64_mrset(struct mem_range_softc *sc, struct mem
i = (sc-mr_cap MR686_FIXMTRR) ? MTRR_N64K + MTRR_N16K + MTRR_N4K : 0;
mrd = sc-mr_desc + i;
for (; i sc-mr_ndesc; i++, mrd++) {
- if (mrd-mr_flags MDF_ACTIVE)
+ if ((mrd-mr_flags (MDF_ACTIVE | MDF_BOGUS)) == MDF_ACTIVE)
pmap_demote_DMAP(mrd-mr_base, mrd-mr_len, FALSE);
}
@@ -688,7 +688,7 @@ amd64_mrinit(struct mem_range_softc *sc)
i = (sc-mr_cap MR686_FIXMTRR) ? MTRR_N64K + MTRR_N16K + MTRR_N4K : 0;
mrd = sc-mr_desc + i;
for (; i sc-mr_ndesc; i++, mrd++) {
- if (mrd-mr_flags MDF_ACTIVE)
+ if ((mrd-mr_flags (MDF_ACTIVE | MDF_BOGUS)) == MDF_ACTIVE)
pmap_demote_DMAP(mrd-mr_base, mrd-mr_len, TRUE);
}
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky hsela...@c2i.net wrote:
Hi,
On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote:
I think you're misunderstanding the existing taskqueue(9) implementation.
As long as TQ_LOCK is held, the state of ta-ta_pending cannot change,
nor can the set of running tasks. So the order of checks is
irrelevant.
I agree that the order of checks is not important. That is not the problem.
Cut paste from suggested taskqueue patch from Fleming:
+int
+taskqueue_cancel(struct taskqueue *queue, struct task *task)
+{
+ int rc;
+
+ TQ_LOCK(queue);
+ if (!task_is_running(queue, task)) {
+ if ((rc = task-ta_pending) 0)
+ STAILQ_REMOVE(queue-tq_queue, task, task,
ta_link); + task-ta_pending = 0;
+ } else {
+ rc = -EBUSY;
What happens in this case if ta_pending 0. Are you saying this is not
possible? If ta_pending 0, shouldn't we also do a STAILQ_REMOVE() ?
Ah! I see what you mean.
I'm not quite sure what the best thing to do here is; I agree it would
be nice if taskqueue_cancel(9) dequeued the task, but I believe it
also needs to indicate that the task is currently running. I guess
the best thing would be to return the old pending count by reference
parameter, and 0 or EBUSY to also indicate if there is a task
currently running.
Adding jhb@ to this mail since he has good thoughts on interfacing.
Thanks,
matthew
+ }
+ TQ_UNLOCK(queue);
+ return (rc);
+}
As John said, the taskqueue(9) implementation cannot protect consumers
of it from re-queueing a task; that kind of serialization needs to
happen at a higher level.
Agreed, but that is not what I'm pointing at. I'm pointing at what happens if
you re-queue a task and then cancel while it is actually running. Will the
task still be queued for execution after taskqueue_cancel()?
taskqueue(9) is not quite like callout(9); the taskqueue(9)
implementation drops all locks before calling the task's callback
function. So once the task is running, taskqueue(9) can do nothing
about it until the task stops running.
This is not the problem.
This is why Jeff's
implementation of taskqueue_cancel(9) slept if the task was running,
and why mine returns an error code. The only way to know for sure
that a task is about to run is to ask taskqueue(9), because there's
a window where the TQ_LOCK is dropped before the callback is entered.
And if you re-queue and cancel in this window, shouldn't this also be handled
like in the other cases?
Cut paste from kern/subr_taskqueue.c:
task-ta_pending = 0;
tb.tb_running = task;
TQ_UNLOCK(queue);
If a concurrent thread at exactly this point in time calls taskqueue_enqueue()
on this task, then we re-add the task to the queue-tq_queue. So far we
agree. Imagine now that for some reason a following call to taskqueue_cancel()
on this task at same point in time. Now, shouldn't taskqueue_cancel() also
remove the task from the queue-tq_queue in this case aswell? Because in
your implementation you only remove the task if we are not running, and that
is not true when we are at exactly this point in time.
task-ta_func(task-ta_context, pending);
TQ_LOCK(queue);
tb.tb_running = NULL;
wakeup(task);
Another issue I noticed is that the ta_pending counter should have a wrap
protector.
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: siftr LOR: PFil hook read/write mutex vs. tcp
On 6 November 2010 20:27, Bruce Cran br...@cran.org.uk wrote: 1st 0x80990308 PFil read/write mutex (PFil hook read/write mutex @ /usr/src/head/sys/net/pfil.c:77 2nd 0x80991528 tcp (tcp) @ /usr/src/head/sys/modules/siftr/../../netinet/siftr.c:702 KDB: stack backtrace: db_trace_self_wrapper() kdb_backtrace() _witness_debugger() witness_checkorder() _rw_rlock() siftr_chkpkt() pfil_run_hooks() ip_input() netisr_dispatch_src() ether_demux() ether_input() msk_handle_events() msk_intr() intr_event_execute_handlers() ithread_loop() fork_exit() fork_trampoline() --- trap 0, rip = 0, rsp = 0xff8123559cf0, rbp = 0 --- AFAIK, this LOR is documented in siftr(4) as harmless. -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 05, 2010 at 07:30:38PM +0100, Hans Petter Selasky wrote: Hi, In the patch attached to this e-mail I included Matthew Fleming's patch aswell. 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles the words of the callout and USB API's terminology for doing the same. 2) I turns out I need to have code in subr_taskqueue.c to be able to make the operations atomic. 3) I did not update the manpage in this patch. Will do that before a commit. 4) My patch implements separate state keeping in struct task_pair, which avoids having to change any KPI's for now, like suggested by John Baldwin I think. 5) In my implementation I hard-coded the priority argument to zero, so that enqueuing is fast. Comments are welcome! The patch looks almost you moved usb_process.c code into taskqueue(9) that I means it still follows that a entry which enqueued at last should be executed at last. It seems that at least it's not a general for taskqueue(9). In my humble opinion it looks a trick. I think it'd better to find a general solution to solve it though I used sx(9) lock in my patches. regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
