linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: build warnings after merge of the btrfs tree
@ 2021-01-27  1:36 Stephen Rothwell
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2021-01-27  1:36 UTC (permalink / raw)
  To: David Sterba
  Cc: Nikolay Borisov, Jonathan Corbet, Mauro Carvalho Chehab,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the btrfs tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

fs/btrfs/file-item.c:44: warning: expecting prototype for s size according to filesystem options(). Prototype was for btrfs_inode_safe_disk_i_size_write() instead
fs/btrfs/file-item.c:82: warning: expecting prototype for Mark range within a file as having a new extent inserted(). Prototype was for btrfs_inode_set_file_extent_range() instead
fs/btrfs/file-item.c:110: warning: expecting prototype for Marks an inode range as not having a backing extent(). Prototype was for btrfs_inode_clear_file_extent_range() instead
fs/btrfs/file-item.c:354: warning: wrong kernel-doc identifier on line:
 * Lookup the checksum for the read bio in csum tree.
fs/btrfs/extent_map.c:402: warning: expecting prototype for Add new extent map to the extent tree(). Prototype was for add_extent_mapping() instead
fs/btrfs/extent_map.c:603: warning: expecting prototype for Add extent mapping into em_tree(). Prototype was for btrfs_add_extent_mapping() instead
fs/btrfs/extent_io.c:415: warning: expecting prototype for Such entry would have(). Prototype was for __etree_search() instead
fs/btrfs/extent_io.c:1609: warning: expecting prototype for Find a contiguous area of bits(). Prototype was for find_contiguous_extent_bit() instead
fs/btrfs/extent_io.c:1646: warning: expecting prototype for This range could start before(). Prototype was for find_first_clear_extent_bit() instead
fs/btrfs/extent_io.c:4260: warning: wrong kernel-doc identifier on line:
 * Walk the list of dirty pages of the given address space and write all of them.
fs/btrfs/delayed-ref.c:81: warning: expecting prototype for s reservation(). Prototype was for btrfs_delayed_refs_rsv_release() instead
fs/btrfs/delayed-ref.c:130: warning: expecting prototype for Transfer bytes to our delayed refs rsv(). Prototype was for btrfs_migrate_to_delayed_refs_rsv() instead
fs/btrfs/delayed-ref.c:177: warning: expecting prototype for Refill based on our delayed refs usage(). Prototype was for btrfs_delayed_refs_rsv_refill() instead
fs/btrfs/free-space-cache.c:1329: warning: expecting prototype for Write out cached info to an inode(). Prototype was for __btrfs_write_out_cache() instead
fs/btrfs/inode.c:3110: warning: expecting prototype for Wait for flushing all delayed iputs(). Prototype was for btrfs_wait_on_delayed_iputs() instead
fs/btrfs/backref.c:1525: warning: expecting prototype for Check if an extent is shared or not(). Prototype was for btrfs_check_shared() instead
fs/btrfs/discard.c:205: warning: expecting prototype for Wrap find_next_block_group(). Prototype was for peek_discard_list() instead
fs/btrfs/delalloc-space.c:207: warning: expecting prototype for Release any excessive reservation(). Prototype was for btrfs_inode_rsv_release() instead
fs/btrfs/delalloc-space.c:378: warning: expecting prototype for Release a metadata reservation for an inode(). Prototype was for btrfs_delalloc_release_metadata() instead
fs/btrfs/delalloc-space.c:477: warning: expecting prototype for Release data and metadata space for delalloc(). Prototype was for btrfs_delalloc_release_space() instead
fs/btrfs/space-info.c:572: warning: expecting prototype for Possibly commit the transaction if its ok to(). Prototype was for may_commit_transaction() instead
fs/btrfs/space-info.c:1373: warning: Function parameter or member 'start_ns' not described in 'handle_reserve_ticket'
fs/btrfs/space-info.c:1373: warning: Function parameter or member 'orig_bytes' not described in 'handle_reserve_ticket'
fs/btrfs/space-info.c:1373: warning: expecting prototype for Do the appropriate flushing and waiting for a ticket(). Prototype was for handle_reserve_ticket() instead
fs/btrfs/space-info.c:1478: warning: expecting prototype for s space(). Prototype was for __reserve_bytes() instead
fs/btrfs/space-info.c:1604: warning: expecting prototype for s space(). Prototype was for btrfs_reserve_metadata_bytes() instead
fs/btrfs/space-info.c:1640: warning: expecting prototype for Try to reserve data bytes for an allocation(). Prototype was for btrfs_reserve_data_bytes() instead
fs/btrfs/block-group.c:1583: warning: expecting prototype for Map a physical disk address to a list of logical addresses(). Prototype was for btrfs_rmap_block() instead

