Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] inet: fix inet_bind_bucket_for_each
From: David Miller @ 2009-11-14  4:49 UTC (permalink / raw)
  To: lgrijincu; +Cc: netdev, opurdila
In-Reply-To: <200911121707.26224.lgrijincu@ixiacom.com>

From: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
Date: Thu, 12 Nov 2009 17:07:26 +0200

> The first "node" is supposed to be the cursor used in the for_each.
> 
> The second "node" is ment literally and should not be macro expanded:
> it's the name of the hlist_node field from the inet_bind_bucket.
> 
> This currently works because when inet_bind_bucket_for_each is called
> it's argument is still "node".
> 
> Signed-off-by: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>

Applied.

^ permalink raw reply

* Re: [net-next-2.6 PATCH] ixgbe: Make queue pairs on single MSI-X interrupts
From: David Miller @ 2009-11-14  4:49 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, peter.p.waskiewicz.jr
In-Reply-To: <20091113095035.2059.13992.stgit@localhost.localdomain>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 13 Nov 2009 01:50:43 -0800

> From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> 
> This patch pairs similar-numbered Rx and Tx queues onto a single
> MSI-X vector.  For example, Tx queue 0 and Rx queue 0's interrupt
> with be ethX-RxTx-0.  This allows for more efficient cleanup, since
> fewer interrupts will be firing during device operation.  It also
> helps with a cleaner CPU affinity for IRQ affinity.
> 
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

^ permalink raw reply

* Re: [patch 0/4] s390: networking patches for 2.6.33
From: David Miller @ 2009-11-14  4:49 UTC (permalink / raw)
  To: ursula.braun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens
In-Reply-To: <20091113074626.078348000@linux.vnet.ibm.com>

From: Ursula Braun <ursula.braun@de.ibm.com>
Date: Fri, 13 Nov 2009 08:46:26 +0100

> here is a set of networking patches for 2.6.33.
> 
> shortlog:
> Frank  Blaschka (1)
> ctcm: suspend has to wait for outstanding I/O
> 
> Ursula Braun (3)
> iucv: add work_queue cleanup for suspend
> s390: remove cu3088 layer for lcs and ctcm
> netiucv: displayed TX bytes value much too high

All applied, thanks.

^ permalink raw reply

* Re: [net-next-2.6 PATCH] ixgbe: Flush the LSC mask change to prevent repeated interrupts
From: David Miller @ 2009-11-14  4:48 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, shannon.nelson
In-Reply-To: <20091113044709.1601.82693.stgit@localhost.localdomain>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 12 Nov 2009 20:47:11 -0800

> From: Nelson, Shannon <shannon.nelson@intel.com>
> 
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

^ permalink raw reply

* Re: [net-next-2.6 PATCH 1/7] igb: change type for ring sizes to u16 in igb_set_ring_param
From: David Miller @ 2009-11-14  4:48 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20091113043604.1240.80142.stgit@localhost.localdomain>


All 7 patches applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next-2.6] igmp: Use next_net_device_rcu()
From: David Miller @ 2009-11-14  4:39 UTC (permalink / raw)
  To: shemminger; +Cc: eric.dumazet, netdev
In-Reply-To: <20091111211435.570b259a@nehalam>

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 11 Nov 2009 21:14:35 -0800

> On Thu, 12 Nov 2009 04:48:52 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
>> We need to use next_det_device_rcu() in RCU protected section.
>> 
>> We also can avoid in_dev_get()/in_dev_put() overhead (code size mainly)
>> in rcu_read_lock() sections.
>> 
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> 
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next-2.6] ipv6: use RCU to walk list of network devices
From: David Miller @ 2009-11-14  4:39 UTC (permalink / raw)
  To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <4AFB8246.6060804@gmail.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Nov 2009 04:34:30 +0100

> [PATCH net-next-2.6] ipv6: use RCU to walk list of network devices
> 
> No longer need read_lock(&dev_base_lock), use RCU instead.
> We also can avoid taking references on inet6_dev structs.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied.

