* Re: [PATCH v2 net-next 14/19] ionic: Add Tx and Rx handling
From: Jakub Kicinski @ 2019-06-29 18:57 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev
In-Reply-To: <20190628213934.8810-15-snelson@pensando.io>
On Fri, 28 Jun 2019 14:39:29 -0700, Shannon Nelson wrote:
> +static int ionic_tx(struct queue *q, struct sk_buff *skb)
> +{
> + struct tx_stats *stats = q_to_tx_stats(q);
> + int err;
> +
> + if (skb->ip_summed == CHECKSUM_PARTIAL)
> + err = ionic_tx_calc_csum(q, skb);
> + else
> + err = ionic_tx_calc_no_csum(q, skb);
> + if (err)
> + return err;
> +
> + err = ionic_tx_skb_frags(q, skb);
> + if (err)
> + return err;
> +
> + skb_tx_timestamp(skb);
> + stats->pkts++;
> + stats->bytes += skb->len;
Presumably this is 64bit so you should use
u64_stats_update_begin()
u64_stats_update_end()
around it (and all other stats).
> +
> + ionic_txq_post(q, !netdev_xmit_more(), ionic_tx_clean, skb);
> +
> + return 0;
> +}
> +
> +static int ionic_tx_descs_needed(struct queue *q, struct sk_buff *skb)
> +{
> + struct tx_stats *stats = q_to_tx_stats(q);
> + int err;
> +
> + /* If TSO, need roundup(skb->len/mss) descs */
> + if (skb_is_gso(skb))
> + return (skb->len / skb_shinfo(skb)->gso_size) + 1;
> +
> + /* If non-TSO, just need 1 desc and nr_frags sg elems */
> + if (skb_shinfo(skb)->nr_frags <= IONIC_TX_MAX_SG_ELEMS)
> + return 1;
> +
> + /* Too many frags, so linearize */
> + err = skb_linearize(skb);
> + if (err)
> + return err;
> +
> + stats->linearize++;
> +
> + /* Need 1 desc and zero sg elems */
> + return 1;
> +}
> +
> +netdev_tx_t ionic_start_xmit(struct sk_buff *skb, struct net_device *netdev)
> +{
> + u16 queue_index = skb_get_queue_mapping(skb);
> + struct lif *lif = netdev_priv(netdev);
> + struct queue *q;
> + int ndescs;
> + int err;
> +
> + if (unlikely(!test_bit(LIF_UP, lif->state))) {
> + dev_kfree_skb(skb);
> + return NETDEV_TX_OK;
> + }
> +
> + if (likely(lif_to_txqcq(lif, queue_index)))
> + q = lif_to_txq(lif, queue_index);
> + else
> + q = lif_to_txq(lif, 0);
> +
> + ndescs = ionic_tx_descs_needed(q, skb);
> + if (ndescs < 0)
> + goto err_out_drop;
> +
> + if (!ionic_q_has_space(q, ndescs)) {
> + netif_stop_subqueue(netdev, queue_index);
> + q->stop++;
> +
> + /* Might race with ionic_tx_clean, check again */
> + smp_rmb();
> + if (ionic_q_has_space(q, ndescs)) {
> + netif_wake_subqueue(netdev, queue_index);
> + q->wake++;
> + } else {
> + return NETDEV_TX_BUSY;
This should never really happen..
> + }
> + }
> +
> + if (skb_is_gso(skb))
> + err = ionic_tx_tso(q, skb);
> + else
> + err = ionic_tx(q, skb);
> +
> + if (err)
> + goto err_out_drop;
.. at this point if you can't guarantee fitting biggest possible frame
in, you have to stop the ring.
> + return NETDEV_TX_OK;
> +
> +err_out_drop:
> + q->drop++;
> + dev_kfree_skb(skb);
> + return NETDEV_TX_OK;
> +}
^ permalink raw reply
* [Patch net] xfrm: remove a duplicated assignment
From: Cong Wang @ 2019-06-29 19:17 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Florian Westphal, Steffen Klassert
Fixes: 30846090a746 ("xfrm: policy: add sequence count to sync with hash resize")
Cc: Florian Westphal <fw@strlen.de>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/xfrm/xfrm_policy.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index b1694d5d15d3..3235562f6588 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -582,9 +582,6 @@ static void xfrm_bydst_resize(struct net *net, int dir)
spin_lock_bh(&net->xfrm.xfrm_policy_lock);
write_seqcount_begin(&xfrm_policy_hash_generation);
- odst = rcu_dereference_protected(net->xfrm.policy_bydst[dir].table,
- lockdep_is_held(&net->xfrm.xfrm_policy_lock));
-
odst = rcu_dereference_protected(net->xfrm.policy_bydst[dir].table,
lockdep_is_held(&net->xfrm.xfrm_policy_lock));
--
2.21.0
^ permalink raw reply related
* Re: [PATCH net] selftests: rtnetlink: skip ipsec offload tests if netdevsim isn't present
From: David Miller @ 2019-06-29 19:19 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20190627151242.5150-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 27 Jun 2019 17:12:42 +0200
> running the script on systems without netdevsim now prints:
>
> SKIP: ipsec_offload can't load netdevsim
>
> instead of error message & failed status.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> Feel free to apply to -next, its not a bug fix per se.
Applied to net-next, thank you.
^ permalink raw reply
* Re: [PATCH V4] bnx2x: Prevent ptp_task to be rescheduled indefinitely
From: David Miller @ 2019-06-29 19:20 UTC (permalink / raw)
To: gpiccoli; +Cc: GR-everest-linux-l2, netdev, skalluru, aelior, jay.vosburgh
In-Reply-To: <20190627163133.5990-1-gpiccoli@canonical.com>
From: "Guilherme G. Piccoli" <gpiccoli@canonical.com>
Date: Thu, 27 Jun 2019 13:31:33 -0300
> Currently bnx2x ptp worker tries to read a register with timestamp
> information in case of TX packet timestamping and in case it fails,
> the routine reschedules itself indefinitely. This was reported as a
> kworker always at 100% of CPU usage, which was narrowed down to be
> bnx2x ptp_task.
>
> By following the ioctl handler, we could narrow down the problem to
> an NTP tool (chrony) requesting HW timestamping from bnx2x NIC with
> RX filter zeroed; this isn't reproducible for example with ptp4l
> (from linuxptp) since this tool requests a supported RX filter.
> It seems NIC FW timestamp mechanism cannot work well with
> RX_FILTER_NONE - driver's PTP filter init routine skips a register
> write to the adapter if there's not a supported filter request.
>
> This patch addresses the problem of bnx2x ptp thread's everlasting
> reschedule by retrying the register read 10 times; between the read
> attempts the thread sleeps for an increasing amount of time starting
> in 1ms to give FW some time to perform the timestamping. If it still
> fails after all retries, we bail out in order to prevent an unbound
> resource consumption from bnx2x.
>
> The patch also adds an ethtool statistic for accounting the skipped
> TX timestamp packets and it reduces the priority of timestamping
> error messages to prevent log flooding. The code was tested using
> both linuxptp and chrony.
>
> Reported-and-tested-by: Przemyslaw Hausman <przemyslaw.hausman@canonical.com>
> Suggested-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2] net: dsa: mv88e6xxx: wait after reset deactivation
From: David Miller @ 2019-06-29 19:21 UTC (permalink / raw)
To: baruch; +Cc: andrew, vivien.didelot, netdev
In-Reply-To: <2e272a4e588ae44137864237d0cd73e2208f2c60.1561659459.git.baruch@tkos.co.il>
From: Baruch Siach <baruch@tkos.co.il>
Date: Thu, 27 Jun 2019 21:17:39 +0300
> Add a 1ms delay after reset deactivation. Otherwise the chip returns
> bogus ID value. This is observed with 88E6390 (Peridot) chip.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> v2: Address Andrew Lunn's comments:
> Use usleep_range.
> Delay only when reset line is valid.
Applied and queuedu up for -stable, thanks.
^ permalink raw reply
* Re: [PATCHv2 next 3/3] blackhole_dev: add a selftest
From: David Miller @ 2019-06-29 19:28 UTC (permalink / raw)
To: maheshb; +Cc: netdev, edumazet, michael.chan, dja, mahesh
In-Reply-To: <20190627194309.94291-1-maheshb@google.com>
From: Mahesh Bandewar <maheshb@google.com>
Date: Thu, 27 Jun 2019 12:43:09 -0700
> +config TEST_BLACKHOLE_DEV
> + tristate "Test BPF filter functionality"
I think the tristate string needs to be changed :-)
^ permalink raw reply
* Re: [PATCH net-next] r8169: improve handling VLAN tag
From: David Miller @ 2019-06-29 19:29 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <29fd564b-3279-a36d-a082-1c650168567e@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 27 Jun 2019 23:06:33 +0200
> The VLAN tag is stored in the descriptor in network byte order.
> Using swab16 works on little endian host systems only. Better play safe
> and use ntohs or htons respectively.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: consider that 32 Bit DMA is the default
From: David Miller @ 2019-06-29 19:30 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <eabad258-68de-49b9-91d7-7c853ea4f150@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 27 Jun 2019 23:12:39 +0200
> Documentation/DMA-API-HOWTO.txt states:
> By default, the kernel assumes that your device can address 32-bits of
> DMA addressing. For a 64-bit capable device, this needs to be increased,
> and for a device with limitations, it needs to be decreased.
>
> Therefore we don't need the 32 Bit DMA fallback configuration and can
> remove it.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: remove not needed call to dma_sync_single_for_device
From: David Miller @ 2019-06-29 19:30 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <8377f1a6-787a-7eea-17be-0d70cb9911d3@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 27 Jun 2019 23:19:09 +0200
> DMA_API_HOWTO.txt includes an example explaining when
> dma_sync_single_for_device() is not needed, and that example matches
> our use case. The buffer isn't changed by the CPU and direction is
> DMA_FROM_DEVICE, so we can remove the call to
> dma_sync_single_for_device().
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ethernet: mediatek: Fix overlapping capability bits.
From: Willem de Bruijn @ 2019-06-29 19:33 UTC (permalink / raw)
To: René van Dorst
Cc: sean.wang, f.fainelli, linux, David Miller, matthias.bgg, andrew,
vivien.didelot, frank-w, Network Development, linux-mediatek,
linux-mips
In-Reply-To: <20190629122419.19026-1-opensource@vdorst.com>
On Sat, Jun 29, 2019 at 8:24 AM René van Dorst <opensource@vdorst.com> wrote:
>
> Both MTK_TRGMII_MT7621_CLK and MTK_PATH_BIT are defined as bit 10.
>
> This causes issues on non-MT7621 devices which has the
> MTK_PATH_BIT(MTK_ETH_PATH_GMAC1_RGMII) capability set.
> The wrong TRGMII setup code is executed.
>
> Moving the MTK_PATH_BIT to bit 11 fixes the issue.
>
> Fixes: 8efaa653a8a5 ("net: ethernet: mediatek: Add MT7621 TRGMII mode
> support")
> Signed-off-by: René van Dorst <opensource@vdorst.com>
This targets net? Please mark networking patches [PATCH net] or [PATCH
net-next].
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index 876ce6798709..2cb8a915731c 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -626,7 +626,7 @@ enum mtk_eth_path {
> #define MTK_TRGMII_MT7621_CLK BIT(10)
>
> /* Supported path present on SoCs */
> -#define MTK_PATH_BIT(x) BIT((x) + 10)
>
> +#define MTK_PATH_BIT(x) BIT((x) + 11)
>
To avoid this happening again, perhaps make the reserved range more explicit?
For instance
#define MTK_FIXED_BIT_LAST 10
#define MTK_TRGMII_MT7621_CLK BIT(MTK_FIXED_BIT_LAST)
#define MTK_PATH_BIT_FIRST (MTK_FIXED_BIT_LAST + 1)
#define MTK_PATH_BIT_LAST (MTK_FIXED_BIT_LAST + 7)
#define MTK_MUX_BIT_FIRST (MTK_PATH_BIT_LAST + 1)
Though I imagine there are cleaner approaches. Perhaps define all
fields as enum instead of just mtk_eth_mux and mtk_eth_path. Then
there can be no accidental collision.
^ permalink raw reply
* Re: net: check before dereferencing netdev_ops during busy poll
From: Matteo Croce @ 2019-06-29 19:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Josh Elsasser, Sasha Levin, stable, netdev, LKML, David Miller
In-Reply-To: <20190629074553.GA28708@kroah.com>
On Sat, Jun 29, 2019 at 9:45 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jun 28, 2019 at 07:03:01PM -0700, Josh Elsasser wrote:
> > On Jun 28, 2019, at 3:55 PM, Sasha Levin <sashal@kernel.org> wrote:
> >
> > > What's the upstream commit id?
> >
> > The commit wasn't needed upstream, as I only sent the original patch after
> > 79e7fff47b7b ("net: remove support for per driver ndo_busy_poll()") had
> > made the fix unnecessary in Linus' tree.
> >
> > May've gotten lost in the shuffle due to my poor Fixes tags. The patch in
> > question applied only on top of the 4.9 stable release at the time, but the
> > actual NPE had been around in some form since 3.11 / 0602129286705 ("net: add
> > low latency socket poll").
>
> Ok, can people then resend this and be very explicit as to why this is
> needed only in a stable kernel tree and get reviews from people agreeing
> that this really is the correct fix?
>
> thanks,
>
> greg k-h
Hi Greg,
I think that David alredy reviewed the patch here:
https://lore.kernel.org/netdev/20180313.105115.682846171057663636.davem@davemloft.net/
Anyway, I tested the patch and it fixes the panic, at least on my
iwlwifi card, so:
Tested-by: Matteo Croce <mcroce@redhat.com>
Regards,
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* r8169 not working on 5.2.0rc6 with GPD MicroPC
From: Karsten Wiborg @ 2019-06-29 20:34 UTC (permalink / raw)
To: nic_swsd, romieu; +Cc: netdev
Hello,
writing to you because of the r8168-dkms-README.Debian.
I am using a GPD MicroPC running Debian Buster with Kernel:
Linux praktifix 5.2.0-050200rc6-generic #201906222033 SMP Sun Jun 23
00:36:46 UTC 2019 x86_64 GNU/Linux
Got the Kernel from:
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2-rc6/
Reason for the Kernel: it includes Hans DeGoedes necessary fixes for the
GPD MicroPC, see:
https://github.com/jwrdegoede/linux-sunxi
(btw. I also tried Hans' 5.2.0rc5-kernel which also did not work with
respect to Ethernet). Googling of course didn't help out either.
My GPD MicroPC with running r8169 gives the following lines in dmesg:
...
[ 2.839485] libphy: r8169: probed
[ 2.839776] r8169 0000:02:00.0 eth0: RTL8168h/8111h,
00:00:00:00:00:00, XID 541, IRQ 126
[ 2.839779] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200
bytes, tx checksumming: ko]
...
[ 2.897924] r8169 0000:02:00.0 eno1: renamed from eth0
ip addr show gives me:
# ip addr show
...
2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
...
ethtool gives me:
# ethtool -i eno1
driver: r8169
version:
firmware-version:
expansion-rom-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
lspci shows me:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
Installing r8168-dkms fails with the following errors:
Setting up r8168-dkms (8.046.00-1) ...
Removing old r8168-8.046.00 DKMS files...
------------------------------
Deleting module version: 8.046.00
completely from the DKMS tree.
------------------------------
Done.
Loading new r8168-8.046.00 DKMS files...
Building for 5.2.0-050200rc6-generic 5.2.0-rc5-gpd-custom
Building initial module for 5.2.0-050200rc6-generic
Error! Bad return status for module build on kernel:
5.2.0-050200rc6-generic (x86_64)
Consult /var/lib/dkms/r8168/8.046.00/build/make.log for more information.
dpkg: error processing package r8168-dkms (--configure):
installed r8168-dkms package post-installation script subprocess
returned error exit status 10
Errors were encountered while processing:
r8168-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)
Does that help you?
Do you need more data?
Thank you very much in advance for hopefully looking into this matter.
Regards,
Karsten Wiborg
^ permalink raw reply
* Re: [net-next 08/15] iavf: Fix up debug print macro
From: Joe Perches @ 2019-06-29 20:42 UTC (permalink / raw)
To: Jeff Kirsher, davem; +Cc: netdev, nhorman, sassmann, Andrew Bowers
In-Reply-To: <20190628224932.3389-9-jeffrey.t.kirsher@intel.com>
On Fri, 2019-06-28 at 15:49 -0700, Jeff Kirsher wrote:
> This aligns the iavf_debug() macro with the other Intel drivers.
>
> Add the bus number, bus_id field to i40e_bus_info so output shows
> each physical port(i.e func) in following format:
> [[[[<domain>]:]<bus>]:][<slot>][.[<func>]]
> domains are numbered from 0 to ffff), bus (0-ff), slot (0-1f) and
> function (0-7).
>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf_osdep.h | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_osdep.h b/drivers/net/ethernet/intel/iavf/iavf_osdep.h
> index d39684558597..a452ce90679a 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_osdep.h
> +++ b/drivers/net/ethernet/intel/iavf/iavf_osdep.h
> @@ -44,8 +44,12 @@ struct iavf_virt_mem {
> #define iavf_allocate_virt_mem(h, m, s) iavf_allocate_virt_mem_d(h, m, s)
> #define iavf_free_virt_mem(h, m) iavf_free_virt_mem_d(h, m)
>
> -#define iavf_debug(h, m, s, ...) iavf_debug_d(h, m, s, ##__VA_ARGS__)
> -extern void iavf_debug_d(void *hw, u32 mask, char *fmt_str, ...)
> - __printf(3, 4);
> +#define iavf_debug(h, m, s, ...) \
> +do { \
> + if (((m) & (h)->debug_mask)) \
> + pr_info("iavf %02x:%02x.%x " s, \
> + (h)->bus.bus_id, (h)->bus.device, \
> + (h)->bus.func, ##__VA_ARGS__); \
> +} while (0)
Why not change the function to do this?
And if this is really wanted this particular way
the now unused function should be removed too.
But I suggest emitting at KERN_DEBUG and using
the more typical %pV vsprintf extension.
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 25 ++++++++++++++-----------
drivers/net/ethernet/intel/iavf/iavf_osdep.h | 9 ++++++---
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 881561b36083..8504fd71d398 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -143,25 +143,28 @@ enum iavf_status iavf_free_virt_mem_d(struct iavf_hw *hw,
}
/**
- * iavf_debug_d - OS dependent version of debug printing
+ * _iavf_debug - OS dependent version of debug printing
* @hw: pointer to the HW structure
* @mask: debug level mask
- * @fmt_str: printf-type format description
+ * @fmt: printf-type format description
**/
-void iavf_debug_d(void *hw, u32 mask, char *fmt_str, ...)
+void _iavf_debug(const struct iavf_hw *hw, u32 mask, const char *fmt, ...)
{
- char buf[512];
- va_list argptr;
+ struct va_format vaf;
+ va_list args;
- if (!(mask & ((struct iavf_hw *)hw)->debug_mask))
+ if (!(hw->debug_mask & mask))
return;
- va_start(argptr, fmt_str);
- vsnprintf(buf, sizeof(buf), fmt_str, argptr);
- va_end(argptr);
+ va_start(args, fmt);
- /* the debug string is already formatted with a newline */
- pr_info("%s", buf);
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ pr_debug("iavf %02x:%02x.%x %pV",
+ hw->bus.bus_id, hw->bus.device, hw->bus.func, &vaf);
+
+ va_end(args);
}
/**
diff --git a/drivers/net/ethernet/intel/iavf/iavf_osdep.h b/drivers/net/ethernet/intel/iavf/iavf_osdep.h
index d39684558597..0e6ac7d262c8 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_osdep.h
+++ b/drivers/net/ethernet/intel/iavf/iavf_osdep.h
@@ -44,8 +44,11 @@ struct iavf_virt_mem {
#define iavf_allocate_virt_mem(h, m, s) iavf_allocate_virt_mem_d(h, m, s)
#define iavf_free_virt_mem(h, m) iavf_free_virt_mem_d(h, m)
-#define iavf_debug(h, m, s, ...) iavf_debug_d(h, m, s, ##__VA_ARGS__)
-extern void iavf_debug_d(void *hw, u32 mask, char *fmt_str, ...)
- __printf(3, 4);
+struct iavf_hw;
+
+__printf(3, 4)
+void _iavf_debug(const struct iavf_hw *hw, u32 mask, const char *fmt, ...);
+#define iavf_debug(hw, mask, fmt, ...) \
+ _iavf_debug(hw, mask, fmt, ##__VA_ARGS__)
#endif /* _IAVF_OSDEP_H_ */
^ permalink raw reply related
* Re: KASAN: use-after-free Write in xfrm_hash_rebuild
From: syzbot @ 2019-06-29 21:11 UTC (permalink / raw)
To: davem, fw, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
In-Reply-To: <000000000000d028b30588fed102@google.com>
syzbot has bisected this bug to:
commit 1548bc4e0512700cf757192c106b3a20ab639223
Author: Florian Westphal <fw@strlen.de>
Date: Fri Jan 4 13:17:02 2019 +0000
xfrm: policy: delete inexact policies from inexact list on hash rebuild
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1734cba9a00000
start commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=14b4cba9a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=10b4cba9a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2
dashboard link: https://syzkaller.appspot.com/bug?extid=0165480d4ef07360eeda
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cf37c3a00000
Reported-by: syzbot+0165480d4ef07360eeda@syzkaller.appspotmail.com
Fixes: 1548bc4e0512 ("xfrm: policy: delete inexact policies from inexact
list on hash rebuild")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: r8169 not working on 5.2.0rc6 with GPD MicroPC
From: Karsten Wiborg @ 2019-06-29 21:19 UTC (permalink / raw)
To: nic_swsd, romieu; +Cc: netdev
In-Reply-To: <0a560a5e-17f2-f6ff-1dad-66907133e9c2@web.de>
Hi,
short update with some more data:
# more /var/lib/dkms/r8168/8.046.00/build/make.log
DKMS make.log for r8168-8.046.00 for kernel 5.2.0-050200rc6-generic (x86_64)
Sat 29 Jun 2019 10:11:15 PM CEST
make: Entering directory '/usr/src/linux-headers-5.2.0-050200rc6-generic'
CC [M] /var/lib/dkms/r8168/8.046.00/build/r8168_n.o
CC [M] /var/lib/dkms/r8168/8.046.00/build/r8168_asf.o
CC [M] /var/lib/dkms/r8168/8.046.00/build/rtl_eeprom.o
CC [M] /var/lib/dkms/r8168/8.046.00/build/rtltool.o
/var/lib/dkms/r8168/8.046.00/build/r8168_n.c: In function ‘rtl8168_down’:
/var/lib/dkms/r8168/8.046.00/build/r8168_n.c:28376:9: error: implicit
declaration of function ‘synch
ronize_sched’; did you mean ‘synchronize_net’?
[-Werror=implicit-function-declaration]
synchronize_sched(); /* FIXME: should this be
synchronize_irq()? */
^~~~~~~~~~~~~~~~~
synchronize_net
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:278:
/var/lib/dkms/r8168/8.046.00/build/r8168_n.o] Error 1
make: *** [Makefile:1595: _module_/var/lib/dkms/r8168/8.046.00/build]
Error 2
make: Leaving directory '/usr/src/linux-headers-5.2.0-050200rc6-generic'
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)
Regards,
Karsten Wiborg
On 6/29/19 10:34 PM, Karsten Wiborg wrote:
> Hello,
>
> writing to you because of the r8168-dkms-README.Debian.
>
> I am using a GPD MicroPC running Debian Buster with Kernel:
> Linux praktifix 5.2.0-050200rc6-generic #201906222033 SMP Sun Jun 23
> 00:36:46 UTC 2019 x86_64 GNU/Linux
>
>
> Got the Kernel from:
> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2-rc6/
> Reason for the Kernel: it includes Hans DeGoedes necessary fixes for the
> GPD MicroPC, see:
> https://github.com/jwrdegoede/linux-sunxi
> (btw. I also tried Hans' 5.2.0rc5-kernel which also did not work with
> respect to Ethernet). Googling of course didn't help out either.
>
>
> My GPD MicroPC with running r8169 gives the following lines in dmesg:
> ...
> [ 2.839485] libphy: r8169: probed
> [ 2.839776] r8169 0000:02:00.0 eth0: RTL8168h/8111h,
> 00:00:00:00:00:00, XID 541, IRQ 126
> [ 2.839779] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200
> bytes, tx checksumming: ko]
> ...
> [ 2.897924] r8169 0000:02:00.0 eno1: renamed from eth0
>
>
> ip addr show gives me:
> # ip addr show
> ...
> 2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> ...
>
>
> ethtool gives me:
> # ethtool -i eno1
> driver: r8169
> version:
> firmware-version:
> expansion-rom-version:
> bus-info: 0000:02:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: yes
> supports-priv-flags: no
>
>
> lspci shows me:
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
>
>
> Installing r8168-dkms fails with the following errors:
> Setting up r8168-dkms (8.046.00-1) ...
> Removing old r8168-8.046.00 DKMS files...
>
> ------------------------------
> Deleting module version: 8.046.00
> completely from the DKMS tree.
> ------------------------------
> Done.
> Loading new r8168-8.046.00 DKMS files...
> Building for 5.2.0-050200rc6-generic 5.2.0-rc5-gpd-custom
> Building initial module for 5.2.0-050200rc6-generic
> Error! Bad return status for module build on kernel:
> 5.2.0-050200rc6-generic (x86_64)
> Consult /var/lib/dkms/r8168/8.046.00/build/make.log for more information.
> dpkg: error processing package r8168-dkms (--configure):
> installed r8168-dkms package post-installation script subprocess
> returned error exit status 10
> Errors were encountered while processing:
> r8168-dkms
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
>
> Does that help you?
> Do you need more data?
> Thank you very much in advance for hopefully looking into this matter.
>
> Regards,
> Karsten Wiborg
>
^ permalink raw reply
* Re: [RFC iproute2 1/1] ip: netns: add mounted state file for each netns
From: Matteo Croce @ 2019-06-29 21:45 UTC (permalink / raw)
To: David Howells
Cc: Nicolas Dichtel, Alexander Aring, netdev, linux-fsdevel, kernel
In-Reply-To: <CAGnkfhwe6p412q4sATwX=3ht4+NxKJDOFihRG=iwvXqWUtwgLQ@mail.gmail.com>
On Fri, Jun 28, 2019 at 7:06 PM Matteo Croce <mcroce@redhat.com> wrote:
>
> On Fri, Jun 28, 2019 at 6:27 PM David Howells <dhowells@redhat.com> wrote:
> >
> > Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> >
> > > David Howells was working on a mount notification mechanism:
> > > https://lwn.net/Articles/760714/
> > > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=notifications
> > >
> > > I don't know what is the status of this series.
> >
> > It's still alive. I just posted a new version on it. I'm hoping, possibly
> > futiley, to get it in in this merge window.
> >
> > David
>
> Hi all,
>
> this could cause a clash if I create a netns with name ending with .mounted.
>
> $ sudo ip/ip netns add ns1.mounted
> $ sudo ip/ip netns add ns1
> Cannot create namespace file "/var/run/netns/ns1.mounted": File exists
> Cannot remove namespace file "/var/run/netns/ns1.mounted": Device or
> resource busy
>
> If you want to go along this road, please either:
> - disallow netns creation with names ending with .mounted
> - or properly document it in the manpage
>
> Regards,
> --
> Matteo Croce
> per aspera ad upstream
BTW, this breaks the namespace listing:
# ip netns add test
# ip netns list
Error: Peer netns reference is invalid.
Error: Peer netns reference is invalid.
test.mounted
test
A better choice IMHO could be to create a temporary file before the
placeholder, and delete it after the bind mount, so an inotify watcher
can listen for the delete event.
For example, when creating the namespace "foo":
- create /var/run/netns/.foo.mounting
- create /var/run/netns/foo
- bind mount from /proc/.. to /var/run/netns/foo
- remove /var/run/netns/.foo.mounting
and exclude .*.mounting from the netns listing
Or, announce netns creation/deletion in some other way (dbus?).
Regards,
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* loss of connectivity after enabling vlan_filtering
From: vtolkm @ 2019-06-29 22:01 UTC (permalink / raw)
To: netdev
* DSA MV88E6060
* iproute2 v.5.0.0-2.0
* OpenWRT 19.07 with kernel 4.14.131 armv7l
_______
after
# bridge v a dev {bridge} self vid {n} untagged pvid
or with the device enslaved in the br
# bridge v a dev {device} vid {n} untagged pvid
I am hitting a roadblock when executing
# sysctl -w /sys/class/net/{bridge}/bridge/vlan_filtering=1
there is immediate loss of connectivity with the node until
# sysctl -w /sys/class/net/{bridge}/bridge/vlan_filtering=0
Since writing here I apparently trust that above is unexpected and I
cannot figure out what is (going) wrong.
Tried some variation (enabling VID on the client when appropriate) but
having met the same outcome.
# bridge v a dev {bridge} self vid {n} untagged
# bridge v a dev {bridge} self vid {n} pvid
# bridge v a dev {bridge} self vid {n}
# bridge v s
reflects any such change.
# ip -d l sh type bridge
br-mgt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP mode DEFAULT group default qlen 1000
link/ether 1e:8e:c2:3c:b8:35 brd ff:ff:ff:ff:ff:ff promiscuity 0
bridge forward_delay 200 hello_time 200 max_age 2000 ageing_time
30000 stp_state 0 priority 32767 vlan_filtering 0 vlan_protocol 802.1Q
bridge_id 7fff.1E:8E:C2:3C:B8:35 designated_root 7fff.1E:8E:C2:3C:B8:35
root_port 0 root_path_cost 0 topology_change 0 topology_change_detected
0 hello_timer 0.00 tcn_timer 0.00 topology_change_timer 0.00
gc_timer 168.58 vlan_default_pvid 1 vlan_stats_enabled 0 group_fwd_mask
0 group_address 01:80:c2:00:00:00 mcast_snooping 0 mcast_router 1
mcast_query_use_ifaddr 0 mcast_querier 0 mcast_hash_elasticity 4
mcast_hash_max 512 mcast_last_member_count 2 mcast_startup_query_count 2
mcast_last_member_interval 100 mcast_membership_interval 26000
mcast_querier_interval 25500 mcast_query_interval 12500
mcast_query_response_interval 1000 mcast_startup_query_interval 3125
mcast_stats_enabled 0 mcast_igmp_version 2 mcast_mld_version 1
nf_call_iptables 0 nf_call_ip6tables 0 nf_call_arptables 0 addrgenmode
stable_secret numtxqueues 1 numrxqueues 1 gso_max_size 65536
gso_max_segs 65535
______________________
* kernel conf
---
CONFIG_NETFILTER=y
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=m
CONFIG_NETFILTER_INGRESS=y
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_FAMILY_BRIDGE=y
CONFIG_NETFILTER_FAMILY_ARP=y
# CONFIG_NETFILTER_NETLINK_ACCT is not set
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
# CONFIG_NETFILTER_NETLINK_GLUE_CT is not set
CONFIG_IP_NF_MATCH_RPFILTER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP6_NF_MATCH_RPFILTER=m
CONFIG_IP6_NF_FILTER=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_ATM_BR2684_IPFILTER=y
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_HAVE_NET_DSA=y
CONFIG_NET_DSA=y
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
CONFIG_NET_DSA_TAG_TRAILER=y
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
# CONFIG_NET_DSA_BCM_SF2 is not set
# CONFIG_NET_DSA_LOOP is not set
# CONFIG_NET_DSA_MT7530 is not set
CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
# CONFIG_NET_DSA_QCA8K is not set
# CONFIG_NET_DSA_SMSC_LAN9303_I2C is not set
# CONFIG_NET_DSA_SMSC_LAN9303_MDIO is not set
# CONFIG_HNS_DSAF is not set
CONFIG_PPP_FILTER=y
CONFIG_IPPP_FILTER=y
^ permalink raw reply
* Re: r8169 not working on 5.2.0rc6 with GPD MicroPC
From: Heiner Kallweit @ 2019-06-29 22:09 UTC (permalink / raw)
To: Karsten Wiborg, nic_swsd, romieu; +Cc: netdev
In-Reply-To: <0a560a5e-17f2-f6ff-1dad-66907133e9c2@web.de>
On 29.06.2019 22:34, Karsten Wiborg wrote:
> Hello,
>
> writing to you because of the r8168-dkms-README.Debian.
>
> I am using a GPD MicroPC running Debian Buster with Kernel:
> Linux praktifix 5.2.0-050200rc6-generic #201906222033 SMP Sun Jun 23
> 00:36:46 UTC 2019 x86_64 GNU/Linux
>
>
> Got the Kernel from:
> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2-rc6/
> Reason for the Kernel: it includes Hans DeGoedes necessary fixes for the
> GPD MicroPC, see:
> https://github.com/jwrdegoede/linux-sunxi
> (btw. I also tried Hans' 5.2.0rc5-kernel which also did not work with
> respect to Ethernet). Googling of course didn't help out either.
>
>
> My GPD MicroPC with running r8169 gives the following lines in dmesg:
> ...
If r8169 (the mainline driver) is running, why do you want to switch
to r8168 (the Realtek vendor driver)? The latter is not supported by
the kernel community.
> [ 2.839485] libphy: r8169: probed
> [ 2.839776] r8169 0000:02:00.0 eth0: RTL8168h/8111h,
> 00:00:00:00:00:00, XID 541, IRQ 126
> [ 2.839779] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200
> bytes, tx checksumming: ko]
> ...
> [ 2.897924] r8169 0000:02:00.0 eno1: renamed from eth0
>
>
> ip addr show gives me:
> # ip addr show
> ...
> 2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> ...
>
Seems like the network isn't started.
>
> ethtool gives me:
> # ethtool -i eno1
> driver: r8169
> version:
> firmware-version:
> expansion-rom-version:
> bus-info: 0000:02:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: yes
> supports-priv-flags: no
>
>
> lspci shows me:
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
>
>
> Installing r8168-dkms fails with the following errors:
> Setting up r8168-dkms (8.046.00-1) ...
> Removing old r8168-8.046.00 DKMS files...
>
> ------------------------------
> Deleting module version: 8.046.00
> completely from the DKMS tree.
> ------------------------------
> Done.
> Loading new r8168-8.046.00 DKMS files...
> Building for 5.2.0-050200rc6-generic 5.2.0-rc5-gpd-custom
> Building initial module for 5.2.0-050200rc6-generic
> Error! Bad return status for module build on kernel:
> 5.2.0-050200rc6-generic (x86_64)
> Consult /var/lib/dkms/r8168/8.046.00/build/make.log for more information.
> dpkg: error processing package r8168-dkms (--configure):
> installed r8168-dkms package post-installation script subprocess
> returned error exit status 10
> Errors were encountered while processing:
> r8168-dkms
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
>
> Does that help you?
> Do you need more data?
> Thank you very much in advance for hopefully looking into this matter.
>
> Regards,
> Karsten Wiborg
> .
>
^ permalink raw reply
* Re: loss of connectivity after enabling vlan_filtering
From: Andrew Lunn @ 2019-06-29 22:49 UTC (permalink / raw)
To: vtolkm; +Cc: netdev
In-Reply-To: <e5252bf0-f9c1-3e40-aebd-8c091dbb3e64@gmail.com>
On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
> * DSA MV88E6060
> * iproute2 v.5.0.0-2.0
> * OpenWRT 19.07 with kernel 4.14.131 armv7l
The mv88e6060 driver is very simple. It has no support for VLANs. It
does not even have support for offloading bridging between ports to
the switch.
The data sheet for this device is open. So if you want to hack on the
driver, you could do.
Andrew
^ permalink raw reply
* Re: loss of connectivity after enabling vlan_filtering
From: vtolkm @ 2019-06-29 23:04 UTC (permalink / raw)
To: netdev; +Cc: Andrew Lunn
In-Reply-To: <20190629224927.GA26554@lunn.ch>
On 30/06/2019 00:49, Andrew Lunn wrote:
> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>> * DSA MV88E6060
>> * iproute2 v.5.0.0-2.0
>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
> The mv88e6060 driver is very simple. It has no support for VLANs. It
> does not even have support for offloading bridging between ports to
> the switch.
>
> The data sheet for this device is open. So if you want to hack on the
> driver, you could do.
>
> Andrew
Are you sure? That is a bit confusing after reading
https://lore.kernel.org/patchwork/patch/575746/
^ permalink raw reply
* Re: [RFC net-next] net: dsa: add support for MC_DISABLED attribute
From: Andrew Lunn @ 2019-06-29 23:06 UTC (permalink / raw)
To: Ido Schimmel
Cc: f.fainelli, vivien.didelot, netdev@vger.kernel.org, Jiri Pirko,
linux@armlinux.org.uk, davem@davemloft.net
In-Reply-To: <20190629153135.GA17143@splinter>
> We have some tests under tools/testing/selftests/net/forwarding/, but
> not so much for MC. However, even if such tests were to be contributed,
> would you be able to run them on your hardware? I remember that in the
> past you complained about the number of required ports.
Hi Ido
Most devices have 4 or 5 ports. Some have more, some less. Given that
the current tests need a second port for every port under test, this
limits you to 2 ports under test. For IGMP snooping and MC in general,
i don't think that is enough. You need one port as the source of the
MC traffic, one port with a host interested in the traffic, and one
port without interest in the traffic. You can then test that traffic
is correctly forwarded and blocked.
The testing we do with DSA makes use of a test host with 4 interfaces,
and connect them one to one to the switch. That gives us 4 ports under
test, and so that gives us many more possibilities for running
interesting tests.
Andrew
^ permalink raw reply
* Re: loss of connectivity after enabling vlan_filtering
From: Andrew Lunn @ 2019-06-29 23:11 UTC (permalink / raw)
To: vtolkm; +Cc: netdev
In-Reply-To: <6226b473-b232-e1d3-40e9-18d118dd82c4@gmail.com>
On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>
> On 30/06/2019 00:49, Andrew Lunn wrote:
> > On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
> >> * DSA MV88E6060
> >> * iproute2 v.5.0.0-2.0
> >> * OpenWRT 19.07 with kernel 4.14.131 armv7l
> > The mv88e6060 driver is very simple. It has no support for VLANs. It
> > does not even have support for offloading bridging between ports to
> > the switch.
> >
> > The data sheet for this device is open. So if you want to hack on the
> > driver, you could do.
> >
> > Andrew
>
> Are you sure? That is a bit confusing after reading
> https://lore.kernel.org/patchwork/patch/575746/
Quoting that patch:
This commit implements the switchdev operations to add, delete
and dump VLANs for the Marvell 88E6352 and compatible switch
chips.
Vivien added support for the 6352. That uses the mv88e6xxx driver, not
the mv88e6060. And by compatible switches, he meant those in the 6352
family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
Andrew
^ permalink raw reply
* Re: loss of connectivity after enabling vlan_filtering
From: vtolkm @ 2019-06-29 23:23 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190629231119.GC26554@lunn.ch>
On 30/06/2019 01:11, Andrew Lunn wrote:
> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>> * DSA MV88E6060
>>>> * iproute2 v.5.0.0-2.0
>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>> does not even have support for offloading bridging between ports to
>>> the switch.
>>>
>>> The data sheet for this device is open. So if you want to hack on the
>>> driver, you could do.
>>>
>>> Andrew
>> Are you sure? That is a bit confusing after reading
>> https://lore.kernel.org/patchwork/patch/575746/
> Quoting that patch:
>
> This commit implements the switchdev operations to add, delete
> and dump VLANs for the Marvell 88E6352 and compatible switch
> chips.
>
> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
> the mv88e6060. And by compatible switches, he meant those in the 6352
> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>
> Andrew
A simple soul might infer that mv88e6xxx includes MV88E6060, at least
that happened to me apparently (being said simpleton).
That may as it be, and pardon my continued ignorance, how is it
explained then that a command as
# bridge v a dev {bridge} self vid {n} untagged pvid
reflects in
# bridge v s
a/o
# bridge mo
?
If the commands are not implemented one would expect them to fail in the
first place or not reflecting a change at all?
^ permalink raw reply
* Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: Andy Lutomirski @ 2019-06-29 23:47 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andy Lutomirski, Stephen Smalley, James Morris, linux-security,
LKML, Linux API, David Howells, Alexei Starovoitov,
Network Development, Chun-Yi Lee, Daniel Borkmann, LSM List
In-Reply-To: <CACdnJuuy7-tkj86njAqtdJ3dUMu-2T8a2y8DC3fMKBK0z9J6ag@mail.gmail.com>
On Fri, Jun 28, 2019 at 11:47 AM Matthew Garrett <mjg59@google.com> wrote:
>
> On Thu, Jun 27, 2019 at 4:27 PM Andy Lutomirski <luto@kernel.org> wrote:
> > They're really quite similar in my mind. Certainly some things in the
> > "integrity" category give absolutely trivial control over the kernel
> > (e.g. modules) while others make it quite challenging (ioperm), but
> > the end result is very similar. And quite a few "confidentiality"
> > things genuinely do allow all kernel memory to be read.
> >
> > I agree that finer-grained distinctions could be useful. My concern is
> > that it's a tradeoff, and the other end of the tradeoff is an ABI
> > stability issue. If someone decides down the road that some feature
> > that is currently "integrity" can be split into a narrow "integrity"
> > feature and a "confidentiality" feature then, if the user policy knows
> > about the individual features, there's a risk of breaking people's
> > systems. If we keep the fine-grained control, do we have a clear
> > compatibility story?
>
> My preference right now is to retain the fine-grained aspect of things
> in the internal API, simply because it'll be more annoying to add it
> back later if we want to. I don't want to expose it via the Lockdown
> user facing API for the reasons you've described, but it's not
> impossible that another LSM would find a way to do this reasonably.
> Does it seem reasonable to punt this discussion out to the point where
> another LSM tries to do something with this information, based on the
> implementation they're attempting?
I think I can get behind this, as long as it's clear to LSM authors
that this list is only a little bit stable. I can certainly see the
use for the fine-grained info being available for auditing.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Andy Lutomirski @ 2019-06-30 0:12 UTC (permalink / raw)
To: Song Liu, linux-security
Cc: Andy Lutomirski, Networking, bpf, Alexei Starovoitov,
Daniel Borkmann, Kernel Team, Lorenz Bauer, Jann Horn, Greg KH,
linux-abi@vger.kernel.org, kees@chromium.org
In-Reply-To: <3C595328-3ABE-4421-9772-8D41094A4F57@fb.com>
On Fri, Jun 28, 2019 at 12:05 PM Song Liu <songliubraving@fb.com> wrote:
>
> Hi Andy,
>
> > On Jun 27, 2019, at 4:40 PM, Andy Lutomirski <luto@kernel.org> wrote:
> >
> > On 6/27/19 1:19 PM, Song Liu wrote:
> >> This patch introduce unprivileged BPF access. The access control is
> >> achieved via device /dev/bpf. Users with write access to /dev/bpf are able
> >> to call sys_bpf().
> >> Two ioctl command are added to /dev/bpf:
> >> The two commands enable/disable permission to call sys_bpf() for current
> >> task. This permission is noted by bpf_permitted in task_struct. This
> >> permission is inherited during clone(CLONE_THREAD).
> >> Helper function bpf_capable() is added to check whether the task has got
> >> permission via /dev/bpf.
> >
> >> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> >> index 0e079b2298f8..79dc4d641cf3 100644
> >> --- a/kernel/bpf/verifier.c
> >> +++ b/kernel/bpf/verifier.c
> >> @@ -9134,7 +9134,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr,
> >> env->insn_aux_data[i].orig_idx = i;
> >> env->prog = *prog;
> >> env->ops = bpf_verifier_ops[env->prog->type];
> >> - is_priv = capable(CAP_SYS_ADMIN);
> >> + is_priv = bpf_capable(CAP_SYS_ADMIN);
> >
> > Huh? This isn't a hardening measure -- the "is_priv" verifier mode allows straight-up leaks of private kernel state to user mode.
> >
> > (For that matter, the pending lockdown stuff should possibly consider this a "confidentiality" issue.)
> >
> >
> > I have a bigger issue with this patch, though: it's a really awkward way to pretend to have capabilities. For bpf, it seems like you could make this be a *real* capability without too much pain since there's only one syscall there. Just find a way to pass an fd to /dev/bpf into the syscall. If this means you need a new bpf_with_cap() syscall that takes an extra argument, so be it. The old bpf() syscall can just translate to bpf_with_cap(..., -1).
> >
> > For a while, I've considered a scheme I call "implicit rights". There would be a directory in /dev called /dev/implicit_rights. This would either be part of devtmpfs or a whole new filesystem -- it would *not* be any other filesystem. The contents would be files that can't be read or written and exist only in memory. You create them with a privileged syscall. Certain actions that are sensitive but not at the level of CAP_SYS_ADMIN (use of large-attack-surface bpf stuff, creation of user namespaces, profiling the kernel, etc) could require an "implicit right". When you do them, if you don't have CAP_SYS_ADMIN, the kernel would do a path walk for, say, /dev/implicit_rights/bpf and, if the object exists, can be opened, and actually refers to the "bpf" rights object, then the action is allowed. Otherwise it's denied.
> >
> > This is extensible, and it doesn't require the rather ugly per-task state of whether it's enabled.
> >
> > For things like creation of user namespaces, there's an existing API, and the default is that it works without privilege. Switching it to an implicit right has the benefit of not requiring code changes to programs that already work as non-root.
> >
> > But, for BPF in particular, this type of compatibility issue doesn't exist now. You already can't use most eBPF functionality without privilege. New bpf-using programs meant to run without privilege are *new*, so they can use a new improved API. So, rather than adding this obnoxious ioctl, just make the API explicit, please.
> >
> > Also, please cc: linux-abi next time.
>
> Thanks for your inputs.
>
> I think we need to clarify the use case here. In this case, we are NOT
> thinking about creating new tools for unprivileged users. Instead, we
> would like to use existing tools without root.
I read patch 4, and I interpret it very differently. Patches 2-4 are
creating a new version of libbpf and a new version of bpftool. Given
this, I see no real justification for adding a new in-kernel per-task
state instead of just pushing the complexity into libbpf.
> On the kernel side, we are not planning provides a subset of safe
> features for unprivileged users. The permission here is all-or-nothing.
This may be a showstopper. I think this series needs an extremely
clear explanation of the security implications of providing access to
/dev/bpf. Is it just exposing more attack surface for kernel bugs, or
is it, *by design*, exposing new privileges. Given the is_priv change
that I pointed out upthread, it appears to be the latter, and I'm
wondering how this is a reasonable thing to do.
>
> Introducing bpf_with_cap() syscall means we need teach these tools to
> manage the fd, and use the new API when necessary. This is clearly not
> easy.
How hard can it be? I looked the the libbpf sources, and there are
really very few call sites of sys_bpf(). You could update all of them
with a very small patch.
Also, on a quick survey of kernel/bpf's capable() calls, I feel like
this series may be misguided. If you want to enable unprivileged or
less privileged use of bpf(), how about going through all of the
capable() calls and handling them one-by-one as appropriate. Here's a
random survey:
map_freeze(): It looks like the only reason for a capable() call is
that there isn't a clear permission model right now defining who owns
a map and therefore may freeze it. Could you not use a check along
the lines of capable_wrt_inode_uidgid() instead of capable()?
if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) &&
(attr->prog_flags & BPF_F_ANY_ALIGNMENT) &&
!capable(CAP_SYS_ADMIN))
return -EPERM;
I'm not sure why this is needed at all? Is it a DoS mitigation? If
so, couldn't you find a way to acocunt for inefficient unaligned
access similarly to how you account for complexity in general?
if (attr->insn_cnt == 0 ||
attr->insn_cnt > (capable(CAP_SYS_ADMIN) ?
BPF_COMPLEXITY_LIMIT_INSNS : BPF_MAXINSNS))
return -E2BIG;
This is similar. I could imagine a cgroup setting that limits bpf
program complexity. This is very, very different type of privilege
than reading kernel memory.
if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
type != BPF_PROG_TYPE_CGROUP_SKB &&
!capable(CAP_SYS_ADMIN))
return -EPERM;
I suspect you could just delete this check or expand the allowable
unprivileged program types after auditing that the other types have
appropriately restrictive verifiers and require appropriate
permissions to *run* the programs.
In bpf_prog_attach():
if (!capable(CAP_NET_ADMIN))
return -EPERM;
This looks like it wants to be ns_capable() after you audit the code
to make sure it's safe enough.
bpf_prog_get_fd_by_id(): I really think you just need a real
permission model. Anyone can create a file on a filesystem, and there
are reasonable policies that allow appropriate users to open existing
files by name without CAP_SYS_ADMIN. Similarly, anyone can create a
key in the kernel keyring subsystem, and there are well-defined rules
under which someone can access an existing key by name. I think you
should come up with a way to handle this for bpf. Adding a bpffs for
this seems like a decent approach.
bpf_prog_get_info_by_id():
if (!capable(CAP_SYS_ADMIN)) {
info.jited_prog_len = 0;
info.xlated_prog_len = 0;
info.nr_jited_ksyms = 0;
info.nr_jited_func_lens = 0;
info.nr_func_info = 0;
info.nr_line_info = 0;
info.nr_jited_line_info = 0;
goto done;
}
It looks like someone decided this information was sensitive if you
query someone else's program. Again, there are sensible ways to
address this.
Finally, in the verifier:
is_priv = capable(CAP_SYS_ADMIN);
That should just be left alone. Arguably you could make a new
capability CAP_BPF_LEAK_KERNEL_ADDRESSES or similar for this.
As it stands, it seems like bpf() was designed under the assumption
that the kind of security model needed to make it work well for
unprivileged or differently-privileged users would be developed later.
But, instead of developing such a security model, this patch is
introducing a whole new Linux "capability" that just disables all
security. From my perspective, this seems like a bad idea.
So, if anyone cares about my opinion, NAK to the whole concept.
Please instead work on fixing this for real, one capable() check at a
time.
^ 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