Fengguang Wu
2013-Nov-20 04:05 UTC
Re: fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments
On Tue, Nov 19, 2013 at 07:56:35PM -0800, Kees Cook wrote:> Hi! > > Which tree is ''devel-snb''? I don''t see that on the kernel.org trees.It''s my local merge branch, based on the latest upstream release. Let''s CC the btrfs developers for this warning. :) Thanks, Fengguang> On Tue, Nov 19, 2013 at 5:01 PM, kbuild test robot > <fengguang.wu@intel.com> wrote: > > tree: devel-snb-x86_64-201311200240 > > head: 1a985a0807ea34f37a4c5287089abd1cd2f65049 > > commit: a9b93a3684dd6ebfb7cfa173f78a79c09de81207 Merge ''kees/format-security'' into devel-snb-x86_64-201311200240 > > date: 6 hours ago > > config: make ARCH=x86_64 allmodconfig > > > > All error/warnings: > > > > fs/btrfs/extent-tree.c:6201:12: sparse: symbol ''get_raid_name'' was not declared. Should it be static? > > fs/btrfs/extent-tree.c:2469:28: sparse: context imbalance in ''run_clustered_refs'' - unexpected unlock > > fs/btrfs/extent-tree.c:8304:9: sparse: context imbalance in ''btrfs_put_block_group_cache'' - wrong count at exit > > fs/btrfs/extent-tree.c: In function ''__link_block_group'': > >>> fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments [-Werror=format-security] > > get_raid_name(index)); > > ^ > > cc1: some warnings being treated as errors > > > > vim +8430 fs/btrfs/extent-tree.c > > > > 8414 return 0; > > 8415 } > > 8416 > > 8417 static void __link_block_group(struct btrfs_space_info *space_info, > > 8418 struct btrfs_block_group_cache *cache) > > 8419 { > > 8420 int index = get_block_group_index(cache); > > 8421 > > 8422 down_write(&space_info->groups_sem); > > 8423 if (list_empty(&space_info->block_groups[index])) { > > 8424 struct kobject *kobj = &space_info->block_group_kobjs[index]; > > 8425 int ret; > > 8426 > > 8427 kobject_get(&space_info->kobj); /* put in release */ > > 8428 ret = kobject_init_and_add(kobj, &btrfs_raid_ktype, > > 8429 &space_info->kobj, > >> 8430 get_raid_name(index)); > > 8431 if (ret) { > > 8432 pr_warn("btrfs: failed to add kobject for block cache. ignoring.\n"); > > 8433 kobject_put(&space_info->kobj); > > 8434 } > > 8435 } > > 8436 list_add_tail(&cache->list, &space_info->block_groups[index]); > > 8437 up_write(&space_info->groups_sem); > > 8438 } > > > > --- > > 0-DAY kernel build testing backend Open Source Technology Center > > http://lists.01.org/mailman/listinfo/kbuild Intel Corporation > > > > -- > Kees Cook > Chrome OS Security-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kees Cook
2013-Nov-20 16:04 UTC
Re: fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments
On Tue, Nov 19, 2013 at 8:05 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:> On Tue, Nov 19, 2013 at 07:56:35PM -0800, Kees Cook wrote: >> Hi! >> >> Which tree is ''devel-snb''? I don''t see that on the kernel.org trees. > > It''s my local merge branch, based on the latest upstream release.Hm, which release? I don''t see it in 3.12, Linus''s tree, nor linux-next.> Let''s CC the btrfs developers for this warning. :)Sounds good. I wanted to see what get_raid_name() uses for return values in case gcc was being dumb, but adding "%s" before it should fix the problem. -Kees> > Thanks, > Fengguang > >> On Tue, Nov 19, 2013 at 5:01 PM, kbuild test robot >> <fengguang.wu@intel.com> wrote: >> > tree: devel-snb-x86_64-201311200240 >> > head: 1a985a0807ea34f37a4c5287089abd1cd2f65049 >> > commit: a9b93a3684dd6ebfb7cfa173f78a79c09de81207 Merge ''kees/format-security'' into devel-snb-x86_64-201311200240 >> > date: 6 hours ago >> > config: make ARCH=x86_64 allmodconfig >> > >> > All error/warnings: >> > >> > fs/btrfs/extent-tree.c:6201:12: sparse: symbol ''get_raid_name'' was not declared. Should it be static? >> > fs/btrfs/extent-tree.c:2469:28: sparse: context imbalance in ''run_clustered_refs'' - unexpected unlock >> > fs/btrfs/extent-tree.c:8304:9: sparse: context imbalance in ''btrfs_put_block_group_cache'' - wrong count at exit >> > fs/btrfs/extent-tree.c: In function ''__link_block_group'': >> >>> fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments [-Werror=format-security] >> > get_raid_name(index)); >> > ^ >> > cc1: some warnings being treated as errors >> > >> > vim +8430 fs/btrfs/extent-tree.c >> > >> > 8414 return 0; >> > 8415 } >> > 8416 >> > 8417 static void __link_block_group(struct btrfs_space_info *space_info, >> > 8418 struct btrfs_block_group_cache *cache) >> > 8419 { >> > 8420 int index = get_block_group_index(cache); >> > 8421 >> > 8422 down_write(&space_info->groups_sem); >> > 8423 if (list_empty(&space_info->block_groups[index])) { >> > 8424 struct kobject *kobj = &space_info->block_group_kobjs[index]; >> > 8425 int ret; >> > 8426 >> > 8427 kobject_get(&space_info->kobj); /* put in release */ >> > 8428 ret = kobject_init_and_add(kobj, &btrfs_raid_ktype, >> > 8429 &space_info->kobj, >> >> 8430 get_raid_name(index)); >> > 8431 if (ret) { >> > 8432 pr_warn("btrfs: failed to add kobject for block cache. ignoring.\n"); >> > 8433 kobject_put(&space_info->kobj); >> > 8434 } >> > 8435 } >> > 8436 list_add_tail(&cache->list, &space_info->block_groups[index]); >> > 8437 up_write(&space_info->groups_sem); >> > 8438 } >> > >> > --- >> > 0-DAY kernel build testing backend Open Source Technology Center >> > http://lists.01.org/mailman/listinfo/kbuild Intel Corporation >> >> >> >> -- >> Kees Cook >> Chrome OS Security-- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason
2013-Nov-20 17:30 UTC
Re: fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments
Quoting Fengguang Wu (2013-11-19 23:05:51)> On Tue, Nov 19, 2013 at 07:56:35PM -0800, Kees Cook wrote: > > Hi! > > > > Which tree is ''devel-snb''? I don''t see that on the kernel.org trees. > > It''s my local merge branch, based on the latest upstream release. > > Let''s CC the btrfs developers for this warning. :) > > Thanks, > Fengguang > > > On Tue, Nov 19, 2013 at 5:01 PM, kbuild test robot > > <fengguang.wu@intel.com> wrote: > > > tree: devel-snb-x86_64-201311200240 > > > head: 1a985a0807ea34f37a4c5287089abd1cd2f65049 > > > commit: a9b93a3684dd6ebfb7cfa173f78a79c09de81207 Merge ''kees/format-security'' into devel-snb-x86_64-201311200240 > > > date: 6 hours ago > > > config: make ARCH=x86_64 allmodconfig > > > > > > All error/warnings: > > > > > > fs/btrfs/extent-tree.c:6201:12: sparse: symbol ''get_raid_name'' was not declared. Should it be static? > > > fs/btrfs/extent-tree.c:2469:28: sparse: context imbalance in ''run_clustered_refs'' - unexpected unlock > > > fs/btrfs/extent-tree.c:8304:9: sparse: context imbalance in ''btrfs_put_block_group_cache'' - wrong count at exit > > > fs/btrfs/extent-tree.c: In function ''__link_block_group'': > > >>> fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments [-Werror=format-security] > > > get_raid_name(index));This comes from the btrfs-next tree, with Jeff''s sysfs patches, so I''ve added Jeff. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff Mahoney
2013-Nov-20 18:05 UTC
Re: fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments
On 11/20/13, 12:30 PM, Chris Mason wrote:> Quoting Fengguang Wu (2013-11-19 23:05:51) >> On Tue, Nov 19, 2013 at 07:56:35PM -0800, Kees Cook wrote: >>> Hi! >>> >>> Which tree is ''devel-snb''? I don''t see that on the kernel.org trees. >> >> It''s my local merge branch, based on the latest upstream release. >> >> Let''s CC the btrfs developers for this warning. :) >> >> Thanks, >> Fengguang >> >>> On Tue, Nov 19, 2013 at 5:01 PM, kbuild test robot >>> <fengguang.wu@intel.com> wrote: >>>> tree: devel-snb-x86_64-201311200240 >>>> head: 1a985a0807ea34f37a4c5287089abd1cd2f65049 >>>> commit: a9b93a3684dd6ebfb7cfa173f78a79c09de81207 Merge ''kees/format-security'' into devel-snb-x86_64-201311200240 >>>> date: 6 hours ago >>>> config: make ARCH=x86_64 allmodconfig >>>> >>>> All error/warnings: >>>> >>>> fs/btrfs/extent-tree.c:6201:12: sparse: symbol ''get_raid_name'' was not declared. Should it be static? >>>> fs/btrfs/extent-tree.c:2469:28: sparse: context imbalance in ''run_clustered_refs'' - unexpected unlock >>>> fs/btrfs/extent-tree.c:8304:9: sparse: context imbalance in ''btrfs_put_block_group_cache'' - wrong count at exit >>>> fs/btrfs/extent-tree.c: In function ''__link_block_group'': >>>>>> fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments [-Werror=format-security] >>>> get_raid_name(index)); > > This comes from the btrfs-next tree, with Jeff''s sysfs patches, so I''ve > added Jeff.Thanks for the heads up. I have a few other fixes that need to go into that patch set WRT cleanup too. -Jeff -- Jeff Mahoney SUSE Labs
Kees Cook
2013-Nov-20 18:37 UTC
Re: fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments
On Wed, Nov 20, 2013 at 10:05 AM, Jeff Mahoney <jeffm@suse.com> wrote:> On 11/20/13, 12:30 PM, Chris Mason wrote: >> Quoting Fengguang Wu (2013-11-19 23:05:51) >>> On Tue, Nov 19, 2013 at 07:56:35PM -0800, Kees Cook wrote: >>>> Hi! >>>> >>>> Which tree is ''devel-snb''? I don''t see that on the kernel.org trees. >>> >>> It''s my local merge branch, based on the latest upstream release. >>> >>> Let''s CC the btrfs developers for this warning. :) >>> >>> Thanks, >>> Fengguang >>> >>>> On Tue, Nov 19, 2013 at 5:01 PM, kbuild test robot >>>> <fengguang.wu@intel.com> wrote: >>>>> tree: devel-snb-x86_64-201311200240 >>>>> head: 1a985a0807ea34f37a4c5287089abd1cd2f65049 >>>>> commit: a9b93a3684dd6ebfb7cfa173f78a79c09de81207 Merge ''kees/format-security'' into devel-snb-x86_64-201311200240 >>>>> date: 6 hours ago >>>>> config: make ARCH=x86_64 allmodconfig >>>>> >>>>> All error/warnings: >>>>> >>>>> fs/btrfs/extent-tree.c:6201:12: sparse: symbol ''get_raid_name'' was not declared. Should it be static? >>>>> fs/btrfs/extent-tree.c:2469:28: sparse: context imbalance in ''run_clustered_refs'' - unexpected unlock >>>>> fs/btrfs/extent-tree.c:8304:9: sparse: context imbalance in ''btrfs_put_block_group_cache'' - wrong count at exit >>>>> fs/btrfs/extent-tree.c: In function ''__link_block_group'': >>>>>>> fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments [-Werror=format-security] >>>>> get_raid_name(index)); >> >> This comes from the btrfs-next tree, with Jeff''s sysfs patches, so I''ve >> added Jeff.Ah, found it: http://git.kernel.org/cgit/linux/kernel/git/josef/btrfs-next.git/tree/fs/btrfs/extent-tree.c> > Thanks for the heads up. I have a few other fixes that need to go into > that patch set WRT cleanup too.It looks like gcc is being stupid (const strings again). If you don''t want to change the call from kobject_init_and_add(..., get_raid_name(index)); to kobject_init_and_add(..., "%s", get_raid_name(index)); that''s fine -- I can whitelist it since it''s a string constant. But since it''s not critical path, it would be nice to gain the "%s" just to be defensive if get_raid_name ever changes, etc. Thanks for taking a look! -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fengguang Wu
2013-Nov-21 01:03 UTC
Re: fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments
On Wed, Nov 20, 2013 at 08:04:58AM -0800, Kees Cook wrote:> On Tue, Nov 19, 2013 at 8:05 PM, Fengguang Wu <fengguang.wu@intel.com> wrote: > > On Tue, Nov 19, 2013 at 07:56:35PM -0800, Kees Cook wrote: > >> Hi! > >> > >> Which tree is ''devel-snb''? I don''t see that on the kernel.org trees. > > > > It''s my local merge branch, based on the latest upstream release. > > Hm, which release? I don''t see it in 3.12, Linus''s tree, nor linux-next.''devel-snb'' is one of my private branch, starting from v3.12, merging several public git branches (eg. btrfs-next, kees/format-security, ...) and finally do compile tests on top of it. This effectively tests all of the merged public branches in one go. :) Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html