^ permalink raw reply

* Re: [patch 4/5] [PATCH] qeth: rework TSO functions
From: David Miller @ 2009-11-14  4:36 UTC (permalink / raw)
  To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20091112101301.126320000@de.ibm.com>

From: frank.blaschka@de.ibm.com
Date: Thu, 12 Nov 2009 11:11:44 +0100

> From: Frank Blaschka <frank.blaschka@de.ibm.com>
> 
> The maximum TSO size OSA can handle is 15 * PAGE_SIZE. This
> patch reduces gso_max_size to this value and adds some sanity
> checks and statistics to the TSO implementation.
> Since only layer 3 is able to do TSO move all TSO related functions
> to the qeth_l3 module.
> 
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>

Please don't add sysctl knobs for getting and setting TSO enabling,
that's what ethtool is for.

^ permalink raw reply

* Re: [PATCH] X25: Enable setting of cause and diagnostic fields
From: David Miller @ 2009-11-14  4:32 UTC (permalink / raw)
  To: andrew.hendry; +Cc: netdev, linux-x25, linux-kernel
In-Reply-To: <d45a3acc0911111613v38fa9df4jed21876ce6309097@mail.gmail.com>

From: andrew hendry <andrew.hendry@gmail.com>
Date: Thu, 12 Nov 2009 11:13:27 +1100

> Adds SIOCX25SCAUSEDIAG, allowing X.25 programs to set the cause and
> diagnostic fields.
> Normally used to indicate status upon closing connections.
> 
> Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>

This change is incomplete.

You need to add handling to compat_x25_ioctl().

^ permalink raw reply

* Re: r8169: Fix receive buffer length when MTU is between 1515 and 1536
From: David Miller @ 2009-11-14  3:59 UTC (permalink / raw)
  To: ray; +Cc: romieu, netdev
In-Reply-To: <4AFDC703.10902@apollo.lv>


Applied, thank you.

^ permalink raw reply

* Re: [PATCH] can: add the missing netlink get_xstats_size callback
From: David Miller @ 2009-11-14  3:58 UTC (permalink / raw)
  To: wg; +Cc: netdev, socketcan-core
In-Reply-To: <4AFC2AED.1090607@grandegger.com>

From: Wolfgang Grandegger <wg@grandegger.com>
Date: Thu, 12 Nov 2009 16:34:05 +0100

> This patch adds the missing "get_xstats_size" callback for the
> netlink interface, which is required if "fill_xstats" is used,
> as pointed out by Patrick McHardy.
> 
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-2.6] can: Fix driver Kconfig structure
From: David Miller @ 2009-11-14  3:58 UTC (permalink / raw)
  To: oliver; +Cc: wg, netdev, socketcan-core
In-Reply-To: <4AFBF2E5.1090909@hartkopp.net>

From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Thu, 12 Nov 2009 12:35:01 +0100

> In 2.6.32-rc the new EMS USB CAN driver was contributed and added the Kconfig
> entry right behind an entry of the same *vendor*. This teared the SJA1000
> based driver selection into pieces.
> 
> This fix cleans up the 2.6.32-rc Kconfig files for the CAN drivers and moves
> the SJA1000 and USB Kconfig portions into the belonging directories.
> 
> As there are many new CAN drivers in the queue getting this cleanup into
> 2.6.32-rc would massively reduce the problems for the upcoming drivers.
> 
> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>

Applied.

^ permalink raw reply

* Re: [patch] missing dev_put() on error path in vif_add()
From: David Miller @ 2009-11-14  3:57 UTC (permalink / raw)
  To: ellre923; +Cc: error27, netdev
In-Reply-To: <4AFB77DA.3040600@gmail.com>

From: Wang Chen <ellre923@gmail.com>
Date: Thu, 12 Nov 2009 10:50:02 +0800

> Dan Carpenter said the following on 2009-11-11 20:03:
>> The other error paths in front of this one have a dev_put() but this one 
>> got missed.
>> 
>> Found by smatch static checker.
 ...
