Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

-Wduplicate-decl-specifier #52

Closed
nickdesaulniers opened this issue Sep 11, 2018 · 6 comments
Closed

-Wduplicate-decl-specifier #52

nickdesaulniers opened this issue Sep 11, 2018 · 6 comments
Assignees
@nickdesaulniers
Labels
[BUG] llvm A bug that should be fixed in upstream LLVM feature-request Not a bug per-se [FIXED][LLVM] 8 This bug was fixed in LLVM 8.0

Comments

@nickdesaulniers
Copy link
Member

I think I'm just going to fix this in clang, based on @gburgessiv 's recommendation. IIRC, his observation was that this is not warned from gcc unless -pedanticis specified, which it's not. Should be a straightforward patch to clang's DIAG.

Seen in at least:

  CC      drivers/gpu/drm/nouveau/nvif/disp.o
drivers/gpu/drm/nouveau/nvif/disp.c:53:12: warning: duplicate 'const' declaration
      specifier [-Wduplicate-decl-specifier]
        int cid = nvif_sclass(&device->object, disps, oclass);
                  ^
drivers/gpu/drm/nouveau/include/nvif/object.h:103:2: note: expanded from macro
      'nvif_sclass'
        const typeof(m[0]) *_mclass = (m);                                     \
        ^
@nickdesaulniers nickdesaulniers added [BUG] llvm A bug that should be fixed in upstream LLVM feature-request Not a bug per-se labels Sep 11, 2018
@nickdesaulniers nickdesaulniers added this to the ARCH=arm64 allyesconfig milestone Sep 11, 2018
@nickdesaulniers nickdesaulniers self-assigned this Sep 11, 2018
@shenki
Copy link
Member

shenki commented Sep 12, 2018

We hit this in the powerpc kernel too:

https://github.com/linuxppc/linux/issues/185

Having the same behaviour as GCC when the code uses const typeof(const foo*) would be helpful.

@nickdesaulniers
Copy link
Member Author

nickdesaulniers commented Sep 14, 2018 •
edited by nathanchance
Loading

LLVM bug: https://llvm.org/pr32985

@tpimh
Copy link

tpimh commented Sep 18, 2018

Is it similar?

drivers/hwmon/w83795.c:312:9: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
        reg0 = find_closest_descending(val, pwm_freq_cksel0,
               ^
./include/linux/util_macros.h:39:43: note: expanded from macro 'find_closest_descending'
#define find_closest_descending(x, a, as) __find_closest(x, a, as, >=)
                                          ^
./include/linux/util_macros.h:9:13: note: expanded from macro '__find_closest'
        typeof(*a) const *__fc_a = (a);                                 \
                   ^
1 warning generated.

@nickdesaulniers
Copy link
Member Author

yes, I'm looking into this this week.

@nickdesaulniers
Copy link
Member Author

https://reviews.llvm.org/D52248

@nickdesaulniers nickdesaulniers added [PATCH] Exists There is a patch that fixes this issue [PATCH] Submitted A patch has been submitted for review and removed [PATCH] Exists There is a patch that fixes this issue labels Sep 19, 2018
@nickdesaulniers
Copy link
Member Author

https://reviews.llvm.org/rL343740

@nickdesaulniers nickdesaulniers added [FIXED][LLVM] 8 This bug was fixed in LLVM 8.0 and removed [PATCH] Submitted A patch has been submitted for review labels Oct 3, 2018
shenki pushed a commit to shenki/linux that referenced this issue Oct 10, 2018
@antonblanchard @shenki
powerpc: Fix duplicate const clang warning in user access code
9fde84b 
This re-applies b91c1e3 which was reverted in f2ca809
d466f6c f84ed59 (powerpc/sparse: Constify the address pointer
...").

We see a large number of duplicate const errors in the user access
code when building with llvm/clang:

  include/linux/pagemap.h:576:8: warning: duplicate 'const' declaration specifier
      [-Wduplicate-decl-specifier]
        ret = __get_user(c, uaddr);

The problem is we are doing const __typeof__(*(ptr)), which will hit the
warning if ptr is marked const.

Removing const does not seem to have any effect on GCC code generation.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
If we don't want to apply this, other options are suppressing the
warning, or wait for a fix to land in clang
(ClangBuiltLinux#52).
nathanchance pushed a commit that referenced this issue Nov 9, 2018
s390/kasan: increase instrumented stack size to 64k
9fed920 
Increase kasan instrumented kernel stack size from 32k to 64k. Other
architectures seems to get away with just doubling kernel stack size under
kasan, but on s390 this appears to be not enough due to bigger frame size.
The particular pain point is kasan inlined checks (CONFIG_KASAN_INLINE
vs CONFIG_KASAN_OUTLINE). With inlined checks one particular case hitting
stack overflow is fs sync on xfs filesystem:

 #0 [9a0681e8]  704 bytes  check_usage at 34b1fc
 #1 [9a0684a8]  432 bytes  check_usage at 34c710
 #2 [9a068658]  1048 bytes  validate_chain at 35044a
 #3 [9a068a70]  312 bytes  __lock_acquire at 3559fe
 #4 [9a068ba8]  440 bytes  lock_acquire at 3576ee
 #5 [9a068d60]  104 bytes  _raw_spin_lock at 21b44e0
 #6 [9a068dc8]  1992 bytes  enqueue_entity at 2dbf72
 #7 [9a069590]  1496 bytes  enqueue_task_fair at 2df5f0
 #8 [9a069b68]  64 bytes  ttwu_do_activate at 28f438
 #9 [9a069ba8]  552 bytes  try_to_wake_up at 298c4c
 #10 [9a069dd0]  168 bytes  wake_up_worker at 23f97c
 #11 [9a069e78]  200 bytes  insert_work at 23fc2e
 #12 [9a069f40]  648 bytes  __queue_work at 2487c0
 #13 [9a06a1c8]  200 bytes  __queue_delayed_work at 24db28
 #14 [9a06a290]  248 bytes  mod_delayed_work_on at 24de84
 #15 [9a06a388]  24 bytes  kblockd_mod_delayed_work_on at 153e2a0
 #16 [9a06a3a0]  288 bytes  __blk_mq_delay_run_hw_queue at 158168c
 #17 [9a06a4c0]  192 bytes  blk_mq_run_hw_queue at 1581a3c
 #18 [9a06a580]  184 bytes  blk_mq_sched_insert_requests at 15a2192
 #19 [9a06a638]  1024 bytes  blk_mq_flush_plug_list at 1590f3a
 #20 [9a06aa38]  704 bytes  blk_flush_plug_list at 1555028
 #21 [9a06acf8]  320 bytes  schedule at 219e476
 #22 [9a06ae38]  760 bytes  schedule_timeout at 21b0aac
 #23 [9a06b130]  408 bytes  wait_for_common at 21a1706
 #24 [9a06b2c8]  360 bytes  xfs_buf_iowait at fa1540
 #25 [9a06b430]  256 bytes  __xfs_buf_submit at fadae6
 #26 [9a06b530]  264 bytes  xfs_buf_read_map at fae3f6
 #27 [9a06b638]  656 bytes  xfs_trans_read_buf_map at 10ac9a8
 #28 [9a06b8c8]  304 bytes  xfs_btree_kill_root at e72426
 #29 [9a06b9f8]  288 bytes  xfs_btree_lookup_get_block at e7bc5e
 #30 [9a06bb18]  624 bytes  xfs_btree_lookup at e7e1a6
 #31 [9a06bd88]  2664 bytes  xfs_alloc_ag_vextent_near at dfa070
 #32 [9a06c7f0]  144 bytes  xfs_alloc_ag_vextent at dff3ca
 #33 [9a06c880]  1128 bytes  xfs_alloc_vextent at e05fce
 #34 [9a06cce8]  584 bytes  xfs_bmap_btalloc at e58342
 #35 [9a06cf30]  1336 bytes  xfs_bmapi_write at e618de
 #36 [9a06d468]  776 bytes  xfs_iomap_write_allocate at ff678e
 #37 [9a06d770]  720 bytes  xfs_map_blocks at f82af8
 #38 [9a06da40]  928 bytes  xfs_writepage_map at f83cd6
 #39 [9a06dde0]  320 bytes  xfs_do_writepage at f85872
 #40 [9a06df20]  1320 bytes  write_cache_pages at 73dfe8
 #41 [9a06e448]  208 bytes  xfs_vm_writepages at f7f892
 #42 [9a06e518]  88 bytes  do_writepages at 73fe6a
 #43 [9a06e570]  872 bytes  __writeback_single_inode at a20cb6
 #44 [9a06e8d8]  664 bytes  writeback_sb_inodes at a23be2
 #45 [9a06eb70]  296 bytes  __writeback_inodes_wb at a242e0
 #46 [9a06ec98]  928 bytes  wb_writeback at a2500e
 #47 [9a06f038]  848 bytes  wb_do_writeback at a260ae
 #48 [9a06f388]  536 bytes  wb_workfn at a28228
 #49 [9a06f5a0]  1088 bytes  process_one_work at 24a234
 #50 [9a06f9e0]  1120 bytes  worker_thread at 24ba26
 #51 [9a06fe40]  104 bytes  kthread at 26545a
 #52 [9a06fea8]             kernel_thread_starter at 21b6b62

To be able to increase the stack size to 64k reuse LLILL instruction
in __switch_to function to load 64k - STACK_FRAME_OVERHEAD - __PT_SIZE
(65192) value as unsigned.

Reported-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nickdesaulniers nickdesaulniers

Labels
[BUG] llvm A bug that should be fixed in upstream LLVM feature-request Not a bug per-se [FIXED][LLVM] 8 This bug was fixed in LLVM 8.0
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@shenki @tpimh @nickdesaulniers