public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Michael Halcrow <mhalcrow@us.ibm.com>
Cc: David Howells <dhowells@redhat.com>,
	akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir
Date: Wed, 06 Sep 2006 10:44:45 +0100	[thread overview]
Message-ID: <8777.1157535885@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <20060904225419.GA4367@us.ibm.com>

Michael Halcrow <mhalcrow@us.ibm.com> wrote:

> Is it safe to assume that a pointer will always be equal to or smaller
> than an unsigned long for all architectures?

I presume you're talking about the sizes of the types.  Inside the Linux
kernel:

	sizeof(void *) == sizeof(unsigned long)

must always hold true.  There are too many things that depend on it to do
otherwise.

> Casting a pointer to an unsigned long, in general, makes me a bit
> uncomfortable.

Pointers are just numbers that are used in a particular way.  Go and look in
linux/err.h:-)

> Dave Chinner told me that XFS uses 32-bit inode numbers on 32-bit
> machines, so I imagine that this patch really is only helpful for NFS.

At the moment, maybe, but they could always change it.  And what about Reiser4?

> +int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode)
> +{
> +	if (ecryptfs_inode_to_private(inode) && 

Is this part of the condition actually necessary?  Can you not guarantee that
this will always be true?

> +	ecryptfs_set_inode_lower(inode, igrab((struct inode *)lower_inode));

igrab() might fail.  I would recommend doing it before calling iget5_unlocked()
and drop the extraneous reference to lower_inode afterwards if the eCryptFS
inode returned is already set up.

You're also casting lower_inode twice.  Whilst there's nothing actually wrong
with that, it might look better if you assigned it to its own variable at the
top of the function and only do the cast once.

> +static void ecryptfs_read_inode(struct inode *inode) { }
> +

You shouldn't need that any more.  Just leave the read_inode op pointer unset.
The NULL pointer exception handler will let you know if anyone tries to access
it (which they shouldn't - only *you* should call iget*() on your own inodes).


Looks good otherwise.  Just the igrab() thing is a real problem.

David

  reply	other threads:[~2006-09-06  9:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-24 18:17 [PATCH 0/4] eCryptfs: Public key support Michael Halcrow
2006-08-24 18:18 ` [PATCH 1/4] eCryptfs: Netlink functions for public key Michael Halcrow
2006-08-25  3:54   ` Andrew Morton
2006-08-25 19:18     ` Michael Halcrow
2006-08-28 20:02       ` Andrew Morton
2006-08-24 18:19 ` [PATCH 2/4] eCryptfs: Public key header packets Michael Halcrow
2006-08-24 18:20 ` [PATCH 3/4] eCryptfs: Open-code flag manipulation Michael Halcrow
2006-08-25 21:42   ` David Howells
2006-08-24 18:20 ` [PATCH 4/4] eCryptfs: ino_t to u64 for filldir Michael Halcrow
2006-08-25 21:42   ` David Howells
2006-08-25 21:51   ` David Howells
2006-08-25 22:16     ` Michael Halcrow
2006-08-25 22:59       ` David Howells
2006-08-30 21:12         ` Michael Halcrow
2006-08-31 10:30           ` David Howells
2006-09-04 22:54             ` Michael Halcrow
2006-09-06  9:44               ` David Howells [this message]
2006-09-06 23:20                 ` Michael Halcrow
2006-09-07 10:28                   ` David Howells

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=8777.1157535885@warthog.cambridge.redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@us.ibm.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