linux-next: build failure after merge of the ext4 tree

linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

Hi Theodore,

After merging the ext4 tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/ext4/ialloc.c: In function '__ext4_new_inode':
fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
 next_ino:
 ^
fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
    goto next_inode;
    ^

Hmm ...

Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
inodes in no journal mode").

I have used the ext4 tree from next-20130726 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Hi Ted,

On Mon, 29 Jul 2013 11:08:16 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the ext4 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/ext4/ialloc.c: In function '__ext4_new_inode':
> fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
>  next_ino:
>  ^
> fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
>     goto next_inode;
>     ^
> 
> Hmm ...
> 
> Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
> inodes in no journal mode").
> 
> I have used the ext4 tree from next-20130726 for today.

I am still getting this ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Sedat Dilek]

On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Theodore,
>
> After merging the ext4 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/ext4/ialloc.c: In function '__ext4_new_inode':
> fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
>  next_ino:
>  ^
> fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
>     goto next_inode;
>     ^
>
> Hmm ...
>
> Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
> inodes in no journal mode").
>
> I have used the ext4 tree from next-20130726 for today.

Since this message ext4-tree was not updated.
The commit "ext4: avoid reusing recently deleted inodes in no journal
mode" was refreshed and has a different commit-id.
Did you test with this one? You still see the breakage?

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/patch/?id=533ec0ed5bac34233087f0c10c698d20095d6628

Re: linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Hi Sedat,

On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
<sedat.dilek@gmail.com> wrote:
>
> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the ext4 tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/ext4/ialloc.c: In function '__ext4_new_inode':
> > fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
> >  next_ino:
> >  ^
> > fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
> >     goto next_inode;
> >     ^
> >
> > Hmm ...
> >
> > Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
> > inodes in no journal mode").
> >
> > I have used the ext4 tree from next-20130726 for today.
> 
> Since this message ext4-tree was not updated.
> The commit "ext4: avoid reusing recently deleted inodes in no journal
> mode" was refreshed and has a different commit-id.
> Did you test with this one? You still see the breakage?

Today's linux-next does not have this build failure.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Sedat Dilek]

On Wed, Aug 7, 2013 at 7:38 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Sedat,
>
> On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
> <sedat.dilek@gmail.com> wrote:
>>
>> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > After merging the ext4 tree, today's linux-next build (powerpc
>> > ppc64_defconfig) failed like this:
>> >
>> > fs/ext4/ialloc.c: In function '__ext4_new_inode':
>> > fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
>> >  next_ino:
>> >  ^
>> > fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
>> >     goto next_inode;
>> >     ^
>> >
>> > Hmm ...
>> >
>> > Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
>> > inodes in no journal mode").
>> >
>> > I have used the ext4 tree from next-20130726 for today.
>>
>> Since this message ext4-tree was not updated.
>> The commit "ext4: avoid reusing recently deleted inodes in no journal
>> mode" was refreshed and has a different commit-id.
>> Did you test with this one? You still see the breakage?
>
> Today's linux-next does not have this build failure.

The refreshed patch is from 02-Aug-2013.
So why did next-20130805 and next-20130806 did not have it?
I was reading for these Linux-next releases the same: "I have used the
ext4 tree from next-20130726 for today.".
I am wondering what went wrong.

- Sedat -

> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

Re: linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Hi Sedat,

On Wed, 7 Aug 2013 07:43:59 +0200 Sedat Dilek
<sedat.dilek@gmail.com> wrote:
>
> The refreshed patch is from 02-Aug-2013.
> So why did next-20130805 and next-20130806 did not have it?
> I was reading for these Linux-next releases the same: "I have used the
> ext4 tree from next-20130726 for today.".
> I am wondering what went wrong.

Ted did not update the branch of his tree that is included in linux-next
until now.  Presumably he was doing some testing - there were other
changes in it as well.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Kevin Hilman]

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi Sedat,
>
> On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
> <sedat.dilek@gmail.com> wrote:
>>
>> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > After merging the ext4 tree, today's linux-next build (powerpc
>> > ppc64_defconfig) failed like this:
>> >
>> > fs/ext4/ialloc.c: In function '__ext4_new_inode':
>> > fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
>> >  next_ino:
>> >  ^
>> > fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
>> >     goto next_inode;
>> >     ^
>> >
>> > Hmm ...
>> >
>> > Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
>> > inodes in no journal mode").
>> >
>> > I have used the ext4 tree from next-20130726 for today.
>> 
>> Since this message ext4-tree was not updated.
>> The commit "ext4: avoid reusing recently deleted inodes in no journal
>> mode" was refreshed and has a different commit-id.
>> Did you test with this one? You still see the breakage?
>
> Today's linux-next does not have this build failure.

However, this same commit does introduce a new build failure (not
present in next-20130806) when ext4 is built as a module:

ERROR: "dirty_expire_interval" [fs/ext4/ext4.ko] undefined!
make[3]: *** [__modpost] Error 1
make[2]: *** [modules] Error 2

The change below fixes the problem.

Found when building the mv78xx0_defconfig on ARM.

Kevin

------------8<--------------
>From 8bd28888e08124d9b298f42a0e0c3a7584ba285f Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Wed, 7 Aug 2013 08:17:43 -0700
Subject: [PATCH] mm: page-writeback: export dirty_expire_interval, used by
 ext4

commit 533ec0ed (ext4: avoid reusing recently deleted inodes in no
journal mode) started using dirty_expire_inteval, which is not
available to modules.  Make it available to modules.

Cc: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
 mm/page-writeback.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index d374b29..c8b61ef 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -104,6 +104,8 @@ EXPORT_SYMBOL_GPL(dirty_writeback_interval);
  */
 unsigned int dirty_expire_interval = 30 * 100; /* centiseconds */
 
