fs/bcachefs/bcachefs_format.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Hi all,
After merging the origin tree, today's linux-next build (s390 defconfig)
failed like this:
In file included from fs/bcachefs/bset.h:9,
from fs/bcachefs/btree_iter.h:5,
from fs/bcachefs/str_hash.h:5,
from fs/bcachefs/xattr.h:5,
from fs/bcachefs/acl.c:6:
fs/bcachefs/bkey.h: In function 'bch2_bkey_format_add_key':
fs/bcachefs/bkey.h:557:41: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
557 | x(BKEY_FIELD_VERSION_HI, bversion.hi) \
| ^~~~~~~~
fs/bcachefs/bkey.h:578:50: note: in definition of macro 'x'
578 | #define x(id, field) __bkey_format_add(s, id, k->field);
| ^~~~~
fs/bcachefs/bkey.h:579:9: note: in expansion of macro 'bkey_fields'
579 | bkey_fields()
| ^~~~~~~~~~~
fs/bcachefs/bkey.h:558:41: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
558 | x(BKEY_FIELD_VERSION_LO, bversion.lo)
| ^~~~~~~~
fs/bcachefs/bkey.h:578:50: note: in definition of macro 'x'
578 | #define x(id, field) __bkey_format_add(s, id, k->field);
| ^~~~~
fs/bcachefs/bkey.h:579:9: note: in expansion of macro 'bkey_fields'
579 | bkey_fields()
| ^~~~~~~~~~~
In file included from fs/bcachefs/bset.h:10:
fs/bcachefs/bkey_methods.h: In function 'bch2_bkey_maybe_mergable':
fs/bcachefs/bkey_methods.h:73:34: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
73 | !bversion_cmp(l->bversion, r->bversion) &&
| ^~~~~~~~
| version
fs/bcachefs/bkey_methods.h:73:47: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
73 | !bversion_cmp(l->bversion, r->bversion) &&
| ^~~~~~~~
| version
In file included from fs/bcachefs/extents.h:6,
from fs/bcachefs/buckets.h:12,
from fs/bcachefs/alloc_background.h:7,
from fs/bcachefs/alloc_foreground.c:15:
fs/bcachefs/bkey.h: In function 'bch2_bkey_format_add_key':
fs/bcachefs/bkey.h:557:41: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
557 | x(BKEY_FIELD_VERSION_HI, bversion.hi) \
| ^~~~~~~~
fs/bcachefs/bkey.h:578:50: note: in definition of macro 'x'
578 | #define x(id, field) __bkey_format_add(s, id, k->field);
| ^~~~~
fs/bcachefs/bkey.h:579:9: note: in expansion of macro 'bkey_fields'
579 | bkey_fields()
| ^~~~~~~~~~~
fs/bcachefs/bkey.h:558:41: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
558 | x(BKEY_FIELD_VERSION_LO, bversion.lo)
| ^~~~~~~~
fs/bcachefs/bkey.h:578:50: note: in definition of macro 'x'
578 | #define x(id, field) __bkey_format_add(s, id, k->field);
| ^~~~~
fs/bcachefs/bkey.h:579:9: note: in expansion of macro 'bkey_fields'
579 | bkey_fields()
| ^~~~~~~~~~~
In file included from fs/bcachefs/btree_cache.h:7,
from fs/bcachefs/backpointers.h:5,
from fs/bcachefs/alloc_foreground.c:17:
fs/bcachefs/bkey_methods.h: In function 'bch2_bkey_maybe_mergable':
fs/bcachefs/bkey_methods.h:73:34: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
73 | !bversion_cmp(l->bversion, r->bversion) &&
| ^~~~~~~~
| version
fs/bcachefs/bkey_methods.h:73:47: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
73 | !bversion_cmp(l->bversion, r->bversion) &&
| ^~~~~~~~
| version
In file included from fs/bcachefs/extents.h:6,
from fs/bcachefs/buckets.h:12,
from fs/bcachefs/alloc_background.h:7,
from fs/bcachefs/alloc_background.c:3:
fs/bcachefs/bkey.h: In function 'bch2_bkey_format_add_key':
fs/bcachefs/bkey.h:557:41: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
557 | x(BKEY_FIELD_VERSION_HI, bversion.hi) \
| ^~~~~~~~
fs/bcachefs/bkey.h:578:50: note: in definition of macro 'x'
578 | #define x(id, field) __bkey_format_add(s, id, k->field);
| ^~~~~
fs/bcachefs/bkey.h:579:9: note: in expansion of macro 'bkey_fields'
579 | bkey_fields()
| ^~~~~~~~~~~
fs/bcachefs/bkey.h:558:41: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
558 | x(BKEY_FIELD_VERSION_LO, bversion.lo)
| ^~~~~~~~
fs/bcachefs/bkey.h:578:50: note: in definition of macro 'x'
578 | #define x(id, field) __bkey_format_add(s, id, k->field);
| ^~~~~
fs/bcachefs/bkey.h:579:9: note: in expansion of macro 'bkey_fields'
579 | bkey_fields()
| ^~~~~~~~~~~
In file included from fs/bcachefs/btree_cache.h:7,
from fs/bcachefs/backpointers.h:5,
from fs/bcachefs/alloc_background.c:5:
fs/bcachefs/bkey_methods.h: In function 'bch2_bkey_maybe_mergable':
fs/bcachefs/bkey_methods.h:73:34: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
73 | !bversion_cmp(l->bversion, r->bversion) &&
| ^~~~~~~~
| version
fs/bcachefs/bkey_methods.h:73:47: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
73 | !bversion_cmp(l->bversion, r->bversion) &&
| ^~~~~~~~
| version
In file included from fs/bcachefs/btree_write_buffer.h:6,
from fs/bcachefs/alloc_background.c:13:
fs/bcachefs/disk_accounting.h: In function 'bch2_accounting_accumulate':
fs/bcachefs/disk_accounting.h:39:33: error: 'struct bkey' has no member named 'bversion'; did you mean 'version'?
39 | if (bversion_cmp(dst->k.bversion, src.k->bversion) < 0)
| ^~~~~~~~
| version
fs/bcachefs/disk_accounting.h:39:50: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
39 | if (bversion_cmp(dst->k.bversion, src.k->bversion) < 0)
| ^~~~~~~~
| version
fs/bcachefs/disk_accounting.h:40:24: error: 'struct bkey' has no member named 'bversion'; did you mean 'version'?
40 | dst->k.bversion = src.k->bversion;
| ^~~~~~~~
| version
fs/bcachefs/disk_accounting.h:40:42: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
40 | dst->k.bversion = src.k->bversion;
| ^~~~~~~~
| version
Caused by commit
cf49f8a8c277 ("bcachefs: rename version -> bversion")
I have applied the following fix patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Sep 2024 13:31:16 +1000
Subject: [PATCH] fix up for "bcachefs: rename version -> bversion"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/bcachefs/bcachefs_format.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/bcachefs/bcachefs_format.h b/fs/bcachefs/bcachefs_format.h
index 203ee627cab5..84832c2d4df9 100644
--- a/fs/bcachefs/bcachefs_format.h
+++ b/fs/bcachefs/bcachefs_format.h
@@ -223,7 +223,7 @@ struct bkey {
#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
struct bpos p;
__u32 size; /* extent size, in sectors */
- struct bversion version;
+ struct bversion bversion;
__u8 pad[1];
#endif
--
2.45.2
--
Cheers,
Stephen Rothwell
On 30/09/2024 05:38, Stephen Rothwell wrote:
> Hi all,
>
> After merging the origin tree, today's linux-next build (s390 defconfig)
> failed like this:
>
> In file included from fs/bcachefs/bset.h:9,
> from fs/bcachefs/btree_iter.h:5,
> from fs/bcachefs/str_hash.h:5,
> from fs/bcachefs/xattr.h:5,
> from fs/bcachefs/acl.c:6:
> fs/bcachefs/bkey.h: In function 'bch2_bkey_format_add_key':
> fs/bcachefs/bkey.h:557:41: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'?
> 557 | x(BKEY_FIELD_VERSION_HI, bversion.hi) \
> | ^~~~~~~~
Also reported earlier here:
https://lore.kernel.org/all/202409272048.MZvBm569-lkp@intel.com/
https://lore.kernel.org/all/202409271712.EZRpO2Z1-lkp@intel.com/
But the true problem is here:
commit cf49f8a8c277f9f2b78e2a56189a741a508a9820
Author: Kent Overstreet <kent.overstreet@linux.dev>
AuthorDate: Thu Sep 26 15:49:17 2024 -0400
^^^^^^^^^^^
Commit: Kent Overstreet <kent.overstreet@linux.dev>
CommitDate: Fri Sep 27 21:46:35 2024 -0400
^^^^^^^^^^^ one day difference!
Last minute commits usually won't receive wide build coverage, at least
not instantaneously.
And if you go through the history, I see around 40 commits with authored
date ~20-26 September and committed on Sep 27. Plus another ~40 authored
earlier but committed on September 21, which is middle of merge window.
Why such commits for RC1 are sent at the end of merge window or
committed during merge window?
Best regards,
Krzysztof
Best regards,
Krzysztof
On Mon, Sep 30, 2024 at 12:28:40PM GMT, Krzysztof Kozlowski wrote: > On 30/09/2024 05:38, Stephen Rothwell wrote: > > Hi all, > > > > After merging the origin tree, today's linux-next build (s390 defconfig) > > failed like this: > > > > In file included from fs/bcachefs/bset.h:9, > > from fs/bcachefs/btree_iter.h:5, > > from fs/bcachefs/str_hash.h:5, > > from fs/bcachefs/xattr.h:5, > > from fs/bcachefs/acl.c:6: > > fs/bcachefs/bkey.h: In function 'bch2_bkey_format_add_key': > > fs/bcachefs/bkey.h:557:41: error: 'const struct bkey' has no member named 'bversion'; did you mean 'version'? > > 557 | x(BKEY_FIELD_VERSION_HI, bversion.hi) \ > > | ^~~~~~~~ > > > Also reported earlier here: > https://lore.kernel.org/all/202409272048.MZvBm569-lkp@intel.com/ > https://lore.kernel.org/all/202409271712.EZRpO2Z1-lkp@intel.com/ > > But the true problem is here: > > commit cf49f8a8c277f9f2b78e2a56189a741a508a9820 > Author: Kent Overstreet <kent.overstreet@linux.dev> > AuthorDate: Thu Sep 26 15:49:17 2024 -0400 > ^^^^^^^^^^^ > Commit: Kent Overstreet <kent.overstreet@linux.dev> > CommitDate: Fri Sep 27 21:46:35 2024 -0400 > ^^^^^^^^^^^ one day difference! > > Last minute commits usually won't receive wide build coverage, at least > not instantaneously. > > And if you go through the history, I see around 40 commits with authored > date ~20-26 September and committed on Sep 27. Plus another ~40 authored > earlier but committed on September 21, which is middle of merge window. > > Why such commits for RC1 are sent at the end of merge window or > committed during merge window? the rename was something I did to track down a bug in the disk accounting rewrite: https://lore.kernel.org/linux-bcachefs/pvga5sgp4vejnnr5ojgiuwte6qeve4x7ld4dhdmzb625l367fq@q4td2cutlfvu/T/ I do need to get multi-arch build testing going on my CI, but right now I'm busy working on corner cases in the repair code...
On 30/09/2024 12:50, Kent Overstreet wrote: > On Mon, Sep 30, 2024 at 12:28:40PM GMT, Krzysztof Kozlowski wrote: >> On 30/09/2024 05:38, Stephen Rothwell wrote: >>> Hi all, >>> >>> After merging the origin tree, today's linux-next build (s390 >>> defconfig) failed like this: >>> >>> In file included from fs/bcachefs/bset.h:9, from >>> fs/bcachefs/btree_iter.h:5, from fs/bcachefs/str_hash.h:5, from >>> fs/bcachefs/xattr.h:5, from fs/bcachefs/acl.c:6: >>> fs/bcachefs/bkey.h: In function 'bch2_bkey_format_add_key': >>> fs/bcachefs/bkey.h:557:41: error: 'const struct bkey' has no >>> member named 'bversion'; did you mean 'version'? 557 | >>> x(BKEY_FIELD_VERSION_HI, bversion.hi) >>> \ | ^~~~~~~~ >> >> >> Also reported earlier here: >> https://lore.kernel.org/all/202409272048.MZvBm569-lkp@intel.com/ >> https://lore.kernel.org/all/202409271712.EZRpO2Z1-lkp@intel.com/ >> >> But the true problem is here: >> >> commit cf49f8a8c277f9f2b78e2a56189a741a508a9820 Author: Kent >> Overstreet <kent.overstreet@linux.dev> AuthorDate: Thu Sep 26 >> 15:49:17 2024 -0400 ^^^^^^^^^^^ Commit: Kent Overstreet >> <kent.overstreet@linux.dev> CommitDate: Fri Sep 27 21:46:35 2024 >> -0400 ^^^^^^^^^^^ one day difference! >> >> Last minute commits usually won't receive wide build coverage, at >> least not instantaneously. >> >> And if you go through the history, I see around 40 commits with >> authored date ~20-26 September and committed on Sep 27. Plus >> another ~40 authored earlier but committed on September 21, which >> is middle of merge window. >> >> Why such commits for RC1 are sent at the end of merge window or >> committed during merge window? > > the rename was something I did to track down a bug in the disk > accounting rewrite: > https://lore.kernel.org/linux-bcachefs/pvga5sgp4vejnnr5ojgiuwte6qeve4x7ld4dhdmzb625l367fq@q4td2cutlfvu/T/ I am sorry, but I do not see how cleanup-like rename is related to tracking down a tricky bug and fixing it. Looks like fixes got inter-mixed with such minor refactoring. > > I do need to get multi-arch build testing going on my CI, but right > now I'm busy working on corner cases in the repair code... Well, I claim it is easy, if you wait one day for the notification from LKP - I got notification after every push, also on success, so I am sure that my kernel (and development, but that's unrelated) builds fine on wide configuration. And this is free as in free beer... Best regards, Krzysztof
© 2016 - 2024 Red Hat, Inc.