* Re: nfs NULL-dereferencing in net-next
From: Jakub Kicinski @ 2016-10-26 18:08 UTC (permalink / raw)
To: Anna Schumaker
Cc: Yotam Gigi, Andy Adamson, linux-nfs@vger.kernel.org,
netdev@vger.kernel.org, Trond Myklebust, Yotam Gigi, mlxsw
In-Reply-To: <DB3PR05MB0764B39F6EDF851A8A52EBACACAB0@DB3PR05MB0764.eurprd05.prod.outlook.com>
On Wed, 26 Oct 2016 16:15:24 +0000, Yotam Gigi wrote:
> >-----Original Message-----
> >From: Anna Schumaker [mailto:Anna.Schumaker@Netapp.com]
> >Sent: Wednesday, October 26, 2016 5:40 PM
> >To: Yotam Gigi <yotamg@mellanox.com>; Jakub Kicinski <kubakici@wp.pl>; Andy
> >Adamson <andros@netapp.com>; Anna Schumaker
> ><Anna.Schumaker@Netapp.com>; linux-nfs@vger.kernel.org
> >Cc: netdev@vger.kernel.org; Trond Myklebust <Trond.Myklebust@netapp.com>;
> >Yotam Gigi <yotam.gi@gmail.com>; mlxsw <mlxsw@mellanox.com>
> >Subject: Re: nfs NULL-dereferencing in net-next
> >
> >On 10/25/2016 01:19 PM, Yotam Gigi wrote:
> >>
> >>> -----Original Message-----
> >>> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> >On
> >>> Behalf Of Jakub Kicinski
> >>> Sent: Monday, October 17, 2016 10:20 PM
> >>> To: Andy Adamson <andros@netapp.com>; Anna Schumaker
> >>> <Anna.Schumaker@Netapp.com>; linux-nfs@vger.kernel.org
> >>> Cc: netdev@vger.kernel.org; Trond Myklebust
> ><Trond.Myklebust@netapp.com>
> >>> Subject: nfs NULL-dereferencing in net-next
> >>>
> >>> Hi!
> >>>
> >>> I'm hitting this reliably on net-next, HEAD at 3f3177bb680f
> >>> ("fsl/fman: fix error return code in mac_probe()").
> >>
> >>
> >> I see the same thing. It happens constantly on some of my machines, making
> >them
> >> completely unusable.
> >>
> >> I bisected it and got to the commit:
> >>
> >> commit 04ea1b3e6d8ed4978bb608c1748530af3de8c274
> >> Author: Andy Adamson <andros@netapp.com>
> >> Date: Fri Sep 9 09:22:27 2016 -0400
> >>
> >> NFS add xprt switch addrs test to match client
> >>
> >> Signed-off-by: Andy Adamson <andros@netapp.com>
> >> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
> >
> >Thanks for reporting on this everyone! Does this patch help?
>
> Actually, I still see the same bug with the same trace.
I rebuild the latest net-next and I'm not seeing the trace any more...
I'm only seeing this (with or without your patch):
[ 23.465877] NFS: set_pnfs_layoutdriver: cl_exchange_flags 0x0
[ 23.473784] NFS: set_pnfs_layoutdriver: cl_exchange_flags 0x0
[ 23.588890] NFS: set_pnfs_layoutdriver: cl_exchange_flags 0x0
[ 23.596746] NFS: set_pnfs_layoutdriver: cl_exchange_flags 0x0
[ 23.781574] NFS: set_pnfs_layoutdriver: cl_exchange_flags 0x0
[ 23.789599] NFS: set_pnfs_layoutdriver: cl_exchange_flags 0x0
HTH
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Fetch the phy connection type from DT
From: Florian Fainelli @ 2016-10-26 18:05 UTC (permalink / raw)
To: Jason Gunthorpe, Sebastian Hesselbarth; +Cc: devicetree, netdev
In-Reply-To: <20161026174702.GB24717@obsidianresearch.com>
On 10/26/2016 10:47 AM, Jason Gunthorpe wrote:
> The MAC is capable of RGMII mode and that is probably a more typical
> connection type than GMII today (eg it is used by Marvell Reference
> designs for several SOCs). Let DT users specify the standard
>
> phy-connection-type = "rgmii-id";
>
> On a phy node.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Took a little while to understand the re-ordering of SET_NETDEV_DEV() to
come earlier was necessary to access mp->dev->dev.parent.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH] net: bonding: use new api ethtool_{get|set}_link_ksettings
From: Jay Vosburgh @ 2016-10-26 18:00 UTC (permalink / raw)
To: Philippe Reynes; +Cc: vfalico, andy, davem, netdev, linux-kernel
In-Reply-To: <1477413691-10894-1-git-send-email-tremyfr@gmail.com>
Philippe Reynes <tremyfr@gmail.com> wrote:
>The ethtool api {get|set}_settings is deprecated.
>We move this driver to new api {get|set}_link_ksettings.
This is just an API change, i.e., no change to functionality?
-J
>Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
>---
> drivers/net/bonding/bond_main.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index c9944d8..5708f17 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -4080,16 +4080,16 @@ static netdev_tx_t bond_start_xmit(struct sk_buff *skb, struct net_device *dev)
> return ret;
> }
>
>-static int bond_ethtool_get_settings(struct net_device *bond_dev,
>- struct ethtool_cmd *ecmd)
>+static int bond_ethtool_get_link_ksettings(struct net_device *bond_dev,
>+ struct ethtool_link_ksettings *cmd)
> {
> struct bonding *bond = netdev_priv(bond_dev);
> unsigned long speed = 0;
> struct list_head *iter;
> struct slave *slave;
>
>- ecmd->duplex = DUPLEX_UNKNOWN;
>- ecmd->port = PORT_OTHER;
>+ cmd->base.duplex = DUPLEX_UNKNOWN;
>+ cmd->base.port = PORT_OTHER;
>
> /* Since bond_slave_can_tx returns false for all inactive or down slaves, we
> * do not need to check mode. Though link speed might not represent
>@@ -4100,12 +4100,12 @@ static int bond_ethtool_get_settings(struct net_device *bond_dev,
> if (bond_slave_can_tx(slave)) {
> if (slave->speed != SPEED_UNKNOWN)
> speed += slave->speed;
>- if (ecmd->duplex == DUPLEX_UNKNOWN &&
>+ if (cmd->base.duplex == DUPLEX_UNKNOWN &&
> slave->duplex != DUPLEX_UNKNOWN)
>- ecmd->duplex = slave->duplex;
>+ cmd->base.duplex = slave->duplex;
> }
> }
>- ethtool_cmd_speed_set(ecmd, speed ? : SPEED_UNKNOWN);
>+ cmd->base.speed = speed ? : SPEED_UNKNOWN;
>
> return 0;
> }
>@@ -4121,8 +4121,8 @@ static void bond_ethtool_get_drvinfo(struct net_device *bond_dev,
>
> static const struct ethtool_ops bond_ethtool_ops = {
> .get_drvinfo = bond_ethtool_get_drvinfo,
>- .get_settings = bond_ethtool_get_settings,
> .get_link = ethtool_op_get_link,
>+ .get_link_ksettings = bond_ethtool_get_link_ksettings,
> };
>
> static const struct net_device_ops bond_netdev_ops = {
>--
>1.7.4.4
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH iproute2 2/2] tc filters: fix filters to display handle when deleted even when no option
From: Stephen Hemminger @ 2016-10-26 17:57 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, daniel, xiyou.wangcong, mrv
In-Reply-To: <1476696885-22214-2-git-send-email-jhs@emojatatu.com>
On Mon, 17 Oct 2016 05:34:45 -0400
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> Fix a few stylistic things that hurt my eyes while at it.
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
This patch has whitespace issues, please fix and resubmit.
ARNING: suspect code indent for conditional statements (16, 19)
#127: FILE: tc/f_fw.c:126:
+ if (tb[TCA_FW_MASK]) {
+ __u32 tmask = rta_getattr_u32(tb[TCA_FW_MASK]);
WARNING: Statements should start on a tabstop
#131: FILE: tc/f_fw.c:129:
+ if (tmask != 0xFFFFFFFF)
WARNING: suspect code indent for conditional statements (19, 27)
#131: FILE: tc/f_fw.c:129:
+ if (tmask != 0xFFFFFFFF)
+ mask = tmask;
^ permalink raw reply
* [PATCH] i40e: fix panic on SPARC while changing num of desc
From: Tushar Dave @ 2016-10-26 17:49 UTC (permalink / raw)
To: jeffrey.t.kirsher, intel-wired-lan, netdev, jesse.brandeburg
On SPARC, writel() should not be used to write directly to memory
address but only to memory mapped I/O address otherwise it causes
data access exception.
Commit 147e81ec75689 ("i40e: Test memory before ethtool alloc
succeeds") introduced a code that uses memory address to fake the HW
tail address and attempt to write to that address using writel()
causes kernel panic on SPARC. The issue is reproduced while changing
number of descriptors using ethtool.
This change resolves the panic by using HW read-only memory mapped
I/O register to fake HW tail address instead memory address.
e.g.
> ethtool -G eth2 tx 2048 rx 2048
i40e 0000:03:00.2 eth2: Changing Tx descriptor count from 512 to 2048.
i40e 0000:03:00.2 eth2: Changing Rx descriptor count from 512 to 2048
sun4v_data_access_exception: ADDR[fff8001f9734a000] CTX[0000]
TYPE[0004], going.
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
ethtool(3273): Dax [#1]
CPU: 9 PID: 3273 Comm: ethtool Tainted: G E
4.8.0-linux-net_temp+ #7
task: fff8001f96d7a660 task.stack: fff8001f97348000
TSTATE: 0000009911001601 TPC: 00000000103189e4 TNPC: 00000000103189e8 Y:
00000000 Tainted: G E
TPC: <i40e_alloc_rx_buffers+0x124/0x260 [i40e]>
g0: fff8001f4eb64000 g1: 00000000000007ff g2: fff8001f9734b92c g3:
00203e0000000000
g4: fff8001f96d7a660 g5: fff8001fa6704000 g6: fff8001f97348000 g7:
0000000000000001
o0: 0006000046706928 o1: 00000000db3e2000 o2: fff8001f00000000 o3:
0000000000002000
o4: 0000000000002000 o5: 0000000000000001 sp: fff8001f9734afc1 ret_pc:
0000000010318a64
RPC: <i40e_alloc_rx_buffers+0x1a4/0x260 [i40e]>
l0: fff8001f4e8bffe0 l1: fff8001f4e8cffe0 l2: 00000000000007ff l3:
00000000ff000000
l4: 0000000000ff0000 l5: 000000000000ff00 l6: 0000000000cda6a8 l7:
0000000000e822f0
i0: fff8001f96380000 i1: 0000000000000000 i2: 00203edb00000000 i3:
0006000046706928
i4: 0000000002086320 i5: 0000000000e82370 i6: fff8001f9734b071 i7:
00000000103062d4
I7: <i40e_set_ringparam+0x3b4/0x540 [i40e]>
Call Trace:
[00000000103062d4] i40e_set_ringparam+0x3b4/0x540 [i40e]
[000000000094e2f8] dev_ethtool+0x898/0xbe0
[0000000000965570] dev_ioctl+0x250/0x300
[0000000000923800] sock_do_ioctl+0x40/0x60
[000000000092427c] sock_ioctl+0x7c/0x280
[00000000005ef040] vfs_ioctl+0x20/0x60
[00000000005ef5d4] do_vfs_ioctl+0x194/0x4c0
[00000000005ef974] SyS_ioctl+0x74/0xa0
[0000000000406214] linux_sparc_syscall+0x34/0x44
Disabling lock debugging due to kernel taint
Caller[00000000103062d4]: i40e_set_ringparam+0x3b4/0x540 [i40e]
Caller[000000000094e2f8]: dev_ethtool+0x898/0xbe0
Caller[0000000000965570]: dev_ioctl+0x250/0x300
Caller[0000000000923800]: sock_do_ioctl+0x40/0x60
Caller[000000000092427c]: sock_ioctl+0x7c/0x280
Caller[00000000005ef040]: vfs_ioctl+0x20/0x60
Caller[00000000005ef5d4]: do_vfs_ioctl+0x194/0x4c0
Caller[00000000005ef974]: SyS_ioctl+0x74/0xa0
Caller[0000000000406214]: linux_sparc_syscall+0x34/0x44
Caller[0000000000107154]: 0x107154
Instruction DUMP: e43620c8
e436204a c45e2038
<c2a083a0> 82102000
81cfe008 90086001
82102000 81cfe008
Kernel panic - not syncing: Fatal exception
Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 92bc884..23f4eee 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1219,6 +1219,7 @@ static int i40e_set_ringparam(struct net_device *netdev,
{
struct i40e_ring *tx_rings = NULL, *rx_rings = NULL;
struct i40e_netdev_priv *np = netdev_priv(netdev);
+ struct i40e_hw *hw = &np->vsi->back->hw;
struct i40e_vsi *vsi = np->vsi;
struct i40e_pf *pf = vsi->back;
u32 new_rx_count, new_tx_count;
@@ -1311,10 +1312,6 @@ static int i40e_set_ringparam(struct net_device *netdev,
}
for (i = 0; i < vsi->num_queue_pairs; i++) {
- /* this is to allow wr32 to have something to write to
- * during early allocation of Rx buffers
- */
- u32 __iomem faketail = 0;
struct i40e_ring *ring;
u16 unused;
@@ -1326,7 +1323,10 @@ static int i40e_set_ringparam(struct net_device *netdev,
*/
rx_rings[i].desc = NULL;
rx_rings[i].rx_bi = NULL;
- rx_rings[i].tail = (u8 __iomem *)&faketail;
+ /* this is to allow wr32 to have something to write to
+ * during early allocation of Rx buffers
+ */
+ rx_rings[i].tail = hw->hw_addr + I40E_PRTGEN_STATUS;
err = i40e_setup_rx_descriptors(&rx_rings[i]);
if (err)
goto rx_unwind;
--
1.9.1
^ permalink raw reply related
* [PATCH] net: mv643xx_eth: Fetch the phy connection type from DT
From: Jason Gunthorpe @ 2016-10-26 17:47 UTC (permalink / raw)
To: Sebastian Hesselbarth; +Cc: devicetree, netdev
The MAC is capable of RGMII mode and that is probably a more typical
connection type than GMII today (eg it is used by Marvell Reference
designs for several SOCs). Let DT users specify the standard
phy-connection-type = "rgmii-id";
On a phy node.
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
---
.../devicetree/bindings/net/marvell-orion-net.txt | 1 +
drivers/net/ethernet/marvell/mv643xx_eth.c | 23 ++++++++++++++++++----
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
index bce52b2ec55e..6fd988c84c4f 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-net.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
@@ -49,6 +49,7 @@ Optional port properties:
and
- phy-handle: See ethernet.txt file in the same directory.
+ - phy-mode: See ethernet.txt file in the same directory.
or
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 55831188bc32..bf5cc55ba24c 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2968,6 +2968,22 @@ static void set_params(struct mv643xx_eth_private *mp,
mp->txq_count = pd->tx_queue_count ? : 1;
}
+static int get_phy_mode(struct mv643xx_eth_private *mp)
+{
+ struct device *dev = mp->dev->dev.parent;
+ int iface = -1;
+
+ if (dev->of_node)
+ iface = of_get_phy_mode(dev->of_node);
+
+ /* Historical default if unspecified. We could also read/write
+ * the interface state in the PSC1
+ */
+ if (iface < 0)
+ iface = PHY_INTERFACE_MODE_GMII;
+ return iface;
+}
+
static struct phy_device *phy_scan(struct mv643xx_eth_private *mp,
int phy_addr)
{
@@ -2994,7 +3010,7 @@ static struct phy_device *phy_scan(struct mv643xx_eth_private *mp,
"orion-mdio-mii", addr);
phydev = phy_connect(mp->dev, phy_id, mv643xx_eth_adjust_link,
- PHY_INTERFACE_MODE_GMII);
+ get_phy_mode(mp));
if (!IS_ERR(phydev)) {
phy_addr_set(mp, addr);
break;
@@ -3090,6 +3106,7 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
if (!dev)
return -ENOMEM;
+ SET_NETDEV_DEV(dev, &pdev->dev);
mp = netdev_priv(dev);
platform_set_drvdata(pdev, mp);
@@ -3129,7 +3146,7 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
if (pd->phy_node) {
mp->phy = of_phy_connect(mp->dev, pd->phy_node,
mv643xx_eth_adjust_link, 0,
- PHY_INTERFACE_MODE_GMII);
+ get_phy_mode(mp));
if (!mp->phy)
err = -ENODEV;
else
@@ -3187,8 +3204,6 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
dev->priv_flags |= IFF_UNICAST_FLT;
dev->gso_max_segs = MV643XX_MAX_TSO_SEGS;
- SET_NETDEV_DEV(dev, &pdev->dev);
-
if (mp->shared->win_protect)
wrl(mp, WINDOW_PROTECT(mp->port_num), mp->shared->win_protect);
--
2.1.4
^ permalink raw reply related
* [PATCH net] Revert "hv_netvsc: report vmbus name in ethtool"
From: Stephen Hemminger @ 2016-10-26 15:30 UTC (permalink / raw)
To: David Miller, KY Srinivasan, Vitaly Kuznetsov; +Cc: netdev
From: Stephen Hemminger <sthemmin@microsoft.com>
This reverts commit e3f74b841d48
("hv_netvsc: report vmbus name in ethtool")'
because of problem introduced by commit f9a56e5d6a0ba
("Drivers: hv: make VMBus bus ids persistent").
This changed the format of the vmbus name and this new format is too
long to fit in the bus_info field of ethtool.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
drivers/net/hyperv/netvsc_drv.c | 4 ----
include/linux/hyperv.h | 7 -------
2 files changed, 11 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index c71d966..f638215 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -699,12 +699,8 @@ int netvsc_recv_callback(struct hv_device *device_obj,
static void netvsc_get_drvinfo(struct net_device *net,
struct ethtool_drvinfo *info)
{
- struct net_device_context *net_device_ctx = netdev_priv(net);
- struct hv_device *dev = net_device_ctx->device_ctx;
-
strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
strlcpy(info->fw_version, "N/A", sizeof(info->fw_version));
- strlcpy(info->bus_info, vmbus_dev_name(dev), sizeof(info->bus_info));
}
static void netvsc_get_channels(struct net_device *net,
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 6824556..cd184bd 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1169,13 +1169,6 @@ int __must_check __vmbus_driver_register(struct hv_driver *hv_driver,
const char *mod_name);
void vmbus_driver_unregister(struct hv_driver *hv_driver);
-static inline const char *vmbus_dev_name(const struct hv_device *device_obj)
-{
- const struct kobject *kobj = &device_obj->device.kobj;
-
- return kobj->name;
-}
-
void vmbus_hvsock_device_unregister(struct vmbus_channel *channel);
int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
--
2.9.3
^ permalink raw reply related
* Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing
From: Mickaël Salaün @ 2016-10-26 17:24 UTC (permalink / raw)
To: Jann Horn
Cc: linux-kernel, Alexei Starovoitov, Andy Lutomirski,
Daniel Borkmann, Daniel Mack, David Drysdale, David S . Miller,
Eric W . Biederman, James Morris, Kees Cook, Paul Moore,
Sargun Dhillon, Serge E . Hallyn, Tejun Heo, Thomas Graf,
Will Drewry, kernel-hardening, linux-api, linux-security-module,
netdev, cgroups
In-Reply-To: <5810E04D.9020300@digikod.net>
[-- Attachment #1.1: Type: text/plain, Size: 1751 bytes --]
On 26/10/2016 18:56, Mickaël Salaün wrote:
>
> On 26/10/2016 16:52, Jann Horn wrote:
>> On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
>>> The loaded Landlock eBPF programs can be triggered by a seccomp filter
>>> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed from
>>> a seccomp filter to eBPF programs. This allow flexible security policies
>>> between seccomp and Landlock.
>>
>> Is this still up to date, or was that removed in v3?
>>
>
> I forgot to remove this part. In this v4 series, as describe in the
> (small) patch 11/18, a Landlock rule cannot be triggered by a seccomp
> filter. So there is no more RET_LANDLOCK nor cookie.
>
Here is an up-to-date version:
# Use case scenario
First, a process needs to create a new dedicated eBPF map containing handles.
This handles are references to system resources (e.g. file or directory). They
are grouped in one or multiple maps to be efficiently managed and checked in
batches. This kind of map can be passed to Landlock eBPF functions to compare,
for example, with a file access request.
First, a task need to create or receive a Landlock rule. This rule is a
dedicated eBPF program tied to one of the Landlock hooks, which are a subset of
LSM hooks. Once loaded, a Landlock rule can be enforced through the seccomp(2)
syscall for the current thread and its (future) children, like a seccomp
filter.
Another way to enforce a Landlock security policy is to attach Landlock rules
to a cgroup. All the processes in this cgroup will then be subject to this
policy.
A triggered Landlock eBPF program can allow or deny an access, according to
its subtype (i.e. LSM hook), thanks to errno return values.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [Intel-wired-lan] [net-next PATCH 27/27] igb: Revert "igb: Revert support for build_skb in igb"
From: Jeff Kirsher @ 2016-10-26 17:22 UTC (permalink / raw)
To: Alexander Duyck, netdev, intel-wired-lan, linux-kernel, linux-mm
Cc: davem, brouer
In-Reply-To: <20161025153911.4815.45366.stgit@ahduyck-blue-test.jf.intel.com>
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
On Tue, 2016-10-25 at 11:39 -0400, Alexander Duyck wrote:
> This reverts commit f9d40f6a9921 ("igb: Revert support for build_skb in
> igb") and adds a few changes to update it to work with the latest version
> of igb. We are now able to revert the removal of this due to the fact
> that with the recent changes to the page count and the use of
> DMA_ATTR_SKIP_CPU_SYNC we can make the pages writable so we should not be
> invalidating the additional data added when we call build_skb.
>
> The biggest risk with this change is that we are now not able to support
> full jumbo frames when using build_skb. Instead we can only support up
> to
> 2K minus the skb overhead and padding offset.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Intel-wired-lan] [net-next PATCH 26/27] igb: Update code to better handle incrementing page count
From: Jeff Kirsher @ 2016-10-26 17:21 UTC (permalink / raw)
To: Alexander Duyck, netdev, intel-wired-lan, linux-kernel, linux-mm
Cc: davem, brouer
In-Reply-To: <20161025153906.4815.61652.stgit@ahduyck-blue-test.jf.intel.com>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
On Tue, 2016-10-25 at 11:39 -0400, Alexander Duyck wrote:
> This patch updates the driver code so that we do bulk updates of the page
> reference count instead of just incrementing it by one reference at a
> time.
> The advantage to doing this is that we cut down on atomic operations and
> this in turn should give us a slight improvement in cycles per packet.
> In
> addition if we eventually move this over to using build_skb the gains
> will
> be more noticeable.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Intel-wired-lan] [net-next PATCH 25/27] igb: Update driver to make use of DMA_ATTR_SKIP_CPU_SYNC
From: Jeff Kirsher @ 2016-10-26 17:21 UTC (permalink / raw)
To: Alexander Duyck, netdev, intel-wired-lan, linux-kernel, linux-mm
Cc: davem, brouer
In-Reply-To: <20161025153900.4815.4927.stgit@ahduyck-blue-test.jf.intel.com>
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
On Tue, 2016-10-25 at 11:39 -0400, Alexander Duyck wrote:
> The ARM architecture provides a mechanism for deferring cache line
> invalidation in the case of map/unmap. This patch makes use of this
> mechanism to avoid unnecessary synchronization.
>
> A secondary effect of this change is that the portion of the page that
> has
> been synchronized for use by the CPU should be writable and could be
> passed
> up the stack (at least on ARM).
>
> The last bit that occurred to me is that on architectures where the
> sync_for_cpu call invalidates cache lines we were prefetching and then
> invalidating the first 128 bytes of the packet. To avoid that I have
> moved
> the sync up to before we perform the prefetch and allocate the skbuff so
> that we can actually make use of it.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: iproute: ss truncates abstract unix domain socket embedding null
From: Stephen Hemminger @ 2016-10-26 17:15 UTC (permalink / raw)
To: Isaac Boukris; +Cc: netdev
In-Reply-To: <CAC-fF8SdbDHPMZbOwHg=cOpsy+4ewTq9KGi-Cp=uaaG0hEJ8Fg@mail.gmail.com>
On Tue, 18 Oct 2016 21:46:48 +0300
Isaac Boukris <iboukris@gmail.com> wrote:
> Hi again,
>
> On Sun, Oct 16, 2016 at 11:43 PM, Isaac Boukris <iboukris@gmail.com> wrote:
> > Hello,
> >
> > The unix(7) man page says that null have no special meaning in
> > abstract unix domain socket address (the length is specified
> > therefore).
> >
> > However, when such name (embedding null) is used, ss (and netstat)
> > will only show up to the first null occurrence (second technically, if
> > we count the null prefix).
> > e.g. the name "\0/tmp/fo\0.sock" is displayed as: "@/tmp/fo" (whilst
> > strace tool shows it as: sun_path=@"/tmp/fo\0.sock").
> >
> > Would it be more useful if it printed the whole name and escaped the null?
> > If so, would '\0' be ok for escaping the null?
>
>
> Meanwhile, I've got it to escape the null character with with '\0' as suggested.
> Can anyone take a look and advise if I'm on the right track? Thanks!
I did a little investigation and current ss behavior matches the output
of other commands (netstat and lsof). Therefore I really can't see the motivation
to fix this.
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: David Miller @ 2016-10-26 17:11 UTC (permalink / raw)
To: mst; +Cc: brouer, shrijeet, tom, netdev, shm, roopa, nikolay
In-Reply-To: <20161026200153-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 26 Oct 2016 20:07:19 +0300
> On Wed, Oct 26, 2016 at 12:52:45PM -0400, David Miller wrote:
>> From: "Michael S. Tsirkin" <mst@redhat.com>
>> Date: Wed, 26 Oct 2016 19:36:45 +0300
>>
>> > On Wed, Oct 26, 2016 at 03:52:02PM +0200, Jesper Dangaard Brouer wrote:
>> >> On Sat, 22 Oct 2016 04:07:23 +0000
>> >> Shrijeet Mukherjee <shrijeet@gmail.com> wrote:
>> >>
>> >> > This patch adds support for xdp ndo and also inserts the xdp program
>> >> > call into the merged RX buffers and big buffers paths
>> >>
>> >> I really appreciate you are doing this for virtio_net.
>> >>
>> >> My first question is: Is the (packet) page data writable?
>> >> (MST might be able to answer?)
>> >>
>> >> As this is currently an XDP requirement[1].
>> >
>> > I'm not sure I understand what does writable mean.
>> > Could you explain a bit more pls?
>> > We do copy data into skb ATM but I plan to change that.
>>
>> The packet data area must be writable,
>
> This is the part I don't fully understand.
> It's in RAM so of course it's writeable.
Pages in SKB frag lists are not usually writable, because they share
space with data from other packets the way drivers usually carve up
pages to receive packets into.
It is therefore illegal for the networking code to write into SKB frag
pages.
Pages used for XDP processed packets must not have this restriction.
> We share pages between arbitrary multiple packets. I think that's
> OK
That's exactly what is not allowed with XDP.
Each packet must be the sole user of a page, otherwise the semantics
required by XDP are not met.
^ permalink raw reply
* Re: [PATCH] net: Reset skb to network header in neigh_hh_output
From: Eric Dumazet @ 2016-10-26 17:08 UTC (permalink / raw)
To: Abdelrhman Ahmed; +Cc: davem, netdev, linux-kernel
In-Reply-To: <15801e95765.f826e84d266359.4807464957002677781@abahmed.com>
On Wed, 2016-10-26 at 18:53 +0200, Abdelrhman Ahmed wrote:
> I think it's at the right place as the current one is a little different from the
> commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c.
>
> In the next lines, skb_push is called after copying the hardware header and there
> is no change to the data pointer inside the retry loop. We only need to reset
> before this loop.
>
> __skb_pull(skb, skb_network_offset(skb));
>
> do {
> seq = read_seqbegin(&hh->hh_lock);
> hh_len = hh->hh_len;
> if (likely(hh_len <= HH_DATA_MOD)) {
> /* this is inlined by gcc */
> memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);
> } else {
> int hh_alen = HH_DATA_ALIGN(hh_len);
>
> memcpy(skb->data - hh_alen, hh->hh_data, hh_alen);
> }
> } while (read_seqretry(&hh->hh_lock, seq));
>
> skb_push(skb, hh_len);
>
> In the commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c, dev_hard_header which
> calls create method for adding hardware header (uses skb_push) so it was
> required to reset to network header in the beginning of the retry loop.
Right you are, thanks for the clarification !
Back to the cause of the bug then.
If netfilter is the only case this might be needed, can't this be fixed
in netfilter ?
neigh_hh_output() is in fast path, it is quite annoying adding this
operation.
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Michael S. Tsirkin @ 2016-10-26 17:07 UTC (permalink / raw)
To: David Miller; +Cc: brouer, shrijeet, tom, netdev, shm, roopa, nikolay
In-Reply-To: <20161026.125245.1630138589657247338.davem@davemloft.net>
On Wed, Oct 26, 2016 at 12:52:45PM -0400, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Wed, 26 Oct 2016 19:36:45 +0300
>
> > On Wed, Oct 26, 2016 at 03:52:02PM +0200, Jesper Dangaard Brouer wrote:
> >> On Sat, 22 Oct 2016 04:07:23 +0000
> >> Shrijeet Mukherjee <shrijeet@gmail.com> wrote:
> >>
> >> > This patch adds support for xdp ndo and also inserts the xdp program
> >> > call into the merged RX buffers and big buffers paths
> >>
> >> I really appreciate you are doing this for virtio_net.
> >>
> >> My first question is: Is the (packet) page data writable?
> >> (MST might be able to answer?)
> >>
> >> As this is currently an XDP requirement[1].
> >
> > I'm not sure I understand what does writable mean.
> > Could you explain a bit more pls?
> > We do copy data into skb ATM but I plan to change that.
>
> The packet data area must be writable,
This is the part I don't fully understand.
It's in RAM so of course it's writeable.
> and the page it lives in must
> not be shared with any other entity in the system.
We share pages between arbitrary multiple packets. I think that's
OK - or is there an assumption that multiple programs
will be attached with different priveledges?
> This is because the eBPF program that executes via XDP must be able
> to modify and read arbitrary parts of the packet area.
--
MST
^ permalink raw reply
* Re: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
From: Scott Wood @ 2016-10-26 17:06 UTC (permalink / raw)
To: Yangbo Lu, linux-mmc, ulf.hansson, Arnd Bergmann
Cc: linuxppc-dev, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-i2c, iommu, netdev, Mark Rutland, Rob Herring,
Russell King, Jochen Friedrich, Joerg Roedel, Claudiu Manoil,
Bhupesh Sharma, Qiang Zhao, Kumar Gala, Santosh Shilimkar, Leo Li,
Xiaobo Xie, Minghuan Lian
In-Reply-To: <1474441040-11946-6-git-send-email-yangbo.lu@nxp.com>
On Wed, 2016-09-21 at 14:57 +0800, Yangbo Lu wrote:
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> new file mode 100644
> index 0000000..b99764c
> --- /dev/null
> +++ b/drivers/soc/fsl/Kconfig
> @@ -0,0 +1,19 @@
> +#
> +# Freescale SOC drivers
> +#
> +
> +source "drivers/soc/fsl/qe/Kconfig"
> +
> +config FSL_GUTS
> + bool "Freescale QorIQ GUTS driver"
> + select SOC_BUS
> + help
> + The global utilities block controls power management, I/O device
> + enabling, power-onreset(POR) configuration monitoring, alternate
> + function selection for multiplexed signals,and clock control.
> + This driver is to manage and access global utilities block.
> + Initially only reading SVR and registering soc device are
> supported.
> + Other guts accesses, such as reading RCW, should eventually be
> moved
> + into this driver as well.
> +
> + If you want GUTS driver support, you should say Y here.
This is user-enablable without dependencies, which means it will break some
randconfigs. If this is to be enabled via select then remove the text after
"bool".
> +/* SoC die attribute definition for QorIQ platform */
> +static const struct fsl_soc_die_attr fsl_soc_die[] = {
> +#ifdef CONFIG_PPC
> + /*
> + * Power Architecture-based SoCs T Series
> + */
> +
> + /* Die: T4240, SoC: T4240/T4160/T4080 */
> + { .die = "T4240",
> + .svr = 0x82400000,
> + .mask = 0xfff00000,
> + },
> + /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
> + { .die = "T1040",
> + .svr = 0x85200000,
> + .mask = 0xfff00000,
> + },
> + /* Die: T2080, SoC: T2080/T2081 */
> + { .die = "T2080",
> + .svr = 0x85300000,
> + .mask = 0xfff00000,
> + },
> + /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
> + { .die = "T1024",
> + .svr = 0x85400000,
> + .mask = 0xfff00000,
> + },
> +#endif /* CONFIG_PPC */
> +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)
Will this driver ever be probed on MXC? Why do we need these ifdefs at all?
> + /*
> + * ARM-based SoCs LS Series
> + */
> +
> + /* Die: LS1043A, SoC: LS1043A/LS1023A */
> + { .die = "LS1043A",
> + .svr = 0x87920000,
> + .mask = 0xffff0000,
> + },
> + /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
> + { .die = "LS2080A",
> + .svr = 0x87010000,
> + .mask = 0xff3f0000,
> + },
> + /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
> + { .die = "LS1088A",
> + .svr = 0x87030000,
> + .mask = 0xff3f0000,
> + },
> + /* Die: LS1012A, SoC: LS1012A */
> + { .die = "LS1012A",
> + .svr = 0x87040000,
> + .mask = 0xffff0000,
> + },
> + /* Die: LS1046A, SoC: LS1046A/LS1026A */
> + { .die = "LS1046A",
> + .svr = 0x87070000,
> + .mask = 0xffff0000,
> + },
> + /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
> + { .die = "LS2088A",
> + .svr = 0x87090000,
> + .mask = 0xff3f0000,
> + },
> + /* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A
> + * Note: Put this die at the end in cause of incorrect
> identification
> + */
> + { .die = "LS1021A",
> + .svr = 0x87000000,
> + .mask = 0xfff00000,
> + },
> +#endif /* CONFIG_ARCH_MXC || CONFIG_ARCH_LAYERSCAPE */
Instead of relying on ordering, add more bits to the mask so that there's no
overlap. I think 0xfff70000 would work.
> +out:
> + kfree(soc_dev_attr.machine);
> + kfree(soc_dev_attr.family);
> + kfree(soc_dev_attr.soc_id);
> + kfree(soc_dev_attr.revision);
> + iounmap(guts->regs);
> +out_free:
> + kfree(guts);
> + return ret;
> +}
Please use devm.
-Scott
^ permalink raw reply
* Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing
From: Mickaël Salaün @ 2016-10-26 16:56 UTC (permalink / raw)
To: Jann Horn
Cc: linux-kernel, Alexei Starovoitov, Andy Lutomirski,
Daniel Borkmann, Daniel Mack, David Drysdale, David S . Miller,
Eric W . Biederman, James Morris, Kees Cook, Paul Moore,
Sargun Dhillon, Serge E . Hallyn, Tejun Heo, Thomas Graf,
Will Drewry, kernel-hardening, linux-api, linux-security-module,
netdev, cgroups
In-Reply-To: <20161026145207.GM3334@pc.thejh.net>
[-- Attachment #1.1: Type: text/plain, Size: 640 bytes --]
On 26/10/2016 16:52, Jann Horn wrote:
> On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
>> The loaded Landlock eBPF programs can be triggered by a seccomp filter
>> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed from
>> a seccomp filter to eBPF programs. This allow flexible security policies
>> between seccomp and Landlock.
>
> Is this still up to date, or was that removed in v3?
>
I forgot to remove this part. In this v4 series, as describe in the
(small) patch 11/18, a Landlock rule cannot be triggered by a seccomp
filter. So there is no more RET_LANDLOCK nor cookie.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Reset skb to network header in neigh_hh_output
From: Abdelrhman Ahmed @ 2016-10-26 16:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1477440742.7065.161.camel@edumazet-glaptop3.roam.corp.google.com>
I think it's at the right place as the current one is a little different from the
commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c.
In the next lines, skb_push is called after copying the hardware header and there
is no change to the data pointer inside the retry loop. We only need to reset
before this loop.
__skb_pull(skb, skb_network_offset(skb));
do {
seq = read_seqbegin(&hh->hh_lock);
hh_len = hh->hh_len;
if (likely(hh_len <= HH_DATA_MOD)) {
/* this is inlined by gcc */
memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);
} else {
int hh_alen = HH_DATA_ALIGN(hh_len);
memcpy(skb->data - hh_alen, hh->hh_data, hh_alen);
}
} while (read_seqretry(&hh->hh_lock, seq));
skb_push(skb, hh_len);
In the commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c, dev_hard_header which
calls create method for adding hardware header (uses skb_push) so it was
required to reset to network header in the beginning of the retry loop.
---- On Wed, 26 Oct 2016 02:12:22 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote ----
> On Wed, 2016-10-26 at 01:57 +0200, Abdelrhman Ahmed wrote:
> > > What is the issue you want to fix exactly ?
> > > Please describe the use case.
> >
> > When netfilter hook uses skb_push to add a specific header between network
> > header and hardware header.
> > For the first time(s) before caching hardware header, this header will be
> > removed / overwritten by hardware header due to resetting to network header.
> > After using the cached hardware header, this header will be kept as we do not
> > reset. I think this behavior is inconsistent, so we need to reset in both cases.
> >
> > > Otherwise, your fix is in fact adding a critical bug.
> >
> > Could you explain more as it's not clear to me?
> >
>
> Maybe my wording was not good here.
>
> What I intended to say is that the
> __skb_pull(skb, skb_network_offset(skb)) might not be at the right
> place.
>
> Look at commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c to find the
> reason.
>
>
> >
> >
> > ---- On Fri, 07 Oct 2016 23:10:56 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote ----
> > > On Fri, 2016-10-07 at 16:14 +0200, Abdelrhman Ahmed wrote:
> > > > When hardware header is added without using cached one, neigh_resolve_output
> > > > and neigh_connected_output reset skb to network header before adding it.
> > > > When cached one is used, neigh_hh_output does not reset the skb to network
> > > > header.
> > > >
> > > > The fix is to reset skb to network header before adding cached hardware header
> > > > to keep the behavior consistent in all cases.
> > >
> > > What is the issue you want to fix exactly ?
> > >
> > > Please describe the use case.
> > >
> > > I highly suggest you take a look at commit
> > >
> > > e1f165032c8bade3a6bdf546f8faf61fda4dd01c
> > > ("net: Fix skb_under_panic oops in neigh_resolve_output")
> > >
> > > Otherwise, your fix is in fact adding a critical bug.
> > >
> > >
> > >
> >
>
>
>
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: David Miller @ 2016-10-26 16:52 UTC (permalink / raw)
To: mst; +Cc: brouer, shrijeet, tom, netdev, shm, roopa, nikolay
In-Reply-To: <20161026185743-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 26 Oct 2016 19:36:45 +0300
> On Wed, Oct 26, 2016 at 03:52:02PM +0200, Jesper Dangaard Brouer wrote:
>> On Sat, 22 Oct 2016 04:07:23 +0000
>> Shrijeet Mukherjee <shrijeet@gmail.com> wrote:
>>
>> > This patch adds support for xdp ndo and also inserts the xdp program
>> > call into the merged RX buffers and big buffers paths
>>
>> I really appreciate you are doing this for virtio_net.
>>
>> My first question is: Is the (packet) page data writable?
>> (MST might be able to answer?)
>>
>> As this is currently an XDP requirement[1].
>
> I'm not sure I understand what does writable mean.
> Could you explain a bit more pls?
> We do copy data into skb ATM but I plan to change that.
The packet data area must be writable, and the page it lives in must
not be shared with any other entity in the system.
This is because the eBPF program that executes via XDP must be able
to modify and read arbitrary parts of the packet area.
^ permalink raw reply
* [PATCH next] flow_dissector: __skb_get_hash_symmetric arg can be const
From: Florian Westphal @ 2016-10-26 16:49 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
Signed-off-by: Florian Westphal <fw@strlen.de>
---
include/linux/skbuff.h | 2 +-
net/core/flow_dissector.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 601258f6e621..663fda2887f7 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1086,7 +1086,7 @@ __skb_set_sw_hash(struct sk_buff *skb, __u32 hash, bool is_l4)
}
void __skb_get_hash(struct sk_buff *skb);
-u32 __skb_get_hash_symmetric(struct sk_buff *skb);
+u32 __skb_get_hash_symmetric(const struct sk_buff *skb);
u32 skb_get_poff(const struct sk_buff *skb);
u32 __skb_get_poff(const struct sk_buff *skb, void *data,
const struct flow_keys *keys, int hlen);
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 1a7b80f73376..0cc607d05fc8 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -723,7 +723,7 @@ EXPORT_SYMBOL(make_flow_keys_digest);
static struct flow_dissector flow_keys_dissector_symmetric __read_mostly;
-u32 __skb_get_hash_symmetric(struct sk_buff *skb)
+u32 __skb_get_hash_symmetric(const struct sk_buff *skb)
{
struct flow_keys keys;
--
2.7.3
^ permalink raw reply related
* Re: [PATCH net] bpf: fix samples to add fake KBUILD_MODNAME
From: Alexei Starovoitov @ 2016-10-26 16:44 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev
In-Reply-To: <581054DC.5000904@iogearbox.net>
On Wed, Oct 26, 2016 at 09:01:48AM +0200, Daniel Borkmann wrote:
> On 10/26/2016 03:17 AM, Alexei Starovoitov wrote:
> >On Wed, Oct 26, 2016 at 12:37:53AM +0200, Daniel Borkmann wrote:
> >>Some of the sample files are causing issues when they are loaded with tc
> >>and cls_bpf, meaning tc bails out while trying to parse the resulting ELF
> >>file as program/map/etc sections are not present, which can be easily
> >>spotted with readelf(1).
> >>
> >>Currently, BPF samples are including some of the kernel headers and mid
> >>term we should change them to refrain from this, really. When dynamic
> >>debugging is enabled, we bail out due to undeclared KBUILD_MODNAME, which
> >>is easily overlooked in the build as clang spills this along with other
> >>noisy warnings from various header includes, and llc still generates an
> >>ELF file with mentioned characteristics. For just playing around with BPF
> >>examples, this can be a bit of a hurdle to take.
> >>
> >>Just add a fake KBUILD_MODNAME as a band-aid to fix the issue, same is
> >>done in xdp*_kern samples already.
> >>
> >>Fixes: 65d472fb007d ("samples/bpf: add 'pointer to packet' tests")
> >>Fixes: 6afb1e28b859 ("samples/bpf: Add tunnel set/get tests.")
> >>Fixes: a3f74617340b ("cgroup: bpf: Add an example to do cgroup checking in BPF")
> >>Reported-by: Chandrasekar Kannan <ckannan@console.to>
> >>Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> >>---
> >> samples/bpf/parse_ldabs.c | 1 +
> >> samples/bpf/parse_simple.c | 1 +
> >> samples/bpf/parse_varlen.c | 1 +
> >> samples/bpf/tcbpf1_kern.c | 1 +
> >> samples/bpf/tcbpf2_kern.c | 1 +
> >> samples/bpf/test_cgrp2_tc_kern.c | 1 +
> >> 6 files changed, 6 insertions(+)
> >
> >It's also needed for all of tracex*_kern.c, right?
>
> Rest compiles just fine for me and readelf output looks good on all
> tracex*_kern.o, too.
>
> I see just warnings coming from various kernel header inclusions (see
> log), but no errors anymore.
ahh. good to know. I guess networking examples include some header
with dynamic debug that tracing examples don't.
Thanks for checking.
> ./include/linux/cgroup-defs.h:322:16: warning: field 'cgrp' with variable sized type 'struct cgroup' not at the end of a struct or class is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
> struct cgroup cgrp;
> ^
> 2 warnings generated.
this cgroup warning is crazy annoying and would have to be fixed anyway
for kernel to be compiled with clang.
^ permalink raw reply
* [PATCH net-next] net: phy: at803x: Add a definition for PHY ID mask
From: Fabio Estevam @ 2016-10-26 16:03 UTC (permalink / raw)
To: davem; +Cc: f.fainelli, netdev, Fabio Estevam
Add a definition for PHY ID mask for improving code readability.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
drivers/net/phy/at803x.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index f279a89..dd47b69 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -58,6 +58,7 @@
#define ATH8030_PHY_ID 0x004dd076
#define ATH8031_PHY_ID 0x004dd074
#define ATH8035_PHY_ID 0x004dd072
+#define AT803X_PHY_ID_MASK 0xffffffef
MODULE_DESCRIPTION("Atheros 803x PHY driver");
MODULE_AUTHOR("Matus Ujhelyi");
@@ -386,7 +387,7 @@ static struct phy_driver at803x_driver[] = {
/* ATHEROS 8035 */
.phy_id = ATH8035_PHY_ID,
.name = "Atheros 8035 ethernet",
- .phy_id_mask = 0xffffffef,
+ .phy_id_mask = AT803X_PHY_ID_MASK,
.probe = at803x_probe,
.config_init = at803x_config_init,
.set_wol = at803x_set_wol,
@@ -403,7 +404,7 @@ static struct phy_driver at803x_driver[] = {
/* ATHEROS 8030 */
.phy_id = ATH8030_PHY_ID,
.name = "Atheros 8030 ethernet",
- .phy_id_mask = 0xffffffef,
+ .phy_id_mask = AT803X_PHY_ID_MASK,
.probe = at803x_probe,
.config_init = at803x_config_init,
.link_change_notify = at803x_link_change_notify,
@@ -421,7 +422,7 @@ static struct phy_driver at803x_driver[] = {
/* ATHEROS 8031 */
.phy_id = ATH8031_PHY_ID,
.name = "Atheros 8031 ethernet",
- .phy_id_mask = 0xffffffef,
+ .phy_id_mask = AT803X_PHY_ID_MASK,
.probe = at803x_probe,
.config_init = at803x_config_init,
.set_wol = at803x_set_wol,
@@ -439,9 +440,9 @@ static struct phy_driver at803x_driver[] = {
module_phy_driver(at803x_driver);
static struct mdio_device_id __maybe_unused atheros_tbl[] = {
- { ATH8030_PHY_ID, 0xffffffef },
- { ATH8031_PHY_ID, 0xffffffef },
- { ATH8035_PHY_ID, 0xffffffef },
+ { ATH8030_PHY_ID, AT803X_PHY_ID_MASK },
+ { ATH8031_PHY_ID, AT803X_PHY_ID_MASK },
+ { ATH8035_PHY_ID, AT803X_PHY_ID_MASK },
{ }
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Michael S. Tsirkin @ 2016-10-26 16:36 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Shrijeet Mukherjee, tom, netdev, shm, roopa, nikolay
In-Reply-To: <20161026155202.5d99d935@redhat.com>
On Wed, Oct 26, 2016 at 03:52:02PM +0200, Jesper Dangaard Brouer wrote:
> On Sat, 22 Oct 2016 04:07:23 +0000
> Shrijeet Mukherjee <shrijeet@gmail.com> wrote:
>
> > This patch adds support for xdp ndo and also inserts the xdp program
> > call into the merged RX buffers and big buffers paths
>
> I really appreciate you are doing this for virtio_net.
>
> My first question is: Is the (packet) page data writable?
> (MST might be able to answer?)
>
> As this is currently an XDP requirement[1].
I'm not sure I understand what does writable mean.
Could you explain a bit more pls?
We do copy data into skb ATM but I plan to change that.
>
> > * The small packet skb receive is skipped for now
> > * No TX for now
>
> I do see more and more valid use-cases for only implementing XDP_DROP
> and not necessarily also implementing XDP_TX. This does requires that
> we implement some kind of feature/capabilities negotiation mechanism[2].
>
>
> [1] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/design/requirements.html#write-access-to-packet-data
>
> [2] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/design/design.html#capabilities-negotiation
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> Author of http://www.iptv-analyzer.org
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH net-next] tcp/dccp: drop SYN packets if accept queue is full
From: Eric Dumazet @ 2016-10-26 16:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Yuchung Cheng, Neal Cardwell
From: Eric Dumazet <edumazet@google.com>
Per listen(fd, backlog) rules, there is really no point accepting a SYN,
sending a SYNACK, and dropping the following ACK packet if accept queue
is full, because application is not draining accept queue fast enough.
This behavior is fooling TCP clients that believe they established a
flow, while there is nothing at server side. They might then send about
10 MSS (if using IW10) that will be dropped anyway while server is under
stress.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/inet_connection_sock.h | 5 -----
net/dccp/ipv4.c | 8 +-------
net/dccp/ipv6.c | 2 +-
net/ipv4/tcp_input.c | 8 +-------
4 files changed, 3 insertions(+), 20 deletions(-)
diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
index 197a30d221e92b839e2e96fa37f4a796514ea461..146054ceea8e0566f79739b1ed115dea53423258 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -289,11 +289,6 @@ static inline int inet_csk_reqsk_queue_len(const struct sock *sk)
return reqsk_queue_len(&inet_csk(sk)->icsk_accept_queue);
}
-static inline int inet_csk_reqsk_queue_young(const struct sock *sk)
-{
- return reqsk_queue_len_young(&inet_csk(sk)->icsk_accept_queue);
-}
-
static inline int inet_csk_reqsk_queue_is_full(const struct sock *sk)
{
return inet_csk_reqsk_queue_len(sk) >= sk->sk_max_ack_backlog;
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 345a3aeb8c7e36449a765298cd6512eab8cfef4b..a957acac2337680f619fef09f19660a3b4c309d3 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -588,13 +588,7 @@ int dccp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
if (inet_csk_reqsk_queue_is_full(sk))
goto drop;
- /*
- * Accept backlog is full. If we have already queued enough
- * of warm entries in syn queue, drop request. It is better than
- * clogging syn queue with openreqs with exponentially increasing
- * timeout.
- */
- if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1)
+ if (sk_acceptq_is_full(sk))
goto drop;
req = inet_reqsk_alloc(&dccp_request_sock_ops, sk, true);
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 3828f94b234c1104a3e745b3c0a76ab343aed4b6..32f9f1a189f8b8082bfdebd97baa04045562a3c6 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -325,7 +325,7 @@ static int dccp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
if (inet_csk_reqsk_queue_is_full(sk))
goto drop;
- if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1)
+ if (sk_acceptq_is_full(sk))
goto drop;
req = inet_reqsk_alloc(&dccp6_request_sock_ops, sk, true);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index a27b9c0e27c08b4e4aeaff3d0bfdf3ae561ba4d8..f2c59c8e57ff195c803ac05e6897242a6b097d00 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -6298,13 +6298,7 @@ int tcp_conn_request(struct request_sock_ops *rsk_ops,
goto drop;
}
-
- /* Accept backlog is full. If we have already queued enough
- * of warm entries in syn queue, drop request. It is better than
- * clogging syn queue with openreqs with exponentially increasing
- * timeout.
- */
- if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {
+ if (sk_acceptq_is_full(sk)) {
NET_INC_STATS(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
goto drop;
}
^ permalink raw reply related
* [PATCH net] Revert "hv_netvsc: report vmbus name in ethtool"
From: Stephen Hemminger @ 2016-10-26 16:27 UTC (permalink / raw)
To: David Miller, KY Srinivasan, Vitaly Kuznetsov; +Cc: netdev
From: Stephen Hemminger <sthemmin@microsoft.com>
This reverts commit e3f74b841d48
("hv_netvsc: report vmbus name in ethtool")'
because of problem introduced by commit f9a56e5d6a0ba
("Drivers: hv: make VMBus bus ids persistent").
This changed the format of the vmbus name and this new format is too
long to fit in the bus_info field of ethtool.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
drivers/net/hyperv/netvsc_drv.c | 4 ----
include/linux/hyperv.h | 7 -------
2 files changed, 11 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index c71d966..f638215 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -699,12 +699,8 @@ int netvsc_recv_callback(struct hv_device *device_obj,
static void netvsc_get_drvinfo(struct net_device *net,
struct ethtool_drvinfo *info)
{
- struct net_device_context *net_device_ctx = netdev_priv(net);
- struct hv_device *dev = net_device_ctx->device_ctx;
-
strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
strlcpy(info->fw_version, "N/A", sizeof(info->fw_version));
- strlcpy(info->bus_info, vmbus_dev_name(dev), sizeof(info->bus_info));
}
static void netvsc_get_channels(struct net_device *net,
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 6824556..cd184bd 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1169,13 +1169,6 @@ int __must_check __vmbus_driver_register(struct hv_driver *hv_driver,
const char *mod_name);
void vmbus_driver_unregister(struct hv_driver *hv_driver);
-static inline const char *vmbus_dev_name(const struct hv_device *device_obj)
-{
- const struct kobject *kobj = &device_obj->device.kobj;
-
- return kobj->name;
-}
-
void vmbus_hvsock_device_unregister(struct vmbus_channel *channel);
int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
--
2.9.3
^ permalink raw reply related
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