* Re: Correct method for initializing Pause and Asymmetrical Pause support in phy drivers
From: Marc Bertola @ 2017-01-12 16:52 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: netdev, Florian Fainelli, Timur Tabi
In-Reply-To: <68c58b10-1458-636e-a4a6-686a17ba743b@neratec.com>
Yes! This solution makes most sense, as Pause support is definitely on
the MAC side.
I thought this was not allowed because I was following instructions
from a stale copy of phy.txt -- I figured my copy was good because the
"last update" date at the top of the master file was the same. (It is
still 2008-04-08 -- see
https://github.com/torvalds/linux/blob/master/Documentation/networking/phy.txt)
Thank you very much for your swift response. This whole issue has been
very interesting to investigate. I'll take a look at Timur's cleanup
and respect that approach as I repair the older copy of kernel that I
am working with for this project.
^ permalink raw reply
* [PATCH net-next] ipv6: sr: static percpu allocation for hmac_ring
From: Eric Dumazet @ 2017-01-12 16:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, David Lebrun
From: Eric Dumazet <edumazet@google.com>
Current allocations are not NUMA aware, and lack proper
cleanup in case of error.
It is perfectly fine to use static per cpu allocations for 256 bytes
per cpu.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Lebrun <david.lebrun@uclouvain.be>
---
net/ipv6/seg6_hmac.c | 43 ++---------------------------------------
1 file changed, 3 insertions(+), 40 deletions(-)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index ef1c8a46e7aceee45b2044d4b4338dc3aed88807..6389bf3e9c9f28cdd3e30175f2880b74e099e273 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -45,7 +45,7 @@
#include <net/seg6_hmac.h>
#include <linux/random.h>
-static char * __percpu *hmac_ring;
+static DEFINE_PER_CPU(char [SEG6_HMAC_RING_SIZE], hmac_ring);
static int seg6_hmac_cmpfn(struct rhashtable_compare_arg *arg, const void *obj)
{
@@ -192,7 +192,7 @@ int seg6_hmac_compute(struct seg6_hmac_info *hinfo, struct ipv6_sr_hdr *hdr,
*/
local_bh_disable();
- ring = *this_cpu_ptr(hmac_ring);
+ ring = this_cpu_ptr(hmac_ring);
off = ring;
/* source address */
@@ -353,27 +353,6 @@ int seg6_push_hmac(struct net *net, struct in6_addr *saddr,
}
EXPORT_SYMBOL(seg6_push_hmac);
-static int seg6_hmac_init_ring(void)
-{
- int i;
-
- hmac_ring = alloc_percpu(char *);
-
- if (!hmac_ring)
- return -ENOMEM;
-
- for_each_possible_cpu(i) {
- char *ring = kzalloc(SEG6_HMAC_RING_SIZE, GFP_KERNEL);
-
- if (!ring)
- return -ENOMEM;
-
- *per_cpu_ptr(hmac_ring, i) = ring;
- }
-
- return 0;
-}
-
static int seg6_hmac_init_algo(void)
{
struct seg6_hmac_algo *algo;
@@ -422,16 +401,7 @@ static int seg6_hmac_init_algo(void)
int __init seg6_hmac_init(void)
{
- int ret;
-
- ret = seg6_hmac_init_ring();
- if (ret < 0)
- goto out;
-
- ret = seg6_hmac_init_algo();
-
-out:
- return ret;
+ return seg6_hmac_init_algo();
}
EXPORT_SYMBOL(seg6_hmac_init);
@@ -450,13 +420,6 @@ void seg6_hmac_exit(void)
struct seg6_hmac_algo *algo = NULL;
int i, alg_count, cpu;
- for_each_possible_cpu(i) {
- char *ring = *per_cpu_ptr(hmac_ring, i);
-
- kfree(ring);
- }
- free_percpu(hmac_ring);
-
alg_count = sizeof(hmac_algos) / sizeof(struct seg6_hmac_algo);
for (i = 0; i < alg_count; i++) {
algo = &hmac_algos[i];
^ permalink raw reply related
* [PATCH iproute2] bridge: fdb: add state filter support
From: Nikolay Aleksandrov @ 2017-01-12 16:47 UTC (permalink / raw)
To: netdev; +Cc: roopa, stephen, purna, Nikolay Aleksandrov
This patch adds a new argument to the bridge fdb show command that allows
to filter by entry state.
Also update the man page to include all available show arguments.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
bridge/fdb.c | 32 ++++++++++++++++++++++++++++++--
man/man8/bridge.8 | 10 +++++++++-
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index a91521776e99..a71a78f23b20 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -29,7 +29,7 @@
#include "rt_names.h"
#include "utils.h"
-static unsigned int filter_index, filter_vlan;
+static unsigned int filter_index, filter_vlan, filter_state;
json_writer_t *jw_global;
@@ -39,7 +39,7 @@ static void usage(void)
" [ self ] [ master ] [ use ] [ router ]\n"
" [ local | static | dynamic ] [ dst IPADDR ] [ vlan VID ]\n"
" [ port PORT] [ vni VNI ] [ via DEV ]\n");
- fprintf(stderr, " bridge fdb [ show [ br BRDEV ] [ brport DEV ] [ vlan VID ] ]\n");
+ fprintf(stderr, " bridge fdb [ show [ br BRDEV ] [ brport DEV ] [ vlan VID ] [ state STATE ] ]\n");
exit(-1);
}
@@ -63,6 +63,24 @@ static const char *state_n2a(unsigned int s)
return buf;
}
+static int state_a2n(unsigned int *s, const char *arg)
+{
+ if (matches(arg, "permanent") == 0)
+ *s = NUD_PERMANENT;
+ else if (matches(arg, "static") == 0 || matches(arg, "temp") == 0)
+ *s = NUD_NOARP;
+ else if (matches(arg, "stale") == 0)
+ *s = NUD_STALE;
+ else if (matches(arg, "reachable") == 0 || matches(arg, "dynamic") == 0)
+ *s = NUD_REACHABLE;
+ else if (strcmp(arg, "all") == 0)
+ *s = ~0;
+ else if (get_unsigned(s, arg, 0))
+ return -1;
+
+ return 0;
+}
+
static void start_json_fdb_flags_array(bool *fdb_flags)
{
if (*fdb_flags)
@@ -100,6 +118,9 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
if (filter_index && filter_index != r->ndm_ifindex)
return 0;
+ if (filter_state && !(r->ndm_state & filter_state))
+ return 0;
+
parse_rtattr(tb, NDA_MAX, NDA_RTA(r),
n->nlmsg_len - NLMSG_LENGTH(sizeof(*r)));
@@ -310,6 +331,13 @@ static int fdb_show(int argc, char **argv)
if (filter_vlan)
duparg("vlan", *argv);
filter_vlan = atoi(*argv);
+ } else if (strcmp(*argv, "state") == 0) {
+ unsigned int state;
+
+ NEXT_ARG();
+ if (state_a2n(&state, *argv))
+ invarg("invalid state", *argv);
+ filter_state |= state;
} else {
if (matches(*argv, "help") == 0)
usage();
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 6617e188a384..9c5f855df72e 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -70,7 +70,15 @@ bridge \- show / manipulate bridge addresses and devices
.ti -8
.BR "bridge fdb" " [ " show " ] [ "
.B dev
-.IR DEV " ]"
+.IR DEV " ] [ "
+.B br
+.IR BRDEV " ] [ "
+.B brport
+.IR DEV " ] [ "
+.B vlan
+.IR VID " ] [ "
+.B state
+.IR STATE " ]"
.ti -8
.BR "bridge mdb" " { " add " | " del " } "
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests
From: Herbert Xu @ 2017-01-12 16:44 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List,
Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Ard Biesheuvel
In-Reply-To: <890f4bdb28a1cf72f6b802b220b35ebaf0f76bb9.1484090585.git.luto@kernel.org>
On Tue, Jan 10, 2017 at 03:24:46PM -0800, Andy Lutomirski wrote:
> There are some hashes (e.g. sha224) that have some internal trickery
> to make sure that only the correct number of output bytes are
> generated. If something goes wrong, they could potentially overrun
> the output buffer.
>
> Make the test more robust by allocating only enough space for the
> correct output size so that memory debugging will catch the error if
> the output is overrun.
>
> Tested by intentionally breaking sha224 to output all 256
> internally-generated bits while running on KASAN.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v1 3/8] crypto:chcr- Fix key length for RFC4106
From: Harsh Jain @ 2017-01-12 16:38 UTC (permalink / raw)
To: Herbert Xu; +Cc: hariprasad, netdev, linux-crypto
In-Reply-To: <20170112160959.GA19732@gondor.apana.org.au>
On 12-01-2017 21:39, Herbert Xu wrote:
> On Fri, Jan 06, 2017 at 02:01:34PM +0530, Harsh Jain wrote:
>> Check keylen before copying salt to avoid wrap around of Integer.
>>
>> Signed-off-by: Harsh Jain <harsh@chelsio.com>
>> ---
>> drivers/crypto/chelsio/chcr_algo.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
>> index deec7c0..6c2dea3 100644
>> --- a/drivers/crypto/chelsio/chcr_algo.c
>> +++ b/drivers/crypto/chelsio/chcr_algo.c
>> @@ -2194,8 +2194,8 @@ static int chcr_gcm_setkey(struct crypto_aead *aead, const u8 *key,
>> unsigned int ck_size;
>> int ret = 0, key_ctx_size = 0;
>>
>> - if (get_aead_subtype(aead) ==
>> - CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106) {
>> + if (get_aead_subtype(aead) == CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106 &&
>> + keylen > 3) {
>> keylen -= 4; /* nonce/salt is present in the last 4 bytes */
>> memcpy(aeadctx->salt, key + keylen, 4);
>> }
> We should return an error in this case.
That case is already handled in next if condition.It will error out with -EINVAL in next condition.
if (keylen == AES_KEYSIZE_128) {
>
> Cheers,
^ permalink raw reply
* Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
From: Sergei Shtylyov @ 2017-01-12 16:37 UTC (permalink / raw)
To: Lino Sanfilippo, Simon Horman
Cc: David Miller, Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <d840eddd-f6a3-fe8c-dbaa-242c117b5274@marvell.com>
On 01/12/2017 04:23 PM, Lino Sanfilippo wrote:
>>>> +
>>>> + for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
>
> BTW: How can this work correctly when cur_tx wraps and dirty_tx is greater?
{cur|dirty}_tx never wrap.
> Regards,
> Lino
MBR, Sergei
^ permalink raw reply
* Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
From: Sergei Shtylyov @ 2017-01-12 16:33 UTC (permalink / raw)
To: Simon Horman; +Cc: David Miller, Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20170112131821.GA16060@verge.net.au>
On 01/12/2017 04:18 PM, Simon Horman wrote:
> ...
>
>>>> Here, it stop once an untransmitted buffer is encountered...
>>>
>>> Yes, I see that now.
>>>
>>> I wonder if we should:
>>>
>>> a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
>>> (current behaviour) or all buffers (new behaviour).
>>> b) provide a different version of this loop in ravb_ring_free()
>>>
>>> What are your thoughts?
>>
>> I'm voting for (b).
>
> Ok, something like this?
>
> @@ -215,6 +225,30 @@ static void ravb_ring_free(struct net_device *ndev, int q)
> }
>
> if (priv->tx_ring[q]) {
> + for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
You're still copying the loop logic from ravb_tx_free() while we (I think)
need a simple loop over all the descriptor ring.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb
From: Oliver Hartkopp @ 2017-01-12 16:33 UTC (permalink / raw)
To: Liu ShuoX
Cc: Eric Dumazet, linux-kernel, yanmin_zhang, shuox.liu, Zhang Yanmin,
He, Bo, Marc Kleine-Budde, David S. Miller,
open list:CAN NETWORK LAYER, open list:NETWORKING [GENERAL]
In-Reply-To: <1484226099.15816.25.camel@edumazet-glaptop3.roam.corp.google.com>
On 01/12/2017 02:01 PM, Eric Dumazet wrote:
> On Thu, 2017-01-12 at 09:22 +0100, Oliver Hartkopp wrote:
>> But my main concern is:
>>
>> The reason why can_rx_delete_receiver() was introduced was the need to
>> remove a huge number of receivers with can_rx_unregister().
>>
>> When you call synchronize_rcu() after each receiver removal this would
>> potentially lead to a big performance issue when e.g. closing CAN_RAW
>> sockets with a high number of receivers.
>>
>> So the idea was to remove/unlink the receiver hlist_del_rcu(&r->list)
>> and also kmem_cache_free(rcv_cache, r) by some rcu mechanism - so that
>> all elements are cleaned up by rcu at a later point.
>>
>> Is it possible that the problems emerge due to hlist_del_rcu(&r->list)
>> and you accidently fix it with your introduced synchronize_rcu()?
>
> I agree this patch does not fix the root cause.
>
> The main problem seems that the sockets themselves are not RCU
> protected.
>
> If CAN uses RCU for delivery, then sockets should be freed only after
> one RCU grace period.
>
> On recent kernels, following patch could help :
>
Thanks Eric!
@Liu ShuoX: Can you check if Eric's suggestion fixes the issue in your
setup?
Best regards,
Oliver
^ permalink raw reply
* Re: [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Nicolas Dichtel @ 2017-01-12 16:32 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Christoph Hellwig, arnd, mmarek, linux-kbuild, linux-doc,
linux-kernel, linux-alpha, linux-snps-arc, linux-arm-kernel,
adi-buildroot-devel, linux-c6x-dev, linux-cris-kernel,
uclinux-h8-devel, linux-hexagon, linux-ia64, linux-m68k,
linux-metag, linux-mips, linux-am33-list, nios2-dev, openrisc,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux
In-Reply-To: <alpine.LSU.2.20.1701121727180.19188@erq.vanv.qr>
Le 12/01/2017 à 17:28, Jan Engelhardt a écrit :
> On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:
>
>> Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
>>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>>> Regularly, when a new header is created in include/uapi/, the developer
>>>> forgets to add it in the corresponding Kbuild file. This error is usually
>>>> detected after the release is out.
>>>>
>>>> In fact, all headers under uapi directories should be exported, thus it's
>>>> useless to have an exhaustive list.
>>>>
>>>> After this patch, the following files, which were not exported, are now
>>>> exported (with make headers_install_all):
>>>
>>> ... snip ...
>>>
>>>> linux/genwqe/.install
>>>> linux/genwqe/..install.cmd
>>>> linux/cifs/.install
>>>> linux/cifs/..install.cmd
>>>
>>> I'm pretty sure these should not be exported!
>>>
>> Those files are created in every directory:
>> $ find usr/include/ -name '\.\.install.cmd' | wc -l
>> 71
>
> That still does not mean they should be exported.
>
> Anything but headers (and directories as a skeleton structure) is maximally suspicious.
>
What I was trying to say is that I export those directories like other are.
Removing those files is not related to that series.
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Jan Engelhardt @ 2017-01-12 16:28 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: Christoph Hellwig, arnd, mmarek, linux-kbuild, linux-doc,
linux-kernel, linux-alpha, linux-snps-arc, linux-arm-kernel,
adi-buildroot-devel, linux-c6x-dev, linux-cris-kernel,
uclinux-h8-devel, linux-hexagon, linux-ia64, linux-m68k,
linux-metag, linux-mips, linux-am33-list, nios2-dev, openrisc,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux
In-Reply-To: <464a1323-4450-e563-ff59-9e6d57b75959@6wind.com>
On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:
>Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>> Regularly, when a new header is created in include/uapi/, the developer
>>> forgets to add it in the corresponding Kbuild file. This error is usually
>>> detected after the release is out.
>>>
>>> In fact, all headers under uapi directories should be exported, thus it's
>>> useless to have an exhaustive list.
>>>
>>> After this patch, the following files, which were not exported, are now
>>> exported (with make headers_install_all):
>>
>> ... snip ...
>>
>>> linux/genwqe/.install
>>> linux/genwqe/..install.cmd
>>> linux/cifs/.install
>>> linux/cifs/..install.cmd
>>
>> I'm pretty sure these should not be exported!
>>
>Those files are created in every directory:
>$ find usr/include/ -name '\.\.install.cmd' | wc -l
>71
That still does not mean they should be exported.
Anything but headers (and directories as a skeleton structure) is maximally suspicious.
^ permalink raw reply
* Re: Setting link down or up in software
From: Andrew Lunn @ 2017-01-12 16:27 UTC (permalink / raw)
To: Mason; +Cc: netdev, Mans Rullgard, Florian Fainelli, Thibaud Cornic
In-Reply-To: <75281de4-d50d-76fd-8de9-606001a4d93a@free.fr>
> Whatever the reason for the symptoms I'm seeing, some kind of race
> condition must be involved, because it occurs randomly.
The PHY is polled once a second for its status. So it would depend on
who fast autoneg happens if you see the down.
Andrew
^ permalink raw reply
* Re: [PATCH] fix itnull.cocci warnings
From: Herbert Xu @ 2017-01-12 16:26 UTC (permalink / raw)
To: Julia Lawall
Cc: Harsh Jain, hariprasad, netdev, linux-crypto, Atul Gupta,
kbuild-all
In-Reply-To: <alpine.DEB.2.20.1701071042410.2029@hadrien>
On Sat, Jan 07, 2017 at 10:46:17AM +0100, Julia Lawall wrote:
> The first argument to list_for_each_entry cannot be NULL.
>
> Generated by: scripts/coccinelle/iterators/itnull.cocci
>
> CC: Harsh Jain <harsh@chelsio.com>
> Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
>
> This code comes from the following git tree:
>
> url:
> https://github.com/0day-ci/linux/commits/Harsh-Jain/crypto-chcr-Bug-fixes/20170107-093356
> base:
> https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
> master
> In-Reply-To:
> <8e0086b56d8fb61637d179c32a09a1bca03c4186.1483599449.git.harsh@chelsio.com>
Harsh, please fold this patch into your series when you resubmit.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Setting link down or up in software
From: Mason @ 2017-01-12 16:22 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Mans Rullgard, Florian Fainelli, Thibaud Cornic
In-Reply-To: <20170112152856.GL13033@lunn.ch>
On 12/01/2017 16:28, Andrew Lunn wrote:
> Mason wrote:
>
>> Here's an example of "Link is Down" printed when I set link up:
>>
>> At [ 62.750220] I run ip link set dev eth0 down
>> Then leave the system idle for 10 minutes.
>> At [ 646.263041] I run ip link set dev eth0 up
>> At [ 647.364079] it prints "Link is Down"
>> At [ 649.417434] it prints "Link is Up - 1Gbps/Full - flow control rx/tx"
>
> Purely a guess, but when you up the interface, it starts auto
> negotiation. That often involves resetting the PHY. If the PHY has
> already once completed autoneg, e.g. because of the boot loader, it
> will be initially UP. The reset will put it DOWN, and then once
> autoneg is complete, it will be Up again.
>
> Pure guess. Go read the code and see if i'm write.
Thanks for giving me some food for thought, although the net framework
is far from easy to navigate. (So I'm not sure "go read the code" will
take me anywhere in the short term.)
Whatever the reason for the symptoms I'm seeing, some kind of race
condition must be involved, because it occurs randomly.
Regards.
^ permalink raw reply
* Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request
From: Sergei Shtylyov @ 2017-01-12 16:14 UTC (permalink / raw)
To: David Miller, horms; +Cc: magnus.damm, netdev, linux-renesas-soc
In-Reply-To: <20170112.110402.1123747824643306383.davem@davemloft.net>
On 01/12/2017 07:04 PM, David Miller wrote:
>> What I now see is that a few lines further up there is:
>>
>> if (skb_put_padto(skb, ETH_ZLEN))
>> goto drop;
>>
>> where ETH_ZLEN is 60.
>>
>> So I don't think we need to worry about skb->len being less than 60 and
>> this patch can be simplified to:
>>
>> if (len == 0)
>> len = 4;
>
> I'd say this might deserve a comment...
Sure. And the one better than the original "quick fix"... :-)
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v1 0/8] crypto:chcr- Bug fixes
From: Herbert Xu @ 2017-01-12 16:14 UTC (permalink / raw)
To: Harsh Jain; +Cc: hariprasad, netdev, linux-crypto
In-Reply-To: <cover.1483599449.git.harsh@chelsio.com>
On Fri, Jan 06, 2017 at 02:01:31PM +0530, Harsh Jain wrote:
> The patch series is based on Herbert's cryptodev-2.6 tree.
> It include bug fixes.
>
> Atul Gupta (4):
> crypto:chcr-Change flow IDs
> crypto:chcr- Fix panic on dma_unmap_sg
> crypto:chcr- Check device is allocated before use
> crypto:chcr- Fix wrong typecasting
> Harsh Jain (4):
> crypto:chcr- Fix key length for RFC4106
> crypto:chcr- Use cipher instead of Block Cipher in gcm setkey
> crypto:chcr: Change cra_flags for cipher algos
> crypto:chcr- Change algo priority
When you resubmit this please split it into two series. Please
send the critical bug fixes (panic + key length + alloc check)
in one series separate from the others. This way I can push
them easily to the 4.10 tree.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Correct method for initializing Pause and Asymmetrical Pause support in phy drivers
From: Andrew Lunn @ 2017-01-12 15:35 UTC (permalink / raw)
To: Marc Bertola; +Cc: netdev
In-Reply-To: <CAMqDo0XxvtjD+uJQeHJuSyN71zEEa5AB9YE1CUYK8wq2NGeAbQ@mail.gmail.com>
On Thu, Jan 12, 2017 at 10:21:29AM -0500, Marc Bertola wrote:
> Hello netdev list,
>
> I am currently investigating a problem related to Ethernet
> auto-negotiation of Pause and Asymmetrical Pause capabilities.
Hi Marc
Have you read:
commit 2fa3e25b454e267d8f55ee19c27be540495463e7
Author: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun Nov 27 18:45:13 2016 -0800
Documentation: net: phy: Add a paragraph about pause frames/flow control
Describe that the Ethernet MAC controller is ultimately responsible for
dealing with proper pause frames/flow control advertisement and
enabling, and that it is therefore allowed to have it change
phydev->supported/advertising with SUPPORTED_Pause and
SUPPORTED_AsymPause.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Andrew
^ permalink raw reply
* Re: [PATCH v1 3/8] crypto:chcr- Fix key length for RFC4106
From: Herbert Xu @ 2017-01-12 16:09 UTC (permalink / raw)
To: Harsh Jain; +Cc: hariprasad, netdev, linux-crypto
In-Reply-To: <6d8e61299e051d51dacdb6bfd6c5e582b230027c.1483599449.git.harsh@chelsio.com>
On Fri, Jan 06, 2017 at 02:01:34PM +0530, Harsh Jain wrote:
> Check keylen before copying salt to avoid wrap around of Integer.
>
> Signed-off-by: Harsh Jain <harsh@chelsio.com>
> ---
> drivers/crypto/chelsio/chcr_algo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
> index deec7c0..6c2dea3 100644
> --- a/drivers/crypto/chelsio/chcr_algo.c
> +++ b/drivers/crypto/chelsio/chcr_algo.c
> @@ -2194,8 +2194,8 @@ static int chcr_gcm_setkey(struct crypto_aead *aead, const u8 *key,
> unsigned int ck_size;
> int ret = 0, key_ctx_size = 0;
>
> - if (get_aead_subtype(aead) ==
> - CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106) {
> + if (get_aead_subtype(aead) == CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106 &&
> + keylen > 3) {
> keylen -= 4; /* nonce/salt is present in the last 4 bytes */
> memcpy(aeadctx->salt, key + keylen, 4);
> }
We should return an error in this case.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next] cdc-ether: usbnet_cdc_zte_status() can be static
From: David Miller @ 2017-01-12 16:09 UTC (permalink / raw)
To: weiyj.lk; +Cc: oliver, weiyongjun1, linux-usb, netdev
In-Reply-To: <20170112134347.22793-1-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 12 Jan 2017 13:43:47 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/net/usb/cdc_ether.c:469:6: warning:
> symbol 'usbnet_cdc_zte_status' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
From: Christian Borntraeger @ 2017-01-12 16:05 UTC (permalink / raw)
To: Michal Hocko, Andrew Morton
Cc: Vlastimil Babka, David Rientjes, Mel Gorman, Johannes Weiner,
Al Viro, linux-mm, LKML, Michal Hocko, Martin Schwidefsky,
Heiko Carstens, Herbert Xu, Anton Vorontsov, Colin Cross,
Kees Cook, Tony Luck, Rafael J. Wysocki, Ben Skeggs,
Kent Overstreet, Santosh Raspatur, Hariprasad S, Tariq
In-Reply-To: <20170112153717.28943-6-mhocko@kernel.org>
On 01/12/2017 04:37 PM, Michal Hocko wrote:
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 4f74511015b8..e6bbb33d2956 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -1126,10 +1126,7 @@ static long kvm_s390_get_skeys(struct kvm *kvm, struct kvm_s390_skeys *args)
> if (args->count < 1 || args->count > KVM_S390_SKEYS_MAX)
> return -EINVAL;
>
> - keys = kmalloc_array(args->count, sizeof(uint8_t),
> - GFP_KERNEL | __GFP_NOWARN);
> - if (!keys)
> - keys = vmalloc(sizeof(uint8_t) * args->count);
> + keys = kvmalloc(args->count * sizeof(uint8_t), GFP_KERNEL);
> if (!keys)
> return -ENOMEM;
>
> @@ -1171,10 +1168,7 @@ static long kvm_s390_set_skeys(struct kvm *kvm, struct kvm_s390_skeys *args)
> if (args->count < 1 || args->count > KVM_S390_SKEYS_MAX)
> return -EINVAL;
>
> - keys = kmalloc_array(args->count, sizeof(uint8_t),
> - GFP_KERNEL | __GFP_NOWARN);
> - if (!keys)
> - keys = vmalloc(sizeof(uint8_t) * args->count);
> + keys = kvmalloc(sizeof(uint8_t) * args->count, GFP_KERNEL);
> if (!keys)
> return -ENOMEM;
KVM/s390 parts
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: Joao Pinto @ 2017-01-12 16:04 UTC (permalink / raw)
To: David Miller, Joao.Pinto
Cc: alexandre.torgue, f.fainelli, lars.persson, niklass,
peppe.cavallaro, netdev
In-Reply-To: <20170112.104539.326369092090046644.davem@davemloft.net>
Às 3:45 PM de 1/12/2017, David Miller escreveu:
> From: Joao Pinto <Joao.Pinto@synopsys.com>
> Date: Thu, 12 Jan 2017 15:39:47 +0000
>
>> In my understanding the advantage is to prepare the future.
>
> If the driver is named foo or bar, yet in both cases loads and
> properly attaches to the user's device, the user does not care.
Of course. Although my car works I like to open the hood a see it clean and
organized. Gives the user more confidence.
>
> Therefore, there is no bonafide benefit to the user.
>
> You aren't getting past that point.
>
> You also are not addressing the pain this will cause for long
> term maintainence of this driver.
I am aware. I can co-maintain it if current maintainers wish it, no problem with
that. My activity at Synopsys in mainline contribution, so it is part of my job.
>
> I'm the one who does all of the backporting of stmmac bug fixes to
> -stable, so I for one care a lot about this.
>
> You are making more work for me and lots of other people by renaming
> this driver and I don't think you are considering that at all.
>
I understand, it is a lot of work. I volunteer to help.
Joao
^ permalink raw reply
* Re: [PATCH] [net] net/mlx5e: fix another -Wmaybe-uninitialized warning
From: Arnd Bergmann @ 2017-01-12 16:04 UTC (permalink / raw)
To: Or Gerlitz
Cc: Saeed Mahameed, Hadar Hen Zion, David S . Miller, netdev,
linux-kernel
In-Reply-To: <46a85790-2cfe-a8d9-f764-4f736fbd1af7@mellanox.com>
On Thursday, January 12, 2017 5:21:49 PM CET Or Gerlitz wrote:
> On 1/11/2017 11:14 PM, Arnd Bergmann wrote:
> > As found by Olof's build bot, today's mainline kernel gained a harmless
> > warning about a potential uninitalied variable reference:
> >
> > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function 'parse_tc_fdb_actions':
> > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:769:13: warning: 'out_dev' may be used uninitialized in this function [-Wmaybe-uninitialized]
> > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:811:21: note: 'out_dev' was declared here
> >
> > This was introduced through the addition of an 'IS_ERR/PTR_ERR' pair that
> > gcc is unfortunately unable to completely figure out. Replacing it with
> > PTR_ERR_OR_ZERO makes the code more understandable to gcc so it no longer
> > warns.
>
> can you elaborate on this a little further?
The problem is
static int mlx5e_route_lookup_ipv4(struct net_device **out_dev, ...)
{
...
if (IS_ERR(rt))
return PTR_ERR(rt);
*out_dev = ...;
...
}
static int mlx5e_create_encap_header_ipv4(...)
{
...
err = mlx5e_route_lookup_ipv4(..., out_dev, ...);
if (err)
goto out;
e->out_dev = *out_dev;
...
}
I've seen several examples of this, the problem every time is
that gcc cannot tell that if(IS_ERR()) in the first function is
equivalent to if(err) in the second, so it assumes that 'out_dev'
is used here after the first 'return PTR_ERR(rt)'.
The PTR_ERR_OR_ZERO() case by comparison is fairly easy to detect
by gcc, so it can't get that wrong here.
> > Hadar Hen Zion already attempted to fix the warning earlier by adding
> > fake initializations, but that ended up just making the code worse without
> > fully addressing all warnings, so I'm reverting it now that it is no longer needed.
>
> ok, so if your approach eliminates the warning on out_dev and also on
> the variables for which Hadar added the faked initializers, I guess we
> should be fine with this change (saw your reply on my other comment),
Ok.
> just another question:
>
> > In order to avoid pulling a variable declaration into the #ifdef, I'm
> > removing it in favor of a more readable 'if()' statement here that has the same effect.
>
> When I build here without CONFIG_INET in my system, the build goes fine
> with this approach. However, we're pretty sure that in the past we got
> 0-day report from the kbuild test robot where he was unhappy that we
> make the ip_route_output_key call without being wrapped with that #if
> IS_ENABLED(CONFIG_INET) -- so, we don't want to go there again... thoughts?
I went back and forth between the two versions, either leaving the #if
in place, or using the if(IS_ENABLED()) check to be really sure that
we can't get compile error here.
I did check that ip_route_output_key() is always declared, but now
I see that net/route.h might not always be included from en_tc.c
if CONFIG_INET is disabled (I don't see how it gets included, but
it obviously is when CONFIG_INET is turned on).
Adding an explicit include of that file should probably avoid the
case you ran into earlier, but for I agree it's safer to not rely
on that here for a bugfix, and just leave the #ifdef. Do you want to
modify it yourself, or should I spin a new version with that?
Arnd
^ permalink raw reply
* Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request
From: David Miller @ 2017-01-12 16:04 UTC (permalink / raw)
To: horms; +Cc: sergei.shtylyov, magnus.damm, netdev, linux-renesas-soc
In-Reply-To: <20170112154647.GA2329@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Thu, 12 Jan 2017 16:46:47 +0100
> What I now see is that a few lines further up there is:
>
> if (skb_put_padto(skb, ETH_ZLEN))
> goto drop;
>
> where ETH_ZLEN is 60.
>
> So I don't think we need to worry about skb->len being less than 60 and
> this patch can be simplified to:
>
> if (len == 0)
> len = 4;
I'd say this might deserve a comment...
^ permalink raw reply
* Re: [PATCH] synopsys: remove dwc_eth_qos driver
From: David Miller @ 2017-01-12 16:03 UTC (permalink / raw)
To: Joao.Pinto
Cc: lars.persson, niklass, peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <066a57f3-29b5-c297-cd67-d9c937b9c9d9@synopsys.com>
From: Joao Pinto <Joao.Pinto@synopsys.com>
Date: Thu, 12 Jan 2017 15:54:39 +0000
> I know that changing what is working properly is a risk, I totally understand,
> and if I was a top maintainer I would have the same concern
I'm not saying you risk breaking anything.
I'm saying you will make backporting bug fixes to older releases for
me and every distribution maintainer unreasonably difficult.
^ permalink raw reply
* Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
From: David Sterba @ 2017-01-12 15:57 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Colin Cross, Hariprasad S, Santosh Raspatur,
Kees Cook, Johannes Weiner, Heiko Carstens, Martin Schwidefsky,
Anton Vorontsov, Eric Dumazet, Ilya Dryomov, Kent Overstreet,
Herbert Xu, David Rientjes, Andreas Dilger, Dan Williams,
Oleg Drokin, Tony Luck, Alexei Starovoitov, linux-mm,
Tariq Toukan, Yishai Hadas, Boris Ostrovsky
In-Reply-To: <20170112153717.28943-6-mhocko@kernel.org>
On Thu, Jan 12, 2017 at 04:37:16PM +0100, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> There are many code paths opencoding kvmalloc. Let's use the helper
> instead. The main difference to kvmalloc is that those users are usually
> not considering all the aspects of the memory allocator. E.g. allocation
> requests < 64kB are basically never failing and invoke OOM killer to
> satisfy the allocation. This sounds too disruptive for something that
> has a reasonable fallback - the vmalloc. On the other hand those
> requests might fallback to vmalloc even when the memory allocator would
> succeed after several more reclaim/compaction attempts previously. There
> is no guarantee something like that happens though.
>
> This patch converts many of those places to kv[mz]alloc* helpers because
> they are more conservative.
For the btrfs bits,
Acked-by: David Sterba <dsterba@suse.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request
From: Sergei Shtylyov @ 2017-01-12 15:56 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <1484229217-25585-1-git-send-email-horms+renesas@verge.net.au>
On 01/12/2017 04:53 PM, Simon Horman wrote:
> From: Masaru Nagai <masaru.nagai.vx@renesas.com>
>
> Due to alignment requirements of the hardware transmissions are split
> into two DMA requests,
Rather DMA descriptors.
> a small padding request of 0 - 4 bytes in length
0..3 currently.
> followed by the a request for rest of the packet.
>
> In the case of IP packets the first request will never be zero due
> to the way that the stack aligns buffers for IP packets. However, for
> non-IP packets it may be zero.
>
> In this case it has been reported that timeouts occur, presumably because
> transmission stops at the first zero-length DMA request and thus the packet
> is not transmitted. However, in my environment a BUG is triggered as
> follows:
>
> [ 20.381417] ------------[ cut here ]------------
> [ 20.386054] kernel BUG at lib/swiotlb.c:495!
> [ 20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [ 20.395805] Modules linked in:
> [ 20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f #162
> [ 20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
> [ 20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
> [ 20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
> [ 20.424625] LR is at map_single+0x4c/0x98
> [ 20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
> [ 20.436019] sp : ffff80063a71f9b0
> [ 20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
> [ 20.444636] x27: ffff000008ed5000 x26: 0000000000000000
> [ 20.449944] x25: 000000067abe2adc x24: 0000000000000000
> [ 20.455252] x23: 0000000000200000 x22: 0000000000000001
> [ 20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
> [ 20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
> [ 20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
> [ 20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
> [ 20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
> [ 20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
> [ 20.492407] x9 : 0000000000000000 x8 : 0000000000000000
> [ 20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
> [ 20.503028] x5 : 0000000000000000 x4 : 0000000000000001
> [ 20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
> [ 20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
> [ 20.518958]
> [ 20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
> [ 20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
> [ 20.532543] f9a0: ffff80063a71fa30 ffff00000839c680
> [ 20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
> [ 20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
> [ 20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
> [ 20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
> [ 20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
> [ 20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
> [ 20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
> [ 20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
> [ 20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
> [ 20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
> [ 20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
> [ 20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
> [ 20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
> [ 20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
> [ 20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
> [ 20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
> [ 20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
> [ 20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
> [ 20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
> [ 20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
> [ 20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
> [ 20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
> [ 20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
> [ 20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
> [ 20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
> [ 20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
> [ 20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
> [ 20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
> [ 20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
> [ 20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
> [ 20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
> [ 20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
> [ 20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
> [ 20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
> [ 20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
> [ 20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
> [ 20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
> [ 20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
> [ 20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
> [ 20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
> [ 20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
> [ 20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
> [ 20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
> [ 20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
> [ 20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
> [ 20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
> [ 20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
> [ 20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
> [ 20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
> [ 20.931867] Call trace:
> [ 20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
> [ 20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
> [ 20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
> [ 20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
> [ 20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
> [ 20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
> [ 20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
> [ 20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
> [ 20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
> [ 21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
> [ 21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
> [ 21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
> [ 21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
> [ 21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
> [ 21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
> [ 21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
> [ 21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
> [ 21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
> [ 21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
> [ 21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
> [ 21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
> [ 21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
> [ 21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
> [ 21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
> [ 21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
> [ 21.094611] ---[ end trace 5bc544ad491f3814 ]---
> [ 21.099234] Kernel panic - not syncing: Fatal exception in interrupt
> [ 21.105587] Kernel Offset: disabled
> [ 21.109073] Memory Limit: none
> [ 21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
>
> Fixes: 2f45d1902acf ("ravb: minimize TX data copying")
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> v1 [Simon Horman]
> * rewrote changelog
> * handle skb->len < 4
>
> v0 [Kazuya Mizuguchi]
Not Masaru Nagai?
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 92d7692c840d..3b4d2504285e 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1508,6 +1508,8 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> buffer = PTR_ALIGN(priv->tx_align[q], DPTR_ALIGN) +
> entry / NUM_TX_DESC * DPTR_ALIGN;
> len = PTR_ALIGN(skb->data, DPTR_ALIGN) - skb->data;
> + if (len == 0)
> + len = skb->len > 4 ? 4 : skb->len;
This indeed can be simply 4.
[...]
MBR, Sergei
^ 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