Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: build failure after merge of the kspp tree
@ 2020-06-21 13:48 Stephen Rothwell
  2020-06-21 15:36 ` Kees Cook
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Rothwell @ 2020-06-21 13:48 UTC (permalink / raw)
  To: Kees Cook
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Sargun Dhillon


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

Hi all,

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

x86_64-linux-gnu-ld: fs/file.o: in function `__fd_install_received':
file.c:(.text+0x1010): undefined reference to `sock_from_file'
x86_64-linux-gnu-ld: file.c:(.text+0x104a): undefined reference to `sock_from_file'

Caused by commit

  d3868eea5cbc ("fs: Move __scm_install_fd() to __fd_install_received()")

I reverted these commits for today (from the breaking commit to the end
of the branch):

b29bb87cbb0a selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD
af35c3c6a9a5 seccomp: Introduce addfd ioctl to seccomp user notifier
50ca89d3a4fb fs: Expand __fd_install_received() to accept fd
f533d1758f02 pidfd: Replace open-coded partial fd_install_received()
4ab6bcc3ad3b fs: Add fd_install_received() wrapper for __fd_install_received()
d3868eea5cbc fs: Move __scm_install_fd() to __fd_install_received()

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2020-06-21 13:48 linux-next: build failure after merge of the kspp tree Stephen Rothwell
@ 2020-06-21 15:36 ` Kees Cook
  0 siblings, 0 replies; 35+ messages in thread
From: Kees Cook @ 2020-06-21 15:36 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Sargun Dhillon

On Sun, Jun 21, 2020 at 11:48:51PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the kspp tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> x86_64-linux-gnu-ld: fs/file.o: in function `__fd_install_received':
> file.c:(.text+0x1010): undefined reference to `sock_from_file'
> x86_64-linux-gnu-ld: file.c:(.text+0x104a): undefined reference to `sock_from_file'

Oh fun. Okay, that's the first use of sock_from_file() in core kernel
code. I will fix linux/net.h to include a NULL-returning static inline
for the CONFIG_NET=n case.

And I will add "allnoconfig" to my test workflow. :)

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2020-06-23  3:51 Stephen Rothwell
@ 2020-06-23  3:56 ` David Miller
  0 siblings, 0 replies; 35+ messages in thread
From: David Miller @ 2020-06-23  3:56 UTC (permalink / raw)
  To: sfr; +Cc: keescook, netdev, linux-next, linux-kernel, parav

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Jun 2020 13:51:34 +1000

> I have added the following merge fix patch.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 23 Jun 2020 13:43:06 +1000
> Subject: [PATCH] net/core/devlink.c: remove new uninitialized_var() usage
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Applied, thanks Stephen.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* linux-next: build failure after merge of the kspp tree
@ 2020-06-23  3:51 Stephen Rothwell
  2020-06-23  3:56 ` David Miller
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Rothwell @ 2020-06-23  3:51 UTC (permalink / raw)
  To: Kees Cook, David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Parav Pandit


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

Hi all,

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

net/core/devlink.c: In function 'devlink_nl_port_function_attrs_put':
net/core/devlink.c:586:3: warning: parameter names (without types) in function declaration
  586 |   int uninitialized_var(hw_addr_len);
      |   ^~~
net/core/devlink.c:589:65: error: 'hw_addr_len' undeclared (first use in this function); did you mean 'hw_addr'?
  589 |   err = ops->port_function_hw_addr_get(devlink, port, hw_addr, &hw_addr_len, extack);
      |                                                                 ^~~~~~~~~~~
      |                                                                 hw_addr
net/core/devlink.c:589:65: note: each undeclared identifier is reported only once for each function it appears in

Caused by commit

  2e6d06799c15 ("compiler: Remove uninitialized_var() macro")

interacting with commit

  2a916ecc4056 ("net/devlink: Support querying hardware address of port function")

from the net-next tree.

I have added the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Jun 2020 13:43:06 +1000
Subject: [PATCH] net/core/devlink.c: remove new uninitialized_var() usage

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/core/devlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/devlink.c b/net/core/devlink.c
index 455998a57671..6ae36808c152 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -583,7 +583,7 @@ devlink_nl_port_function_attrs_put(struct sk_buff *msg, struct devlink_port *por
 
 	ops = devlink->ops;
 	if (ops->port_function_hw_addr_get) {
-		int uninitialized_var(hw_addr_len);
+		int hw_addr_len;
 		u8 hw_addr[MAX_ADDR_LEN];
 
 		err = ops->port_function_hw_addr_get(devlink, port, hw_addr, &hw_addr_len, extack);
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-31 10:09         ` Will Deacon
@ 2018-07-31 11:27           ` Stephen Rothwell
  0 siblings, 0 replies; 35+ messages in thread
From: Stephen Rothwell @ 2018-07-31 11:27 UTC (permalink / raw)
  To: Will Deacon
  Cc: Kees Cook, Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexander Popov, Catalin Marinas, Laura Abbott


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

Hi Will,

On Tue, 31 Jul 2018 11:09:18 +0100 Will Deacon <will.deacon@arm.com> wrote:
>
> I've pushed out Laura's fix to the arm64 for-next/core branch, so this
> should be resolved in the next next.

Thanks.  I actually applied Laura's patch to today's linux-next as well.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-30  7:33       ` Stephen Rothwell
  2018-07-30 14:47         ` Laura Abbott
@ 2018-07-31 10:09         ` Will Deacon
  2018-07-31 11:27           ` Stephen Rothwell
  1 sibling, 1 reply; 35+ messages in thread
From: Will Deacon @ 2018-07-31 10:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Kees Cook, Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexander Popov, Catalin Marinas, Laura Abbott

On Mon, Jul 30, 2018 at 05:33:56PM +1000, Stephen Rothwell wrote:
> On Fri, 27 Jul 2018 13:55:22 +0100 Will Deacon <will.deacon@arm.com> wrote:
> > Thanks, Stephen. I managed to reproduce this by merging for-next/kspp from
> > Kees's tree and for-next/core from the arm64 tree. The failure happens when
> > building the EFI stub, so the commit you mention above is almost certainly
> > the culprit.
> > 
> > We build the stub with the following GCC invocation:
> > 
> >  gcc -Wp,-MD,drivers/firmware/efi/libstub/.efi-stub-helper.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mcmodel=small -m64 -D__KERNEL__ -O2 -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY -ffreestanding -fno-stack-protector -fplugin-arg-stackleak_plugin-disable   -fno-builtin      -DKBUILD_BASENAME='"efi_stub_helper"' -DKBUILD_MODNAME='"efi_stub_helper"' -c -o drivers/firmware/efi/libstub/.tmp_efi-stub-helper.o drivers/firmware/efi/libstub/ef
 i-stub-helper.c
> > 
> > so given that we're not passing any -fplugin= option anyway (because we
> > override KBUILD_CFLAGS for the stub), I don't understand why we need
> > to the disable option at all.
> > 
> > Laura?
> 
> So today I am just trying reverting that arm64 tree commit.

I've pushed out Laura's fix to the arm64 for-next/core branch, so this
should be resolved in the next next.

Will

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-30 14:47         ` Laura Abbott
@ 2018-07-30 16:37           ` Will Deacon
  0 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2018-07-30 16:37 UTC (permalink / raw)
  To: Laura Abbott
  Cc: Stephen Rothwell, Kees Cook, Linux-Next Mailing List,
	Linux Kernel Mailing List, Alexander Popov, Catalin Marinas

Hi Laura,

On Mon, Jul 30, 2018 at 07:47:52AM -0700, Laura Abbott wrote:
> On 07/30/2018 12:33 AM, Stephen Rothwell wrote:
> >On Fri, 27 Jul 2018 13:55:22 +0100 Will Deacon <will.deacon@arm.com> wrote:
> >>On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> >>>Actually, it may have been caused by commit
> >>>
> >>>   0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")
> >>>
> >>>from the arm64 tree.
> >>
> >>Thanks, Stephen. I managed to reproduce this by merging for-next/kspp from
> >>Kees's tree and for-next/core from the arm64 tree. The failure happens when
> >>building the EFI stub, so the commit you mention above is almost certainly
> >>the culprit.
> >>
> >>We build the stub with the following GCC invocation:
> >>
> >>  gcc -Wp,-MD,drivers/firmware/efi/libstub/.efi-stub-helper.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mcmodel=small -m64 -D__KERNEL__ -O2 -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY -ffreestanding -fno-stack-protector -fplugin-arg-stackleak_plugin-disable   -fno-builtin      -DKBUILD_BASENAME='"efi_stub_helper"' -DKBUILD_MODNAME='"efi_stub_helper"' -c -o drivers/firmware/efi/libstub/.tmp_efi-stub-helper.o drivers/firmware/efi/libstub/e
 fi-stub-helper.c
> >>
> >>so given that we're not passing any -fplugin= option anyway (because we
> >>override KBUILD_CFLAGS for the stub), I don't understand why we need
> >>to the disable option at all.
> >>
> >>Laura?
> >
> >So today I am just trying reverting that arm64 tree commit.
> >
> 
> It looks like arm and arm64 start from the KBUILD_CFLAGS and
> then filter out vs. x86 which just specifies the CFLAGS individually,
> hence x86 picking up the disable when there's no plugin at all. This
> seems to be the simplest fix unless we want to change arm64 to not
> pick up all the KBUILD_CFLAGS to match x86. That seems like a more
> involved process though. If this is okay, I can send a patch
> that also sticks a comment in there explaining why fixing on arm64
> is necessary.

Indeed, I posted a very similar patch last week!

https://lore.kernel.org/lkml/CAGXu5jJ=0YBYKkQM3=KZRp1o3fT0yGY6-0UDkkit0WenFM3oDg@mail.gmail.com/T/#m1bd3d2de78e33da4d1f496fd82be7cf088ebaa06

If you send a version with a commit message, I'm happy to pick it up.

Cheers,

Will

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-30  7:33       ` Stephen Rothwell
@ 2018-07-30 14:47         ` Laura Abbott
  2018-07-30 16:37           ` Will Deacon
  2018-07-31 10:09         ` Will Deacon
  1 sibling, 1 reply; 35+ messages in thread
From: Laura Abbott @ 2018-07-30 14:47 UTC (permalink / raw)
  To: Stephen Rothwell, Will Deacon
  Cc: Kees Cook, Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexander Popov, Catalin Marinas

On 07/30/2018 12:33 AM, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 27 Jul 2018 13:55:22 +0100 Will Deacon <will.deacon@arm.com> wrote:
>>
>> On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
>>> On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>> On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>>
>>>>> After merging the kspp tree, today's linux-next build (x86_64
>>>>> allmodconfig) failed like this:
>>>>>
>>>>> cc1: error: plugin stackleak_plugin should be specified before -fplugin-arg-stackleak_plugin-disable in the command line
>>>>>
>>>>> Maybe caused by commit
>>>>>
>>>>>    a8b9eaddb9c0 ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")
>>>>>
>>>>> I have used the kspp tree from next-20180726 for today.
>>>>
>>>> Well, that obviously didn't work since the tree hasn't changed for a
>>>> few days.
>>>>
>>>> I can't see what has interacted to make this happen, so I have dropped
>>>> the kspp tree for today.
>>>
>>> Actually, it may have been caused by commit
>>>
>>>    0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")
>>>
>>> from the arm64 tree.
>>
>> Thanks, Stephen. I managed to reproduce this by merging for-next/kspp from
>> Kees's tree and for-next/core from the arm64 tree. The failure happens when
>> building the EFI stub, so the commit you mention above is almost certainly
>> the culprit.
>>
>> We build the stub with the following GCC invocation:
>>
>>   gcc -Wp,-MD,drivers/firmware/efi/libstub/.efi-stub-helper.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mcmodel=small -m64 -D__KERNEL__ -O2 -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY -ffreestanding -fno-stack-protector -fplugin-arg-stackleak_plugin-disable   -fno-builtin      -DKBUILD_BASENAME='"efi_stub_helper"' -DKBUILD_MODNAME='"efi_stub_helper"' -c -o drivers/firmware/efi/libstub/.tmp_efi-stub-helper.o drivers/firmware/efi/libstub/ef
 i-stub-helper.c
>>
>> so given that we're not passing any -fplugin= option anyway (because we
>> override KBUILD_CFLAGS for the stub), I don't understand why we need
>> to the disable option at all.
>>
>> Laura?
> 
> So today I am just trying reverting that arm64 tree commit.
> 

It looks like arm and arm64 start from the KBUILD_CFLAGS and
then filter out vs. x86 which just specifies the CFLAGS individually,
hence x86 picking up the disable when there's no plugin at all. This
seems to be the simplest fix unless we want to change arm64 to not
pick up all the KBUILD_CFLAGS to match x86. That seems like a more
involved process though. If this is okay, I can send a patch
that also sticks a comment in there explaining why fixing on arm64
is necessary.

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 25dd2a14560d..31f376279d5c 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -11,7 +11,8 @@ cflags-$(CONFIG_X86)		+= -m$(BITS) -D__KERNEL__ -O2 \
  				   -fPIC -fno-strict-aliasing -mno-red-zone \
  				   -mno-mmx -mno-sse -fshort-wchar
  
-cflags-$(CONFIG_ARM64)		:= $(subst -pg,,$(KBUILD_CFLAGS)) -fpie
+cflags-$(CONFIG_ARM64)		:= $(subst -pg,,$(KBUILD_CFLAGS)) -fpie \
+				   $(DISABLE_STACKLEAK_PLUGIN)
  cflags-$(CONFIG_ARM)		:= $(subst -pg,,$(KBUILD_CFLAGS)) \
  				   -fno-builtin -fpic -mno-single-pic-base
  
@@ -21,7 +22,6 @@ KBUILD_CFLAGS			:= $(cflags-y) -DDISABLE_BRANCH_PROFILING \
  				   -D__NO_FORTIFY \
  				   $(call cc-option,-ffreestanding) \
  				   $(call cc-option,-fno-stack-protector) \
-				   $(DISABLE_STACKLEAK_PLUGIN)
  
  GCOV_PROFILE			:= n
  KASAN_SANITIZE			:= n

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-27 12:55     ` Will Deacon
  2018-07-27 13:01       ` Will Deacon