+EXPORT_SYMBOL_GPL(dirty_expire_interval);
+
 /*
  * Flag that makes the machine dump writes/reads and block dirtyings.
  */
-- 
1.8.3

Re: linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

Hi Kevin,

On Wed, 07 Aug 2013 08:28:35 -0700 Kevin Hilman
<khilman@linaro.org> wrote:
>
> However, this same commit does introduce a new build failure (not
> present in next-20130806) when ext4 is built as a module:
> 
> ERROR: "dirty_expire_interval" [fs/ext4/ext4.ko] undefined!
> make[3]: *** [__modpost] Error 1
> make[2]: *** [modules] Error 2
> 
> The change below fixes the problem.
> 
> Found when building the mv78xx0_defconfig on ARM.

OK, this raises an interesting question for me.  Why does an x86_64
allmodconfig build build ext4 (amongst lots of other things) into the
kernel (instead of making them modules)?

Well, it seems that normally it doesn't.  However when I do my
x86_64 allmodconfig builds, I set

CONFIG_PROFILE_ALL_BRANCHES=n
CONFIG_DEBUG_INFO=n
CONFIG_X86_DECODER_SELFTEST=n

via the KCONFIG_ALLCONFIG=<file> mechanism and that is enough to make
sure that CONFIG_MODULES=n - which is a bit self defeating for an
allmodconfig build. :-(

In fact, even giving an empty file to KCONFIG_ALLCONFIG= is enough to
turn CONFIG_MODULES off ...

These tests were done with Linus' tree of today (head commit b7bc9e7
"Merge tag 'trace-fixes-3.11-rc3' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace").

More quick testing with an empty file: v3.9 is OK, v3.10 gives
CONFIG_MODULES unset.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
wrote:
>
> More quick testing with an empty file: v3.9 is OK, v3.10 gives
> CONFIG_MODULES unset.

Bisecting gives:

cfa98f2e0ae956feca935573e977d7661a9561b9 is the first bad commit
commit cfa98f2e0ae956feca935573e977d7661a9561b9
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date:   Wed Apr 24 22:00:04 2013 +0200

    kconfig: do not override symbols already set
    
    For randconfig, if a list of required symbols is specified with
    KCONFIG_ALLCONFIG, such symbols do not "have a value" as per
    sym_has_value(), but have the "valid" flag set.
    
    Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>


And reverting that commit in v3.10 gives me CONFIG_MODULES=y.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Yann E. MORIN]

Stephen, All,

On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly:
> On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
> wrote:
> >
> > More quick testing with an empty file: v3.9 is OK, v3.10 gives
> > CONFIG_MODULES unset.

Sorry, I don't understand the above. Can you elaborate on what you did,
what you got, what expected, so I can try to reproduce and fix this,
please?

> Bisecting gives:
> 
> cfa98f2e0ae956feca935573e977d7661a9561b9 is the first bad commit
> commit cfa98f2e0ae956feca935573e977d7661a9561b9
> Author: Yann E. MORIN <yann.morin.1998@free.fr>
> Date:   Wed Apr 24 22:00:04 2013 +0200
> 
>     kconfig: do not override symbols already set
>     
>     For randconfig, if a list of required symbols is specified with
>     KCONFIG_ALLCONFIG, such symbols do not "have a value" as per
>     sym_has_value(), but have the "valid" flag set.
>     
>     Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> And reverting that commit in v3.10 gives me CONFIG_MODULES=y.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Re: linux-next: build failure after merge of the ext4 tree

[Yann E. MORIN]

Stephen, All,

On 2013-08-08 21:16 +0200, Yann E. MORIN spake thusly:
> On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly:
> > On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
> > wrote:
> > >
> > > More quick testing with an empty file: v3.9 is OK, v3.10 gives
> > > CONFIG_MODULES unset.
> 
> Sorry, I don't understand the above. Can you elaborate on what you did,
> what you got, what expected, so I can try to reproduce and fix this,
> please?

Ok, I've had a look in the linux-next archives, and I think I got it.
Is the following right?

    git clean -d; git clean -dX     # To be sure tree is clean
    touch empty
    make KCONFIG_ALLCONFIG=empty allmodconfig
    grep MODULES .config
    $ CONFIG_MODULES is not set

If so, I think I found the reason: the modules symbol is _always_ set to
being valid as soon as KCONFIG_ALLCONFIG is read, even if it was not
present in that file.

Since it is set to be valid, the following change means it is not
affected another value later on.

So, I wonder what the best option is:
  1- revert the following, and find another solution,
  2- de-specialise the modules symbol,
  3- or further specialise the modules symbol.

I'd be inclined to go for 1, but I have no straightforward idea so far.
It's late here, so I'll look more thouroughly this WE.

> > Bisecting gives:
> > 
> > cfa98f2e0ae956feca935573e977d7661a9561b9 is the first bad commit
> > commit cfa98f2e0ae956feca935573e977d7661a9561b9
> > Author: Yann E. MORIN <yann.morin.1998@free.fr>
> > Date:   Wed Apr 24 22:00:04 2013 +0200
> > 
> >     kconfig: do not override symbols already set
> >     
> >     For randconfig, if a list of required symbols is specified with
> >     KCONFIG_ALLCONFIG, such symbols do not "have a value" as per
> >     sym_has_value(), but have the "valid" flag set.
> >     
> >     Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> > 
> > And reverting that commit in v3.10 gives me CONFIG_MODULES=y.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Re: linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

Hi Yann,