>> Signed-off-by: Dan Carpenter <error27@gmail.com>
 ...
> It's my fault. Introduced in 7dc00c82cbb0119cf4663f65bbaa2cc55f961db2.
> 
> Acked-by: Wang Chen <ellre923@gmail.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] s2io: fixing a ethtool test that is broken
From: David Miller @ 2009-11-14  3:57 UTC (permalink / raw)
  To: leitao; +Cc: netdev, sreenivasa.honnur
In-Reply-To: <1257882263-7507-1-git-send-email-leitao@linux.vnet.ibm.com>

From: leitao@linux.vnet.ibm.com
Date: Tue, 10 Nov 2009 14:44:23 -0500

> Due commit 4b77b0a2ba27d64f58f16d8d4d48d8319dda36ff, it is not more
> possible to pci_restore_state() more than once without calling
> pci_save_state() in the middle.
> 
> Actually running a ethtool test on s2io makes the card inactive, 
> and it needs to unload/reload the module to fix. 
> 
> This patch just save the state just after it restore in order to
> keep the old behaviour
> 
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>

Applied.

^ permalink raw reply

* Re: [PATCH] sctp: Set socket source address when additing first transport
From: David Miller @ 2009-11-14  3:57 UTC (permalink / raw)
  To: vladislav.yasevich; +Cc: netdev, linux-sctp
In-Reply-To: <1257976477-31326-1-git-send-email-vladislav.yasevich@hp.com>

From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Wed, 11 Nov 2009 16:54:37 -0500

> Recent commits
> 	sctp: Get rid of an extra routing lookup when adding a transport
> and
> 	sctp: Set source addresses on the association before adding transports
> 
> changed when routes are added to the sctp transports.  As such,
> we didn't set the socket source address correctly when adding the first
> transport.  The first transport is always the primary/active one, so
> when adding it, set the socket source address.  This was causing
> regression failures in SCTP tests.
> 
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>

Applied.

^ permalink raw reply

* Re: [PATCH] sctp: Fix regression introduced by new sctp_connectx api
From: David Miller @ 2009-11-14  3:57 UTC (permalink / raw)
  To: vladislav.yasevich; +Cc: netdev, linux-sctp
In-Reply-To: <1257963564-26376-1-git-send-email-vladislav.yasevich@hp.com>

From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Wed, 11 Nov 2009 13:19:24 -0500

> A new (unrealeased to the user) sctp_connectx api
> 
> c6ba68a26645dbc5029a9faa5687ebe6fcfc53e4
>     sctp: support non-blocking version of the new sctp_connectx() API
> 
> introduced a regression cought by the user regression test
> suite.  In particular, the API requires the user library to
> re-allocate the buffer and could potentially trigger a SIGFAULT.
> 
> This change corrects that regression by passing the original
> address buffer to the kernel unmodified, but still allows for
> a returned association id.
> 
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>

Applied.

^ permalink raw reply

* Re: [PATCH] sctp: Set source addresses on the association before adding transports
From: David Miller @ 2009-11-14  3:57 UTC (permalink / raw)
  To: vladislav.yasevich; +Cc: netdev, linux-sctp
In-Reply-To: <1257879454-31661-1-git-send-email-vladislav.yasevich@hp.com>

From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Tue, 10 Nov 2009 13:57:34 -0500

> Recent commit 8da645e101a8c20c6073efda3c7cc74eec01b87f
> 	sctp: Get rid of an extra routing lookup when adding a transport
> introduced a regression in the connection setup.  The behavior was
> different between IPv4 and IPv6.  IPv4 case ended up working because the
> route lookup routing returned a NULL route, which triggered another
> route lookup later in the output patch that succeeded.  In the IPv6 case,
> a valid route was returned for first call, but we could not find a valid
> source address at the time since the source addresses were not set on the
> association yet.  Thus resulted in a hung connection.
> 
> The solution is to set the source addresses on the association prior to
> adding peers.
> 
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>

Applied.

^ permalink raw reply

* Re: [PATCH] forcedeth: mac address fix
From: David Miller @ 2009-11-14  3:52 UTC (permalink / raw)
  To: stas; +Cc: aabdulla, yinghai, netdev, linux-kernel
In-Reply-To: <1258114975-5715-1-git-send-email-stas@lvk.cs.msu.su>

From: "Stanislav O\. Bezzubtsev" <stas@lvk.cs.msu.su>
Date: Fri, 13 Nov 2009 15:22:55 +0300

> Set second bit of randomly generated mac. That marks MAC
> as locally assigned. IEEE802.3, section one, 3.2.3.
> 
> Signed-off-by: Stanislav O. Bezzubtsev <stas@lvk.cs.msu.su>

Do you know why this driver even has this bug?

It's because it does not use random_ether_addr() and tries to
do it by hand all by itself.

Please fix this bug for real by having the driver use the proper
interface to calculate a randomized ethernet address.

Thank you.

^ permalink raw reply

* Re: [PATCH] ppp: fix BUG on non-linear SKB (multilink receive)
From: David Miller @ 2009-11-14  3:46 UTC (permalink / raw)
  To: ben; +Cc: paulus, netdev, linux-ppp
In-Reply-To: <Pine.LNX.4.58.0911121144380.25398@benxen>

From: Ben McKeegan <ben@netservers.co.uk>
Date: Thu, 12 Nov 2009 13:09:57 +0000 (GMT)

> @@ -1944,7 +1944,13 @@ ppp_receive_mp_frame(struct ppp *ppp, st
> 
>  	/* Pull completed packets off the queue and receive them. */
>  	while ((skb = ppp_mp_reconstruct(ppp)))
> -		ppp_receive_nonmp_frame(ppp, skb);
> +	  	if (pskb_may_pull(skb, 2))
> +			ppp_receive_nonmp_frame(ppp, skb);
> +		else {
> +			++ppp->dev->stats.rx_length_errors;
> +			kfree_skb(skb);
> +			ppp_receive_error(ppp);
> +		}
> 
>  	return;

This fix looks correct, but could you please enclose the while()
loop in braces, that dangling else and the subsequent "return;"
statement look confusing otherwise.

Thanks.

^ permalink raw reply

* Re: [PATCH]NET:PCNET32: poll method return 0 when done
From: David Miller @ 2009-11-14  3:39 UTC (permalink / raw)
  To: pcnet32; +Cc: figo1802, netdev
In-Reply-To: <1258042401.7727.3.camel@localhost.localdomain>

From: Don Fry <pcnet32@verizon.net>
Date: Thu, 12 Nov 2009 08:13:21 -0800

> I do not understand why you are suggesting this change.  With NAPI
> the amount of work done is returned on exit, not zero.  All other
> drivers I have looked at do not force a zero on exit.
> 
> NAK

Right, this change is completely wrong.

^ permalink raw reply

* Re: [PATCH] s2io: fixing a ethtool test that is broken
From: David Miller @ 2009-11-14  3:36 UTC (permalink / raw)
  To: Sivakumar.Subramani; +Cc: leitao, netdev, Sreenivasa.Honnur, Ramkrishna.Vepa
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7705E74E6F@nekter>

From: "Sivakumar Subramani" <Sivakumar.Subramani@neterion.com>
Date: Thu, 12 Nov 2009 13:59:53 -0500

> [Siva] Reviewed the patch. Please accept it.
> 
> Acked-by: Sivakumar Subramani <sivakumar.subramani@neterion.com>

Please use reasonable mechanisms to reply to patches when you review
them.  Something in your mail client software or elsewhere has messed
with the Message-Id and other elements of the email headers, and
therefore the threading of messages so that patchwork and other tools
can attach your reply to the patch posting itself simply do not work.

This makes more work for me and I am not going to go searching for
your replies by hand.

So you should fix this because otherwise your review reply ACKs
will get lost.

Also you have this very non-standard way to attributing your content
by adding these "[Name]" tags.  Please don't do that, it is
non-standard and therefore most people don't understand it at all.

The normal email reply quoting mechanisms of your email client will
let us know exactly what parts are written by you, and what parts are
said by other people in quoted text.

Thank you.

^ permalink raw reply

* Re: [RFC PATCH] net: add dataref destructor to sk_buff
From: David Miller @ 2009-11-14  3:09 UTC (permalink / raw)
  To: gregory.haskins
  Cc: herbert, ghaskins, mst, alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <4AFE15AD.6000208@gmail.com>

From: Gregory Haskins <gregory.haskins@gmail.com>
Date: Fri, 13 Nov 2009 21:27:57 -0500

> Clearly there must be _some_ mechanism to synchronize (e.g.
> flush/barrier) though, right?  Otherwise, that interface would seem to
> be quite prone to races and would likely be unusable.   So what does
> said flush use to know when the buffer is free?

There is no such synchronization at all.

If some synchronization is required, it must be done at a higher
level.

For example, SAMBA can only use sendfile() to serve file contents when
the client holds an SMB "OP Lock" on the file.  Luckily, by default
pretty much all SMB client implementations hold the OP Lock on a file
even just to read it (this is so that self-modifying autoexec.bat
scripts work :-)

But frankly most sendfile() consumers don't care, and the only thing
that really matters is that the checksum on the final TCP packet that
goes out is correct, and since we require card checksums to sendfile()
without copying, that is taken care of transparently.

^ permalink raw reply

* Re: [RFC PATCH] net: add dataref destructor to sk_buff
From: David Miller @ 2009-11-14  3:04 UTC (permalink / raw)
  To: gregory.haskins
  Cc: herbert, ghaskins, mst, alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <4AFE08EF.2030308@gmail.com>

From: Gregory Haskins <gregory.haskins@gmail.com>
Date: Fri, 13 Nov 2009 20:33:35 -0500

> Well, not with respect to the overall protocol, of course not.  But with
> respect to the buffer in question, it _has_ to be.  Or am I missing
> something?

sendfile() absolutely, and positively, is not.

Any entity can write to the pages being send via sendfile(), at will,
and those writes will show up in the packet stream if they occur
before the NIC DMA's the memory backed by those pages into it's
buffer.

There is zero data synchronization whatsoever, we don't lock the
pages, we don't block their usage while they are queued up in the
socket send queue, nothing like that.

The user returns long before it every hits the wire and there is zero
"notification" to the user that the pages in question for the
sendfile() request are no longer in use.

It seems that your understanding of how buffering and synchronization
works in the TCP stack has come out of a fairy tale :-)