@ 2018-07-30  7:33       ` Stephen Rothwell
  2018-07-30 14:47         ` Laura Abbott
  2018-07-31 10:09         ` Will Deacon
  1 sibling, 2 replies; 35+ messages in thread
From: Stephen Rothwell @ 2018-07-30  7:33 UTC (permalink / raw)
  To: Will Deacon
  Cc: Kees Cook, Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexander Popov, Catalin Marinas, Laura Abbott


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

Hi all,

On Fri, 27 Jul 2018 13:55:22 +0100 Will Deacon <will.deacon@arm.com> wrote:
>
> On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> > On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > >
> > > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > > >
> > > > After merging the kspp tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > > 
> > > > cc1: error: plugin stackleak_plugin should be specified before -fplugin-arg-stackleak_plugin-disable in the command line
> > > > 
> > > > Maybe caused by commit
> > > > 
> > > >   a8b9eaddb9c0 ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")
> > > > 
> > > > I have used the kspp tree from next-20180726 for today.    
> > > 
> > > Well, that obviously didn't work since the tree hasn't changed for a
> > > few days.
> > > 
> > > I can't see what has interacted to make this happen, so I have dropped
> > > the kspp tree for today.  
> > 
> > Actually, it may have been caused by commit
> > 
> >   0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")
> > 
> > from the arm64 tree.  
> 
> Thanks, Stephen. I managed to reproduce this by merging for-next/kspp from
> Kees's tree and for-next/core from the arm64 tree. The failure happens when
> building the EFI stub, so the commit you mention above is almost certainly
> the culprit.
> 
> We build the stub with the following GCC invocation:
> 
>  gcc -Wp,-MD,drivers/firmware/efi/libstub/.efi-stub-helper.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mcmodel=small -m64 -D__KERNEL__ -O2 -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY -ffreestanding -fno-stack-protector -fplugin-arg-stackleak_plugin-disable   -fno-builtin      -DKBUILD_BASENAME='"efi_stub_helper"' -DKBUILD_MODNAME='"efi_stub_helper"' -c -o drivers/firmware/efi/libstub/.tmp_efi-stub-helper.o drivers/firmware/efi/libstub/efi-stub-helper.c
> 
> so given that we're not passing any -fplugin= option anyway (because we
> override KBUILD_CFLAGS for the stub), I don't understand why we need
> to the disable option at all.
> 
> Laura?

So today I am just trying reverting that arm64 tree commit.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-27 13:27         ` Will Deacon
@ 2018-07-27 16:00           ` Kees Cook
  0 siblings, 0 replies; 35+ messages in thread
From: Kees Cook @ 2018-07-27 16:00 UTC (permalink / raw)
  To: Will Deacon
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Alexander Popov, Catalin Marinas,
	Laura Abbott

On Fri, Jul 27, 2018 at 6:27 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jul 27, 2018 at 02:01:06PM +0100, Will Deacon wrote:
>> On Fri, Jul 27, 2018 at 01:55:22PM +0100, Will Deacon wrote:
>> > On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
>> > > On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > > >
>> > > > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > > > >
>> > > > > After merging the kspp tree, today's linux-next build (x86_64
>> > > > > allmodconfig) failed like this:
>> > > > >
>> > > > > cc1: error: plugin stackleak_plugin should be specified before -fplugin-arg-stackleak_plugin-disable in the command line
>> > > > >
>> > > > > Maybe caused by commit
>> > > > >
>> > > > >   a8b9eaddb9c0 ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")
>> > > > >
>> > > > > I have used the kspp tree from next-20180726 for today.
>> > > >
>> > > > Well, that obviously didn't work since the tree hasn't changed for a
>> > > > few days.
>> > > >
>> > > > I can't see what has interacted to make this happen, so I have dropped
>> > > > the kspp tree for today.
>> > >
>> > > Actually, it may have been caused by commit
>> > >
>> > >   0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")
>> > >
>> > > from the arm64 tree.
>> >
>> > Thanks, Stephen. I managed to reproduce this by merging for-next/kspp from
>> > Kees's tree and for-next/core from the arm64 tree. The failure happens when
>> > building the EFI stub, so the commit you mention above is almost certainly
>> > the culprit.
>> >
>> > We build the stub with the following GCC invocation:
>> >
>> >  gcc -Wp,-MD,drivers/firmware/efi/libstub/.efi-stub-helper.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mcmodel=small -m64 -D__KERNEL__ -O2 -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY -ffreestanding -fno-stack-protector -fplugin-arg-stackleak_plugin-disable   -fno-builtin      -DKBUILD_BASENAME='"efi_stub_helper"' -DKBUILD_MODNAME='"efi_stub_helper"' -c -o drivers/firmware/efi/libstub/.tmp_efi-stub-helper.o drivers/firmware/efi/libstub/efi-stub-helper.c
>> >
>> > so given that we're not passing any -fplugin= option anyway (because we
>> > override KBUILD_CFLAGS for the stub), I don't understand why we need
>> > to the disable option at all.
>> >
>> > Laura?
>>
>> ... ah, but arm and arm64 inherit the old KBUILD_CFLAGS via the
>> cflags-$(CONFIG_ARM64) and cflags-$(CONFIG_ARM) definitions, so they
>> would be the places where we need to disable the plugin.
>
> i.e. something like the diff below.
>
> Will
>
> --->8
>
> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> index 25dd2a14560d..f3700fe08908 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -11,9 +11,11 @@ cflags-$(CONFIG_X86)         += -m$(BITS) -D__KERNEL__ -O2 \
>                                    -fPIC -fno-strict-aliasing -mno-red-zone \
>                                    -mno-mmx -mno-sse -fshort-wchar
>
> -cflags-$(CONFIG_ARM64)         := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie
> +cflags-$(CONFIG_ARM64)         := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie \
> +                                  $(DISABLE_STACKLEAK_PLUGIN)
>  cflags-$(CONFIG_ARM)           := $(subst -pg,,$(KBUILD_CFLAGS)) \
> -                                  -fno-builtin -fpic -mno-single-pic-base
> +                                  -fno-builtin -fpic -mno-single-pic-base \
> +                                  $(DISABLE_STACKLEAK_PLUGIN)
>
>  cflags-$(CONFIG_EFI_ARMSTUB)   += -I$(srctree)/scripts/dtc/libfdt
>
> @@ -21,7 +23,6 @@ KBUILD_CFLAGS                 := $(cflags-y) -DDISABLE_BRANCH_PROFILING \
>                                    -D__NO_FORTIFY \
>                                    $(call cc-option,-ffreestanding) \
>                                    $(call cc-option,-fno-stack-protector) \
> -                                  $(DISABLE_STACKLEAK_PLUGIN)
>
>  GCOV_PROFILE                   := n
>  KASAN_SANITIZE                 := n

Ah! Thanks for tracking this down!

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-27 13:01       ` Will Deacon
@ 2018-07-27 13:27         ` Will Deacon
  2018-07-27 16:00           ` Kees Cook
  0 siblings, 1 reply; 35+ messages in thread
From: Will Deacon @ 2018-07-27 13:27 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Kees Cook, Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexander Popov, Catalin Marinas, Laura Abbott

On Fri, Jul 27, 2018 at 02:01:06PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2018 at 01:55:22PM +0100, Will Deacon wrote:
> > On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> > > On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >
> > > > > After merging the kspp tree, today's linux-next build (x86_64
> > > > > allmodconfig) failed like this:
> > > > > 
> > > > > cc1: error: plugin stackleak_plugin should be specified before -fplugin-arg-stackleak_plugin-disable in the command line
> > > > > 
> > > > > Maybe caused by commit
> > > > > 
> > > > >   a8b9eaddb9c0 ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")
> > > > > 
> > > > > I have used the kspp tree from next-20180726 for today.  
> > > > 
> > > > Well, that obviously didn't work since the tree hasn't changed for a
> > > > few days.
> > > > 
> > > > I can't see what has interacted to make this happen, so I have dropped
> > > > the kspp tree for today.
> > > 
> > > Actually, it may have been caused by commit
> > > 
> > >   0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")
> > > 
> > > from the arm64 tree.
> > 
> > Thanks, Stephen. I managed to reproduce this by merging for-next/kspp from
> > Kees's tree and for-next/core from the arm64 tree. The failure happens when
> > building the EFI stub, so the commit you mention above is almost certainly
> > the culprit.
> > 
> > We build the stub with the following GCC invocation:
> > 
> >  gcc -Wp,-MD,drivers/firmware/efi/libstub/.efi-stub-helper.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mcmodel=small -m64 -D__KERNEL__ -O2 -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY -ffreestanding -fno-stack-protector -fplugin-arg-stackleak_plugin-disable   -fno-builtin      -DKBUILD_BASENAME='"efi_stub_helper"' -DKBUILD_MODNAME='"efi_stub_helper"' -c -o drivers/firmware/efi/libstub/.tmp_efi-stub-helper.o drivers/firmware/efi/libstub/ef
 i-stub-helper.c
> > 
> > so given that we're not passing any -fplugin= option anyway (because we
> > override KBUILD_CFLAGS for the stub), I don't understand why we need
> > to the disable option at all.
> > 
> > Laura?
> 
> ... ah, but arm and arm64 inherit the old KBUILD_CFLAGS via the
> cflags-$(CONFIG_ARM64) and cflags-$(CONFIG_ARM) definitions, so they
> would be the places where we need to disable the plugin.

i.e. something like the diff below.

Will

--->8

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 25dd2a14560d..f3700fe08908 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -11,9 +11,11 @@ cflags-$(CONFIG_X86)         += -m$(BITS) -D__KERNEL__ -O2 \
                                   -fPIC -fno-strict-aliasing -mno-red-zone \
                                   -mno-mmx -mno-sse -fshort-wchar
 
-cflags-$(CONFIG_ARM64)         := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie
+cflags-$(CONFIG_ARM64)         := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie \
+                                  $(DISABLE_STACKLEAK_PLUGIN)
 cflags-$(CONFIG_ARM)           := $(subst -pg,,$(KBUILD_CFLAGS)) \
-                                  -fno-builtin -fpic -mno-single-pic-base
+                                  -fno-builtin -fpic -mno-single-pic-base \
+                                  $(DISABLE_STACKLEAK_PLUGIN)
 
 cflags-$(CONFIG_EFI_ARMSTUB)   += -I$(srctree)/scripts/dtc/libfdt
 
@@ -21,7 +23,6 @@ KBUILD_CFLAGS                 := $(cflags-y) -DDISABLE_BRANCH_PROFILING \
                                   -D__NO_FORTIFY \
                                   $(call cc-option,-ffreestanding) \
                                   $(call cc-option,-fno-stack-protector) \
-                                  $(DISABLE_STACKLEAK_PLUGIN)
 
 GCOV_PROFILE                   := n
 KASAN_SANITIZE                 := n

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-27 12:55     ` Will Deacon
@ 2018-07-27 13:01       ` Will Deacon
  2018-07-27 13:27         ` Will Deacon
  2018-07-30  7:33       ` Stephen Rothwell
  1 sibling, 1 reply; 35+ messages in thread
From: Will Deacon @ 2018-07-27 13:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Kees Cook, Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexander Popov, Catalin Marinas, Laura Abbott

On Fri, Jul 27, 2018 at 01:55:22PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> > On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > After merging the kspp tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > > 
> > > > cc1: error: plugin stackleak_plugin should be specified before -fplugin-arg-stackleak_plugin-disable in the command line
> > > > 
> > > > Maybe caused by commit
> > > > 
> > > >   a8b9eaddb9c0 ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")
> > > > 
> > > > I have used the kspp tree from next-20180726 for today.  
> > > 
> > > Well, that obviously didn't work since the tree hasn't changed for a
> > > few days.
> > > 
> > > I can't see what has interacted to make this happen, so I have dropped
> > > the kspp tree for today.
> > 
> > Actually, it may have been caused by commit
> > 
> >   0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")
> > 
> > from the arm64 tree.
> 
> Thanks, Stephen. I managed to reproduce this by merging for-next/kspp from
> Kees's tree and for-next/core from the arm64 tree. The failure happens when
> building the EFI stub, so the commit you mention above is almost certainly
> the culprit.
> 
> We build the stub with the following GCC invocation:
> 
>  gcc -Wp,-MD,drivers/firmware/efi/libstub/.efi-stub-helper.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mcmodel=small -m64 -D__KERNEL__ -O2 -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY -ffreestanding -fno-stack-protector -fplugin-arg-stackleak_plugin-disable   -fno-builtin      -DKBUILD_BASENAME='"efi_stub_helper"' -DKBUILD_MODNAME='"efi_stub_helper"' -c -o drivers/firmware/efi/libstub/.tmp_efi-stub-helper.o drivers/firmware/efi/libstub/efi-
 stub-helper.c
> 
> so given that we're not passing any -fplugin= option anyway (because we
> override KBUILD_CFLAGS for the stub), I don't understand why we need
> to the disable option at all.
> 
> Laura?

... ah, but arm and arm64 inherit the old KBUILD_CFLAGS via the
cflags-$(CONFIG_ARM64) and cflags-$(CONFIG_ARM) definitions, so they
would be the places where we need to disable the plugin.

Will

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-27 10:55   ` Stephen Rothwell
@ 2018-07-27 12:55     ` Will Deacon
  2018-07-27 13:01       ` Will Deacon
  2018-07-30  7:33       ` Stephen Rothwell
  0 siblings, 2 replies; 35+ messages in thread
From: Will Deacon @ 2018-07-27 12:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Kees Cook, Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexander Popov, Catalin Marinas, Laura Abbott

On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > After merging the kspp tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > cc1: error: plugin stackleak_plugin should be specified before -fplugin-arg-stackleak_plugin-disable in the command line
> > > 
> > > Maybe caused by commit
> > > 
> > >   a8b9eaddb9c0 ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")
> > > 
> > > I have used the kspp tree from next-20180726 for today.  
> > 
> > Well, that obviously didn't work since the tree hasn't changed for a
> > few days.
> > 
> > I can't see what has interacted to make this happen, so I have dropped
> > the kspp tree for today.
> 
> Actually, it may have been caused by commit
> 
>   0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")
> 
> from the arm64 tree.

Thanks, Stephen. I managed to reproduce this by merging for-next/kspp from
Kees's tree and for-next/core from the arm64 tree. The failure happens when
building the EFI stub, so the commit you mention above is almost certainly
the culprit.

We build the stub with the following GCC invocation:

 gcc -Wp,-MD,drivers/firmware/efi/libstub/.efi-stub-helper.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mcmodel=small -m64 -D__KERNEL__ -O2 -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY -ffreestanding -fno-stack-protector -fplugin-arg-stackleak_plugin-disable   -fno-builtin      -DKBUILD_BASENAME='"efi_stub_helper"' -DKBUILD_MODNAME='"efi_stub_helper"' -c -o drivers/firmware/efi/libstub/.tmp_efi-stub-helper.o drivers/firmware/efi/libstub/efi-st
 ub-helper.c

so given that we're not passing any -fplugin= option anyway (because we
override KBUILD_CFLAGS for the stub), I don't understand why we need
to the disable option at all.

Laura?

Will

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-27  9:06 ` Stephen Rothwell
@ 2018-07-27 10:55   ` Stephen Rothwell
  2018-07-27 12:55     ` Will Deacon
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Rothwell @ 2018-07-27 10:55 UTC (permalink / raw)
  To: Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexander Popov, Catalin Marinas, Will Deacon, Laura Abbott


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

Hi all,

On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the kspp tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > cc1: error: plugin stackleak_plugin should be specified before -fplugin-arg-stackleak_plugin-disable in the command line
> > 
> > Maybe caused by commit
> > 
> >   a8b9eaddb9c0 ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")
> > 
> > I have used the kspp tree from next-20180726 for today.  
> 
> Well, that obviously didn't work since the tree hasn't changed for a
> few days.
> 
> I can't see what has interacted to make this happen, so I have dropped
> the kspp tree for today.

Actually, it may have been caused by commit

  0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")

from the arm64 tree.
-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2018-07-27  9:02 Stephen Rothwell
@ 2018-07-27  9:06 ` Stephen Rothwell
  2018-07-27 10:55   ` Stephen Rothwell
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Rothwell @ 2018-07-27  9:06 UTC (permalink / raw)
  To: Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Alexander Popov


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

Hi all,

On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the kspp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> cc1: error: plugin stackleak_plugin should be specified before -fplugin-arg-stackleak_plugin-disable in the command line
> 
> Maybe caused by commit
> 
>   a8b9eaddb9c0 ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")
> 
> I have used the kspp tree from next-20180726 for today.

Well, that obviously didn't work since the tree hasn't changed for a
few days.

I can't see what has interacted to make this happen, so I have dropped
the kspp tree for today.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* linux-next: build failure after merge of the kspp tree
@ 2018-07-27  9:02 Stephen Rothwell
  2018-07-27  9:06 ` Stephen Rothwell
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Rothwell @ 2018-07-27  9:02 UTC (permalink / raw)
  To: Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Alexander Popov


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

Hi Kees,

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

cc1: error: plugin stackleak_plugin should be specified before -fplugin-arg-stackleak_plugin-disable in the command line

Maybe caused by commit

  a8b9eaddb9c0 ("gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack")

I have used the kspp tree from next-20180726 for today.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-11-09  0:18   ` Darrick J. Wong
@ 2017-11-09  0:31     ` Kees Cook
  0 siblings, 0 replies; 35+ messages in thread
From: Kees Cook @ 2017-11-09  0:31 UTC (permalink / raw)
  To: Darrick J. Wong
  Cc: Stephen Rothwell, David Chinner, linux-xfs,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	David Windsor, Christoph Hellwig

On Wed, Nov 8, 2017 at 4:18 PM, Darrick J. Wong <darrick.wong@oracle.com> wrote:
> Agreed.  I guess we'll see you for round X when you get to general
> kmalloc annotating. :)

That should be "fun". :)

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-11-08 23:43 ` Kees Cook
@ 2017-11-09  0:18   ` Darrick J. Wong
  2017-11-09  0:31     ` Kees Cook
  0 siblings, 1 reply; 35+ messages in thread
From: Darrick J. Wong @ 2017-11-09  0:18 UTC (permalink / raw)
  To: Kees Cook
  Cc: Stephen Rothwell, David Chinner, linux-xfs,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	David Windsor, Christoph Hellwig

On Wed, Nov 08, 2017 at 03:43:47PM -0800, Kees Cook wrote:
> On Tue, Nov 7, 2017 at 9:23 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Kees,
> >
> > After merging the kspp tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from include/linux/compiler_types.h:58:0,
> >                  from include/uapi/linux/stddef.h:2,
> >                  from include/linux/stddef.h:5,
> >                  from include/uapi/linux/posix_types.h:5,
> >                  from include/uapi/linux/types.h:14,
> >                  from include/linux/types.h:6,
> >                  from fs/xfs/xfs_linux.h:21,
> >                  from fs/xfs/xfs.h:35,
> >                  from fs/xfs/xfs_super.c:19:
> > fs/xfs/xfs_super.c: In function 'xfs_init_zones':
> > include/linux/compiler-gcc.h:166:2: error: 'xfs_ifork_t {aka struct xfs_ifork}' has no member named 'if_u2'
> >   __builtin_offsetof(a, b)
> >   ^
> > include/linux/stddef.h:17:32: note: in expansion of macro '__compiler_offsetof'
> >  #define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
> >                                 ^
> > fs/xfs/xfs_super.c:1862:4: note: in expansion of macro 'offsetof'
> >     offsetof(xfs_inode_t, i_df.if_u2.if_inline_data),
> >     ^
> > In file included from include/uapi/linux/posix_types.h:5:0,
> >                  from include/uapi/linux/types.h:14,
> >                  from include/linux/types.h:6,
> >                  from fs/xfs/xfs_linux.h:21,
> >                  from fs/xfs/xfs.h:35,
> >                  from fs/xfs/xfs_super.c:19:
> > fs/xfs/xfs_super.c:1863:34: error: 'xfs_ifork_t {aka struct xfs_ifork}' has no member named 'if_u2'
> >     sizeof_field(xfs_inode_t, i_df.if_u2.if_inline_data),
> >                                   ^
> > include/linux/stddef.h:22:66: note: in definition of macro 'sizeof_field'
> >  #define sizeof_field(structure, field) sizeof((((structure *)0)->field))
> >                                                                   ^
> >
> > Caused by commit
> >
> >   1d48144b9688 ("xfs: Define usercopy region in xfs_inode slab cache")
> >
> > interacting with commit
> >
> >   43518812d297 ("xfs: remove support for inlining data/extents into the inode fork")
> >
> > from the  tree.
> >
> > I just reverted the kspp tree commit as it seems like it is no longer
> > needed.
> 
> Yup, that looks like the correct fix. Thanks!

Agreed.  I guess we'll see you for round X when you get to general
kmalloc annotating. :)

--D

> -Kees
> 
> -- 
> Kees Cook
> Pixel Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-11-08  5:23 Stephen Rothwell
@ 2017-11-08 23:43 ` Kees Cook
  2017-11-09  0:18   ` Darrick J. Wong
  0 siblings, 1 reply; 35+ messages in thread
From: Kees Cook @ 2017-11-08 23:43 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Darrick J. Wong, David Chinner, linux-xfs,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	David Windsor, Christoph Hellwig

On Tue, Nov 7, 2017 at 9:23 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Kees,
>
> After merging the kspp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/compiler_types.h:58:0,
>                  from include/uapi/linux/stddef.h:2,
>                  from include/linux/stddef.h:5,
>                  from include/uapi/linux/posix_types.h:5,
>                  from include/uapi/linux/types.h:14,
>                  from include/linux/types.h:6,
>                  from fs/xfs/xfs_linux.h:21,
>                  from fs/xfs/xfs.h:35,
>                  from fs/xfs/xfs_super.c:19:
> fs/xfs/xfs_super.c: In function 'xfs_init_zones':
> include/linux/compiler-gcc.h:166:2: error: 'xfs_ifork_t {aka struct xfs_ifork}' has no member named 'if_u2'
>   __builtin_offsetof(a, b)
>   ^
> include/linux/stddef.h:17:32: note: in expansion of macro '__compiler_offsetof'
>  #define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
>                                 ^
> fs/xfs/xfs_super.c:1862:4: note: in expansion of macro 'offsetof'
>     offsetof(xfs_inode_t, i_df.if_u2.if_inline_data),
>     ^
> In file included from include/uapi/linux/posix_types.h:5:0,
>                  from include/uapi/linux/types.h:14,
>                  from include/linux/types.h:6,
>                  from fs/xfs/xfs_linux.h:21,
>                  from fs/xfs/xfs.h:35,
>                  from fs/xfs/xfs_super.c:19:
> fs/xfs/xfs_super.c:1863:34: error: 'xfs_ifork_t {aka struct xfs_ifork}' has no member named 'if_u2'
>     sizeof_field(xfs_inode_t, i_df.if_u2.if_inline_data),
>                                   ^
> include/linux/stddef.h:22:66: note: in definition of macro 'sizeof_field'
>  #define sizeof_field(structure, field) sizeof((((structure *)0)->field))
>                                                                   ^
>
> Caused by commit
>
>   1d48144b9688 ("xfs: Define usercopy region in xfs_inode slab cache")
>
> interacting with commit
>
>   43518812d297 ("xfs: remove support for inlining data/extents into the inode fork")
>
> from the  tree.
>
> I just reverted the kspp tree commit as it seems like it is no longer
> needed.

Yup, that looks like the correct fix. Thanks!

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 35+ messages in thread

* linux-next: build failure after merge of the kspp tree
@ 2017-11-08  5:23 Stephen Rothwell
  2017-11-08 23:43 ` Kees Cook
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Rothwell @ 2017-11-08  5:23 UTC (permalink / raw)
  To: Kees Cook, Darrick J. Wong, David Chinner, linux-xfs
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	David Windsor, Christoph Hellwig

Hi Kees,

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

In file included from include/linux/compiler_types.h:58:0,
                 from include/uapi/linux/stddef.h:2,
                 from include/linux/stddef.h:5,
                 from include/uapi/linux/posix_types.h:5,
                 from include/uapi/linux/types.h:14,
                 from include/linux/types.h:6,
                 from fs/xfs/xfs_linux.h:21,
                 from fs/xfs/xfs.h:35,
                 from fs/xfs/xfs_super.c:19:
fs/xfs/xfs_super.c: In function 'xfs_init_zones':
include/linux/compiler-gcc.h:166:2: error: 'xfs_ifork_t {aka struct xfs_ifork}' has no member named 'if_u2'
  __builtin_offsetof(a, b)
  ^
include/linux/stddef.h:17:32: note: in expansion of macro '__compiler_offsetof'
 #define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
                                ^
fs/xfs/xfs_super.c:1862:4: note: in expansion of macro 'offsetof'
    offsetof(xfs_inode_t, i_df.if_u2.if_inline_data),
    ^
In file included from include/uapi/linux/posix_types.h:5:0,
                 from include/uapi/linux/types.h:14,
                 from include/linux/types.h:6,
                 from fs/xfs/xfs_linux.h:21,
                 from fs/xfs/xfs.h:35,
                 from fs/xfs/xfs_super.c:19:
fs/xfs/xfs_super.c:1863:34: error: 'xfs_ifork_t {aka struct xfs_ifork}' has no member named 'if_u2'
    sizeof_field(xfs_inode_t, i_df.if_u2.if_inline_data),
                                  ^
include/linux/stddef.h:22:66: note: in definition of macro 'sizeof_field'
 #define sizeof_field(structure, field) sizeof((((structure *)0)->field))
                                                                  ^

Caused by commit

  1d48144b9688 ("xfs: Define usercopy region in xfs_inode slab cache")

interacting with commit

  43518812d297 ("xfs: remove support for inlining data/extents into the inode fork")

from the  tree.

I just reverted the kspp tree commit as it seems like it is no longer
needed.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-27 22:16       ` Kees Cook
@ 2017-06-28  5:48         ` James Morris
  0 siblings, 0 replies; 35+ messages in thread
From: James Morris @ 2017-06-28  5:48 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Tue, 27 Jun 2017, Kees Cook wrote:

> On Mon, Jun 26, 2017 at 8:33 PM, James Morris <jmorris@namei.org> wrote:
> > On Mon, 26 Jun 2017, Kees Cook wrote:
> >
> >> >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
> >> >> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >> > Acked-by: John Johansen <john.johansen@canonical.com>
> >>
> >> Hi James,
> >>
> >> Just a ping; this needs to get into -next to avoid build errors.
> >
> > Surely Linus will resolve this when he pulls the trees in?
> 
> It's not a merge glitch, it's a refactoring glitch. John's commit in
> security-next ("apparmor: move path_link mediation to using labels")
> undid an earlier commit 8486adf0d755 ("apparmor: use designated
> initializers") from v4.11. This patch is needed for security-next.
> 

Thanks.

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-27  3:33     ` James Morris
@ 2017-06-27 22:16       ` Kees Cook
  2017-06-28  5:48         ` James Morris
  0 siblings, 1 reply; 35+ messages in thread
From: Kees Cook @ 2017-06-27 22:16 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Mon, Jun 26, 2017 at 8:33 PM, James Morris <jmorris@namei.org> wrote:
> On Mon, 26 Jun 2017, Kees Cook wrote:
>
>> >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
>> >> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> > Acked-by: John Johansen <john.johansen@canonical.com>
>>
>> Hi James,
>>
>> Just a ping; this needs to get into -next to avoid build errors.
>
> Surely Linus will resolve this when he pulls the trees in?

It's not a merge glitch, it's a refactoring glitch. John's commit in
security-next ("apparmor: move path_link mediation to using labels")
undid an earlier commit 8486adf0d755 ("apparmor: use designated
initializers") from v4.11. This patch is needed for security-next.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-26 18:19   ` Kees Cook
@ 2017-06-27  3:33     ` James Morris
  2017-06-27 22:16       ` Kees Cook
  0 siblings, 1 reply; 35+ messages in thread
From: James Morris @ 2017-06-27  3:33 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Mon, 26 Jun 2017, Kees Cook wrote:

> >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
> >> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > Acked-by: John Johansen <john.johansen@canonical.com>
> 
> Hi James,
> 
> Just a ping; this needs to get into -next to avoid build errors.

Surely Linus will resolve this when he pulls the trees in?


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-20  5:39 ` John Johansen
@ 2017-06-26 18:19   ` Kees Cook
  2017-06-27  3:33     ` James Morris
  0 siblings, 1 reply; 35+ messages in thread
From: Kees Cook @ 2017-06-26 18:19 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Mon, Jun 19, 2017 at 10:39 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 06/19/2017 09:56 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the kspp tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> security/apparmor/file.c: In function 'aa_path_link':
>> security/apparmor/file.c:475:23: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>>   struct path link = { new_dir->mnt, new_dentry };
>>                        ^
>> security/apparmor/file.c:475:23: note: (near initialization for 'link')
>> security/apparmor/file.c:475:37: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>>   struct path link = { new_dir->mnt, new_dentry };
>>                                      ^
>> security/apparmor/file.c:475:37: note: (near initialization for 'link')
>> security/apparmor/file.c:476:25: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>>   struct path target = { new_dir->mnt, old_dentry };
>>                          ^
>> security/apparmor/file.c:476:25: note: (near initialization for 'target')
>> security/apparmor/file.c:476:39: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>>   struct path target = { new_dir->mnt, old_dentry };
>>                                        ^
>> security/apparmor/file.c:476:39: note: (near initialization for 'target')
>>
>> Caused by commit
>>
>>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
>>
>> interacting with commit
>>
>>   8014370f1257 ("apparmor: move path_link mediation to using labels")
>>
>> from the security tree.
>>
>> I added the following merge fix patch for today:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 20 Jun 2017 14:50:36 +1000
>> Subject: [PATCH] apparmor: put back designators in struct initialisers
>>
>> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Acked-by: John Johansen <john.johansen@canonical.com>

Hi James,

Just a ping; this needs to get into -next to avoid build errors.
Please consider it also:

Acked-by: Kees Cook <keescook@chromium.org>

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-20  5:39 ` Kees Cook
@ 2017-06-20  5:42   ` John Johansen
  0 siblings, 0 replies; 35+ messages in thread
From: John Johansen @ 2017-06-20  5:42 UTC (permalink / raw)
  To: Kees Cook, Stephen Rothwell
  Cc: James Morris, Linux-Next Mailing List, Linux Kernel Mailing List

On 06/19/2017 10:39 PM, Kees Cook wrote:
> On Mon, Jun 19, 2017 at 9:56 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> After merging the kspp tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> security/apparmor/file.c: In function 'aa_path_link':
>> security/apparmor/file.c:475:23: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>>   struct path link = { new_dir->mnt, new_dentry };
>>                        ^
>> security/apparmor/file.c:475:23: note: (near initialization for 'link')
>> security/apparmor/file.c:475:37: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>>   struct path link = { new_dir->mnt, new_dentry };
>>                                      ^
>> security/apparmor/file.c:475:37: note: (near initialization for 'link')
>> security/apparmor/file.c:476:25: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>>   struct path target = { new_dir->mnt, old_dentry };
>>                          ^
>> security/apparmor/file.c:476:25: note: (near initialization for 'target')
>> security/apparmor/file.c:476:39: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>>   struct path target = { new_dir->mnt, old_dentry };
>>                                        ^
>> security/apparmor/file.c:476:39: note: (near initialization for 'target')
>>
>> Caused by commit
>>
>>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
>>
>> interacting with commit
>>
>>   8014370f1257 ("apparmor: move path_link mediation to using labels")
>>
>> from the security tree.
>>
>> I added the following merge fix patch for today:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 20 Jun 2017 14:50:36 +1000
>> Subject: [PATCH] apparmor: put back designators in struct initialisers
>>
>> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>>  security/apparmor/file.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
>> index b6e8e5b11e05..3382518b87fa 100644
>> --- a/security/apparmor/file.c
>> +++ b/security/apparmor/file.c
>> @@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
>>  int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
>>                  const struct path *new_dir, struct dentry *new_dentry)
>>  {
>> -       struct path link = { new_dir->mnt, new_dentry };
>> -       struct path target = { new_dir->mnt, old_dentry };
>> +       struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
>> +       struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
>>         struct path_cond cond = {
>>                 d_backing_inode(old_dentry)->i_uid,
>>                 d_backing_inode(old_dentry)->i_mode
>> --
>> 2.11.0
> 
> Thanks for the fix! That looks correct to me. It seems the refactoring
> in 8014370f1257 ("apparmor: move path_link mediation to using labels")
> didn't take 8486adf0d755 ("apparmor: use designated initializers")
> into account. John, if this looks okay, can you Ack it for James to
> carry in security-next?
> 
yep, already done. Sorry I missed that one :(

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-20  4:56 Stephen Rothwell
  2017-06-20  5:39 ` Kees Cook
@ 2017-06-20  5:39 ` John Johansen
  2017-06-26 18:19   ` Kees Cook
  1 sibling, 1 reply; 35+ messages in thread
From: John Johansen @ 2017-06-20  5:39 UTC (permalink / raw)
  To: Stephen Rothwell, Kees Cook, James Morris
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

On 06/19/2017 09:56 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the kspp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> security/apparmor/file.c: In function 'aa_path_link':
> security/apparmor/file.c:475:23: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>                        ^
> security/apparmor/file.c:475:23: note: (near initialization for 'link')
> security/apparmor/file.c:475:37: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>                                      ^
> security/apparmor/file.c:475:37: note: (near initialization for 'link')
> security/apparmor/file.c:476:25: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>                          ^
> security/apparmor/file.c:476:25: note: (near initialization for 'target')
> security/apparmor/file.c:476:39: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>                                        ^
> security/apparmor/file.c:476:39: note: (near initialization for 'target')
> 
> Caused by commit
> 
>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
> 
> interacting with commit
> 
>   8014370f1257 ("apparmor: move path_link mediation to using labels")
> 
> from the security tree.
> 
> I added the following merge fix patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 20 Jun 2017 14:50:36 +1000
> Subject: [PATCH] apparmor: put back designators in struct initialisers
> 
> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: John Johansen <john.johansen@canonical.com>

> ---
>  security/apparmor/file.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index b6e8e5b11e05..3382518b87fa 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
>  int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
>  		 const struct path *new_dir, struct dentry *new_dentry)
>  {
> -	struct path link = { new_dir->mnt, new_dentry };
> -	struct path target = { new_dir->mnt, old_dentry };
> +	struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
> +	struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
>  	struct path_cond cond = {
>  		d_backing_inode(old_dentry)->i_uid,
>  		d_backing_inode(old_dentry)->i_mode
> 

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-20  4:56 Stephen Rothwell
@ 2017-06-20  5:39 ` Kees Cook
  2017-06-20  5:42   ` John Johansen
  2017-06-20  5:39 ` John Johansen
  1 sibling, 1 reply; 35+ messages in thread
From: Kees Cook @ 2017-06-20  5:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: James Morris, Linux-Next Mailing List, Linux Kernel Mailing List,
	John Johansen

On Mon, Jun 19, 2017 at 9:56 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the kspp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> security/apparmor/file.c: In function 'aa_path_link':
> security/apparmor/file.c:475:23: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>                        ^
> security/apparmor/file.c:475:23: note: (near initialization for 'link')
> security/apparmor/file.c:475:37: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>                                      ^
> security/apparmor/file.c:475:37: note: (near initialization for 'link')
> security/apparmor/file.c:476:25: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>                          ^
> security/apparmor/file.c:476:25: note: (near initialization for 'target')
> security/apparmor/file.c:476:39: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>                                        ^
> security/apparmor/file.c:476:39: note: (near initialization for 'target')
>
> Caused by commit
>
>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
>
> interacting with commit
>
>   8014370f1257 ("apparmor: move path_link mediation to using labels")
>
> from the security tree.
>
> I added the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 20 Jun 2017 14:50:36 +1000
> Subject: [PATCH] apparmor: put back designators in struct initialisers
>
> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  security/apparmor/file.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index b6e8e5b11e05..3382518b87fa 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
>  int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
>                  const struct path *new_dir, struct dentry *new_dentry)
>  {
> -       struct path link = { new_dir->mnt, new_dentry };
> -       struct path target = { new_dir->mnt, old_dentry };
> +       struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
> +       struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
>         struct path_cond cond = {
>                 d_backing_inode(old_dentry)->i_uid,
>                 d_backing_inode(old_dentry)->i_mode
> --
> 2.11.0

Thanks for the fix! That looks correct to me. It seems the refactoring
in 8014370f1257 ("apparmor: move path_link mediation to using labels")
didn't take 8486adf0d755 ("apparmor: use designated initializers")
into account. John, if this looks okay, can you Ack it for James to
carry in security-next?

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 35+ messages in thread

* linux-next: build failure after merge of the kspp tree
@ 2017-06-20  4:56 Stephen Rothwell
  2017-06-20  5:39 ` Kees Cook
  2017-06-20  5:39 ` John Johansen
  0 siblings, 2 replies; 35+ messages in thread
From: Stephen Rothwell @ 2017-06-20  4:56 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, John Johansen

Hi all,

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

security/apparmor/file.c: In function 'aa_path_link':
security/apparmor/file.c:475:23: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path link = { new_dir->mnt, new_dentry };
                       ^
security/apparmor/file.c:475:23: note: (near initialization for 'link')
security/apparmor/file.c:475:37: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path link = { new_dir->mnt, new_dentry };
                                     ^
security/apparmor/file.c:475:37: note: (near initialization for 'link')
security/apparmor/file.c:476:25: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path target = { new_dir->mnt, old_dentry };
                         ^
security/apparmor/file.c:476:25: note: (near initialization for 'target')
security/apparmor/file.c:476:39: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path target = { new_dir->mnt, old_dentry };
                                       ^
security/apparmor/file.c:476:39: note: (near initialization for 'target')

Caused by commit

  1a12979f61e4 ("randstruct: Mark various structs for randomization")

interacting with commit

  8014370f1257 ("apparmor: move path_link mediation to using labels")

from the security tree.

I added the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 20 Jun 2017 14:50:36 +1000
Subject: [PATCH] apparmor: put back designators in struct initialisers

Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 security/apparmor/file.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index b6e8e5b11e05..3382518b87fa 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
 int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
 		 const struct path *new_dir, struct dentry *new_dentry)
 {
-	struct path link = { new_dir->mnt, new_dentry };
-	struct path target = { new_dir->mnt, old_dentry };
+	struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
+	struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
 	struct path_cond cond = {
 		d_backing_inode(old_dentry)->i_uid,
 		d_backing_inode(old_dentry)->i_mode
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-19  0:23       ` Stephen Rothwell
@ 2017-06-19 21:01         ` Kees Cook
  0 siblings, 0 replies; 35+ messages in thread
From: Kees Cook @ 2017-06-19 21:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Micay, Linux-Next Mailing List, Linux Kernel Mailing List,
	Andrew Morton

On Sun, Jun 18, 2017 at 5:23 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Stephen,
>
> On Fri, 16 Jun 2017 13:31:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi Kees,
>>
>> On Thu, 15 Jun 2017 20:20:47 -0700 Kees Cook <keescook@google.com> wrote:
>> >
>> > I'm so confused -- isn't this in next? All the build tests I did were
>> > against yesterday's -next which includes this from what I can see...
>>
>> It is in next, but gets merged after the kspp tree ... so, this is when
>> inter-tree dependencies are a pain - I can merge the kspp tree later,
>> but then you have to remember which trees Linus must merge before you
>> send your pull request.  That's why we like to have all trees be
>> effectively stand alone (as much as possible).
>
> OK, for now I have moved the merging of the kspp tree to after
> everything else (except Andrew's quilt series).  This will
> (unfortunately) hide some dependencies between trees.

In the other thread Andrew asked that I just have it all go through
-mm, so I've removed it from KSPP and sent the series his way (with
you in Cc).

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-16  3:31     ` Stephen Rothwell
@ 2017-06-19  0:23       ` Stephen Rothwell
  2017-06-19 21:01         ` Kees Cook
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Rothwell @ 2017-06-19  0:23 UTC (permalink / raw)
  To: Kees Cook
  Cc: Daniel Micay, Linux-Next Mailing List, Linux Kernel Mailing List,
	Andrew Morton

Hi Stephen,

On Fri, 16 Jun 2017 13:31:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Kees,
> 
> On Thu, 15 Jun 2017 20:20:47 -0700 Kees Cook <keescook@google.com> wrote:
> >
> > I'm so confused -- isn't this in next? All the build tests I did were
> > against yesterday's -next which includes this from what I can see...  
> 
> It is in next, but gets merged after the kspp tree ... so, this is when
> inter-tree dependencies are a pain - I can merge the kspp tree later,
> but then you have to remember which trees Linus must merge before you
> send your pull request.  That's why we like to have all trees be
> effectively stand alone (as much as possible).

OK, for now I have moved the merging of the kspp tree to after
everything else (except Andrew's quilt series).  This will
(unfortunately) hide some dependencies between trees.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-16  3:20   ` Kees Cook
@ 2017-06-16  3:31     ` Stephen Rothwell
  2017-06-19  0:23       ` Stephen Rothwell
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Rothwell @ 2017-06-16  3:31 UTC (permalink / raw)
  To: Kees Cook
  Cc: Daniel Micay, Linux-Next Mailing List, Linux Kernel Mailing List,
	Andrew Morton

Hi Kees,

On Thu, 15 Jun 2017 20:20:47 -0700 Kees Cook <keescook@google.com> wrote:
>
> I'm so confused -- isn't this in next? All the build tests I did were
> against yesterday's -next which includes this from what I can see...

It is in next, but gets merged after the kspp tree ... so, this is when
inter-tree dependencies are a pain - I can merge the kspp tree later,
but then you have to remember which trees Linus must merge before you
send your pull request.  That's why we like to have all trees be
effectively stand alone (as much as possible).

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-16  2:51 ` Daniel Micay
  2017-06-16  2:52   ` Daniel Micay
@ 2017-06-16  3:20   ` Kees Cook
  2017-06-16  3:31     ` Stephen Rothwell
  1 sibling, 1 reply; 35+ messages in thread
From: Kees Cook @ 2017-06-16  3:20 UTC (permalink / raw)
  To: Daniel Micay
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Andrew Morton

On Thu, Jun 15, 2017 at 7:51 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Fri, 2017-06-16 at 11:30 +1000, Stephen Rothwell wrote:
>> Hi Kees,
>>
>> After merging the kspp 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 arch/x86/include/asm/cpumask.h:4,
>>                  from arch/x86/include/asm/msr.h:10,
>>                  from arch/x86/include/asm/processor.h:20,
>>                  from arch/x86/include/asm/cpufeature.h:4,
>>                  from arch/x86/include/asm/thread_info.h:52,
>>                  from include/linux/thread_info.h:37,
>>                  from arch/x86/include/asm/preempt.h:6,
>>                  from include/linux/preempt.h:80,
>>                  from include/linux/spinlock.h:50,
>>                  from include/linux/mmzone.h:7,
>>                  from include/linux/gfp.h:5,
>>                  from include/linux/slab.h:14,
>>                  from drivers/scsi/csiostor/csio_lnode.c:37:
>> In function 'memcpy',
>>     inlined from 'csio_append_attrib' at
>> drivers/scsi/csiostor/csio_lnode.c:248:2,
>>     inlined from 'csio_ln_fdmi_dprt_cbfn' at
>> drivers/scsi/csiostor/csio_lnode.c:471:2:
>> include/linux/string.h:309:4: error: call to '__read_overflow2'
>> declared with attribute error: detected read beyond size of object
>> passed as 2nd parameter
>>     __read_overflow2();
>>     ^
>> In function 'memcpy',
>>     inlined from 'csio_append_attrib' at
>> drivers/scsi/csiostor/csio_lnode.c:248:2,
>>     inlined from 'csio_ln_fdmi_rhba_cbfn' at
>> drivers/scsi/csiostor/csio_lnode.c:337:2:
>> include/linux/string.h:309: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
>>
>>   b90d6eba50d7 ("include/linux/string.h: add the option of fortified
>> string.h functions")
>>
>> I have reverted that commit for today.
>
> That's this one: https://lkml.org/lkml/2017/5/9/613, which is in
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/ in the
> 4.13/scsi-queue and for-next branches. I think that's why Kees didn't
> include it but I get he needs to add that.

I'm so confused -- isn't this in next? All the build tests I did were
against yesterday's -next which includes this from what I can see...

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-16  2:51 ` Daniel Micay
@ 2017-06-16  2:52   ` Daniel Micay
  2017-06-16  3:20   ` Kees Cook
  1 sibling, 0 replies; 35+ messages in thread
From: Daniel Micay @ 2017-06-16  2:52 UTC (permalink / raw)
  To: Stephen Rothwell, Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andrew Morton

> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/ in the
> 4.13/scsi-queue and for-next branches. I think that's why Kees didn't
> include it but I get he needs to add that.

s/get/guess/

Or is that repo supposed to get pulled into next?

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linux-next: build failure after merge of the kspp tree
  2017-06-16  1:30 Stephen Rothwell
@ 2017-06-16  2:51 ` Daniel Micay
  2017-06-16  2:52   ` Daniel Micay
  2017-06-16  3:20   ` Kees Cook
  0 siblings, 2 replies; 35+ messages in thread
From: Daniel Micay @ 2017-06-16  2:51 UTC (permalink / raw)
  To: Stephen Rothwell, Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andrew Morton

On Fri, 2017-06-16 at 11:30 +1000, Stephen Rothwell wrote:
> Hi Kees,
> 
> After merging the kspp 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 arch/x86/include/asm/cpumask.h:4,
>                  from arch/x86/include/asm/msr.h:10,
>                  from arch/x86/include/asm/processor.h:20,
>                  from arch/x86/include/asm/cpufeature.h:4,
>                  from arch/x86/include/asm/thread_info.h:52,
>                  from include/linux/thread_info.h:37,
>                  from arch/x86/include/asm/preempt.h:6,
>                  from include/linux/preempt.h:80,
>                  from include/linux/spinlock.h:50,
>                  from include/linux/mmzone.h:7,
>                  from include/linux/gfp.h:5,
>                  from include/linux/slab.h:14,
>                  from drivers/scsi/csiostor/csio_lnode.c:37:
> In function 'memcpy',
>     inlined from 'csio_append_attrib' at
> drivers/scsi/csiostor/csio_lnode.c:248:2,
>     inlined from 'csio_ln_fdmi_dprt_cbfn' at
> drivers/scsi/csiostor/csio_lnode.c:471:2:
> include/linux/string.h:309:4: error: call to '__read_overflow2'
> declared with attribute error: detected read beyond size of object
> passed as 2nd parameter
>     __read_overflow2();
>     ^
> In function 'memcpy',
>     inlined from 'csio_append_attrib' at
> drivers/scsi/csiostor/csio_lnode.c:248:2,
>     inlined from 'csio_ln_fdmi_rhba_cbfn' at
> drivers/scsi/csiostor/csio_lnode.c:337:2:
> include/linux/string.h:309: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
> 
>   b90d6eba50d7 ("include/linux/string.h: add the option of fortified
> string.h functions")
> 
> I have reverted that commit for today.

That's this one: https://lkml.org/lkml/2017/5/9/613, which is in
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/ in the
4.13/scsi-queue and for-next branches. I think that's why Kees didn't
include it but I get he needs to add that.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* linux-next: build failure after merge of the kspp tree
@ 2017-06-16  1:30 Stephen Rothwell
  2017-06-16  2:51 ` Daniel Micay
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Rothwell @ 2017-06-16  1:30 UTC (permalink / raw)
  To: Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Daniel Micay,
	Andrew Morton

Hi Kees,

After merging the kspp 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 arch/x86/include/asm/cpumask.h:4,
                 from arch/x86/include/asm/msr.h:10,
                 from arch/x86/include/asm/processor.h:20,
                 from arch/x86/include/asm/cpufeature.h:4,
                 from arch/x86/include/asm/thread_info.h:52,
                 from include/linux/thread_info.h:37,
                 from arch/x86/include/asm/preempt.h:6,
                 from include/linux/preempt.h:80,
                 from include/linux/spinlock.h:50,
                 from include/linux/mmzone.h:7,
                 from include/linux/gfp.h:5,
                 from include/linux/slab.h:14,
                 from drivers/scsi/csiostor/csio_lnode.c:37:
In function 'memcpy',
    inlined from 'csio_append_attrib' at drivers/scsi/csiostor/csio_lnode.c:248:2,
    inlined from 'csio_ln_fdmi_dprt_cbfn' at drivers/scsi/csiostor/csio_lnode.c:471:2:
include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
    __read_overflow2();
    ^
In function 'memcpy',
    inlined from 'csio_append_attrib' at drivers/scsi/csiostor/csio_lnode.c:248:2,
    inlined from 'csio_ln_fdmi_rhba_cbfn' at drivers/scsi/csiostor/csio_lnode.c:337:2:
include/linux/string.h:309: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

  b90d6eba50d7 ("include/linux/string.h: add the option of fortified string.h functions")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, back to index

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-21 13:48 linux-next: build failure after merge of the kspp tree Stephen Rothwell
2020-06-21 15:36 ` Kees Cook
  -- strict thread matches above, loose matches on Subject: below --
2020-06-23  3:51 Stephen Rothwell
2020-06-23  3:56 ` David Miller
2018-07-27  9:02 Stephen Rothwell
2018-07-27  9:06 ` Stephen Rothwell
2018-07-27 10:55   ` Stephen Rothwell
2018-07-27 12:55     ` Will Deacon
2018-07-27 13:01       ` Will Deacon
2018-07-27 13:27         ` Will Deacon
2018-07-27 16:00           ` Kees Cook
2018-07-30  7:33       ` Stephen Rothwell
2018-07-30 14:47         ` Laura Abbott
2018-07-30 16:37           ` Will Deacon
2018-07-31 10:09         ` Will Deacon
2018-07-31 11:27           ` Stephen Rothwell
2017-11-08  5:23 Stephen Rothwell
2017-11-08 23:43 ` Kees Cook
2017-11-09  0:18   ` Darrick J. Wong
2017-11-09  0:31     ` Kees Cook
2017-06-20  4:56 Stephen Rothwell
2017-06-20  5:39 ` Kees Cook
2017-06-20  5:42   ` John Johansen
2017-06-20  5:39 ` John Johansen
2017-06-26 18:19   ` Kees Cook
2017-06-27  3:33     ` James Morris
2017-06-27 22:16       ` Kees Cook
2017-06-28  5:48         ` James Morris
2017-06-16  1:30 Stephen Rothwell
2017-06-16  2:51 ` Daniel Micay
2017-06-16  2:52   ` Daniel Micay
2017-06-16  3:20   ` Kees Cook
2017-06-16  3:31     ` Stephen Rothwell
2017-06-19  0:23       ` Stephen Rothwell
2017-06-19 21:01         ` Kees Cook

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git