From: NeilBrown <neilb@suse.de>
To: "Kwolek, Adam" <adam.kwolek@intel.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"Ciechanowski, Ed" <ed.ciechanowski@intel.com>,
"Neubauer, Wojciech" <Wojciech.Neubauer@intel.com>
Subject: Re: [PATCH 0/2] patches addresses problem with memory corruption
Date: Tue, 1 Feb 2011 10:49:03 +1100 [thread overview]
Message-ID: <20110201104903.48891253@notabene.brown> (raw)
In-Reply-To: <905EDD02F158D948B186911EB64DB3D17701C779@irsmsx503.ger.corp.intel.com>
On Mon, 31 Jan 2011 15:59:24 +0000 "Kwolek, Adam" <adam.kwolek@intel.com>
wrote:
>
>
> > -----Original Message-----
> > From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> > owner@vger.kernel.org] On Behalf Of Adam Kwolek
> > Sent: Monday, January 31, 2011 4:25 PM
> > To: neilb@suse.de
> > Cc: linux-raid@vger.kernel.org; Williams, Dan J; Ciechanowski, Ed;
> > Neubauer, Wojciech
> > Subject: [PATCH 0/2] patches addresses problem with memory corruption
> >
> > When for raid0 metadata is updated outside mdmon it can happen that
> > memory corruption occurs due to too amount of memory is allocated
> > for imsm device structure.
> >
> > 1. imsm: FIX: mdmon crash during 2 raid0 arrays expansion
> > this patch is almost the same to sent earlier except 2 changes:
> > a) compilation problem
> > b) size should affect anchor size also
> > (added calculation changes extends space_needed variable also
> > this variable is used for anchor allocation)
> > so it replaces previous one.
> > 2. imsm: FIX: sizeof_imsm_dev() can return too small value
> > size returned by sizeof_imsm_dev() describes minimum size of
> > device
> > This is correct when both device maps has the same length
> > When device expands or shrinks we should return size that
> > allows
> > for storing larger device information to avoid memory
> > corruption.
> >
> > BR
> > Adam
>
> imsm: FIX: sizeof_imsm_dev() can return too small value
> This should be addressed in different way (fix in different place), I have to think about it...
> please review/apply first patch only (imsm: FIX: mdmon crash during 2 raid0 arrays expansion)
>
ahhh.. ok. Yes, I see your point.
The size adjustment has to happen at the point when we malloc.
I suspect we should get ride of the idea of always allocating enough space to
hold the migration info as well, as we don't really know in advance how big
that is going to be. Maybe we shoul always allocated (or re-allocated)
exactly how much we know we need now...
I had applied this patch, but I have now reverted it.
Thanks,
NeilBrown
next prev parent reply other threads:[~2011-01-31 23:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 15:25 [PATCH 0/2] patches addresses problem with memory corruption Adam Kwolek
2011-01-31 15:25 ` [PATCH 1/2] imsm: FIX: mdmon crash during 2 raid0 arrays expansion Adam Kwolek
2011-01-31 15:25 ` [PATCH 2/2] imsm: FIX: sizeof_imsm_dev() can return too small value Adam Kwolek
2011-01-31 15:59 ` [PATCH 0/2] patches addresses problem with memory corruption Kwolek, Adam
2011-01-31 23:49 ` NeilBrown [this message]
2011-01-31 23:38 ` NeilBrown
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=20110201104903.48891253@notabene.brown \
--to=neilb@suse.de \
--cc=Wojciech.Neubauer@intel.com \
--cc=adam.kwolek@intel.com \
--cc=dan.j.williams@intel.com \
--cc=ed.ciechanowski@intel.com \
--cc=linux-raid@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).