* [patch net-next v2 01/12] fib: notifier: Add VIF add and delete event types
From: Jiri Pirko @ 2017-09-24 17:22 UTC (permalink / raw)
To: netdev; +Cc: davem, yotamg, idosch, mlxsw, nikolay, andrew
In-Reply-To: <20170924172212.10096-1-jiri@resnulli.us>
From: Yotam Gigi <yotamg@mellanox.com>
In order for an interface to forward packets according to the kernel
multicast routing table, it must be configured with a VIF index according
to the mroute user API. The VIF index is then used to refer to that
interface in the mroute user API, for example, to set the iif and oifs of
an MFC entry.
In order to allow drivers to be aware and offload multicast routes, they
have to be aware of the VIF add and delete notifications.
Due to the fact that a specific VIF can be deleted and re-added pointing to
another netdevice, and the MFC routes that point to it will forward the
matching packets to the new netdevice, a driver willing to offload MFC
cache entries must be aware of the VIF add and delete events in addition to
MFC routes notifications.
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
include/net/fib_notifier.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/fib_notifier.h b/include/net/fib_notifier.h
index 669b971..54cd6b8 100644
--- a/include/net/fib_notifier.h
+++ b/include/net/fib_notifier.h
@@ -20,6 +20,8 @@ enum fib_event_type {
FIB_EVENT_RULE_DEL,
FIB_EVENT_NH_ADD,
FIB_EVENT_NH_DEL,
+ FIB_EVENT_VIF_ADD,
+ FIB_EVENT_VIF_DEL,
};
struct fib_notifier_ops {
--
2.9.5
^ permalink raw reply related
* [patch net-next v2 00/12] mlxsw: Add support for offloading IPv4 multicast routes
From: Jiri Pirko @ 2017-09-24 17:22 UTC (permalink / raw)
To: netdev; +Cc: davem, yotamg, idosch, mlxsw, nikolay, andrew
From: Jiri Pirko <jiri@mellanox.com>
This patch-set introduces offloading of the kernel IPv4 multicast router
logic in the Spectrum driver.
The first patch makes the Spectrum driver ignore FIB notifications that are
not of address family IPv4 or IPv6. This is needed in order to prevent
crashes while the next patches introduce the RTNL_FAMILY_IPMR FIB
notifications.
Patches 2-5 update ipmr to use the FIB notification chain for both MFC and
VIF notifications, and patches 8-12 update the Spectrum driver to register
to these notifications and offload the routes.
Similarly to IPv4 and IPv6, any failure will trigger the abort mechanism
which is updated in this patch-set to eject multicast route tables too.
At this stage, the following limitations apply:
- A multicast MFC route will be offloaded by the driver if all the output
interfaces are Spectrum router interfaces (RIFs). In any other case
(which includes pimreg device, tunnel devices and management ports) the
route will be trapped to the CPU and the packets will be forwarded by
software.
- ipmr proxy routes are not supported and will trigger the abort
mechanism.
- The MFC TTL values are currently treated as boolean: if the value is
different than 255, the traffic is forwarded to the interface and if the
value is 255 it is not forwarded. Dropping packets based on their TTL isn't
currently supported.
To allow users to have visibility on which of the routes are offloaded and
which are not, patch 6 introduces a per-route offload indication similar to
IPv4 and IPv6 routes which is sent to the user via the RTNetlink interface.
The Spectrum driver multicast router offloading support, which is
introduced in patches 8 and 9, is divided into two parts:
- The hardware logic which abstracts the Spectrum hardware and provides a
simple API for the upper levels.
- The offloading logic which gets the MFC and VIF notifications from the
kernel and updates the hardware using the hardware logic part.
Finally, the last patch makes the Spectrum router logic not ignore the
multicast FIB notifications and call the corresponding functions in the
multicast router offloading logic.
---
v1->v2:
- Add comments for struct fields in mroute.h
- Take the mrt_lock while dumping VIFs in the fib_notifier dump callback
- Update the MFC lastuse field too
Yotam Gigi (12):
fib: notifier: Add VIF add and delete event types
ipmr: Add reference count to MFC entries
ipmr: Add FIB notification access functions
ipmr: Send FIB notifications on MFC and VIF entries
net: ipmr: Add MFC offload indication
net: mroute: Check if rule is a default rule
mlxsw: spectrum: Add the multicast routing offloading logic
mlxsw: spectrum: Add the multicast routing hardware logic
mlxsw: spectrum: router: Squash the default route table to main
mlxsw: spectrum_router: Add multicast routes notification handling
functionality
mlxsw: spectrum: Notify multicast router on RIF MTU changes
mlxsw: spectrum: router: Don't ignore IPMR notifications
drivers/net/ethernet/mellanox/mlxsw/Makefile | 3 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 +
drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c | 1014 ++++++++++++++++++++
drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.h | 133 +++
.../net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c | 828 ++++++++++++++++
.../net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.h | 43 +
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 205 +++-
include/linux/mroute.h | 45 +
include/net/fib_notifier.h | 2 +
include/net/netns/ipv4.h | 3 +
net/ipv4/ipmr.c | 211 +++-
11 files changed, 2478 insertions(+), 11 deletions(-)
create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c
create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.h
create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.c
create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr_tcam.h
--
2.9.5
^ permalink raw reply
* Re: [PATCH] mac80211: aead api to reduce redundancy
From: Xiang Gao @ 2017-09-24 17:21 UTC (permalink / raw)
To: Johannes Berg
Cc: Herbert Xu, David S. Miller, linux-crypto, linux-kernel,
linux-wireless, netdev
In-Reply-To: <1506265531.2909.5.camel@sipsolutions.net>
2017-09-24 11:05 GMT-04:00 Johannes Berg <johannes@sipsolutions.net>:
> On Sun, 2017-09-24 at 01:40 -0400, Xiang Gao wrote:
>> Currently, the aes_ccm.c and aes_gcm.c are almost line by line
>> copy of each other. This patch reduce code redundancy by moving
>> the code in these two files to crypto/aead_api.c to make it a
>> higher level aead api. The aes_ccm.c and aes_gcm.c are removed
>> and all the functions are now implemented in their headers using
>> the newly added aead api.
>>
> No objection from me, though I'd ask you to respin with the indentation
> fixed up a bit.
Hi Johannes,
Thank you for you time for the suggestion. I'm not sure if I correctly
understand you point.
Do you mean to put more characters each line in the description? Something like:
> Currently, the aes_ccm.c and aes_gcm.c are almost line by line copy of
> each other. This patch reduce code redundancy by moving the code in these
> two files to crypto/aead_api.c to make it a higher level aead api. The
> file aes_ccm.c and aes_gcm.c are removed and all the functions there are
> now implemented in their headers using the newly added aead api.
instead of
> Currently, the aes_ccm.c and aes_gcm.c are almost line by line
> copy of each other. This patch reduce code redundancy by moving
> the code in these two files to crypto/aead_api.c to make it a
> higher level aead api. The aes_ccm.c and aes_gcm.c are removed
> and all the functions are now implemented in their headers using
> the newly added aead api.
Xiang Gao
>
> johannes
^ permalink raw reply
* Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone
From: Tom Herbert @ 2017-09-24 17:18 UTC (permalink / raw)
To: Harald Welte
Cc: Tom Herbert, Andreas Schultz, David S. Miller,
Linux Kernel Network Developers, Pablo Neira Ayuso, Rohit Seth
In-Reply-To: <20170924162543.d7syskutxzgvbw23@nataraja>
> I'm not sure where a "vendor" is involved with the GTP patches so far. I
> think we have to draw a distinction between what you expect from
> professional, corporate "vendors" with a commercial interest in mind
> (such as supporting their hardware) and what you can expect from people
> doing things in their spare time, out of enthusiasm to finally bring
> some Free Software into the closed world of telecommunications.
>
If it makes you feel any better I am not getting paid for this work either :-)
> The Telecom world should have implemented something like a GTP kernel
> module a decade to 15 years ago. They could have saved significant
> investments in proprietary hardware by running open source GGSNs with an
> accelerated user plane in the kernel. Nobody seemed to have an interest
> in that, until today - as you can see from Pablo and me working on this
> in our spare time, whenever we have a couple of spare cycles next to
> many other projects. You can see from the osmo-gtp-kernel commit log it
> took years of being a ultra-low-priority on-and-off project to ever get
> to a point where we thought it was worth submitting it mainline.
> Andreas deserves the praise for finally pushing it ahead.
>
I completely agree, and your work is well appreciated! But I don't
believe it is to late to steer the ship away from proprietary
solutions. In fact, given the direction of the rest of the industry
direction, now is our best opportunity to try. That is a major reason
for these patches. We need to bring GTP into the limelight and get a
lot more people thinking about. This might even be the world's most
important tunneling protocol. If nothing else, a discussion like this
is good if it inspires others in the community to start to look at it.
Tom
^ permalink raw reply
* Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone
From: Harald Welte @ 2017-09-24 16:25 UTC (permalink / raw)
To: Tom Herbert
Cc: Andreas Schultz, Tom Herbert, David S. Miller,
Linux Kernel Network Developers, Pablo Neira Ayuso, Rohit Seth
In-Reply-To: <CAPDqMer0R+XoTzYpQoo7rUY3uVcsa6ffk1FHjkG=3xcuhnDgXg@mail.gmail.com>
Hi Tom,
On Sun, Sep 24, 2017 at 08:55:49AM -0700, Tom Herbert wrote:
> Do you believe that these patches are not at all on the right track,
> that they can't be built upon to get to a standards-compliant
> implementation, and that we are going to have to throw all of this and
> start from scratch to provide IPv6 support?
I believe I have pointed out where the problem areas are, several times
by now. I see no reason why things would have to be started from
scratch. However, the issues pointed out in the IPv6 support patch[es]
have to be resolved *before* any merge to mainline.
I don't mind merging "incomplete" code that doesn't cover all parts of a
spec but provides basic interoperability. I also am not arguing that
code must be bug-free at the time it is merged (which is impossible
anyway). But I am arguing that we cannot merge something that is
a wrong implementation as per the spec, and hence it must be brought
in-line with the spec before it can be merged.
> > There's no use in merging an IPv6 support patch if already by code
> > review it can be shown that it's impossible to create a spec-compliant
> > implementation using that patch. To me, that would be "merging IPv6
> > support so we can check off a box on a management form or marketing
> > sheet", but not for any practical value.
>
> To be clear, these patches are not done because to be a bullet point
> on a marketing sheet.
Great.
> IPv6 is becoming _the_ Internet protocol.
I'm all aware of that, and I've been a very early adopter, since the
1990ies with 6bone.
My argument is not against IPv6 support. My argument is against merging
something that introdues IPv6 in a way that's not in-line with the GTP
protocol specifications, as such a way is of no use to anyone (except
marketing sheets).
> We should be far past the days of vendors only providing IPv4 in the
> kernel support because "that's what our customers use" and they'll get
> to IPv6 support at their leisure.
I'm not sure where a "vendor" is involved with the GTP patches so far. I
think we have to draw a distinction between what you expect from
professional, corporate "vendors" with a commercial interest in mind
(such as supporting their hardware) and what you can expect from people
doing things in their spare time, out of enthusiasm to finally bring
some Free Software into the closed world of telecommunications.
The Telecom world should have implemented something like a GTP kernel
module a decade to 15 years ago. They could have saved significant
investments in proprietary hardware by running open source GGSNs with an
accelerated user plane in the kernel. Nobody seemed to have an interest
in that, until today - as you can see from Pablo and me working on this
in our spare time, whenever we have a couple of spare cycles next to
many other projects. You can see from the osmo-gtp-kernel commit log it
took years of being a ultra-low-priority on-and-off project to ever get
to a point where we thought it was worth submitting it mainline.
Andreas deserves the praise for finally pushing it ahead.
I'm looking forward to reviewing the next version of the patch series.
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone
From: Tom Herbert @ 2017-09-24 15:55 UTC (permalink / raw)
To: Harald Welte
Cc: Andreas Schultz, Tom Herbert, David S. Miller,
Linux Kernel Network Developers, Pablo Neira Ayuso, Rohit Seth
In-Reply-To: <20170924021626.b37zlwsomlibtnfs@nataraja>
> It's not about "not liking". I'm very happy about contributions,
> including (of course) yours. It's about making sure that code we merge
> into the kernel GTP driver will actually be usable to create a
> standards-compliant GTP application or not.
>
Harald,
Do you believe that these patches are not at all on the right track,
that they can't be built upon to get to a standards-compliant
implementation, and that we are going to have to throw all of this and
start from scratch to provide IPv6 support?
> There's no use in merging an IPv6 support patch if already by code
> review it can be shown that it's impossible to create a spec-compliant
> implementation using that patch. To me, that would be "merging IPv6
> support so we can check off a box on a management form or marketing
> sheet", but not for any practical value.
>
To be clear, these patches are not done because to be a bullet point
on a marketing sheet. IPv6 is becoming _the_ Internet protocol. It
continues to exhibit exponential growth (~20% of Internet, per Google
stats), I believe least two of the largest datacenter operators are
running everything over IPv6, and there are already proposals to start
official deprecation of IPv4. In the mobile space IPv6 is going to be
a critical enabler of IoT and security in technologies like 5G. If we
want Linux to be at the forefront of the next technology wave then we
need to focus on IPv6 now! We should be far past the days of vendors
only providing IPv4 in the kernel support because "that's what our
customers use" and they'll get to IPv6 support at their leisure. IMO,
davem has every right to unilaterally NAK patches that only support
IPv4 or only test IPv4 with not even a path or timeline for IPv6
support.
Thanks,
Tom
^ permalink raw reply
* Re: [RFC] endianness issues in drivers/net/ethernet/qlogic/qed
From: Al Viro @ 2017-09-24 15:30 UTC (permalink / raw)
To: Tayar, Tomer; +Cc: netdev@vger.kernel.org, Elior, Ariel, David Miller
In-Reply-To: <BN3PR0701MB15918FECAEB8503920850A7580650@BN3PR0701MB1591.namprd07.prod.outlook.com>
On Sun, Sep 24, 2017 at 02:34:19PM +0000, Tayar, Tomer wrote:
>
> > "qed: Utilize FW 8.10.3.0" has attempted some endianness annotations
> > in that driver; unfortunately, either annotations are BS or the driver is genuinely
> > broken on big-endian hosts.
> [...]
> > Is that driver intended to be used on big-endian hosts at all?
>
> Thanks for taking the time to review our driver and pointing out these mistakes.
> Support for BE machines is planned to be added but currently it is not available.
> However, the structures which are used to abstract the HW carry endianity annotations.
> Obviously, there are some misses and some annotations were added when not required.
> We will prepare a patch that fixes the issues you pointed out and similar ones.
OK... sparse is pretty good at spotting the problems; if you have any questions - just
ask. A bit of random braindump concerning that kind of work:
* bitfields and fixed-endian data do not mix. It's much better to have just
__le32 (or __le64, etc.) in the structure and use GET_FIELD/SET_FIELD or similar for
accesses. Another safe technics is something like
if ((foo->bar & cpu_to_le32(BAR_MASK)) == cpu_to_le32(BAR_THIS << BAR_SHIFT))
instead of
if (get_bar(foo) == BAR_THIS))
since that keeps shift and endianness conversion on the constant size. The same goes
for
if ((foo->bar ^ baz->bar) & cpu_to_le32(BAR_MASK))
instead of
if (get_bar(foo) != get_bar(baz))
If would be nice if compiler had recognized that kind of stuff and transformed the
latter into the former on its own, but...
* swab... is a Bloody Bad Idea(tm) in almost all situations. Keeping track of
whether given data is little-endian or host-endian is much easier than keeping track of
how many times have we flipped it.
* don't mix little-endian and host-endian in the same variable. See the previous
point for the reasons - static typing is much safer and easier to reason about. Code
doing
n = cpu_to_le32(n);
is asking for trouble. For local variables it's not even an optimization - compiler
is generally pretty good at spotting two local variables that are never live at the
same point and reusing memory. And for anything non-local you are introducing a hidden
piece of state - "is that field in this structure little-endian or host-endian at the
moment?", making it very easy to screw up a few months down the road. Brittle and
hell to debug...
* one very common source of noise is cpu_to_le32() when le32_to_cpu() was
intended. Sure, they do the same transformation on anything even remotely plausible
(something like V0 V2 V3 V1 is not a byte order likely to happen on any hardware),
but the choice documents what kind of values do you have before and after the
conversion. Both the human readers and automated typechecking (sparse) have much
easier life if those are accurate. Again, see the point re keeping track of the
number of flips vs. keeping track of what's host-endian and what's little-endian.
The latter is local, the former takes reasoning about control flow.
* for situations like "use this le32 value as search key in binary tree",
where you are really OK with having differently-shaped trees on l-e and b-e hosts,
use something like
if ((__force __u32) key > node->key)
preferably with a comment explaining why treating this value that way is OK.
^ permalink raw reply
* [PATCH] net/tls: move version check after second userspace fetch
From: Meng Xu @ 2017-09-24 15:14 UTC (permalink / raw)
To: ilyal, aviadye, davejwatson, davem, netdev, linux-kernel
Cc: meng.xu, sanidhya, taesoo, Meng Xu
Even the userspace buffer optval passed the version check
(i.e., tmp_crypto_info.version == TLS_1_2_VERSION) after the first fetch,
it can still be changed before the second copy_from_user() and hence,
a version different than TLS_1_2_VERSION may be copied into crypto_info.
This patch moves the version check after the second userspace fetch.
Signed-off-by: Meng Xu <mengxu.gatech@gmail.com>
---
net/tls/tls_main.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 60aff60..d4a7bc6 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -354,12 +354,6 @@ static int do_tls_setsockopt_tx(struct sock *sk, char __user *optval,
goto out;
}
- /* check version */
- if (tmp_crypto_info.version != TLS_1_2_VERSION) {
- rc = -ENOTSUPP;
- goto out;
- }
-
/* get user crypto info */
crypto_info = &ctx->crypto_send;
@@ -382,6 +376,12 @@ static int do_tls_setsockopt_tx(struct sock *sk, char __user *optval,
rc = -EFAULT;
goto err_crypto_info;
}
+
+ /* check version */
+ if (crypto_info->version != TLS_1_2_VERSION) {
+ rc = -ENOTSUPP;
+ goto err_crypto_info;
+ }
break;
}
default:
--
2.7.4
^ permalink raw reply related
* [PATCH] isdn/eicon: do integrity check on cmd->adapter == a->controller early
From: Meng Xu @ 2017-09-24 15:14 UTC (permalink / raw)
To: mac, isdn, netdev, linux-kernel; +Cc: meng.xu, sanidhya, taesoo, Meng Xu
In my understanding, the reason to have the check on
if (cmd->adapter != a->controller) {report error} is to prevent the case
where after xdi_copy_from_user() in diva_xdi_write(), data->adapter
is changed from what is previously fetched in diva_xdi_open_adapter(),
and hence, leading to using a wrong adapter to do interface.cmd_proc().
Although respective checks are in place in the three implementations of
cmd_proc(), i.e., diva_4bri_cmd_card_proc(), diva_bri_cmd_card_proc(),
and diva_pri_cmd_card_proc(), in my opinion, a better way might be doing
this integrity right after the xdi_copy_from_user() in diva_xdi_write(),
which is what this patch is for.
Signed-off-by: Meng Xu <mengxu.gatech@gmail.com>
---
drivers/isdn/hardware/eicon/diva.c | 10 +++++++++-
drivers/isdn/hardware/eicon/os_4bri.c | 6 ------
drivers/isdn/hardware/eicon/os_bri.c | 6 ------
drivers/isdn/hardware/eicon/os_pri.c | 6 ------
4 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/isdn/hardware/eicon/diva.c b/drivers/isdn/hardware/eicon/diva.c
index d91dd58..8ebd3c7 100644
--- a/drivers/isdn/hardware/eicon/diva.c
+++ b/drivers/isdn/hardware/eicon/diva.c
@@ -460,7 +460,15 @@ diva_xdi_write(void *adapter, void *os_handle, const void __user *src,
length = (*cp_fn) (os_handle, data, src, length);
if (length > 0) {
- if ((*(a->interface.cmd_proc))
+ /* do the integrity check early */
+ if(((diva_xdi_um_cfg_cmd_t *)data)->adapter != a->controller){
+ DBG_ERR(("A: A(%d) write, invalid controller=%d != %d",
+ ((diva_xdi_um_cfg_cmd_t *)data)->adapter, a->controller));
+
+ length = -1;
+ }
+
+ else if ((*(a->interface.cmd_proc))
(a, (diva_xdi_um_cfg_cmd_t *) data, length)) {
length = -3;
}
diff --git a/drivers/isdn/hardware/eicon/os_4bri.c b/drivers/isdn/hardware/eicon/os_4bri.c
index 1891246..adbd852 100644
--- a/drivers/isdn/hardware/eicon/os_4bri.c
+++ b/drivers/isdn/hardware/eicon/os_4bri.c
@@ -629,12 +629,6 @@ diva_4bri_cmd_card_proc(struct _diva_os_xdi_adapter *a,
{
int ret = -1;
- if (cmd->adapter != a->controller) {
- DBG_ERR(("A: 4bri_cmd, invalid controller=%d != %d",
- cmd->adapter, a->controller))
- return (-1);
- }
-
switch (cmd->command) {
case DIVA_XDI_UM_CMD_GET_CARD_ORDINAL:
a->xdi_mbox.data_length = sizeof(dword);
diff --git a/drivers/isdn/hardware/eicon/os_bri.c b/drivers/isdn/hardware/eicon/os_bri.c
index 20f2653..e3d398f 100644
--- a/drivers/isdn/hardware/eicon/os_bri.c
+++ b/drivers/isdn/hardware/eicon/os_bri.c
@@ -398,12 +398,6 @@ diva_bri_cmd_card_proc(struct _diva_os_xdi_adapter *a,
{
int ret = -1;
- if (cmd->adapter != a->controller) {
- DBG_ERR(("A: pri_cmd, invalid controller=%d != %d",
- cmd->adapter, a->controller))
- return (-1);
- }
-
switch (cmd->command) {
case DIVA_XDI_UM_CMD_GET_CARD_ORDINAL:
a->xdi_mbox.data_length = sizeof(dword);
diff --git a/drivers/isdn/hardware/eicon/os_pri.c b/drivers/isdn/hardware/eicon/os_pri.c
index da4957a..93443aa 100644
--- a/drivers/isdn/hardware/eicon/os_pri.c
+++ b/drivers/isdn/hardware/eicon/os_pri.c
@@ -604,12 +604,6 @@ diva_pri_cmd_card_proc(struct _diva_os_xdi_adapter *a,
{
int ret = -1;
- if (cmd->adapter != a->controller) {
- DBG_ERR(("A: pri_cmd, invalid controller=%d != %d",
- cmd->adapter, a->controller))
- return (-1);
- }
-
switch (cmd->command) {
case DIVA_XDI_UM_CMD_GET_CARD_ORDINAL:
a->xdi_mbox.data_length = sizeof(dword);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] mac80211: aead api to reduce redundancy
From: Johannes Berg @ 2017-09-24 15:05 UTC (permalink / raw)
To: Xiang Gao, herbert, davem, linux-crypto, linux-kernel,
linux-wireless, netdev
In-Reply-To: <20170924054015.8958-1-qasdfgtyuiop@gmail.com>
On Sun, 2017-09-24 at 01:40 -0400, Xiang Gao wrote:
> Currently, the aes_ccm.c and aes_gcm.c are almost line by line
> copy of each other. This patch reduce code redundancy by moving
> the code in these two files to crypto/aead_api.c to make it a
> higher level aead api. The aes_ccm.c and aes_gcm.c are removed
> and all the functions are now implemented in their headers using
> the newly added aead api.
>
No objection from me, though I'd ask you to respin with the indentation
fixed up a bit.
johannes
^ permalink raw reply
* RE: [RFC] endianness issues in drivers/net/ethernet/qlogic/qed
From: Tayar, Tomer @ 2017-09-24 14:34 UTC (permalink / raw)
To: Al Viro, netdev@vger.kernel.org; +Cc: Elior, Ariel, David Miller
In-Reply-To: <20170918174940.GB32076@ZenIV.linux.org.uk>
> "qed: Utilize FW 8.10.3.0" has attempted some endianness annotations
> in that driver; unfortunately, either annotations are BS or the driver is genuinely
> broken on big-endian hosts.
[...]
> Is that driver intended to be used on big-endian hosts at all?
Thanks for taking the time to review our driver and pointing out these mistakes.
Support for BE machines is planned to be added but currently it is not available.
However, the structures which are used to abstract the HW carry endianity annotations.
Obviously, there are some misses and some annotations were added when not required.
We will prepare a patch that fixes the issues you pointed out and similar ones.
^ permalink raw reply
* Re: [RESEND] Re: usb/net/p54: trying to register non-static key in p54_unregister_leds
From: Johannes Berg @ 2017-09-24 14:13 UTC (permalink / raw)
To: Christian Lamparter, Andrey Konovalov
Cc: Kalle Valo, linux-wireless, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, syzkaller, Stephen Boyd, Tejun Heo, Yong Zhang
In-Reply-To: <2589427.Vd4nrgaY4N@debian64>
On Sat, 2017-09-23 at 21:37 +0200, Christian Lamparter wrote:
> But this also begs the question: Is this really working then?
> From what I can tell, if CONFIG_LOCKDEP is not set then there's no
> BUG no WARN, no other splat or any other odd system behaviour. Does
> [cancel | flush]_[delayed_]work[_sync] really "just work" by
> *accident*, as long the delayed_work | work_struct is zeroed out?
It looks like it does, but I'm not sure it's not more or less by
accident. Look at get_work_pool() for example, it might actually return
non-NULL in this case, and then in start_flush_work() you'll probably
fall into one of the few "already_gone" cases.
> And should it work in the future as well?
I guess it's not really guaranteed, the API doesn't state anything to
that effect. Not that I'm looking forward to a new workqueue rewrite ;)
johannes
^ permalink raw reply
* Have a successfully day!
From: Dr Paul Benk @ 2017-09-24 14:08 UTC (permalink / raw)
Greetings!
I have a proposal for you, this however is not mandatory nor will I in
any manner compel you to honor against your will. I am Dr.Paul Benk a
former executive director with Arab Tunisian Bank here in Tunis; I
retired 1 year 7 months ago after putting in 28 years of meticulous
service. During my days with Arab Tunisian Bank, I was the personal
account officer and one of the financial advisers to Zine Al-Abidine
Ben Ali the past Tunisian President in self exile at Saudi Arabia.
During his trying period, he instructed me to move all his investment
in my care which consists of US$115M and 767KG of gold out of the Gulf
States for safe keeping; and that I successfully did by moving US$50
Million to Madrid Spain, US$50 Million to Dubai United Arab Emirate,
US$15 Million to Burkina Faso and the 767KG of gold to Burkina Faso in
West Africa as an anonymous deposits, so that the funds will in no way
be traced to him. He has instructed me to find an investor who would
stand as the anonymous depositor of the fund and gold; and claim it
for further investment.
Consequent upon the above, my proposal is that I would like you as a
foreigner to stand in as the anonymous depositor of this fund and gold
that I have successfully moved outside the country and provide an
account overseas where this said fund will be transferred into. It is
a careful network and my voluntary retirement from the Arab Tunisian
Bank is to ensure a hitch-free operation as all modalities for you to
stand as beneficiary and owner of the deposits has been perfected by
me. Mr. Zine al-Abidine Ben Ali will be offering you 20% of the total
investment if you can be the investor and claim this deposits in Spain
and Burkina Faso as the anonymous depositor.
Now my questions are:-
1. Can you handle this transaction?
2. Can I give you this trust?
Consider this and get back to me as soon as possible on my private
email Only here: paulbenkbi@gmail.com, so that I can give you more
details regarding this transaction. Finally, it is my humble request
that the information as contained herein be accorded the necessary
attention, urgency as well as the secrecy it deserves.
I expect your urgent response if you can handle this project.
Respectfully yours,
From:Dr.Paul Benk.
Email: paulbenkbi@gmail.com
------------------------------------------------------------------------------
------------------------------------------------------------------------------
^ permalink raw reply
* [PATCH] net: bcm63xx_enet: Use setup_timer and mod_timer
From: Himanshu Jha @ 2017-09-24 12:11 UTC (permalink / raw)
To: f.fainelli
Cc: bcm-kernel-feedback-list, davem, arnd, yamada.masahiro, netdev,
linux-arm-kernel, linux-kernel, Himanshu Jha
Use setup_timer and mod_timer API instead of structure assignments.
This is done using Coccinelle and semantic patch used
for this as follows:
@@
expression x,y,z,a,b;
@@
-init_timer (&x);
+setup_timer (&x, y, z);
+mod_timer (&a, b);
-x.function = y;
-x.data = z;
-x.expires = b;
-add_timer(&a);
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index f8bbbbf..c6221f0 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -2331,11 +2331,8 @@ static int bcm_enetsw_open(struct net_device *dev)
}
/* start phy polling timer */
- init_timer(&priv->swphy_poll);
- priv->swphy_poll.function = swphy_poll_timer;
- priv->swphy_poll.data = (unsigned long)priv;
- priv->swphy_poll.expires = jiffies;
- add_timer(&priv->swphy_poll);
+ setup_timer(&priv->swphy_poll, swphy_poll_timer, (unsigned long)priv);
+ mod_timer(&priv->swphy_poll, jiffies);
return 0;
out:
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 10/10] net: hns3: Add mqprio support when interacting with network stack
From: Jiri Pirko @ 2017-09-24 11:37 UTC (permalink / raw)
To: Yunsheng Lin
Cc: davem@davemloft.net, huangdaode, xuwei (O), Liguozhu (Kenneth),
Zhuangyuzeng (Yisen), Gabriele Paoloni, John Garry, Linuxarm,
Salil Mehta, lipeng (Y), netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <fdd8d8af-6d74-143a-adfa-502bd94a90d9@huawei.com>
Sat, Sep 23, 2017 at 02:47:20AM CEST, linyunsheng@huawei.com wrote:
>Hi, Jiri
>
>On 2017/9/23 0:03, Jiri Pirko wrote:
>> Fri, Sep 22, 2017 at 04:11:51PM CEST, linyunsheng@huawei.com wrote:
>>> Hi, Jiri
>>>
>>>>> - if (!tc) {
>>>>> + if (if_running) {
>>>>> + (void)hns3_nic_net_stop(netdev);
>>>>> + msleep(100);
>>>>> + }
>>>>> +
>>>>> + ret = (kinfo->dcb_ops && kinfo->dcb_ops->>setup_tc) ?
>>>>> + kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : ->EOPNOTSUPP;
>>>
>>>> This is most odd. Why do you call dcb_ops from >ndo_setup_tc callback?
>>>> Why are you mixing this together? prio->tc mapping >can be done
>>>> directly in dcbnl
>>>
>>> Here is what we do in dcb_ops->setup_tc:
>>> Firstly, if current tc num is different from the tc num
>>> that user provide, then we setup the queues for each
>>> tc.
>>>
>>> Secondly, we tell hardware the pri to tc mapping that
>>> the stack is using. In rx direction, our hardware need
>>> that mapping to put different packet into different tc'
>>> queues according to the priority of the packet, then
>>> rss decides which specific queue in the tc should the
>>> packet goto.
>>>
>>> By mixing, I suppose you meant why we need the
>>> pri to tc infomation?
>>
>> by mixing, I mean what I wrote. You are calling dcb_ops callback from
>> ndo_setup_tc callback. So you are mixing DCBNL subsystem and TC
>> subsystem. Why? Why do you need sch_mqprio? Why DCBNL is not enough for
>> all?
>
>When using lldptool, dcbnl is involved.
>
>But when using tc qdisc, dcbbl is not involved, below is the a few key
>call graph in the kernel when tc qdisc cmd is executed.
>
>cmd:
>tc qdisc add dev eth0 root handle 1:0 mqprio num_tc 4 map 1 2 3 3 1 3 1 1 hw 1
>
>call graph:
>rtnetlink_rcv_msg -> tc_modify_qdisc -> qdisc_create -> mqprio_init ->
>hns3_nic_setup_tc
>
>When hns3_nic_setup_tc is called, we need to know how many tc num and
>prio_tc mapping from the tc_mqprio_qopt which is provided in the paramter
>in the ndo_setup_tc function, and dcb_ops is the our hardware specific
>method to setup the tc related parameter to the hardware, so this is why
>we call dcb_ops callback in ndo_setup_tc callback.
>
>I hope this will answer your question, thanks for your time.
Okay. I understand that you have a usecase for mqprio mapping offload
without lldptool being involved. Ok. I believe it is wrong to call dcb_ops
from tc callback. You should have a generic layer inside the driver and
call it from both dcb_ops and tc callbacks.
Also, what happens If I run lldptool concurrently with mqprio? Who wins
and is going to configure the mapping?
>
>>
>>
>>
>>> I hope I did not misunderstand your question, thanks
>>> for your time reviewing.
>>
>> .
>>
>
^ permalink raw reply
* Re: [PATCH v2 net-next 3/4] qed: Fix maximum number of CQs for iWARP
From: Leon Romanovsky @ 2017-09-24 10:35 UTC (permalink / raw)
To: Michal Kalderon
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
dledford-H+wXaHxf7aLQT0dZR+AlfA, Ariel Elior
In-Reply-To: <1506244185-2129-4-git-send-email-Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Sun, Sep 24, 2017 at 12:09:44PM +0300, Michal Kalderon wrote:
> The maximum number of CQs supported is bound to the number
> of connections supported, which differs between RoCE and iWARP.
>
> This fixes a crash that occurred in iWARP when running 1000 sessions
> using perftest.
>
> Fixes: 67b40dccc45 ("qed: Implement iWARP initialization, teardown and qp operations")
>
> Signed-off-by: Michal Kalderon <Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Ariel Elior <Ariel.Elior-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> ---
> drivers/net/ethernet/qlogic/qed/qed_rdma.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
Thanks,
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2 net-next 2/4] qed: Add iWARP out of order support
From: Michal Kalderon @ 2017-09-24 9:09 UTC (permalink / raw)
To: davem, netdev, leon; +Cc: linux-rdma, dledford, Michal Kalderon, Ariel Elior
In-Reply-To: <1506244185-2129-1-git-send-email-Michal.Kalderon@cavium.com>
iWARP requires OOO support which is already provided by the ll2
interface (until now was used only for iSCSI offload).
The changes mostly include opening a ll2 dedicated connection for
OOO and notifiying the FW about the handle id.
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
Signed-off-by: Ariel Elior <Ariel.Elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 44 +++++++++++++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_iwarp.h | 11 +++++++-
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 7 +++--
3 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index 9d989c9..568e985 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -41,6 +41,7 @@
#include "qed_rdma.h"
#include "qed_reg_addr.h"
#include "qed_sp.h"
+#include "qed_ooo.h"
#define QED_IWARP_ORD_DEFAULT 32
#define QED_IWARP_IRD_DEFAULT 32
@@ -119,6 +120,13 @@ static void qed_iwarp_cid_cleaned(struct qed_hwfn *p_hwfn, u32 cid)
spin_unlock_bh(&p_hwfn->p_rdma_info->lock);
}
+void qed_iwarp_init_fw_ramrod(struct qed_hwfn *p_hwfn,
+ struct iwarp_init_func_params *p_ramrod)
+{
+ p_ramrod->ll2_ooo_q_index = RESC_START(p_hwfn, QED_LL2_QUEUE) +
+ p_hwfn->p_rdma_info->iwarp.ll2_ooo_handle;
+}
+
static int qed_iwarp_alloc_cid(struct qed_hwfn *p_hwfn, u32 *cid)
{
int rc;
@@ -1876,6 +1884,16 @@ static int qed_iwarp_ll2_stop(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
iwarp_info->ll2_syn_handle = QED_IWARP_HANDLE_INVAL;
}
+ if (iwarp_info->ll2_ooo_handle != QED_IWARP_HANDLE_INVAL) {
+ rc = qed_ll2_terminate_connection(p_hwfn,
+ iwarp_info->ll2_ooo_handle);
+ if (rc)
+ DP_INFO(p_hwfn, "Failed to terminate ooo connection\n");
+
+ qed_ll2_release_connection(p_hwfn, iwarp_info->ll2_ooo_handle);
+ iwarp_info->ll2_ooo_handle = QED_IWARP_HANDLE_INVAL;
+ }
+
qed_llh_remove_mac_filter(p_hwfn,
p_ptt, p_hwfn->p_rdma_info->iwarp.mac_addr);
return rc;
@@ -1927,10 +1945,12 @@ static int qed_iwarp_ll2_stop(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
struct qed_iwarp_info *iwarp_info;
struct qed_ll2_acquire_data data;
struct qed_ll2_cbs cbs;
+ u16 n_ooo_bufs;
int rc = 0;
iwarp_info = &p_hwfn->p_rdma_info->iwarp;
iwarp_info->ll2_syn_handle = QED_IWARP_HANDLE_INVAL;
+ iwarp_info->ll2_ooo_handle = QED_IWARP_HANDLE_INVAL;
iwarp_info->max_mtu = params->max_mtu;
@@ -1978,6 +1998,29 @@ static int qed_iwarp_ll2_stop(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
if (rc)
goto err;
+ /* Start OOO connection */
+ data.input.conn_type = QED_LL2_TYPE_OOO;
+ data.input.mtu = params->max_mtu;
+
+ n_ooo_bufs = (QED_IWARP_MAX_OOO * QED_IWARP_RCV_WND_SIZE_DEF) /
+ iwarp_info->max_mtu;
+ n_ooo_bufs = min_t(u32, n_ooo_bufs, QED_IWARP_LL2_OOO_MAX_RX_SIZE);
+
+ data.input.rx_num_desc = n_ooo_bufs;
+ data.input.rx_num_ooo_buffers = n_ooo_bufs;
+
+ data.input.tx_max_bds_per_packet = 1; /* will never be fragmented */
+ data.input.tx_num_desc = QED_IWARP_LL2_OOO_DEF_TX_SIZE;
+ data.p_connection_handle = &iwarp_info->ll2_ooo_handle;
+
+ rc = qed_ll2_acquire_connection(p_hwfn, &data);
+ if (rc)
+ goto err;
+
+ rc = qed_ll2_establish_connection(p_hwfn, iwarp_info->ll2_ooo_handle);
+ if (rc)
+ goto err;
+
return rc;
err:
qed_iwarp_ll2_stop(p_hwfn, p_ptt);
@@ -2014,6 +2057,7 @@ int qed_iwarp_setup(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
qed_spq_register_async_cb(p_hwfn, PROTOCOLID_IWARP,
qed_iwarp_async_event);
+ qed_ooo_setup(p_hwfn);
return qed_iwarp_ll2_start(p_hwfn, params, p_ptt);
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.h b/drivers/net/ethernet/qlogic/qed/qed_iwarp.h
index 148ef3c..9e2bfde 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.h
@@ -47,7 +47,12 @@ enum qed_iwarp_qp_state {
#define QED_IWARP_LL2_SYN_TX_SIZE (128)
#define QED_IWARP_LL2_SYN_RX_SIZE (256)
#define QED_IWARP_MAX_SYN_PKT_SIZE (128)
-#define QED_IWARP_HANDLE_INVAL (0xff)
+
+#define QED_IWARP_LL2_OOO_DEF_TX_SIZE (256)
+#define QED_IWARP_MAX_OOO (16)
+#define QED_IWARP_LL2_OOO_MAX_RX_SIZE (16384)
+
+#define QED_IWARP_HANDLE_INVAL (0xff)
struct qed_iwarp_ll2_buff {
void *data;
@@ -67,6 +72,7 @@ struct qed_iwarp_info {
u8 crc_needed;
u8 tcp_flags;
u8 ll2_syn_handle;
+ u8 ll2_ooo_handle;
u8 peer2peer;
enum mpa_negotiation_mode mpa_rev;
enum mpa_rtr_type rtr_type;
@@ -147,6 +153,9 @@ struct qed_iwarp_listener {
int qed_iwarp_setup(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
struct qed_rdma_start_in_params *params);
+void qed_iwarp_init_fw_ramrod(struct qed_hwfn *p_hwfn,
+ struct iwarp_init_func_params *p_ramrod);
+
int qed_iwarp_stop(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt);
void qed_iwarp_resc_free(struct qed_hwfn *p_hwfn);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.c b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
index 06715f7..4f46f28 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_rdma.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
@@ -551,10 +551,13 @@ static int qed_rdma_start_fw(struct qed_hwfn *p_hwfn,
if (rc)
return rc;
- if (QED_IS_IWARP_PERSONALITY(p_hwfn))
+ if (QED_IS_IWARP_PERSONALITY(p_hwfn)) {
+ qed_iwarp_init_fw_ramrod(p_hwfn,
+ &p_ent->ramrod.iwarp_init_func.iwarp);
p_ramrod = &p_ent->ramrod.iwarp_init_func.rdma;
- else
+ } else {
p_ramrod = &p_ent->ramrod.roce_init_func.rdma;
+ }
p_params_header = &p_ramrod->params_header;
p_params_header->cnq_start_offset = (u8)RESC_START(p_hwfn,
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 1/4] qed: Add iWARP enablement support
From: Michal Kalderon @ 2017-09-24 9:09 UTC (permalink / raw)
To: davem, netdev, leon; +Cc: linux-rdma, dledford, Michal Kalderon, Ariel Elior
In-Reply-To: <1506244185-2129-1-git-send-email-Michal.Kalderon@cavium.com>
This patch is the last of the initial iWARP patch series. It
adds the possiblity to actually detect iWARP from the device and enable
it in the critical locations which basically make iWARP available.
It wasn't submitted until now as iWARP hadn't been accepted into
the rdma tree.
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
Signed-off-by: Ariel Elior <Ariel.Elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_cxt.c | 6 ++++++
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 10 +++++-----
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 5 ++++-
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 1 +
4 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index af106be..afd07ad 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -2069,6 +2069,12 @@ static void qed_rdma_set_pf_params(struct qed_hwfn *p_hwfn,
num_srqs = min_t(u32, 32 * 1024, p_params->num_srqs);
+ if (p_hwfn->mcp_info->func_info.protocol == QED_PCI_ETH_RDMA) {
+ DP_NOTICE(p_hwfn,
+ "Current day drivers don't support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only\n");
+ p_hwfn->hw_info.personality = QED_PCI_ETH_ROCE;
+ }
+
switch (p_hwfn->hw_info.personality) {
case QED_PCI_ETH_IWARP:
/* Each QP requires one connection */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 376485d..8b99c7d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1691,12 +1691,12 @@ int qed_mcp_get_media_type(struct qed_dev *cdev, u32 *p_media_type)
case FW_MB_PARAM_GET_PF_RDMA_ROCE:
*p_proto = QED_PCI_ETH_ROCE;
break;
- case FW_MB_PARAM_GET_PF_RDMA_BOTH:
- DP_NOTICE(p_hwfn,
- "Current day drivers don't support RoCE & iWARP. Default to RoCE-only\n");
- *p_proto = QED_PCI_ETH_ROCE;
- break;
case FW_MB_PARAM_GET_PF_RDMA_IWARP:
+ *p_proto = QED_PCI_ETH_IWARP;
+ break;
+ case FW_MB_PARAM_GET_PF_RDMA_BOTH:
+ *p_proto = QED_PCI_ETH_RDMA;
+ break;
default:
DP_NOTICE(p_hwfn,
"MFW answers GET_PF_RDMA_PROTOCOL but param is %08x\n",
diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.c b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
index 6fb9951..06715f7 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_rdma.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
@@ -156,7 +156,10 @@ static int qed_rdma_alloc(struct qed_hwfn *p_hwfn,
return rc;
p_hwfn->p_rdma_info = p_rdma_info;
- p_rdma_info->proto = PROTOCOLID_ROCE;
+ if (QED_IS_IWARP_PERSONALITY(p_hwfn))
+ p_rdma_info->proto = PROTOCOLID_IWARP;
+ else
+ p_rdma_info->proto = PROTOCOLID_ROCE;
num_cons = qed_cxt_get_proto_cid_count(p_hwfn, p_rdma_info->proto,
NULL);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c b/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
index 46d0c3c..a1d33f3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sp_commands.c
@@ -377,6 +377,7 @@ int qed_sp_pf_start(struct qed_hwfn *p_hwfn,
p_ramrod->personality = PERSONALITY_ISCSI;
break;
case QED_PCI_ETH_ROCE:
+ case QED_PCI_ETH_IWARP:
p_ramrod->personality = PERSONALITY_RDMA_AND_ETH;
break;
default:
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 0/4] qed: iWARP fixes and enhancements
From: Michal Kalderon @ 2017-09-24 9:09 UTC (permalink / raw)
To: davem, netdev, leon; +Cc: linux-rdma, dledford, Michal Kalderon, Ariel Elior
This patch series includes several fixes and enhancements
related to iWARP.
Patch #1 is actually the last of the initial iWARP submission.
It has been delayed until now as I wanted to make sure that qedr
supports iWARP prior to enabling iWARP device detection.
iWARP changes in RDMA tree have been accepted and targeted at
kernel 4.15, therefore, all iWARP fixes for this cycle are
submitted to net-next.
Changes from v1->v2
- Added "Fixes:" tag to commit message of patch #3
Signed-off by: Michal.Kalderon@cavium.com
Signed-off-by: Ariel Elior <Ariel.Elior@cavium.com>
Michal Kalderon (4):
qed: Add iWARP enablement support
qed: Add iWARP out of order support
qed: Fix maximum number of CQs for iWARP
qed: iWARP - Add check for errors on a SYN packet
drivers/net/ethernet/qlogic/qed/qed_cxt.c | 6 +++
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 52 +++++++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_iwarp.h | 11 ++++-
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 10 ++---
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 24 +++++++----
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 1 +
include/linux/qed/qed_ll2_if.h | 1 +
8 files changed, 91 insertions(+), 15 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH v2 net-next 4/4] qed: iWARP - Add check for errors on a SYN packet
From: Michal Kalderon @ 2017-09-24 9:09 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
leon-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
dledford-H+wXaHxf7aLQT0dZR+AlfA, Michal Kalderon, Ariel Elior
In-Reply-To: <1506244185-2129-1-git-send-email-Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
A SYN packet which arrives with errors from FW should be dropped.
This required adding an additional field to the ll2
rx completion data.
Signed-off-by: Michal Kalderon <Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Ariel Elior <Ariel.Elior-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
---
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 8 ++++++++
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 1 +
include/linux/qed/qed_ll2_if.h | 1 +
3 files changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index 568e985..8fc9c811 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -1733,6 +1733,14 @@ int qed_iwarp_reject(void *rdma_cxt, struct qed_iwarp_reject_in *iparams)
memset(&cm_info, 0, sizeof(cm_info));
ll2_syn_handle = p_hwfn->p_rdma_info->iwarp.ll2_syn_handle;
+
+ /* Check if packet was received with errors... */
+ if (data->err_flags) {
+ DP_NOTICE(p_hwfn, "Error received on SYN packet: 0x%x\n",
+ data->err_flags);
+ goto err;
+ }
+
if (GET_FIELD(data->parse_flags,
PARSING_AND_ERR_FLAGS_L4CHKSMWASCALCULATED) &&
GET_FIELD(data->parse_flags, PARSING_AND_ERR_FLAGS_L4CHKSMERROR)) {
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ll2.c b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
index c06ad4f..250afa5 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
@@ -413,6 +413,7 @@ static void qed_ll2_rxq_parse_reg(struct qed_hwfn *p_hwfn,
struct qed_ll2_comp_rx_data *data)
{
data->parse_flags = le16_to_cpu(p_cqe->rx_cqe_fp.parse_flags.flags);
+ data->err_flags = le16_to_cpu(p_cqe->rx_cqe_fp.err_flags.flags);
data->length.packet_length =
le16_to_cpu(p_cqe->rx_cqe_fp.packet_length);
data->vlan = le16_to_cpu(p_cqe->rx_cqe_fp.vlan);
diff --git a/include/linux/qed/qed_ll2_if.h b/include/linux/qed/qed_ll2_if.h
index dd7a3b8..89fa0bb 100644
--- a/include/linux/qed/qed_ll2_if.h
+++ b/include/linux/qed/qed_ll2_if.h
@@ -101,6 +101,7 @@ struct qed_ll2_comp_rx_data {
void *cookie;
dma_addr_t rx_buf_addr;
u16 parse_flags;
+ u16 err_flags;
u16 vlan;
bool b_last_packet;
u8 connection_handle;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* [PATCH v2 net-next 3/4] qed: Fix maximum number of CQs for iWARP
From: Michal Kalderon @ 2017-09-24 9:09 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
leon-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
dledford-H+wXaHxf7aLQT0dZR+AlfA, Michal Kalderon, Ariel Elior
In-Reply-To: <1506244185-2129-1-git-send-email-Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
The maximum number of CQs supported is bound to the number
of connections supported, which differs between RoCE and iWARP.
This fixes a crash that occurred in iWARP when running 1000 sessions
using perftest.
Fixes: 67b40dccc45 ("qed: Implement iWARP initialization, teardown and qp operations")
Signed-off-by: Michal Kalderon <Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Ariel Elior <Ariel.Elior-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
---
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.c b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
index 4f46f28..c8c4b39 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_rdma.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
@@ -209,11 +209,11 @@ static int qed_rdma_alloc(struct qed_hwfn *p_hwfn,
goto free_pd_map;
}
- /* Allocate bitmap for cq's. The maximum number of CQs is bounded to
- * twice the number of QPs.
+ /* Allocate bitmap for cq's. The maximum number of CQs is bound to
+ * the number of connections we support. (num_qps in iWARP or
+ * num_qps/2 in RoCE).
*/
- rc = qed_rdma_bmap_alloc(p_hwfn, &p_rdma_info->cq_map,
- p_rdma_info->num_qps * 2, "CQ");
+ rc = qed_rdma_bmap_alloc(p_hwfn, &p_rdma_info->cq_map, num_cons, "CQ");
if (rc) {
DP_VERBOSE(p_hwfn, QED_MSG_RDMA,
"Failed to allocate cq bitmap, rc = %d\n", rc);
@@ -222,10 +222,10 @@ static int qed_rdma_alloc(struct qed_hwfn *p_hwfn,
/* Allocate bitmap for toggle bit for cq icids
* We toggle the bit every time we create or resize cq for a given icid.
- * The maximum number of CQs is bounded to twice the number of QPs.
+ * Size needs to equal the size of the cq bmap.
*/
rc = qed_rdma_bmap_alloc(p_hwfn, &p_rdma_info->toggle_bits,
- p_rdma_info->num_qps * 2, "Toggle");
+ num_cons, "Toggle");
if (rc) {
DP_VERBOSE(p_hwfn, QED_MSG_RDMA,
"Failed to allocate toogle bits, rc = %d\n", rc);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* Re: [PATCH net-next] bpf/verifier: improve disassembly of BPF_END instructions
From: Alexei Starovoitov @ 2017-09-24 5:50 UTC (permalink / raw)
To: Y Song
Cc: Edward Cree, Daniel Borkmann, David Miller, netdev, Jiong Wang,
Jakub Kicinski
In-Reply-To: <CAH3MdRUCPNzXHQRQtVp7-p9XLDbJrkhxYEe=c0Fkt4+D9Tk9sw@mail.gmail.com>
On Fri, Sep 22, 2017 at 09:49:10PM -0700, Y Song wrote:
> On Fri, Sep 22, 2017 at 9:23 AM, Edward Cree <ecree@solarflare.com> wrote:
> > On 22/09/17 16:16, Alexei Starovoitov wrote:
> >> looks like we're converging on
> >> "be16/be32/be64/le16/le32/le64 #register" for BPF_END.
> >> I guess it can live with that. I would prefer more C like syntax
> >> to match the rest, but llvm parsing point is a strong one.
> > Yep, agreed. I'll post a v2 once we've settled BPF_NEG.
> >> For BPG_NEG I prefer to do it in C syntax like interpreter does:
> >> ALU_NEG:
> >> DST = (u32) -DST;
> >> ALU64_NEG:
> >> DST = -DST;
> >> Yonghong, does it mean that asmparser will equally suffer?
> > Correction to my earlier statements: verifier will currently disassemble
> > neg as:
> > (87) r0 neg 0
> > (84) (u32) r0 neg (u32) 0
> > because it pretends 'neg' is a compound-assignment operator like +=.
> > The analogy with be16 and friends would be to use
> > neg64 r0
> > neg32 r0
> > whereas the analogy with everything else would be
> > r0 = -r0
> > r0 = (u32) -r0
> > as Alexei says.
> > I'm happy to go with Alexei's version if it doesn't cause problems for llvm.
>
> I got some time to do some prototyping in llvm and it looks like that
> I am able to
> resolve the issue and we are able to use more C-like syntax. That is:
> for bswap:
> r1 = (be16) (u16) r1
> or
> r1 = (be16) r1
> or
> r1 = be16 r1
> for neg:
> r0 = -r0
> (for 32bit support, llvm may output "w0 = -w0" in the future. But
> since it is not
> enabled yet, you can continue to output "r0 = (u32) -r0".)
>
> Not sure which syntax is best for bswap. The "r1 = (be16) (u16) r1" is most
> explicit in its intention.
>
> Attaching my llvm patch as well and cc'ing Jiong and Jakub so they can see my
> implementation and the relative discussion here. (In this patch, I did
> not implement
> bswap for little endian yet.) Maybe they can provide additional comments.
This is awesome. In such case I'd like to swing back to the C syntax for bpf_end :)
Any of these
r1 = (be16) (u16) r1
or
r1 = (be16) r1
or
r1 = be16 r1
are better than just
be16 r1
I like 1st the most, since it's explicit in terms of what happens with upper bits,
but 2nd is also ok. 3rd is not quite C-like.
^ permalink raw reply
* [PATCH] mac80211: aead api to reduce redundancy
From: Xiang Gao @ 2017-09-24 5:40 UTC (permalink / raw)
To: herbert, davem, johannes, linux-crypto, linux-kernel,
linux-wireless, netdev
Cc: qasdfgtyuiop
Currently, the aes_ccm.c and aes_gcm.c are almost line by line
copy of each other. This patch reduce code redundancy by moving
the code in these two files to crypto/aead_api.c to make it a
higher level aead api. The aes_ccm.c and aes_gcm.c are removed
and all the functions are now implemented in their headers using
the newly added aead api.
Signed-off-by: Xiang Gao <qasdfgtyuiop@gmail.com>
---
crypto/Makefile | 2 +-
net/mac80211/aes_gcm.c => crypto/aead_api.c | 53 +++++++------
include/crypto/aead_api.h | 21 +++++
net/mac80211/Makefile | 2 -
net/mac80211/aes_ccm.c | 115 ----------------------------
net/mac80211/aes_ccm.h | 42 +++++++---
net/mac80211/aes_gcm.h | 40 ++++++++--
net/mac80211/key.c | 1 +
net/mac80211/wpa.c | 11 +--
9 files changed, 118 insertions(+), 169 deletions(-)
rename net/mac80211/aes_gcm.c => crypto/aead_api.c (54%)
create mode 100644 include/crypto/aead_api.h
delete mode 100644 net/mac80211/aes_ccm.c
diff --git a/crypto/Makefile b/crypto/Makefile
index d41f0331b085..541316db5841 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -14,7 +14,7 @@ crypto_algapi-$(CONFIG_PROC_FS) += proc.o
crypto_algapi-y := algapi.o scatterwalk.o $(crypto_algapi-y)
obj-$(CONFIG_CRYPTO_ALGAPI2) += crypto_algapi.o
-obj-$(CONFIG_CRYPTO_AEAD2) += aead.o
+obj-$(CONFIG_CRYPTO_AEAD2) += aead.o aead_api.o
crypto_blkcipher-y := ablkcipher.o
crypto_blkcipher-y += blkcipher.o
diff --git a/net/mac80211/aes_gcm.c b/crypto/aead_api.c
similarity index 54%
rename from net/mac80211/aes_gcm.c
rename to crypto/aead_api.c
index 8a4397cc1b08..9585ee400b2e 100644
--- a/net/mac80211/aes_gcm.c
+++ b/crypto/aead_api.c
@@ -1,7 +1,4 @@
-/*
- * Copyright 2014-2015, Qualcomm Atheros, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
+/* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
@@ -9,43 +6,43 @@
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/err.h>
-#include <crypto/aead.h>
+#include <linux/scatterlist.h>
-#include <net/mac80211.h>
-#include "key.h"
-#include "aes_gcm.h"
+#include <crypto/aead_api.h>
-int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic)
+int aead_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t aad_len,
+ u8 *data, size_t data_len, u8 *auth)
{
struct scatterlist sg[3];
struct aead_request *aead_req;
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
u8 *__aad;
- aead_req = kzalloc(reqsize + GCM_AAD_LEN, GFP_ATOMIC);
+ aead_req = kzalloc(reqsize + aad_len, GFP_ATOMIC);
if (!aead_req)
return -ENOMEM;
__aad = (u8 *)aead_req + reqsize;
- memcpy(__aad, aad, GCM_AAD_LEN);
+ memcpy(__aad, aad, aad_len);
sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad));
+ sg_set_buf(&sg[0], __aad, aad_len);
sg_set_buf(&sg[1], data, data_len);
- sg_set_buf(&sg[2], mic, IEEE80211_GCMP_MIC_LEN);
+ sg_set_buf(&sg[2], auth, tfm->authsize);
aead_request_set_tfm(aead_req, tfm);
- aead_request_set_crypt(aead_req, sg, sg, data_len, j_0);
+ aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
crypto_aead_encrypt(aead_req);
kzfree(aead_req);
+
return 0;
}
+EXPORT_SYMBOL_GPL(aead_encrypt);
-int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic)
+int aead_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t aad_len,
+ u8 *data, size_t data_len, u8 *auth)
{
struct scatterlist sg[3];
struct aead_request *aead_req;
@@ -56,21 +53,20 @@ int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
if (data_len == 0)
return -EINVAL;
- aead_req = kzalloc(reqsize + GCM_AAD_LEN, GFP_ATOMIC);
+ aead_req = kzalloc(reqsize + aad_len, GFP_ATOMIC);
if (!aead_req)
return -ENOMEM;
__aad = (u8 *)aead_req + reqsize;
- memcpy(__aad, aad, GCM_AAD_LEN);
+ memcpy(__aad, aad, aad_len);
sg_init_table(sg, 3);
sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad));
sg_set_buf(&sg[1], data, data_len);
- sg_set_buf(&sg[2], mic, IEEE80211_GCMP_MIC_LEN);
+ sg_set_buf(&sg[2], auth, tfm->authsize);
aead_request_set_tfm(aead_req, tfm);
- aead_request_set_crypt(aead_req, sg, sg,
- data_len + IEEE80211_GCMP_MIC_LEN, j_0);
+ aead_request_set_crypt(aead_req, sg, sg, data_len + tfm->authsize, b_0);
aead_request_set_ad(aead_req, sg[0].length);
err = crypto_aead_decrypt(aead_req);
@@ -78,21 +74,22 @@ int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
return err;
}
+EXPORT_SYMBOL_GPL(aead_decrypt);
-struct crypto_aead *ieee80211_aes_gcm_key_setup_encrypt(const u8 key[],
- size_t key_len)
+struct crypto_aead *aead_key_setup_encrypt(const char *alg,
+ const u8 key[], size_t key_len, size_t authsize)
{
struct crypto_aead *tfm;
int err;
- tfm = crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG_ASYNC);
+ tfm = crypto_alloc_aead(alg, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
return tfm;
err = crypto_aead_setkey(tfm, key, key_len);
if (err)
goto free_aead;
- err = crypto_aead_setauthsize(tfm, IEEE80211_GCMP_MIC_LEN);
+ err = crypto_aead_setauthsize(tfm, authsize);
if (err)
goto free_aead;
@@ -102,8 +99,10 @@ struct crypto_aead *ieee80211_aes_gcm_key_setup_encrypt(const u8 key[],
crypto_free_aead(tfm);
return ERR_PTR(err);
}
+EXPORT_SYMBOL_GPL(aead_key_setup_encrypt);
-void ieee80211_aes_gcm_key_free(struct crypto_aead *tfm)
+void aead_key_free(struct crypto_aead *tfm)
{
crypto_free_aead(tfm);
}
+EXPORT_SYMBOL_GPL(aead_key_free);
diff --git a/include/crypto/aead_api.h b/include/crypto/aead_api.h
new file mode 100644
index 000000000000..45deda0d538f
--- /dev/null
+++ b/include/crypto/aead_api.h
@@ -0,0 +1,21 @@
+/* This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _AEAD_API_H
+#define _AEAD_API_H
+
+#include <crypto/aead.h>
+#include <linux/crypto.h>
+
+struct crypto_aead *aead_key_setup_encrypt(const char *alg,
+ const u8 key[], size_t key_len, size_t authsize);
+
+int aead_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
+ size_t aad_len, u8 *data, size_t data_len, u8 *auth);
+int aead_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
+ size_t aad_len, u8 *data, size_t data_len, u8 *auth);
+void aead_key_free(struct crypto_aead *tfm);
+
+#endif /* _AEAD_API_H */
diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index 282912245938..f1efc8c81ce6 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -15,8 +15,6 @@ mac80211-y := \
rate.o \
michael.o \
tkip.o \
- aes_ccm.o \
- aes_gcm.o \
aes_cmac.o \
aes_gmac.o \
fils_aead.o \
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
deleted file mode 100644
index a4e0d59a40dd..000000000000
--- a/net/mac80211/aes_ccm.c
+++ /dev/null
@@ -1,115 +0,0 @@
-/*
- * Copyright 2003-2004, Instant802 Networks, Inc.
- * Copyright 2005-2006, Devicescape Software, Inc.
- *
- * Rewrite: Copyright (C) 2013 Linaro Ltd <ard.biesheuvel@linaro.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/kernel.h>
-#include <linux/types.h>
-#include <linux/err.h>
-#include <crypto/aead.h>
-
-#include <net/mac80211.h>
-#include "key.h"
-#include "aes_ccm.h"
-
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len)
-{
- struct scatterlist sg[3];
- struct aead_request *aead_req;
- int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
- u8 *__aad;
-
- aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
- if (!aead_req)
- return -ENOMEM;
-
- __aad = (u8 *)aead_req + reqsize;
- memcpy(__aad, aad, CCM_AAD_LEN);
-
- sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad));
- sg_set_buf(&sg[1], data, data_len);
- sg_set_buf(&sg[2], mic, mic_len);
-
- aead_request_set_tfm(aead_req, tfm);
- aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
- aead_request_set_ad(aead_req, sg[0].length);
-
- crypto_aead_encrypt(aead_req);
- kzfree(aead_req);
-
- return 0;
-}
-
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len)
-{
- struct scatterlist sg[3];
- struct aead_request *aead_req;
- int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
- u8 *__aad;
- int err;
-
- if (data_len == 0)
- return -EINVAL;
-
- aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
- if (!aead_req)
- return -ENOMEM;
-
- __aad = (u8 *)aead_req + reqsize;
- memcpy(__aad, aad, CCM_AAD_LEN);
-
- sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad));
- sg_set_buf(&sg[1], data, data_len);
- sg_set_buf(&sg[2], mic, mic_len);
-
- aead_request_set_tfm(aead_req, tfm);
- aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
- aead_request_set_ad(aead_req, sg[0].length);
-
- err = crypto_aead_decrypt(aead_req);
- kzfree(aead_req);
-
- return err;
-}
-
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
- size_t key_len,
- size_t mic_len)
-{
- struct crypto_aead *tfm;
- int err;
-
- tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
- if (IS_ERR(tfm))
- return tfm;
-
- err = crypto_aead_setkey(tfm, key, key_len);
- if (err)
- goto free_aead;
- err = crypto_aead_setauthsize(tfm, mic_len);
- if (err)
- goto free_aead;
-
- return tfm;
-
-free_aead:
- crypto_free_aead(tfm);
- return ERR_PTR(err);
-}
-
-void ieee80211_aes_key_free(struct crypto_aead *tfm)
-{
- crypto_free_aead(tfm);
-}
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index fcd3254c5cf0..b51ef23201c1 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -10,19 +10,39 @@
#ifndef AES_CCM_H
#define AES_CCM_H
-#include <linux/crypto.h>
+#include <crypto/aead_api.h>
#define CCM_AAD_LEN 32
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
- size_t key_len,
- size_t mic_len);
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len);
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len);
-void ieee80211_aes_key_free(struct crypto_aead *tfm);
+static inline struct crypto_aead *ieee80211_aes_key_setup_encrypt(
+ const u8 key[], size_t key_len, size_t mic_len)
+{
+ return aead_key_setup_encrypt("ccm(aes)", key, key_len, mic_len);
+}
+
+static inline int ieee80211_aes_ccm_encrypt(
+ struct crypto_aead *tfm,
+ u8 *b_0, u8 *aad, u8 *data,
+ size_t data_len, u8 *mic)
+{
+ return aead_encrypt(tfm, b_0, aad + 2,
+ be16_to_cpup((__be16 *)aad),
+ data, data_len, mic);
+}
+
+static inline int ieee80211_aes_ccm_decrypt(
+ struct crypto_aead *tfm,
+ u8 *b_0, u8 *aad, u8 *data,
+ size_t data_len, u8 *mic)
+{
+ return aead_decrypt(tfm, b_0, aad + 2,
+ be16_to_cpup((__be16 *)aad),
+ data, data_len, mic);
+}
+
+static inline void ieee80211_aes_key_free(struct crypto_aead *tfm)
+{
+ return aead_key_free(tfm);
+}
#endif /* AES_CCM_H */
diff --git a/net/mac80211/aes_gcm.h b/net/mac80211/aes_gcm.h
index 55aed5352494..f07359d5ebbd 100644
--- a/net/mac80211/aes_gcm.h
+++ b/net/mac80211/aes_gcm.h
@@ -9,16 +9,40 @@
#ifndef AES_GCM_H
#define AES_GCM_H
-#include <linux/crypto.h>
+#include <crypto/aead_api.h>
#define GCM_AAD_LEN 32
-int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic);
-int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic);
-struct crypto_aead *ieee80211_aes_gcm_key_setup_encrypt(const u8 key[],
- size_t key_len);
-void ieee80211_aes_gcm_key_free(struct crypto_aead *tfm);
+static inline int ieee80211_aes_gcm_encrypt(
+ struct crypto_aead *tfm,
+ u8 *j_0, u8 *aad, u8 *data,
+ size_t data_len, u8 *mic)
+{
+ return aead_encrypt(tfm, j_0, aad + 2,
+ be16_to_cpup((__be16 *)aad),
+ data, data_len, mic);
+}
+
+static inline int ieee80211_aes_gcm_decrypt(
+ struct crypto_aead *tfm,
+ u8 *j_0, u8 *aad, u8 *data,
+ size_t data_len, u8 *mic)
+{
+ return aead_decrypt(tfm, j_0, aad + 2,
+ be16_to_cpup((__be16 *)aad),
+ data, data_len, mic);
+}
+
+static inline struct crypto_aead *ieee80211_aes_gcm_key_setup_encrypt(
+ const u8 key[], size_t key_len)
+{
+ return aead_key_setup_encrypt("gcm(aes)", key,
+ key_len, IEEE80211_GCMP_MIC_LEN);
+}
+
+static inline void ieee80211_aes_gcm_key_free(struct crypto_aead *tfm)
+{
+ return aead_key_free(tfm);
+}
#endif /* AES_GCM_H */
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index a98fc2b5e0dc..a61cecd078bb 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -18,6 +18,7 @@
#include <linux/rtnetlink.h>
#include <linux/slab.h>
#include <linux/export.h>
+#include <linux/crypto.h>
#include <net/mac80211.h>
#include <asm/unaligned.h>
#include "ieee80211_i.h"
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index 0d722ea98a1b..e30e09c1e149 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -464,7 +464,7 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb,
pos += IEEE80211_CCMP_HDR_LEN;
ccmp_special_blocks(skb, pn, b_0, aad);
return ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad, pos, len,
- skb_put(skb, mic_len), mic_len);
+ skb_put(skb, key->u.ccmp.tfm->authsize));
}
@@ -540,10 +540,11 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
ccmp_special_blocks(skb, pn, b_0, aad);
if (ieee80211_aes_ccm_decrypt(
- key->u.ccmp.tfm, b_0, aad,
- skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
- data_len,
- skb->data + skb->len - mic_len, mic_len))
+ key->u.ccmp.tfm, b_0, aad,
+ skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
+ data_len,
+ skb->data + skb->len - key->u.ccmp.tfm->authsize
+ ))
return RX_DROP_UNUSABLE;
}
--
2.14.1
^ permalink raw reply related
* Re: [PATCH 1/1] forcedeth: optimize the xmit/rx with unlikely
From: David Miller @ 2017-09-24 3:04 UTC (permalink / raw)
To: yanjun.zhu; +Cc: jarod, netdev
In-Reply-To: <1506090021-16489-1-git-send-email-yanjun.zhu@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Fri, 22 Sep 2017 10:20:21 -0400
> In the xmit/rx fastpath, the function dma_map_single rarely fails.
> Therefore, add an unlikely() optimization to this error check
> conditional.
>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net] net: qualcomm: rmnet: Fix rcu splat in rmnet_is_real_dev_registered
From: David Miller @ 2017-09-24 3:00 UTC (permalink / raw)
To: subashab; +Cc: xiaolong.ye, netdev
In-Reply-To: <1506038436-4865-1-git-send-email-subashab@codeaurora.org>
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Thu, 21 Sep 2017 18:00:36 -0600
> Xiaolong reported a suspicious rcu_dereference_check in the device
> unregister notifier callback. Since we do not dereference the
> rx_handler_data, it's ok to just check for the value of the pointer.
> Note that this section is already protected by rtnl_lock.
...
> Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation")
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> Reported-by: kernel test robot <xiaolong.ye@intel.com>
Applied, thank you.
^ 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