[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141016220126.GK11522@wil.cx>
Date: Thu, 16 Oct 2014 18:01:26 -0400
From: Matthew Wilcox <willy@...ux.intel.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Matthew Wilcox <matthew.r.wilcox@...el.com>,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Ross Zwisler <ross.zwisler@...ux.intel.com>
Subject: Re: [PATCH v11 19/21] dax: Add dax_zero_page_range
On Thu, Oct 16, 2014 at 02:38:24PM +0200, Mathieu Desnoyers wrote:
> > +int dax_zero_page_range(struct inode *inode, loff_t from, unsigned length,
>
> nit: unsigned -> unsigned int ?
>
> Do we want a unsigned int or unsigned long here ?
It's supposed to be for a fragment of a page, so until we see a machine
with PAGE_SIZE > 4GB, we're good to use an unsigned int.
> > if (!length)
> > return 0;
> > + BUG_ON((offset + length) > PAGE_CACHE_SIZE);
>
> Isn't it a bit extreme to BUG_ON this condition ? We could return an
> error to the caller, and perhaps WARN_ON_ONCE(), but BUG_ON() appears to
> be slightly too strong here.
Dave Chinner asked for it :-) The filesystem is supposed to be doing
this clamping (until the last version, I had this function doing the
clamping, and I was told off for "leaving landmines lying around".
> > +static inline int dax_zero_page_range(struct inode *i, loff_t frm,
> > + unsigned len, get_block_t gb)
> > +{
> > + return 0;
>
> Should we return 0 or -ENOSYS here ?
I kind of wonder if we shouldn't just declare the function. It's called
like this:
if (IS_DAX(inode))
return dax_zero_page_range(inode, from, length, ext4_get_block);
return __ext4_block_zero_page_range(handle, mapping, from, length);
and if CONFIG_DAX is not set, IS_DAX evaluates to 0 at compile time, so
the compiler will optimise out the call to dax_zero_page_range() anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists