Re: [kernel-locking] question about structure field initialization

From: Chris Wilson
Date: Fri May 12 2017 - 04:38:56 EST


On Thu, May 11, 2017 at 03:00:02PM -0500, Gustavo A. R. Silva wrote:
>
> Hello everybody,
>
> While looking into Coverity ID 1402035 I ran into the following
> piece of code at kernel/locking/test-ww_mutex.c:197:
>
> 197static int test_abba(bool resolve)
> 198{
> 199 struct test_abba abba;
> 200 struct ww_acquire_ctx ctx;
> 201 int err, ret;
> 202
> 203 ww_mutex_init(&abba.a_mutex, &ww_class);
> 204 ww_mutex_init(&abba.b_mutex, &ww_class);
> 205 INIT_WORK_ONSTACK(&abba.work, test_abba_work);
> 206 init_completion(&abba.a_ready);
> 207 init_completion(&abba.b_ready);
> 208 abba.resolve = resolve;
> 209
> 210 schedule_work(&abba.work);
> 211
> 212 ww_acquire_init(&ctx, &ww_class);
> 213 ww_mutex_lock(&abba.a_mutex, &ctx);
> 214
> 215 complete(&abba.a_ready);
> 216 wait_for_completion(&abba.b_ready);
> 217
> 218 err = ww_mutex_lock(&abba.b_mutex, &ctx);
> 219 if (resolve && err == -EDEADLK) {
> 220 ww_mutex_unlock(&abba.a_mutex);
> 221 ww_mutex_lock_slow(&abba.b_mutex, &ctx);
> 222 err = ww_mutex_lock(&abba.a_mutex, &ctx);
> 223 }
> 224
> 225 if (!err)
> 226 ww_mutex_unlock(&abba.b_mutex);
> 227 ww_mutex_unlock(&abba.a_mutex);
> 228 ww_acquire_fini(&ctx);
> 229
> 230 flush_work(&abba.work);
> 231 destroy_work_on_stack(&abba.work);
> 232
> 233 ret = 0;
> 234 if (resolve) {
> 235 if (err || abba.result) {
> 236 pr_err("%s: failed to resolve ABBA
> deadlock, A err=%d, B err=%d\n",
> 237 __func__, err, abba.result);
> 238 ret = -EINVAL;
> 239 }
> 240 } else {
> 241 if (err != -EDEADLK && abba.result != -EDEADLK) {
> 242 pr_err("%s: missed ABBA deadlock, A
> err=%d, B err=%d\n",
> 243 __func__, err, abba.result);
> 244 ret = -EINVAL;
> 245 }
> 246 }
> 247 return ret;
> 248}
>
> The issue here is that apparently abba.result is being used at lines
> 235, 237 and 241 without previous initialization.
>
> It seems to me that this is an issue, but I may be overlooking something.
> Can someone help me to spot where exactly abba.result is being
> initialized, if at all?

You are only looking at half the code. Though the schedule/flush it is
indirectly executing test_abba_work().
-Chris

--
Chris Wilson, Intel Open Source Technology Centre