From: Li Zefan <lizf@cn.fujitsu.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] vfs: use kstrdup()
Date: Mon, 21 Jul 2008 14:29:47 +0800 [thread overview]
Message-ID: <48842CDB.1090009@cn.fujitsu.com> (raw)
In-Reply-To: <20080721052713.GY28946@ZenIV.linux.org.uk>
Al Viro wrote:
> On Sat, Jul 19, 2008 at 05:19:09PM +0400, Cyrill Gorcunov wrote:
>> [Cyrill Gorcunov - Sat, Jul 19, 2008 at 05:13:17PM +0400]
>> [...]
>> | | - }
>> | | - }
>> | | + mnt->mnt_devname = kstrdup(name, GFP_KERNEL);
>> | | }
>> | | return mnt;
>> | | }
>> | | --
>> | | 1.5.4.rc3
>> | |
>> | |
>> |
>> | but kstrdup may return NULL - is it safe there?
>> | Sorry if that "not smart" question.
>> |
>> | - Cyrill -
>>
>> ah, I see it is safe - sorry for noise
>
> FWIW, it _is_ a good question.
>
> * is all code treating ->mnt_devname as optional? AFAICS, there's
> at least one place in NFS that doesn't. We could treat failing allocation
> the same way we treat failing allocation of vfsmount itself - callers can
> cope with that already.
I just did a cleanup, and the original code didn't check for NULL.
I just looked into the git history, and I found out since fs/namespace.c was
created in v2.4.10.4, the code has never changed to check for failing
allocation of ->mnt_devname.
> * AFAICS, it should be const char *.
Agreed.
> * ... or perhaps we shouldn't copy it at all. How about something
> like
> struct {
> int count;
> char name[];
> }
> with cloning sharing the reference and bumping the count, protecting it with
> e.g. vfsmount_lock? For setups where we have a lot of bindings/namespaces
> it might be noticable.
>
I'm not sure whether this is a good idea, as I have limited knowledge about the
vfs internal.
next prev parent reply other threads:[~2008-07-21 6:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-19 10:16 [PATCH] vfs: use kstrdup() Li Zefan
2008-07-19 11:30 ` Pekka Enberg
2008-07-19 13:13 ` Cyrill Gorcunov
2008-07-19 13:19 ` Cyrill Gorcunov
2008-07-21 5:27 ` Al Viro
2008-07-21 6:29 ` Li Zefan [this message]
2008-07-21 7:03 ` Al Viro
2008-07-21 7:09 ` Cyrill Gorcunov
2008-07-21 8:04 ` Cyrill Gorcunov
2008-07-21 8:28 ` Li Zefan
2008-07-21 8:44 ` Cyrill Gorcunov
2008-07-21 8:59 ` Li Zefan
2008-07-21 9:06 ` Pekka Enberg
2008-07-21 10:05 ` Cyrill Gorcunov
2008-07-21 10:10 ` Li Zefan
2008-07-21 10:17 ` Cyrill Gorcunov
2008-07-21 9:12 ` Al Viro
2008-07-21 8:28 ` Al Viro
2008-07-21 8:35 ` Cyrill Gorcunov
2008-07-21 8:42 ` Cyrill Gorcunov
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=48842CDB.1090009@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=gorcunov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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