On Mon, Sep 25, 2017 at 07:22:26AM +0200, Johannes Berg wrote:
>
> The code moves to crypto/ though, and I'm not even sure I can vouch for
> the Makefile choice there.
Thanks, I missed that. I don't think this belongs in crypto.
This proposed helper is only useful for wireless so it should
stay
On Mon, 2017-09-25 at 12:56 +0800, Herbert Xu wrote:
> On Sun, Sep 24, 2017 at 07:42:46PM +0200, Johannes Berg wrote:
> >
> > Unrelated to this, I'm not sure whose tree this should go through -
> > probably Herbert's (or DaveM's with his ACK? not sure if there's a
> > crypto tree?) or so?
>
> Sin
On Sun, Sep 24, 2017 at 07:42:46PM +0200, Johannes Berg wrote:
>
> Unrelated to this, I'm not sure whose tree this should go through -
> probably Herbert's (or DaveM's with his ACK? not sure if there's a
> crypto tree?) or so?
Since you're just rearranging code invoking the crypto API, rather
than
Arnd Bergmann writes:
> With KASAN and a couple of other patches applied, this driver is one
> of the few remaining ones that actually use more than 2048 bytes of
> kernel stack:
>
> broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function
> 'wlc_phy_workarounds_nphy_gainctrl':
> broadcom/brcm80211/
Andrey Konovalov writes:
> I've got the following report while fuzzing the kernel with syzkaller.
>
> On commit 6e80ecdddf4ea6f3cd84e83720f3d852e6624a68 (Sep 21).
>
> ==
> BUG: KASAN: use-after-free in __run_timers+0xc0e/0xd40
> Writ
Arend van Spriel writes:
> Please use 'brcmsmac:' as prefix instead of 'brcm80211:'.
I can fix that.
--
Kalle Valo
ath9k hardware claims to support up to 4 MSI vectors, and when run in
that configuration, it would be allowed to modify the lower bits of the
MSI Message Data when generating interrupts in order to signal which
of the 4 vectors the interrupt is being raised on.
Linux's PCI-MSI irqchip only support
2017-09-24 13:42 GMT-04:00 Johannes Berg :
> On Sun, 2017-09-24 at 13:21 -0400, Xiang Gao wrote:
>>
>> Do you mean to put more characters each line in the description
>>
> Huh, sorry, no - my bad. I was thinking of the code, not the
> description at all.
Oh yes, these indentation do looks ugly. Th
On Sun, 2017-09-24 at 13:21 -0400, Xiang Gao wrote:
>
> Do you mean to put more characters each line in the description
>
Huh, sorry, no - my bad. I was thinking of the code, not the
description at all.
For example here:
> -int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad
2017-09-24 11:05 GMT-04:00 Johannes Berg :
> 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
>> h
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
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
12 matches
Mail list logo
