Re: linux-next: build failure after merge of the akpm tree
On Thu, Dec 3, 2020 at 9:52 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> mm/kasan/quarantine.c: In function 'quarantine_put':
> mm/kasan/quarantine.c:197:15: error: 'info' undeclared (first use in this
> function)
> 197 | qlink_free(&info->quarantine_link, cache);
> | ^~~~
> mm/kasan/quarantine.c:197:15: note: each undeclared identifier is reported
> only once for each function it appears in
> mm/kasan/quarantine.c:199:3: error: 'return' with no value, in function
> returning non-void [-Werror=return-type]
> 199 | return;
> | ^~
> mm/kasan/quarantine.c:171:6: note: declared here
> 171 | bool quarantine_put(struct kmem_cache *cache, void *object)
> | ^~
>
> Caused by patches
>
> "kasan: rename get_alloc/free_info"
> "kasan: sanitize objects when metadata doesn't fit"
Yeah, this is conflict with the "kasan: fix object remain in offline
per-cpu quarantine" patch.
> I have applied the following fix patch:
>
> From: Stephen Rothwell
> Date: Thu, 3 Dec 2020 19:41:49 +1100
> Subject: [PATCH] kasan-rename-get_alloc-free_info-fix
>
> Signed-off-by: Stephen Rothwell
> ---
> mm/kasan/quarantine.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index feae26ea5cbb..d98b516f372f 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -194,9 +194,9 @@ bool quarantine_put(struct kmem_cache *cache, void
> *object)
>
> q = this_cpu_ptr(&cpu_quarantine);
> if (q->offline) {
> - qlink_free(&info->quarantine_link, cache);
> + qlink_free(&meta->quarantine_link, cache);
> local_irq_restore(flags);
> - return;
> + return false;
> }
> qlist_put(q, &meta->quarantine_link, cache->size);
> if (unlikely(q->bytes > QUARANTINE_PERCPU_SIZE)) {
> --
> 2.29.2
>
> --
> Cheers,
> Stephen Rothwell
This fixup looks good to me. Thanks!
Re: linux-next: build failure after merge of the akpm tree
Hi Mike,
On Sun, 15 Nov 2020 11:01:05 +0200 Mike Rapoport wrote:
>
> My preference would be to put the entire function body in '#ifdef
> CONFIG_MEMCG' here.
OK, so today I used this:
From: Stephen Rothwell
Date: Mon, 16 Nov 2020 16:55:10 +1100
Subject: [PATCH] secretmem-add-memcg-accounting-fix2
Signed-off-by: Stephen Rothwell
---
mm/secretmem.c | 4
1 file changed, 4 insertions(+)
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 5ed6b2070136..c7a37b2d01ed 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -59,6 +59,7 @@ bool secretmem_active(void)
static int secretmem_memcg_charge(struct page *page, gfp_t gfp, int order)
{
+#ifdef CONFIG_MEMCG
unsigned long nr_pages = (1 << order);
int i, err;
@@ -72,11 +73,13 @@ static int secretmem_memcg_charge(struct page *page, gfp_t
gfp, int order)
p->memcg_data = page->memcg_data;
}
+#endif
return 0;
}
static void secretmem_memcg_uncharge(struct page *page, int order)
{
+#ifdef CONFIG_MEMCG
unsigned long nr_pages = (1 << order);
int i;
@@ -87,6 +90,7 @@ static void secretmem_memcg_uncharge(struct page *page, int
order)
}
memcg_kmem_uncharge_page(page, PMD_PAGE_ORDER);
+#endif
}
static int secretmem_pool_increase(struct secretmem_ctx *ctx, gfp_t gfp)
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpWly60721G2.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm tree
On Fri, Nov 13, 2020 at 05:14:52PM -0800, Andrew Morton wrote:
> On Fri, 13 Nov 2020 18:02:39 +1100 Stephen Rothwell
> wrote:
>
> > Hi all,
> >
> > After merging the akpm tree, today's linux-next build (i386 defconfig)
> > failed like this:
> >
> > mm/secretmem.c: In function 'secretmem_memcg_charge':
> > mm/secretmem.c:72:4: error: 'struct page' has no member named 'memcg_data'
> >72 | p->memcg_data = page->memcg_data;
> > |^~
> > mm/secretmem.c:72:23: error: 'struct page' has no member named 'memcg_data'
> >72 | p->memcg_data = page->memcg_data;
> > | ^~
> > mm/secretmem.c: In function 'secretmem_memcg_uncharge':
> > mm/secretmem.c:86:4: error: 'struct page' has no member named 'memcg_data'
> >86 | p->memcg_data = 0;
> > |^~
> >
> > ...
> >
> > --- a/mm/secretmem.c
> > +++ b/mm/secretmem.c
> > @@ -69,7 +69,9 @@ static int secretmem_memcg_charge(struct page *page,
> > gfp_t gfp, int order)
> > for (i = 1; i < nr_pages; i++) {
> > struct page *p = page + i;
> >
> > +#ifdef CONFIG_MEMCG
> > p->memcg_data = page->memcg_data;
> > +#endif
> > }
> >
> > return 0;
>
> Thanks, that'll work for now.
>
> I guess we're looking at adding a set_page_memcg() (I'd prefer
> page_memcg_set()).
>
> But probably these functions shouldn't be compiled at all if
> CONFIG_MEMCG=n.
My preference would be to put the entire function body in '#ifdef
CONFIG_MEMCG' here.
--
Sincerely yours,
Mike.
Re: linux-next: build failure after merge of the akpm tree
On Fri, 13 Nov 2020 18:02:39 +1100 Stephen Rothwell
wrote:
> Hi all,
>
> After merging the akpm tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> mm/secretmem.c: In function 'secretmem_memcg_charge':
> mm/secretmem.c:72:4: error: 'struct page' has no member named 'memcg_data'
>72 | p->memcg_data = page->memcg_data;
> |^~
> mm/secretmem.c:72:23: error: 'struct page' has no member named 'memcg_data'
>72 | p->memcg_data = page->memcg_data;
> | ^~
> mm/secretmem.c: In function 'secretmem_memcg_uncharge':
> mm/secretmem.c:86:4: error: 'struct page' has no member named 'memcg_data'
>86 | p->memcg_data = 0;
> |^~
>
> ...
>
> --- a/mm/secretmem.c
> +++ b/mm/secretmem.c
> @@ -69,7 +69,9 @@ static int secretmem_memcg_charge(struct page *page, gfp_t
> gfp, int order)
> for (i = 1; i < nr_pages; i++) {
> struct page *p = page + i;
>
> +#ifdef CONFIG_MEMCG
> p->memcg_data = page->memcg_data;
> +#endif
> }
>
> return 0;
Thanks, that'll work for now.
I guess we're looking at adding a set_page_memcg() (I'd prefer
page_memcg_set()).
But probably these functions shouldn't be compiled at all if
CONFIG_MEMCG=n.
Re: linux-next: build failure after merge of the akpm tree
Thanks, the fix looks correct.
Re: linux-next: build failure after merge of the akpm tree
Hi all,
On Thu, 4 Jun 2020 16:44:42 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the akpm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> arch/powerpc/mm/ptdump/ptdump.c: In function 'walk_pagetables':
> arch/powerpc/mm/ptdump/ptdump.c:337:25: error: implicit declaration of
> function 'pgd_is_leaf'; did you mean 'p4d_is_leaf'?
> [-Werror=implicit-function-declaration]
> 337 | if (pgd_none(*pgd) || pgd_is_leaf(*pgd))
> | ^~~
> | p4d_is_leaf
>
> Caused by commit
>
>"powerpc: add support for folded p4d page tables"
>
> I applied the following fix up patch.
>
> From: Stephen Rothwell
> Date: Thu, 4 Jun 2020 16:33:01 +1000
> Subject: [PATCH] fixup for powerpc ptdump.c
>
> Signed-off-by: Stephen Rothwell
> ---
> arch/powerpc/mm/ptdump/ptdump.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
> index 9b1c89b05622..de6e05ef871c 100644
> --- a/arch/powerpc/mm/ptdump/ptdump.c
> +++ b/arch/powerpc/mm/ptdump/ptdump.c
> @@ -334,12 +334,12 @@ static void walk_pagetables(struct pg_state *st)
> for (i = pgd_index(addr); i < PTRS_PER_PGD; i++, pgd++, addr +=
> PGDIR_SIZE) {
> p4d_t *p4d = p4d_offset(pgd, 0);
>
> - if (pgd_none(*pgd) || pgd_is_leaf(*pgd))
> + if (p4d_none(*p4d) || p4d_is_leaf(*p4d))
> note_page(st, addr, 1, p4d_val(*p4d), PGDIR_SIZE);
> else if (is_hugepd(__hugepd(p4d_val(*p4d
> - walk_hugepd(st, (hugepd_t *)pgd, addr, PGDIR_SHIFT, 1);
> + walk_hugepd(st, (hugepd_t *)p4d, addr, PGDIR_SHIFT, 1);
> else
> - /* pgd exists */
> + /* p4d exists */
> walk_pud(st, p4d, addr);
> }
> }
>
I have put that in linux-next (for tomorrow) as a fix up for
powerpc-add-support-for-folded-p4d-page-tables.
--
Cheers,
Stephen Rothwell
pgpad3T77XNxx.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm tree
On Tue, 2 Jun 2020 19:57:41 +1000 Stephen Rothwell wrote: > Subject: [PATCH] turns out that probe_user_write is used in modular code > > Signed-off-by: Stephen Rothwell > --- > mm/maccess.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/maccess.c b/mm/maccess.c > index ddfda8e6f4a5..88845eda5047 100644 > --- a/mm/maccess.c > +++ b/mm/maccess.c > @@ -246,6 +246,7 @@ long probe_user_write(void __user *dst, const void *src, > size_t size) > return -EFAULT; > return 0; > } > +EXPORT_SYMBOL_GPL(probe_user_write); Thanks, I shall squish that in and make the appropriate changelog update.
Re: linux-next: build failure after merge of the akpm tree
This looks correct, thanks.
Re: linux-next: build failure after merge of the akpm tree
Hi John,
On Mon, 25 May 2020 11:18:46 -0700 John Hubbard wrote:
>
> Yes, looks good. And in fact, Andrew has the same fix-up in the mmotm branch
> of
> linux-next.git, as
>
> commit a76c281a8ddd
> ("mmap-locking-api-rename-mmap_sem-to-mmap_lock-fix").
For some reason that was not included in the section that gets applied
to linux-next :-(
I have added it to the akpm tree today.
--
Cheers,
Stephen Rothwell
pgp7Z4lJLgwRm.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm tree
On 2020-05-25 05:17, Stephen Rothwell wrote:
Hi all,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/kernel.h:14,
from mm/gup.c:2:
mm/gup.c: In function 'internal_get_user_pages_fast':
mm/gup.c:2732:33: error: 'struct mm_struct' has no member named 'mmap_sem'; did
you mean 'mmap_base'?
2732 | might_lock_read(¤t->mm->mmap_sem);
| ^~~~
Caused by commit
64fe66e8a95e ("mmap locking API: rename mmap_sem to mmap_lock")
fron the akpm tree interacting with commit
b1fc8b5ddb4e ("mm/gup: might_lock_read(mmap_sem) in get_user_pages_fast()")
from the akpm-current tree.
I added the following patch for today.
From: Stephen Rothwell
Date: Mon, 25 May 2020 22:11:51 +1000
Subject: [PATCH] mm/gup: update for mmap_sem rename
Signed-off-by: Stephen Rothwell
---
mm/gup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/gup.c b/mm/gup.c
index 8977e5fe9843..f4bca3de0b4b 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2729,7 +2729,7 @@ static int internal_get_user_pages_fast(unsigned long
start, int nr_pages,
return -EINVAL;
if (!(gup_flags & FOLL_FAST_ONLY))
- might_lock_read(¤t->mm->mmap_sem);
+ might_lock_read(¤t->mm->mmap_lock);
start = untagged_addr(start) & PAGE_MASK;
addr = start;
Yes, looks good. And in fact, Andrew has the same fix-up in the mmotm branch of
linux-next.git, as
commit a76c281a8ddd ("mmap-locking-api-rename-mmap_sem-to-mmap_lock-fix").
thanks,
--
John Hubbard
NVIDIA
Re: linux-next: build failure after merge of the akpm tree
On Tue, Feb 26, 2019 at 06:39:15PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> /home/sfr/next/next/arch/powerpc/kernel/setup_32.c:176:21: error:
> redefinition of 'alloc_stack'
> static void *__init alloc_stack(void)
> ^~~
> /home/sfr/next/next/arch/powerpc/kernel/setup_32.c:165:21: note: previous
> definition of 'alloc_stack' was here
> static void *__init alloc_stack(void)
> ^~~
>
> Caused by patch
>
> "powerpc: use memblock functions returning virtual address"
>
> from the akpm tree interacting with commit
>
> c8e409a33cf8 ("powerpc/irq: use memblock functions returning virtual
> address")
>
> from the powerpc tree.
>
> Both patches added the alloc_stack() function and git resolved it by
> adding both. :-( I have added a patch to remove one of them.
Yeah, me too :)
https://lore.kernel.org/linux-mm/20190226064032.GA5873@rapoport-lnx/
Stephen, sorry, should have cc'ed you
> --
> Cheers,
> Stephen Rothwell
--
Sincerely yours,
Mike.
Re: linux-next: build failure after merge of the akpm tree
Hi Anshuman,
On Wed, 12 Dec 2018 22:35:38 +0530 Anshuman Khandual
wrote:
>
> On 12/03/2018 12:30 PM, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > After merging the akpm tree, today's linux-next build (powerpc_le perf)
> > failed like this:
> >
> > bench/numa.c:37:10: fatal error: linux/numa.h: No such file or directory
> > #include
> > ^~
> >
> > Caused by patches
> >
> > "mm: replace all open encodings for NUMA_NO_NODE"
> > "mm-replace-all-open-encodings-for-numa_no_node-fix"
> >
> > For linux/numa.h to be generally availble to the tools builds, it must
> > be copied into tools/include/linux ...
> >
> > I have done that copy for today:
> >
> > From 6dabc11d5513510d0ec0a6b0a4aa8b9051b71516 Mon Sep 17 00:00:00 2001
> > From: Stephen Rothwell
> > Date: Mon, 3 Dec 2018 17:57:27 +1100
> > Subject: [PATCH] linux/numa.h is now needed for the perf build
> >
> > Signed-off-by: Stephen Rothwell
>
> Hello Stephen,
>
> I will respin the original patch
> (https://patchwork.kernel.org/patch/10698089/)
> once more to accommodate new feedbacks from Lubomir Rintel. This patch fixes
> the
> build problem related to tools/perf. As Lubomir suggested, it might be better
> to
> split the tools/perf changes ("tools: Replace open encodings for
> NUMA_NO_NODE")
> from the original patch and then fold this fix onto it with both
> signed-off-by.
> Does it sound good. Are you okay with it ?
Sounds fine to me.
--
Cheers,
Stephen Rothwell
pgpgBF03O_AOy.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm tree
On 12/03/2018 12:30 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc_le perf)
> failed like this:
>
> bench/numa.c:37:10: fatal error: linux/numa.h: No such file or directory
> #include
> ^~
>
> Caused by patches
>
> "mm: replace all open encodings for NUMA_NO_NODE"
> "mm-replace-all-open-encodings-for-numa_no_node-fix"
>
> For linux/numa.h to be generally availble to the tools builds, it must
> be copied into tools/include/linux ...
>
> I have done that copy for today:
>
> From 6dabc11d5513510d0ec0a6b0a4aa8b9051b71516 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell
> Date: Mon, 3 Dec 2018 17:57:27 +1100
> Subject: [PATCH] linux/numa.h is now needed for the perf build
>
> Signed-off-by: Stephen Rothwell
Hello Stephen,
I will respin the original patch (https://patchwork.kernel.org/patch/10698089/)
once more to accommodate new feedbacks from Lubomir Rintel. This patch fixes the
build problem related to tools/perf. As Lubomir suggested, it might be better to
split the tools/perf changes ("tools: Replace open encodings for NUMA_NO_NODE")
from the original patch and then fold this fix onto it with both signed-off-by.
Does it sound good. Are you okay with it ?
- Anshuman
Re: linux-next: build failure after merge of the akpm tree
On 12/03/2018 12:30 PM, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm tree, today's linux-next build (powerpc_le perf) > failed like this: > > bench/numa.c:37:10: fatal error: linux/numa.h: No such file or directory > #include > ^~ > > Caused by patches > > "mm: replace all open encodings for NUMA_NO_NODE" > "mm-replace-all-open-encodings-for-numa_no_node-fix" > > For linux/numa.h to be generally availble to the tools builds, it must > be copied into tools/include/linux ... > > I have done that copy for today: > > From 6dabc11d5513510d0ec0a6b0a4aa8b9051b71516 Mon Sep 17 00:00:00 2001 > From: Stephen Rothwell > Date: Mon, 3 Dec 2018 17:57:27 +1100 > Subject: [PATCH] linux/numa.h is now needed for the perf build > > Signed-off-by: Stephen Rothwell Makes sense. Thanks Stephen for taking care of this build failure more than once. Reviewed-by: Anshuman Khandual
Re: linux-next: build failure after merge of the akpm tree
On 11/30/2018 11:00 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc_le perf)
> failed like this:
>
> bench/numa.c: In function 'bind_to_node':
> bench/numa.c:301:21: error: 'NUMA_NO_NODE' undeclared (first use in this
> function); did you mean 'NUMA_NUM_NODES'?
> if (target_node == NUMA_NO_NODE) {
> ^~~~
> NUMA_NUM_NODES
> bench/numa.c:301:21: note: each undeclared identifier is reported only once
> for each function it appears in
> bench/numa.c: In function 'bind_to_memnode':
> bench/numa.c:342:14: error: 'NUMA_NO_NODE' undeclared (first use in this
> function); did you mean 'NUMA_NUM_NODES'?
> if (node == NUMA_NO_NODE)
> ^~~~
> NUMA_NUM_NODES
> bench/numa.c: In function 'init_thread_data':
> bench/numa.c:1366:19: error: 'NUMA_NO_NODE' undeclared (first use in this
> function); did you mean 'NUMA_NUM_NODES'?
>td->bind_node = NUMA_NO_NODE;
>^~~~
>NUMA_NUM_NODES
>
> Caused by patch
>
> "mm: replace all open encodings for NUMA_NO_NODE"
>
> I applied the following partial revert for today:
I had skipped this particular file because it includes 'numa.h'. But that does
not
seem to pull in though. Could we please add
instead
of reverting the actual changes from the patch. I can send out another version
of
the patch if required.
- Anshuman
Re: linux-next: build failure after merge of the akpm tree
* Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 8 Oct 2018 19:03:41 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the akpm tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > arch/x86/mm/kaslr.c:26:10: fatal error: linux/bootmem.h: No such file or
> > directory
> > #include
> > ^
> >
> > Caused by patch
> >
> > "mm: remove include/linux/bootmem.h"
> >
> > interacting with commit
> >
> > 3a387c6d96e6 ("x86/kaslr, ACPI/NUMA: Fix KASLR build error")
> >
> > from the tip tree.
> >
> > I have added the following patch for today:
> >
> > From: Stephen Rothwell
> > Date: Mon, 8 Oct 2018 18:57:00 +1100
> > Subject: [PATCH] x86/kaslr, ACPI/NUMA: fix for linux/bootmem.h removal
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > arch/x86/mm/kaslr.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> > index b3471388288d..ad80bdc690c1 100644
> > --- a/arch/x86/mm/kaslr.c
> > +++ b/arch/x86/mm/kaslr.c
> > @@ -23,7 +23,7 @@
> > #include
> > #include
> > #include
> > -#include
> > +#include
> >
> > #include
> > #include
> > --
>
> So the above tip tree patch no longer exists, so this one is also no
> longer needed and I have removed it from the akpm tree today.
Yeah, we are reworking this series in WIP.x86/boot, it probably won't
make v4.20 so I removed it from -next.
Thanks,
Ingo
Re: linux-next: build failure after merge of the akpm tree
Hi all,
On Mon, 8 Oct 2018 19:03:41 +1100 Stephen Rothwell
wrote:
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> arch/x86/mm/kaslr.c:26:10: fatal error: linux/bootmem.h: No such file or
> directory
> #include
> ^
>
> Caused by patch
>
> "mm: remove include/linux/bootmem.h"
>
> interacting with commit
>
> 3a387c6d96e6 ("x86/kaslr, ACPI/NUMA: Fix KASLR build error")
>
> from the tip tree.
>
> I have added the following patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 8 Oct 2018 18:57:00 +1100
> Subject: [PATCH] x86/kaslr, ACPI/NUMA: fix for linux/bootmem.h removal
>
> Signed-off-by: Stephen Rothwell
> ---
> arch/x86/mm/kaslr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index b3471388288d..ad80bdc690c1 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -23,7 +23,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #include
> #include
> --
So the above tip tree patch no longer exists, so this one is also no
longer needed and I have removed it from the akpm tree today.
--
Cheers,
Stephen Rothwell
pgpIczDCutsbU.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm tree
Hi Greg, On Wed, 21 Mar 2018 11:02:08 +0100 Greg Kroah-Hartman wrote: > > Patch is now queued up, thanks. Excellent. -- Cheers, Stephen Rothwell pgpMuNJUwYuTO.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm tree
On Wed, Mar 21, 2018 at 07:17:27PM +1100, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > drivers/base/firmware_loader/fallback.c: In function 'map_fw_priv_pages': > drivers/base/firmware_loader/fallback.c:232:2: error: implicit declaration of > function 'vunmap'; did you mean 'kunmap'? > [-Werror=implicit-function-declaration] > vunmap(fw_priv->data); > ^~ > kunmap > drivers/base/firmware_loader/fallback.c:233:18: error: implicit declaration > of function 'vmap'; did you mean 'kmap'? > [-Werror=implicit-function-declaration] > fw_priv->data = vmap(fw_priv->pages, fw_priv->nr_pages, 0, > ^~~~ > kmap > drivers/base/firmware_loader/fallback.c:233:16: warning: assignment makes > pointer from integer without a cast [-Wint-conversion] > fw_priv->data = vmap(fw_priv->pages, fw_priv->nr_pages, 0, > ^ > drivers/base/firmware_loader/fallback.c: In function 'firmware_loading_store': > drivers/base/firmware_loader/fallback.c:274:4: error: implicit declaration of > function 'vfree'; did you mean 'kvfree'? > [-Werror=implicit-function-declaration] > vfree(fw_priv->pages); > ^ > kvfree > drivers/base/firmware_loader/fallback.c: In function 'fw_realloc_pages': > drivers/base/firmware_loader/fallback.c:405:15: error: implicit declaration > of function 'vmalloc'; did you mean 'kvmalloc'? > [-Werror=implicit-function-declaration] >new_pages = vmalloc(new_array_size * sizeof(void *)); >^~~ >kvmalloc > drivers/base/firmware_loader/fallback.c:405:13: warning: assignment makes > pointer from integer without a cast [-Wint-conversion] >new_pages = vmalloc(new_array_size * sizeof(void *)); > ^ > > Maybe caused by patch > > "headers: untangle kmemleak.h from mm.h" > > Anyway this file should explicitly include linux/vmalloc.h since it uses > stuff in there, so I have added the following patch for today (I think > this could just be applied to the driver-core tree ...): Patch is now queued up, thanks. greg k-h
Re: linux-next: build failure after merge of the akpm tree
On Tue, Aug 1, 2017 at 8:40 PM, Kees Cook wrote: >> >> I don't know why this has turned up now. I have just left it broken >> for now and would appreciate any fix. > > Thanks for the heads-up! I'm not sure why this suddenly appeared > either, but Arnd has sent a patch for this now. The main difference I see that can impact gcc's optimization steps is the unreachable() that was there in BUG() but is absent in WARN(). It's possible that the compiler decided that the entire code path leading up to the unreachable() couldn't happen, so it dropped the __read_overflow2() call as well. Arnd
Re: linux-next: build failure after merge of the akpm tree
On Mon, Jul 31, 2017 at 11:25 PM, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > In file included from arch/powerpc/include/asm/paca.h:19:0, > from arch/powerpc/include/asm/hw_irq.h:42, > from arch/powerpc/include/asm/irqflags.h:11, > from include/linux/irqflags.h:15, > from include/linux/spinlock.h:53, > from include/linux/wait.h:8, > from include/linux/wait_bit.h:7, > from include/linux/fs.h:5, > from include/linux/buffer_head.h:11, > from fs/adfs/dir_f.c:12: > In function 'memcpy', > inlined from '__adfs_dir_put' at fs/adfs/dir_f.c:318:2, > inlined from 'adfs_f_update' at fs/adfs/dir_f.c:403:2: > include/linux/string.h:305:4: error: call to '__read_overflow2' declared with > attribute error: detected read beyond size of object passed as 2nd parameter > __read_overflow2(); > ^ > > I don't know why this has turned up now. I have just left it broken > for now and would appreciate any fix. Thanks for the heads-up! I'm not sure why this suddenly appeared either, but Arnd has sent a patch for this now. -Kees -- Kees Cook Pixel Security
Re: linux-next: build failure after merge of the akpm tree
From: Stephen Rothwell Date: Fri, 30 Jun 2017 16:32:41 +1000 > From: Stephen Rothwell > Date: Fri, 30 Jun 2017 16:24:35 +1000 > Subject: [PATCH] net/mlx5: fix memcpy limit? > > Signed-off-by: Stephen Rothwell Applied, thanks.
Re: linux-next: build failure after merge of the akpm tree
Hi all,
On Fri, 30 Jun 2017 16:32:41 +1000 Stephen Rothwell
wrote:
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/bitmap.h:8:0,
> from include/linux/cpumask.h:11,
> from include/linux/mm_types_task.h:13,
> from include/linux/mm_types.h:4,
> from include/linux/kmemcheck.h:4,
> from include/linux/skbuff.h:18,
> from include/linux/if_ether.h:23,
> from include/linux/etherdevice.h:25,
> from drivers/net/ethernet/mellanox/mlx5/core/fpga/cmd.c:33:
> In function 'memcpy',
> inlined from 'mlx5_fpga_query_qp' at
> drivers/net/ethernet/mellanox/mlx5/core/fpga/cmd.c:194:2:
> include/linux/string.h:315:4: error: call to '__read_overflow2' declared with
> attribute error: detected read beyond size of object passed as 2nd parameter
> __read_overflow2();
> ^
>
> Caused by commit
>
> c151149cc4db ("include/linux/string.h: add the option of fortified string.h
> functions")
>
> interacting with commit
>
> 6062118d5cd2 ("net/mlx5: FPGA, Add FW commands for FPGA QPs")
>
> from the net-next tree.
>
> I took a guess and tried the following patch which seemed to work.
>
> From: Stephen Rothwell
> Date: Fri, 30 Jun 2017 16:24:35 +1000
> Subject: [PATCH] net/mlx5: fix memcpy limit?
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/ethernet/mellanox/mlx5/core/fpga/cmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fpga/cmd.c
> b/drivers/net/ethernet/mellanox/mlx5/core/fpga/cmd.c
> index 5cb855fd618f..e37453d838db 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fpga/cmd.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fpga/cmd.c
> @@ -191,7 +191,7 @@ int mlx5_fpga_query_qp(struct mlx5_core_dev *dev,
> if (ret)
> return ret;
>
> - memcpy(fpga_qpc, MLX5_ADDR_OF(fpga_query_qp_out, in, fpga_qpc),
> + memcpy(fpga_qpc, MLX5_ADDR_OF(fpga_query_qp_out, out, fpga_qpc),
> MLX5_FLD_SZ_BYTES(fpga_query_qp_out, fpga_qpc));
> return ret;
> }
> --
> 2.11.0
Again today ... so is the fix correct? if so, Dave should apply it, if
not someone should supply a correct fix for Dave.
--
Cheers,
Stephen Rothwell
Re: linux-next: build failure after merge of the akpm tree
Hi Michal,
On Mon, 26 Jun 2017 09:13:46 +0200 Michal Hocko wrote:
>
> On Mon 26-06-17 16:53:43, Stephen Rothwell wrote:
> >
> > After merging the akpm tree, today's linux-next build (sparc64 defconfig)
> > failed like this:
> >
> > arch/sparc/kernel/mdesc.c: In function 'mdesc_kmalloc':
> > arch/sparc/kernel/mdesc.c:208:48: error: '__GFP_REPEAT' undeclared (first
> > use in this function)
> > base = kmalloc(handle_size + 15, GFP_KERNEL | __GFP_REPEAT);
> > ^
> >
> > Caused by commit
> >
> > 726ad49b664b ("mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL
> > with more useful semantic")
> >
> > interacting with commit
> >
> > 0ab2fcd69dbf ("sparc64: mdesc: use __GFP_REPEAT action modifier for VM
> > allocation")
> >
> > from the sparc-next tree.
> >
> > For now I have applied the following (I expect it to be replaced with
> > something better):
>
> You simply want s@__GFP_REPEAT@__GFP_RETRY_MAYFAIL@
OK, I have replaced the patch with this:
From: Stephen Rothwell
Date: Mon, 26 Jun 2017 16:47:46 +1000
Subject: [PATCH] paper over the removal of __GFP_REPEAT for now
Signed-off-by: Stephen Rothwell
---
arch/sparc/kernel/mdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c
index e4b4e790bf89..c9ecd5abf5bf 100644
--- a/arch/sparc/kernel/mdesc.c
+++ b/arch/sparc/kernel/mdesc.c
@@ -205,7 +205,7 @@ static struct mdesc_handle *mdesc_kmalloc(unsigned int
mdesc_size)
handle_size = (sizeof(struct mdesc_handle) -
sizeof(struct mdesc_hdr) +
mdesc_size);
- base = kmalloc(handle_size + 15, GFP_KERNEL | __GFP_REPEAT);
+ base = kmalloc(handle_size + 15, GFP_KERNEL | __GFP_RETRY_MAYFAIL);
if (!base)
return NULL;
--
2.11.0
--
Cheers,
Stephen Rothwell
Re: linux-next: build failure after merge of the akpm tree
On Mon 26-06-17 16:53:43, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> arch/sparc/kernel/mdesc.c: In function 'mdesc_kmalloc':
> arch/sparc/kernel/mdesc.c:208:48: error: '__GFP_REPEAT' undeclared (first use
> in this function)
> base = kmalloc(handle_size + 15, GFP_KERNEL | __GFP_REPEAT);
> ^
>
> Caused by commit
>
> 726ad49b664b ("mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL
> with more useful semantic")
>
> interacting with commit
>
> 0ab2fcd69dbf ("sparc64: mdesc: use __GFP_REPEAT action modifier for VM
> allocation")
>
> from the sparc-next tree.
>
> For now I have applied the following (I expect it to be replaced with
> something better):
You simply want s@__GFP_REPEAT@__GFP_RETRY_MAYFAIL@
>
> From: Stephen Rothwell
> Date: Mon, 26 Jun 2017 16:47:46 +1000
> Subject: [PATCH] paper over the removal of __GFP_REPEAT for now
>
> Signed-off-by: Stephen Rothwell
> ---
> arch/sparc/kernel/mdesc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c
> index e4b4e790bf89..c9ecd5abf5bf 100644
> --- a/arch/sparc/kernel/mdesc.c
> +++ b/arch/sparc/kernel/mdesc.c
> @@ -205,7 +205,7 @@ static struct mdesc_handle *mdesc_kmalloc(unsigned int
> mdesc_size)
> handle_size = (sizeof(struct mdesc_handle) -
> sizeof(struct mdesc_hdr) +
> mdesc_size);
> - base = kmalloc(handle_size + 15, GFP_KERNEL | __GFP_REPEAT);
> + base = kmalloc(handle_size + 15, GFP_KERNEL /* | __GFP_REPEAT */);
> if (!base)
> return NULL;
>
> --
> 2.11.0
>
> --
> Cheers,
> Stephen Rothwell
--
Michal Hocko
SUSE Labs
Re: linux-next: build failure after merge of the akpm tree
On Mon 20-03-17 16:37:35, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/f2fs/node.c: In function 'init_free_nid_cache':
> fs/f2fs/node.c:2634:25: error: implicit declaration of function
> 'f2fs_kvzalloc' [-Werror=implicit-function-declaration]
> nm_i->free_nid_count = f2fs_kvzalloc(nm_i->nat_blocks *
> ^
> fs/f2fs/node.c:2634:23: warning: assignment makes pointer from integer
> without a cast [-Wint-conversion]
> nm_i->free_nid_count = f2fs_kvzalloc(nm_i->nat_blocks *
>^
>
> Caused by commit
>
> 69e5e80117a3 ("mm: introduce kv[mz]alloc helpers")
>
> interacting with commit
>
> c48b15867a2f ("f2fs: skip scanning free nid bitmap of full NAT blocks")
>
> from the f2fs tree.
>
> I applied the following fix patch:
yes this is correct. Thanks!
>
> From: Stephen Rothwell
> Date: Mon, 20 Mar 2017 16:28:21 +1100
> Subject: [PATCH] mm: introduce kv[mz]alloc helpers - f2fs fix up
>
> Signed-off-by: Stephen Rothwell
> ---
> fs/f2fs/node.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index cdbb05745895..0ea1dca8a0e2 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -2631,7 +2631,7 @@ static int init_free_nid_cache(struct f2fs_sb_info *sbi)
> if (!nm_i->nat_block_bitmap)
> return -ENOMEM;
>
> - nm_i->free_nid_count = f2fs_kvzalloc(nm_i->nat_blocks *
> + nm_i->free_nid_count = kvzalloc(nm_i->nat_blocks *
> sizeof(unsigned short), GFP_KERNEL);
> if (!nm_i->free_nid_count)
> return -ENOMEM;
> --
> 2.11.0
>
> --
> Cheers,
> Stephen Rothwell
--
Michal Hocko
SUSE Labs
Re: linux-next: build failure after merge of the akpm tree
On 03/20, Michal Hocko wrote:
> On Mon 20-03-17 16:37:35, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > After merging the akpm tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > fs/f2fs/node.c: In function 'init_free_nid_cache':
> > fs/f2fs/node.c:2634:25: error: implicit declaration of function
> > 'f2fs_kvzalloc' [-Werror=implicit-function-declaration]
> > nm_i->free_nid_count = f2fs_kvzalloc(nm_i->nat_blocks *
> > ^
> > fs/f2fs/node.c:2634:23: warning: assignment makes pointer from integer
> > without a cast [-Wint-conversion]
> > nm_i->free_nid_count = f2fs_kvzalloc(nm_i->nat_blocks *
> >^
> >
> > Caused by commit
> >
> > 69e5e80117a3 ("mm: introduce kv[mz]alloc helpers")
> >
> > interacting with commit
> >
> > c48b15867a2f ("f2fs: skip scanning free nid bitmap of full NAT blocks")
> >
> > from the f2fs tree.
> >
> > I applied the following fix patch:
>
> yes this is correct. Thanks!
Thank you for checking this out.
Thanks,
>
> >
> > From: Stephen Rothwell
> > Date: Mon, 20 Mar 2017 16:28:21 +1100
> > Subject: [PATCH] mm: introduce kv[mz]alloc helpers - f2fs fix up
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > fs/f2fs/node.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index cdbb05745895..0ea1dca8a0e2 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -2631,7 +2631,7 @@ static int init_free_nid_cache(struct f2fs_sb_info
> > *sbi)
> > if (!nm_i->nat_block_bitmap)
> > return -ENOMEM;
> >
> > - nm_i->free_nid_count = f2fs_kvzalloc(nm_i->nat_blocks *
> > + nm_i->free_nid_count = kvzalloc(nm_i->nat_blocks *
> > sizeof(unsigned short), GFP_KERNEL);
> > if (!nm_i->free_nid_count)
> > return -ENOMEM;
> > --
> > 2.11.0
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
> --
> Michal Hocko
> SUSE Labs
Re: linux-next: build failure after merge of the akpm tree
On 03/06/2017 07:07 PM, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from include/net/sock.h:64:0, > from include/linux/tcp.h:23, > from include/linux/ipv6.h:83, > from include/net/ipv6.h:16, > from include/linux/sunrpc/clnt.h:27, > from include/linux/nfs_fs.h:30, > from init/do_mounts.c:32: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from arch/powerpc/net/bpf_jit_comp64.c:17:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/net/sock.h:64:0, > from ipc/mqueue.c:42: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > kernel/module.c:52:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/net/sock.h:64:0, > from include/linux/tcp.h:23, > from include/linux/ipv6.h:83, > from include/net/ipv6.h:16, > from include/linux/sunrpc/clnt.h:27, > from include/linux/nfs_fs.h:30, > from kernel/sysctl.c:54: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/extable.c:25:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/net/sock.h:64:0, > from kernel/cgroup/cgroup.c:57: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/bpf/inode.c:22:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/kallsyms.c:26:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/events/core.c:46:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/bpf/core.c:24:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/bpf/hashtab.c:15:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/linux/bpf_verifier.h:11:0, > from kernel/bpf/verifier.c:17: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/bpf/stackmap.c:9:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/seccomp.c:31:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/trace/events/bpf.h:7:0, > from include/linux/bpf_trace.h:4, > from kernel/bpf/syscall.c:13: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/net/sock.h:64:0, > from include/net/inet_sock.h:27, > from include/net/ip.h:30, > from include/net/busy_poll.h:30, > from fs/select.c:31: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/bpf/helpers.c:20:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/net/sock.h:64:0, > from kernel/bpf/cgroup.c:17: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/net/sock.h:64:0, > from include/linux/tcp.h:23, > from include/linux/ipv6.h:83, > from include/net/ipv6.h:16, > from kernel/bpf/lpm_trie.c:17: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/bpf/arraymap.c:16:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from kernel/trace/bpf_trace.c:13:0: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/net/sock.h:64:0, > from include/linux/if_pppox.h:46, > from fs/compat_ioctl.c:38: > include/linux/filter.h:21:28: fatal error: asm/set_memory.h: No such file or > directory > In file included from include/net/sock.h:64:0, > from include/linux/tcp.h:23, > from include/linux/ipv6.h:83, > from include/net/ipv6.h:16, > from fs/cifs/cifsfs.c:4
Re: linux-next: build failure after merge of the akpm tree
On Tue, 26 Jan 2016 21:51:30 +0100,
Stephen Rothwell wrote:
>
> Hi Takashi,
>
> On Mon, 25 Jan 2016 14:45:55 +0100 Takashi Iwai wrote:
> >
> > From: Takashi Iwai
> > Subject: [PATCH v2] ALSA: compress: Disable GET_CODEC_CAPS ioctl for some
> > architectures
> >
> > Some architectures like PowerPC can handle the maximum struct size in
> > an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by
> > SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This
> > problem was revealed recently by a powerpc change, as it's now treated
> > as a fatal build error.
> >
> > This patch is a workaround for that: for architectures with less than
> > 14 bit ioctl struct size, get rid of the handling of the relevant
> > ioctl. We should provide an alternative equivalent ioctl code later,
> > but for now just paper over it. Luckily, the compress API hasn't been
> > used on such architectures, so the impact must be effectively zero.
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > sound/core/compress_offload.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
> > index 18b8dc45bb8f..0609e618107a 100644
> > --- a/sound/core/compress_offload.c
> > +++ b/sound/core/compress_offload.c
> > @@ -46,6 +46,13 @@
> > #include
> > #include
> >
> > +/* FIXME: struct snd_compr_codec_caps overflows the ioctl bit size for some
> > + *architectures, so we need to disable the relevant ioctls.
> > + */
> > +#if _IOC_SIZEBITS < 14
> > +#define COMPR_CODEC_CAPS_OVERFLOW
> > +#endif
> > +
> > /* TODO:
> > * - add substream support for multiple devices in case of
> > * SND_DYNAMIC_MINORS is not used
> > @@ -440,6 +447,7 @@ out:
> > return retval;
> > }
> >
> > +#ifndef COMPR_CODEC_CAPS_OVERFLOW
> > static int
> > snd_compr_get_codec_caps(struct snd_compr_stream *stream, unsigned long
> > arg)
> > {
> > @@ -463,6 +471,7 @@ out:
> > kfree(caps);
> > return retval;
> > }
> > +#endif /* !COMPR_CODEC_CAPS_OVERFLOW */
> >
> > /* revisit this with snd_pcm_preallocate_xxx */
> > static int snd_compr_allocate_buffer(struct snd_compr_stream *stream,
> > @@ -801,9 +810,11 @@ static long snd_compr_ioctl(struct file *f, unsigned
> > int cmd, unsigned long arg)
> > case _IOC_NR(SNDRV_COMPRESS_GET_CAPS):
> > retval = snd_compr_get_caps(stream, arg);
> > break;
> > +#ifndef COMPR_CODEC_CAPS_OVERFLOW
> > case _IOC_NR(SNDRV_COMPRESS_GET_CODEC_CAPS):
> > retval = snd_compr_get_codec_caps(stream, arg);
> > break;
> > +#endif
> > case _IOC_NR(SNDRV_COMPRESS_SET_PARAMS):
> > retval = snd_compr_set_params(stream, arg);
> > break;
> > --
> > 2.7.0
>
> I have replaced my other patch in my fixes tree until someone gets this
> patch to Linus.
I've merged this to for-linus branch, so it'll be included in the next
pull request.
thanks,
Takashi
Re: linux-next: build failure after merge of the akpm tree
Hi Takashi,
On Mon, 25 Jan 2016 14:45:55 +0100 Takashi Iwai wrote:
>
> From: Takashi Iwai
> Subject: [PATCH v2] ALSA: compress: Disable GET_CODEC_CAPS ioctl for some
> architectures
>
> Some architectures like PowerPC can handle the maximum struct size in
> an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by
> SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This
> problem was revealed recently by a powerpc change, as it's now treated
> as a fatal build error.
>
> This patch is a workaround for that: for architectures with less than
> 14 bit ioctl struct size, get rid of the handling of the relevant
> ioctl. We should provide an alternative equivalent ioctl code later,
> but for now just paper over it. Luckily, the compress API hasn't been
> used on such architectures, so the impact must be effectively zero.
>
> Signed-off-by: Takashi Iwai
> ---
> sound/core/compress_offload.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
> index 18b8dc45bb8f..0609e618107a 100644
> --- a/sound/core/compress_offload.c
> +++ b/sound/core/compress_offload.c
> @@ -46,6 +46,13 @@
> #include
> #include
>
> +/* FIXME: struct snd_compr_codec_caps overflows the ioctl bit size for some
> + *architectures, so we need to disable the relevant ioctls.
> + */
> +#if _IOC_SIZEBITS < 14
> +#define COMPR_CODEC_CAPS_OVERFLOW
> +#endif
> +
> /* TODO:
> * - add substream support for multiple devices in case of
> * SND_DYNAMIC_MINORS is not used
> @@ -440,6 +447,7 @@ out:
> return retval;
> }
>
> +#ifndef COMPR_CODEC_CAPS_OVERFLOW
> static int
> snd_compr_get_codec_caps(struct snd_compr_stream *stream, unsigned long arg)
> {
> @@ -463,6 +471,7 @@ out:
> kfree(caps);
> return retval;
> }
> +#endif /* !COMPR_CODEC_CAPS_OVERFLOW */
>
> /* revisit this with snd_pcm_preallocate_xxx */
> static int snd_compr_allocate_buffer(struct snd_compr_stream *stream,
> @@ -801,9 +810,11 @@ static long snd_compr_ioctl(struct file *f, unsigned int
> cmd, unsigned long arg)
> case _IOC_NR(SNDRV_COMPRESS_GET_CAPS):
> retval = snd_compr_get_caps(stream, arg);
> break;
> +#ifndef COMPR_CODEC_CAPS_OVERFLOW
> case _IOC_NR(SNDRV_COMPRESS_GET_CODEC_CAPS):
> retval = snd_compr_get_codec_caps(stream, arg);
> break;
> +#endif
> case _IOC_NR(SNDRV_COMPRESS_SET_PARAMS):
> retval = snd_compr_set_params(stream, arg);
> break;
> --
> 2.7.0
I have replaced my other patch in my fixes tree until someone gets this
patch to Linus.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
Re: linux-next: build failure after merge of the akpm tree
On Mon, Jan 25, 2016 at 01:55:46PM +, Mark Brown wrote: > > though we will need to come up with an alternative solution for the > affected architectures if anyone ends up caring (MIPS or PowerPC might > possibly). Okay I did some rethink on this. So we should be able to make MAX_NUM_CODEC_DESCRIPTORS to 16. But that will be ABI change :( Also further down the road if people start hitting this limit add additional ioctl to get more descriptors, but for Intel devices this is okay, WM doesn't seem to implement this.. Thanks -- ~Vinod signature.asc Description: Digital signature
Re: linux-next: build failure after merge of the akpm tree
On Mon, Jan 25, 2016 at 02:45:55PM +0100, Takashi Iwai wrote: > Below is the revised one. Acked-by: Vinod Koul Thanks for fixing this up... -- ~Vinod
Re: linux-next: build failure after merge of the akpm tree
On Mon, Jan 25, 2016 at 02:45:55PM +0100, Takashi Iwai wrote: > On Mon, 25 Jan 2016 14:10:37 +0100, > Takashi Iwai wrote: > > > > On Mon, 25 Jan 2016 12:41:50 +0100, > > Mark Brown wrote: > > > > > > > Signed-off-by: Takashi Iwai > > --- > > sound/core/compress_offload.c | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c > > index 18b8dc45bb8f..36b0083fd9f4 100644 > > --- a/sound/core/compress_offload.c > > +++ b/sound/core/compress_offload.c > > @@ -46,6 +46,13 @@ > > #include > > #include > > > > +/* FIXME: struct snd_compr_codec_caps overflows the ioctl bit size for some > > + *architectures, so we need to disable the relevant ioctls. > > + */ > > +#if _IOC_SIZEBITS < 13 > > Argh, a typo here. I forgot to refresh the patch, sorry. > > Below is the revised one. powerpc allmodconfig builds properly now. Acked-by: Sudip Mukherjee regards sudip
Re: linux-next: build failure after merge of the akpm tree
On Mon, Jan 25, 2016 at 02:45:55PM +0100, Takashi Iwai wrote: > Argh, a typo here. I forgot to refresh the patch, sorry. > Below is the revised one. This makes sense to me. Reviwed-by: Mark Brown though we will need to come up with an alternative solution for the affected architectures if anyone ends up caring (MIPS or PowerPC might possibly). signature.asc Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
On Mon, 25 Jan 2016 14:10:37 +0100, Takashi Iwai wrote: > > On Mon, 25 Jan 2016 12:41:50 +0100, > Mark Brown wrote: > > > > On Mon, Jan 25, 2016 at 10:29:54AM +0100, Takashi Iwai wrote: > > > Stephen Rothwell wrote: > > > > > > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig > > > > index 50693c867e71..ee5f36b9c787 100644 > > > > --- a/sound/soc/codecs/Kconfig > > > > +++ b/sound/soc/codecs/Kconfig > > > > @@ -13,6 +13,7 @@ menu "CODEC drivers" > > > > config SND_SOC_ALL_CODECS > > > > tristate "Build all ASoC CODEC drivers" > > > > depends on COMPILE_TEST > > > > + depends on !PPC > > > > select SND_SOC_88PM860X if MFD_88PM860X > > > > select SND_SOC_L3 > > > > select SND_SOC_AB8500_CODEC if ABX500_CORE > > > > > Suppressing this whole is an overreaction, IMO. It should suffice > > > just to disable compile-testing Intel driver. > > > > Please send patches and reports to maintainers :( I agree that this is > > an absurdly wide change. > > > > > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig > > > index 803f95e40679..d854cd66e090 100644 > > > --- a/sound/soc/intel/Kconfig > > > +++ b/sound/soc/intel/Kconfig > > > @@ -31,6 +31,8 @@ config SND_SOC_INTEL_SST > > > tristate > > > select SND_SOC_INTEL_SST_ACPI if ACPI > > > depends on (X86 || COMPILE_TEST) > > > + # FIXME: a part of compress API is broken for PPC > > > + depends on !PPC > > > > Why is an Intel CPU thing being enabled by SND_SOC_ALL_CODECS? I'm also > > unclear why this will help when we're selecting in the drivers so their > > dependencies will be ignored. > > Yeah, obviously papering over a wrong place. > > In anyway, thinking of this workaround again, I don't think it being > the best way. The easier and safer workaround is to just avoid the > corresponding ioctl being handled. The untested patch is attached > below. > > > thanks, > > Takashi > > -- 8< -- > From: Takashi Iwai > Subject: [PATCH] ALSA: compress: Disable GET_CODEC_CAPS ioctl for some > architectures > > Some architectures like PowerPC can handle the maximum struct size in > an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by > SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This > problem was revealed recently by a powerpc change, as it's now treated > as a fatal build error. > > This patch is a workaround for that: for architectures with less than > 14 bit ioctl struct size, get rid of the handling of the relevant > ioctl. We should provide an alternative equivalent ioctl code later, > but for now just paper over it. Luckily, the compress API hasn't been > used on such architectures, so the impact must be effectively zero. > > Signed-off-by: Takashi Iwai > --- > sound/core/compress_offload.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c > index 18b8dc45bb8f..36b0083fd9f4 100644 > --- a/sound/core/compress_offload.c > +++ b/sound/core/compress_offload.c > @@ -46,6 +46,13 @@ > #include > #include > > +/* FIXME: struct snd_compr_codec_caps overflows the ioctl bit size for some > + *architectures, so we need to disable the relevant ioctls. > + */ > +#if _IOC_SIZEBITS < 13 Argh, a typo here. I forgot to refresh the patch, sorry. Below is the revised one. Takashi -- 8< -- From: Takashi Iwai Subject: [PATCH v2] ALSA: compress: Disable GET_CODEC_CAPS ioctl for some architectures Some architectures like PowerPC can handle the maximum struct size in an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This problem was revealed recently by a powerpc change, as it's now treated as a fatal build error. This patch is a workaround for that: for architectures with less than 14 bit ioctl struct size, get rid of the handling of the relevant ioctl. We should provide an alternative equivalent ioctl code later, but for now just paper over it. Luckily, the compress API hasn't been used on such architectures, so the impact must be effectively zero. Signed-off-by: Takashi Iwai --- sound/core/compress_offload.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index 18b8dc45bb8f..0609e618107a 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -46,6 +46,13 @@ #include #include +/* FIXME: struct snd_compr_codec_caps overflows the ioctl bit size for some + *architectures, so we need to disable the relevant ioctls. + */ +#if _IOC_SIZEBITS < 14 +#define COMPR_CODEC_CAPS_OVERFLOW +#endif + /* TODO: * - add substream support for multiple devices in case of * SND_DYNAMIC_MINORS is not used @@ -440,6 +447,7 @@ out: return retval; } +#ifndef COMPR_CODEC_CAPS_OVERFLOW static int snd_compr_get_codec_caps(struct snd_compr_stream *stream, unsigned l
Re: linux-next: build failure after merge of the akpm tree
On Mon, 25 Jan 2016 12:41:50 +0100,
Mark Brown wrote:
>
> On Mon, Jan 25, 2016 at 10:29:54AM +0100, Takashi Iwai wrote:
> > Stephen Rothwell wrote:
>
> > > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> > > index 50693c867e71..ee5f36b9c787 100644
> > > --- a/sound/soc/codecs/Kconfig
> > > +++ b/sound/soc/codecs/Kconfig
> > > @@ -13,6 +13,7 @@ menu "CODEC drivers"
> > > config SND_SOC_ALL_CODECS
> > > tristate "Build all ASoC CODEC drivers"
> > > depends on COMPILE_TEST
> > > + depends on !PPC
> > > select SND_SOC_88PM860X if MFD_88PM860X
> > > select SND_SOC_L3
> > > select SND_SOC_AB8500_CODEC if ABX500_CORE
>
> > Suppressing this whole is an overreaction, IMO. It should suffice
> > just to disable compile-testing Intel driver.
>
> Please send patches and reports to maintainers :( I agree that this is
> an absurdly wide change.
>
> > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> > index 803f95e40679..d854cd66e090 100644
> > --- a/sound/soc/intel/Kconfig
> > +++ b/sound/soc/intel/Kconfig
> > @@ -31,6 +31,8 @@ config SND_SOC_INTEL_SST
> > tristate
> > select SND_SOC_INTEL_SST_ACPI if ACPI
> > depends on (X86 || COMPILE_TEST)
> > + # FIXME: a part of compress API is broken for PPC
> > + depends on !PPC
>
> Why is an Intel CPU thing being enabled by SND_SOC_ALL_CODECS? I'm also
> unclear why this will help when we're selecting in the drivers so their
> dependencies will be ignored.
Yeah, obviously papering over a wrong place.
In anyway, thinking of this workaround again, I don't think it being
the best way. The easier and safer workaround is to just avoid the
corresponding ioctl being handled. The untested patch is attached
below.
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] ALSA: compress: Disable GET_CODEC_CAPS ioctl for some
architectures
Some architectures like PowerPC can handle the maximum struct size in
an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by
SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This
problem was revealed recently by a powerpc change, as it's now treated
as a fatal build error.
This patch is a workaround for that: for architectures with less than
14 bit ioctl struct size, get rid of the handling of the relevant
ioctl. We should provide an alternative equivalent ioctl code later,
but for now just paper over it. Luckily, the compress API hasn't been
used on such architectures, so the impact must be effectively zero.
Signed-off-by: Takashi Iwai
---
sound/core/compress_offload.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
index 18b8dc45bb8f..36b0083fd9f4 100644
--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -46,6 +46,13 @@
#include
#include
+/* FIXME: struct snd_compr_codec_caps overflows the ioctl bit size for some
+ *architectures, so we need to disable the relevant ioctls.
+ */
+#if _IOC_SIZEBITS < 13
+#define COMPR_CODEC_CAPS_OVERFLOW
+#endif
+
/* TODO:
* - add substream support for multiple devices in case of
* SND_DYNAMIC_MINORS is not used
@@ -440,6 +447,7 @@ out:
return retval;
}
+#ifndef COMPR_CODEC_CAPS_OVERFLOW
static int
snd_compr_get_codec_caps(struct snd_compr_stream *stream, unsigned long arg)
{
@@ -463,6 +471,7 @@ out:
kfree(caps);
return retval;
}
+#endif /* !COMPR_CODEC_CAPS_OVERFLOW */
/* revisit this with snd_pcm_preallocate_xxx */
static int snd_compr_allocate_buffer(struct snd_compr_stream *stream,
@@ -801,9 +810,11 @@ static long snd_compr_ioctl(struct file *f, unsigned int
cmd, unsigned long arg)
case _IOC_NR(SNDRV_COMPRESS_GET_CAPS):
retval = snd_compr_get_caps(stream, arg);
break;
+#ifndef COMPR_CODEC_CAPS_OVERFLOW
case _IOC_NR(SNDRV_COMPRESS_GET_CODEC_CAPS):
retval = snd_compr_get_codec_caps(stream, arg);
break;
+#endif
case _IOC_NR(SNDRV_COMPRESS_SET_PARAMS):
retval = snd_compr_set_params(stream, arg);
break;
--
2.7.0
Re: linux-next: build failure after merge of the akpm tree
On Mon, Jan 25, 2016 at 10:29:54AM +0100, Takashi Iwai wrote: > Stephen Rothwell wrote: > > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig > > index 50693c867e71..ee5f36b9c787 100644 > > --- a/sound/soc/codecs/Kconfig > > +++ b/sound/soc/codecs/Kconfig > > @@ -13,6 +13,7 @@ menu "CODEC drivers" > > config SND_SOC_ALL_CODECS > > tristate "Build all ASoC CODEC drivers" > > depends on COMPILE_TEST > > + depends on !PPC > > select SND_SOC_88PM860X if MFD_88PM860X > > select SND_SOC_L3 > > select SND_SOC_AB8500_CODEC if ABX500_CORE > Suppressing this whole is an overreaction, IMO. It should suffice > just to disable compile-testing Intel driver. Please send patches and reports to maintainers :( I agree that this is an absurdly wide change. > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig > index 803f95e40679..d854cd66e090 100644 > --- a/sound/soc/intel/Kconfig > +++ b/sound/soc/intel/Kconfig > @@ -31,6 +31,8 @@ config SND_SOC_INTEL_SST > tristate > select SND_SOC_INTEL_SST_ACPI if ACPI > depends on (X86 || COMPILE_TEST) > + # FIXME: a part of compress API is broken for PPC > + depends on !PPC Why is an Intel CPU thing being enabled by SND_SOC_ALL_CODECS? I'm also unclear why this will help when we're selecting in the drivers so their dependencies will be ignored. signature.asc Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
On Mon, Jan 25, 2016 at 12:03:54PM +0100, Takashi Iwai wrote: > On Mon, 25 Jan 2016 11:45:56 +0100, > Sudip Mukherjee wrote: > > > > On Mon, Jan 25, 2016 at 10:29:54AM +0100, Takashi Iwai wrote: > > > On Fri, 22 Jan 2016 03:40:45 +0100, > > > Stephen Rothwell wrote: > > > > > > > > Hi all, > > > > > > > > > > > > From: Stephen Rothwell > > > > Date: Fri, 22 Jan 2016 13:24:57 +1100 > > > > Subject: [PATCH] next: suppress the building of all the sound codecs on > > > > PPC > > > > for now > > > > > > > > Signed-off-by: Stephen Rothwell > > > > --- > > > > sound/soc/codecs/Kconfig | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig > > > > index 50693c867e71..ee5f36b9c787 100644 > > > > --- a/sound/soc/codecs/Kconfig > > > > +++ b/sound/soc/codecs/Kconfig > > > > @@ -13,6 +13,7 @@ menu "CODEC drivers" > > > > config SND_SOC_ALL_CODECS > > > > tristate "Build all ASoC CODEC drivers" > > > > depends on COMPILE_TEST > > > > + depends on !PPC > > > > select SND_SOC_88PM860X if MFD_88PM860X > > > > select SND_SOC_L3 > > > > select SND_SOC_AB8500_CODEC if ABX500_CORE > > > > > > Suppressing this whole is an overreaction, IMO. It should suffice > > > just to disable compile-testing Intel driver. > > > How about the patch below? > > > > > > > > > thanks, > > > > > > Takashi > > > > > > -- 8< -- > > > From: Takashi Iwai > > > Subject: [PATCH] ASoC: intel: suppress compile-test with PowerPC > > > > > > Since some ioctl in compress offload API is broken for PPC (the struct > > > size overflows), now we get actually the build error. > > > > > > Until we get the proper solution (e.g. alternative ioctl), let's > > > disable the build of Intel ASoC driver that is the only driver who > > > enables SND_SOC_COMPRESS (and eventually SND_COMPRESS_OFFLOAD) in the > > > mainline tree. > > > > Sorry, but this does not fix the build failure. > > I can still see SND_COMPRESS_OFFLOAD=m in .config and the build fails. > > Who sets this config? SND_COMPRESS_OFFLOAD has no prompt, so this > should be default off. I think when we are doing allmodconfig SND_SOC_COMPRESS will be selected which in turn will select SND_COMPRESS_OFFLOAD as SND_SOC_COMPRESS depends only on SND_SOC. And alpha is not affected. It builds fine. regards sudip
Re: linux-next: build failure after merge of the akpm tree
On Mon, 25 Jan 2016 11:45:56 +0100,
Sudip Mukherjee wrote:
>
> On Mon, Jan 25, 2016 at 10:29:54AM +0100, Takashi Iwai wrote:
> > On Fri, 22 Jan 2016 03:40:45 +0100,
> > Stephen Rothwell wrote:
> > >
> > > Hi all,
> > >
> > > On Fri, 22 Jan 2016 11:24:42 +1100 Stephen Rothwell
> > > wrote:
> > > >
> > > > On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell
> > > > wrote:
> > > > >
> > > > > On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai
> > > > > wrote:
> > > > > >
> > > > > > On Sat, 16 Jan 2016 09:51:29 +0100,
> > > > > > Takashi Iwai wrote:
> > > > > > >
> > > > > > > There are a few ways to fix this, but all are not comfortable.
> > > > > > >
> > > > > > > A. Disable compress API for powerpc.
> > > > >
> > > > > This also affects alpha, mips and (maybe) sparc.
> > > >
> > > > This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
> > > > UBSAN support") which is in Linus' tree as of this morning. The only
> > > > relevant change that made was in the compiler flags (I tested this by
> > > > building the file without that commit but with these new compiler flags:
> > > >
> > > > -fsanitize=shift -fsanitize=integer-divide-by-zero
> > > > -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
> > > > -fsanitize=signed-integer-overflow -fsanitize=bounds
> > > > -fsanitize=object-size -fsanitize=returns-nonnull-attribute
> > > > -fsanitize=bool -fsanitize=enum -fsanitize=alignment
> > > >
> > > > The preprocessed file is the same in both cases, but with these flags
> > > > the compiler errors.
> > >
> > > So for now I have suppressed the error using the following patch (which
> > > I will keep in my fixes tree until some other fix is applied):
> > >
> > > From: Stephen Rothwell
> > > Date: Fri, 22 Jan 2016 13:24:57 +1100
> > > Subject: [PATCH] next: suppress the building of all the sound codecs on
> > > PPC
> > > for now
> > >
> > > Signed-off-by: Stephen Rothwell
> > > ---
> > > sound/soc/codecs/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> > > index 50693c867e71..ee5f36b9c787 100644
> > > --- a/sound/soc/codecs/Kconfig
> > > +++ b/sound/soc/codecs/Kconfig
> > > @@ -13,6 +13,7 @@ menu "CODEC drivers"
> > > config SND_SOC_ALL_CODECS
> > > tristate "Build all ASoC CODEC drivers"
> > > depends on COMPILE_TEST
> > > + depends on !PPC
> > > select SND_SOC_88PM860X if MFD_88PM860X
> > > select SND_SOC_L3
> > > select SND_SOC_AB8500_CODEC if ABX500_CORE
> >
> > Suppressing this whole is an overreaction, IMO. It should suffice
> > just to disable compile-testing Intel driver.
> > How about the patch below?
> >
> >
> > thanks,
> >
> > Takashi
> >
> > -- 8< --
> > From: Takashi Iwai
> > Subject: [PATCH] ASoC: intel: suppress compile-test with PowerPC
> >
> > Since some ioctl in compress offload API is broken for PPC (the struct
> > size overflows), now we get actually the build error.
> >
> > Until we get the proper solution (e.g. alternative ioctl), let's
> > disable the build of Intel ASoC driver that is the only driver who
> > enables SND_SOC_COMPRESS (and eventually SND_COMPRESS_OFFLOAD) in the
> > mainline tree.
>
> Sorry, but this does not fix the build failure.
> I can still see SND_COMPRESS_OFFLOAD=m in .config and the build fails.
Who sets this config? SND_COMPRESS_OFFLOAD has no prompt, so this
should be default off.
> But the following does fix it for powerpc:
>
> diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
> index 7ea66ee..b92d286 100644
> --- a/sound/soc/Kconfig
> +++ b/sound/soc/Kconfig
> @@ -31,6 +31,7 @@ config SND_SOC_GENERIC_DMAENGINE_PCM
>
> config SND_SOC_COMPRESS
> bool
> + depends on !PPC
> select SND_COMPRESS_OFFLOAD
>
> config SND_SOC_TOPOLOGY
It has a reverse-selection, and the reverse-selection ignores Depends,
AFAIK. If that long-standing problem were already fixed, it's
great...
Takashi
>
> --
>
> I will just check with alpha and see if that is also affected.
>
> regards
> sudip
>
Re: linux-next: build failure after merge of the akpm tree
On Mon, Jan 25, 2016 at 10:29:54AM +0100, Takashi Iwai wrote:
> On Fri, 22 Jan 2016 03:40:45 +0100,
> Stephen Rothwell wrote:
> >
> > Hi all,
> >
> > On Fri, 22 Jan 2016 11:24:42 +1100 Stephen Rothwell
> > wrote:
> > >
> > > On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell
> > > wrote:
> > > >
> > > > On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai wrote:
> > > > >
> > > > > On Sat, 16 Jan 2016 09:51:29 +0100,
> > > > > Takashi Iwai wrote:
> > > > > >
> > > > > > There are a few ways to fix this, but all are not comfortable.
> > > > > >
> > > > > > A. Disable compress API for powerpc.
> > > >
> > > > This also affects alpha, mips and (maybe) sparc.
> > >
> > > This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
> > > UBSAN support") which is in Linus' tree as of this morning. The only
> > > relevant change that made was in the compiler flags (I tested this by
> > > building the file without that commit but with these new compiler flags:
> > >
> > > -fsanitize=shift -fsanitize=integer-divide-by-zero
> > > -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
> > > -fsanitize=signed-integer-overflow -fsanitize=bounds
> > > -fsanitize=object-size -fsanitize=returns-nonnull-attribute
> > > -fsanitize=bool -fsanitize=enum -fsanitize=alignment
> > >
> > > The preprocessed file is the same in both cases, but with these flags
> > > the compiler errors.
> >
> > So for now I have suppressed the error using the following patch (which
> > I will keep in my fixes tree until some other fix is applied):
> >
> > From: Stephen Rothwell
> > Date: Fri, 22 Jan 2016 13:24:57 +1100
> > Subject: [PATCH] next: suppress the building of all the sound codecs on PPC
> > for now
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > sound/soc/codecs/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> > index 50693c867e71..ee5f36b9c787 100644
> > --- a/sound/soc/codecs/Kconfig
> > +++ b/sound/soc/codecs/Kconfig
> > @@ -13,6 +13,7 @@ menu "CODEC drivers"
> > config SND_SOC_ALL_CODECS
> > tristate "Build all ASoC CODEC drivers"
> > depends on COMPILE_TEST
> > + depends on !PPC
> > select SND_SOC_88PM860X if MFD_88PM860X
> > select SND_SOC_L3
> > select SND_SOC_AB8500_CODEC if ABX500_CORE
>
> Suppressing this whole is an overreaction, IMO. It should suffice
> just to disable compile-testing Intel driver.
> How about the patch below?
>
>
> thanks,
>
> Takashi
>
> -- 8< --
> From: Takashi Iwai
> Subject: [PATCH] ASoC: intel: suppress compile-test with PowerPC
>
> Since some ioctl in compress offload API is broken for PPC (the struct
> size overflows), now we get actually the build error.
>
> Until we get the proper solution (e.g. alternative ioctl), let's
> disable the build of Intel ASoC driver that is the only driver who
> enables SND_SOC_COMPRESS (and eventually SND_COMPRESS_OFFLOAD) in the
> mainline tree.
Sorry, but this does not fix the build failure.
I can still see SND_COMPRESS_OFFLOAD=m in .config and the build fails.
But the following does fix it for powerpc:
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 7ea66ee..b92d286 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -31,6 +31,7 @@ config SND_SOC_GENERIC_DMAENGINE_PCM
config SND_SOC_COMPRESS
bool
+ depends on !PPC
select SND_COMPRESS_OFFLOAD
config SND_SOC_TOPOLOGY
--
I will just check with alpha and see if that is also affected.
regards
sudip
Re: linux-next: build failure after merge of the akpm tree
On Mon, 25 Jan 2016 11:41:12 +0100,
Vinod Koul wrote:
>
> On Mon, Jan 25, 2016 at 10:29:54AM +0100, Takashi Iwai wrote:
> > On Fri, 22 Jan 2016 03:40:45 +0100,
> > Stephen Rothwell wrote:
> > >
> > > Hi all,
> > >
> > > On Fri, 22 Jan 2016 11:24:42 +1100 Stephen Rothwell
> > > wrote:
> > > >
> > > > On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell
> > > > wrote:
> > > > >
> > > > > On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai
> > > > > wrote:
> > > > > >
> > > > > > On Sat, 16 Jan 2016 09:51:29 +0100,
> > > > > > Takashi Iwai wrote:
> > > > > > >
> > > > > > > There are a few ways to fix this, but all are not comfortable.
> > > > > > >
> > > > > > > A. Disable compress API for powerpc.
> > > > >
> > > > > This also affects alpha, mips and (maybe) sparc.
> > > >
> > > > This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
> > > > UBSAN support") which is in Linus' tree as of this morning. The only
> > > > relevant change that made was in the compiler flags (I tested this by
> > > > building the file without that commit but with these new compiler flags:
> > > >
> > > > -fsanitize=shift -fsanitize=integer-divide-by-zero
> > > > -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
> > > > -fsanitize=signed-integer-overflow -fsanitize=bounds
> > > > -fsanitize=object-size -fsanitize=returns-nonnull-attribute
> > > > -fsanitize=bool -fsanitize=enum -fsanitize=alignment
> > > >
> > > > The preprocessed file is the same in both cases, but with these flags
> > > > the compiler errors.
> > >
> > > So for now I have suppressed the error using the following patch (which
> > > I will keep in my fixes tree until some other fix is applied):
> > >
> > > From: Stephen Rothwell
> > > Date: Fri, 22 Jan 2016 13:24:57 +1100
> > > Subject: [PATCH] next: suppress the building of all the sound codecs on
> > > PPC
> > > for now
> > >
> > > Signed-off-by: Stephen Rothwell
> > > ---
> > > sound/soc/codecs/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> > > index 50693c867e71..ee5f36b9c787 100644
> > > --- a/sound/soc/codecs/Kconfig
> > > +++ b/sound/soc/codecs/Kconfig
> > > @@ -13,6 +13,7 @@ menu "CODEC drivers"
> > > config SND_SOC_ALL_CODECS
> > > tristate "Build all ASoC CODEC drivers"
> > > depends on COMPILE_TEST
> > > + depends on !PPC
> > > select SND_SOC_88PM860X if MFD_88PM860X
> > > select SND_SOC_L3
> > > select SND_SOC_AB8500_CODEC if ABX500_CORE
> >
> > Suppressing this whole is an overreaction, IMO. It should suffice
> > just to disable compile-testing Intel driver.
> > How about the patch below?
>
> Takashi,
>
> This wont fix it as we have WM driver using this as well. SND_SOC_WM_ADSP
> uses SND_SOC_COMPRESS.
Yes, but SND_SOC_WM_ADSP isn't selected at all in the mainline, so
my patch should work actually alone.
> So the better fix would be to do so in either SND_SOC_COMPRESS or even
> better in SND_COMPRESS_OFFLOAD..
No, it won't work because it's reverse-selected. You can't put
depends there. It's a known limitation of the current Kconfig stuff.
Takashi
> I think this has been exposed by WM driver as Intel driver depends on X86 so
> compress core wouldn't be compiled as none of the drivers select this :)
>
> --
> Thanks
> ~Vinod
> >
> >
> > thanks,
> >
> > Takashi
> >
> > -- 8< --
> > From: Takashi Iwai
> > Subject: [PATCH] ASoC: intel: suppress compile-test with PowerPC
> >
> > Since some ioctl in compress offload API is broken for PPC (the struct
> > size overflows), now we get actually the build error.
> >
> > Until we get the proper solution (e.g. alternative ioctl), let's
> > disable the build of Intel ASoC driver that is the only driver who
> > enables SND_SOC_COMPRESS (and eventually SND_COMPRESS_OFFLOAD) in the
> > mainline tree.
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > sound/soc/intel/Kconfig | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> > index 803f95e40679..d854cd66e090 100644
> > --- a/sound/soc/intel/Kconfig
> > +++ b/sound/soc/intel/Kconfig
> > @@ -31,6 +31,8 @@ config SND_SOC_INTEL_SST
> > tristate
> > select SND_SOC_INTEL_SST_ACPI if ACPI
> > depends on (X86 || COMPILE_TEST)
> > + # FIXME: a part of compress API is broken for PPC
> > + depends on !PPC
> >
> > config SND_SOC_INTEL_SST_ACPI
> > tristate
> > --
> > 2.7.0
> >
>
Re: linux-next: build failure after merge of the akpm tree
On Mon, Jan 25, 2016 at 10:29:54AM +0100, Takashi Iwai wrote:
> On Fri, 22 Jan 2016 03:40:45 +0100,
> Stephen Rothwell wrote:
> >
> > Hi all,
> >
> > On Fri, 22 Jan 2016 11:24:42 +1100 Stephen Rothwell
> > wrote:
> > >
> > > On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell
> > > wrote:
> > > >
> > > > On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai wrote:
> > > > >
> > > > > On Sat, 16 Jan 2016 09:51:29 +0100,
> > > > > Takashi Iwai wrote:
> > > > > >
> > > > > > There are a few ways to fix this, but all are not comfortable.
> > > > > >
> > > > > > A. Disable compress API for powerpc.
> > > >
> > > > This also affects alpha, mips and (maybe) sparc.
> > >
> > > This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
> > > UBSAN support") which is in Linus' tree as of this morning. The only
> > > relevant change that made was in the compiler flags (I tested this by
> > > building the file without that commit but with these new compiler flags:
> > >
> > > -fsanitize=shift -fsanitize=integer-divide-by-zero
> > > -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
> > > -fsanitize=signed-integer-overflow -fsanitize=bounds
> > > -fsanitize=object-size -fsanitize=returns-nonnull-attribute
> > > -fsanitize=bool -fsanitize=enum -fsanitize=alignment
> > >
> > > The preprocessed file is the same in both cases, but with these flags
> > > the compiler errors.
> >
> > So for now I have suppressed the error using the following patch (which
> > I will keep in my fixes tree until some other fix is applied):
> >
> > From: Stephen Rothwell
> > Date: Fri, 22 Jan 2016 13:24:57 +1100
> > Subject: [PATCH] next: suppress the building of all the sound codecs on PPC
> > for now
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > sound/soc/codecs/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> > index 50693c867e71..ee5f36b9c787 100644
> > --- a/sound/soc/codecs/Kconfig
> > +++ b/sound/soc/codecs/Kconfig
> > @@ -13,6 +13,7 @@ menu "CODEC drivers"
> > config SND_SOC_ALL_CODECS
> > tristate "Build all ASoC CODEC drivers"
> > depends on COMPILE_TEST
> > + depends on !PPC
> > select SND_SOC_88PM860X if MFD_88PM860X
> > select SND_SOC_L3
> > select SND_SOC_AB8500_CODEC if ABX500_CORE
>
> Suppressing this whole is an overreaction, IMO. It should suffice
> just to disable compile-testing Intel driver.
> How about the patch below?
Takashi,
This wont fix it as we have WM driver using this as well. SND_SOC_WM_ADSP
uses SND_SOC_COMPRESS.
So the better fix would be to do so in either SND_SOC_COMPRESS or even
better in SND_COMPRESS_OFFLOAD..
I think this has been exposed by WM driver as Intel driver depends on X86 so
compress core wouldn't be compiled as none of the drivers select this :)
--
Thanks
~Vinod
>
>
> thanks,
>
> Takashi
>
> -- 8< --
> From: Takashi Iwai
> Subject: [PATCH] ASoC: intel: suppress compile-test with PowerPC
>
> Since some ioctl in compress offload API is broken for PPC (the struct
> size overflows), now we get actually the build error.
>
> Until we get the proper solution (e.g. alternative ioctl), let's
> disable the build of Intel ASoC driver that is the only driver who
> enables SND_SOC_COMPRESS (and eventually SND_COMPRESS_OFFLOAD) in the
> mainline tree.
>
> Signed-off-by: Takashi Iwai
> ---
> sound/soc/intel/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> index 803f95e40679..d854cd66e090 100644
> --- a/sound/soc/intel/Kconfig
> +++ b/sound/soc/intel/Kconfig
> @@ -31,6 +31,8 @@ config SND_SOC_INTEL_SST
> tristate
> select SND_SOC_INTEL_SST_ACPI if ACPI
> depends on (X86 || COMPILE_TEST)
> + # FIXME: a part of compress API is broken for PPC
> + depends on !PPC
>
> config SND_SOC_INTEL_SST_ACPI
> tristate
> --
> 2.7.0
>
Re: linux-next: build failure after merge of the akpm tree
On Mon, 25 Jan 2016 10:40:14 +0100, Michael Ellerman wrote: > > On Mon, 2016-01-25 at 10:29 +0100, Takashi Iwai wrote: > > On Fri, 22 Jan 2016 03:40:45 +0100, Stephen Rothwell wrote: > > > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig > > > index 50693c867e71..ee5f36b9c787 100644 > > > --- a/sound/soc/codecs/Kconfig > > > +++ b/sound/soc/codecs/Kconfig > > > @@ -13,6 +13,7 @@ menu "CODEC drivers" > > > config SND_SOC_ALL_CODECS > > > tristate "Build all ASoC CODEC drivers" > > > depends on COMPILE_TEST > > > + depends on !PPC > > > select SND_SOC_88PM860X if MFD_88PM860X > > > select SND_SOC_L3 > > > select SND_SOC_AB8500_CODEC if ABX500_CORE > > > > Suppressing this whole is an overreaction, IMO. It should suffice > > just to disable compile-testing Intel driver. > > How about the patch below? > > > > > > thanks, > > > > Takashi > > > > -- 8< -- > > From: Takashi Iwai > > Subject: [PATCH] ASoC: intel: suppress compile-test with PowerPC > > > > Since some ioctl in compress offload API is broken for PPC (the struct > > size overflows), now we get actually the build error. > > > > Until we get the proper solution (e.g. alternative ioctl), let's > > disable the build of Intel ASoC driver that is the only driver who > > enables SND_SOC_COMPRESS (and eventually SND_COMPRESS_OFFLOAD) in the > > mainline tree. > > > > Signed-off-by: Takashi Iwai > > --- > > sound/soc/intel/Kconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig > > index 803f95e40679..d854cd66e090 100644 > > --- a/sound/soc/intel/Kconfig > > +++ b/sound/soc/intel/Kconfig > > @@ -31,6 +31,8 @@ config SND_SOC_INTEL_SST > > tristate > > select SND_SOC_INTEL_SST_ACPI if ACPI > > depends on (X86 || COMPILE_TEST) > > + # FIXME: a part of compress API is broken for PPC > > + depends on !PPC > > > > config SND_SOC_INTEL_SST_ACPI > > tristate > > > That's fine by me. > > Acked-by: Michael Ellerman > > > Though it looks like alpha and mips would also be broken, but perhaps they > can't build that code for some other reason. > > arch/alpha/include/uapi/asm/ioctl.h:#define _IOC_SIZEBITS 13 > arch/mips/include/uapi/asm/ioctl.h:#define _IOC_SIZEBITS13 OK, I'll resubmit the patch including these other archs. thanks, Takashi
Re: linux-next: build failure after merge of the akpm tree
On Mon, 2016-01-25 at 10:29 +0100, Takashi Iwai wrote: > On Fri, 22 Jan 2016 03:40:45 +0100, Stephen Rothwell wrote: > > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig > > index 50693c867e71..ee5f36b9c787 100644 > > --- a/sound/soc/codecs/Kconfig > > +++ b/sound/soc/codecs/Kconfig > > @@ -13,6 +13,7 @@ menu "CODEC drivers" > > config SND_SOC_ALL_CODECS > > tristate "Build all ASoC CODEC drivers" > > depends on COMPILE_TEST > > + depends on !PPC > > select SND_SOC_88PM860X if MFD_88PM860X > > select SND_SOC_L3 > > select SND_SOC_AB8500_CODEC if ABX500_CORE > > Suppressing this whole is an overreaction, IMO. It should suffice > just to disable compile-testing Intel driver. > How about the patch below? > > > thanks, > > Takashi > > -- 8< -- > From: Takashi Iwai > Subject: [PATCH] ASoC: intel: suppress compile-test with PowerPC > > Since some ioctl in compress offload API is broken for PPC (the struct > size overflows), now we get actually the build error. > > Until we get the proper solution (e.g. alternative ioctl), let's > disable the build of Intel ASoC driver that is the only driver who > enables SND_SOC_COMPRESS (and eventually SND_COMPRESS_OFFLOAD) in the > mainline tree. > > Signed-off-by: Takashi Iwai > --- > sound/soc/intel/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig > index 803f95e40679..d854cd66e090 100644 > --- a/sound/soc/intel/Kconfig > +++ b/sound/soc/intel/Kconfig > @@ -31,6 +31,8 @@ config SND_SOC_INTEL_SST > tristate > select SND_SOC_INTEL_SST_ACPI if ACPI > depends on (X86 || COMPILE_TEST) > + # FIXME: a part of compress API is broken for PPC > + depends on !PPC > > config SND_SOC_INTEL_SST_ACPI > tristate That's fine by me. Acked-by: Michael Ellerman Though it looks like alpha and mips would also be broken, but perhaps they can't build that code for some other reason. arch/alpha/include/uapi/asm/ioctl.h:#define _IOC_SIZEBITS 13 arch/mips/include/uapi/asm/ioctl.h:#define _IOC_SIZEBITS13 cheers
Re: linux-next: build failure after merge of the akpm tree
On Fri, 22 Jan 2016 03:40:45 +0100,
Stephen Rothwell wrote:
>
> Hi all,
>
> On Fri, 22 Jan 2016 11:24:42 +1100 Stephen Rothwell
> wrote:
> >
> > On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell
> > wrote:
> > >
> > > On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai wrote:
> > > >
> > > > On Sat, 16 Jan 2016 09:51:29 +0100,
> > > > Takashi Iwai wrote:
> > > > >
> > > > > There are a few ways to fix this, but all are not comfortable.
> > > > >
> > > > > A. Disable compress API for powerpc.
> > >
> > > This also affects alpha, mips and (maybe) sparc.
> >
> > This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
> > UBSAN support") which is in Linus' tree as of this morning. The only
> > relevant change that made was in the compiler flags (I tested this by
> > building the file without that commit but with these new compiler flags:
> >
> > -fsanitize=shift -fsanitize=integer-divide-by-zero
> > -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
> > -fsanitize=signed-integer-overflow -fsanitize=bounds
> > -fsanitize=object-size -fsanitize=returns-nonnull-attribute
> > -fsanitize=bool -fsanitize=enum -fsanitize=alignment
> >
> > The preprocessed file is the same in both cases, but with these flags
> > the compiler errors.
>
> So for now I have suppressed the error using the following patch (which
> I will keep in my fixes tree until some other fix is applied):
>
> From: Stephen Rothwell
> Date: Fri, 22 Jan 2016 13:24:57 +1100
> Subject: [PATCH] next: suppress the building of all the sound codecs on PPC
> for now
>
> Signed-off-by: Stephen Rothwell
> ---
> sound/soc/codecs/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index 50693c867e71..ee5f36b9c787 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -13,6 +13,7 @@ menu "CODEC drivers"
> config SND_SOC_ALL_CODECS
> tristate "Build all ASoC CODEC drivers"
> depends on COMPILE_TEST
> + depends on !PPC
> select SND_SOC_88PM860X if MFD_88PM860X
> select SND_SOC_L3
> select SND_SOC_AB8500_CODEC if ABX500_CORE
Suppressing this whole is an overreaction, IMO. It should suffice
just to disable compile-testing Intel driver.
How about the patch below?
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] ASoC: intel: suppress compile-test with PowerPC
Since some ioctl in compress offload API is broken for PPC (the struct
size overflows), now we get actually the build error.
Until we get the proper solution (e.g. alternative ioctl), let's
disable the build of Intel ASoC driver that is the only driver who
enables SND_SOC_COMPRESS (and eventually SND_COMPRESS_OFFLOAD) in the
mainline tree.
Signed-off-by: Takashi Iwai
---
sound/soc/intel/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
index 803f95e40679..d854cd66e090 100644
--- a/sound/soc/intel/Kconfig
+++ b/sound/soc/intel/Kconfig
@@ -31,6 +31,8 @@ config SND_SOC_INTEL_SST
tristate
select SND_SOC_INTEL_SST_ACPI if ACPI
depends on (X86 || COMPILE_TEST)
+ # FIXME: a part of compress API is broken for PPC
+ depends on !PPC
config SND_SOC_INTEL_SST_ACPI
tristate
--
2.7.0
Re: linux-next: build failure after merge of the akpm tree
Hi all,
On Fri, 22 Jan 2016 11:24:42 +1100 Stephen Rothwell
wrote:
>
> On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell
> wrote:
> >
> > On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai wrote:
> > >
> > > On Sat, 16 Jan 2016 09:51:29 +0100,
> > > Takashi Iwai wrote:
> > > >
> > > > There are a few ways to fix this, but all are not comfortable.
> > > >
> > > > A. Disable compress API for powerpc.
> >
> > This also affects alpha, mips and (maybe) sparc.
>
> This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
> UBSAN support") which is in Linus' tree as of this morning. The only
> relevant change that made was in the compiler flags (I tested this by
> building the file without that commit but with these new compiler flags:
>
> -fsanitize=shift -fsanitize=integer-divide-by-zero
> -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
> -fsanitize=signed-integer-overflow -fsanitize=bounds
> -fsanitize=object-size -fsanitize=returns-nonnull-attribute
> -fsanitize=bool -fsanitize=enum -fsanitize=alignment
>
> The preprocessed file is the same in both cases, but with these flags
> the compiler errors.
I have discussed this with the PowerPC maintainer (Michael) and he
figured out why the compiler does not produce an error (normally). It
is because this driver is using _IOC_NR(xxx) to match ioctls instead of
the full ioctl number. Because of that, the compiler can figure out
that it does not care about the undefined reference to
__invalid_size_argument_for_IOC that the size check shouold generate
(since _IOC_NR shifts and masks it out).
So, the switch statement in snd_compr_ioctl() should be rewritten to
check against the full ioctl number (since currently it could
theoretically match any number of ioctls, not just the relevant ones).
And then something needs to be done about the very large structure
being passed.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
Re: linux-next: build failure after merge of the akpm tree
Hi all,
On Fri, 22 Jan 2016 11:24:42 +1100 Stephen Rothwell
wrote:
>
> On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell
> wrote:
> >
> > On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai wrote:
> > >
> > > On Sat, 16 Jan 2016 09:51:29 +0100,
> > > Takashi Iwai wrote:
> > > >
> > > > There are a few ways to fix this, but all are not comfortable.
> > > >
> > > > A. Disable compress API for powerpc.
> >
> > This also affects alpha, mips and (maybe) sparc.
>
> This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
> UBSAN support") which is in Linus' tree as of this morning. The only
> relevant change that made was in the compiler flags (I tested this by
> building the file without that commit but with these new compiler flags:
>
> -fsanitize=shift -fsanitize=integer-divide-by-zero
> -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
> -fsanitize=signed-integer-overflow -fsanitize=bounds
> -fsanitize=object-size -fsanitize=returns-nonnull-attribute
> -fsanitize=bool -fsanitize=enum -fsanitize=alignment
>
> The preprocessed file is the same in both cases, but with these flags
> the compiler errors.
So for now I have suppressed the error using the following patch (which
I will keep in my fixes tree until some other fix is applied):
From: Stephen Rothwell
Date: Fri, 22 Jan 2016 13:24:57 +1100
Subject: [PATCH] next: suppress the building of all the sound codecs on PPC
for now
Signed-off-by: Stephen Rothwell
---
sound/soc/codecs/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 50693c867e71..ee5f36b9c787 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -13,6 +13,7 @@ menu "CODEC drivers"
config SND_SOC_ALL_CODECS
tristate "Build all ASoC CODEC drivers"
depends on COMPILE_TEST
+ depends on !PPC
select SND_SOC_88PM860X if MFD_88PM860X
select SND_SOC_L3
select SND_SOC_AB8500_CODEC if ABX500_CORE
--
2.6.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
Re: linux-next: build failure after merge of the akpm tree
Hi all,
On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell
wrote:
>
> On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai wrote:
> >
> > On Sat, 16 Jan 2016 09:51:29 +0100,
> > Takashi Iwai wrote:
> > >
> > > There are a few ways to fix this, but all are not comfortable.
> > >
> > > A. Disable compress API for powerpc.
>
> This also affects alpha, mips and (maybe) sparc.
This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
UBSAN support") which is in Linus' tree as of this morning. The only
relevant change that made was in the compiler flags (I tested this by
building the file without that commit but with these new compiler flags:
-fsanitize=shift -fsanitize=integer-divide-by-zero
-fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
-fsanitize=signed-integer-overflow -fsanitize=bounds
-fsanitize=object-size -fsanitize=returns-nonnull-attribute
-fsanitize=bool -fsanitize=enum -fsanitize=alignment
The preprocessed file is the same in both cases, but with these flags
the compiler errors.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
Re: linux-next: build failure after merge of the akpm tree
Hi Takashi, On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai wrote: > > On Sat, 16 Jan 2016 09:51:29 +0100, > Takashi Iwai wrote: > > > > There are a few ways to fix this, but all are not comfortable. > > > > A. Disable compress API for powerpc. This also affects alpha, mips and (maybe) sparc. -- Cheers, Stephen Rothwells...@canb.auug.org.au
Re: linux-next: build failure after merge of the akpm tree
Hi Thierry, On Thu, 6 Nov 2014 12:24:00 +0100 Thierry Reding wrote: > > I fixed this using the attached patch. I will apply this to linux-next today (unless Andrew beats me to it). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgptxz_cahjEZ.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm tree
On Thu, Nov 06, 2014 at 12:24:00PM +0100, Thierry Reding wrote:
> On Thu, Nov 06, 2014 at 07:36:18PM +1100, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > After merging the akpm tree, today's linux-next build (sparc defconfig)
> > failed like this:
> >
> > mm/slab.c: In function 'slab_alloc':
> > mm/slab.c:3260:4: error: implicit declaration of function 'slab_free'
> > [-Werror=implicit-function-declaration]
> > slab_free(cachep, objp);
> > ^
> > mm/slab.c: At top level:
> > mm/slab.c:3534:29: warning: conflicting types for 'slab_free'
> > static __always_inline void slab_free(struct kmem_cache *cachep, void
> > *objp)
> > ^
> > mm/slab.c:3534:29: error: static declaration of 'slab_free' follows
> > non-static declaration
> > mm/slab.c:3260:4: note: previous implicit declaration of 'slab_free' was
> > here
> > slab_free(cachep, objp);
> > ^
> >
> > I am not sure what caused this, but it is something in the akpm-current
> > or akpm trees (possibly interacting with something else).
>
> I fixed this using the attached patch.
>
> Thierry
> From a9ec6cfacb892e044a5f76dce3b7fc9a3337d01a Mon Sep 17 00:00:00 2001
> From: Thierry Reding
> Date: Thu, 6 Nov 2014 11:59:23 +0100
> Subject: [PATCH] mm/slab: Always predeclare slab_free()
>
> Commit 5da1c3c725ab ("slab: recharge slab pages to the allocating memory
> cgroup") added a predeclaration of the new slab_free() helper so that it
> can be used in slab_alloc_node() and slab_alloc(). However the prototype
> is added in an #ifdef CONFIG_NUMA protected section of code, which works
> fine for slab_alloc_node() but fails for slab_alloc().
>
> Fixes the following build warnings and errors:
>
> mm/slab.c: In function 'slab_alloc':
> mm/slab.c:3260:4: error: implicit declaration of function 'slab_free'
> [-Werror=implicit-function-declaration]
> slab_free(cachep, objp);
> ^
> mm/slab.c: At top level:
> mm/slab.c:3534:29: warning: conflicting types for 'slab_free'
>static __always_inline void slab_free(struct kmem_cache *cachep, void
> *objp)
>^
> mm/slab.c:3534:29: error: static declaration of 'slab_free' follows
> non-static declaration
> mm/slab.c:3260:4: note: previous implicit declaration of 'slab_free'
> was here
> slab_free(cachep, objp);
> ^
>
> Reported-by: Stephen Rothwell
> Signed-off-by: Thierry Reding
> ---
> mm/slab.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 61b01c2ae1d9..00cd028404cb 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2961,6 +2961,8 @@ out:
> return objp;
> }
>
> +static __always_inline void slab_free(struct kmem_cache *cachep, void *objp);
> +
> #ifdef CONFIG_NUMA
> /*
> * Try allocating on another node if PFA_SPREAD_SLAB is a mempolicy is set.
> @@ -3133,8 +3135,6 @@ done:
> return obj;
> }
>
> -static __always_inline void slab_free(struct kmem_cache *cachep, void *objp);
> -
> static __always_inline void *
> slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid,
> unsigned long caller)
Attached is a follow-up cleanup patch that avoids the need for a pre-
declaration. Feel free to ignore if you prefer the predeclaration.
Thierry
From 3ad8947fd8613d13f2b9dc1ccd370d0a9ffaeb7b Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Thu, 6 Nov 2014 12:25:03 +0100
Subject: [PATCH] mm/slab: Shuffle code around to avoid a predeclaration
Instead of providing a predeclaration for the slab_free() helper, move
the helper and its dependencies before any of their users.
Signed-off-by: Thierry Reding
---
mm/slab.c | 200 +++---
1 file changed, 99 insertions(+), 101 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 00cd028404cb..3c025f5934da 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2961,7 +2961,105 @@ out:
return objp;
}
-static __always_inline void slab_free(struct kmem_cache *cachep, void *objp);
+static void cache_flusharray(struct kmem_cache *cachep, struct array_cache *ac)
+{
+ int batchcount;
+ struct kmem_cache_node *n;
+ int node = numa_mem_id();
+ LIST_HEAD(list);
+
+ batchcount = ac->batchcount;
+#if DEBUG
+ BUG_ON(!batchcount || batchcount > ac->avail);
+#endif
+ check_irq_off();
+ n = get_node(cachep, node);
+ spin_lock(&n->list_lock);
+ if (n->shared) {
+ struct array_cache *shared_array = n->shared;
+ int max = shared_array->limit - shared_array->avail;
+ if (max) {
+ if (batchcount > max)
+batchcount = max;
+ memcpy(&(shared_array->entry[shared_array->avail]),
+ ac->entry, sizeof(void *) * batchcount);
+ shared_array->avail += batchcount;
+ goto free_done;
+ }
+ }
+
+ free_block(cachep, ac->entry, batchcount, node, &list);
+free_done:
+#if STATS
+ {
+ int i = 0;
+ struct list_head *p;
+
+ p = n->slabs_free.next;
+ while (p != &(n->slabs_free)
Re: linux-next: build failure after merge of the akpm tree
On Thu, Nov 06, 2014 at 07:36:18PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (sparc defconfig)
> failed like this:
>
> mm/slab.c: In function 'slab_alloc':
> mm/slab.c:3260:4: error: implicit declaration of function 'slab_free'
> [-Werror=implicit-function-declaration]
> slab_free(cachep, objp);
> ^
> mm/slab.c: At top level:
> mm/slab.c:3534:29: warning: conflicting types for 'slab_free'
> static __always_inline void slab_free(struct kmem_cache *cachep, void *objp)
> ^
> mm/slab.c:3534:29: error: static declaration of 'slab_free' follows
> non-static declaration
> mm/slab.c:3260:4: note: previous implicit declaration of 'slab_free' was here
> slab_free(cachep, objp);
> ^
>
> I am not sure what caused this, but it is something in the akpm-current
> or akpm trees (possibly interacting with something else).
I fixed this using the attached patch.
Thierry
From a9ec6cfacb892e044a5f76dce3b7fc9a3337d01a Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Thu, 6 Nov 2014 11:59:23 +0100
Subject: [PATCH] mm/slab: Always predeclare slab_free()
Commit 5da1c3c725ab ("slab: recharge slab pages to the allocating memory
cgroup") added a predeclaration of the new slab_free() helper so that it
can be used in slab_alloc_node() and slab_alloc(). However the prototype
is added in an #ifdef CONFIG_NUMA protected section of code, which works
fine for slab_alloc_node() but fails for slab_alloc().
Fixes the following build warnings and errors:
mm/slab.c: In function 'slab_alloc':
mm/slab.c:3260:4: error: implicit declaration of function 'slab_free' [-Werror=implicit-function-declaration]
slab_free(cachep, objp);
^
mm/slab.c: At top level:
mm/slab.c:3534:29: warning: conflicting types for 'slab_free'
static __always_inline void slab_free(struct kmem_cache *cachep, void *objp)
^
mm/slab.c:3534:29: error: static declaration of 'slab_free' follows non-static declaration
mm/slab.c:3260:4: note: previous implicit declaration of 'slab_free' was here
slab_free(cachep, objp);
^
Reported-by: Stephen Rothwell
Signed-off-by: Thierry Reding
---
mm/slab.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 61b01c2ae1d9..00cd028404cb 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2961,6 +2961,8 @@ out:
return objp;
}
+static __always_inline void slab_free(struct kmem_cache *cachep, void *objp);
+
#ifdef CONFIG_NUMA
/*
* Try allocating on another node if PFA_SPREAD_SLAB is a mempolicy is set.
@@ -3133,8 +3135,6 @@ done:
return obj;
}
-static __always_inline void slab_free(struct kmem_cache *cachep, void *objp);
-
static __always_inline void *
slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid,
unsigned long caller)
--
2.1.3
pgpu5cJmfanz8.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
Hi Don,
On Tue, 26 Aug 2014 09:54:17 -0400 Don Zickus wrote:
>
> On Tue, Aug 26, 2014 at 05:18:18PM +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > After merging the akpm tree, today's linux-next build (sparc64
> > defconfig) failed like this:
> >
> > kernel/built-in.o: In function `proc_dowatchdog':
> > (.text+0x6a620): undefined reference to
> > `watchdog_hardlockup_detector_is_enabled'
> > kernel/built-in.o: In function `proc_dowatchdog':
> > (.text+0x6a6a8): undefined reference to
> > `watchdog_enable_hardlockup_detector'
> > kernel/built-in.o: In function `proc_dowatchdog':
> > (.text+0x6a79c): undefined reference to
> > `watchdog_enable_hardlockup_detector'
> >
> > Caused by commit 72355eed4bd7 ("kernel/watchdog.c: control hard lockup
> > detection default"). This build has CONFIG_HAVE_NMI_WATCHDOG=y,
> > CONFIG_HARDLOCKUP_DETECTOR not set.
>
> :-( I was trying to figure out why touch_nmi_watchdog doesn't break the
> same way until I noticed sparc has its own personal implementation of this
> function (instead of using kernel/watchdog.c's version).
>
> We are going to have to split the include/linux/nmi.h changes out into its
> own #ifdef area. I am not sure my brain is quite ready to untangle the
> sparc implementation of the watchdog stuff and try to make it use the
> generic one yet.
>
> This patch I believe fixes the compile problem for now.
>
> Not sure the proper way to post this or who to send this too.
Send it to Andrew Morton (since he has the original patch) who is cc'd
anyway. I will put this in linux-next today instead of reverting the
other patches if he doesn't get around to doing another mmotm before
then.
> From: Don Zickus
> Date: Tue, 26 Aug 2014 09:50:21 -0400
> Subject: [PATCH] watchdog, nmi: Fix compile issues on sparc
>
> Sparc doesn't use HARDLOCKUP_DETECTOR the same way x86 does. As a
> result break out the new functions
>
> watchdog_hardlockup_detector_is_enabled
> watchdog_enable_hardlockup_detector
>
> into their own #if defined area. This resolves the compile issue
> where CONFIG_NMI_WATCHDOG=y and CONFIG_HARDLOCKUP_DETECTOR is not set
> on sparc.
Reported-by: Stephen Rothwell
> Signed-off-by: Don Zickus
> ---
> include/linux/nmi.h | 10 +++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/nmi.h b/include/linux/nmi.h
> index 72aacf4..f82a5bf 100644
> --- a/include/linux/nmi.h
> +++ b/include/linux/nmi.h
> @@ -17,14 +17,18 @@
> #if defined(CONFIG_HAVE_NMI_WATCHDOG) ||
> defined(CONFIG_HARDLOCKUP_DETECTOR) #include
> extern void touch_nmi_watchdog(void);
> -extern void watchdog_enable_hardlockup_detector(bool val);
> -extern bool watchdog_hardlockup_detector_is_enabled(void);
> #else
> static inline void touch_nmi_watchdog(void)
> {
> touch_softlockup_watchdog();
> }
> -static inline void watchdog_enable_hardlockup_detector(bool)
> +#endif
> +
> +#if defined(CONFIG_HARDLOCKUP_DETECTOR)
> +extern void watchdog_enable_hardlockup_detector(bool val);
> +extern bool watchdog_hardlockup_detector_is_enabled(void);
> +#else
> +static inline void watchdog_enable_hardlockup_detector(bool val)
> {
> }
> static inline bool watchdog_hardlockup_detector_is_enabled(void)
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
On Tue, Aug 26, 2014 at 05:18:18PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> kernel/built-in.o: In function `proc_dowatchdog':
> (.text+0x6a620): undefined reference to
> `watchdog_hardlockup_detector_is_enabled'
> kernel/built-in.o: In function `proc_dowatchdog':
> (.text+0x6a6a8): undefined reference to `watchdog_enable_hardlockup_detector'
> kernel/built-in.o: In function `proc_dowatchdog':
> (.text+0x6a79c): undefined reference to `watchdog_enable_hardlockup_detector'
>
> Caused by commit 72355eed4bd7 ("kernel/watchdog.c: control hard lockup
> detection default"). This build has CONFIG_HAVE_NMI_WATCHDOG=y,
> CONFIG_HARDLOCKUP_DETECTOR not set.
:-( I was trying to figure out why touch_nmi_watchdog doesn't break the
same way until I noticed sparc has its own personal implementation of this
function (instead of using kernel/watchdog.c's version).
We are going to have to split the include/linux/nmi.h changes out into its
own #ifdef area. I am not sure my brain is quite ready to untangle the
sparc implementation of the watchdog stuff and try to make it use the
generic one yet.
This patch I believe fixes the compile problem for now.
Not sure the proper way to post this or who to send this too.
--8<--
From: Don Zickus
Date: Tue, 26 Aug 2014 09:50:21 -0400
Subject: [PATCH] watchdog, nmi: Fix compile issues on sparc
Sparc doesn't use HARDLOCKUP_DETECTOR the same way x86 does. As a result break
out the new functions
watchdog_hardlockup_detector_is_enabled
watchdog_enable_hardlockup_detector
into their own #if defined area. This resolves the compile issue where
CONFIG_NMI_WATCHDOG=y and CONFIG_HARDLOCKUP_DETECTOR is not set on sparc.
Signed-off-by: Don Zickus
---
include/linux/nmi.h | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index 72aacf4..f82a5bf 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -17,14 +17,18 @@
#if defined(CONFIG_HAVE_NMI_WATCHDOG) || defined(CONFIG_HARDLOCKUP_DETECTOR)
#include
extern void touch_nmi_watchdog(void);
-extern void watchdog_enable_hardlockup_detector(bool val);
-extern bool watchdog_hardlockup_detector_is_enabled(void);
#else
static inline void touch_nmi_watchdog(void)
{
touch_softlockup_watchdog();
}
-static inline void watchdog_enable_hardlockup_detector(bool)
+#endif
+
+#if defined(CONFIG_HARDLOCKUP_DETECTOR)
+extern void watchdog_enable_hardlockup_detector(bool val);
+extern bool watchdog_hardlockup_detector_is_enabled(void);
+#else
+static inline void watchdog_enable_hardlockup_detector(bool val)
{
}
static inline bool watchdog_hardlockup_detector_is_enabled(void)
--
1.7.1
--
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 akpm tree
On Wed 16-07-14 18:26:41, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> mm/memcontrol.c:5269:12: error: 'CFTYPE_INSANE' undeclared here (not in a
> function)
>.flags = CFTYPE_INSANE,
> ^
>
> Caused by commit 8fa6a8baeffc ("memcg: deprecate memory.force_empty
> knob") interacting with commits a8ddc8215e1a ("cgroup: distinguish the
> default and legacy hierarchies when handling cftypes") and 05ebb6e60f04
> ("cgroup: make CFTYPE_ONLY_ON_DFL and CFTYPE_NO_ internal to cgroup
> core") from the cgroup tree.
>
> I applied the following fix up patch:
This basically means dropping the page from Andrew's tree after the
above cgroups changes. I am sorry but I was really busy last few weeks
so I didn't follow cgroups changes closely. I will post a patch that
deals with the dfl hierarchy.
> From: Stephen Rothwell
> Date: Wed, 16 Jul 2014 18:20:59 +1000
> Subject: [PATCH] memcg-deprecate-memoryforce_empty-knob-fix2
>
> Signed-off-by: Stephen Rothwell
> ---
> mm/memcontrol.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 8fa6602a32cd..e1c9699b157b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5266,7 +5266,6 @@ static struct cftype mem_cgroup_files[] = {
> },
> {
> .name = "force_empty",
> - .flags = CFTYPE_INSANE,
> .write = mem_cgroup_force_empty_write,
> },
> {
> --
> 2.0.1
>
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
Michal Hocko
SUSE Labs
--
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 akpm tree
On Fri, 7 Mar 2014 11:05:49 -0600 (CST) Christoph Lameter wrote: > On Thu, 6 Mar 2014, Andrew Morton wrote: > > > > So, by "the whole series" do you mean just/all these: > > > > > > percpu-add-raw_cpu_ops.patch > > > ... > > > sh-replace-__get_cpu_var-uses.patch > > > > Yep. Commented out in http://ozlabs.org/~akpm/mmots/series > > > > > If so, I will remove them from my tree today (if you don't get around to > > > a new mmotm before then). > > > > Cool. > > I need at least the initial 5 patches that establish the framework in > -next and do the debugging in order to make further progress on this one. I'll re-enable percpu-add-raw_cpu_ops.patch mm-use-raw_cpu-ops-for-determining-current-numa-node.patch modules-use-raw_cpu_write-for-initialization-of-per-cpu-refcount.patch net-replace-__this_cpu_inc-in-routec-with-raw_cpu_inc.patch percpu-add-preemption-checks-to-__this_cpu-ops.patch OK? > The rest are bits and pieces that may require some detail work. It looks like they will need quite a lot of work I'm afraid. The automated sweep wasn't very successful but it did demonstrate that there are nasties and gremlins all over the place. -- 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 akpm tree
On Thu, 6 Mar 2014, Andrew Morton wrote: > > So, by "the whole series" do you mean just/all these: > > > > percpu-add-raw_cpu_ops.patch > > ... > > sh-replace-__get_cpu_var-uses.patch > > Yep. Commented out in http://ozlabs.org/~akpm/mmots/series > > > If so, I will remove them from my tree today (if you don't get around to > > a new mmotm before then). > > Cool. I need at least the initial 5 patches that establish the framework in -next and do the debugging in order to make further progress on this one. The rest are bits and pieces that may require some detail work. -- 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 akpm tree
On Thu, 6 Mar 2014, Stephen Rothwell wrote: > > I have reverted that commit for today. > > I suspect that this whole series may need more review and work. Toss the bits that do not build for now. These can then be handled in individual patches since the overall framework is present. -- 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 akpm tree
On Fri, 7 Mar 2014 11:57:44 +1100 Stephen Rothwell wrote: > Hi Andrew, > > On Thu, 6 Mar 2014 13:48:48 -0800 Andrew Morton > wrote: > > > > Yes, I've disabled the whole series for now. Some of these errors > > appear to be caused by compiler mishandling, so it's going to be > > difficult :( > > So, by "the whole series" do you mean just/all these: > > percpu-add-raw_cpu_ops.patch > ... > sh-replace-__get_cpu_var-uses.patch Yep. Commented out in http://ozlabs.org/~akpm/mmots/series > If so, I will remove them from my tree today (if you don't get around to > a new mmotm before then). Cool. -- 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 akpm tree
Hi Andrew, On Thu, 6 Mar 2014 13:48:48 -0800 Andrew Morton wrote: > > Yes, I've disabled the whole series for now. Some of these errors > appear to be caused by compiler mishandling, so it's going to be > difficult :( So, by "the whole series" do you mean just/all these: percpu-add-raw_cpu_ops.patch mm-use-raw_cpu-ops-for-determining-current-numa-node.patch modules-use-raw_cpu_write-for-initialization-of-per-cpu-refcount.patch net-replace-__this_cpu_inc-in-routec-with-raw_cpu_inc.patch percpu-add-preemption-checks-to-__this_cpu-ops.patch mm-replace-__get_cpu_var-uses-with-this_cpu_ptr.patch tracing-replace-__get_cpu_var-uses-with-this_cpu_ptr.patch percpu-replace-__get_cpu_var-with-this_cpu_ptr.patch kernel-misc-replace-__get_cpu_var-uses.patch drivers-char-random-replace-__get_cpu_var-uses.patch drivers-cpuidle-replace-__get_cpu_var-uses-for-address-calculation.patch drivers-oprofile-replace-__get_cpu_var-uses-for-address-calculation.patch drivers-leds-replace-__get_cpu_var-use-through-this_cpu_ptr.patch drivers-clocksource-replace-__get_cpu_var-used-for-address-calculation.patch parisc-replace-__get_cpu_var-uses-for-address-calculation.patch metag-replace-__get_cpu_var-uses-for-address-calculation.patch drivers-net-ethernet-tile-replace-__get_cpu_var-uses-for-address-calculation.patch drivers-net-ethernet-tile-__get_cpu_var-call-introduced-in-314.patch tilegx-another-case-of-get_cpu_var.patch time-replace-__get_cpu_var-uses.patch scheduler-replace-__get_cpu_var-with-this_cpu_ptr.patch tick-sched-fix-two-new-uses-of-__get_cpu_ptr.patch block-replace-__this_cpu_ptr-with-raw_cpu_ptr.patch rcu-replace-__this_cpu_ptr-uses-with-raw_cpu_ptr.patch watchdog-replace-__raw_get_cpu_var-uses.patch net-replace-get_cpu_var-through-this_cpu_ptr.patch md-replace-__this_cpu_ptr-with-raw_cpu_ptr.patch irqchips-replace-__this_cpu_ptr-uses.patch x86-replace-__get_cpu_var-uses.patch x86-change-__get_cpu_var-calls-introduced-in-314.patch arm-replace-__this_cpu_ptr-with-raw_cpu_ptr.patch mips-replace-__get_cpu_var-uses-in-fpu-emulator.patch mips-replace-__get_cpu_var-uses.patch s390-rename-__this_cpu_ptr-to-raw_cpu_ptr.patch s390-replace-__get_cpu_var-uses.patch s390-handle-new-__get_cpu_var-calls-added-in-314.patch ia64-replace-__get_cpu_var-uses.patch powerpc-replace-__get_cpu_var-uses.patch powerpc-handle-new-__get_cpu_var-calls-in-314.patch sparc-replace-__get_cpu_var-uses.patch tile-replace-__get_cpu_var-uses.patch blackfin-replace-__get_cpu_var-uses.patch avr32-replace-__get_cpu_var-with-__this_cpu_write.patch alpha-replace-__get_cpu_var.patch alpha-replace-__get_cpu_var-fix.patch sh-replace-__get_cpu_var-uses.patch If so, I will remove them from my tree today (if you don't get around to a new mmotm before then). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpLf5vDcSgZi.pgp Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
On Thu, 6 Mar 2014 19:22:34 +1100 Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> arch/sparc/kernel/time_64.c: In function 'timer_interrupt':
> arch/sparc/kernel/time_64.c:735:28: error: lvalue required as increment
> operand
> arch/sparc/kernel/traps_64.c: In function '__cheetah_flush_icache':
> arch/sparc/kernel/traps_64.c:963:2: error: 'pscr_ret__.icache_size' is used
> uninitialized in this function [-Werror=uninitialized]
> arch/sparc/kernel/traps_64.c: In function 'cheetah_flush_dcache':
> arch/sparc/kernel/traps_64.c:1002:2: error: 'pscr_ret__.dcache_size' is used
> uninitialized in this function [-Werror=uninitialized]
> arch/sparc/kernel/traps_64.c: In function 'cheetah_plus_parity_error':
> arch/sparc/kernel/traps_64.c:1023:2: error: 'pscr_ret__.dcache_size' may be
> used uninitialized in this function [-Werror=uninitialized]
> arch/sparc/kernel/traps_64.c:1020:16: note: 'pscr_ret__.dcache_size' was
> declared here
> arch/sparc/kernel/traps_64.c:1033:33: error: 'pscr_ret__.dcache_line_size'
> may be used uninitialized in this function [-Werror=uninitialized]
> arch/sparc/kernel/traps_64.c:1021:21: note: 'pscr_ret__.dcache_line_size' was
> declared here
> cc1: all warnings being treated as errors
> kernel/softirq.c: In function '__do_softirq':
> kernel/softirq.c:252:1: error: lvalue required as left operand of assignment
> kernel/softirq.c: In function '__raise_softirq_irqoff':
> kernel/softirq.c:427:1: error: lvalue required as left operand of assignment
> arch/sparc/kernel/ptrace_64.c: In function 'flush_ptrace_access':
> arch/sparc/kernel/ptrace_64.c:91:20: error: 'pscr_ret__.dcache_line_size' may
> be used uninitialized in this function [-Werror=uninitialized]
> arch/sparc/kernel/ptrace_64.c:113:20: error: 'pscr_ret__.icache_line_size'
> may be used uninitialized in this function [-Werror=uninitialized]
>
> Caused by commit 5aa661aa13d4 ("sparc: replace __get_cpu_var uses").
>
> I have reverted that commit for today.
>
> I suspect that this whole series may need more review and work.
Yes, I've disabled the whole series for now. Some of these errors
appear to be caused by compiler mishandling, so it's going to be
difficult :(
--
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 akpm tree
On Wed, Sep 25, 2013 at 02:43:28PM -0700, Andrew Morton wrote: > On Wed, 25 Sep 2013 14:32:14 -0700 (PDT) Hugh Dickins > wrote: > > > On Wed, 25 Sep 2013, Andrew Morton wrote: > > > On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell > > > wrote: > > > > Hi Andrew, > > > > > > > > After merging the akpm tree, linux-next builds (powerpc allmodconfig) > > > > fail like this: > > > > > > I can't get powerpc to build at all at present: > > > > > > CHK include/config/kernel.release > > > CHK include/generated/uapi/linux/version.h > > > CHK include/generated/utsrelease.h > > > CC arch/powerpc/kernel/asm-offsets.s > > > In file included from include/linux/vtime.h:6, > > > from include/linux/hardirq.h:7, > > > from include/linux/memcontrol.h:24, > > > from include/linux/swap.h:8, > > > from include/linux/suspend.h:4, > > > from arch/powerpc/kernel/asm-offsets.c:24: > > > arch/powerpc/include/generated/asm/vtime.h:1:31: error: > > > asm-generic/vtime.h: No such file or directory > > > > That caught me too: include/asm-generic/vtime.h is a patch-unfriendly > > 0-length file in the git tree; > > hm, this? > > > From: Andrew Morton > Subject: include/asm-generic/vtime.h: avoid zero-length file > > patch(1) can't handle zero-length files - it appears to simply not create > the file, so my powerpc build fails. > > Put something in here to make life easier. > > Cc: Hugh Dickins > Signed-off-by: Andrew Morton > --- > > include/asm-generic/vtime.h |1 + > 1 file changed, 1 insertion(+) > > diff -puN /dev/null include/asm-generic/vtime.h > --- /dev/null > +++ a/include/asm-generic/vtime.h > @@ -0,0 +1 @@ > +/* no content, but patch(1) dislikes empty files */ > _ > > > > > I wonder what use it's supposed to have. > > Frederic, can you please confirm that include/asm-generic/vtime.h is > supposed to be empty? Yep. I use to let archs override some CPP symbols. And if they don't override these, they simply return the generic vtime.h file that is empty and as such doesn't override anything. May be that's an ugly way to handle this kind of override scenario but I couldn't find a better mechanism. Actually, a Kconfig symbol would do the trick. It just seemed to me like an overkill at that time. But it may be better. Thanks. > > > (And I'm not very keen on the growing trend for symlinks in the git tree.) > > ooh, that explains why I lost my arch/microblaze/boot/dts/system.dts. -- 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 akpm tree
On Wed, 25 Sep 2013 14:32:14 -0700 (PDT) Hugh Dickins wrote: > On Wed, 25 Sep 2013, Andrew Morton wrote: > > On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell > > wrote: > > > Hi Andrew, > > > > > > After merging the akpm tree, linux-next builds (powerpc allmodconfig) > > > fail like this: > > > > I can't get powerpc to build at all at present: > > > > CHK include/config/kernel.release > > CHK include/generated/uapi/linux/version.h > > CHK include/generated/utsrelease.h > > CC arch/powerpc/kernel/asm-offsets.s > > In file included from include/linux/vtime.h:6, > > from include/linux/hardirq.h:7, > > from include/linux/memcontrol.h:24, > > from include/linux/swap.h:8, > > from include/linux/suspend.h:4, > > from arch/powerpc/kernel/asm-offsets.c:24: > > arch/powerpc/include/generated/asm/vtime.h:1:31: error: > > asm-generic/vtime.h: No such file or directory > > That caught me too: include/asm-generic/vtime.h is a patch-unfriendly > 0-length file in the git tree; hm, this? From: Andrew Morton Subject: include/asm-generic/vtime.h: avoid zero-length file patch(1) can't handle zero-length files - it appears to simply not create the file, so my powerpc build fails. Put something in here to make life easier. Cc: Hugh Dickins Signed-off-by: Andrew Morton --- include/asm-generic/vtime.h |1 + 1 file changed, 1 insertion(+) diff -puN /dev/null include/asm-generic/vtime.h --- /dev/null +++ a/include/asm-generic/vtime.h @@ -0,0 +1 @@ +/* no content, but patch(1) dislikes empty files */ _ > I wonder what use it's supposed to have. Frederic, can you please confirm that include/asm-generic/vtime.h is supposed to be empty? > (And I'm not very keen on the growing trend for symlinks in the git tree.) ooh, that explains why I lost my arch/microblaze/boot/dts/system.dts. -- 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 akpm tree
On Wed, 25 Sep 2013, Andrew Morton wrote: > On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell > wrote: > > Hi Andrew, > > > > After merging the akpm tree, linux-next builds (powerpc allmodconfig) > > fail like this: > > I can't get powerpc to build at all at present: > > CHK include/config/kernel.release > CHK include/generated/uapi/linux/version.h > CHK include/generated/utsrelease.h > CC arch/powerpc/kernel/asm-offsets.s > In file included from include/linux/vtime.h:6, > from include/linux/hardirq.h:7, > from include/linux/memcontrol.h:24, > from include/linux/swap.h:8, > from include/linux/suspend.h:4, > from arch/powerpc/kernel/asm-offsets.c:24: > arch/powerpc/include/generated/asm/vtime.h:1:31: error: asm-generic/vtime.h: > No such file or directory That caught me too: include/asm-generic/vtime.h is a patch-unfriendly 0-length file in the git tree; I wonder what use it's supposed to have. (And I'm not very keen on the growing trend for symlinks in the git tree.) Hugh -- 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 akpm tree
On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm tree, linux-next builds (powerpc allmodconfig)
> fail like this:
I can't get powerpc to build at all at present:
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CC arch/powerpc/kernel/asm-offsets.s
In file included from include/linux/vtime.h:6,
from include/linux/hardirq.h:7,
from include/linux/memcontrol.h:24,
from include/linux/swap.h:8,
from include/linux/suspend.h:4,
from arch/powerpc/kernel/asm-offsets.c:24:
arch/powerpc/include/generated/asm/vtime.h:1:31: error: asm-generic/vtime.h: No
such file or directory
> drivers/tty/ehv_bytechan.c:362:1: error: type defaults to 'int' in
> declaration of 'console_initcall' [-Werror=implicit-int]
>
> Caused by commit 0f01cf96c2d4 ("./Makefile: enable -Werror=implicit-int
> and -Werror=strict-prototypes by default") which has bee in linux-next
> since Aug 16. This commit exposed that fact that
> drivers/tty/ehv_bytechan.c can be built as a module, but has a
> console_initcall (which is not available to modules). This was
> originally introduced in commit dcd83aaff1c8 ("tty/powerpc: introduce the
> ePAPR embedded hypervisor byte channel driver") in v3.2.
>
> Anyone got a good solution?
console_initcall() is a macro defined in init.h. But we forgot to
provide a version for #ifdef MODULE.
At include/linux/init.h line 284 we see:
/* Don't use these in loadable modules, but some people do... */
#define early_initcall(fn) module_init(fn)
#define core_initcall(fn) module_init(fn)
...
So we *could* add console_initcall() there. But the problem is that it
won't work as desired - when the driver is loaded as a module,
ehv_bc_console_init() will be called at modprobe time, which is far far
later than console_initcall-time.
So the ehv_bytechan.c developers need to work out what they want to do
here. Do we disallow building that driver as a module? Or do we
permit that, and run ehv_bc_console_init() at modprobe time (needs
testing!).
If the latter then I'd be reluctant to add a modular version of
console_initcall() because the thing's very presence is misleading.
otoh, drivers which use such a console_initcall() _might_ work, and
everyone tests their drivers both built-in and as modules, don't they?
Don't they?
--
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 akpm tree
On Tue, Sep 24, 2013 at 8:06 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, linux-next builds (powerpc allmodconfig)
> fail like this:
>
> drivers/tty/ehv_bytechan.c:362:1: error: type defaults to 'int' in
> declaration of 'console_initcall' [-Werror=implicit-int]
>
> Caused by commit 0f01cf96c2d4 ("./Makefile: enable -Werror=implicit-int
> and -Werror=strict-prototypes by default") which has bee in linux-next
> since Aug 16. This commit exposed that fact that
> drivers/tty/ehv_bytechan.c can be built as a module, but has a
> console_initcall (which is not available to modules).
Is this something new? This code hasn't changed in over two years, so
I'm surprised it suddenly broke.
> This was
> originally introduced in commit dcd83aaff1c8 ("tty/powerpc: introduce the
> ePAPR embedded hypervisor byte channel driver") in v3.2.
>
> Anyone got a good solution?
How about:
#ifndef MODULE
static int __init ehv_bc_console_init(void)
{
...
}
console_initcall(ehv_bc_console_init);
#endif
--
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 akpm tree
On Fri, Jun 7, 2013 at 3:52 PM, Stephen Rothwell wrote:
> Hi,
>
> On Fri, 7 Jun 2013 15:26:56 +0800 Peng Tao wrote:
>>
>> On Fri, Jun 7, 2013 at 2:28 PM, Stephen Rothwell
>> wrote:
>> >
>> > After merging the akpm tree, today's linux-next build (x86_64
>> > allmodconfig) failed like this:
>> >
>> > In file included from
>> > drivers/staging/lustre/include/linux/libcfs/linux/libcfs.h:49:0,
>> > from
>> > drivers/staging/lustre/include/linux/libcfs/libcfs.h:44,
>> > from
>> > drivers/staging/lustre/include/linux/lnet/linux/lib-lnet.h:45,
>> > from
>> > drivers/staging/lustre/include/linux/lnet/lib-lnet.h:44,
>> > from drivers/staging/lustre/lnet/lnet/api-ni.c:38:
>> > drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h: In function
>> > 'set_shrinker':
>> > drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h:102:3:
>> > error: 'struct shrinker' has no member named 'shrink'
>> > s->shrink = func;
>> >^
>> >
>> > Caused by commit a37f14f05f2f ("shrinker: Kill old ->shrink API") from
>> > the akpm tree interacting with the new Lustre client code from the
>> > staging tree.
>> >
>> > I have just disabled the Lustre client code again (by reverting commit
>> > ee04fd11f11f ("Revert "Revert "staging/lustre: drop CONFIG_BROKEN
>> > dependency""")) and maybe someone can tell me what I need to do to fix
>> > this when I get back in a week.
>> I have a patchset to fix this but haven't yet sent out because it will
>> break build in Greg's staging tree. I can send it now but please tell
>> me to whom I should send the patches? Greg's tree doesn't contain
>> shrinker change, and mm- tree doesn't have Lustre code.
>
> The mm- tree now has the lustre code since it it based on most of
> linux-next, so send them to Andrew.
>
> It will then be up to Andrew and Greg to make sure that the staging tree
> is merged into Linus' tree before Andrew's patch bomb.
I see. Thanks. I will send them to Andrew then.
--
Thanks,
Tao
--
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 akpm tree
Hi,
On Fri, 7 Jun 2013 15:26:56 +0800 Peng Tao wrote:
>
> On Fri, Jun 7, 2013 at 2:28 PM, Stephen Rothwell
> wrote:
> >
> > After merging the akpm tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from
> > drivers/staging/lustre/include/linux/libcfs/linux/libcfs.h:49:0,
> > from
> > drivers/staging/lustre/include/linux/libcfs/libcfs.h:44,
> > from
> > drivers/staging/lustre/include/linux/lnet/linux/lib-lnet.h:45,
> > from
> > drivers/staging/lustre/include/linux/lnet/lib-lnet.h:44,
> > from drivers/staging/lustre/lnet/lnet/api-ni.c:38:
> > drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h: In function
> > 'set_shrinker':
> > drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h:102:3: error:
> > 'struct shrinker' has no member named 'shrink'
> > s->shrink = func;
> >^
> >
> > Caused by commit a37f14f05f2f ("shrinker: Kill old ->shrink API") from
> > the akpm tree interacting with the new Lustre client code from the
> > staging tree.
> >
> > I have just disabled the Lustre client code again (by reverting commit
> > ee04fd11f11f ("Revert "Revert "staging/lustre: drop CONFIG_BROKEN
> > dependency""")) and maybe someone can tell me what I need to do to fix
> > this when I get back in a week.
> I have a patchset to fix this but haven't yet sent out because it will
> break build in Greg's staging tree. I can send it now but please tell
> me to whom I should send the patches? Greg's tree doesn't contain
> shrinker change, and mm- tree doesn't have Lustre code.
The mm- tree now has the lustre code since it it based on most of
linux-next, so send them to Andrew.
It will then be up to Andrew and Greg to make sure that the staging tree
is merged into Linus' tree before Andrew's patch bomb.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpTTFgywDQvV.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
On Fri, Jun 7, 2013 at 2:28 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from
> drivers/staging/lustre/include/linux/libcfs/linux/libcfs.h:49:0,
> from drivers/staging/lustre/include/linux/libcfs/libcfs.h:44,
> from
> drivers/staging/lustre/include/linux/lnet/linux/lib-lnet.h:45,
> from drivers/staging/lustre/include/linux/lnet/lib-lnet.h:44,
> from drivers/staging/lustre/lnet/lnet/api-ni.c:38:
> drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h: In function
> 'set_shrinker':
> drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h:102:3: error:
> 'struct shrinker' has no member named 'shrink'
> s->shrink = func;
>^
>
> Caused by commit a37f14f05f2f ("shrinker: Kill old ->shrink API") from
> the akpm tree interacting with the new Lustre client code from the
> staging tree.
>
> I have just disabled the Lustre client code again (by reverting commit
> ee04fd11f11f ("Revert "Revert "staging/lustre: drop CONFIG_BROKEN
> dependency""")) and maybe someone can tell me what I need to do to fix
> this when I get back in a week.
I have a patchset to fix this but haven't yet sent out because it will
break build in Greg's staging tree. I can send it now but please tell
me to whom I should send the patches? Greg's tree doesn't contain
shrinker change, and mm- tree doesn't have Lustre code.
--
Thanks,
Tao
--
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 akpm tree
On 11/02/2013 09:13, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ethernet/mellanox/mlx4/en_rx.c: In function
> 'mlx4_en_process_rx_cq':
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:628:53: error: macro
> "hlist_for_each_entry_rcu" passed 4 arguments, but takes just 3
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:628:5: error:
> 'hlist_for_each_entry_rcu' undeclared (first use in this function)
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:628:55: error: expected ';' before
> '{' token
>
> Caused by commit c07cb4b0ab78 ("net/mlx4_en: Manage hash of MAC addresses
> per port") from the net-next tree interacting with commit "hlist: drop
> the node parameter from iterators" from the akpm tree.
>
> I applied the following merge fix patch for today:
>
> From 7a10f5e7e8d1232d618307d568ea9a78dc4680bb Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell
> Date: Mon, 11 Feb 2013 18:01:23 +1100
> Subject: [PATCH] net/mlx4_en: fix up for hlist_for_each_entry_rcu API change
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index ce38654..19a9c05 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -617,7 +617,6 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct
> mlx4_en_cq *cq, int bud
>
> if (is_multicast_ether_addr(ethh->h_dest)) {
> struct mlx4_mac_entry *entry;
> - struct hlist_node *n;
> struct hlist_head *bucket;
> unsigned int mac_hash;
>
> @@ -625,7 +624,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct
> mlx4_en_cq *cq, int bud
> mac_hash = ethh->h_source[MLX4_EN_MAC_HASH_IDX];
> bucket = &priv->mac_hash[mac_hash];
> rcu_read_lock();
> - hlist_for_each_entry_rcu(entry, n, bucket,
> hlist) {
> + hlist_for_each_entry_rcu(entry, bucket, hlist) {
> if (ether_addr_equal_64bits(entry->mac,
>
> ethh->h_source)) {
> rcu_read_unlock();
>
Acked-By: Amir Vadai
--
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 akpm tree
On Tue, Dec 18, 2012 at 01:29:07PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> mm/migrate.c: In function 'migrate_misplaced_transhuge_page':
> mm/migrate.c:1738:2: error: incompatible type for argument 3 of
> 'update_mmu_cache_pmd'
> arch/x86/include/asm/pgtable.h:792:20: note: expected 'struct pmd_t *' but
> argument is of type 'pmd_t'
>
> Caused by commit b32967ff101a ("mm: numa: Add THP migration for the NUMA
> working set scanning fault case") from Linus' tree interacting with
> commit "x86: convert update_mmu_cache() and update_mmu_cache_pmd() to
> functions".
>
> This was previously reported as against the tip tree, but the fix patch
> (which was applied to the tip tree) did not survive the rewrite that went
> into Linus' tree. Just a little annoyed :-(
>
Sorry about that Stephen, I should have caught the fix in the tip tree
and picked it up. Thanks for fixing it a second time.
--
Mel Gorman
SUSE Labs
--
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 akpm tree
* Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> mm/migrate.c: In function 'migrate_misplaced_transhuge_page_put':
> mm/migrate.c:1666:2: error: incompatible type for argument 3 of
> 'update_mmu_cache_pmd'
> arch/x86/include/asm/pgtable.h:792:20: note: expected 'struct pmd_t *' but
> argument is of type 'pmd_t'
>
> Caused by commit 7f7f03ce3820 ("mm, numa: Implement migrate-on-fault lazy
> NUMA strategy for regular and THP pages") from the tip tree and expose by
> commit "x86: convert update_mmu_cache() and update_mmu_cache_pmd() to
> functions" from the akpm tree.
>
> I applied the following patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 10 Dec 2012 19:50:57 +1100
> Subject: [PATCH] mm,numa: fix update_mmu_cache_pmd call
>
> Fixes this build error:
>
> mm/migrate.c: In function 'migrate_misplaced_transhuge_page_put':
> mm/migrate.c:1666:2: error: incompatible type for argument 3 of
> 'update_mmu_cache_pmd'
> arch/x86/include/asm/pgtable.h:792:20: note: expected 'struct pmd_t *' but
> argument is of type 'pmd_t'
>
> Signed-off-by: Stephen Rothwell
> ---
> mm/migrate.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 5be98e5..964a8c1 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1663,7 +1663,7 @@ int migrate_misplaced_transhuge_page_put(struct
> mm_struct *mm,
> page_add_new_anon_rmap(new_page, vma, haddr);
>
> set_pmd_at(mm, haddr, pmd, entry);
> - update_mmu_cache_pmd(vma, address, entry);
> + update_mmu_cache_pmd(vma, address, &entry);
> page_remove_rmap(page);
> /*
>* Finish the charge transaction under the page table lock to
I think the real bug is not in the akpm but in the -tip tree: we
copy & pasted a pre-existing buggy upstream place that also
called update_mmu_cache_pmd() with a pmd value, not by address.
akpm's patch fixed the original buggy place, but not our copy of
it.
Practically this does not truly matter at the moment as only
Sparc64 appears to be a real user of that function, and Sparc64
does not turn on the NUMA feature (yet) - but nevertheless the
change in akpm's tree which introduces correct typing for this
method exposed the latent bug.
I'll pick up your fix.
Thanks,
Ingo
--
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 akpm tree
On Wed, 24 Oct 2012 12:19:39 -0700 Joe Perches wrote: > On Tue, 2012-10-23 at 13:02 -0700, Andrew Morton wrote: > > On Tue, 23 Oct 2012 12:51:29 -0700 > > Joe Perches wrote: > > > > > > btw, what's up with printk_syslog.h? It includes two header files > > > > which it > > > > doesn't need but fails to include the two it *does* need: printk_log.h > > > > and types.h. > > > > > > > > > > > > > > printk_syslog.c includes kernel.h (it includes types.h) > > > and printk_log.h. > > > > > > I think printk_syslog.h doesn't need printk_log.h > > > > A general rule is that the header file shouldn't know or care what else > > it's includer has included. Ideally it shouldn't know or care what > > else its includees have included, either. > > > > A fun test would be > > > > for i in *.h > > echo $i > foo.c > > make foo.o > > done > > A whole lot of things in include/ fail this. I bet. > Do you really think that anything using u8/16/32/64 > should include types.h? Well, yes. If someone writes a C file which includes such a header as fisst-included then OK, it will fail and they'll fix things up. But where the problems occur is when that file is *not* the first-included, but they happened to get types.h via another Kconfig-dependent include. Later, the build explodes for someone else. The only reliable way of avoiding this is for each file to include its dependencies. I don't think it's worth going off and trying to "fix" all of this though. Such an exercise has its own risks and this problem just isn't that big - it happens often enough, but it's very easy to fix. -- 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 akpm tree
On Tue, 2012-10-23 at 13:02 -0700, Andrew Morton wrote: > On Tue, 23 Oct 2012 12:51:29 -0700 > Joe Perches wrote: > > > > btw, what's up with printk_syslog.h? It includes two header files which > > > it > > > doesn't need but fails to include the two it *does* need: printk_log.h > > > and types.h. > > > > > > > > > > printk_syslog.c includes kernel.h (it includes types.h) > > and printk_log.h. > > > > I think printk_syslog.h doesn't need printk_log.h > > A general rule is that the header file shouldn't know or care what else > it's includer has included. Ideally it shouldn't know or care what > else its includees have included, either. > > A fun test would be > > for i in *.h > echo $i > foo.c > make foo.o > done A whole lot of things in include/ fail this. Do you really think that anything using u8/16/32/64 should include types.h? -- 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 akpm tree
On Tue, 23 Oct 2012 12:51:29 -0700 Joe Perches wrote: > > btw, what's up with printk_syslog.h? It includes two header files which it > > doesn't need but fails to include the two it *does* need: printk_log.h > > and types.h. > > > > > > printk_syslog.c includes kernel.h (it includes types.h) > and printk_log.h. > > I think printk_syslog.h doesn't need printk_log.h A general rule is that the header file shouldn't know or care what else it's includer has included. Ideally it shouldn't know or care what else its includees have included, either. A fun test would be for i in *.h echo $i > foo.c make foo.o done -- 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 akpm tree
On Tue, 2012-10-23 at 12:44 -0700, Andrew Morton wrote:
> On Tue, 23 Oct 2012 14:42:21 +1100
> Stephen Rothwell wrote:
>
> > Hi Andrew,
> >
> > After merging the akpm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > kernel/printk/printk_syslog.c: In function 'printk_syslog_print':
> > kernel/printk/printk_syslog.c:108:3: error: implicit declaration of
> > function 'copy_to_user' [-Werror=implicit-function-declaration]
> > kernel/printk/printk_syslog.c: In function 'do_syslog':
> > kernel/printk/printk_syslog.c:245:3: error: implicit declaration of
> > function 'access_ok' [-Werror=implicit-function-declaration]
> > kernel/printk/printk_syslog.c:245:18: error: 'VERIFY_WRITE' undeclared
> > (first use in this function)
> > kernel/printk/printk_syslog.c:245:18: note: each undeclared identifier is
> > reported only once for each function it appears in
> >
> > Caused by commit 598815e5f25f ("printk: add printk_syslog.c and .h").
> >
> > Presumably missing an (or some) include files - see Rule 1 in
> > Documentation/SubmitChecklist.
> >
> > I have reverted that commit for today (and the following commit
> > 2cf91e0e4b9f ("printk: move kmsg_dump functions to separate file")).
>
> I'll add the include.
>
> btw, what's up with printk_syslog.h? It includes two header files which it
> doesn't need but fails to include the two it *does* need: printk_log.h
> and types.h.
>
>
printk_syslog.c includes kernel.h (it includes types.h)
and printk_log.h.
I think printk_syslog.h doesn't need printk_log.h
I'd appreciate being cc'd.
There's also a needed fix for braille
and a duplicate #define.
I'll resubmit the whole series tomorrow.
cheers, Joe
--
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 akpm tree
On Tue, 23 Oct 2012 14:42:21 +1100
Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> kernel/printk/printk_syslog.c: In function 'printk_syslog_print':
> kernel/printk/printk_syslog.c:108:3: error: implicit declaration of function
> 'copy_to_user' [-Werror=implicit-function-declaration]
> kernel/printk/printk_syslog.c: In function 'do_syslog':
> kernel/printk/printk_syslog.c:245:3: error: implicit declaration of function
> 'access_ok' [-Werror=implicit-function-declaration]
> kernel/printk/printk_syslog.c:245:18: error: 'VERIFY_WRITE' undeclared (first
> use in this function)
> kernel/printk/printk_syslog.c:245:18: note: each undeclared identifier is
> reported only once for each function it appears in
>
> Caused by commit 598815e5f25f ("printk: add printk_syslog.c and .h").
>
> Presumably missing an (or some) include files - see Rule 1 in
> Documentation/SubmitChecklist.
>
> I have reverted that commit for today (and the following commit
> 2cf91e0e4b9f ("printk: move kmsg_dump functions to separate file")).
I'll add the include.
btw, what's up with printk_syslog.h? It includes two header files which it
doesn't need but fails to include the two it *does* need: printk_log.h
and types.h.
--
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 akpm tree
On Tue, 2012-10-23 at 14:42 +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> kernel/printk/printk_syslog.c: In function 'printk_syslog_print':
> kernel/printk/printk_syslog.c:108:3: error: implicit declaration of function
> 'copy_to_user' [-Werror=implicit-function-declaration]
> kernel/printk/printk_syslog.c: In function 'do_syslog':
> kernel/printk/printk_syslog.c:245:3: error: implicit declaration of function
> 'access_ok' [-Werror=implicit-function-declaration]
> kernel/printk/printk_syslog.c:245:18: error: 'VERIFY_WRITE' undeclared (first
> use in this function)
> kernel/printk/printk_syslog.c:245:18: note: each undeclared identifier is
> reported only once for each function it appears in
>
> Caused by commit 598815e5f25f ("printk: add printk_syslog.c and .h").
>
> Presumably missing an (or some) include files - see Rule 1 in
> Documentation/SubmitChecklist.
Yup, missing at least which x86 gets
via an arch specific include.
I compiled it only x86.
I'll resubmit that one.
--
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 akpm tree
On Fri, 28 Sep 2012 11:19:29 -0400 (EDT)
Mikulas Patocka wrote:
> > - if (!prio_tree_empty(&mapping->i_mmap) ||
> > + if (!RB_EMPTY_ROOT(&mapping->i_mmap) ||
> > !list_empty(&mapping->i_mmap_nonlinear)) {
> > mutex_unlock(&mapping->i_mmap_mutex);
> > percpu_up_write(&bdev->bd_block_size_semaphore);
> > --
> > 1.7.10.280.gaa39
> >
> > --
> > Cheers,
> > Stephen Rothwells...@canb.auug.org.au
>
> ... or replace it with
>
> if (mapping_mapped(&mapping)) { ...
yup..
From: Andrew Morton
Subject: fs/block_dev.c:set_blocksize(): use mapping_mapped()
... instead of open-coding it.
Suggested-by: Mikulas Patocka
Cc: Stephen Rothwell
Signed-off-by: Andrew Morton
---
fs/block_dev.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -puN fs/block_dev.c~fs-block_devc-set_blocksize-use-mapping_mapped
fs/block_dev.c
--- a/fs/block_dev.c~fs-block_devc-set_blocksize-use-mapping_mapped
+++ a/fs/block_dev.c
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
#include "internal.h"
@@ -133,8 +132,7 @@ int set_blocksize(struct block_device *b
/* Check that the block device is not memory mapped */
mapping = bdev->bd_inode->i_mapping;
mutex_lock(&mapping->i_mmap_mutex);
- if (!RB_EMPTY_ROOT(&mapping->i_mmap) ||
- !list_empty(&mapping->i_mmap_nonlinear)) {
+ if (mapping_mapped(mapping)) {
mutex_unlock(&mapping->i_mmap_mutex);
percpu_up_write(&bdev->bd_block_size_semaphore);
return -EBUSY;
_
--
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 akpm tree
On Fri, 28 Sep 2012, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/block_dev.c: In function 'set_blocksize':
> fs/block_dev.c:135:2: error: implicit declaration of function
> 'prio_tree_empty' [-Werror=implicit-function-declaration]
>
> Caused by commit b87570f5d349 ("Fix a crash when block device is read and
> block size is changed at the same time") from the block tree interacting
> with commit "prio_tree: remove" from the akpm tree.
>
> I added the following merge fix patch for today.
>
> From: Stephen Rothwell
> Date: Fri, 28 Sep 2012 16:21:10 +1000
> Subject: [PATCH] prio_tree: fix fs/block_dev.c for removal of prio_tree
>
> Signed-off-by: Stephen Rothwell
> ---
> fs/block_dev.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index 246a81e..165b01f 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "internal.h"
>
> @@ -132,7 +133,7 @@ int set_blocksize(struct block_device *bdev, int size)
> /* Check that the block device is not memory mapped */
> mapping = bdev->bd_inode->i_mapping;
> mutex_lock(&mapping->i_mmap_mutex);
> - if (!prio_tree_empty(&mapping->i_mmap) ||
> + if (!RB_EMPTY_ROOT(&mapping->i_mmap) ||
> !list_empty(&mapping->i_mmap_nonlinear)) {
> mutex_unlock(&mapping->i_mmap_mutex);
> percpu_up_write(&bdev->bd_block_size_semaphore);
> --
> 1.7.10.280.gaa39
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
... or replace it with
if (mapping_mapped(&mapping)) { ...
Mikulas
--
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 akpm tree
Hi Andrew, On Wed, 26 Sep 2012 13:33:35 -0700 Andrew Morton wrote: > > On Wed, 26 Sep 2012 13:15:58 -0700 > Kees Cook wrote: > > > This is weird -- my original patch doesn't touch audit_get_sessionid() at > > all: > > http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=commitdiff;h=7bbfec58ed33d5e74043530b87992f16da718ba2 > > That patch has been broken multiple times as things change under its > feet. I've just repaired my most recent attempt to repair it. > > > From: Kees Cook > Subject: audit.h: replace defines with C stubs > > Replace the #defines used when CONFIG_AUDIT or CONFIG_AUDIT_SYSCALLS are > disabled so we get type checking during those builds. > > Suggested-by: Andrew Morton > Signed-off-by: Kees Cook > Cc: Al Viro > Signed-off-by: Andrew Morton OK, so I replaced the old version of this patch in the akpm tree in linux-next with this one (with the kuid_t patch mashed in). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpyNXdQ2WxwE.pgp Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
On Wed, 26 Sep 2012 13:42:05 -0700
Kees Cook wrote:
> > +static inline int audit_get_loginuid(struct task_struct *tsk)
>
> Shouldn't this return kuid_t, due to "userns: Convert the audit
> loginuid to be a kuid"?
yup, thanks.
--- a/include/linux/audit.h~audith-replace-defines-with-c-stubs-fix
+++ a/include/linux/audit.h
@@ -530,7 +530,7 @@ extern int auditsc_get_stamp(struct audi
struct timespec *t, unsigned int *serial);
extern int audit_set_loginuid(kuid_t loginuid);
-static inline int audit_get_loginuid(struct task_struct *tsk)
+static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
{
return tsk->loginuid
}
@@ -677,7 +677,7 @@ static inline int auditsc_get_stamp(stru
{
return 0;
}
-static inline int audit_get_loginuid(struct task_struct *tsk)
+static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
{
return INVALID_UID;
}
_
--
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 akpm tree
Hi,
Thanks! This almost matched what I was preparing. Notes below...
On Wed, Sep 26, 2012 at 1:33 PM, Andrew Morton
wrote:
> On Wed, 26 Sep 2012 13:15:58 -0700
> Kees Cook wrote:
>
>> This is weird -- my original patch doesn't touch audit_get_sessionid() at
>> all:
>> http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=commitdiff;h=7bbfec58ed33d5e74043530b87992f16da718ba2
>
> That patch has been broken multiple times as things change under its
> feet. I've just repaired my most recent attempt to repair it.
>
>
> From: Kees Cook
> Subject: audit.h: replace defines with C stubs
>
> Replace the #defines used when CONFIG_AUDIT or CONFIG_AUDIT_SYSCALLS are
> disabled so we get type checking during those builds.
>
> Suggested-by: Andrew Morton
> Signed-off-by: Kees Cook
> Cc: Al Viro
> Signed-off-by: Andrew Morton
> ---
>
> include/linux/audit.h | 206 +---
> 1 file changed, 153 insertions(+), 53 deletions(-)
>
> diff -puN include/linux/audit.h~audith-replace-defines-with-c-stubs
> include/linux/audit.h
> --- a/include/linux/audit.h~audith-replace-defines-with-c-stubs
> +++ a/include/linux/audit.h
> @@ -528,9 +528,18 @@ static inline void audit_ptrace(struct t
> extern unsigned int audit_serial(void);
> extern int auditsc_get_stamp(struct audit_context *ctx,
> struct timespec *t, unsigned int *serial);
> -extern int audit_set_loginuid(kuid_t loginuid);
> -#define audit_get_loginuid(t) ((t)->loginuid)
> -#define audit_get_sessionid(t) ((t)->sessionid)
> +extern int audit_set_loginuid(kuid_t loginuid);
> +
> +static inline int audit_get_loginuid(struct task_struct *tsk)
Shouldn't this return kuid_t, due to "userns: Convert the audit
loginuid to be a kuid"?
> +{
> + return tsk->loginuid
> +}
> +
> +static inline int audit_get_sessionid(struct task_struct *tsk)
> +{
> + return tsk->sessionid;
> +}
> +
> extern void audit_log_task_context(struct audit_buffer *ab);
> extern void audit_log_task_info(struct audit_buffer *ab, struct task_struct
> *tsk);
> extern void __audit_ipc_obj(struct kern_ipc_perm *ipcp);
> @@ -627,38 +636,101 @@ static inline void audit_mmap_fd(int fd,
> extern int audit_n_rules;
> extern int audit_signals;
> #else /* CONFIG_AUDITSYSCALL */
> -#define audit_alloc(t) ({ 0; })
> -#define audit_free(t) do { ; } while (0)
> -#define audit_syscall_entry(ta,a,b,c,d,e) do { ; } while (0)
> -#define audit_syscall_exit(r) do { ; } while (0)
> -#define audit_dummy_context() 1
> -#define audit_getname(n) do { ; } while (0)
> -#define audit_putname(n) do { ; } while (0)
> -#define __audit_inode(n,d) do { ; } while (0)
> -#define __audit_inode_child(i,p) do { ; } while (0)
> -#define audit_inode(n,d) do { (void)(d); } while (0)
> -#define audit_inode_child(i,p) do { ; } while (0)
> -#define audit_core_dumps(i) do { ; } while (0)
> -#define audit_seccomp(i,s,c) do { ; } while (0)
> -#define auditsc_get_stamp(c,t,s) (0)
> -#define audit_get_loginuid(t) (INVALID_UID)
> -#define audit_get_sessionid(t) (-1)
> -#define audit_log_task_context(b) do { ; } while (0)
> -#define audit_log_task_info(b, t) do { ; } while (0)
> -#define audit_ipc_obj(i) ((void)0)
> -#define audit_ipc_set_perm(q,u,g,m) ((void)0)
> -#define audit_bprm(p) ({ 0; })
> -#define audit_socketcall(n,a) ((void)0)
> -#define audit_fd_pair(n,a) ((void)0)
> -#define audit_sockaddr(len, addr) ({ 0; })
> -#define audit_mq_open(o,m,a) ((void)0)
> -#define audit_mq_sendrecv(d,l,p,t) ((void)0)
> -#define audit_mq_notify(d,n) ((void)0)
> -#define audit_mq_getsetattr(d,s) ((void)0)
> -#define audit_log_bprm_fcaps(b, ncr, ocr) ({ 0; })
> -#define audit_log_capset(pid, ncr, ocr) ((void)0)
> -#define audit_mmap_fd(fd, flags) ((void)0)
> -#define audit_ptrace(t) ((void)0)
> +static inline int audit_alloc(struct task_struct *task)
> +{
> + return 0;
> +}
> +static inline void audit_free(struct task_struct *task)
> +{ }
> +static inline void audit_syscall_entry(int arch, int major, unsigned long a0,
> + unsigned long a1, unsigned long a2,
> + unsigned long a3)
> +{ }
> +static inline void audit_syscall_exit(void *pt_regs)
> +{ }
> +static inline int audit_dummy_context(void)
> +{
> + return 1;
> +}
> +static inline void audit_getname(const char *name)
> +{ }
> +static inline void audit_putname(const char *name)
> +{ }
> +static inline void __audit_inode(const char *name, const struct dentry
> *dentry)
> +{ }
> +static inline void __audit_inode_child(const struct dentry *dentry,
> + const struct inode *parent)
> +{ }
> +static inline void audit_inode(const char *name, const struct dentry *dentry)
> +{ }
> +static inline void audit_inode_child(const struct dentry *dentry,
> +const struct inode *parent)
> +{ }
> +static inline void audit_core_dumps(long signr)
> +{ }
> +static inline void __audit_secc
Re: linux-next: build failure after merge of the akpm tree
On Wed, 26 Sep 2012 13:15:58 -0700
Kees Cook wrote:
> This is weird -- my original patch doesn't touch audit_get_sessionid() at all:
> http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=commitdiff;h=7bbfec58ed33d5e74043530b87992f16da718ba2
That patch has been broken multiple times as things change under its
feet. I've just repaired my most recent attempt to repair it.
From: Kees Cook
Subject: audit.h: replace defines with C stubs
Replace the #defines used when CONFIG_AUDIT or CONFIG_AUDIT_SYSCALLS are
disabled so we get type checking during those builds.
Suggested-by: Andrew Morton
Signed-off-by: Kees Cook
Cc: Al Viro
Signed-off-by: Andrew Morton
---
include/linux/audit.h | 206 +---
1 file changed, 153 insertions(+), 53 deletions(-)
diff -puN include/linux/audit.h~audith-replace-defines-with-c-stubs
include/linux/audit.h
--- a/include/linux/audit.h~audith-replace-defines-with-c-stubs
+++ a/include/linux/audit.h
@@ -528,9 +528,18 @@ static inline void audit_ptrace(struct t
extern unsigned int audit_serial(void);
extern int auditsc_get_stamp(struct audit_context *ctx,
struct timespec *t, unsigned int *serial);
-extern int audit_set_loginuid(kuid_t loginuid);
-#define audit_get_loginuid(t) ((t)->loginuid)
-#define audit_get_sessionid(t) ((t)->sessionid)
+extern int audit_set_loginuid(kuid_t loginuid);
+
+static inline int audit_get_loginuid(struct task_struct *tsk)
+{
+ return tsk->loginuid
+}
+
+static inline int audit_get_sessionid(struct task_struct *tsk)
+{
+ return tsk->sessionid;
+}
+
extern void audit_log_task_context(struct audit_buffer *ab);
extern void audit_log_task_info(struct audit_buffer *ab, struct task_struct
*tsk);
extern void __audit_ipc_obj(struct kern_ipc_perm *ipcp);
@@ -627,38 +636,101 @@ static inline void audit_mmap_fd(int fd,
extern int audit_n_rules;
extern int audit_signals;
#else /* CONFIG_AUDITSYSCALL */
-#define audit_alloc(t) ({ 0; })
-#define audit_free(t) do { ; } while (0)
-#define audit_syscall_entry(ta,a,b,c,d,e) do { ; } while (0)
-#define audit_syscall_exit(r) do { ; } while (0)
-#define audit_dummy_context() 1
-#define audit_getname(n) do { ; } while (0)
-#define audit_putname(n) do { ; } while (0)
-#define __audit_inode(n,d) do { ; } while (0)
-#define __audit_inode_child(i,p) do { ; } while (0)
-#define audit_inode(n,d) do { (void)(d); } while (0)
-#define audit_inode_child(i,p) do { ; } while (0)
-#define audit_core_dumps(i) do { ; } while (0)
-#define audit_seccomp(i,s,c) do { ; } while (0)
-#define auditsc_get_stamp(c,t,s) (0)
-#define audit_get_loginuid(t) (INVALID_UID)
-#define audit_get_sessionid(t) (-1)
-#define audit_log_task_context(b) do { ; } while (0)
-#define audit_log_task_info(b, t) do { ; } while (0)
-#define audit_ipc_obj(i) ((void)0)
-#define audit_ipc_set_perm(q,u,g,m) ((void)0)
-#define audit_bprm(p) ({ 0; })
-#define audit_socketcall(n,a) ((void)0)
-#define audit_fd_pair(n,a) ((void)0)
-#define audit_sockaddr(len, addr) ({ 0; })
-#define audit_mq_open(o,m,a) ((void)0)
-#define audit_mq_sendrecv(d,l,p,t) ((void)0)
-#define audit_mq_notify(d,n) ((void)0)
-#define audit_mq_getsetattr(d,s) ((void)0)
-#define audit_log_bprm_fcaps(b, ncr, ocr) ({ 0; })
-#define audit_log_capset(pid, ncr, ocr) ((void)0)
-#define audit_mmap_fd(fd, flags) ((void)0)
-#define audit_ptrace(t) ((void)0)
+static inline int audit_alloc(struct task_struct *task)
+{
+ return 0;
+}
+static inline void audit_free(struct task_struct *task)
+{ }
+static inline void audit_syscall_entry(int arch, int major, unsigned long a0,
+ unsigned long a1, unsigned long a2,
+ unsigned long a3)
+{ }
+static inline void audit_syscall_exit(void *pt_regs)
+{ }
+static inline int audit_dummy_context(void)
+{
+ return 1;
+}
+static inline void audit_getname(const char *name)
+{ }
+static inline void audit_putname(const char *name)
+{ }
+static inline void __audit_inode(const char *name, const struct dentry *dentry)
+{ }
+static inline void __audit_inode_child(const struct dentry *dentry,
+ const struct inode *parent)
+{ }
+static inline void audit_inode(const char *name, const struct dentry *dentry)
+{ }
+static inline void audit_inode_child(const struct dentry *dentry,
+const struct inode *parent)
+{ }
+static inline void audit_core_dumps(long signr)
+{ }
+static inline void __audit_seccomp(unsigned long syscall, long signr, int code)
+{ }
+static inline void audit_seccomp(unsigned long syscall, long signr, int code)
+{ }
+static inline int auditsc_get_stamp(struct audit_context *ctx,
+ struct timespec *t, unsigned int *serial)
+{
+ return 0;
+}
+static inline int audit_get_loginuid(struct task_struct *tsk)
+{
+ return INVALID_UID;
+}
+static inline int audit_get_sessionid(struct task_struct *ts
Re: linux-next: build failure after merge of the akpm tree
Hi,
This is weird -- my original patch doesn't touch audit_get_sessionid() at all:
http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=commitdiff;h=7bbfec58ed33d5e74043530b87992f16da718ba2
The patch in linux-next (currently
e269b4131288512ebfe2adfe69042983cb2e69e5) got mangled to include
removing it, possibly triggered by the audit_get_loginuid() changes
("userns: Convert the audit loginuid to be a kuid"). These shouldn't
be removed:
#define audit_get_loginuid(t) (INVALID_UID)
#define audit_get_sessionid(t) (-1)
I'll send an updated patch that'll apply on top of what's in linux-next.
Thanks!
-Kees
On Tue, Sep 25, 2012 at 11:01 PM, Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/key/af_key.c: In function 'pfkey_add':
> net/key/af_key.c:1476:9: error: implicit declaration of function
> 'audit_get_sessionid' [-Werror=implicit-function-declaration]
> net/core/dev.c: In function '__dev_set_promiscuity':
> net/core/dev.c:4573:5: error: implicit declaration of function
> 'audit_get_sessionid' [-Werror=implicit-function-declaration]
>
> Caused by commit "audit.h: replace defines with C stubs".
>
> I have reverted that commit for today.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
Kees Cook
Chrome OS Security
--
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 akpm tree
Hi Roland,
I am on vacation until next Tuesday -- I'll look at this then.
-Jack
On Monday 24 September 2012 21:36, Roland Dreier wrote:
> On Mon, Sep 24, 2012 at 7:02 AM, Stephen Rothwell
> wrote:
> > After merging the akpm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/infiniband/hw/mlx4/cm.c: In function 'id_map_alloc':
> > drivers/infiniband/hw/mlx4/cm.c:228:36: error: 'MAX_ID_MASK' undeclared
> > (first use in this function)
> >
> > Caused by commit d7a4e9b679e9 ("IB/mlx4: Add CM paravirtualization") from
> > the infiniband tree interacting with commit "idr: rename MAX_LEVEL to
> > MAX_IDR_LEVEL" from the akpm tree.
> >
> > I have added the following merge fix patch for today:
> >
> > From: Stephen Rothwell
> > Date: Mon, 24 Sep 2012 23:57:53 +1000
> > Subject: [PATCH] IB/mlx4: fix for MAX_ID_MASK to MAX_IDR_MASK name change
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/infiniband/hw/mlx4/cm.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx4/cm.c
> > b/drivers/infiniband/hw/mlx4/cm.c
> > index e25e4da..80079e5 100644
> > --- a/drivers/infiniband/hw/mlx4/cm.c
> > +++ b/drivers/infiniband/hw/mlx4/cm.c
> > @@ -225,7 +225,7 @@ id_map_alloc(struct ib_device *ibdev, int slave_id, u32
> > sl_cm_id)
> > ret = idr_get_new_above(&sriov->pv_id_table, ent,
> > next_id, &id);
> > if (!ret) {
> > - next_id = ((unsigned) id + 1) & MAX_ID_MASK;
> > + next_id = ((unsigned) id + 1) & MAX_IDR_MASK;
> > ent->pv_cm_id = (u32)id;
> > sl_id_map_add(ibdev, ent);
> > }
>
> Andrew, any preference on how to handle this merge?
>
> Jack/Amir, I wonder if there's some way we can avoid this code
> entirely? Is an IDR the right structure to use here, or would we
> be better off with a radix tree maybe (where we can assign our
> own ID)?
>
> - R.
>
--
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 akpm tree
On Mon, 24 Sep 2012 12:36:43 -0700
Roland Dreier wrote:
> On Mon, Sep 24, 2012 at 7:02 AM, Stephen Rothwell
> wrote:
> > After merging the akpm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/infiniband/hw/mlx4/cm.c: In function 'id_map_alloc':
> > drivers/infiniband/hw/mlx4/cm.c:228:36: error: 'MAX_ID_MASK' undeclared
> > (first use in this function)
> >
> > Caused by commit d7a4e9b679e9 ("IB/mlx4: Add CM paravirtualization") from
> > the infiniband tree interacting with commit "idr: rename MAX_LEVEL to
> > MAX_IDR_LEVEL" from the akpm tree.
> >
> > I have added the following merge fix patch for today:
> >
> > From: Stephen Rothwell
> > Date: Mon, 24 Sep 2012 23:57:53 +1000
> > Subject: [PATCH] IB/mlx4: fix for MAX_ID_MASK to MAX_IDR_MASK name change
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/infiniband/hw/mlx4/cm.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx4/cm.c
> > b/drivers/infiniband/hw/mlx4/cm.c
> > index e25e4da..80079e5 100644
> > --- a/drivers/infiniband/hw/mlx4/cm.c
> > +++ b/drivers/infiniband/hw/mlx4/cm.c
> > @@ -225,7 +225,7 @@ id_map_alloc(struct ib_device *ibdev, int slave_id, u32
> > sl_cm_id)
> > ret = idr_get_new_above(&sriov->pv_id_table, ent,
> > next_id, &id);
> > if (!ret) {
> > - next_id = ((unsigned) id + 1) & MAX_ID_MASK;
> > + next_id = ((unsigned) id + 1) & MAX_IDR_MASK;
> > ent->pv_cm_id = (u32)id;
> > sl_id_map_add(ibdev, ent);
> > }
>
> Andrew, any preference on how to handle this merge?
I'm fixing up that patch as things change under its feet. I usually
merge things like this late in the merge window after everything else
has landed, to cause minimum breakage/disruption.
If there was something in linux-next which didn't get into the merge
window (bad) then I cheerily break it and the tree maintainer fixes
things up.
--
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 akpm tree
On Mon, Sep 24, 2012 at 7:02 AM, Stephen Rothwell wrote:
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/infiniband/hw/mlx4/cm.c: In function 'id_map_alloc':
> drivers/infiniband/hw/mlx4/cm.c:228:36: error: 'MAX_ID_MASK' undeclared
> (first use in this function)
>
> Caused by commit d7a4e9b679e9 ("IB/mlx4: Add CM paravirtualization") from
> the infiniband tree interacting with commit "idr: rename MAX_LEVEL to
> MAX_IDR_LEVEL" from the akpm tree.
>
> I have added the following merge fix patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 24 Sep 2012 23:57:53 +1000
> Subject: [PATCH] IB/mlx4: fix for MAX_ID_MASK to MAX_IDR_MASK name change
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/infiniband/hw/mlx4/cm.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/mlx4/cm.c b/drivers/infiniband/hw/mlx4/cm.c
> index e25e4da..80079e5 100644
> --- a/drivers/infiniband/hw/mlx4/cm.c
> +++ b/drivers/infiniband/hw/mlx4/cm.c
> @@ -225,7 +225,7 @@ id_map_alloc(struct ib_device *ibdev, int slave_id, u32
> sl_cm_id)
> ret = idr_get_new_above(&sriov->pv_id_table, ent,
> next_id, &id);
> if (!ret) {
> - next_id = ((unsigned) id + 1) & MAX_ID_MASK;
> + next_id = ((unsigned) id + 1) & MAX_IDR_MASK;
> ent->pv_cm_id = (u32)id;
> sl_id_map_add(ibdev, ent);
> }
Andrew, any preference on how to handle this merge?
Jack/Amir, I wonder if there's some way we can avoid this code
entirely? Is an IDR the right structure to use here, or would we
be better off with a radix tree maybe (where we can assign our
own ID)?
- R.
--
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 akpm tree
Hi Stephen, On Fri, Sep 21, 2012 at 8:26 AM, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > fs/compat_binfmt_elf.c:22:53: fatal error: asm/sigframe.h: No such file or > directory > > Caused by commit "coredump: add a new elf note with siginfo of the > signal". That include file only exists on the x86 and tile architectures. > > I have reverted that commit (and "coredump: extend core dump note section > to contain file names of mapped files" and > "coredump-extend-core-dump-note-section-to-contain-file-names-of-mapped-files-checkpatch-fixes" > that follow it) for today. Sorry about this. I will take a look at it. -- vda -- 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 akpm tree
Hi Andrew, On Thu, 13 Sep 2012 18:31:06 +1000 Stephen Rothwell wrote: > > Here is the chunk of the series file I have: > > idr-rename-max_level-to-max_idr_level.patch > idr-rename-max_level-to-max_idr_level-fix.patch > idr-rename-max_level-to-max_idr_level-fix-fix-2.patch > #NEXT_PATCHES_END > # > linux-next.patch > i-need-old-gcc.patch > idr-rename-max_level-to-max_idr_level-fix-3.patch > arch-alpha-kernel-systblss-remove-debug-check.patch > # > #NEXT_PATCHES_START linux-next-urgent > > So idr-rename-max_level-to-max_idr_level-fix-3.patch is excluded form > linux-next :-( I guess I need to just move that further down in the > series file? Though when you send the preceding three patches to Linus, > that fix-3 patch will be needed when I merge the thermal tree. I put idr-rename-max_level-to-max_idr_level-fix-3.patch into the akpm tree in linux-next (just after the -fix-2 patch). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpJIHtZTPUPc.pgp Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
Hi Zhang, On Thu, 13 Sep 2012 16:46:27 +0800 Zhang Rui wrote: > > I'm new as a git owner, so a stupid question here, > in this case, who should keep this fix? Do I need to do something when > sending pull request? Andrew will take care of it. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpr6h8xzSvhd.pgp Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
Hi, all,
On 四, 2012-09-13 at 17:44 +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/cpu_cooling.c: In function 'get_idr':
> drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK' undeclared (first
> use in this function)
>
> Caused by commit "idr: rename MAX_LEVEL to MAX_IDR_LEVEL" from the akpm
> tree interacting with commit 78edc7cdcf5e ("thermal: add generic cpufreq
> cooling implementation") from the thermal tree.
>
> I have applied the following merge fix patch and can carry it as
> necessary.
>
> From: Stephen Rothwell
> Date: Thu, 13 Sep 2012 17:42:11 +1000
> Subject: [PATCH] thermal: fix up for MAX_ID_MASK rename
>
> Signed-off-by: Stephen Rothwell
thanks for the fix.
I'm new as a git owner, so a stupid question here,
in this case, who should keep this fix? Do I need to do something when
sending pull request?
thanks,
rui
> ---
> drivers/thermal/cpu_cooling.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 99a5d75..f6ce617 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -9,7 +9,7 @@
> * it under the terms of the GNU General Public License as published by
> * the Free Software Foundation; version 2 of the License.
> *
> - * This program is distributed in the hope that it will be useful, but
> + * This program is distributed in the hope that it will be useful,
> butX_ID_MASK
> * WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> * General Public License for more details.
> @@ -86,7 +86,7 @@ again:
> else if (unlikely(err))
> return err;
>
> - *id = *id & MAX_ID_MASK;
> + *id = *id & MAX_IDR_MASK;
> return 0;
> }
>
> --
> 1.7.10.280.gaa39
>
--
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 akpm tree
Hi Sachin, On Thu, 13 Sep 2012 13:19:48 +0530 Sachin Kamat wrote: > > > - * This program is distributed in the hope that it will be useful, but > > + * This program is distributed in the hope that it will be useful, > > butX_ID_MASK > > ^ > Looks like a stray paste.. Yeah, thanks. I will sort it out tomorrow. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp5tSNSYA2Ck.pgp Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
Hi Andrew,
On Thu, 13 Sep 2012 00:56:57 -0700 Andrew Morton
wrote:
>
> On Thu, 13 Sep 2012 17:44:41 +1000 Stephen Rothwell
> wrote:
>
> > After merging the akpm tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/thermal/cpu_cooling.c: In function 'get_idr':
> > drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK' undeclared (first
> > use in this function)
> >
> > Caused by commit "idr: rename MAX_LEVEL to MAX_IDR_LEVEL" from the akpm
> > tree interacting with commit 78edc7cdcf5e ("thermal: add generic cpufreq
> > cooling implementation") from the thermal tree.
> >
> > I have applied the following merge fix patch and can carry it as
> > necessary.
> >
> > ...
> >
> > --- a/drivers/thermal/cpu_cooling.c
> > +++ b/drivers/thermal/cpu_cooling.c
> > @@ -9,7 +9,7 @@
> > * it under the terms of the GNU General Public License as published by
> > * the Free Software Foundation; version 2 of the License.
> > *
> > - * This program is distributed in the hope that it will be useful, but
> > + * This program is distributed in the hope that it will be useful,
> > butX_ID_MASK
> > * WITHOUT ANY WARRANTY; without even the implied warranty of
> > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > * General Public License for more details.
> > @@ -86,7 +86,7 @@ again:
> > else if (unlikely(err))
> > return err;
> >
> > - *id = *id & MAX_ID_MASK;
> > + *id = *id & MAX_IDR_MASK;
> > return 0;
> > }
>
> Confused.
> http://ozlabs.org/~akpm/mmotm/broken-out/idr-rename-max_level-to-max_idr_level-fix-3.patch
> already does this. How did that change get into the wrong place?
So, ignore the first hunk above, that was my typo.
Here is the chunk of the series file I have:
idr-rename-max_level-to-max_idr_level.patch
idr-rename-max_level-to-max_idr_level-fix.patch
idr-rename-max_level-to-max_idr_level-fix-fix-2.patch
#NEXT_PATCHES_END
#
linux-next.patch
i-need-old-gcc.patch
idr-rename-max_level-to-max_idr_level-fix-3.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
#
#NEXT_PATCHES_START linux-next-urgent
So idr-rename-max_level-to-max_idr_level-fix-3.patch is excluded form
linux-next :-( I guess I need to just move that further down in the
series file? Though when you send the preceding three patches to Linus,
that fix-3 patch will be needed when I merge the thermal tree.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp3YI464QNTp.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the akpm tree
On Thu, 13 Sep 2012 17:44:41 +1000 Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/cpu_cooling.c: In function 'get_idr':
> drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK' undeclared (first
> use in this function)
>
> Caused by commit "idr: rename MAX_LEVEL to MAX_IDR_LEVEL" from the akpm
> tree interacting with commit 78edc7cdcf5e ("thermal: add generic cpufreq
> cooling implementation") from the thermal tree.
>
> I have applied the following merge fix patch and can carry it as
> necessary.
>
> ...
>
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -9,7 +9,7 @@
> * it under the terms of the GNU General Public License as published by
> * the Free Software Foundation; version 2 of the License.
> *
> - * This program is distributed in the hope that it will be useful, but
> + * This program is distributed in the hope that it will be useful,
> butX_ID_MASK
> * WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> * General Public License for more details.
> @@ -86,7 +86,7 @@ again:
> else if (unlikely(err))
> return err;
>
> - *id = *id & MAX_ID_MASK;
> + *id = *id & MAX_IDR_MASK;
> return 0;
> }
Confused.
http://ozlabs.org/~akpm/mmotm/broken-out/idr-rename-max_level-to-max_idr_level-fix-3.patch
already does this. How did that change get into the wrong place?
--
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 akpm tree
On 13 September 2012 13:14, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/cpu_cooling.c: In function 'get_idr':
> drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK' undeclared (first
> use in this function)
>
> Caused by commit "idr: rename MAX_LEVEL to MAX_IDR_LEVEL" from the akpm
> tree interacting with commit 78edc7cdcf5e ("thermal: add generic cpufreq
> cooling implementation") from the thermal tree.
>
> I have applied the following merge fix patch and can carry it as
> necessary.
>
> From: Stephen Rothwell
> Date: Thu, 13 Sep 2012 17:42:11 +1000
> Subject: [PATCH] thermal: fix up for MAX_ID_MASK rename
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/thermal/cpu_cooling.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 99a5d75..f6ce617 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -9,7 +9,7 @@
> * it under the terms of the GNU General Public License as published by
> * the Free Software Foundation; version 2 of the License.
> *
> - * This program is distributed in the hope that it will be useful, but
> + * This program is distributed in the hope that it will be useful,
> butX_ID_MASK
^
Looks like a stray paste..
> * WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> * General Public License for more details.
> @@ -86,7 +86,7 @@ again:
> else if (unlikely(err))
> return err;
>
> - *id = *id & MAX_ID_MASK;
> + *id = *id & MAX_IDR_MASK;
> return 0;
> }
>
> --
> 1.7.10.280.gaa39
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
With warm regards,
Sachin
--
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 akpm tree
Hi, Thanks for the patch - I'd not realised that I'd used the wrong function there... it is fixed now in the GFS2 -nmw tree, Steve. On Sun, 2012-08-05 at 22:04 -0700, Michel Lespinasse wrote: > gfs2 calls RB_EMPTY_NODE() to check if nodes are not on an rbtree. > The corresponding initialization function is RB_CLEAR_NODE(). > rb_init_node() was never clearly defined and is going away. > > Signed-off-by: Michel Lespinasse > --- > fs/gfs2/rgrp.c |5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c > index eaa4188..675e7cc 100644 > --- a/fs/gfs2/rgrp.c > +++ b/fs/gfs2/rgrp.c > @@ -487,7 +487,7 @@ int gfs2_rs_alloc(struct gfs2_inode *ip) > if (!res) > error = -ENOMEM; > > - rb_init_node(&res->rs_node); > + RB_CLEAR_NODE(&res->rs_node); > > down_write(&ip->i_rw_mutex); > if (ip->i_res) > @@ -520,7 +520,7 @@ static void __rs_deltree(struct gfs2_inode *ip, struct > gfs2_blkreserv *rs) > rgd = rs->rs_rbm.rgd; > trace_gfs2_rs(ip, rs, TRACE_RS_TREEDEL); > rb_erase(&rs->rs_node, &rgd->rd_rstree); > - rb_init_node(&rs->rs_node); > + RB_CLEAR_NODE(&rs->rs_node); > BUG_ON(!rgd->rd_rs_cnt); > rgd->rd_rs_cnt--; > -- 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 akpm tree
gfs2 calls RB_EMPTY_NODE() to check if nodes are not on an rbtree. The corresponding initialization function is RB_CLEAR_NODE(). rb_init_node() was never clearly defined and is going away. Signed-off-by: Michel Lespinasse --- fs/gfs2/rgrp.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index eaa4188..675e7cc 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -487,7 +487,7 @@ int gfs2_rs_alloc(struct gfs2_inode *ip) if (!res) error = -ENOMEM; - rb_init_node(&res->rs_node); + RB_CLEAR_NODE(&res->rs_node); down_write(&ip->i_rw_mutex); if (ip->i_res) @@ -520,7 +520,7 @@ static void __rs_deltree(struct gfs2_inode *ip, struct gfs2_blkreserv *rs) rgd = rs->rs_rbm.rgd; trace_gfs2_rs(ip, rs, TRACE_RS_TREEDEL); rb_erase(&rs->rs_node, &rgd->rd_rstree); - rb_init_node(&rs->rs_node); + RB_CLEAR_NODE(&rs->rs_node); BUG_ON(!rgd->rd_rs_cnt); rgd->rd_rs_cnt--; -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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 akpm tree
On Sun, Aug 5, 2012 at 8:43 PM, Stephen Rothwell wrote:
> Caused by commit 5599fe1ab023 ("rbtree: empty nodes have no color") from
> the akpm tree interacting with commit cde7c325077b ("GFS2: Add structure
> to contain rgrp, bitmap, offset tuple") from the gfs2 tree.
>
> I have applied the following merge fix patch (which is probably not
> sufficient).
You are right that this is insufficient - gfs2 is using
RB_EMPTY_NODE() to check for nodes not being inserted on any rbtree,
so it must use RB_CLEAR_NODE() for initialization.
Will attach a patch as a reply to this.
I am surprised how fast these rb_init_node() calls are spreading.
Should I send Linus a patch removing that function so he could include
it in v3.6 and avoid having to deal with all these new uses ?
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
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 akpm tree
On Mon, Jul 30, 2012 at 9:40 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> net/ceph/osd_client.c: In function 'ceph_osdc_alloc_request':
> net/ceph/osd_client.c:216:2: error: implicit declaration of function
> 'rb_init_node' [-Werror=implicit-function-declaration]
>
> Caused by commit 753b960e52b7 ("rbtree: empty nodes have no color") from
> the akpm tree interacting with commit cd43045c2de6 ("libceph: initialize
> rb, list nodes in ceph_osd_request") from the ceph tree.
>
> I added the following merge fix patch for today:
>
> From: Stephen Rothwell
> Date: Tue, 31 Jul 2012 14:37:35 +1000
> Subject: [PATCH] libceph: remove rb_node initialisation
>
> Signed-off-by: Stephen Rothwell
Reviewed-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
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/
