On Wed, 26 Oct 2011 17:30:13 +0200 Jes.Sorensen@xxxxxxxxxx wrote: > From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> > > Hi, > > I cam across a couple of these last week while I was chasing the > assemble problem of IMSM raids, so I started going through the code to > fix up some more of these. > > This is just low hanging fruit, and there is more to be done, but at > least it's a few fixes. Hi, I'm not at all sure this sort of thing is worth it. There is no guarantee that the memory is actually there when malloc returns non-NULL. You might only get a page mapped when you access the memory, and equally the failure could happen at that time. If there is something genuinely useful that can be done when malloc fails, the it might make sense, but just printing a message an exiting seems pointless. If we were to go that route, I would probably want to use a #define to replace everything with a wrapper (xmalloc??) that printed a message and failed. Do you have a strong reason to add these checks? Thanks, NeilBrown > > Cheers, > Jes > > > Jes Sorensen (13): > count_active() catch malloc() failure > Catch malloc() failures > Try to catch malloc() failures in Assemble.c > Attempt to catch malloc() failure in Detail.c > Handle malloc() failure in Examine.c > Handle malloc() errors in Manage.c > Fix malloc() failure handling in Monitor.c > Handle malloc() failures in devline() > Fix malloc handling in dlink.c > Handle malloc() failure in Grow.c > Handle malloc() failure in mdopen.c > Handle malloc() failure in mdstat.c > Catch malloc() failure > > Assemble.c | 37 ++++++++++++++++++++- > Detail.c | 22 +++++++++++++ > Examine.c | 5 +++ > Grow.c | 7 ++++ > Incremental.c | 4 ++ > Manage.c | 13 ++++++- > Monitor.c | 7 ++++ > config.c | 99 ++++++++++++++++++++++++++++++++++++++++++--------------- > dlink.c | 6 ++- > mdopen.c | 6 +++ > mdstat.c | 5 +++ > policy.c | 5 +++ > util.c | 19 +++++++++-- > 13 files changed, 200 insertions(+), 35 deletions(-) >
Attachment:
signature.asc
Description: PGP signature
