* Re: [PATCH kernel 2.6.37-rc1] axnet_cs: fix resume problem for some Ax88790 chip
From: David Miller @ 2010-11-12 22:01 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20101107001124.7d8ef6c4.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sun, 7 Nov 2010 00:11:24 +0900
>
> axnet_cs:
> Some Ax88790 chip need to reinitialize the CISREG_CCSR register
> after resume.
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: don't remove address state on ifdown if the address is being kept
From: David Miller @ 2010-11-12 21:45 UTC (permalink / raw)
To: lorenzo; +Cc: netdev, maze, brian.haley
In-Reply-To: <AANLkTimLicmgC3BptZvXGoA0aN6-cFJtRG3DpqJ3NTpJ@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 27 Oct 2010 23:45:17 -0700
> On Wed, Oct 27, 2010 at 9:16 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
>> Fix it so that none of this state is updated if the address is being kept on the interface.
>
> Or, since the logic of the patched code is a little hard to follow,
> here's an alternative patch against 2.6.36. I think it does exactly
> the same as the previous patch, but it moves things around to make the
> result more readable.
>
> Tested: Added a statically configured IPv6 address to an interface,
> started ping, brought link down, brought link up again. When link came
> up ping kept on going and "ip -6 maddr" showed that the host was still
> subscribed to there
>
> Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Ok, this looks good, applied.
Thanks for your patience.
^ permalink raw reply
* [PATCH 09/14] drivers/net/can/sja1000: Use printf extension %pR for struct resource
From: Joe Perches @ 2010-11-12 21:37 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Wolfgang Grandegger, socketcan-core, netdev, linux-kernel
In-Reply-To: <cover.1289597644.git.joe@perches.com>
Using %pR standardizes the struct resource output.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/can/sja1000/sja1000_of_platform.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/can/sja1000/sja1000_of_platform.c b/drivers/net/can/sja1000/sja1000_of_platform.c
index 5bfccfd..09c3e9d 100644
--- a/drivers/net/can/sja1000/sja1000_of_platform.c
+++ b/drivers/net/can/sja1000/sja1000_of_platform.c
@@ -107,17 +107,13 @@ static int __devinit sja1000_ofp_probe(struct platform_device *ofdev,
res_size = resource_size(&res);
if (!request_mem_region(res.start, res_size, DRV_NAME)) {
- dev_err(&ofdev->dev, "couldn't request %#llx..%#llx\n",
- (unsigned long long)res.start,
- (unsigned long long)res.end);
+ dev_err(&ofdev->dev, "couldn't request %pR\n", &res);
return -EBUSY;
}
base = ioremap_nocache(res.start, res_size);
if (!base) {
- dev_err(&ofdev->dev, "couldn't ioremap %#llx..%#llx\n",
- (unsigned long long)res.start,
- (unsigned long long)res.end);
+ dev_err(&ofdev->dev, "couldn't ioremap %pR\n", &res);
err = -ENOMEM;
goto exit_release_mem;
}
--
1.7.3.1.g432b3.dirty
^ permalink raw reply related
* [PATCH 00/14] Use printf extension %pR for struct resource
From: Joe Perches @ 2010-11-12 21:37 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-parisc-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw
Yet more trivia...
Joe Perches (14):
arch/frv: Use printf extension %pR for struct resource
arch/mips: Use printf extension %pR for struct resource
arch/powerpc: Use printf extension %pR for struct resource
drivers/dma/ppc4xx: Use printf extension %pR for struct resource
drivers/infiniband: Use printf extension %pR for struct resource
drivers/mfd: Use printf extension %pR for struct resource
drivers/mtd/maps: Use printf extension %pR for struct resource
drivers/mtd/nand: Use printf extension %pR for struct resource
drivers/net/can/sja1000: Use printf extension %pR for struct resource
drivers/parisc: Use printf extension %pR for struct resource
drivers/rapidio: Use printf extension %pR for struct resource
drivers/uwb: Use printf extension %pR for struct resource
drivers/video: Use printf extension %pR for struct resource
sound/ppc: Use printf extension %pR for struct resource
arch/frv/mb93090-mb00/pci-vdk.c | 8 ++------
arch/mips/txx9/generic/pci.c | 7 ++-----
arch/powerpc/kernel/pci_64.c | 3 +--
arch/powerpc/sysdev/tsi108_dev.c | 8 ++++----
drivers/dma/ppc4xx/adma.c | 5 ++---
drivers/infiniband/hw/ipath/ipath_driver.c | 5 ++---
drivers/mfd/sm501.c | 7 ++-----
drivers/mtd/maps/amd76xrom.c | 7 ++-----
drivers/mtd/maps/ck804xrom.c | 7 ++-----
drivers/mtd/maps/esb2rom.c | 9 +++------
drivers/mtd/maps/ichxrom.c | 9 +++------
drivers/mtd/maps/physmap_of.c | 4 +---
drivers/mtd/maps/scx200_docflash.c | 5 ++---
drivers/mtd/nand/pasemi_nand.c | 2 +-
drivers/net/can/sja1000/sja1000_of_platform.c | 8 ++------
drivers/parisc/dino.c | 13 +++++--------
drivers/parisc/hppb.c | 6 ++----
drivers/rapidio/rio.c | 4 ++--
drivers/uwb/umc-dev.c | 7 ++-----
drivers/video/platinumfb.c | 8 ++------
sound/ppc/pmac.c | 12 ++++--------
21 files changed, 48 insertions(+), 96 deletions(-)
--
1.7.3.1.g432b3.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: a problem tcp_v4_err()
From: David Miller @ 2010-11-12 21:36 UTC (permalink / raw)
To: eric.dumazet
Cc: kuznet, kaber, equinox, eparis, hzhong, netdev, linux-kernel,
pekkas, jmorris, yoshfuji, paul.moore, damian
In-Reply-To: <1289596718.2743.2.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 12 Nov 2010 22:18:38 +0100
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks for reviewing, here is the final bit I committed and
I'll queue this up for whatever -stable trees need this.
--------------------
tcp: Don't change unlocked socket state in tcp_v4_err().
Alexey Kuznetsov noticed a regression introduced by
commit f1ecd5d9e7366609d640ff4040304ea197fbc618
("Revert Backoff [v3]: Revert RTO on ICMP destination unreachable")
The RTO and timer modification code added to tcp_v4_err()
doesn't check sock_owned_by_user(), which if true means we
don't have exclusive access to the socket and therefore cannot
modify it's critical state.
Just skip this new code block if sock_owned_by_user() is true
and eliminate the now superfluous sock_owned_by_user() code
block contained within.
Reported-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
CC: Damian Lukowski <damian@tvk.rwth-aachen.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp_ipv4.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 8f8527d..69ccbc1 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -415,6 +415,9 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
!icsk->icsk_backoff)
break;
+ if (sock_owned_by_user(sk))
+ break;
+
icsk->icsk_backoff--;
inet_csk(sk)->icsk_rto = __tcp_set_rto(tp) <<
icsk->icsk_backoff;
@@ -429,11 +432,6 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
if (remaining) {
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
remaining, TCP_RTO_MAX);
- } else if (sock_owned_by_user(sk)) {
- /* RTO revert clocked out retransmission,
- * but socket is locked. Will defer. */
- inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
- HZ/20, TCP_RTO_MAX);
} else {
/* RTO revert clocked out retransmission.
* Will retransmit now */
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH net-next-2.6] net: net_families __rcu annotations
From: David Miller @ 2010-11-12 21:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1289422244.17691.2.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 10 Nov 2010 21:50:44 +0100
> Use modern RCU API / annotations for net_families array.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: Kconfig whitespace cleanup
From: David Miller @ 2010-11-12 21:21 UTC (permalink / raw)
To: phdm; +Cc: netdev
In-Reply-To: <1289514681-3940-1-git-send-email-phdm@macqel.be>
From: Philippe De Muyter <phdm@macqel.be>
Date: Thu, 11 Nov 2010 23:31:21 +0100
> Many lines in Kconfig start withe 8 spaces instead of a TAB, and even
> sometimes with 7 spaces. Replace 10 or 9 spaces, or TAB + 1 space,
> by TAB + 2 spaces, and 8 or 7 spaces by TAB.
>
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6 V2] igmp: RCU conversion of in_dev->mc_list
From: David Miller @ 2010-11-12 21:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiyou.wangcong, cypher.w, linux-kernel, netdev
In-Reply-To: <1289576810.3185.261.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 12 Nov 2010 16:46:50 +0100
> [PATCH net-next-2.6 V2] igmp: RCU conversion of in_dev->mc_list
>
> in_dev->mc_list is protected by one rwlock (in_dev->mc_list_lock).
>
> This can easily be converted to a RCU protection.
>
> Writers hold RTNL, so mc_list_lock is removed, not replaced by a
> spinlock.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
This looks good to me, so I've applied it to net-next-2.6
We have enough time there to fix any fallout or revert if
necessary.
^ permalink raw reply
* Re: a problem tcp_v4_err()
From: Eric Dumazet @ 2010-11-12 21:18 UTC (permalink / raw)
To: David Miller
Cc: kuznet, kaber, equinox, eparis, hzhong, netdev, linux-kernel,
pekkas, jmorris, yoshfuji, paul.moore, damian
In-Reply-To: <20101112.112224.112610807.davem@davemloft.net>
Le vendredi 12 novembre 2010 à 11:22 -0800, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 12 Nov 2010 19:33:23 +0100
>
> > I CC Damian Lukowski in my previous answer (and this one too)
>
> Probably the safest fix is this:
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 8f8527d..69ccbc1 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -415,6 +415,9 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
> !icsk->icsk_backoff)
> break;
>
> + if (sock_owned_by_user(sk))
> + break;
> +
> icsk->icsk_backoff--;
> inet_csk(sk)->icsk_rto = __tcp_set_rto(tp) <<
> icsk->icsk_backoff;
> @@ -429,11 +432,6 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
> if (remaining) {
> inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
> remaining, TCP_RTO_MAX);
> - } else if (sock_owned_by_user(sk)) {
> - /* RTO revert clocked out retransmission,
> - * but socket is locked. Will defer. */
> - inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
> - HZ/20, TCP_RTO_MAX);
> } else {
> /* RTO revert clocked out retransmission.
> * Will retransmit now */
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [RFC PATCH] network: return errors if we know tcp_connect failed
From: David Miller @ 2010-11-12 21:18 UTC (permalink / raw)
To: equinox
Cc: kaber, eric.dumazet, eparis, hzhong, netdev, linux-kernel, kuznet,
pekkas, jmorris, yoshfuji, paul.moore
In-Reply-To: <20101112211627.GC122902@jupiter.n2.diac24.net>
From: David Lamparter <equinox@diac24.net>
Date: Fri, 12 Nov 2010 22:16:27 +0100
> As food for thought I'd like to pose the following rule:
> iptables -A OUTPUT -m statistic --mode nth --every 5 -j DROP
> which should, to my understanding, still allow the connect to complete,
> even if the first SYN got (silently!...) dropped.
Yes, I agree and this is pretty much the point I tried to make
earlier.
^ permalink raw reply
* Re: [RFC PATCH] network: return errors if we know tcp_connect failed
From: David Lamparter @ 2010-11-12 21:16 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Lamparter, Eric Dumazet, Eric Paris, Hua Zhong, netdev,
linux-kernel, davem, kuznet, pekkas, jmorris, yoshfuji,
paul.moore
In-Reply-To: <4CDD7145.8070606@trash.net>
On Fri, Nov 12, 2010 at 05:54:29PM +0100, Patrick McHardy wrote:
> Am 12.11.2010 17:35, schrieb David Lamparter:
> > On Fri, Nov 12, 2010 at 05:15:32PM +0100, Eric Dumazet wrote:
> >> Le vendredi 12 novembre 2010 à 11:08 -0500, Eric Paris a écrit :
> >>
> >>> 2) What should the generic TCP code (tcp_connect()) do if the skb failed
> >>> to send. Should it return error codes back up the stack somehow or
> >>> should they continue to be ignored? Obviously continuing to just ignore
> >>> information we have doesn't make me happy (otherwise I wouldn't have
> >>> started scratching this itch). But the point about ENOBUFS is well
> >>> taken. Maybe I should make tcp_connect(), or the caller to
> >>> tcp_connect() more intelligent about specific error codes?
> >>>
> >>> I'm looking for a path forward. If SELinux is rejecting the SYN packets
> >>> on connect() I want to pass that info to userspace rather than just
> >>> hanging. What's the best way to accomplish that?
> >>>
> >>
> >> Eric, if you can differentiate a permanent reject, instead of a
> >> temporary one (congestion, or rate limiting, or ENOBUF, or ...), then
> >> yes, you could make tcp_connect() report to user the permanent error,
> >> and ignore the temporary one.
>
> Indeed. We could even make the NF_DROP return value configurable
> by encoding it in the verdict.
> There is no NF_REJECT.
Ah, sorry, not at home in netfilter, coming from an user perspective here.
> Returning NF_DROP results in -EPERM getting reported back. As Eric
> noticed, this is ignored for SYN packets.
Hrm. But how do you silently drop packets? This seems counterintuitive
or even buggy to me; or at least the netfilter DROP target shouldn't use
this kind of error-reporting drop.
As food for thought I'd like to pose the following rule:
iptables -A OUTPUT -m statistic --mode nth --every 5 -j DROP
which should, to my understanding, still allow the connect to complete,
even if the first SYN got (silently!...) dropped.
Also, i'm *very* sure i was able to trigger a "permission denied" from
either firewall or route rules; weirdly enough i can't get that on my
2.6.35.7 router... (poking older boxes to reproduce it right now)
Just for reference some test results: (heavily cropped)
TL;DR: only tcp-reset and route prohibit work immediately.
+ telnet 74.125.43.105 80
Connected to 74.125.43.105.
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT
# default w/o reject-with is icmp-port-unreachable
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: Connection refused
real 0m3.014s
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT --reject-with tcp-reset
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: Connection refused
real 0m0.007s
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT --reject-with host-prohib
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: No route to host
real 0m3.010s
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT --reject-with admin-prohib
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: No route to host
real 0m3.009s
+ iptables -I OUTPUT -p tcp -d 74.125.43.105 --dport 80 -j REJECT --reject-with net-prohib
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: Network is unreachable
real 0m3.011s
+ iptables -F OUTPUT
+ ip route add prohibit 74.125.43.105
+ ip route flush cache
+ telnet 74.125.43.105 80
telnet: connect to address 74.125.43.105: Network is unreachable
real 0m0.007s
-David
^ permalink raw reply
* Re: [net-2.6 PATCH] nete zero kobject in rx_queue_release
From: David Miller @ 2010-11-12 21:08 UTC (permalink / raw)
To: john.r.fastabend; +Cc: netdev, eric.dumazet, therbert
In-Reply-To: <20101111201341.4418.16400.stgit@jf-dev1-dcblab>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Thu, 11 Nov 2010 12:13:41 -0800
> netif_set_real_num_rx_queues() can decrement and increment
> the number of rx queues. For example ixgbe does this as
> features and offloads are toggled. Presumably this could
> also happen across down/up on most devices if the available
> resources changed (cpu offlined).
>
> The kobject needs to be zero'd in this case so that the
> state is not preserved across kobject_put()/kobject_init_and_add().
>
> This resolves the following error report.
...
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
I think it's probably better to clear the entire netdev_rx_queue
object rather than just the embedded kobject.
Otherwise we leave dangling rps_map, rps_flow_table, etc. pointers.
In fact, it's more tricky than this, because notice that your
patch will memset() free'd memory in the case where the
first->count drops to zero and we execute the kfree().
So we'll need something like:
if (atomic_dec_and_test(&first->count))
kfree(first);
else
/* clear everything except queue->first */
or, alternatively:
--------------------
map = rcu_dereference_raw(queue->rps_map);
if (map) {
call_rcu(&map->rcu, rps_map_release);
rcu_assign_pointer(queue->rps_map, NULL);
}
flow_table = rcu_dereference_raw(queue->rps_flow_table);
if (flow_table) {
call_rcu(&flow_table->rcu, rps_dev_flow_table_release);
rcu_assign_pointer(queue->rps_flow_table, NULL);
}
if (atomic_dec_and_test(&first->count))
kfree(first);
else
memset(kobj);
--------------------
Something like that.
^ permalink raw reply
* Re: [PATCH v2] Prevent crashing when parsing bad X.25 facilities
From: David Miller @ 2010-11-12 20:50 UTC (permalink / raw)
To: drosenberg; +Cc: andrew.hendry, netdev
In-Reply-To: <1289594665.3090.336.camel@Dan>
From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Fri, 12 Nov 2010 15:44:25 -0500
>
>> I find this kind of carelessness extremely amusing coming from someone
>> who is so big on security theatre.
>
> You know what I find amusing? The sheer number of security issues a
> single person can find in his spare time. Congratulations on your
> attention to detail.
I do not even agree that, for example, pointer exposure is a real
issue. It still remains a matter of opinion.
And much of your claims and boasting is based upon that opinion.
So don't pass it off saliently or indirectly as fact.
^ permalink raw reply
* Re: [PATCH v3] Prevent crashing when parsing bad X.25 facilities
From: David Miller @ 2010-11-12 20:45 UTC (permalink / raw)
To: drosenberg; +Cc: andrew.hendry, netdev
In-Reply-To: <1289594548.3090.334.camel@Dan>
From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Fri, 12 Nov 2010 15:42:28 -0500
> Now with improved comma support.
>
> On parsing malformed X.25 facilities, decrementing the remaining length
> may cause it to underflow. Since the length is an unsigned integer,
> this will result in the loop continuing until the kernel crashes.
>
> This patch adds checks to ensure decrementing the remaining length does
> not cause it to wrap around.
>
> Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] Prevent crashing when parsing bad X.25 facilities
From: Dan Rosenberg @ 2010-11-12 20:44 UTC (permalink / raw)
To: David Miller; +Cc: andrew.hendry, netdev
In-Reply-To: <20101112.122946.102556009.davem@davemloft.net>
> I find this kind of carelessness extremely amusing coming from someone
> who is so big on security theatre.
You know what I find amusing? The sheer number of security issues a
single person can find in his spare time. Congratulations on your
attention to detail.
-Dan
^ permalink raw reply
* Re: [PATCH] r8169: fix checksum broken
From: David Miller @ 2010-11-12 20:44 UTC (permalink / raw)
To: shanwei; +Cc: romieu, netdev
In-Reply-To: <4CDD13BD.7060109@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 12 Nov 2010 18:15:25 +0800
> If r8196 received packets with invalid sctp/igmp(not tcp, udp) checksum, r8196 set skb->ip_summed
> wit CHECKSUM_UNNECESSARY. This cause that upper protocol don't check checksum field.
>
> I am not family with r8196 driver. I try to guess the meaning of RxProtoIP and IPFail.
> RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp.
> !(opts1 & IPFail) is true means that driver correctly to check checksum in IPv4 header.
>
> If it's right, I think we should not set ip_summed wit CHECKSUM_UNNECESSARY for my sctp packets
> with invalid checksum.
>
> If it's not right, please tell me.
>
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Francois, please review, it looks correct to my eyes.
^ permalink raw reply
* Re: [net-next] stmmac: update the driver documentation
From: David Miller @ 2010-11-12 20:43 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1289561852-22833-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 12 Nov 2010 12:37:32 +0100
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v3] Prevent crashing when parsing bad X.25 facilities
From: Dan Rosenberg @ 2010-11-12 20:42 UTC (permalink / raw)
To: andrew.hendry; +Cc: netdev
Now with improved comma support.
On parsing malformed X.25 facilities, decrementing the remaining length
may cause it to underflow. Since the length is an unsigned integer,
this will result in the loop continuing until the kernel crashes.
This patch adds checks to ensure decrementing the remaining length does
not cause it to wrap around.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
---
net/x25/x25_facilities.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/x25/x25_facilities.c b/net/x25/x25_facilities.c
index 3a8c4c4..55187c8 100644
--- a/net/x25/x25_facilities.c
+++ b/net/x25/x25_facilities.c
@@ -61,6 +61,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
while (len > 0) {
switch (*p & X25_FAC_CLASS_MASK) {
case X25_FAC_CLASS_A:
+ if (len < 2)
+ return 0;
switch (*p) {
case X25_FAC_REVERSE:
if((p[1] & 0x81) == 0x81) {
@@ -104,6 +106,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
len -= 2;
break;
case X25_FAC_CLASS_B:
+ if (len < 3)
+ return 0;
switch (*p) {
case X25_FAC_PACKET_SIZE:
facilities->pacsize_in = p[1];
@@ -125,6 +129,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
len -= 3;
break;
case X25_FAC_CLASS_C:
+ if (len < 4)
+ return 0;
printk(KERN_DEBUG "X.25: unknown facility %02X, "
"values %02X, %02X, %02X\n",
p[0], p[1], p[2], p[3]);
@@ -132,6 +138,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
len -= 4;
break;
case X25_FAC_CLASS_D:
+ if (len < p[1] + 2)
+ return 0;
switch (*p) {
case X25_FAC_CALLING_AE:
if (p[1] > X25_MAX_DTE_FACIL_LEN || p[1] <= 1)
@@ -149,9 +157,7 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
break;
default:
printk(KERN_DEBUG "X.25: unknown facility %02X,"
- "length %d, values %02X, %02X, "
- "%02X, %02X\n",
- p[0], p[1], p[2], p[3], p[4], p[5]);
+ "length %d\n", p[0], p[1]);
break;
}
len -= p[1] + 2;
^ permalink raw reply related
* enic build warnings
From: David Miller @ 2010-11-12 20:40 UTC (permalink / raw)
To: vkolluri; +Cc: roprabhu, dwang2, netdev
Please fix these warnings, you cannot pass the address of
a "u64" object where a "dma_addr_t" is expected:
drivers/net/enic/enic_main.c: In function 'enic_set_rsskey':
drivers/net/enic/enic_main.c:2056:16: warning: passing argument 3 of 'pci_alloc_consistent' from incompatible pointer type
include/asm-generic/pci-dma-compat.h:16:1: note: expected 'dma_addr_t *' but argument is of type 'u64 *'
drivers/net/enic/enic_main.c: In function 'enic_set_rsscpu':
drivers/net/enic/enic_main.c:2082:16: warning: passing argument 3 of 'pci_alloc_consistent' from incompatible pointer type
include/asm-generic/pci-dma-compat.h:16:1: note: expected 'dma_addr_t *' but argument is of type 'u64 *'
Thanks.
^ permalink raw reply
* Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/
From: David Miller @ 2010-11-12 20:37 UTC (permalink / raw)
To: adobriyan; +Cc: shemminger, netdev
In-Reply-To: <20101112201850.GA5625@core2.telecom.by>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Fri, 12 Nov 2010 22:18:50 +0200
> On Fri, Nov 12, 2010 at 08:33:15AM -0800, Stephen Hemminger wrote:
>> Also, the whole idea needs to be under a config option, so only
>> the paranoid idiots turn it on.
>
> Would be fun if something will break because ffff8800bcd498c0
> will become something else. :-)
Actually, this is not even a joke.
Take a look at how we track what sockets a user wants dumped via
the inet_diag netlink facility, the socket pointer is used as
the identification cookie.
I'm sure we'll now get some more security theatre about how we
have to undo that too.
More and more I see this whole idea as extremely rediculious.
If I can write to or read kernel memory, I can look up the
sockets, inodes, and whatever else we're currently exposing
the addresses of. Even without a symbol table, which is
readily available, I can easily find the ksymtab and find the
inode and socket hash table addresses there.
This whole exercise is closing the barn door after the horses have
already escaped, and it's causing all kinds of inconveniences
that we really have no need for.
^ permalink raw reply
* Re: [PATCH v2] Prevent crashing when parsing bad X.25 facilities
From: David Miller @ 2010-11-12 20:29 UTC (permalink / raw)
To: drosenberg; +Cc: andrew.hendry, netdev
In-Reply-To: <1289570877.3090.274.camel@Dan>
From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Fri, 12 Nov 2010 09:07:57 -0500
> @@ -149,9 +157,8 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
> break;
> default:
> printk(KERN_DEBUG "X.25: unknown facility %02X,"
> - "length %d, values %02X, %02X, "
> - "%02X, %02X\n",
> - p[0], p[1], p[2], p[3], p[4], p[5]);
> + "length %d\n"
> + p[0], p[1]);
> break;
Thanks for not even compile testing your changes:
net/x25/x25_facilities.c: In function 'x25_parse_facilities':
net/x25/x25_facilities.c:161:6: error: expected ')' before 'p'
net/x25/x25_facilities.c:161:6: warning: too few arguments for format
I find this kind of carelessness extremely amusing coming from someone
who is so big on security theatre.
^ permalink raw reply
* Re: [PATCH net-26 0/6] cxgb4vf: a number of bug fixes
From: David Miller @ 2010-11-12 20:27 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <1289502413-9895-1-git-send-email-leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Thu, 11 Nov 2010 11:06:47 -0800
> The following patch set includes a number of bug fixes for the cxgb4vf
> network driver. As always, please toss these in the bin if they're not
> right.
All 6 patches applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: Fix deadlock
From: David Miller @ 2010-11-12 20:25 UTC (permalink / raw)
To: cbouatmailru; +Cc: Joakim.Tjernlund, linuxppc-dev, netdev
In-Reply-To: <20101112140947.GB28223@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <cbouatmailru@gmail.com>
Date: Fri, 12 Nov 2010 17:09:47 +0300
> On Fri, Nov 12, 2010 at 02:55:09PM +0100, Joakim Tjernlund wrote:
>> This script:
>> while [ 1==1 ] ; do ifconfig eth0 up; usleep 1950000 ;ifconfig eth0 down; dmesg -c ;done
>> causes in just a second or two:
>> INFO: task ifconfig:572 blocked for more than 120 seconds.
> [...]
>> The reason appears to be ucc_geth_stop meets adjust_link as the
>> PHY reports PHY changes. I belive adjust_link hangs somewhere,
>> holding the PHY lock, because ucc_geth_stop disabled the
>> controller HW.
>> Fix is to stop the PHY before disabling the controller.
>>
>> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> It's unclear where exactly adjust_link() hangs, but the patch
> looks as the right thing overall.
>
> Thanks!
>
> Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] ucc_geth: Do not bring the whole IF down when TX failure.
From: David Miller @ 2010-11-12 20:24 UTC (permalink / raw)
To: cbouatmailru; +Cc: Joakim.Tjernlund, linuxppc-dev, netdev
In-Reply-To: <20101112140515.GA28223@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <cbouatmailru@gmail.com>
Date: Fri, 12 Nov 2010 17:05:15 +0300
> On Fri, Nov 12, 2010 at 02:55:08PM +0100, Joakim Tjernlund wrote:
>> ucc_geth_close lacks a cancel_work_sync(&ugeth->timeout_work)
>> to stop any outstanding processing of TX fail. However, one
>> can not call cancel_work_sync without fixing the timeout function
>> otherwise it will deadlock. This patch brings ucc_geth in line with
>> gianfar:
>>
>> Don't bring the interface down and up, just reinit controller HW
>> and PHY.
>>
>> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> Looks sane, thanks!
>
> Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 v2 3/3] ixgbe: Look inside vlan when determining offload protocol.
From: David Miller @ 2010-11-12 20:24 UTC (permalink / raw)
To: jesse
Cc: netdev, hzheng, jeffrey.t.kirsher, alexander.h.duyck,
jesse.brandeburg
In-Reply-To: <1289519279-20641-3-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Thu, 11 Nov 2010 15:47:59 -0800
> From: Hao Zheng <hzheng@nicira.com>
>
> Currently the skb->protocol field is used to setup various
> offloading parameters on transmit for the correct protocol.
> However, if vlan offloading is disabled or otherwise not used,
> the protocol field will be ETH_P_8021Q, not the actual protocol.
> This will cause the offloading to be not performed correctly,
> even though the hardware is capable of looking inside vlan tags.
> Instead, look inside the header if necessary to determine the
> correct protocol type.
>
> To some extent this fixes a regression from 2.6.36 because it
> was previously not possible to disable vlan offloading and this
> error case was not exposed.
>
> Signed-off-by: Hao Zheng <hzheng@nicira.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: Alex Duyck <alexander.h.duyck@intel.com>
> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Applied.
^ 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