ntly see how this is bypassing that check. But
clearly it has found a way through the check since it's crashing.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
nted 4.14.0-rc4+ #80
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> task: 8801d4ecc1c0 task.stack: 8801c13f8000
> RIP: 0010:pfkey_xfrm_policy2msg+0x209c/0x22b0 net/key/af_key.c:2068
This shows that you have a xfrm policy that
ast tests the crypto users via testmgr and
> tcrypt but I do note that I do not have access to some
> of the HW whose drivers are modified nor do I claim I was
> able to test all of the corner cases.
>
> The patch set is based upon linux-next release tagged
> next-20171017.
All a
On Sun, Oct 08, 2017 at 01:37:18PM +0530, Harsh Jain wrote:
> From: Yeshaswi M R Gowda <yesha...@chelsio.com>
>
> Remove unused parameter sent to latest fw.
>
> Signed-off-by: Harsh Jain <ha...@chelsio.com>
All applied. Thanks.
--
Email: Herbert Xu <herb...@
t;
> Hopefully the situation where the FPU is not available is rare enough
> So it won't hurt the performance too much.
For your intended use case I think async processing should work just
fine as it does for IPsec.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page:
On Tue, Oct 31, 2017 at 07:23:35AM +, Ilya Lesokhin wrote:
> On Tuesday, October 31, 2017 9:17 AM, Herbert Xu wrote:
> >
> > Users of the crypto API shouldn't need to check irq_fpu_usable().
> > The crypto API should work regardless of what context you're in.
>
&g
t need to check irq_fpu_usable().
The crypto API should work regardless of what context you're in.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
fm from atomic context? That is not allowed.
Normally you would allocate the tfm in process context, e.g., when
the connection is setup.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Oct 26, 2017 at 07:51:06AM -0500, Gustavo A. R. Silva wrote:
> Use BUG_ON instead of if condition followed by BUG in esp_remove_trailer.
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com>
Acked
info(r_skb, net, sportid, seq, *flags);
BUG_ON(err < 0);
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
er(struct sk_buff *skb)
> goto out;
> }
>
> - if (skb_copy_bits(skb, skb->len - alen - 2, nexthdr, 2))
> - BUG();
> + BUG_ON(skb_copy_bits(skb, skb->len - alen - 2, nexthdr, 2));
How about
ret = skb_copy_bits(skb, skb->len - alen
ke
int err;
err = ;
BUG_ON(err);
Having real code in BUG_ON may pose problems to people reading the
code because some of us tend to ignore code in BUG_ON and similar
macros such as BUILD_BUG_ON.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gond
BUG_ON(cond);
rather than just
BUG_ON(code_that_does_something());
But maybe it's just me.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Mon, Oct 23, 2017 at 10:50:43PM -0500, Gustavo A. R. Silva wrote:
>
> Quoting Herbert Xu <herb...@gondor.apana.org.au>:
>
> >On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote:
> >>Use BUG_ON instead of if condition followed by BUG.
&g
rrible. Why on earth is Coccinelle even
warning about this?
If anything we should be converting these constructs to not use
BUG.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
arget socket's receive
buffer is full.
This patch fixes it by using the cb->start mechanism to ensure that
the initialisation is always done regardless of the buffer situation.
Fixes: 12a169e7d8f4 ("ipsec: Put dumpers on the dump list")
Signed-off-by: Herbert Xu <herb...@gondor.apana.
On Thu, Oct 19, 2017 at 05:26:25PM +0800, Herbert Xu wrote:
>
> So it's an netlink API issue. It is possible for cb->done to be
> called without cb->dump ever being called. And xfrm_user doesn't
> deal with that. Let me survey the others to see whether we should
> fix
On Tue, Oct 17, 2017 at 02:55:21PM +0300, Gilad Ben-Yossef wrote:
>
> Would you mind if we used ENOSPC instead of E2BIG?
>
> "No space left on device" seems more appropriate than
> "Argument list too long".
It's fine by me.
Thanks,
--
Email: Herbert Xu <
On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote:
>
> Changes from v8:
> - Remove the translation of EAGAIN return code to the
> previous return code of EBUSY for the user space
> interface of algif as no one seems to rely on it as
> requested by Herbert
On Sat, Oct 07, 2017 at 10:51:42AM +0300, Gilad Ben-Yossef wrote:
> On Sat, Oct 7, 2017 at 6:05 AM, Herbert Xu <herb...@gondor.apana.org.au>
> wrote:
> > On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
> >>
> >> diff --git a/crypto/algif_has
Allen Pais <allen.l...@gmail.com> wrote:
> Signed-off-by: Allen Pais <allen.l...@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ever to the user, do the translation here.
> + */
> +static inline int crypto_user_err(int err)
> +{
> + if (err == -EAGAIN)
> + return -EBUSY;
> +
> + return err;
I don't see the need to carry along this baggage. Does anyone
in user-space actually rely on EBUSY?
C
On Thu, Oct 05, 2017 at 06:16:20PM +0800, Herbert Xu wrote:
>
> That was my point. Functions like sctp_pack_cookie shouldn't be
> setting the key in the first place. The setkey should happen at
> the point when the key is generated. That's sctp_endpoint_init
> which AFAICS o
t when the key is generated. That's sctp_endpoint_init
which AFAICS only gets called in GFP_KERNEL context.
Or is there a code-path where sctp_endpoint_init is called in
softirq context?
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PG
enerates the secret key in the first
place. AFAICS that's only called in GFP_KERNEL context. What
am I missing?
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
or every hashing operation. But so far these are uses have
been very few so there has been no need to provide an API for them.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ould
stay there.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
API, rather
than touching actual crypto API code, I think you should handle it
as you do with any other wireless patch.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
gt;
> This patch replaces the continue with a goto and label to ensure a
> matching call to rhashtable_walk_stop().
>
> Signed-off-by: Bob Peterson <rpete...@redhat.com>
Acked-by: Herbert Xu <herb...@gondor.apana.org.au>
Thanks for catching this!
--
Email: Herbert Xu <he
field.
>
> Fixes: f4a3e90ba5739 ("rhashtable-test: extend to test concurrency")
> Reported by: Manuel Messner <m...@skelett.io>
> Signed-off-by: Phil Sutter <p...@nwl.cc>
Acked-by: Herbert Xu <herb...@gondor.apana.org.au>
--
Email: Herbert Xu <he
On Tue, Jul 11, 2017 at 01:31:14PM -0700, David Miller wrote:
>
> Acked-by: David S. Miller <da...@davemloft.net>
>
> Looks good, is this going via my tree or your's?
I'll push it along. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gond
ly redundant because all the work
it does is subsumed by sock_init_data. However, it was added
to placate SELinux as it uses it to initialise its internal state.
This patch avoisd the warning by making the SELinux call directly.
Reported-by: Linus Torvalds <torva...@linux-foundation.
cket leak, this time in
> AF_ALG.
Hmm, I can't see the problem in af_alg_accept. The struct socket
comes directly from sys_accept() which creates it using sock_alloc.
So the only thing I can think of is that the memory returned by
sock_alloc is not zeroed and therefore the WARN_ON is just
2k
> Atul Gupta (2):
> chcr - Add debug counters
> crypto: chcr - Select device in Round Robin fashion
All applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
RCU_INIT_POINTER(plist->next, list);
Your second RCU_INIT_POINTER needs to be rcu_assign_pointer.
Your approach of retaining the first duplicate object as the head
of the list should work too but I don't really see any point in
changing this.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
algorithm to the crypto API.
>
> With these patches, performance of MACsec on a single core increases
> by 40% (from 4.5Gbps to around 6.3Gbps).
All patches applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote:
>
>
> On 28/04/17 12:30 AM, Herbert Xu wrote:
> > You are right. Indeed the existing code looks buggy as they
> > don't take sg->offset into account when doing the kmap. Could
> > you send me some p
way with
https://patchwork.ozlabs.org/patch/756233/
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Apr 27, 2017 at 09:45:57AM -0600, Logan Gunthorpe wrote:
>
>
> On 26/04/17 09:56 PM, Herbert Xu wrote:
> > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
> >> Very straightforward conversion to the new function in the caam driver
> >> an
ctly set
to zero instead of 2^31.
This patch fixes it by only lowering max_elems when max_size is not
zero.
Fixes: 6d684e54690c ("rhashtable: Cap total number of entries to 2^31")
Reported-by: Florian Fainelli <f.faine...@gmail.com>
Reported-by: kernel test robot <feng
No that doesn't do the same thing. Setting max_size caps the table
size and I don't want to do that at all.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
t be safer to move the freeing from the destructors
into their ndo_uninit functions instead?
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
This is set to 2^31 as nelems is
not a precise count. This is sufficiently smaller than UINT_MAX
that it should be safe.
When max_size is set max_elems will be lowered to at most twice
max_size as is the status quo.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
diff --git a/include/lin
On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
> Very straightforward conversion to the new function in the caam driver
> and shash library.
>
> Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
> Cc: Herbert Xu <herb...@gondor.apana.org.au>
its size further).
I see at least one hole on 64-bit which means that you can fit
it into struct rhashtable for free.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ime we insert
an element that you keep the value in struct rhashtable, but as an
internal value as opposed to a paramter that is set by the user.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ou can put ca116922afa8 in the body of the commit
description.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
lled in
your case, then you'll need to start debugging the kernel work
queue mechanism to see why macvlan_process_broadcast is not getting
called.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
56].
> chcr: Add fallback for AEAD algos
> Atul Gupta (1):
> chcr: Fix txq ids
All applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
isn't used anywhere, just get rid of it.
> xfrm_dst->partner isn't used either, so get rid of that too.
>
> Fixes: ca116922afa8 ("xfrm: Eliminate "fl" and "pol" args to
> xfrm_bundle_ok().")
The commit you refer to here doesn't seem to have caused
On Thu, Apr 20, 2017 at 12:50:29PM +0200, Steffen Klassert wrote:
> On Thu, Apr 20, 2017 at 05:52:35PM +0800, Herbert Xu wrote:
> > On Thu, Apr 20, 2017 at 11:17:52AM +0200, Steffen Klassert wrote:
> > >
> > > I tried to use async algorithms but it lead to serveral pr
rocess the broadcast
queue, thus removing any reference counts held.
It's only when the queue is purged that we run into trouble.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
free for...")
Reported-by: Joe Ghalam <joe.gha...@dell.com>
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 9261722..b34eaaa 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -1139,6
s if the driver is busy etc.
Why would we need to requeue? As it is if you get an EBUSY on
an IPsec packet it's simply dropped.
The main AES implementation on x86 is now async so I think it's
pretty important that we support it out-of-the-box.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana
here we know the final output device
> but can't handle asynchronous returns fron the crypto layer.
Can you explain why we can't handle async algorithms on the fallback
path?
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http:
rcounted first
of all as it includes the header itself. It also fails to check
the length before dereferencing the sa_family field.
This patch fixes those problems in parse_sockaddr_pair and then
uses it in parse_ipsecrequest.
Reported-by: Andrey Konovalov <andreyk...@google.com>
Signed-off-by: Herbert Xu
names. That is beyond the scope of this
patch.
For names shorter than 64 bytes the existing API needs be respected
and user-space must pad it to exactly 64 bytes.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
raise
the value of CRYPTO_MAX_ALG_NAME.
Furthermore, the code has been updated to handle names longer than
the user-space API. They will be truncated.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
crypto/crypto_user.c| 18 +-
include/uapi
erd...@nokia.com>
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
include/linux/crypto.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index c0b0cf3..84da997 100644
--- a/include/linux/crypto.h
+++ b/include/li
This patch fixes the xfrm_user code to use the actual array size
rather than the hard-coded CRYPTO_MAX_ALG_NAME length. This is
because the array size is fixed at 64 bytes while we want to increase
the in-kernel CRYPTO_MAX_ALG_NAME value.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org
-by: Herbert Xu <herb...@gondor.apana.org.au>
---
crypto/af_alg.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 690deca..3556d8e 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -160,11 +160,11 @@ static int alg_bind(
w allows arbitrarily long names.
As the final patch depends on all three it would be easiest if
we pushed the xfrm patch through the crypto tree. Steffen/David?
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
probably go via your crypto tree.
Thanks David. It's already in the crypto tree.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ly call list_add_tail on
> them at the same time. The fix is thus be hoist that lock outside of
> that block.
>
> Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Mon, Mar 20, 2017 at 02:23:57PM +0100, Peter Zijlstra wrote:
>
> So what bench/setup do you want ran?
You can start by counting how many cycles an atomic op takes
vs. how many cycles this new code takes.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Hom
hange you should
demonstrate that it does not cause a performance regression.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
CONFIG_DEBUG_REFCOUNT. So the performance (and code
> size!) with CONFIG_DEBUG_REFCOUNT=n is unaltered from present code.
> And make CONFIG_DEBUG_REFCOUNT suitably difficult to set.
I agree. Refcounts are used in many performance-critical sites
within the network subsystem.
Thanks,
--
Email: Herber
...
I completely agree. I think this thing needs to default to the
existing atomic_t behaviour.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
rted-by: Dmitry Vyukov <dvyu...@google.com>
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 7b73c7c..596eaff 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -96,6 +96,44 @@ static i
43
> >___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
> >__sys_sendmsg+0x138/0x300 net/socket.c:2019
> >SYSC_sendmsg net/socket.c:2030 [inline]
> >SyS_sendmsg+0x2d/0x50 net/socket.c:2026
> >entry_SYSCALL_64_fastpath+0x1f/0xc2
Ditto. Please disregard any reports involving genl_mutex and
cb_mutex where the latter comes from crypto_user.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
entry_SYSCALL_64_fastpath+0x1f/0xc2
This looks like a false positive. The cb_mutex in #1 is not the
same as the cb_mutex in #0. The cb_mutex in #0 comes is obtained
by crypto_user which uses straight netlink. The cb_mutex in #1
is a genl netlink socket.
I'll have a look to see if we can annotate this.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ing
> this ifdef to the generic networking code.
It's not that simple though. IPComp's header_len is set to zero
because we opportunistically drop the IPComp header when the total
compressed length exceeds the original packet length. That is,
we only ever do IPComp when it does not cause the packet
On Thu, Feb 16, 2017 at 03:17:03PM +0300, Dan Carpenter wrote:
> Hello Herbert Xu,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 40137906c5f5: "rhashtable: Add nested tables" from Feb 11,
> 2017, leads to the followin
On Sat, Feb 18, 2017 at 01:23:31PM +0800, Fengguang Wu wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://github.com/0day-ci/linux
> Herbert-Xu/rhashtable-Handle-table-allocation-failure-during-insertion/20170212-
table for glocks")
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
fs/gfs2/glock.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 94f50ca..70e9417 100644
--- a/fs/gfs2/glock.c
+++ b
with this by introducing nested tables.
The first two patches removes manual hash table walks which cannot
work on a nested table.
The final patch introduces nested tables.
I've tested this with test_rhashtable and it appears to work.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page
of change rhashtable this way, I'm going
> to let these changes sit for a couple days before applying them.
No problems. Good thing too as the lkp found a bug in my RCU
annotation. So I will send a v2 with that fixed.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Pa
. Also,
the rehash code will never rehash into a nested table. If we
detect a nested table during a rehash, the rehash will be aborted
and a new rehash will be scheduled.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
include/linux/rhashtable.h | 78 +
lib/rhasht
used
spinlocks which provide the barriers implicitly.
This patch fixes both problems.
Fixes: 07f6c4bc048a ("tipc: convert tipc reference table to...")
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
Acked-by: Ying Xue <ying@windriver.com>
---
net/tipc/net.c
te).
Yes insecure_elasticity is now obsolete and anyone using it should
switch over to rhlist. Once nobody uses it then it can be removed.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
we'd be much better off just failing
them than sticking them on what will essentially be a linked list.
As people don't like insertion failure, I think this level of
complexity is justified.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.
table for glocks")
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
fs/gfs2/glock.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 94f50ca..70e9417 100644
--- a/fs/gfs2/glock.c
+++ b
. Also,
the rehash code will never rehash into a nested table. If we
detect a nested table during a rehash, the rehash will be aborted
and a new rehash will be scheduled.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
include/linux/rhashtable.h | 78 +
lib/rhasht
used
spinlocks which provide the barriers implicitly.
This patch fixes both problems.
Fixes: 07f6c4bc048a ("tipc: convert tipc reference table to...")
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
net/tipc/net.c|4
net/tipc
.
The final patch introduces nested tables.
I've tested this with test_rhashtable and it appears to work.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
explanation. I see what it's protecting now. And
this could indeed be responsible for the race that Oleg reported.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
The comment says that it's pairing with an mb in tcp_poll, but
tcp_poll doesn't touch QUEUE_SHRUNK at all. So what exactly is
this barrier for?
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
; crypto:chcr-Fix Smatch Complaint
All applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
to:chcr- Check device is allocated before use
> Julia Lawall (1):
> crypto:chcr-fix itnull.cocci warnings
Patches 2 and 3 look critical, but the other ones do not. Please
don't mix fixes targeted for this cycle with other patches.
Please resubmit them as two separate series.
Thanks,
into 4.10/4.11 and then resubmit.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
on KASAN.
>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Herbert Xu <herb...@gondor.apana.org.au>
> Signed-off-by: Andy Lutomirski <l...@kernel.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondo
/linux/kernel/git/herbert/cryptodev-2.6.git
> master
> In-Reply-To:
> <8e0086b56d8fb61637d179c32a09a1bca03c4186.1483599449.git.ha...@chelsio.com>
Harsh, please fold this patch into your series when you resubmit.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Pag
ty
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 <herb...@gondor.apana.org.au>
Home Page: http:
amp;
> + 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 <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
lue then we have u128 in crypto/b128ops.h
that could be generalised for this.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
N.
>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Herbert Xu <herb...@gondor.apana.org.au>
> Signed-off-by: Andy Lutomirski <l...@kernel.org>
This patch doesn't seem to depend on anything else in the series.
Do you want me to take it separately?
Cheers
On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
>
> According to Daniel, the networking folks want to let embedded systems
> include BPF without requiring the crypto core.
Last I checked the IPv4 stack depended on the crypto API so this
sounds bogus.
Cheers,
--
Email
irectly
rather than through the crypto API?
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
h on average? If it's a large
amount then perhaps using the existing crypto API would be a better
option than adding this.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ecessary, but in most cases nothing is done, and so
> things just leak over time.
Actually those users that use rhashtable now have a much more
sophisticated defence against these attacks, dyanmic rehashing
when bucket length exceeds a preset limit.
Cheers,
--
Email: Herbert Xu <herb...@gon
101 - 200 of 2197 matches
Mail list logo
