* Re: [PATCH net-next] rds-tcp: Add module parameters to control sndbuf/rcvbuf size of RDS-TCP socket
From: David Miller @ 2016-03-14 18:59 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: tom, stephen, netdev
In-Reply-To: <20160314180642.GI5084@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Mon, 14 Mar 2016 14:06:42 -0400
> However, it would still be nice to know exactly what distribution
> issues come out of modparam.
Module parameters mean unstable interfaces, and provide inconsistent
ways to do the same exact thing from driver to driver and protocol to
protocol.
Do not use them, ever.
^ permalink raw reply
* Re: [PATCH net-next v6] tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/In
From: David Miller @ 2016-03-14 19:01 UTC (permalink / raw)
To: kafai; +Cc: netdev, kernel-team, rapier, edumazet, mleitner, ncardwell,
ycheng
In-Reply-To: <1457977935-2018863-1-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Mon, 14 Mar 2016 10:52:15 -0700
> Per RFC4898, they count segments sent/received
> containing a positive length data segment (that includes
> retransmission segments carrying data). Unlike
> tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
> carrying no data (e.g. pure ack).
>
> The patch also updates the segs_in in tcp_fastopen_add_skb()
> so that segs_in >= data_segs_in property is kept.
>
> Together with retransmission data, tcpi_data_segs_out
> gives a better signal on the rxmit rate.
>
> v6: Rebase on the latest net-next
>
> v5: Eric pointed out that checking skb->len is still needed in
> tcp_fastopen_add_skb() because skb can carry a FIN without data.
> Hence, instead of open coding segs_in and data_segs_in, tcp_segs_in()
> helper is used. Comment is added to the fastopen case to explain why
> segs_in has to be reset and tcp_segs_in() has to be called before
> __skb_pull().
>
> v4: Add comment to the changes in tcp_fastopen_add_skb()
> and also add remark on this case in the commit message.
>
> v3: Add const modifier to the skb parameter in tcp_segs_in()
>
> v2: Rework based on recent fix by Eric:
> commit a9d99ce28ed3 ("tcp: fix tcpi_segs_in after connection establishment")
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> Cc: Chris Rapier <rapier@psc.edu>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Marcelo Ricardo Leitner <mleitner@redhat.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] fsl/fman: fix dtsec_set_tx_pause_frames
From: David Miller @ 2016-03-14 19:03 UTC (permalink / raw)
To: igal.liberman; +Cc: netdev, scottwood, madalin.bucur
In-Reply-To: <1457896483-7942-1-git-send-email-igal.liberman@freescale.com>
From: <igal.liberman@freescale.com>
Date: Sun, 13 Mar 2016 21:14:43 +0200
> From: Igal Liberman <igal.liberman@freescale.com>
>
> Fix a bug introduced in e06a03b (fsl/fman: fix the pause_time test)
> When pause_time is set to '0' - pause frames are disabled and
> there's no need to apply dTSEC-A003 Errata workaround.
>
> Signed-off-by: Igal Liberman <igal.liberman@freescale.com>
Applied, thank you.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/2] DT MDIO bus of fixed phys
From: Andrew Lunn @ 2016-03-14 19:04 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <56E6EC23.9080301@gmail.com>
On Mon, Mar 14, 2016 at 09:51:47AM -0700, Florian Fainelli wrote:
> On 11/03/16 16:12, Andrew Lunn wrote:
> >>>> Humm, if that's the problem we want to solve, we could introduce a
> >>>> helper function which tries to locate the phy using a 'phy-handle'
> >>>> property
> >>>
> >>> I don't follow you. Where do you get a phandle from to use with
> >>> phy-handle?
> >>
> >> >From the caller of the function: the consumer of that phy-handle and/or
> >> fixed-link property which is either an Ethernet MAC driver or a DSA's
> >> switch port node.
> >
> > I still don't get it. Lets take a real example. I currently have this
> > in one of my dts files:
> >
> > &fec1 {
> > phy-mode = "rmii";
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_fec1>;
> > status = "okay";
> >
> > fixed-link {
> > speed = <100>;
> > full-duplex;
> > };
> > };
>
> All drivers have this exact same structure:
>
> &fec1 {
> phy-handle = <XYZ>;
> or
> fixed-link {
> speed = <100>;
> full-duplex;
> };
> };
>
> In both cases, the argument that this proposed helper function would
> take is a struct device_node pointing to &fec1 here. You could therefore
> imagine having something along these lines:
>
> struct device_node *of_get_phy_by_phandle(struct device_node *dn, bool
> try_fixed_link)
I don't particularly like this name. It suggests it is using the
phandle, when it might not.
> {
> struct device_node *phy_dn;
> int ret;
>
> phy_dn = of_parse_phandle(dn, "phy-handle", 0);
> if (!phy_dn && !try_fixed_link)
> return -ENODEV;
>
> if (of_phy_is_fixed_link(dn)) {
> ret = of_phy_register_fixed_link(dn);
> if (ret)
> return PTR_ERR(-ret);
>
> phy_dn = of_node_get(dn);
> }
>
> return phy_dn;
> }
To make release work, i think you need to hack something into
phy_disconnect() or phy_detach() so that the fixed_phy registered
above gets freed.
I don't particularly like these special cases. What i suggested does
not require any special cases, because they act just like phys on an
mdio bus.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Jiri Pirko @ 2016-03-14 19:04 UTC (permalink / raw)
To: roopa; +Cc: netdev, jhs, davem
In-Reply-To: <56E706C3.4030808@cumulusnetworks.com>
Mon, Mar 14, 2016 at 07:45:23PM CET, roopa@cumulusnetworks.com wrote:
>On 3/14/16, 7:51 AM, Jiri Pirko wrote:
>> Sun, Mar 13, 2016 at 02:56:25AM CET, roopa@cumulusnetworks.com wrote:
>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>
>>> This patch adds a new RTM_GETSTATS message to query link stats via netlink
>> >from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
>>> returns a lot more than just stats and is expensive in some cases when
>>> frequent polling for stats from userspace is a common operation.
>>>
>>> RTM_GETSTATS is an attempt to provide a light weight netlink message
>>> to explicity query only link stats from the kernel on an interface.
>>> The idea is to also keep it extensible so that new kinds of stats can be
>>> added to it in the future.
>>>
>>> This patch adds the following attribute for NETDEV stats:
>>> struct nla_policy ifla_stats_policy[IFLA_STATS_MAX + 1] = {
>>> [IFLA_STATS_LINK64] = { .len = sizeof(struct rtnl_link_stats64) },
>>> };
>>>
>>> This patch also allows for af family stats (an example af stats for IPV6
>>> is available with the second patch in the series).
>>>
>>> Like any other rtnetlink message, RTM_GETSTATS can be used to get stats of
>>> a single interface or all interfaces with NLM_F_DUMP.
>>>
>>> Future possible new types of stat attributes:
>>> - IFLA_MPLS_STATS (nested. for mpls/mdev stats)
>>> - IFLA_EXTENDED_STATS (nested. extended software netdev stats like bridge,
>>> vlan, vxlan etc)
>>> - IFLA_EXTENDED_HW_STATS (nested. extended hardware stats which are
>>> available via ethtool today)
>>>
>>> This patch also declares a filter mask for all stat attributes.
>>> User has to provide a mask of stats attributes to query. This will be
>>> specified in a new hdr 'struct if_stats_msg' for stats messages.
>>>
>>> Without any attributes in the filter_mask, no stats will be returned.
>>>
>>> This patch has been tested with modified iproute2 ifstat.
>>>
>>> Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
>>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>>> ---
>>> include/net/rtnetlink.h | 5 ++
>>> include/uapi/linux/if_link.h | 19 ++++
>>> include/uapi/linux/rtnetlink.h | 7 ++
>>> net/core/rtnetlink.c | 200 +++++++++++++++++++++++++++++++++++++++++
>>> 4 files changed, 231 insertions(+)
>>>
>>> diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
>>> index 2f87c1b..fa68158 100644
>>> --- a/include/net/rtnetlink.h
>>> +++ b/include/net/rtnetlink.h
>>> @@ -131,6 +131,11 @@ struct rtnl_af_ops {
>>> const struct nlattr *attr);
>>> int (*set_link_af)(struct net_device *dev,
>>> const struct nlattr *attr);
>>> + size_t (*get_link_af_stats_size)(const struct net_device *dev,
>>> + u32 filter_mask);
>>> + int (*fill_link_af_stats)(struct sk_buff *skb,
>>> + const struct net_device *dev,
>>> + u32 filter_mask);
>>> };
>>>
>>> void __rtnl_af_unregister(struct rtnl_af_ops *ops);
>>> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>>> index 249eef9..0840f3e 100644
>>> --- a/include/uapi/linux/if_link.h
>>> +++ b/include/uapi/linux/if_link.h
>>> @@ -741,4 +741,23 @@ enum {
>>>
>>> #define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
>>>
>>> +/* STATS section */
>>> +
>>> +struct if_stats_msg {
>>> + __u8 family;
>>> + __u32 ifindex;
>>> + __u32 filter_mask;
>> This limit future extension to only 32 groups of stats. I can imagine
>> that more than that can be added, easily.
>I thought about that, but it is going to be a while before we run out of the u32.
>Most of the other stats will be nested like per logical interface stats or
>per hw stats. If we do run out of them, in the future we could add a netlink
>attribute for extended filter mask to carry more bits (similar to IFLA_EXT_MASK).
>I did also start with just having a IFLA_STATS_EXT_MASK like attribute
>to begin with, but since no stats are dumped by default, having a way to easily specify
>mask in the hdr will be easier on apps. And this will again be a u32 anyways.
I believe that using *any* structs to send over netlink is a mistake.
Netlink is capable to transfer everything using attrs. Easy to compose,
easy to parse. easy to extend. Couple of more bytes in the message? So what?
For newly introduced things, I suggest to do this properly.
>
>
>> Why don't you use nested
>> attribute IFLA_STATS_FILTER with flag attributes for every type?
>> That
>> would be easily extendable.
>a u8 for each stats selector seems like an overkill.
>> Using netlink header struct for this does not look correct to me.
>> In past, this was done lot of times and turned out to be a problem later.
>>
>>
>I started with not adding it, but rtnetlink rcv handler looks for family
>in the hdr. And hence all of the messages have a struct header
>with family as the first field (you can correct me if you find that it is not necessary.)
>
>
^ permalink raw reply
* Re: [PATCH net] ppp: ensure file->private_data can't be overridden
From: Guillaume Nault @ 2016-03-14 19:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, paulus, alan, arnd
In-Reply-To: <20160314.145759.727527672385295428.davem@davemloft.net>
On Mon, Mar 14, 2016 at 02:57:59PM -0400, David Miller wrote:
> From: Guillaume Nault <g.nault@alphalink.fr>
> Date: Mon, 14 Mar 2016 18:59:40 +0100
>
> > Testing ->private_data without lock in ppp_ioctl() before calling
> > ppp_unattached_ioctl() is fine, because either ->private_data is
> > not NULL and thus is stable, or it is and ppp_unattached_ioctl()
> > takes care of not overriding ->private_data, should its value get
> > modified before taking the mutex.
>
> This is exactly the ambiguous behavior I want you to avoid.
>
> The decision should be atomic from ppp_ioctl()'s test all the way
> until ppp_unattached_ioctl() does it's work.
OK, will fix in v2.
^ permalink raw reply
* Re: [PATCH] Documentation: networking: phy.txt: Add missing functions
From: David Miller @ 2016-03-14 19:14 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew
In-Reply-To: <1457978150-29568-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 14 Mar 2016 10:55:50 -0700
> Some new development in PHYLIB added new function pointers to the struct
> phy_driver, document these.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 08/13] net/mlx5e: Add fragmented memory support for RX multi packet WQE
From: achiad shochat @ 2016-03-14 19:16 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Eric Dumazet, Saeed Mahameed, David S. Miller, Linux Netdev List,
Or Gerlitz, Eran Ben Elisha, Tal Alon, Tariq Toukan,
Jesper Dangaard Brouer
In-Reply-To: <CALzJLG9rB4iBnOC0f+8NopjdS407-WJ9b7KFUPO9hjbwFCyP-A@mail.gmail.com>
On 14 March 2016 at 20:16, Saeed Mahameed <saeedm@dev.mellanox.co.il> wrote:
> On Fri, Mar 11, 2016 at 9:58 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>>> I totally agree with this, we should have reported skb->truesize +=
>>> (consumed strides)*(stride size).
>>> but again this is not as critical as you think, in the worst case
>>> skb->truesize will be off by 127B at most.
>>
>> Ouch. really you are completely wrong.
>
> It it is just a matter of perspective, quoting:
> http://vger.kernel.org/~davem/skb_sk.html
> "This is the total of how large a data buffer we allocated for the
> packet, plus the size of 'struct sk_buff' itself."
>
> as explained more than once, a page used in ConnectX4 MPWQE approach
> can be used for more than one packet, according to the above
> documentation and many other examples in the kernel, each packet will
> report as much data buffer as it used from that page, and we allocated
> for that packet: #strides * stridesize from that page, (common sense).
>
> it is really uncalled-for to report for each SKB, skb->truesize +=
> PAGE_SIZE for the same shared reuseable page, as we did in here and as
> other drivers already do.
>
> It is just ridiculous to report PAGE_SIZE for SKB that used only 128B
> and the others parts of that page are being either reused by HW or
> reported back to the stack and we already did the truesize accounting
> on their parts.
>
> It seems to me that reporting PAGE_SIZE* (#SKBs pointing to that page)
> for all of those SKBs is just a big lie and it is just an abuse to the
> skb->truesize to protect against special/rare cases like OOO issue
> that I can suggest a handful of solutions (out of this thread scope)
> for them without the need of lying in device drivers of the actual
> truesize.
> Think about it, if SKBs share the same page then SUM(SKBs->truesize) =
> PAGE_SIZE.
>
> and suppose you are right, why just not remove the truesize param
> from skb_add_rx_frag, and just explicitly do skb->true_szie +=
> PAGE_SIZE, hardcoded inside that function? or rename the truesize
> param to pageorder ?
>
>>
>> If one skb has a fragment of a page, and sits in a queue for a long
>> time, it really uses a full page, because the remaining part of the page
>> is not reusable. Only kmalloc(128) can deal with that idea of allowing
>> other parts of the page being 'freed and reusable'
> This concern was also true before this series for other drivers in the
> kernel, who use pages for fragmented SKBs and non of them report
> PAGE_SIZE as SKB->truesize, as their pages are reuseable.
>
>>
>> It is trivial for an attacker to make sure the host will consume one
>> page + sk_buff + skb->head = 4096 + 256 + 512, by specially sending out
>> of order packets on TCP flows.
> we can do special accounting for ooo like issues in the stack (maybe
> count page references and sum up page sizes as you suggest), device
> drivers shouldn't have special handling/accounting to protect against
> such cases.
I really do not see why the new scheme is more DOSable than the common
scheme of pre-allocating SKB using napi_alloc_skb().
In both cases each RX packet "eats" a chunk from a (likely(compound))
page and holds the page as long as it sits in a queue.
Only in the new scheme the size of the eaten chunk equals to the
actual incoming packet size rather than pre-defined according to the
maximum packet size (MTU), which yields optimal memory usage and
locality.
It does not make sense that an incoming packet of 64 bytes will eat
1500 bytes of memory.
In the new scheme the RX buffer "credits" is bytes only, not in
packets, which makes more sense - given a link speed, the size of the
buffer in bytes determines how long the SW response time for an
incoming burst of traffic can be before the buffer will overrun.
Eric, am I missing something here or the new scheme was not clear to
you previously?
^ permalink raw reply
* Re: [PATCH] SOCK_SEQPACKET socketpair must get SIGPIPE in AF_UNIX if one end is closed
From: David Miller @ 2016-03-14 19:19 UTC (permalink / raw)
To: glider; +Cc: edumazet, rweikusat, linux-kernel, netdev
In-Reply-To: <1457532623-125301-1-git-send-email-glider@google.com>
From: Alexander Potapenko <glider@google.com>
Date: Wed, 9 Mar 2016 15:10:23 +0100
> According to IEEE Std 1003.1, 2013, sending data to a SOCK_SEQPACKET
> socketpair with MSG_NOSIGNAL flag set must result in a SIGPIPE if the
> socket is no longer connected.
>
> Signed-off-by: Alexander Potapenko <glider@google.com>
Please format your Subject line properly, the format is:
[PATCH] $SUBSYSTEM: $DESCRIPTION.
In this case "af_unx: " would be a proper subsystem marker.
Also,
> ---
> I used the following program to check the kernel behavior:
Please include this in your commit message rather than cutting it out
using the "---" marker, as it will help people in the future
understand your change and how you tested it. More information is
always better than less information.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] ixgbe: Avoid unaligned access in ixgbe_atr() for LLC packets
From: Alexander Duyck @ 2016-03-14 19:20 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: intel-wired-lan, Netdev, Jeff Kirsher, Brandeburg, Jesse,
shannon nelson, Carolyn Wyborny, Skidmore, Donald C,
Bruce W Allan, John Ronciak, Mitch Williams
In-Reply-To: <20160314175909.GH5084@oracle.com>
On Mon, Mar 14, 2016 at 10:59 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (03/14/16 10:55), Alexander Duyck wrote:
>>
>> One other thing I forgot to mention is that we don't support ARP so
>> that check could be dropped. The ATR code only supports IPv4 or IPv6
>> with TCP.
>
> I did notice that, but I left it in place because (a) it comes down
> the stack with the NET_IP_ALIGNment and (b) ARP is only sent over
> Ethernet II (there is no LLC SAP for ARP, which is a big reason
> why ipv4 is not sent over llc, despite rfc 1042).
>
> I figured it would not hurt to pass it down, in case we decide
> to do something clever with it in the future.
I figure it is better to just drop it since we don't need to be trying
to parse ARP packets anyway.
- Alex
^ permalink raw reply
* Re: pull request (net): ipsec 2016-03-10
From: David Miller @ 2016-03-14 19:21 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1457605469-17332-1-git-send-email-steffen.klassert@secunet.com>
Patches 4 and 5 were given some feedback, please fix those issues up and
respin this pull request.
Thank you!
^ permalink raw reply
* Re: [PATCH] net: mvneta: Add missing hotplug notifier transition
From: David Miller @ 2016-03-14 19:22 UTC (permalink / raw)
To: anna-maria; +Cc: linux-kernel, rt, thomas.petazzoni, netdev
In-Reply-To: <1457687423-39784-1-git-send-email-anna-maria@linutronix.de>
From: Anna-Maria Gleixner <anna-maria@linutronix.de>
Date: Fri, 11 Mar 2016 10:10:23 +0100
> The mvneta_percpu_notifier() hotplug callback lacks handling of the
> CPU_DOWN_FAILED case. That means, if CPU_DOWN_PREPARE failes, the
> driver is not well configured on the CPU.
>
> Add handling for CPU_DOWN_FAILED[_FROZEN] hotplug notifier transition
> to setup the driver.
>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2] vsock: Fix blocking ops call in prepare_to_wait
From: David Miller @ 2016-03-14 19:24 UTC (permalink / raw)
To: imbrenda; +Cc: linux-kernel, netdev, labbott
In-Reply-To: <1457699963-27694-1-git-send-email-imbrenda@linux.vnet.ibm.com>
From: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
Date: Fri, 11 Mar 2016 13:39:23 +0100
> I think I found a problem with the patch submitted by Laura Abbott
> ( https://lkml.org/lkml/2016/2/4/711 ): we might miss wakeups.
> Since the condition is not checked between the prepare_to_wait and the
> schedule(), if a wakeup happens after the condition is checked but before
> the sleep happens, and we miss it. ( A description of the problem can be
> found here: http://www.makelinux.net/ldd3/chp-6-sect-2 ).
>
> My solution (see patch below) is to shrink the area influenced by
> prepare_to_wait, but keeping the fragile section around the condition, and
> keep the rest of the code in "normal" running state. This way the sleep is
> correct and the other functions don't need to worry. The only caveat here
> is that the function(s) called to verify the conditions are really not
> allowed to sleep, so if you need synchronization in the backend of e.g.
> vsock_stream_has_space(), you should use spinlocks and not mutexes.
>
> In case we want to be able to sleep while waiting for conditions, we can
> consider this instead: https://lwn.net/Articles/628628/ .
>
>
> I stumbled on this problem while working on fixing the upcoming virtio
> backend for vsock, below is the patch I had prepared, with the original
> message.
Can someone please look at this? Who maintains this code anyways?
^ permalink raw reply
* Re: [PATCH] batman-adv: Less function calls in batadv_is_ap_isolated() after error detection
From: David Miller @ 2016-03-14 19:25 UTC (permalink / raw)
To: elfring
Cc: b.a.t.m.a.n, netdev, a, mareklindner, sw, sven, linux-kernel,
kernel-janitors, julia.lawall
In-Reply-To: <56E2BCD8.9010200@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 11 Mar 2016 13:40:56 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 11 Mar 2016 13:10:20 +0100
>
> The variables "tt_local_entry" and "tt_global_entry" were eventually
> checked again despite of a corresponding null pointer test before.
>
> * Avoid this double check by reordering a function call sequence
> and the better selection of jump targets.
>
> * Omit the initialisation for these variables at the beginning then.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
I am assuming Antonio will take this in via his tree.
^ permalink raw reply
* Re: [PATCH v2 0/3] net/phy: Improvements to Cavium Thunder MDIO code.
From: David Miller @ 2016-03-14 19:27 UTC (permalink / raw)
To: ddaney.cavm
Cc: netdev, linux-arm-kernel, f.fainelli, rric, sgoutham, galak,
ijc+devicetree, mark.rutland, pawel.moll, robh+dt, linux-kernel,
rchintakuntla, david.daney
In-Reply-To: <1457718791-6505-1-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <ddaney.cavm@gmail.com>
Date: Fri, 11 Mar 2016 09:53:08 -0800
> Changes from v1:
>
> - In 1/3 Add back check for non-OF objects in bgx_init_of_phy(). It
> is probably not necessary, but better safe than sorry...
>
> The firmware on many Cavium Thunder systems configures the MDIO bus
> hardware to be probed as a PCI device. In order to use the MDIO bus
> drivers in this configuration, we must add PCI probing to the driver.
>
> There are two parts to this set of three patches:
>
> 1) Cleanup the PHY probing code in thunder_bgx.c to handle the case
> where there is no PHY attached to a port, as well as being more
> robust in the face of driver loading order by use of
> -EPROBE_DEFER.
>
> 2) Split mdio-octeon.c into two drivers, one with platform probing,
> and the other with PCI probing. Common code is shared between the
> two.
>
> Tested on several different Thunder and OCTEON systems, also compile
> tested on x86_64.
Series applied, thanks David.
^ permalink raw reply
* Re: [PATCH] Driver: Vmxnet3: Fix regression caused by cec0556
From: David Miller @ 2016-03-14 19:28 UTC (permalink / raw)
To: skhare; +Cc: pv-drivers, netdev, linux-kernel, gyang
In-Reply-To: <1457731784-96240-1-git-send-email-skhare@vmware.com>
From: Shrikrishna Khare <skhare@vmware.com>
Date: Fri, 11 Mar 2016 13:29:44 -0800
> don't pass uninitialized flags to spin_unlock_irqrestore.
>
> Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Signed-off-by: Shrikrishna Khare <skhare@vmware.com>
> Signed-off-by: Guolin Yang <gyang@vmware.com>
Sorry, I noticed Arnd's version of this fix first and therefore applied
his version.
^ permalink raw reply
* Re: [PATCH v2 0/3] of_mdio: use IS_ERR_OR_NULL() and PTR_ERR_OR_ZERO()
From: David Miller @ 2016-03-14 19:32 UTC (permalink / raw)
To: sergei.shtylyov
Cc: grant.likely, robh+dt, devicetree, f.fainelli, netdev,
frowand.list
In-Reply-To: <2682275.WNlbxTfNal@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 13 Mar 2016 00:32:13 +0300
> Here's the set of 3 patches against DaveM's 'net-next.git'
> repo. They deal with some error checks in the device tree MDIO
> code...
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] ixgbe: Avoid unaligned access in ixgbe_atr() for LLC packets
From: Sowmini Varadhan @ 2016-03-14 19:32 UTC (permalink / raw)
To: Alexander Duyck
Cc: intel-wired-lan, Netdev, Jeff Kirsher, Brandeburg, Jesse,
shannon nelson, Carolyn Wyborny, Skidmore, Donald C,
Bruce W Allan, John Ronciak, Mitch Williams
In-Reply-To: <CAKgT0Ud9b7MaOk-O4gs3LCMgO+dApCFJ=tOrStk1kuxEE5dShw@mail.gmail.com>
On (03/14/16 12:20), Alexander Duyck wrote:
> I figure it is better to just drop it since we don't need to be trying
> to parse ARP packets anyway.
Ok, let me send out v3.
^ permalink raw reply
* Re: [PATCH RFC v2 00/32] Make DSA switches linux devices.
From: Florian Fainelli @ 2016-03-14 19:36 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Vivien Didelot, netdev
In-Reply-To: <20160312170827.GA2186@lunn.ch>
On 12/03/16 09:08, Andrew Lunn wrote:
>> [snip]
>>
>>>
>>> The third switch is as you would expect, dsa,member = <0 2>;
>>
>> I like that representation.
>>
>
> ...
>
>> So does that mean you agree we do not need the DSA platform device
>> anymore :)?
>
> It looks like it can be done without the DSA platform device.
>
> My previous approach was to keep the new binding as similar as
> possible to the current one. If however, we decide we are going for
> something totally new, we can remove this platform device.
The old binding can and should remain available, we just don't want to
match it anymore using a generic DSA platform device, but that does not
prevent a driver using the old binding to get a struct dsa_platform_data
to be properly filed if it was using it through dsa_of_probe(). With the
networking stack offfering resident code to deal with DSA, we could also
warn if we see a node in tree with "marvell,dsa".
The new binding looks very similar to the previous one and this is
certainly a good thing to do. With that in mind the new binding should
probably be keeping the per-port Device Tree node representation and
properties, because that one seems correct, the parts that had gone
wrong were definitively the "reg" property and the dsa,mii-bus property
if not the dsa,ethernet as well, but code will talk.
>
> It probably means we need to turn slave.c and parts of dsa.c into a
> library. Add a new dsa_v2.c file, containing the new binding
> code. With things like having the switch devices instantiate there own
> MDIO bus, fixed phys on a compatible MDIO bus referenced via phandles,
> etc, I hope we can make parts of the dsa_v2 simpler.
Looks like we still need to get this one ironed out.
>
>> Very true, we support a wide variety of setups, and that creates a lot
>> of complexity that could probably be absorbed by a more generic helper
>> function?
>
> No, i want to go the other direction. Make all these phy setups look
> identical. It is just a phy-handle=<&phandle> property. With my MDIO
> fixed-phy bus patches, it just works for user ports, and the only
> thing we need to deal with is phy-mode.
>
> DSA and CPU ports are harder, due to a lack of a netdev. Horrible, but
> maybe would could do a alloc_netdev(), but never register_netdev()?
> It gives us something to attach the phy to.
Humm, I suppose that could work, in practice, having a full-fledged
"cpu" network device would be more useful than having e.g: eth0, now
being the conduit interface, because that one, really is useless to
applications because it needs a tag to be applied and there is nothing
doing that. Food for thought.
>
>>> 1) The switch device should use mdiobus_alloc()/mdiobus_register() for
>>> its own MDIO bus.
>>
>> Agreed, possibly with the help of the DSA slave code, since some of that
>> is already doing its magic for most drivers here.
>
> I think the switch driver should instantiate the MDIO bus, not the
> core. The core could however offer some helper code.
Works for me.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 0/5] DSA cleanup and fixes
From: David Miller @ 2016-03-14 19:44 UTC (permalink / raw)
To: andrew; +Cc: netdev, f.fainelli, vivien.didelot
In-Reply-To: <1457737300-23660-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sat, 12 Mar 2016 00:01:35 +0100
> The RFC patchset for re-architecturing DSA probing contains a few
> standalone patches, either clean up or fixes. This pulls them out for
> submission.
Series applied, thanks Andrew.
^ permalink raw reply
* Re: pull request: bluetooth-next 2016-03-12
From: David Miller @ 2016-03-14 19:45 UTC (permalink / raw)
To: johan.hedberg; +Cc: netdev, linux-bluetooth
In-Reply-To: <20160312063934.GA21940@t440s.P-661HNU-F1>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Sat, 12 Mar 2016 08:39:34 +0200
> Here's the last bluetooth-next pull request for the 4.6 kernel.
>
> - New USB ID for AR3012 in btusb
> - New BCM2E55 ACPI ID
> - Buffer overflow fix for the Add Advertising command
> - Support for a new Bluetooth LE limited privacy mode
> - Fix for firmware activation in btmrvl_sdio
> - Cleanups to mac802154 & 6lowpan code
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [PATCH -next] bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict
From: David Miller @ 2016-03-14 19:47 UTC (permalink / raw)
To: fw; +Cc: netdev, stephen, nbd, zefir.kurtisi
In-Reply-To: <1457777682-24689-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Sat, 12 Mar 2016 11:14:42 +0100
> Zefir Kurtisi reported kernel panic with an openwrt specific patch.
> However, it turns out that mainline has a similar bug waiting to happen.
>
> Once NF_HOOK() returns the skb is in undefined state and must not be
> used. Moreover, the okfn must consume the skb to support async
> processing (NF_QUEUE).
>
> Current okfn in this spot doesn't consume it and caller assumes that
> NF_HOOK return value tells us if skb was freed or not, but thats wrong.
>
> It "works" because no in-tree user registers a NFPROTO_BRIDGE hook at
> LOCAL_IN that returns STOLEN or NF_QUEUE verdicts.
>
> Once we add NF_QUEUE support for nftables bridge this will break --
> NF_QUEUE holds the skb for async processing, caller will erronoulsy
> return RX_HANDLER_PASS and on reinject netfilter will access free'd skb.
>
> Fix this by pushing skb up the stack in the okfn instead.
>
> NB: It also seems dubious to use LOCAL_IN while bypassing PRE_ROUTING
> completely in this case but this is how its been forever so it seems
> preferable to not change this.
>
> Cc: Felix Fietkau <nbd@openwrt.org>
> Cc: Zefir Kurtisi <zefir.kurtisi@neratec.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Technically this is a netfilter change, but I'll apply it directly to my
tree, thanks Florian.
^ permalink raw reply
* [PATCH V3 net-next] ixgbe: Avoid unaligned access in ixgbe_atr() for LLC packets
From: Sowmini Varadhan @ 2016-03-14 19:47 UTC (permalink / raw)
To: intel-wired-lan, netdev, alexander.duyck
Cc: jeffrey.t.kirsher, jesse.brandeburg, shannon.nelson,
carolyn.wyborny, donald.c.skidmore, bruce.w.allan, john.ronciak,
mitch.a.williams, sowmini.varadhan
For LLC based protocols like lldp, stp etc., the ethernet header
is an 802.3 header with a h_proto that is not 0x800, 0x86dd, or
even 0x806. In this world, the skb_network_header() points at
the DSAP/SSAP/.. and is not likely to be NET_IP_ALIGNed in
ixgbe_atr().
With LLC, drivers are not likely to correctly find IPVERSION,
or "6", at hdr.ipv4->version, but will instead just needlessly
trigger an unaligned access. (IPv4/IPv6 over LLC is almost never
implemented).
The unaligned access is thus avoidable: bail out quickly after
examining skb->protocol. The only Ethernet II protocols handled
are IPv4 and IPv6
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
v2: Alexander Duyck comments
v3: filter out all ethertypes except for Ethernet II and (IPv4 or IPv6)
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 4d6223d..aeab2fe 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7574,6 +7574,11 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
if (!ring->atr_sample_rate)
return;
+ /* this function only handles IPv4 or IPv6 */
+ if (first->protocol != htons(ETH_P_IP) &&
+ first->protocol != htons(ETH_P_IPV6))
+ return;
+
ring->atr_count++;
/* snag network header to get L4 type and address */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net v2 0/4] Few mvneta fixes
From: David Miller @ 2016-03-14 19:49 UTC (permalink / raw)
To: gregory.clement
Cc: linux-kernel, netdev, thomas.petazzoni, jason, andrew,
sebastian.hesselbarth, linux-arm-kernel, alior, nadavh, mw,
patrick, dima, oferh
In-Reply-To: <1457804660-8463-1-git-send-email-gregory.clement@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Sat, 12 Mar 2016 18:44:16 +0100
> In this second version I split the last patch in two parts as
> requested.
>
> For the record the initial cover letter was:
> "here is a patch set of few fixes. Without the first one, a kernel
> configured with debug features ended to hang when the driver is built
> as a module and is removed. This is quite is annoying for debugging!
>
> The second patch fix a forgotten flag at the initial submission of the
> driver.
>
> The third patch is only really a cosmetic one so I have no problem to
> not apply it for 4.5 and wait for 4.6.
>
> I really would like to see the first one applied for 4.5 and for the
> second I let you judge if it something needed for now or that should
> wait the next release."
Series applied and patches #1 and #2 queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] sh_eth: kill useless initializers
From: David Miller @ 2016-03-14 19:50 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <2737382.tXjN0OZRaC@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 13 Mar 2016 01:29:45 +0300
> Some of the local variable intializers in the driver turned out to be
> pointless, kill 'em.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied, thanks Sergei.
^ 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