* Re: [PATCH bpf-next 2/2] tools: bpftool: add "bpftool map freeze" subcommand
From: Daniel Borkmann @ 2019-08-21 13:08 UTC (permalink / raw)
To: Quentin Monnet, Alexei Starovoitov; +Cc: bpf, netdev, oss-drivers
In-Reply-To: <2b6d7326-fc74-288b-fa52-b79752222123@netronome.com>
On 8/21/19 2:58 PM, Quentin Monnet wrote:
> 2019-08-21 13:40 UTC+0200 ~ Daniel Borkmann <daniel@iogearbox.net>
>> On 8/21/19 10:52 AM, Quentin Monnet wrote:
>>> Add a new subcommand to freeze maps from user space.
>>>
>>> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
>>> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>>> ---
>>> .../bpf/bpftool/Documentation/bpftool-map.rst | 9 +++++
>>> tools/bpf/bpftool/bash-completion/bpftool | 4 +--
>>> tools/bpf/bpftool/map.c | 34 ++++++++++++++++++-
>>> 3 files changed, 44 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/tools/bpf/bpftool/Documentation/bpftool-map.rst
>>> b/tools/bpf/bpftool/Documentation/bpftool-map.rst
>>> index 61d1d270eb5e..1c0f7146aab0 100644
>>> --- a/tools/bpf/bpftool/Documentation/bpftool-map.rst
>>> +++ b/tools/bpf/bpftool/Documentation/bpftool-map.rst
>>> @@ -36,6 +36,7 @@ MAP COMMANDS
>>> | **bpftool** **map pop** *MAP*
>>> | **bpftool** **map enqueue** *MAP* **value** *VALUE*
>>> | **bpftool** **map dequeue** *MAP*
>>> +| **bpftool** **map freeze** *MAP*
>>> | **bpftool** **map help**
>>> |
>>> | *MAP* := { **id** *MAP_ID* | **pinned** *FILE* }
>>> @@ -127,6 +128,14 @@ DESCRIPTION
>>> **bpftool map dequeue** *MAP*
>>> Dequeue and print **value** from the queue.
>>> + **bpftool map freeze** *MAP*
>>> + Freeze the map as read-only from user space. Entries from a
>>> + frozen map can not longer be updated or deleted with the
>>> + **bpf\ ()** system call. This operation is not reversible,
>>> + and the map remains immutable from user space until its
>>> + destruction. However, read and write permissions for BPF
>>> + programs to the map remain unchanged.
>>
>> That is not correct, programs that are loaded into the system /after/
>> the map
>> has been frozen cannot modify values either, thus read-only from both
>> sides.
>
> Are you entirely sure about it? I could not find the relevant
> restriction in the code, the checks seem to be on map flags
> (BPF_F_RDONLY) which do not seem to be modified by the "frozen" status
> in map_freeze()? And tests I ran on my side seem to indicate the map can
> still be updated by new programs. Did I miss something?
>
> Tested on 5.3.0-rc1:
>
> 1. Create hash map
> 2. Load BPF program foo, using map
> 3. Test-run program foo - map is updated
> 4. Freeze map - update effectively becomes impossible from user space
> 5. Load BPF program bar, using same map
> 6. Test-run program bar - map is still updated
Looks like I need some more coffee. ;-) Indeed, the program side was via
BPF_F_RDONLY_PROG flag.
^ permalink raw reply
* Re: [PATCH bpf-next v4] libbpf: add xsk_ring_prod__nb_free() function
From: Magnus Karlsson @ 2019-08-21 13:11 UTC (permalink / raw)
To: Eelco Chaudron
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Andrii Nakryiko
In-Reply-To: <d1773613833e2824f95c3adbe46bff757280c16e.1565790591.git.echaudro@redhat.com>
On Wed, Aug 14, 2019 at 3:51 PM Eelco Chaudron <echaudro@redhat.com> wrote:
>
> When an AF_XDP application received X packets, it does not mean X
> frames can be stuffed into the producer ring. To make it easier for
> AF_XDP applications this API allows them to check how many frames can
> be added into the ring.
>
> The patch below looks like a name change only, but the xsk_prod__
> prefix denotes that this API is exposed to be used by applications.
>
> Besides, if you set the nb value to the size of the ring, you will
> get the exact amount of slots available, at the cost of performance
> (you touch shared state for sure). nb is there to limit the
> touching of the shared state.
>
> Also the example xdpsock application has been modified to use this
> new API, so it's also able to process flows at a 1pps rate on veth
> interfaces.
My apologies for the late reply and thank you for working on this. So
what kind of performance difference do you see with your modified
xdpsock application on a regular NIC for txpush and l2fwd? If there is
basically no difference or it is faster, we can go ahead and accept
this. But if the difference is large, we might consider to have two
versions of txpush and l2fwd as the regular NICs do not need this. Or
we optimize your code so that it becomes as fast as the previous
version.
/Magnus
> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> ---
>
> v3 -> v4
> - Cleanedup commit message
> - Updated AF_XDP sample application to use this new API
>
> v2 -> v3
> - Removed cache by pass option
>
> v1 -> v2
> - Renamed xsk_ring_prod__free() to xsk_ring_prod__nb_free()
> - Add caching so it will only touch global state when needed
>
> samples/bpf/xdpsock_user.c | 109 ++++++++++++++++++++++++++++---------
> tools/lib/bpf/xsk.h | 4 +-
> 2 files changed, 86 insertions(+), 27 deletions(-)
>
> diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
> index 93eaaf7239b2..87115e233b54 100644
> --- a/samples/bpf/xdpsock_user.c
> +++ b/samples/bpf/xdpsock_user.c
> @@ -461,9 +461,13 @@ static void kick_tx(struct xsk_socket_info *xsk)
>
> static inline void complete_tx_l2fwd(struct xsk_socket_info *xsk)
> {
> - u32 idx_cq = 0, idx_fq = 0;
> - unsigned int rcvd;
> + static u64 free_frames[NUM_FRAMES];
> + static size_t nr_free_frames;
> +
> + u32 idx_cq = 0, idx_fq = 0, free_slots;
> + unsigned int rcvd, i;
> size_t ndescs;
> + int ret;
>
> if (!xsk->outstanding_tx)
> return;
> @@ -474,27 +478,52 @@ static inline void complete_tx_l2fwd(struct xsk_socket_info *xsk)
>
> /* re-add completed Tx buffers */
> rcvd = xsk_ring_cons__peek(&xsk->umem->cq, ndescs, &idx_cq);
> - if (rcvd > 0) {
> - unsigned int i;
> - int ret;
> + if (!rcvd)
> + return;
>
> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
> - while (ret != rcvd) {
> - if (ret < 0)
> - exit_with_error(-ret);
> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd,
> - &idx_fq);
> - }
> - for (i = 0; i < rcvd; i++)
> + /* When xsk_ring_cons__peek() for example returns that 5 packets
> + * have been received, it does not automatically mean that
> + * xsk_ring_prod__reserve() will have 5 slots available. You will
> + * see this, for example, when using a veth interface due to the
> + * RX_BATCH_SIZE used by the generic driver.
> + *
> + * In this example we store unused buffers and try to re-stock
> + * them the next iteration.
> + */
> +
> + free_slots = xsk_prod__nb_free(&xsk->umem->fq, rcvd + nr_free_frames);
> + if (free_slots > rcvd + nr_free_frames)
> + free_slots = rcvd + nr_free_frames;
> +
> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots, &idx_fq);
> + while (ret != free_slots) {
> + if (ret < 0)
> + exit_with_error(-ret);
> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots,
> + &idx_fq);
> + }
> + for (i = 0; i < rcvd; i++) {
> + u64 addr = *xsk_ring_cons__comp_addr(&xsk->umem->cq, idx_cq++);
> +
> + if (i < free_slots)
> *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
> - *xsk_ring_cons__comp_addr(&xsk->umem->cq,
> - idx_cq++);
> + addr;
> + else
> + free_frames[nr_free_frames++] = addr;
> + }
>
> - xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
> - xsk_ring_cons__release(&xsk->umem->cq, rcvd);
> - xsk->outstanding_tx -= rcvd;
> - xsk->tx_npkts += rcvd;
> + if (free_slots > rcvd) {
> + for (i = 0; i < (free_slots - rcvd); i++) {
> + u64 addr = free_frames[--nr_free_frames];
> + *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
> + addr;
> + }
> }
> +
> + xsk_ring_prod__submit(&xsk->umem->fq, free_slots);
> + xsk_ring_cons__release(&xsk->umem->cq, rcvd);
> + xsk->outstanding_tx -= rcvd;
> + xsk->tx_npkts += rcvd;
> }
>
> static inline void complete_tx_only(struct xsk_socket_info *xsk)
> @@ -517,19 +546,37 @@ static inline void complete_tx_only(struct xsk_socket_info *xsk)
>
> static void rx_drop(struct xsk_socket_info *xsk)
> {
> + static u64 free_frames[NUM_FRAMES];
> + static size_t nr_free_frames;
> +
> unsigned int rcvd, i;
> - u32 idx_rx = 0, idx_fq = 0;
> + u32 idx_rx = 0, idx_fq = 0, free_slots;
> int ret;
>
> rcvd = xsk_ring_cons__peek(&xsk->rx, BATCH_SIZE, &idx_rx);
> if (!rcvd)
> return;
>
> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
> - while (ret != rcvd) {
> + /* When xsk_ring_cons__peek() for example returns that 5 packets
> + * have been received, it does not automatically mean that
> + * xsk_ring_prod__reserve() will have 5 slots available. You will
> + * see this, for example, when using a veth interface due to the
> + * RX_BATCH_SIZE used by the generic driver.
> + *
> + * In this example we store unused buffers and try to re-stock
> + * them the next iteration.
> + */
> +
> + free_slots = xsk_prod__nb_free(&xsk->umem->fq, rcvd + nr_free_frames);
> + if (free_slots > rcvd + nr_free_frames)
> + free_slots = rcvd + nr_free_frames;
> +
> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots, &idx_fq);
> + while (ret != free_slots) {
> if (ret < 0)
> exit_with_error(-ret);
> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots,
> + &idx_fq);
> }
>
> for (i = 0; i < rcvd; i++) {
> @@ -538,10 +585,22 @@ static void rx_drop(struct xsk_socket_info *xsk)
> char *pkt = xsk_umem__get_data(xsk->umem->buffer, addr);
>
> hex_dump(pkt, len, addr);
> - *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) = addr;
> + if (i < free_slots)
> + *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
> + addr;
> + else
> + free_frames[nr_free_frames++] = addr;
> + }
> +
> + if (free_slots > rcvd) {
> + for (i = 0; i < (free_slots - rcvd); i++) {
> + u64 addr = free_frames[--nr_free_frames];
> + *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
> + addr;
> + }
> }
>
> - xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
> + xsk_ring_prod__submit(&xsk->umem->fq, free_slots);
> xsk_ring_cons__release(&xsk->rx, rcvd);
> xsk->rx_npkts += rcvd;
> }
> diff --git a/tools/lib/bpf/xsk.h b/tools/lib/bpf/xsk.h
> index 833a6e60d065..cae506ab3f3c 100644
> --- a/tools/lib/bpf/xsk.h
> +++ b/tools/lib/bpf/xsk.h
> @@ -76,7 +76,7 @@ xsk_ring_cons__rx_desc(const struct xsk_ring_cons *rx, __u32 idx)
> return &descs[idx & rx->mask];
> }
>
> -static inline __u32 xsk_prod_nb_free(struct xsk_ring_prod *r, __u32 nb)
> +static inline __u32 xsk_prod__nb_free(struct xsk_ring_prod *r, __u32 nb)
> {
> __u32 free_entries = r->cached_cons - r->cached_prod;
>
> @@ -110,7 +110,7 @@ static inline __u32 xsk_cons_nb_avail(struct xsk_ring_cons *r, __u32 nb)
> static inline size_t xsk_ring_prod__reserve(struct xsk_ring_prod *prod,
> size_t nb, __u32 *idx)
> {
> - if (xsk_prod_nb_free(prod, nb) < nb)
> + if (xsk_prod__nb_free(prod, nb) < nb)
> return 0;
>
> *idx = prod->cached_prod;
> --
> 2.18.1
>
^ permalink raw reply
* [PATCH 0/1] pull request for net: batman-adv 2019-08-21
From: Simon Wunderlich @ 2019-08-21 13:30 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Simon Wunderlich
Hi David,
here is a pull request with Erics bugfix from last week which we would
like to have integrated into net. We didn't get anything else, so it's
a short one this time. :)
Please pull or let me know of any problem!
Thank you,
Simon
The following changes since commit f7af86ccf1882084293b11077deec049fd01da63:
batman-adv: Fix deletion of RTR(4|6) mcast list entries (2019-07-22 21:34:58 +0200)
are available in the Git repository at:
git://git.open-mesh.org/linux-merge.git tags/batadv-net-for-davem-20190821
for you to fetch changes up to 3ee1bb7aae97324ec9078da1f00cb2176919563f:
batman-adv: fix uninit-value in batadv_netlink_get_ifindex() (2019-08-14 19:27:07 +0200)
----------------------------------------------------------------
Here is a batman-adv bugfix:
- fix uninit-value in batadv_netlink_get_ifindex(), by Eric Dumazet
----------------------------------------------------------------
Eric Dumazet (1):
batman-adv: fix uninit-value in batadv_netlink_get_ifindex()
net/batman-adv/netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH 1/1] batman-adv: fix uninit-value in batadv_netlink_get_ifindex()
From: Simon Wunderlich @ 2019-08-21 13:30 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Eric Dumazet, syzbot, Sven Eckelmann,
Simon Wunderlich
In-Reply-To: <20190821133015.12778-1-sw@simonwunderlich.de>
From: Eric Dumazet <edumazet@google.com>
batadv_netlink_get_ifindex() needs to make sure user passed
a correct u32 attribute.
syzbot reported :
BUG: KMSAN: uninit-value in batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968
CPU: 1 PID: 11705 Comm: syz-executor888 Not tainted 5.1.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x191/0x1f0 lib/dump_stack.c:113
kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
__msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968
genl_lock_dumpit+0xc6/0x130 net/netlink/genetlink.c:482
netlink_dump+0xa84/0x1ab0 net/netlink/af_netlink.c:2253
__netlink_dump_start+0xa3a/0xb30 net/netlink/af_netlink.c:2361
genl_family_rcv_msg net/netlink/genetlink.c:550 [inline]
genl_rcv_msg+0xfc1/0x1a40 net/netlink/genetlink.c:627
netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2486
genl_rcv+0x63/0x80 net/netlink/genetlink.c:638
netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1337
netlink_sendmsg+0x127e/0x12f0 net/netlink/af_netlink.c:1926
sock_sendmsg_nosec net/socket.c:651 [inline]
sock_sendmsg net/socket.c:661 [inline]
___sys_sendmsg+0xcc6/0x1200 net/socket.c:2260
__sys_sendmsg net/socket.c:2298 [inline]
__do_sys_sendmsg net/socket.c:2307 [inline]
__se_sys_sendmsg+0x305/0x460 net/socket.c:2305
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2305
do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x440209
Fixes: b60620cf567b ("batman-adv: netlink: hardif query")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/netlink.c b/net/batman-adv/netlink.c
index 6f08fd122a8d..7e052d6f759b 100644
--- a/net/batman-adv/netlink.c
+++ b/net/batman-adv/netlink.c
@@ -164,7 +164,7 @@ batadv_netlink_get_ifindex(const struct nlmsghdr *nlh, int attrtype)
{
struct nlattr *attr = nlmsg_find_attr(nlh, GENL_HDRLEN, attrtype);
- return attr ? nla_get_u32(attr) : 0;
+ return (attr && nla_len(attr) == sizeof(u32)) ? nla_get_u32(attr) : 0;
}
/**
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] net: fec: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:29 UTC (permalink / raw)
To: davem, fugang.duan; +Cc: linux-kernel, netdev, YueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/freescale/fec_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index c01d3ec..cacc671 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3338,7 +3338,6 @@ fec_probe(struct platform_device *pdev)
struct fec_platform_data *pdata;
struct net_device *ndev;
int i, irq, ret = 0;
- struct resource *r;
const struct of_device_id *of_id;
static int dev_id;
struct device_node *np = pdev->dev.of_node, *phy_node;
@@ -3378,8 +3377,7 @@ fec_probe(struct platform_device *pdev)
/* Select default pin state */
pinctrl_pm_select_default_state(&pdev->dev);
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- fep->hwp = devm_ioremap_resource(&pdev->dev, r);
+ fep->hwp = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(fep->hwp)) {
ret = PTR_ERR(fep->hwp);
goto failed_ioremap;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] amd-xgbe: use devm_platform_ioremap_resource() to simplify code
From: Lendacky, Thomas @ 2019-08-21 13:32 UTC (permalink / raw)
To: YueHaibing, davem@davemloft.net
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190821123203.71404-1-yuehaibing@huawei.com>
On 8/21/19 7:32 AM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> drivers/net/ethernet/amd/xgbe/xgbe-platform.c | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-platform.c b/drivers/net/ethernet/amd/xgbe/xgbe-platform.c
> index dce9e59..4ebd241 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-platform.c
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-platform.c
> @@ -301,7 +301,6 @@ static int xgbe_platform_probe(struct platform_device *pdev)
> struct xgbe_prv_data *pdata;
> struct device *dev = &pdev->dev;
> struct platform_device *phy_pdev;
> - struct resource *res;
> const char *phy_mode;
> unsigned int phy_memnum, phy_irqnum;
> unsigned int dma_irqnum, dma_irqend;
> @@ -353,8 +352,7 @@ static int xgbe_platform_probe(struct platform_device *pdev)
> }
>
> /* Obtain the mmio areas for the device */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - pdata->xgmac_regs = devm_ioremap_resource(dev, res);
> + pdata->xgmac_regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(pdata->xgmac_regs)) {
> dev_err(dev, "xgmac ioremap failed\n");
> ret = PTR_ERR(pdata->xgmac_regs);
> @@ -363,8 +361,7 @@ static int xgbe_platform_probe(struct platform_device *pdev)
> if (netif_msg_probe(pdata))
> dev_dbg(dev, "xgmac_regs = %p\n", pdata->xgmac_regs);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - pdata->xpcs_regs = devm_ioremap_resource(dev, res);
> + pdata->xpcs_regs = devm_platform_ioremap_resource(pdev, 1);
> if (IS_ERR(pdata->xpcs_regs)) {
> dev_err(dev, "xpcs ioremap failed\n");
> ret = PTR_ERR(pdata->xpcs_regs);
> @@ -373,8 +370,8 @@ static int xgbe_platform_probe(struct platform_device *pdev)
> if (netif_msg_probe(pdata))
> dev_dbg(dev, "xpcs_regs = %p\n", pdata->xpcs_regs);
>
> - res = platform_get_resource(phy_pdev, IORESOURCE_MEM, phy_memnum++);
> - pdata->rxtx_regs = devm_ioremap_resource(dev, res);
> + pdata->rxtx_regs = devm_platform_ioremap_resource(phy_pdev,
> + phy_memnum++);
> if (IS_ERR(pdata->rxtx_regs)) {
> dev_err(dev, "rxtx ioremap failed\n");
> ret = PTR_ERR(pdata->rxtx_regs);
> @@ -383,8 +380,8 @@ static int xgbe_platform_probe(struct platform_device *pdev)
> if (netif_msg_probe(pdata))
> dev_dbg(dev, "rxtx_regs = %p\n", pdata->rxtx_regs);
>
> - res = platform_get_resource(phy_pdev, IORESOURCE_MEM, phy_memnum++);
> - pdata->sir0_regs = devm_ioremap_resource(dev, res);
> + pdata->sir0_regs = devm_platform_ioremap_resource(phy_pdev,
> + phy_memnum++);
> if (IS_ERR(pdata->sir0_regs)) {
> dev_err(dev, "sir0 ioremap failed\n");
> ret = PTR_ERR(pdata->sir0_regs);
> @@ -393,8 +390,8 @@ static int xgbe_platform_probe(struct platform_device *pdev)
> if (netif_msg_probe(pdata))
> dev_dbg(dev, "sir0_regs = %p\n", pdata->sir0_regs);
>
> - res = platform_get_resource(phy_pdev, IORESOURCE_MEM, phy_memnum++);
> - pdata->sir1_regs = devm_ioremap_resource(dev, res);
> + pdata->sir1_regs = devm_platform_ioremap_resource(phy_pdev,
> + phy_memnum++);
> if (IS_ERR(pdata->sir1_regs)) {
> dev_err(dev, "sir1 ioremap failed\n");
> ret = PTR_ERR(pdata->sir1_regs);
>
^ permalink raw reply
* [PATCH net-next] net: mvneta: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:33 UTC (permalink / raw)
To: davem, bigeasy; +Cc: linux-kernel, netdev, YueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/marvell/mvneta_bm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta_bm.c b/drivers/net/ethernet/marvell/mvneta_bm.c
index 82ee2bc..46c942e 100644
--- a/drivers/net/ethernet/marvell/mvneta_bm.c
+++ b/drivers/net/ethernet/marvell/mvneta_bm.c
@@ -411,15 +411,13 @@ static int mvneta_bm_probe(struct platform_device *pdev)
{
struct device_node *dn = pdev->dev.of_node;
struct mvneta_bm *priv;
- struct resource *res;
int err;
priv = devm_kzalloc(&pdev->dev, sizeof(struct mvneta_bm), GFP_KERNEL);
if (!priv)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->reg_base = devm_ioremap_resource(&pdev->dev, res);
+ priv->reg_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->reg_base))
return PTR_ERR(priv->reg_base);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] pxa168_eth: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:38 UTC (permalink / raw)
To: davem, andrew, mcgrof, tglx, ynezz; +Cc: linux-kernel, netdev, YueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/marvell/pxa168_eth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index 3aa9987..51b77c2 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -1425,8 +1425,7 @@ static int pxa168_eth_probe(struct platform_device *pdev)
pep->dev = dev;
pep->clk = clk;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- pep->base = devm_ioremap_resource(&pdev->dev, res);
+ pep->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(pep->base)) {
err = -ENOMEM;
goto err_netdev;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] net: bcmgenet: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:41 UTC (permalink / raw)
To: davem, opendmb, f.fainelli, bcm-kernel-feedback-list
Cc: linux-kernel, netdev, YueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index d3a0b61..2108e59 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -3437,7 +3437,6 @@ static int bcmgenet_probe(struct platform_device *pdev)
struct bcmgenet_priv *priv;
struct net_device *dev;
const void *macaddr;
- struct resource *r;
unsigned int i;
int err = -EIO;
const char *phy_mode_str;
@@ -3477,8 +3476,7 @@ static int bcmgenet_probe(struct platform_device *pdev)
macaddr = pd->mac_address;
}
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->base = devm_ioremap_resource(&pdev->dev, r);
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->base)) {
err = PTR_ERR(priv->base);
goto err;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] rtnetlink: gate MAC address with an LSM hook
From: Jeff Vander Stoep @ 2019-08-21 13:45 UTC (permalink / raw)
To: netdev, linux-security-module, selinux; +Cc: Jeff Vander Stoep
MAC addresses are often considered sensitive because they are
usually unique and can be used to identify/track a device or
user [1].
The MAC address is accessible via the RTM_NEWLINK message type of a
netlink route socket[2]. Ideally we could grant/deny access to the
MAC address on a case-by-case basis without blocking the entire
RTM_NEWLINK message type which contains a lot of other useful
information. This can be achieved using a new LSM hook on the netlink
message receive path. Using this new hook, individual LSMs can select
which processes are allowed access to the real MAC, otherwise a
default value of zeros is returned. Offloading access control
decisions like this to an LSM is convenient because it preserves the
status quo for most Linux users while giving the various LSMs
flexibility to make finer grained decisions on access to sensitive
data based on policy.
[1] https://adamdrake.com/mac-addresses-udids-and-privacy.html
[2] Other access vectors like ioctl(SIOCGIFHWADDR) are already covered
by existing LSM hooks.
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
---
include/linux/lsm_hooks.h | 8 ++++++++
include/linux/security.h | 6 ++++++
net/core/rtnetlink.c | 12 ++++++++++--
security/security.c | 5 +++++
4 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index df1318d85f7d..dfcb2e11ff43 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -728,6 +728,12 @@
*
* Security hooks for Netlink messaging.
*
+ * @netlink_receive
+ * Check permissions on a netlink message field before populating it.
+ * @sk associated sock of task receiving the message.
+ * @skb contains the sk_buff structure for the netlink message.
+ * Return 0 if the data should be included in the message.
+ *
* @netlink_send:
* Save security information for a netlink message so that permission
* checking can be performed when the message is processed. The security
@@ -1673,6 +1679,7 @@ union security_list_options {
int (*sem_semop)(struct kern_ipc_perm *perm, struct sembuf *sops,
unsigned nsops, int alter);
+ int (*netlink_receive)(struct sock *sk, struct sk_buff *skb);
int (*netlink_send)(struct sock *sk, struct sk_buff *skb);
void (*d_instantiate)(struct dentry *dentry, struct inode *inode);
@@ -1952,6 +1959,7 @@ struct security_hook_heads {
struct hlist_head sem_associate;
struct hlist_head sem_semctl;
struct hlist_head sem_semop;
+ struct hlist_head netlink_receive;
struct hlist_head netlink_send;
struct hlist_head d_instantiate;
struct hlist_head getprocattr;
diff --git a/include/linux/security.h b/include/linux/security.h
index 5f7441abbf42..46b5af6de59e 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -382,6 +382,7 @@ int security_getprocattr(struct task_struct *p, const char *lsm, char *name,
char **value);
int security_setprocattr(const char *lsm, const char *name, void *value,
size_t size);
+int security_netlink_receive(struct sock *sk, struct sk_buff *skb);
int security_netlink_send(struct sock *sk, struct sk_buff *skb);
int security_ismaclabel(const char *name);
int security_secid_to_secctx(u32 secid, char **secdata, u32 *seclen);
@@ -1162,6 +1163,11 @@ static inline int security_setprocattr(const char *lsm, char *name,
return -EINVAL;
}
+static inline int security_netlink_receive(struct sock *sk, struct sk_buff *skb)
+{
+ return 0;
+}
+
static inline int security_netlink_send(struct sock *sk, struct sk_buff *skb)
{
return 0;
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 1ee6460f8275..7d69fcb8d22e 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1650,8 +1650,16 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb,
goto nla_put_failure;
if (dev->addr_len) {
- if (nla_put(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr) ||
- nla_put(skb, IFLA_BROADCAST, dev->addr_len, dev->broadcast))
+ if (skb->sk && security_netlink_receive(skb->sk, skb)) {
+ if (!nla_reserve(skb, IFLA_ADDRESS, dev->addr_len))
+ goto nla_put_failure;
+
+ } else {
+ if (nla_put(skb, IFLA_ADDRESS, dev->addr_len,
+ dev->dev_addr))
+ goto nla_put_failure;
+ }
+ if (nla_put(skb, IFLA_BROADCAST, dev->addr_len, dev->broadcast))
goto nla_put_failure;
}
diff --git a/security/security.c b/security/security.c
index 250ee2d76406..35c5929921b2 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1861,6 +1861,11 @@ int security_setprocattr(const char *lsm, const char *name, void *value,
return -EINVAL;
}
+int security_netlink_receive(struct sock *sk, struct sk_buff *skb)
+{
+ return call_int_hook(netlink_receive, 0, sk, skb);
+}
+
int security_netlink_send(struct sock *sk, struct sk_buff *skb)
{
return call_int_hook(netlink_send, 0, sk, skb);
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* [PATCH 2/2] selinux: use netlink_receive hook
From: Jeff Vander Stoep @ 2019-08-21 13:46 UTC (permalink / raw)
To: netdev, linux-security-module, selinux; +Cc: Jeff Vander Stoep
Add the nlmsg_readpriv permission to netlink_route socket class.
Currently this is only used to restrict MAC address access.
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
---
security/selinux/hooks.c | 6 ++++++
security/selinux/include/classmap.h | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 74dd46de01b6..2ab89a73f663 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5825,6 +5825,11 @@ static unsigned int selinux_ipv6_postroute(void *priv,
#endif /* CONFIG_NETFILTER */
+static int selinux_netlink_receive(struct sock *sk, struct sk_buff *skb)
+{
+ return sock_has_perm(current, sk, NETLINK_ROUTE_SOCKET__NLMSG_READPRIV);
+}
+
static int selinux_netlink_send(struct sock *sk, struct sk_buff *skb)
{
return selinux_nlmsg_perm(sk, skb);
@@ -6765,6 +6770,7 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(syslog, selinux_syslog),
LSM_HOOK_INIT(vm_enough_memory, selinux_vm_enough_memory),
+ LSM_HOOK_INIT(netlink_receive, selinux_netlink_receive),
LSM_HOOK_INIT(netlink_send, selinux_netlink_send),
LSM_HOOK_INIT(bprm_set_creds, selinux_bprm_set_creds),
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index 201f7e588a29..3726c61a3dd1 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -115,7 +115,7 @@ struct security_class_mapping secclass_map[] = {
{ COMMON_IPC_PERMS, NULL } },
{ "netlink_route_socket",
{ COMMON_SOCK_PERMS,
- "nlmsg_read", "nlmsg_write", NULL } },
+ "nlmsg_read", "nlmsg_write", "nlmsg_readpriv", NULL } },
{ "netlink_tcpdiag_socket",
{ COMMON_SOCK_PERMS,
"nlmsg_read", "nlmsg_write", NULL } },
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* Re: [PATCH bpf-next v4] libbpf: add xsk_ring_prod__nb_free() function
From: Eelco Chaudron @ 2019-08-21 13:46 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Andrii Nakryiko
In-Reply-To: <CAJ8uoz3MszznV7McpttcVauQ5vgSiOpfT7J=63BNbruVwjFQBQ@mail.gmail.com>
On 21 Aug 2019, at 15:11, Magnus Karlsson wrote:
> On Wed, Aug 14, 2019 at 3:51 PM Eelco Chaudron <echaudro@redhat.com>
> wrote:
>>
>> When an AF_XDP application received X packets, it does not mean X
>> frames can be stuffed into the producer ring. To make it easier for
>> AF_XDP applications this API allows them to check how many frames can
>> be added into the ring.
>>
>> The patch below looks like a name change only, but the xsk_prod__
>> prefix denotes that this API is exposed to be used by applications.
>>
>> Besides, if you set the nb value to the size of the ring, you will
>> get the exact amount of slots available, at the cost of performance
>> (you touch shared state for sure). nb is there to limit the
>> touching of the shared state.
>>
>> Also the example xdpsock application has been modified to use this
>> new API, so it's also able to process flows at a 1pps rate on veth
>> interfaces.
>
> My apologies for the late reply and thank you for working on this. So
> what kind of performance difference do you see with your modified
> xdpsock application on a regular NIC for txpush and l2fwd? If there is
> basically no difference or it is faster, we can go ahead and accept
> this. But if the difference is large, we might consider to have two
> versions of txpush and l2fwd as the regular NICs do not need this. Or
> we optimize your code so that it becomes as fast as the previous
> version.
For both operation modes, I ran 5 test with and without the changes
applied using an iexgb connecting to a XENA tester. The throughput
numbers were within the standard deviation, so no noticeable performance
gain or drop.
Let me know if this is enough, if not I can rebuild the setup and do
some more tests.
> /Magnus
>
>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>> ---
>>
>> v3 -> v4
>> - Cleanedup commit message
>> - Updated AF_XDP sample application to use this new API
>>
>> v2 -> v3
>> - Removed cache by pass option
>>
>> v1 -> v2
>> - Renamed xsk_ring_prod__free() to xsk_ring_prod__nb_free()
>> - Add caching so it will only touch global state when needed
>>
>> samples/bpf/xdpsock_user.c | 109
>> ++++++++++++++++++++++++++++---------
>> tools/lib/bpf/xsk.h | 4 +-
>> 2 files changed, 86 insertions(+), 27 deletions(-)
>>
>> diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
>> index 93eaaf7239b2..87115e233b54 100644
>> --- a/samples/bpf/xdpsock_user.c
>> +++ b/samples/bpf/xdpsock_user.c
>> @@ -461,9 +461,13 @@ static void kick_tx(struct xsk_socket_info *xsk)
>>
>> static inline void complete_tx_l2fwd(struct xsk_socket_info *xsk)
>> {
>> - u32 idx_cq = 0, idx_fq = 0;
>> - unsigned int rcvd;
>> + static u64 free_frames[NUM_FRAMES];
>> + static size_t nr_free_frames;
>> +
>> + u32 idx_cq = 0, idx_fq = 0, free_slots;
>> + unsigned int rcvd, i;
>> size_t ndescs;
>> + int ret;
>>
>> if (!xsk->outstanding_tx)
>> return;
>> @@ -474,27 +478,52 @@ static inline void complete_tx_l2fwd(struct
>> xsk_socket_info *xsk)
>>
>> /* re-add completed Tx buffers */
>> rcvd = xsk_ring_cons__peek(&xsk->umem->cq, ndescs, &idx_cq);
>> - if (rcvd > 0) {
>> - unsigned int i;
>> - int ret;
>> + if (!rcvd)
>> + return;
>>
>> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd,
>> &idx_fq);
>> - while (ret != rcvd) {
>> - if (ret < 0)
>> - exit_with_error(-ret);
>> - ret = xsk_ring_prod__reserve(&xsk->umem->fq,
>> rcvd,
>> - &idx_fq);
>> - }
>> - for (i = 0; i < rcvd; i++)
>> + /* When xsk_ring_cons__peek() for example returns that 5
>> packets
>> + * have been received, it does not automatically mean that
>> + * xsk_ring_prod__reserve() will have 5 slots available. You
>> will
>> + * see this, for example, when using a veth interface due to
>> the
>> + * RX_BATCH_SIZE used by the generic driver.
>> + *
>> + * In this example we store unused buffers and try to
>> re-stock
>> + * them the next iteration.
>> + */
>> +
>> + free_slots = xsk_prod__nb_free(&xsk->umem->fq, rcvd +
>> nr_free_frames);
>> + if (free_slots > rcvd + nr_free_frames)
>> + free_slots = rcvd + nr_free_frames;
>> +
>> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots,
>> &idx_fq);
>> + while (ret != free_slots) {
>> + if (ret < 0)
>> + exit_with_error(-ret);
>> + ret = xsk_ring_prod__reserve(&xsk->umem->fq,
>> free_slots,
>> + &idx_fq);
>> + }
>> + for (i = 0; i < rcvd; i++) {
>> + u64 addr = *xsk_ring_cons__comp_addr(&xsk->umem->cq,
>> idx_cq++);
>> +
>> + if (i < free_slots)
>> *xsk_ring_prod__fill_addr(&xsk->umem->fq,
>> idx_fq++) =
>> -
>> *xsk_ring_cons__comp_addr(&xsk->umem->cq,
>> - idx_cq++);
>> + addr;
>> + else
>> + free_frames[nr_free_frames++] = addr;
>> + }
>>
>> - xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
>> - xsk_ring_cons__release(&xsk->umem->cq, rcvd);
>> - xsk->outstanding_tx -= rcvd;
>> - xsk->tx_npkts += rcvd;
>> + if (free_slots > rcvd) {
>> + for (i = 0; i < (free_slots - rcvd); i++) {
>> + u64 addr = free_frames[--nr_free_frames];
>> + *xsk_ring_prod__fill_addr(&xsk->umem->fq,
>> idx_fq++) =
>> + addr;
>> + }
>> }
>> +
>> + xsk_ring_prod__submit(&xsk->umem->fq, free_slots);
>> + xsk_ring_cons__release(&xsk->umem->cq, rcvd);
>> + xsk->outstanding_tx -= rcvd;
>> + xsk->tx_npkts += rcvd;
>> }
>>
>> static inline void complete_tx_only(struct xsk_socket_info *xsk)
>> @@ -517,19 +546,37 @@ static inline void complete_tx_only(struct
>> xsk_socket_info *xsk)
>>
>> static void rx_drop(struct xsk_socket_info *xsk)
>> {
>> + static u64 free_frames[NUM_FRAMES];
>> + static size_t nr_free_frames;
>> +
>> unsigned int rcvd, i;
>> - u32 idx_rx = 0, idx_fq = 0;
>> + u32 idx_rx = 0, idx_fq = 0, free_slots;
>> int ret;
>>
>> rcvd = xsk_ring_cons__peek(&xsk->rx, BATCH_SIZE, &idx_rx);
>> if (!rcvd)
>> return;
>>
>> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
>> - while (ret != rcvd) {
>> + /* When xsk_ring_cons__peek() for example returns that 5
>> packets
>> + * have been received, it does not automatically mean that
>> + * xsk_ring_prod__reserve() will have 5 slots available. You
>> will
>> + * see this, for example, when using a veth interface due to
>> the
>> + * RX_BATCH_SIZE used by the generic driver.
>> + *
>> + * In this example we store unused buffers and try to
>> re-stock
>> + * them the next iteration.
>> + */
>> +
>> + free_slots = xsk_prod__nb_free(&xsk->umem->fq, rcvd +
>> nr_free_frames);
>> + if (free_slots > rcvd + nr_free_frames)
>> + free_slots = rcvd + nr_free_frames;
>> +
>> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots,
>> &idx_fq);
>> + while (ret != free_slots) {
>> if (ret < 0)
>> exit_with_error(-ret);
>> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd,
>> &idx_fq);
>> + ret = xsk_ring_prod__reserve(&xsk->umem->fq,
>> free_slots,
>> + &idx_fq);
>> }
>>
>> for (i = 0; i < rcvd; i++) {
>> @@ -538,10 +585,22 @@ static void rx_drop(struct xsk_socket_info
>> *xsk)
>> char *pkt = xsk_umem__get_data(xsk->umem->buffer,
>> addr);
>>
>> hex_dump(pkt, len, addr);
>> - *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
>> addr;
>> + if (i < free_slots)
>> + *xsk_ring_prod__fill_addr(&xsk->umem->fq,
>> idx_fq++) =
>> + addr;
>> + else
>> + free_frames[nr_free_frames++] = addr;
>> + }
>> +
>> + if (free_slots > rcvd) {
>> + for (i = 0; i < (free_slots - rcvd); i++) {
>> + u64 addr = free_frames[--nr_free_frames];
>> + *xsk_ring_prod__fill_addr(&xsk->umem->fq,
>> idx_fq++) =
>> + addr;
>> + }
>> }
>>
>> - xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
>> + xsk_ring_prod__submit(&xsk->umem->fq, free_slots);
>> xsk_ring_cons__release(&xsk->rx, rcvd);
>> xsk->rx_npkts += rcvd;
>> }
>> diff --git a/tools/lib/bpf/xsk.h b/tools/lib/bpf/xsk.h
>> index 833a6e60d065..cae506ab3f3c 100644
>> --- a/tools/lib/bpf/xsk.h
>> +++ b/tools/lib/bpf/xsk.h
>> @@ -76,7 +76,7 @@ xsk_ring_cons__rx_desc(const struct xsk_ring_cons
>> *rx, __u32 idx)
>> return &descs[idx & rx->mask];
>> }
>>
>> -static inline __u32 xsk_prod_nb_free(struct xsk_ring_prod *r, __u32
>> nb)
>> +static inline __u32 xsk_prod__nb_free(struct xsk_ring_prod *r, __u32
>> nb)
>> {
>> __u32 free_entries = r->cached_cons - r->cached_prod;
>>
>> @@ -110,7 +110,7 @@ static inline __u32 xsk_cons_nb_avail(struct
>> xsk_ring_cons *r, __u32 nb)
>> static inline size_t xsk_ring_prod__reserve(struct xsk_ring_prod
>> *prod,
>> size_t nb, __u32 *idx)
>> {
>> - if (xsk_prod_nb_free(prod, nb) < nb)
>> + if (xsk_prod__nb_free(prod, nb) < nb)
>> return 0;
>>
>> *idx = prod->cached_prod;
>> --
>> 2.18.1
>>
^ permalink raw reply
* [PATCH net-next] net: systemport: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:46 UTC (permalink / raw)
To: davem, opendmb, f.fainelli, bcm-kernel-feedback-list
Cc: linux-kernel, netdev, YueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 9483553..cae66ba 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -2420,12 +2420,10 @@ static int bcm_sysport_probe(struct platform_device *pdev)
struct device_node *dn;
struct net_device *dev;
const void *macaddr;
- struct resource *r;
u32 txq, rxq;
int ret;
dn = pdev->dev.of_node;
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
of_id = of_match_node(bcm_sysport_of_match, dn);
if (!of_id || !of_id->data)
return -EINVAL;
@@ -2473,7 +2471,7 @@ static int bcm_sysport_probe(struct platform_device *pdev)
goto err_free_netdev;
}
- priv->base = devm_ioremap_resource(&pdev->dev, r);
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->base)) {
ret = PTR_ERR(priv->base);
goto err_free_netdev;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] net: stmmac: dwmac-meson8b: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:51 UTC (permalink / raw)
To: davem, peppe.cavallaro, alexandre.torgue, joabreu, khilman,
mcoquelin.stm32
Cc: linux-kernel, netdev, linux-arm-kernel, linux-amlogic,
linux-stm32, YueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 786ca4a..9cda29e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -308,7 +308,6 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
- struct resource *res;
struct meson8b_dwmac *dwmac;
int ret;
@@ -332,8 +331,7 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
ret = -EINVAL;
goto err_remove_config_dt;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- dwmac->regs = devm_ioremap_resource(&pdev->dev, res);
+ dwmac->regs = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(dwmac->regs)) {
ret = PTR_ERR(dwmac->regs);
goto err_remove_config_dt;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] net: stmmac: dwmac-meson: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:54 UTC (permalink / raw)
To: davem, peppe.cavallaro, alexandre.torgue, joabreu, khilman,
mcoquelin.stm32
Cc: linux-kernel, netdev, linux-arm-kernel, linux-amlogic,
linux-stm32, YueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
index 88eb169..bbc16b5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
@@ -46,7 +46,6 @@ static int meson6_dwmac_probe(struct platform_device *pdev)
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
struct meson_dwmac *dwmac;
- struct resource *res;
int ret;
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
@@ -63,8 +62,7 @@ static int meson6_dwmac_probe(struct platform_device *pdev)
goto err_remove_config_dt;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- dwmac->reg = devm_ioremap_resource(&pdev->dev, res);
+ dwmac->reg = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(dwmac->reg)) {
ret = PTR_ERR(dwmac->reg);
goto err_remove_config_dt;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] rtnetlink: gate MAC address with an LSM hook
From: Jeffrey Vander Stoep @ 2019-08-21 13:55 UTC (permalink / raw)
To: netdev, LSM List, selinux
In-Reply-To: <20190821134547.96929-1-jeffv@google.com>
On Wed, Aug 21, 2019 at 3:45 PM Jeff Vander Stoep <jeffv@google.com> wrote:
>
> MAC addresses are often considered sensitive because they are
> usually unique and can be used to identify/track a device or
> user [1].
>
> The MAC address is accessible via the RTM_NEWLINK message type of a
> netlink route socket[2]. Ideally we could grant/deny access to the
> MAC address on a case-by-case basis without blocking the entire
> RTM_NEWLINK message type which contains a lot of other useful
> information. This can be achieved using a new LSM hook on the netlink
> message receive path. Using this new hook, individual LSMs can select
> which processes are allowed access to the real MAC, otherwise a
> default value of zeros is returned. Offloading access control
> decisions like this to an LSM is convenient because it preserves the
> status quo for most Linux users while giving the various LSMs
> flexibility to make finer grained decisions on access to sensitive
> data based on policy.
>
> [1] https://adamdrake.com/mac-addresses-udids-and-privacy.html
> [2] Other access vectors like ioctl(SIOCGIFHWADDR) are already covered
> by existing LSM hooks.
>
> Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
> ---
> include/linux/lsm_hooks.h | 8 ++++++++
> include/linux/security.h | 6 ++++++
> net/core/rtnetlink.c | 12 ++++++++++--
> security/security.c | 5 +++++
> 4 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index df1318d85f7d..dfcb2e11ff43 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -728,6 +728,12 @@
> *
> * Security hooks for Netlink messaging.
> *
> + * @netlink_receive
> + * Check permissions on a netlink message field before populating it.
> + * @sk associated sock of task receiving the message.
> + * @skb contains the sk_buff structure for the netlink message.
> + * Return 0 if the data should be included in the message.
> + *
> * @netlink_send:
> * Save security information for a netlink message so that permission
> * checking can be performed when the message is processed. The security
> @@ -1673,6 +1679,7 @@ union security_list_options {
> int (*sem_semop)(struct kern_ipc_perm *perm, struct sembuf *sops,
> unsigned nsops, int alter);
>
> + int (*netlink_receive)(struct sock *sk, struct sk_buff *skb);
> int (*netlink_send)(struct sock *sk, struct sk_buff *skb);
>
> void (*d_instantiate)(struct dentry *dentry, struct inode *inode);
> @@ -1952,6 +1959,7 @@ struct security_hook_heads {
> struct hlist_head sem_associate;
> struct hlist_head sem_semctl;
> struct hlist_head sem_semop;
> + struct hlist_head netlink_receive;
> struct hlist_head netlink_send;
> struct hlist_head d_instantiate;
> struct hlist_head getprocattr;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 5f7441abbf42..46b5af6de59e 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -382,6 +382,7 @@ int security_getprocattr(struct task_struct *p, const char *lsm, char *name,
> char **value);
> int security_setprocattr(const char *lsm, const char *name, void *value,
> size_t size);
> +int security_netlink_receive(struct sock *sk, struct sk_buff *skb);
> int security_netlink_send(struct sock *sk, struct sk_buff *skb);
> int security_ismaclabel(const char *name);
> int security_secid_to_secctx(u32 secid, char **secdata, u32 *seclen);
> @@ -1162,6 +1163,11 @@ static inline int security_setprocattr(const char *lsm, char *name,
> return -EINVAL;
> }
>
> +static inline int security_netlink_receive(struct sock *sk, struct sk_buff *skb)
> +{
> + return 0;
> +}
> +
> static inline int security_netlink_send(struct sock *sk, struct sk_buff *skb)
> {
> return 0;
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 1ee6460f8275..7d69fcb8d22e 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1650,8 +1650,16 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb,
> goto nla_put_failure;
>
> if (dev->addr_len) {
> - if (nla_put(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr) ||
> - nla_put(skb, IFLA_BROADCAST, dev->addr_len, dev->broadcast))
> + if (skb->sk && security_netlink_receive(skb->sk, skb)) {
> + if (!nla_reserve(skb, IFLA_ADDRESS, dev->addr_len))
> + goto nla_put_failure;
Is populating the field with zeros the right approach or should I just
omit it entirely?
Even though this change will only impact LSM users I would still like to
minimize the potential for breakage of userspace processes. Returning the same
packet size and format seems like the least fragile thing to do.
>
> +
> + } else {
> + if (nla_put(skb, IFLA_ADDRESS, dev->addr_len,
> + dev->dev_addr))
> + goto nla_put_failure;
> + }
> + if (nla_put(skb, IFLA_BROADCAST, dev->addr_len, dev->broadcast))
> goto nla_put_failure;
> }
>
> diff --git a/security/security.c b/security/security.c
> index 250ee2d76406..35c5929921b2 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -1861,6 +1861,11 @@ int security_setprocattr(const char *lsm, const char *name, void *value,
> return -EINVAL;
> }
>
> +int security_netlink_receive(struct sock *sk, struct sk_buff *skb)
> +{
> + return call_int_hook(netlink_receive, 0, sk, skb);
> +}
> +
> int security_netlink_send(struct sock *sk, struct sk_buff *skb)
> {
> return call_int_hook(netlink_send, 0, sk, skb);
> --
> 2.23.0.rc1.153.gdeed80330f-goog
>
^ permalink raw reply
* [PATCH net-next] net: stmmac: dwmac-anarion: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:55 UTC (permalink / raw)
To: davem, peppe.cavallaro, alexandre.torgue, joabreu, khilman,
mcoquelin.stm32
Cc: linux-kernel, netdev, linux-arm-kernel, linux-amlogic,
linux-stm32, YueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c
index 6ce3a7f..527f933 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c
@@ -62,12 +62,10 @@ static void anarion_gmac_exit(struct platform_device *pdev, void *priv)
static struct anarion_gmac *anarion_config_dt(struct platform_device *pdev)
{
int phy_mode;
- struct resource *res;
void __iomem *ctl_block;
struct anarion_gmac *gmac;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- ctl_block = devm_ioremap_resource(&pdev->dev, res);
+ ctl_block = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(ctl_block)) {
dev_err(&pdev->dev, "Cannot get reset region (%ld)!\n",
PTR_ERR(ctl_block));
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] net: stmmac: dwc-qos: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:57 UTC (permalink / raw)
To: davem, peppe.cavallaro, alexandre.torgue, joabreu, khilman,
mcoquelin.stm32
Cc: linux-kernel, netdev, linux-arm-kernel, linux-amlogic,
linux-stm32, YueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index f2197b0..dd9967a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -418,7 +418,6 @@ static int dwc_eth_dwmac_probe(struct platform_device *pdev)
const struct dwc_eth_dwmac_data *data;
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
- struct resource *res;
void *priv;
int ret;
@@ -435,8 +434,7 @@ static int dwc_eth_dwmac_probe(struct platform_device *pdev)
return stmmac_res.irq;
stmmac_res.wol_irq = stmmac_res.irq;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- stmmac_res.addr = devm_ioremap_resource(&pdev->dev, res);
+ stmmac_res.addr = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(stmmac_res.addr))
return PTR_ERR(stmmac_res.addr);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH rdma-next 0/3] RDMA RX RoCE Steering Support
From: Leon Romanovsky @ 2019-08-21 14:02 UTC (permalink / raw)
To: Doug Ledford
Cc: Jason Gunthorpe, RDMA mailing list, Mark Bloch, Mark Zhang,
Saeed Mahameed, linux-netdev
In-Reply-To: <6e099d052f1803e74b5731fe3da2d9109533734d.camel@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
On Tue, Aug 20, 2019 at 01:54:59PM -0400, Doug Ledford wrote:
> On Mon, 2019-08-19 at 14:36 +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Hi,
> >
> > This series from Mark extends mlx5 with RDMA_RX RoCE flow steering
> > support
> > for DEVX and QP objects.
> >
> > Thanks
> >
> > Mark Zhang (3):
> > net/mlx5: Add per-namespace flow table default miss action support
> > net/mlx5: Create bypass and loopback flow steering namespaces for
> > RDMA
> > RX
> > RDMA/mlx5: RDMA_RX flow type support for user applications
>
> I have no objection to this series.
Thanks, first two patches were applied to mlx5-next
e6806e9a63a7 net/mlx5: Create bypass and loopback flow steering namespaces for RDMA RX
f66ad830b114 net/mlx5: Add per-namespace flow table default miss action support
>
> --
> Doug Ledford <dledford@redhat.com>
> GPG KeyID: B826A3330E572FDD
> Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: dwmac-meson: use devm_platform_ioremap_resource() to simplify code
From: Neil Armstrong @ 2019-08-21 14:02 UTC (permalink / raw)
To: YueHaibing, davem, peppe.cavallaro, alexandre.torgue, joabreu,
khilman, mcoquelin.stm32
Cc: netdev, linux-kernel, linux-amlogic, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190821135406.26200-1-yuehaibing@huawei.com>
On 21/08/2019 15:54, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
> index 88eb169..bbc16b5 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
> @@ -46,7 +46,6 @@ static int meson6_dwmac_probe(struct platform_device *pdev)
> struct plat_stmmacenet_data *plat_dat;
> struct stmmac_resources stmmac_res;
> struct meson_dwmac *dwmac;
> - struct resource *res;
> int ret;
>
> ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> @@ -63,8 +62,7 @@ static int meson6_dwmac_probe(struct platform_device *pdev)
> goto err_remove_config_dt;
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - dwmac->reg = devm_ioremap_resource(&pdev->dev, res);
> + dwmac->reg = devm_platform_ioremap_resource(pdev, 1);
> if (IS_ERR(dwmac->reg)) {
> ret = PTR_ERR(dwmac->reg);
> goto err_remove_config_dt;
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: dwmac-meson8b: use devm_platform_ioremap_resource() to simplify code
From: Neil Armstrong @ 2019-08-21 14:03 UTC (permalink / raw)
To: YueHaibing, davem, peppe.cavallaro, alexandre.torgue, joabreu,
khilman, mcoquelin.stm32
Cc: netdev, linux-kernel, linux-amlogic, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190821135130.68636-1-yuehaibing@huawei.com>
On 21/08/2019 15:51, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> index 786ca4a..9cda29e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> @@ -308,7 +308,6 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
> {
> struct plat_stmmacenet_data *plat_dat;
> struct stmmac_resources stmmac_res;
> - struct resource *res;
> struct meson8b_dwmac *dwmac;
> int ret;
>
> @@ -332,8 +331,7 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
> ret = -EINVAL;
> goto err_remove_config_dt;
> }
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - dwmac->regs = devm_ioremap_resource(&pdev->dev, res);
> + dwmac->regs = devm_platform_ioremap_resource(pdev, 1);
> if (IS_ERR(dwmac->regs)) {
> ret = PTR_ERR(dwmac->regs);
> goto err_remove_config_dt;
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver
From: Richard Cochran @ 2019-08-21 14:08 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Mark Brown, Hubert Feurstein, mlichvar, Andrew Lunn,
Florian Fainelli, linux-spi, netdev
In-Reply-To: <20190821043845.GB1332@localhost>
On Tue, Aug 20, 2019 at 09:38:45PM -0700, Richard Cochran wrote:
> Overall, the PTP switch use case is well supported by Linux. The
> synchronization of the management CPU to the PTP, while nice to have,
> is not required to implement a Transparent Clock. Your specific
> application might require it, but honestly, if the management CPU
> needs good synchronization, then you really aught to feed a PPS from
> the switch into a gpio (for example) on the CPU.
Another way to achieve this is to have a second MAC interface on the
management CPU connected to a spare port on the switch. Then time
stamping, PHC, ptp4l, and phc2sys work as expected.
Thanks,
Richard
^ permalink raw reply
* [PATCH] i40e: check __I40E_VF_DISABLE bit in i40e_sync_filters_subtask
From: Stefan Assmann @ 2019-08-21 14:09 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, davem, jeffrey.t.kirsher, lihong.yang, sassmann
While testing VF spawn/destroy the following panic occured.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000029
[...]
Workqueue: i40e i40e_service_task [i40e]
RIP: 0010:i40e_sync_vsi_filters+0x6fd/0xc60 [i40e]
[...]
Call Trace:
? __switch_to_asm+0x35/0x70
? __switch_to_asm+0x41/0x70
? __switch_to_asm+0x35/0x70
? _cond_resched+0x15/0x30
i40e_sync_filters_subtask+0x56/0x70 [i40e]
i40e_service_task+0x382/0x11b0 [i40e]
? __switch_to_asm+0x41/0x70
? __switch_to_asm+0x41/0x70
process_one_work+0x1a7/0x3b0
worker_thread+0x30/0x390
? create_worker+0x1a0/0x1a0
kthread+0x112/0x130
? kthread_bind+0x30/0x30
ret_from_fork+0x35/0x40
Investigation revealed a race where pf->vf[vsi->vf_id].trusted may get
accessed by the watchdog via i40e_sync_filters_subtask() although
i40e_free_vfs() already free'd pf->vf.
To avoid this the call to i40e_sync_vsi_filters() in
i40e_sync_filters_subtask() needs to be guarded by __I40E_VF_DISABLE,
which is also used by i40e_free_vfs().
Note: put the __I40E_VF_DISABLE check after the
__I40E_MACVLAN_SYNC_PENDING check as the latter is more likely to
trigger.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 6d456e579314..f25c7da59b2b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -2587,6 +2587,10 @@ static void i40e_sync_filters_subtask(struct i40e_pf *pf)
return;
if (!test_and_clear_bit(__I40E_MACVLAN_SYNC_PENDING, pf->state))
return;
+ if (test_and_set_bit(__I40E_VF_DISABLE, pf->state)) {
+ set_bit(__I40E_MACVLAN_SYNC_PENDING, pf->state);
+ return;
+ }
for (v = 0; v < pf->num_alloc_vsi; v++) {
if (pf->vsi[v] &&
@@ -2601,6 +2605,7 @@ static void i40e_sync_filters_subtask(struct i40e_pf *pf)
}
}
}
+ clear_bit(__I40E_VF_DISABLE, pf->state);
}
/**
--
2.21.0
^ permalink raw reply related
* Re: [PATCH bpf-next v4] libbpf: add xsk_ring_prod__nb_free() function
From: Magnus Karlsson @ 2019-08-21 14:14 UTC (permalink / raw)
To: Eelco Chaudron
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Andrii Nakryiko
In-Reply-To: <BC1D077F-1601-451D-A396-1C129B185DD3@redhat.com>
On Wed, Aug 21, 2019 at 3:46 PM Eelco Chaudron <echaudro@redhat.com> wrote:
>
>
>
> On 21 Aug 2019, at 15:11, Magnus Karlsson wrote:
>
> > On Wed, Aug 14, 2019 at 3:51 PM Eelco Chaudron <echaudro@redhat.com>
> > wrote:
> >>
> >> When an AF_XDP application received X packets, it does not mean X
> >> frames can be stuffed into the producer ring. To make it easier for
> >> AF_XDP applications this API allows them to check how many frames can
> >> be added into the ring.
> >>
> >> The patch below looks like a name change only, but the xsk_prod__
> >> prefix denotes that this API is exposed to be used by applications.
> >>
> >> Besides, if you set the nb value to the size of the ring, you will
> >> get the exact amount of slots available, at the cost of performance
> >> (you touch shared state for sure). nb is there to limit the
> >> touching of the shared state.
> >>
> >> Also the example xdpsock application has been modified to use this
> >> new API, so it's also able to process flows at a 1pps rate on veth
> >> interfaces.
> >
> > My apologies for the late reply and thank you for working on this. So
> > what kind of performance difference do you see with your modified
> > xdpsock application on a regular NIC for txpush and l2fwd? If there is
> > basically no difference or it is faster, we can go ahead and accept
> > this. But if the difference is large, we might consider to have two
> > versions of txpush and l2fwd as the regular NICs do not need this. Or
> > we optimize your code so that it becomes as fast as the previous
> > version.
>
> For both operation modes, I ran 5 test with and without the changes
> applied using an iexgb connecting to a XENA tester. The throughput
> numbers were within the standard deviation, so no noticeable performance
> gain or drop.
Sounds good, but let me take your patches for a run on something
faster, just to make sure we are CPU bound. Will get back.
/Magnus
> Let me know if this is enough, if not I can rebuild the setup and do
> some more tests.
>
> > /Magnus
> >
> >> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> >> ---
> >>
> >> v3 -> v4
> >> - Cleanedup commit message
> >> - Updated AF_XDP sample application to use this new API
> >>
> >> v2 -> v3
> >> - Removed cache by pass option
> >>
> >> v1 -> v2
> >> - Renamed xsk_ring_prod__free() to xsk_ring_prod__nb_free()
> >> - Add caching so it will only touch global state when needed
> >>
> >> samples/bpf/xdpsock_user.c | 109
> >> ++++++++++++++++++++++++++++---------
> >> tools/lib/bpf/xsk.h | 4 +-
> >> 2 files changed, 86 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
> >> index 93eaaf7239b2..87115e233b54 100644
> >> --- a/samples/bpf/xdpsock_user.c
> >> +++ b/samples/bpf/xdpsock_user.c
> >> @@ -461,9 +461,13 @@ static void kick_tx(struct xsk_socket_info *xsk)
> >>
> >> static inline void complete_tx_l2fwd(struct xsk_socket_info *xsk)
> >> {
> >> - u32 idx_cq = 0, idx_fq = 0;
> >> - unsigned int rcvd;
> >> + static u64 free_frames[NUM_FRAMES];
> >> + static size_t nr_free_frames;
> >> +
> >> + u32 idx_cq = 0, idx_fq = 0, free_slots;
> >> + unsigned int rcvd, i;
> >> size_t ndescs;
> >> + int ret;
> >>
> >> if (!xsk->outstanding_tx)
> >> return;
> >> @@ -474,27 +478,52 @@ static inline void complete_tx_l2fwd(struct
> >> xsk_socket_info *xsk)
> >>
> >> /* re-add completed Tx buffers */
> >> rcvd = xsk_ring_cons__peek(&xsk->umem->cq, ndescs, &idx_cq);
> >> - if (rcvd > 0) {
> >> - unsigned int i;
> >> - int ret;
> >> + if (!rcvd)
> >> + return;
> >>
> >> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd,
> >> &idx_fq);
> >> - while (ret != rcvd) {
> >> - if (ret < 0)
> >> - exit_with_error(-ret);
> >> - ret = xsk_ring_prod__reserve(&xsk->umem->fq,
> >> rcvd,
> >> - &idx_fq);
> >> - }
> >> - for (i = 0; i < rcvd; i++)
> >> + /* When xsk_ring_cons__peek() for example returns that 5
> >> packets
> >> + * have been received, it does not automatically mean that
> >> + * xsk_ring_prod__reserve() will have 5 slots available. You
> >> will
> >> + * see this, for example, when using a veth interface due to
> >> the
> >> + * RX_BATCH_SIZE used by the generic driver.
> >> + *
> >> + * In this example we store unused buffers and try to
> >> re-stock
> >> + * them the next iteration.
> >> + */
> >> +
> >> + free_slots = xsk_prod__nb_free(&xsk->umem->fq, rcvd +
> >> nr_free_frames);
> >> + if (free_slots > rcvd + nr_free_frames)
> >> + free_slots = rcvd + nr_free_frames;
> >> +
> >> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots,
> >> &idx_fq);
> >> + while (ret != free_slots) {
> >> + if (ret < 0)
> >> + exit_with_error(-ret);
> >> + ret = xsk_ring_prod__reserve(&xsk->umem->fq,
> >> free_slots,
> >> + &idx_fq);
> >> + }
> >> + for (i = 0; i < rcvd; i++) {
> >> + u64 addr = *xsk_ring_cons__comp_addr(&xsk->umem->cq,
> >> idx_cq++);
> >> +
> >> + if (i < free_slots)
> >> *xsk_ring_prod__fill_addr(&xsk->umem->fq,
> >> idx_fq++) =
> >> -
> >> *xsk_ring_cons__comp_addr(&xsk->umem->cq,
> >> - idx_cq++);
> >> + addr;
> >> + else
> >> + free_frames[nr_free_frames++] = addr;
> >> + }
> >>
> >> - xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
> >> - xsk_ring_cons__release(&xsk->umem->cq, rcvd);
> >> - xsk->outstanding_tx -= rcvd;
> >> - xsk->tx_npkts += rcvd;
> >> + if (free_slots > rcvd) {
> >> + for (i = 0; i < (free_slots - rcvd); i++) {
> >> + u64 addr = free_frames[--nr_free_frames];
> >> + *xsk_ring_prod__fill_addr(&xsk->umem->fq,
> >> idx_fq++) =
> >> + addr;
> >> + }
> >> }
> >> +
> >> + xsk_ring_prod__submit(&xsk->umem->fq, free_slots);
> >> + xsk_ring_cons__release(&xsk->umem->cq, rcvd);
> >> + xsk->outstanding_tx -= rcvd;
> >> + xsk->tx_npkts += rcvd;
> >> }
> >>
> >> static inline void complete_tx_only(struct xsk_socket_info *xsk)
> >> @@ -517,19 +546,37 @@ static inline void complete_tx_only(struct
> >> xsk_socket_info *xsk)
> >>
> >> static void rx_drop(struct xsk_socket_info *xsk)
> >> {
> >> + static u64 free_frames[NUM_FRAMES];
> >> + static size_t nr_free_frames;
> >> +
> >> unsigned int rcvd, i;
> >> - u32 idx_rx = 0, idx_fq = 0;
> >> + u32 idx_rx = 0, idx_fq = 0, free_slots;
> >> int ret;
> >>
> >> rcvd = xsk_ring_cons__peek(&xsk->rx, BATCH_SIZE, &idx_rx);
> >> if (!rcvd)
> >> return;
> >>
> >> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
> >> - while (ret != rcvd) {
> >> + /* When xsk_ring_cons__peek() for example returns that 5
> >> packets
> >> + * have been received, it does not automatically mean that
> >> + * xsk_ring_prod__reserve() will have 5 slots available. You
> >> will
> >> + * see this, for example, when using a veth interface due to
> >> the
> >> + * RX_BATCH_SIZE used by the generic driver.
> >> + *
> >> + * In this example we store unused buffers and try to
> >> re-stock
> >> + * them the next iteration.
> >> + */
> >> +
> >> + free_slots = xsk_prod__nb_free(&xsk->umem->fq, rcvd +
> >> nr_free_frames);
> >> + if (free_slots > rcvd + nr_free_frames)
> >> + free_slots = rcvd + nr_free_frames;
> >> +
> >> + ret = xsk_ring_prod__reserve(&xsk->umem->fq, free_slots,
> >> &idx_fq);
> >> + while (ret != free_slots) {
> >> if (ret < 0)
> >> exit_with_error(-ret);
> >> - ret = xsk_ring_prod__reserve(&xsk->umem->fq, rcvd,
> >> &idx_fq);
> >> + ret = xsk_ring_prod__reserve(&xsk->umem->fq,
> >> free_slots,
> >> + &idx_fq);
> >> }
> >>
> >> for (i = 0; i < rcvd; i++) {
> >> @@ -538,10 +585,22 @@ static void rx_drop(struct xsk_socket_info
> >> *xsk)
> >> char *pkt = xsk_umem__get_data(xsk->umem->buffer,
> >> addr);
> >>
> >> hex_dump(pkt, len, addr);
> >> - *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) =
> >> addr;
> >> + if (i < free_slots)
> >> + *xsk_ring_prod__fill_addr(&xsk->umem->fq,
> >> idx_fq++) =
> >> + addr;
> >> + else
> >> + free_frames[nr_free_frames++] = addr;
> >> + }
> >> +
> >> + if (free_slots > rcvd) {
> >> + for (i = 0; i < (free_slots - rcvd); i++) {
> >> + u64 addr = free_frames[--nr_free_frames];
> >> + *xsk_ring_prod__fill_addr(&xsk->umem->fq,
> >> idx_fq++) =
> >> + addr;
> >> + }
> >> }
> >>
> >> - xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
> >> + xsk_ring_prod__submit(&xsk->umem->fq, free_slots);
> >> xsk_ring_cons__release(&xsk->rx, rcvd);
> >> xsk->rx_npkts += rcvd;
> >> }
> >> diff --git a/tools/lib/bpf/xsk.h b/tools/lib/bpf/xsk.h
> >> index 833a6e60d065..cae506ab3f3c 100644
> >> --- a/tools/lib/bpf/xsk.h
> >> +++ b/tools/lib/bpf/xsk.h
> >> @@ -76,7 +76,7 @@ xsk_ring_cons__rx_desc(const struct xsk_ring_cons
> >> *rx, __u32 idx)
> >> return &descs[idx & rx->mask];
> >> }
> >>
> >> -static inline __u32 xsk_prod_nb_free(struct xsk_ring_prod *r, __u32
> >> nb)
> >> +static inline __u32 xsk_prod__nb_free(struct xsk_ring_prod *r, __u32
> >> nb)
> >> {
> >> __u32 free_entries = r->cached_cons - r->cached_prod;
> >>
> >> @@ -110,7 +110,7 @@ static inline __u32 xsk_cons_nb_avail(struct
> >> xsk_ring_cons *r, __u32 nb)
> >> static inline size_t xsk_ring_prod__reserve(struct xsk_ring_prod
> >> *prod,
> >> size_t nb, __u32 *idx)
> >> {
> >> - if (xsk_prod_nb_free(prod, nb) < nb)
> >> + if (xsk_prod__nb_free(prod, nb) < nb)
> >> return 0;
> >>
> >> *idx = prod->cached_prod;
> >> --
> >> 2.18.1
> >>
^ permalink raw reply
* Re: [PATCH 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: Leonardo Bras @ 2019-08-21 14:14 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Florian Westphal, netfilter-devel, coreteam, netdev, linux-kernel,
Jozsef Kadlecsik, David S. Miller
In-Reply-To: <20190821095844.me6kscvnfruinseu@salvia>
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]
On Wed, 2019-08-21 at 11:58 +0200, Pablo Neira Ayuso wrote:
> On Tue, Aug 20, 2019 at 01:15:58PM -0300, Leonardo Bras wrote:
> > On Tue, 2019-08-20 at 07:36 +0200, Florian Westphal wrote:
> > > Wouldn't fib_netdev.c have the same problem?
> > Probably, but I haven't hit this issue yet.
> >
> > > If so, might be better to place this test in both
> > > nft_fib6_eval_type and nft_fib6_eval.
> >
> > I think that is possible, and not very hard to do.
> >
> > But in my humble viewpoint, it looks like it's nft_fib_inet_eval() and
> > nft_fib_netdev_eval() have the responsibility to choose a valid
> > protocol or drop the package.
> > I am not sure if it would be a good move to transfer this
> > responsibility to nft_fib6_eval_type() and nft_fib6_eval(), so I would
> > rather add the same test to nft_fib_netdev_eval().
> >
> > Does it make sense?
>
> Please, update common code to netdev and ip6 extensions as Florian
> suggests.
>
> Thanks.
Ok then, I will send a v2 with that change.
Thanks,
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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