* 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] ppp: ensure file->private_data can't be overridden
From: David Miller @ 2016-03-14 18:57 UTC (permalink / raw)
To: g.nault; +Cc: netdev, paulus, alan, arnd
In-Reply-To: <20160314175940.GB1462@alphalink.fr>
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.
^ permalink raw reply
* [PATCH v2 net-next] ixgbe: Avoid unaligned access in ixgbe_atr() for LLC packets
From: Sowmini Varadhan @ 2016-03-14 17:46 UTC (permalink / raw)
To: intel-wired-lan, netdev
Cc: sowmini.varadhan, alexander.duyck, jeffrey.t.kirsher,
jesse.brandeburg, shannon.nelson, carolyn.wyborny,
donald.c.skidmore, bruce.w.allan, john.ronciak, mitch.a.williams
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 first->protocol.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
v2: Alexander Duyck comments.
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..b25e603 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;
+ if (first->protocol != htons(ETH_P_IP) &&
+ first->protocol != htons(ETH_P_IPV6) &&
+ first->protocol != htons(ETH_P_ARP))
+ return;
+
ring->atr_count++;
/* snag network header to get L4 type and address */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2 2/3] of_mdio: use IS_ERR_OR_NULL()
From: Sergei Shtylyov @ 2016-03-14 18:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: grant.likely, robh+dt, devicetree, f.fainelli, netdev,
frowand.list
In-Reply-To: <4173235.nHpIx7Ti2k@wuerfel>
On 03/14/2016 01:22 AM, Arnd Bergmann wrote:
>> IS_ERR_OR_NULL() is open coded in of_mdiobus_register_phy(), so just call
>> it directly...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>>
>> ---
>> Changes in version 2:
>> - removed the of_mdiobus_register_device() hunk;
>> - added the "Reviewed-by:" tag.
>>
>> drivers/of/of_mdio.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: net-next/drivers/of/of_mdio.c
>> ===================================================================
>> --- net-next.orig/drivers/of/of_mdio.c
>> +++ net-next/drivers/of/of_mdio.c
>> @@ -56,7 +56,7 @@ static int of_mdiobus_register_phy(struc
>> phy = phy_device_create(mdio, addr, phy_id, 0, NULL);
>> else
>> phy = get_phy_device(mdio, addr, is_c45);
>> - if (!phy || IS_ERR(phy))
>> + if (IS_ERR_OR_NULL(phy))
>> return 1;
>>
>> rc = irq_of_parse_and_map(child, 0);
>>
>>
>
> IS_ERR_OR_NULL() usually indicates that the code is wrong, or that
> an API has been misdesigned.
>
> Can you clarify in the changelog which one it is,
The second. :-)
> or (better) change
> it so that 'phy' in this function is either NULL or IS_ERR() in case
> of an error but not both?
I guess you meant to change get_phy_device() to not return NULL (and so
only return the error codes, not both), am I correct?
> I think moving the 'if (problem) return 1' into the two if/else
> is a correct transformation that also makes it very clear what
> is going on here.
Can be done too... it's not that I have much time for that many respins
though. It all started with 1 little patch (this one). :-)
> Arnd
MBR, Sergei
^ permalink raw reply
* [PATCH] ath5k: Change led pin configuration for compaq c700 laptop
From: Joseph Salisbury @ 2016-03-14 18:51 UTC (permalink / raw)
To: jirislaby, mickflemm, mcgrof, kvalo
Cc: linux-kernel, stable, linux-wireless, netdev
BugLink: http://bugs.launchpad.net/bugs/972604
Commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin
configuration for compaq c700 laptop") added a pin configuration for the Compaq
c700 laptop. However, the polarity of the led pin is reversed. It should be
red for wifi off and blue for wifi on, but it is the opposite. This bug was
reported in the following bug report:
http://pad.lv/972604
Fixes: 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin
configuration for compaq c700 laptop")
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Cc: stable@vger.kernel.org
---
drivers/net/wireless/ath/ath5k/led.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
index 803030f..6a2a168 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -77,7 +77,7 @@ static const struct pci_device_id ath5k_led_devices[] = {
/* HP Compaq CQ60-206US (ddreggors@jumptv.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137a), ATH_LED(3, 1) },
/* HP Compaq C700 (nitrousnrg@gmail.com) */
- { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
+ { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 0) },
/* LiteOn AR5BXB63 (magooz@salug.it) */
{ ATH_SDEVICE(PCI_VENDOR_ID_ATHEROS, 0x3067), ATH_LED(3, 0) },
/* IBM-specific AR5212 (all others) */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: roopa @ 2016-03-14 18:45 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, jhs, davem
In-Reply-To: <20160314145144.GE2346@nanopsycho.orion>
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.
> 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 3/4] infiniband: hns: add Hisilicon RoCE support(driver code)
From: Parav Pandit @ 2016-03-14 18:20 UTC (permalink / raw)
To: oulijun
Cc: Wei Hu(Xavier), Doug Ledford, Hefty, Sean, Hal Rosenstock, davem,
jeffrey.t.kirsher, jiri, Or Gerlitz, linux-rdma, linux-kernel,
netdev, gongyangming, xiaokun, tangchaofei, haifeng.wei,
yisen.zhuang, yankejian, lisheng011, charles.chenxin, linuxarm
In-Reply-To: <56E65EFC.3030109@huawei.com>
>>
>> Since SRQ is not supported in this driver version, can you keep
>> remaining code base also to not bother about SRQ specifically
>> poll_cq_one, modify_qp, destroy_qp etc?
>> SRQ support can come as complete additional patch along with cmd_mask,
>> callbacks and rest of the code.
>>
>> .
> Sorry, I see your review in time.
> Sure, SRQ is not supported in current roce driver. I have verified the function
> for RDMA. It is not influence. For your question, we need to analyse it scientific.
> after that, i will reply your doubt, is that ok?
Yes. No problem.
^ permalink raw reply
* Re: [PATCH net-next 08/13] net/mlx5e: Add fragmented memory support for RX multi packet WQE
From: Saeed Mahameed @ 2016-03-14 18:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: Saeed Mahameed, David S. Miller, Linux Netdev List, Or Gerlitz,
Eran Ben Elisha, Tal Alon, Tariq Toukan, Jesper Dangaard Brouer
In-Reply-To: <1457726319.2663.50.camel@edumazet-ThinkPad-T530>
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.
^ permalink raw reply
* Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing
From: Cong Wang @ 2016-03-14 18:15 UTC (permalink / raw)
To: David Miller
Cc: Mahesh Bandewar, Mahesh Bandewar, Eric Dumazet,
Linux Kernel Network Developers
In-Reply-To: <20160313.235358.1007563444789525672.davem@davemloft.net>
On Sun, Mar 13, 2016 at 8:53 PM, David Miller <davem@davemloft.net> wrote:
>
> Please stop pretending that this device switching is ok, it's not.
+1
This is what I have been complaining about since v1...
^ permalink raw reply
* Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing
From: Cong Wang @ 2016-03-14 18:13 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Nicolas Dichtel, Mahesh Bandewar, David Miller, Eric Dumazet,
netdev, Eric W. Biederman, Cong Wang
In-Reply-To: <CAF2d9jhv3-GNqy3jWfPPUBgnFuOwpmMtrKSkm+9SVK7tPhEQeA@mail.gmail.com>
On Sun, Mar 13, 2016 at 5:01 PM, Mahesh Bandewar <maheshb@google.com> wrote:
>>> If I understand correctly (and as Cong already said), information are
>>> leaking
>>> between netns during the input phase. On the tx side, skb_scrub_packet() is
>>> called, but not on the rx side. I think it's wrong. There should be an
>>> explicit
>>> boundary.
>>
>> That is not what I am complaining about.
>>
>> I dislike the trick of switching skb->dev pointer with skb->dev->l3_dev.
>> This is not how we switch netns, nor the way how netns works.
>>
> How it is different from what we are doing currently?
>
> Current: Use skb->dev for L3 processing and derive netns from skb->dev
> Proposal: use skb->dev->l3_dev for L3 processing and derive netns from
> skb->dev->l3_dev
If you ever read the part you quote below, you will have the answer.
>
>> Look at veth pair or dev_change_net_namespace(), each time when we
>> switch netns, we need to do a full reregistration or a full reentrance, we
>> never just switch some pointers to switch netns. This is why I said it breaks
>> isolation.
^ You miss this part.
>>
>> Also, it is ugly to hide such a ipvlan-specific pointer for half of the RX code
>> path.
> I think I have already mentioned, I'm adding RX code now and later
> I'll add TX code to use
> l3_dev to make it symmetric. This way all L3 (Tx/Rx) will use this
> device reference
> always.
You are trying to convince me by telling me you will add more ugly code??
Seriously??
^ permalink raw reply
* RE: [PATCH v2 4/4] ethtool: support setting default Rx flow indirection table
From: Keller, Jacob E @ 2016-03-14 18:13 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1457886300.3331.26.camel@decadent.org.uk>
> -----Original Message-----
> From: Ben Hutchings [mailto:ben@decadent.org.uk]
> Sent: Sunday, March 13, 2016 9:25 AM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: netdev <netdev@vger.kernel.org>
> Subject: Re: [PATCH v2 4/4] ethtool: support setting default Rx flow
> indirection table
>
> On Tue, 2016-02-16 at 21:22 +0000, Keller, Jacob E wrote:
>
> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > ---
> >
> > Not sure if there is a mailing list for this, I sent this to the netdev
> > list but forgot to Cc you on the ethtool change.
>
> I haven't been keeping up with netdev for a long time, but I have
> recently set up filtering by subject so I can keep up with just the
> ethtool-related messages. Still, patches for the ethtool command
> should always be explicitly sent to me.
>
> > Dave applied the
> > network core patches, but they're more or less useless unless we
> > actually have the ability to request default setting using ethtool
> > (which I extended to support "default" here)
>
> The patch was mangled (word-wrapped and modified white-space) in this
> message, so I took the version in
> <http://article.gmane.org/gmane.linux.network/398404/>.
>
> [...]
> > @@ -3332,7 +3335,7 @@ static int do_srxfh(struct cmd_context *ctx)
> > u32 entry_size = sizeof(rss_head.rss_config[0]);
> > u32 num_weights = 0;
> >
> > - if (ctx->argc < 2)
> > + if (ctx->argc < 1)
> > exit_bad_args();
> [...]
>
> This means we might continue without having the required parameter
> after "equal", "weight" or "hkey". But, having said that, since we're
> only checking once before running the loop, we're already failing to
> validate that properly.
>
> I've applied this, but could you please send another patch that adds
> checks on ctx->argc within the loop and test cases in test-cmdline.c?
>
> Ben.
>
Yes. Not sure how the patch got broken for you here, as I sent it using git-send-email. I will send the proposed fix above.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH net-next] rds-tcp: Add module parameters to control sndbuf/rcvbuf size of RDS-TCP socket
From: Sowmini Varadhan @ 2016-03-14 18:06 UTC (permalink / raw)
To: Tom Herbert
Cc: Stephen Hemminger, David S. Miller,
Linux Kernel Network Developers
In-Reply-To: <CALx6S37m5s+6h4v1gKiBv2e2p+Ft9Ub4g-YLREWe=A5iuZAseA@mail.gmail.com>
In any case, to wrap up this thread.
I managed to set this up with sysctl. End result gives me a tunable
per netns (which modparam would not), and thanks to the RDS reconnect
infra, can be done dynamically at any time, not just at startup.
And it is more compact than a daemon-y solution.
I'll send out the patches later this week after some more cleanup
and testing.
--Sowmini
However, it would still be nice to know exactly what distribution
issues come out of modparam.
^ permalink raw reply
* Re: [PATCH 1/3] net: mediatek: use dma_addr_t correctly
From: John Crispin @ 2016-03-14 18:01 UTC (permalink / raw)
To: Arnd Bergmann, David S. Miller
Cc: Felix Fietkau, netdev, linux-kernel, linux-mediatek,
Matthias Brugger, linux-arm-kernel
In-Reply-To: <1457964435-2945038-1-git-send-email-arnd@arndb.de>
On 14/03/2016 15:07, Arnd Bergmann wrote:
> dma_alloc_coherent() expects a dma_addr_t pointer as its argument,
> not an 'unsigned int', and gcc correctly warns about broken
> code in the mtk_init_fq_dma function:
>
> drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function 'mtk_init_fq_dma':
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:463:13: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
>
> This changes the type of the local variable to dma_addr_t.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
thanks for the fixes
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index ba3afa5d4640..3e42204adfe5 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -453,7 +453,7 @@ static inline void mtk_rx_get_desc(struct mtk_rx_dma *rxd,
> /* the qdma core needs scratch memory to be setup */
> static int mtk_init_fq_dma(struct mtk_eth *eth)
> {
> - unsigned int phy_ring_head, phy_ring_tail;
> + dma_addr_t phy_ring_head, phy_ring_tail;
> int cnt = MTK_DMA_SIZE;
> dma_addr_t dma_addr;
> int i;
>
^ permalink raw reply
* Re: [PATCH v2 net-next] ixgbe: Avoid unaligned access in ixgbe_atr() for LLC packets
From: Sowmini Varadhan @ 2016-03-14 17:59 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: <CAKgT0Ucnf7Yyzjp_vccimVmjx-ZbYnOfKoTt6rEEZOsOEhVboQ@mail.gmail.com>
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.
--Sowmini
^ permalink raw reply
* Re: [PATCH net] ppp: ensure file->private_data can't be overridden
From: Guillaume Nault @ 2016-03-14 17:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, paulus, alan, arnd
In-Reply-To: <20160311.144216.676727973447663610.davem@davemloft.net>
On Fri, Mar 11, 2016 at 02:42:16PM -0500, David Miller wrote:
> From: Guillaume Nault <g.nault@alphalink.fr>
> Date: Tue, 8 Mar 2016 20:14:30 +0100
>
> > Lock ppp_mutex and check that file->private_data is NULL before
> > executing any action in ppp_unattached_ioctl().
> > The test done by ppp_ioctl() can't be relied upon, because
> > file->private_data may have been updated meanwhile. In which case
> > ppp_unattached_ioctl() will override file->private_data and mess up
> > reference counters or loose pointer to previously allocated PPP unit.
> >
> > In case the test fails, -ENOTTY is returned, just like if ppp_ioctl()
> > had rejected the ioctl in the first place.
> >
> > Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
>
> If this thing can disappear on us, then we need to make the entirety
> of ppp_ioctl() run with the mutex held to fix this properly.
>
> Otherwise ->private_data could go NULL on us meanwhile as well.
>
> We should hold the mutex, to stabilize the value of ->private_data.
Actually, only ppp_release() can reset ->private_data to NULL. Beyond
closing the file's last reference, the only way to trigger it is
to run the PPPIOCDETACH ioctl. But even then, ppp_release() isn't
called if the file has more than one reference.
So ->private_data should never go NULL from under another user.
As for setting ->private_data to non-NULL value, this is exclusively
handled by ppp_unattached_ioctl(). Since the ppp_mutex is held at the
beginning of the function, calls are serialised, but one may still
overwrite ->private_data and leak the memory previously pointed to.
By testing ->private_data with ppp_mutex held, this patch fixes this
issue, and ->private_data is now guaranteed to remain constant after
it's been set.
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.
I considered moving ppp_mutex up to cover the entirety of ppp_ioctl()
too, but finally choosed to handle everything in ppp_unattached_ioctl()
because that's where the problem really stands.
ppp_ioctl() takes the mutex for historical reasons (semi-automatic BKL
removal) and there are several places where holding ppp_mutex seems
unnecessary (e.g. for PPPIOCDETACH). So I felt the right direction was
to move ppp_mutex further down rather than moving it up to cover the
entirety of ppp_ioctl().
In particular, with regard to adding rtnetlink handlers for PPP (which
is the objective that lead to those PPP fixes), holding ppp_mutex for
too long is a problem. An rtnetlink handler would run under protection
of the rtnl mutex, and would need to grab ppp_mutex too (unless we
don't associate the PPP unit fd to the net device in the .newlink
callback).
But currently the PPPIOCNEWUNIT ioctl holds ppp_mutex before taking the
rtnl mutex (in ppp_create_interface()). In this context moving
ppp_mutex up to ppp_ioctl() makes things more difficult because what's
required is, on the contrary, moving it further down so that it gets
held after the rtnl mutex.
However I'd agree that such consideration shouldn't come into play for
fixes on net. It weighted a bit in my decision to not push ppp_mutex
up though.
^ permalink raw reply
* [PATCH] Documentation: networking: phy.txt: Add missing functions
From: Florian Fainelli @ 2016-03-14 17:55 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, Florian Fainelli
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>
---
Documentation/networking/phy.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index e839e7efc835..7ab9404a8412 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -267,13 +267,23 @@ Writing a PHY driver
config_intr: Enable or disable interrupts
remove: Does any driver take-down
ts_info: Queries about the HW timestamping status
+ match_phy_device: used for Clause 45 capable PHYs to match devices
+ in package and ensure they are compatible
hwtstamp: Set the PHY HW timestamping configuration
rxtstamp: Requests a receive timestamp at the PHY level for a 'skb'
txtsamp: Requests a transmit timestamp at the PHY level for a 'skb'
set_wol: Enable Wake-on-LAN at the PHY level
get_wol: Get the Wake-on-LAN status at the PHY level
+ link_change_notify: called to inform the core is about to change the
+ link state, can be used to work around bogus PHY between state changes
read_mmd_indirect: Read PHY MMD indirect register
write_mmd_indirect: Write PHY MMD indirect register
+ module_info: Get the size and type of an EEPROM contained in an plug-in
+ module
+ module_eeprom: Get EEPROM information of a plug-in module
+ get_sset_count: Get number of strings sets that get_strings will count
+ get_strings: Get strings from requested objects (statistics)
+ get_stats: Get the extended statistics from the PHY device
Of these, only config_aneg and read_status are required to be
assigned by the driver code. The rest are optional. Also, it is
--
2.1.0
^ permalink raw reply related
* Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing
From: Mahesh Bandewar @ 2016-03-14 17:57 UTC (permalink / raw)
To: David Miller; +Cc: mahesh, Eric Dumazet, linux-netdev
In-Reply-To: <20160313.235358.1007563444789525672.davem@davemloft.net>
On Sun, Mar 13, 2016 at 8:53 PM, David Miller <davem@davemloft.net> wrote:
> From: Mahesh Bandewar <maheshb@google.com>
> Date: Sun, 13 Mar 2016 19:29:58 -0700
>
>> On Sun, Mar 13, 2016 at 6:50 PM, David Miller <davem@davemloft.net> wrote:
>>> It doesn't matter whether doing so or not makes sense.
>>>
>>> You're going to have to find a way to do both, and also I'm concerned
>>> about how you're leaking the source namespace's "stuff" into the
>>> destination's. That's very worrisome to me.
>>
>> If we add a new mode (e.g. L3s) and preserve current mode as is it,
>> then that should address your first concern.
>
> Also, I don't want all of this device translation stuff all over the
> place.
>
I could add skb->dev. Is that OK? Then non of this translation / helper-stuff
is required. I'm definitely open for suggestions.
> Furthermore, when you walk across the ns boundary, that old device has
> to disappear. That's why that is the device assigned to skb->dev.
>
The layer boundaries are not that well maintained. We do check for the xfrm
policies in L4 and expect the skb->dev pointing to the L3 device. So unless we
have a way to derive a L3 dev from skb->dev, I don't think xfrm will
work. Unless
some Xfrm-expert asserts that this is not needed.
> Please stop pretending that this device switching is ok, it's not.
^ permalink raw reply
* Re: [PATCH net-next] rds-tcp: Add module parameters to control sndbuf/rcvbuf size of RDS-TCP socket
From: Tom Herbert @ 2016-03-14 17:57 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: Stephen Hemminger, David S. Miller,
Linux Kernel Network Developers
In-Reply-To: <20160312043952.GC26486@oracle.com>
On Fri, Mar 11, 2016 at 8:39 PM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (03/11/16 20:07), Tom Herbert wrote:
>
>> You are describing your deployment of RDS, not kernel implementation.
>> What I see is a very rigid implementation that would make it hard for
>> many us to ever even consider deploying. The abilities of applications
>> to tune TCP connections is well understood, very prevalent, and really
>> fundamental in making TCP based datacenters at large scale.
>
> sorry, historically, OS DDI/DKI's for kernel modules have always
> had some way to set up startup parameters at module load time. And
> clusters have been around for a while.
>
> So let's just focus on the technical question around module config here,
> which involves more than TCP sockets, btw.
>
>> Any way, it was just an idea... ;-)
>
> Thank you.
>
> Moving on,
>
>> Maybe add one module parameter that indicates the module should just
>> load but not start, configure whatever is needed via netlink, and then
>> send one more netlink command to start operations.
>
> Even that needs an extra daemon.
>
> Without getting into the vast number of questions that it raises (such
> as every module with startup params now needs a uspace counterpart?
> modprobe-r behavior, namespace behavior? Why netlink for every kernel
> module? etc)..
>
Most modules of any significant complexity are managed via netlink,
and so all of your questions have likely already been answered. Yes,
netlink assumes userspace configuration tools ("ip" configuration many
different networking modules). There are simple interfaces to
create/delete a module's netlink hooks when module is added/removed.
Netlink operates in the context of network namespaces. netlink is
preferred since it is far more extensible and generic for
configuration than sysctl, module params, etc.
Tom
> One module parameter is as much a "distribution management"
> problem as 10 of them, yes? I hope you see that I dont need that module
> param and daemon baggage- I can just use sysctl to set up all my params,
> including one bit for module_can_start_now to achieve the same thing.
>
> But it is still more than the handful of lines of code in my patch,
> so it would be nice to understand what is the "distribution" issue.
>
> Stepping back, how do we make sysctl fully namespace friendly?
>
> btw setting kernel socket keepalive params via sysctl is not a problem
> to implement at all, if it ever shows up as a requirement for customers.
>
> --Sowmini
>
^ permalink raw reply
* Re: [PATCH 1/5] mlx4: add missing braces in verify_qp_parameters
From: Leon Romanovsky @ 2016-03-14 17:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA, Yishai Hadas,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1457965120-3155420-2-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
On Mon, Mar 14, 2016 at 03:18:34PM +0100, Arnd Bergmann wrote:
> The implementation of QP paravirtualization back in linux-3.7 included
> some code that looks very dubious, and gcc-6 has grown smart enough
> to warn about it:
>
> drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'verify_qp_parameters':
> drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3154:5: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
> if (optpar & MLX4_QP_OPTPAR_ALT_ADDR_PATH) {
> ^~
> drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3144:4: note: ...this 'if' clause, but it is not
> if (slave != mlx4_master_func_num(dev))
>
> From looking at the context, I'm reasonably sure that the indentation
> is correct but that it should have contained curly braces from the
> start, as the update_gid() function in the same patch correctly does.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Fixes: 54679e148287 ("mlx4: Implement QP paravirtualization and maintain phys_pkey_cache for smp_snoop")
Thanks, looks good.
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> index 25ce1b030a00..cd9b2b28df88 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> @@ -3141,7 +3141,7 @@ static int verify_qp_parameters(struct mlx4_dev *dev,
> case QP_TRANS_RTS2RTS:
> case QP_TRANS_SQD2SQD:
> case QP_TRANS_SQD2RTS:
> - if (slave != mlx4_master_func_num(dev))
> + if (slave != mlx4_master_func_num(dev)) {
> if (optpar & MLX4_QP_OPTPAR_PRIMARY_ADDR_PATH) {
> port = (qp_ctx->pri_path.sched_queue >> 6 & 1) + 1;
> if (dev->caps.port_mask[port] != MLX4_PORT_TYPE_IB)
> @@ -3160,6 +3160,7 @@ static int verify_qp_parameters(struct mlx4_dev *dev,
> if (qp_ctx->alt_path.mgid_index >= num_gids)
> return -EINVAL;
> }
> + }
> break;
> default:
> break;
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 net-next] ixgbe: Avoid unaligned access in ixgbe_atr() for LLC packets
From: Alexander Duyck @ 2016-03-14 17:55 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: <20160314174624.GG5084@oracle.com>
On Mon, Mar 14, 2016 at 10:46 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
>
> 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 first->protocol.
>
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> ---
> v2: Alexander Duyck comments.
>
> 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..b25e603 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;
>
> + if (first->protocol != htons(ETH_P_IP) &&
> + first->protocol != htons(ETH_P_IPV6) &&
> + first->protocol != htons(ETH_P_ARP))
> + return;
> +
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.
- Alex
^ permalink raw reply
* [PATCH net-next v6] tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/In
From: Martin KaFai Lau @ 2016-03-14 17:52 UTC (permalink / raw)
To: netdev
Cc: Kernel Team, Chris Rapier, Eric Dumazet, Marcelo Ricardo Leitner,
Neal Cardwell, Yuchung Cheng
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>
---
include/linux/tcp.h | 6 ++++++
include/net/tcp.h | 10 ++++++++++
include/uapi/linux/tcp.h | 2 ++
net/ipv4/tcp.c | 2 ++
net/ipv4/tcp_fastopen.c | 8 ++++++++
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/tcp_minisocks.c | 2 +-
net/ipv4/tcp_output.c | 4 +++-
net/ipv6/tcp_ipv6.c | 2 +-
9 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index bcbf51d..7be9b12 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -158,6 +158,9 @@ struct tcp_sock {
u32 segs_in; /* RFC4898 tcpEStatsPerfSegsIn
* total number of segments in.
*/
+ u32 data_segs_in; /* RFC4898 tcpEStatsPerfDataSegsIn
+ * total number of data segments in.
+ */
u32 rcv_nxt; /* What we want to receive next */
u32 copied_seq; /* Head of yet unread data */
u32 rcv_wup; /* rcv_nxt on last window update sent */
@@ -165,6 +168,9 @@ struct tcp_sock {
u32 segs_out; /* RFC4898 tcpEStatsPerfSegsOut
* The total number of segments sent.
*/
+ u32 data_segs_out; /* RFC4898 tcpEStatsPerfDataSegsOut
+ * total number of data segments sent.
+ */
u64 bytes_acked; /* RFC4898 tcpEStatsAppHCThruOctetsAcked
* sum(delta(snd_una)), or how many bytes
* were acked.
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 0302636..c8dbd29 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1840,4 +1840,14 @@ static inline int tcp_inq(struct sock *sk)
return answ;
}
+static inline void tcp_segs_in(struct tcp_sock *tp, const struct sk_buff *skb)
+{
+ u16 segs_in;
+
+ segs_in = max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ tp->segs_in += segs_in;
+ if (skb->len > tcp_hdrlen(skb))
+ tp->data_segs_in += segs_in;
+}
+
#endif /* _TCP_H */
diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
index fe95446..53e8e3f 100644
--- a/include/uapi/linux/tcp.h
+++ b/include/uapi/linux/tcp.h
@@ -199,6 +199,8 @@ struct tcp_info {
__u32 tcpi_notsent_bytes;
__u32 tcpi_min_rtt;
+ __u32 tcpi_data_segs_in; /* RFC4898 tcpEStatsDataSegsIn */
+ __u32 tcpi_data_segs_out; /* RFC4898 tcpEStatsDataSegsOut */
};
/* for TCP_MD5SIG socket option */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index a265f00..992b310 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2715,6 +2715,8 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
info->tcpi_notsent_bytes = max(0, notsent_bytes);
info->tcpi_min_rtt = tcp_min_rtt(tp);
+ info->tcpi_data_segs_in = tp->data_segs_in;
+ info->tcpi_data_segs_out = tp->data_segs_out;
}
EXPORT_SYMBOL_GPL(tcp_get_info);
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index fdb286d..4fc0061 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -140,6 +140,14 @@ void tcp_fastopen_add_skb(struct sock *sk, struct sk_buff *skb)
return;
skb_dst_drop(skb);
+ /* segs_in has been initialized to 1 in tcp_create_openreq_child().
+ * Hence, reset segs_in to 0 before calling tcp_segs_in()
+ * to avoid double counting. Also, tcp_segs_in() expects
+ * skb->len to include the tcp_hdrlen. Hence, it should
+ * be called before __skb_pull().
+ */
+ tp->segs_in = 0;
+ tcp_segs_in(tp, skb);
__skb_pull(skb, tcp_hdrlen(skb));
skb_set_owner_r(skb, sk);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 4c8d58d..0b02ef7 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1650,7 +1650,7 @@ process:
sk_incoming_cpu_update(sk);
bh_lock_sock_nested(sk);
- tcp_sk(sk)->segs_in += max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ tcp_segs_in(tcp_sk(sk), skb);
ret = 0;
if (!sock_owned_by_user(sk)) {
if (!tcp_prequeue(sk, skb))
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index ae90e4b..acb366d 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -812,7 +812,7 @@ int tcp_child_process(struct sock *parent, struct sock *child,
int ret = 0;
int state = child->sk_state;
- tcp_sk(child)->segs_in += max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ tcp_segs_in(tcp_sk(child), skb);
if (!sock_owned_by_user(child)) {
ret = tcp_rcv_state_process(child, skb);
/* Wakeup parent, send SIGIO */
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 7d2c7a4..7d2dc01 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1003,8 +1003,10 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
if (likely(tcb->tcp_flags & TCPHDR_ACK))
tcp_event_ack_sent(sk, tcp_skb_pcount(skb));
- if (skb->len != tcp_header_size)
+ if (skb->len != tcp_header_size) {
tcp_event_data_sent(tp, sk);
+ tp->data_segs_out += tcp_skb_pcount(skb);
+ }
if (after(tcb->end_seq, tp->snd_nxt) || tcb->seq == tcb->end_seq)
TCP_ADD_STATS(sock_net(sk), TCP_MIB_OUTSEGS,
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 33f2820..9c16565 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1443,7 +1443,7 @@ process:
sk_incoming_cpu_update(sk);
bh_lock_sock_nested(sk);
- tcp_sk(sk)->segs_in += max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ tcp_segs_in(tcp_sk(sk), skb);
ret = 0;
if (!sock_owned_by_user(sk)) {
if (!tcp_prequeue(sk, skb))
--
2.5.1
^ permalink raw reply related
* Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
From: Scott Wood @ 2016-03-14 17:45 UTC (permalink / raw)
To: Yangbo Lu, Arnd Bergmann, linuxppc-dev@lists.ozlabs.org
Cc: devicetree@vger.kernel.org, ulf.hansson@linaro.org, Zhao Qiang,
Russell King, Bhupesh Sharma, netdev@vger.kernel.org,
Joerg Roedel, Kumar Gala, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org, Yang-Leo Li,
iommu@lists.linux-foundation.org, Rob Herring,
linux-i2c@vger.kernel.org, Claudiu Manoil, Santosh Shilimkar,
Xiaobo Xie, linux-clk@vger.kernel.org,
"linux-arm-kernel@lists.infradead.
In-Reply-To: <HE1PR04MB0889CE4742B92461A925B9C4F8880@HE1PR04MB0889.eurprd04.prod.outlook.com>
On 03/14/2016 02:29 AM, Yangbo Lu wrote:
>> -----Original Message-----
>> From: Arnd Bergmann [mailto:arnd@arndb.de]
>> Sent: Monday, March 14, 2016 6:26 AM
>> To: linuxppc-dev@lists.ozlabs.org
>> Cc: Yangbo Lu; devicetree@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
>> clk@vger.kernel.org; linux-i2c@vger.kernel.org; iommu@lists.linux-
>> foundation.org; netdev@vger.kernel.org; linux-mmc@vger.kernel.org;
>> ulf.hansson@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma; Joerg
>> Roedel; Santosh Shilimkar; Scott Wood; Rob Herring; Claudiu Manoil; Kumar
>> Gala; Yang-Leo Li; Xiaobo Xie
>> Subject: Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-
>> R1.0-R2.0
>>
>> On Wednesday 09 March 2016 18:08:51 Yangbo Lu wrote:
>>> @@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device
>> *pdev, struct sdhci_host *host)
>>> struct sdhci_pltfm_host *pltfm_host;
>>> struct sdhci_esdhc *esdhc;
>>> u16 host_ver;
>>> + u32 svr;
>>>
>>> pltfm_host = sdhci_priv(host);
>>> esdhc = sdhci_pltfm_priv(pltfm_host);
>>>
>>> + fsl_guts_init();
>>> + svr = fsl_guts_get_svr();
>>> + if (svr) {
>>> + esdhc->soc_ver = SVR_SOC_VER(svr);
>>> + esdhc->soc_rev = SVR_REV(svr);
>>> + } else {
>>> + dev_err(&pdev->dev, "Failed to get SVR value!\n");
>>> + }
>>> +
>>
>> This makes the driver non-portable. Better identify the specific
>> workarounds based on the compatible string for this device, or add a
>> boolean DT property for the quirk.
>>
>> Arnd
>
> [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before.
> https://patchwork.kernel.org/patch/6834221/
>
> We don’t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one.
> In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed.
> See the link for details.
>
> So we decide to read SVR from the device-config/guts MMIO block other than using DTS.
> Thanks.
Also note that this driver is already only for fsl-specific hardware,
and it will still work even if fsl_guts doesn't find anything to bind to
-- it just wouldn't be able to detect errata based on SVR in that case.
-Scott
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net-next] ixgbe: Avoid unaligned access in ixgbe_atr() for LLC packets
From: Alexander Duyck @ 2016-03-14 17:12 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: intel-wired-lan, Netdev
In-Reply-To: <20160314153216.GF5084@oracle.com>
On Mon, Mar 14, 2016 at 8:32 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
>
> 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.
>
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> ---
> 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..c3885a8 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -7602,6 +7602,11 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
> #endif /* CONFIG_IXGBE_VXLAN */
> }
>
> + if (skb->protocol != htons(ETH_P_IP) &&
> + skb->protocol != htons(ETH_P_IPV6) &&
> + skb->protocol != htons(ETH_P_ARP))
> + return;
> +
This is disabling too much as it snags VLAN along with everything
else. Replace skb->protocol with first->protocol and this should work
correctly.
You may also want to move it up by several lines so that you don't
count it as a valid ATR frame via atr_count.
Thanks.
- Alex
^ permalink raw reply
* Re: [PATCH] vmxnet3: fix lock imbalance in vmxnet3_tq_xmit()
From: David Miller @ 2016-03-14 17:11 UTC (permalink / raw)
To: arnd
Cc: skhare, pv-drivers, sbhatewara, gyang, nhorman, khoroshilov,
netdev, linux-kernel
In-Reply-To: <1457967280-4014226-1-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 14 Mar 2016 15:53:57 +0100
> A recent bug fix rearranged the code in vmxnet3_tq_xmit() in a
> way that left the error handling for oversized headers unlock
> a lock that had not been taken yet. Gcc warns about the incorrect
> use of the 'flags' variable because of that:
>
> drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_tq_xmit.constprop':
> include/linux/spinlock.h:246:3: error: 'flags' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This changes the error handling path to 'goto' the end of the function
> beyond the lock/unlock pair.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: cec05562fb1d ("vmxnet3: avoid calling pskb_may_pull with interrupts disabled")
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: net: gcc-6.0 warning fixes
From: David Miller @ 2016-03-14 17:10 UTC (permalink / raw)
To: arnd; +Cc: netdev
In-Reply-To: <1457965120-3155420-1-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 14 Mar 2016 15:18:33 +0100
> I've just installed gcc-6.0 to see what kinds of new warnings
> we get. It turns out that it's actually really useful once I
> disabled -Wunused-const-variable, and all of the warnings it
> found in network drivers seem valid.
>
> Sorry for the bad timing in the merge window, but I figured
> it would be better to send the fixes as I found the bugs
> rather than waiting for the next cycle. The first three
> look appropriate for stable backports.
>
> The other two only fix a gcc warning about incorrect whitespace,
> probably not worth backporting those.
Series applied, and patches 1, 2, and 3 queued up for -stable.
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