* Re: [PATCH v2 5/5] posix-timers: make it configurable
From: Richard Cochran @ 2016-10-26 20:18 UTC (permalink / raw)
To: Nicolas Pitre
Cc: John Stultz, Yann E. MORIN, Michal Marek, Thomas Gleixner,
Josh Triplett, Edward Cree, netdev, linux-kbuild, linux-kernel
In-Reply-To: <alpine.LFD.2.20.1610260941520.14694@knanqh.ubzr>
On Wed, Oct 26, 2016 at 09:56:13AM -0400, Nicolas Pitre wrote:
> So if my Fedora usage doesn't need them, we can infer that
> the number of embedded systems also not needing them might tend towards
> a high percentage.
(I wouldn't call Fedora an embedded distro, but heh...)
> But let's be conservative and say "some".
Sounds good to me.
Thanks,
Richard
^ permalink raw reply
* Re: [kernel-hardening] [RFC v4 03/18] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles
From: Jann Horn @ 2016-10-26 20:16 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, 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-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <58110BFD.5090005-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3144 bytes --]
On Wed, Oct 26, 2016 at 10:03:09PM +0200, Mickaël Salaün wrote:
> On 26/10/2016 21:01, Jann Horn wrote:
> > On Wed, Oct 26, 2016 at 08:56:39AM +0200, Mickaël Salaün wrote:
> >> This new arraymap looks like a set and brings new properties:
> >> * strong typing of entries: the eBPF functions get the array type of
> >> elements instead of CONST_PTR_TO_MAP (e.g.
> >> CONST_PTR_TO_LANDLOCK_HANDLE_FS);
> >> * force sequential filling (i.e. replace or append-only update), which
> >> allow quick browsing of all entries.
> >>
> >> This strong typing is useful to statically check if the content of a map
> >> can be passed to an eBPF function. For example, Landlock use it to store
> >> and manage kernel objects (e.g. struct file) instead of dealing with
> >> userland raw data. This improve efficiency and ensure that an eBPF
> >> program can only call functions with the right high-level arguments.
> >>
> >> The enum bpf_map_handle_type list low-level types (e.g.
> >> BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD) which are identified when
> >> updating a map entry (handle). This handle types are used to infer a
> >> high-level arraymap type which are listed in enum bpf_map_array_type
> >> (e.g. BPF_MAP_ARRAY_TYPE_LANDLOCK_FS).
> >>
> >> For now, this new arraymap is only used by Landlock LSM (cf. next
> >> commits) but it could be useful for other needs.
> >>
> >> Changes since v3:
> >> * make handle arraymap safe (RCU) and remove buggy synchronize_rcu()
> >> * factor out the arraymay walk
> >>
> >> Changes since v2:
> >> * add a RLIMIT_NOFILE-based limit to the maximum number of arraymap
> >> handle entries (suggested by Andy Lutomirski)
> >> * remove useless checks
> >>
> >> Changes since v1:
> >> * arraymap of handles replace custom checker groups
> >> * simpler userland API
> > [...]
> >> + case BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD:
> >> + handle_file = fget(handle->fd);
> >> + if (IS_ERR(handle_file))
> >> + return ERR_CAST(handle_file);
> >> + /* check if the FD is tied to a user mount point */
> >> + if (unlikely(handle_file->f_path.mnt->mnt_flags & MNT_INTERNAL)) {
> >> + fput(handle_file);
> >> + return ERR_PTR(-EINVAL);
> >> + }
> >> + path_get(&handle_file->f_path);
> >> + ret = kmalloc(sizeof(*ret), GFP_KERNEL);
> >> + ret->path = handle_file->f_path;
> >> + fput(handle_file);
> >
> > You can use fdget() and fdput() here because the reference to
> > handle_file is dropped before the end of the syscall.
>
> The reference to handle_file is dropped but not the reference to the
> (inner) path thanks to path_get().
That's irrelevant. As long as you promise to fdput() any references
acquired using fdget() before any of the following can happen, using
fdget() is okay:
- the syscall exits
- the fd table is shared with a process that might write to it
- an fd is closed by the kernel
In other words, you must be able to prove that nobody can remove the
struct file * from your fd table before you fdput().
Taking a long-term reference to an object pointed to by a struct file
that was looked up with fdget() is fine.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC v4 03/18] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles
From: Mickaël Salaün @ 2016-10-26 20:03 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: <20161026190147.GN3334@pc.thejh.net>
[-- Attachment #1.1: Type: text/plain, Size: 3735 bytes --]
On 26/10/2016 21:01, Jann Horn wrote:
> On Wed, Oct 26, 2016 at 08:56:39AM +0200, Mickaël Salaün wrote:
>> This new arraymap looks like a set and brings new properties:
>> * strong typing of entries: the eBPF functions get the array type of
>> elements instead of CONST_PTR_TO_MAP (e.g.
>> CONST_PTR_TO_LANDLOCK_HANDLE_FS);
>> * force sequential filling (i.e. replace or append-only update), which
>> allow quick browsing of all entries.
>>
>> This strong typing is useful to statically check if the content of a map
>> can be passed to an eBPF function. For example, Landlock use it to store
>> and manage kernel objects (e.g. struct file) instead of dealing with
>> userland raw data. This improve efficiency and ensure that an eBPF
>> program can only call functions with the right high-level arguments.
>>
>> The enum bpf_map_handle_type list low-level types (e.g.
>> BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD) which are identified when
>> updating a map entry (handle). This handle types are used to infer a
>> high-level arraymap type which are listed in enum bpf_map_array_type
>> (e.g. BPF_MAP_ARRAY_TYPE_LANDLOCK_FS).
>>
>> For now, this new arraymap is only used by Landlock LSM (cf. next
>> commits) but it could be useful for other needs.
>>
>> Changes since v3:
>> * make handle arraymap safe (RCU) and remove buggy synchronize_rcu()
>> * factor out the arraymay walk
>>
>> Changes since v2:
>> * add a RLIMIT_NOFILE-based limit to the maximum number of arraymap
>> handle entries (suggested by Andy Lutomirski)
>> * remove useless checks
>>
>> Changes since v1:
>> * arraymap of handles replace custom checker groups
>> * simpler userland API
> [...]
>> + case BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD:
>> + handle_file = fget(handle->fd);
>> + if (IS_ERR(handle_file))
>> + return ERR_CAST(handle_file);
>> + /* check if the FD is tied to a user mount point */
>> + if (unlikely(handle_file->f_path.mnt->mnt_flags & MNT_INTERNAL)) {
>> + fput(handle_file);
>> + return ERR_PTR(-EINVAL);
>> + }
>> + path_get(&handle_file->f_path);
>> + ret = kmalloc(sizeof(*ret), GFP_KERNEL);
>> + ret->path = handle_file->f_path;
>> + fput(handle_file);
>
> You can use fdget() and fdput() here because the reference to
> handle_file is dropped before the end of the syscall.
The reference to handle_file is dropped but not the reference to the
(inner) path thanks to path_get().
>
>
>> + break;
>> + case BPF_MAP_HANDLE_TYPE_UNSPEC:
>> + default:
>> + return ERR_PTR(-EINVAL);
>> + }
>> + ret->type = handle_type;
>> + return ret;
>> +}
>> +
>> +static void *nop_map_lookup_elem(struct bpf_map *map, void *key)
>> +{
>> + return ERR_PTR(-EINVAL);
>> +}
>> +
>> +/* called from syscall or from eBPF program */
>> +static int landlock_array_map_update_elem(struct bpf_map *map, void *key,
>> + void *value, u64 map_flags)
>> +{
>
> This being callable from eBPF context is IMO pretty surprising and should
> at least be well-documented. Also: What is the usecase here?
>
This may be callable but is restricted to CAP_SYS_ADMIN. Any update with
an FD should indeed be denied, but updates with raw values (e.g. GLOB,
IP or port numbers, not yet implemented) may be allowed. Because an eBPF
program is trusted by the process which loaded it (and have the same
rights), this program should be able to update a map like its creator
process. One usecase may be to adjust a map of handles by removing
entries or tightening them (i.e. drop privileges) when a specific
behavior of a monitored process is detected by the eBPF program.
I'm going to fix this update-with-FD case which make no sense anyway.
Thanks,
Mickaël
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH v7 0/6] Add eBPF hooks for cgroups
From: Pablo Neira Ayuso @ 2016-10-26 19:59 UTC (permalink / raw)
To: Daniel Mack
Cc: htejun, daniel, ast, davem, kafai, fw, harald, netdev, sargun,
cgroups
In-Reply-To: <1477390454-12553-1-git-send-email-daniel@zonque.org>
On Tue, Oct 25, 2016 at 12:14:08PM +0200, Daniel Mack wrote:
[...]
> Dumping programs once they are installed is problematic because of
> the internal optimizations done to the eBPF program during its
> lifetime. Also, the references to maps etc. would need to be
> restored during the dump.
>
> Just exposing whether or not a program is attached would be
> trivial to do, however, most easily through another bpf(2)
> command. That can be added later on though.
I don't know if anyone told you, but during last netconf, this topic
took a bit of time of discussion and it was controversial, I would say
1/3 of netdev hackers there showed their concerns, and that's
something that should not be skipped IMO.
While xdp is pushing bpf programs at the very early packet path, not
interfering with the stack, before even entering the generic ingress
path. But this is adding hooks to push bpf programs in the middle of
our generic stack, this is way different domain.
I would really like to explore way earlier filtering, by extending
socket lookup facilities. So far the problem seems to be that we need
to lookup for broadcast/multicast UDP sockets and those cannot be
attach via the usual skb->sk. I think it would be possible to wrap
around this socket code in functions so we can invoke it. I guess
filtering of UDP and TCP should be good for you at this stage. This
would require more work though, but this would come with no hooks in
the stack and packets will not have to consume *lots of cycles* just
to be dropped before entering the socket queue.
How useful can be to drop lots of unwanted traffic at such a late
stage? How would the performance numbers to drop packets would look
like? Extremely bad, I predict.
^ permalink raw reply
* Re: [PATCH net-next] tcp/dccp: drop SYN packets if accept queue is full
From: Yuchung Cheng @ 2016-10-26 19:42 UTC (permalink / raw)
To: Neal Cardwell; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <CADVnQy=f==Ffk_=xPN7hOHyu5sHqhgi3rUw89rTYn1fxF7HdqQ@mail.gmail.com>
On Wed, Oct 26, 2016 at 11:39 AM, Neal Cardwell <ncardwell@google.com> wrote:
>
> On Wed, Oct 26, 2016 at 12:27 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > 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>
> > ---
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
It's too bad the git has no history of the extra young sockets check.
it seemed to be some kind bandaid fix before syn-cookie was invented?
>
> Great. Thanks, Eric!
>
> neal
^ permalink raw reply
* [PATCH 1/5] net: phy: broadcom: Add BCM54810 phy entry
From: Jon Mason @ 2016-10-26 19:35 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel, Vikas Soni
In-Reply-To: <1477510561-17035-1-git-send-email-jon.mason@broadcom.com>
From: Vikas Soni <vsoni@broadcom.com>
Add BCM54810 phy entry
Signed-off-by: Vikas Soni <vsoni@broadcom.com>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
drivers/net/phy/Kconfig | 2 +-
drivers/net/phy/broadcom.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/brcmphy.h | 7 +++++
3 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 45f68ea..31967ca 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -217,7 +217,7 @@ config BROADCOM_PHY
select BCM_NET_PHYLIB
---help---
Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
- BCM5481 and BCM5482 PHYs.
+ BCM5481, BCM54810 and BCM5482 PHYs.
config CICADA_PHY
tristate "Cicada PHYs"
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 870327e..cdce761 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -35,6 +35,35 @@ static int bcm54xx_auxctl_write(struct phy_device *phydev, u16 regnum, u16 val)
return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
}
+static int bcm54810_config(struct phy_device *phydev)
+{
+ int rc;
+
+ /* Disable BroadR-Reach */
+ rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL, 0);
+ if (rc < 0)
+ return rc;
+
+ /* SKEW DISABLE */
+ rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
+ 0xF0E0);
+ if (rc < 0)
+ return rc;
+
+ /* DELAY DISABLE */
+ rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
+ 0x7000);
+ if (rc < 0)
+ return rc;
+
+ /* DELAY DISABLE */
+ rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, 0);
+ if (rc < 0)
+ return rc;
+
+ return 0;
+}
+
/* Needs SMDSP clock enabled via bcm54xx_phydsp_config() */
static int bcm50610_a0_workaround(struct phy_device *phydev)
{
@@ -207,6 +236,20 @@ static int bcm54xx_config_init(struct phy_device *phydev)
(phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
bcm54xx_adjust_rxrefclk(phydev);
+ if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
+ err = bcm54810_config(phydev);
+ if (err)
+ return err;
+
+ reg = phy_read(phydev, MII_BMCR);
+ if (reg < 0)
+ return reg;
+
+ err = phy_write(phydev, MII_BMCR, reg & ~BMCR_PDOWN);
+ if (err)
+ return err;
+ }
+
bcm54xx_phydsp_config(phydev);
return 0;
@@ -334,6 +377,15 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
phy_write(phydev, 0x18, reg);
}
+ if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810 &&
+ phydev->dev_flags & PHY_BRCM_EXP_LANE_SWAP) {
+ /* LANE SWAP */
+ ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
+ 0x11B);
+ if (ret < 0)
+ return ret;
+ }
+
return ret;
}
@@ -521,6 +573,18 @@ static struct phy_driver broadcom_drivers[] = {
.ack_interrupt = bcm_phy_ack_intr,
.config_intr = bcm_phy_config_intr,
}, {
+ .phy_id = PHY_ID_BCM54810,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM54810",
+ .features = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = bcm5481_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm_phy_ack_intr,
+ .config_intr = bcm_phy_config_intr,
+}, {
.phy_id = PHY_ID_BCM5482,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5482",
@@ -603,6 +667,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] = {
{ PHY_ID_BCM54616S, 0xfffffff0 },
{ PHY_ID_BCM5464, 0xfffffff0 },
{ PHY_ID_BCM5481, 0xfffffff0 },
+ { PHY_ID_BCM54810, 0xfffffff0 },
{ PHY_ID_BCM5482, 0xfffffff0 },
{ PHY_ID_BCM50610, 0xfffffff0 },
{ PHY_ID_BCM50610M, 0xfffffff0 },
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index e7a3d9d..40e6ead 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -13,6 +13,7 @@
#define PHY_ID_BCM5241 0x0143bc30
#define PHY_ID_BCMAC131 0x0143bc70
#define PHY_ID_BCM5481 0x0143bca0
+#define PHY_ID_BCM54810 0x03625d00
#define PHY_ID_BCM5482 0x0143bcb0
#define PHY_ID_BCM5411 0x00206070
#define PHY_ID_BCM5421 0x002060e0
@@ -55,6 +56,8 @@
#define PHY_BRCM_EXT_IBND_TX_ENABLE 0x00002000
#define PHY_BRCM_CLEAR_RGMII_MODE 0x00004000
#define PHY_BRCM_DIS_TXCRXC_NOENRGY 0x00008000
+#define PHY_BRCM_EXP_LANE_SWAP 0x00010000
+
/* Broadcom BCM7xxx specific workarounds */
#define PHY_BRCM_7XXX_REV(x) (((x) >> 8) & 0xff)
#define PHY_BRCM_7XXX_PATCH(x) ((x) & 0xff)
@@ -187,6 +190,10 @@
#define BCM5482_SSD_SGMII_SLAVE_EN 0x0002 /* Slave mode enable */
#define BCM5482_SSD_SGMII_SLAVE_AD 0x0001 /* Slave auto-detection */
+/* BCM54810 Registers */
+#define BCM54810_EXP_BROADREACH_LRE_MISC_CTL (MII_BCM54XX_EXP_SEL_ER + 0x90)
+#define BCM54810_SHD_CLK_CTL 0x3
+
/*****************************************************************************/
/* Fast Ethernet Transceiver definitions. */
--
2.7.4
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: NS2: add AMAC ethernet support
From: Jon Mason @ 2016-10-26 19:36 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1477510561-17035-1-git-send-email-jon.mason@broadcom.com>
Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
tree
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 5 +++++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 ++++++++++++
2 files changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index 2d7872a..362db7e 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -56,6 +56,11 @@
};
};
+&enet {
+ brcm,enet-phy-lane-swap;
+ status = "ok";
+};
+
&pci_phy0 {
status = "ok";
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index d95dc40..773ed59 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -191,6 +191,18 @@
#include "ns2-clock.dtsi"
+ enet: ethernet@61000000 {
+ compatible = "brcm,ns2-amac";
+ reg = <0x61000000 0x1000>,
+ <0x61090000 0x1000>,
+ <0x61030000 0x100>;
+ reg-names = "amac_base", "idm_base", "nicpm_base";
+ interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>;
+ phy-handle = <&gphy0>;
+ phy-mode = "rgmii";
+ status = "disabled";
+ };
+
dma0: dma@61360000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x61360000 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] net: ethernet: bgmac: add NS2 support
From: Jon Mason @ 2016-10-26 19:36 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal-g1n6cQUeyibVItvQsEIGlw,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477510561-17035-1-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Add support for the variant of amac hardware present in the Broadcom
Northstar2 based SoCs. Northstar2 requires an additional register to be
configured with the port speed/duplexity (NICPM). This can be added to
the link callback to hide it from the instances that do not use this.
Also, the bgmac_chip_reset() was intentionally removed to prevent the
resetting of the chip to the default values on open. Finally, clearing
of the pending interrupts on init is required due to observed issues on
some platforms.
Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
drivers/net/ethernet/broadcom/bgmac-platform.c | 64 +++++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bgmac.c | 5 +-
drivers/net/ethernet/broadcom/bgmac.h | 2 +
3 files changed, 67 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
index aed5dc5..49fcff4 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -14,12 +14,21 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/bcma/bcma.h>
+#include <linux/brcmphy.h>
#include <linux/etherdevice.h>
#include <linux/of_address.h>
#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "bgmac.h"
+#define NICPM_IOMUX_CTRL 0x00000008
+
+#define NICPM_IOMUX_CTRL_INIT_VAL 0x3196e000
+#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
+#define NICPM_IOMUX_CTRL_SPD_10M 0
+#define NICPM_IOMUX_CTRL_SPD_100M 1
+#define NICPM_IOMUX_CTRL_SPD_1000M 2
+
static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
{
return readl(bgmac->plat.base + offset);
@@ -87,17 +96,56 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
WARN_ON(1);
}
+static void bgmac_nicpm_speed_set(struct net_device *net_dev)
+{
+ struct bgmac *bgmac = netdev_priv(net_dev);
+ u32 val;
+
+ if (!bgmac->plat.nicpm_base)
+ return;
+
+ val = NICPM_IOMUX_CTRL_INIT_VAL;
+ switch (bgmac->net_dev->phydev->speed) {
+ default:
+ pr_err("Unsupported speed. Defaulting to 1000Mb\n");
+ case SPEED_1000:
+ val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+ break;
+ case SPEED_100:
+ val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+ break;
+ case SPEED_10:
+ val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+ break;
+ }
+
+ writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
+
+ usleep_range(10, 100);
+
+ bgmac_adjust_link(bgmac->net_dev);
+}
+
static int platform_phy_connect(struct bgmac *bgmac)
{
struct phy_device *phy_dev;
- phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
- bgmac_adjust_link);
+ if (bgmac->plat.nicpm_base)
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+ bgmac->dev->of_node,
+ bgmac_nicpm_speed_set);
+ else
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+ bgmac->dev->of_node,
+ bgmac_adjust_link);
if (!phy_dev) {
dev_err(bgmac->dev, "Phy connect failed\n");
return -ENODEV;
}
+ if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
+ phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
+
return 0;
}
@@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, bgmac);
+ if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
+ bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
+
/* Set the features of the 4707 family */
bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
@@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
if (IS_ERR(bgmac->plat.idm_base))
return PTR_ERR(bgmac->plat.idm_base);
+ regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
+ if (regs) {
+ bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
+ regs);
+ if (IS_ERR(bgmac->plat.nicpm_base))
+ return PTR_ERR(bgmac->plat.nicpm_base);
+ }
+
bgmac->read = platform_bgmac_read;
bgmac->write = platform_bgmac_write;
bgmac->idm_read = platform_bgmac_idm_read;
@@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
static const struct of_device_id bgmac_of_enet_match[] = {
{.compatible = "brcm,amac",},
{.compatible = "brcm,nsp-amac",},
+ {.compatible = "brcm,ns2-amac",},
{},
};
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 38876ec..1796208 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
/* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
static void bgmac_chip_init(struct bgmac *bgmac)
{
+ /* Clear any erroneously pending interrupts */
+ bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
+
/* 1 interrupt per received frame */
bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
@@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
struct bgmac *bgmac = netdev_priv(net_dev);
int err = 0;
- bgmac_chip_reset(bgmac);
-
err = bgmac_dma_init(bgmac);
if (err)
return err;
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index ea52ac3..677e685 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -409,6 +409,7 @@
#define BGMAC_FEAT_CC4_IF_SW_TYPE BIT(17)
#define BGMAC_FEAT_CC4_IF_SW_TYPE_RGMII BIT(18)
#define BGMAC_FEAT_CC7_IF_TYPE_RGMII BIT(19)
+#define BGMAC_FEAT_LANE_SWAP BIT(20)
struct bgmac_slot_info {
union {
@@ -463,6 +464,7 @@ struct bgmac {
struct {
void *base;
void *idm_base;
+ void *nicpm_base;
} plat;
struct {
struct bcma_device *core;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 related
* [PATCH 3/5] net: ethernet: bgmac: device tree phy enablement
From: Jon Mason @ 2016-10-26 19:35 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1477510561-17035-1-git-send-email-jon.mason@broadcom.com>
Change the bgmac driver to allow for phy's defined by the device tree
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
drivers/net/ethernet/broadcom/bgmac-bcma.c | 48 ++++++++++++++++++++++++
drivers/net/ethernet/broadcom/bgmac-platform.c | 48 +++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bgmac.c | 51 +-------------------------
drivers/net/ethernet/broadcom/bgmac.h | 7 ++++
4 files changed, 104 insertions(+), 50 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c b/drivers/net/ethernet/broadcom/bgmac-bcma.c
index c16ec3a..3e3efde 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -80,6 +80,50 @@ static void bcma_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset, u32 mask,
bcma_maskset32(bgmac->bcma.cmn, offset, mask, set);
}
+static int bcma_phy_connect(struct bgmac *bgmac)
+{
+ struct phy_device *phy_dev;
+ char bus_id[MII_BUS_ID_SIZE + 3];
+
+ /* Connect to the PHY */
+ snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
+ bgmac->phyaddr);
+ phy_dev = phy_connect(bgmac->net_dev, bus_id, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "PHY connecton failed\n");
+ return PTR_ERR(phy_dev);
+ }
+
+ return 0;
+}
+
+static int bcma_phy_direct_connect(struct bgmac *bgmac)
+{
+ struct fixed_phy_status fphy_status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+ };
+ struct phy_device *phy_dev;
+ int err;
+
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ if (!phy_dev || IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+ return -ENODEV;
+ }
+
+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (err) {
+ dev_err(bgmac->dev, "Connecting PHY failed\n");
+ return err;
+ }
+
+ return err;
+}
+
static const struct bcma_device_id bgmac_bcma_tbl[] = {
BCMA_CORE(BCMA_MANUF_BCM, BCMA_CORE_4706_MAC_GBIT,
BCMA_ANY_REV, BCMA_ANY_CLASS),
@@ -275,6 +319,10 @@ static int bgmac_probe(struct bcma_device *core)
bgmac->cco_ctl_maskset = bcma_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = bcma_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = bcma_bgmac_cmn_maskset32;
+ if (bgmac->mii_bus)
+ bgmac->phy_connect = bcma_phy_connect;
+ else
+ bgmac->phy_connect = bcma_phy_direct_connect;
err = bgmac_enet_probe(bgmac);
if (err)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
index be52f27..aed5dc5 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -16,6 +16,7 @@
#include <linux/bcma/bcma.h>
#include <linux/etherdevice.h>
#include <linux/of_address.h>
+#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "bgmac.h"
@@ -86,6 +87,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
WARN_ON(1);
}
+static int platform_phy_connect(struct bgmac *bgmac)
+{
+ struct phy_device *phy_dev;
+
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
+ bgmac_adjust_link);
+ if (!phy_dev) {
+ dev_err(bgmac->dev, "Phy connect failed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int platform_phy_direct_connect(struct bgmac *bgmac)
+{
+ struct fixed_phy_status fphy_status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+ };
+ struct phy_device *phy_dev;
+ int err;
+
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ if (!phy_dev || IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+ return -ENODEV;
+ }
+
+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (err) {
+ dev_err(bgmac->dev, "Connecting PHY failed\n");
+ return err;
+ }
+
+ return err;
+}
+
static int bgmac_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -102,7 +143,6 @@ static int bgmac_probe(struct platform_device *pdev)
/* Set the features of the 4707 family */
bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
- bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
bgmac->feature_flags |= BGMAC_FEAT_CMDCFG_SR_REV4;
bgmac->feature_flags |= BGMAC_FEAT_TX_MASK_SETUP;
bgmac->feature_flags |= BGMAC_FEAT_RX_MASK_SETUP;
@@ -151,6 +191,12 @@ static int bgmac_probe(struct platform_device *pdev)
bgmac->cco_ctl_maskset = platform_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = platform_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = platform_bgmac_cmn_maskset32;
+ if (of_parse_phandle(np, "phy-handle", 0)) {
+ bgmac->phy_connect = platform_phy_connect;
+ } else {
+ bgmac->phy_connect = platform_phy_direct_connect;
+ bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
+ }
return bgmac_enet_probe(bgmac);
}
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 856379c..38876ec 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1388,7 +1388,7 @@ static const struct ethtool_ops bgmac_ethtool_ops = {
* MII
**************************************************/
-static void bgmac_adjust_link(struct net_device *net_dev)
+void bgmac_adjust_link(struct net_device *net_dev)
{
struct bgmac *bgmac = netdev_priv(net_dev);
struct phy_device *phy_dev = net_dev->phydev;
@@ -1412,50 +1412,6 @@ static void bgmac_adjust_link(struct net_device *net_dev)
}
}
-static int bgmac_phy_connect_direct(struct bgmac *bgmac)
-{
- struct fixed_phy_status fphy_status = {
- .link = 1,
- .speed = SPEED_1000,
- .duplex = DUPLEX_FULL,
- };
- struct phy_device *phy_dev;
- int err;
-
- phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
- if (!phy_dev || IS_ERR(phy_dev)) {
- dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
- return -ENODEV;
- }
-
- err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
- PHY_INTERFACE_MODE_MII);
- if (err) {
- dev_err(bgmac->dev, "Connecting PHY failed\n");
- return err;
- }
-
- return err;
-}
-
-static int bgmac_phy_connect(struct bgmac *bgmac)
-{
- struct phy_device *phy_dev;
- char bus_id[MII_BUS_ID_SIZE + 3];
-
- /* Connect to the PHY */
- snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
- bgmac->phyaddr);
- phy_dev = phy_connect(bgmac->net_dev, bus_id, &bgmac_adjust_link,
- PHY_INTERFACE_MODE_MII);
- if (IS_ERR(phy_dev)) {
- dev_err(bgmac->dev, "PHY connecton failed\n");
- return PTR_ERR(phy_dev);
- }
-
- return 0;
-}
-
int bgmac_enet_probe(struct bgmac *info)
{
struct net_device *net_dev;
@@ -1507,10 +1463,7 @@ int bgmac_enet_probe(struct bgmac *info)
netif_napi_add(net_dev, &bgmac->napi, bgmac_poll, BGMAC_WEIGHT);
- if (!bgmac->mii_bus)
- err = bgmac_phy_connect_direct(bgmac);
- else
- err = bgmac_phy_connect(bgmac);
+ err = bgmac_phy_connect(bgmac);
if (err) {
dev_err(bgmac->dev, "Cannot connect to phy\n");
goto err_dma_free;
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index 80836b4..ea52ac3 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -513,10 +513,12 @@ struct bgmac {
u32 (*get_bus_clock)(struct bgmac *bgmac);
void (*cmn_maskset32)(struct bgmac *bgmac, u16 offset, u32 mask,
u32 set);
+ int (*phy_connect)(struct bgmac *bgmac);
};
int bgmac_enet_probe(struct bgmac *info);
void bgmac_enet_remove(struct bgmac *bgmac);
+void bgmac_adjust_link(struct net_device *net_dev);
struct mii_bus *bcma_mdio_mii_register(struct bcma_device *core, u8 phyaddr);
void bcma_mdio_mii_unregister(struct mii_bus *mii_bus);
@@ -583,4 +585,9 @@ static inline void bgmac_set(struct bgmac *bgmac, u16 offset, u32 set)
{
bgmac_maskset(bgmac, offset, ~0, set);
}
+
+static inline int bgmac_phy_connect(struct bgmac *bgmac)
+{
+ return bgmac->phy_connect(bgmac);
+}
#endif /* _BGMAC_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac
From: Jon Mason @ 2016-10-26 19:35 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1477510561-17035-1-git-send-email-jon.mason@broadcom.com>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
Documentation/devicetree/bindings/net/brcm,amac.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
index ba5ecc1..f92caee 100644
--- a/Documentation/devicetree/bindings/net/brcm,amac.txt
+++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
@@ -2,15 +2,18 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
-------------------------------------------------------------
Required properties:
- - compatible: "brcm,amac" or "brcm,nsp-amac"
+ - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
- reg: Address and length of the GMAC registers,
Address and length of the GMAC IDM registers
+ Address and length of the NIC Port Manager registers (optional)
- reg-names: Names of the registers. Must have both "amac_base" and
- "idm_base"
+ "idm_base". "nicpm_base" is optional (required for NS2)
- interrupts: Interrupt number
Optional properties:
- mac-address: See ethernet.txt file in the same directory
+- brcm,enet-phy-lane-swap:
+ boolean; Swap the PHY lanes (needed on some SKUs of NS2)
Examples:
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] add NS2 support to bgmac
From: Jon Mason @ 2016-10-26 19:35 UTC (permalink / raw)
To: David Miller, Rob Herring, Mark Rutland, Florian Fainelli
Cc: rafal, bcm-kernel-feedback-list, netdev, devicetree,
linux-arm-kernel, linux-kernel
Add support for the amac found in the Broadcom Northstar2 SoC to the
bgmac driver. This necessitates adding support to connect to an
externally defined phy (as described in the device tree) in the driver.
These phy changes are in addition to the changes necessary to get NS2
working.
This series (based on the net-next git tree) has been tested on NSP and
NS2 HW.
Jon Mason (4):
Documentation: devicetree: net: add NS2 bindings to amac
net: ethernet: bgmac: device tree phy enablement
net: ethernet: bgmac: add NS2 support
arm64: dts: NS2: add AMAC ethernet support
Vikas Soni (1):
net: phy: broadcom: Add BCM54810 phy entry
.../devicetree/bindings/net/brcm,amac.txt | 7 +-
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 5 +
arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 +++
drivers/net/ethernet/broadcom/bgmac-bcma.c | 48 +++++++++
drivers/net/ethernet/broadcom/bgmac-platform.c | 108 ++++++++++++++++++++-
drivers/net/ethernet/broadcom/bgmac.c | 56 +----------
drivers/net/ethernet/broadcom/bgmac.h | 9 ++
drivers/net/phy/Kconfig | 2 +-
drivers/net/phy/broadcom.c | 65 +++++++++++++
include/linux/brcmphy.h | 7 ++
10 files changed, 264 insertions(+), 55 deletions(-)
--
2.7.4
^ permalink raw reply
* [RFC net-next iproute2 1/2] libnetlink: Add test for error code returned from netlink reply
From: Cyrill Gorcunov @ 2016-10-26 19:30 UTC (permalink / raw)
To: netdev
Cc: Stephen Hemminger, Eric Dumazet, David Ahern, Andrey Vagin,
Cyrill Gorcunov
In-Reply-To: <1477510208-20292-1-git-send-email-gorcunov@gmail.com>
In case if some diag module is not present in the system,
say the kernel is not modern enough, we simply skip the
error code reported. Instead we should check for data
length in NLMSG_DONE and process unsupported case.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
lib/libnetlink.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 2279935..a397c07 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -312,6 +312,27 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
dump_intr = 1;
if (h->nlmsg_type == NLMSG_DONE) {
+ int len;
+
+ /*
+ * The kernel reports if there is
+ * no inet-diag module present in
+ * the system via negative length
+ * as error code.
+ */
+ if (h->nlmsg_len < NLMSG_LENGTH(sizeof(int))) {
+ fprintf(stderr, "Truncated length reply\n");
+ return -1;
+ }
+ len = *(int *)NLMSG_DATA(h);
+ if (len < 0) {
+ errno = -len;
+ if (errno == ENOENT ||
+ errno == EOPNOTSUPP)
+ return -1;
+ perror("RTNETLINK answers");
+ return len;
+ }
found_done = 1;
break; /* process next filter */
}
--
2.7.4
^ permalink raw reply related
* [RFC net-next iproute2 0/2] Add support for operating raw sockest via diag interface
From: Cyrill Gorcunov @ 2016-10-26 19:30 UTC (permalink / raw)
To: netdev
Cc: Stephen Hemminger, Eric Dumazet, David Ahern, Andrey Vagin,
Cyrill Gorcunov
The diag interface for raw sockets is now in linux-net-next
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=432490f9d455fb842d70219f22d9d2c812371676
so here is early patches for misc/ss
While "showing" action works as expected, I see some weird effects on
"kill" socket actions. In particular I've a test program which binds
sockets to veth interface
# ip link add dev vm1 type veth peer name vm2
setsockopt(sk, SOL_SOCKET, SO_BINDTODEVICE, "vm1", 3);
setsockopt(sk6, SOL_SOCKET, SO_BINDTODEVICE, "vm1", 3);
setsockopt(skc, SOL_SOCKET, SO_BINDTODEVICE, "vm1", 3);
setsockopt(sk6, SOL_SOCKET, SO_BINDTODEVICE, "vm1", 3);
setsockopt(skicmp, SOL_SOCKET, SO_BINDTODEVICE, "vm1", 3);
so the output shows
[root@pcs7 iproute2]# ./misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *%vm1:icmp *:*
UNCONN 0 0 *:ipproto-255 *:*
UNCONN 0 0 *%vm1:ipproto-255 *:*
UNCONN 0 0 127.0.0.10%vm1:ipproto-255 *:*
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
ESTAB 0 0 ::1:ipproto-255 ::1:ipproto-9091
UNCONN 0 0 ::1%vm1:ipproto-255 :::*
[root@pcs7 iproute2]#
But when I start killing sockets
[root@pcs7 iproute2]# ./misc/ss -aKw 'dev == vm1'
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *%vm1:ipproto-255 *:*
UNCONN 0 0 127.0.0.10%vm1:ipproto-255 *:*
UNCONN 0 0 ::1%vm1:ipproto-255 :::*
[root@pcs7 iproute2]#
[root@pcs7 iproute2]# ./misc/ss -aKw 'dev == vm1'
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 127.0.0.10%vm1:ipproto-255 *:*
[root@pcs7 iproute2]# ./misc/ss -aKw 'dev == vm1'
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *%vm1:icmp *:*
[root@pcs7 iproute2]# ./misc/ss -aKw 'dev == vm1'
State Recv-Q Send-Q Local Address:Port Peer Address:Port
[root@pcs7 iproute2]#
It doesn't do all this in one pass, so I suspect I miss something in second patch?
Please take a look, once time permit.
Cyrill Gorcunov (2):
libnetlink: Add test for error code returned from netlink reply
ss: Add inet raw sockets information gathering via netlink diag
interface
include/linux/inet_diag.h | 15 +++++++++++++++
lib/libnetlink.c | 21 +++++++++++++++++++++
misc/ss.c | 20 ++++++++++++++++++--
3 files changed, 54 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* [RFC net-next iproute2 2/2] ss: Add inet raw sockets information gathering via netlink diag interface
From: Cyrill Gorcunov @ 2016-10-26 19:30 UTC (permalink / raw)
To: netdev
Cc: Stephen Hemminger, Eric Dumazet, David Ahern, Andrey Vagin,
Cyrill Gorcunov
In-Reply-To: <1477510208-20292-1-git-send-email-gorcunov@gmail.com>
unix, tcp, udp[lite], packet, netlink sockets already support diag
interface for their collection and killing. Now with commit XXX
this facility is implemented for raw sockets.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
include/linux/inet_diag.h | 15 +++++++++++++++
misc/ss.c | 20 ++++++++++++++++++--
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/include/linux/inet_diag.h b/include/linux/inet_diag.h
index f5f5c1b..ac66148 100644
--- a/include/linux/inet_diag.h
+++ b/include/linux/inet_diag.h
@@ -43,6 +43,21 @@ struct inet_diag_req_v2 {
struct inet_diag_sockid id;
};
+/*
+ * An alias for struct inet_diag_req_v2,
+ * @sdiag_raw_protocol member shadows
+ * @pad explicitly, it is done this way
+ * for backward compatibility sake.
+ */
+struct inet_diag_req_raw {
+ __u8 sdiag_family;
+ __u8 sdiag_protocol;
+ __u8 idiag_ext;
+ __u8 sdiag_raw_protocol;
+ __u32 idiag_states;
+ struct inet_diag_sockid id;
+};
+
enum {
INET_DIAG_REQ_NONE,
INET_DIAG_REQ_BYTECODE,
diff --git a/misc/ss.c b/misc/ss.c
index dd77b81..e8c4010 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -724,6 +724,7 @@ struct sockstat {
struct sockstat *next;
unsigned int type;
uint16_t prot;
+ uint16_t raw_prot;
inet_prefix local;
inet_prefix remote;
int lport;
@@ -2190,6 +2191,10 @@ static void parse_diag_msg(struct nlmsghdr *nlh, struct sockstat *s)
s->mark = 0;
if (tb[INET_DIAG_MARK])
s->mark = *(__u32 *) RTA_DATA(tb[INET_DIAG_MARK]);
+ if (tb[INET_DIAG_PROTOCOL])
+ s->raw_prot = *(__u8 *)RTA_DATA(tb[INET_DIAG_PROTOCOL]);
+ else
+ s->raw_prot = 0;
if (s->local.family == AF_INET)
s->local.bytelen = s->remote.bytelen = 4;
@@ -2384,7 +2389,7 @@ struct inet_diag_arg {
struct rtnl_handle *rth;
};
-static int kill_inet_sock(struct nlmsghdr *h, void *arg)
+static int kill_inet_sock(struct nlmsghdr *h, void *arg, struct sockstat *s)
{
struct inet_diag_msg *d = NLMSG_DATA(h);
struct inet_diag_arg *diag_arg = arg;
@@ -2399,6 +2404,13 @@ static int kill_inet_sock(struct nlmsghdr *h, void *arg)
req.r.sdiag_protocol = diag_arg->protocol;
req.r.id = d->id;
+ if (diag_arg->protocol == IPPROTO_RAW) {
+ struct inet_diag_req_raw *raw = (void *)&req.r;
+
+ BUILD_BUG_ON(sizeof(req.r) != sizeof(*raw));
+ raw->sdiag_raw_protocol = s->raw_prot;
+ }
+
return rtnl_talk(rth, &req.nlh, NULL, 0);
}
@@ -2418,7 +2430,7 @@ static int show_one_inet_sock(const struct sockaddr_nl *addr,
if (diag_arg->f->f && run_ssfilter(diag_arg->f->f, &s) == 0)
return 0;
- if (diag_arg->f->kill && kill_inet_sock(h, arg) != 0) {
+ if (diag_arg->f->kill && kill_inet_sock(h, arg, &s) != 0) {
if (errno == EOPNOTSUPP || errno == ENOENT) {
/* Socket can't be closed, or is already closed. */
return 0;
@@ -2715,6 +2727,10 @@ static int raw_show(struct filter *f)
dg_proto = RAW_PROTO;
+ if (!getenv("PROC_NET_RAW") && !getenv("PROC_ROOT") &&
+ inet_show_netlink(f, NULL, IPPROTO_RAW) == 0)
+ return 0;
+
if (f->families&(1<<AF_INET)) {
if ((fp = net_raw_open()) == NULL)
goto outerr;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net v2] packet: on direct_xmit, limit tso and csum to supported devices
From: Daniel Borkmann @ 2016-10-26 19:07 UTC (permalink / raw)
To: Willem de Bruijn, netdev; +Cc: davem, Willem de Bruijn
In-Reply-To: <1477495387-36861-1-git-send-email-willemdebruijn.kernel@gmail.com>
On 10/26/2016 05:23 PM, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> When transmitting on a packet socket with PACKET_VNET_HDR and
> PACKET_QDISC_BYPASS, validate device support for features requested
> in vnet_hdr.
>
> Drop TSO packets sent to devices that do not support TSO or have the
> feature disabled. Note that the latter currently do process those
> packets correctly, regardless of not advertising the feature.
>
> Because of SKB_GSO_DODGY, it is not sufficient to test device features
> with netif_needs_gso. Full validate_xmit_skb is needed.
>
> Switch to software checksum for non-TSO packets that request checksum
> offload if that device feature is unsupported or disabled. Note that
> similar to the TSO case, device drivers may perform checksum offload
> correctly even when not advertising it.
>
> When switching to software checksum, packets hit skb_checksum_help,
> which has two BUG_ON checksum not in linear segment. Packet sockets
> always allocate at least up to csum_start + csum_off + 2 as linear.
>
> Tested by running github.com/wdebruij/kerneltools/psock_txring_vnet.c
>
> ethtool -K eth0 tso off tx on
> psock_txring_vnet -d $dst -s $src -i eth0 -l 2000 -n 1 -q -v
> psock_txring_vnet -d $dst -s $src -i eth0 -l 2000 -n 1 -q -v -N
>
> ethtool -K eth0 tx off
> psock_txring_vnet -d $dst -s $src -i eth0 -l 1000 -n 1 -q -v -G
> psock_txring_vnet -d $dst -s $src -i eth0 -l 1000 -n 1 -q -v -G -N
>
> v2:
> - add EXPORT_SYMBOL_GPL(validate_xmit_skb_list)
>
> Fixes: d346a3fae3ff ("packet: introduce PACKET_QDISC_BYPASS socket option")
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 2/3] bpf: Add new cgroups prog type to enable sock modifications
From: Thomas Graf @ 2016-10-26 18:57 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, daniel, ast, daniel
In-Reply-To: <993982d6-7192-cde5-6fcb-a2fa04f93389@cumulusnetworks.com>
On 10/26/16 at 10:08am, David Ahern wrote:
> On 10/26/16 2:41 AM, Thomas Graf wrote:
> > On 10/25/16 at 03:30pm, David Ahern wrote:
> >> @@ -171,6 +177,9 @@ int __cgroup_bpf_run_filter(struct sock *sk,
> >> case BPF_CGROUP_INET_EGRESS:
> >> ret = __cgroup_bpf_run_filter_skb(skb, prog);
> >> break;
> >> + case BPF_CGROUP_INET_SOCK_CREATE:
> >> + ret = __cgroup_bpf_run_filter_sk_create(sk, prog);
> >> + break;
> >> /* make gcc happy else complains about missing enum value */
> >> default:
> >> return 0;
> >
> > Thinking further ahead of your simple example. Instead of adding yet
> > another prog type for the same hook, we can make this compatible with
> > BPF_CGROUP_INET_EGRESS instead which would then provide a ctx which
> > contains both, the sk and skb.
> >
> > The ctx concept is very flexible. We can keep the existing dummy skb
> > representation and add sk_ fields which are only valid for BPF at
> > socket layer, e.g skb->sk_bound_dev_if would translate to
> > sk->bound_dev_if.
> >
>
> It's an odd user semantic to me to put sock elements into the shadow sk_buff and to reuse BPF_CGROUP_INET_EGRESS.
>
> I can drop the _CREATE and just make it BPF_CGROUP_INET_SOCK so it works for any sock modification someone wants to add -- e.g., the port binding use case.
Your specific sk_alloc hook won't have an skb but the majority of
socket BPF programs will want to see both skb and sk. It is not
ideal to introduce a new bpf_prog_type for every minimal difference
in capability if the majority of capabilities and restrictions are
shared. Instead, the subtype approach was implemented by the Landlock
series looks much cleaner to me.
I think we should think about how to do this properly for all BPF
programs which operate in socket cgroup context.
^ permalink raw reply
* Re: [kernel-hardening] [RFC v4 03/18] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles
From: Jann Horn @ 2016-10-26 19:01 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, 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-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161026065654.19166-4-mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]
On Wed, Oct 26, 2016 at 08:56:39AM +0200, Mickaël Salaün wrote:
> This new arraymap looks like a set and brings new properties:
> * strong typing of entries: the eBPF functions get the array type of
> elements instead of CONST_PTR_TO_MAP (e.g.
> CONST_PTR_TO_LANDLOCK_HANDLE_FS);
> * force sequential filling (i.e. replace or append-only update), which
> allow quick browsing of all entries.
>
> This strong typing is useful to statically check if the content of a map
> can be passed to an eBPF function. For example, Landlock use it to store
> and manage kernel objects (e.g. struct file) instead of dealing with
> userland raw data. This improve efficiency and ensure that an eBPF
> program can only call functions with the right high-level arguments.
>
> The enum bpf_map_handle_type list low-level types (e.g.
> BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD) which are identified when
> updating a map entry (handle). This handle types are used to infer a
> high-level arraymap type which are listed in enum bpf_map_array_type
> (e.g. BPF_MAP_ARRAY_TYPE_LANDLOCK_FS).
>
> For now, this new arraymap is only used by Landlock LSM (cf. next
> commits) but it could be useful for other needs.
>
> Changes since v3:
> * make handle arraymap safe (RCU) and remove buggy synchronize_rcu()
> * factor out the arraymay walk
>
> Changes since v2:
> * add a RLIMIT_NOFILE-based limit to the maximum number of arraymap
> handle entries (suggested by Andy Lutomirski)
> * remove useless checks
>
> Changes since v1:
> * arraymap of handles replace custom checker groups
> * simpler userland API
[...]
> + case BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD:
> + handle_file = fget(handle->fd);
> + if (IS_ERR(handle_file))
> + return ERR_CAST(handle_file);
> + /* check if the FD is tied to a user mount point */
> + if (unlikely(handle_file->f_path.mnt->mnt_flags & MNT_INTERNAL)) {
> + fput(handle_file);
> + return ERR_PTR(-EINVAL);
> + }
> + path_get(&handle_file->f_path);
> + ret = kmalloc(sizeof(*ret), GFP_KERNEL);
> + ret->path = handle_file->f_path;
> + fput(handle_file);
You can use fdget() and fdput() here because the reference to
handle_file is dropped before the end of the syscall.
> + break;
> + case BPF_MAP_HANDLE_TYPE_UNSPEC:
> + default:
> + return ERR_PTR(-EINVAL);
> + }
> + ret->type = handle_type;
> + return ret;
> +}
> +
> +static void *nop_map_lookup_elem(struct bpf_map *map, void *key)
> +{
> + return ERR_PTR(-EINVAL);
> +}
> +
> +/* called from syscall or from eBPF program */
> +static int landlock_array_map_update_elem(struct bpf_map *map, void *key,
> + void *value, u64 map_flags)
> +{
This being callable from eBPF context is IMO pretty surprising and should
at least be well-documented. Also: What is the usecase here?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net] ibmvnic: Fix releasing of sub-CRQ IRQs in interrupt context
From: Thomas Falcon @ 2016-10-26 18:57 UTC (permalink / raw)
To: netdev
Schedule these XPORT event tasks in the shared workqueue
so that IRQs are not freed in an interrupt context when
sub-CRQs are released.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 35 ++++++++++++++++++++++++-----------
drivers/net/ethernet/ibm/ibmvnic.h | 1 +
2 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index bfe17d9..4d227d7 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3232,6 +3232,27 @@ static void ibmvnic_free_inflight(struct ibmvnic_adapter *adapter)
spin_unlock_irqrestore(&adapter->inflight_lock, flags);
}
+static void ibmvnic_xport_event(struct work_struct *work)
+{
+ struct ibmvnic_adapter *adapter = container_of(work,
+ struct ibmvnic_adapter,
+ ibmvnic_xport);
+ struct device *dev = &adapter->vdev->dev;
+ int rc;
+
+ ibmvnic_free_inflight(adapter);
+ release_sub_crqs(adapter);
+ if (adapter->migrated) {
+ rc = ibmvnic_reenable_crq_queue(adapter);
+ if (rc)
+ dev_err(dev, "Error after enable rc=%ld\n", rc);
+ adapter->migrated = false;
+ rc = ibmvnic_send_crq_init(adapter);
+ if (rc)
+ dev_err(dev, "Error sending init rc=%ld\n", rc);
+ }
+}
+
static void ibmvnic_handle_crq(union ibmvnic_crq *crq,
struct ibmvnic_adapter *adapter)
{
@@ -3267,15 +3288,7 @@ static void ibmvnic_handle_crq(union ibmvnic_crq *crq,
if (gen_crq->cmd == IBMVNIC_PARTITION_MIGRATED) {
dev_info(dev, "Re-enabling adapter\n");
adapter->migrated = true;
- ibmvnic_free_inflight(adapter);
- release_sub_crqs(adapter);
- rc = ibmvnic_reenable_crq_queue(adapter);
- if (rc)
- dev_err(dev, "Error after enable rc=%ld\n", rc);
- adapter->migrated = false;
- rc = ibmvnic_send_crq_init(adapter);
- if (rc)
- dev_err(dev, "Error sending init rc=%ld\n", rc);
+ schedule_work(&adapter->ibmvnic_xport);
} else if (gen_crq->cmd == IBMVNIC_DEVICE_FAILOVER) {
dev_info(dev, "Backing device failover detected\n");
netif_carrier_off(netdev);
@@ -3284,8 +3297,7 @@ static void ibmvnic_handle_crq(union ibmvnic_crq *crq,
/* The adapter lost the connection */
dev_err(dev, "Virtual Adapter failed (rc=%d)\n",
gen_crq->cmd);
- ibmvnic_free_inflight(adapter);
- release_sub_crqs(adapter);
+ schedule_work(&adapter->ibmvnic_xport);
}
return;
case IBMVNIC_CRQ_CMD_RSP:
@@ -3725,6 +3737,7 @@ static int ibmvnic_probe(struct vio_dev *dev, const struct vio_device_id *id)
SET_NETDEV_DEV(netdev, &dev->dev);
INIT_WORK(&adapter->vnic_crq_init, handle_crq_init_rsp);
+ INIT_WORK(&adapter->ibmvnic_xport, ibmvnic_xport_event);
spin_lock_init(&adapter->stats_lock);
diff --git a/drivers/net/ethernet/ibm/ibmvnic.h b/drivers/net/ethernet/ibm/ibmvnic.h
index bfc84c7..682057d 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@ -1048,5 +1048,6 @@ struct ibmvnic_adapter {
u8 map_id;
struct work_struct vnic_crq_init;
+ struct work_struct ibmvnic_xport;
bool failover;
};
--
1.8.3.1
^ permalink raw reply related
* Re: iproute: ss truncates abstract unix domain socket embedding null
From: Isaac Boukris @ 2016-10-26 18:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20161026101554.15d8d37b@xeon-e3>
Hi Stephen, thanks for looking into this.
On Wed, Oct 26, 2016 at 8:15 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> 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.
The motivation behind the fix is because the usage of abstract unix
domain socket is somewhat tricky.
I've seen it being used incorrectly where for example the addrlen was
specified as 'sizeof(struct sockaddr_un)' which is ok for regular unix
sockets because their names are null-terminated, but with abstract
sockets it causes extra null padding which leads to interoperability
problems.
On another occasion, addrlen was incremented to account for an
additional null-termination byte.
I was thinking therefore, it could help if the diagnostic tools would
show all the significant bytes of the name in order to make it clear
and easy to distinguish.
On the other hand, I think I've complicated it a little bit with the
'\0' escaping.
Perhaps it would suffice to substitute each null character with an '@'
sign, the same way we do for the null prefix.
As regarding netstat, I have in fact made a patch for it, but then I
realized it perhaps isn't its fault as it prints what it reads from
'/proc/net/unix' which prints the null prefix as '@' but leaves
subsequent nulls as is (literally, can be seen with 'cat -A').
So I'm trying to see if '/proc/net/unix' can be fixed to translate all
null occurrences to '@' sign (not only the prefix).
This should fix netstat and also (I think) the alternative 'proc' base
implementation in ss (unix_use_proc).
What do you think?
^ permalink raw reply
* Re: [PATCH net-next] tcp/dccp: drop SYN packets if accept queue is full
From: Neal Cardwell @ 2016-10-26 18:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Yuchung Cheng
In-Reply-To: <1477499277.7065.193.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, Oct 26, 2016 at 12:27 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 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>
> ---
Acked-by: Neal Cardwell <ncardwell@google.com>
Great. Thanks, Eric!
neal
^ permalink raw reply
* Re: [PATCH iproute2 net-next] tc: m_mirred: Fix parsing of 'index' optional argument
From: Stephen Hemminger @ 2016-10-26 18:23 UTC (permalink / raw)
To: Shmulik Ladkani; +Cc: Jamal Hadi Salim, netdev
In-Reply-To: <1477080075-17146-1-git-send-email-shmulik.ladkani@gmail.com>
On Fri, 21 Oct 2016 23:01:15 +0300
Shmulik Ladkani <shmulik.ladkani@gmail.com> wrote:
> Code in parse_mirred() suggests "index" argument can be placed either
> after the "egress" clause, or as the first argument (after "action mirred").
>
> However, parse_egress() fails to correctly parse "index" if it's the
> first argument.
>
> For example:
>
> # tc filter add ... action mirred index 5
> RTNETLINK answers: Invalid argument
> (unnecessary RTNETLINK issued, should have been parse error)
>
> # tc filter add ... action mirred index 5 egress redirect dev eth0
> bad action type egress
> (should have been parsed successfully)
>
> Fix parse_egress as follows:
> - continue parsing after valid "index" is seen
> - don't issue the RTNETLINK unless valid "egress" is seen
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Looks like a good fix but does not apply cleanly to current net-next branch.
Please cleanup and resubmit.
^ permalink raw reply
* Re: [PATCH iproute2 net-next] tc: m_mirred: Add support for ingress redirect/mirror
From: Stephen Hemminger @ 2016-10-26 18:21 UTC (permalink / raw)
To: Shmulik Ladkani; +Cc: Jamal Hadi Salim, netdev
In-Reply-To: <20161019141409.23172-1-shmulik.ladkani@gmail.com>
On Wed, 19 Oct 2016 17:14:09 +0300
Shmulik Ladkani <shmulik.ladkani@gmail.com> wrote:
> So far, only the 'egress' direction was implemented.
>
> Allow specifying 'ingress' as the direction packet appears on the target
> interface.
>
> For example, this takes incoming 802.1q frames on veth0 and redirects
> them for input on dummy0:
>
> # tc filter add dev veth0 parent ffff: pref 1 protocol 802.1q basic \
> action mirred ingress redirect dev dummy0
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Applied to net-next branch
^ permalink raw reply
* Re: nfs NULL-dereferencing in net-next
From: Anna Schumaker @ 2016-10-26 18:17 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Yotam Gigi, Andy Adamson, linux-nfs@vger.kernel.org,
netdev@vger.kernel.org, Trond Myklebust, Yotam Gigi, mlxsw
In-Reply-To: <20161026190840.3d46dad8@jkicinski-Precision-T1700>
On 10/26/2016 02:08 PM, Jakub Kicinski wrote:
> 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.
Well, it was worth a shot. I'll keep poking at it.
>
> 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
Interesting, I get that too when I try to use NFS v4.1. It's weird that the crash would stop happening like that, so maybe something is racy in this area.
Thanks for testing, Yotam and Jakub!
Anna
>
> HTH
>
^ permalink raw reply
* Re: [PATCH v3] iproute2: macvlan: add "source" mode
From: Stephen Hemminger @ 2016-10-26 18:11 UTC (permalink / raw)
To: Michael Braun; +Cc: netdev, projekt-wlan, steweg
In-Reply-To: <1474830535-12689-1-git-send-email-michael-dev@fami-braun.de>
On Sun, 25 Sep 2016 21:08:55 +0200
Michael Braun <michael-dev@fami-braun.de> wrote:
> Adjusting iproute2 utility to support new macvlan link type mode called
> "source".
>
> Example of commands that can be applied:
> ip link add link eth0 name macvlan0 type macvlan mode source
> ip link set link dev macvlan0 type macvlan macaddr add 00:11:11:11:11:11
> ip link set link dev macvlan0 type macvlan macaddr del 00:11:11:11:11:11
> ip link set link dev macvlan0 type macvlan macaddr flush
> ip -details link show dev macvlan0
>
> Based on previous work of Stefan Gula <steweg@gmail.com>
>
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
>
> Cc: steweg@gmail.com
> --
> v3: fix coding style, sorry for the noise
> ---
> include/linux/if_link.h | 2 +
> ip/iplink_macvlan.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++--
> man/man8/ip-link.8.in | 57 +++++++++++++++++++++++++++
> 3 files changed, 158 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> index 1feb708..ec5e64e 100644
> --- a/include/linux/if_link.h
> +++ b/include/linux/if_link.h
> @@ -401,6 +401,8 @@ enum macvlan_macaddr_mode {
> };
>
> #define MACVLAN_FLAG_NOPROMISC 1
> +#define MACVLAN_FLAG_UNICAST 2
> +#define MACVLAN_FLAG_UNICAST_ALL 4
These header changes are not in upstream source. Sorry, you have to get the kernel
changes in first. I am backing this out of iproute2
^ permalink raw reply
* 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
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