[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzU1S6cybghVv4Bg2K8X1NC2pX2XebSrEgn0pKtgyCfRw@mail.gmail.com>
Date: Wed, 19 Sep 2012 16:01:50 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Rientjes <rientjes@...gle.com>
Cc: Konrad Rzeszutek Wilk <konrad@...nel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Dave Jones <davej@...hat.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
Suzuki Poulose <suzuki@...ibm.com>,
Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Subject: Re: 3.6rc6 slab corruption.
On Wed, Sep 19, 2012 at 2:49 PM, David Rientjes <rientjes@...gle.com> wrote:
>
> An alternative to this, though, might be to never test for *ppos == 0 in
> u32_array_read() and do the format_array_alloc() in u32_array_open() to
> initialize file->private_data. If that allocation fails, just return
> -ENOMEM. Then you never need to add a mutex in the read path.
>
> Any reason we can't do this?
That does look simpler, and avoiding the lock is a good idea. Since we
don't support lseek() (or pread/pwrite) on that thing anyway, there's
no way to keep the fd open and just re-use it to read the data over
and over, so populating it at open time sounds like a good solution
with no real downsides.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists