Re: [PATCH v20 3/7 RESEND] xbitmap: add more operations

On 12/21/2017 10:37 PM, Tetsuo Handa wrote: Matthew Wilcox wrote: +/** + * xb_find_set - find the next set bit in a range of bits + * @xb: the xbitmap to search from + * @offset: the offset in the range to start searching + * @size: the size of the range + * + * Returns: the found bit or, @size

Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests

On Fri, Dec 22, 2017 at 09:41:48AM +0100, Corentin Labbe wrote: > > It's you that was suggesting using crypto_async_request: > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html > "The only wart with this scheme is that the drivers end up seeing > struct crypto_async_request

Re: [PATCH v20 3/7 RESEND] xbitmap: add more operations

On 12/22/2017 05:03 AM, Matthew Wilcox wrote: OK, here's a rewrite of xbitmap. Compared to the version you sent: - xb_find_set() is the rewrite I sent out yesterday. - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find clear bits. This led to me finding a bug in

Re: [PATCH v20 3/7 RESEND] xbitmap: add more operations

On Sat, Dec 23, 2017 at 11:59:54AM +0900, Tetsuo Handa wrote: > Matthew Wilcox wrote: > > + bit %= IDA_BITMAP_BITS; > > + radix_tree_iter_init(, index); > > + slot = idr_get_free_cmn(root, , GFP_NOWAIT | __GFP_NOWARN, index); > > + if (IS_ERR(slot)) { > > + if (slot ==

Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests

On Fri, Dec 22, 2017 at 08:06:03PM +1100, Herbert Xu wrote: > On Fri, Dec 22, 2017 at 09:41:48AM +0100, Corentin Labbe wrote: > > > > It's you that was suggesting using crypto_async_request: > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html > > "The only wart with this

Re: [PATCH v5 4/4] virtio_remoteproc: correct put_device virtio_device.dev

On Thu, 21 Dec 2017 20:40:58 +0800 weiping zhang wrote: > rproc_virtio_dev_release will be called iff virtio_device.dev's > reference count drops to 0. Here we just put vdev.dev, and then > rproc->dev's cleanup will be done in rproc_virtio_dev_release. > >

Re: [PATCH v5 1/4] virtio: split device_register into device_initialize and device_add

On Thu, 21 Dec 2017 20:39:50 +0800 weiping zhang wrote: > In order to make caller do a simple cleanup, we split device_register > into device_initialize and device_add. device_initialize always succeeds, > so the caller can always use put_device when

[bpf-next V2 PATCH 11/14] virtio_net: setup xdp_rxq_info

The virtio_net driver doesn't dynamically change the RX-ring queue layout and backing pages, but instead reject XDP setup if all the conditions for XDP is not meet. Thus, the xdp_rxq_info also remains fairly static. This allow us to simply add the reg/unreg to net_device open/close functions.

Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests

On Fri, Dec 22, 2017 at 05:57:24PM +1100, Herbert Xu wrote: > On Wed, Nov 29, 2017 at 09:41:18AM +0100, Corentin Labbe wrote: > > The crypto engine could actually only enqueue hash and ablkcipher request. > > This patch permit it to enqueue any type of crypto_async_request. > > > > Signed-off-by:

[PATCH 4.14 065/159] x86/virt: Add enum for hypervisors to replace x86_hyper

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 03b2a320b19f1424e9ac9c21696be9c60b6d0d93 upstream. The x86_hyper pointer is only used for checking whether a virtual device is supporting the hypervisor

[PATCH 4.14 064/159] x86/virt, x86/platform: Merge struct x86_hyper into struct x86_platform and struct x86_init

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit f72e38e8ec8869ac0ba5a75d7d2f897d98a1454e upstream. Instead of x86_hyper being either NULL on bare metal or a pointer to a struct hypervisor_x86 in case