^ permalink raw reply

* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: David Miller @ 2009-11-14  2:59 UTC (permalink / raw)
  To: bcrl; +Cc: shemminger, opurdila, eric.dumazet, netdev
In-Reply-To: <20091113235210.GR19478@kvack.org>

From: Benjamin LaHaise <bcrl@lhnet.ca>
Date: Fri, 13 Nov 2009 18:52:10 -0500

> If you don't want the overhead from this kind of scaling, stick it under a 
> config option, but please don't stop other people from pushing Linux into 
> new uses which have these scaling requirements.

This 'scaling requirement' only exists in environments where people
undersubsribe their networks, right?

I'm not saying we won't put scaling into these areas, I'm just trying
to make a point to show that this "need" only exists because people
have purposefully created these situations where they feel the need to
massively control their users usage in order to generate revenue.

^ permalink raw reply

* Re: [RFC PATCH] net: add dataref destructor to sk_buff
From: Herbert Xu @ 2009-11-14  2:51 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Gregory Haskins, Gregory Haskins, Michael S. Tsirkin,
	alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <20091113184503.13f6d447@s6510>

On Fri, Nov 13, 2009 at 06:45:03PM -0800, Stephen Hemminger wrote:
> 
> No all the interfaces require a copy. Actually, sendfile makes no guarantee about synchronization

Actually sendfile does not require a copy.

> because the receiver of said file could be arbitrarily slow, and any attempt at locking down
> current contents of file is a denial of service exposure.

Agreed.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox