* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Vishwanathapura, Niranjana @ 2017-01-11 9:05 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, ira.weiny, Jeff Kirsher, David S. Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170110081402.GH7218-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
On Tue, Jan 10, 2017 at 10:14:02AM +0200, Leon Romanovsky wrote:
>On Mon, Jan 09, 2017 at 07:39:54PM -0800, Vishwanathapura, Niranjana wrote:
>> We are also looking into Jason’s suggestion to make hfi_vnic interface to
>> the bottom driver a generic interface. This will include moving some of the
>> netstack interfacing to the bottom hfi1 driver.
>
>Great, do you have rough estimation when will it be posted on the ML?
>
>Thanks
>
Hi Leon,
I am currently doing some prototype on this. I will respond with the interface
definition first once I have it solidified. RFC v3 with implemetion will be
later.
Niranjana
--
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 2/3] xgbe: switch to pci_irq_alloc_vectors
From: Christoph Hellwig @ 2017-01-11 9:03 UTC (permalink / raw)
To: Tom Lendacky
Cc: Christoph Hellwig, linux-pci, Mauro Carvalho Chehab, netdev,
linux-media
In-Reply-To: <11ed330c-84e9-79e9-7945-ca17a497359c@amd.com>
On Tue, Jan 10, 2017 at 12:40:10PM -0600, Tom Lendacky wrote:
> On 1/9/2017 2:37 PM, Christoph Hellwig wrote:
> > The newly added xgbe drivers uses the deprecated pci_enable_msi_exact
> > and pci_enable_msix_range interfaces. Switch it to use
> > pci_irq_alloc_vectors instead.
>
> I was just working on switching over to this API with some additional
> changes / simplification. I'm ok with using this patch so that you get
> the API removal accomplished. Going through the PCI tree just means
> it will probably be easier for me to hold off on the additional changes
> I wanted to make until later.
Hi Tom,
if you have a better patch I'd be more than happy to use that one instead,
this one was intended as a stupid search and replace. The important
part for me is to get the two conversions and the interface removal
in together.
E.g. I've alreayd wondered why the driver requires the exact vector
number for MSI and a variable one for MSI-X, and there certainly is
all kinds of opportunity for cosmetic cleanup.
^ permalink raw reply
* Re: bad interaction between privacy extensions, prefix lifetimes and protocols that maintain long-term connections.
From: Bjørn Mork @ 2017-01-11 8:54 UTC (permalink / raw)
To: peter green; +Cc: debian-ipv6, netdev
In-Reply-To: <9769f6b7-946c-1279-110f-15de8ec40022@p10link.net>
peter green <plugwash@p10link.net> writes:
> Disabling privacy extensions solved the issue but obviously reveals
> the MAC address of my new machine to the world which is undesirable.
I have no solution to the problem with privacy extensions, but just
wanted to let you know there is a third alternative for IPv6
autoconfigured addresses: stable-privacy
This will give you addresses which are just as stable as the eui64
addresses, but derived from a configurable secret instead of the
mac. The kernel part is documented in under 'stable_secret' in
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
If you use NetworkManager, then this is very easy to set up: Just set
'addr-gen-mode' to 'stable-privacy'. See the docs in nm-settings(5).
Or if you use ifupdown and prefer to control it yourself, you can
e.g. save the secret (in IPv6 address format) in some file and write it
to /proc/sys/net/ipv6/conf/default/stable_secret on boot. This will set
a common secret for all interfaces. Note that the generated interface
ids still will be different, since the prefix is used as part of the
input to the generator.
Bjørn
^ permalink raw reply
* [PATCH net] r8152: fix the sw rx checksum is unavailable
From: Hayes Wang @ 2017-01-11 8:25 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Fix the hw rx checksum is always enabled, and the user couldn't switch
it to sw rx checksum.
Note that the RTL_VER_01 only support sw rx checksum only. Besides,
the hw rx checksum for RTL_VER_02 is disabled after
commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index be41856..f3b48ad 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1730,7 +1730,7 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc *rx_desc)
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
- if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02)
+ if (!(tp->netdev->features & NETIF_F_RXCSUM))
goto return_result;
opts2 = le32_to_cpu(rx_desc->opts2);
@@ -4356,6 +4356,11 @@ static int rtl8152_probe(struct usb_interface *intf,
NETIF_F_HIGHDMA | NETIF_F_FRAGLIST |
NETIF_F_IPV6_CSUM | NETIF_F_TSO6;
+ if (tp->version == RTL_VER_01) {
+ netdev->features &= ~NETIF_F_RXCSUM;
+ netdev->hw_features &= ~NETIF_F_RXCSUM;
+ }
+
netdev->ethtool_ops = &ops;
netif_set_gso_max_size(netdev, RTL_LIMITED_TSO_SIZE);
--
2.7.4
^ permalink raw reply related
* net: ti: cpsw-phy-sel: RGMII is not working on AM335x
From: Teresa Remmet @ 2017-01-11 8:14 UTC (permalink / raw)
To: Alexandru Gagniuc, David S. Miller, Mugunthan V N,
Grygorii Strashko
Cc: linux-omap, netdev
Hello,
I met a issue with the gmii_sel register on the AM335x when using
RGMII. The patch,
commit 74685b08fbb26ff5b8448fabe0941a53269dd33e
Author: Alex <alex.g@adaptrum.com>
Date: Tue Dec 6 10:56:51 2016 -0800
drivers: net: cpsw-phy-sel: Clear RGMII_IDMODE on "rgmii" links
Support for setting the RGMII_IDMODE bit was added in the commit
referenced below. However, that commit did not add the symmetrical
clearing of the bit by way of setting it in "mask". Add it here.
Note that the documentation marks clearing this bit as "reserved",
however, according to TI, support for delaying the clock does exist in
the MAC, although it is not officially supported.
We tested this on a board with an RGMII to RGMII link that will not
work unless this bit is cleared.
Fixes: 0fb26c3063ea ("drivers: net: cpsw-phy-sel: add support to configure rgmii int
Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
is suppose to fix the RGMII mode with setting the RGMII0/1_ID_MODE
bit to 0: "Reserved". I use RMII1 and RGMII2 on our custom
AM335x board. The RMII1 is still working with the patch but
I do not get any data transfered on the RGMII2. When I revert
the patch, everything works again.
I tested this on 4.10-rc3.
The AM335x TRM Rev. O notes on Chapter 14.3.6.4:
"The RGMII0/1_ID_MODE bit value in the GMII_SEL register should
only be set to 1 for 'no internal delay'.
The device does not support internal delay mode for RGMII."
So I wonder what is correct now? As for me the patch makes RGMII unusable.
Has anyone an explanation?
Regards,
Teresa
^ permalink raw reply
* Re: [PATCH net-next 2/2] Revert "net: dsa: Implement ndo_get_phys_port_id"
From: Jiri Pirko @ 2017-01-11 7:29 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem, vivien.didelot, andrew
In-Reply-To: <20170110203237.23907-3-f.fainelli@gmail.com>
Tue, Jan 10, 2017 at 09:32:37PM CET, f.fainelli@gmail.com wrote:
>This reverts commit 3a543ef479868e36c95935de320608a7e41466ca ("net: dsa:
>Implement ndo_get_phys_port_id") since it misuses the purpose of
>ndo_get_phys_port_id(). We have ndo_get_phys_port_name() to do the
>correct thing for us now.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>---
> net/dsa/slave.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
>diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>index fed3fbd403cb..0cdcaf526987 100644
>--- a/net/dsa/slave.c
>+++ b/net/dsa/slave.c
>@@ -983,15 +983,6 @@ static void dsa_slave_poll_controller(struct net_device *dev)
> }
> #endif
>
>-static int dsa_slave_get_phys_port_id(struct net_device *dev,
>- struct netdev_phys_item_id *ppid)
>-{
>- struct dsa_slave_priv *p = netdev_priv(dev);
>-
>- ppid->id_len = sizeof(p->port);
>- memcpy(ppid->id, &p->port, ppid->id_len);
>-}
>-
> static int dsa_slave_get_phys_port_name(struct net_device *dev,
> char *name, size_t len)
> {
>@@ -1050,7 +1041,6 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
> .ndo_bridge_getlink = switchdev_port_bridge_getlink,
> .ndo_bridge_setlink = switchdev_port_bridge_setlink,
> .ndo_bridge_dellink = switchdev_port_bridge_dellink,
>- .ndo_get_phys_port_id = dsa_slave_get_phys_port_id,
> .ndo_get_phys_port_name = dsa_slave_get_phys_port_name,
> };
>
>--
>2.9.3
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: Implement ndo_get_phys_port_name()
From: Jiri Pirko @ 2017-01-11 7:29 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem, vivien.didelot, andrew
In-Reply-To: <20170110203237.23907-2-f.fainelli@gmail.com>
Tue, Jan 10, 2017 at 09:32:36PM CET, f.fainelli@gmail.com wrote:
>Return the physical port number of a DSA created network device using
>ndo_get_phys_port_name().
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>---
> net/dsa/slave.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
>diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>index 5cd5b8137c08..fed3fbd403cb 100644
>--- a/net/dsa/slave.c
>+++ b/net/dsa/slave.c
>@@ -990,6 +990,15 @@ static int dsa_slave_get_phys_port_id(struct net_device *dev,
>
> ppid->id_len = sizeof(p->port);
> memcpy(ppid->id, &p->port, ppid->id_len);
>+}
>+
>+static int dsa_slave_get_phys_port_name(struct net_device *dev,
>+ char *name, size_t len)
>+{
>+ struct dsa_slave_priv *p = netdev_priv(dev);
>+
>+ if (snprintf(name, len, "p%d", p->port) >= len)
>+ return -EINVAL;
>
> return 0;
> }
>@@ -1042,6 +1051,7 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
> .ndo_bridge_setlink = switchdev_port_bridge_setlink,
> .ndo_bridge_dellink = switchdev_port_bridge_dellink,
> .ndo_get_phys_port_id = dsa_slave_get_phys_port_id,
>+ .ndo_get_phys_port_name = dsa_slave_get_phys_port_name,
> };
>
> static const struct switchdev_ops dsa_slave_switchdev_ops = {
>--
>2.9.3
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: Implement ndo_get_phys_port_name()
From: Jiri Pirko @ 2017-01-11 7:28 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, netdev, davem, vivien.didelot
In-Reply-To: <60d188ef-a080-1707-9ff2-0ebfa58b81d2@gmail.com>
Tue, Jan 10, 2017 at 09:58:53PM CET, f.fainelli@gmail.com wrote:
>On 01/10/2017 12:50 PM, Andrew Lunn wrote:
>> On Tue, Jan 10, 2017 at 12:32:36PM -0800, Florian Fainelli wrote:
>>> Return the physical port number of a DSA created network device using
>>> ndo_get_phys_port_name().
>>
>> At what level does this need to be unique?
>
>This needs to be unique to the switch I would say,
Yes.
>ndo_get_phys_switch_id would return the physical number of the switch
>device in the tree/cluster, so that number plus the port name should be
>an unique differentiator that is good enough for e.g: a persistent
>naming rule?
Yes.
>
>>
>> We can have multiple switches within one switch cluster. p->port will
>> be unique within one switch, but can be repeated in a cluster.
>>
>> We can also have multiple clusters, and again p->port will be re-used.
>
>
>--
>Florian
^ permalink raw reply
* Re: [PATCH net-next v2] net: dsa: make "label" property optional for dsa2
From: Jiri Pirko @ 2017-01-11 7:26 UTC (permalink / raw)
To: Florian Fainelli
Cc: Vivien Didelot, netdev, linux-kernel, kernel, David S. Miller,
Andrew Lunn, Uwe Kleine-König, Andrey Smirnov
In-Reply-To: <3c7e5102-cef7-c909-a192-6238103e444e@gmail.com>
Tue, Jan 10, 2017 at 06:58:18PM CET, f.fainelli@gmail.com wrote:
>On 01/10/2017 01:55 AM, Jiri Pirko wrote:
>> Mon, Jan 09, 2017 at 07:06:39PM CET, f.fainelli@gmail.com wrote:
>>> On 01/09/2017 09:58 AM, Jiri Pirko wrote:
>>>> Mon, Jan 09, 2017 at 06:42:07PM CET, f.fainelli@gmail.com wrote:
>>>>> On 01/09/2017 08:06 AM, Jiri Pirko wrote:
>>>>>> Mon, Jan 09, 2017 at 04:45:33PM CET, vivien.didelot@savoirfairelinux.com wrote:
>>>>>>> Hi Jiri,
>>>>>>>
>>>>>>> Jiri Pirko <jiri@resnulli.us> writes:
>>>>>>>
>>>>>>>>> Extra question: shouldn't phys_port_{id,name} be switchdev attributes in
>>>>>>>>
>>>>>>>> Again, phys_port_id has nothing to do with switches. Should be removed
>>>>>>>> from dsa because its use there is incorrect.
>>>>>>>
>>>>>>> Florian, since 3a543ef just got in, can it be reverted?
>>>>>>
>>>>>> Yes, please revert it. It is only in net-next.
>>>>>
>>>>> Maybe the use case can be understood before reverting the change. How do
>>>>> we actually the physical port number of an Ethernet switch per-port
>>>>> network device? The name is not enough, because there are plenty of
>>>>> cases where we need to manipulate a physical port number (be it just for
>>>>> informational purposes).
>>>>
>>>> Like what?
>>>
>>> Specifying the physical port number (and derive a queue number
>>> eventually) for some ethtool (e.g: rxnfc)/tc (queue mapping) operations
>>> where there is an action/queue/port destination argument that gets
>>> programmed into the hardware.
>>
>> Could you point me to a real example? User command?
>
>ethtool --config-nfc moca flow-type udp4 src-ip 192.168.1.20 dst-ip \
> 192.168.1.10 src-port 49884 dst-port 5001 action 2
>
>Where 2 here designates a port number, users need to be able to look up
>the physical port number corresponding to an interface to know which
>value to put in this command.
2 is not a port number but RX queue number. I believe you need to
ditinguish that and port_name. Not sure how are they related.
>
>Yes I know we can do the same thing with cls_flower, possibly by
>referencing network devices directly.
Yes, that is what you should do. I believe that using config-nfc is not
correct for this use-case.
>
>>
>>
>>>
>>> You already have the originating port number from the interface you call
>>> the method against, but you also need the destination port number since
>>> that is what the HW understands.
>>
>> This is internal to kernel? I fail to understand what you mean exactly.
>
>See the command above, from using the "moca" netdev here, we can access
>the DSA private network device (dsa_slave_priv) structure and get the
>port number from there, and pass this down to the switch driver. The
>switch driver also takes another port number (and eventually a queue
>number) to program classification filters.
>
>>
>>
>>>
>>> Aside from that, it is useful for allowing interface naming in user
>>> space if you don't want to use labels.
>>>
>>>>
>>>> Why the name is not enough? This is something propagated to userspace
>>>> and never used internally in kernel.
>>>
>>> Because the name is not reflective of the port number in some switches.
>>> In my case for instance, we have 5 ports that are named after the
>>> entities they connect to (an integrated Gigabit PHY, two RGMII pads, one
>>> MoCA interface, and the CPU)
>>>
>>
>> Again, I'm missing why you need a portnumber as a Integer to userspace.
>> From driver, you can expose phys_port_name:
>
>If we are exposing the port name here, we may as well expose the DSA
>"label" instead of the physical port number number?
Yeah, that makes sense.
>
>I don't deny my change may be misusing what phys_port_id was originally
>designed for, but providing "p0" instead of "0" to user-space, what
>value is there in adding the "p" in front really?
It's up to a driver. He knows how the front panel names look like.
>--
>Florian
^ permalink raw reply
* Re: [RFC PATCH 2/4] page_pool: basic implementation of page_pool
From: Jesper Dangaard Brouer @ 2017-01-11 7:10 UTC (permalink / raw)
To: Mel Gorman
Cc: Vlastimil Babka, linux-mm, Alexander Duyck, willemdebruijn.kernel,
netdev, john.fastabend, Saeed Mahameed, bjorn.topel,
Alexei Starovoitov, Tariq Toukan, brouer
In-Reply-To: <20170109215825.k4grwyhffiv6wksp@techsingularity.net>
On Mon, 9 Jan 2017 21:58:26 +0000
Mel Gorman <mgorman@techsingularity.net> wrote:
> On Mon, Jan 09, 2017 at 09:45:24PM +0100, Jesper Dangaard Brouer wrote:
> > > I see. I guess if all page pool pages were order>0 compound pages, you
> > > could hook this to the existing compound_dtor functionality instead.
> >
> > The page_pool will support order>0 pages, but it is the order-0 case
> > that is optimized for.
> >
>
> The bulk allocator is currently not suitable for high-order pages. It would
> take more work to do that but is not necessarily even a good idea. FWIW,
> the high-order per-cpu page allocator posted some weeks ago would be the
> basis. I didn't push that series as the benefit to SLUB was too marginal
> given the complexity.
>
> > > Well typically the VMA mapped pages are those on the LRU list (anonymous
> > > or file). But I don't suppose you will want memory reclaim to free your
> > > pages, so seems lru field should be reusable for you.
> >
> > Thanks for the info.
> >
> > So, LRU-list area could be reusable, but I does not align so well with
> > the bulking API Mel just introduced/proposed, but still doable.
> >
>
> That's a relatively minor implementation detail. I needed something to
> hang the pages onto for returning. Using a list and page->lru is a standard
> approach but it does not mandate that the caller preserve page->lru or that
> it's related to the LRU. The caller simply needs to put the pages back onto
> a list if it's bulk freeing or call __free_pages() directly for each page.
> If any in-kernel user uses __free_pages() then the free_pages_bulk()
> API can be dropped entirely.
>
> I'm not intending to merge the bulk allocator due to a lack of in-kernel
> users and an inability to test in-kernel users. It was simply designed to
> illustrate how to call the core of the page allocator in a way that avoids
> the really expensive checks. If required, the pages could be returned on
> a caller-allocated array or something exotic like using one page to store
> pointers to the rest. Either of those alternatives are harder to use. A
> caller-allocated array must be sure the nr_pages parameter is correct and
> the exotic approach would require careful use by the caller. Using page->lru
> was more straight-forward when the requirements of the callers was unknown.
>
> It opens the question of what to do with that series. I was going to wait
> for feedback but my intent was to try merge patches 1-3 if there were no
> objections and preferably with your reviewed-by or ack. I would then hand
> patch 4 over to you for addition to a series that added in-kernel callers to
> alloc_pages_bulk() be that the generic pool recycle or modifying drivers.
> You are then free to modify the API to suit your needs without having to
> figure out the best way of calling the page allocator.
I think that sound like a good plan.
Your patches 1-3 is a significant performance improvement for the page
allocator, and I want to see those merged. Don't want to block it with
patch 4 (bulking).
I'm going to do some (more) testing on your patchset, and then ACK the
patches.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v3 10/27] benet: use __vlan_hwaccel helpers
From: Somnath Kotur @ 2017-01-11 5:29 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, Ajit Khaparde
In-Reply-To: <8a9f0d12b69ee4e25fefc4872575d5cf31441bb8.1483484748.git.mirq-linux@rere.qmqm.pl>
On Wed, Jan 4, 2017 at 4:41 AM, Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
> v3: fix adapter->pvid handling
>
> drivers/net/ethernet/emulex/benet/be_main.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 7e1633bf5a22..cd12c9a7664b 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -1035,30 +1035,35 @@ static struct sk_buff *be_insert_vlan_in_pkt(struct be_adapter *adapter,
> struct be_wrb_params
> *wrb_params)
> {
> + bool insert_vlan = false;
> u16 vlan_tag = 0;
>
> skb = skb_share_check(skb, GFP_ATOMIC);
> if (unlikely(!skb))
> return skb;
>
> - if (skb_vlan_tag_present(skb))
> + if (skb_vlan_tag_present(skb)) {
> vlan_tag = be_get_tx_vlan_tag(adapter, skb);
> + insert_vlan = true;
> + }
>
> if (qnq_async_evt_rcvd(adapter) && adapter->pvid) {
> - if (!vlan_tag)
> + if (!insert_vlan) {
> vlan_tag = adapter->pvid;
> + insert_vlan = true;
> + }
> /* f/w workaround to set skip_hw_vlan = 1, informs the F/W to
> * skip VLAN insertion
> */
> BE_WRB_F_SET(wrb_params->features, VLAN_SKIP_HW, 1);
> }
>
> - if (vlan_tag) {
> + if (insert_vlan) {
> skb = vlan_insert_tag_set_proto(skb, htons(ETH_P_8021Q),
> vlan_tag);
> if (unlikely(!skb))
> return skb;
> - skb->vlan_tci = 0;
> + __vlan_hwaccel_clear_tag(skb);
> }
>
> /* Insert the outer VLAN, if any */
> --
> 2.11.0
>
Thanks
Acked-by: Somnath Kotur <somnath.kotur@broadcom.com>
^ permalink raw reply
* Re: [RFC PATCH] tcp: accept RST for rcv_nxt - 1 after receiving a FIN
From: Christoph Paasch @ 2017-01-11 5:17 UTC (permalink / raw)
To: Jason Baron; +Cc: netdev
In-Reply-To: <1483652008-20255-1-git-send-email-jbaron@akamai.com>
Hello Jason,
(resending as Gmail sent out with HTML)
On 05/01/17 - 16:33:28, Jason Baron wrote:
> Using a Mac OSX box as a client connecting to a Linux server, we have found
> that when certain applications (such as 'ab'), are abruptly terminated
> (via ^C), a FIN is sent followed by a RST packet on tcp connections. The
> FIN is accepted by the Linux stack but the RST is sent with the same
> sequence number as the FIN, and Linux responds with a challenge ACK per
> RFC 5961. The OSX client then does not reply with any RST as would be
> expected on a closed socket.
do you see this behavior consistently, even in a controlled environment?
The problem seems rather to be that after the first RST, the NAT on the path
has dropped its mapping and is thus dropping all other traffic. So, Linux's
challenge-ack does not go through to the OSX-host to "re-synchronize" the
state (which would allow OSX to send a RST with the updated sequence numbers).
This is also documented in RFC5961:
9.3. Middleboxes That Drop the Challenge ACK
It also needs to be noted that, some middleboxes (Firewalls/NATs)
that don't have the fix recommended in the document, may drop the
challenge ACK. This can happen because, the original RST segment
that was in window had already cleared the flow state pertaining to
the TCP connection in the middlebox. In such cases, the end hosts
that have implemented the RST mitigation described in this document,
will have the TCP connection left open. This is a corner case and
can go away if the middlebox is conformant with the changes proposed
in this document.
Cheers,
Christoph
>
> This results in sockets accumulating on the Linux server left mostly in
> the CLOSE_WAIT state, although LAST_ACK and CLOSING are also possible.
> This sequence of events can tie up a lot of resources on the Linux server
> since there may be a lot of data in write buffers at the time of the RST.
> Accepting a RST equal to rcv_nxt - 1, after we have already successfully
> processed a FIN, has made a significant difference for us in practice, by
> freeing up unneeded resources in a more expedient fashion.
>
> I also found a posting that the iOS client behaves in a similar manner here
> (it will send a FIN followed by a RST for rcv_nxt - 1):
> https://www.snellman.net/blog/archive/2016-02-01-tcp-rst/
>
> A packetdrill test demonstrating the behavior.
>
> // testing mac osx rst behavior
>
> // Establish a connection
> 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> 0.000 bind(3, ..., ...) = 0
> 0.000 listen(3, 1) = 0
>
> 0.100 < S 0:0(0) win 32768 <mss 1460,nop,wscale 10>
> 0.100 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 5>
> 0.200 < . 1:1(0) ack 1 win 32768
> 0.200 accept(3, ..., ...) = 4
>
> // Client closes the connection
> 0.300 < F. 1:1(0) ack 1 win 32768
>
> // now send rst with same sequence
> 0.300 < R. 1:1(0) ack 1 win 32768
>
> // make sure we are in TCP_CLOSE
> 0.400 %{
> assert tcpi_state == 7
> }%
>
> Signed-off-by: Jason Baron <jbaron@akamai.com>
> ---
> net/ipv4/tcp_input.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index ec6d84363024..373bea05c93b 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -5249,6 +5249,24 @@ static int tcp_copy_to_iovec(struct sock *sk, struct sk_buff *skb, int hlen)
> return err;
> }
>
> +/* Accept RST for rcv_nxt - 1 after a FIN.
> + * When tcp connections are abruptly terminated from Mac OSX (via ^C), a
> + * FIN is sent followed by a RST packet. The RST is sent with the same
> + * sequence number as the FIN, and thus according to RFC 5961 a challenge
> + * ACK should be sent. However, Mac OSX does not reply to the challenge ACK
> + * with a RST on the closed socket, hence accept this class of RSTs.
> + */
> +static bool tcp_reset_check(struct sock *sk, struct sk_buff *skb)
> +{
> + struct tcp_sock *tp = tcp_sk(sk);
> +
> + return unlikely((TCP_SKB_CB(skb)->seq == (tp->rcv_nxt - 1)) &&
> + (TCP_SKB_CB(skb)->end_seq == (tp->rcv_nxt - 1)) &&
> + (sk->sk_state == TCP_CLOSE_WAIT ||
> + sk->sk_state == TCP_LAST_ACK ||
> + sk->sk_state == TCP_CLOSING));
> +}
> +
> /* Does PAWS and seqno based validation of an incoming segment, flags will
> * play significant role here.
> */
> @@ -5287,6 +5305,8 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
> LINUX_MIB_TCPACKSKIPPEDSEQ,
> &tp->last_oow_ack_time))
> tcp_send_dupack(sk, skb);
> + } else if (tcp_reset_check(sk, skb)) {
> + tcp_reset(sk);
> }
> goto discard;
> }
> @@ -5300,7 +5320,8 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
> * else
> * Send a challenge ACK
> */
> - if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt) {
> + if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt ||
> + tcp_reset_check(sk, skb)) {
> rst_seq_match = true;
> } else if (tcp_is_sack(tp) && tp->rx_opt.num_sacks > 0) {
> struct tcp_sack_block *sp = &tp->selective_acks[0];
> --
> 2.6.1
>
^ permalink raw reply
* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: Jie Deng @ 2017-01-11 4:00 UTC (permalink / raw)
To: Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, alexandre.torgue, netdev,
CARLOS.PALMINHA
In-Reply-To: <c74e6665ca14a4ca03b38cd3442ef0644d9e250d.1484059674.git.jpinto@synopsys.com>
Hi Joao,
On 2017/1/10 22:52, Joao Pinto wrote:
> This patch renames stmicro/stmmac to synopsys/ since it is a standard
> ethernet software package regarding synopsys ethernet controllers, supporting
> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
> retro-compatibility, only the description was changed.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> ---
> changes v1->v2:
> - nothing changed. Just to keep up with patch set version
>
> @@ -1,5 +1,5 @@
> config STMMAC_ETH
> - tristate "STMicroelectronics 10/100/1000 Ethernet driver"
> + tristate "Synopsys Ethernet drivers"
> depends on HAS_IOMEM && HAS_DMA
> select MII
> select PHYLIB
> @@ -14,7 +14,7 @@ config STMMAC_ETH
> if STMMAC_ETH
>
"Synopsys Ethernet drivers" is too generic. The name should reflect the
controller. This driver is for Synopsys GMAC 10M/100M/1G IPs. We will submit a
driver for the new 25G/40G/50G/100G XLGMAC IP in the future.
> config STMMAC_PLATFORM
> - tristate "STMMAC Platform bus support"
> + tristate "Platform bus support"
> depends on STMMAC_ETH
> select MFD_SYSCON
> default y
> @@ -149,13 +149,13 @@ config DWMAC_SUNXI
> endif
>
> config STMMAC_PCI
> - tristate "STMMAC PCI bus support"
> + tristate "PCI bus support"
> depends on STMMAC_ETH && PCI
> ---help---
> This is to select the Synopsys DWMAC available on PCI devices,
> if you have a controller with this interface, say Y or M here.
>
> - This PCI support is tested on XLINX XC2V3000 FF1152AMT0221
> + This PCI support was tested on XLINX XC2V3000 FF1152AMT0221
> D1215994A VIRTEX FPGA board.
The name is also too generic. Please try to reflect the controller.
Thanks,
Jie
^ permalink raw reply
* [PATCH net] gro: use min_t() in skb_gro_reset_offset()
From: Eric Dumazet @ 2017-01-11 3:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, herbert, slavash, willemb, edumazet
In-Reply-To: <20170110.212911.71346127320993214.davem@davemloft.net>
From: Eric Dumazet <edumazet@google.com>
On 32bit arches, (skb->end - skb->data) is not 'unsigned int',
so we shall use min_t() instead of min() to avoid a compiler error.
Fixes: 1272ce87fa01 ("gro: Enter slow-path if there is no tailroom")
Reported-by: kernel test robot <fengguang.wu@intel.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/dev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 88d2907ca2cda3438a7a1c0c179051a5038aa1e1..07b307b0b414730688b64fdb2295b0fa1b721e51 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4441,8 +4441,9 @@ static void skb_gro_reset_offset(struct sk_buff *skb)
pinfo->nr_frags &&
!PageHighMem(skb_frag_page(frag0))) {
NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
- NAPI_GRO_CB(skb)->frag0_len = min(skb_frag_size(frag0),
- skb->end - skb->tail);
+ NAPI_GRO_CB(skb)->frag0_len = min_t(unsigned int,
+ skb_frag_size(frag0),
+ skb->end - skb->tail);
}
}
^ permalink raw reply related
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Jason Wang @ 2017-01-11 3:37 UTC (permalink / raw)
To: Michael S. Tsirkin, John Fastabend
Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170110065056-mutt-send-email-mst@kernel.org>
On 2017年01月10日 13:00, Michael S. Tsirkin wrote:
> On Mon, Jan 09, 2017 at 08:25:43PM -0800, John Fastabend wrote:
>> On 17-01-09 07:55 PM, Michael S. Tsirkin wrote:
>>> On Mon, Jan 09, 2017 at 07:30:34PM -0800, John Fastabend wrote:
>>>> On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
>>>>> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>>>>>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
>>>>>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
>>>>>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
>>>>>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
>>>>>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>>>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>>>>>>>>>>>>>> program load and does not block MTU changes after the program
>>>>>>>>>>>>>>>>> has loaded.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>>>>>>>>>>>>>> needs to read the mtu via
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> virtio_cread16(vdev, ...)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or we may break the negotiated mtu.
>>>>>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>>>>>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
>>>>>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
>>>>>>>>>>>>> after init time even without XDP which I assume should ideally result in a
>>>>>>>>>>>>> notification if the MTU is negotiated.
>>>>>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
>>>>>>>>>>>> MTU change in this case?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>> Why does host care?
>>>>>>>>>>>
>>>>>>>>>> Well the guest will drop packets after mtu has been reduced.
>>>>>>>>> I didn't know. What place in code does this?
>>>>>>>>>
>>>>>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
>>>>>>>> buffer sizes and a receive side max length filter. For example in the Intel
>>>>>>>> drivers if a packet with length greater than MTU + some headroom is received we
>>>>>>>> drop it. I guess in the networking stack RX path though nothing forces this and
>>>>>>>> virtio doesn't have any code to drop packets on rx size.
>>>>>>>>
>>>>>>>> In virtio I don't see any existing case currently. In the XDP case though we
>>>>>>>> need to ensure packets fit in a page for the time being which is why I was
>>>>>>>> looking at this code and generated this patch.
>>>>>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
>>>>>>>
>>>>>>>
>>>>>> Does this work for small buffers consider it always allocate skb with size
>>>>>> of GOOD_PACKET_LEN?
>>>>> Spec says hardware won't send in packets > max mtu in config space.
>>>>>
>>>>>> I think in any case, we should limit max_mtu to
>>>>>> GOOD_PACKET_LEN for small buffers.
>>>>>>
>>>>>> Thanks
>>>>> XDP seems to have a bunch of weird restrictions, I just
>>>>> do not like it that the logic spills out to all drivers.
>>>>> What if someone decides to extend it to two pages in the future?
>>>>> Recode it all in all drivers ...
>>>>>
>>>>> Why can't net core enforce mtu?
>>>>>
>>>> OK I agree I'll put most the logic in rtnetlink.c when the program is added
>>>> or removed.
>>>>
>>>> But, I'm looking at the non-XDP receive_small path now and wondering how does
>>>> multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?)
>>> I don't understand the question. Look at add_recvbuf_small,
>>> it adds a tiny buffer for head and then the skb.
>>>
>> Specifically this seems to fail with mergeable buffers disabled
>>
>> On the host:
>>
>> # ip link set dev tap0 mtu 9000
>> # ping 22.2 -s 2048
>>
>> On the guest:
>>
>> # insmod ./drivers/net/virtio_net.ko
>> # ip link set dev eth0 mtu 9000
> Why would it work? You are sending a packet larger than ethernet MTU.
Ok, does it mean virtio-net does not support Jumbo frame? And if it
can't work, use MAX_MTU as max_mtu is a bug to me.
>
>> With mergeable buffers enabled no problems it works as I expect at least.
> We don't expect to get these packets but
> mergeable is able to process them anyway.
> It's an accident:)
>
But path MTU discovery indeed benefits from this "accident".
Thanks
^ permalink raw reply
* [PATCH v2] net: netcp: correct netcp_get_stats function signature
From: Keerthy @ 2017-01-11 3:33 UTC (permalink / raw)
To: w-kwok2, m-karicheri2
Cc: netdev, linux-kernel, stephen, m-scherban, j-keerthy
Commit: bc1f44709cf2 - net: make ndo_get_stats64 a void function
and
Commit: 6a8162e99ef3 - net: netcp: store network statistics in 64 bits.
The commit 6a8162e99ef3 adds ndo_get_stats64 function as per old
signature which causes compilation error:
drivers/net/ethernet/ti/netcp_core.c:1951:28: error:
initialization from incompatible pointer type
.ndo_get_stats64 = netcp_get_stats,
Hence correct netcp_get_stats function signature as per
the latest definition.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Fixes: 6a8162e99ef344fc("net: netcp: store network statistics in 64 bits")
---
Changes in v2:
* Added the static in the function definition.
This is due patches crossing at the same time.
Fixes the compilation error. Only build tested. It would be
good if someone can boot test.
Applies on top of latest next branch.
drivers/net/ethernet/ti/netcp_core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 68a75cc..34852f2 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1909,7 +1909,7 @@ static int netcp_setup_tc(struct net_device *dev, u32 handle, __be16 proto,
return 0;
}
-static struct rtnl_link_stats64 *
+static void
netcp_get_stats(struct net_device *ndev, struct rtnl_link_stats64 *stats)
{
struct netcp_intf *netcp = netdev_priv(ndev);
@@ -1938,8 +1938,6 @@ static int netcp_setup_tc(struct net_device *dev, u32 handle, __be16 proto,
stats->rx_errors = p->rx_errors;
stats->rx_dropped = p->rx_dropped;
stats->tx_dropped = p->tx_dropped;
-
- return stats;
}
static const struct net_device_ops netcp_netdev_ops = {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] net: netcp: correct netcp_get_stats function signature
From: Keerthy @ 2017-01-11 3:28 UTC (permalink / raw)
To: David Miller
Cc: w-kwok2, m-karicheri2, netdev, linux-kernel, stephen, m-scherban
In-Reply-To: <20170110.115213.1856085394233309828.davem@davemloft.net>
On Tuesday 10 January 2017 10:22 PM, David Miller wrote:
> From: Keerthy <j-keerthy@ti.com>
> Date: Tue, 10 Jan 2017 16:56:25 +0530
>
>> @@ -1909,7 +1909,7 @@ static int netcp_setup_tc(struct net_device *dev, u32 handle, __be16 proto,
>> return 0;
>> }
>>
>> -static struct rtnl_link_stats64 *
>> +void
>> netcp_get_stats(struct net_device *ndev, struct rtnl_link_stats64 *stats)
>
> Please do not remove the static qualifier.
Sure. I will add that back.
>
^ permalink raw reply
* [net:master 16/18] net/core/dev.c:4444:33: note: in expansion of macro 'min'
From: kbuild test robot @ 2017-01-11 3:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: kbuild-all, netdev, Eric Dumazet
[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
head: 6c711c8691bf91d0e830ff4215b08e51c0626769
commit: 1272ce87fa017ca4cf32920764d879656b7a005a [16/18] gro: Enter slow-path if there is no tailroom
config: i386-randconfig-x004-201702 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 1272ce87fa017ca4cf32920764d879656b7a005a
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/sched.h:17:0,
from include/linux/uaccess.h:4,
from net/core/dev.c:75:
net/core/dev.c: In function 'skb_gro_reset_offset':
include/linux/kernel.h:753:16: warning: comparison of distinct pointer types lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:756:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^~~~~
>> net/core/dev.c:4444:33: note: in expansion of macro 'min'
NAPI_GRO_CB(skb)->frag0_len = min(skb_frag_size(frag0),
^~~
vim +/min +4444 net/core/dev.c
4428 }
4429 }
4430
4431 static void skb_gro_reset_offset(struct sk_buff *skb)
4432 {
4433 const struct skb_shared_info *pinfo = skb_shinfo(skb);
4434 const skb_frag_t *frag0 = &pinfo->frags[0];
4435
4436 NAPI_GRO_CB(skb)->data_offset = 0;
4437 NAPI_GRO_CB(skb)->frag0 = NULL;
4438 NAPI_GRO_CB(skb)->frag0_len = 0;
4439
4440 if (skb_mac_header(skb) == skb_tail_pointer(skb) &&
4441 pinfo->nr_frags &&
4442 !PageHighMem(skb_frag_page(frag0))) {
4443 NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
> 4444 NAPI_GRO_CB(skb)->frag0_len = min(skb_frag_size(frag0),
4445 skb->end - skb->tail);
4446 }
4447 }
4448
4449 static void gro_pull_from_frag0(struct sk_buff *skb, int grow)
4450 {
4451 struct skb_shared_info *pinfo = skb_shinfo(skb);
4452
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29102 bytes --]
^ permalink raw reply
* Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256
From: Andy Lutomirski @ 2017-01-11 3:11 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Andy Lutomirski, Netdev, LKML, Linux Crypto Mailing List,
Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Alexei Starovoitov
In-Reply-To: <58758169.2020408@iogearbox.net>
On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 01/11/2017 12:24 AM, Andy Lutomirski wrote:
>>
>> This makes it easier to add another digest algorithm down the road if
>> needed. It also serves to force any programs that might have been
>> written against a kernel that had the old field name to notice the
>> change and make any necessary changes.
>>
>> This shouldn't violate any stable API policies, as no released kernel
>> has ever had TCA*BPF_DIGEST.
>
>
> Imho, this and patch 6/8 is not really needed. Should there ever
> another digest alg be used (doubt it), then you'd need a new nl
> attribute and fdinfo line anyway to keep existing stuff intact.
> Nobody made the claim that you can just change this underneath
> and not respecting abi for existing applications when I read from
> above that such apps now will get "forced" to notice a change.
Fair enough. I was more concerned about prerelease iproute2 versions,
but maybe that's a nonissue. I'll drop these two patches.
--Andy
^ permalink raw reply
* Re: linux-next: build failure after merge of the selinux tree
From: Paul Moore @ 2017-01-11 3:11 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, linux-next, linux-kernel, Ursula Braun,
Stephen Smalley
In-Reply-To: <20170110122703.2dbdfd18@canb.auug.org.au>
On Mon, Jan 9, 2017 at 8:27 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Paul,
>
> After merging the selinux tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from /home/sfr/next/next/security/selinux/avc.c:35:0:
> /home/sfr/next/next/security/selinux/include/classmap.h:242:2: error: #error New address family defined, please update secclass_map.
> #error New address family defined, please update secclass_map.
> ^
> /home/sfr/next/next/security/selinux/hooks.c: In function 'socket_type_to_security_class':
> /home/sfr/next/next/security/selinux/hooks.c:1409:2: error: #error New address family defined, please update this function.
>
> Caused by commit
>
> da69a5306ab9 ("selinux: support distinctions among all network address families")
>
> interacting with commit
>
> ac7138746e14 ("smc: establish new socket family")
>
> from the net-next tree.
>
> I added the following merge fix patch:
Thanks Stephen.
There are still some concerns around which protocol/address families
require their own SELinux object class, but it looks like SMC should
have it's own object class. If the "selinux: support distinctions
among all network address families" commit doesn't go up to Linus
during the next merge window I'll make sure it is updated for PF_SMC.
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 10 Jan 2017 12:22:21 +1100
> Subject: [PATCH] selinux: merge fix for "smc: establish new socket family"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> security/selinux/hooks.c | 4 +++-
> security/selinux/include/classmap.h | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index bada3cd42b9c..712fd0e7c91d 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1405,7 +1405,9 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
> return SECCLASS_KCM_SOCKET;
> case PF_QIPCRTR:
> return SECCLASS_QIPCRTR_SOCKET;
> -#if PF_MAX > 43
> + case PF_SMC:
> + return SECCLASS_SMC_SOCKET;
> +#if PF_MAX > 44
> #error New address family defined, please update this function.
> #endif
> }
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index 0dfd26d0b8d8..40f1d4f8bc2a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -235,9 +235,11 @@ struct security_class_mapping secclass_map[] = {
> { COMMON_SOCK_PERMS, NULL } },
> { "qipcrtr_socket",
> { COMMON_SOCK_PERMS, NULL } },
> + { "smc_socket",
> + { COMMON_SOCK_PERMS, NULL } },
> { NULL }
> };
>
> -#if PF_MAX > 43
> +#if PF_MAX > 44
> #error New address family defined, please update secclass_map.
> #endif
> --
> 2.10.2
>
> --
> Cheers,
> Stephen Rothwell
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net 00/10] Mellanox mlx5 fixes and cleanups 2017-01-10
From: David Miller @ 2017-01-11 2:35 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 10 Jan 2017 22:33:29 +0200
> This series includes some mlx5e general cleanups from Daniel, Gil, Hadar
> and myself.
> Also it includes some critical mlx5e TC offloads fixes from Or Gerlitz.
Series applied, thanks.
> For -stable:
> - net/mlx5e: Remove WARN_ONCE from adaptive moderation code
>
> Although this fix doesn't affect any functionality, I thought it is
> better to clean this -WARN_ONCE- up for -stable in case someone hits
> such corner case.
Queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] gro: Disable frag0 optimization on IPv6 ext headers
From: David Miller @ 2017-01-11 2:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, herbert, slavash, willemb, edumazet
In-Reply-To: <1484079855.21472.36.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Jan 2017 12:24:15 -0800
> From: Herbert Xu <herbert@gondor.apana.org.au>
>
> The GRO fast path caches the frag0 address. This address becomes
> invalid if frag0 is modified by pskb_may_pull or its variants.
> So whenever that happens we must disable the frag0 optimization.
>
> This is usually done through the combination of gro_header_hard
> and gro_header_slow, however, the IPv6 extension header path did
> the pulling directly and would continue to use the GRO fast path
> incorrectly.
>
> This patch fixes it by disabling the fast path when we enter the
> IPv6 extension header path.
>
> Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual address")
> Reported-by: Slava Shwartsman <slavash@mellanox.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] gro: Enter slow-path if there is no tailroom
From: David Miller @ 2017-01-11 2:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, herbert, slavash, willemb, edumazet
In-Reply-To: <1484079841.21472.35.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Jan 2017 12:24:01 -0800
> From: Herbert Xu <herbert@gondor.apana.org.au>
>
> The GRO path has a fast-path where we avoid calling pskb_may_pull
> and pskb_expand by directly accessing frag0. However, this should
> only be done if we have enough tailroom in the skb as otherwise
> we'll have to expand it later anyway.
>
> This patch adds the check by capping frag0_len with the skb tailroom.
>
> Fixes: cb18978cbf45 ("gro: Open-code final pskb_may_pull")
> Reported-by: Slava Shwartsman <slavash@mellanox.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next 5/8] net: dsa: Export dev_to_net_device()
From: David Miller @ 2017-01-11 2:24 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, jason, andrew, sebastian.hesselbarth, gregory.clement,
linux, vivien.didelot, tremyfr, schwidefsky, gregkh, stuart.yoder,
ingo.tuchscherer, linux-arm-kernel, linux-kernel
In-Reply-To: <20170110201235.21771-6-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 10 Jan 2017 12:12:32 -0800
> @@ -491,7 +491,7 @@ struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(dsa_host_dev_to_mii_bus);
>
> -static struct net_device *dev_to_net_device(struct device *dev)
> +struct net_device *dev_to_net_device(struct device *dev)
> {
> struct device *d;
>
> @@ -508,6 +508,7 @@ static struct net_device *dev_to_net_device(struct device *dev)
>
> return NULL;
> }
> +EXPORT_SYMBOL_GPL(dev_to_net_device);
Something like this, a public interface with a very high level generic name,
doesn't belong in the DSA layer. It belongs in net/core/dev.c or something
like that.
^ permalink raw reply
* Re: [PATCH net v2] mlx4: Return EOPNOTSUPP instead of ENOTSUPP
From: David Miller @ 2017-01-11 2:17 UTC (permalink / raw)
To: kafai; +Cc: netdev, saeedm, tariqt, kernel-team
In-Reply-To: <1484070109-105991-1-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Tue, 10 Jan 2017 09:41:49 -0800
> In commit b45f0674b997 ("mlx4: xdp: Allow raising MTU up to one page minus eth and vlan hdrs"),
> it changed EOPNOTSUPP to ENOTSUPP by mistake. This patch fixes it.
>
> Fixes: b45f0674b997 ("mlx4: xdp: Allow raising MTU up to one page minus eth and vlan hdrs")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Applied.
^ 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