On Tue, 22 Apr 2014 03:50:36 +0300 "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> wrote:
> On Mon, Apr 21, 2014 at 04:35:22PM -0700, Andrew Morton wrote:
> > > + ret = faultin_page(tsk, vma, start, &foll_flags,
> > > + nonblocking);
> > > + switch (ret) {
> > > + case 0:
> > > + break;
> > > + case -EFAULT:
> > > + case -ENOMEM:
> > > + case -EHWPOISON:
> > > + return i ? i : ret;
> > > + case -EBUSY:
> > > return i;
> > > + case -ENOENT:
> > > + goto next_page;
> > > + default:
> > > + BUILD_BUG();
> >
> > hm, why the BUILD_BUG?
>
> To be sure that we can catch and handle any value faultin_page() can
> return.
Well sure, but to do that we use BUG().
BUILD_BUG() will fail to build and that of course is what happened.
> Could you show resulting faultin_page() from you tree? Or I can just
> rebase it on top of your tree once it will be published if you wish.
It looked like this:
ret = faultin_page(tsk, vma, start, &foll_flags,
nonblocking);
switch (ret) {
case 0:
break;
case -EFAULT:
case -ENOMEM:
case -EHWPOISON:
return i ? i : ret;
case -EBUSY:
return i;
case -ENOENT:
goto next_page;
default:
BUILD_BUG();
}
is that what you tested?
I suspect what happened is that your gcc worked out that faultin_page()
cannot return anything other than one of those six values and so the
compiler elided the BUILD_BUG() code. But my gcc-4.4.4 isn't that smart.
For example this:
--- a/fs/open.c~a
+++ a/fs/open.c
@@ -1101,3 +1101,9 @@ int nonseekable_open(struct inode *inode
}
EXPORT_SYMBOL(nonseekable_open);
+
+void foo(void)
+{
+ if (0)
+ BUILD_BUG();
+}
compiles OK with gcc-4.4.4.
No matter, let's just leave it as a BUG().
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>