Sorry, maybe I'm wrong.
I wonder if the gfp parameter in static inline void *kmalloc(size_t s,
gfp_t gfp) can be deleted if it is not used.
Or would be better to move memset to kmalloc.
Like this:
#define __GFP_ZERO 0x1
static inline void *kmalloc(size_t s, gfp_t gfp)
{
void *p;
On Wed, Jun 05, 2024 at 09:52:45PM +0800, cuitao wrote:
> Use the __GFP_ZERO flag of kmalloc to initialize memory while allocating it,
> without the need for an additional memset call.
>
> Signed-off-by: cuitao
> ---
> tools/virtio/linux/kernel.h | 5 +
> 1 file chang
Sorry, this is a stupid mistake.
I wonder if the gfp parameter in static inline void *kmalloc(size_t s, gfp_t gfp) can be deleted if it is not used.
Or would be better to move memset to kmalloc.
Like this:
#define __GFP_ZERO 0x1
static inline void *kmalloc(size_t s, gfp_t gfp)
{
void *p;
if
On Wed, Jun 5, 2024 at 9:56 PM cuitao wrote:
>
> Use the __GFP_ZERO flag of kmalloc to initialize memory while allocating it,
> without the need for an additional memset call.
>
> Signed-off-by: cuitao
> ---
> tools/virtio/linux/kernel.h | 5 +
> 1 file changed, 1 i
Use the __GFP_ZERO flag of kmalloc to initialize memory while allocating it,
without the need for an additional memset call.
Signed-off-by: cuitao
---
tools/virtio/linux/kernel.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/virtio/linux/kernel.h b/tools/virtio
On Wed, May 15, 2024 at 02:30:37PM -0700, Alexei Starovoitov wrote:
> On Tue, May 14, 2024 at 12:33 AM Ubisectech Sirius
> wrote:
> >
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> > Recently, our team has discovered a issue in Linux kernel 6.7. Attach
On Tue, May 14, 2024 at 12:33 AM Ubisectech Sirius
wrote:
>
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel 6.7. Attached to
> the email were a PoC file of the issue.
Jiri,
please take a look.
>
Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the
email were a PoC file of the issue.
Stack dump:
loop3: detected capacity change from 0 to 8
MTD: Attempt to mount non-MTD device "/dev
On Mon, Feb 05, 2024 at 10:49:37AM +0530, Ajay Kaher wrote:
> From: Prathu Baronia
>
> From: Prathu Baronia
>
> commit 4d8df0f5f79f747d75a7d356d9b9ea40a4e4c8a9 upstream
>
> Use kzalloc() to allocate new zeroed out msg node instead of
> memsetting a node allocated wit
From: Prathu Baronia
From: Prathu Baronia
commit 4d8df0f5f79f747d75a7d356d9b9ea40a4e4c8a9 upstream
Use kzalloc() to allocate new zeroed out msg node instead of
memsetting a node allocated with kmalloc().
Signed-off-by: Prathu Baronia
Message-Id: <20230522085019.42914-1-prathubaron
On Mon, Dec 11, 2023 at 02:01:43PM +0100, Jiri Olsa wrote:
> On Mon, Dec 11, 2023 at 07:29:40PM +0800, Hou Tao wrote:
>
> SNIP
>
> >
> > It seems a big attr->link_create.uprobe_multi.cnt is passed to
> > bpf_uprobe_multi_link_attach(). Could you please try the first patch in
> > the following pa
On Mon, Dec 11, 2023 at 07:29:40PM +0800, Hou Tao wrote:
SNIP
>
> It seems a big attr->link_create.uprobe_multi.cnt is passed to
> bpf_uprobe_multi_link_attach(). Could you please try the first patch in
> the following patch set ?
>
> https://lore.kernel.org/bpf/2023122843.4147157-1-hou...@
Hi,
On 12/11/2023 4:12 PM, xingwei lee wrote:
> Sorry for containing HTML part, repeat the mail
> Hello I found a bug in net/bpf in the lastest upstream linux and
> lastest net tree.
> WARNING: kmalloc bug in bpf_uprobe_multi_link_attach
>
> kernel: net 28a7cb045ab700de555419
On Mon, 11 Dec 2023 16:10:32 +0800
xingwei lee wrote:
> Hello I found a bug in net/bpf in the lastest upstream linux and lastest
> net tree.
> WARNING: kmalloc bug in bpf_uprobe_multi_link_attach
Hmm, uprobe_multi is recently introduced and it seems a normal
uprobes unlike kprobe_mul
Sorry for containing HTML part, repeat the mail
Hello I found a bug in net/bpf in the lastest upstream linux and
lastest net tree.
WARNING: kmalloc bug in bpf_uprobe_multi_link_attach
kernel: net 28a7cb045ab700de5554193a1642917602787784
Kernel config:
https://github.com/google/syzkaller/commits
..c3a029fe183d 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -48,7 +49,7 @@ static void *kmalloc_parameter(unsigned int size)
{
struct kmalloced_param *p;
- p = kmalloc(sizeof(*p
/params.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -48,7 +49,7 @@ static void *kmalloc_parameter(unsigned int size)
{
struct kmalloced_param *p;
- p = kmalloc(sizeof(*p) + size, GFP_KERNEL);
+ p = kmalloc(size_add(sizeof(*p
Randomized slab caches for
> kmalloc()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c6152940584290668b35fa0800026f6a1ae05fe)
> patch series merged upstream, and I've and enough discussions about it to
> warrant summarising them into a small blogpost.
I wrote a small blogpost[1] about this series, and was told[2] that it
would be interesting to share it on this thread, so here it is, copied
verbatim:
Ruiqi Gong and Xiu Jianfeng got their
[Randomized slab caches for
kmalloc()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
t reduced to tens of MBs when we do lazy list_lru head allocations
> under GFP_ATOMIC.
That does not make GFP_ATOMIC allocations safe or desirable. In
general, using GFP_ATOMIC outside of interrupt context indicates
something is being done incorrectly. Especially if it can be
triggered from
allocations are really not preferrable
but want to point out that the allocations in the range of hundreds of
GBs get reduced to tens of MBs when we do lazy list_lru head allocations
under GFP_ATOMIC.
As shown earlier, this is what I see in my experimental setup with
10k containers:
Nu
On Thu, Apr 15, 2021 at 08:54:43AM +0200, Michal Hocko wrote:
> On Thu 15-04-21 10:53:00, Bharata B Rao wrote:
> > On Wed, Apr 07, 2021 at 08:28:07AM +1000, Dave Chinner wrote:
> > >
> > > Another approach may be to identify filesystem types that do not
> > > need memcg awareness and feed that int
l the memcgs. Due to
> the way the memcg_nr_cache_ids grow and the list_lru heads are
> allocated for all memcgs, huge amount of memory gets consumed
> by kmalloc-32 slab cache when running thousands of containers.
>
> Improve this situation by allowing filesystems to opt out
> of m
allocated for all memcgs, huge amount of memory gets consumed
by kmalloc-32 slab cache when running thousands of containers.
Improve this situation by allowing filesystems to opt out
of memcg awareness. In this patch, tmpfs, proc and ramfs
opt out of memcg awareness. This leads to considerable memory
; > consumption increases quite a lot (around 172G) when the containers are
> > running. Most of it comes from slab (149G) and within slab, the majority of
> > it comes from kmalloc-32 cache (102G)
>
> Is this 10k cgroups a testing enviroment or does anybody really use that
ry), it is seen that memory
> > consumption increases quite a lot (around 172G) when the containers are
> > running. Most of it comes from slab (149G) and within slab, the majority of
> > it comes from kmalloc-32 cache (102G)
> >
> > The major allocator of kmalloc-32
> > > server(160 CPUs, 2 NUMA nodes, 256G memory), it is seen that memory
> > > consumption increases quite a lot (around 172G) when the containers are
> > > running. Most of it comes from slab (149G) and within slab, the majority
> > > of
> > > it comes
that memory
> > consumption increases quite a lot (around 172G) when the containers are
> > running. Most of it comes from slab (149G) and within slab, the majority of
> > it comes from kmalloc-32 cache (102G)
>
> Is this 10k cgroups a testing enviroment or does anybody really use
that memory
> > consumption increases quite a lot (around 172G) when the containers are
> > running. Most of it comes from slab (149G) and within slab, the majority of
> > it comes from kmalloc-32 cache (102G)
>
> Is this 10k cgroups a testing enviroment or does anybody really use
On 07.04.2021 14:47, Bharata B Rao wrote:
> On Wed, Apr 07, 2021 at 01:07:27PM +0300, Kirill Tkhai wrote:
>>> Here is how the calculation turns out to be in my setup:
>>>
>>> Number of possible NUMA nodes = 2
>>> Number of mounts per container = 7 (Check below to see which are these)
>>> Number of
unning. Most of it comes from slab (149G) and within slab, the majority of
> it comes from kmalloc-32 cache (102G)
Is this 10k cgroups a testing enviroment or does anybody really use that
in production? I would be really curious to hear how that behaves when
those containers are not idle. E.g.
On Wed, Apr 07, 2021 at 01:07:27PM +0300, Kirill Tkhai wrote:
> > Here is how the calculation turns out to be in my setup:
> >
> > Number of possible NUMA nodes = 2
> > Number of mounts per container = 7 (Check below to see which are these)
> > Number of list creation requests per mount = 2
> > Nu
r9
>>> server(160 CPUs, 2 NUMA nodes, 256G memory), it is seen that memory
>>> consumption increases quite a lot (around 172G) when the containers are
>>> running. Most of it comes from slab (149G) and within slab, the majority of
>>> it comes from kmalloc-32 cache (
ry), it is seen that memory
> > consumption increases quite a lot (around 172G) when the containers are
> > running. Most of it comes from slab (149G) and within slab, the majority of
> > it comes from kmalloc-32 cache (102G)
> >
> > The major allocator of kmalloc-32
ers on a bare-metal Power9
> > > server(160 CPUs, 2 NUMA nodes, 256G memory), it is seen that memory
> > > consumption increases quite a lot (around 172G) when the containers are
> > > running. Most of it comes from slab (149G) and within slab, the majority
> > &g
containers are
> running. Most of it comes from slab (149G) and within slab, the majority of
> it comes from kmalloc-32 cache (102G)
>
> The major allocator of kmalloc-32 slab cache happens to be the list_head
> allocations of list_lru_one list. These lists are created whenever a
> FS
rom_memcg_idx(nlru, src_idx);
> > > + if (!src)
> > > + goto out;
> > > +
> > > dst = list_lru_from_memcg_idx(nlru, dst_idx);
> > > + if (!dst) {
> > > + /* TODO: Use __GFP_NOFAIL? */
> >
seen that memory
> > consumption increases quite a lot (around 172G) when the containers are
> > running. Most of it comes from slab (149G) and within slab, the majority of
> > it comes from kmalloc-32 cache (102G)
> >
> > The major allocator of kmalloc-32 slab cache h
seen that memory
> > consumption increases quite a lot (around 172G) when the containers are
> > running. Most of it comes from slab (149G) and within slab, the majority of
> > it comes from kmalloc-32 cache (102G)
> >
> > The major allocator of kmalloc-32 slab cache h
ners are
> running. Most of it comes from slab (149G) and within slab, the majority of
> it comes from kmalloc-32 cache (102G)
>
> The major allocator of kmalloc-32 slab cache happens to be the list_head
> allocations of list_lru_one list. These lists are created whenever a
> FS mount h
From: J. Bruce Fields
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DENIED.
This
From: J. Bruce Fields
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DENIED.
This
From: J. Bruce Fields
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DENIED.
This
From: J. Bruce Fields
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DENIED.
This
From: J. Bruce Fields
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DENIED.
This
From: J. Bruce Fields
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DENIED.
This
From: J. Bruce Fields
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DENIED.
This
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Bharata-B-Rao/High-kmalloc-32-slab-cache-consumption-with-10k-containers/20210405-135124
base: https://git.kernel.org/pub/scm/linux/kernel/gi
comes from kmalloc-32 cache (102G)
The major allocator of kmalloc-32 slab cache happens to be the list_head
allocations of list_lru_one list. These lists are created whenever a
FS mount happens. Specially two such lists are registered by alloc_super(),
one for dentry and another for inode shrinker
Applied. Thanks!
On Wed, Mar 31, 2021 at 9:36 AM Bernard Zhao wrote:
>
> Fix patch check warning:
> WARNING: Prefer kmalloc_array over kmalloc with multiply
> + buf = kmalloc(MAX_KFIFO_SIZE * sizeof(*buf), GFP_KERNEL);
>
> Signed-off-by: Bernard Zhao
> ---
> dr
>
> kfree should be used to free memory allocated by kmalloc or kzalloc to avoid
> any overhead and for
> maintaining consistency.
>
> Fixes: 5dfeb6d945 ("cifsd: use kmalloc() for small allocations")
> Signed-off-by: Muhammad Usama Anjum
Looks good. I will apply. Thanks for your patch!
kfree should be used to free memory allocated by kmalloc or kzalloc to
avoid any overhead and for maintaining consistency.
Fixes: 5dfeb6d945 ("cifsd: use kmalloc() for small allocations")
Signed-off-by: Muhammad Usama Anjum
---
fs/cifsd/buffer_pool.c | 4 ++--
fs/cifsd/mgmt/shar
Fix patch check warning:
WARNING: Prefer kmalloc_array over kmalloc with multiply
+ buf = kmalloc(MAX_KFIFO_SIZE * sizeof(*buf), GFP_KERNEL);
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
From: "J. Bruce Fields"
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DEN
From: "J. Bruce Fields"
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DEN
From: "J. Bruce Fields"
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DEN
From: "J. Bruce Fields"
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DEN
From: "J. Bruce Fields"
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DEN
From: "J. Bruce Fields"
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DEN
From: "J. Bruce Fields"
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The
kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL,
and returning SVC_DEN
Hi Jianqun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on hnaz-linux-mm/master]
url:
https://github.com/0day-ci/linux/commits/Jianqun-Xu/mm-slab-kmalloc-with-GFP_DMA32-allocate-from-SLAB_CACHE_DMA32/20210312-160426
base: https://github.com/hnaz/linux-mm
On Fri, Mar 12, 2021 at 04:03:20PM +0800, Jianqun Xu wrote:
> The flag GFP_DMA32 only effect in kmalloc_large currently.
>
> This patch will create caches with GFP_DMA32 to support kmalloc with
> size under KMALLOC_MAX_CACHE_SIZE.
No. No new code should use GFP_DMA32, never mind
The flag GFP_DMA32 only effect in kmalloc_large currently.
This patch will create caches with GFP_DMA32 to support kmalloc with
size under KMALLOC_MAX_CACHE_SIZE.
Signed-off-by: Jianqun Xu
---
include/linux/slab.h | 7 +++
mm/slab_common.c | 14 ++
2 files changed, 21
e/ucc_geth.c
> @@ -3591,10 +3591,9 @@ static int ucc_geth_probe(struct platform_device*
> ofdev)
> if ((ucc_num < 0) || (ucc_num > 7))
> return -ENODEV;
>
> - ug_info = kmalloc(sizeof(*ug_info), GFP_KERNEL);
> + ug_info = kmemdup(&
Am Montag, den 08.03.2021, 09:50 +0100 schrieb Bruno Thomsen:
>
> Tested-by: Bruno Thomsen
>
> I have not observed any oops with patches applied. Patches have seen
> more than 10 weeks of runtime testing across multiple devices.
Hi,
that is good news. I shall send them upstream.
Regar
Den fre. 26. feb. 2021 kl. 15.14 skrev Bruno Thomsen :
>
> Den tor. 25. feb. 2021 kl. 10.57 skrev Oliver Neukum :
> >
> > Am Mittwoch, den 24.02.2021, 16:21 +0100 schrieb Bruno Thomsen:
> >
> > Hi,
> >
> > > No, this is not a regression from 5.10. It seems that many attempts to
> > > fix cdc-acm in
; 0) || (ucc_num > 7))
return -ENODEV;
- ug_info = kmalloc(sizeof(*ug_info), GFP_KERNEL);
+ ug_info = kmemdup(&ugeth_primary_info, sizeof(*ug_info), GFP_KERNEL);
if (ug_info == NULL)
return -ENOMEM;
- memcpy(ug_info, &uget
Den tor. 25. feb. 2021 kl. 10.57 skrev Oliver Neukum :
>
> Am Mittwoch, den 24.02.2021, 16:21 +0100 schrieb Bruno Thomsen:
>
> Hi,
>
> > No, this is not a regression from 5.10. It seems that many attempts to
> > fix cdc-acm in the 5.x kernel series have failed to fix the root cause of
> > these oop
Am Mittwoch, den 24.02.2021, 16:21 +0100 schrieb Bruno Thomsen:
Hi,
> No, this is not a regression from 5.10. It seems that many attempts to
> fix cdc-acm in the 5.x kernel series have failed to fix the root cause of
> these oops. I have not seen this on 4.14 and 4.19, but I have observed
> it on
Den man. 22. feb. 2021 kl. 10.36 skrev Oliver Neukum :
>
> Am Donnerstag, den 18.02.2021, 16:52 +0100 schrieb Bruno Thomsen:
> > Den fre. 12. feb. 2021 kl. 16.33 skrev Bruno Thomsen
> > :
> > > Hi,
> > >
> > > I have been experience random kernel oops in the cdc-acm driver on
> > > imx7 (arm arch)
Am Donnerstag, den 18.02.2021, 16:52 +0100 schrieb Bruno Thomsen:
> Den fre. 12. feb. 2021 kl. 16.33 skrev Bruno Thomsen
> :
> > Hi,
> >
> > I have been experience random kernel oops in the cdc-acm driver on
> > imx7 (arm arch). Normally it happens during the first 1-3min runtime
> > after power-
fw_minibuffer[i].buffer is allocated by kmalloc in sh_css_load_blob_info
and by vmalloc in setup_binary. So use kvfree to decide which of those
allocators to use for freeing.
Also remove the useless cast.
Signed-off-by: Jiri Slaby
Cc: Mauro Carvalho Chehab
---
drivers/staging/media/atomisp
Den fre. 12. feb. 2021 kl. 16.33 skrev Bruno Thomsen :
>
> Hi,
>
> I have been experience random kernel oops in the cdc-acm driver on
> imx7 (arm arch). Normally it happens during the first 1-3min runtime
> after power-on. Below oops is from 5.8.17 mainline kernel with an
> extra patch back-ported
Logging an error when kmalloc fails is not necessary (and in general
should be avoided) because the malloc failure will already complain
loudly itself.
Signed-off-by: Hans de Goede
---
drivers/misc/lis3lv02d/lis3lv02d.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a
On Mon, Feb 15, 2021 at 09:44:24AM +0100, Michal Hocko wrote:
> On Sat 13-02-21 15:05:28, Ivan Safonov wrote:
> > memdup_user() is shorter and safer equivalent
> > of kmalloc/copy_from_user pair.
> >
> > Signed-off-by: Ivan Safonov
> > ---
> > driv
On Sat 13-02-21 15:05:28, Ivan Safonov wrote:
> memdup_user() is shorter and safer equivalent
> of kmalloc/copy_from_user pair.
>
> Signed-off-by: Ivan Safonov
> ---
> drivers/staging/wlan-ng/p80211netdev.c | 28 --
> 1 file changed, 13 insert
memdup_user() is shorter and safer equivalent
of kmalloc/copy_from_user pair.
Signed-off-by: Ivan Safonov
---
drivers/staging/wlan-ng/p80211netdev.c | 28 --
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/wlan-ng/p80211netdev.c
b/drivers
[ 55.391133] 9fe0: 0013
[ 55.397757] Code: e92d4010 e2504000 e24dd008 0a0e (e5d43020)
[ 55.403857] ---[ end trace 1ec2a82c3635d550 ]---
[ 55.408479] note: kworker/0:2[82] exited with preempt_count 1
[ 60.237
Similarly to kasan_kmalloc(), kasan_kmalloc_large() doesn't need
to unpoison the object as it as already unpoisoned by alloc_pages()
(or by ksize() for krealloc()).
This patch changes kasan_kmalloc_large() to only poison the redzone.
Reviewed-by: Marco Elver
Signed-off-by: Andrey Konovalov
---
For allocations from kmalloc caches, kasan_kmalloc() always follows
kasan_slab_alloc(). Currenly, both of them unpoison the whole object,
which is unnecessary.
This patch provides separate implementations for both annotations:
kasan_slab_alloc() unpoisons the whole object, and kasan_kmalloc
Similarly to kasan_kmalloc(), kasan_kmalloc_large() doesn't need
to unpoison the object as it as already unpoisoned by alloc_pages()
(or by ksize() for krealloc()).
This patch changes kasan_kmalloc_large() to only poison the redzone.
Reviewed-by: Marco Elver
Signed-off-by: Andrey Konovalov
---
For allocations from kmalloc caches, kasan_kmalloc() always follows
kasan_slab_alloc(). Currenly, both of them unpoison the whole object,
which is unnecessary.
This patch provides separate implementations for both annotations:
kasan_slab_alloc() unpoisons the whole object, and kasan_kmalloc
On Thu, 4 Feb 2021 10:51:59 -0800 Jakub Kicinski wrote:
> On Thu, 4 Feb 2021 15:02:30 +0600 Sabyrzhan Tasbolatov wrote:
> > Replaced kzalloc() with kmalloc(), there is no need for zeroed-out
> > memory for simple void *kbuf.
>
> There is no need for zeroed-out memory bec
On Thu, 4 Feb 2021 15:02:30 +0600 Sabyrzhan Tasbolatov wrote:
> Replaced kzalloc() with kmalloc(), there is no need for zeroed-out
> memory for simple void *kbuf.
There is no need for zeroed-out memory because it's immediately
overwritten by copy_from_iter...
> >For potential,
Replaced kzalloc() with kmalloc(), there is no need for zeroed-out
memory for simple void *kbuf.
>For potential, separate clean up - this is followed
>by copy_from_iter_full(len) kzalloc() can probably
>be replaced by kmalloc()?
>
>> if (!kbuf)
>> ret
On Tue, 2 Feb 2021 at 18:16, Andrey Konovalov wrote:
>
> On Tue, Feb 2, 2021 at 5:25 PM Marco Elver wrote:
> >
> > > +#ifdef CONFIG_KASAN_GENERIC
> > > +
> > > +/**
> > > + * kasan_poison_last_granule - mark the last granule of the memory range
> > > as
> > > + * unaccessible
> > > + * @addr - r
On Tue, Feb 2, 2021 at 5:25 PM Marco Elver wrote:
>
> > +#ifdef CONFIG_KASAN_GENERIC
> > +
> > +/**
> > + * kasan_poison_last_granule - mark the last granule of the memory range as
> > + * unaccessible
> > + * @addr - range start address, must be aligned to KASAN_GRANULE_SIZE
> > + * @size - range
On Mon, Feb 01, 2021 at 08:43PM +0100, Andrey Konovalov wrote:
> Similarly to kasan_kmalloc(), kasan_kmalloc_large() doesn't need
> to unpoison the object as it as already unpoisoned by alloc_pages()
> (or by ksize() for krealloc()).
>
> This patch changes kasan_kmalloc_large() to only poison the
On Mon, Feb 01, 2021 at 08:43PM +0100, Andrey Konovalov wrote:
> For allocations from kmalloc caches, kasan_kmalloc() always follows
> kasan_slab_alloc(). Currenly, both of them unpoison the whole object,
> which is unnecessary.
>
> This patch provides separate implement
For allocations from kmalloc caches, kasan_kmalloc() always follows
kasan_slab_alloc(). Currenly, both of them unpoison the whole object,
which is unnecessary.
This patch provides separate implementations for both annotations:
kasan_slab_alloc() unpoisons the whole object, and kasan_kmalloc
Similarly to kasan_kmalloc(), kasan_kmalloc_large() doesn't need
to unpoison the object as it as already unpoisoned by alloc_pages()
(or by ksize() for krealloc()).
This patch changes kasan_kmalloc_large() to only poison the redzone.
Signed-off-by: Andrey Konovalov
---
mm/kasan/common.c | 20 ++
Joe Perches writes:
> On Thu, 2021-01-28 at 00:52 -0300, Thiago Jung Bauermann wrote:
>> The problem is that this patch implements only part of the suggestion,
>> which isn't useful in itself. So the patch series should either drop
>> this patch or consolidate the FDT allocation between the arc
Quoting Jani Nikula (2021-01-28 13:23:48)
>
> A number of our CI systems are hitting redzone overwritten errors after
> s2idle, with the errors introduced between v5.11-rc4 and v5.11-rc5. See
> snippet below, full logs for one affected machine at [1].
>
> Known issue?
Fwiw, I think this should b
-tgl-u2/igt@gem_exec_susp...@basic-s0.html
<6> [71.947160] Restarting tasks ... done.
<3> [71.948035]
=
<3> [71.948545] BUG kmalloc-1k (Not tainted): Redzone overwrit
On Thu, 2021-01-28 at 00:52 -0300, Thiago Jung Bauermann wrote:
> The problem is that this patch implements only part of the suggestion,
> which isn't useful in itself. So the patch series should either drop
> this patch or consolidate the FDT allocation between the arches.
>
> I just tested on po
15, 2021 at 09:30:16AM -0800, Lakshmi Ramasubramanian wrote:
create_dtb() function allocates kernel virtual memory for
the device tree blob (DTB). This is not consistent with other
architectures, such as powerpc, which calls kmalloc() for allocating
memory for the DTB.
Call kmalloc() to allocate
; create_dtb() function allocates kernel virtual memory for
>> > > the device tree blob (DTB). This is not consistent with other
>> > > architectures, such as powerpc, which calls kmalloc() for allocating
>> > > memory for the DTB.
>> > >
>&
t;>> Hi Will,
>>>>
>>>>> On Fri, Jan 15, 2021 at 09:30:16AM -0800, Lakshmi Ramasubramanian wrote:
>>>>>> create_dtb() function allocates kernel virtual memory for
>>>>>> the device tree blob (DTB). This is not consistent with othe
allocates kernel virtual memory for
the device tree blob (DTB). This is not consistent with other
architectures, such as powerpc, which calls kmalloc() for allocating
memory for the DTB.
Call kmalloc() to allocate memory for the DTB, and kfree() to free
the allocated memory.
Co-developed-by
> > > the device tree blob (DTB). This is not consistent with other
> > > architectures, such as powerpc, which calls kmalloc() for allocating
> > > memory for the DTB.
> > >
> > > Call kmalloc() to allocate memory for the DTB, and kfree() to free
>
1 - 100 of 1602 matches
Mail list logo
