All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
	linux-kernel@vger.kernel.org, Eric Paris <eparis@redhat.com>,
	hugh.dickins@tiscali.co.uk
Subject: Re: shmem_fill_super(): WARNING: kmemcheck: Caught 32-bit read from uninitialized memory
Date: Sun, 20 Sep 2009 20:40:59 +0200	[thread overview]
Message-ID: <20090920184059.GA21154@elte.hu> (raw)
In-Reply-To: <84144f020909201101g2f1dbc22wd2497e8309800d7e@mail.gmail.com>


* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> Hi Ingo,
> 
> On Sun, Sep 20, 2009 at 8:58 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >> From: Pekka Enberg <penberg@cs.helsinki.fi>
> >> Date: Sun, 20 Sep 2009 20:43:35 +0300
> >> Subject: [PATCH] shmem: initialize struct shmem_sb_info to zero
> >>
> >> Fixes the following kmemcheck false positive:
> >>
> >> [ ? ?0.337000] Total of 1 processors activated (3088.38 BogoMIPS).
> >> [ ? ?0.352000] CPU0 attaching NULL sched-domain.
> >> [ ? ?0.360000] WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (9f8020fc)
> >> [ ? ?0.361000] a44240820000000041f6998100000000000000000000000000000000ff030000
> >> [ ? ?0.368000] ?i i i i i i i i i i i i i i i i u u u u i i i i i i i i i i u u
> >> [ ? ?0.375000] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> >> [ ? ?0.376000]
> >> [ ? ?0.377000] Pid: 9, comm: khelper Not tainted (2.6.31-tip #206) P4DC6
> >> [ ? ?0.378000] EIP: 0060:[<810a3a95>] EFLAGS: 00010246 CPU: 0
> >> [ ? ?0.379000] EIP is at shmem_fill_super+0xb5/0x120
> >> [ ? ?0.380000] EAX: 00000000 EBX: 9f845400 ECX: 824042a4 EDX: 8199f641
> >> [ ? ?0.381000] ESI: 9f8020c0 EDI: 9f845400 EBP: 9f81af68 ESP: 81cd6eec
> >> [ ? ?0.382000] ?DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> >> [ ? ?0.383000] CR0: 8005003b CR2: 9f806200 CR3: 01ccd000 CR4: 000006d0
> >> [ ? ?0.384000] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> >> [ ? ?0.385000] DR6: ffff4ff0 DR7: 00000400
> >> [ ? ?0.386000] ?[<810c25fc>] get_sb_nodev+0x3c/0x80
> >> [ ? ?0.388000] ?[<810a3514>] shmem_get_sb+0x14/0x20
> >> [ ? ?0.390000] ?[<810c207f>] vfs_kern_mount+0x4f/0x120
> >> [ ? ?0.392000] ?[<81b2849e>] init_tmpfs+0x7e/0xb0
> >> [ ? ?0.394000] ?[<81b11597>] do_basic_setup+0x17/0x30
> >> [ ? ?0.396000] ?[<81b11907>] kernel_init+0x57/0xa0
> >> [ ? ?0.398000] ?[<810039b7>] kernel_thread_helper+0x7/0x10
> >> [ ? ?0.400000] ?[<ffffffff>] 0xffffffff
> >> [ ? ?0.402000] khelper used greatest stack depth: 2820 bytes left
> >> [ ? ?0.407000] calling ?init_mmap_min_addr+0x0/0x10 @ 1
> >> [ ? ?0.408000] initcall init_mmap_min_addr+0x0/0x10 returned 0 after 0 usecs
> >>
> >> Reported-by: Ingo Molnar <mingo@elte.hu>
> >> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
> >> ---
> >> ?mm/shmem.c | ? ?5 +----
> >> ?1 files changed, 1 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/mm/shmem.c b/mm/shmem.c
> >> index d713239..a8f54f3 100644
> >> --- a/mm/shmem.c
> >> +++ b/mm/shmem.c
> >> @@ -2307,17 +2307,14 @@ static int shmem_fill_super(struct super_block *sb,
> >> ? ? ? int err = -ENOMEM;
> >>
> >> ? ? ? /* Round up to L1_CACHE_BYTES to resist false sharing */
> >> - ? ? sbinfo = kmalloc(max((int)sizeof(struct shmem_sb_info),
> >> + ? ? sbinfo = kzalloc(max((int)sizeof(struct shmem_sb_info),
> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? L1_CACHE_BYTES), GFP_KERNEL);
> >> ? ? ? if (!sbinfo)
> >> ? ? ? ? ? ? ? return -ENOMEM;
> >>
> >> - ? ? sbinfo->max_blocks = 0;
> >> - ? ? sbinfo->max_inodes = 0;
> >> ? ? ? sbinfo->mode = S_IRWXUGO | S_ISVTX;
> >> ? ? ? sbinfo->uid = current_fsuid();
> >> ? ? ? sbinfo->gid = current_fsgid();
> >> - ? ? sbinfo->mpol = NULL;
> >> ? ? ? sb->s_fs_info = sbinfo;
> >
> > That looks like a step forward even without kmemcheck considered, right?
> 
> Oh, sure. It usually less error prone to use kzalloc() for infrequent 
> allocations such as this.

So in that sense kmemcheck was useful here: it made kernel code a bit 
better.

	Ingo

  reply	other threads:[~2009-09-20 18:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-15  8:09 WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (bf438284) Ingo Molnar
2009-09-15  8:59 ` Eric Dumazet
2009-09-15  9:34   ` Ingo Molnar
2009-09-15  9:39     ` David Miller
2009-09-20  7:22 ` shmem_fill_super(): WARNING: kmemcheck: Caught 32-bit read from uninitialized memory Ingo Molnar
2009-09-20 17:35   ` Vegard Nossum
2009-09-20 17:55     ` Pekka J Enberg
2009-09-20 17:58       ` Ingo Molnar
2009-09-20 18:01         ` Pekka Enberg
2009-09-20 18:40           ` Ingo Molnar [this message]
2009-09-20 18:04         ` Cyrill Gorcunov
2009-09-21 10:49       ` Hugh Dickins
2009-09-21 11:07         ` Pekka Enberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090920184059.GA21154@elte.hu \
    --to=mingo@elte.hu \
    --cc=eparis@redhat.com \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=vegard.nossum@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.