Introduced by commits

  5001aa0708b9 ("btrfs: fix function description formats in file-item.c")
  1cf15d8d422e ("btrfs: document modified parameter of add_extent_mapping")
  d0295ba341a8 ("btrfs: fix parameter description of btrfs_add_extent_mapping")
  b4a01a9a613b ("btrfs: fix parameter description for functions in extent_io.c")
  28eef9969992 ("btrfs: fix parameter description in delayed-ref.c functions")
  d89752bbf791 ("btrfs: improve parameter description for __btrfs_write_out_cache")

and so on ...

Presumably exposed by commit

  52042e2db452 ("scripts: kernel-doc: validate kernel-doc markup with the actual names")

from the jc_docs tree.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warnings after merge of the btrfs tree
  2023-09-12 12:20   ` Stephen Rothwell
@ 2023-09-20  3:16     ` Stephen Rothwell
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2023-09-20  3:16 UTC (permalink / raw)
  To: David Sterba; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi Stephen,

On Tue, 12 Sep 2023 22:20:06 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi David,
> 
> On Tue, 12 Sep 2023 13:20:11 +0200 David Sterba <dsterba@suse.cz> wrote:
> > 
> > I tried 12 and 13, no warnings on x86_64, however the report is on
> > powerpc. If this is on a big endian host it could be a valid warning, we
> > have an optmization where the on-disk format endianity matches CPU
> > (little endian) then the structures btrfs_disk_key and btrfs_key are
> > equivalent and no coversion is needed.
> > 
> > There were some changes that might be related and newly added to
> > for-next so we don't have any other reference point, I'll take a look.  
> 
> This is indeed a big endian build (big endian cross build on a little
> endian host).  I also did *not* get these warnings on my x86_64 build.

