[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171004.213758.2210486785503998906.davem@davemloft.net>
Date: Wed, 04 Oct 2017 21:37:58 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: herbert@...dor.apana.org.au
Cc: marcelo.leitner@...il.com, luto@...nel.org, baijiaju1990@....com,
nhorman@...driver.com, vyasevich@...il.com, kvalo@...eaurora.org,
linux-crypto@...r.kernel.org, netdev@...r.kernel.org,
linux-sctp@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned
From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Thu, 5 Oct 2017 11:40:54 +0800
> On Tue, Oct 03, 2017 at 07:45:06PM -0300, Marcelo Ricardo Leitner wrote:
>>
>> > Usually if you're invoking setkey from a non-sleeping code-path
>> > you're probably doing something wrong.
>>
>> Usually but not always. There are 3 calls to that function on SCTP
>> code:
>> - pack a cookie, which is sent on an INIT_ACK packet to the client
>> - unpack the cookie above, after it is sent back by the client on a
>> COOKIE_ECHO packet
>> - send a chunk authenticated by a hash
>
> I'm not talking about the code-path in question. I'm talking
> about the function which generates the secret key in the first
> place. AFAICS that's only called in GFP_KERNEL context. What
> am I missing?
The setkey happens in functions like sctp_pack_cookie() and
sctp_unpack_cookie(), which seems to run from software interrupts.
Powered by blists - more mailing lists