From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,T_DKIMWL_WL_MED,USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BEDF5C004C9 for ; Wed, 8 May 2019 01:43:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7C37220C01 for ; Wed, 8 May 2019 01:43:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="O8tU0NT/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726452AbfEHBnm (ORCPT ); Tue, 7 May 2019 21:43:42 -0400 Received: from mail-oi1-f201.google.com ([209.85.167.201]:45843 "EHLO mail-oi1-f201.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726276AbfEHBnm (ORCPT ); Tue, 7 May 2019 21:43:42 -0400 Received: by mail-oi1-f201.google.com with SMTP id v13so2586938oie.12 for ; Tue, 07 May 2019 18:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=NduO8ogfu84h+oAWfquIvduxd06JrUFONyQu1hpKcT0=; b=O8tU0NT/SnusHzYpn83+BS2INjb5OytF8gAd4PLpKrAc9pjd2fZnknioiaczIYOhDJ kqmrXrN/YvIGLjts1jSeuSmkp1uTOeINhUa1ucsyXlWwjkjnAeF6m/3YvepnG5i3wttk XlHEi3gsXL9QXY2xn8mAR5nCLqTZ3U6q1VSIr1b6u8sJTz3AYVvctLlqrQ9la6PyMSAS 6jt74pchJ9l4VlKsUNpsjfMCzLz5H7bfGaCezd7vHHTp7Uqo9i+weuqDexDfbARs/oof waGeWYqGvHY6RXH6DxKIxzCoZUgbJKTgaiadsPYjNQe3JH6FKp3TQCNROaOVOKI333B8 5Qpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=NduO8ogfu84h+oAWfquIvduxd06JrUFONyQu1hpKcT0=; b=kmsFID0ihYsD/u2KaHNDtnGkkSu6fiYcevDBEi/6dJIqSp/izglRhd3dLMXNfgPEsm PRgAr4EFerjpVUCNObA2eDNAQw+3ya+fzBvKUGhrNAeZ3u7d5yi3jJbADQHSUW0w0D7F mMD2L7r1sgdUrASwTtw6T6kTVSvEjuCEFKDKl7IB5577krF/RdGL6KsMvL28kK4MXt1a WxVhmmawwq8LcnSAhEvZoWk4Glpuf/LlnqTTmnzZX9G6tMIIYjVgIFdKlj2Wp9ourJ9y awyMM4PgO0lNAiOiuBB2p3TRtsd0NlVCHghee54S80bPWvGcR//EU7ldM03Zdd+3sA6S LDew== X-Gm-Message-State: APjAAAVYDTJJDeX3LxcaccUhMEXLBcteRbbypbJ+SU6VFOEkbslc4KnO ZgyYa+mDd4UDTEVHsWSH2RlMx2jSR6Ssqnc= X-Google-Smtp-Source: APXvYqy7YZ/qZ/UMekXTXuLrAXn8JpizuXc1mSFZ4ETgnqDFgY80Xo1eHkGpsnbBKMdktWPM4OzZNXIljJO9vbE= X-Received: by 2002:a9d:7d88:: with SMTP id j8mr3292175otn.39.1557279821060; Tue, 07 May 2019 18:43:41 -0700 (PDT) Date: Tue, 7 May 2019 18:43:20 -0700 Message-Id: <20190508014320.55404-1-jsperbeck@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.21.0.1020.gf2820cf01a-goog Subject: [PATCH] percpu: remove spurious lock dependency between percpu and sched From: John Sperbeck To: Dennis Zhou , Tejun Heo , Christoph Lameter Cc: Eric Dumazet , linux-mm@kvack.org, linux-kernel@vger.kernel.org, John Sperbeck Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In free_percpu() we sometimes call pcpu_schedule_balance_work() to queue a work item (which does a wakeup) while holding pcpu_lock. This creates an unnecessary lock dependency between pcpu_lock and the scheduler's pi_lock. There are other places where we call pcpu_schedule_balance_work() without hold pcpu_lock, and this case doesn't need to be different. Moving the call outside the lock prevents the following lockdep splat when running tools/testing/selftests/bpf/{test_maps,test_progs} in sequence with lockdep enabled: ====================================================== WARNING: possible circular locking dependency detected 5.1.0-dbg-DEV #1 Not tainted ------------------------------------------------------ kworker/23:255/18872 is trying to acquire lock: 000000000bc79290 (&(&pool->lock)->rlock){-.-.}, at: __queue_work+0xb2/0x520 but task is already holding lock: 00000000e3e7a6aa (pcpu_lock){..-.}, at: free_percpu+0x36/0x260 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (pcpu_lock){..-.}: lock_acquire+0x9e/0x180 _raw_spin_lock_irqsave+0x3a/0x50 pcpu_alloc+0xfa/0x780 __alloc_percpu_gfp+0x12/0x20 alloc_htab_elem+0x184/0x2b0 __htab_percpu_map_update_elem+0x252/0x290 bpf_percpu_hash_update+0x7c/0x130 __do_sys_bpf+0x1912/0x1be0 __x64_sys_bpf+0x1a/0x20 do_syscall_64+0x59/0x400 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #3 (&htab->buckets[i].lock){....}: lock_acquire+0x9e/0x180 _raw_spin_lock_irqsave+0x3a/0x50 htab_map_update_elem+0x1af/0x3a0 -> #2 (&rq->lock){-.-.}: lock_acquire+0x9e/0x180 _raw_spin_lock+0x2f/0x40 task_fork_fair+0x37/0x160 sched_fork+0x211/0x310 copy_process.part.43+0x7b1/0x2160 _do_fork+0xda/0x6b0 kernel_thread+0x29/0x30 rest_init+0x22/0x260 arch_call_rest_init+0xe/0x10 start_kernel+0x4fd/0x520 x86_64_start_reservations+0x24/0x26 x86_64_start_kernel+0x6f/0x72 secondary_startup_64+0xa4/0xb0 -> #1 (&p->pi_lock){-.-.}: lock_acquire+0x9e/0x180 _raw_spin_lock_irqsave+0x3a/0x50 try_to_wake_up+0x41/0x600 wake_up_process+0x15/0x20 create_worker+0x16b/0x1e0 workqueue_init+0x279/0x2ee kernel_init_freeable+0xf7/0x288 kernel_init+0xf/0x180 ret_from_fork+0x24/0x30 -> #0 (&(&pool->lock)->rlock){-.-.}: __lock_acquire+0x101f/0x12a0 lock_acquire+0x9e/0x180 _raw_spin_lock+0x2f/0x40 __queue_work+0xb2/0x520 queue_work_on+0x38/0x80 free_percpu+0x221/0x260 pcpu_freelist_destroy+0x11/0x20 stack_map_free+0x2a/0x40 bpf_map_free_deferred+0x3c/0x50 process_one_work+0x1f7/0x580 worker_thread+0x54/0x410 kthread+0x10f/0x150 ret_from_fork+0x24/0x30 other info that might help us debug this: Chain exists of: &(&pool->lock)->rlock --> &htab->buckets[i].lock --> pcpu_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pcpu_lock); lock(&htab->buckets[i].lock); lock(pcpu_lock); lock(&(&pool->lock)->rlock); *** DEADLOCK *** 3 locks held by kworker/23:255/18872: #0: 00000000b36a6e16 ((wq_completion)events){+.+.}, at: process_one_work+0x17a/0x580 #1: 00000000dfd966f0 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x17a/0x580 #2: 00000000e3e7a6aa (pcpu_lock){..-.}, at: free_percpu+0x36/0x260 stack backtrace: CPU: 23 PID: 18872 Comm: kworker/23:255 Not tainted 5.1.0-dbg-DEV #1 Hardware name: ... Workqueue: events bpf_map_free_deferred Call Trace: dump_stack+0x67/0x95 print_circular_bug.isra.38+0x1c6/0x220 check_prev_add.constprop.50+0x9f6/0xd20 __lock_acquire+0x101f/0x12a0 lock_acquire+0x9e/0x180 _raw_spin_lock+0x2f/0x40 __queue_work+0xb2/0x520 queue_work_on+0x38/0x80 free_percpu+0x221/0x260 pcpu_freelist_destroy+0x11/0x20 stack_map_free+0x2a/0x40 bpf_map_free_deferred+0x3c/0x50 process_one_work+0x1f7/0x580 worker_thread+0x54/0x410 kthread+0x10f/0x150 ret_from_fork+0x24/0x30 Signed-off-by: John Sperbeck --- mm/percpu.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mm/percpu.c b/mm/percpu.c index 68dd2e7e73b5..d832793bf83a 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -1738,6 +1738,7 @@ void free_percpu(void __percpu *ptr) struct pcpu_chunk *chunk; unsigned long flags; int off; + bool need_balance = false; if (!ptr) return; @@ -1759,7 +1760,7 @@ void free_percpu(void __percpu *ptr) list_for_each_entry(pos, &pcpu_slot[pcpu_nr_slots - 1], list) if (pos != chunk) { - pcpu_schedule_balance_work(); + need_balance = true; break; } } @@ -1767,6 +1768,9 @@ void free_percpu(void __percpu *ptr) trace_percpu_free_percpu(chunk->base_addr, off, ptr); spin_unlock_irqrestore(&pcpu_lock, flags); + + if (need_balance) + pcpu_schedule_balance_work(); } EXPORT_SYMBOL_GPL(free_percpu); -- 2.21.0.1020.gf2820cf01a-goog