But I do get them from my s390 defconfig build.  Any progress?

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warnings after merge of the btrfs tree
  2023-09-12 11:20 ` David Sterba
@ 2023-09-12 12:20   ` Stephen Rothwell
  2023-09-20  3:16     ` Stephen Rothwell
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2023-09-12 12:20 UTC (permalink / raw)
  To: David Sterba; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi David,

On Tue, 12 Sep 2023 13:20:11 +0200 David Sterba <dsterba@suse.cz> wrote:
> 
> I tried 12 and 13, no warnings on x86_64, however the report is on
> powerpc. If this is on a big endian host it could be a valid warning, we
> have an optmization where the on-disk format endianity matches CPU
> (little endian) then the structures btrfs_disk_key and btrfs_key are
> equivalent and no coversion is needed.
> 
> There were some changes that might be related and newly added to
> for-next so we don't have any other reference point, I'll take a look.

This is indeed a big endian build (big endian cross build on a little
endian host).  I also did *not* get these warnings on my x86_64 build.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warnings after merge of the btrfs tree
  2023-09-12  0:46 Stephen Rothwell
@ 2023-09-12 11:20 ` David Sterba
  2023-09-12 12:20   ` Stephen Rothwell
  0 siblings, 1 reply; 7+ messages in thread
From: David Sterba @ 2023-09-12 11:20 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Sep 12, 2023 at 10:46:46AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the btrfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
> 
> In file included from include/linux/swab.h:5,
>                  from include/uapi/linux/byteorder/big_endian.h:14,
>                  from include/linux/byteorder/big_endian.h:5,
>                  from arch/powerpc/include/uapi/asm/byteorder.h:14,
>                  from include/asm-generic/bitops/le.h:6,
>                  from arch/powerpc/include/asm/bitops.h:336,
>                  from include/linux/bitops.h:68,
>                  from fs/btrfs/extent_io.c:3:
> In function 'btrfs_disk_key_to_cpu',
>     inlined from 'btrfs_item_key_to_cpu' at fs/btrfs/accessors.h:648:2,
>     inlined from 'fiemap_find_last_extent_offset' at fs/btrfs/extent_io.c:2804:2,
>     inlined from 'extent_fiemap' at fs/btrfs/extent_io.c:2879:8:
> include/uapi/linux/swab.h:128:28: warning: 'disk_key.objectid' may be used uninitialized [-Wmaybe-uninitialized]
>   128 | #define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
>       |                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/uapi/linux/byteorder/big_endian.h:33:26: note: in expansion of macro '__swab64'
>    33 | #define __le64_to_cpu(x) __swab64((__force __u64)(__le64)(x))
>       |                          ^~~~~~~~
> include/linux/byteorder/generic.h:87:21: note: in expansion of macro '__le64_to_cpu'
>    87 | #define le64_to_cpu __le64_to_cpu
>       |                     ^~~~~~~~~~~~~
> fs/btrfs/accessors.h:622:25: note: in expansion of macro 'le64_to_cpu'
>   622 |         cpu->objectid = le64_to_cpu(disk->objectid);
>       |                         ^~~~~~~~~~~
> In file included from fs/btrfs/extent_io.c:34:
> fs/btrfs/accessors.h: In function 'extent_fiemap':
> fs/btrfs/accessors.h:645:31: note: 'disk_key.objectid' was declared here
>   645 |         struct btrfs_disk_key disk_key;
>       |                               ^~~~~~~~
> In function 'fiemap_find_last_extent_offset',
>     inlined from 'extent_fiemap' at fs/btrfs/extent_io.c:2879:8:
> fs/btrfs/extent_io.c:2805:33: warning: 'disk_key.type' may be used uninitialized [-Wmaybe-uninitialized]
>  2805 |         if (key.objectid != ino || key.type != BTRFS_EXTENT_DATA_KEY) {
> fs/btrfs/accessors.h: In function 'extent_fiemap':
> fs/btrfs/accessors.h:645:31: note: 'disk_key.type' was declared here
>   645 |         struct btrfs_disk_key disk_key;
>       |                               ^~~~~~~~
> 
> I don't really have any idea what caused this (it *may* have been my
> change from gcc v12 to v13?).

I tried 12 and 13, no warnings on x86_64, however the report is on
powerpc. If this is on a big endian host it could be a valid warning, we
have an optmization where the on-disk format endianity matches CPU
(little endian) then the structures btrfs_disk_key and btrfs_key are
equivalent and no coversion is needed.

There were some changes that might be related and newly added to
for-next so we don't have any other reference point, I'll take a look.

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

* linux-next: build warnings after merge of the btrfs tree
@ 2023-09-12  0:46 Stephen Rothwell
  2023-09-12 11:20 ` David Sterba
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2023-09-12  0:46 UTC (permalink / raw)
  To: David Sterba; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the btrfs tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

In file included from include/linux/swab.h:5,
                 from include/uapi/linux/byteorder/big_endian.h:14,
                 from include/linux/byteorder/big_endian.h:5,
                 from arch/powerpc/include/uapi/asm/byteorder.h:14,
                 from include/asm-generic/bitops/le.h:6,
                 from arch/powerpc/include/asm/bitops.h:336,
                 from include/linux/bitops.h:68,
                 from fs/btrfs/extent_io.c:3:
In function 'btrfs_disk_key_to_cpu',
    inlined from 'btrfs_item_key_to_cpu' at fs/btrfs/accessors.h:648:2,
    inlined from 'fiemap_find_last_extent_offset' at fs/btrfs/extent_io.c:2804:2,
    inlined from 'extent_fiemap' at fs/btrfs/extent_io.c:2879:8:
include/uapi/linux/swab.h:128:28: warning: 'disk_key.objectid' may be used uninitialized [-Wmaybe-uninitialized]
  128 | #define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
      |                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/uapi/linux/byteorder/big_endian.h:33:26: note: in expansion of macro '__swab64'
   33 | #define __le64_to_cpu(x) __swab64((__force __u64)(__le64)(x))
      |                          ^~~~~~~~
include/linux/byteorder/generic.h:87:21: note: in expansion of macro '__le64_to_cpu'
   87 | #define le64_to_cpu __le64_to_cpu
      |                     ^~~~~~~~~~~~~
