On Mon, Feb 19, 2007 at 08:11:59AM +0100, Jarek Poplawski wrote:
> On Sun, Feb 18, 2007 at 10:27:19PM -0800, Ben Greear wrote:
..
> > You are also changing the semantics of ASSERT_RTNL (assert *this thread*
> > has rtnl, from the
> > old behaviour: assert *some thread* has rtnl). It may be bette
On Mon, Feb 19, 2007 at 07:55:48AM +0100, Jarek Poplawski wrote:
...
> So to use this we only need such changes:
>
> ... some_delayed_work_func(...)
> {
> ...
> - rtnl_lock();
> + rtnl_lock_work();
> ...
> - rtnl_unlock();
> + rtnl_unlock_work();
> }
>
> ... some_d
On Sun, Feb 18, 2007 at 10:27:19PM -0800, Ben Greear wrote:
> Jarek Poplawski wrote:
> >On Fri, Feb 16, 2007 at 11:04:02AM -0800, Ben Greear wrote:
> >
> >>Stephen Hemminger wrote:
> >>
> >>>On Thu, 15 Feb 2007 23:40:32 -0800
> >>>Ben Greear <[EMAIL PROTECTED]> wrote:
> >>>
> Maybe
On Fri, Feb 16, 2007 at 11:04:02AM -0800, Ben Greear wrote:
> Stephen Hemminger wrote:
> >On Thu, 15 Feb 2007 23:40:32 -0800
> >Ben Greear <[EMAIL PROTECTED]> wrote:
>
> >>Maybe there should be something like an ASSERT_NOT_RTNL() in the
> >>flush_scheduled_work()
> >>method? If it's performance
Jarek Poplawski wrote:
On Fri, Feb 16, 2007 at 11:04:02AM -0800, Ben Greear wrote:
Stephen Hemminger wrote:
On Thu, 15 Feb 2007 23:40:32 -0800
Ben Greear <[EMAIL PROTECTED]> wrote:
Maybe there should be something like an ASSERT_NOT_RTNL() in the
flush_scheduled_work()
method? I
On Fri, Feb 16, 2007 at 11:04:02AM -0800, Ben Greear wrote:
> Stephen Hemminger wrote:
> >On Thu, 15 Feb 2007 23:40:32 -0800
> >Ben Greear <[EMAIL PROTECTED]> wrote:
>
> >>Maybe there should be something like an ASSERT_NOT_RTNL() in the
> >>flush_scheduled_work()
> >>method? If it's performance
On Sun, Feb 18, 2007 at 03:52:05PM -0700, Eric W. Biederman wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > On Sun, Feb 18, 2007 at 08:55:20AM -0700, Eric W. Biederman wrote:
> >> User space is allowed to rename network devices to anything any name
> >> not currently taken by another network de
Hello!
I've seen the thread "sky2 problems on Intel Mac Mini" on this list and
subscribed to continue the discussion :)
I'm getting absolutely same problems as reported by Chris Lightfoot
here: http://www.mail-archive.com/netdev@vger.kernel.org/msg30466.html
I'm running Fedora Core 6, stock kern
Greg KH <[EMAIL PROTECTED]> writes:
> On Sun, Feb 18, 2007 at 08:55:20AM -0700, Eric W. Biederman wrote:
>> User space is allowed to rename network devices to anything any name
>> not currently taken by another network device.
>>
>> However when I now do something like:
>>
>> ip link set eth0 na
On 2/18/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
... Much less vulnerable to cache eviction DDoS
than a hash, because the hot connections get rotated up into non-leaf
layers and get traversed enough to keep them in the LRU set.
Let me enlarge on this a bit. I used to work for a compa
A better data structure for RCU, even with a fixed key space, is
probably a splay tree. Much less vulnerable to cache eviction DDoS
than a hash, because the hot connections get rotated up into non-leaf
layers and get traversed enough to keep them in the LRU set. But I am
not a data structures gu
Daniel Drake wrote:
From: Ulrich Kunitz <[EMAIL PROTECTED]>
Michael Buesch commented that GFP_NOFS should not be used in a
network driver. This patch implements it for zd1211rw-d80211.
Forgot to update the description. As you might have figured, this
version of the patch is for wireless-2.6,
From: Ulrich Kunitz <[EMAIL PROTECTED]>
Michael Buesch commented that GFP_NOFS should not be used in a
network driver. This patch implements it for zd1211rw-d80211.
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
zd_chip.c |4 ++--
zd_usb.
Evgeniy Polyakov a e'crit :
On Sun, Feb 18, 2007 at 07:46:22PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
Why anyone do not want to use trie - for socket-like loads it has
exactly constant search/insert/delete time and scales as hell.
Because we want to be *very* fast. You cannot beat has
On Sun, Feb 18, 2007 at 08:55:20AM -0700, Eric W. Biederman wrote:
>
> I believe the culprit is 43cb76d91ee85f579a69d42bc8efc08bac560278.
>
> For some reason network devices are now showing up under the pci
> device tree, in directories that have something other than network
> devices.
>
> # ls
On Sun, Feb 18, 2007 at 07:46:22PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> >Why anyone do not want to use trie - for socket-like loads it has
> >exactly constant search/insert/delete time and scales as hell.
> >
>
> Because we want to be *very* fast. You cannot beat hash table.
>
> Say
Evgeniy Polyakov a e'crit :
On Mon, Feb 05, 2007 at 10:02:53AM -0800, [EMAIL PROTECTED] ([EMAIL PROTECTED])
wrote:
On Sat, 4 Feb 2007 [EMAIL PROTECTED] wrote:
I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving
I believe the culprit is 43cb76d91ee85f579a69d42bc8efc08bac560278.
For some reason network devices are now showing up under the pci
device tree, in directories that have something other than network
devices.
# ls -l /sys/class/net/eth0
lrwxrwxrwx 1 root root 0 Feb 17 23:19 /sys/class/net/eth0 ->
18 matches
Mail list logo
