the initialization as well as the vlan
> registration.
Sure, not having this hardware I didn't want to attempt a complicated
change. I'll let you take care of this.
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
as well as the vlan
registration.
Sure, not having this hardware I didn't want to attempt a complicated
change. I'll let you take care of this.
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
not clear exactly what
change is needed:
drivers/net/amd8111e.c
drivers/net/cxgb3/*
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
= 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
that
cannot do this the change will ensure tagged packets remain tagged in
the network stack.
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
---
Note, __vlan_hwaccel_rx() needed to move below __vlan_put_tag() so the
change really isn't as big as it may look below.
= include/linux/if_
that
cannot do this the change will ensure tagged packets remain tagged in
the network stack.
Signed-off-by: Dave Johnson [EMAIL PROTECTED]
---
Note, __vlan_hwaccel_rx() needed to move below __vlan_put_tag() so the
change really isn't as big as it may look below.
= include/linux/if_vlan.h 1.25
not clear exactly what
change is needed:
drivers/net/amd8111e.c
drivers/net/cxgb3/*
Signed-off-by: Dave Johnson [EMAIL PROTECTED]
= 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
Dave Johnson writes:
> Ben Greear writes:
> > Currently, VLAN devices offer the ability to 'reorder' the header
> > and explicitly remove the VLAN header. I assume we keep this
> > feature and have the AF_PACKET logic check the device flags to see
> > if it should in
Dave Johnson writes:
Ben Greear writes:
Currently, VLAN devices offer the ability to 'reorder' the header
and explicitly remove the VLAN header. I assume we keep this
feature and have the AF_PACKET logic check the device flags to see
if it should insert the VLAN header for hw-accel vlans
ice. Not sure of an easy fix for
this as af_packet can specifically bind to a specified base device. I
don't this this would be much of an issue and probably doesn't need
fixing.
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
base device. I
don't this this would be much of an issue and probably doesn't need
fixing.
--
Dave Johnson
Starent Networks
-
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
lan_hwaccel_receive_skb() shim a vlan tag back on the packet and send
it to the base device if there is no vlan device to send to? Also, is
it up to the individual driver to have a vlan tag on the packet if it
uses netif_receive_skb() as in case 1 above?
--
Dave Johnson
Starent Networks
-
device to send to? Also, is
it up to the individual driver to have a vlan tag on the packet if it
uses netif_receive_skb() as in case 1 above?
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Hiroshi Shimamoto writes:
> Dave Johnson wrote:
> > mach_prepare_counter();
>
> It's a really rare case, but if SMI interrupt takes CPU here, just after
> prepare and before rdtscll, it makes delta64 shorter than expected one.
> Is it possible? And how about
Daniel Walker writes:
> Can you tell us what type of machine this was? I've seen complaints
> where the SMI's can cause some other funny stuff with calibration , be
> no one can every reproduce anything..
Xeon LV (Sossaman) based custom board. BIOS is GenSW.
--
Dave Johnson
Starent
From: Dave Johnson <[EMAIL PROTECTED]>
The previous patch wasn't correctly handling the 'count' variable. If
a CPU gave bad results on the 1st or 2nd run but good results on the
3rd, it wouldn't do the correct thing. No idea if any such CPU
exists, but the patch below handles tha
Daniel Walker writes:
Can you tell us what type of machine this was? I've seen complaints
where the SMI's can cause some other funny stuff with calibration , be
no one can every reproduce anything..
Xeon LV (Sossaman) based custom board. BIOS is GenSW.
--
Dave Johnson
Starent Networks
Hiroshi Shimamoto writes:
Dave Johnson wrote:
mach_prepare_counter();
It's a really rare case, but if SMI interrupt takes CPU here, just after
prepare and before rdtscll, it makes delta64 shorter than expected one.
Is it possible? And how about moving rdtscll before
From: Dave Johnson [EMAIL PROTECTED]
The previous patch wasn't correctly handling the 'count' variable. If
a CPU gave bad results on the 1st or 2nd run but good results on the
3rd, it wouldn't do the correct thing. No idea if any such CPU
exists, but the patch below handles that case
From: Dave Johnson <[EMAIL PROTECTED]>
I ran into this problem on a system that was unable to obtain NTP sync
because the clock was running very slow (over 1ppm slow). ntpd had
declared all of its peers 'reject' with 'peer_dist' reason.
On investigation, the tsc_khz va
From: Dave Johnson [EMAIL PROTECTED]
I ran into this problem on a system that was unable to obtain NTP sync
because the clock was running very slow (over 1ppm slow). ntpd had
declared all of its peers 'reject' with 'peer_dist' reason.
On investigation, the tsc_khz variable was significantly
-by: Dave Johnson <[EMAIL PROTECTED]>
Cc: Srinivas Akkipeddi <[EMAIL PROTECTED]>
= net/sctp/ipv6.c 1.108 vs edited =
--- 1.108/net/sctp/ipv6.c 2007-07-05 20:40:15 -04:00
+++ edited/net/sctp/ipv6.c 2007-07-25 16:30:41 -04:00
@@ -641,6 +641,8 @@
newsctp6
r patch to __sctp_connect()
fixes calls to getpeername() after connect() just fine.
I'll post a patch for the accept()/getpeername() case in a bit.
Acked-by: Dave Johnson <[EMAIL PROTECTED]>
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line "unsubscrib
() after connect() just fine.
I'll post a patch for the accept()/getpeername() case in a bit.
Acked-by: Dave Johnson [EMAIL PROTECTED]
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
-by: Dave Johnson [EMAIL PROTECTED]
Cc: Srinivas Akkipeddi [EMAIL PROTECTED]
= net/sctp/ipv6.c 1.108 vs edited =
--- 1.108/net/sctp/ipv6.c 2007-07-05 20:40:15 -04:00
+++ edited/net/sctp/ipv6.c 2007-07-25 16:30:41 -04:00
@@ -641,6 +641,8 @@
newsctp6sk = (struct sctp6_sock
our patch, connect and accept
both work with v4 mapped addresses.
Note instead of:
> + af = sctp_get_af_specific(sa_addr->sa.sa_family);
> + af->to_sk_daddr(sa_addr, sk);
you should have:
> + af = sctp_get_af_specific(sa_addr->sa_family);
> + af->to_sk_da
l+0xb1/0x260
[] syscall_call+0x7/0xb
I'm unsure if there is a path to call sctp_v4_to_sk_saddr() but it was
added just to be complete.
v4mapped in sctp_v4_create_accept_sk() probably isn't needed, but
since v4mapped is in sctp_sock not sctp6_sock copying it seems like a
good idea.
--
Dave Johnson
Staren
by ambiguity like the site-local addresses defined in
>[ADDARCH].
--
Dave Johnson
Starent Networks
-
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/majord
addresses.
Note instead of:
+ af = sctp_get_af_specific(sa_addr-sa.sa_family);
+ af-to_sk_daddr(sa_addr, sk);
you should have:
+ af = sctp_get_af_specific(sa_addr-sa_family);
+ af-to_sk_daddr((union sctp_addr *)sa_addr, sk);
--
Dave Johnson
Starent Networks
-
To unsubscribe
the site-local addresses defined in
[ADDARCH].
--
Dave Johnson
Starent Networks
-
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
/0x260
[c0103013] syscall_call+0x7/0xb
I'm unsure if there is a path to call sctp_v4_to_sk_saddr() but it was
added just to be complete.
v4mapped in sctp_v4_create_accept_sk() probably isn't needed, but
since v4mapped is in sctp_sock not sctp6_sock copying it seems like a
good idea.
--
Dave
t/sctp/ipv6.c:sctp_v6_available()
net/sctp/ipv6.c:sctp_v6_addr_valid()
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
as a missing check for INET6 socket type in
sctp_v4_to_sk_*addr().
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
Cc: Srinivas Akkipeddi <[EMAIL PROTECTED]>
= net/sctp/ipv6.c 1.108 vs edited =
--- 1.108/net/sctp/ipv6.c 2007-07-05 20:40:15 -04:00
+++ edited/net/sctp/ipv6.c
if listening on IPV6_ADDR_ANY.
There may be other users of ipv6_addr_type() that could also have
problems.
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
Cc: Srinivas Akkipeddi <[EMAIL PROTECTED]>
= net/ipv6/addrconf_core.c 1.2 vs edited =
--- 1.2/net/ipv6/addrconf_core.c2007
.c:sctp_v6_available()
net/sctp/ipv6.c:sctp_v6_addr_valid()
--
Dave Johnson
Starent Networks
-
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
as a missing check for INET6 socket type in
sctp_v4_to_sk_*addr().
Signed-off-by: Dave Johnson [EMAIL PROTECTED]
Cc: Srinivas Akkipeddi [EMAIL PROTECTED]
= net/sctp/ipv6.c 1.108 vs edited =
--- 1.108/net/sctp/ipv6.c 2007-07-05 20:40:15 -04:00
+++ edited/net/sctp/ipv6.c 2007-07-25 16
if listening on IPV6_ADDR_ANY.
There may be other users of ipv6_addr_type() that could also have
problems.
Signed-off-by: Dave Johnson [EMAIL PROTECTED]
Cc: Srinivas Akkipeddi [EMAIL PROTECTED]
= net/ipv6/addrconf_core.c 1.2 vs edited =
--- 1.2/net/ipv6/addrconf_core.c2007-02-26 14:42:57
there is a small change in that rt_free() is called while the
lock is held where before it was called without the lock held. I
don't think this should be an issue.
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
= net/ipv4/route.c 1.162 vs edited =
--- 1.162/net/ipv4/route.c 2
there is a small change in that rt_free() is called while the
lock is held where before it was called without the lock held. I
don't think this should be an issue.
Signed-off-by: Dave Johnson [EMAIL PROTECTED]
= net/ipv4/route.c 1.162 vs edited =
--- 1.162/net/ipv4/route.c 2007-02
to occur because do_tty_write() isn't checking for
O_NONBLOCK when taking the tty's write mutex.
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
= drivers/char/tty_io.c 1.237 vs edited =
--- 1.237/drivers/char/tty_io.c 2007-03-18 16:40:06 -04:00
+++ edited/drivers/char/tty_io.c2
to occur because do_tty_write() isn't checking for
O_NONBLOCK when taking the tty's write mutex.
Signed-off-by: Dave Johnson [EMAIL PROTECTED]
= drivers/char/tty_io.c 1.237 vs edited =
--- 1.237/drivers/char/tty_io.c 2007-03-18 16:40:06 -04:00
+++ edited/drivers/char/tty_io.c2007-05-01
Dave Johnson writes:
> Phillip Lougher writes:
> > Doesn't iget_locked() assume inode numbers are unique?
> >
> > In Cramfs inode numbers are set to 1 for non-data inodes (fifos,
> > sockets, devices, empty directories), i.e
> >
> > %stat device namedpi
> Access: 1970-01-01 01:00:00.0 +0100
> Modify: 1970-01-01 01:00:00.0 +0100
> Change: 1970-01-01 01:00:00.0 +0100
>
> Should iget5_locked() be used here?
Yep, that was busted. Below patch should be better.
--
Dave Johnson
Starent Networks
= fs/cramfs/in
as the old buffer cache is now orphaned as well.
Patch below fixes this by making get_cramfs_inode() use the inode
cache before blindly creating a new entry every time. This eliminates
the duplicate inodes and duplicate buffer cache.
--
Dave Johnson
Starent Networks
= fs/cramfs/inode.c
inutes or even longer if the peers remain active due
to arriving packets while the loop is occurring.
Bug is present in both 2.4 and 2.6. Same patch will apply to both just
fine.
--
Dave Johnson
Starent Networks
= net/ipv4/inetpeer.c 1.12 vs edited =
--- 1.12/net/ipv4/inetpeer.c2005-06
or even longer if the peers remain active due
to arriving packets while the loop is occurring.
Bug is present in both 2.4 and 2.6. Same patch will apply to both just
fine.
--
Dave Johnson
Starent Networks
= net/ipv4/inetpeer.c 1.12 vs edited =
--- 1.12/net/ipv4/inetpeer.c2005-06-24 16
as the old buffer cache is now orphaned as well.
Patch below fixes this by making get_cramfs_inode() use the inode
cache before blindly creating a new entry every time. This eliminates
the duplicate inodes and duplicate buffer cache.
--
Dave Johnson
Starent Networks
= fs/cramfs/inode.c
:00.0 +0100
Change: 1970-01-01 01:00:00.0 +0100
Should iget5_locked() be used here?
Yep, that was busted. Below patch should be better.
--
Dave Johnson
Starent Networks
= fs/cramfs/inode.c 1.42 vs edited =
--- 1.42/fs/cramfs/inode.c 2005-07-14 12:24:48 -04:00
Dave Johnson writes:
Phillip Lougher writes:
Doesn't iget_locked() assume inode numbers are unique?
In Cramfs inode numbers are set to 1 for non-data inodes (fifos,
sockets, devices, empty directories), i.e
%stat device namedpipe
File: `device'
Size: 0
otherwise).
Programs that make use of sendmsg/recvmsg with a large iovec will
cause the leak. The below test program will cause a OOM DoS rather
quickly.
My original post to linux-mips mailing list follows.
--
Dave Johnson
Starent Networks
sendmsg()/recvmsg() syscalls from o32/n32
otherwise).
Programs that make use of sendmsg/recvmsg with a large iovec will
cause the leak. The below test program will cause a OOM DoS rather
quickly.
My original post to linux-mips mailing list follows.
--
Dave Johnson
Starent Networks
sendmsg()/recvmsg() syscalls from o32/n32
50 matches
Mail list logo
