similar to: [PATCH v2 0/8] slab: provide and use krealloc_array()

On Mon, 2020-11-02 at 16:20 +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski at baylibre.com> > > Andy brought to my attention the fact that users allocating an array of > equally sized elements should check if the size multiplication doesn't > overflow. This is why we have helpers like kmalloc_array(). > > However we don't have

On Mon, Nov 02, 2020 at 04:20:37PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski at baylibre.com> > > Use the helper that checks for overflows internally instead of manually > calculating the size of the new array. ... > + nfences = krealloc_array(fences, i, > + sizeof(*fences), GFP_KERNEL); On 80 position is closing parenthesis,

On Mon, Nov 02, 2020 at 04:20:30PM +0100, Bartosz Golaszewski wrote: > +Chunks allocated with `kmalloc` can be resized with `krealloc`. Similarly > +to `kmalloc_array`: a helper for resising arrays is provided in the form of > +`krealloc_array`. Is there any reason you chose to `do_this` instead of do_this()? The automarkup script turns do_this() into a nice link to the documentation

I don't think the root cause of those warnings are introduced by virtio-crypto driver. What's your opinion? Sam and David? Thanks, -Gonglei > -----Original Message----- > From: kbuild test robot [mailto:lkp at intel.com] > Sent: Sunday, December 04, 2016 10:40 AM > Subject: Re: [PATCH v5 1/1] crypto: add virtio-crypto driver > > Hi Gonglei, > > [auto build

On Mon, Apr 13, 2020 at 05:15:49PM -0400, Waiman Long wrote: > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 23c7500eea7d..c08bc7eb20bd 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1707,17 +1707,17 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags) > EXPORT_SYMBOL(krealloc); > > /** > - * kzfree - like kfree but zero memory

Hi Gonglei, [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.9-rc7 next-20161202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gonglei/crypto-add-virtio-crypto-driver/20161202-190424 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master

Hi Gonglei, [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.9-rc7 next-20161202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gonglei/crypto-add-virtio-crypto-driver/20161202-190424 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master

On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long <longman at redhat.com> wrote: > As said by Linus: > > A symmetric naming is only helpful if it implies symmetries in use. > Otherwise it's actively misleading. > > In "kzalloc()", the z is meaningful and an important part of what the > caller wants. > > In "kzfree()", the z is

Signed-off-by: Dor Laor <dor.laor at qumranet.com> --- external-module-compat.h | 4 ++-- hack-module.awk | 5 ++++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/external-module-compat.h b/external-module-compat.h index 75c4fd0..9c93464 100644 --- a/external-module-compat.h +++ b/external-module-compat.h @@ -63,6 +63,8 @@ do { \ } while(0) #define

Not sure if it''s anything interesting - I had the following entry in dmesg a few days ago, on a server with 32 GB RAM. The system is still working fine. [1878432.675210] btrfs-qgroup-re: page allocation failure: order:5, mode:0x104050 [1878432.675319] CPU: 5 PID: 22251 Comm: btrfs-qgroup-re Not tainted 3.11.0-rc7 #2 [1878432.675417] Hardware name: System manufacturer System Product

From: Rock <zimilo@code-trick.com> --- fs/btrfs/backref.c | 10 ++-- fs/btrfs/qgroup.c | 16 +++--- fs/btrfs/send.c | 2 +- fs/btrfs/ulist.c | 154 +++++++++++++++++++++++++++++++++++++--------------- fs/btrfs/ulist.h | 45 ++++++++++++--- 5 files changed, 161 insertions(+), 66 deletions(-) diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c index ff6475f..a5bebc8

The VMCI handle array has an integer overflow in vmci_handle_arr_append_entry when it tries to expand the array. This can be triggered from a guest, since the doorbell link hypercall doesn't impose a limit on the number of doorbell handles that a VM can create in the hypervisor, and these handles are stored in a handle array. In this change, we introduce a mandatory max capacity for handle

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=445 laforge@netfilter.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|laforge@netfilter.org |opensource@intra2net.com ------- Additional Comments From laforge@netfilter.org 2006-02-09 15:38 MET ------- ipt_account

On Mon, Apr 06, 2020 at 09:07:44AM +0200, Dmitry Vyukov wrote: > On Mon, Apr 6, 2020 at 8:46 AM syzbot > <syzbot+d3a7951ed361037407db at syzkaller.appspotmail.com> wrote: > > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit: ffc1c20c Merge tag 'for-5.7/dm-changes' of git://git.kerne.. > > git tree:

In preparation to virtio header changes, include slab.h directly as this module is using it. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_input.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c index 5ae529671b3d..efaf65b0f42d 100644 --- a/drivers/virtio/virtio_input.c +++

In preparation to virtio header changes, include slab.h directly as this module is using it. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_input.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c index 5ae529671b3d..efaf65b0f42d 100644 --- a/drivers/virtio/virtio_input.c +++

Hi, > > > +drivers/gpu/drm/virtio/virtgpu_object.c maintainers > > > Now we have both mainline and linux-next boot broken (linux-next is > > > broken for the past 40 days). > > > No testing of new code happens. > > > > > > > virtio_gpu_object_shmem_init drivers/gpu/drm/virtio/virtgpu_object.c:151 [inline] > > > >

The kzfree() function is normally used to clear some sensitive information, like encryption keys, in the buffer before freeing it back to the pool. Memset() is currently used for the buffer clearing. However, it is entirely possible that the compiler may choose to optimize away the memory clearing especially if LTO is being used. To make sure that this optimization will not happen,

On Mon 15-06-20 21:57:16, Waiman Long wrote: > The kzfree() function is normally used to clear some sensitive > information, like encryption keys, in the buffer before freeing it back > to the pool. Memset() is currently used for the buffer clearing. However, > it is entirely possible that the compiler may choose to optimize away the > memory clearing especially if LTO is being

Waiman Long <longman at redhat.com> wrote: > The kzfree() function is normally used to clear some sensitive > information, like encryption keys, in the buffer before freeing it back > to the pool. Memset() "memset()" is all lowercase. > is currently used for buffer clearing. However unlikely, there is still a > non-zero probability I'd say "a