Messages in this thread | | | From | John Ogness <> | Subject | Re: [PATCH next v2 1/2] dump_stack: move cpu lock to printk.c | Date | Thu, 10 Jun 2021 15:26:15 +0200 |
| |
On 2021-06-08, Petr Mladek <pmladek@suse.com> wrote: >> lib/dump_stack.c: In function 'dump_stack_lvl': >> >> lib/dump_stack.c:107:2: warning: 'lock_flag' is used uninitialized in this function [-Wuninitialized] >> 107 | printk_cpu_unlock_irqrestore(lock_flag, irq_flags); >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Interesting. I am curious that it does not complain also about > irq_flags. But it is possible the it reports only the first problem.
Strangely enough, if I set a value for @lock_flag, it is happy and does not complain about @irq_flags. Probably a compiler oversight.
> Anyway, we will likely need to do some trickery via #define to tell > the compiler that the value is set.
This is on ARCH=mips and !CONFIG_SMP. So the value is _not_ getting set. (The static inline function does nothing.)
By changing printk_cpu_unlock_irqrestore() to use pointers:
static inline void printk_cpu_unlock_irqrestore(bool *lock_flag, unsigned long *irq_flags)
then the warning disappears. Indeed, by not using pointers on unlock, technically data is copied that was never initialized. I thought maybe the compiler would optimize all that out, but it seems that it does not.
I have no problems using pointers for unlock(). It was strange using pointers for lock(), but not for unlock() anyway.
Or would you prefer something else?
John Ogness
| |