Hi Eric,
On Fri, Sep 28, 2018 at 6:55 AM Eric Biggers wrote:
> And you still haven't answered my question about adding a new algorithm that
> is
> useful to have in both APIs. You're proposing that in most cases the crypto
> API
> part will need to go through Herbert while the implementation w
On Sat, Sep 22, 2018 at 08:41:55PM -0400, Waiman Long wrote:
> The following KASAN warning was printed when booting a 64-bit kernel
> on some systems with Intel CPUs:
>
> [ 44.512826]
> ==
> [ 44.520165] BUG: KASAN: stack-out-of-
On Fri, Sep 21, 2018 at 06:03:18PM +0300, Leonard Crestez wrote:
> When compiling with CONFIG_DEBUG_ATOMIC_SLEEP=y the mxs-dcp driver
> prints warnings such as:
>
> WARNING: CPU: 0 PID: 120 at kernel/sched/core.c:7736 __might_sleep+0x98/0x9c
> do not call blocking ops when !TASK_RUNNING; state=1 s
On Thu, Sep 20, 2018 at 05:57:16PM +0800, zhong jiang wrote:
> kfree_skb has taken the null pointer into account. hence it is safe
> to remove the redundant null pointer check before kfree_skb.
>
> Signed-off-by: zhong jiang
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor
On Fri, Sep 21, 2018 at 09:30:15PM +0800, zhong jiang wrote:
> kfree has taken the null pointer into account. hence it is safe
> to remove the redundant null pointer check before kfree.
>
> Signed-off-by: zhong jiang
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.o
On Fri, Sep 21, 2018 at 05:08:00PM +0530, Srikanth Jampala wrote:
> Get the device partname based on it's capabilities like,
> core frequency, number of cores and revision id.
>
> Signed-off-by: Srikanth Jampala
> ---
> drivers/crypto/cavium/nitrox/nitrox_csr.h | 111 +
> dr
On Thu, Sep 20, 2018 at 02:18:37PM +0100, Gilad Ben-Yossef wrote:
> Add OFB mode generic implementation and more SM4 tests
>
> Gilad Ben-Yossef (3):
> crypto: testmgr: update sm4 test vectors
> crypto: add output feedback mode
> crypto: tcrypt: add OFB functional tests
>
> crypto/Kconfig
On Wed, Sep 19, 2018 at 10:42:16PM +0530, Harsh Jain wrote:
> Update PCI Id in "cpl_rx_phys_dsgl" header. In case pci_chan_id and
> tx_chan_id are not derived from same queue, H/W can send request
> completion indication before completing DMA Transfer.
>
> Herbert, It would be good if fix can be m
On Wed, Sep 19, 2018 at 05:54:21PM +0300, Horia Geantă wrote:
> Commit 110492183c4b ("crypto: compress - remove unused pcomp interface")
> removed pcomp interface but missed cleaning up tcrypt.
>
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondo
On Wed, Sep 19, 2018 at 10:10:53AM +, Corentin Labbe wrote:
> This patch is a try to implement a generic crypto driver statistics.
> The goal is to have an "ifconfig" for crypto device.
>
> Some driver tried to implement this via a debugfs interface.
>
> This serie do it directly in the crypt
On Tue, Sep 18, 2018 at 07:10:37PM -0700, Kees Cook wrote:
> This is the full follow-up to earlier discussions[1] that suggested
> adding a new struct crypto_sync_skcipher to handle the VLA removal from
> SKCIPHER_REQUEST_ON_STACK.
>
> This series is effectively a no-op change: everything is a wra
On Mon, Sep 17, 2018 at 05:09:26PM +0200, Christoph Manszewski wrote:
> Hello,
>
> This patch series adds aes-ctr support in s5p-sss.c driver. Additionally it
> it provides a fix, and a minor code cleanup.
>
> Patch 1 contains a simple fix, of a possible race condition.
> Patches 2-3 are code cle
On Mon, Sep 17, 2018 at 08:24:32PM +0300, Dan Aloni wrote:
> The encryption mode of pkcs1pad never uses out_sg and out_buf, so
> there's no need to allocate the buffer, which presently is not even
> being freed.
>
> CC: Herbert Xu
> CC: linux-crypto@vger.kernel.org
> CC: "David S. Miller"
> Sign
Hi Jason,
On Fri, Sep 28, 2018 at 04:35:48AM +0200, Jason A. Donenfeld wrote:
> Hi Eric,
>
> On Thu, Sep 27, 2018 at 06:17:27PM -0700, Eric Biggers wrote:
> > So, Zinc will simultaneously replace the current crypto implementations,
> > *and*
> > be "orthogonal" and "separate" from all the crypto
Hi Eric,
On Thu, Sep 27, 2018 at 06:17:27PM -0700, Eric Biggers wrote:
> So, Zinc will simultaneously replace the current crypto implementations, *and*
> be "orthogonal" and "separate" from all the crypto code currently maintained
> by
> Herbert? You can't have your cake and eat it too...
The p
On Thu, Sep 27, 2018 at 11:35:39PM +0200, Jason A. Donenfeld wrote:
> Hi Eric,
>
> On Thu, Sep 27, 2018 at 8:29 PM Eric Biggers wrote:
> > Why is Herbert Xu's existing crypto tree being circumvented, especially for
> > future patches (the initial merge isn't quite as important as that's a
> > on
On Fri, Sep 28, 2018 at 12:37 AM Jason A. Donenfeld wrote:
> Will do. v7 will include the wg_ prefix.
$ nm *.o | while read a b c; do [[ $b == T ]] && echo $c; done | grep -v ^wg_
cleanup_module
init_module
Success.
Hi Andrew,
Thanks for following up with this.
On Thu, Sep 27, 2018 at 3:15 AM Andrew Lunn wrote:
> I know you have been concentrating on the crypto code, so i'm not
> expecting too many changes at the moment in the network code.
I should be addressing things in parallel, actually, so I'm happy
Hi Eric,
On Thu, Sep 27, 2018 at 8:29 PM Eric Biggers wrote:
> Why is Herbert Xu's existing crypto tree being circumvented, especially for
> future patches (the initial merge isn't quite as important as that's a
> one-time
> event)? I like being able to check out cryptodev to test upcoming cryp
št 27. 9. 2018 o 0:50 napísal(a):
> sparse complains thusly:
>
> CHECK arch/x86/crypto/morus640-sse2-glue.c
> arch/x86/crypto/morus640-sse2-glue.c:38:1: warning: symbol
> 'crypto_morus640_sse2_algs' was not declared. Should it be static?
> CHECK arch/x86/crypto/morus1280-sse2-glue.c
> arc
On Tue, Sep 25, 2018 at 04:55:59PM +0200, Jason A. Donenfeld wrote:
>
> It is intended that this entire patch series enter the kernel through
> DaveM's net-next tree. Subsequently, WireGuard patches will go through
> DaveM's net-next tree, while Zinc patches will go through Greg KH's tree.
>
Why
On Thu, Sep 27, 2018 at 6:27 PM Andy Lutomirski wrote:
> I would add another consideration: if you can get better latency with
> negligible overhead (0.1%? 0.05%), then that might make sense too. For
> example, it seems plausible that checking need_resched() every few blocks
> adds basically no
> On Sep 27, 2018, at 8:19 AM, Jason A. Donenfeld wrote:
>
> Hey again Thomas,
>
>> On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote:
>>
>> Hi Thomas,
>>
>> I'm trying to optimize this for crypto performance while still taking
>> into account preemption concerns. I'm having a bit o
Hey again Thomas,
On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote:
>
> Hi Thomas,
>
> I'm trying to optimize this for crypto performance while still taking
> into account preemption concerns. I'm having a bit of trouble figuring
> out a way to determine numerically what the upper bounds
Hi Thomas,
I'm trying to optimize this for crypto performance while still taking
into account preemption concerns. I'm having a bit of trouble figuring
out a way to determine numerically what the upper bounds for this
stuff looks like. I'm sure I could pick a pretty sane number that's
arguably oka
On Thu, Sep 27, 2018 at 10:35:48AM +0200, Ard Biesheuvel wrote:
> (+ Stefan)
>
> On Wed, 26 Sep 2018 at 22:24, syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:739d0def85ca Merge branch 'hv_netvsc-Support-LRO-RSC-in-th..
> > git tree: net-n
(+ Stefan)
On Wed, 26 Sep 2018 at 22:24, syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:739d0def85ca Merge branch 'hv_netvsc-Support-LRO-RSC-in-th..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1146ffae40
> kerne
27 matches
Mail list logo