fs/btrfs/accessors.h:622:25: note: in expansion of macro 'le64_to_cpu'
  622 |         cpu->objectid = le64_to_cpu(disk->objectid);
      |                         ^~~~~~~~~~~
In file included from fs/btrfs/extent_io.c:34:
fs/btrfs/accessors.h: In function 'extent_fiemap':
fs/btrfs/accessors.h:645:31: note: 'disk_key.objectid' was declared here
  645 |         struct btrfs_disk_key disk_key;
      |                               ^~~~~~~~
In function 'fiemap_find_last_extent_offset',
    inlined from 'extent_fiemap' at fs/btrfs/extent_io.c:2879:8:
fs/btrfs/extent_io.c:2805:33: warning: 'disk_key.type' may be used uninitialized [-Wmaybe-uninitialized]
 2805 |         if (key.objectid != ino || key.type != BTRFS_EXTENT_DATA_KEY) {
fs/btrfs/accessors.h: In function 'extent_fiemap':
fs/btrfs/accessors.h:645:31: note: 'disk_key.type' was declared here
  645 |         struct btrfs_disk_key disk_key;
      |                               ^~~~~~~~

I don't really have any idea what caused this (it *may* have been my
change from gcc v12 to v13?).

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warnings after merge of the btrfs tree
  2020-01-14 22:30 Stephen Rothwell
@ 2020-01-17 16:24 ` David Sterba
  0 siblings, 0 replies; 7+ messages in thread
From: David Sterba @ 2020-01-17 16:24 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Sterba, Linux Next Mailing List, Linux Kernel Mailing List,
	Nikolay Borisov

On Wed, Jan 15, 2020 at 09:30:04AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the btrfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
> 
> fs/btrfs/block-group.c: In function 'exclude_super_stripes':
> fs/btrfs/block-group.c:1706:5: warning: 'logical' may be used uninitialized in this function [-Wmaybe-uninitialized]
>  1706 |     kfree(logical);
>       |     ^~~~~~~~~~~~~~
> fs/btrfs/block-group.c:1691:20: warning: 'stripe_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
>  1691 |    if (logical[nr] + stripe_len <= cache->start)
>       |        ~~~~~~~~~~~~^~~~~~~~~~~~
> 
> Introduced by commit
> 
>   767f58cdaf20 ("btrfs: Refactor btrfs_rmap_block to improve readability")
> 
> btrfs_rmap_block() returns zero even if its output arguments are not
> assigned to ... maybe the final "return 0" should be "return ret"?

Yes that's it, thanks. Updated for-next branch pushed.

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

* linux-next: build warnings after merge of the btrfs tree
@ 2020-01-14 22:30 Stephen Rothwell
  2020-01-17 16:24 ` David Sterba
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2020-01-14 22:30 UTC (permalink / raw)
  To: David Sterba
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Nikolay Borisov

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

Hi all,

After merging the btrfs tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

fs/btrfs/block-group.c: In function 'exclude_super_stripes':
fs/btrfs/block-group.c:1706:5: warning: 'logical' may be used uninitialized in this function [-Wmaybe-uninitialized]
 1706 |     kfree(logical);
      |     ^~~~~~~~~~~~~~
fs/btrfs/block-group.c:1691:20: warning: 'stripe_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
 1691 |    if (logical[nr] + stripe_len <= cache->start)
      |        ~~~~~~~~~~~~^~~~~~~~~~~~

Introduced by commit

  767f58cdaf20 ("btrfs: Refactor btrfs_rmap_block to improve readability")

btrfs_rmap_block() returns zero even if its output arguments are not
assigned to ... maybe the final "return 0" should be "return ret"?

-- 
Cheers,
Stephen Rothwell

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

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

end of thread, other threads:[~2023-09-20  3:16 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-27  1:36 linux-next: build warnings after merge of the btrfs tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2023-09-12  0:46 Stephen Rothwell
2023-09-12 11:20 ` David Sterba
2023-09-12 12:20   ` Stephen Rothwell
2023-09-20  3:16     ` Stephen Rothwell
2020-01-14 22:30 Stephen Rothwell
2020-01-17 16:24 ` David Sterba

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).