* [PATCH net-next 1/2] selftests/txtimestamp: Add more configurable parameters
From: Vinicius Costa Gomes @ 2018-03-13 20:35 UTC (permalink / raw)
To: netdev; +Cc: Vinicius Costa Gomes, randy.e.witt, davem, eric.dumazet
In-Reply-To: <20180313203519.8638-1-vinicius.gomes@intel.com>
Add a way to configure if poll() should wait forever for an event, the
number of packets that should be sent for each and if there should be
any delay between packets.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
---
.../selftests/networking/timestamping/txtimestamp.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/networking/timestamping/txtimestamp.c b/tools/testing/selftests/networking/timestamping/txtimestamp.c
index 5df07047ca86..5190b1dd78b1 100644
--- a/tools/testing/selftests/networking/timestamping/txtimestamp.c
+++ b/tools/testing/selftests/networking/timestamping/txtimestamp.c
@@ -68,9 +68,11 @@ static int cfg_num_pkts = 4;
static int do_ipv4 = 1;
static int do_ipv6 = 1;
static int cfg_payload_len = 10;
+static int cfg_poll_timeout = 100;
static bool cfg_show_payload;
static bool cfg_do_pktinfo;
static bool cfg_loop_nodata;
+static bool cfg_no_delay;
static uint16_t dest_port = 9000;
static struct sockaddr_in daddr;
@@ -171,7 +173,7 @@ static void __poll(int fd)
memset(&pollfd, 0, sizeof(pollfd));
pollfd.fd = fd;
- ret = poll(&pollfd, 1, 100);
+ ret = poll(&pollfd, 1, cfg_poll_timeout);
if (ret != 1)
error(1, errno, "poll");
}
@@ -371,7 +373,8 @@ static void do_test(int family, unsigned int opt)
error(1, errno, "send");
/* wait for all errors to be queued, else ACKs arrive OOO */
- usleep(50 * 1000);
+ if (!cfg_no_delay)
+ usleep(50 * 1000);
__poll(fd);
@@ -397,6 +400,9 @@ static void __attribute__((noreturn)) usage(const char *filepath)
" -n: set no-payload option\n"
" -r: use raw\n"
" -R: use raw (IP_HDRINCL)\n"
+ " -D: no delay between packets\n"
+ " -F: poll() waits forever for an event\n"
+ " -c N: number of packets for each test\n"
" -p N: connect to port N\n"
" -u: use udp\n"
" -x: show payload (up to 70 bytes)\n",
@@ -409,7 +415,7 @@ static void parse_opt(int argc, char **argv)
int proto_count = 0;
char c;
- while ((c = getopt(argc, argv, "46hIl:np:rRux")) != -1) {
+ while ((c = getopt(argc, argv, "46hIl:np:rRuxc:DF")) != -1) {
switch (c) {
case '4':
do_ipv6 = 0;
@@ -447,6 +453,15 @@ static void parse_opt(int argc, char **argv)
case 'x':
cfg_show_payload = true;
break;
+ case 'c':
+ cfg_num_pkts = strtoul(optarg, NULL, 10);
+ break;
+ case 'D':
+ cfg_no_delay = true;
+ break;
+ case 'F':
+ cfg_poll_timeout = -1;
+ break;
case 'h':
default:
usage(argv[0]);
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 0/2] skbuff: Fix applications not being woken for errors
From: Vinicius Costa Gomes @ 2018-03-13 20:35 UTC (permalink / raw)
To: netdev; +Cc: Vinicius Costa Gomes, randy.e.witt, davem, eric.dumazet
Hi,
Changes from the RFC:
- tweaked commit messages;
Original cover letter:
This is actually a "bug report"-RFC instead of the more usual "new
feature"-RFC.
We are developing an application that uses TX hardware timestamping to
make some measurements, and during development Randy Witt initially
reported that the application poll() never unblocked when TX hardware
timestamping was enabled.
After some investigation, it turned out the problem wasn't only
exclusive to hardware timestamping, and could be reproduced with
software timestamping.
Applying patch (1), and running txtimestamp like this, for example:
$ ./txtimestamp -u -4 192.168.1.71 -c 1000 -D -l 1000 -F
('-u' to use UDP only, '-4' for ipv4 only, '-c 1000' to send 1000
packets for each test, '-D' to remove the delay between packets, '-l
1000' to set the payload to 1000 bytes, '-F' for configuring poll() to
wait forever)
will cause the application to become stuck in the poll() call in most
of the times. (Note: I couldn't reproduce the issue running against an
address that is routed through loopback.)
Another interesting fact is that if the POLLIN event is added to the
poll() .events, poll() no longer becomes stuck, and more interestingly
the returned event in .revents is only POLLERR.
After a few debugging sessions, we got to 'sock_queue_err_skb()' and
how it notifies applications of the error just enqueued. Changing it
to use 'sk->sk_error_report()', fixes the issue for hardware and
software timestamping. That is patch (2).
The "solution" proposed in patch (2) looks like too big a hammer, if
it's not, then it seems that this problem existed since a long time
ago (pre git) and was uncommon for folks to reach the necessary
conditions to trigger it (my hypothesis is that only triggers when the
error is reported from a different task context than the application).
Am I missing something here?
Cheers,
--
Vinicius Costa Gomes (2):
selftests/txtimestamp: Add more configurable parameters
skbuff: Fix not waking applications when errors are enqueued
net/core/skbuff.c | 2 +-
.../selftests/networking/timestamping/txtimestamp.c | 21 ++++++++++++++++++---
2 files changed, 19 insertions(+), 4 deletions(-)
--
2.16.2
^ permalink raw reply
* [PATCH net-next 2/2] skbuff: Fix not waking applications when errors are enqueued
From: Vinicius Costa Gomes @ 2018-03-13 20:35 UTC (permalink / raw)
To: netdev; +Cc: Vinicius Costa Gomes, randy.e.witt, davem, eric.dumazet
In-Reply-To: <20180313203519.8638-1-vinicius.gomes@intel.com>
When errors are enqueued to the error queue via sock_queue_err_skb()
function, it is possible that the waiting application is not notified.
Calling 'sk->sk_data_ready()' would not notify applications that
selected only POLLERR events in poll() (for example).
Reported-by: Randy E. Witt <randy.e.witt@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 715c13495ba6..6def3534f509 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4181,7 +4181,7 @@ int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
skb_queue_tail(&sk->sk_error_queue, skb);
if (!sock_flag(sk, SOCK_DEAD))
- sk->sk_data_ready(sk);
+ sk->sk_error_report(sk);
return 0;
}
EXPORT_SYMBOL(sock_queue_err_skb);
--
2.16.2
^ permalink raw reply related
* Re: linux-next: build warning after merge of the net-next tree
From: Gustavo A. R. Silva @ 2018-03-13 20:28 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20180313.113313.629581257230548483.davem@davemloft.net>
On 03/13/2018 10:33 AM, David Miller wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
> Date: Tue, 13 Mar 2018 06:46:24 -0500
>
>> Hi Stephen,
>>
>> On 03/13/2018 01:11 AM, Stephen Rothwell wrote:
>>> Hi all,
>>> After merging the net-next tree, today's linux-next build (sparc
>>> defconfig) produced this warning:
>>> net/core/pktgen.c: In function 'pktgen_if_write':
>>> net/core/pktgen.c:1710:1: warning: the frame size of 1048 bytes is
>>> larger than 1024 bytes [-Wframe-larger-than=]
>>> }
>>> ^
>>> Introduced by commit
>>> 35951393bbff ("pktgen: Remove VLA usage")
>>>
>>
>> Thanks for the report.
>>
>> David:
>>
>> If this code is not going to be executed very often [1], then I think
>> it is safe to use dynamic memory allocation instead, as this is not
>> going to impact the performance.
>>
>> What do you think?
>>
>> [1] https://lkml.org/lkml/2018/3/9/630
>
> Sure, that works.
>
> It is only invoked when pktgen configuration changes are made.
>
OK. I'll send a new patch for this.
Thanks
--
Gustavo
^ permalink raw reply
* [PATCH iproute2] treat "default" and "all"/"any" parameters differenty
From: Alexander Zubkov @ 2018-03-13 20:19 UTC (permalink / raw)
To: Luca Boccassi, Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <1520942521.12414.1.camel@debian.org>
Debian maintainer found that basic command:
# ip route flush all
No longer worked as expected which breaks user scripts and
expectations. It no longer flushed all IPv4 routes.
Recently behaviour of "default" prefix parameter was corrected. But at
the same time behaviour of "all"/"any" was altered too, because they
were the same branch of the code. As those parameters mean different,
they need to be treated differently in code too. This patch reflects
the difference.
Reported-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Alexander Zubkov <green@msu.ru>
---
lib/utils.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/utils.c b/lib/utils.c
index 9fa5220..b289d9c 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -658,7 +658,8 @@ int get_prefix_1(inet_prefix *dst, char *arg, int
family)
dst->family = family;
dst->bytelen = 0;
dst->bitlen = 0;
- dst->flags |= PREFIXLEN_SPECIFIED;
+ if (strcmp(arg, "default") == 0)
+ dst->flags |= PREFIXLEN_SPECIFIED;
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH iproute2] Revert "iproute: "list/flush/save default" selected all of the routes"
From: Alexander Zubkov @ 2018-03-13 20:12 UTC (permalink / raw)
To: Luca Boccassi, Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <1520942521.12414.1.camel@debian.org>
Hi,
I just realized that you need patch for v4.15.0, which is easier to do.
I'll send it as separate message now. I will make patch for the master
branch, but later.
On 13.03.2018 13:02, Luca Boccassi wrote:
> On Tue, 2018-03-13 at 12:05 +0100, Alexander Zubkov wrote:
>> Hello again,
>>
>> The fun thing is that before the commit "ip route ls all" showed all
>> routes, but "ip -[4|6] route ls all" showed only default. So it was
>> broken too, but in other way.
>> I see parsing of prefix was changed since my patch. So I need several
>> days to propose fix. I think if "ip route ls [all|any]" shows all
>> routes and "ip route ls default" shows only default, everybody will
>> be happy with that?
>
> Hi,
>
> My only concern is that behaviour of existing commands that have been
> in releases is not changed, otherwise I get bugs raised :-)
>
> Thank you for your work!
>
>> 13.03.2018, 09:46, "Alexander Zubkov" <green@msu.ru>:
>>> Hello.
>>>
>>> May be the better way would be to change how "all"/"any" argument
>>> behaves? My original concern was about "default" only. I agree too,
>>> that "all" or "any" should work for all routes. But not for the
>>> default.
>>>
>>> 12.03.2018, 22:37, "Luca Boccassi" <bluca@debian.org>:
>>>> On Mon, 2018-03-12 at 14:03 -0700, Stephen Hemminger wrote:
>>>>> This reverts commit 9135c4d6037ff9f1818507bac0049fc44db8c3d2.
>>>>>
>>>>> Debian maintainer found that basic command:
>>>>> # ip route flush all
>>>>> No longer worked as expected which breaks user scripts and
>>>>> expectations. It no longer flushed all IPv4 routes.
>>>>>
>>>>> Reported-by: Luca Boccassi <bluca@debian.org>
>>>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>>>> ---
>>>>> ip/iproute.c | 65 ++++++++++++++++++----------------------
>>>>> --------
>>>>> ------------
>>>>> lib/utils.c | 13 ++++++++++++
>>>>> 2 files changed, 32 insertions(+), 46 deletions(-)
>>>>
>>>> Tested-by: Luca Boccassi <bluca@debian.org>
>>>>
>>>> Thanks, solves the problem. I'll backport it to Debian.
>>>>
>>>> Alexander, reproducing the issue is quite simple - before that
>>>> commit,
>>>> ip route ls all showed all routes, but with the change it
>>>> started
>>>> showing only the default table. Same for ip route flush.
>>>>
>>>> --
>>>> Kind regards,
>>>> Luca Boccassi
>
^ permalink raw reply
* Re: [RESEND] rsi: Remove stack VLA usage
From: tcharding @ 2018-03-13 20:17 UTC (permalink / raw)
To: Kalle Valo
Cc: kernel-hardening, linux-kernel, netdev, linux-wireless,
Tycho Andersen, Kees Cook
In-Reply-To: <20180312094606.8192B6081A@smtp.codeaurora.org>
On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote:
> tcharding <me@tobin.cc> wrote:
>
> > The kernel would like to have all stack VLA usage removed[1]. rsi uses
> > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size
> > is defined using a magic number. We can use a pre-processor defined
> > constant and declare the array to maximum size. We add a check before
> > accessing the array in case of programmer error.
> >
> > [1]: https://lkml.org/lkml/2018/3/7/621
> >
> > Signed-off-by: Tobin C. Harding <me@tobin.cc>
>
> Tobin, your name in patchwork.kernel.org is just "tcharding" then it should be
> "Tobin C. Harding". Patchwork is braindead in a way as it takes the name from
> it's database instead of the From header of the patch in question.
>
> I can fix that manually but it would be helpful if you could register to
> patchwork and fix your name during registration. You have only one chance to
> fix your name (another braindead feature!) so be careful :)
Hi Kalle,
I logged into my patchwork account but I don't see any way to set the
name. Within 'profile' there is only 'change password' and 'link
email'. I thought I could unregister then re-register but I can't see
how to do that either. Is there a maintainer of patchwork.kernel.org
who I can email to manually remove me from the system?
thanks,
Tobin.
^ permalink raw reply
* Re: [PATCH iproute2] Revert "iproute: "list/flush/save default" selected all of the routes"
From: Luca Boccassi @ 2018-03-13 20:15 UTC (permalink / raw)
To: Alexander Zubkov, Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <3ebb9805-fb69-c67d-6222-c6d1d344f4ec@msu.ru>
[-- Attachment #1: Type: text/plain, Size: 3179 bytes --]
On Tue, 2018-03-13 at 21:12 +0100, Alexander Zubkov wrote:
> Hi,
>
> I just realized that you need patch for v4.15.0, which is easier to
> do.
> I'll send it as separate message now. I will make patch for the
> master
> branch, but later.
Thanks but don't worry about 4.15 - Stephen's revert will be enough for
now. I'm going to push 4.16 as soon as it's out anyway, so you can just
do the changes for master if you wish.
> On 13.03.2018 13:02, Luca Boccassi wrote:
> > On Tue, 2018-03-13 at 12:05 +0100, Alexander Zubkov wrote:
> > > Hello again,
> > >
> > > The fun thing is that before the commit "ip route ls all" showed
> > > all
> > > routes, but "ip -[4|6] route ls all" showed only default. So it
> > > was
> > > broken too, but in other way.
> > > I see parsing of prefix was changed since my patch. So I need
> > > several
> > > days to propose fix. I think if "ip route ls [all|any]" shows all
> > > routes and "ip route ls default" shows only default, everybody
> > > will
> > > be happy with that?
> >
> > Hi,
> >
> > My only concern is that behaviour of existing commands that have
> > been
> > in releases is not changed, otherwise I get bugs raised :-)
> >
> > Thank you for your work!
> >
> > > 13.03.2018, 09:46, "Alexander Zubkov" <green@msu.ru>:
> > > > Hello.
> > > >
> > > > May be the better way would be to change how "all"/"any"
> > > > argument
> > > > behaves? My original concern was about "default" only. I agree
> > > > too,
> > > > that "all" or "any" should work for all routes. But not for the
> > > > default.
> > > >
> > > > 12.03.2018, 22:37, "Luca Boccassi" <bluca@debian.org>:
> > > > > On Mon, 2018-03-12 at 14:03 -0700, Stephen Hemminger wrote:
> > > > > > This reverts commit
> > > > > > 9135c4d6037ff9f1818507bac0049fc44db8c3d2.
> > > > > >
> > > > > > Debian maintainer found that basic command:
> > > > > > # ip route flush all
> > > > > > No longer worked as expected which breaks user scripts
> > > > > > and
> > > > > > expectations. It no longer flushed all IPv4 routes.
> > > > > >
> > > > > > Reported-by: Luca Boccassi <bluca@debian.org>
> > > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber
> > > > > > .org>
> > > > > > ---
> > > > > > ip/iproute.c | 65 ++++++++++++++++++-------------------
> > > > > > ---
> > > > > > --------
> > > > > > ------------
> > > > > > lib/utils.c | 13 ++++++++++++
> > > > > > 2 files changed, 32 insertions(+), 46 deletions(-)
> > > > >
> > > > > Tested-by: Luca Boccassi <bluca@debian.org>
> > > > >
> > > > > Thanks, solves the problem. I'll backport it to Debian.
> > > > >
> > > > > Alexander, reproducing the issue is quite simple - before
> > > > > that
> > > > > commit,
> > > > > ip route ls all showed all routes, but with the change it
> > > > > started
> > > > > showing only the default table. Same for ip route flush.
> > > > >
> > > > > --
> > > > > Kind regards,
> > > > > Luca Boccassi
>
>
--
Kind regards,
Luca Boccassi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RESEND PATCH] rsi: Remove stack VLA usage
From: Tobin C. Harding @ 2018-03-13 20:09 UTC (permalink / raw)
To: Larry Finger
Cc: Kalle Valo, kernel-hardening, linux-kernel, netdev,
linux-wireless, Tycho Andersen, Kees Cook
In-Reply-To: <ff9309bf-4c3d-b0f9-cdd0-429dacd3177b@lwfinger.net>
On Sun, Mar 11, 2018 at 09:06:10PM -0500, Larry Finger wrote:
> On 03/11/2018 08:43 PM, Tobin C. Harding wrote:
> >The kernel would like to have all stack VLA usage removed[1]. rsi uses
> >a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size
> >is defined using a magic number. We can use a pre-processor defined
> >constant and declare the array to maximum size. We add a check before
> >accessing the array in case of programmer error.
> >
> >[1]: https://lkml.org/lkml/2018/3/7/621
> >
> >Signed-off-by: Tobin C. Harding <me@tobin.cc>
> >---
> >
> >RESEND: add wireless mailing list to CC's (requested by Kalle)
> >
> > drivers/net/wireless/rsi/rsi_91x_hal.c | 13 +++++++------
> > drivers/net/wireless/rsi/rsi_91x_sdio.c | 9 +++++++--
> > 2 files changed, 14 insertions(+), 8 deletions(-)
> >
> >diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c b/drivers/net/wireless/rsi/rsi_91x_hal.c
> >index 1176de646942..839ebdd602df 100644
> >--- a/drivers/net/wireless/rsi/rsi_91x_hal.c
> >+++ b/drivers/net/wireless/rsi/rsi_91x_hal.c
> >@@ -641,7 +641,7 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 cmd, u8 *addr, u32 size)
> > u32 cmd_addr;
> > u16 cmd_resp, cmd_req;
> > u8 *str;
> >- int status;
> >+ int status, ret;
> > if (cmd == PING_WRITE) {
> > cmd_addr = PING_BUFFER_ADDRESS;
> >@@ -655,12 +655,13 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 cmd, u8 *addr, u32 size)
> > str = "PONG_VALID";
> > }
> >- status = hif_ops->load_data_master_write(adapter, cmd_addr, size,
> >+ ret = hif_ops->load_data_master_write(adapter, cmd_addr, size,
> > block_size, addr);
> >- if (status) {
> >- rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr %0x\n",
> >- __func__, *addr);
> >- return status;
> >+ if (ret) {
> >+ if (ret != -EINVAL)
> >+ rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr %0x\n",
> >+ __func__, *addr);
> >+ return ret;
> > }
> > status = bl_cmd(adapter, cmd_req, cmd_resp, str);
> >diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> >index b0cf41195051..b766578b591a 100644
> >--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
> >+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> >@@ -20,6 +20,8 @@
> > #include "rsi_common.h"
> > #include "rsi_hal.h"
> >+#define RSI_MAX_BLOCK_SIZE 256
> >+
> > /**
> > * rsi_sdio_set_cmd52_arg() - This function prepares cmd 52 read/write arg.
> > * @rw: Read/write
> >@@ -362,7 +364,7 @@ static int rsi_setblocklength(struct rsi_hw *adapter, u32 length)
> > rsi_dbg(INIT_ZONE, "%s: Setting the block length\n", __func__);
> > status = sdio_set_block_size(dev->pfunction, length);
> >- dev->pfunction->max_blksize = 256;
> >+ dev->pfunction->max_blksize = RSI_MAX_BLOCK_SIZE;
> > adapter->block_size = dev->pfunction->max_blksize;
> > rsi_dbg(INFO_ZONE,
> >@@ -567,9 +569,12 @@ static int rsi_sdio_load_data_master_write(struct rsi_hw *adapter,
> > {
> > u32 num_blocks, offset, i;
> > u16 msb_address, lsb_address;
> >- u8 temp_buf[block_size];
> >+ u8 temp_buf[RSI_MAX_BLOCK_SIZE];
> > int status;
> >+ if (block_size > RSI_MAX_BLOCK_SIZE)
> >+ return -EINVAL;
> >+
> > num_blocks = instructions_sz / block_size;
> > msb_address = base_address >> 16;
>
> I am not giving this patch a negative review, but my solution to the same
> problem has been to change the on-stack array into a u8 pointer, use
> kmalloc() to assign the space, and then free that space at the end. That way
> large stack allocations are avoided, with a minimum of changes.
Your idea is better Larry, have you got a patch done already or do you
want me to knock one up?
thanks,
Tobin.
^ permalink raw reply
* Re: [PATCH] net: dsa: drop some VLAs in switch.c
From: Florian Fainelli @ 2018-03-13 20:06 UTC (permalink / raw)
To: Vivien Didelot, Salvatore Mesoraca, linux-kernel
Cc: kernel-hardening, netdev, David S. Miller, Andrew Lunn, Kees Cook
In-Reply-To: <87fu5321du.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On 03/13/2018 12:58 PM, Vivien Didelot wrote:
> Hi Salvatore,
>
> Salvatore Mesoraca <s.mesoraca16@gmail.com> writes:
>
>> dsa_switch's num_ports is currently fixed to DSA_MAX_PORTS. So we avoid
>> 2 VLAs[1] by using DSA_MAX_PORTS instead of ds->num_ports.
>>
>> [1] https://lkml.org/lkml/2018/3/7/621
>>
>> Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
>
> NAK.
>
> We are in the process to remove hardcoded limits such as DSA_MAX_PORTS
> and DSA_MAX_SWITCHES, so we have to stick with ds->num_ports.
Then this means that we need to allocate a bitmap from the heap, which
sounds a bit superfluous and could theoretically fail... not sure which
way is better, but bumping the size to DSA_MAX_PORTS definitively does
help people working on enabling -Wvla.
--
Florian
^ permalink raw reply
* Re: [PATCH] net: dsa: drop some VLAs in switch.c
From: Vivien Didelot @ 2018-03-13 19:58 UTC (permalink / raw)
To: Salvatore Mesoraca, linux-kernel
Cc: kernel-hardening, netdev, David S. Miller, Andrew Lunn,
Florian Fainelli, Kees Cook, Salvatore Mesoraca
In-Reply-To: <1520970647-19587-1-git-send-email-s.mesoraca16@gmail.com>
Hi Salvatore,
Salvatore Mesoraca <s.mesoraca16@gmail.com> writes:
> dsa_switch's num_ports is currently fixed to DSA_MAX_PORTS. So we avoid
> 2 VLAs[1] by using DSA_MAX_PORTS instead of ds->num_ports.
>
> [1] https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
NAK.
We are in the process to remove hardcoded limits such as DSA_MAX_PORTS
and DSA_MAX_SWITCHES, so we have to stick with ds->num_ports.
Thanks,
Vivien
^ permalink raw reply
* Re: [pull request][for-next 00/11] Mellanox, mlx5 IPSec updates 2018-02-28-2 (Part 2)
From: Doug Ledford @ 2018-03-13 19:52 UTC (permalink / raw)
To: Saeed Mahameed, davem@davemloft.net
Cc: Jason Gunthorpe, netdev@vger.kernel.org, Matan Barak,
linux-rdma@vger.kernel.org, Leon Romanovsky, Aviad Yehezkel,
Boris Pismenny
In-Reply-To: <1520905422.18703.0.camel@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]
On Mon, 2018-03-12 at 21:43 -0400, Doug Ledford wrote:
> On Mon, 2018-03-12 at 21:43 +0000, Saeed Mahameed wrote:
> > On Thu, 2018-03-08 at 14:14 -0500, Doug Ledford wrote:
> > > On 3/8/2018 1:04 PM, David Miller wrote:
> > > > From: Saeed Mahameed <saeedm@mellanox.com>
> > > > Date: Wed, 7 Mar 2018 17:26:03 -0800
> > > >
> > > > > Hi Dave and Doug,
> > > > >
> > > > > This series includes shared code updates (IPSec part2) for mlx5
> > > > > core
> > > > > driver for both netdev and rdma subsystems. This series should
> > > > > be pulled
> > > > > to both trees so we can continue netdev and rdma specific
> > > > > submissions
> > > > > separately.
> > > >
> > > > Doug, please give this series a quick review.
> > > >
> > > > Thank you.
> > > >
> > >
> > > I'm good with it. Pull it as you see fit.
> > >
> >
> > Hi Doug,
> >
> > Just FYI, I see that Dave already pulled the series into net-next.
> > I think you can pull as well, so Leon will start the mlx5 RDMA
> > submissions as planned on top this last pull request.
> >
> > thanks,
> > Saeed.
>
> Ok, thanks Saeed.
>
Pulled and a new wip/dl-for-next is available.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] net: dsa: drop some VLAs in switch.c
From: Salvatore Mesoraca @ 2018-03-13 19:50 UTC (permalink / raw)
To: linux-kernel
Cc: kernel-hardening, netdev, David S. Miller, Andrew Lunn,
Florian Fainelli, Kees Cook, Salvatore Mesoraca, Vivien Didelot
dsa_switch's num_ports is currently fixed to DSA_MAX_PORTS. So we avoid
2 VLAs[1] by using DSA_MAX_PORTS instead of ds->num_ports.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
---
net/dsa/switch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index b935117..78e9897 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -136,7 +136,7 @@ static int dsa_switch_mdb_add(struct dsa_switch *ds,
{
const struct switchdev_obj_port_mdb *mdb = info->mdb;
struct switchdev_trans *trans = info->trans;
- DECLARE_BITMAP(group, ds->num_ports);
+ DECLARE_BITMAP(group, DSA_MAX_PORTS);
int port;
/* Build a mask of Multicast group members */
@@ -204,7 +204,7 @@ static int dsa_switch_vlan_add(struct dsa_switch *ds,
{
const struct switchdev_obj_port_vlan *vlan = info->vlan;
struct switchdev_trans *trans = info->trans;
- DECLARE_BITMAP(members, ds->num_ports);
+ DECLARE_BITMAP(members, DSA_MAX_PORTS);
int port;
/* Build a mask of VLAN members */
--
1.9.1
^ permalink raw reply related
* RE: [PATCH v2 iproute2-next 3/6] rdma: Add CM_ID resource tracking information
From: Steve Wise @ 2018-03-13 19:44 UTC (permalink / raw)
To: 'Leon Romanovsky'; +Cc: dsahern, stephen, netdev, linux-rdma
In-Reply-To: <20180313180736.GJ1080@mtr-leonro.local>
> On Tue, Feb 27, 2018 at 08:07:05AM -0800, Steve Wise wrote:
> > Sample output:
> >
> > # rdma resource
> > 2: cxgb4_0: pd 5 cq 2 qp 2 cm_id 3 mr 7
> > 3: mlx4_0: pd 7 cq 3 qp 3 cm_id 3 mr 7
> >
> > # rdma resource show cm_id
> > link cxgb4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm
> rping src-addr 0.0.0.0:7174
> > link cxgb4_0/2 lqpn 1048 qp-type RC state CONNECT ps TCP pid 30503
> comm rping src-addr 172.16.2.1:7174 dst-addr 172.16.2.1:38246
> > link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498
> comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174
> > link mlx4_0/- lqpn 0 qp-type RC state LISTEN ps TCP pid 30485 comm rping
> src-addr 0.0.0.0:7174
> > link mlx4_0/1 lqpn 539 qp-type RC state CONNECT ps TCP pid 30494
> comm rping src-addr 172.16.99.1:7174 dst-addr 172.16.99.1:43670
> > link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492
> comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174
> >
> > # rdma resource show cm_id dst-port 7174
> > link cxgb4_0/2 lqpn 1040 qp-type RC state CONNECT ps TCP pid 30498
> comm rping src-addr 172.16.2.1:38246 dst-addr 172.16.2.1:7174
> > link mlx4_0/1 lqpn 538 qp-type RC state CONNECT ps TCP pid 30492
> comm rping src-addr 172.16.99.1:43670 dst-addr 172.16.99.1:7174
> >
> > Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> > ---
> > rdma/rdma.h | 2 +
> > rdma/res.c | 258
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > rdma/utils.c | 5 ++
> > 3 files changed, 264 insertions(+), 1 deletion(-)
> >
>
> Steve, can you please add man pages update as a followup to this series?
>
> Especially the fact that you are providing dst-port filter option should
> be mentioned.
>
> Thanks,
> Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Will do.
^ permalink raw reply
* [PATCH net 2/2] vmxnet3: use correct flag to indicate LRO feature
From: Ronak Doshi @ 2018-03-13 19:41 UTC (permalink / raw)
To: netdev
Cc: rachel_lunnon, Ronak Doshi, Shrikrishna Khare, VMware, Inc.,
open list
'Commit 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2
(fwd)")' introduced a flag "lro" in structure vmxnet3_adapter which is
used to indicate whether LRO is enabled or not. However, the patch
did not set the flag and hence it was never exercised.
So, when LRO is enabled, it resulted in poor TCP performance due to
delayed acks. This issue is seen with packets which are larger than
the mss getting a delayed ack rather than an immediate ack, thus
resulting in high latency.
This patch removes the lro flag and directly uses device features
against NETIF_F_LRO to check if lro is enabled.
Reported-by: Rachel Lunnon <rachel_lunnon@stormagic.com>
Signed-off-by: Ronak Doshi <doshir@vmware.com>
Acked-by: Shrikrishna Khare <skhare@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 3 ++-
drivers/net/vmxnet3/vmxnet3_int.h | 5 ++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 052eef2f729f..86c4d6e4dfaa 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -1473,7 +1473,8 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
vmxnet3_rx_csum(adapter, skb,
(union Vmxnet3_GenericDesc *)rcd);
skb->protocol = eth_type_trans(skb, adapter->netdev);
- if (!rcd->tcp || !adapter->lro)
+ if (!rcd->tcp ||
+ !(adapter->netdev->features & NETIF_F_LRO))
goto not_lro;
if (segCnt != 0 && mss != 0) {
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index b94fdfd0b6f1..99387a4a20a8 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.4.12.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.4.13.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01040c00
+#define VMXNET3_DRIVER_VERSION_NUM 0x01040d00
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
@@ -343,7 +343,6 @@ struct vmxnet3_adapter {
u8 version;
bool rxcsum;
- bool lro;
#ifdef VMXNET3_RSS
struct UPT1_RSSConf *rss_conf;
--
2.11.0
^ permalink raw reply related
* [PATCH net 1/2] vmxnet3: avoid xmit reset due to a race in vmxnet3
From: Ronak Doshi @ 2018-03-13 19:40 UTC (permalink / raw)
To: netdev; +Cc: ntanaka, Ronak Doshi, Shrikrishna Khare, VMware, Inc., open list
The field txNumDeferred is used by the driver to keep track of the number
of packets it has pushed to the emulation. The driver increments it on
pushing the packet to the emulation and the emulation resets it to 0 at
the end of the transmit.
There is a possibility of a race either when (a) ESX is under heavy load or
(b) workload inside VM is of low packet rate.
This race results in xmit hangs when network coalescing is disabled. This
change creates a local copy of txNumDeferred and uses it to perform ring
arithmetic.
Reported-by: Noriho Tanaka <ntanaka@vmware.com>
Signed-off-by: Ronak Doshi <doshir@vmware.com>
Acked-by: Shrikrishna Khare <skhare@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 13 ++++++++-----
drivers/net/vmxnet3/vmxnet3_int.h | 4 ++--
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 8b39c160743d..052eef2f729f 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -977,6 +977,8 @@ vmxnet3_tq_xmit(struct sk_buff *skb, struct vmxnet3_tx_queue *tq,
{
int ret;
u32 count;
+ int numPkts;
+ int localTxNumDeferred;
unsigned long flags;
struct vmxnet3_tx_ctx ctx;
union Vmxnet3_GenericDesc *gdesc;
@@ -1075,12 +1077,12 @@ vmxnet3_tq_xmit(struct sk_buff *skb, struct vmxnet3_tx_queue *tq,
#else
gdesc = ctx.sop_txd;
#endif
+ localTxNumDeferred = le32_to_cpu(tq->shared->txNumDeferred);
if (ctx.mss) {
gdesc->txd.hlen = ctx.eth_ip_hdr_size + ctx.l4_hdr_size;
gdesc->txd.om = VMXNET3_OM_TSO;
gdesc->txd.msscof = ctx.mss;
- le32_add_cpu(&tq->shared->txNumDeferred, (skb->len -
- gdesc->txd.hlen + ctx.mss - 1) / ctx.mss);
+ numPkts = (skb->len - gdesc->txd.hlen + ctx.mss - 1) / ctx.mss;
} else {
if (skb->ip_summed == CHECKSUM_PARTIAL) {
gdesc->txd.hlen = ctx.eth_ip_hdr_size;
@@ -1091,8 +1093,10 @@ vmxnet3_tq_xmit(struct sk_buff *skb, struct vmxnet3_tx_queue *tq,
gdesc->txd.om = 0;
gdesc->txd.msscof = 0;
}
- le32_add_cpu(&tq->shared->txNumDeferred, 1);
+ numPkts = 1;
}
+ le32_add_cpu(&tq->shared->txNumDeferred, numPkts);
+ localTxNumDeferred += numPkts;
if (skb_vlan_tag_present(skb)) {
gdesc->txd.ti = 1;
@@ -1118,8 +1122,7 @@ vmxnet3_tq_xmit(struct sk_buff *skb, struct vmxnet3_tx_queue *tq,
spin_unlock_irqrestore(&tq->tx_lock, flags);
- if (le32_to_cpu(tq->shared->txNumDeferred) >=
- le32_to_cpu(tq->shared->txThreshold)) {
+ if (localTxNumDeferred >= le32_to_cpu(tq->shared->txThreshold)) {
tq->shared->txNumDeferred = 0;
VMXNET3_WRITE_BAR0_REG(adapter,
VMXNET3_REG_TXPROD + tq->qid * 8,
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 5ba222920e80..b94fdfd0b6f1 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.4.11.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.4.12.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01040b00
+#define VMXNET3_DRIVER_VERSION_NUM 0x01040c00
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] hv_netvsc: Make sure out channel is fully opened on send
From: Stephen Hemminger @ 2018-03-13 19:35 UTC (permalink / raw)
To: Mohammed Gamal
Cc: netdev, sthemmin, otubo, linux-kernel, devel, vkuznets, davem
In-Reply-To: <1520968010-20733-1-git-send-email-mgamal@redhat.com>
On Tue, 13 Mar 2018 20:06:50 +0100
Mohammed Gamal <mgamal@redhat.com> wrote:
> Dring high network traffic changes to network interface parameters
> such as number of channels or MTU can cause a kernel panic with a NULL
> pointer dereference. This is due to netvsc_device_remove() being
> called and deallocating the channel ring buffers, which can then be
> accessed by netvsc_send_pkt() before they're allocated on calling
> netvsc_device_add()
>
> The patch fixes this problem by checking the channel state and returning
> ENODEV if not yet opened. We also move the call to hv_ringbuf_avail_percent()
> which may access the uninitialized ring buffer.
>
> Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
> ---
> drivers/net/hyperv/netvsc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index 0265d70..44a8358 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -757,7 +757,7 @@ static inline int netvsc_send_pkt(
> struct netdev_queue *txq = netdev_get_tx_queue(ndev, packet->q_idx);
> u64 req_id;
> int ret;
> - u32 ring_avail = hv_ringbuf_avail_percent(&out_channel->outbound);
> + u32 ring_avail;
>
> nvmsg.hdr.msg_type = NVSP_MSG1_TYPE_SEND_RNDIS_PKT;
> if (skb)
> @@ -773,7 +773,7 @@ static inline int netvsc_send_pkt(
>
> req_id = (ulong)skb;
>
> - if (out_channel->rescind)
> + if (out_channel->rescind || out_channel->state != CHANNEL_OPENED_STATE)
> return -ENODEV;
>
> if (packet->page_buf_cnt) {
> @@ -791,6 +791,7 @@ static inline int netvsc_send_pkt(
> VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> }
>
> + ring_avail = hv_ringbuf_avail_percent(&out_channel->outbound);
> if (ret == 0) {
> atomic_inc_return(&nvchan->queue_sends);
>
Thanks for your patch. Yes there are races with the current update
logic. The root cause goes higher up in the flow; the send queues should
be stopped before netvsc_device_remove is called. Solving it where you tried
to is racy and not going to work reliably.
Network patches should go to netdev@vger.kernel.org
You can't move the ring_avail check until after the vmbus_sendpacket because
that will break the flow control logic.
Instead, you should just move the avail_read check until just after the existing rescind
check.
Also, you shouldn't need to check for OPENED_STATE, just rescind is enough.
^ permalink raw reply
* [PATCH net-next] enic: drop IP proto check for vxlan tunnel delete
From: Govindarajulu Varadarajan @ 2018-03-13 12:24 UTC (permalink / raw)
To: davem, netdev; +Cc: benve, Govindarajulu Varadarajan
Commit d11790941dd3 ("enic: Add vxlan offload support for IPv6 pkts")
added vxlan offload support for IPv6 pkts. Required change in
enic_udp_tunnel_del was not made. This creates a bug where once user
adds IPv6 tunnel, hw offload for that cannot be deleted.
This patch removes check for IP proto in tunnel delete path. Driver need
not check for IP proto since same UDP port cannot be used to create two
tunnels.
Fixes: d11790941dd3 ("enic: Add vxlan offload support for IPv6 pkts")
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index a25fb95492a0..81684acf52af 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -251,9 +251,8 @@ static void enic_udp_tunnel_del(struct net_device *netdev,
spin_lock_bh(&enic->devcmd_lock);
- if ((ti->sa_family != AF_INET) ||
- ((ntohs(ti->port) != enic->vxlan.vxlan_udp_port_number)) ||
- (ti->type != UDP_TUNNEL_TYPE_VXLAN)) {
+ if ((ntohs(ti->port) != enic->vxlan.vxlan_udp_port_number) ||
+ ti->type != UDP_TUNNEL_TYPE_VXLAN) {
netdev_info(netdev, "udp_tnl: port:%d, sa_family: %d, type: %d not offloaded",
ntohs(ti->port), ti->sa_family, ti->type);
goto unlock;
--
2.16.2
^ permalink raw reply related
* [PATCH net-next] doc: remove out of date links and info from packet mmap
From: Stephen Hemminger @ 2018-03-13 19:24 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger, Stephen Hemminger
The packet_mmap documentation had links to no longer existing web
sites; replace with other site which has similar example.
Support for packet mmap has been in mainline versions of libpcap
for several years.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
Documentation/networking/packet_mmap.txt | 22 +++++-----------------
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index bf654845556e..999eb41da81d 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -7,15 +7,12 @@ socket interface on 2.4/2.6/3.x kernels. This type of sockets is used for
i) capture network traffic with utilities like tcpdump, ii) transmit network
traffic, or any other that needs raw access to network interface.
-You can find the latest version of this document at:
- http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap
-
Howto can be found at:
- http://wiki.gnu-log.net (packet_mmap)
+ https://sites.google.com/site/packetmmap/
Please send your comments to
Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
- Johann Baudy <johann.baudy@gnu-log.net>
+ Johann Baudy
-------------------------------------------------------------------------------
+ Why use PACKET_MMAP
@@ -51,17 +48,8 @@ From the user standpoint, you should use the higher level libpcap library, which
is a de facto standard, portable across nearly all operating systems
including Win32.
-Said that, at time of this writing, official libpcap 0.8.1 is out and doesn't include
-support for PACKET_MMAP, and also probably the libpcap included in your distribution.
-
-I'm aware of two implementations of PACKET_MMAP in libpcap:
-
- http://wiki.ipxwarzone.com/ (by Simon Patarin, based on libpcap 0.6.2)
- http://public.lanl.gov/cpw/ (by Phil Wood, based on lastest libpcap)
-
-The rest of this document is intended for people who want to understand
-the low level details or want to improve libpcap by including PACKET_MMAP
-support.
+Packet MMAP support was integrated into libpcap around the time of version 1.3.0;
+TPACKET_V3 support was added in version 1.5.0
--------------------------------------------------------------------------------
+ How to use mmap() directly to improve capture process
@@ -174,7 +162,7 @@ As capture, each frame contains two parts:
/* bind socket to eth0 */
bind(this->socket, (struct sockaddr *)&my_addr, sizeof(struct sockaddr_ll));
- A complete tutorial is available at: http://wiki.gnu-log.net/
+ A complete tutorial is available at: https://sites.google.com/site/packetmmap/
By default, the user should put data at :
frame base + TPACKET_HDRLEN - sizeof(struct sockaddr_ll)
--
2.16.1
^ permalink raw reply related
* Re: [PATCH 12/15] ice: Add stats and ethtool support
From: Eric Dumazet @ 2018-03-13 19:17 UTC (permalink / raw)
To: Venkataramanan, Anirudh, kubakici@wp.pl
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org
In-Reply-To: <1520967916.696.21.camel@intel.com>
On 03/13/2018 12:05 PM, Venkataramanan, Anirudh wrote:
> On Fri, 2018-03-09 at 15:14 -0800, Jakub Kicinski wrote:
>> On Fri, 9 Mar 2018 09:21:33 -0800, Anirudh Venkataramanan wrote:
>>> +static const struct ice_stats ice_net_stats[] = {
>>> + ICE_NETDEV_STAT(rx_packets),
>>> + ICE_NETDEV_STAT(tx_packets),
>>> + ICE_NETDEV_STAT(rx_bytes),
>>> + ICE_NETDEV_STAT(tx_bytes),
>>> + ICE_NETDEV_STAT(rx_errors),
>>> + ICE_NETDEV_STAT(tx_errors),
>>> + ICE_NETDEV_STAT(rx_dropped),
>>> + ICE_NETDEV_STAT(tx_dropped),
>>> + ICE_NETDEV_STAT(multicast),
>>> + ICE_NETDEV_STAT(rx_length_errors),
>>> + ICE_NETDEV_STAT(rx_crc_errors),
>>> +};
>>
>> Please don't duplicate standard netdev stats in ethtool -S.
>
> Jacub,
>
> Thanks for the feedback. I am not sure I understand what's being asked
> here. Do you mean to say that standard netdev stats should not be
> printed when we do ethtool -S or something else?
>
> Thanks!
> Ani
>
Yes, this is a recurring mistake
See commit
bf909456f6a89654cb65c01fe83a4f9b133bf978 Revert "net: hns3: Add packet
statistics of netdev"
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 6/6] rdma: Add PD resource tracking information
From: Leon Romanovsky @ 2018-03-13 19:07 UTC (permalink / raw)
To: Steve Wise; +Cc: dsahern, stephen, netdev, linux-rdma
In-Reply-To: <d45991a74de63bf587824839a3c902f4b6d94081.1520020530.git.swise@opengridcomputing.com>
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
On Tue, Feb 27, 2018 at 08:07:23AM -0800, Steve Wise wrote:
> Sample output:
>
> Without CAP_NET_ADMIN capability:
>
> link mlx4_0/- users 0 pid 0 comm [ib_srpt]
> link mlx4_0/- users 0 pid 0 comm [ib_srp]
> link mlx4_0/- users 1 pid 0 comm [ib_core]
> link cxgb4_0/- users 0 pid 0 comm [ib_srp]
>
> With CAP_NET_ADMIN capability:
> link mlx4_0/- local_dma_lkey 0x8000 users 0 pid 0 comm [ib_srpt]
> link mlx4_0/- local_dma_lkey 0x8000 users 0 pid 0 comm [ib_srp]
> link mlx4_0/- local_dma_lkey 0x8000 users 1 pid 0 comm [ib_core]
> link cxgb4_0/- local_dma_lkey 0x0 users 0 pid 0 comm [ib_srp]
>
> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> ---
> rdma/res.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 92 insertions(+)
>
Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] hv_netvsc: Make sure out channel is fully opened on send
From: Mohammed Gamal @ 2018-03-13 19:06 UTC (permalink / raw)
To: netdev, sthemmin
Cc: devel, davem, vkuznets, otubo, linux-kernel, Mohammed Gamal
Dring high network traffic changes to network interface parameters
such as number of channels or MTU can cause a kernel panic with a NULL
pointer dereference. This is due to netvsc_device_remove() being
called and deallocating the channel ring buffers, which can then be
accessed by netvsc_send_pkt() before they're allocated on calling
netvsc_device_add()
The patch fixes this problem by checking the channel state and returning
ENODEV if not yet opened. We also move the call to hv_ringbuf_avail_percent()
which may access the uninitialized ring buffer.
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
drivers/net/hyperv/netvsc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 0265d70..44a8358 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -757,7 +757,7 @@ static inline int netvsc_send_pkt(
struct netdev_queue *txq = netdev_get_tx_queue(ndev, packet->q_idx);
u64 req_id;
int ret;
- u32 ring_avail = hv_ringbuf_avail_percent(&out_channel->outbound);
+ u32 ring_avail;
nvmsg.hdr.msg_type = NVSP_MSG1_TYPE_SEND_RNDIS_PKT;
if (skb)
@@ -773,7 +773,7 @@ static inline int netvsc_send_pkt(
req_id = (ulong)skb;
- if (out_channel->rescind)
+ if (out_channel->rescind || out_channel->state != CHANNEL_OPENED_STATE)
return -ENODEV;
if (packet->page_buf_cnt) {
@@ -791,6 +791,7 @@ static inline int netvsc_send_pkt(
VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
}
+ ring_avail = hv_ringbuf_avail_percent(&out_channel->outbound);
if (ret == 0) {
atomic_inc_return(&nvchan->queue_sends);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 iproute2-next 5/6] rdma: Add MR resource tracking information
From: Leon Romanovsky @ 2018-03-13 19:06 UTC (permalink / raw)
To: Steve Wise; +Cc: dsahern, stephen, netdev, linux-rdma
In-Reply-To: <367508e4291fceb71f2d60e77dbf2d60cbebf286.1520020530.git.swise@opengridcomputing.com>
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
On Tue, Feb 27, 2018 at 08:07:17AM -0800, Steve Wise wrote:
> Sample output:
>
> Without CAP_NET_ADMIN:
>
> $ rdma resource show mr mrlen 65536
> link mlx4_0/- mrlen 65536 pid 0 comm [nvme_rdma]
> link cxgb4_0/- mrlen 65536 pid 0 comm [nvme_rdma]
>
> With CAP_NET_ADMIN:
>
> # rdma resource show mr mrlen 65536
> link mlx4_0/- rkey 0x12702 lkey 0x12702 iova 0x85724a000 mrlen 65536 pid 0 comm [nvme_rdma]
> link cxgb4_0/- rkey 0x68fe4e9 lkey 0x68fe4e9 iova 0x835b91000 mrlen 65536 pid 0 comm [nvme_rdma]
>
> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> ---
> include/json_writer.h | 2 +
> lib/json_writer.c | 11 +++++
> rdma/res.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++
> rdma/utils.c | 6 +++
> 4 files changed, 144 insertions(+)
>
Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 12/15] ice: Add stats and ethtool support
From: Venkataramanan, Anirudh @ 2018-03-13 19:05 UTC (permalink / raw)
To: kubakici@wp.pl; +Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org
In-Reply-To: <20180309151428.4d73358c@cakuba.netronome.com>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
On Fri, 2018-03-09 at 15:14 -0800, Jakub Kicinski wrote:
> On Fri, 9 Mar 2018 09:21:33 -0800, Anirudh Venkataramanan wrote:
> > +static const struct ice_stats ice_net_stats[] = {
> > + ICE_NETDEV_STAT(rx_packets),
> > + ICE_NETDEV_STAT(tx_packets),
> > + ICE_NETDEV_STAT(rx_bytes),
> > + ICE_NETDEV_STAT(tx_bytes),
> > + ICE_NETDEV_STAT(rx_errors),
> > + ICE_NETDEV_STAT(tx_errors),
> > + ICE_NETDEV_STAT(rx_dropped),
> > + ICE_NETDEV_STAT(tx_dropped),
> > + ICE_NETDEV_STAT(multicast),
> > + ICE_NETDEV_STAT(rx_length_errors),
> > + ICE_NETDEV_STAT(rx_crc_errors),
> > +};
>
> Please don't duplicate standard netdev stats in ethtool -S.
Jacub,
Thanks for the feedback. I am not sure I understand what's being asked
here. Do you mean to say that standard netdev stats should not be
printed when we do ethtool -S or something else?
Thanks!
Ani
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3302 bytes --]
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 4/6] rdma: Add CQ resource tracking information
From: Leon Romanovsky @ 2018-03-13 19:05 UTC (permalink / raw)
To: Steve Wise; +Cc: dsahern, stephen, netdev, linux-rdma
In-Reply-To: <9bb3491baaa8c8253d166aced89813bd06c51b01.1520020530.git.swise@opengridcomputing.com>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
On Tue, Feb 27, 2018 at 08:07:11AM -0800, Steve Wise wrote:
> Sample output:
>
> # rdma resource show cq
> link cxgb4_0/- cqe 46 users 2 pid 30503 comm rping
> link cxgb4_0/- cqe 46 users 2 pid 30498 comm rping
> link mlx4_0/- cqe 63 users 2 pid 30494 comm rping
> link mlx4_0/- cqe 63 users 2 pid 30489 comm rping
> link mlx4_0/- cqe 1023 users 2 poll_ctx WORKQUEUE pid 0 comm [ib_core]
>
> # rdma resource show cq pid 30489
> link mlx4_0/- cqe 63 users 2 pid 30489 comm rping
>
> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> ---
> rdma/res.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> rdma/utils.c | 5 +++
> 2 files changed, 141 insertions(+)
>
Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
[-- Attachment #2: signature.asc --]
[-- 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