public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Timothy Shimmin <tes@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] XFS: handle memory allocation failures during log	initialisation
Date: Wed, 05 Nov 2008 11:24:46 +1100	[thread overview]
Message-ID: <4910E7CE.1020801@sgi.com> (raw)
In-Reply-To: <20081102231023.GJ19509@disturbed>

Dave Chinner wrote:
> On Fri, Oct 31, 2008 at 03:33:49PM +1100, Timothy Shimmin wrote:
>>> +
>>> +out_free_iclog:
>>> +	for (iclog = log->l_iclog; iclog; iclog = prev_iclog) {
>>> +		prev_iclog = iclog->ic_next;
>>> +		if (iclog->ic_bp) {
>>> +			sv_destroy(&iclog->ic_force_wait);
>>> +			sv_destroy(&iclog->ic_write_wait);
>>> +			xfs_buf_free(iclog->ic_bp);
>>> +			xlog_trace_iclog_dealloc(iclog);
>>> +		}
>>> +		kmem_free(iclog);
>>> +	}
>>> +	spinlock_destroy(&log->l_icloglock);
>>> +	spinlock_destroy(&log->l_grant_lock);
>>> +	xlog_trace_loggrant_dealloc(log);
>>> +	xfs_buf_free(log->l_xbuf);
>>> +out_free_log:
>>> +	kmem_free(log);
>>> +	return NULL;
>>>  }	/* xlog_alloc_log */
>>>  
>>>  
>> I would have done s/prev_iclog/next_iclog/
>> as I'm not sure why you look at it as previous.
> 
> Already had a local variable of the right type - not much
> point in declaring a new variable to use as a list iterator
> when you've already got a variable that is used as a list
> iterator in another, non-overlapping part of the code ;)
> 
Oh I see your point.
And if the variable was called iclog or something more generic
then it wouldn't be so bad.
However, in this case, the name is misleading for its use - it
infers the wrong object.
But this is irrelevant considering below :)

>> However, I think it would be nicer to modify xlog_dealloc_log()
>> to handle less than l_iclog_bufs.
>> i.e put the code you have here into xlog_dealloc_log()
>> and do the deallocation in one place.
> 
> The current trend is to unwind complex initialisation errors at
> the place they occur, even if there is a destructor function for
> a completely intialised object/subsystem. I just followed that
> construct. And to be truly complete, it should also handle
> trace buffer initialisation failure, which would make the
> unwinding even more complex than it is above.
> 
> Given that this is a regression fix I didn't want to perturb the
> log destructor code by making it have to handle partially set up
> lists and objects....
> 
> If you still want me to push this into xlog_dealloc_log() I will,
> just let me know.
> 
:-)
Yeah, I'd prefer to reuse the same bit of code.
IMHO, it minimises the chance of getting it wrong by having it in one place etc.

Thanks muchly,
Tim.

      reply	other threads:[~2008-11-05  0:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-31  1:26 [PATCH] XFS: handle memory allocation failures during log initialisation Dave Chinner
2008-10-31  4:33 ` Timothy Shimmin
2008-11-02 23:10   ` Dave Chinner
2008-11-05  0:24     ` Timothy Shimmin [this message]

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=4910E7CE.1020801@sgi.com \
    --to=tes@sgi.com \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox