* [PATCH] [NETFILTER] Consolidate nf_sockopt and compat_nf_sockopt v2
From: Pavel Emelyanov @ 2007-11-06 8:29 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Netdev List, devel
Both lookup the nf_sockopt_ops object to call the get/set callbacks
from, but they perform it in a completely similar way.
Introduce the helper for finding the ops.
Ported at the top of today's net-2.6 tree to resolve conflict
with the patch from Alexey Dobriyan.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/netfilter/nf_sockopt.c b/net/netfilter/nf_sockopt.c
index 2dfac32..87bc144 100644
--- a/net/netfilter/nf_sockopt.c
+++ b/net/netfilter/nf_sockopt.c
@@ -60,46 +60,57 @@ void nf_unregister_sockopt(struct nf_sockopt_ops *reg)
}
EXPORT_SYMBOL(nf_unregister_sockopt);
-/* Call get/setsockopt() */
-static int nf_sockopt(struct sock *sk, int pf, int val,
- char __user *opt, int *len, int get)
+static struct nf_sockopt_ops *nf_sockopt_find(struct sock *sk, int pf,
+ int val, int get)
{
struct nf_sockopt_ops *ops;
- int ret;
if (sk->sk_net != &init_net)
- return -ENOPROTOOPT;
+ return ERR_PTR(-ENOPROTOOPT);
if (mutex_lock_interruptible(&nf_sockopt_mutex) != 0)
- return -EINTR;
+ return ERR_PTR(-EINTR);
list_for_each_entry(ops, &nf_sockopts, list) {
if (ops->pf == pf) {
if (!try_module_get(ops->owner))
goto out_nosup;
+
if (get) {
- if (val >= ops->get_optmin
- && val < ops->get_optmax) {
- mutex_unlock(&nf_sockopt_mutex);
- ret = ops->get(sk, val, opt, len);
+ if (val >= ops->get_optmin &&
+ val < ops->get_optmax)
goto out;
- }
} else {
- if (val >= ops->set_optmin
- && val < ops->set_optmax) {
- mutex_unlock(&nf_sockopt_mutex);
- ret = ops->set(sk, val, opt, *len);
+ if (val >= ops->set_optmin &&
+ val < ops->set_optmax)
goto out;
- }
}
module_put(ops->owner);
}
}
- out_nosup:
+out_nosup:
+ ops = ERR_PTR(-ENOPROTOOPT);
+out:
mutex_unlock(&nf_sockopt_mutex);
- return -ENOPROTOOPT;
+ return ops;
+}
+
+/* Call get/setsockopt() */
+static int nf_sockopt(struct sock *sk, int pf, int val,
+ char __user *opt, int *len, int get)
+{
+ struct nf_sockopt_ops *ops;
+ int ret;
+
+ ops = nf_sockopt_find(sk, pf, val, get);
+ if (IS_ERR(ops))
+ return PTR_ERR(ops);
+
+ if (get)
+ ret = ops->get(sk, val, opt, len);
+ else
+ ret = ops->set(sk, val, opt, *len);
- out:
module_put(ops->owner);
return ret;
}
@@ -124,51 +135,22 @@ static int compat_nf_sockopt(struct sock *sk, int pf, int val,
struct nf_sockopt_ops *ops;
int ret;
- if (sk->sk_net != &init_net)
- return -ENOPROTOOPT;
-
-
- if (mutex_lock_interruptible(&nf_sockopt_mutex) != 0)
- return -EINTR;
-
- list_for_each_entry(ops, &nf_sockopts, list) {
- if (ops->pf == pf) {
- if (!try_module_get(ops->owner))
- goto out_nosup;
-
- if (get) {
- if (val >= ops->get_optmin
- && val < ops->get_optmax) {
- mutex_unlock(&nf_sockopt_mutex);
- if (ops->compat_get)
- ret = ops->compat_get(sk,
- val, opt, len);
- else
- ret = ops->get(sk,
- val, opt, len);
- goto out;
- }
- } else {
- if (val >= ops->set_optmin
- && val < ops->set_optmax) {
- mutex_unlock(&nf_sockopt_mutex);
- if (ops->compat_set)
- ret = ops->compat_set(sk,
- val, opt, *len);
- else
- ret = ops->set(sk,
- val, opt, *len);
- goto out;
- }
- }
- module_put(ops->owner);
- }
+ ops = nf_sockopt_find(sk, pf, val, get);
+ if (IS_ERR(ops))
+ return PTR_ERR(ops);
+
+ if (get) {
+ if (ops->compat_get)
+ ret = ops->compat_get(sk, val, opt, len);
+ else
+ ret = ops->get(sk, val, ops, len);
+ } else {
+ if (ops->compat_set)
+ ret = ops->compat_set(sk, val, ops, *len);
+ else
+ ret = ops->set(sk, val, ops, *len);
}
- out_nosup:
- mutex_unlock(&nf_sockopt_mutex);
- return -ENOPROTOOPT;
- out:
module_put(ops->owner);
return ret;
}
^ permalink raw reply related
* Re: Endianness problem with u32 classifier hash masks
From: Radu Rendec @ 2007-11-06 8:09 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: hadi, netdev
In-Reply-To: <472FAF29.7050704@o2.pl>
On Tue, 2007-11-06 at 01:02 +0100, Jarek Poplawski wrote:
> > I meant that it didnt seem necessary to me you have to do the conversion
> > back and forth of the hmask as you do in the u32_change(). The basis of
> > the patch i posted - which is based on yours - is to remove that change.
> > If that doesnt work, please just send your patch as is and we can think
> > of optimization later.
Yup, you're right. Bitwise anding is the same regardless of the byte
ordering of the operands. As long as you don't have one operand in host
order and the other in net order, it's ok.
However, Jarek's computations with his mask and your patch seemed
correct to me yesterday. And I think I know the answer: data must be
changed to host order _before_ shifting. I mean something like this:
static __inline__ unsigned u32_hash_fold(u32 key, struct tc_u32_sel
*sel, u8 fshift)
{
unsigned h = ntohl(key & sel->hmask) >> fshift;
return h;
}
And everything else remains unchanged (except for the ntohl() applied to
hmask before computing fshift). In other words, the idea behind your
patch now seems to be right (it's easier not to convert the hmask back
and forth as long as ntohl() in u32_hash_fold() is applied before
shifting).
> > On paper i get the same result with the new or old scheme for the bucket selection.
> > As i stated on the patch - i never did test the theory.
Well, neither did I (about what I stated above). But still I think,
Jarek was right yesterday and I can't figure out how it worked for you
on paper. How about this new version?
> In Radu's patch all calculations are done with data in host order, and
> still only this one transformation on the fast path. In your version orders
> are mixed, and this makes a difference. And, since the old scheme gives
> wrong result on little endian, I don't get it why you would want it again?
> So, with your patch with the same address and mask: 00.00.0f.f0 (host order
> on little endian) we have:
>
> on big endian (net and host order):
> f0.0f.00.00 >> 4 gives: ff.00.00.00 with lsb: ff
> on little endian (net order):
> f0.0f.00.00 >> 4 gives: 0f.00.0f.00 then ntohl: 00.0f.00.0f with lsb: 0f
> on little endian with Radu's patch (host order):
> 00.00.0f.f0 >> 4 gives: 00.00.00.ff with lsb: ff
Ok, but now (moving ntohl() before shifting), it's like this:
ntohl(f0.0f.00.00) gives: 00.00.0f.f0, then >>4 gives 00.00.00.ff
> >> Radu, as far as I know Jamal (from reading) he most probably is busy with
> >> some conference!
> >
> > I actually have a day job and have to show up and meet TheMan, Jarek;->
> > Most of the days at work, i dont have time to look at external email
> > account - but you can bet all horses you own i will get back to you
> > within a few hours if you CC me on email.
>
>
> No offence! I've thought Radu gets a bit impatient, and don't know if he
> knows about your scientific and international achievements. On the other
> hand I can't imagine why anybody would ever like to go out of Canada!
> (Btw, in Polish the second meaning of Kanada is something like paradise
> or extreme welfare.) And, on the other hand, I'm very honoured, but I'm
> a really modest guy, far from this universities' high life here...
Actually I'm not impatient at all, because the shaping machine at the
ISP where I work is already patched with my original patch, and cpu
usage has gone from 100% to 8% after implementing hashes ;->
Still, I thought it would be a good idea to share what I found out with
the maintainers and have it fixed in the next kernel release. Now all I
want is to help you out fixing it "right" and test it. And... who
knows... if it's fixed in the official kernel, I won't need to bother
patching if i upgrade my machine ;->
BTW, I also have a steady job and don't have much time there to work on
the kernel. It's ok.
> >> Since these patches aren't so big I think you could
> >> try Jamal's at first, and if it doesn't work, and nothing new from Jamal
> >> in the meantime, resend your version. Cutdown in u32_change() seems to
> >> add more to the fastpath, but maybe Jamal thinks about something else.
> >
> > I mean do most work on slow/config path.
Well, I think it's pretty clear now: I'll try my version of Jamal's
patch :) But not right now, because I also have to show up at work.
Cheers,
Radu Rendec
^ permalink raw reply
* [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2007-11-06 8:51 UTC (permalink / raw)
To: linuxppc-dev, netdev, jgarzik
The patch updates the booting-without-of.txt-file.
There is a description for the case
if mdio data and clock pins are on different processor ports.
It is a extending for e-mail "[PATCH v3] using mii-bitbang on different processor ports".
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
--
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index a96e853..497d8d8 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1956,6 +1956,12 @@ platforms are moved over to use the flattened-device-tree model.
fsl,mdc-pin = <13>;
};
+ The "reg"-property may have also depending on board design
+ the following form:
+ reg = <10d40 14 10d60 14>;
+ In that case the pin for mdio data controlling is on the port C,
+ and the pin for mdio clock controlling is on the port D.
+
v) Baud Rate Generators
Currently defined compatibles:
^ permalink raw reply related
* Re: problems with ib-bonding of 2.6.24-rc1
From: Moni Shoua @ 2007-11-06 8:16 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <47300F46.9000507@voltaire.com>
Same thing happens with Ethernet slave - Intel 82546GB Gigabit Ethernet Controller (rev 03)
^ permalink raw reply
* Re: [BUG] in inet6_create
From: Pavel Emelyanov @ 2007-11-06 8:14 UTC (permalink / raw)
To: Roel Kluin; +Cc: netdev, linux-net
In-Reply-To: <472B638C.1030001@tiscali.nl>
Roel Kluin wrote:
> Pavel Emelyanov wrote:
>> Roel Kluin wrote:
>>> Roel Kluin wrote:
>>>> I got this bug recently, I am not sure whether this is related to any previously
>>>> reported ones. It was a recently pulled git kernel. Also I have been hacking my
>>>> kernel a bit lately, but I think that I haven't got any changes in the currently
>>>> running kernel.
>>>>
>>>> FYI: my network card was not running (module not loaded, and I just started
>>>> thunderbird)
>>>>
>>>> Roel
>>>>
>>>> More information needed?
>> Yes, please.
>>
>> Can you send us the disasm (objdump -dr) of your ipv6 module.
>> More precisely - I need the disassembled inet6_create() function to
>> figure out where exactly this thing happened.
>
> I was very lucky to still be able to produce this: When the bug hit me, I had just
> recompiled a new kernel, however, since I had previously git-pulled, (but not yet
> compiled) the old module was not overwritten.
>
> to answer the question in your other mail - whether I hacked this kernel - I am not
> 100% certain, I am certain, however that I did not touch IPv6 code, and my changes
> to net code were very trivial oneliner changes that I have previously posted, and
> were generally accepted as fixes.
> --
> 000002f0 <inet6_create>:
Hm... The oops says that the buggy place is <inet6_create>+0x5f, that is
(according to this dump) 0x2f0 + 0x5f = 0x34f, but:
1. there's no instruction at this address (there are 0x34e and 0x355)
2. the codeline (... 1c <8b> 00 0f 18 ...) is not present here
There's something wrong with this oops...
Is this reproducible? If yes, can you try the non-patched net-2.6 kernel.
Thanks,
Pavel
> 2f0: 55 push %ebp
> 2f1: bd 9f ff ff ff mov $0xffffff9f,%ebp
> 2f6: 57 push %edi
> 2f7: 56 push %esi
> 2f8: 89 ce mov %ecx,%esi
> 2fa: 53 push %ebx
> 2fb: 83 ec 20 sub $0x20,%esp
> 2fe: 3d 00 00 00 00 cmp $0x0,%eax
> 2ff: R_386_32 init_net
> 303: 89 54 24 10 mov %edx,0x10(%esp)
> 307: 74 0a je 313 <inet6_create+0x23>
> 309: 83 c4 20 add $0x20,%esp
> 30c: 89 e8 mov %ebp,%eax
> 30e: 5b pop %ebx
> 30f: 5e pop %esi
> 310: 5f pop %edi
> 311: 5d pop %ebp
> 312: c3 ret
> 313: 8b 42 3c mov 0x3c(%edx),%eax
> 316: 83 e8 02 sub $0x2,%eax
> 319: 66 83 f8 01 cmp $0x1,%ax
> 31d: 76 0e jbe 32d <inet6_create+0x3d>
> 31f: 8b 0d 00 00 00 00 mov 0x0,%ecx
> 321: R_386_32 inet_ehash_secret
> 325: 85 c9 test %ecx,%ecx
> 327: 0f 84 76 02 00 00 je 5a3 <inet6_create+0x2b3>
> 32d: c7 44 24 18 00 00 00 movl $0x0,0x18(%esp)
> 334: 00
> 335: 31 d2 xor %edx,%edx
> 337: 31 c9 xor %ecx,%ecx
> 339: b8 00 00 00 00 mov $0x0,%eax
> 33a: R_386_32 rcu_lock_map
> 33e: c7 44 24 08 35 03 00 movl $0x335,0x8(%esp)
> 345: 00
> 342: R_386_32 .text
> 346: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp)
> 34d: 00
> 34e: c7 04 24 02 00 00 00 movl $0x2,(%esp)
> 355: e8 fc ff ff ff call 356 <inet6_create+0x66>
> 356: R_386_PC32 lock_acquire
> 35a: 8b 44 24 10 mov 0x10(%esp),%eax
> 35e: 8b 78 3c mov 0x3c(%eax),%edi
> 361: 0f bf c7 movswl %di,%eax
> 364: c1 e0 03 shl $0x3,%eax
> 367: 8b 98 00 00 00 00 mov 0x0(%eax),%ebx
> 369: R_386_32 .bss
> 36d: 8d 90 00 00 00 00 lea 0x0(%eax),%edx
> 36f: R_386_32 .bss
> 373: 89 5c 24 1c mov %ebx,0x1c(%esp)
> 377: 8b 44 24 1c mov 0x1c(%esp),%eax
> 37b: 8b 00 mov (%eax),%eax
> 37d: 8d 44 20 00 lea 0x0(%eax),%eax
> 381: 39 d3 cmp %edx,%ebx
> 383: bd a2 ff ff ff mov $0xffffffa2,%ebp
> 388: 75 3a jne 3c4 <inet6_create+0xd4>
> 38a: e9 23 02 00 00 jmp 5b2 <inet6_create+0x2c2>
> 38f: 90 nop
> 390: 85 f6 test %esi,%esi
> 392: 0f 84 5d 02 00 00 je 5f5 <inet6_create+0x305>
> 398: 66 85 c0 test %ax,%ax
> 39b: 90 nop
> 39c: 8d 74 26 00 lea 0x0(%esi),%esi
> 3a0: 74 31 je 3d3 <inet6_create+0xe3>
> 3a2: 8b 1b mov (%ebx),%ebx
> 3a4: 89 5c 24 1c mov %ebx,0x1c(%esp)
> 3a8: 8b 44 24 1c mov 0x1c(%esp),%eax
> 3ac: 8b 00 mov (%eax),%eax
> 3ae: 8d 44 20 00 lea 0x0(%eax),%eax
> 3b2: 0f bf c7 movswl %di,%eax
> 3b5: 8d 04 c5 00 00 00 00 lea 0x0(,%eax,8),%eax
> 3b8: R_386_32 .bss
> 3bc: 39 d8 cmp %ebx,%eax
> 3be: 0f 84 e9 01 00 00 je 5ad <inet6_create+0x2bd>
> 3c4: 0f b7 43 0a movzwl 0xa(%ebx),%eax
> 3c8: 0f b7 c8 movzwl %ax,%ecx
> 3cb: 39 ce cmp %ecx,%esi
> 3cd: 75 c1 jne 390 <inet6_create+0xa0>
> 3cf: 85 f6 test %esi,%esi
> 3d1: 74 cf je 3a2 <inet6_create+0xb2>
> 3d3: 8b 43 14 mov 0x14(%ebx),%eax
> 3d6: 85 c0 test %eax,%eax
> 3d8: 7e 12 jle 3ec <inet6_create+0xfc>
> 3da: e8 fc ff ff ff call 3db <inet6_create+0xeb>
> 3db: R_386_PC32 capable
> 3df: 85 c0 test %eax,%eax
> 3e1: bd ff ff ff ff mov $0xffffffff,%ebp
> 3e6: 0f 84 99 01 00 00 je 585 <inet6_create+0x295>
> 3ec: 8b 43 10 mov 0x10(%ebx),%eax
> 3ef: 8b 54 24 10 mov 0x10(%esp),%edx
> 3f3: b9 ec 03 00 00 mov $0x3ec,%ecx
> 3f4: R_386_32 .text
> 3f8: 89 42 08 mov %eax,0x8(%edx)
> 3fb: 0f b6 43 18 movzbl 0x18(%ebx),%eax
> 3ff: 8b 7b 0c mov 0xc(%ebx),%edi
> 402: 88 44 24 17 mov %al,0x17(%esp)
> 406: 0f b6 53 19 movzbl 0x19(%ebx),%edx
> 40a: b8 00 00 00 00 mov $0x0,%eax
> 40b: R_386_32 rcu_lock_map
> 40f: 88 54 24 16 mov %dl,0x16(%esp)
> 413: ba 01 00 00 00 mov $0x1,%edx
> 418: e8 fc ff ff ff call 419 <inet6_create+0x129>
> 419: R_386_PC32 lock_release
> 41d: 8b 57 70 mov 0x70(%edi),%edx
> 420: 85 d2 test %edx,%edx
> 422: 0f 84 36 02 00 00 je 65e <inet6_create+0x36e>
> 428: b9 d0 00 00 00 mov $0xd0,%ecx
> 42d: ba 0a 00 00 00 mov $0xa,%edx
> 432: b8 00 00 00 00 mov $0x0,%eax
> 433: R_386_32 init_net
> 437: 89 3c 24 mov %edi,(%esp)
> 43a: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp)
> 441: 00
> 442: bd 97 ff ff ff mov $0xffffff97,%ebp
> 447: e8 fc ff ff ff call 448 <inet6_create+0x158>
> 448: R_386_PC32 sk_alloc
> 44c: 85 c0 test %eax,%eax
> 44e: 89 c7 mov %eax,%edi
> 450: 0f 84 b3 fe ff ff je 309 <inet6_create+0x19>
> 456: 89 c2 mov %eax,%edx
> 458: 8b 44 24 10 mov 0x10(%esp),%eax
> 45c: e8 fc ff ff ff call 45d <inet6_create+0x16d>
> 45d: R_386_PC32 sock_init_data
> 461: 80 64 24 17 03 andb $0x3,0x17(%esp)
> 466: 0f b6 54 24 17 movzbl 0x17(%esp),%edx
> 46b: 0f b6 47 28 movzbl 0x28(%edi),%eax
> 46f: c1 e2 02 shl $0x2,%edx
> 472: 83 e0 f3 and $0xfffffff3,%eax
> 475: 09 d0 or %edx,%eax
> 477: 88 47 28 mov %al,0x28(%edi)
> 47a: 0f b6 44 24 16 movzbl 0x16(%esp),%eax
> 47f: a8 01 test $0x1,%al
> 481: 74 04 je 487 <inet6_create+0x197>
> 483: c6 47 03 01 movb $0x1,0x3(%edi)
> 487: 0f b6 97 3f 02 00 00 movzbl 0x23f(%edi),%edx
> 48e: c1 e8 02 shr $0x2,%eax
> 491: 83 e0 01 and $0x1,%eax
> 494: 01 c0 add %eax,%eax
> 496: 83 e2 fd and $0xfffffffd,%edx
> 499: 09 c2 or %eax,%edx
> 49b: 88 97 3f 02 00 00 mov %dl,0x23f(%edi)
> 4a1: 8b 44 24 10 mov 0x10(%esp),%eax
> 4a5: 66 83 78 3c 03 cmpw $0x3,0x3c(%eax)
> 4aa: 0f 84 64 01 00 00 je 614 <inet6_create+0x324>
> 4b0: 89 f2 mov %esi,%edx
> 4b2: c7 87 18 02 00 00 00 movl $0x0,0x218(%edi)
> 4b9: 00 00 00
> 4b8: R_386_32 inet_sock_destruct
> 4bc: 66 c7 07 0a 00 movw $0xa,(%edi)
> 4c1: 88 57 29 mov %dl,0x29(%edi)
> 4c4: 8b 43 0c mov 0xc(%ebx),%eax
> 4c7: 8b 40 40 mov 0x40(%eax),%eax
> 4ca: 89 87 14 02 00 00 mov %eax,0x214(%edi)
> 4d0: 8b 47 20 mov 0x20(%edi),%eax
> 4d3: 8b 48 74 mov 0x74(%eax),%ecx
> 4d6: 83 e9 70 sub $0x70,%ecx
> 4d9: 8d 0c 0f lea (%edi,%ecx,1),%ecx
> 4dc: 89 8f 1c 02 00 00 mov %ecx,0x21c(%edi)
> 4e2: 0f b6 41 46 movzbl 0x46(%ecx),%eax
> 4e6: 66 c7 41 3c ff ff movw $0xffff,0x3c(%ecx)
> 4ec: 66 c7 41 3e ff ff movw $0xffff,0x3e(%ecx)
> 4f2: 83 e0 e7 and $0xffffffe7,%eax
> 4f5: 83 c8 09 or $0x9,%eax
> 4f8: 88 41 46 mov %al,0x46(%ecx)
> 4fb: 0f b6 15 00 00 00 00 movzbl 0x0,%edx
> 4fe: R_386_32 sysctl_ipv6_bindv6only
> 502: 83 e0 df and $0xffffffdf,%eax
> 505: 83 e2 01 and $0x1,%edx
> 508: c1 e2 05 shl $0x5,%edx
> 50b: 09 d0 or %edx,%eax
> 50d: 88 41 46 mov %al,0x46(%ecx)
> 510: 80 8f 3f 02 00 00 10 orb $0x10,0x23f(%edi)
> 517: 66 c7 87 30 02 00 00 movw $0xffff,0x230(%edi)
> 51e: ff ff
> 520: c6 87 3d 02 00 00 01 movb $0x1,0x23d(%edi)
> 527: c7 87 40 02 00 00 00 movl $0x0,0x240(%edi)
> 52e: 00 00 00
> 531: c7 87 48 02 00 00 00 movl $0x0,0x248(%edi)
> 538: 00 00 00
> 53b: a1 04 00 00 00 mov 0x4,%eax
> 53c: R_386_32 ipv4_config
> 540: 85 c0 test %eax,%eax
> 542: 0f b7 87 2a 02 00 00 movzwl 0x22a(%edi),%eax
> 549: 0f 94 87 3e 02 00 00 sete 0x23e(%edi)
> 550: 66 85 c0 test %ax,%ax
> 553: 0f 85 a3 00 00 00 jne 5fc <inet6_create+0x30c>
> 559: 8b 47 20 mov 0x20(%edi),%eax
> 55c: 31 ed xor %ebp,%ebp
> 55e: 8b 50 14 mov 0x14(%eax),%edx
> 561: 85 d2 test %edx,%edx
> 563: 0f 84 a0 fd ff ff je 309 <inet6_create+0x19>
> 569: 89 f8 mov %edi,%eax
> 56b: ff d2 call *%edx
> 56d: 85 c0 test %eax,%eax
> 56f: 89 c5 mov %eax,%ebp
> 571: 0f 84 92 fd ff ff je 309 <inet6_create+0x19>
> 577: 89 f8 mov %edi,%eax
> 579: e8 fc ff ff ff call 57a <inet6_create+0x28a>
> 57a: R_386_PC32 sk_common_release
> 57e: 66 90 xchg %ax,%ax
> 580: e9 84 fd ff ff jmp 309 <inet6_create+0x19>
> 585: b8 00 00 00 00 mov $0x0,%eax
> 586: R_386_32 rcu_lock_map
> 58a: b9 85 05 00 00 mov $0x585,%ecx
> 58b: R_386_32 .text
> 58f: ba 01 00 00 00 mov $0x1,%edx
> 594: e8 fc ff ff ff call 595 <inet6_create+0x2a5>
> 595: R_386_PC32 lock_release
> 599: 83 c4 20 add $0x20,%esp
> 59c: 89 e8 mov %ebp,%eax
> 59e: 5b pop %ebx
> 59f: 5e pop %esi
> 5a0: 5f pop %edi
> 5a1: 5d pop %ebp
> 5a2: c3 ret
> 5a3: e8 fc ff ff ff call 5a4 <inet6_create+0x2b4>
> 5a4: R_386_PC32 build_ehash_secret
> 5a8: e9 80 fd ff ff jmp 32d <inet6_create+0x3d>
> 5ad: bd a3 ff ff ff mov $0xffffffa3,%ebp
> 5b2: 83 7c 24 18 02 cmpl $0x2,0x18(%esp)
> 5b7: 74 cc je 585 <inet6_create+0x295>
> 5b9: b9 b9 05 00 00 mov $0x5b9,%ecx
> 5ba: R_386_32 .text
> 5be: ba 01 00 00 00 mov $0x1,%edx
> 5c3: b8 00 00 00 00 mov $0x0,%eax
> 5c4: R_386_32 rcu_lock_map
> 5c8: e8 fc ff ff ff call 5c9 <inet6_create+0x2d9>
> 5c9: R_386_PC32 lock_release
> 5cd: ff 44 24 18 incl 0x18(%esp)
> 5d1: 83 7c 24 18 01 cmpl $0x1,0x18(%esp)
> 5d6: 74 5d je 635 <inet6_create+0x345>
> 5d8: 89 74 24 08 mov %esi,0x8(%esp)
> 5dc: c7 44 24 04 0a 00 00 movl $0xa,0x4(%esp)
> 5e3: 00
> 5e4: c7 04 24 1b 00 00 00 movl $0x1b,(%esp)
> 5e7: R_386_32 .rodata.str1.1
> 5eb: e8 fc ff ff ff call 5ec <inet6_create+0x2fc>
> 5ec: R_386_PC32 request_module
> 5f0: e9 40 fd ff ff jmp 335 <inet6_create+0x45>
> 5f5: 89 ce mov %ecx,%esi
> 5f7: e9 d7 fd ff ff jmp 3d3 <inet6_create+0xe3>
> 5fc: 8b 57 20 mov 0x20(%edi),%edx
> 5ff: 66 c1 c0 08 rol $0x8,%ax
> 603: 66 89 87 38 02 00 00 mov %ax,0x238(%edi)
> 60a: 89 f8 mov %edi,%eax
> 60c: ff 52 44 call *0x44(%edx)
> 60f: e9 45 ff ff ff jmp 559 <inet6_create+0x269>
> 614: 81 fe ff 00 00 00 cmp $0xff,%esi
> 61a: 66 89 b7 2a 02 00 00 mov %si,0x22a(%edi)
> 621: 0f 85 89 fe ff ff jne 4b0 <inet6_create+0x1c0>
> 627: 83 ca 08 or $0x8,%edx
> 62a: 88 97 3f 02 00 00 mov %dl,0x23f(%edi)
> 630: e9 7b fe ff ff jmp 4b0 <inet6_create+0x1c0>
> 635: 8b 54 24 10 mov 0x10(%esp),%edx
> 639: 0f bf 42 3c movswl 0x3c(%edx),%eax
> 63d: 89 74 24 08 mov %esi,0x8(%esp)
> 641: c7 44 24 04 0a 00 00 movl $0xa,0x4(%esp)
> 648: 00
> 649: c7 04 24 00 00 00 00 movl $0x0,(%esp)
> 64c: R_386_32 .rodata.str1.1
> 650: 89 44 24 0c mov %eax,0xc(%esp)
> 654: e8 fc ff ff ff call 655 <inet6_create+0x365>
> 655: R_386_PC32 request_module
> 659: e9 d7 fc ff ff jmp 335 <inet6_create+0x45>
> 65e: c7 44 24 0c a2 00 00 movl $0xa2,0xc(%esp)
> 665: 00
> 666: c7 44 24 08 a0 00 00 movl $0xa0,0x8(%esp)
> 66d: 00
> 66a: R_386_32 .rodata.str1.4
> 66e: c7 44 24 04 2e 00 00 movl $0x2e,0x4(%esp)
> 675: 00
> 672: R_386_32 .rodata.str1.1
> 676: c7 04 24 e0 00 00 00 movl $0xe0,(%esp)
> 679: R_386_32 .rodata.str1.4
> 67d: e8 fc ff ff ff call 67e <inet6_create+0x38e>
> 67e: R_386_PC32 printk
> 682: e9 a1 fd ff ff jmp 428 <inet6_create+0x138>
> 687: 89 f6 mov %esi,%esi
> 689: 8d bc 27 00 00 00 00 lea 0x0(%edi),%edi
>
> 00000690 <inet6_destroy_sock>:
>
^ permalink raw reply
* Re: [PATCH 0/4] NET : struct proto diet
From: David Miller @ 2007-11-06 7:43 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <472F5860.4010607@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Mon, 05 Nov 2007 18:52:32 +0100
> This patch series does some cleanup and optimization.
>
> [PATCH 1/4] NET : defines an infrastructure to keep 'inuse' changes in
> an efficent SMP/NUMA way.
> [PATCH 2/4] NET : makes ipv4 use the {DEFINE|REF}_PROTO_INUSE
> infrastructure
> [PATCH 3/4] NET : makes ipv6 use the {DEFINE|REF}_PROTO_INUSE
> infrastructure
> [PATCH 4/4] NET : makes sctp use the {DEFINE|REF}_PROTO_INUSE
> infrastructure
Applied, and because I love DCCP I added the following
patch on top.
>From 43d36c1ceff9ce1ed5a9ba87ea91a99f4f79ad00 Mon Sep 17 00:00:00 2001
From: David S. Miller <davem@sunset.davemloft.net>
Date: Mon, 5 Nov 2007 23:42:25 -0800
Subject: [PATCH] [DCCP]: Use DEFINE_PROTO_INUSE infrastructure.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/dccp/ipv4.c | 3 +++
net/dccp/ipv6.c | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 01a6a80..db17b83 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -922,6 +922,8 @@ static struct timewait_sock_ops dccp_timewait_sock_ops = {
.twsk_obj_size = sizeof(struct inet_timewait_sock),
};
+DEFINE_PROTO_INUSE(dccp_v4)
+
static struct proto dccp_v4_prot = {
.name = "DCCP",
.owner = THIS_MODULE,
@@ -950,6 +952,7 @@ static struct proto dccp_v4_prot = {
.compat_setsockopt = compat_dccp_setsockopt,
.compat_getsockopt = compat_dccp_getsockopt,
#endif
+ REF_PROTO_INUSE(dccp_v4)
};
static struct net_protocol dccp_v4_protocol = {
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 62428ff..87c98fb 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -1107,6 +1107,8 @@ static struct timewait_sock_ops dccp6_timewait_sock_ops = {
.twsk_obj_size = sizeof(struct dccp6_timewait_sock),
};
+DEFINE_PROTO_INUSE(dccp_v6)
+
static struct proto dccp_v6_prot = {
.name = "DCCPv6",
.owner = THIS_MODULE,
@@ -1135,6 +1137,7 @@ static struct proto dccp_v6_prot = {
.compat_setsockopt = compat_dccp_setsockopt,
.compat_getsockopt = compat_dccp_getsockopt,
#endif
+ REF_PROTO_INUSE(dccp_v6)
};
static struct inet6_protocol dccp_v6_protocol = {
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH 2.6.23] [PPP]: L2TP: Fix oops in transmit and receive paths
From: David Miller @ 2007-11-06 7:33 UTC (permalink / raw)
To: jchapman; +Cc: netdev
In-Reply-To: <200711051717.lA5HHd9u013301@quickie.katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Mon, 5 Nov 2007 17:17:39 GMT
> [PPP]: L2TP: Fix oops in transmit and receive paths
>
> Changes made on 18-sep to fix skb handling in the pppol2tp driver
> broke the transmit and receive paths. Users are only running into this
> now because distros are now using 2.6.23 and I must have messed up
> when I tested the change.
>
> For receive, we now do our own calculation of how much to pull from
> the skb (variable length L2TP header) rather than using
> skb_transport_offset(). Also, if the skb isn't a data packet, it must
> be passed back to UDP with skb->data pointing to the UDP header.
>
> For transmit, make sure skb->sk is set up because ip_queue_xmit()
> needs it.
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
Applied, thanks James.
I'll queue this up for -stable too.
^ permalink raw reply
* Re: problems with ib-bonding of 2.6.24-rc1
From: Moni Shoua @ 2007-11-06 6:52 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <20510.1194311154@death>
Jay Vosburgh wrote:
> Moni Shoua <monisonlists@gmail.com> wrote:
>
>> Basically, what I see is that after a while commands like ifconfig or ip stucks.
>> I only use sysfs to configure bonding (which also stucks after a while).
>
> I've fooled with setting various things in bonding in the
> current linux-2.6 git kernel, and I'm not seeing the failure you
> describe. Can you provide some step by step instructions, including the
> type of system, bonding mode, options, number and type of slaves, etc,
> to induce the failure?
>
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
Machine
-------------------
ARCH: x86_64
OS: Redhat EL Server 5
bonding
-------------------
mod. options: none
mode: 1 (active-backup)
miimon: 100
slaves: IP over InfiniBand
Below is a scenario that ends up with what I described
[root@linux root]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:04:23:B3:25:C4
inet addr:172.30.3.234 Bcast:172.30.255.255 Mask:255.255.0.0
inet6 addr: fe80::204:23ff:feb3:25c4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:333219 errors:0 dropped:0 overruns:0 frame:0
TX packets:130880 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:248023834 (236.5 MiB) TX bytes:35230500 (33.5 MiB)
Base address:0xdc00 Memory:fcea0000-fcec0000
eth1 Link encap:Ethernet HWaddr 00:04:23:B3:25:C5
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Base address:0xdc80 Memory:fcee0000-fcf00000
ib0 Link encap:InfiniBand HWaddr 00:00:04:04:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
BROADCAST MULTICAST MTU:2044 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:128
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
ib1 Link encap:InfiniBand HWaddr 00:00:04:05:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
BROADCAST MULTICAST MTU:2044 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:128
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:44 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7145 (6.9 KiB) TX bytes:7145 (6.9 KiB)
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[root@linux root]# modprobe bonding
[root@linux root]# echo 1 > /sys/class/net/bond0/bonding/mode
[root@linux root]# echo 100 > /sys/class/net/bond0/bonding/miimon
[root@linux root]# echo +ib0 > /sys/class/net/bond0/bonding/slaves
[root@linux root]# echo +ib1 > /sys/class/net/bond0/bonding/slaves
[root@linux root]# ifconfig bond0 192.168.3.234
[root@linux root]# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:04:23:b3:25:c4 brd ff:ff:ff:ff:ff:ff
inet 172.30.3.234/16 brd 172.30.255.255 scope global eth0
inet6 fe80::204:23ff:feb3:25c4/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:04:23:b3:25:c5 brd ff:ff:ff:ff:ff:ff
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
5: ib0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 128
link/infiniband 00:00:04:04:fe:80:00:00:00:00:00:00:00:08:f1:04:03:96:e8:a9 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
6: ib1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 128
link/infiniband 00:00:04:05:fe:80:00:00:00:00:00:00:00:08:f1:04:03:96:e8:aa brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/infiniband 00:00:04:04:fe:80:00:00:00:00:00:00:00:08:f1:04:03:96:e8:a9 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
inet 192.168.3.234/24 brd 192.168.3.255 scope global bond0
inet6 fe80::208:f104:396:e8a9/64 scope link
valid_lft forever preferred_lft forever
[root@linux root]# ping -c 1 192.168.3.232
PING 192.168.3.232 (192.168.3.232) 56(84) bytes of data.
64 bytes from 192.168.3.232: icmp_seq=1 ttl=64 time=0.112 ms
--- 192.168.3.232 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.112/0.112/0.112/0.000 ms
[root@linux root]# ifconfig
bond0 Link encap:InfiniBand HWaddr 00:00:04:04:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
inet addr:192.168.3.234 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::208:f104:396:e8a9/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:53 errors:0 dropped:0 overruns:0 frame:0
TX packets:23 errors:0 dropped:7 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4172 (4.0 KiB) TX bytes:4085 (3.9 KiB)
eth0 Link encap:Ethernet HWaddr 00:04:23:B3:25:C4
inet addr:172.30.3.234 Bcast:172.30.255.255 Mask:255.255.0.0
inet6 addr: fe80::204:23ff:feb3:25c4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:334158 errors:0 dropped:0 overruns:0 frame:0
TX packets:131146 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:248115222 (236.6 MiB) TX bytes:35272782 (33.6 MiB)
Base address:0xdc00 Memory:fcea0000-fcec0000
ib0 Link encap:InfiniBand HWaddr 00:00:04:04:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:29 errors:0 dropped:0 overruns:0 frame:0
TX packets:23 errors:0 dropped:7 overruns:0 carrier:0
collisions:0 txqueuelen:128
RX bytes:2284 (2.2 KiB) TX bytes:4085 (3.9 KiB)
ib1 Link encap:InfiniBand HWaddr 00:00:04:05:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:24 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:128
RX bytes:1888 (1.8 KiB) TX bytes:0 (0.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:44 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7145 (6.9 KiB) TX bytes:7145 (6.9 KiB)
[root@linux root]# cat /sys/class/net/bond0/bonding/active_slave
ib0
[root@linux root]# ip a s dev bond0
^ permalink raw reply
* Re: [PATCH] Clean the ip_sockglue.c from some ugly ifdefs
From: David Miller @ 2007-11-06 5:32 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4729F642.7000709@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 01 Nov 2007 18:52:34 +0300
> The #idfed CONFIG_IP_MROUTE is sometimes places inside the if-s,
> which looks completely bad. Similar ifdefs inside the functions
> looks a bit better, but they are also not recommended to be used.
>
> Provide an ifdef-ed ip_mroute_opt() helper to cleanup the code.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks Pavel.
^ permalink raw reply
* Re: [PATCH] decnet: "addr" module param can't be __initdata
From: David Miller @ 2007-11-06 5:31 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, devel
In-Reply-To: <20071101153629.GA16499@localhost.sw.ru>
From: Alexey Dobriyan <adobriyan@sw.ru>
Date: Thu, 1 Nov 2007 18:36:29 +0300
> sysfs keeps references to module parameters via /sys/module/*/parameters,
> so marking them as __initdata can't work.
>
> Steps to reproduce:
>
> modprobe decnet
> cat /sys/module/decnet/parameters/addr
>
> BUG: unable to handle kernel paging request at virtual address f88cd410
...
> Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] [IPv6] SNMP: Restore Udp6InErrors incrementation
From: David Miller @ 2007-11-06 5:29 UTC (permalink / raw)
To: herbert; +Cc: mitch, netdev, yoshfuji
In-Reply-To: <20071101150500.GB7965@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 1 Nov 2007 23:05:00 +0800
> On Thu, Nov 01, 2007 at 10:46:38PM +0900, Mitsuru Chinen wrote:
> > As the checksum verification is postponed till user calls recv or poll,
> > the inrementation of Udp6InErrors counter should be also postponed.
> > Currently, it is postponed in non-blocking operation case. However it
> > should be postponed in all case like the IPv4 code.
> >
> > Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
>
> Looks good to me. Thanks for catching this!
Applied.
^ permalink raw reply
* Re: [PATCH] Remove /proc/net/stat/*_arp_cache upon module removal
From: David Miller @ 2007-11-06 5:28 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, devel
In-Reply-To: <20071101135235.GB8639@localhost.sw.ru>
From: Alexey Dobriyan <adobriyan@sw.ru>
Date: Thu, 1 Nov 2007 16:52:35 +0300
> neigh_table_init_no_netlink() creates them, but they aren't removed anywhere.
...
> Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
Applied, thanks Alexey.
^ permalink raw reply
* Re: [PATCH 2/2][IPV6] Consolidate the ip cork destruction in ip6_output.c
From: David Miller @ 2007-11-06 5:04 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <472B4AD2.5050202@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 02 Nov 2007 19:05:38 +0300
> The ip6_push_pending_frames and ip6_flush_pending_frames do the
> same things to flush the sock's cork. Move this into a separate
> function and save ~100 bytes from the .text
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2][IPV4] Consolidate the ip cork destruction in ip_output.c
From: David Miller @ 2007-11-06 5:03 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <472B4A76.2040801@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 02 Nov 2007 19:04:06 +0300
> The ip_push_pending_frames and ip_flush_pending_frames do the
> same things to flush the sock's cork. Move this into a separate
> function and save ~80 bytes from the .text
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH] add support for smc91x ethernet interface on zylonite
From: Nicolas Pitre @ 2007-11-06 3:37 UTC (permalink / raw)
To: eric miao; +Cc: Jeff Garzik, netdev
In-Reply-To: <f17812d70711051645p4d1a8e44mbc21413cc6ef12ba@mail.gmail.com>
On Tue, 6 Nov 2007, eric miao wrote:
> >From 9363662844b6373ddf4265e7007eb29ff963a377 Mon Sep 17 00:00:00 2001
> From: eric miao <eric.miao@marvell.com>
According to the SOB line below, shouldn't this be:
From: Aleksey Makarov <amakarov@ru.mvista.com>
?
> Date: Tue, 30 Oct 2007 09:48:41 +0800
> Subject: [PATCH] add support for smc91x ethernet interface on zylonite
>
> This patch adds LAN91C111 ethernet interface support for zylonite
> (a.k.a Marvell's PXA3xx Development Platform) with smc91x driver.
>
> It would be better if a patch would support zylonite along with all
> other PXA boards with a single binary of smc91x driver, but it looks
> quite difficult for the moment, so ugly #ifdef is still used here.
>
> Signed-off-by: Aleksey Makarov <amakarov@ru.mvista.com>
> Acked-by: eric miao <eric.miao@marvell.com>
Acked-by: Nicolas Pitre <nico@cam.org>
> ---
> drivers/net/smc91x.h | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> index 729fd28..db34e1e 100644
> --- a/drivers/net/smc91x.h
> +++ b/drivers/net/smc91x.h
> @@ -224,6 +224,21 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
> }
> }
>
> +#elif defined(CONFIG_MACH_ZYLONITE)
> +
> +#define SMC_CAN_USE_8BIT 1
> +#define SMC_CAN_USE_16BIT 1
> +#define SMC_CAN_USE_32BIT 0
> +#define SMC_IO_SHIFT 0
> +#define SMC_NOWAIT 1
> +#define SMC_USE_PXA_DMA 1
> +#define SMC_inb(a, r) readb((a) + (r))
> +#define SMC_inw(a, r) readw((a) + (r))
> +#define SMC_insw(a, r, p, l) insw((a) + (r), p, l)
> +#define SMC_outsw(a, r, p, l) outsw((a) + (r), p, l)
> +#define SMC_outb(v, a, r) writeb(v, (a) + (r))
> +#define SMC_outw(v, a, r) writew(v, (a) + (r))
> +
> #elif defined(CONFIG_ARCH_OMAP)
>
> /* We can only do 16-bit reads and writes in the static memory space. */
> --
> 1.5.2.5.GIT
>
Nicolas
^ permalink raw reply
* RE: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Ramkrishna Vepa @ 2007-11-06 2:39 UTC (permalink / raw)
To: Dave Johnson, David Miller, jes, mchan, ram.vepa, <linux-ke
In-Reply-To: <18223.22296.654548.764588@zeus.sw.starentnetworks.com>
The Xframe (S2io) adapter can be programmed dynamically to either,
always strip the vlan tag or not. In this case, if the vlan group is
NULL, it can be programmed at run time to NOT strip the vlan tag.
When a packet with a Vlan id is received that is not added to the group,
should it be dropped or indicated up? Either can be handled by the
hardware. The vlan tag in this particular case will be stripped as the
vlan group is not NULL.
Ram
> -----Original Message-----
> From: Dave Johnson
[mailto:djohnson+linux-kernel@sw.starentnetworks.com]
> Sent: Monday, November 05, 2007 9:47 AM
> To: David Miller; jes@trained-monkey.org; mchan@broadcom.com;
> ram.vepa@neterion.com; linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org; bguo@sw.starentnetworks.com
> Subject: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of
keeping
> it
>
>
> This patch changes the following drivers to use vlan_hwaccel_rx()
> and/or vlan_hwaccel_receive_skb() with a NULL vlan group if needed as
> they are not setup to dynamically enable/disable vlan removal in
> their MAC based on the vlan group:
>
> drivers/net/tg3.c Tested on BCM5704, looks good
> drivers/net/bnx2.c Tested on BCM5708, looks good
> drivers/net/acenic.c Not tested, I don't have one of these
> drivers/net/s2io.c Not tested, I don't have one of these
>
> In addition, these drivers might also need changes, but should
> probably be done by the maintainer as it's not clear exactly what
> change is needed:
>
> drivers/net/amd8111e.c
> drivers/net/cxgb3/*
>
> Signed-off-by: Dave Johnson <djohnson@sw.starentnetworks.com>
>
> ===== drivers/net/acenic.c 1.77 vs edited =====
> --- 1.77/drivers/net/acenic.c 2007-07-24 16:28:41 -04:00
> +++ edited/drivers/net/acenic.c 2007-11-03 12:27:40 -04:00
> @@ -2036,7 +2036,7 @@
>
> /* send it up */
> #if ACENIC_DO_VLAN
> - if (ap->vlgrp && (bd_flags & BD_FLG_VLAN_TAG)) {
> + if (bd_flags & BD_FLG_VLAN_TAG) {
> vlan_hwaccel_rx(skb, ap->vlgrp, retdesc->vlan);
> } else
> #endif
> ===== drivers/net/bnx2.c 1.135 vs edited =====
> --- 1.135/drivers/net/bnx2.c 2007-09-20 15:14:21 -04:00
> +++ edited/drivers/net/bnx2.c 2007-11-05 09:34:26 -05:00
> @@ -2493,7 +2493,8 @@
> }
>
> #ifdef BCM_VLAN
> - if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) && (bp->vlgrp
!= 0))
> {
> + if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) &&
> + (bp->vlgrp || (bp->flags & ASF_ENABLE_FLAG))) {
> vlan_hwaccel_receive_skb(skb, bp->vlgrp,
> rx_hdr->l2_fhdr_vlan_tag);
> }
> ===== drivers/net/s2io.c 1.124 vs edited =====
> --- 1.124/drivers/net/s2io.c 2007-08-03 18:10:44 -04:00
> +++ edited/drivers/net/s2io.c 2007-11-03 12:29:09 -04:00
> @@ -6834,8 +6834,7 @@
> sp->mac_control.stats_info->sw_stat.mem_freed += skb->truesize;
> if (!sp->lro) {
> skb->protocol = eth_type_trans(skb, dev);
> - if ((sp->vlgrp && RXD_GET_VLAN_TAG(rxdp->Control_2) &&
> - vlan_strip_flag)) {
> + if (RXD_GET_VLAN_TAG(rxdp->Control_2) &&
vlan_strip_flag) {
> /* Queueing the vlan frame to the upper layer */
> if (napi)
> vlan_hwaccel_receive_skb(skb, sp->vlgrp,
> ===== drivers/net/tg3.c 1.523 vs edited =====
> --- 1.523/drivers/net/tg3.c 2007-09-11 04:28:44 -04:00
> +++ edited/drivers/net/tg3.c 2007-11-05 09:38:33 -05:00
> @@ -3417,7 +3417,7 @@
>
> skb->protocol = eth_type_trans(skb, tp->dev);
> #if TG3_VLAN_TAG_USED
> - if (tp->vlgrp != NULL &&
> + if ((tp->vlgrp || (tp->tg3_flags & TG3_FLAG_ENABLE_ASF))
&&
> desc->type_flags & RXD_FLAG_VLAN) {
> tg3_vlan_rx(tp, skb,
> desc->err_vlan & RXD_VLAN_MASK);
^ permalink raw reply
* Please pull 'upstream-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-11-06 1:16 UTC (permalink / raw)
To: jeff-o2qLIJkoznsdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Jeff,
Here is a slew of patches targeted for 2.6.25. There are a bunch
of rt2x00, iwl3945, iwl4965, b43, and b43legacy patches, as well as
a few others. I'm sorry I didn't spread this out better -- I got a
bit behind... :-(
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-jgarzik/
---
The following changes since commit 5d66f151ac7cb5162f201fe2996c6e01f0323f37:
Linus Torvalds (1):
Merge master.kernel.org:/.../gregkh/pci-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-jgarzik
Adam Baker (2):
rt2x00: Unconstify rt2x00dev
rt2x00: Place mutex around USB register access
Christoph Hellwig (3):
iwlwifi: mark more functions/variables static
iwlwifi: keep 3945 and 4965 headers separate
iwlwifi: cleanup Kconfig and ifdefs to split 3945 and 4965
Dan Williams (1):
orinoco: more reliable scan handling
Dmitry Torokhov (1):
P54: use temporary variables to reduce size of generated code
Emmanuel Grumbach (3):
iwlwifi-ht: move 4965 SCD registers to iwl-prph.h
iwlwifi: move 3945 SCD registers to iwl-prph.h
iwlwifi: add 5965 SCD registers to iwl-prph.h
Holger Schurig (1):
libertas: move wlan_*_association_work from header to c file
Ian Schram (5):
iwlwifi: fix various spelling and typos
iwlwifi: rename iwl_eeprom_aqcuire_semaphore to _acquire_
iwlwifi: Two comments in iwl-3945.c were longer than 80 columns
iwlwifi: Beautify by removing superfluous newlines and code
iwlwifi: remove late null-check and duplicate bug_on
Ivo van Doorn (15):
rt2x00: Move quality statistics into seperate structure
rt2x00: Use enum defines
rt2x00: Correctly translate mac80211 antenna setup to rt2x00
rt2x00: SW diversity should default to antenna B
rt2x00: Remove rt2x00_clear_link
rt2x00: Implement SW diversity
rt2x00: Cleanup if-statements
rt2x00: Release rt2x00 2.0.11
rt2x00: Disable RX when switching antenna
rt2x00: Split rt61/rt73 antenna selection into RX and TX antenna
rt2x00: Input-polldev requires input device
rt2x00: Detect initial rfkill state on register
rt2x00: Remove unused variables
rt2x00: Remove data_desc structure
rt2x00: Release rt2x00 2.0.12
Jes Sorensen (1):
iwlwifi: disable interrupts before calling request_irq
Larry Finger (4):
b43legacy: LED triggers support
b43legacy: RF-kill support
b43legacy: Use input-polldev for the rfkill switch
b43legacy: Rewrite pwork locking
Matthias Kaehlcke (1):
Prism54: Convert mgmt_sem to the mutex API
Mattias Nissler (4):
rt2x00: Fix antenna selection.
rt2x00: Rework rt61 antenna selection.
rt2x00: Rework rt73 antenna selection
rt2x00: Correctly set ACK bit in tx descriptors
Michael Buesch (7):
b43legacy: Remove set_key callback
b43: Dereference of wl->current_dev must be protected by wl->mutex
b43: Use the retry limit parameters from mac80211
b43: consistent naming for ieee80211_ops
b43: Fix rfkill callback deadlock
b43: debugfs SHM read buffer overrun fix
b43: Rewrite and fix rfkill init
Roel Kluin (1):
wireless: fix '!x & y' typo's
Tomas Winkler (11):
iwlwifi: Add erp_ie_changed hanlder
iwlwifi: renaming last_used and first_empty
iwlwifi: rs-4965 fix return values
iwlwifi: add TGN flag to qos parameters
iwlwifi: remove cck_flag from iwl_driver_hw_info
iwlwifi: remove cck_power_index_compensation
iwlwifi: using PCI_DEVICE macro
iwlwifi: replace restricted_reg with prph
iwlwifi: rename restricted_mem to targ_mem
iwlwifi: replacing wording restricted to nic access in iwl-io
iwlwifi: Renames struct fw_image_desc to struct fw_desc
Zhu Yi (2):
iwlwifi: Update iwlwifi version stamp to 1.1.18
iwlwifi: Update iwlwifi version stamp to 1.1.19
mabbas (2):
iwlwifi: accept up to 4K frame size on Rx side to fit A-MSDU frame
iwl4965: exclude 60M rate from probe request
drivers/net/wireless/Makefile | 3 +-
drivers/net/wireless/airo.c | 2 +-
drivers/net/wireless/atmel.c | 2 +-
drivers/net/wireless/b43/debugfs.c | 2 +-
drivers/net/wireless/b43/main.c | 159 ++--
drivers/net/wireless/b43/rfkill.c | 115 +--
drivers/net/wireless/b43/rfkill.h | 14 +-
drivers/net/wireless/b43/xmit.c | 3 +-
drivers/net/wireless/b43legacy/Kconfig | 12 +
drivers/net/wireless/b43legacy/Makefile | 29 +-
drivers/net/wireless/b43legacy/b43legacy.h | 11 +-
drivers/net/wireless/b43legacy/leds.c | 413 ++++-----
drivers/net/wireless/b43legacy/leds.h | 61 +-
drivers/net/wireless/b43legacy/main.c | 214 ++---
drivers/net/wireless/b43legacy/radio.c | 15 +-
drivers/net/wireless/b43legacy/radio.h | 2 +-
drivers/net/wireless/b43legacy/rfkill.c | 185 ++++
drivers/net/wireless/b43legacy/rfkill.h | 59 ++
drivers/net/wireless/iwlwifi/Kconfig | 169 ++--
.../{iwl-commands.h => iwl-3945-commands.h} | 275 +-----
.../iwlwifi/{iwl-debug.h => iwl-3945-debug.h} | 6 +-
drivers/net/wireless/iwlwifi/iwl-3945-hw.h | 629 ++++++++++++-
.../wireless/iwlwifi/{iwl-io.h => iwl-3945-io.h} | 289 +++---
drivers/net/wireless/iwlwifi/iwl-3945-rs.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-3945-rs.h | 4 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 182 ++--
drivers/net/wireless/iwlwifi/iwl-3945.h | 963 ++++++++++++++++++-
.../{iwl-commands.h => iwl-4965-commands.h} | 154 +---
.../iwlwifi/{iwl-debug.h => iwl-4965-debug.h} | 6 +-
drivers/net/wireless/iwlwifi/iwl-4965-hw.h | 711 +++++++++++++-
.../wireless/iwlwifi/{iwl-io.h => iwl-4965-io.h} | 289 +++---
drivers/net/wireless/iwlwifi/iwl-4965-rs.c | 149 ++--
drivers/net/wireless/iwlwifi/iwl-4965-rs.h | 4 +-
drivers/net/wireless/iwlwifi/iwl-4965.c | 305 +++---
drivers/net/wireless/iwlwifi/iwl-4965.h | 1035 +++++++++++++++++++-
drivers/net/wireless/iwlwifi/iwl-channel.h | 161 ---
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 336 -------
drivers/net/wireless/iwlwifi/iwl-hw.h | 537 ----------
drivers/net/wireless/iwlwifi/iwl-priv.h | 308 ------
drivers/net/wireless/iwlwifi/iwl-prph.h | 53 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 405 ++++----
drivers/net/wireless/iwlwifi/iwl4965-base.c | 529 +++++-----
drivers/net/wireless/iwlwifi/iwlwifi.h | 708 -------------
drivers/net/wireless/libertas/assoc.h | 18 -
drivers/net/wireless/libertas/wext.c | 52 +-
drivers/net/wireless/orinoco.c | 541 ++++++-----
drivers/net/wireless/orinoco.h | 12 +-
drivers/net/wireless/p54common.c | 2 +-
drivers/net/wireless/p54pci.c | 77 +-
drivers/net/wireless/prism54/isl_ioctl.c | 4 +-
drivers/net/wireless/prism54/islpci_dev.c | 2 +-
drivers/net/wireless/prism54/islpci_dev.h | 3 +-
drivers/net/wireless/prism54/islpci_mgt.c | 4 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 104 ++-
drivers/net/wireless/rt2x00/rt2400pci.h | 4 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 112 ++--
drivers/net/wireless/rt2x00/rt2500pci.h | 4 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 169 +++--
drivers/net/wireless/rt2x00/rt2500usb.h | 17 +-
drivers/net/wireless/rt2x00/rt2x00.h | 192 +++-
drivers/net/wireless/rt2x00/rt2x00config.c | 95 ++-
drivers/net/wireless/rt2x00/rt2x00debug.h | 4 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 212 ++++-
drivers/net/wireless/rt2x00/rt2x00lib.h | 2 +
drivers/net/wireless/rt2x00/rt2x00pci.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00pci.h | 8 +-
drivers/net/wireless/rt2x00/rt2x00rfkill.c | 44 +-
drivers/net/wireless/rt2x00/rt2x00ring.h | 23 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 38 +-
drivers/net/wireless/rt2x00/rt2x00usb.h | 19 +-
drivers/net/wireless/rt2x00/rt61pci.c | 332 ++++---
drivers/net/wireless/rt2x00/rt61pci.h | 14 +-
drivers/net/wireless/rt2x00/rt73usb.c | 198 +++--
drivers/net/wireless/rt2x00/rt73usb.h | 14 +-
drivers/net/wireless/zd1211rw/zd_rf_uw2453.c | 2 +-
net/ieee80211/ieee80211_wx.c | 2 +-
76 files changed, 6655 insertions(+), 5189 deletions(-)
create mode 100644 drivers/net/wireless/b43legacy/rfkill.c
create mode 100644 drivers/net/wireless/b43legacy/rfkill.h
copy drivers/net/wireless/iwlwifi/{iwl-commands.h => iwl-3945-commands.h} (86%)
copy drivers/net/wireless/iwlwifi/{iwl-debug.h => iwl-3945-debug.h} (97%)
copy drivers/net/wireless/iwlwifi/{iwl-io.h => iwl-3945-io.h} (50%)
rename drivers/net/wireless/iwlwifi/{iwl-commands.h => iwl-4965-commands.h} (93%)
rename drivers/net/wireless/iwlwifi/{iwl-debug.h => iwl-4965-debug.h} (97%)
rename drivers/net/wireless/iwlwifi/{iwl-io.h => iwl-4965-io.h} (50%)
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-channel.h
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-eeprom.h
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-hw.h
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-priv.h
delete mode 100644 drivers/net/wireless/iwlwifi/iwlwifi.h
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/upstream-jgarzik.patch
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* Re: problems with ib-bonding of 2.6.24-rc1
From: Jay Vosburgh @ 2007-11-06 1:05 UTC (permalink / raw)
To: Moni Shoua; +Cc: Moni Shoua, netdev
In-Reply-To: <472EFB28.9090000@gmail.com>
Moni Shoua <monisonlists@gmail.com> wrote:
>Basically, what I see is that after a while commands like ifconfig or ip stucks.
>I only use sysfs to configure bonding (which also stucks after a while).
I've fooled with setting various things in bonding in the
current linux-2.6 git kernel, and I'm not seeing the failure you
describe. Can you provide some step by step instructions, including the
type of system, bonding mode, options, number and type of slaves, etc,
to induce the failure?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* [PATCH] add support for smc91x ethernet interface on zylonite
From: eric miao @ 2007-11-06 0:45 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Nicolas Pitre
>From 9363662844b6373ddf4265e7007eb29ff963a377 Mon Sep 17 00:00:00 2001
From: eric miao <eric.miao@marvell.com>
Date: Tue, 30 Oct 2007 09:48:41 +0800
Subject: [PATCH] add support for smc91x ethernet interface on zylonite
This patch adds LAN91C111 ethernet interface support for zylonite
(a.k.a Marvell's PXA3xx Development Platform) with smc91x driver.
It would be better if a patch would support zylonite along with all
other PXA boards with a single binary of smc91x driver, but it looks
quite difficult for the moment, so ugly #ifdef is still used here.
Signed-off-by: Aleksey Makarov <amakarov@ru.mvista.com>
Acked-by: eric miao <eric.miao@marvell.com>
---
drivers/net/smc91x.h | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 729fd28..db34e1e 100644
--- a/drivers/net/smc91x.h
+++ b/drivers/net/smc91x.h
@@ -224,6 +224,21 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
}
}
+#elif defined(CONFIG_MACH_ZYLONITE)
+
+#define SMC_CAN_USE_8BIT 1
+#define SMC_CAN_USE_16BIT 1
+#define SMC_CAN_USE_32BIT 0
+#define SMC_IO_SHIFT 0
+#define SMC_NOWAIT 1
+#define SMC_USE_PXA_DMA 1
+#define SMC_inb(a, r) readb((a) + (r))
+#define SMC_inw(a, r) readw((a) + (r))
+#define SMC_insw(a, r, p, l) insw((a) + (r), p, l)
+#define SMC_outsw(a, r, p, l) outsw((a) + (r), p, l)
+#define SMC_outb(v, a, r) writeb(v, (a) + (r))
+#define SMC_outw(v, a, r) writew(v, (a) + (r))
+
#elif defined(CONFIG_ARCH_OMAP)
/* We can only do 16-bit reads and writes in the static memory space. */
--
1.5.2.5.GIT
^ permalink raw reply related
* Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: David Miller @ 2007-11-06 0:35 UTC (permalink / raw)
To: kaber
Cc: djohnson+linux-kernel, jes, mchan, ram.vepa, linux-kernel, netdev,
bguo
In-Reply-To: <472FB375.1020802@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 06 Nov 2007 01:21:09 +0100
> David Miller wrote:
> > From: Patrick McHardy <kaber@trash.net>
> > Date: Mon, 05 Nov 2007 19:00:19 +0100
> >
> >> This looks like a rather expensive operation for the unlikely case
> >> that packets will be received by a packet socket. IMO it should only
> >> be reconstructed if actually needed, by af_packet itself.
> >
> > Completely agreed. We should not do this by default when %99
> > of the networking stack simply does not care about this.
>
>
> I think there is one more case that matters, which is briding
> from a device with VLAN stripping for a VLAN not configured
> locally. The tag will be stripped and will be lost for forwarded
> packets. But I'm not exactly sure this really can be configured
> (time for bed so I'll check tommorrow).
If so then when such rules are loaded, just like PF_PACKET, it can set
the indication to start reconstituting VLAN headers stripped by HW.
> >> As we discussed some time back storing the VLAN tag in the CB on
> >> TX clashes with other users of the CB like qdiscs, so we need a
> >> new field in the skb for this anyway.
> >
> > Someone will have to find a way to remove some other fields in
> > sk_buff before I'm going to allow more space to be eaten up
> > by this completely fringe case feature.
>
> We have a two byte hole after tc_verd where we could fit this in.
> But I'm pretty sure we also could reuse some other fields on input,
> like queue_mapping or maybe even destructor for unowned skbs.
Two bytes is enough, so if there is a hole we can use it.
^ permalink raw reply
* Re: [PATCH] NET: Remove unneeded type cast in skb_truesize_check()
From: David Miller @ 2007-11-06 0:33 UTC (permalink / raw)
To: chuck.lever; +Cc: netdev
In-Reply-To: <472FAE5E.8030701@oracle.com>
From: Chuck Lever <chuck.lever@oracle.com>
Date: Mon, 05 Nov 2007 18:59:26 -0500
> If that's truly the case, document the requirement (perhaps using
> something the compiler itself can verify) instead of using a clever
> type cast trick.
Feel free to submit such a change.
> Here's the problem with leaving these little surprises in commonly used
> kernel headers. Suppose the developer of a network driver or network
> file system that uses one of these headers wants to employ static code
> analysis to identify issues introduced by new patches to their
> subsystem. The tool warnings generated in kernel headers are just
> noise, and make using such code analysis difficult.
Here's the problem with submitting patches fixing non-bugs and
removing useful assertions from kernel. I won't apply them.
^ permalink raw reply
* Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Patrick McHardy @ 2007-11-06 0:21 UTC (permalink / raw)
To: David Miller
Cc: djohnson+linux-kernel, jes, mchan, ram.vepa, linux-kernel, netdev,
bguo
In-Reply-To: <20071105.151544.175839612.davem@davemloft.net>
David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 05 Nov 2007 19:00:19 +0100
>
>> This looks like a rather expensive operation for the unlikely case
>> that packets will be received by a packet socket. IMO it should only
>> be reconstructed if actually needed, by af_packet itself.
>
> Completely agreed. We should not do this by default when %99
> of the networking stack simply does not care about this.
I think there is one more case that matters, which is briding
from a device with VLAN stripping for a VLAN not configured
locally. The tag will be stripped and will be lost for forwarded
packets. But I'm not exactly sure this really can be configured
(time for bed so I'll check tommorrow).
>> As we discussed some time back storing the VLAN tag in the CB on
>> TX clashes with other users of the CB like qdiscs, so we need a
>> new field in the skb for this anyway.
>
> Someone will have to find a way to remove some other fields in
> sk_buff before I'm going to allow more space to be eaten up
> by this completely fringe case feature.
We have a two byte hole after tc_verd where we could fit this in.
But I'm pretty sure we also could reuse some other fields on input,
like queue_mapping or maybe even destructor for unowned skbs.
^ permalink raw reply
* Re: netfilter: nf_conntrack_ipv4 does not show nf_nat as a user
From: Patrick McHardy @ 2007-11-06 0:12 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Netdev
In-Reply-To: <472F78C9.9060900@redhat.com>
Chuck Ebbert wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=333481#c3
>
> This is netfilter kernel problem. There is a usage count for the conntrack_ipv4
> module from the nf_nat module, which is not reported by lsmod.
>
This is "fixed" in the current kernel.
^ permalink raw reply
* [git patches] net driver fixes
From: Jeff Garzik @ 2007-11-06 0:03 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, LKML
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus
to receive the following updates:
drivers/net/82596.c | 3 ++-
drivers/net/phy/marvell.c | 23 ++++++++++++++++++-----
drivers/net/phy/phy_device.c | 2 +-
drivers/net/sunhme.c | 4 ++--
4 files changed, 23 insertions(+), 9 deletions(-)
David Miller (1):
SUNHME: Fix missing NETIF_F_VLAN_CHALLENGED on PCI happy meals
Evgeniy Dushistov (1):
82596: free nonexistent resource fix
Olof Johansson (2):
phylib: Add ID for Marvell 88E1240
phylib: Silence driver registration
diff --git a/drivers/net/82596.c b/drivers/net/82596.c
index bb30d5b..2797da7 100644
--- a/drivers/net/82596.c
+++ b/drivers/net/82596.c
@@ -1192,6 +1192,8 @@ struct net_device * __init i82596_probe(int unit)
goto out;
}
+ dev->base_addr = ioaddr;
+
for (i = 0; i < 8; i++) {
eth_addr[i] = inb(ioaddr + 8 + i);
checksum += eth_addr[i];
@@ -1209,7 +1211,6 @@ struct net_device * __init i82596_probe(int unit)
goto out1;
}
- dev->base_addr = ioaddr;
dev->irq = 10;
}
#endif
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index d2ede5f..035fd41 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -265,7 +265,7 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
- .driver = {.owner = THIS_MODULE,},
+ .driver = { .owner = THIS_MODULE },
},
{
.phy_id = 0x01410c90,
@@ -278,7 +278,7 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
- .driver = {.owner = THIS_MODULE,},
+ .driver = { .owner = THIS_MODULE },
},
{
.phy_id = 0x01410cc0,
@@ -291,7 +291,7 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
- .driver = {.owner = THIS_MODULE,},
+ .driver = { .owner = THIS_MODULE },
},
{
.phy_id = 0x01410cd0,
@@ -304,8 +304,21 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
- .driver = {.owner = THIS_MODULE,},
- }
+ .driver = { .owner = THIS_MODULE },
+ },
+ {
+ .phy_id = 0x01410e30,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Marvell 88E1240",
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = &m88e1111_config_init,
+ .config_aneg = &marvell_config_aneg,
+ .read_status = &genphy_read_status,
+ .ack_interrupt = &marvell_ack_interrupt,
+ .config_intr = &marvell_config_intr,
+ .driver = { .owner = THIS_MODULE },
+ },
};
static int __init marvell_init(void)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index c046121..f6e4848 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -706,7 +706,7 @@ int phy_driver_register(struct phy_driver *new_driver)
return retval;
}
- pr_info("%s: Registered new driver\n", new_driver->name);
+ pr_debug("%s: Registered new driver\n", new_driver->name);
return 0;
}
diff --git a/drivers/net/sunhme.c b/drivers/net/sunhme.c
index 120c8af..c20a3bd 100644
--- a/drivers/net/sunhme.c
+++ b/drivers/net/sunhme.c
@@ -3143,8 +3143,8 @@ static int __devinit happy_meal_pci_probe(struct pci_dev *pdev,
dev->irq = pdev->irq;
dev->dma = 0;
- /* Happy Meal can do it all... */
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ /* Happy Meal can do it all... except VLAN. */
+ dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_VLAN_CHALLENGED;
#if defined(CONFIG_SBUS) && defined(CONFIG_PCI)
/* Hook up PCI register/dma accessors. */
^ permalink raw reply related
* Re: [PATCH] NET: Remove unneeded type cast in skb_truesize_check()
From: Chuck Lever @ 2007-11-05 23:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20071102.142717.157261554.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]
David Miller wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
> Date: Fri, 02 Nov 2007 15:14:26 -0400
>
>> The (int) type cast in skb_truesize_check() is unneeded: without it, all
>> the variable types in the conditional expression are unsigned integers. As
>> it stands, the type cast causes a comparison between a signed and an
>> unsigned integer, which can produce unexpected results.
>>
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>
> This is checking for skb->truesize being decremented too much by other
> code, which could cause a wraparound below zero, so we do want
> negaitve checks here.
If that's truly the case, document the requirement (perhaps using
something the compiler itself can verify) instead of using a clever
type cast trick.
Here's the problem with leaving these little surprises in commonly used
kernel headers. Suppose the developer of a network driver or network
file system that uses one of these headers wants to employ static code
analysis to identify issues introduced by new patches to their
subsystem. The tool warnings generated in kernel headers are just
noise, and make using such code analysis difficult.
[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 259 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard
^ 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