On Thu, 8 Aug 2013 23:54:49 +0200 "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
>
> Ok, I've had a look in the linux-next archives, and I think I got it.
> Is the following right?
> 
>     git clean -d; git clean -dX     # To be sure tree is clean
>     touch empty
>     make KCONFIG_ALLCONFIG=empty allmodconfig
>     grep MODULES .config
>     $ CONFIG_MODULES is not set

Yes, that is what I am seeing.

> If so, I think I found the reason: the modules symbol is _always_ set to
> being valid as soon as KCONFIG_ALLCONFIG is read, even if it was not
> present in that file.
> 
> Since it is set to be valid, the following change means it is not
> affected another value later on.
> 
> So, I wonder what the best option is:
>   1- revert the following, and find another solution,
>   2- de-specialise the modules symbol,
>   3- or further specialise the modules symbol.
> 
> I'd be inclined to go for 1, but I have no straightforward idea so far.
> It's late here, so I'll look more thouroughly this WE.

Thanks.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Sam Ravnborg]

On Thu, Aug 08, 2013 at 11:54:49PM +0200, Yann E. MORIN wrote:
> Stephen, All,
> 
> On 2013-08-08 21:16 +0200, Yann E. MORIN spake thusly:
> > On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly:
> > > On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
> > > wrote:
> > > >
> > > > More quick testing with an empty file: v3.9 is OK, v3.10 gives
> > > > CONFIG_MODULES unset.
> > 
> > Sorry, I don't understand the above. Can you elaborate on what you did,
> > what you got, what expected, so I can try to reproduce and fix this,
> > please?
> 
> Ok, I've had a look in the linux-next archives, and I think I got it.
> Is the following right?
> 
>     git clean -d; git clean -dX     # To be sure tree is clean
>     touch empty
>     make KCONFIG_ALLCONFIG=empty allmodconfig
>     grep MODULES .config
>     $ CONFIG_MODULES is not set
> 
> If so, I think I found the reason: the modules symbol is _always_ set to
> being valid as soon as KCONFIG_ALLCONFIG is read, even if it was not
> present in that file.
> 
> Since it is set to be valid, the following change means it is not
> affected another value later on.
> 
> So, I wonder what the best option is:
>   1- revert the following, and find another solution,
>   2- de-specialise the modules symbol,
>   3- or further specialise the modules symbol.

If we drop the special handling of "MODULES" and introduced
the following in we may fix it - hopefully:

config MODULES
	option modules

The option handling is already in place. It is even documented :-)

At least we could then drop the sym_lookup here (zconf.y):
        if (!modules_sym->prop) {
                struct property *prop;

                prop = prop_alloc(P_DEFAULT, modules_sym);
                prop->expr = expr_alloc_symbol(sym_lookup("MODULES", 0));
        }
Without the sym_lookup I think the symbol will not be defined and tus not marked valid.

Soory - no patch as I am busy with day-time job stuff.

	Sam

Re: linux-next: build failure after merge of the ext4 tree

[Yann E. MORIN]

Sam, All,

On 2013-08-09 13:42 +0200, Sam Ravnborg spake thusly:
> On Thu, Aug 08, 2013 at 11:54:49PM +0200, Yann E. MORIN wrote:
> > Stephen, All,
> > 
> > On 2013-08-08 21:16 +0200, Yann E. MORIN spake thusly:
> > > On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly:
> > > > On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
> > > > wrote:
> > > > >
> > > > > More quick testing with an empty file: v3.9 is OK, v3.10 gives
> > > > > CONFIG_MODULES unset.
> > > 
> > > Sorry, I don't understand the above. Can you elaborate on what you did,
> > > what you got, what expected, so I can try to reproduce and fix this,
> > > please?
> > 
> > Ok, I've had a look in the linux-next archives, and I think I got it.
> > Is the following right?
> > 
> >     git clean -d; git clean -dX     # To be sure tree is clean
> >     touch empty
> >     make KCONFIG_ALLCONFIG=empty allmodconfig
> >     grep MODULES .config
> >     $ CONFIG_MODULES is not set
> > 
> > If so, I think I found the reason: the modules symbol is _always_ set to
> > being valid as soon as KCONFIG_ALLCONFIG is read, even if it was not
> > present in that file.
> > 
> > Since it is set to be valid, the following change means it is not
> > affected another value later on.
> > 
> > So, I wonder what the best option is:
> >   1- revert the following, and find another solution,
> >   2- de-specialise the modules symbol,
> >   3- or further specialise the modules symbol.
> 
> If we drop the special handling of "MODULES" and introduced
> the following in we may fix it - hopefully:
> 
> config MODULES
> 	option modules
> 
> The option handling is already in place. It is even documented :-)

Yes, indeed, that one is pretty easy! :-)

> At least we could then drop the sym_lookup here (zconf.y):
>         if (!modules_sym->prop) {
>                 struct property *prop;
> 
>                 prop = prop_alloc(P_DEFAULT, modules_sym);
>                 prop->expr = expr_alloc_symbol(sym_lookup("MODULES", 0));
>         }
> Without the sym_lookup I think the symbol will not be defined and tus not marked valid.

Sorry, I don't understand what we should do here.

>From what I understand, here's what happens:
  - there's no symbol that declared the 'modules' option, so the
    modules_sym->prop is NULL;
  - so we look for the symbol 'MODULES' and use that as the symbol used
    to evaluate if tristates are enabled.

So, now we have 'option modules' added to MODULES, we never enter this
if() condition.

But what would happen to other projects that do not have a symbol set
with 'option modules' and no 'MODULES' symbol? Surely, those projects do
not need tristates, but what should the code do in this case?

So, I don't know what to replace this 'sym_lookup("MODULES", 0)' with.

> Soory - no patch as I am busy with day-time job stuff.

I hope you can share some guidnce here, please... ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Re: linux-next: build failure after merge of the ext4 tree

