Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Nov 22, 2007 11:56 AM, Rusty Russell [EMAIL PROTECTED] wrote: On Thursday 22 November 2007 13:43:06 Andi Kleen wrote: There seems to be rough consensus that the kernel currently has too many exported symbols. A lot of these exports are generally usable utility functions or important driver interfaces; but another large part are functions intended by only one or two very specific modules for a very specific purpose. Hi Andi, This is an interesting idea, thanks for the code! My only question is whether we can get most of this benefit by dropping the indirection of namespaces and have something like EXPORT_SYMBOL_TO(sym, modname)? Andy, I like your idea. IMHO, as Rusty said a simple EXPORT_SYMBOL_TO is better. And I wonder if it is possible to export to something like the struct device_driver? If it's possible then it will not limited to modules. doesn't work so well for exporting to a group of modules, but that seems a reasonable line to draw anyway. Cheers, Rusty. PS. Probably better to use the standard warnx and errx in modpost, too. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - 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: [PATCHv6 0/3] Interface group patches
David Miller írta: From: Patrick McHardy [EMAIL PROTECTED] Date: Wed, 21 Nov 2007 01:25:54 +0100 I'm working on the incremental ruleset changing API BTW :) One of the changes will be that interface matching is not a default part of every rule, and without wildcards it will use the ifindex. But since the cost of this feature seems pretty low, I don't see a compelling reason against it. Fair enough :) If this means the patch is ok, please apply it. Thanks. -- Attila - 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: [RFC PATCH 1/2] [TCP]: MTUprobe: receiver window data available checks fixed
On Wed, Nov 21, 2007 at 06:01:27PM +0200, Ilpo Järvinen wrote:
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Thanks for the patch Ilpo!
I've just got a couple small questions.
@@ -1307,6 +1308,7 @@ static int tcp_mtu_probe(struct sock *sk)
/* Very simple search strategy: just double the MSS. */
mss_now = tcp_current_mss(sk, 0);
probe_size = 2*tp-mss_cache;
+ size_needed = probe_size + (tp-reordering + 1) * mss_now;
Should we use mss_now here or mss_cache? It would seem that an
over-estimate would be safer than an under-estimate.
Also should that be Tcprexmtthresh segments at the current MTU
or the probed MTU?
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
Re: [RFC][PATCH 1/3] NET_SCHED: PSPacer qdisc module
Hi Patrick, Looks good, but please run checkpatch over it. A few more comments below. I am sorry I forgot to run checkpatch. Thanks for your comments. They are very useful for me. I will fix them and resent the patch. Best regards, Ryousei Takano - 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: [RFC][PATCH 1/3] NET_SCHED: PSPacer qdisc module
Hi Eric,
+static struct sk_buff *alloc_gap_packet(struct Qdisc* sch, int size)
+{
+ struct sk_buff *skb;
+ struct net_device *dev = sch-dev;
+ unsigned char *pkt;
+ int pause_time = 0;
+ int pktsize = size + 2;
+
+ skb = alloc_skb(pktsize, GFP_ATOMIC);
+ if (!skb)
+ return NULL;
+
+ skb_reserve(skb, 2);
minor nit, but skb_reserve is not *needed* here.
skb_reserve() is used to align IP header on a 16 bytes boundary, and
we do it on rx side to speedup IP stack, at the cost of a possibly more
expensive DMA transfert.
Here you dont send an IP packet, do you ?
Yes, I send not an IP packet but an Ethernet frame. I removed it
and confirmed to work. Thanks for your comment.
Best regards,
Ryousei Takano
-
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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Thu, Nov 22, 2007 at 02:56:22PM +1100, Rusty Russell wrote: This is an interesting idea, thanks for the code! My only question is whether we can get most of this benefit by dropping the indirection of namespaces and have something like EXPORT_SYMBOL_TO(sym, modname)? It doesn't work so well for exporting to a group of modules, but that seems a reasonable line to draw anyway. I'd say exporting to a group of modules is the main use case. E.g. in scsi there would be symbols exported to transport class modules only or lots of the vfs_ symbols would be exported only to stackable filesystems or nfsd. - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
Very nice, looking forward to organize the exports mess a bit more. - 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: [PATCH][IRDA] Compilation for CONFIG_INET=n case
On Wed, Nov 21, 2007 at 07:03:16PM +0300, Pavel Emelyanov wrote:
Found this occasionally.
The CONFIG_INET=n is hardly ever set, but if it is the
irlan_eth_send_gratuitous_arp() compilation should produce a
warning about unused variable in_dev.
Too pedantic? :)
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
Not too pedantic yet, please keep trying :)
Applied to net-2.6. Thanks!
--
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
Re: [RFC PATCH 2/2] [TCP] MTUprobe: Cleanup send queue check (no need to loop)
On Wed, Nov 21, 2007 at 06:01:28PM +0200, Ilpo Järvinen wrote:
The original code has striking complexity to perform a query
which can be reduced to a very simple compare.
FIN seqno may be included to write_seq but it should not make
any significant difference here compared to skb-len which was
used previously. One won't end up there with SYN still queued.
Use of write_seq check guarantees that there's a valid skb in
send_head so I removed the extra check.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
OK, this one looks pretty straightforward. I'll put it in once
we resolve the other patch.
Thanks,
--
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
Re: [patch 1/4] pfkey: sending an SADB_GET responds with an SADB_GET
On Wed, Nov 21, 2007 at 11:02:13PM +, [EMAIL PROTECTED] wrote:
From: Charles Hardin [EMAIL PROTECTED]
Kernel needs to respond to an SADB_GET with the same message type to
conform to the RFC 2367 Section 3.1.5
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Applied to net-2.6. Thanks Andrew.
--
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
Re: [patch 2/4] make sunrpc/xprtsock.c:xs_setup_{udp,tcp}() static
On Wed, Nov 21, 2007 at 11:02:14PM +, [EMAIL PROTECTED] wrote:
From: Adrian Bunk [EMAIL PROTECTED]
xs_setup_{udp,tcp}() can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Applied.
--
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
Re: [patch 4/4] Net: sunrpc, remove SPIN_LOCK_UNLOCKED
On Wed, Nov 21, 2007 at 11:02:15PM +, [EMAIL PROTECTED] wrote:
From: Jiri Slaby [EMAIL PROTECTED]
sunrpc, remove SPIN_LOCK_UNLOCKED
SPIN_LOCK_UNLOCKED is deprecated, use DEFINE_SPINLOCK instead
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Applied.
--
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
Re: [patch 3/4] tlan list is subscribers-only
On Wed, Nov 21, 2007 at 11:02:15PM +, [EMAIL PROTECTED] wrote:
From: Gabriel C [EMAIL PROTECTED]
Your mail to 'Tlan-devel' with the subject
drivers/net/tlan question
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Applied.
--
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
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Thursday 22 November 2007 04:56, Rusty Russell wrote: This is an interesting idea, thanks for the code! My only question is whether we can get most of this benefit by dropping the indirection of namespaces and have something like EXPORT_SYMBOL_TO(sym, modname)? It doesn't work so well for exporting to a group of modules, but that seems a reasonable line to draw anyway. That would explode quickly already even for my example inet namespace. It already has several modules. I don't think so much duplication would be a good idea. -Andi - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Thursday 22 November 2007 12:06, Christoph Hellwig wrote: Very nice, looking forward to organize the exports mess a bit more. I would need people to help me converting more subsystems to this new scheme. In particular all exports that are only used by a single module are direct candidates for a namespace. For the others it has to be checked by someone who knows the particular subsystem well. e.g. for SCSI it would be nice to put the symbols only used by sd/sr/sg etc. into a namespace. -Andi - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
Em Thu, Nov 22, 2007 at 03:43:06AM +0100, Andi Kleen escreveu: There seems to be rough consensus that the kernel currently has too many exported symbols. A lot of these exports are generally usable utility functions or important driver interfaces; but another large part are functions intended by only one or two very specific modules for a very specific purpose. One example is the TCP code. It has most of its internals exported, but only for use by tcp_ipv6.c (and now a few more by the TCP/IP congestion modules) But it doesn't make sense to include these exported for a specific module functions into a broader kernel interface. External modules assume they can use these functions, but they were never intended for that. Thank you for doing this. Creating the DCCP and its congestion control infrastructure (CCID) module namespaces is now on my TODO list. :-) - Arnaldo - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Thu, Nov 22, 2007 at 12:54:49PM +0100, Andi Kleen wrote: On Thursday 22 November 2007 12:06, Christoph Hellwig wrote: Very nice, looking forward to organize the exports mess a bit more. I would need people to help me converting more subsystems to this new scheme. In particular all exports that are only used by a single module are direct candidates for a namespace. For the others it has to be checked by someone who knows the particular subsystem well. e.g. for SCSI it would be nice to put the symbols only used by sd/sr/sg etc. into a namespace. True. I'll take care of the scsi bits once this goes in. - 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
[PATCH] smc911x: Fix multicast handling
smc911x_set_multicast_list fails to fill out the multicast hash table
correctly; Bit 1 was used rather than bit 5 to decide if the lower or
upper register should be used.
The function is at the same time cleaned up by calling ether_crc rather
than using it's own bit reversal table.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
drivers/net/smc911x.c | 17 -
1 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index dd18af0..b6c6c99 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -1379,13 +1379,6 @@ static void smc911x_set_multicast_list(struct net_device
*dev)
unsigned int multicast_table[2];
unsigned int mcr, update_multicast = 0;
unsigned long flags;
- /* table for flipping the order of 5 bits */
- static const unsigned char invert5[] =
- {0x00, 0x10, 0x08, 0x18, 0x04, 0x14, 0x0C, 0x1C,
-0x02, 0x12, 0x0A, 0x1A, 0x06, 0x16, 0x0E, 0x1E,
-0x01, 0x11, 0x09, 0x19, 0x05, 0x15, 0x0D, 0x1D,
-0x03, 0x13, 0x0B, 0x1B, 0x07, 0x17, 0x0F, 0x1F};
-
DBG(SMC_DEBUG_FUNC, %s: -- %s\n, dev-name, __FUNCTION__);
@@ -1432,7 +1425,7 @@ static void smc911x_set_multicast_list(struct net_device
*dev)
cur_addr = dev-mc_list;
for (i = 0; i dev-mc_count; i++, cur_addr = cur_addr-next) {
- int position;
+ u32 position;
/* do we have a pointer here? */
if (!cur_addr)
@@ -1442,12 +1435,10 @@ static void smc911x_set_multicast_list(struct
net_device *dev)
if (!(*cur_addr-dmi_addr 1))
continue;
- /* only use the low order bits */
- position = crc32_le(~0, cur_addr-dmi_addr, 6) 0x3f;
+ /* upper 6 bits are used as hash index */
+ position = ether_crc(ETH_ALEN, cur_addr-dmi_addr)26;
- /* do some messy swapping to put the bit in the right
spot */
- multicast_table[invert5[position0x1F]0x1] |=
- (1invert5[(position1)0x1F]);
+ multicast_table[position5] |= 1 (position0x1f);
}
/* be sure I get rid of flags I might have set */
--
1.5.3.5
-
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: [README] away until Dec 3rd
Hello. I have a question. Yesterday, I posted a patch based on 2.6.24-rc3-mm1 that modifies the following files. include/linux/security.h | 34 +- net/core/datagram.c | 26 -- net/socket.c |7 +-- security/dummy.c | 13 ++--- security/security.c | 10 -- But you say that I should make patches based on the net-2.6.25 tree. Which tree (-mm or net-2.6.25) should I use for making this patch? There is no pending objection at LSM-ml so far, and I'm asking for an approval from one of the core developers at netdev-ml. Regards. - 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: [README] away until Dec 3rd
On Thu, Nov 22, 2007 at 09:57:14PM +0900, Tetsuo Handa wrote:
But you say that I should make patches based on the net-2.6.25 tree.
Which tree (-mm or net-2.6.25) should I use for making this patch?
The net-2.6.25 tree is the one. Please use the tree at
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/net-2.6.25.git/
while Dave is away.
Thanks,
--
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
Re: [RFC PATCH 1/2] [TCP]: MTUprobe: receiver window data available checks fixed
On Thu, 22 Nov 2007, Herbert Xu wrote:
On Wed, Nov 21, 2007 at 06:01:27PM +0200, Ilpo Järvinen wrote:
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Thanks for the patch Ilpo!
I've just got a couple small questions.
...Thanks for actually commenting it. :-)
@@ -1307,6 +1308,7 @@ static int tcp_mtu_probe(struct sock *sk)
/* Very simple search strategy: just double the MSS. */
mss_now = tcp_current_mss(sk, 0);
probe_size = 2*tp-mss_cache;
+ size_needed = probe_size + (tp-reordering + 1) * mss_now;
Should we use mss_now here or mss_cache? It would seem that an
over-estimate would be safer than an under-estimate.
You're right, it's definately better that way... New version below, I
just tweaked that line inline :-).
Also should that be Tcprexmtthresh segments at the current MTU
or the probed MTU?
...We'll be using current MTU sized packets except for the probe until
the probe has succeeded, only from that point onward will the new packets
will be sent with the larger MTU. If the probe succeeds, all reservations
we made here are no longer meaningful or necessary anyway. The point is to
detect failure by having fast recovery triggered by the current MTU sized
packets that follow the probe, that's because we know that those smaller
packets are not going to be dropped by the path even though an oversize
probe would be.
--
i.
--
[PATCH 1/2] [TCP]: MTUprobe: receiver window data available checks fixed
It seems that the checked range for receiver window check should
begin from the first rather than from the last skb that is going
to be included to the probe. And that can be achieved without
reference to skbs at all, snd_nxt and write_seq provides the
correct seqno already. Plus, it SHOULD account packets that are
necessary to trigger fast retransmit [RFC4821].
Location of snd_wnd probe_size/size_needed check is bogus
because it will cause the other if() match as well (due to
snd_nxt = snd_una invariant).
Removed dead obvious comment.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_output.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 30d6737..ff22ce8 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1289,6 +1289,7 @@ static int tcp_mtu_probe(struct sock *sk)
struct sk_buff *skb, *nskb, *next;
int len;
int probe_size;
+ int size_needed;
unsigned int pif;
int copy;
int mss_now;
@@ -1307,6 +1308,7 @@ static int tcp_mtu_probe(struct sock *sk)
/* Very simple search strategy: just double the MSS. */
mss_now = tcp_current_mss(sk, 0);
probe_size = 2*tp-mss_cache;
+ size_needed = probe_size + (tp-reordering + 1) * tp-mss_cache;
if (probe_size tcp_mtu_to_mss(sk, icsk-icsk_mtup.search_high)) {
/* TODO: set timer for probe_converge_event */
return -1;
@@ -1316,18 +1318,15 @@ static int tcp_mtu_probe(struct sock *sk)
len = 0;
if ((skb = tcp_send_head(sk)) == NULL)
return -1;
- while ((len += skb-len) probe_size !tcp_skb_is_last(sk, skb))
+ while ((len += skb-len) size_needed !tcp_skb_is_last(sk, skb))
skb = tcp_write_queue_next(sk, skb);
- if (len probe_size)
+ if (len size_needed)
return -1;
- /* Receive window check. */
- if (after(TCP_SKB_CB(skb)-seq + probe_size, tp-snd_una +
tp-snd_wnd)) {
- if (tp-snd_wnd probe_size)
- return -1;
- else
- return 0;
- }
+ if (tp-snd_wnd size_needed)
+ return -1;
+ if (after(tp-snd_nxt + size_needed, tp-snd_una + tp-snd_wnd))
+ return 0;
/* Do we need to wait to drain cwnd? */
pif = tcp_packets_in_flight(tp);
--
1.5.0.6
[PATCH][UNIX] Move the unix sock iterators in to proper place
The first_unix_socket() and next_unix_sockets() are now used
in proc file and in forall_unix_socets macro only.
The forall_unix_sockets is not used in this file at all so
remove it. After this move the helpers to where they really
belong, i.e. closer to proc code under the #ifdef CONFIG_PROC_FS
option.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 6be6d87..b62a271 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -127,32 +127,6 @@ static atomic_t unix_nr_socks = ATOMIC_INIT(0);
#define UNIX_ABSTRACT(sk) (unix_sk(sk)-addr-hash != UNIX_HASH_SIZE)
-static struct sock *first_unix_socket(int *i)
-{
- for (*i = 0; *i = UNIX_HASH_SIZE; (*i)++) {
- if (!hlist_empty(unix_socket_table[*i]))
- return __sk_head(unix_socket_table[*i]);
- }
- return NULL;
-}
-
-static struct sock *next_unix_socket(int *i, struct sock *s)
-{
- struct sock *next = sk_next(s);
- /* More in this chain? */
- if (next)
- return next;
- /* Look for next non-empty chain. */
- for ((*i)++; *i = UNIX_HASH_SIZE; (*i)++) {
- if (!hlist_empty(unix_socket_table[*i]))
- return __sk_head(unix_socket_table[*i]);
- }
- return NULL;
-}
-
-#define forall_unix_sockets(i, s) \
- for (s = first_unix_socket((i)); s; s = next_unix_socket((i),(s)))
-
#ifdef CONFIG_SECURITY_NETWORK
static void unix_get_secdata(struct scm_cookie *scm, struct sk_buff *skb)
{
@@ -2010,6 +1984,29 @@ static unsigned int unix_poll(struct file * file, struct
socket *sock, poll_tabl
#ifdef CONFIG_PROC_FS
+static struct sock *first_unix_socket(int *i)
+{
+ for (*i = 0; *i = UNIX_HASH_SIZE; (*i)++) {
+ if (!hlist_empty(unix_socket_table[*i]))
+ return __sk_head(unix_socket_table[*i]);
+ }
+ return NULL;
+}
+
+static struct sock *next_unix_socket(int *i, struct sock *s)
+{
+ struct sock *next = sk_next(s);
+ /* More in this chain? */
+ if (next)
+ return next;
+ /* Look for next non-empty chain. */
+ for ((*i)++; *i = UNIX_HASH_SIZE; (*i)++) {
+ if (!hlist_empty(unix_socket_table[*i]))
+ return __sk_head(unix_socket_table[*i]);
+ }
+ return NULL;
+}
+
struct unix_iter_state {
struct seq_net_private p;
int i;
-
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
[RFC] bridging: don't forward EAPOL frames
This patch makes the bridging code drop EAPOL frames as recommended by
802.1X-2004 in C.3.3.
Is this really the right place to put it?
---
include/linux/if_ether.h |1 +
include/net/ieee80211.h |6 --
net/bridge/br_input.c|3 +++
3 files changed, 4 insertions(+), 6 deletions(-)
--- everything.orig/include/linux/if_ether.h2007-11-22 11:47:14.178686360
+0100
+++ everything/include/linux/if_ether.h 2007-11-22 11:48:21.438679036 +0100
@@ -74,6 +74,7 @@
#define ETH_P_ATMFATE 0x8884 /* Frame-based ATM Transport
* over Ethernet
*/
+#define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */
#define ETH_P_AOE 0x88A2 /* ATA over Ethernet*/
#define ETH_P_TIPC 0x88CA /* TIPC */
--- everything.orig/include/net/ieee80211.h 2007-11-22 11:46:29.908682888
+0100
+++ everything/include/net/ieee80211.h 2007-11-22 11:48:51.908679037 +0100
@@ -183,12 +183,6 @@ const char *escape_essid(const char *ess
#endif
#include net/iw_handler.h/* new driver API */
-#ifndef ETH_P_PAE
-#define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */
-#endif /* ETH_P_PAE */
-
-#define ETH_P_PREAUTH 0x88C7 /* IEEE 802.11i pre-authentication */
-
#ifndef ETH_P_80211_RAW
#define ETH_P_80211_RAW (ETH_P_ECONET + 1)
#endif
--- everything.orig/net/bridge/br_input.c 2007-11-22 11:54:44.798683106
+0100
+++ everything/net/bridge/br_input.c2007-11-22 11:57:23.248680285 +0100
@@ -145,6 +145,9 @@ struct sk_buff *br_handle_frame(struct n
}
}
+ if (unlikely(skb-protocol = htons(ETH_P_PAE)))
+ goto drop;
+
switch (p-state) {
case BR_STATE_FORWARDING:
-
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
[PATCH net-2.6.25] Add packet filtering based on process's security context.
Hello.
Herbert Xu wrote:
On Thu, Nov 22, 2007 at 09:57:14PM +0900, Tetsuo Handa wrote:
But you say that I should make patches based on the net-2.6.25 tree.
Which tree (-mm or net-2.6.25) should I use for making this patch?
The net-2.6.25 tree is the one. Please use the tree at
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/net-2.6.25.git/
while Dave is away.
Thank you.
I refreshed the patch based on net-2.6.25 tree.
Regards.
-
Subject: Add packet filtering based on process's security context.
This patch allows LSM modules filter incoming connections/datagrams
based on the process's security context who is attempting to pick up.
There are already hooks to filter incoming connections/datagrams
based on the socket's security context, but these hooks are not
applicable when one wants to do TCP Wrapper-like filtering
(e.g. App1 is permitted to accept TCP connections from 192.168.0.0/16).
Precautions: This approach has a side effect which unlikely occurs.
If a socket is shared by multiple processes with differnt policy,
the process who should be able to accept this connection
will not be able to accept this connection
because socket_post_accept() aborts this connection.
But if socket_post_accept() doesn't abort this connection,
the process who must not be able to accept this connection
will repeat accept() forever, which is a worse side effect.
Similarly, if a socket is shared by multiple processes with differnt policy,
the process who should be able to pick up this datagram
will not be able to pick up this datagram
because socket_post_recv_datagram() discards this datagram.
But if socket_post_recv_datagram() doesn't discard this datagram,
the process who must not be able to pick up this datagram
will repeat recvmsg() forever, which is a worse side effect.
So, don't give different permissions between processes who share one socket.
Otherwise, some connections/datagrams cannot be delivered to intended process.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
include/linux/security.h | 34 +-
net/core/datagram.c | 26 --
net/socket.c |7 +--
security/dummy.c | 13 ++---
security/security.c | 10 --
5 files changed, 76 insertions(+), 14 deletions(-)
--- net-2.6.25.orig/include/linux/security.h
+++ net-2.6.25/include/linux/security.h
@@ -781,8 +781,12 @@ struct request_sock;
* @socket_post_accept:
* This hook allows a security module to copy security
* information into the newly created socket's inode.
+ * This hook also allows a security module to filter connections
+ * from unwanted peers based on the process accepting this connection.
+ * The connection will be aborted if this hook returns nonzero.
* @sock contains the listening socket structure.
* @newsock contains the newly created server socket for connection.
+ * Return 0 if permission is granted.
* @socket_sendmsg:
* Check permission before transmitting a message to another socket.
* @sock contains the socket structure.
@@ -796,6 +800,15 @@ struct request_sock;
* @size contains the size of message structure.
* @flags contains the operational flags.
* Return 0 if permission is granted.
+ * @socket_post_recv_datagram:
+ * Check permission after receiving a datagram.
+ * This hook allows a security module to filter packets
+ * from unwanted peers based on the process receiving this datagram.
+ * The packet will be discarded if this hook returns nonzero.
+ * @sk contains the socket.
+ * @skb contains the socket buffer (may be NULL).
+ * @flags contains the operational flags.
+ * Return 0 if permission is granted.
* @socket_getsockname:
* Check permission before the local address (name) of the socket object
* @sock is retrieved.
@@ -1387,12 +1400,13 @@ struct security_operations {
struct sockaddr * address, int addrlen);
int (*socket_listen) (struct socket * sock, int backlog);
int (*socket_accept) (struct socket * sock, struct socket * newsock);
- void (*socket_post_accept) (struct socket * sock,
- struct socket * newsock);
+ int (*socket_post_accept) (struct socket *sock, struct socket *newsock);
int (*socket_sendmsg) (struct socket * sock,
struct msghdr * msg, int size);
int (*socket_recvmsg) (struct socket * sock,
struct msghdr * msg, int size, int flags);
+ int (*socket_post_recv_datagram) (struct sock *sk, struct sk_buff *skb,
+ unsigned int flags);
int (*socket_getsockname) (struct socket * sock);
int (*socket_getpeername) (struct socket * sock);
int (*socket_getsockopt) (struct socket *
Re: [RFC PATCH 1/2] [TCP]: MTUprobe: receiver window data available checks fixed
On Thu, Nov 22, 2007 at 03:11:35PM +0200, Ilpo Järvinen wrote:
...We'll be using current MTU sized packets except for the probe until
the probe has succeeded, only from that point onward will the new packets
will be sent with the larger MTU. If the probe succeeds, all reservations
we made here are no longer meaningful or necessary anyway. The point is to
detect failure by having fast recovery triggered by the current MTU sized
packets that follow the probe, that's because we know that those smaller
packets are not going to be dropped by the path even though an oversize
probe would be.
Thanks for the explanation!
I'll apply both patches to net-2.6.
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
Re: [PATCHv6 0/3] Interface group patches
From: Patrick McHardy I'm working on the incremental ruleset changing API BTW :) One of the changes will be that interface matching is not a default part of every rule, and without wildcards it will use the ifindex. But since the cost of this feature seems pretty low, I don't see a compelling reason against it. Using ifindex instead of string matching the interface name in -i and -o would be a serious problem as it changes the semantics. 1) Now you can match a non existing interface. This is certainly used. I.e. with vlan interfaces, ppp etc. 2) Now your rule will match an interface even if the ifindex of the interface changes. This is used (i.e. you activate a backup interface and rename it, build new bridges etc.). If one wants to use the ifindex instead of a string match on the name one should explicitly request that (i.e. by using -i =eth0 or something like that). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
Creating the DCCP and its congestion control infrastructure (CCID) module namespaces is now on my TODO list. :-) My original patchkit had DCCP actually done, but I ran into some problem while forward porting and disabled it again. But should be reasonably easy to resurrect. -Andi - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
Andy, I like your idea. IMHO, as Rusty said a simple EXPORT_SYMBOL_TO is better. I don't think so. e.g. tcpcong would be very very messy this way. And I wonder if it is possible to export to something like the struct device_driver? If it's possible then it will not limited to modules. Not sure I follow you. Can you expand? -Andi - 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
2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
WARN during log message being output to ttyS0 and netconsole: [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at kernel/softirq.c:139 local_bh_enable() [2059664.620535] [80120364] local_bh_enable+0x3c/0x97 [2059664.620553] [802e3356] __nf_ct_ext_destroy+0x35/0x5b [2059664.620569] [802dfbeb] destroy_conntrack+0x5e/0xf6 [2059664.620577] [802db821] nf_conntrack_destroy+0x1f/0x3f [2059664.620585] [802c0c71] __kfree_skb+0xb8/0xf6 [2059664.620597] [802d00f0] zap_completion_queue+0x3e/0x64 [2059664.620606] [802d0583] find_skb+0x14/0x6b [2059664.620612] [801167cc] inc_nr_running+0x12/0x25 [2059664.620622] [802d0fd8] netpoll_send_udp+0x2d/0x251 [2059664.620630] [80226135] uart_console_write+0x2a/0x33 [2059664.620645] [80241319] write_msg+0x32/0x41 [2059664.620657] [8011c205] __call_console_drivers+0x61/0x6d [2059664.620669] [8011c3fc] release_console_sem+0x164/0x1bf [2059664.620679] [8011c81f] vprintk+0x27a/0x2ff [2059664.620692] [8013881e] handle_IRQ_event+0x1a/0x3f [2059664.620702] [801203a5] local_bh_enable+0x7d/0x97 [2059664.620709] [8031ae6a] fn_hash_lookup+0xb0/0xcd [2059664.620723] [8011c8bf] printk+0x1b/0x1f [2059664.620731] [8032b372] ipt_log_packet+0x71/0x15e [2059664.620747] [8032b4a0] ipt_log_target+0x41/0x4a [2059664.620757] [802ea446] ipt_limit_match+0x58/0x76 [2059664.620766] [8032b45f] ipt_log_target+0x0/0x4a [2059664.620774] [803288c5] ipt_do_table+0x3e2/0x479 [2059664.620785] [80331228] xfrm_policy_put_afinfo+0xa/0x1e [2059664.620800] [80332219] xfrm_lookup+0x15/0x69 [2059664.620809] [802db7d0] nf_iterate+0x38/0x6a [2059664.620822] [802dbb60] nf_hook_slow+0x57/0xe0 [2059664.620830] [802f1e7c] ip_forward_finish+0x0/0x22 [2059664.620841] [802f20d1] ip_forward+0x233/0x2ae [2059664.620849] [802f1e7c] ip_forward_finish+0x0/0x22 [2059664.620859] [802f0e7a] ip_rcv+0x46f/0x49c [2059664.620866] [802f04a8] ip_rcv_finish+0x0/0x2ab [2059664.620876] [802f0a0b] ip_rcv+0x0/0x49c [2059664.620884] [802c544a] netif_receive_skb+0x326/0x3ae [2059664.620894] [802c6efe] process_backlog+0x6d/0xd2 [2059664.620903] [802c766e] net_rx_action+0x86/0x193 [2059664.620911] [80120001] __do_softirq+0x40/0x85 [2059664.620919] [8012006d] do_softirq+0x27/0x2b [2059664.620925] [8012023d] irq_exit+0x2d/0x37 [2059664.620931] [801062d9] do_IRQ+0x7a/0x8d [2059664.620943] [8010479b] common_interrupt+0x23/0x28 [2059664.620954] [80209f85] acpi_processor_idle+0x235/0x3a0 [2059664.620967] [80102344] cpu_idle+0x43/0x6c [2059664.620973] [804aa99e] start_kernel+0x210/0x215 [2059664.620989] [804aa317] unknown_bootoption+0x0/0x195 [2059664.620998] === [2059664.852188] SRC=66.249.93.147 DST=* LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=23868 DF PROTO=TCP SPT=80 DPT=55219 WINDOW=0 RES=0x00 RST URGP=0 [0.00] Linux version 2.6.23-git ([EMAIL PROTECTED]) (gcc version 4.1.2 20070214 ( (gdc 0.23, using dmd 1.007)) (Gentoo 4.1.2)) #41 PREEMPT Sun Oct 21 20:42:28 BST 2007 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3fee (usable) [0.00] BIOS-e820: 3fee - 3fee3000 (ACPI NVS) [0.00] BIOS-e820: 3fee3000 - 3fef (ACPI data) [0.00] BIOS-e820: 3fef - 3ff0 (reserved) [0.00] BIOS-e820: fec0 - fec01000 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: - 0001 (reserved) [0.00] 0MB HIGHMEM available. [0.00] 1022MB LOWMEM available. [0.00] found SMP MP-table at 000f4d50 [0.00] NX (Execute Disable) protection: active [0.00] Entering add_active_range(0, 0, 261856) 0 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] Normal 4096 - 261856 [0.00] HighMem261856 - 261856 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 - 261856 [0.00] On node 0 totalpages: 261856 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 2013 pages used for memmap [0.00] Normal zone: 255747 pages, LIFO batch:31 [0.00] HighMem zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F6E10, 0014 (r0 CN700 ) [0.00] ACPI: RSDT 3FEE3040, 002C (r1 CN700 AWRDACPI 42302E31 AWRD 0) [0.00] ACPI: FACP 3FEE30C0, 0074 (r1 CN700 AWRDACPI 42302E31 AWRD 0) [
NET: dmfe.c : fix access to card's pci config space in D3
Hi, I somehow assumed that pci_save_state should be called while device is powered off, but actually the opposite is true. Thus I am sending this patch to fix it. Sorry for this mistake, Best regards, Maxim Levitsky - 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
[PATCH] NET: dmfe: don't access configuration space in D3 state
From 7e24227257f315e52fe0b494dc1253d2a0ce5dff Mon Sep 17 00:00:00 2001 From: Maxim Levitsky [EMAIL PROTECTED] Date: Fri, 23 Nov 2007 01:15:36 +0200 Subject: [PATCH] NET: dmfe: don't access configuration space in D3 state Accidently I reversed the order of pci_save_state and pci_set_power_state in .suspend()/.resume() callbacks Signed-off-by: Maxim Levitsky [EMAIL PROTECTED] --- drivers/net/tulip/dmfe.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c index 390d02d..9d199b0 100644 --- a/drivers/net/tulip/dmfe.c +++ b/drivers/net/tulip/dmfe.c @@ -2118,8 +2118,8 @@ static int dmfe_suspend(struct pci_dev *pci_dev, pm_message_t state) pci_enable_wake(pci_dev, PCI_D3cold, 1); /* Power down device*/ - pci_set_power_state(pci_dev, pci_choose_state (pci_dev,state)); pci_save_state(pci_dev); + pci_set_power_state(pci_dev, pci_choose_state (pci_dev,state)); return 0; } @@ -2129,8 +2129,8 @@ static int dmfe_resume(struct pci_dev *pci_dev) struct net_device *dev = pci_get_drvdata(pci_dev); u32 tmp; - pci_restore_state(pci_dev); pci_set_power_state(pci_dev, PCI_D0); + pci_restore_state(pci_dev); /* Re-initilize DM910X board */ dmfe_init_dm910x(dev); -- 1.5.3.4 - 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: [PATCH net-2.6.25] Add packet filtering based on process's security context.
On Thu, 22 Nov 2007, Tetsuo Handa wrote: This patch allows LSM modules filter incoming connections/datagrams based on the process's security context who is attempting to pick up. There are already hooks to filter incoming connections/datagrams based on the socket's security context, but these hooks are not applicable when one wants to do TCP Wrapper-like filtering (e.g. App1 is permitted to accept TCP connections from 192.168.0.0/16). This functionality looks like it could be useful in that we currently have no direct security mapping from incoming packet to user process, but only to the receiving socket, as you mention. For SELinux, it may help us simplify/clarify policy. It's also been long-desired for netfilter/iptables, to allow ipt_owner to work cleanly for incoming packets. So, this probably needs to be implemented in a way which works for both LSM and netfilter. There have been several discussions on the issue from the netfilter side, although I don't know what the latest status of that is (I've expanded the cc list to hopefully get some more feedback). From memory, one approach under discussion was to add netfilter hooks to the transport layer, which could be invoked correctly by each type of protocol when the target process is selected. If this is done for netfilter, then an LSM hook is probably not needed at all, as security modules can utilize netfilter hooks directly. Precautions: This approach has a side effect which unlikely occurs. If a socket is shared by multiple processes with differnt policy, the process who should be able to accept this connection will not be able to accept this connection because socket_post_accept() aborts this connection. But if socket_post_accept() doesn't abort this connection, the process who must not be able to accept this connection will repeat accept() forever, which is a worse side effect. Similarly, if a socket is shared by multiple processes with differnt policy, the process who should be able to pick up this datagram will not be able to pick up this datagram because socket_post_recv_datagram() discards this datagram. But if socket_post_recv_datagram() doesn't discard this datagram, the process who must not be able to pick up this datagram will repeat recvmsg() forever, which is a worse side effect. So, don't give different permissions between processes who share one socket. Otherwise, some connections/datagrams cannot be delivered to intended process. These semantics changes are concerning, and lead me to wonder if there are any more. Needs more review by networking folk. - James -- James Morris [EMAIL PROTECTED] - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Thursday 22 November 2007 22:46:23 Andi Kleen wrote: On Thursday 22 November 2007 04:56, Rusty Russell wrote: This is an interesting idea, thanks for the code! My only question is whether we can get most of this benefit by dropping the indirection of namespaces and have something like EXPORT_SYMBOL_TO(sym, modname)? It doesn't work so well for exporting to a group of modules, but that seems a reasonable line to draw anyway. That would explode quickly already even for my example inet namespace. It already has several modules. I don't think so much duplication would be a good idea. Yes, and if a symbol is already used by multiple modules, it's generically useful. And if so, why restrict it to in-tree modules? If your real intent is to bias against out-of-tree modules, let's just generate a list of in-tree module names, and restrict some or all exports to that set. Rusty. - 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
[PATCH] add compare_ether_addr_unaligned
David Miller found a problem in a wireless driver where I was using
compare_ether_addr() on potentially unaligned data. Document that
compare_ether_addr() is not safe for use everywhere, and add an equivalent
function that works regardless of alignment.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux-2.6.24-rc3-git1/include/linux/etherdevice.h
===
--- linux-2.6.24-rc3-git1.orig/include/linux/etherdevice.h
+++ linux-2.6.24-rc3-git1/include/linux/etherdevice.h
@@ -123,11 +123,13 @@ static inline void random_ether_addr(u8
}
/**
- * compare_ether_addr - Compare two Ethernet addresses
+ * compare_ether_addr - Compare two 16-bit-aligned Ethernet addresses
* @addr1: Pointer to a six-byte array containing the Ethernet address
* @addr2: Pointer other six-byte array containing the Ethernet address
*
- * Compare two ethernet addresses, returns 0 if equal
+ * Compare two ethernet addresses, returns 0 if equal. Both addresses must
+ * be 16-bit aligned. For unaligned or potentially unaligned address
+ * comparisons, use compare_ether_addr_unaligned() instead.
*/
static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
{
@@ -137,6 +139,21 @@ static inline unsigned compare_ether_add
BUILD_BUG_ON(ETH_ALEN != 6);
return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
}
+
+/**
+ * compare_ether_addr_unaligned - Compare two Ethernet addresses
+ * @addr1: Pointer to a six-byte array containing the Ethernet address
+ * @addr2: Pointer other six-byte array containing the Ethernet address
+ *
+ * Compare two ethernet addresses, returns 0 if equal. compare_ether_addr()
+ * is faster than this function, but unless you can ensure alignment you
+ * must use this function instead.
+ */
+static inline unsigned compare_ether_addr_unaligned(const u8 *addr1,
+ const u8 *addr2)
+{
+ return memcmp(addr1, addr2, ETH_ALEN);
+}
#endif /* __KERNEL__ */
#endif /* _LINUX_ETHERDEVICE_H */
-
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: [PATCH] cassini: NAPI configuration
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 21 Nov 2007 11:53:58 -0800 The Cassini driver has NAPI support, but it not possible to configure it. Compile tested only, no idea if it works (no hardware). Get rid of warning from lefover variable in now visible code. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] This driver needs massive amounts of work, and along with some contacts within Sun I plan to make this soon after I get back from Korea. Therefore, please leave this stuff alone for a bit. Thanks. - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Thursday 22 November 2007 22:05:45 Christoph Hellwig wrote: On Thu, Nov 22, 2007 at 02:56:22PM +1100, Rusty Russell wrote: This is an interesting idea, thanks for the code! My only question is whether we can get most of this benefit by dropping the indirection of namespaces and have something like EXPORT_SYMBOL_TO(sym, modname)? It doesn't work so well for exporting to a group of modules, but that seems a reasonable line to draw anyway. I'd say exporting to a group of modules is the main use case. E.g. in scsi there would be symbols exported to transport class modules only or lots of the vfs_ symbols would be exported only to stackable filesystems or nfsd. That's my point. If there's a whole class of modules which can use a symbol, why are we ruling out external modules? If that's what you want, why not have a list of permitted modules compiled into the kernel and allow no others? Cheers, Rusty. - 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: [RFC/PATCH] SO_NO_CHECK for IPv6
Regardless of whatever verifications your application is doing on the data, it is not checksumming the ports and that's what the pseudo-header is helping with. So what? We are in the case where the data has already gotten to him. If it got to him in error, he'll reject it anyway. The receive checksum check will only reject packets that he would reject anyway. That makes it needless. Of course, if the check is nearly free, there's no potential win, so no point in bothering. DS - 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: [RFC/PATCH] SO_NO_CHECK for IPv6
From: Jeff Garzik [EMAIL PROTECTED] Date: Wed, 21 Nov 2007 19:17:40 -0500 YOSHIFUJI Hideaki / 吉藤英明 wrote: In article [EMAIL PROTECTED] (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff Garzik [EMAIL PROTECTED] says: SO_NO_CHECK support for IPv6 appeared to be missing. This is presented, based on a reading of net/ipv4/udp.c. Disagree. UDP checksum is mandatory in IPv6. Ah, you mean that I need to turn off UDP checksum on receive end as well in IPv6... true. For those interested, I am dealing with a UDP app that already does very strong checksumming and encryption, so additional software checksumming at the lower layers is quite simply a waste of CPU cycles. Hardware checksumming is fine, as long as its free. Regardless of whatever verifications your application is doing on the data, it is not checksumming the ports and that's what the pseudo-header is helping with. You cannot disable checksums in ipv6/UDP, they are not optional and with %99.999 of cards doing the checksum in hardware, and even if we do have to compute it it's free during the copy during recvmsg(). - 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: [PATCH] add compare_ether_addr_unaligned
On Fri, 23 Nov 2007 00:09:22 + (GMT)
Daniel Drake [EMAIL PROTECTED] wrote:
David Miller found a problem in a wireless driver where I was using
compare_ether_addr() on potentially unaligned data. Document that
compare_ether_addr() is not safe for use everywhere, and add an equivalent
function that works regardless of alignment.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux-2.6.24-rc3-git1/include/linux/etherdevice.h
===
--- linux-2.6.24-rc3-git1.orig/include/linux/etherdevice.h
+++ linux-2.6.24-rc3-git1/include/linux/etherdevice.h
@@ -123,11 +123,13 @@ static inline void random_ether_addr(u8
}
/**
- * compare_ether_addr - Compare two Ethernet addresses
+ * compare_ether_addr - Compare two 16-bit-aligned Ethernet addresses
* @addr1: Pointer to a six-byte array containing the Ethernet address
* @addr2: Pointer other six-byte array containing the Ethernet address
*
- * Compare two ethernet addresses, returns 0 if equal
+ * Compare two ethernet addresses, returns 0 if equal. Both addresses must
+ * be 16-bit aligned. For unaligned or potentially unaligned address
+ * comparisons, use compare_ether_addr_unaligned() instead.
*/
static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
{
@@ -137,6 +139,21 @@ static inline unsigned compare_ether_add
BUILD_BUG_ON(ETH_ALEN != 6);
return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
}
+
+/**
+ * compare_ether_addr_unaligned - Compare two Ethernet addresses
+ * @addr1: Pointer to a six-byte array containing the Ethernet address
+ * @addr2: Pointer other six-byte array containing the Ethernet address
+ *
+ * Compare two ethernet addresses, returns 0 if equal. compare_ether_addr()
+ * is faster than this function, but unless you can ensure alignment you
+ * must use this function instead.
+ */
+static inline unsigned compare_ether_addr_unaligned(const u8 *addr1,
+ const u8 *addr2)
+{
+ return memcmp(addr1, addr2, ETH_ALEN);
+}
#endif /* __KERNEL__ */
You could probably get the similar speedup by doing xor by byte, rather
than falling back to memcmp.
-
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: [Bugme-new] [Bug 9440] New: Problem in joinning a socket to ipv6 multicast address in specific scenario
On Thu, 22 Nov 2007 11:02:04 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9440 Summary: Problem in joinning a socket to ipv6 multicast address in specific scenario Product: Networking Version: 2.5 KernelVersion: 2.6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: IPV6 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I have a problem in joinning a socket to multicast address in the following scenario (maybe kernel bug): 1. I am changing the mtu size of the eth device to a small size - ifconfig eth1 mtu 100 2. After that i am resizing the mtu for it's orginal size - ifconfig eth1 mtu 1500 3. Now i am running a program i wrote in c that opens a dgram socket (sock_fd[i] = socket(test_data-protocol, SOCK_DGRAM, 0);) and join it to multicast ipv6 address. if i am running this program after steps 1+2 i get the following error: Resource temporarily unavailable when trying to join the socket to the multicast ipv6 address by the system call : struct ipv6_mreq maddr6_group; ... setsockopt(sock_fd, IPPROTO_IPV6, IPV6_JOIN_GROUP, (char *)maddr6_group, sizeof(maddr6_group)); but if i am running my program after reset of the driver (before steps 1+2) it is working fine. if i am trying to run the program and join a socket to ipv4 multicast address (instead of ipv6) i get no errors - this doesn't work only when trying to join to ipv6 multicast address. I got this error in broadcom device (Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 21)) but i don't think this is a bug in broadcom driver, because i tried it on differnt devices, in some devices i got the following error instead: Invalid argument with the same multicast address. As i said before if i am trying to join a socket to multicast ipv6 address before resizing the mtu size it is working fine, all the problems are after step 1+2. All my tries were OS: 1. SLES10.0 - 2.6.16.21-0.8-smp 2. REDHAT5.0 - 2.6.18-8.el5 #1 SMP. I am waiting for an answer, thanks a lot, Aviad Yehezkel. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Nov 23, 2007 2:19 AM, Andi Kleen [EMAIL PROTECTED] wrote: Andy, I like your idea. IMHO, as Rusty said a simple EXPORT_SYMBOL_TO is better. I don't think so. e.g. tcpcong would be very very messy this way. And I wonder if it is possible to export to something like the struct device_driver? If it's possible then it will not limited to modules. Not sure I follow you. Can you expand? I know little about module internal, so if I'm wrong please just don't mind, please point out or just ignore. Kernel symbols could apply to kernel object model, doesn't it? I just think that because the device_driver have a mod_name member (for built-in module), so if something can be done as device driver is registered. - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Friday 23 November 2007 01:25, Rusty Russell wrote: On Thursday 22 November 2007 22:05:45 Christoph Hellwig wrote: On Thu, Nov 22, 2007 at 02:56:22PM +1100, Rusty Russell wrote: This is an interesting idea, thanks for the code! My only question is whether we can get most of this benefit by dropping the indirection of namespaces and have something like EXPORT_SYMBOL_TO(sym, modname)? It doesn't work so well for exporting to a group of modules, but that seems a reasonable line to draw anyway. I'd say exporting to a group of modules is the main use case. E.g. in scsi there would be symbols exported to transport class modules only or lots of the vfs_ symbols would be exported only to stackable filesystems or nfsd. That's my point. If there's a whole class of modules which can use a symbol, why are we ruling out external modules? The point is to get cleaner interfaces. Anything which is kind of internal should only be used by closely related in tree modules which can be updated. Point of is not to be some kind of license enforcer or similar, there are already other mechanisms for that. Just to get the set of really public kernel interfaces down to a manageable level. But I still think exporting only to a single module would be to limiting for this case even. It would work for the TCP-ipv6.ko post child, but not for some of the other networking cases where it makes sense. If that's what you want, why not have a list of permitted modules compiled into the kernel and allow no others? That would not make the relationship explicit, which would not further the goal. -Andi - 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: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Friday 23 November 2007 12:36:22 Andi Kleen wrote: On Friday 23 November 2007 01:25, Rusty Russell wrote: That's my point. If there's a whole class of modules which can use a symbol, why are we ruling out external modules? The point is to get cleaner interfaces. But this doesn't change interfaces at all. It makes modules fail to load unless they're on a permitted list, which now requires maintenance. Anything which is kind of internal should only be used by closely related in tree modules which can be updated. Is there evidence that this is a problem for us? Are there any interfaces you've restricted so far which are causing problems? Point of is not to be some kind of license enforcer or similar, there are already other mechanisms for that. Just to get the set of really public kernel interfaces down to a manageable level. Why do we care what a really public? We treat them all the same, as changeable interfaces. ie. None of them are really public. For example, you put all the udp functions in the udp namespace. But what have we gained? What has become easier to maintain? All those function start with udp_: are people having trouble telling what they're for? If you really want to reduce public interfaces then it's much simpler to mark explicitly what out-of-tree modules can use. We can have a list of symbol names in include/linux/public-exports.h. I just don't see what problems this separation solves. Rusty. - 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: [PATCH 12/21] r8169: confusion between hardware and IP header alignment
Hi Francois,
A Debian user reported that NFS transfers are not working correctly on
a Thecus N2100 (which has two 8169 ports). I confirmed this bug with
2.6.18 and 2.6.22 but couldn't reproduce it with 2.6.23. A git bisect
has revealed that your patch confusion between hardware and IP header
alignment fixes the issue. Thanks for fixing this bug before we even
got a chance to report it. ;-)
I'd like to backport the fix to the 2.6.18 kernel that is in our
stable release and have a couple of questions:
- Does your later patch align the IP header when there is no DMA
constraint fix any bugs or is it merely an improvement?
- Should I change align to 8 for RTL_CFG_1, as it's done in
current kernels?
I'd like to backport only the changes needed to actually fix the bug
in order to make sure I won't break any other devices. The patch
below works for me but I'd like to hear your opinion about my
questions above.
[ I added Adrian Bunk to the CC line since he might be interested in
applying the patch from [1] and possibly [2] to his 2.6.16 branch. ]
--- a/drivers/net/r8169.c 2007-11-22 12:20:51.0 +
+++ b/drivers/net/r8169.c 2007-11-22 12:20:51.0 +
@@ -202,7 +202,7 @@
unsigned int region;
unsigned int align;
} rtl_cfg_info[] = {
- [RTL_CFG_0] = { 1, NET_IP_ALIGN },
+ [RTL_CFG_0] = { 1, 2 },
[RTL_CFG_1] = { 2, NET_IP_ALIGN },
[RTL_CFG_2] = { 2, 8 }
};
@@ -2487,9 +2487,9 @@
if (pkt_size rx_copybreak) {
struct sk_buff *skb;
- skb = dev_alloc_skb(pkt_size + align);
+ skb = dev_alloc_skb(pkt_size + NET_IP_ALIGN);
if (skb) {
- skb_reserve(skb, (align - 1) (u32)skb-data);
+ skb_reserve(skb, NET_IP_ALIGN);
eth_copy_and_sum(skb, sk_buff[0]-data, pkt_size, 0);
*sk_buff = skb;
rtl8169_mark_to_asic(desc, rx_buf_sz);
Some background: the Thecus N2100 is an ARM based NAS device with two
8169 ports. The chips exhibit PCI parity problems so
dev-broken_parity_status is set on this platform. The Debian bug is
http://bugs.debian.org/452069
Here's the output from lspci:
00:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit
Ethernet (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 27
I/O ports at fe00 [size=256]
Memory at 800a0200 (32-bit, non-prefetchable) [size=256]
Expansion ROM at 8008 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Capabilities: [60] Vital Product Data
00:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit
Ethernet (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 30
I/O ports at fe000400 [size=256]
Memory at 800a0300 (32-bit, non-prefetchable) [size=256]
Expansion ROM at 8009 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Capabilities: [60] Vital Product Data
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=864022344caf43dab7fa5219152280d056c6e051
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e9f63f30863fd778a5329e93c7e2208b9bcb5b79
--
Martin Michlmayr
http://www.cyrius.com/
-
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
