Hi all,
[I am not sure why this error only popped up after I merged Andrew's
patch set ...]
After merging the btrfs tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/string.h:253,
from include/linux/bitmap.h:11,
from include/linux/cpumask.h:12,
from arch/x86/include/asm/cpumask.h:5,
from arch/x86/include/asm/msr.h:11,
from arch/x86/include/asm/processor.h:22,
from arch/x86/include/asm/cpufeature.h:5,
from arch/x86/include/asm/thread_info.h:53,
from include/linux/thread_info.h:60,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:55,
from include/linux/wait.h:9,
from include/linux/mempool.h:8,
from include/linux/bio.h:8,
from fs/btrfs/ioctl.c:7:
In function 'memcpy',
inlined from '_btrfs_ioctl_send' at fs/btrfs/ioctl.c:4846:3:
include/linux/fortify-string.h:219:4: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object (1st parameter)
219 | __write_overflow();
| ^~~~~~~~~~~~~~~~~~
Caused by commit
c8d9cdfc766d ("btrfs: send: prepare for v2 protocol")
This changes the "reserved" field of struct btrfs_ioctl_send_args from 4 u64's to 3, but the above memcpy is copying the "reserved" filed from a struct btrfs_ioctl_send_args_32 (4 u64s) into it.
All I could really do at this point was mark BTRFS_FS as BROKEN
(TEST_KMOD selects BTRFS_FS):
From: Stephen Rothwell <[email protected]>
Date: Wed, 27 Oct 2021 20:53:24 +1100
Subject: [PATCH] make btrfs as BROKEN due to an inconsistent API change
Signed-off-by: Stephen Rothwell <[email protected]>
---
fs/btrfs/Kconfig | 1 +
lib/Kconfig.debug | 1 +
2 files changed, 2 insertions(+)
diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index 520a0f6a7d9e..f7dd994a88af 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -20,6 +20,7 @@ config BTRFS_FS
select SRCU
depends on !PPC_256K_PAGES # powerpc
depends on !PAGE_SIZE_256KB # hexagon
+ depends on BROKEN
help
Btrfs is a general purpose copy-on-write filesystem with extents,
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 0104cafd403f..44a6df361016 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2491,6 +2491,7 @@ config TEST_KMOD
depends on m
depends on NETDEVICES && NET_CORE && INET # for TUN
depends on BLOCK
+ depends on BROKEN
select TEST_LKM
select XFS_FS
select TUN
--
2.33.0
--
Cheers,
Stephen Rothwell
Hi all,
On Wed, 27 Oct 2021 21:09:24 +1100 Stephen Rothwell <[email protected]> wrote:
>
> [I am not sure why this error only popped up after I merged Andrew's
> patch set ...]
>
> After merging the btrfs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/string.h:253,
> from include/linux/bitmap.h:11,
> from include/linux/cpumask.h:12,
> from arch/x86/include/asm/cpumask.h:5,
> from arch/x86/include/asm/msr.h:11,
> from arch/x86/include/asm/processor.h:22,
> from arch/x86/include/asm/cpufeature.h:5,
> from arch/x86/include/asm/thread_info.h:53,
> from include/linux/thread_info.h:60,
> from arch/x86/include/asm/preempt.h:7,
> from include/linux/preempt.h:78,
> from include/linux/spinlock.h:55,
> from include/linux/wait.h:9,
> from include/linux/mempool.h:8,
> from include/linux/bio.h:8,
> from fs/btrfs/ioctl.c:7:
> In function 'memcpy',
> inlined from '_btrfs_ioctl_send' at fs/btrfs/ioctl.c:4846:3:
> include/linux/fortify-string.h:219:4: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object (1st parameter)
> 219 | __write_overflow();
> | ^~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
> c8d9cdfc766d ("btrfs: send: prepare for v2 protocol")
>
> This changes the "reserved" field of struct btrfs_ioctl_send_args from 4 u64's to 3, but the above memcpy is copying the "reserved" filed from a struct btrfs_ioctl_send_args_32 (4 u64s) into it.
>
> All I could really do at this point was mark BTRFS_FS as BROKEN
> (TEST_KMOD selects BTRFS_FS):
>
> From: Stephen Rothwell <[email protected]>
> Date: Wed, 27 Oct 2021 20:53:24 +1100
> Subject: [PATCH] make btrfs as BROKEN due to an inconsistent API change
>
> Signed-off-by: Stephen Rothwell <[email protected]>
> ---
> fs/btrfs/Kconfig | 1 +
> lib/Kconfig.debug | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
> index 520a0f6a7d9e..f7dd994a88af 100644
> --- a/fs/btrfs/Kconfig
> +++ b/fs/btrfs/Kconfig
> @@ -20,6 +20,7 @@ config BTRFS_FS
> select SRCU
> depends on !PPC_256K_PAGES # powerpc
> depends on !PAGE_SIZE_256KB # hexagon
> + depends on BROKEN
>
> help
> Btrfs is a general purpose copy-on-write filesystem with extents,
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 0104cafd403f..44a6df361016 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2491,6 +2491,7 @@ config TEST_KMOD
> depends on m
> depends on NETDEVICES && NET_CORE && INET # for TUN
> depends on BLOCK
> + depends on BROKEN
> select TEST_LKM
> select XFS_FS
> select TUN
> --
> 2.33.0
Ping?
--
Cheers,
Stephen Rothwell
On Wed, Oct 27, 2021 at 09:09:24PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> [I am not sure why this error only popped up after I merged Andrew's
> patch set ...]
>
> After merging the btrfs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/string.h:253,
> from include/linux/bitmap.h:11,
> from include/linux/cpumask.h:12,
> from arch/x86/include/asm/cpumask.h:5,
> from arch/x86/include/asm/msr.h:11,
> from arch/x86/include/asm/processor.h:22,
> from arch/x86/include/asm/cpufeature.h:5,
> from arch/x86/include/asm/thread_info.h:53,
> from include/linux/thread_info.h:60,
> from arch/x86/include/asm/preempt.h:7,
> from include/linux/preempt.h:78,
> from include/linux/spinlock.h:55,
> from include/linux/wait.h:9,
> from include/linux/mempool.h:8,
> from include/linux/bio.h:8,
> from fs/btrfs/ioctl.c:7:
> In function 'memcpy',
> inlined from '_btrfs_ioctl_send' at fs/btrfs/ioctl.c:4846:3:
> include/linux/fortify-string.h:219:4: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object (1st parameter)
> 219 | __write_overflow();
> | ^~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
> c8d9cdfc766d ("btrfs: send: prepare for v2 protocol")
>
> This changes the "reserved" field of struct btrfs_ioctl_send_args from 4 u64's to 3, but the above memcpy is copying the "reserved" filed from a struct btrfs_ioctl_send_args_32 (4 u64s) into it.
I'll fix it in the next update. There are two structures for the ioctl
that need to be in sync but I forgot to do that.
On Fri, Oct 29, 2021 at 11:52:26AM +0200, David Sterba wrote:
> On Wed, Oct 27, 2021 at 09:09:24PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > [I am not sure why this error only popped up after I merged Andrew's
> > patch set ...]
> >
> > After merging the btrfs tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from include/linux/string.h:253,
> > from include/linux/bitmap.h:11,
> > from include/linux/cpumask.h:12,
> > from arch/x86/include/asm/cpumask.h:5,
> > from arch/x86/include/asm/msr.h:11,
> > from arch/x86/include/asm/processor.h:22,
> > from arch/x86/include/asm/cpufeature.h:5,
> > from arch/x86/include/asm/thread_info.h:53,
> > from include/linux/thread_info.h:60,
> > from arch/x86/include/asm/preempt.h:7,
> > from include/linux/preempt.h:78,
> > from include/linux/spinlock.h:55,
> > from include/linux/wait.h:9,
> > from include/linux/mempool.h:8,
> > from include/linux/bio.h:8,
> > from fs/btrfs/ioctl.c:7:
> > In function 'memcpy',
> > inlined from '_btrfs_ioctl_send' at fs/btrfs/ioctl.c:4846:3:
> > include/linux/fortify-string.h:219:4: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object (1st parameter)
> > 219 | __write_overflow();
> > | ^~~~~~~~~~~~~~~~~~
> >
> > Caused by commit
> >
> > c8d9cdfc766d ("btrfs: send: prepare for v2 protocol")
> >
> > This changes the "reserved" field of struct btrfs_ioctl_send_args from 4 u64's to 3, but the above memcpy is copying the "reserved" filed from a struct btrfs_ioctl_send_args_32 (4 u64s) into it.
>
> I'll fix it in the next update. There are two structures for the ioctl
> that need to be in sync but I forgot to do that.
Now pushed with top commit 764ada31357678.
Also I think that next time you can use some older version of the
for-next branch instead of making the whole subsystem depend on BROKEN.
This causes much more harm in the testing setups that suddenly can't
work at all, compared to testing a few days older branch.
On Fri, Oct 29, 2021 at 01:58:53PM +0300, Andy Shevchenko wrote:
> On Friday, October 29, 2021, David Sterba <[email protected]> wrote:
>
> > On Fri, Oct 29, 2021 at 11:52:26AM +0200, David Sterba wrote:
> > > On Wed, Oct 27, 2021 at 09:09:24PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > [I am not sure why this error only popped up after I merged Andrew's
> > > > patch set ...]
> >
> >
>
>
>
> > Also I think that next time you can use some older version of the
> > for-next branch instead of making the whole subsystem depend on BROKEN.
> > This causes much more harm in the testing setups that suddenly can't
> > work at all, compared to testing a few days older branch.
>
> The Linux Next reflects current state of affairs and marking something
> which is definitely broken as BROCKEN is what I expect as a developer who
> tests some other stuff on top of broken code.
I'd argue against using the big 'depdends BROKEN' hammer as much as
possible, surely not for linux-next. Normaly the BROKEN status is earned
after known unfixed breakage for subsystems where nobody cares. If code
is buggy and causes crashes when testing linux-next, that's something we
want to see, not "no test results at all".
Can you imagine all compilation breakages in linux-next get resolved by
BROKEN? I know Stephen is capable of fixing various compilation problems
by himself and given the whole-tree scope it's heroic efforts, leaving
the shortcuts for the rest. In this case the fix may not be obvious so
I'd understand not merging my for-next branch at all or merging a stub
like the latest rc instead, ie. resolving that on the integration level
and not touching the config or code itself.
Hi David,
On Fri, 29 Oct 2021 14:14:09 +0200 David Sterba <[email protected]> wrote:
>
> On Fri, Oct 29, 2021 at 01:58:53PM +0300, Andy Shevchenko wrote:
> > On Friday, October 29, 2021, David Sterba <[email protected]> wrote:
> >
> > > On Fri, Oct 29, 2021 at 11:52:26AM +0200, David Sterba wrote:
> > > > On Wed, Oct 27, 2021 at 09:09:24PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > >
> > > > > [I am not sure why this error only popped up after I merged Andrew's
> > > > > patch set ...]
> > >
> > >
> >
> >
> >
> > > Also I think that next time you can use some older version of the
> > > for-next branch instead of making the whole subsystem depend on BROKEN.
> > > This causes much more harm in the testing setups that suddenly can't
> > > work at all, compared to testing a few days older branch.
> >
> > The Linux Next reflects current state of affairs and marking something
> > which is definitely broken as BROCKEN is what I expect as a developer who
> > tests some other stuff on top of broken code.
>
> I'd argue against using the big 'depdends BROKEN' hammer as much as
> possible, surely not for linux-next. Normaly the BROKEN status is earned
> after known unfixed breakage for subsystems where nobody cares. If code
> is buggy and causes crashes when testing linux-next, that's something we
> want to see, not "no test results at all".
>
> Can you imagine all compilation breakages in linux-next get resolved by
> BROKEN? I know Stephen is capable of fixing various compilation problems
> by himself and given the whole-tree scope it's heroic efforts, leaving
> the shortcuts for the rest. In this case the fix may not be obvious so
> I'd understand not merging my for-next branch at all or merging a stub
> like the latest rc instead, ie. resolving that on the integration level
> and not touching the config or code itself.
OK, this was a pain because the error did not show up until late in
the day (something in Andrew's patch series exposed the problem - note
my report was sent at 9:09 PM - my day starts about 7:30 AM). This is
after I had merged maybe 150-200 tress in top of yours. My choices are
few at that point (you don't expect me to remerge all those trees,
right?). Almost all errors I see are immediately after I merge a tree,
at which point my usual response is to reset my tree to before the
merge and then merge the previous day's version of the tree. Generally,
I do not fix build errors unless they are caused by an interaction
between 2 trees.
Given that I had spent some time to figure out what the problem was, I
expected a fix to be done pretty soon, so the easiest way I could
continue was to just mark btrfs broken and continue on (I still had
another hour to go before I was finished (my days get really long just
before Linus does a release :-( ).
--
Cheers,
Stephen Rothwell