* Re: Fwd: Re: Section 4 No. 9,10 Failed was occurred by IPv6 Ready Logo Conformance Test
From: Yuki Machida @ 2016-04-19 8:45 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: hannes, rongqing.li, netdev, davem
In-Reply-To: <293867211.2746.1460728775752@office.mailbox.org>
Hi Hagen,
On 2016年04月15日 22:59, Hagen Paul Pfeifer wrote:
>> On April 15, 2016 at 10:47 AM Yuki Machida <machida.yuki@jp.fujitsu.com> wrote:
>>
>>>> commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2
>>>> Author: Hagen Paul Pfeifer <hagen@jauu.net>
>>>> Date: Thu Jan 15 22:34:25 2015 +0100
>>>>
>>>> ipv6: stop sending PTB packets for MTU < 1280
>>>>
>>>> Reduce the attack vector and stop generating IPv6 Fragment Header for
>>>> paths with an MTU smaller than the minimum required IPv6 MTU
>>>> size (1280 byte) - called atomic fragments.
>>>>
>>>> See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1]
>>>> for more information and how this "feature" can be misused.
>>>>
>>>> [1]
>>>> https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00
>>>>
>>>> Signed-off-by: Fernando Gont <fgont@si6networks.com>
>>>> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
>>>> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>
>>> I will try.
>>
>> I confirmed that v4.1.20 revert above patch is passed Section 4 No. 9 and 10 testcases
>> in IPv6 Ready Logo Conformance Test.
>> I can't immediately revert above patch from v4.6-rc1 by implementation has changed.
>
> is it to please a conforming test tool or fix "revert 9d289715eb5c2" a real problem? If so: which problem do you have with 9d289715eb5c2 or draft-ietf-6man-deprecate-atomfrag-generation-06?
Thank you for your reply.
I was wrong.
That real problem may not be 9d289715eb5c2,
Because Roy said "TAHI should be updated".
But I don't understand that real problem is in Test Tool or draft-ietf-6man-deprecate-atomfrag-generation-06.
I am conforming it.
Regards,
Yuki Machida
>
> Hagen
>
^ permalink raw reply
* Re: [Odd commit author id merge via netdev]
From: Johannes Berg @ 2016-04-19 8:55 UTC (permalink / raw)
To: santosh shilimkar; +Cc: netdev, David S. Miller
In-Reply-To: <5712D538.10305@oracle.com>
> Thought of letting you know that creating username didn't
> seems to help. I did create a patchwork account and associated
> the email ids I use for commits after last email exchange.
>
> Now it got tested with Dave's 'net' tree commits indirectly.
> The patchwork commit format still seems to be
> "Author: email-id <email-id>" irrespective of patchwork user
> name for me.
>
That's unfortunate.
Very strange - I see on patchwork two entries for you - one @ti.com and
one @oracle.com, and only the former seems to have a real name in
patchwork.
johannes
^ permalink raw reply
* Re: [PATCH v3] prism54: isl_38xx: Replace 'struct timeval'
From: Johannes Berg @ 2016-04-19 8:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Luis R. Rodriguez, y2038, netdev, linux-wireless, Tina Ruchandani,
linux-kernel
In-Reply-To: <4679823.7bDEQhE9qO@wuerfel>
On Mon, 2016-04-18 at 00:10 +0200, Arnd Bergmann wrote:
> On Sunday 17 April 2016 14:42:33 Johannes Berg wrote:
> >
> >
> > I was thinking more restrictively of just the stuff that can't even
> > be
> > built without modifying the sources - like the "#if VERBOSE" thing.
> All the DEBUG() statements are inside of this kind of check, so if we
> remove the #ifdefs, it would be logical to remove the rest of the
> debugging infrastructure (DEBUG() macros, SHOW_*, pc_debug, maybe
> more) as well.
>
Seems reasonable.
Maybe we should Cc the maintainer, but I suspect that since the driver
is marked Obsolete anyway Luis won't care either :)
johannes
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* RE: [PATCHv2] wlcore: spi: add wl18xx support
From: Reizer, Eyal @ 2016-04-19 9:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kalle Valo, Eyal Reizer,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1463330011.BhWEcYYuGD@wuerfel>
Arnd,
> > > >
> > > > - all wilink family needs special init command for entering wspi mode.
> > > > extra clock cycles should be sent after the spi init command while the
> > > > cs pin is high.
> > > > - switch to controling the cs pin from the spi driver for achieveing the
> > > > above.
> > > > - the selected cs gpio is read from the spi device-tree node using the
> > > > cs-gpios field and setup as a gpio.
> > > > - See the example below for specifying the cs gpio using the cs-gpios
> entry
> > > > &spi0 {
> > > > ...
> > > > cs-gpios = <&gpio0 5 0>;
> > > > ...
> > > > wlcore: wlcore@0 {
> > > > compatible = "ti,wl1835";
> > > > ...
> > > > ...
> > > > };
> > > > };
> > > >
> > > > Signed-off-by: Eyal Reizer <eyalr-l0cyMroinI0@public.gmane.org>
> > >
> > > I don't think this can work in general: not all SPI hosts uses GPIOs
> > > for controlling CS, so the logic can't work, and it's also a
> > > layering violation for the driver to look at the parent.
> > >
> > > I would suggest fixing this using a new API function from the SPI
> > > core, if we don't already have a generic way to do it.
> > >
> > Originally this is what I have done until I was pointed to the generic
> > cs-gpio mechanism in the SPI core.
> > It is a generic mechanism already in the SPI core driver.
> > See: Documentation/devicetree/bindings/spi/spi-bus.txt
>
> The cs-gpios property is documented as optional, it defines how you should
> list the gpios if CS is implemented using gpio, but not all hardware does it like
> this.
>
> > It is also part of the generic spi.h (include/Linux/spi/spi.h),
> > already part of " struct spi_device" So it seemed redundant adding
> > another mechanism for implementing the same.
> > Platform that interact with a wilink need to use it, and platforms
> > that don't have this capability will probably not interact with a wilink device
> using SPI.
>
> The cs_gpio field in spi_device belongs to the spi host controller, no other
> slave driver uses it.
>
> I wasn't asking for a duplication of this mechanism, but an interface to use it
> properly. Internally, the spi core uses the spi_set_cs() function to pick a CS.
> Find a way to use that rather than reimplementing it incorrectly.
>
Understood. As this special CS manipulation is unique to wspi (wilink spi) I think the
best option is to move this gpio allocation into wlcore_spi as a new device tree entry
used only by this driver.
If you agree I will submit a v3.
Best Regards,
Eyal
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 net-next] net: use jiffies_to_msecs to replace EXPIRES_IN_MS in inet/sctp_diag
From: Jakub Sitnicki @ 2016-04-19 9:13 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Vlad Yasevich,
daniel, davem, eric.dumazet
In-Reply-To: <87a0e83132ce64a3fe2266a5323fa6577a2e5c96.1461049801.git.lucien.xin@gmail.com>
On Tue, Apr 19, 2016 at 09:10 AM CEST, Xin Long <lucien.xin@gmail.com> wrote:
> EXPIRES_IN_MS macro comes from net/ipv4/inet_diag.c and dates
> back to before jiffies_to_msecs() has been introduced.
>
> Now we can remove it and use jiffies_to_msecs().
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
Acked-by: Jakub Sitnicki <jkbs@redhat.com>
^ permalink raw reply
* RE: [RFC PATCH v2 net-next 4/7] tcp: Make use of MSG_EOR flag in tcp_sendmsg
From: David Laight @ 2016-04-19 9:47 UTC (permalink / raw)
To: 'Eric Dumazet', Martin KaFai Lau
Cc: netdev@vger.kernel.org, Eric Dumazet, Neal Cardwell,
Soheil Hassas Yeganeh, Willem de Bruijn, Yuchung Cheng,
Kernel Team
In-Reply-To: <1461021493.10638.131.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet
> Sent: 19 April 2016 00:18
...
> MSG_EOR should not depend on SKBTX_ANY_TSTAMP
>
> Really, simply using send(fd, ..., len, MSG_EOR) should instruct TCP to
> mark the cooked skb as a non candidate for future coalescing.
Isn't that very similar to the inverse of MSG_MORE?
Or a send with Nagle disabled?
David
^ permalink raw reply
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Johannes Berg @ 2016-04-19 10:09 UTC (permalink / raw)
To: David Miller, eric.dumazet
Cc: roopa, netdev, jhs, tgraf, nicolas.dichtel, Emmanuel Grumbach
In-Reply-To: <20160418.235207.395468709808133833.davem@davemloft.net>
On Mon, 2016-04-18 at 23:52 -0400, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Mon, 18 Apr 2016 21:48:51 -0400 (EDT)
>
> > I think the time has probably come to have a new netlink attribute
> > format that doesn't have this multi-decade old problem.
> ...
>
> Scratch this whole idea, I think the padding attribute works a lot
> better and is backwards compatible with every properly written
> netlink application.
This talk about attribute flags reminded me about something else.
At netconf, we talked about how awkward it can be that one doesn't know
if an attribute was accepted by the kernel or simply ignored because
it's not supported (older kernel version).
I considered (and Emmanuel has started to cook up a patch for it)
adding a flag here meaning "reject if not parsed" (or so).
Now, I realize that with all the existing netlink commands one can't
actually rely on that (since it requires some infrastructure), but new
commands in existing families and also entirely new generic netlink
families would allow let userspace rely on such a thing.
Thoughts?
johannes
^ permalink raw reply
* Re: [PATCH] bpf: avoid warning for wrong pointer cast
From: Philip Li @ 2016-04-19 10:09 UTC (permalink / raw)
To: Fengguang Wu
Cc: Alexei Starovoitov, Arnd Bergmann, David S . Miller, netdev,
Steven Rostedt, Ingo Molnar, Alexei Starovoitov, Daniel Borkmann,
linux-kernel
In-Reply-To: <20160419023334.GC24067@wfg-t540p.sh.intel.com>
On Tue, Apr 19, 2016 at 10:33:34AM +0800, Fengguang Wu wrote:
> Hi Alexei,
>
> On Sat, Apr 16, 2016 at 05:47:42PM -0700, Alexei Starovoitov wrote:
> > On Sat, Apr 16, 2016 at 10:29:33PM +0200, Arnd Bergmann wrote:
> > > Two new functions in bpf contain a cast from a 'u64' to a
> > > pointer. This works on 64-bit architectures but causes a warning
> > > on all 32-bit architectures:
> > >
> > > kernel/trace/bpf_trace.c: In function 'bpf_perf_event_output_tp':
> > > kernel/trace/bpf_trace.c:350:13: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
> > > u64 ctx = *(long *)r1;
> > >
> > > This changes the cast to first convert the u64 argument into a uintptr_t,
> > > which is guaranteed to be the same size as a pointer.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Fixes: 9940d67c93b5 ("bpf: support bpf_get_stackid() and bpf_perf_event_output() in tracepoint programs")
> >
> > Thanks.
> > Acked-by: Alexei Starovoitov <ast@kernel.org>
> >
> > I guess I started to rely on 0-day build-bot too much.
> > This patch has been in my tree for 2+ weeks and then in net-next and
> > I didn't receive a single email from build-bot about this warning,
> > though I do receive them for my other work-in-progress stuff. Odd.
> > Fengguang, any idea why build-bot sometimes silent?
>
> Sorry I went off for some time.. Philip, would you help have a check?
Hi Alexei, i have done some investigation for this. Fengguang, pls correct me if my understanding is wrong.
0day has caught the warning for f1ff54 commit around 2016-3-22, which considers the same warning in future is not new one, thus neglect it.
rli9@inn /kbuild-tests/build-error$ cat kernel-trace-bpf_trace.c:warning:cast-to-pointer-from-integer-of-different-size
kernel/trace/bpf_trace.c:345:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
2016-03-22 17:12:38 xian bpf:master:321e70e79c94e5e6394a882d567baac949b74000 i386-randconfig-x009-201612 f1ff543dbdd3eff53c8328cfb582f18e6c3d56ec
And for f1ff54's warning, 0day actually bisects to it, but then it checks the head of bpf/master at that time which is 321e70e, find the error is not existed, so
it ignores the interim warning to not send email report.
2016-03-22_17:15:49 O: R: /kbuild/src/consumer/kernel/trace/bpf_trace.c:345:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
2016-03-22_17:15:49 O: grep -h -r . /tmp/kernel/i386-randconfig-x009-201612/gcc-5/f1ff543dbdd3eff53c8328cfb582f18e6c3d56ec/build-error # 0 errors
2016-03-22_17:15:49 O: grep -h -r . /tmp/kernel/i386-randconfig-x009-201612/gcc-5/f1ff543dbdd3eff53c8328cfb582f18e6c3d56ec/build-error/ # 0 errors
2016-03-22_17:15:49 O: /c/kernel-tests/list-head bpf:master:321e70e79c94e5e6394a882d567baac949b74000 i386-randconfig-x009-201612
2016-03-22_17:16:03 O: .
2016-03-22_17:16:03 O: ..
2016-03-22_17:16:03 O: kernel-trace-bpf_trace.c:warning:cast-to-pointer-from-integer-of-different-size
2016-03-22_17:16:03 O: 2016-03-22 17:16:03 don't email interim warnings
2016-03-22_17:16:03 O: 2016-03-22 17:16:03 error no longer exist in head bpf/master 321e70e79c94e5e6394a882d567baac949b74000, check
/tmp/kernel/i386-randconfig-x009-201612/gcc-5/321e70e79c94e5e6394a882d567baac949b74000, errno 14
2016-03-22_17:16:03 O: 2016-03-22 17:16:03 Don't email interim warnings!
what really happens to 321e70e is it has build error (i rerun it to confirm), which is reported at https://lists.01.org/pipermail/kbuild-all/2016-March/018625.html. So this is
a possible change to be done in 0day to report the first bad commit when HEAD is build error.
2016-04-19_15:00:39 O: 2016-04-19 15:00 Running /kbuild-tests/build-queue/lkp-nex06-consumer/i386-randconfig-x009-201612-gcc-5-321e70e79c94e5e6394a882d567baac949b74000
2016-04-19_15:00:39 O: create new KBUILD_OUTPUT dir /kbuild/obj/consumer/i386-randconfig-x009-201612
2016-04-19_15:00:39 O: git checkout -B build-queue 321e70e79c94e5e6394a882d567baac949b74000
2016-04-19_15:07:08 E: 330 real 4732 user 629 sys 1620.50% cpu i386-randconfig-x009-201612
2016-04-19_15:07:13 O: status: FAIL: build error
2016-04-19_15:07:13 O: ERROR: "tcp_sendpage" [drivers/staging/lustre/lnet/klnds/socklnd/ksocklnd.ko] undefined!
>
> Thanks,
> Fengguang
^ permalink raw reply
* Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Emmanuel Grumbach @ 2016-04-19 10:48 UTC (permalink / raw)
To: Johannes Berg
Cc: David Miller, Eric Dumazet, roopa, netdev@vger.kernel.org, jhs,
tgraf, nicolas.dichtel
In-Reply-To: <1461060543.2766.20.camel@sipsolutions.net>
On Tue, Apr 19, 2016 at 1:09 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2016-04-18 at 23:52 -0400, David Miller wrote:
>> From: David Miller <davem@davemloft.net>
>> Date: Mon, 18 Apr 2016 21:48:51 -0400 (EDT)
>>
>> > I think the time has probably come to have a new netlink attribute
>> > format that doesn't have this multi-decade old problem.
>> ...
>>
>> Scratch this whole idea, I think the padding attribute works a lot
>> better and is backwards compatible with every properly written
>> netlink application.
>
> This talk about attribute flags reminded me about something else.
>
> At netconf, we talked about how awkward it can be that one doesn't know
> if an attribute was accepted by the kernel or simply ignored because
> it's not supported (older kernel version).
>
> I considered (and Emmanuel has started to cook up a patch for it)
> adding a flag here meaning "reject if not parsed" (or so).
>
> Now, I realize that with all the existing netlink commands one can't
> actually rely on that (since it requires some infrastructure), but new
> commands in existing families and also entirely new generic netlink
> families would allow let userspace rely on such a thing.
>
> Thoughts?
FWIW:
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 2a5dbcc..2dfd46d 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -663,6 +663,15 @@ static inline int nla_type(const struct nlattr *nla)
}
/**
+ * nla_must_parse - returns true if the attribute must be parsed
+ * @nla: netlink attribute
+ */
+static inline bool nla_must_parse(const struct nlattr *nla)
+{
+ return nla->nla_type & NLA_F_NET_MUST_PARSE;
+}
+
+/**
* nla_data - head of payload
* @nla: netlink attribute
*/
diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index 1a85940..e81a8d4 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -165,17 +165,21 @@ struct nlattr {
/*
* nla_type (16 bits)
- * +---+---+-------------------------------+
- * | N | O | Attribute Type |
- * +---+---+-------------------------------+
+ * +---+---+---+----------------------------+
+ * | N | O | M | Attribute Type |
+ * +---+---+---+----------------------------+
* N := Carries nested attributes
* O := Payload stored in network byte order
+ * M := Attribute can't be ignored
*
* Note: The N and O flag are mutually exclusive.
*/
#define NLA_F_NESTED (1 << 15)
#define NLA_F_NET_BYTEORDER (1 << 14)
-#define NLA_TYPE_MASK ~(NLA_F_NESTED | NLA_F_NET_BYTEORDER)
+#define NLA_F_NET_MUST_PARSE (1 << 13)
+#define NLA_TYPE_MASK ~(NLA_F_NESTED | \
+ NLA_F_NET_BYTEORDER | \
+ NLA_F_NET_MUST_PARSE)
#define NLA_ALIGNTO 4
#define NLA_ALIGN(len) (((len) + NLA_ALIGNTO - 1) & ~(NLA_ALIGNTO - 1))
diff --git a/lib/nlattr.c b/lib/nlattr.c
index f5907d2..fa15e6f 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -198,6 +198,10 @@ int nla_parse(struct nlattr **tb, int maxtype,
const struct nlattr *head,
}
tb[type] = (struct nlattr *)nla;
+ } else if (nla_must_parse(nla)) {
+ err = -EINVAL;
+ goto errout;
}
}
^ permalink raw reply related
* [PATCH net-next] NLA_BINARY misuse bug in HSR
From: Peter Heise @ 2016-04-19 11:34 UTC (permalink / raw)
To: arvid.brodin, davem, netdev; +Cc: daniel, julia.lawall, peter.heise
Removed .type field from NLA to do proper length checking.
Reported by Daniel Borkmann and Julia Lawall.
Signed-off-by: Peter Heise <peter.heise@airbus.com>
---
net/hsr/hsr_netlink.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c
index 5425d87..d4d1617 100644
--- a/net/hsr/hsr_netlink.c
+++ b/net/hsr/hsr_netlink.c
@@ -24,7 +24,7 @@ static const struct nla_policy hsr_policy[IFLA_HSR_MAX + 1] = {
[IFLA_HSR_SLAVE2] = { .type = NLA_U32 },
[IFLA_HSR_MULTICAST_SPEC] = { .type = NLA_U8 },
[IFLA_HSR_VERSION] = { .type = NLA_U8 },
- [IFLA_HSR_SUPERVISION_ADDR] = { .type = NLA_BINARY, .len = ETH_ALEN },
+ [IFLA_HSR_SUPERVISION_ADDR] = { .len = ETH_ALEN },
[IFLA_HSR_SEQ_NR] = { .type = NLA_U16 },
};
@@ -121,10 +121,9 @@ static struct rtnl_link_ops hsr_link_ops __read_mostly = {
/* attribute policy */
-/* NLA_BINARY missing in libnl; use NLA_UNSPEC in userspace instead. */
static const struct nla_policy hsr_genl_policy[HSR_A_MAX + 1] = {
- [HSR_A_NODE_ADDR] = { .type = NLA_BINARY, .len = ETH_ALEN },
- [HSR_A_NODE_ADDR_B] = { .type = NLA_BINARY, .len = ETH_ALEN },
+ [HSR_A_NODE_ADDR] = { .len = ETH_ALEN },
+ [HSR_A_NODE_ADDR_B] = { .len = ETH_ALEN },
[HSR_A_IFINDEX] = { .type = NLA_U32 },
[HSR_A_IF1_AGE] = { .type = NLA_U32 },
[HSR_A_IF2_AGE] = { .type = NLA_U32 },
--
2.5.0
^ permalink raw reply related
* Re: [PATCHv3 net-next] net: use jiffies_to_msecs to replace EXPIRES_IN_MS in inet/sctp_diag
From: Marcelo Ricardo Leitner @ 2016-04-19 11:59 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, Vlad Yasevich, daniel, davem,
eric.dumazet, jsitnick
In-Reply-To: <87a0e83132ce64a3fe2266a5323fa6577a2e5c96.1461049801.git.lucien.xin@gmail.com>
Re $tags, this is actually the 1st version of the patch, not the 3rd.
On Tue, Apr 19, 2016 at 03:10:01PM +0800, Xin Long wrote:
> EXPIRES_IN_MS macro comes from net/ipv4/inet_diag.c and dates
> back to before jiffies_to_msecs() has been introduced.
>
> Now we can remove it and use jiffies_to_msecs().
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/ipv4/inet_diag.c | 12 ++++++------
> net/sctp/sctp_diag.c | 6 ++----
> 2 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
> index 70212bd..ad7956f 100644
> --- a/net/ipv4/inet_diag.c
> +++ b/net/ipv4/inet_diag.c
> @@ -197,27 +197,27 @@ int inet_sk_diag_fill(struct sock *sk, struct inet_connection_sock *icsk,
> goto out;
> }
>
> -#define EXPIRES_IN_MS(tmo) DIV_ROUND_UP((tmo - jiffies) * 1000, HZ)
> -
> if (icsk->icsk_pending == ICSK_TIME_RETRANS ||
> icsk->icsk_pending == ICSK_TIME_EARLY_RETRANS ||
> icsk->icsk_pending == ICSK_TIME_LOSS_PROBE) {
> r->idiag_timer = 1;
> r->idiag_retrans = icsk->icsk_retransmits;
> - r->idiag_expires = EXPIRES_IN_MS(icsk->icsk_timeout);
> + r->idiag_expires =
> + jiffies_to_msecs(icsk->icsk_timeout - jiffies);
> } else if (icsk->icsk_pending == ICSK_TIME_PROBE0) {
> r->idiag_timer = 4;
> r->idiag_retrans = icsk->icsk_probes_out;
> - r->idiag_expires = EXPIRES_IN_MS(icsk->icsk_timeout);
> + r->idiag_expires =
> + jiffies_to_msecs(icsk->icsk_timeout - jiffies);
> } else if (timer_pending(&sk->sk_timer)) {
> r->idiag_timer = 2;
> r->idiag_retrans = icsk->icsk_probes_out;
> - r->idiag_expires = EXPIRES_IN_MS(sk->sk_timer.expires);
> + r->idiag_expires =
> + jiffies_to_msecs(sk->sk_timer.expires - jiffies);
> } else {
> r->idiag_timer = 0;
> r->idiag_expires = 0;
> }
> -#undef EXPIRES_IN_MS
>
> if ((ext & (1 << (INET_DIAG_INFO - 1))) && handler->idiag_info_size) {
> attr = nla_reserve(skb, INET_DIAG_INFO,
> diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c
> index 98ecd16..bb2d8d9 100644
> --- a/net/sctp/sctp_diag.c
> +++ b/net/sctp/sctp_diag.c
> @@ -48,10 +48,8 @@ static void inet_diag_msg_sctpasoc_fill(struct inet_diag_msg *r,
> r->idiag_state = asoc->state;
> r->idiag_timer = SCTP_EVENT_TIMEOUT_T3_RTX;
> r->idiag_retrans = asoc->rtx_data_chunks;
> -#define EXPIRES_IN_MS(tmo) DIV_ROUND_UP((tmo - jiffies) * 1000, HZ)
> - r->idiag_expires =
> - EXPIRES_IN_MS(asoc->timeouts[SCTP_EVENT_TIMEOUT_T3_RTX]);
> -#undef EXPIRES_IN_MS
> + r->idiag_expires = jiffies_to_msecs(
> + asoc->timeouts[SCTP_EVENT_TIMEOUT_T3_RTX] - jiffies);
Indentation here is tricky but I don't see any better way.
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> }
>
> static int inet_diag_msg_sctpladdrs_fill(struct sk_buff *skb,
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2 2/4] io-mapping: Specify mapping size for io_mapping_map_wc()
From: Chris Wilson @ 2016-04-19 12:02 UTC (permalink / raw)
To: intel-gfx
Cc: Tvrtko Ursulin, Daniel Vetter, Jani Nikula, David Airlie,
Yishai Hadas, Dan Williams, Ingo Molnar, Peter Zijlstra (Intel),
David Hildenbrand, Luis R. Rodriguez, dri-devel, netdev,
linux-rdma, linux-kernel
In-Reply-To: <1460978042-9953-2-git-send-email-chris@chris-wilson.co.uk>
On Mon, Apr 18, 2016 at 12:14:00PM +0100, Chris Wilson wrote:
> The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> can be used for remapping multiple pages. Extend the helper so that
> future callers can use it for larger ranges.
Adding Luis Rodriguez as he has been active in the area of ioremap_*().
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Yishai Hadas <yishaih@mellanox.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
> Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: netdev@vger.kernel.org
> Cc: linux-rdma@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/gpu/drm/i915/intel_overlay.c | 3 ++-
> drivers/net/ethernet/mellanox/mlx4/pd.c | 4 +++-
> include/linux/io-mapping.h | 10 +++++++---
> 3 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
> index 9746b9841c13..0d5a376878d3 100644
> --- a/drivers/gpu/drm/i915/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/intel_overlay.c
> @@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
> regs = (struct overlay_registers __iomem *)overlay->reg_bo->phys_handle->vaddr;
> else
> regs = io_mapping_map_wc(ggtt->mappable,
> - overlay->flip_addr);
> + overlay->flip_addr,
> + PAGE_SIZE);
>
> return regs;
> }
> diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c b/drivers/net/ethernet/mellanox/mlx4/pd.c
> index b3cc3ab63799..6fc156a3918d 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/pd.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
> @@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, int node)
> goto free_uar;
> }
>
> - uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << PAGE_SHIFT);
> + uar->bf_map = io_mapping_map_wc(priv->bf_mapping,
> + uar->index << PAGE_SHIFT,
> + PAGE_SIZE);
> if (!uar->bf_map) {
> err = -ENOMEM;
> goto unamp_uar;
> diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
> index e399029b68c5..645ad06b5d52 100644
> --- a/include/linux/io-mapping.h
> +++ b/include/linux/io-mapping.h
> @@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
> }
>
> static inline void __iomem *
> -io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
> +io_mapping_map_wc(struct io_mapping *mapping,
> + unsigned long offset,
> + unsigned long size)
> {
> resource_size_t phys_addr;
>
> BUG_ON(offset >= mapping->size);
> phys_addr = mapping->base + offset;
>
> - return ioremap_wc(phys_addr, PAGE_SIZE);
> + return ioremap_wc(phys_addr, size);
> }
>
> static inline void
> @@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
>
> /* Non-atomic map/unmap */
> static inline void __iomem *
> -io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
> +io_mapping_map_wc(struct io_mapping *mapping,
> + unsigned long offset,
> + unsigned long size)
> {
> return ((char __force __iomem *) mapping) + offset;
> }
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 4/7] tcp: Make use of MSG_EOR flag in tcp_sendmsg
From: Eric Dumazet @ 2016-04-19 12:19 UTC (permalink / raw)
To: David Laight
Cc: Martin KaFai Lau, netdev@vger.kernel.org, Eric Dumazet,
Neal Cardwell, Soheil Hassas Yeganeh, Willem de Bruijn,
Yuchung Cheng, Kernel Team
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F4A53D7@AcuExch.aculab.com>
On Tue, 2016-04-19 at 09:47 +0000, David Laight wrote:
> From: Eric Dumazet
> > Sent: 19 April 2016 00:18
> ...
> > MSG_EOR should not depend on SKBTX_ANY_TSTAMP
> >
> > Really, simply using send(fd, ..., len, MSG_EOR) should instruct TCP to
> > mark the cooked skb as a non candidate for future coalescing.
>
> Isn't that very similar to the inverse of MSG_MORE?
Yes. But not specifying MSG_MORE does not mean we want to force send
tiny packets. TCP is allowed to aggregate since it is a stream protocol,
since it reduces overhead.
> Or a send with Nagle disabled?
No. tcp_sendmsg() still can coalesce/aggregate data to the last packet
in write queue, if it was not yet sent, regardless of Nagle.
If you enable or disable Nagle, following command will only send first
packets with 724 bytes, but following ones will be very big.
netperf -t TCP_STREAM -- -m 724
05:16:53.707778 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [S], seq 711876787, win 29200, options [mss 1460,sackOK,TS val 320048472 ecr 0,nop,wscale 7], length 0
05:16:53.707908 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [S.], seq 2592965917, ack 711876788, win 28960, options [mss 1460,sackOK,TS val 23660532 ecr 320048472,nop,wscale 7], length 0
05:16:53.708001 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [.], ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 0
05:16:53.708045 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 1:725, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 724
05:16:53.708053 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 725, win 238, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708083 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 725:2173, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 1448
05:16:53.708097 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 2173, win 261, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708094 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 2173:3621, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 1448
05:16:53.708107 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 3621, win 283, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708132 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 3621:6517, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 2896
05:16:53.708133 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 6517:7965, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 1448
05:16:53.708148 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 6517, win 329, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708152 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 7965, win 351, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708157 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 7965:10861, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 2896
05:16:53.708165 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 10861, win 396, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708168 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 10861:12309, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 1448
05:16:53.708177 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 12309, win 419, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708220 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [.], seq 12309:16653, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 4344
05:16:53.708240 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 16653, win 487, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708335 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 16653:28237, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 11584
05:16:53.708378 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 28237, win 668, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708453 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 28237:42717, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 14480
05:16:53.708496 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 42717, win 894, options [nop,nop,TS val 23660532 ecr 320048473], length 0
05:16:53.708537 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [.], seq 42717:49957, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 7240
05:16:53.708585 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 49957:57197, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 7240
05:16:53.708641 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 49957, win 1007, options [nop,nop,TS val 23660533 ecr 320048473], length 0
05:16:53.708651 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 57197, win 1120, options [nop,nop,TS val 23660533 ecr 320048473], length 0
05:16:53.708806 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 57197:83261, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660532], length 26064
05:16:53.708836 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 83261, win 1528, options [nop,nop,TS val 23660533 ecr 320048473], length 0
05:16:53.708944 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [.], seq 83261:97741, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660533], length 14480
05:16:53.708967 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 97741, win 1754, options [nop,nop,TS val 23660533 ecr 320048473], length 0
05:16:53.709005 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [.], seq 97741:104981, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660533], length 7240
05:16:53.709036 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 104981:109325, ack 1, win 229, options [nop,nop,TS val 320048473 ecr 23660533], length 4344
05:16:53.709058 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 104981, win 1867, options [nop,nop,TS val 23660533 ecr 320048473], length 0
05:16:53.709065 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 109325, win 1924, options [nop,nop,TS val 23660533 ecr 320048473], length 0
05:16:53.709251 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 109325:135389, ack 1, win 229, options [nop,nop,TS val 320048474 ecr 23660533], length 26064
05:16:53.709332 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [.], seq 135389:141181, ack 1, win 229, options [nop,nop,TS val 320048474 ecr 23660533], length 5792
05:16:53.709423 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 135389, win 1924, options [nop,nop,TS val 23660533 ecr 320048474], length 0
05:16:53.709434 IP 10.246.7.151.42681 > 10.246.7.133.37427: Flags [.], ack 141181, win 1924, options [nop,nop,TS val 23660533 ecr 320048474], length 0
05:16:53.709730 IP 10.246.7.133.37427 > 10.246.7.151.42681: Flags [P.], seq 141181:191861, ack 1, win 229, options [nop,nop,TS val 320048474 ecr 23660533], length 50680
Using MSG_EOR on the send(fd, buffer, 724, MSG_EOR) would force TCP to
send tiny datagrams and not big GSO/TSO packets.
^ permalink raw reply
* Re: [PATCHv3 net-next] net: use jiffies_to_msecs to replace EXPIRES_IN_MS in inet/sctp_diag
From: Eric Dumazet @ 2016-04-19 12:25 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Vlad Yasevich,
daniel, davem, jsitnick
In-Reply-To: <87a0e83132ce64a3fe2266a5323fa6577a2e5c96.1461049801.git.lucien.xin@gmail.com>
On Tue, 2016-04-19 at 15:10 +0800, Xin Long wrote:
> EXPIRES_IN_MS macro comes from net/ipv4/inet_diag.c and dates
> back to before jiffies_to_msecs() has been introduced.
>
> Now we can remove it and use jiffies_to_msecs().
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
Ok. Note that you could have mentioned this was
Suggested-by: Jakub Sitnicki <jkbs@redhat.com>
Even coworkers deserve credits ;)
Acked-by: Eric Dumazet <edumazet@google.com>
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/4] io-mapping: Specify mapping size for io_mapping_map_wc()
From: Luis R. Rodriguez @ 2016-04-19 12:30 UTC (permalink / raw)
To: Chris Wilson, intel-gfx, Tvrtko Ursulin, Daniel Vetter,
Jani Nikula, David Airlie, Yishai Hadas, Dan Williams,
Ingo Molnar, Peter Zijlstra (Intel), David Hildenbrand,
Luis R. Rodriguez, dri-devel, netdev, linux-rdma, linux-kernel
In-Reply-To: <20160419120225.GF26039@nuc-i3427.alporthouse.com>
On Tue, Apr 19, 2016 at 01:02:25PM +0100, Chris Wilson wrote:
> On Mon, Apr 18, 2016 at 12:14:00PM +0100, Chris Wilson wrote:
> > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > can be used for remapping multiple pages. Extend the helper so that
> > future callers can use it for larger ranges.
>
> Adding Luis Rodriguez as he has been active in the area of ioremap_*().
Can someone bounce me a copy of the original e-mails? Can you also use
mcgrof@kernel.org ?
Luis
^ permalink raw reply
* [PATCH 1/3] e1000e: e1000e_cyclecounter_read(): incvalue is 32 bits, not 64
From: Denys Vlasenko @ 2016-04-19 12:34 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Denys Vlasenko, Jesse Brandeburg, Shannon Nelson, Carolyn Wyborny,
Don Skidmore, Bruce Allan, John Ronciak, Mitch Williams,
David S. Miller, LKML, netdev
"incvalue" variable holds a result of "er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK"
and used in "do_div(temp, incvalue)" as a divisor.
Thus, "u64 incvalue" declaration is probably a mistake.
Even though it seems to be a harmless one, let's fix it.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Shannon Nelson <shannon.nelson@intel.com>
CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
CC: Don Skidmore <donald.c.skidmore@intel.com>
CC: Bruce Allan <bruce.w.allan@intel.com>
CC: John Ronciak <john.ronciak@intel.com>
CC: Mitch Williams <mitch.a.williams@intel.com>
CC: David S. Miller <davem@davemloft.net>
CC: LKML <linux-kernel@vger.kernel.org>
CC: netdev@vger.kernel.org
---
drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 9b4ec13..967311b 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4300,7 +4300,8 @@ static cycle_t e1000e_cyclecounter_read(const struct cyclecounter *cc)
}
if ((hw->mac.type == e1000_82574) || (hw->mac.type == e1000_82583)) {
- u64 incvalue, time_delta, rem, temp;
+ u64 time_delta, rem, temp;
+ u32 incvalue;
int i;
/* errata for 82574/82583 possible bad bits read from SYSTIMH/L
--
1.8.1.4
^ permalink raw reply related
* [PATCH 2/3] e1000e: e1000e_cyclecounter_read(): fix er32(SYSTIML) overflow check
From: Denys Vlasenko @ 2016-04-19 12:34 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Denys Vlasenko, Jesse Brandeburg, Shannon Nelson, Carolyn Wyborny,
Don Skidmore, Bruce Allan, John Ronciak, Mitch Williams,
David S. Miller, LKML, netdev
In-Reply-To: <1461069286-31946-1-git-send-email-dvlasenk@redhat.com>
If two consecutive reads of the counter are the same, it is also not an overflow.
"systimel_1 < systimel_2" should be "systimel_1 <= systimel_2".
Before the patch, we could perform an *erroneous* correction:
Let's say that systimel_1 == systimel_2 == 0xffffffff.
"systimel_1 < systimel_2" is false, we think it's an overflow,
we read "systimeh = er32(SYSTIMH)" which meanwhile had incremented,
and use "(systimeh << 32) + systimel_2" value which is 2^32 too large.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Shannon Nelson <shannon.nelson@intel.com>
CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
CC: Don Skidmore <donald.c.skidmore@intel.com>
CC: Bruce Allan <bruce.w.allan@intel.com>
CC: John Ronciak <john.ronciak@intel.com>
CC: Mitch Williams <mitch.a.williams@intel.com>
CC: David S. Miller <davem@davemloft.net>
CC: LKML <linux-kernel@vger.kernel.org>
CC: netdev@vger.kernel.org
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 967311b..99d0e6e 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4287,7 +4287,7 @@ static cycle_t e1000e_cyclecounter_read(const struct cyclecounter *cc)
systimeh = er32(SYSTIMH);
systimel_2 = er32(SYSTIML);
/* Check for overflow. If there was no overflow, use the values */
- if (systimel_1 < systimel_2) {
+ if (systimel_1 <= systimel_2) {
systim = (cycle_t)systimel_1;
systim |= (cycle_t)systimeh << 32;
} else {
--
1.8.1.4
^ permalink raw reply related
* [PATCH 3/3] e1000e: e1000e_cyclecounter_read(): do overflow check only if needed
From: Denys Vlasenko @ 2016-04-19 12:34 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Denys Vlasenko, Jesse Brandeburg, Shannon Nelson, Carolyn Wyborny,
Don Skidmore, Bruce Allan, John Ronciak, Mitch Williams,
David S. Miller, LKML, netdev
In-Reply-To: <1461069286-31946-1-git-send-email-dvlasenk@redhat.com>
SYSTIMH:SYSTIML registers are incremented by 24-bit value TIMINCA[23..0]
er32(SYSTIML) are probably moderately expensive (they are pci bus reads).
Can we avoid one of them? Yes, we can.
If the SYSTIML value we see is smaller than 0xff000000, the overflow
into SYSTIMH would require at least two increments.
We do two reads, er32(SYSTIML) and er32(SYSTIMH), in this order.
Even if one increment happens between them, the overflow into SYSTIMH
is impossible, and we can avoid doing another er32(SYSTIML) read
and overflow check.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Shannon Nelson <shannon.nelson@intel.com>
CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
CC: Don Skidmore <donald.c.skidmore@intel.com>
CC: Bruce Allan <bruce.w.allan@intel.com>
CC: John Ronciak <john.ronciak@intel.com>
CC: Mitch Williams <mitch.a.williams@intel.com>
CC: David S. Miller <davem@davemloft.net>
CC: LKML <linux-kernel@vger.kernel.org>
CC: netdev@vger.kernel.org
---
drivers/net/ethernet/intel/e1000e/netdev.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 99d0e6e..6f17f89 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4275,7 +4275,7 @@ static cycle_t e1000e_cyclecounter_read(const struct cyclecounter *cc)
struct e1000_adapter *adapter = container_of(cc, struct e1000_adapter,
cc);
struct e1000_hw *hw = &adapter->hw;
- u32 systimel_1, systimel_2, systimeh;
+ u32 systimel, systimeh;
cycle_t systim, systim_next;
/* SYSTIMH latching upon SYSTIML read does not work well.
* This means that if SYSTIML overflows after we read it but before
@@ -4283,21 +4283,21 @@ static cycle_t e1000e_cyclecounter_read(const struct cyclecounter *cc)
* will experience a huge non linear increment in the systime value
* to fix that we test for overflow and if true, we re-read systime.
*/
- systimel_1 = er32(SYSTIML);
+ systimel = er32(SYSTIML);
systimeh = er32(SYSTIMH);
- systimel_2 = er32(SYSTIML);
- /* Check for overflow. If there was no overflow, use the values */
- if (systimel_1 <= systimel_2) {
- systim = (cycle_t)systimel_1;
- systim |= (cycle_t)systimeh << 32;
- } else {
- /* There was an overflow, read again SYSTIMH, and use
- * systimel_2
- */
- systimeh = er32(SYSTIMH);
- systim = (cycle_t)systimel_2;
- systim |= (cycle_t)systimeh << 32;
+ /* Is systimel is so large that overflow is possible? */
+ if (systimel >= (u32)0xffffffff - E1000_TIMINCA_INCVALUE_MASK) {
+ u32 systimel_2 = er32(SYSTIML);
+ if (systimel > systimel_2) {
+ /* There was an overflow, read again SYSTIMH, and use
+ * systimel_2
+ */
+ systimeh = er32(SYSTIMH);
+ systimel = systimel_2;
+ }
}
+ systim = (cycle_t)systimel;
+ systim |= (cycle_t)systimeh << 32;
if ((hw->mac.type == e1000_82574) || (hw->mac.type == e1000_82583)) {
u64 time_delta, rem, temp;
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH v2 2/4] io-mapping: Specify mapping size for io_mapping_map_wc()
From: Chris Wilson @ 2016-04-19 12:34 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: David Airlie, netdev, intel-gfx, linux-kernel, Ingo Molnar,
Peter Zijlstra (Intel), dri-devel, linux-rdma, Daniel Vetter,
Dan Williams, Yishai Hadas, David Hildenbrand
In-Reply-To: <20160419123028.GI1990@wotan.suse.de>
On Tue, Apr 19, 2016 at 02:30:28PM +0200, Luis R. Rodriguez wrote:
> On Tue, Apr 19, 2016 at 01:02:25PM +0100, Chris Wilson wrote:
> > On Mon, Apr 18, 2016 at 12:14:00PM +0100, Chris Wilson wrote:
> > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > > can be used for remapping multiple pages. Extend the helper so that
> > > future callers can use it for larger ranges.
> >
> > Adding Luis Rodriguez as he has been active in the area of ioremap_*().
>
> Can someone bounce me a copy of the original e-mails? Can you also use
> mcgrof@kernel.org ?
Hopefully done. Please ping me if they don't arrive, or have a look at
https://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=iomap
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH net 6/9] net/mlx5e: Use vport MTU rather than physical port MTU
From: Saeed Mahameed @ 2016-04-19 12:33 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Saeed Mahameed
In-Reply-To: <1461069222-27076-1-git-send-email-saeedm@mellanox.com>
Set and report vport MTU rather than physical MTU,
Driver will set both vport and physical port mtu and will
rely on the query of vport mtu.
SRIOV VFs have to report their MTU to their vport manager (PF),
and this will allow them to work with any MTU they need
without failing the request.
Also for some cases where the PF is not a port owner, PF can
work with MTU less than the physical port mtu if set physical
port mtu didn't take effect.
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 44 ++++++++++++++++----
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 40 +++++++++++++++++++
include/linux/mlx5/vport.h | 2 +
3 files changed, 77 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 93e4ef4..85773f8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -1404,24 +1404,50 @@ static int mlx5e_refresh_tirs_self_loopback_enable(struct mlx5e_priv *priv)
return 0;
}
-static int mlx5e_set_dev_port_mtu(struct net_device *netdev)
+static int mlx5e_set_mtu(struct mlx5e_priv *priv, u16 mtu)
{
- struct mlx5e_priv *priv = netdev_priv(netdev);
struct mlx5_core_dev *mdev = priv->mdev;
- u16 hw_mtu;
+ u16 hw_mtu = MLX5E_SW2HW_MTU(mtu);
int err;
- err = mlx5_set_port_mtu(mdev, MLX5E_SW2HW_MTU(netdev->mtu), 1);
+ err = mlx5_set_port_mtu(mdev, hw_mtu, 1);
if (err)
return err;
- mlx5_query_port_oper_mtu(mdev, &hw_mtu, 1);
+ /* Update vport context MTU */
+ mlx5_modify_nic_vport_mtu(mdev, hw_mtu);
+ return 0;
+}
+
+static void mlx5e_query_mtu(struct mlx5e_priv *priv, u16 *mtu)
+{
+ struct mlx5_core_dev *mdev = priv->mdev;
+ u16 hw_mtu = 0;
+ int err;
+
+ err = mlx5_query_nic_vport_mtu(mdev, &hw_mtu);
+ if (err || !hw_mtu) /* fallback to port oper mtu */
+ mlx5_query_port_oper_mtu(mdev, &hw_mtu, 1);
+
+ *mtu = MLX5E_HW2SW_MTU(hw_mtu);
+}
+
+static int mlx5e_set_dev_port_mtu(struct net_device *netdev)
+{
+ struct mlx5e_priv *priv = netdev_priv(netdev);
+ u16 mtu;
+ int err;
+
+ err = mlx5e_set_mtu(priv, netdev->mtu);
+ if (err)
+ return err;
- if (MLX5E_HW2SW_MTU(hw_mtu) != netdev->mtu)
- netdev_warn(netdev, "%s: Port MTU %d is different than netdev mtu %d\n",
- __func__, MLX5E_HW2SW_MTU(hw_mtu), netdev->mtu);
+ mlx5e_query_mtu(priv, &mtu);
+ if (mtu != netdev->mtu)
+ netdev_warn(netdev, "%s: VPort MTU %d is different than netdev mtu %d\n",
+ __func__, mtu, netdev->mtu);
- netdev->mtu = MLX5E_HW2SW_MTU(hw_mtu);
+ netdev->mtu = mtu;
return 0;
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index bd51840..b69dadc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -196,6 +196,46 @@ int mlx5_modify_nic_vport_mac_address(struct mlx5_core_dev *mdev,
}
EXPORT_SYMBOL_GPL(mlx5_modify_nic_vport_mac_address);
+int mlx5_query_nic_vport_mtu(struct mlx5_core_dev *mdev, u16 *mtu)
+{
+ int outlen = MLX5_ST_SZ_BYTES(query_nic_vport_context_out);
+ u32 *out;
+ int err;
+
+ out = mlx5_vzalloc(outlen);
+ if (!out)
+ return -ENOMEM;
+
+ err = mlx5_query_nic_vport_context(mdev, 0, out, outlen);
+ if (!err)
+ *mtu = MLX5_GET(query_nic_vport_context_out, out,
+ nic_vport_context.mtu);
+
+ kvfree(out);
+ return err;
+}
+EXPORT_SYMBOL_GPL(mlx5_query_nic_vport_mtu);
+
+int mlx5_modify_nic_vport_mtu(struct mlx5_core_dev *mdev, u16 mtu)
+{
+ int inlen = MLX5_ST_SZ_BYTES(modify_nic_vport_context_in);
+ void *in;
+ int err;
+
+ in = mlx5_vzalloc(inlen);
+ if (!in)
+ return -ENOMEM;
+
+ MLX5_SET(modify_nic_vport_context_in, in, field_select.mtu, 1);
+ MLX5_SET(modify_nic_vport_context_in, in, nic_vport_context.mtu, mtu);
+
+ err = mlx5_modify_nic_vport_context(mdev, in, inlen);
+
+ kvfree(in);
+ return err;
+}
+EXPORT_SYMBOL_GPL(mlx5_modify_nic_vport_mtu);
+
int mlx5_query_nic_vport_mac_list(struct mlx5_core_dev *dev,
u32 vport,
enum mlx5_list_type list_type,
diff --git a/include/linux/mlx5/vport.h b/include/linux/mlx5/vport.h
index bd93e63..301da4a 100644
--- a/include/linux/mlx5/vport.h
+++ b/include/linux/mlx5/vport.h
@@ -45,6 +45,8 @@ int mlx5_query_nic_vport_mac_address(struct mlx5_core_dev *mdev,
u16 vport, u8 *addr);
int mlx5_modify_nic_vport_mac_address(struct mlx5_core_dev *dev,
u16 vport, u8 *addr);
+int mlx5_query_nic_vport_mtu(struct mlx5_core_dev *mdev, u16 *mtu);
+int mlx5_modify_nic_vport_mtu(struct mlx5_core_dev *mdev, u16 mtu);
int mlx5_query_nic_vport_system_image_guid(struct mlx5_core_dev *mdev,
u64 *system_image_guid);
int mlx5_query_nic_vport_node_guid(struct mlx5_core_dev *mdev, u64 *node_guid);
--
1.7.1
^ permalink raw reply related
* [PATCH net 8/9] net/mlx5: Add pci shutdown callback
From: Saeed Mahameed @ 2016-04-19 12:33 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Majd Dibbiny,
Tariq Toukan, Haggai Abramovsky, Saeed Mahameed
In-Reply-To: <1461069222-27076-1-git-send-email-saeedm@mellanox.com>
From: Majd Dibbiny <majd@mellanox.com>
This patch introduces kexec support for mlx5.
When switching kernels, kexec() calls shutdown, which unloads
the driver and cleans its resources.
In addition, remove unregister netdev from shutdown flow. This will
allow a clean shutdown, even if some netdev clients did not release their
reference from this netdev. Releasing The HW resources only is enough as
the kernel is shutting down
Signed-off-by: Majd Dibbiny <majd@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Haggai Abramovsky <hagaya@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 15 +++++++++++-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 23 +++++++++++++++++---
include/linux/mlx5/driver.h | 7 +++--
3 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 85773f8..67d548b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -2633,7 +2633,16 @@ static void mlx5e_destroy_netdev(struct mlx5_core_dev *mdev, void *vpriv)
schedule_work(&priv->set_rx_mode_work);
mlx5e_disable_async_events(priv);
flush_scheduled_work();
- unregister_netdev(netdev);
+ if (test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, &mdev->intf_state)) {
+ netif_device_detach(netdev);
+ mutex_lock(&priv->state_lock);
+ if (test_bit(MLX5E_STATE_OPENED, &priv->state))
+ mlx5e_close_locked(netdev);
+ mutex_unlock(&priv->state_lock);
+ } else {
+ unregister_netdev(netdev);
+ }
+
mlx5e_tc_cleanup(priv);
mlx5e_vxlan_cleanup(priv);
mlx5e_destroy_flow_tables(priv);
@@ -2646,7 +2655,9 @@ static void mlx5e_destroy_netdev(struct mlx5_core_dev *mdev, void *vpriv)
mlx5_core_dealloc_transport_domain(priv->mdev, priv->tdn);
mlx5_core_dealloc_pd(priv->mdev, priv->pdn);
mlx5_unmap_free_uar(priv->mdev, &priv->cq_uar);
- free_netdev(netdev);
+
+ if (!test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, &mdev->intf_state))
+ free_netdev(netdev);
}
static void *mlx5e_get_netdev(void *vpriv)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index ddd352a..6892746 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -966,7 +966,7 @@ static int mlx5_load_one(struct mlx5_core_dev *dev, struct mlx5_priv *priv)
int err;
mutex_lock(&dev->intf_state_mutex);
- if (dev->interface_state == MLX5_INTERFACE_STATE_UP) {
+ if (test_bit(MLX5_INTERFACE_STATE_UP, &dev->intf_state)) {
dev_warn(&dev->pdev->dev, "%s: interface is up, NOP\n",
__func__);
goto out;
@@ -1133,7 +1133,8 @@ static int mlx5_load_one(struct mlx5_core_dev *dev, struct mlx5_priv *priv)
if (err)
pr_info("failed request module on %s\n", MLX5_IB_MOD);
- dev->interface_state = MLX5_INTERFACE_STATE_UP;
+ clear_bit(MLX5_INTERFACE_STATE_DOWN, &dev->intf_state);
+ set_bit(MLX5_INTERFACE_STATE_UP, &dev->intf_state);
out:
mutex_unlock(&dev->intf_state_mutex);
@@ -1207,7 +1208,7 @@ static int mlx5_unload_one(struct mlx5_core_dev *dev, struct mlx5_priv *priv)
}
mutex_lock(&dev->intf_state_mutex);
- if (dev->interface_state == MLX5_INTERFACE_STATE_DOWN) {
+ if (test_bit(MLX5_INTERFACE_STATE_DOWN, &dev->intf_state)) {
dev_warn(&dev->pdev->dev, "%s: interface is down, NOP\n",
__func__);
goto out;
@@ -1241,7 +1242,8 @@ static int mlx5_unload_one(struct mlx5_core_dev *dev, struct mlx5_priv *priv)
mlx5_cmd_cleanup(dev);
out:
- dev->interface_state = MLX5_INTERFACE_STATE_DOWN;
+ clear_bit(MLX5_INTERFACE_STATE_UP, &dev->intf_state);
+ set_bit(MLX5_INTERFACE_STATE_DOWN, &dev->intf_state);
mutex_unlock(&dev->intf_state_mutex);
return err;
}
@@ -1452,6 +1454,18 @@ static const struct pci_error_handlers mlx5_err_handler = {
.resume = mlx5_pci_resume
};
+static void shutdown(struct pci_dev *pdev)
+{
+ struct mlx5_core_dev *dev = pci_get_drvdata(pdev);
+ struct mlx5_priv *priv = &dev->priv;
+
+ dev_info(&pdev->dev, "Shutdown was called\n");
+ /* Notify mlx5 clients that the kernel is being shut down */
+ set_bit(MLX5_INTERFACE_STATE_SHUTDOWN, &dev->intf_state);
+ mlx5_unload_one(dev, priv);
+ mlx5_pci_disable_device(dev);
+}
+
static const struct pci_device_id mlx5_core_pci_table[] = {
{ PCI_VDEVICE(MELLANOX, 0x1011) }, /* Connect-IB */
{ PCI_VDEVICE(MELLANOX, 0x1012), MLX5_PCI_DEV_IS_VF}, /* Connect-IB VF */
@@ -1471,6 +1485,7 @@ static struct pci_driver mlx5_core_driver = {
.id_table = mlx5_core_pci_table,
.probe = init_one,
.remove = remove_one,
+ .shutdown = shutdown,
.err_handler = &mlx5_err_handler,
.sriov_configure = mlx5_core_sriov_configure,
};
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index dcd5ac8..369c837 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -519,8 +519,9 @@ enum mlx5_device_state {
};
enum mlx5_interface_state {
- MLX5_INTERFACE_STATE_DOWN,
- MLX5_INTERFACE_STATE_UP,
+ MLX5_INTERFACE_STATE_DOWN = BIT(0),
+ MLX5_INTERFACE_STATE_UP = BIT(1),
+ MLX5_INTERFACE_STATE_SHUTDOWN = BIT(2),
};
enum mlx5_pci_status {
@@ -544,7 +545,7 @@ struct mlx5_core_dev {
enum mlx5_device_state state;
/* sync interface state */
struct mutex intf_state_mutex;
- enum mlx5_interface_state interface_state;
+ unsigned long intf_state;
void (*event) (struct mlx5_core_dev *dev,
enum mlx5_dev_event event,
unsigned long param);
--
1.7.1
^ permalink raw reply related
* [PATCH net 0/9] mlx5 driver updates and fixes
From: Saeed Mahameed @ 2016-04-19 12:33 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Saeed Mahameed
Hi Dave,
This series has few bug fixes for mlx5 core and ethernet driver.
Eli fixed a wrong static local variable declaration in flow steering API.
Majd added the support of ConnectX-5 PF and VF and added the support
for kernel shutdown pci callback for more robust reboot procedures.
Maor fixed a soft lockup in flow steering.
Rana fixed a wrog speed define in mlx5 EN driver.
I also had the chance to introduce some bug fixes in mlx5 EN mtu
reporting and handling, and added the ability to reset link speed
to device's default.
For -stable:
net/mlx5_core: Fix soft lockup in steering error flow
net/mlx5e: Device's mtu field is u16 and not int
net/mlx5e: Fix minimum MTU
net/mlx5e: Use vport MTU rather than physical port MTU
Thanks,
Saeed
Eli Cohen (1):
net/mlx5_core: Remove static from local variable
Majd Dibbiny (2):
net/mlx5_core: Add ConnectX-5 to list of supported devices
net/mlx5: Add pci shutdown callback
Maor Gottlieb (1):
net/mlx5_core: Fix soft lockup in steering error flow
Rana Shahout (1):
net/mlx5e: Fix MLX5E_100BASE_T define
Saeed Mahameed (4):
net/mlx5e: Device's mtu field is u16 and not int
net/mlx5e: Fix minimum MTU
net/mlx5e: Use vport MTU rather than physical port MTU
net/mlx5e: Reset link modes upon setting speed to zero
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 26 ++++---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 72 +++++++++++++++----
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 48 +++++--------
drivers/net/ethernet/mellanox/mlx5/core/main.c | 25 ++++++-
drivers/net/ethernet/mellanox/mlx5/core/port.c | 10 ++--
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 40 +++++++++++
include/linux/mlx5/driver.h | 7 +-
include/linux/mlx5/port.h | 6 +-
include/linux/mlx5/vport.h | 2 +
10 files changed, 166 insertions(+), 72 deletions(-)
^ permalink raw reply
* [PATCH net 3/9] net/mlx5_core: Add ConnectX-5 to list of supported devices
From: Saeed Mahameed @ 2016-04-19 12:33 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Majd Dibbiny,
Saeed Mahameed
In-Reply-To: <1461069222-27076-1-git-send-email-saeedm@mellanox.com>
From: Majd Dibbiny <majd@mellanox.com>
Add the upcoming ConnectX-5 devices (PF and VF) to the list of
supported devices by the mlx5 driver.
Signed-off-by: Majd Dibbiny <majd@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 3f3b2fa..ddd352a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1459,6 +1459,8 @@ static const struct pci_device_id mlx5_core_pci_table[] = {
{ PCI_VDEVICE(MELLANOX, 0x1014), MLX5_PCI_DEV_IS_VF}, /* ConnectX-4 VF */
{ PCI_VDEVICE(MELLANOX, 0x1015) }, /* ConnectX-4LX */
{ PCI_VDEVICE(MELLANOX, 0x1016), MLX5_PCI_DEV_IS_VF}, /* ConnectX-4LX VF */
+ { PCI_VDEVICE(MELLANOX, 0x1017) }, /* ConnectX-5 */
+ { PCI_VDEVICE(MELLANOX, 0x1018), MLX5_PCI_DEV_IS_VF}, /* ConnectX-5 VF */
{ 0, }
};
--
1.7.1
^ permalink raw reply related
* [PATCH net 7/9] net/mlx5_core: Remove static from local variable
From: Saeed Mahameed @ 2016-04-19 12:33 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Eli Cohen,
Saeed Mahameed
In-Reply-To: <1461069222-27076-1-git-send-email-saeedm@mellanox.com>
From: Eli Cohen <eli@mellanox.com>
The static is not required and breaks re-entrancy if it will be required.
Fixes: 2530236303d9 ("net/mlx5_core: Flow steering tree initialization")
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index 3c7e3e5..89cce97 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -1276,7 +1276,7 @@ struct mlx5_flow_namespace *mlx5_get_flow_namespace(struct mlx5_core_dev *dev,
{
struct mlx5_flow_root_namespace *root_ns = dev->priv.root_ns;
int prio;
- static struct fs_prio *fs_prio;
+ struct fs_prio *fs_prio;
struct mlx5_flow_namespace *ns;
if (!root_ns)
--
1.7.1
^ permalink raw reply related
* [PATCH net 1/9] net/mlx5_core: Fix soft lockup in steering error flow
From: Saeed Mahameed @ 2016-04-19 12:33 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Maor Gottlieb,
Saeed Mahameed
In-Reply-To: <1461069222-27076-1-git-send-email-saeedm@mellanox.com>
From: Maor Gottlieb <maorg@mellanox.com>
In the error flow of adding flow rule to auto-grouped flow
table, we call to tree_remove_node.
tree_remove_node locks the node's parent, however the node's parent
is already locked by mlx5_add_flow_rule and this causes a deadlock.
After this patch, if we failed to add the flow rule, we unlock the
flow table before calling to tree_remove_node.
fixes: f0d22d187473 ('net/mlx5_core: Introduce flow steering autogrouped
flow table')
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Reported-by: Amir Vadai <amir@vadai.me>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 46 ++++++++-------------
1 files changed, 17 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index 5121be4..3c7e3e5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -1065,33 +1065,6 @@ unlock_fg:
return rule;
}
-static struct mlx5_flow_rule *add_rule_to_auto_fg(struct mlx5_flow_table *ft,
- u8 match_criteria_enable,
- u32 *match_criteria,
- u32 *match_value,
- u8 action,
- u32 flow_tag,
- struct mlx5_flow_destination *dest)
-{
- struct mlx5_flow_rule *rule;
- struct mlx5_flow_group *g;
-
- g = create_autogroup(ft, match_criteria_enable, match_criteria);
- if (IS_ERR(g))
- return (void *)g;
-
- rule = add_rule_fg(g, match_value,
- action, flow_tag, dest);
- if (IS_ERR(rule)) {
- /* Remove assumes refcount > 0 and autogroup creates a group
- * with a refcount = 0.
- */
- tree_get_node(&g->node);
- tree_remove_node(&g->node);
- }
- return rule;
-}
-
static struct mlx5_flow_rule *
_mlx5_add_flow_rule(struct mlx5_flow_table *ft,
u8 match_criteria_enable,
@@ -1119,8 +1092,23 @@ _mlx5_add_flow_rule(struct mlx5_flow_table *ft,
goto unlock;
}
- rule = add_rule_to_auto_fg(ft, match_criteria_enable, match_criteria,
- match_value, action, flow_tag, dest);
+ g = create_autogroup(ft, match_criteria_enable, match_criteria);
+ if (IS_ERR(g)) {
+ rule = (void *)g;
+ goto unlock;
+ }
+
+ rule = add_rule_fg(g, match_value,
+ action, flow_tag, dest);
+ if (IS_ERR(rule)) {
+ /* Remove assumes refcount > 0 and autogroup creates a group
+ * with a refcount = 0.
+ */
+ unlock_ref_node(&ft->node);
+ tree_get_node(&g->node);
+ tree_remove_node(&g->node);
+ return rule;
+ }
unlock:
unlock_ref_node(&ft->node);
return rule;
--
1.7.1
^ permalink raw reply related
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