* Re: [PATCH 4/6] net: sh_eth: modify the PHY_INTERFACE_MODE
From: David Miller @ 2011-03-14 21:11 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4D75E1F1.5090306@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Tue, 08 Mar 2011 16:59:45 +0900
> The previous code had hardcoded the PHY_INTERFACE_MODE_MII of phy_connect.
> So some Gigabit PHYs will not behave correctly.
> The patch adds the phy_interface in sh_eth_plat_data, so we can select
> the phy interface.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/6] net: sh_eth: modify the definitions of register
From: David Miller @ 2011-03-14 21:10 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4D75E1DE.3030408@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Tue, 08 Mar 2011 16:59:26 +0900
> The previous code cannot handle the ETHER and GETHER both as same time
> because the definitions of register was hardcoded.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 5/6] net: sh_eth: add support for SH7757's GETHER
From: David Miller @ 2011-03-14 21:11 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4D75E1F5.3050704@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Tue, 08 Mar 2011 16:59:49 +0900
> The SH7757 have GETHER and ETHER both. This patch supports them.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH 6/6] net: sh_eth: add set_mdio_gate in bb_info
From: David Miller @ 2011-03-14 21:11 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4D75E1FB.6000607@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Tue, 08 Mar 2011 16:59:55 +0900
> The SH7757's ETHER and GETHER use common MDIO pin. The MDIO pin is
> selected by specific register. So this patch adds new interface in
> bb_info, and when the sh_eth driver use the mdio, the register can
> be changed by the function.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* [PATCH] Disable rp_filter for IPsec packets
From: Michael Smith @ 2011-03-14 21:14 UTC (permalink / raw)
To: netdev
The reverse path filter interferes with IPsec subnet-to-subnet tunnels,
especially when the link to the IPsec peer is on an interface other than
the one hosting the default route.
With dynamic routing, where the peer might be reachable through eth0
today and eth1 tomorrow, it's difficult to keep rp_filter enabled unless
fake routes to the remote subnets are configured on the interface
currently used to reach the peer.
IPsec provides a much stronger anti-spoofing policy than rp_filter, so
this patch disables the rp_filter for packets with a security path.
Signed-off-by: Michael Smith <msmith@cbnco.com>
---
include/net/ip_fib.h | 2 +-
net/ipv4/fib_frontend.c | 4 ++--
net/ipv4/route.c | 26 ++++++++++++++++++--------
3 files changed, 21 insertions(+), 11 deletions(-)
I have a feeling the approach of checking for skb->sp != NULL is pretty
naive, but it seems to work. Patch is against Linus' tree.
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index 07bdb5e..61d5365 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -217,7 +217,7 @@ extern const struct nla_policy rtm_ipv4_policy[];
extern void ip_fib_init(void);
extern int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
struct net_device *dev, __be32 *spec_dst,
- u32 *itag, u32 mark);
+ u32 *itag, u32 mark, int norpf);
extern void fib_select_default(struct net *net, const struct flowi *flp,
struct fib_result *res);
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 1d2cdd4..ae889cc 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -245,7 +245,7 @@ EXPORT_SYMBOL(inet_dev_addr_type);
*/
int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
struct net_device *dev, __be32 *spec_dst,
- u32 *itag, u32 mark)
+ u32 *itag, u32 mark, int norpf)
{
struct in_device *in_dev;
struct flowi fl = {
@@ -265,7 +265,7 @@ int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
in_dev = __in_dev_get_rcu(dev);
if (in_dev) {
no_addr = in_dev->ifa_list == NULL;
- rpf = IN_DEV_RPFILTER(in_dev);
+ rpf = norpf ? 0 : IN_DEV_RPFILTER(in_dev);
accept_local = IN_DEV_ACCEPT_LOCAL(in_dev);
if (mark && !IN_DEV_SRC_VMARK(in_dev))
fl.mark = 0;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 6ed6603..3ada54c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1870,7 +1870,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
spec_dst = inet_select_addr(dev, 0, RT_SCOPE_LINK);
} else {
err = fib_validate_source(saddr, 0, tos, 0, dev, &spec_dst,
- &itag, 0);
+ &itag, 0, 0);
if (err < 0)
goto e_err;
}
@@ -1962,7 +1962,7 @@ static int __mkroute_input(struct sk_buff *skb,
struct fib_result *res,
struct in_device *in_dev,
__be32 daddr, __be32 saddr, u32 tos,
- struct rtable **result)
+ struct rtable **result, int norpf)
{
struct rtable *rth;
int err;
@@ -1982,7 +1982,8 @@ static int __mkroute_input(struct sk_buff *skb,
err = fib_validate_source(saddr, daddr, tos, FIB_RES_OIF(*res),
- in_dev->dev, &spec_dst, &itag, skb->mark);
+ in_dev->dev, &spec_dst, &itag, skb->mark,
+ norpf);
if (err < 0) {
ip_handle_martian_source(in_dev->dev, in_dev, skb, daddr,
saddr);
@@ -2059,7 +2060,7 @@ static int ip_mkroute_input(struct sk_buff *skb,
struct fib_result *res,
const struct flowi *fl,
struct in_device *in_dev,
- __be32 daddr, __be32 saddr, u32 tos)
+ __be32 daddr, __be32 saddr, u32 tos, int norpf)
{
struct rtable* rth = NULL;
int err;
@@ -2071,7 +2072,7 @@ static int ip_mkroute_input(struct sk_buff *skb,
#endif
/* create a routing cache entry */
- err = __mkroute_input(skb, res, in_dev, daddr, saddr, tos, &rth);
+ err = __mkroute_input(skb, res, in_dev, daddr, saddr, tos, &rth, norpf);
if (err)
return err;
@@ -2111,6 +2112,13 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
int err = -EINVAL;
struct net * net = dev_net(dev);
+#ifdef CONFIG_XFRM
+ /* Disable the reverse path filter for IPsec-protected packets. */
+ int norpf = skb->sp != NULL;
+#else
+ int norpf = 0;
+#endif
+
/* IP on this device is disabled. */
if (!in_dev)
@@ -2154,7 +2162,8 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (res.type == RTN_LOCAL) {
err = fib_validate_source(saddr, daddr, tos,
net->loopback_dev->ifindex,
- dev, &spec_dst, &itag, skb->mark);
+ dev, &spec_dst, &itag, skb->mark,
+ norpf);
if (err < 0)
goto martian_source_keep_err;
if (err)
@@ -2168,7 +2177,8 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (res.type != RTN_UNICAST)
goto martian_destination;
- err = ip_mkroute_input(skb, &res, &fl, in_dev, daddr, saddr, tos);
+ err = ip_mkroute_input(skb, &res, &fl, in_dev, daddr, saddr, tos,
+ norpf);
out: return err;
brd_input:
@@ -2179,7 +2189,7 @@ brd_input:
spec_dst = inet_select_addr(dev, 0, RT_SCOPE_LINK);
else {
err = fib_validate_source(saddr, 0, tos, 0, dev, &spec_dst,
- &itag, skb->mark);
+ &itag, skb->mark, norpf);
if (err < 0)
goto martian_source_keep_err;
if (err)
--
1.6.3.2
^ permalink raw reply related
* Re: [PATCH 4/7] tcp_cubic: fix clock dependency
From: Stephen Hemminger @ 2011-03-14 21:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <1300128679.3423.167.camel@edumazet-laptop>
On Mon, 14 Mar 2011 19:51:19 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 14 mars 2011 à 10:52 -0700, Stephen Hemminger a écrit :
> > pièce jointe document texte brut (tcp-cubic-minrtt.patch)
> > The hystart code was written with assumption that HZ=1000.
> > Replace the use of jiffies with bictcp_clock as a millisecond
> > real time clock.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> > Reported-by: Lucas Nussbaum <lucas.nussbaum@loria.fr>
> >
> > --- a/net/ipv4/tcp_cubic.c 2011-03-14 08:19:18.000000000 -0700
> > +++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:22:42.486690594 -0700
> > @@ -88,7 +88,7 @@ struct bictcp {
> > u32 last_time; /* time when updated last_cwnd */
> > u32 bic_origin_point;/* origin point of bic function */
> > u32 bic_K; /* time to origin point from the beginning of the current epoch */
> > - u32 delay_min; /* min delay */
> > + u32 delay_min; /* min delay (msec << 3) */
> > u32 epoch_start; /* beginning of an epoch */
> > u32 ack_cnt; /* number of acks */
> > u32 tcp_cwnd; /* estimated tcp cwnd */
> > @@ -98,7 +98,7 @@ struct bictcp {
> > u8 found; /* the exit point is found? */
> > u32 round_start; /* beginning of each round */
> > u32 end_seq; /* end_seq of the round */
> > - u32 last_jiffies; /* last time when the ACK spacing is close */
> > + u32 last_ack; /* last time when the ACK spacing is close */
> > u32 curr_rtt; /* the minimum rtt of current round */
> > };
> >
> > @@ -119,12 +119,21 @@ static inline void bictcp_reset(struct b
> > ca->found = 0;
> > }
> >
> > +static inline u32 bictcp_clock(void)
> > +{
> > +#if HZ < 1000
> > + return ktime_to_ms(ktime_get_real());
>
> Small point : This can be changed if date/time is changed
>
> Maybe use monotonic time (aka ktime_get_ts()) ?
I choose get_real() because that is what skb timestamp is using;
both should probably use monotonic clock.
--
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: David Miller @ 2011-03-14 21:25 UTC (permalink / raw)
To: msmith; +Cc: netdev
In-Reply-To: <1300137299-28161-1-git-send-email-msmith@cbnco.com>
From: Michael Smith <msmith@cbnco.com>
Date: Mon, 14 Mar 2011 17:14:59 -0400
> The reverse path filter interferes with IPsec subnet-to-subnet tunnels,
> especially when the link to the IPsec peer is on an interface other than
> the one hosting the default route.
>
> With dynamic routing, where the peer might be reachable through eth0
> today and eth1 tomorrow, it's difficult to keep rp_filter enabled unless
> fake routes to the remote subnets are configured on the interface
> currently used to reach the peer.
>
> IPsec provides a much stronger anti-spoofing policy than rp_filter, so
> this patch disables the rp_filter for packets with a security path.
>
> Signed-off-by: Michael Smith <msmith@cbnco.com>
First, I'm only willing to accept a patch like this to net-next-2.6
for which all of the code you are changing is radically different.
Secondly, fib_validate_source() already takes too many damn arguments.
Find another, less costly, way to pass this information down there.
Frankly, I think RPF should be disabled completely by default. When
it doesn't do anything useful, it's making route lookups twice as
expensive as they need to be.
^ permalink raw reply
* Re: [PATCH] drivers/net: fix build warnings with CONFIG_PM_SLEEP disabled
From: David Miller @ 2011-03-14 21:26 UTC (permalink / raw)
To: walken; +Cc: shemminger, netdev, akpm, torvalds, linux-kernel
In-Reply-To: <20110307021450.GC31188@google.com>
From: Michel Lespinasse <walken@google.com>
Date: Sun, 6 Mar 2011 18:14:50 -0800
> This fixes a couple of build warnings when CONFIG_PM is enabled but
> CONFIG_PM_SLEEP is disabled. Applies on top of v2.6.38-rc7 - I know it's
> late, but it would be great if v2.6.38 could compile without warnings!
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
I know it'd "be great" if this went into 2.6.38 but it doesn't fix
any real bugs, so I'm putting it into net-next-2.6
Thanks.
^ permalink raw reply
* Re: [PATCH] bridge: control carrier based on ports online
From: David Miller @ 2011-03-14 21:29 UTC (permalink / raw)
To: shemminger
Cc: nicolas.2p.debian, adamm, kuznet, pekkas, jmorris, yoshfuji,
kaber, bridge, netdev, andy, fubar
In-Reply-To: <20110307103406.27330529@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 7 Mar 2011 10:34:06 -0800
> This makes the bridge device behave like a physical device.
> In earlier releases the bridge always asserted carrier. This
> changes the behavior so that bridge device carrier is on only
> if one or more ports are in the forwarding state. This
> should help IPv6 autoconfiguration, DHCP, and routing daemons.
>
> I did brief testing with Network and Virt manager and they
> seem fine, but since this changes behavior of bridge, it should
> wait until net-next (2.6.39).
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied to net-next-2.6, thanks Stephen.
^ permalink raw reply
* Re: [PATCH 4/7] tcp_cubic: fix clock dependency
From: Eric Dumazet @ 2011-03-14 21:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110314142125.63e84ade@nehalam>
Le lundi 14 mars 2011 à 14:21 -0700, Stephen Hemminger a écrit :
> I choose get_real() because that is what skb timestamp is using;
> both should probably use monotonic clock.
>
>
This point was raised elsewhere, problem is tcpdump/libpcap probably
wants "real" time, not monotonic clock...
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: Michael Smith @ 2011-03-14 21:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110314.142520.28811818.davem@davemloft.net>
David Miller wrote:
> First, I'm only willing to accept a patch like this to net-next-2.6
> for which all of the code you are changing is radically different.
OK.
> Secondly, fib_validate_source() already takes too many damn arguments.
> Find another, less costly, way to pass this information down there.
What would be a less costly way to pass it? Could I just hand it the
whole skb?
> Frankly, I think RPF should be disabled completely by default. When
> it doesn't do anything useful, it's making route lookups twice as
> expensive as they need to be.
Yeah, it's disabled by default. It's an easy way of preventing spoofing
of internal source addresses from the Internet, so I like it.
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: David Miller @ 2011-03-14 21:41 UTC (permalink / raw)
To: msmith; +Cc: netdev
In-Reply-To: <4D7E88C7.5080706@cbnco.com>
From: Michael Smith <msmith@cbnco.com>
Date: Mon, 14 Mar 2011 17:29:43 -0400
> David Miller wrote:
>> Secondly, fib_validate_source() already takes too many damn arguments.
>> Find another, less costly, way to pass this information down there.
>
> What would be a less costly way to pass it? Could I just hand it the
> whole skb?
I don't see how passing a pointer is better than passing an interger.
In both cases you're adding an extra argument to the function.
I was trying to get you to think out of the box and come up with
something clever, but that isn't working. :-)
>> Frankly, I think RPF should be disabled completely by default. When
>> it doesn't do anything useful, it's making route lookups twice as
>> expensive as they need to be.
>
> Yeah, it's disabled by default. It's an easy way of preventing
> spoofing of internal source addresses from the Internet, so I like it.
It is not "disabled by default". fib_validate_source() still does a
limited validation of the reverse path, even with the sysctl is set to
zero.
I want it to do absolutely nothing, and instead just use inet_select_addr()
to calculate spec_dst.
Even the spec_dst calculation is spurious, necessary only in limited
situations, and even in that case only takes on special values for
multicast and broadcast addresses.
In short, fib_validate_source() is nothing but completely unnecessary
overhead in the common case.
^ permalink raw reply
* Re: [Bugme-new] [Bug 30952] New: asix driver broken since 2.6.35
From: Andrew Morton @ 2011-03-14 21:43 UTC (permalink / raw)
To: linux-usb, netdev; +Cc: bugzilla-daemon, bugme-daemon, lipski.bogdan
In-Reply-To: <bug-30952-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
The reporter says "workaround suggested in:
https://bugzilla.kernel.org/show_bug.cgi?id=16831 seems to work well
for me as well". That workaround appears to be "dump the kernel driver
and use the driver off the vendor's website".
On Sat, 12 Mar 2011 14:02:37 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=30952
>
> Summary: asix driver broken since 2.6.35
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.35+
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: lipski.bogdan@gmail.com
> Regression: Yes
>
>
> Hey,
>
> there a few reports in here logged but I am not sure if they are 100% the same,
> anyway you can close this one as duplicate if so.
> https://bugzilla.kernel.org/show_bug.cgi?id=16831
> https://bugzilla.kernel.org/show_bug.cgi?id=29082
>
> config:
> - gentoo x64, fully updated
> - tried kernels 2.6.36/2.6.37/2.6.37.3
> - network card d-link dub-e100:
> asix 5-2:1.0: eth2: register 'asix' at usb-0000:00:1d.7-2, ASIX AX88772 USB 2.0
> Ethernet
>
> Bus 005 Device 002: ID 2001:3c05 D-Link Corp. [hex] DUB-E100 Fast Ethernet
> [asix]
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 255 Vendor Specific Class
> bDeviceSubClass 255 Vendor Specific Subclass
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x2001 D-Link Corp. [hex]
> idProduct 0x3c05 DUB-E100 Fast Ethernet [asix]
> bcdDevice 0.01
> iManufacturer 1 D-Link Corporation
> iProduct 2 DUB-E100
> iSerial 3 000001
> bNumConfigurations 1
>
> card is connected directly to scientific atlanta epc2203 cable/voip modem for
> internet access, reason is isp locks it down to mac address and i really don't
> like calling them in case motherboard changes etc...
>
>
> the problem:
> 1. under 2.6.34 (tried 2.6.34-gentoo) everything seems to be well.
> 2. patch from 2.6.35/signed off by Jussi Kivilinna "[PATCH] asix: check packet
> size against mtu+ETH_HLEN instead of ETH_FRAME_LEN"
> => since this patch I am getting a lot of "asix_rx_fixup() Bad RX Length" and
> packets get dropped, under ifconfig I see RX error counter increasing for every
> message logged in dmesg, number of RX errors can shoot up easily to couple
> hundred thousands in just a few hours.
> 3. tried to revert this patch in 2.6.37.3 as it seems to be just a one-liner,
> but it looks like other patches applied to asix.c since 2.6.34 have also some
> influence. anyway when reverting this single patch the behaviour with plenty of
> error messages logged under dmesg stops and there are no RX errors logged under
> ifconfig. however it seems that after some time card starts loosing the packets
> again - i will update this report later if I have any further findings.
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 30952] New: asix driver broken since 2.6.35
From: David Miller @ 2011-03-14 21:45 UTC (permalink / raw)
To: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
lipski.bogdan-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20110314144309.a303662f.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Date: Mon, 14 Mar 2011 14:43:09 -0700
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> The reporter says "workaround suggested in:
> https://bugzilla.kernel.org/show_bug.cgi?id=16831 seems to work well
> for me as well". That workaround appears to be "dump the kernel driver
> and use the driver off the vendor's website".
This is an issue you've brought up to me several months ago.
I started looking into it, but because the vendor driver development
happens in a completely different universe the divergence noise is
substantial and it's a huge effort to consolidate these two drivers.
I think that until the vendor starts to care, nothing is going to
happen to resolve these ASIC driver bugs.
--
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: [PATCH] can: wrong index used in inner loop
From: David Miller @ 2011-03-14 21:47 UTC (permalink / raw)
To: roel.kluin-Re5JQEeQqe8AvxtiuMwx3w
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <4D768917.9040605-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: roel <roel.kluin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 08 Mar 2011 20:52:55 +0100
> Index i was already used in the outer loop.
>
> Signed-off-by: Roel Kluin <roel.kluin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
CAN maintainers, could you please review and ACK patches in a timely manner,
especially utterly trivial bug fixes like this one here?
That's largely what I've been waiting for, a simple sign of life from the
listed maintainers for these files.
Anyways, no use waiting any longer, applied, thanks Roel.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] enic: Support newer version of firmware devcmd CMD_MCPU_FW_INFO
From: David Miller @ 2011-03-14 21:49 UTC (permalink / raw)
To: vkolluri; +Cc: netdev
In-Reply-To: <20110309013530.17378.56666.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Tue, 08 Mar 2011 17:35:30 -0800
> From: Vasanthy Kolluri <vkolluri@cisco.com>
>
> This patch provides support to the newer version of firmware devcmd CMD_MCPU_FW_INFO
> that returns additional information (ASIC type and revision) about the underlying hardware.
> This knowledge is required by the driver to implement any hardware specific features.
>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
Applied, thanks.
^ permalink raw reply
* Re: [Bugme-new] [Bug 30952] New: asix driver broken since 2.6.35
From: Andrew Morton @ 2011-03-14 21:49 UTC (permalink / raw)
To: David Miller
Cc: linux-usb, netdev, bugzilla-daemon, bugme-daemon, lipski.bogdan
In-Reply-To: <20110314.144553.70194816.davem@davemloft.net>
On Mon, 14 Mar 2011 14:45:53 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Mon, 14 Mar 2011 14:43:09 -0700
>
> >
> > (switched to email. Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
> >
> > The reporter says "workaround suggested in:
> > https://bugzilla.kernel.org/show_bug.cgi?id=16831 seems to work well
> > for me as well". That workaround appears to be "dump the kernel driver
> > and use the driver off the vendor's website".
>
> This is an issue you've brought up to me several months ago.
>
> I started looking into it, but because the vendor driver development
> happens in a completely different universe the divergence noise is
> substantial and it's a huge effort to consolidate these two drivers.
>
> I think that until the vendor starts to care, nothing is going to
> happen to resolve these ASIC driver bugs.
Yup. I suppose an alternative approach might be to feed the current
vendor driver through the drivers/staging process (preferably with
their assistance!) then run with two alternative drivers for a
while and eventually remove the old one.
But that's without having looked at the vendor code. Is it a Big Mess?
^ permalink raw reply
* Re: [Bugme-new] [Bug 30952] New: asix driver broken since 2.6.35
From: David Miller @ 2011-03-14 21:57 UTC (permalink / raw)
To: akpm; +Cc: linux-usb, netdev, bugzilla-daemon, bugme-daemon, lipski.bogdan
In-Reply-To: <20110314144954.b87fdd64.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 14 Mar 2011 14:49:54 -0700
> But that's without having looked at the vendor code. Is it a Big Mess?
The vendor took the upstream driver at a point a year or two in the
past then did whatever they want with it.
They made no effort to "merge" in changes made to the upstream driver
during this time, so there is serious divergence especially in the PHY
handling which is probably where all the problems are in the upstream
driver.
Even the table of device IDs for probing is orderred and arranged
differently.
^ permalink raw reply
* Re: [PATCH net-next] bnx2: Update firmware and version
From: David Miller @ 2011-03-14 22:00 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1299628434-4443-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 8 Mar 2011 15:53:54 -0800
> Update 5709 mips firmware to 6.2.1a to fix iSCSI performance regression. There was an unnecessary context read in the fast path affecting performance.
>
> Update bnx2 to 2.1.6.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] phylib: SIOCGMIIREG/SIOCSMIIREG: allow access to all mdio addresses
From: David Miller @ 2011-03-14 22:02 UTC (permalink / raw)
To: jacmet; +Cc: netdev
In-Reply-To: <1299775933-26981-1-git-send-email-jacmet@sunsite.dk>
From: Peter Korsgaard <jacmet@sunsite.dk>
Date: Thu, 10 Mar 2011 17:52:13 +0100
> phylib would silently ignore the phy_id argument to these ioctls and
> perform the read/write with the active phydev address, whereas most
> non-phylib drivers seem to allow access to all mdio addresses
> (E.G. pcnet_cs).
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Applied, thanks.
^ permalink raw reply
* [PATCH net-next-2.6] bonding: enable netpoll without checking link status
From: Andy Gospodarek @ 2011-03-14 22:05 UTC (permalink / raw)
To: netdev; +Cc: WANG Cong, fubar
Only slaves that are up should transmit netpoll frames, so there is no
need to check to see if a slave is up before enabling netpoll on it.
This resolves a reported failure on active-backup bonds where a slave
interface is down when netpoll was enabled.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Tested-by: WANG Cong <amwang@redhat.com>
---
drivers/net/bonding/bond_main.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 7b7ca97..b14c377 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1352,8 +1352,6 @@ static int bond_netpoll_setup(struct net_device *dev, struct netpoll_info *ni)
read_lock(&bond->lock);
bond_for_each_slave(bond, slave, i) {
- if (!IS_UP(slave->dev))
- continue;
err = slave_enable_netpoll(slave);
if (err) {
__bond_netpoll_cleanup(bond);
^ permalink raw reply related
* Re: [PATCH] bridge: skip forwarding delay if not using STP
From: David Miller @ 2011-03-14 22:07 UTC (permalink / raw)
To: shemminger; +Cc: bridge, netdev
In-Reply-To: <20110310075704.47f91bd5@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 10 Mar 2011 07:57:04 -0800
> If Spanning Tree Protocol is not enabled, there is no good reason for
> the bridge code to wait for the forwarding delay period before enabling
> the link. The purpose of the forwarding delay is to allow STP to
> learn about other bridges before nominating itself.
>
> The only possible impact is that when starting up a new port
> the bridge may flood a packet now, where previously it might have
> seen traffic from the other host and preseeded the forwarding table.
>
> Includes change for local variable br already available in that func.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] xen: netfront: ethtool stats fields should be unsigned long
From: David Miller @ 2011-03-14 22:10 UTC (permalink / raw)
To: ian.campbell; +Cc: netdev, jeremy, bhutchings
In-Reply-To: <1299776658-15137-1-git-send-email-ian.campbell@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 10 Mar 2011 17:04:18 +0000
> Fixup the rx_gso_checksum_fixup field added in e0ce4af920eb to be
> unsigned long as suggested by Ben Hutchings in
> <1298919198.2569.14.camel@bwh-desktop>
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Applied, thanks Ian.
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: Michael Smith @ 2011-03-14 22:11 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110314.144156.245399355.davem@davemloft.net>
David Miller wrote:
>> What would be a less costly way to pass it? Could I just hand it the
>> whole skb?
>
> I don't see how passing a pointer is better than passing an interger.
> In both cases you're adding an extra argument to the function.
Yeah, I was thinking an sk_buff could replace the mark parameter,
possibly dev, maybe saddr, daddr, and tos too. On the other hand I can't
think of anything less onerous than an extra stack argument - unless
fib_validate_source() didn't exist at all.
> I was trying to get you to think out of the box and come up with
> something clever, but that isn't working. :-)
Yes, I got that, but I don't know what you are looking for, and don't
expect to succeed by trying something else at random.
> In short, fib_validate_source() is nothing but completely unnecessary
> overhead in the common case.
I'm not entitled to an opinion about fib_validate_source(). It feels
like it might be trying to do one too many things. If it were my code I
might split the RPF out from the spec_dst calculation, move the whole
lot into net/ipv4/route.c, and only do the fib_lookup() if RPF is
enabled or CONFIG_IP_ROUTE_CLASSID (i.e. we need to know the itag).
If that makes sense I'll give it a shot, but beware, I don't even know
what an itag is, and I don't see documentation for CONFIG_IP_ROUTE_CLASSID.
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: David Miller @ 2011-03-14 22:14 UTC (permalink / raw)
To: msmith; +Cc: netdev
In-Reply-To: <4D7E928C.1030707@cbnco.com>
From: Michael Smith <msmith@cbnco.com>
Date: Mon, 14 Mar 2011 18:11:24 -0400
> David Miller wrote:
>> I was trying to get you to think out of the box and come up with
>> something clever, but that isn't working. :-)
>
> Yes, I got that, but I don't know what you are looking for, and don't
> expect to succeed by trying something else at random.
Existing arguments might be large enough to carry more than one piece
of information :-)
>> In short, fib_validate_source() is nothing but completely unnecessary
>> overhead in the common case.
>
> I'm not entitled to an opinion about fib_validate_source(). It feels
> like it might be trying to do one too many things. If it were my code
> I might split the RPF out from the spec_dst calculation, move the
> whole lot into net/ipv4/route.c, and only do the fib_lookup() if RPF
> is enabled or CONFIG_IP_ROUTE_CLASSID (i.e. we need to know the itag).
Can't split two two things up, because spec_dst is a product of the
reverse FIB lookup, in the form of FIB_RES_PREFSRC().
^ 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