* 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
* Re: [PATCH NEXT 1/2] netxen: Notify firmware of Flex-10 interface down
From: David Miller @ 2011-03-14 22:14 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, sony.chacko
In-Reply-To: <1299837003-5616-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Fri, 11 Mar 2011 01:50:02 -0800
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> Notify firmware when a Flex-10 interface is brought down
> so that virtual connect manager can display the correct link status.
>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: David Miller @ 2011-03-14 22:15 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, sony.chacko
In-Reply-To: <1299837003-5616-3-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Fri, 11 Mar 2011 01:50:03 -0800
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> o Allow setting speed and auto negotiation parameters for GbE ports.
> o Log an error message to indicate duplex setting is not supported in
> the hardware currently.
>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
The kernel log is not the place to transmit this information.
Please work with Ben Hutchings who is working for ways to report
this to the user in the proper location, via ethtool.
^ permalink raw reply
* Re: [PATCH net-next-2.6] be2net: changes for BE3 native mode support
From: David Miller @ 2011-03-14 22:17 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <9260707d-e902-4497-a550-a5125c46e2c4@exht1.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Fri, 11 Mar 2011 18:19:26 +0530
> So far be2net has been using BE3 in legacy mode. It now checks for native
> mode capability and if available it sets it. In native mode, the RX_COMPL
> structure is different from that in legacy mode.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [GIT/PATCH v5] xen network backend driver
From: Ian Campbell @ 2011-03-14 22:17 UTC (permalink / raw)
To: David Miller
Cc: bhutchings@solarflare.com, netdev@vger.kernel.org,
xen-devel@lists.xensource.com, jeremy@goop.org,
herbert@gondor.apana.org.au, konrad.wilk@oracle.com,
romieu@fr.zoreil.com, shemminger@vyatta.com, mirqus@gmail.com
In-Reply-To: <20110314.132355.226777213.davem@davemloft.net>
On Mon, 2011-03-14 at 20:23 +0000, David Miller wrote:
> From: Ian Campbell <Ian.Campbell@eu.citrix.com>
> Date: Mon, 14 Mar 2011 19:30:40 +0000
>
> > On Mon, 2011-03-14 at 18:40 +0000, Ben Hutchings wrote:
> >> I know you have asked for this to be pulled, in order to retain its
> >> history, but I'm not sure that David Miller will do this unless the
> >> driver is at least buildable at each stage in the history. (However,
> >> given that the driver wouldn't be enabled before it's added, I'm not
> >> sure it matters in this case.)
> >
> > I think it should be, at least from the second commit onwards (modulo
> > any mistakes made in the past).
>
> I don't want to retain all of that history, there are so many broken
> points in the history that the only thing you can do is go back and
> add Kconfig commits to depend the driver upon BROKEN, and that in effect
> changes the history devalueing it even further.
>
> I just want one patch that adds the driver in it's most current state,
> and that's all.
Would you consider a commit patch which imports the baseline driver as
is from xen.git (this builds and is functional but needed clean up)
followed by the cleanup series? I made sure the cleanup part builds and
works at each step as I went (but I will run through it again to be
sure).
There is real value (to me at least) in keeping the cleanup separate and
being able to (even manually) associate the first upstream commit with
an equivalent point in the historical code.
IOW 1952b4d9e6c8..072407c789a0 collapse to a single commit followed by
(s/0724.../$COLLAPSED COMMIT ID/):
The following changes since commit 072407c789a0cdc6b8adba49d5bbfac5d5feb9d3:
Ian Campbell (1):
xen: netback: handle incoming GSO SKBs which are not CHECKSUM_PARTIAL
are available in the git repository at:
git://xenbits.xen.org/people/ianc/linux-2.6.git upstream/dom0/backend/netback
Ian Campbell (38):
xen: netback: rationalise types used in count_skb_slots
xen: netback: refactor logic for moving to a new receive buffer.
xen: netback: refactor code to get next rx buffer into own function.
xen: netback: simplify use of netbk_add_frag_responses
xen: netback: cleanup coding style
xen: netback: drop private ?PRINTK macros in favour of pr_*
xen: netback: move under drivers/net/xen-netback/
xen: netback: remove queue_length module option
xen: netback: correct error return from ethtool hooks.
xen: netback: avoid leading _ in function parameter names.
xen: netback: drop unused debug interrupt handler.
xen: netif: properly namespace the Xen netif protocol header.
xen: netif: improve Kconfig help text for front- and backend drivers.
xen: netback: drop ethtool drvinfo callback
xen: netback: use xen_netbk prefix where appropriate
xen: netback: refactor to make all xen_netbk knowledge internal to netback.c
xen: netback: use xenvif_ prefix where appropriate
xen: netback: add reference from xenvif to xen_netbk
xen: netback: refactor to separate network device from worker pools
xen: netback: switch to kthread mode and drop tasklet mode
xen: netback: handle frames whose head crosses a page boundary
xen: netback: return correct values from start_xmit
xen: netback: remove useless memset to zero.
xen: netback: use register_netdev()
xen: netback: simplify unwinding netback_init's work on failure.
xen: netback: use core network carrier flag.
xen: netback: s/xenvif_queue_full/xenvif_rx_queue_full/
xen: netback: add xenvif_rx_schedulable
xen: netback: further separate xen_netbk and xenvif
xen: netback: use netdev_LEVEL instead of pr_LEVEL
xen: netback: drop rx_notify and notify_list array in favour of a normal list
xen: netback: Make dependency on PageForeign conditional
xen: netback: completely drop foreign page support
xen: netback: ethtool stats fields should be unsigned long
xen: netback: do not update last_rx on receive.
xen: netback: Allow headroom for VLAN header in SG MTU calculation.
xen: netback: use stats from struct net_device
xen: netback: netdevice features should be u32
drivers/net/Kconfig | 38 +-
drivers/net/Makefile | 1 +
drivers/{xen/netback => net/xen-netback}/Makefile | 0
drivers/net/xen-netback/common.h | 161 ++
drivers/net/xen-netback/interface.c | 424 +++++
drivers/net/xen-netback/netback.c | 1745 +++++++++++++++++++
drivers/{xen/netback => net/xen-netback}/xenbus.c | 155 +-
drivers/net/xen-netfront.c | 20 +-
drivers/xen/Kconfig | 7 -
drivers/xen/Makefile | 1 -
drivers/xen/netback/common.h | 326 ----
drivers/xen/netback/interface.c | 471 -----
drivers/xen/netback/netback.c | 1902 ---------------------
include/xen/interface/io/netif.h | 80 +-
14 files changed, 2483 insertions(+), 2848 deletions(-)
rename drivers/{xen/netback => net/xen-netback}/Makefile (100%)
create mode 100644 drivers/net/xen-netback/common.h
create mode 100644 drivers/net/xen-netback/interface.c
create mode 100644 drivers/net/xen-netback/netback.c
rename drivers/{xen/netback => net/xen-netback}/xenbus.c (75%)
delete mode 100644 drivers/xen/netback/common.h
delete mode 100644 drivers/xen/netback/interface.c
delete mode 100644 drivers/xen/netback/netback.c
^ permalink raw reply
* Re: [GIT/PATCH v5] xen network backend driver
From: David Miller @ 2011-03-14 22:22 UTC (permalink / raw)
To: Ian.Campbell
Cc: bhutchings, netdev, xen-devel, jeremy, herbert, konrad.wilk,
romieu, shemminger, mirqus
In-Reply-To: <1300141060.32696.36.camel@localhost.localdomain>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
Date: Mon, 14 Mar 2011 22:17:40 +0000
> Would you consider a commit patch which imports the baseline driver as
> is from xen.git (this builds and is functional but needed clean up)
> followed by the cleanup series? I made sure the cleanup part builds and
> works at each step as I went (but I will run through it again to be
> sure).
>
> There is real value (to me at least) in keeping the cleanup separate and
> being able to (even manually) associate the first upstream commit with
> an equivalent point in the historical code.
Do you have any idea what that thing is going to do for poor souls trying
to bisect?
GIT is going to hop in and out of your line of development for any GIT
bisect that traverses any period of time in which those driver commits
exists.
It's too messy.
You can keep your tree online somewhere to publish the history, just
like we do for the old bitkeeper import and similar.
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: Michael Smith @ 2011-03-14 22:23 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110314.151424.212690587.davem@davemloft.net>
David Miller wrote:
> Existing arguments might be large enough to carry more than one piece
> of information :-)
If it's encoded into another argument, would there be more overhead from
bit-shifting it out than you'd save by losing an argument?
>> 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().
True, but the result of the reverse FIB lookup could be passed around.
Mike
^ permalink raw reply
* Re: [PATCH 1/2] NET: cdc-phonet, fix stop-queue handling
From: David Miller @ 2011-03-14 22:23 UTC (permalink / raw)
To: remi.denis-courmont
Cc: jslaby, jirislaby, netdev, gregkh, linux-usb, linux-kernel
In-Reply-To: <201103140939.57056.remi.denis-courmont@nokia.com>
From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Date: Mon, 14 Mar 2011 09:39:56 +0200
> On Sunday 13 March 2011 18:54:30 ext Jiri Slaby, you wrote:
>> Currently there is a warning emitted by the cdc-phonet driver:
>> WARNING: at include/linux/netdevice.h:1557 usbpn_probe+0x3bb/0x3f0
>> [cdc_phonet]() Modules linked in: ...
>> Pid: 5877, comm: insmod Not tainted 2.6.37.3-16-desktop #1
>> Call Trace:
>> [<ffffffff810059b9>] dump_trace+0x79/0x340
>> [<ffffffff81520fdc>] dump_stack+0x69/0x6f
>> [<ffffffff810580eb>] warn_slowpath_common+0x7b/0xc0
>> [<ffffffffa00254fb>] usbpn_probe+0x3bb/0x3f0 [cdc_phonet]
>> ...
>> ---[ end trace f5d3e02908603ab4 ]---
>> netif_stop_queue() cannot be called before register_netdev()
>>
>> So remove netif_stop_queue from the probe funtction to avoid that.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>> Cc: David S. Miller <davem@davemloft.net>
>
> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] NET: cdc-phonet, handle empty phonet header
From: David Miller @ 2011-03-14 22:24 UTC (permalink / raw)
To: remi.denis-courmont
Cc: jslaby, jirislaby, netdev, gregkh, linux-usb, linux-kernel
In-Reply-To: <201103140949.04760.remi.denis-courmont@nokia.com>
From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Date: Mon, 14 Mar 2011 09:49:04 +0200
> On Sunday 13 March 2011 18:54:31 ext Jiri Slaby, you wrote:
>> Currently, for N 5800 XM I get:
>> cdc_phonet: probe of 1-6:1.10 failed with error -22
>>
>> It's because phonet_header is empty. Extra altsetting looks like
>> there:
>> E 05 24 00 01 10 03 24 ab 05 24 06 0a 0b 04 24 fd .$....$..$....$.
>> E 00 .
>>
>> I don't see the header used anywhere so just check if the phonet
>> descriptor is there, not the structure itself.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>> Cc: David S. Miller <davem@davemloft.net>
>
> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Also applied, thanks.
^ 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