[Michal Marek]

On 11.8.2013 23:39, Yann E. MORIN wrote:
> On 2013-08-09 13:42 +0200, Sam Ravnborg spake thusly:
>> If we drop the special handling of "MODULES" and introduced
>> the following in we may fix it - hopefully:
>>
>> config MODULES
>> 	option modules
>>
>> The option handling is already in place. It is even documented :-)
> 
> Yes, indeed, that one is pretty easy! :-)
> 
>> At least we could then drop the sym_lookup here (zconf.y):
>>         if (!modules_sym->prop) {
>>                 struct property *prop;
>>
>>                 prop = prop_alloc(P_DEFAULT, modules_sym);
>>                 prop->expr = expr_alloc_symbol(sym_lookup("MODULES", 0));
>>         }
>> Without the sym_lookup I think the symbol will not be defined and tus not marked valid.
> 
> Sorry, I don't understand what we should do here.
> 
> From what I understand, here's what happens:
>   - there's no symbol that declared the 'modules' option, so the
>     modules_sym->prop is NULL;
>   - so we look for the symbol 'MODULES' and use that as the symbol used
>     to evaluate if tristates are enabled.
> 
> So, now we have 'option modules' added to MODULES, we never enter this
> if() condition.
> 
> But what would happen to other projects that do not have a symbol set
> with 'option modules' and no 'MODULES' symbol? Surely, those projects do
> not need tristates, but what should the code do in this case?
> 
> So, I don't know what to replace this 'sym_lookup("MODULES", 0)' with.

If the Kconfig files do not provide any symbol with 'option modules',
then set modules_sym to a dummy bool with the value 'n'?

Thanks,
Michal

Re: linux-next: build failure after merge of the ext4 tree

[Sam Ravnborg]

On Fri, Aug 16, 2013 at 03:10:38PM +0200, Michal Marek wrote:
> On 11.8.2013 23:39, Yann E. MORIN wrote:
> > On 2013-08-09 13:42 +0200, Sam Ravnborg spake thusly:
> >> If we drop the special handling of "MODULES" and introduced
> >> the following in we may fix it - hopefully:
> >>
> >> config MODULES
> >> 	option modules
> >>
> >> The option handling is already in place. It is even documented :-)
> > 
> > Yes, indeed, that one is pretty easy! :-)
> > 
> >> At least we could then drop the sym_lookup here (zconf.y):
> >>         if (!modules_sym->prop) {
> >>                 struct property *prop;
> >>
> >>                 prop = prop_alloc(P_DEFAULT, modules_sym);
> >>                 prop->expr = expr_alloc_symbol(sym_lookup("MODULES", 0));
> >>         }
> >> Without the sym_lookup I think the symbol will not be defined and tus not marked valid.
> > 
> > Sorry, I don't understand what we should do here.
> > 
> > From what I understand, here's what happens:
> >   - there's no symbol that declared the 'modules' option, so the
> >     modules_sym->prop is NULL;
> >   - so we look for the symbol 'MODULES' and use that as the symbol used
> >     to evaluate if tristates are enabled.
> > 
> > So, now we have 'option modules' added to MODULES, we never enter this
> > if() condition.
> > 
> > But what would happen to other projects that do not have a symbol set
> > with 'option modules' and no 'MODULES' symbol? Surely, those projects do
> > not need tristates, but what should the code do in this case?
> > 
> > So, I don't know what to replace this 'sym_lookup("MODULES", 0)' with.
> 
> If the Kconfig files do not provide any symbol with 'option modules',
> then set modules_sym to a dummy bool with the value 'n'?
This is my thinking too - to use the symbol "n".
But I wanted to try it out - but so far have not had time for it.

	Sam

Re: linux-next: build failure after merge of the ext4 tree

[Yann E. MORIN]

Sam, Michal, All,

On 2013-08-16 19:14 +0200, Sam Ravnborg spake thusly:
> On Fri, Aug 16, 2013 at 03:10:38PM +0200, Michal Marek wrote:
> > On 11.8.2013 23:39, Yann E. MORIN wrote:
> > > On 2013-08-09 13:42 +0200, Sam Ravnborg spake thusly:
> > >> If we drop the special handling of "MODULES" and introduced
> > >> the following in we may fix it - hopefully:
> > >>
> > >> config MODULES
> > >> 	option modules
> > >>
> > >> The option handling is already in place. It is even documented :-)
> > > 
> > > Yes, indeed, that one is pretty easy! :-)
> > > 
> > >> At least we could then drop the sym_lookup here (zconf.y):
> > >>         if (!modules_sym->prop) {
> > >>                 struct property *prop;
> > >>
> > >>                 prop = prop_alloc(P_DEFAULT, modules_sym);
> > >>                 prop->expr = expr_alloc_symbol(sym_lookup("MODULES", 0));
> > >>         }
> > >> Without the sym_lookup I think the symbol will not be defined and tus not marked valid.
> > > 
> > > Sorry, I don't understand what we should do here.
> > > 
> > > From what I understand, here's what happens:
> > >   - there's no symbol that declared the 'modules' option, so the
> > >     modules_sym->prop is NULL;
> > >   - so we look for the symbol 'MODULES' and use that as the symbol used
> > >     to evaluate if tristates are enabled.
> > > 
> > > So, now we have 'option modules' added to MODULES, we never enter this
> > > if() condition.
> > > 
> > > But what would happen to other projects that do not have a symbol set
> > > with 'option modules' and no 'MODULES' symbol? Surely, those projects do
> > > not need tristates, but what should the code do in this case?
> > > 
> > > So, I don't know what to replace this 'sym_lookup("MODULES", 0)' with.
> > 
> > If the Kconfig files do not provide any symbol with 'option modules',
> > then set modules_sym to a dummy bool with the value 'n'?
> This is my thinking too - to use the symbol "n".
> But I wanted to try it out - but so far have not had time for it.

