* [PATCH net-next 0/2] rtnetlink: new message for stats
From: Roopa Prabhu @ 2016-03-13 1:56 UTC (permalink / raw)
To: netdev; +Cc: jhs, davem
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds a new RTM_GETSTATS message to query link stats via
netlink from the kernel. RTM_NEWLINK also dumps stats today, but
RTM_NEWLINK returns a lot more than just stats and is expensive in some
cases when frequent polling for stats from userspace is a common operation.
RTM_GETSTATS is an attempt to provide a light weight netlink message
to explicity query only link stats from the kernel on an interface.
The idea is to also keep it extensible so that new kinds of stats can be
added to it in the future.
Roopa Prabhu (2):
rtnetlink: add new RTM_GETSTATS to dump link stats
ipv6: add support for stats via RTM_GETSTATS
Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
RFC to v1 (apologies for the delay in sending this version out. busy days):
- Addressed feedback from Dave
- removed rtnl_link_stats
- Added hdr struct if_stats_msg to carry ifindex and
filter mask
- new macro IFLA_STATS_FILTER_BIT(ATTR) for filter mask
- split the ipv6 patch into a separate patch, need some more eyes on it
- prefix attributes with IFLA_STATS instead of IFLA_LINK_STATS for shorter
attribute names
include/net/rtnetlink.h | 5 +
include/uapi/linux/if_link.h | 19 ++++
include/uapi/linux/rtnetlink.h | 7 ++
net/core/rtnetlink.c | 201 +++++++++++++++++++++++++++++++++++++++++
net/ipv6/addrconf.c | 77 ++++++++++++++--
5 files changed, 301 insertions(+), 8 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [patch net-next] rocker: move ageing_time from struct rocker to struct ofdpa
From: David Miller @ 2016-03-13 1:11 UTC (permalink / raw)
To: jiri; +Cc: netdev, sfeldma, idosch, eladr
In-Reply-To: <1457780607-21264-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sat, 12 Mar 2016 12:03:27 +0100
> From: Jiri Pirko <jiri@mellanox.com>
>
> This is OF-DPA specific, used only there, similar to
> ofdpa_port->ageing_time. So move it to OF-DPA code.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: SYN flooding on port 80 + DMAR:[DMA Write] faults
From: Francois Romieu @ 2016-03-13 0:11 UTC (permalink / raw)
To: Toralf Förster; +Cc: netdev, Linux Kernel
In-Reply-To: <56E4A30A.2060800@gmx.de>
Toralf Förster <toralf.foerster@gmx.de> :
> Today my server (64 bit hardened Gentoo kernel) was faced a SYN-flood attack.
> I do wonder if the DMAR events points to an issue in the kernel ?
Please send a compressed log including all 'fault addr' lines as well
as the (module probe time) XID line from the r8169 driver.
--
Ueimor
^ permalink raw reply
* [PATCH 2/2] mISDN: Support DR6 indication in mISDNipac driver
From: Maciej S. Szmigiero @ 2016-03-12 23:19 UTC (permalink / raw)
To: Karsten Keil; +Cc: netdev, linux-kernel
According to figure 39 in PEB3086 data sheet, version 1.4 this indication
replaces DR when layer 1 transition source state is F6.
This fixes mISDN layer 1 getting stuck in F6 state in TE mode on
Dialogic Diva 2.02 card (and possibly others) when NT deactivates it.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
---
drivers/isdn/hardware/mISDN/ipac.h | 1 +
drivers/isdn/hardware/mISDN/mISDNipac.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/isdn/hardware/mISDN/ipac.h b/drivers/isdn/hardware/mISDN/ipac.h
index 76aa6f8f298e..720ee72aab6a 100644
--- a/drivers/isdn/hardware/mISDN/ipac.h
+++ b/drivers/isdn/hardware/mISDN/ipac.h
@@ -217,6 +217,7 @@ struct ipac_hw {
#define ISAC_IND_SD 0x2
#define ISAC_IND_DIS 0x3
#define ISAC_IND_RSY 0x4
+#define ISAC_IND_DR6 0x5
#define ISAC_IND_EI 0x6
#define ISAC_IND_PU 0x7
#define ISAC_IND_ARD 0x8
diff --git a/drivers/isdn/hardware/mISDN/mISDNipac.c b/drivers/isdn/hardware/mISDN/mISDNipac.c
index cb428b9ee441..aa9b6c3cadc1 100644
--- a/drivers/isdn/hardware/mISDN/mISDNipac.c
+++ b/drivers/isdn/hardware/mISDN/mISDNipac.c
@@ -80,6 +80,7 @@ isac_ph_state_bh(struct dchannel *dch)
l1_event(dch->l1, HW_DEACT_CNF);
break;
case ISAC_IND_DR:
+ case ISAC_IND_DR6:
dch->state = 3;
l1_event(dch->l1, HW_DEACT_IND);
break;
@@ -660,6 +661,7 @@ isac_l1cmd(struct dchannel *dch, u32 cmd)
spin_lock_irqsave(isac->hwlock, flags);
if ((isac->state == ISAC_IND_EI) ||
(isac->state == ISAC_IND_DR) ||
+ (isac->state == ISAC_IND_DR6) ||
(isac->state == ISAC_IND_RS))
ph_command(isac, ISAC_CMD_TIM);
else
^ permalink raw reply related
* [PATCH 1/2] mISDN: Order IPAC register defines
From: Maciej S. Szmigiero @ 2016-03-12 23:18 UTC (permalink / raw)
To: Karsten Keil; +Cc: netdev, linux-kernel
It looks like IPAC/ISAC chips register defines weren't in any particular
order.
Order them by their number to make it easier to spot holes.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
---
drivers/isdn/hardware/mISDN/ipac.h | 40 +++++++++++++++++++-------------------
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/ipac.h b/drivers/isdn/hardware/mISDN/ipac.h
index 8121e046b739..76aa6f8f298e 100644
--- a/drivers/isdn/hardware/mISDN/ipac.h
+++ b/drivers/isdn/hardware/mISDN/ipac.h
@@ -99,32 +99,32 @@ struct ipac_hw {
/* All registers original Siemens Spec */
/* IPAC/ISAC registers */
-#define ISAC_MASK 0x20
#define ISAC_ISTA 0x20
-#define ISAC_STAR 0x21
+#define ISAC_MASK 0x20
#define ISAC_CMDR 0x21
+#define ISAC_STAR 0x21
+#define ISAC_MODE 0x22
+#define ISAC_TIMR 0x23
#define ISAC_EXIR 0x24
-#define ISAC_ADF2 0x39
+#define ISAC_RBCL 0x25
+#define ISAC_RSTA 0x27
+#define ISAC_RBCH 0x2A
#define ISAC_SPCR 0x30
-#define ISAC_ADF1 0x38
#define ISAC_CIR0 0x31
#define ISAC_CIX0 0x31
-#define ISAC_CIR1 0x33
-#define ISAC_CIX1 0x33
-#define ISAC_STCR 0x37
-#define ISAC_MODE 0x22
-#define ISAC_RSTA 0x27
-#define ISAC_RBCL 0x25
-#define ISAC_RBCH 0x2A
-#define ISAC_TIMR 0x23
-#define ISAC_SQXR 0x3b
-#define ISAC_SQRR 0x3b
-#define ISAC_MOSR 0x3a
-#define ISAC_MOCR 0x3a
#define ISAC_MOR0 0x32
#define ISAC_MOX0 0x32
+#define ISAC_CIR1 0x33
+#define ISAC_CIX1 0x33
#define ISAC_MOR1 0x34
#define ISAC_MOX1 0x34
+#define ISAC_STCR 0x37
+#define ISAC_ADF1 0x38
+#define ISAC_ADF2 0x39
+#define ISAC_MOCR 0x3a
+#define ISAC_MOSR 0x3a
+#define ISAC_SQRR 0x3b
+#define ISAC_SQXR 0x3b
#define ISAC_RBCH_XAC 0x80
@@ -212,13 +212,13 @@ struct ipac_hw {
#define ISAC_CMD_DUI 0xF
/* ISAC/ISACX/IPAC/IPACX L1 indications */
-#define ISAC_IND_RS 0x1
-#define ISAC_IND_PU 0x7
#define ISAC_IND_DR 0x0
+#define ISAC_IND_RS 0x1
#define ISAC_IND_SD 0x2
#define ISAC_IND_DIS 0x3
-#define ISAC_IND_EI 0x6
#define ISAC_IND_RSY 0x4
+#define ISAC_IND_EI 0x6
+#define ISAC_IND_PU 0x7
#define ISAC_IND_ARD 0x8
#define ISAC_IND_TI 0xA
#define ISAC_IND_ATI 0xB
@@ -339,9 +339,9 @@ struct ipac_hw {
#define ISACX__AUX 0x08
#define ISACX__CIC 0x10
#define ISACX__ST 0x20
+#define IPACX__ON 0x2C
#define IPACX__ICB 0x40
#define IPACX__ICA 0x80
-#define IPACX__ON 0x2C
/* ISACX/IPACX _CMDRD (W) */
#define ISACX_CMDRD_XRES 0x01
^ permalink raw reply related
* SYN flooding on port 80 + DMAR:[DMA Write] faults
From: Toralf Förster @ 2016-03-12 23:15 UTC (permalink / raw)
To: netdev; +Cc: Linux Kernel
Today my server (64 bit hardened Gentoo kernel) was faced a SYN-flood attack.
I do wonder if the DMAR events points to an issue in the kernel ?
Mar 12 21:56:51 ms-magpie kernel: [99582.831584] TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies. Check SNMP counters.
Mar 12 21:57:17 ms-magpie kernel: [99609.502567] ------------[ cut here ]------------
Mar 12 21:57:17 ms-magpie kernel: [99609.502575] WARNING: CPU: 2 PID: 18218 at net/sched/sch_generic.c:303 dev_watchdog+0x235/0x240()
Mar 12 21:57:17 ms-magpie kernel: [99609.502577] NETDEV WATCHDOG: enp3s0 (r8169): transmit queue 0 timed out
Mar 12 21:57:17 ms-magpie kernel: [99609.502578] Modules linked in: af_packet nf_log_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_log_ipv4 nf_log_common xt_LOG xt_multiport nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables hmac drbg tpm_tis tpm thermal processor atkbd i2c_i801 i2c_core button x86_pkg_temp_thermal
Mar 12 21:57:17 ms-magpie kernel: [99609.502601] CPU: 2 PID: 18218 Comm: cc1plus Not tainted 4.4.5-hardened #1
Mar 12 21:57:17 ms-magpie kernel: [99609.502603] Hardware name: System manufacturer System Product Name/P8H77-M PRO, BIOS 0922 09/10/2012
Mar 12 21:57:17 ms-magpie kernel: [99609.502605] ffffffff8b20482b 0000000000000286 0000000000000000 ffff88041fa83d98
Mar 12 21:57:17 ms-magpie kernel: [99609.502608] ffffffff8aad5247 0000000000000007 ffff88041fa83de0 ffffffff8afb6257
Mar 12 21:57:17 ms-magpie kernel: [99609.502611] ffff88041fa83dd0 ffffffff8a879e8c ffffffff8afb6257 000000000000012f
Mar 12 21:57:17 ms-magpie kernel: [99609.502614] Call Trace:
Mar 12 21:57:17 ms-magpie kernel: [99609.502616] <IRQ> [<ffffffff8aad5247>] dump_stack+0x4e/0x77
Mar 12 21:57:17 ms-magpie kernel: [99609.502625] [<ffffffff8a879e8c>] warn_slowpath_common+0x7c/0xc0
Mar 12 21:57:17 ms-magpie kernel: [99609.502627] [<ffffffff8a879f2b>] warn_slowpath_fmt+0x5b/0x70
Mar 12 21:57:17 ms-magpie kernel: [99609.502631] [<ffffffff8a8a9293>] ? __update_cpu_load+0xe3/0x140
Mar 12 21:57:17 ms-magpie kernel: [99609.502634] [<ffffffff8ac85cf5>] dev_watchdog+0x235/0x240
Mar 12 21:57:17 ms-magpie kernel: [99609.502637] [<ffffffff8ac85ac0>] ? dev_deactivate_queue+0x70/0x70
Mar 12 21:57:17 ms-magpie kernel: [99609.502640] [<ffffffff8a8cfdee>] call_timer_fn.isra.24+0x2e/0x90
Mar 12 21:57:17 ms-magpie kernel: [99609.502643] [<ffffffff8ac85ac0>] ? dev_deactivate_queue+0x70/0x70
Mar 12 21:57:17 ms-magpie kernel: [99609.502645] [<ffffffff8a8d0074>] run_timer_softirq+0x224/0x3b0
Mar 12 21:57:17 ms-magpie kernel: [99609.502649] [<ffffffff8a8de20f>] ? clockevents_program_event+0x7f/0x120
Mar 12 21:57:17 ms-magpie kernel: [99609.502652] [<ffffffff8a87db3f>] __do_softirq+0xef/0x1e0
Mar 12 21:57:17 ms-magpie kernel: [99609.502654] [<ffffffff8a87dd60>] irq_exit+0x80/0x90
Mar 12 21:57:17 ms-magpie kernel: [99609.502657] [<ffffffff8a839f2f>] smp_apic_timer_interrupt+0x4f/0x70
Mar 12 21:57:17 ms-magpie kernel: [99609.502662] [<ffffffff8ad5732b>] apic_timer_interrupt+0x8b/0x90
Mar 12 21:57:17 ms-magpie kernel: [99609.502663] <EOI>
Mar 12 21:57:17 ms-magpie kernel: [99609.502665] ---[ end trace 10603242d3d9404d ]---
Mar 12 21:57:17 ms-magpie kernel: [99609.519275] r8169 0000:03:00.0 enp3s0: link up
Mar 12 21:57:29 ms-magpie kernel: [99621.522005] r8169 0000:03:00.0 enp3s0: link up
Mar 12 21:57:41 ms-magpie kernel: [99633.518745] r8169 0000:03:00.0 enp3s0: link up
Mar 12 21:57:53 ms-magpie kernel: [99645.514461] r8169 0000:03:00.0 enp3s0: link up
Mar 12 21:58:05 ms-magpie kernel: [99657.525221] r8169 0000:03:00.0 enp3s0: link up
Mar 12 21:58:17 ms-magpie kernel: [99669.519938] r8169 0000:03:00.0 enp3s0: link up
Mar 12 21:58:35 ms-magpie kernel: [99687.513517] r8169 0000:03:00.0 enp3s0: link up
Mar 12 21:58:47 ms-magpie kernel: [99699.518283] r8169 0000:03:00.0 enp3s0: link up
Mar 12 21:58:59 ms-magpie kernel: [99711.512010] r8169 0000:03:00.0 enp3s0: link up
Mar 12 22:00:41 ms-magpie kernel: [99813.511713] r8169 0000:03:00.0 enp3s0: link up
Mar 12 22:00:53 ms-magpie kernel: [99825.510459] r8169 0000:03:00.0 enp3s0: link up
Mar 12 22:01:05 ms-magpie kernel: [99837.508171] r8169 0000:03:00.0 enp3s0: link up
Mar 12 22:01:05 ms-magpie kernel: [99837.518271] DMAR: DRHD: handling fault status reg 3
Mar 12 22:01:05 ms-magpie kernel: [99837.518277] DMAR: DMAR:[DMA Write] Request device [03:00.0] fault addr ffbfb000
Mar 12 22:01:05 ms-magpie kernel: [99837.518277] DMAR:[fault reason 05] PTE Write access is not set
Mar 12 22:01:05 ms-magpie kernel: [99837.523139] DMAR: DRHD: handling fault status reg 3
Mar 12 22:01:05 ms-magpie kernel: [99837.523144] DMAR: DMAR:[DMA Write] Request device [03:00.0] fault addr ffbf8000
Mar 12 22:01:05 ms-magpie kernel: [99837.523144] DMAR:[fault reason 05] PTE Write access is not set
Mar 12 22:01:05 ms-magpie kernel: [99837.523213] DMAR: DRHD: handling fault status reg 3
Mar 12 22:01:05 ms-magpie kernel: [99837.523217] DMAR: DMAR:[DMA Write] Request device [03:00.0] fault addr ffbf5000
Mar 12 22:01:05 ms-magpie kernel: [99837.523217] DMAR:[fault reason 05] PTE Write access is not set
Mar 12 22:01:05 ms-magpie kernel: [99837.523221] DMAR: DRHD: handling fault status reg 3
Mar 12 22:01:05 ms-magpie kernel: [99837.523227] DMAR: DMAR:[DMA Write] Request device [03:00.0] fault addr ffbf3000
Mar 12 22:01:05 ms-magpie kernel: [99837.523227] DMAR:[fault reason 05] PTE Write access is not set
Mar 12 22:01:05 ms-magpie kernel: [99837.523241] DMAR: DRHD: handling fault status reg 3
...
Mar 12 22:01:05 ms-magpie kernel: [99837.523507] DMAR: DMAR:[DMA Write] Request device [03:00.0] fault addr ffbcf000
Mar 12 22:01:05 ms-magpie kernel: [99837.523507] DMAR:[fault reason 05] PTE Write access is not set
Mar 12 22:01:17 ms-magpie kernel: [99849.505904] r8169 0000:03:00.0 enp3s0: link up
Mar 12 22:01:29 ms-magpie kernel: [99861.507679] r8169 0000:03:00.0 enp3s0: link up
Mar 12 22:01:41 ms-magpie kernel: [99873.509113] r8169 0000:03:00.0 enp3s0: link up
Mar 12 22:01:53 ms-magpie kernel: [99885.507166] r8169 0000:03:00.0 enp3s0: link up
Mar 12 22:02:05 ms-magpie kernel: [99897.509888] r8169 0000:03:00.0 enp3s0: link up
Mar 12 22:02:17 ms-magpie kernel: [99909.508613] r8169 0000:03:00.0 enp3s0: link up
...
Mar 13 00:00:35 ms-magpie kernel: [107007.349774] r8169 0000:03:00.0 enp3s0: link up
Mar 13 00:01:23 ms-magpie kernel: [107055.350767] r8169 0000:03:00.0 enp3s0: link up
<rebooted>
--
Toralf
PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
^ permalink raw reply
* [PATCH] sh_eth: kill useless initializers
From: Sergei Shtylyov @ 2016-03-12 22:29 UTC (permalink / raw)
To: netdev, linux-renesas-soc
Some of the local variable intializers in the driver turned out to be
pointless, kill 'em.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against the DaveM's 'net-next.git' repo.
drivers/net/ethernet/renesas/sh_eth.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -447,8 +447,8 @@ static bool sh_eth_is_rz_fast_ether(stru
static void sh_eth_select_mii(struct net_device *ndev)
{
- u32 value = 0x0;
struct sh_eth_private *mdp = netdev_priv(ndev);
+ u32 value;
switch (mdp->phy_interface) {
case PHY_INTERFACE_MODE_GMII:
@@ -1231,8 +1231,8 @@ ring_free:
static int sh_eth_dev_init(struct net_device *ndev, bool start)
{
- int ret = 0;
struct sh_eth_private *mdp = netdev_priv(ndev);
+ int ret;
/* Soft Reset */
ret = sh_eth_reset(ndev);
@@ -1355,7 +1355,7 @@ static int sh_eth_txfree(struct net_devi
struct sh_eth_private *mdp = netdev_priv(ndev);
struct sh_eth_txdesc *txdesc;
int free_num = 0;
- int entry = 0;
+ int entry;
for (; mdp->cur_tx - mdp->dirty_tx > 0; mdp->dirty_tx++) {
entry = mdp->dirty_tx % mdp->num_tx_ring;
@@ -1396,10 +1396,10 @@ static int sh_eth_rx(struct net_device *
int boguscnt = (mdp->dirty_rx + mdp->num_rx_ring) - mdp->cur_rx;
int limit;
struct sk_buff *skb;
- u16 pkt_len = 0;
u32 desc_status;
int skbuff_size = mdp->rx_buf_sz + SH_ETH_RX_ALIGN + 32 - 1;
dma_addr_t dma_addr;
+ u16 pkt_len;
u32 buf_len;
boguscnt = min(boguscnt, *quota);
@@ -1778,7 +1778,7 @@ static int sh_eth_phy_init(struct net_de
{
struct device_node *np = ndev->dev.parent->of_node;
struct sh_eth_private *mdp = netdev_priv(ndev);
- struct phy_device *phydev = NULL;
+ struct phy_device *phydev;
mdp->link = 0;
mdp->speed = 0;
@@ -2232,8 +2232,8 @@ static const struct ethtool_ops sh_eth_e
/* network device open function */
static int sh_eth_open(struct net_device *ndev)
{
- int ret = 0;
struct sh_eth_private *mdp = netdev_priv(ndev);
+ int ret;
pm_runtime_get_sync(&mdp->pdev->dev);
@@ -2988,12 +2988,12 @@ static inline struct sh_eth_plat_data *s
static int sh_eth_drv_probe(struct platform_device *pdev)
{
- int ret, devno = 0;
struct resource *res;
- struct net_device *ndev = NULL;
- struct sh_eth_private *mdp = NULL;
struct sh_eth_plat_data *pd = dev_get_platdata(&pdev->dev);
const struct platform_device_id *id = platform_get_device_id(pdev);
+ struct sh_eth_private *mdp;
+ struct net_device *ndev;
+ int ret, devno;
/* get base addr */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
^ permalink raw reply
* [PATCH v2 3/3] of_mdio: use PTR_ERR_OR_ZERO()
From: Sergei Shtylyov @ 2016-03-12 21:34 UTC (permalink / raw)
To: grant.likely, robh+dt, devicetree, f.fainelli, netdev,
frowand.list
In-Reply-To: <2682275.WNlbxTfNal@wasted.cogentembedded.com>
PTR_ERR_OR_ZERO() is open coded in of_phy_register_fixed_link(), so just
call it directly...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
---
Changes in version 2:
- added the "Reviewed-by:" tags.
drivers/of/of_mdio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: net-next/drivers/of/of_mdio.c
===================================================================
--- net-next.orig/drivers/of/of_mdio.c
+++ net-next/drivers/of/of_mdio.c
@@ -412,7 +412,7 @@ int of_phy_register_fixed_link(struct de
if (strcmp(managed, "in-band-status") == 0) {
/* status is zeroed, namely its .link member */
phy = fixed_phy_register(PHY_POLL, &status, -1, np);
- return IS_ERR(phy) ? PTR_ERR(phy) : 0;
+ return PTR_ERR_OR_ZERO(phy);
}
}
@@ -434,7 +434,7 @@ int of_phy_register_fixed_link(struct de
return -EPROBE_DEFER;
phy = fixed_phy_register(PHY_POLL, &status, link_gpio, np);
- return IS_ERR(phy) ? PTR_ERR(phy) : 0;
+ return PTR_ERR_OR_ZERO(phy);
}
/* Old binding */
@@ -446,7 +446,7 @@ int of_phy_register_fixed_link(struct de
status.pause = be32_to_cpu(fixed_link_prop[3]);
status.asym_pause = be32_to_cpu(fixed_link_prop[4]);
phy = fixed_phy_register(PHY_POLL, &status, -1, np);
- return IS_ERR(phy) ? PTR_ERR(phy) : 0;
+ return PTR_ERR_OR_ZERO(phy);
}
return -ENODEV;
^ permalink raw reply
* [PATCH v2 2/3] of_mdio: use IS_ERR_OR_NULL()
From: Sergei Shtylyov @ 2016-03-12 21:34 UTC (permalink / raw)
To: grant.likely, robh+dt, devicetree, f.fainelli, netdev,
frowand.list
In-Reply-To: <2682275.WNlbxTfNal@wasted.cogentembedded.com>
IS_ERR_OR_NULL() is open coded in of_mdiobus_register_phy(), so just call
it directly...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in version 2:
- removed the of_mdiobus_register_device() hunk;
- added the "Reviewed-by:" tag.
drivers/of/of_mdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/drivers/of/of_mdio.c
===================================================================
--- net-next.orig/drivers/of/of_mdio.c
+++ net-next/drivers/of/of_mdio.c
@@ -56,7 +56,7 @@ static int of_mdiobus_register_phy(struc
phy = phy_device_create(mdio, addr, phy_id, 0, NULL);
else
phy = get_phy_device(mdio, addr, is_c45);
- if (!phy || IS_ERR(phy))
+ if (IS_ERR_OR_NULL(phy))
return 1;
rc = irq_of_parse_and_map(child, 0);
^ permalink raw reply
* [PATCH v2 1/3] of_mdio: mdio_device_create() never returns NULL
From: Sergei Shtylyov @ 2016-03-12 21:33 UTC (permalink / raw)
To: grant.likely, robh+dt, devicetree, f.fainelli, netdev,
frowand.list
In-Reply-To: <2682275.WNlbxTfNal@wasted.cogentembedded.com>
mdio_device_create() never returns NULL, thus checking for it in
of_mdiobus_register_device() is pointless...
Suggested-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- new patch.
drivers/of/of_mdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/drivers/of/of_mdio.c
===================================================================
--- net-next.orig/drivers/of/of_mdio.c
+++ net-next/drivers/of/of_mdio.c
@@ -98,7 +98,7 @@ static int of_mdiobus_register_device(st
int rc;
mdiodev = mdio_device_create(mdio, addr);
- if (!mdiodev || IS_ERR(mdiodev))
+ if (IS_ERR(mdiodev))
return 1;
/* Associate the OF node with the device structure so it
^ permalink raw reply
* [PATCH v2 0/3] of_mdio: use IS_ERR_OR_NULL() and PTR_ERR_OR_ZERO()
From: Sergei Shtylyov @ 2016-03-12 21:32 UTC (permalink / raw)
To: grant.likely, robh+dt, devicetree, f.fainelli, netdev,
frowand.list
Hello.
Here's the set of 3 patches against DaveM's 'net-next.git' repo. They deal
with some error checks in the device tree MDIO code...
[1/3] of_mdio: mdio_device_create() never returns NULL
[2/3] of_mdio: use IS_ERR_OR_NULL()
[3/3] of_mdio: use PTR_ERR_OR_ZERO()
MBR, Sergei
^ permalink raw reply
* Re: [PATCH -next] bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict
From: Sergei Shtylyov @ 2016-03-12 19:20 UTC (permalink / raw)
To: Florian Westphal, netdev; +Cc: stephen, Felix Fietkau, Zefir Kurtisi
In-Reply-To: <1457777682-24689-1-git-send-email-fw@strlen.de>
Hello.
On 03/12/2016 01:14 PM, Florian Westphal wrote:
> Zefir Kurtisi reported kernel panic with an openwrt specific patch.
> However, it turns out that mainline has a similar bug waiting to happen.
>
> Once NF_HOOK() returns the skb is in undefined state and must not be
> used. Moreover, the okfn must consume the skb to support async
> processing (NF_QUEUE).
>
> Current okfn in this spot doesn't consume it and caller assumes that
> NF_HOOK return value tells us if skb was freed or not, but thats wrong.
That's.
> It "works" because no in-tree user registers a NFPROTO_BRIDGE hook at
> LOCAL_IN that returns STOLEN or NF_QUEUE verdicts.
>
> Once we add NF_QUEUE support for nftables bridge this will break --
> NF_QUEUE holds the skb for async processing, caller will erronoulsy
Erroneously.
> return RX_HANDLER_PASS and on reinject netfilter will access free'd skb.
>
> Fix this by pushing skb up the stack in the okfn instead.
>
> NB: It also seems dubious to use LOCAL_IN while bypassing PRE_ROUTING
> completely in this case but this is how its been forever so it seems
> preferable to not change this.
>
> Cc: Felix Fietkau <nbd@openwrt.org>
> Cc: Zefir Kurtisi <zefir.kurtisi@neratec.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net v3.16]r8169: Not enable/disable bus mastering when is enabled on BIOS
From: Sergei Shtylyov @ 2016-03-12 19:09 UTC (permalink / raw)
To: Corcodel Marian, netdev; +Cc: Francois Romieu
In-Reply-To: <1457764426-6578-1-git-send-email-asd@marian1000.go.ro>
Hello.
On 03/12/2016 09:33 AM, Corcodel Marian wrote:
> This patch not enable/disable bus mastering when is enabled on BIOS..
> pci_disable_device function also disable bus mastering for, disable bus mastering
> is dedicate function.
>
> Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
> ---
> drivers/net/ethernet/realtek/r8169.c | 29 ++++++++++++++++++++++++++---
> 1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 02aec96..ec555e7 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> @@ -7103,7 +7120,13 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> rtl_ack_events(tp, 0xffff);
>
> - pci_set_master(pdev);
> + pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> + if (cmd & PCI_COMMAND_MASTER)
> + tp->bios_support = true;
> + else {
Documentation/CodingStyle requites {} on all branches of the *if*
statement if at least one branch has them.
> + tp->bios_support = false;
> + pci_set_master(pdev);
> + }
>
> /*
> * Pretend we are using VLANs; This bypasses a nasty bug where
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver
From: Oliver Hartkopp @ 2016-03-12 18:49 UTC (permalink / raw)
To: Ramesh Shanmugasundaram, Marc Kleine-Budde, wg@grandegger.com,
robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
corbet@lwn.net
Cc: linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, geert+renesas@glider.be,
Chris Paterson
In-Reply-To: <KL1PR06MB10315B45ADA2037A5AA85A56C3B50@KL1PR06MB1031.apcprd06.prod.outlook.com>
Hi Ramesh,
On 03/11/2016 08:14 AM, Ramesh Shanmugasundaram wrote:
> As we are fixing this issue in CAN dev.c, I'll remove this check in ndo_open and set CAN_CTRLMODE_FD flag in ctrlmode & remove the flag in ctrlmode_supported in the next v3 version of the patch.
I posted a V2 version of that fix some minutes ago.
It also adds some documentation and a new variable ctrlmode_static which
makes it clear how to specify static/fixed control modes.
Please use the new can_set_static_ctrlmode() helper as suggested in the
changes for m_can.c.
A feedback is welcome whether this new fix fits your expectations.
> Are there any further comments on v2 patch please?
Besides the stuff I wrote above: No :-)
Best regards,
Oliver
^ permalink raw reply
* [PATCH net v2 4/4] net: mvneta: replace magic numbers by existing macros
From: Gregory CLEMENT @ 2016-03-12 17:44 UTC (permalink / raw)
To: David S. Miller, linux-kernel, netdev, Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
linux-arm-kernel, Lior Amsalem, Nadav Haklai, Marcin Wojtas,
Patrick Uiterwijk, Dimitri Epshtein, Ofer Heifetz
In-Reply-To: <1457804660-8463-1-git-send-email-gregory.clement@free-electrons.com>
From: Dmitri Epshtein <dima@marvell.com>
Some literal values are actually already defined by macros, so let's use
them.
[gregory.clement@free-electrons.com: split intial commit in two
individual changes]
Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 58ad36876e8b..225d933259c0 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -880,7 +880,7 @@ static void mvneta_port_down(struct mvneta_port *pp)
mdelay(1);
val = mvreg_read(pp, MVNETA_RXQ_CMD);
- } while (val & 0xff);
+ } while (val & MVNETA_RXQ_ENABLE_MASK);
/* Stop Tx port activity. Check port Tx activity. Issue stop
* command for active channels only
@@ -905,7 +905,7 @@ static void mvneta_port_down(struct mvneta_port *pp)
/* Check TX Command reg that all Txqs are stopped */
val = mvreg_read(pp, MVNETA_TXQ_CMD);
- } while (val & 0xff);
+ } while (val & MVNETA_TXQ_ENABLE_MASK);
/* Double check to verify that TX FIFO is empty */
count = 0;
--
2.5.0
^ permalink raw reply related
* [PATCH net v2 0/4] Few mvneta fixes
From: Gregory CLEMENT @ 2016-03-12 17:44 UTC (permalink / raw)
To: David S. Miller, linux-kernel, netdev, Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
linux-arm-kernel, Lior Amsalem, Nadav Haklai, Marcin Wojtas,
Patrick Uiterwijk, Dimitri Epshtein, Ofer Heifetz
Hi David,
In this second version I split the last patch in two parts as
requested.
For the record the initial cover letter was:
"here is a patch set of few fixes. Without the first one, a kernel
configured with debug features ended to hang when the driver is built
as a module and is removed. This is quite is annoying for debugging!
The second patch fix a forgotten flag at the initial submission of the
driver.
The third patch is only really a cosmetic one so I have no problem to
not apply it for 4.5 and wait for 4.6.
I really would like to see the first one applied for 4.5 and for the
second I let you judge if it something needed for now or that should
wait the next release."
Thanks,
Gregory
Dmitri Epshtein (3):
net: mvneta: enable change MAC address when interface is up
net: mvneta: fix error messages in mvneta_port_down function
net: mvneta: replace magic numbers by existing macros
Gregory CLEMENT (1):
net: mvneta: Fix spinlock usage
drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
--
2.5.0
^ permalink raw reply
* [PATCH net v2 2/4] net: mvneta: enable change MAC address when interface is up
From: Gregory CLEMENT @ 2016-03-12 17:44 UTC (permalink / raw)
To: David S. Miller, linux-kernel, netdev, Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
linux-arm-kernel, Lior Amsalem, Nadav Haklai, Marcin Wojtas,
Patrick Uiterwijk, Dimitri Epshtein, Ofer Heifetz, stable
In-Reply-To: <1457804660-8463-1-git-send-email-gregory.clement@free-electrons.com>
From: Dmitri Epshtein <dima@marvell.com>
Function eth_prepare_mac_addr_change() is called as part of MAC
address change. This function check if interface is running.
To enable change MAC address when interface is running:
IFF_LIVE_ADDR_CHANGE flag must be set to dev->priv_flags field
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP
network unit")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 8dc7df2edff6..2ee05cebea75 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3721,7 +3721,7 @@ static int mvneta_probe(struct platform_device *pdev)
dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
dev->hw_features |= dev->features;
dev->vlan_features |= dev->features;
- dev->priv_flags |= IFF_UNICAST_FLT;
+ dev->priv_flags |= IFF_UNICAST_FLT | IFF_LIVE_ADDR_CHANGE;
dev->gso_max_segs = MVNETA_MAX_TSO_SEGS;
err = register_netdev(dev);
--
2.5.0
^ permalink raw reply related
* [PATCH net v2 3/4] net: mvneta: fix error messages in mvneta_port_down function
From: Gregory CLEMENT @ 2016-03-12 17:44 UTC (permalink / raw)
To: David S. Miller, linux-kernel, netdev, Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
linux-arm-kernel, Lior Amsalem, Nadav Haklai, Marcin Wojtas,
Patrick Uiterwijk, Dimitri Epshtein, Ofer Heifetz
In-Reply-To: <1457804660-8463-1-git-send-email-gregory.clement@free-electrons.com>
From: Dmitri Epshtein <dima@marvell.com>
This commit corrects error printing when shutting down the port.
[gregory.clement@free-electrons.com: split initial commit in two
individual changes]
Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 2ee05cebea75..58ad36876e8b 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -873,7 +873,7 @@ static void mvneta_port_down(struct mvneta_port *pp)
do {
if (count++ >= MVNETA_RX_DISABLE_TIMEOUT_MSEC) {
netdev_warn(pp->dev,
- "TIMEOUT for RX stopped ! rx_queue_cmd: 0x08%x\n",
+ "TIMEOUT for RX stopped ! rx_queue_cmd: 0x%08x\n",
val);
break;
}
@@ -912,7 +912,7 @@ static void mvneta_port_down(struct mvneta_port *pp)
do {
if (count++ >= MVNETA_TX_FIFO_EMPTY_TIMEOUT) {
netdev_warn(pp->dev,
- "TX FIFO empty timeout status=0x08%x\n",
+ "TX FIFO empty timeout status=0x%08x\n",
val);
break;
}
--
2.5.0
^ permalink raw reply related
* [PATCH net v2 1/4] net: mvneta: Fix spinlock usage
From: Gregory CLEMENT @ 2016-03-12 17:44 UTC (permalink / raw)
To: David S. Miller, linux-kernel, netdev, Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
linux-arm-kernel, Lior Amsalem, Nadav Haklai, Marcin Wojtas,
Patrick Uiterwijk, Dimitri Epshtein, Ofer Heifetz
In-Reply-To: <1457804660-8463-1-git-send-email-gregory.clement@free-electrons.com>
In the previous patch, the spinlock was not initialized. While it didn't
cause any trouble yet it could be a problem to use it uninitialized.
The most annoying part was the critical section protected by the spinlock
in mvneta_stop(). Some of the functions could sleep as pointed when
activated CONFIG_DEBUG_ATOMIC_SLEEP. Actually, in mvneta_stop() we only
need to protect the is_stopped flagged, indeed the code of the notifier
for CPU online is protected by the same spinlock, so when we get the
lock, the notifer work is done.
Reported-by: Patrick Uiterwijk <patrick@puiterwijk.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/ethernet/marvell/mvneta.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index b0ae69f84493..8dc7df2edff6 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3070,17 +3070,17 @@ static int mvneta_stop(struct net_device *dev)
struct mvneta_port *pp = netdev_priv(dev);
/* Inform that we are stopping so we don't want to setup the
- * driver for new CPUs in the notifiers
+ * driver for new CPUs in the notifiers. The code of the
+ * notifier for CPU online is protected by the same spinlock,
+ * so when we get the lock, the notifer work is done.
*/
spin_lock(&pp->lock);
pp->is_stopped = true;
+ spin_unlock(&pp->lock);
+
mvneta_stop_dev(pp);
mvneta_mdio_remove(pp);
unregister_cpu_notifier(&pp->cpu_notifier);
- /* Now that the notifier are unregistered, we can release le
- * lock
- */
- spin_unlock(&pp->lock);
on_each_cpu(mvneta_percpu_disable, pp, true);
free_percpu_irq(dev->irq, pp->ports);
mvneta_cleanup_rxqs(pp);
@@ -3612,6 +3612,7 @@ static int mvneta_probe(struct platform_device *pdev)
dev->ethtool_ops = &mvneta_eth_tool_ops;
pp = netdev_priv(dev);
+ spin_lock_init(&pp->lock);
pp->phy_node = phy_node;
pp->phy_interface = phy_mode;
--
2.5.0
^ permalink raw reply related
* Re: [RFC PATCH net-next 2/2] phy: fixed-phy: Allow DT description of an MDIO bus and PHYs.
From: Andrew Lunn @ 2016-03-12 17:32 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <56E35530.6000009@gmail.com>
> One too many " here.
>
> > +- #address-cells = <1>;
> > +- #size-cells = <0>;
> > +
> > +Child nodes represent PHYs on this mdio bus. Standard properties for
> > +fixed links, 'speed', 'full-duplex', 'pause', 'asym-pause',
> > +'link-gpios', as defined above are used. Additionally a 'reg' property
> > +is required for the address of the PHY on the bus. This should be of
> > +value 0 to 31.
>
> This is a virtual bus, the only limitation is because we re-use to the
> maximum permission extent the real MDIO bus code, and this is putting a
> SW constraint on something that does not have one here.
Hi Florian
I now took a look at the core code. PHY_MAX_ADDR is used in quite a
few places, e.g. phy_find_first(), of_mdiobus_link_phydev(),
__mdiobus_register(). In order to be able to use this virtual MDIO bus
just like any other MDIO bus, we need to enforce PHY_MAX_ADDR.
Otherwise it is not going to work.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 5/5] phy: fixed: Fix removal of phys.
From: Andrew Lunn @ 2016-03-12 17:24 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David Miller, netdev, Vivien Didelot
In-Reply-To: <56E35250.6020101@gmail.com>
> > +void fixed_phy_unregister(struct phy_device *phy)
> > +{
> > + phy_device_remove(phy);
> > +
> > + fixed_phy_del(phy->mdio.addr);
>
> fixed_phy_del() should also make sure that there is no dangling
> link_update callback registered, even though this is not fatal, as it
> checks whether the phydev is NULL, we should automatically unregister
> one by doing something like: fixed_phy_set_link_update(phydev, NULL) for
> robustness.
Hi Florian
I don't see how it could happen. The link_update callback is only
called from fixed_mdio_read(). But we have just called
phy_device_remove(). There should not be anything using
fixed_mdio_read() after that. Also, fixed_phy_del() first removes fp
from the list of fmb->phys, meaning it is no longer possible to find
it, and then kfree(fp). So if there is some way we have a dangling
link_update, we are in big trouble, and the locking is badly broken...
Andrew
^ permalink raw reply
* Re: [PATCH RFC v2 00/32] Make DSA switches linux devices.
From: Andrew Lunn @ 2016-03-12 17:08 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Vivien Didelot, netdev
In-Reply-To: <56E357C7.7090309@gmail.com>
> [snip]
>
> >
> > The third switch is as you would expect, dsa,member = <0 2>;
>
> I like that representation.
>
...
> So does that mean you agree we do not need the DSA platform device
> anymore :)?
It looks like it can be done without the DSA platform device.
My previous approach was to keep the new binding as similar as
possible to the current one. If however, we decide we are going for
something totally new, we can remove this platform device.
It probably means we need to turn slave.c and parts of dsa.c into a
library. Add a new dsa_v2.c file, containing the new binding
code. With things like having the switch devices instantiate there own
MDIO bus, fixed phys on a compatible MDIO bus referenced via phandles,
etc, I hope we can make parts of the dsa_v2 simpler.
> Very true, we support a wide variety of setups, and that creates a lot
> of complexity that could probably be absorbed by a more generic helper
> function?
No, i want to go the other direction. Make all these phy setups look
identical. It is just a phy-handle=<&phandle> property. With my MDIO
fixed-phy bus patches, it just works for user ports, and the only
thing we need to deal with is phy-mode.
DSA and CPU ports are harder, due to a lack of a netdev. Horrible, but
maybe would could do a alloc_netdev(), but never register_netdev()?
It gives us something to attach the phy to.
> > 1) The switch device should use mdiobus_alloc()/mdiobus_register() for
> > its own MDIO bus.
>
> Agreed, possibly with the help of the DSA slave code, since some of that
> is already doing its magic for most drivers here.
I think the switch driver should instantiate the MDIO bus, not the
core. The core could however offer some helper code.
Andrew
^ permalink raw reply
* Re: [v6, 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Wolfram Sang @ 2016-03-12 15:52 UTC (permalink / raw)
To: Yangbo Lu
Cc: devicetree, linux-arm-kernel, linux-kernel, linuxppc-dev,
linux-clk, linux-i2c, iommu, netdev, linux-mmc, Rob Herring,
scott.wood, Russell King, Jochen Friedrich, Joerg Roedel,
Claudiu Manoil, ulf.hansson, Bhupesh Sharma, Zhao Qiang,
Kumar Gala, Santosh Shilimkar, leoyang.li, xiaobo.xie
In-Reply-To: <1457518131-11339-5-git-send-email-yangbo.lu@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Wed, Mar 09, 2016 at 06:08:50PM +0800, Yangbo Lu wrote:
> Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
> a common header file. It has been used for mpc85xx and it will
> be used for ARM-based SoC as well.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
From a glimpse, looks like proper refactoring. Thanks!
For the I2C part:
Acked-by: Wolfram Sang <wsa@the-dreams.de>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: userns, netns, and quick physical memory consumption by unprivileged user
From: Yuriy M. Kaminskiy @ 2016-03-12 13:35 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, containers
In-Reply-To: <20160311153406.GB6620@breakpoint.cc>
On 03/11/16 18:34 , Florian Westphal wrote:
> Yuriy M. Kaminskiy <yumkam@gmail.com> wrote:
>> BTW, all those hash/conntrack/etc default sizes was calculated from
>> physical memory size in assumption there will be only *one* instance of
>> those tables. Obviously, introduction of network namespaces (and
>> especially unprivileged user-ns) thrown this assumption in the window
>> (and here comes that "falling back to vmalloc" message again; in pre-netns
>> world, those tables were allocated *once* on early system startup, with
>> typically plenty of free and unfragmented memory).
>
> No idea how to fix this expect by removing conntrack support in net
> namespaces completely.
Well, it is not *only* conntrack. Conntrack eats big chunks at once, but
there are other things that eat kernel memory too: *any* iptables
rules, 'ip address', 'ip link' (at very least, 'type dummy' and
/dev/net/tun are available inside unprivileged userns/netns), 'ip
tunnel', 'ip rule', 'ip route', etc.
Just add *a lot* of them (and over several netns to avoid potential
O(n^2) behaviour on adding), and it will be painful, regardless of
memcg/ulimits/free swap/etc.
E.g. something like
unshare -rn sh -c 'setsid sleep inf & for i in 1 1024; do
ip li add d$i type dummy; ip li set d$i up;done'
eats ~40M kernel memory each (unswappable and not curbed by memcg),
that's way more than conntrack hashtables alone.
At *very minimum*, all that must be limited by memcg (it is not
currently!). And maybe by ulimits too (of process that created userns?
well, natural choice of RLIMIT_MEMLOCK practically forbids netns, no
chance it will fit in 64k).
Specifically with conntrack, separate limits on hash size/entries for
non-initns won't harm, but that's more of "flexibility to avoid
senseless waste of memory" (in case specific container won't use many
connection or won't use conntrack at all) than protection against abuse.
By the way, there are unrestrained kernel memory consumption in *other*
namespace types too. E.g., let's look at mount namespace; it looks like
tmpfs contents is at least curbed by memcg [but *not* curbed by
ulimits!], however *mounts itself* are not; e.g.
unshare -rm sh -c 'while :; do seq -f /tmp/foo%g 1 1024|
while read d; do mkdir -p $d; mount --bind $d $d;done'
is a bit slower [try with several instances?], but end result
would be same).
> I'd disallow all write accesses to skb->nfct (NAT, CONNMARK,
> CONNSECMARK, ...) and then no longer clear skb->nfct when forwarding
> packet from init_ns to container.
>
> Containers could then still test conntrack as seen from init namespace pov
> in PREROUTING/FORWARD/INPUT (but not OUTPUT, obviously).
>
> [ OUTPUT *might* be doable as well by allowing NEW creation in output
> but skipping nat and deferring the confirmation/commit of the new
> entry to the table until skb leaves initns ]
>
> We could key conntrack entries to initns conntrack table
> instead of adding one new table per netns, but seems like this only
> replaces one problem with a new one (filling/blocking initns table from
> another netns).
>
> Maybe we could go with a compromise and skip/disallow conntrack in
> unpriv userns only?
^ permalink raw reply
* Re: [PATCH V7] netfilter: h323: avoid potential attack
From: Pablo Neira Ayuso @ 2016-03-12 12:19 UTC (permalink / raw)
To: Zhouyi Zhou
Cc: eric.dumazet, kaber, kadlec, davem, netfilter-devel, coreteam,
netdev, linux-kernel, fw, gnomes, sergei.shtylyov, Zhouyi Zhou
In-Reply-To: <1455984239-5807-1-git-send-email-zhouzhouyi@gmail.com>
On Sun, Feb 21, 2016 at 12:03:59AM +0800, Zhouyi Zhou wrote:
> I think hackers chould build a malicious h323 packet to overflow
> the pointer p which will panic during the memcpy(addr, p, len)
> For example, he may fabricate a very large taddr->ipAddress.ip in
> function get_h225_addr.
>
> To avoid above, I add buffer boundary checking both in get addr
> functions and set addr functions.
>
> Because the temporary h323 buffer is dynamiclly allocated, I remove
> the h323 spin lock in my patch.
>
> Signed-off-by: Zhouyi Zhou <yizhouzhou@ict.ac.cn>
> ---
> include/linux/netfilter/nf_conntrack_h323.h | 17 +-
> net/ipv4/netfilter/nf_nat_h323.c | 33 ++-
> net/netfilter/nf_conntrack_h323_main.c | 328 +++++++++++++++++-----------
> 3 files changed, 244 insertions(+), 134 deletions(-)
>
> diff --git a/include/linux/netfilter/nf_conntrack_h323.h b/include/linux/netfilter/nf_conntrack_h323.h
> index 858d9b2..6c6fea1 100644
> --- a/include/linux/netfilter/nf_conntrack_h323.h
> +++ b/include/linux/netfilter/nf_conntrack_h323.h
> @@ -27,11 +27,17 @@ struct nf_ct_h323_master {
> };
> };
>
> +struct h323_ct_state {
> + unsigned char *buf;
> + unsigned char *data;
> + int buflen;
> +};
> +
> struct nf_conn;
>
> int get_h225_addr(struct nf_conn *ct, unsigned char *data,
> TransportAddress *taddr, union nf_inet_addr *addr,
> - __be16 *port);
> + __be16 *port, struct h323_ct_state *ctstate);
> void nf_conntrack_h245_expect(struct nf_conn *new,
> struct nf_conntrack_expect *this);
> void nf_conntrack_q931_expect(struct nf_conn *new,
> @@ -50,12 +56,14 @@ extern int (*set_sig_addr_hook) (struct sk_buff *skb,
> struct nf_conn *ct,
> enum ip_conntrack_info ctinfo,
> unsigned int protoff, unsigned char **data,
> - TransportAddress *taddr, int count);
> + TransportAddress *taddr, int count,
> + struct h323_ct_state *ctstate);
> extern int (*set_ras_addr_hook) (struct sk_buff *skb,
> struct nf_conn *ct,
> enum ip_conntrack_info ctinfo,
> unsigned int protoff, unsigned char **data,
> - TransportAddress *taddr, int count);
> + TransportAddress *taddr, int count,
> + struct h323_ct_state *ctstate);
> extern int (*nat_rtp_rtcp_hook) (struct sk_buff *skb,
> struct nf_conn *ct,
> enum ip_conntrack_info ctinfo,
> @@ -90,7 +98,8 @@ extern int (*nat_q931_hook) (struct sk_buff *skb, struct nf_conn *ct,
> unsigned int protoff,
> unsigned char **data, TransportAddress *taddr,
> int idx, __be16 port,
> - struct nf_conntrack_expect *exp);
> + struct nf_conntrack_expect *exp,
> + struct h323_ct_state *ctstate);
>
> #endif
>
> diff --git a/net/ipv4/netfilter/nf_nat_h323.c b/net/ipv4/netfilter/nf_nat_h323.c
> index 574f7eb..5ed2d70 100644
> --- a/net/ipv4/netfilter/nf_nat_h323.c
> +++ b/net/ipv4/netfilter/nf_nat_h323.c
> @@ -33,12 +33,20 @@ static int set_addr(struct sk_buff *skb, unsigned int protoff,
> } __attribute__ ((__packed__)) buf;
> const struct tcphdr *th;
> struct tcphdr _tcph;
> + int datalen;
> + struct iphdr *iph = ip_hdr(skb);
>
> buf.ip = ip;
> buf.port = port;
> addroff += dataoff;
>
> if (ip_hdr(skb)->protocol == IPPROTO_TCP) {
> + th = (void *)iph + iph->ihl * 4;
> + datalen = skb->len - (iph->ihl * 4 + th->doff * 4);
You cannot trust the information that is available in the header. If
this is bogus this check will be defeated. That's why we pass this
protoff parameters to each function.
You also refer to get_h225_addr() in your description. That function
always copies 4 or 16 bytes, so I would appreciate if you can describe
the possible issue further.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox