* Re: Pull request: sfc-next 2012-09-19
From: David Miller @ 2012-09-20 20:42 UTC (permalink / raw)
To: bhutchings; +Cc: richardcochran, giometti, linux-net-drivers, netdev, ajackson
In-Reply-To: <1348081775.2636.15.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 19 Sep 2012 20:09:35 +0100
> The following changes since commit b4516a288e71c64d7e214902250baf78b7b3cdcf:
>
> llc: Remove stray reference to sysctl_llc_station_ack_timeout. (2012-09-17 13:13:24 -0400)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next.git for-davem
>
> (commit 450783747f42dfa3883920acfad4acdd93ce69af)
>
> 1. Extension to PPS/PTP to allow for PHC devices where pulses are
> subject to a variable but measurable delay.
> 2. PPS/PTP/PHC support for Solarflare boards with a timestamping
> peripheral.
> 3. MTD support for updating the timestamping peripheral on those boards.
> 4. Fix for potential over-length requests to firmware.
Pulled, thanks Ben.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: David Miller @ 2012-09-20 20:45 UTC (permalink / raw)
To: mika.westerberg; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20120920091013.GV15548@intel.com>
From: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Thu, 20 Sep 2012 12:10:14 +0300
> On Thu, Sep 20, 2012 at 05:36:22PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the final tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
>>
>> drivers/net/ethernet/i825xx/znet.c: In function 'hardware_init':
>> drivers/net/ethernet/i825xx/znet.c:868:2: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]
>>
>> Caused by commit 1d3ff76759b7 ("i825xx: znet: fix compiler warnings when
>> building a 64-bit kernel"). Is there some Kconfig dependency missing (CONFIG_ISA)?
>
> If we make it dependent on CONFIG_ISA then the driver cannot be built with
> 64-bit kernel. Then again is there someone running 64-bit kernel on Zenith
> Z-note notebook? From the pictures it looks like very ancient "laptop".
>
> An alternative is to make it depend on X86 like this:
I think the powerpc port is at fault here.
Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().
^ permalink raw reply
* Re: [PATCH net-next V4] IB/ipoib: Add rtnl_link_ops support
From: David Miller @ 2012-09-20 20:58 UTC (permalink / raw)
To: ogerlitz; +Cc: roland, netdev, erezsh
In-Reply-To: <1347551797-2495-2-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu, 13 Sep 2012 18:56:36 +0300
> Add rtnl_link_ops to IPoIB, with the first usage being child device
> create/delete through them. Childs devices are now either legacy ones,
> created/deleted through the ipoib sysfs entries, or RTNL ones.
>
> Adding support for RTNL childs involved refactoring of ipoib_vlan_add
> which is now used by both the sysfs and the link_ops code.
>
> Also, added ndo_uninit entry to support calling unregister_netdevice_queue
> from the rtnl dellink entry. This required removal of calls to
> ipoib_dev_cleanup from the driver in flows which use unregister_netdevice,
> since the networking core will invoke ipoib_uninit which does exactly that.
>
> Signed-off-by: Erez Shitrit <erezsh@mellanox.co.il>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
From: David Miller @ 2012-09-20 21:02 UTC (permalink / raw)
To: bjorn; +Cc: ming.lei, oneukum, gregkh, finik, rjw, stern, netdev, linux-usb
In-Reply-To: <87r4pxumdd.fsf@nemi.mork.no>
There seems to be some discussion about the legitimacy of doing things
this way, and in any event the patches were an RFC.
Please resubmit as a non-RFC once all the issues have been worked
out, if appropriate.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH v1 1/3] usbnet: introduce usbnet_link_change API
From: David Miller @ 2012-09-20 21:02 UTC (permalink / raw)
To: ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, oneukum-l3A5Bk7waGM,
finik-l0cyMroinI0, rjw-KKrjLPT3xs0,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1347978201-6219-2-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
From: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Date: Tue, 18 Sep 2012 22:23:19 +0800
> +void usbnet_link_change(struct usbnet *dev, int link, int need_reset)
Please use 'bool' for link and need_reset.
--
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: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
From: Oliver Neukum @ 2012-09-20 21:04 UTC (permalink / raw)
To: David Miller
Cc: bjorn-yOkvZcmFvRU, ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, finik-l0cyMroinI0,
rjw-KKrjLPT3xs0, stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120920.170227.258356702969458329.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thursday 20 September 2012 17:02:27 David Miller wrote:
>
> There seems to be some discussion about the legitimacy of doing things
> this way, and in any event the patches were an RFC.
>
> Please resubmit as a non-RFC once all the issues have been worked
> out, if appropriate.
Just to make this clear, I'd like to state that the discussion involved
only the third, last patch in the series. The first two are fine and make
sense by themselves.
Regards
Oliver
--
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 v2] ucc_geth: Reduce IRQ off in xmit path
From: David Miller @ 2012-09-20 21:08 UTC (permalink / raw)
To: Joakim.Tjernlund; +Cc: netdev, romieu
In-Reply-To: <1348129021-28333-1-git-send-email-Joakim.Tjernlund@transmode.se>
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Thu, 20 Sep 2012 10:17:01 +0200
> Currently ucc_geth_start_xmit wraps IRQ off for the
> whole body just to be safe.
> Reduce the IRQ off period to a minimum.
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
>
> v2: Move assignment of ugeth->tx_skbuff[txQ][ugeth->skb_curtx[txQ]]
> inside IRQ off section to prevent racing against
> ucc_geth_tx(). Spotted by Francois Romieu <romieu@fr.zoreil.com>
I agree with Francois's initial analysis, and disagree with you're
response to him, wrt. the suggest to remove all locking entirely.
Unlike what you claim, there isn't much of a gain at all from merely
make the window of lock holding smaller, especially on the scale
in which you are doing it here.
Whereas removing the lock and the atomic completely, as tg3 does,
will give very significant performance gains.
The locking cost of grabbing the spinlock, and the memory transactions
associated with it, dominate.
Furthermore, even if the gains of your change are non-trivial, you
haven't documented it. So unless you should some noticable gains from
this, it's just code masterbation as far as I'm concerned and I'm
therefore inclined to not apply patches like this.
TG3's core interrupt locking is not that difficult to understand and
replicate in other drivers, so I dismiss your attempts to avoid that
approach on difficulty grounds as well.
^ permalink raw reply
* Re: [PATCH] tcp: Fixed a TFO server bug that crashed kernel by raw sockets
From: David Miller @ 2012-09-20 21:13 UTC (permalink / raw)
To: christoph.paasch; +Cc: hkchu, netdev, ncardwell, edumazet
In-Reply-To: <4380003.jOHRfqhomY@cpaasch-mac>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Wed, 19 Sep 2012 02:19:23 +0200
> From: Christoph Paasch <christoph.paasch@uclouvain.be>
> Date: Wed, 19 Sep 2012 02:06:53 +0200
> Subject: [PATCH] Don't add TCP-code in inet_sock_destruct
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 1/1] ipv6: add support of ECMP
From: David Miller @ 2012-09-20 21:15 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, bernat, yoshfuji
In-Reply-To: <1348046304-4156-2-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed, 19 Sep 2012 11:18:24 +0200
> This patch adds the support of equal cost multipath for IPv6.
>
> The patch is based on a previous work from
> Luc Saillard <luc.saillard@6wind.com>.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Please make the algorithm selection run-time rather than compile
time.
For %99.999999999999999999 of users, making compile time changes
to get the semantics they want is not an option.
^ permalink raw reply
* Re: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
From: David Miller @ 2012-09-20 21:16 UTC (permalink / raw)
To: oliver-GvhC2dPhHPQdnm+yROfE0A
Cc: bjorn-yOkvZcmFvRU, ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, finik-l0cyMroinI0,
rjw-KKrjLPT3xs0, stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1703568.mhE1zQzG7o-ugxBuEnWX9yG/4A2pS7c2Q@public.gmane.org>
From: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Date: Thu, 20 Sep 2012 23:04:38 +0200
> On Thursday 20 September 2012 17:02:27 David Miller wrote:
>>
>> There seems to be some discussion about the legitimacy of doing things
>> this way, and in any event the patches were an RFC.
>>
>> Please resubmit as a non-RFC once all the issues have been worked
>> out, if appropriate.
>
> Just to make this clear, I'd like to state that the discussion involved
> only the third, last patch in the series. The first two are fine and make
> sense by themselves.
I want changes in those, see my replies.
--
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
* [PATCH] ipconfig: add nameserver IPs to kernel-parameter ip=
From: Christoph Fritz @ 2012-09-20 21:28 UTC (permalink / raw)
To: David S. Miller, Rob Landley, Alexey Kuznetsov
Cc: Jan Weitzel, James Morris, Hideaki YOSHIFUJI, Patrick McHardy,
linux-doc, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Hans J. Koch, Daniel Mack
On small systems (e.g. embedded ones) IP addresses are often configured
by bootloaders and get assigned to kernel via parameter "ip=". If set to
"ip=dhcp", even nameserver entries from DHCP daemons are handled. These
entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
To configure nameservers for networks without DHCP, this patch adds option
<dns0-ip> and <dns1-ip> to kernel-parameter 'ip='.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Tested-by: Jan Weitzel <j.weitzel@phytec.de>
---
Documentation/filesystems/nfs/nfsroot.txt | 7 +++++
net/ipv4/ipconfig.c | 39 ++++++++++++++++++++++++++--
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt
index ffdd9d8..4ed7875 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -158,6 +158,13 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
Default: any
+ <dns0-ip> IP address of first nameserver.
+ Value gets exported by /proc/net/pnp which is often linked
+ on embedded systems by /etc/resolv.conf.
+
+ <dns1-ip> IP address of secound nameserver.
+ Same as above.
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 67e8a6b..bfbd61e 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -743,14 +743,22 @@ static void __init ic_bootp_init_ext(u8 *e)
/*
- * Initialize the DHCP/BOOTP mechanism.
+ * Predefine Nameservers
*/
-static inline void __init ic_bootp_init(void)
+static inline void __init ic_nameservers_predef(void)
{
int i;
for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
ic_nameservers[i] = NONE;
+}
+
+/*
+ * Initialize the DHCP/BOOTP mechanism.
+ */
+static inline void __init ic_bootp_init(void)
+{
+ ic_nameservers_predef();
dev_add_pack(&bootp_packet_type);
}
@@ -1379,6 +1387,7 @@ static int __init ip_auto_config(void)
int retries = CONF_OPEN_RETRIES;
#endif
int err;
+ unsigned int i;
#ifdef CONFIG_PROC_FS
proc_net_fops_create(&init_net, "pnp", S_IRUGO, &pnp_seq_fops);
@@ -1499,7 +1508,15 @@ static int __init ip_auto_config(void)
&ic_servaddr, &root_server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(", mtu=%d", ic_dev_mtu);
- pr_cont("\n");
+ for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE) {
+ pr_info(" nameserver%u=%pI4",
+ i, &ic_nameservers[i]);
+ break;
+ }
+ for (i++; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE)
+ pr_cont(", nameserver%u=%pI4\n", i, &ic_nameservers[i]);
#endif /* !SILENT */
return 0;
@@ -1570,6 +1587,8 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ ic_nameservers_predef();
+
/* Parse string for static IP assignment. */
ip = addrs;
while (ip && *ip) {
@@ -1613,6 +1632,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_enable = 0;
}
break;
+ case 7:
+ if (CONF_NAMESERVERS_MAX >= 1) {
+ ic_nameservers[0] = in_aton(ip);
+ if (ic_nameservers[0] == ANY)
+ ic_nameservers[0] = NONE;
+ }
+ break;
+ case 8:
+ if (CONF_NAMESERVERS_MAX >= 2) {
+ ic_nameservers[1] = in_aton(ip);
+ if (ic_nameservers[1] == ANY)
+ ic_nameservers[1] = NONE;
+ }
+ break;
}
}
ip = cp;
--
1.7.2.5
^ permalink raw reply related
* Re: [RFC PATCH] tcp: use of undefined variable
From: David Miller @ 2012-09-20 21:31 UTC (permalink / raw)
To: alan; +Cc: netdev
In-Reply-To: <20120919144557.16956.11280.stgit@localhost.localdomain>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Wed, 19 Sep 2012 15:46:06 +0100
> From: Alan Cox <alan@linux.intel.com>
>
> Both tcp_timewait_state_process and tcp_check_req use the same basic
> construct of
>
> struct tcp_options received tmp_opt;
> tmp_opt.saw_tstamp = 0;
>
> then call
>
> tcp_parse_options
>
> However if they are fed a frame containing a TCP_SACK then tbe code
> behaviour is undefined because opt_rx->sack_ok is undefined data.
>
> This ought to be documented if it is intentional.
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Applied to net-next, except I took this hunk out:
> @@ -96,6 +98,7 @@ tcp_timewait_state_process(struct inet_timewait_sock *tw, struct sk_buff *skb,
> bool paws_reject = false;
>
> tmp_opt.saw_tstamp = 0;
> +
> if (th->doff > (sizeof(*th) >> 2) && tcptw->tw_ts_recent_stamp) {
> tcp_parse_options(skb, &tmp_opt, &hash_location, 0, NULL);
>
Since it's unrelated to your change, and if you were going to do this in
tcp_timewait_state_process() you should do it in tcp_check_req() as well
since the code is identical.
Longer term maybe we probably should add a
tcp_minisock_parse_options() that elides TCP_SACK and other bits these
cases do not want.
Thanks Alan.
^ permalink raw reply
* Re: [PATCH] ipconfig: add nameserver IPs to kernel-parameter ip=
From: David Miller @ 2012-09-20 21:37 UTC (permalink / raw)
To: chf.fritz
Cc: rob, kuznet, j.weitzel, jmorris, yoshfuji, kaber, linux-doc,
linux-kernel, netdev, hjk, daniel
In-Reply-To: <1348176485.3858.92.camel@mars>
From: Christoph Fritz <chf.fritz@googlemail.com>
Date: Thu, 20 Sep 2012 23:28:05 +0200
> + pr_info(" nameserver%u=%pI4",
> + i, &ic_nameservers[i]);
Why don't you just tab that second line out to planet Mars while
you're at it?
Please format this correctly, the goal is not to use a million
TAB characters. Rather, the goal is to get the text starting
on the second line of a function call to line up with the
first column after the openning parenthesis on the previous line.
What you're doing there looks awful, so you'll need to fix this
up before this patch will be considered seriously.
Thanks.
^ permalink raw reply
* Re: [RFC] tcp: use order-3 pages in tcp_sendmsg()
From: Vijay Subramanian @ 2012-09-20 21:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1348119475.31352.60.camel@edumazet-glaptop>
>>
>> I applied this patch to net-next and tested with e1000e driver.
>> With iperf I got around 8 % improvement on loopback.
>>
>> Tested-by: Vijay Subramanian <subramanian.vijay@gmail.com>
I think this tag should be on the thread with the actual patch. I will
reply to your patch with the Tested-by tag.
Thanks for your tips, Eric. For what its worth, here is what I found.
>
> If you keep the producer and consumer on separate cpus, and use large
> enough send() (64KB or 128KB), gain is more like 15 or 20%
>
Curiously, when I use taskset to run iperf server and client on
different cpus, throughput goes down by half
for both baseline (master branch) and with patch. Is taskset the right
way to test this?
I did notice a change in absolute throughout when I increase the
send() buffer size.
However, both the basline as well the patch showed improvement but the
relative improvement
was still around 8%.
> iperf uses 8KB writes, while netperf uses a 16KB default.
I think iperf has a bug. Both man page and comments in code claim
default buffer size for read/write is 8KB but
actual number seems to be 128KB. I believe the actual default is 128KB
not 8KB (-l option with iperf).
Thanks !
Vijay
^ permalink raw reply
* Re: [PATCH net-next v1] net: use a per task frag allocator
From: David Miller @ 2012-09-20 21:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1348073761.26523.1095.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 19 Sep 2012 18:56:01 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> We currently use a per socket page reserve for tcp_sendmsg() operations.
>
> This page is used to build fragments for skbs.
>
> Its done to increase probability of coalescing small write() into
> single segments in skbs still in write queue (not yet sent)
>
> But it wastes a lot of memory for applications handling many mostly
> idle sockets, since each socket holds one page in sk->sk_sndmsg_page
>
> Its also quite inefficient to build TSO packets of 64KB, because we need
> about 16 pages per skb on arches where PAGE_SIZE = 4096, so we hit
> page allocator more than wanted.
>
> This patch switches this frag allocator from socket to task structure,
> and uses bigger pages.
>
> (up to 32768 bytes per frag, thats order-3 pages on x86)
>
> This increases TCP stream performance by 20% on loopback device,
> but also benefits on other network devices, since 8x less frags are
> mapped on transmit and unmapped on tx completion.
>
> Its possible some TSO enabled hardware cant cope with bigger fragments,
> but their ndo_start_xmit() should already handle this, splitting a
> fragment in sub fragments, since some arches have PAGE_SIZE=65536
>
> Successfully tested on various ethernet devices.
> (ixgbe, igb, bnx2x, tg3, mellanox mlx4)
>
> Followup patches can use this infrastructure in two other spots
> and get rid of the socket sk_sndmsg_page.
>
> Open for discussion : Should we fallback to smaller pages
> if order-3 page allocations fail ?
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I like this a lot and I look forward to your upcoming changes to
convert the other two sk_sndmsg_page users as well, but I can't
apply this to net-next just yet.
The question on fallback is a good one and something we have
to resolve before applying this.
Note in particular that sk_allocation can be set to just about
anything, and this also has potential interaction issues with
SOCK_MEMALLOC.
^ permalink raw reply
* [PATCH v2] ipconfig: add nameserver IPs to kernel-parameter ip=
From: Christoph Fritz @ 2012-09-20 21:48 UTC (permalink / raw)
To: David Miller
Cc: rob, kuznet, j.weitzel, jmorris, yoshfuji, kaber, linux-doc,
linux-kernel, netdev, hjk, daniel
In-Reply-To: <20120920.173719.1238894522809866676.davem@davemloft.net>
On small systems (e.g. embedded ones) IP addresses are often configured
by bootloaders and get assigned to kernel via parameter "ip=". If set to
"ip=dhcp", even nameserver entries from DHCP daemons are handled. These
entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
To configure nameservers for networks without DHCP, this patch adds option
<dns0-ip> and <dns1-ip> to kernel-parameter 'ip='.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Tested-by: Jan Weitzel <j.weitzel@phytec.de>
---
v2: - fix indent
---
Documentation/filesystems/nfs/nfsroot.txt | 7 +++++
net/ipv4/ipconfig.c | 39 ++++++++++++++++++++++++++--
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt
index ffdd9d8..4ed7875 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -158,6 +158,13 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
Default: any
+ <dns0-ip> IP address of first nameserver.
+ Value gets exported by /proc/net/pnp which is often linked
+ on embedded systems by /etc/resolv.conf.
+
+ <dns1-ip> IP address of secound nameserver.
+ Same as above.
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 67e8a6b..1c0e7e0 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -743,14 +743,22 @@ static void __init ic_bootp_init_ext(u8 *e)
/*
- * Initialize the DHCP/BOOTP mechanism.
+ * Predefine Nameservers
*/
-static inline void __init ic_bootp_init(void)
+static inline void __init ic_nameservers_predef(void)
{
int i;
for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
ic_nameservers[i] = NONE;
+}
+
+/*
+ * Initialize the DHCP/BOOTP mechanism.
+ */
+static inline void __init ic_bootp_init(void)
+{
+ ic_nameservers_predef();
dev_add_pack(&bootp_packet_type);
}
@@ -1379,6 +1387,7 @@ static int __init ip_auto_config(void)
int retries = CONF_OPEN_RETRIES;
#endif
int err;
+ unsigned int i;
#ifdef CONFIG_PROC_FS
proc_net_fops_create(&init_net, "pnp", S_IRUGO, &pnp_seq_fops);
@@ -1499,7 +1508,15 @@ static int __init ip_auto_config(void)
&ic_servaddr, &root_server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(", mtu=%d", ic_dev_mtu);
- pr_cont("\n");
+ for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE) {
+ pr_info(" nameserver%u=%pI4",
+ i, &ic_nameservers[i]);
+ break;
+ }
+ for (i++; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE)
+ pr_cont(", nameserver%u=%pI4\n", i, &ic_nameservers[i]);
#endif /* !SILENT */
return 0;
@@ -1570,6 +1587,8 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ ic_nameservers_predef();
+
/* Parse string for static IP assignment. */
ip = addrs;
while (ip && *ip) {
@@ -1613,6 +1632,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_enable = 0;
}
break;
+ case 7:
+ if (CONF_NAMESERVERS_MAX >= 1) {
+ ic_nameservers[0] = in_aton(ip);
+ if (ic_nameservers[0] == ANY)
+ ic_nameservers[0] = NONE;
+ }
+ break;
+ case 8:
+ if (CONF_NAMESERVERS_MAX >= 2) {
+ ic_nameservers[1] = in_aton(ip);
+ if (ic_nameservers[1] == ANY)
+ ic_nameservers[1] = NONE;
+ }
+ break;
}
}
ip = cp;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] tcp: restore rcv_wscale in a repair mode (v2)
From: David Miller @ 2012-09-20 21:50 UTC (permalink / raw)
To: avagin; +Cc: netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber, xemul
In-Reply-To: <1348083600-3881500-1-git-send-email-avagin@openvz.org>
From: Andrew Vagin <avagin@openvz.org>
Date: Wed, 19 Sep 2012 23:40:00 +0400
> rcv_wscale is a symetric parameter with snd_wscale.
>
> Both this parameters are set on a connection handshake.
>
> Without this value a remote window size can not be interpreted correctly,
> because a value from a packet should be shifted on rcv_wscale.
>
> And one more thing is that wscale_ok should be set too.
>
> This patch doesn't break a backward compatibility.
> If someone uses it in a old scheme, a rcv window
> will be restored with the same bug (rcv_wscale = 0).
>
> v2: Save backward compatibility on big-endian system. Before
> the first two bytes were snd_wscale and the second two bytes were
> rcv_wscale. Now snd_wscale is opt_val & 0xFFFF and rcv_wscale >> 16.
> This approach is independent on byte ordering.
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> CC: Pavel Emelyanov <xemul@parallels.com>
> Signed-off-by: Andrew Vagin <avagin@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] USB: remove dbg() usage in USB networking drivers
From: David Miller @ 2012-09-20 21:53 UTC (permalink / raw)
To: gregkh; +Cc: netdev, joe, linux-usb, linux-kernel
In-Reply-To: <20120919194614.GA17585@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Wed, 19 Sep 2012 20:46:14 +0100
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> The dbg() USB macro is so old, it predates me. The USB networking drivers are
> the last hold-out using this macro, and we want to get rid of it, so replace
> the usage of it with the proper netdev_dbg() or dev_dbg() (depending on the
> context) calls.
>
> Some places we end up using a local variable for the debug call, so also
> convert the other existing dev_* calls to use it as well, to save tiny amounts
> of code space.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> v2: Addressed review comments from Joe Perches
>
> Again, I am glad to take this in the usb-next tree if wanted, whatever is
> easiest.
I'll take this into net-next, applied, thanks Greg.
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: call subdriver with control intf only
From: David Miller @ 2012-09-20 21:54 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1347308150-19088-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Mon, 10 Sep 2012 22:15:50 +0200
> This fixes a hang on suspend due to calling wdm_suspend on
> the unregistered data interface. The hang should have been
> a NULL pointer reference had it not been for a logic error
> in the cdc_wdm code.
>
> commit 230718bd net: qmi_wwan: bind to both control and data interface
>
> changed qmi_wwan to use cdc_wdm as a subdriver for devices with
> a two-interface QMI/wwan function. The commit failed to update
> qmi_wwan_suspend and qmi_wwan_resume, which were written to handle
> either a single combined interface function, or no subdriver at all.
>
> The result was that we called into the subdriver both when the
> control interface was suspended and when the data interface was
> suspended. Calling the subdriver suspend function with an
> unregistered interface is not supported and will make the
> subdriver bug out.
>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied, thanks.
--
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: [RFC] tcp: use order-3 pages in tcp_sendmsg()
From: Rick Jones @ 2012-09-20 22:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vijay Subramanian, David Miller, netdev
In-Reply-To: <1348119475.31352.60.camel@edumazet-glaptop>
On 09/19/2012 10:37 PM, Eric Dumazet wrote:
> iperf uses 8KB writes, while netperf uses a 16KB default.
For the sake of the archives and posterity, netperf does not have a
"fixed" default send size. The "default" will vary with platform and
platform tuning
What netperf does (for TCP at least) is default the send size to the
value returned after a getsockopt(SO_SNDBUF) issued against the socket
just after it is allocated for the data connection. If the user has
asked for a specific socket buffer size, there will have been a
preceding setsockopt(SO_SNDBUF) call.
So, "by default" under Linux, with no options to set the socket buffer
size, netperf will use 16 KB so long as that is the default (initial)
value for SO_SNDBUF.
The sequence will go something like:
1) create the data socket
2) if user asked to set socket buffer size call setsockopt()
3) call getsockopt()
4) if the user did not specify a send size, use the value returned from
the getsockopt() call
So, if one runs netperf on a platform other than Linux, the "default"
send size may be different. Similarly, if running under linux, but
net.ipv4.tcp_wmwm is tweaked, the "default" send size may be different.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [PATCH 0/6] xfrm_user info leaks
From: David Miller @ 2012-09-20 22:09 UTC (permalink / raw)
To: minipli; +Cc: steffen.klassert, netdev, linux-kernel
In-Reply-To: <1348090423-32665-1-git-send-email-minipli@googlemail.com>
From: Mathias Krause <minipli@googlemail.com>
Date: Wed, 19 Sep 2012 23:33:37 +0200
> the following series fixes various info leaks in the xfrm netlink
> interface. As always, a test case can be supplied on request.
>
> Patches 1 to 5 are probably material for stable, too. Patch 6 is just a
> minor optimization I stumbled across while auditing the code.
>
> Please apply!
All applied, and I made sure to use v3 of patch #5 (which you marked
as 5/7 instead of 5/6 :-)
Also, these have been queued up for -stable as well.
Thanks.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell @ 2012-09-20 22:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: David Miller, mika.westerberg, netdev, linux-next, linux-kernel
In-Reply-To: <20120920.164558.2281417114805373564.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
[Just bring this to the attention of the PowerPC folks ...]
On Thu, 20 Sep 2012 16:45:58 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> Date: Thu, 20 Sep 2012 12:10:14 +0300
>
> > On Thu, Sep 20, 2012 at 05:36:22PM +1000, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> After merging the final tree, today's linux-next build (powerpc
> >> allyesconfig) failed like this:
> >>
> >> drivers/net/ethernet/i825xx/znet.c: In function 'hardware_init':
> >> drivers/net/ethernet/i825xx/znet.c:868:2: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]
> >>
> >> Caused by commit 1d3ff76759b7 ("i825xx: znet: fix compiler warnings when
> >> building a 64-bit kernel"). Is there some Kconfig dependency missing (CONFIG_ISA)?
> >
> > If we make it dependent on CONFIG_ISA then the driver cannot be built with
> > 64-bit kernel. Then again is there someone running 64-bit kernel on Zenith
> > Z-note notebook? From the pictures it looks like very ancient "laptop".
> >
> > An alternative is to make it depend on X86 like this:
>
> I think the powerpc port is at fault here.
>
> Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Benjamin Herrenschmidt @ 2012-09-20 22:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul Mackerras, linuxppc-dev, David Miller, mika.westerberg,
netdev, linux-next, linux-kernel
In-Reply-To: <20120921081531.67db8a7d0ac1b35426b22c45@canb.auug.org.au>
> > I think the powerpc port is at fault here.
> >
> > Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().
Hrm, that's ancient gunk, I'll have to dig. We potentially can support
ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
isa_virt_to_bus is a non-starter.
But then, do we really care ? IE. Is there single device that actually
requires ISA_DMA_API and that is expected to work on any currently
supported powerpc hw ? :-)
We don't even support PReP anymore, so that leaves us with what ?
Anybody has an objection to turning ISA_DMA_API off ?
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell @ 2012-09-20 22:28 UTC (permalink / raw)
To: David Miller
Cc: mika.westerberg, netdev, linux-next, linux-kernel,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
In-Reply-To: <20120920.164558.2281417114805373564.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
Hi Dave,
On Thu, 20 Sep 2012 16:45:58 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> I think the powerpc port is at fault here.
>
> Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().
Not disagreeing, but it would be nice if this was documented somewhere
(maybe in Documentation/DMA-ISA-LPC.txt). We have not had this problem
before because all the other uses of isa_virt_to_bus() are in drivers
that depend on X86 or ARM or ISA or EISA.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v1 11/19] qlcnic: sysfs interface routine updates
From: David Miller @ 2012-09-20 22:31 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver, himanshu.madhani
In-Reply-To: <1348098373-20745-12-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Wed, 19 Sep 2012 19:46:05 -0400
> + if (QLCNIC_IS_82XX(adapter)) {
> + ret = QLC_DEV_GET_DRV(op_mode, pci_func);
> + }
Don't use curly braces for a single line basic block.
^ 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