OK, I'll tackle this. Thanks for the info. :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

Hi Ted,

After merging the ext4 tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from include/linux/srcu.h:33,
                 from include/linux/notifier.h:16,
                 from include/linux/memory_hotplug.h:7,
                 from include/linux/mmzone.h:752,
                 from include/linux/gfp.h:6,
                 from include/linux/umh.h:4,
                 from include/linux/kmod.h:22,
                 from include/linux/module.h:13,
                 from fs/ext4/super.c:20:
fs/ext4/super.c: In function 'get_qf_name':
fs/ext4/super.c:931:40: error: 'struct ext4_sb_info' has no member named 's_qf_names'; did you mean 's_mb_maxs'?
  return rcu_dereference_protected(sbi->s_qf_names[type],
                                        ^~~~~~~~~~
include/linux/rcupdate.h:358:12: note: in definition of macro '__rcu_dereference_protected'
  ((typeof(*p) __force __kernel *)(p)); \
            ^
fs/ext4/super.c:931:9: note: in expansion of macro 'rcu_dereference_protected'
  return rcu_dereference_protected(sbi->s_qf_names[type],
         ^~~~~~~~~~~~~~~~~~~~~~~~~
fs/ext4/super.c:931:40: error: 'struct ext4_sb_info' has no member named 's_qf_names'; did you mean 's_mb_maxs'?
  return rcu_dereference_protected(sbi->s_qf_names[type],
                                        ^~~~~~~~~~
include/linux/rcupdate.h:358:35: note: in definition of macro '__rcu_dereference_protected'
  ((typeof(*p) __force __kernel *)(p)); \
                                   ^
fs/ext4/super.c:931:9: note: in expansion of macro 'rcu_dereference_protected'
  return rcu_dereference_protected(sbi->s_qf_names[type],
         ^~~~~~~~~~~~~~~~~~~~~~~~~
fs/ext4/super.c: In function 'parse_options':
fs/ext4/super.c:1976:26: warning: unused variable 'grp_qf_name' [-Wunused-variable]
  char *p, *usr_qf_name, *grp_qf_name;
                          ^~~~~~~~~~~
fs/ext4/super.c:1976:12: warning: unused variable 'usr_qf_name' [-Wunused-variable]
  char *p, *usr_qf_name, *grp_qf_name;
            ^~~~~~~~~~~

Caused by commit

  cc1ee227e890 ("ext4: fix use-after-free race in ext4_remount()'s error path")

# CONFIG_QUOTA is not set

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Theodore Y. Ts'o]

On Tue, Oct 09, 2018 at 10:51:02AM +1100, Stephen Rothwell wrote:
> Hi Ted,
> 
> After merging the ext4 tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:

Oops, my bad.  Thanks for catching this.  I failed to a new helper
function inside #ifdef CONFIG_QUOTA .. #endif.

Should be fixed now.

						- Ted

linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

Hi Ted,

After merging the ext4 tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

fs/ext4/namei.c: In function 'ext4_lookup':
fs/ext4/namei.c:1572:24: error: 'struct ext4_inode_info' has no member named 'i_crypt_info'
         if (EXT4_I(dir)->i_crypt_info == NULL)
                        ^

i_crypt_info only exists when CONFIG_EXT4_FS_ENCRYPTION is set.

Caused by commit

  676a9962a683 ("ext4 crypto: revalidate dentry after adding or removing the key")

I have used the ext4 tree from next-20160205 for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

Hi Ted,

After merging the ext4 tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

fs/ext4/ioctl.c: In function 'ext4_ioctl_setproject':
fs/ext4/ioctl.c:399:26: error: implicit declaration of function 'dqget' [-Werror=implicit-function-declaration]
  transfer_to[PRJQUOTA] = dqget(sb, make_kqid_projid(kprojid));
                          ^
fs/ext4/ioctl.c:399:24: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
  transfer_to[PRJQUOTA] = dqget(sb, make_kqid_projid(kprojid));
                        ^
fs/ext4/ioctl.c:401:9: error: implicit declaration of function '__dquot_transfer' [-Werror=implicit-function-declaration]
   err = __dquot_transfer(inode, transfer_to);
         ^
fs/ext4/ioctl.c:402:3: error: implicit declaration of function 'dqput' [-Werror=implicit-function-declaration]
   dqput(transfer_to[PRJQUOTA]);
   ^
fs/ext4/super.c: In function 'ext4_statfs_project':
fs/ext4/super.c:4839:10: error: implicit declaration of function 'dqget' [-Werror=implicit-function-declaration]
  dquot = dqget(sb, qid);
          ^
fs/ext4/super.c:4839:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
  dquot = dqget(sb, qid);
        ^
fs/ext4/super.c:4866:2: error: implicit declaration of function 'dqput' [-Werror=implicit-function-declaration]
  dqput(dquot);
  ^

CONFIG_QUOTA is not set for this build.

Caused by commit

  92a86644738b ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support")

I have used the ext4 tree from next-20151231 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

Re: linux-next: build failure after merge of the ext4 tree

[Theodore Ts'o]

On Mon, Jan 04, 2016 at 10:34:19AM +1100, Stephen Rothwell wrote:
> Hi Ted,
> 
> After merging the ext4 tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:...

Thanks for pointing this out!  I fixed it last night so it should be
ready for the next linux-build integration cycle.

						- Ted

linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

Hi Theodore,

After merging the ext4 tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "wbc_account_io" [fs/ext4/ext4.ko] undefined!
ERROR: "bio_associate_blkcg" [fs/ext4/ext4.ko] undefined!

Caused by commit

  001e4a8775f6 ("ext4: implement cgroup writeback support")

I have used the ext4 tree from next-20150722 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

Re: linux-next: build failure after merge of the ext4 tree

[Theodore Ts'o]

On Thu, Jul 23, 2015 at 10:56:23AM +1000, Stephen Rothwell wrote:
> Hi Theodore,
> 
> After merging the ext4 tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "wbc_account_io" [fs/ext4/ext4.ko] undefined!
> ERROR: "bio_associate_blkcg" [fs/ext4/ext4.ko] undefined!
> 
> Caused by commit
> 
>   001e4a8775f6 ("ext4: implement cgroup writeback support")
> 
> I have used the ext4 tree from next-20150722 for today.

Ah, I see, we're missing the include files which define the inline
dummy functions.  I'll fix this in my tree, thanks.

      		       	   	      	    - Ted

Re: linux-next: build failure after merge of the ext4 tree

[Theodore Ts'o]

On Thu, Jul 23, 2015 at 12:49:53PM -0400, Theodore Ts'o wrote:
> > After merging the ext4 tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > ERROR: "wbc_account_io" [fs/ext4/ext4.ko] undefined!
> > ERROR: "bio_associate_blkcg" [fs/ext4/ext4.ko] undefined!
> > 
> > Caused by commit
> > 
> >   001e4a8775f6 ("ext4: implement cgroup writeback support")
> > 
> > I have used the ext4 tree from next-20150722 for today.
> 
> Ah, I see, we're missing the include files which define the inline
> dummy functions.  I'll fix this in my tree, thanks.

Whoops, correction, the problem is that wbc_account_io() and
bio_asociate_blkcg() need to be exported as symbols.

Tejun, how quickly get you get a fix into linux-next?  Or should I
just drop that patch for now?

						- Ted
						

Re: linux-next: build failure after merge of the ext4 tree

[Tejun Heo]

On Thu, Jul 23, 2015 at 01:23:43PM -0400, Theodore Ts'o wrote:
> On Thu, Jul 23, 2015 at 12:49:53PM -0400, Theodore Ts'o wrote:
> > > After merging the ext4 tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > ERROR: "wbc_account_io" [fs/ext4/ext4.ko] undefined!
> > > ERROR: "bio_associate_blkcg" [fs/ext4/ext4.ko] undefined!
> > > 
> > > Caused by commit
> > > 
> > >   001e4a8775f6 ("ext4: implement cgroup writeback support")
> > > 
> > > I have used the ext4 tree from next-20150722 for today.
> > 
> > Ah, I see, we're missing the include files which define the inline
> > dummy functions.  I'll fix this in my tree, thanks.
> 
> Whoops, correction, the problem is that wbc_account_io() and
> bio_asociate_blkcg() need to be exported as symbols.
> 
> Tejun, how quickly get you get a fix into linux-next?  Or should I
> just drop that patch for now?

I'll send the patch to add EXPORT to Jens right away.

Thanks.

-- 
tejun

linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

Hi Ted,

After merging the ext4 tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/ext4/file.c: In function 'ext4_file_mmap':
fs/ext4/file.c:226:3: error: implicit declaration of function 'ext4_get_encryption_info' [-Werror=implicit-function-declaration]
   int err = ext4_get_encryption_info(inode);
   ^
fs/ext4/super.c: In function 'ext4_clear_inode':
fs/ext4/super.c:958:19: error: 'struct ext4_inode_info' has no member named 'i_crypt_info'
  if (EXT4_I(inode)->i_crypt_info)
                   ^

Caused by commit ef8a5d07c606 ("ext4 crypto: reorganize how we store
keys in the inode").  This build has CONFIG_EXT4_FS_ENCRYPTION not set.

I have used the ext4 tree from next-20150506 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

Hi Ted,

After merging the ext4 tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/ext4/resize.c: In function 'ext4_resize_fs':
fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
fs/ext4/resize.c:1882:10: sorry, unimplemented: called from here
fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
fs/ext4/resize.c:275:9: sorry, unimplemented: called from here
fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
fs/ext4/resize.c:287:9: sorry, unimplemented: called from here
fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
fs/ext4/resize.c:299:9: sorry, unimplemented: called from here
fs/ext4/mballoc.c: In function 'ext4_mb_release_context':
fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
fs/ext4/mballoc.c:3347:6: sorry, unimplemented: called from here

Caused by commit dc351389caa5 ("ext4: introduce ext4_get_group_number()").

This build was done with gcc 4.6.3 if that matters.

I have used the ext4 tree from next-20130403 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Lukáš Czerner]

On Thu, 4 Apr 2013, Stephen Rothwell wrote:

> Date: Thu, 4 Apr 2013 10:43:19 +1100
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> To: Theodore Ts'o <tytso@mit.edu>
> Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
>     Lukas Czerner <lczerner@redhat.com>
> Subject: linux-next: build failure after merge of the ext4 tree
> 
> Hi Ted,
> 
> After merging the ext4 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/ext4/resize.c: In function 'ext4_resize_fs':
> fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
> fs/ext4/resize.c:1882:10: sorry, unimplemented: called from here
> fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
> fs/ext4/resize.c:275:9: sorry, unimplemented: called from here
> fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
> fs/ext4/resize.c:287:9: sorry, unimplemented: called from here
> fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
> fs/ext4/resize.c:299:9: sorry, unimplemented: called from here
> fs/ext4/mballoc.c: In function 'ext4_mb_release_context':
> fs/ext4/ext4.h:1799:21: sorry, unimplemented: inlining failed in call to 'ext4_get_group_number': function body not available
> fs/ext4/mballoc.c:3347:6: sorry, unimplemented: called from here

I am afraid I do not understand why this is happening. The commit
simply replaces ext4_get_group_no_and_offset() with
ext4_get_group_number() which has the similar definition in the same
header file. Maybe someone knows what this is all about ?

> 
> Caused by commit dc351389caa5 ("ext4: introduce ext4_get_group_number()").
> 
> This build was done with gcc 4.6.3 if that matters.
> 
> I have used the ext4 tree from next-20130403 for today.
> 

Re: linux-next: build failure after merge of the ext4 tree

[Theodore Ts'o]

On Thu, Apr 04, 2013 at 03:18:32PM +0200, Lukáš Czerner wrote:
> I am afraid I do not understand why this is happening. The commit
> simply replaces ext4_get_group_no_and_offset() with
> ext4_get_group_number() which has the similar definition in the same
> header file. Maybe someone knows what this is all about ?

I've fixed this up already in the ext4 tree.  The problem is that you
defined the function ext4_get_group_number() as "inline", but the
function body was only in fs/ext4/balloc.c.  I have no idea why gcc
wasn't complaining about this on x86, but the fix was to simply
declare the function as "extern", not as "inline".

						- Ted

Re: linux-next: build failure after merge of the ext4 tree

[Lukáš Czerner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1163 bytes --]

On Thu, 4 Apr 2013, Theodore Ts'o wrote:

> Date: Thu, 4 Apr 2013 09:20:48 -0400
> From: Theodore Ts'o <tytso@mit.edu>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>, linux-next@vger.kernel.org,
>     linux-kernel@vger.kernel.org
> Subject: Re: linux-next: build failure after merge of the ext4 tree
> 
> On Thu, Apr 04, 2013 at 03:18:32PM +0200, Lukáš Czerner wrote:
> > I am afraid I do not understand why this is happening. The commit
> > simply replaces ext4_get_group_no_and_offset() with
> > ext4_get_group_number() which has the similar definition in the same
> > header file. Maybe someone knows what this is all about ?
> 
> I've fixed this up already in the ext4 tree.  The problem is that you
> defined the function ext4_get_group_number() as "inline", but the
> function body was only in fs/ext4/balloc.c.  I have no idea why gcc
> wasn't complaining about this on x86, but the fix was to simply
> declare the function as "extern", not as "inline".
> 
> 						- Ted
> 

Ok, that's why I have not seen it in ext4 tree :). I do not know why
I did it, but it was obviously wrong.

Thanks for fixing it.
-Lukas

linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

Hi Ted,

After merging the ext4 tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/ext4/super.c: In function 'ext4_remount':
fs/ext4/super.c:4739:4: error: implicit declaration of function 'ext4_enable_quotas' [-Werror=implicit-function-declaration]

Caused by commit 182bb8fec8f5 ("ext4: make quota as first class supported
feature").  The quota code needs to be protected by CONFIG_QUOTA.

I have used the ext4 tree from next-20120709 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Aditya Kali]

Sorry for the trouble. The following patch should fix the build.


From: Aditya Kali <adityakali@google.com>
Date: Mon, 9 Jul 2012 18:42:28 -0700
Subject: [PATCH] ext4: Fix compilation error for ext4_enable_quotas

ext4_enable_quotas should only be called under CONFIG_QUOTA
block.

Signed-off-by: Aditya Kali <adityakali@google.com>
---
 fs/ext4/super.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index a9b87c3..e4b79fc 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4734,6 +4734,7 @@ static int ext4_remount(struct super_block *sb,
int *flags, char *data)
 	if (enable_quota) {
 		if (sb_any_quota_suspended(sb))
 			dquot_resume(sb, -1);
+#ifdef CONFIG_QUOTA
 		else if (EXT4_HAS_RO_COMPAT_FEATURE(sb,
 					EXT4_FEATURE_RO_COMPAT_QUOTA)) {
 			err = ext4_enable_quotas(sb);
@@ -4742,6 +4743,7 @@ static int ext4_remount(struct super_block *sb,
int *flags, char *data)
 				goto restore_opts;
 			}
 		}
+#endif
 	}

 	ext4_msg(sb, KERN_INFO, "re-mounted. Opts: %s", orig_data);
-- 
1.7.7.3


On Mon, Jul 9, 2012 at 6:23 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ted,
>
> After merging the ext4 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/ext4/super.c: In function 'ext4_remount':
> fs/ext4/super.c:4739:4: error: implicit declaration of function 'ext4_enable_quotas' [-Werror=implicit-function-declaration]
>
> Caused by commit 182bb8fec8f5 ("ext4: make quota as first class supported
> feature").  The quota code needs to be protected by CONFIG_QUOTA.
>
> I have used the ext4 tree from next-20120709 for today.
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au



-- 

Aditya

linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]

Hi Ted,

After merging the ext4 tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/jbd2/built-in.o: In function `journal_clear_buffer_revoked_flags':
(.opd+0x5b8): multiple definition of `journal_clear_buffer_revoked_flags'
fs/jbd/built-in.o:(.opd+0x570): first defined here
fs/jbd2/built-in.o: In function `.journal_clear_buffer_revoked_flags':
(.text+0x7e80): multiple definition of `.journal_clear_buffer_revoked_flags'
fs/jbd/built-in.o:(.text+0x7970): first defined here

Caused by commit 7834c98154f1 ("jbd2: clear revoked flag on buffers
before a new transaction started") interacting with commit 8c111b3f5633
("jbd: clear revoked flag on buffers before a new transaction started")
form the ext3 tree.

I applied this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 3 Jan 2012 11:31:37 +1100
Subject: [PATCH] jbd2: sanitize a new global symbol
 (journal_clear_buffer_revoked_flags)

Fixes these build errors (when combined with the ext3 tree):

fs/jbd2/built-in.o: In function `journal_clear_buffer_revoked_flags':
(.opd+0x5b8): multiple definition of `journal_clear_buffer_revoked_flags'
fs/jbd/built-in.o:(.opd+0x570): first defined here

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/jbd2/commit.c     |    2 +-
 fs/jbd2/revoke.c     |    2 +-
 include/linux/jbd2.h |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index 7f99e17..3f5c545 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -433,7 +433,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
 	 * Clear revoked flag to reflect there is no revoked buffers
 	 * in the next transaction which is going to be started.
 	 */
-	journal_clear_buffer_revoked_flags(journal);
+	jbd2_journal_clear_buffer_revoked_flags(journal);
 
 	/*
 	 * Switch to a new revoke table.
diff --git a/fs/jbd2/revoke.c b/fs/jbd2/revoke.c
index 1c36138..c99d839 100644
--- a/fs/jbd2/revoke.c
+++ b/fs/jbd2/revoke.c
@@ -487,7 +487,7 @@ int jbd2_journal_cancel_revoke(handle_t *handle, struct journal_head *jh)
  * revoke table to reflect there is no revoked buffers in the next
  * transaction which is going to be started.
  */
-void journal_clear_buffer_revoked_flags(journal_t *journal)
+void jbd2_journal_clear_buffer_revoked_flags(journal_t *journal)
 {
 	struct jbd2_revoke_table_s *revoke = journal->j_revoke;
 	int i = 0;
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 17bf089..44b8072 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -1151,7 +1151,7 @@ extern int	jbd2_journal_set_revoke(journal_t *, unsigned long long, tid_t);
 extern int	jbd2_journal_test_revoke(journal_t *, unsigned long long, tid_t);
 extern void	jbd2_journal_clear_revoke(journal_t *);
 extern void	jbd2_journal_switch_revoke_table(journal_t *journal);
-extern void	journal_clear_buffer_revoked_flags(journal_t *journal);
+extern void	jbd2_journal_clear_buffer_revoked_flags(journal_t *journal);
 
 /*
  * The log thread user interface:
-- 
1.7.8.197.g73c6b

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3467 bytes --]

HI Ted,

On Tue, 3 Jan 2012 11:35:33 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the ext4 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/jbd2/built-in.o: In function `journal_clear_buffer_revoked_flags':
> (.opd+0x5b8): multiple definition of `journal_clear_buffer_revoked_flags'
> fs/jbd/built-in.o:(.opd+0x570): first defined here
> fs/jbd2/built-in.o: In function `.journal_clear_buffer_revoked_flags':
> (.text+0x7e80): multiple definition of `.journal_clear_buffer_revoked_flags'
> fs/jbd/built-in.o:(.text+0x7970): first defined here
> 
> Caused by commit 7834c98154f1 ("jbd2: clear revoked flag on buffers
> before a new transaction started") interacting with commit 8c111b3f5633
> ("jbd: clear revoked flag on buffers before a new transaction started")
> form the ext3 tree.
> 
> I applied this merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 3 Jan 2012 11:31:37 +1100
> Subject: [PATCH] jbd2: sanitize a new global symbol
>  (journal_clear_buffer_revoked_flags)
> 
> Fixes these build errors (when combined with the ext3 tree):
> 
> fs/jbd2/built-in.o: In function `journal_clear_buffer_revoked_flags':
> (.opd+0x5b8): multiple definition of `journal_clear_buffer_revoked_flags'
> fs/jbd/built-in.o:(.opd+0x570): first defined here
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/jbd2/commit.c     |    2 +-
>  fs/jbd2/revoke.c     |    2 +-
>  include/linux/jbd2.h |    2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
> index 7f99e17..3f5c545 100644
> --- a/fs/jbd2/commit.c
> +++ b/fs/jbd2/commit.c
> @@ -433,7 +433,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
>  	 * Clear revoked flag to reflect there is no revoked buffers
>  	 * in the next transaction which is going to be started.
>  	 */
> -	journal_clear_buffer_revoked_flags(journal);
> +	jbd2_journal_clear_buffer_revoked_flags(journal);
>  
>  	/*
>  	 * Switch to a new revoke table.
> diff --git a/fs/jbd2/revoke.c b/fs/jbd2/revoke.c
> index 1c36138..c99d839 100644
> --- a/fs/jbd2/revoke.c
> +++ b/fs/jbd2/revoke.c
> @@ -487,7 +487,7 @@ int jbd2_journal_cancel_revoke(handle_t *handle, struct journal_head *jh)
>   * revoke table to reflect there is no revoked buffers in the next
>   * transaction which is going to be started.
>   */
> -void journal_clear_buffer_revoked_flags(journal_t *journal)
> +void jbd2_journal_clear_buffer_revoked_flags(journal_t *journal)
>  {
>  	struct jbd2_revoke_table_s *revoke = journal->j_revoke;
>  	int i = 0;
> diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
> index 17bf089..44b8072 100644
> --- a/include/linux/jbd2.h
> +++ b/include/linux/jbd2.h
> @@ -1151,7 +1151,7 @@ extern int	jbd2_journal_set_revoke(journal_t *, unsigned long long, tid_t);
>  extern int	jbd2_journal_test_revoke(journal_t *, unsigned long long, tid_t);
>  extern void	jbd2_journal_clear_revoke(journal_t *);
>  extern void	jbd2_journal_switch_revoke_table(journal_t *journal);
> -extern void	journal_clear_buffer_revoked_flags(journal_t *journal);
> +extern void	jbd2_journal_clear_buffer_revoked_flags(journal_t *journal);
>  
>  /*
>   * The log thread user interface:

Ping?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]