From: Li Zefan <lizf@cn.fujitsu.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Paul Menage <menage@google.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>,
"containers@lists.osdl.org" <containers@lists.osdl.org>
Subject: Re: [PATCH -mm] cgroups: fix failure path in cgroup_write_event_control()
Date: Thu, 25 Feb 2010 08:43:48 +0800 [thread overview]
Message-ID: <4B85C7C4.4040100@cn.fujitsu.com> (raw)
In-Reply-To: <cc557aab1002240528t28eae36dj976525be2fcf7246@mail.gmail.com>
Kirill A. Shutemov wrote:
> On Wed, Feb 24, 2010 at 5:22 AM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>> How to reproduce:
>>
>> # mount -t cgroup -o memory xxx /cgroup
>> # mkdir /cgroup/tmp
>> # ./cgroup_event_listener /cgroup/tmp/cgroup.event_control abc
>> ^C
>> # rmdir /cgroup/tmp
>> # cat /proc/cgroups | grep memory
>> memory 2 2 1 (should be "2 1 1")
>> # umount /cgroup
>> (failed!)
>>
>> Using a single goto label to cleanup multi failure paths can
>> get things wrong quite easily, while multi labels makes the
>> code cleaner.
>
> I disagree.
> It's easer to make mistake on changing code with multi failure
> paths, if you want to move a code within function.
>
You've made 2 mistakes here (the other one was pointed out by
Paul), so I don't think you can claim the way you use is better.
When using a single label, each cleanup has to take care of 3
different cases:
1. the resource hasn't been allocated.
2. the resource has been allocated.
3. the allocation has failed.
And you have to be aware that some failures may affect the other
cleanups, for example you have to do this check:
if (a != NULL && a->b != NULL)
cleanup(b);
In fact, I hardly see a single label is used where there are more
than 2 resources need to be reclaimed in other parts of kernel
code.
See copy_process() in kernel/fork.c. This function has about
15 failure paths, and it's modified by various people frequently.
What a disaster it will be if you use a single label to do all
the cleanups here.
prev parent reply other threads:[~2010-02-25 0:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-24 3:22 [PATCH -mm] cgroups: fix failure path in cgroup_write_event_control() Li Zefan
2010-02-24 13:28 ` Kirill A. Shutemov
2010-02-24 16:06 ` Paul Menage
2010-02-25 0:43 ` Li Zefan [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=4B85C7C4.4040100@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.osdl.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.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