Re: linux-next: build failure after merge of the ext4 tree
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
Re: linux-next: build failure after merge of the ext4 tree
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
Re: linux-next: build failure after merge of the ext4 tree
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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. |
'--^---^--^'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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. |
'--^---^--^'
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
> > > >
> > > > 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. |
'--^---^--^'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
s...@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. |
'--^---^--^'
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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
> > > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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 s...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Hi Yann, On Thu, 8 Aug 2013 23:54:49 +0200 "Yann E. MORIN" 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 Rothwells...@canb.auug.org.au pgpsLfV1LgcRT.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
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 > > 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 > > 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" > > > > 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. | '--^---^--^' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Stephen, All, On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly: > On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell > 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 > 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" > > 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. | '--^---^--^' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Stephen, All, On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly: On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell s...@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.1...@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.1...@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. | '--^---^--^' -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
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 s...@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.1...@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.1...@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. | '--^---^--^' -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Hi Yann, On Thu, 8 Aug 2013 23:54:49 +0200 Yann E. MORIN yann.morin.1...@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 Rothwells...@canb.auug.org.au pgpsLfV1LgcRT.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell 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 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" And reverting that commit in v3.10 gives me CONFIG_MODULES=y. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpLE4YgH3lfI.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
Hi Kevin, On Wed, 07 Aug 2013 08:28:35 -0700 Kevin Hilman 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= 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 Rothwells...@canb.auug.org.au pgpfxiInnxj1K.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
Stephen Rothwell writes:
> Hi Sedat,
>
> On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
> wrote:
>>
>> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell
>> 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 8bd2e08124d9b298f42a0e0c3a7584ba285f Mon Sep 17 00:00:00 2001
From: Kevin Hilman
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"
Signed-off-by: Kevin Hilman
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Hi Sedat, On Wed, 7 Aug 2013 07:43:59 +0200 Sedat Dilek 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 Rothwells...@canb.auug.org.au pgpzZrzM3hctj.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
Hi Sedat, On Wed, 7 Aug 2013 07:43:59 +0200 Sedat Dilek sedat.di...@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 Rothwells...@canb.auug.org.au pgpzZrzM3hctj.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
Stephen Rothwell s...@canb.auug.org.au writes: Hi Sedat, On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell s...@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 8bd2e08124d9b298f42a0e0c3a7584ba285f Mon Sep 17 00:00:00 2001 From: Kevin Hilman khil...@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 ty...@mit.edu Signed-off-by: Kevin Hilman khil...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Hi Kevin, On Wed, 07 Aug 2013 08:28:35 -0700 Kevin Hilman khil...@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 Rothwells...@canb.auug.org.au pgpfxiInnxj1K.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell s...@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.1...@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.1...@free.fr And reverting that commit in v3.10 gives me CONFIG_MODULES=y. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpLE4YgH3lfI.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
On Wed, Aug 7, 2013 at 7:38 AM, Stephen Rothwell wrote:
> Hi Sedat,
>
> On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
> wrote:
>>
>> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell
>> 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 Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Hi Sedat,
On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
wrote:
>
> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell
> 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 Rothwells...@canb.auug.org.au
pgpi5kHPR1OBo.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell s...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Hi Sedat, On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell s...@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 Rothwells...@canb.auug.org.au pgpi5kHPR1OBo.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
On Wed, Aug 7, 2013 at 7:38 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Sedat, On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell s...@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 Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Hi Ted,
On Mon, 29 Jul 2013 11:08:16 +1000 Stephen Rothwell
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 Rothwells...@canb.auug.org.au
pgpQxpcVsV926.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
Hi Ted, On Mon, 29 Jul 2013 11:08:16 +1000 Stephen Rothwell s...@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 Rothwells...@canb.auug.org.au pgpQxpcVsV926.pgp Description: PGP signature
Re: linux-next: build failure after merge of the ext4 tree
On Thu, 4 Apr 2013, Theodore Ts'o wrote: > Date: Thu, 4 Apr 2013 09:20:48 -0400 > From: Theodore Ts'o > To: Lukáš Czerner > Cc: Stephen Rothwell , linux-n...@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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
On Thu, 4 Apr 2013, Stephen Rothwell wrote:
> Date: Thu, 4 Apr 2013 10:43:19 +1100
> From: Stephen Rothwell
> To: Theodore Ts'o
> Cc: linux-n...@vger.kernel.org, linux-kernel@vger.kernel.org,
> Lukas Czerner
> 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.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
On Thu, 4 Apr 2013, Stephen Rothwell wrote: Date: Thu, 4 Apr 2013 10:43:19 +1100 From: Stephen Rothwell s...@canb.auug.org.au To: Theodore Ts'o ty...@mit.edu Cc: linux-n...@vger.kernel.org, linux-kernel@vger.kernel.org, Lukas Czerner lczer...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
On Thu, 4 Apr 2013, Theodore Ts'o wrote: Date: Thu, 4 Apr 2013 09:20:48 -0400 From: Theodore Ts'o ty...@mit.edu To: Lukáš Czerner lczer...@redhat.com Cc: Stephen Rothwell s...@canb.auug.org.au, linux-n...@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
Re: linux-next: build failure after merge of the ext4 tree
Sorry for the trouble. The following patch should fix the build.
From: Aditya Kali
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
---
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 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 Rothwells...@canb.auug.org.au
--
Aditya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ext4 tree
Sorry for the trouble. The following patch should fix the build.
From: Aditya Kali adityak...@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 adityak...@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 s...@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 Rothwells...@canb.auug.org.au
--
Aditya
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
