From: Boaz Harrosh <bharrosh@panasas.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Duane Griffin <duaneg@dghda.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org
Subject: Re: Checking link targets are NULL-terminated
Date: Tue, 09 Dec 2008 20:00:12 +0200 [thread overview]
Message-ID: <493EB22C.2050108@panasas.com> (raw)
In-Reply-To: <20081209171814.GA8667@infradead.org>
Christoph Hellwig wrote:
> On Mon, Dec 08, 2008 at 02:30:03PM -0800, Andrew Morton wrote:
>> Perhaps nd_set_link() is a suitable place? Change that function so
>> that it is passed a third argument (max_len) and then check that within
>> nd_set_link(). Change nd_set_link() to return a __must_check-marked
>> errno, change callers to handle errors appropriately.
>>
>> Or something totally different ;) But along those lines?
>
> Note that XFS and possibly other filesystem don't store the NULL
> termination on disk.
Note that ext2, for example, also only writes the string bytes without
any NULLs. It only happen to be zero padded because any last-page is zero-padded
from i_size to end of page.
> So having a follow_link interface that uses a
> counted string would be a nice little optimization for the XFS
> follow_link / readlink implementation. But I'm not really sure it's
> worth complicating the VFS for that little gem.
>
The inode's i_size already holds the string count so at the higher level
we have that information. But I'm convinced, nd_set_link() should receive
a new max_len, all users should be changed as a matter of code audit.
nd_set_link() should then proceed to truncate the string at that length
unconditionally no need for error returns.
My $0.017
Boaz
next prev parent reply other threads:[~2008-12-09 18:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-05 14:48 Checking link targets are NULL-terminated Duane Griffin
2008-12-08 22:30 ` Andrew Morton
2008-12-09 17:18 ` Christoph Hellwig
2008-12-09 18:00 ` Boaz Harrosh [this message]
2008-12-11 16:06 ` Duane Griffin
2008-12-09 15:30 ` Boaz Harrosh
2008-12-09 16:20 ` Duane Griffin
2008-12-09 16:46 ` Boaz Harrosh
2008-12-09 18:04 ` Duane Griffin
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=493EB22C.2050108@panasas.com \
--to=bharrosh@panasas.com \
--cc=akpm@linux-foundation.org \
--cc=duaneg@dghda.com \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.