From: Chao Yu <yuchao0@huawei.com> To: Arnd Bergmann <arnd@arndb.de>, Chao Yu <chao@kernel.org> Cc: Jaegeuk Kim <jaegeuk@kernel.org>, <linux-kernel@vger.kernel.org>, <linux-f2fs-devel@lists.sourceforge.net>, Weichao Guo <guoweichao@huawei.com>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [f2fs-dev] [PATCH 04/28] f2fs: replace a build-time warning with runtime WARN_ON Date: Thu, 27 Oct 2016 19:41:05 +0800 [thread overview] Message-ID: <a87b94d4-d873-8f6c-2a61-bcd23ea7d2f1@huawei.com> (raw) In-Reply-To: <3766259.9ZsupLsmdk@wuerfel> On 2016/10/26 22:57, Arnd Bergmann wrote: > On Wednesday, October 26, 2016 10:05:00 PM CEST Chao Yu wrote: >> On 2016/10/18 6:05, Arnd Bergmann wrote: >>> gcc is unsure about the use of last_ofs_in_node, which might happen >>> without a prior initialization: >>> >>> fs/f2fs//git/arm-soc/fs/f2fs/data.c: In function ‘f2fs_map_blocks’: >>> fs/f2fs/data.c:799:54: warning: ‘last_ofs_in_node’ may be used uninitialized in this function [-Wmaybe-uninitialized] >>> if (prealloc && dn.ofs_in_node != last_ofs_in_node + 1) { >> >> In each round of dnode block traverse, we will init 'prealloc' and then update >> 'prealloc' and 'last_ofs_in_node' together in below lines of f2fs_map_blocks: >> if (flag == F2FS_GET_BLOCK_PRE_AIO) { >> if (blkaddr == NULL_ADDR) { >> prealloc++; >> last_ofs_in_node = dn.ofs_in_node; >> } >> } >> >> Then in below codes, it is safe to use 'last_ofs_in_node' since we will check >> 'prealloc' firstly, so if 'prealloc' is non-zero, 'last_ofs_in_node' must be valid. >> if (prealloc && dn.ofs_in_node != last_ofs_in_node + 1) { >> >> So I think we should not add WARN_ON there. > > Ok, that make sense. Thanks for taking a closer look! > > Should we just set last_ofs_in_node to the same value as ofs_in_node > before the loop? I think it's OK as it can remove warning compiler reports. :) Thanks, > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > index 9ae194f..14db4b7 100644 > --- a/fs/f2fs/data.c > +++ b/fs/f2fs/data.c > @@ -716,7 +716,7 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, > } > > prealloc = 0; > - ofs_in_node = dn.ofs_in_node; > + last_ofs_in_node = ofs_in_node = dn.ofs_in_node; > end_offset = ADDRS_PER_PAGE(dn.node_page, inode); > > next_block: > > Arnd > > . >
WARNING: multiple messages have this Message-ID (diff)
From: Chao Yu <yuchao0@huawei.com> To: Arnd Bergmann <arnd@arndb.de>, Chao Yu <chao@kernel.org> Cc: Weichao Guo <guoweichao@huawei.com>, Jaegeuk Kim <jaegeuk@kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [PATCH 04/28] f2fs: replace a build-time warning with runtime WARN_ON Date: Thu, 27 Oct 2016 19:41:05 +0800 [thread overview] Message-ID: <a87b94d4-d873-8f6c-2a61-bcd23ea7d2f1@huawei.com> (raw) In-Reply-To: <3766259.9ZsupLsmdk@wuerfel> On 2016/10/26 22:57, Arnd Bergmann wrote: > On Wednesday, October 26, 2016 10:05:00 PM CEST Chao Yu wrote: >> On 2016/10/18 6:05, Arnd Bergmann wrote: >>> gcc is unsure about the use of last_ofs_in_node, which might happen >>> without a prior initialization: >>> >>> fs/f2fs//git/arm-soc/fs/f2fs/data.c: In function ‘f2fs_map_blocks’: >>> fs/f2fs/data.c:799:54: warning: ‘last_ofs_in_node’ may be used uninitialized in this function [-Wmaybe-uninitialized] >>> if (prealloc && dn.ofs_in_node != last_ofs_in_node + 1) { >> >> In each round of dnode block traverse, we will init 'prealloc' and then update >> 'prealloc' and 'last_ofs_in_node' together in below lines of f2fs_map_blocks: >> if (flag == F2FS_GET_BLOCK_PRE_AIO) { >> if (blkaddr == NULL_ADDR) { >> prealloc++; >> last_ofs_in_node = dn.ofs_in_node; >> } >> } >> >> Then in below codes, it is safe to use 'last_ofs_in_node' since we will check >> 'prealloc' firstly, so if 'prealloc' is non-zero, 'last_ofs_in_node' must be valid. >> if (prealloc && dn.ofs_in_node != last_ofs_in_node + 1) { >> >> So I think we should not add WARN_ON there. > > Ok, that make sense. Thanks for taking a closer look! > > Should we just set last_ofs_in_node to the same value as ofs_in_node > before the loop? I think it's OK as it can remove warning compiler reports. :) Thanks, > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > index 9ae194f..14db4b7 100644 > --- a/fs/f2fs/data.c > +++ b/fs/f2fs/data.c > @@ -716,7 +716,7 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, > } > > prealloc = 0; > - ofs_in_node = dn.ofs_in_node; > + last_ofs_in_node = ofs_in_node = dn.ofs_in_node; > end_offset = ADDRS_PER_PAGE(dn.node_page, inode); > > next_block: > > Arnd > > . > ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2016-10-27 13:52 UTC|newest] Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-10-17 22:03 [PATCH 00/28] Reenable maybe-uninitialized warnings Arnd Bergmann 2016-10-17 22:03 ` Arnd Bergmann 2016-10-17 22:05 ` [PATCH 01/28] [v2] netfilter: nf_tables: avoid uninitialized variable warning Arnd Bergmann 2016-10-18 15:23 ` Pablo Neira Ayuso 2016-10-17 22:05 ` [PATCH 02/28] [v2] mtd: mtk: avoid warning in mtk_ecc_encode Arnd Bergmann 2016-10-17 22:05 ` Arnd Bergmann 2016-10-17 22:05 ` Arnd Bergmann 2016-10-18 5:19 ` Boris Brezillon 2016-10-18 5:19 ` Boris Brezillon 2016-10-18 10:12 ` RogerCC.Lin 2016-10-18 10:12 ` RogerCC.Lin 2016-10-18 10:12 ` RogerCC.Lin 2016-10-18 19:45 ` Boris Brezillon 2016-10-18 19:45 ` Boris Brezillon 2016-10-18 19:45 ` Boris Brezillon [not found] ` <20161017220342.1627073-1-arnd-r2nGTMty4D4@public.gmane.org> 2016-10-17 22:05 ` [PATCH 03/28] [v2] infiniband: shut up a maybe-uninitialized warning Arnd Bergmann 2016-10-17 22:05 ` Arnd Bergmann [not found] ` <20161017220557.1688282-3-arnd-r2nGTMty4D4@public.gmane.org> 2016-10-18 6:47 ` Haggai Eran 2016-10-18 6:47 ` Haggai Eran [not found] ` <33302790-0a4c-e2b3-868d-3e7dadbd3c07-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> 2016-10-18 10:18 ` Arnd Bergmann 2016-10-18 10:18 ` Arnd Bergmann 2016-10-18 10:32 ` Haggai Eran 2016-10-18 10:32 ` Haggai Eran 2016-10-17 22:05 ` [PATCH 04/28] f2fs: replace a build-time warning with runtime WARN_ON Arnd Bergmann 2016-10-17 22:05 ` Arnd Bergmann 2016-10-26 14:05 ` [f2fs-dev] " Chao Yu 2016-10-26 14:57 ` Arnd Bergmann 2016-10-27 11:41 ` Chao Yu [this message] 2016-10-27 11:41 ` Chao Yu 2016-10-17 22:05 ` [PATCH 05/28] ext2: avoid bogus -Wmaybe-uninitialized warning Arnd Bergmann 2016-10-18 5:15 ` Christoph Hellwig 2016-10-18 9:30 ` Jan Kara 2016-10-17 22:05 ` [PATCH 06/28] NFSv4.1: work around " Arnd Bergmann 2016-10-17 22:08 ` [PATCH 07/28] ceph: avoid false positive maybe-uninitialized warning Arnd Bergmann 2016-10-18 2:07 ` Yan, Zheng 2016-10-17 22:08 ` [PATCH 08/28] staging: lustre: restore initialization of return code Arnd Bergmann 2016-10-17 22:08 ` [lustre-devel] " Arnd Bergmann 2016-10-17 22:23 ` Patrick Farrell 2016-10-17 22:29 ` Arnd Bergmann 2016-10-17 22:29 ` Arnd Bergmann 2016-10-17 22:37 ` Linus Torvalds 2016-10-17 22:37 ` Linus Torvalds 2016-10-17 23:00 ` Arnd Bergmann 2016-10-17 23:00 ` Arnd Bergmann 2016-10-17 22:42 ` [PATCH 08/28 v2] " Arnd Bergmann 2016-10-17 22:42 ` [lustre-devel] " Arnd Bergmann 2016-10-17 22:08 ` [PATCH 09/28] staging: lustre: remove broken dead code in cfs_cpt_table_create_pattern Arnd Bergmann 2016-10-17 22:08 ` [lustre-devel] " Arnd Bergmann 2016-10-17 22:10 ` [PATCH 10/28] UBI: fix uninitialized access of vid_hdr pointer Arnd Bergmann 2016-10-18 5:17 ` Boris Brezillon 2016-10-17 22:10 ` [PATCH 11/28] block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized Arnd Bergmann 2016-10-18 9:57 ` Ilya Dryomov 2016-10-18 10:04 ` Arnd Bergmann 2016-10-17 22:12 ` [PATCH 12/28] [media] rc: print correct variable for z8f0811 Arnd Bergmann 2016-10-17 22:13 ` [PATCH 13/28] [media] dib0700: fix uninitialized data on 'repeat' event Arnd Bergmann 2016-10-17 22:13 ` [PATCH 14/28] iio: accel: sca3000_core: avoid potentially uninitialized variable Arnd Bergmann 2016-10-17 22:13 ` Arnd Bergmann 2016-10-23 21:25 ` Jonathan Cameron 2016-10-17 22:13 ` [PATCH 15/28] crypto: aesni: avoid -Wmaybe-uninitialized warning Arnd Bergmann 2016-10-17 22:13 ` [PATCH 16/28] pcmcia: fix return value of soc_pcmcia_regulator_set Arnd Bergmann 2016-10-18 9:42 ` Russell King - ARM Linux 2016-10-17 22:13 ` [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error Arnd Bergmann 2016-10-24 17:27 ` Mark Brown 2016-10-24 17:27 ` Mark Brown 2016-10-24 18:36 ` Heiner Kallweit 2016-10-24 18:36 ` Heiner Kallweit 2016-10-24 18:45 ` Mark Brown 2016-10-24 20:37 ` Arnd Bergmann 2016-10-25 19:13 ` Mark Brown 2016-10-25 19:13 ` Mark Brown 2016-10-25 20:57 ` Arnd Bergmann 2016-10-26 10:15 ` Applied "spi: fsl-espi: avoid processing uninitalized data on error" to the spi tree Mark Brown 2016-10-26 18:11 ` Merge problem: " Heiner Kallweit 2016-10-26 21:59 ` Mark Brown 2016-10-26 21:59 ` Mark Brown 2016-10-17 22:13 ` [PATCH 18/28] drm: avoid uninitialized timestamp use in wait_vblank Arnd Bergmann 2016-10-17 22:13 ` Arnd Bergmann 2016-10-17 23:47 ` Mario Kleiner 2016-10-17 23:47 ` Mario Kleiner 2016-10-18 7:46 ` Daniel Vetter 2016-10-18 7:46 ` Daniel Vetter 2016-10-17 22:13 ` [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap Arnd Bergmann 2016-10-26 6:49 ` Kalle Valo 2016-10-26 6:49 ` Kalle Valo 2016-10-26 9:57 ` Arnd Bergmann 2016-10-26 11:11 ` Kalle Valo 2016-10-26 11:11 ` Kalle Valo 2016-10-26 11:11 ` Kalle Valo 2016-10-27 15:05 ` [19/28] " Kalle Valo 2016-10-27 15:05 ` Kalle Valo 2016-10-17 22:16 ` [PATCH 20/28] net: bcm63xx: avoid referencing uninitialized variable Arnd Bergmann 2016-10-17 22:16 ` Arnd Bergmann 2016-10-18 18:21 ` David Miller 2016-10-18 18:21 ` David Miller 2016-10-17 22:16 ` [PATCH 21/28] net/hyperv: avoid " Arnd Bergmann 2016-10-17 22:16 ` Arnd Bergmann 2016-10-18 18:21 ` David Miller 2016-10-17 22:16 ` [PATCH 22/28] x86: apm: avoid uninitialized data Arnd Bergmann 2016-10-18 13:05 ` Jiri Kosina 2016-10-18 21:35 ` Luis R. Rodriguez 2016-10-17 22:16 ` [PATCH 23/28] x86: mark target address as output in 'insb' asm Arnd Bergmann 2016-10-17 22:16 ` [PATCH 24/28] x86: math-emu: possible uninitialized variable use Arnd Bergmann 2016-10-17 22:16 ` [PATCH 25/28] s390: pci: don't print uninitialized data for debugging Arnd Bergmann 2016-10-18 6:48 ` Martin Schwidefsky 2016-10-18 8:53 ` Sebastian Ott 2016-10-17 22:16 ` [PATCH 26/28] nios2: fix timer initcall return value Arnd Bergmann 2016-10-24 0:54 ` Ley Foon Tan 2016-10-17 22:16 ` [PATCH 27/28] rocker: fix maybe-uninitialized warning Arnd Bergmann 2016-10-18 18:21 ` David Miller 2016-10-17 22:19 ` [PATCH 28/28] Kbuild: bring back -Wmaybe-uninitialized warning Arnd Bergmann 2016-10-17 22:19 ` Arnd Bergmann 2016-10-17 22:19 ` Arnd Bergmann 2016-10-17 22:19 ` Arnd Bergmann 2016-10-18 5:08 ` [PATCH 00/28] Reenable maybe-uninitialized warnings Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=a87b94d4-d873-8f6c-2a61-bcd23ea7d2f1@huawei.com \ --to=yuchao0@huawei.com \ --cc=arnd@arndb.de \ --cc=chao@kernel.org \ --cc=guoweichao@huawei.com \ --cc=jaegeuk@kernel.org \ --cc=linux-f2fs-devel@lists.sourceforge.net \ --cc=linux-kernel@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.