Peter Staubach wrote:
>
> If iunique_register() fails, does not this create a memory leak
> because root will need to get iput()'d?
>
Good point, and now that we have a wrapper for new_inode that handles this
error transparently, both places are easy to fix. This patch should do it:
Signed-off-b
Jeff Layton wrote:
> Peter Staubach wrote:
> >
> > If iunique_register() fails, does not this create a memory leak
> > because root will need to get iput()'d?
> >
>
> Good point, and now that we have a wrapper for new_inode that handles this
> error transparently, both places are easy to fix.
Jeff Layton wrote:
[EMAIL PROTECTED] wrote:
>> Doh! Thanks for explaining that. Here's a respun patch with your
suggestion
>> incorporated. Seems to build correctly without stdbool.h. In fact,
I don't see
>> a stdbool.h in Linus' tree as of this morning. Are you sure that
it's needed?
>
> inc
[EMAIL PROTECTED] wrote:
>> Doh! Thanks for explaining that. Here's a respun patch with your suggestion
>> incorporated. Seems to build correctly without stdbool.h. In fact, I don't
see
>> a stdbool.h in Linus' tree as of this morning. Are you sure that it's needed?
>
> include/linux/types.h:36:t
[EMAIL PROTECTED] wrote:
>> Good catch on the inlining. I had meant to do that and missed it.
>
> Er... if you want it to *be* inlined, you have to put it into the .h
> file so the compiler knows about it at the call site. "static inline"
> tells gcc not avoid emitting a callable version.
>
> Som
> Good catch on the inlining. I had meant to do that and missed it.
Er... if you want it to *be* inlined, you have to put it into the .h
file so the compiler knows about it at the call site. "static inline"
tells gcc not avoid emitting a callable version.
Something like this the following. (You
[EMAIL PROTECTED] wrote:
> I'm very fond of , since it explicitly documents that there
> are exactly two options. It also allows the compiler a few minor
> opportunities for optimization, but that's not as big a deal.
>
> static int __simple_fill_super(struct super_block *s, int magic,
>
Jeff Layton wrote:
> This patch ensures that the inodes allocated by the functions get_sb_pseudo
> and simple_fill_super are unique, provided of course, that the filesystems
> calling them play by the rules. Currently that isn't the case, but will be
> as I get to each of the filesystems.
>
This
On Fri, Dec 08, 2006 at 08:08:03AM -0500, Jeff Layton wrote:
> Josef Sipek wrote:
> >> - ret = simple_fill_super(sb, IPATHFS_MAGIC, files);
> >> + ret = simple_fill_super(sb, IPATHFS_MAGIC, files, 1);
> >
> > I don't know...the magic looking 1 and 0 (later in the patch) seem a bit
> > arbitrary.
Josef Sipek wrote:
>> - ret = simple_fill_super(sb, IPATHFS_MAGIC, files);
>> + ret = simple_fill_super(sb, IPATHFS_MAGIC, files, 1);
>
> I don't know...the magic looking 1 and 0 (later in the patch) seem a bit
> arbitrary. Maybe a #define is in order?
Yeah, I'm not fond of that, though
On Thu, Dec 07, 2006 at 05:13:08PM -0500, Jeff Layton wrote:
> This patch ensures that the inodes allocated by the functions get_sb_pseudo
> and simple_fill_super are unique, provided of course, that the filesystems
> calling them play by the rules. Currently that isn't the case, but will be
> as I
This patch ensures that the inodes allocated by the functions get_sb_pseudo
and simple_fill_super are unique, provided of course, that the filesystems
calling them play by the rules. Currently that isn't the case, but will be
as I get to each of the filesystems.
The patch itself is pretty simple,
12 matches
Mail list logo