* Re: [patch 5/7] bluetooth: blacklist another Broadcom BCM2035 device
From: Marcel Holtmann @ 2008-02-05 16:51 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, andy
In-Reply-To: <20080205.031025.171453745.davem@davemloft.net>
Hi David,
> > From: Andy Shevchenko <andy@smile.org.ua>
> >
> > This device is recognized as bluetooth, but still not works.
> >
> > Signed-off-by: Andy Shevchenko <andy@smile.org.ua>
> > Cc: Marcel Holtmann <marcel@holtmann.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> Applied.
>
> But, what driver should drive this device?
the hci_usb will driver this device, but since it is Broadcom based it
needs some extra quirks to work accordingly.
Regards
Marcel
^ permalink raw reply
* Re: [patch 6/7] hci_ldisc: fix null pointer deref
From: Marcel Holtmann @ 2008-02-05 16:51 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, david, alan, arjan
In-Reply-To: <20080205.031129.40584551.davem@davemloft.net>
Hi David,
> > akpm:
> >
> > No idea. trollmerge.
> >
> > Cc: Arjan van de Ven <arjan@linux.intel.com>
> > Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > Cc: Marcel Holtmann <marcel@holtmann.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> I'll let Marcel and/or Alan take a look at this one.
we might have to re-work the whole hci_uart driver at some point, but
for now I think this fix is feasible.
Alan, if you think it is wrong please step up. I am not an expert when
it comes to TTY line disciplines.
Regards
Marcel
^ permalink raw reply
* Re: Still oopsing in nf_nat_move_storage()
From: Thomas Woerner @ 2008-02-05 16:26 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Chuck Ebbert, Netdev, Netfilter Development Mailinglist
In-Reply-To: <47A44DA9.20907@trash.net>
Patrick McHardy wrote:
> Chuck Ebbert wrote:
>> On 01/31/2008 01:03 PM, Chuck Ebbert wrote:
>>> On 01/29/2008 12:18 PM, Patrick McHardy wrote:
>>>> Chuck Ebbert wrote:
>>>>> nf_nat_move_storage():
>>>>> /usr/src/debug/kernel-2.6.23/linux-2.6.23.i686/net/ipv4/netfilter/nf_nat_core.c:612
>>>>>
>>>>>
>>>>> 87: f7 47 64 80 01 00 00 testl $0x180,0x64(%edi)
>>>>> 8e: 74 39 je c9
>>>>> <nf_nat_move_storage+0x65>
>>>>>
>>>>> line 612:
>>>>> if (!(ct->status & IPS_NAT_DONE_MASK))
>>>>> return;
>>>>>
>>>>> ct is NULL
>>>> The current kernel (and 2.6.23-stable) have:
>>>>
>>>> if (!ct || !(ct->status & IPS_NAT_DONE_MASK))
>>>> return;
>>>>
>>>> so it seems you're using an old version.
>>
>> So, it is now oopsing after the test for NULL and only x86_64 is
>> catching the invalid address because it is non-canonical. Checking
>> for NULL is obviously not enough...
>
>
> Could you try whether this patch fixes it please?
>
Hallo Patrick,
I have tested the patch and the problem seems to be fixed.
Thanks,
Thomas
--
Thomas Woerner
Software Engineer Phone: +49-711-96437-0
Red Hat GmbH Fax : +49-711-96437-111
Hauptstaetterstr. 58 Email: Thomas Woerner <twoerner@redhat.com>
D-70178 Stuttgart Web : http://www.redhat.de/
^ permalink raw reply
* Re: [PATCH] vlan tag match
From: Stephen Hemminger @ 2008-02-05 16:21 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, netdev
In-Reply-To: <47A871FF.5000406@trash.net>
On Tue, 05 Feb 2008 15:26:07 +0100
Patrick McHardy <kaber@trash.net> wrote:
> David Miller wrote:
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Thu, 31 Jan 2008 21:50:25 -0800
> >
> >> On Fri, 01 Feb 2008 06:34:34 +0100
> >> Patrick McHardy <kaber@trash.net> wrote:
> >>
> >>> Stephen Hemminger wrote:
> >>>> Provide a way to use tc filters on vlan tag even if tag is buried in
> >>>> skb due to hardware acceleration.
> >>> Looks reasonable. Would you like to add the same feature to the
> >>> flow classifier?
> >> Yes, that would be good.
> >
> > Did that patch get posted? I didn't see it.
>
>
> No, but I already added it myself. I'll post it in a new thread.
>
> BTW, Stephen, I noticed your ematch patch doesn't mask out the
> VLAN priority which is also included in the return value of
> vlan_get_tag(), is that intentional?
>
It seemed easier than adding two different tag related matches,
since meta match can do expressions.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Alan Cox @ 2008-02-05 16:14 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andi Kleen, Glenn Griffin, netdev, linux-kernel
In-Reply-To: <20080205164837.GC23145@one.firstfloor.org>
> What kind of LISTEN ports? And does it matter if they're DoS'ed?
I guess that depends on the opinion of the owner
- Push based mobile services
- Email delivery
- VoIP
- Management ports
- Peer to peer data transfer
- Instant messaging direct user/user connections
Some of that can also be hardened using IP filter rules
> > Is the other stuff enough - good question, and can be measured easily
> > enough on a little dlink router or similar.
>
> My guess would be that it is.
Alan
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Andi Kleen @ 2008-02-05 16:48 UTC (permalink / raw)
To: Alan Cox; +Cc: Andi Kleen, Glenn Griffin, netdev, linux-kernel
In-Reply-To: <20080205160301.7b2369ee@core>
On Tue, Feb 05, 2008 at 04:03:01PM +0000, Alan Cox wrote:
> > Also your sub PC class appliances rarely run LISTEN servers anyways
> > that are open to the world.
>
> Really. The ones that first come to mind often have exposed ports
> including PDA devices and phones. (Ditto low end PC boxes - portscan an
> EEPC some day ;))
What kind of LISTEN ports? And does it matter if they're DoS'ed?
The only one I can think of right now would be ident and frankly nobody
will really care if that one works or not.
If it's just the management interface etc. (which should really be firewalled)
then likely not.
> Is the other stuff enough - good question, and can be measured easily
> enough on a little dlink router or similar.
My guess would be that it is.
If it's not it would be probably better to look at improving the standard queue
management again; e.g.readd RED.
-Andi
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Alan Cox @ 2008-02-05 16:03 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andi Kleen, Glenn Griffin, netdev, linux-kernel
In-Reply-To: <20080205163912.GB23145@one.firstfloor.org>
> Also your sub PC class appliances rarely run LISTEN servers anyways
> that are open to the world.
Really. The ones that first come to mind often have exposed ports
including PDA devices and phones. (Ditto low end PC boxes - portscan an
EEPC some day ;))
Is the other stuff enough - good question, and can be measured easily
enough on a little dlink router or similar.
Alan
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Andi Kleen @ 2008-02-05 16:39 UTC (permalink / raw)
To: Alan Cox; +Cc: Andi Kleen, Glenn Griffin, netdev, linux-kernel
In-Reply-To: <20080205154213.059ac6e8@core>
On Tue, Feb 05, 2008 at 03:42:13PM +0000, Alan Cox wrote:
> > Syncookies are discouraged these days. They disable too many
> > valuable TCP features (window scaling, SACK) and even without them
> > the kernel is usually strong enough to defend against syn floods
> > and systems have much more memory than they used to be.
>
> Somewhat untrue. Network speeds have risen dramatically, the number of
With strong I meant Linux has much better algorithms to handle the standard
syn queue (syncookies was originally added when it had only dumb head drop)
and there are minisocks which also require significantly less overhead
to manage than full sockets (less memory etc.)
When I wrote syncookies originally that all was not true.
> appliances running Linux that are not PC class means memory has fallen
> not risen and CPU has been pretty level.
>
> > So I don't think it makes much sense to add more code to it, sorry.
>
> I think it makes a lot of sense
I have my doubts. It would be probably better to recheck everything
and then remove syncookies.
Also your sub PC class appliances rarely run LISTEN servers anyways
that are open to the world.
-Andi
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Alan Cox @ 2008-02-05 15:42 UTC (permalink / raw)
To: Andi Kleen; +Cc: Glenn Griffin, netdev, linux-kernel, Andi Kleen
In-Reply-To: <20080205155558.GA23145@one.firstfloor.org>
> Syncookies are discouraged these days. They disable too many
> valuable TCP features (window scaling, SACK) and even without them
> the kernel is usually strong enough to defend against syn floods
> and systems have much more memory than they used to be.
Somewhat untrue. Network speeds have risen dramatically, the number of
appliances running Linux that are not PC class means memory has fallen
not risen and CPU has been pretty level.
> So I don't think it makes much sense to add more code to it, sorry.
I think it makes a lot of sense - providing it defaults off for the PC
world where as you say its use is limited.
Alan
^ permalink raw reply
* Re: netatalk slow after system upgrade (possibly kernel problem?)
From: Michael Monnerie @ 2008-02-05 15:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, netatalk-admins, linux-kernel
In-Reply-To: <20080126220051.d753266b.akpm@linux-foundation.org>
[-- Attachment #1.1: Type: text/plain, Size: 3792 bytes --]
(I let full quote here for reference, my text is on the bottom)
On Sonntag, 27. Januar 2008 Andrew Morton wrote:
> (cc netdev)
>
> > On Fri, 25 Jan 2008 12:55:42 +0100 Michael Monnerie
> > <michael.monnerie@it-management.at> wrote: Dear lists,
> >
> > I've been spending a LOT of time trying to find out where's the
> > problem, but can't find it and therefore seek urgent help now. We
> > have the following system:
> >
> > Server with VMware server
> > -> VM running a webserver and netatalk
> > -> 2 other VMs not related
> >
> > The VM with netatalk was SUSE 10.0 with kernel 2.6.13-15.15-smp
> > (from SUSE), and things were pretty fun and quick. Then we upgraded
> > to SUSE 10.2 and now 10.3, where everything EXCEPT netatalk runs
> > perfect. Since this upgrade, Apple clients (MacOS X) now do READ
> > very very slowly (about 512KB/s over the gigabit LAN), while
> > writing to the server still is normal (>20MB/s). I've even retried
> > with the newest kernel 2.6.23.13, tried different
> > /proc/sys/net/ipv4/tcp_congestion_control (cubic, reno, bic, etc.)
> > and nothing helps. I've then tried to install Samba and found that
> > we have similar problems reading with it from MacOS clients. Now
> > I'm pretty sure it should be something with the linux kernel, but I
> > don't understand what.
> >
> > Here are the wireshark dumps in pcap format:
> > http://zmi.at/x/atalk-write-fast.pcap
> > -> you can see writing to the server (192.168.120.9) is normal and
> > fast
> >
> > http://zmi.at/x/atalk-read-slow.pcap
> > -> reading is horribly slow. Lots of "unknown", because of netatalk
> > or what?
> >
> > http://zmi.at/x/unknown-atalk.pcap
> > -> another dump while reading, you see "unknown" reads. I'm not
> > sure if it's just wireshark not understanding the packets or
> > netatalk.
> >
> > And trying with samba:
> > http://zmi.at/x/smb-read-slow.pcap
> > http://zmi.at/x/smb-write-quick.pcap
> > you can see that it's also slow.
> >
> > Now why did it work with the old 2.6.13 kernel? I still have that
> > old VM, and when I start it, it is always perfectly fast. Only
> > newer versions are slow. Can somebody give me a hint please?
>
> It would be interesting if this could be repeated on bare hardware,
> so we can eliminate the possibility that it is some weird interaction
> with vmware.
I tested now on the same machine, outside of VMware: It is blazing fast,
just as it should be - kernel release 2.6.18.8-0.5-ZMI, where -ZMI
means I compiled the kernel myself. Still, it runs quick within the VM
with kernel 2.6.13-15.15-smp from SUSE 10.0, but slow with more recent
kernels (I couldn't test every combination of course).
I tried but cannot compile 2.6.13 within SUSE 10.3, it gives lots of
errors because libs changed.
It would be very nice to find the source of the problem. I uploaded the
kernel config options files onto my server for reference, HTH:
VMware with SUSE 10.0 and fast netatalk/samba:
http://zmi.at/x/config2.6.13-15.15.txt
VMware host, outside of VMware, also fast:
http://zmi.at/x/config2.6.18.8-host.txt
VMware with SUSE 10.2 and kernel 2.6.22-9-ZMI, slow:
http://zmi.at/x/config2.6.22.9-slow.txt
VMware with SUSE 10.3 and kernel 2.6.23.13-ZMI, slow:
http://zmi.at/x/config2.6.23.13-slow.txt
The problem seems to be somewhere between the kernel and VMware, but I
do not know what to do.
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0676/846 914 666 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: www.keyserver.net Key-ID: 1C1209B4
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]
[-- Attachment #2: Type: text/plain, Size: 228 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
Netatalk-admins mailing list
Netatalk-admins@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-admins
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Andi Kleen @ 2008-02-05 15:55 UTC (permalink / raw)
To: Glenn Griffin; +Cc: netdev, linux-kernel, Andi Kleen
In-Reply-To: <47a79d64.16538c0a.5b6a.ffffb0fe@mx.google.com>
On Mon, Feb 04, 2008 at 03:01:01PM -0800, Glenn Griffin wrote:
> Add IPv6 support to TCP SYN cookies. This is written and tested against
> 2.6.24, and applies cleanly to linus' current HEAD (d2fc0b). Unfortunately
> linus' HEAD breaks my sky2 card at the moment, so I'm unable to test against
> that. I see no reason why it would be affected though. Comments/suggestions
> are welcome.
Syncookies are discouraged these days. They disable too many
valuable TCP features (window scaling, SACK) and even without them
the kernel is usually strong enough to defend against syn floods
and systems have much more memory than they used to be.
So I don't think it makes much sense to add more code to it, sorry.
Besides you should really move it to the ipv6 module, right now the code
would be always compiled in even for ipv4 only kernels.
-Andi
^ permalink raw reply
* Re: [PATCH] SCTP: Fix kernel panic while received ASCONF chunk with bad serial number
From: Vlad Yasevich @ 2008-02-05 15:00 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev, lksctp-developers, David Miller
In-Reply-To: <47A87418.30206@cn.fujitsu.com>
Wei Yongjun wrote:
> While recevied ASCONF chunk with serial number less then needed, kernel
> will treat this chunk as a retransmitted ASCONF chunk and find cached
> ASCONF-ACK chunk used sctp_assoc_lookup_asconf_ack(). But this function
> will always return NO-NULL. So response with cached ASCONF-ACKs chunk
> will cause kernel panic.
> In function sctp_assoc_lookup_asconf_ack(), if the cached ASCONF-ACKs
> list asconf_ack_list is empty, or if the serial being requested does not
> exists, the function as it currectly stands returns the actuall
> list_head asoc->asconf_ack_list, this is not a cache ASCONF-ACK chunk
> but a bogus pointer.
Thanks, applied.
-vlad
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
> --- a/net/sctp/associola.c 2008-01-28 20:31:39.000000000 -0500
> +++ b/net/sctp/associola.c 2008-01-28 23:45:20.000000000 -0500
> @@ -1525,7 +1525,7 @@ struct sctp_chunk *sctp_assoc_lookup_asc
> const struct sctp_association *asoc,
> __be32 serial)
> {
> - struct sctp_chunk *ack = NULL;
> + struct sctp_chunk *ack;
>
> /* Walk through the list of cached ASCONF-ACKs and find the
> * ack chunk whose serial number matches that of the request.
> @@ -1533,9 +1533,9 @@ struct sctp_chunk *sctp_assoc_lookup_asc
> list_for_each_entry(ack, &asoc->asconf_ack_list, transmitted_list) {
> if (ack->subh.addip_hdr->serial == serial) {
> sctp_chunk_hold(ack);
> - break;
> + return ack;
> }
> }
>
> - return ack;
> + return NULL;
> }
>
>
^ permalink raw reply
* [PATCH] SCTP: Fix kernel panic while received ASCONF chunk with bad serial number
From: Wei Yongjun @ 2008-02-05 14:35 UTC (permalink / raw)
To: netdev, lksctp-developers; +Cc: Vlad Yasevich, David Miller
While recevied ASCONF chunk with serial number less then needed, kernel
will treat this chunk as a retransmitted ASCONF chunk and find cached
ASCONF-ACK chunk used sctp_assoc_lookup_asconf_ack(). But this function
will always return NO-NULL. So response with cached ASCONF-ACKs chunk
will cause kernel panic.
In function sctp_assoc_lookup_asconf_ack(), if the cached ASCONF-ACKs
list asconf_ack_list is empty, or if the serial being requested does not
exists, the function as it currectly stands returns the actuall
list_head asoc->asconf_ack_list, this is not a cache ASCONF-ACK chunk
but a bogus pointer.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
--- a/net/sctp/associola.c 2008-01-28 20:31:39.000000000 -0500
+++ b/net/sctp/associola.c 2008-01-28 23:45:20.000000000 -0500
@@ -1525,7 +1525,7 @@ struct sctp_chunk *sctp_assoc_lookup_asc
const struct sctp_association *asoc,
__be32 serial)
{
- struct sctp_chunk *ack = NULL;
+ struct sctp_chunk *ack;
/* Walk through the list of cached ASCONF-ACKs and find the
* ack chunk whose serial number matches that of the request.
@@ -1533,9 +1533,9 @@ struct sctp_chunk *sctp_assoc_lookup_asc
list_for_each_entry(ack, &asoc->asconf_ack_list, transmitted_list) {
if (ack->subh.addip_hdr->serial == serial) {
sctp_chunk_hold(ack);
- break;
+ return ack;
}
}
- return ack;
+ return NULL;
}
^ permalink raw reply
* [IPROUTE]: cls_flow: add vlan-tag support
From: Patrick McHardy @ 2008-02-05 14:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1399 bytes --]
commit 94e9cba778cb97d77d9146dc3bd38ff195bc2c8a
Author: Patrick McHardy <kaber@trash.net>
Date: Sat Feb 2 18:22:16 2008 +0100
[IPROUTE]: cls_flow: add vlan-tag support
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index 16869c2..e3e9e25 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -348,6 +348,7 @@ enum
FLOW_KEY_RTCLASSID,
FLOW_KEY_SKUID,
FLOW_KEY_SKGID,
+ FLOW_KEY_VLAN_TAG,
__FLOW_KEY_MAX,
};
diff --git a/tc/f_flow.c b/tc/f_flow.c
index eca05cd..1537ade 100644
--- a/tc/f_flow.c
+++ b/tc/f_flow.c
@@ -32,7 +32,8 @@ static void explain(void)
"KEY-LIST := [ KEY-LIST , ] KEY\n"
"KEY := [ src | dst | proto | proto-src | proto-dst | iif | priority | \n"
" mark | nfct | nfct-src | nfct-dst | nfct-proto-src | \n"
-" nfct-proto-dst | rt-classid | sk-uid | sk-gid ]\n"
+" nfct-proto-dst | rt-classid | sk-uid | sk-gid |\n"
+" vlan-tag ]\n"
"OPS := [ or NUM | and NUM | xor NUM | rshift NUM | addend NUM ]\n"
"ID := X:Y\n"
);
@@ -55,6 +56,7 @@ static const char *flow_keys[FLOW_KEY_MAX+1] = {
[FLOW_KEY_RTCLASSID] = "rt-classid",
[FLOW_KEY_SKUID] = "sk-uid",
[FLOW_KEY_SKGID] = "sk-gid",
+ [FLOW_KEY_VLAN_TAG] = "vlan-tag",
};
static int flow_parse_keys(__u32 *keys, __u32 *nkeys, char *argv)
^ permalink raw reply related
* [NET_SCHED 04/04]: cls_flow: support classification based on VLAN tag
From: Patrick McHardy @ 2008-02-05 14:29 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy
In-Reply-To: <20080205142902.13543.88604.sendpatchset@localhost.localdomain>
[NET_SCHED]: cls_flow: support classification based on VLAN tag
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 104092e6d90cba5fa00902a3154155872d693f42
tree 0e3fd5871a861fa022bbc2f34d314bb8672b556a
parent 03faf81b8195be455c3c7592d76d712ea9d80b13
author Patrick McHardy <kaber@trash.net> Tue, 05 Feb 2008 15:22:23 +0100
committer Patrick McHardy <kaber@trash.net> Tue, 05 Feb 2008 15:22:23 +0100
include/linux/pkt_cls.h | 1 +
net/sched/cls_flow.c | 12 ++++++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index 40fac8c..28dfc61 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -348,6 +348,7 @@ enum
FLOW_KEY_RTCLASSID,
FLOW_KEY_SKUID,
FLOW_KEY_SKGID,
+ FLOW_KEY_VLAN_TAG,
__FLOW_KEY_MAX,
};
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index eeb223c..971b867 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -19,6 +19,7 @@
#include <linux/in.h>
#include <linux/ip.h>
#include <linux/ipv6.h>
+#include <linux/if_vlan.h>
#include <net/pkt_cls.h>
#include <net/ip.h>
@@ -270,6 +271,15 @@ static u32 flow_get_skgid(const struct sk_buff *skb)
return 0;
}
+static u32 flow_get_vlan_tag(const struct sk_buff *skb)
+{
+ u16 uninitialized_var(tag);
+
+ if (vlan_get_tag(skb, &tag) < 0)
+ return 0;
+ return tag & VLAN_VID_MASK;
+}
+
static u32 flow_key_get(const struct sk_buff *skb, int key)
{
switch (key) {
@@ -305,6 +315,8 @@ static u32 flow_key_get(const struct sk_buff *skb, int key)
return flow_get_skuid(skb);
case FLOW_KEY_SKGID:
return flow_get_skgid(skb);
+ case FLOW_KEY_VLAN_TAG:
+ return flow_get_vlan_tag(skb);
default:
WARN_ON(1);
return 0;
^ permalink raw reply related
* [VLAN 03/04]: Constify skb argument to vlan_get_tag()
From: Patrick McHardy @ 2008-02-05 14:29 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy
In-Reply-To: <20080205142902.13543.88604.sendpatchset@localhost.localdomain>
[VLAN]: Constify skb argument to vlan_get_tag()
Required by next patch to use it from the flow classifier.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 03faf81b8195be455c3c7592d76d712ea9d80b13
tree 9da377d2bd44421494a4c4d7cf6c705d199c26ce
parent 2e5915ef51e55135522e59e041bb176432857d82
author Patrick McHardy <kaber@trash.net> Tue, 05 Feb 2008 15:22:23 +0100
committer Patrick McHardy <kaber@trash.net> Tue, 05 Feb 2008 15:22:23 +0100
include/linux/if_vlan.h | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 34f40ef..79504b2 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -327,7 +327,7 @@ static inline struct sk_buff *vlan_put_tag(struct sk_buff *skb, unsigned short t
*
* Returns error if the skb is not of VLAN type
*/
-static inline int __vlan_get_tag(struct sk_buff *skb, unsigned short *tag)
+static inline int __vlan_get_tag(const struct sk_buff *skb, unsigned short *tag)
{
struct vlan_ethhdr *veth = (struct vlan_ethhdr *)skb->data;
@@ -347,7 +347,8 @@ static inline int __vlan_get_tag(struct sk_buff *skb, unsigned short *tag)
*
* Returns error if @skb->cb[] is not set correctly
*/
-static inline int __vlan_hwaccel_get_tag(struct sk_buff *skb, unsigned short *tag)
+static inline int __vlan_hwaccel_get_tag(const struct sk_buff *skb,
+ unsigned short *tag)
{
struct vlan_skb_tx_cookie *cookie;
@@ -370,7 +371,7 @@ static inline int __vlan_hwaccel_get_tag(struct sk_buff *skb, unsigned short *ta
*
* Returns error if the skb is not VLAN tagged
*/
-static inline int vlan_get_tag(struct sk_buff *skb, unsigned short *tag)
+static inline int vlan_get_tag(const struct sk_buff *skb, unsigned short *tag)
{
if (skb->dev->features & NETIF_F_HW_VLAN_TX) {
return __vlan_hwaccel_get_tag(skb, tag);
^ permalink raw reply related
* [NET_SCHED 02/04]: cls_flow: fix key mask validity check
From: Patrick McHardy @ 2008-02-05 14:29 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy
In-Reply-To: <20080205142902.13543.88604.sendpatchset@localhost.localdomain>
[NET_SCHED]: cls_flow: fix key mask validity check
Since we're using fls(), we need to check whether the value is non-zero first.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 2e5915ef51e55135522e59e041bb176432857d82
tree 9a42fac3d1646a378acdc91b55642b68c9d97dde
parent adfab462c5e0a32ffff274927bba4eec3afc6e35
author Patrick McHardy <kaber@trash.net> Tue, 05 Feb 2008 15:22:23 +0100
committer Patrick McHardy <kaber@trash.net> Tue, 05 Feb 2008 15:22:23 +0100
net/sched/cls_flow.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index 8d76986..eeb223c 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -402,12 +402,13 @@ static int flow_change(struct tcf_proto *tp, unsigned long base,
if (tb[TCA_FLOW_KEYS]) {
keymask = nla_get_u32(tb[TCA_FLOW_KEYS]);
- if (fls(keymask) - 1 > FLOW_KEY_MAX)
- return -EOPNOTSUPP;
nkeys = hweight32(keymask);
if (nkeys == 0)
return -EINVAL;
+
+ if (fls(keymask) - 1 > FLOW_KEY_MAX)
+ return -EOPNOTSUPP;
}
err = tcf_exts_validate(tp, tb, tca[TCA_RATE], &e, &flow_ext_map);
^ permalink raw reply related
* [NET_SCHED 01/04]: em_meta: fix compile warning
From: Patrick McHardy @ 2008-02-05 14:29 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy
In-Reply-To: <20080205142902.13543.88604.sendpatchset@localhost.localdomain>
[NET_SCHED]: em_meta: fix compile warning
net/sched/em_meta.c: In function 'meta_int_vlan_tag':
net/sched/em_meta.c:179: warning: 'tag' may be used uninitialized in this function
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit adfab462c5e0a32ffff274927bba4eec3afc6e35
tree bfac456798152d7ea6bedcca4a03b4f045605d3d
parent fb1c15ba9ebcab6478a409051ad26d7d180fe286
author Patrick McHardy <kaber@trash.net> Tue, 05 Feb 2008 15:22:21 +0100
committer Patrick McHardy <kaber@trash.net> Tue, 05 Feb 2008 15:22:21 +0100
net/sched/em_meta.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/sched/em_meta.c b/net/sched/em_meta.c
index 9c2ec19..2a7e648 100644
--- a/net/sched/em_meta.c
+++ b/net/sched/em_meta.c
@@ -176,7 +176,7 @@ META_COLLECTOR(var_dev)
META_COLLECTOR(int_vlan_tag)
{
- unsigned short tag;
+ unsigned short uninitialized_var(tag);
if (vlan_get_tag(skb, &tag) < 0)
*err = -1;
else
^ permalink raw reply related
* [NET_SCHED 00/04]: Two fixes + cls_flow VLAN tag based classification
From: Patrick McHardy @ 2008-02-05 14:29 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy
These patches fix a compile warning in em_meta, an invalid check in
the flow classifier and add VLAN tag based classification to cls_flow.
Please apply, thanks.
include/linux/if_vlan.h | 7 ++++---
include/linux/pkt_cls.h | 1 +
net/sched/cls_flow.c | 17 +++++++++++++++--
net/sched/em_meta.c | 2 +-
4 files changed, 21 insertions(+), 6 deletions(-)
Patrick McHardy (4):
[NET_SCHED]: em_meta: fix compile warning
[NET_SCHED]: cls_flow: fix key mask validity check
[VLAN]: Constify skb argument to vlan_get_tag()
[NET_SCHED]: cls_flow: support classification based on VLAN tag
^ permalink raw reply
* Re: [PATCH] vlan tag match
From: Patrick McHardy @ 2008-02-05 14:26 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20080205.032040.20578647.davem@davemloft.net>
David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 31 Jan 2008 21:50:25 -0800
>
>> On Fri, 01 Feb 2008 06:34:34 +0100
>> Patrick McHardy <kaber@trash.net> wrote:
>>
>>> Stephen Hemminger wrote:
>>>> Provide a way to use tc filters on vlan tag even if tag is buried in
>>>> skb due to hardware acceleration.
>>> Looks reasonable. Would you like to add the same feature to the
>>> flow classifier?
>> Yes, that would be good.
>
> Did that patch get posted? I didn't see it.
No, but I already added it myself. I'll post it in a new thread.
BTW, Stephen, I noticed your ematch patch doesn't mask out the
VLAN priority which is also included in the return value of
vlan_get_tag(), is that intentional?
^ permalink raw reply
* etcnet Wi-Fi tuning
From: Van Petron @ 2008-02-05 2:32 UTC (permalink / raw)
To: netdev
Hello,
Can you help me? What can I read to solve the task:
The is Altlinux installed on the computer with Ethernet card connected
with the local network/Internet (DHCP) + WiFi USB stick.
There is notebook with Windows XP + Wi-FI PCMCIA card.
I want to connect with notebook AD-HOC: Samba, printer (on my PC
(CUPS)). I also want to retransmit local network/Internet to the notebook.
Altlinux has etcnet.
I made some tuning in ifaces/wlan0, but notebook cannot connect
with wi-fi net "Ivp" (there are two, and it cannot connect with each of
then).
Folder wlan0:
ipv4address:
192.168.0.2/24
ipv4route:
default via 192.168.0.1
iwconfig:
essid Ivp
mode 1
ap 00-50-22-E2-B6-OF
channel 3
rate 54M
options:
TYPE=eth
MODULE=ndiswrapper
NEVER_RMMOD=YES
USE_HOTPLUG=no
ONBOOT=yes
wpa_supplicant.conf:
ctrl_interface=/var/run/wpa_supplicant
update_config=1
network={
ssid="Ivp"
bssid=00-15-E9-B3-2A-20
key_mgmt=NONE
}
What is wrong?
I.P.
^ permalink raw reply
* [PATCH] virtio_net: Fix open <-> interrupt race
From: Christian Borntraeger @ 2008-02-05 13:36 UTC (permalink / raw)
To: netdev; +Cc: Rusty Russell, dor.laor, Anthony Liguori, virtualization
I got the following oops during interface ifup. Unfortunately its not
easily reproducable so I cant say for sure that my fix fixes this
problem, but I am confident and I think its correct anyway:
<2>kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:234!
<4>illegal operation: 0001 [#1] PREEMPT SMP
<4>Modules linked in:
<4>CPU: 0 Not tainted 2.6.24zlive-guest-07293-gf1ca151-dirty #91
<4>Process swapper (pid: 0, task: 0000000000800938, ksp: 000000000084ddb8)
<4>Krnl PSW : 0404300180000000 0000000000466374 (vring_disable_cb+0x30/0x34)
<4> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
<4>Krnl GPRS: 0000000000000001 0000000000000001 0000000010003800 0000000000466344
<4> 000000000e980900 00000000008848b0 000000000084e748 0000000000000000
<4> 000000000087b300 0000000000001237 0000000000001237 000000000f85bdd8
<4> 000000000e980920 00000000001137c0 0000000000464754 000000000f85bdd8
<4>Krnl Code: 0000000000466368: e3b0b0700004 lg %r11,112(%r11)
<4> 000000000046636e: 07fe bcr 15,%r14
<4> 0000000000466370: a7f40001 brc 15,466372
<4> >0000000000466374: a7f4fff6 brc 15,466360
<4> 0000000000466378: eb7ff0500024 stmg %r7,%r15,80(%r15)
<4> 000000000046637e: a7f13e00 tmll %r15,15872
<4> 0000000000466382: b90400ef lgr %r14,%r15
<4> 0000000000466386: a7840001 brc 8,466388
<4>Call Trace:
<4>([<000201500f85c000>] 0x201500f85c000)
<4> [<0000000000466556>] vring_interrupt+0x72/0x88
<4> [<00000000004801a0>] kvm_extint_handler+0x34/0x44
<4> [<000000000010d22c>] do_extint+0xbc/0xf8
<4> [<0000000000113f98>] ext_no_vtime+0x16/0x1a
<4> [<000000000010a182>] cpu_idle+0x216/0x238
<4>([<000000000010a162>] cpu_idle+0x1f6/0x238)
<4> [<0000000000568656>] rest_init+0xaa/0xb8
<4> [<000000000084ee2c>] start_kernel+0x3fc/0x490
<4> [<0000000000100020>] _stext+0x20/0x80
<4>
<4> <0>Kernel panic - not syncing: Fatal exception in interrupt
<4>
After looking at the code and the dump I think the following scenario
happened: Ifup was running on cpu2 and the interrupt arrived on cpu0.
Now virtnet_open on cpu 2 managed to execute napi_enable and disable_cb
but did not execute rx_schedule. Meanwhile on cpu 0 skb_recv_done was
called by vring_interrupt, executed netif_rx_schedule_prep, which
succeeded and therefore called disable_cb. This triggered the BUG_ON,
as interrupts were already disabled by cpu 2.
I think the proper solution is to make the call to disable_cb depend on
the atomic update of NAPI_STATE_SCHED by using netif_rx_schedule_prep
in the same way as skb_recv_done.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
drivers/net/virtio_net.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Index: kvm/drivers/net/virtio_net.c
===================================================================
--- kvm.orig/drivers/net/virtio_net.c
+++ kvm/drivers/net/virtio_net.c
@@ -321,10 +321,12 @@ static int virtnet_open(struct net_devic
/* If all buffers were filled by other side before we napi_enabled, we
* won't get another interrupt, so process any outstanding packets
- * now. virtnet_poll wants re-enable the queue, so we disable here. */
- vi->rvq->vq_ops->disable_cb(vi->rvq);
- netif_rx_schedule(vi->dev, &vi->napi);
-
+ * now. virtnet_poll wants re-enable the queue, so we disable here.
+ * We synchronize against interrupts via NAPI_STATE_SCHED */
+ if (netif_rx_schedule_prep(dev, &vi->napi)) {
+ vi->rvq->vq_ops->disable_cb(vi->rvq);
+ __netif_rx_schedule(dev, &vi->napi);
+ }
return 0;
}
--
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* Re: locking api self-test hanging
From: Bernhard Walle @ 2008-02-05 13:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, Ingo Molnar, linux-kernel, Stephen Hemminger
In-Reply-To: <20080204050421.0febc754.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> [2008-02-04 14:04]:
>
> but that code really needs help.
Using spin_lock_irqsave() is what rtc_get_rtc_time() does which was
used before I changed to get_rtc_time() does. So it should be ok. I
missed that difference. However, I agree with you the whole RTC
"emulation" per HPET is a bit unclean. However, I have too little
experience in this code area to come up with a proper redesign. I just
ported it from the old RTC to the new RTC module interface.
> Bernhard, I believe the checklist items in Documentation/SubmitChecklist
> would have prevented this at the source.
Yes. I must admit that I didn't know that document. I used
checkpatch.pl, but that's of course only for coding style. I'll try to
follow the points in SubmitChecklist in future.
Bernhard
^ permalink raw reply
* [PATCH] [PPPOL2TP] Label unused warning when CONFIG_PROC_FS is not set.
From: Rami Rosen @ 2008-02-05 12:15 UTC (permalink / raw)
To: netdev, jeff, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
Hi,
When CONFIG_PROC_FS is not set and CONFIG_PPPOL2TP is set,
we have the following warning in build:
drivers/net/pppol2tp.c: In function 'pppol2tp_init':
drivers/net/pppol2tp.c:2472: warning: label
'out_unregister_pppox_proto' defined but not used
This patches fixes this warning by adding appropriate #ifdef.
Regards,
Rami Rosen
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 420 bytes --]
diff --git a/drivers/net/pppol2tp.c b/drivers/net/pppol2tp.c
index 1b51bb6..5aa0a80 100644
--- a/drivers/net/pppol2tp.c
+++ b/drivers/net/pppol2tp.c
@@ -2468,9 +2468,10 @@ static int __init pppol2tp_init(void)
out:
return err;
-
+#ifdef CONFIG_PROC_FS
out_unregister_pppox_proto:
unregister_pppox_proto(PX_PROTO_OL2TP);
+#endif
out_unregister_pppol2tp_proto:
proto_unregister(&pppol2tp_sk_proto);
goto out;
^ permalink raw reply related
* Re: [PATCH] vlan tag match
From: David Miller @ 2008-02-05 11:20 UTC (permalink / raw)
To: shemminger; +Cc: kaber, netdev
In-Reply-To: <20080131215025.4ad118f2@extreme>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 31 Jan 2008 21:50:25 -0800
> On Fri, 01 Feb 2008 06:34:34 +0100
> Patrick McHardy <kaber@trash.net> wrote:
>
> > Stephen Hemminger wrote:
> > > Provide a way to use tc filters on vlan tag even if tag is buried in
> > > skb due to hardware acceleration.
> >
> > Looks reasonable. Would you like to add the same feature to the
> > flow classifier?
>
> Yes, that would be good.
Did that patch get posted? I didn't see it.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox