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

2020-06-22 Thread David Miller 
From: Stephen Rothwell 
Date: Tue, 23 Jun 2020 13:51:34 +1000

> I have added the following merge fix patch.
> 
> From: Stephen Rothwell 
> 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 

Applied, thanks Stephen.

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

2020-06-22 Thread Stephen Rothwell 
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 
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 
---
 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


pgporbrv9iX5c.pgp
Description: OpenPGP digital signature

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

2020-06-21 Thread Kees Cook 
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

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

2020-06-21 Thread Stephen Rothwell 
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


pgpkRax3NVPxQ.pgp
Description: OpenPGP digital signature

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

2018-07-31 Thread Stephen Rothwell 
Hi Will,

On Tue, 31 Jul 2018 11:09:18 +0100 Will Deacon  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


pgpoExjvTlxUO.pgp
Description: OpenPGP digital signature

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

2018-07-31 Thread Will Deacon 
On Mon, Jul 30, 2018 at 05:33:56PM +1000, Stephen Rothwell wrote:
> On Fri, 27 Jul 2018 13:55:22 +0100 Will Deacon  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/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.

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

Will

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

2018-07-30 Thread Will Deacon 
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  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/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.
> >
> 
> 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-0udkkit0wenfm3...@mail.gmail.com/T/#m1bd3d2de78e33da4d1f496fd82be7cf088ebaa06

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

Cheers,

Will

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

2018-07-30 Thread Laura Abbott 

On 07/30/2018 12:33 AM, Stephen Rothwell wrote:

Hi all,

On Fri, 27 Jul 2018 13:55:22 +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  
wrote:


On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell  
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.



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

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

2018-07-30 Thread Stephen Rothwell 
Hi all,

On Fri, 27 Jul 2018 13:55:22 +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  
> > wrote:  
> > >
> > > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell 
> > >  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


pgpVMy44VOpzJ.pgp
Description: OpenPGP digital signature

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

2018-07-27 Thread Kees Cook 
On Fri, Jul 27, 2018 at 6:27 AM, Will Deacon  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 
>> > >  wrote:
>> > > >
>> > > > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell 
>> > > >  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

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

2018-07-27 Thread Will Deacon 
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 
> > >  wrote:
> > > >
> > > > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell 
> > > >  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

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

2018-07-27 Thread Will Deacon 
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  
> > wrote:
> > >
> > > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell 
> > >  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

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

2018-07-27 Thread Will Deacon 
On Fri, Jul 27, 2018 at 08:55:11PM +1000, Stephen Rothwell wrote:
> On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell  
> wrote:
> >
> > On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell  
> > 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?

Will

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

2018-07-27 Thread Stephen Rothwell 
Hi all,

On Fri, 27 Jul 2018 19:06:47 +1000 Stephen Rothwell  
wrote:
>
> On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell  
> 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


pgp2ms8O006cJ.pgp
Description: OpenPGP digital signature

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

2018-07-27 Thread Stephen Rothwell 
Hi all,

On Fri, 27 Jul 2018 19:02:07 +1000 Stephen Rothwell  
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


pgpQqB8nJ3dhz.pgp
Description: OpenPGP digital signature

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

2018-07-27 Thread Stephen Rothwell 
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


pgpbUvqThIvGt.pgp
Description: OpenPGP digital signature

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

2017-11-08 Thread Kees Cook 
On Wed, Nov 8, 2017 at 4:18 PM, Darrick J. Wong  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

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

2017-11-08 Thread Darrick J. Wong 
On Wed, Nov 08, 2017 at 03:43:47PM -0800, Kees Cook wrote:
> On Tue, Nov 7, 2017 at 9:23 PM, Stephen Rothwell  
> 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) sizeofstructure *)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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-11-08 Thread Kees Cook 
On Tue, Nov 7, 2017 at 9:23 PM, Stephen Rothwell  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) sizeofstructure *)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

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

2017-11-07 Thread Stephen Rothwell 
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) sizeofstructure *)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

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

2017-06-27 Thread James Morris 
On Tue, 27 Jun 2017, Kees Cook wrote:

> On Mon, Jun 26, 2017 at 8:33 PM, James Morris  wrote:
> > On Mon, 26 Jun 2017, Kees Cook wrote:
> >
> >> >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using 
> >> >> labels")
> >> >> Signed-off-by: Stephen Rothwell 
> >> > Acked-by: John Johansen 
> >>
> >> 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

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

2017-06-27 Thread Kees Cook 
On Mon, Jun 26, 2017 at 8:33 PM, James Morris  wrote:
> On Mon, 26 Jun 2017, Kees Cook wrote:
>
>> >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
>> >> Signed-off-by: Stephen Rothwell 
>> > Acked-by: John Johansen 
>>
>> 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

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

2017-06-26 Thread James Morris 
On Mon, 26 Jun 2017, Kees Cook wrote:

> >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
> >> Signed-off-by: Stephen Rothwell 
> > Acked-by: John Johansen 
> 
> 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

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

2017-06-26 Thread Kees Cook 
On Mon, Jun 19, 2017 at 10:39 PM, John Johansen
 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 
>> 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 
> Acked-by: John Johansen 

Hi James,

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

Acked-by: Kees Cook 

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

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

2017-06-19 Thread John Johansen 
On 06/19/2017 10:39 PM, Kees Cook wrote:
> On Mon, Jun 19, 2017 at 9: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 
>> 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 
>> ---
>>  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 :(

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

2017-06-19 Thread Kees Cook 
On Mon, Jun 19, 2017 at 9: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 
> 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 
> ---
>  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

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

2017-06-19 Thread John Johansen 
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 
> 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 
Acked-by: John Johansen 

> ---
>  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
>

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

2017-06-19 Thread Stephen Rothwell 
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 
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 
---
 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

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

2017-06-19 Thread Kees Cook 
On Sun, Jun 18, 2017 at 5:23 PM, Stephen Rothwell  wrote:
> Hi Stephen,
>
> On Fri, 16 Jun 2017 13:31:44 +1000 Stephen Rothwell  
> wrote:
>>
>> Hi Kees,
>>
>> On Thu, 15 Jun 2017 20:20:47 -0700 Kees Cook  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

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

2017-06-18 Thread Stephen Rothwell 
Hi Stephen,

On Fri, 16 Jun 2017 13:31:44 +1000 Stephen Rothwell  
wrote:
>
> Hi Kees,
> 
> On Thu, 15 Jun 2017 20:20:47 -0700 Kees Cook  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

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

2017-06-15 Thread Stephen Rothwell 
Hi Kees,

On Thu, 15 Jun 2017 20:20:47 -0700 Kees Cook  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

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

2017-06-15 Thread Kees Cook 
On Thu, Jun 15, 2017 at 7:51 PM, Daniel Micay  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

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

2017-06-15 Thread Daniel Micay 
> 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?

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

2017-06-15 Thread Daniel Micay 
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.

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

2017-06-15 Thread Stephen Rothwell 
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