Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2358689pxb; Mon, 20 Sep 2021 20:02:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwvrsBpiZ3bFzEVubgdPSgTCfrFz58O6KrGvtCUTv92qPXxjs7DhEZji1HhoZ9YcpznCQES X-Received: by 2002:a05:6402:17d5:: with SMTP id s21mr33120028edy.377.1632193341728; Mon, 20 Sep 2021 20:02:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632193341; cv=none; d=google.com; s=arc-20160816; b=djgqXs6cKZwP6451+ghZHsxWBkOc20Bnqme4WQrBeFue50Uv1oTsAyyQ+SapmKQ23Z /YzsuFQo+IQzPodG5FH3+esWCa0tEjhsxBCunEORA8RxUUdWmamYo9/CNSJ7pyVc3lel 7lVtDehg84ymVinyQT4pVSypxo+FE6CodCDdTv+cyEUJUfmcOIRkOFnZT5k5gPRBJWbC 2jNf3lAAGNJeIeWN0y0vJ8IeGMLbNlXrsR8jEB5jWsOkjjPzEk81plIS4JlUcQPQAVVB XacyYxc5b/IOX3mWAVZzLwQq7qlLHCM3FAjBpFObudzr2rUfGFPrFamW5GFuWaLRwBYd uWLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=tUvDrFJV0hIvR0FAKJySgQhotyp6SN23Xzoslz2iXJo=; b=W4QMVHKfQxsbUyssg3pHd3Mu+jYa/ZoQvHsIKRjj0u0yicpQZPgT//K1w2N5YP/7qd EyFYTeh0FEzuLEX/cE1fFBzdNui9VEDa/WFcRE2CvHh916f6lHXXWnDUboEn3n6FkN/s 0ParpFHluA+yVwMYtZlT6EGMQ5SEd/ou4V1m/Plp6vRQ7hcVyyvbSIaGzQV5kt/ue51+ RYMgLKdvyhdbApxBZGh8oKWPrBTHNtq/CK/Rw77+WVrJDhKH28fdBwzqT5nE1ViydMY5 rp0X5m4Dh8XCEbpMlb3MU10USJSVms8y2SObLZEBl5JS7S5Q8r77G3mU/2z9r2ZH4X7r jQiA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e1si7628839ejm.383.2021.09.20.20.01.58; Mon, 20 Sep 2021 20:02:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237748AbhITVkM (ORCPT + 99 others); Mon, 20 Sep 2021 17:40:12 -0400 Received: from mail-pj1-f50.google.com ([209.85.216.50]:39536 "EHLO mail-pj1-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232305AbhITViL (ORCPT ); Mon, 20 Sep 2021 17:38:11 -0400 Received: by mail-pj1-f50.google.com with SMTP id h3-20020a17090a580300b0019ce70f8243so436630pji.4; Mon, 20 Sep 2021 14:36:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tUvDrFJV0hIvR0FAKJySgQhotyp6SN23Xzoslz2iXJo=; b=rwZ8zwlOidTutGkQxGYrOqBF81JA94pO/u/nicLbi8TPvOZ0lWpHXtFWr08RN/wTrJ IiIRTTtidtb818tIxjG/sUl5qP6oemw3Jz7NH5ypuMD3jhsZtqgdq7nXaYmVlHPphAe6 JpmYpsu8+zYOKlgCbMae/wIw0vaIS9E8dBUCPclWhDxMbd5eZyuMAIQra8GhouB3syxw OBARQGaw+56cXoXGnBWnkpDI96myiIfCgjYJZfOWdKGg0XEEZaPxNDGthq4sLqiMWIhn C5u9x8Dtl1q17tfaSXB4/8frZQnBZ9LqYhC++2BEzCj6ZaLvpFProu+dyeHa57B/KSaG lYuQ== X-Gm-Message-State: AOAM530VxUgz86UupmG9CScevh7BcKZpOOC90kodH2IHniIoGjjidd6X ufdv9YGfPrYmJC0PgNlRyQ0= X-Received: by 2002:a17:90a:9a2:: with SMTP id 31mr1283242pjo.58.1632173803816; Mon, 20 Sep 2021 14:36:43 -0700 (PDT) Received: from bvanassche-linux.mtv.corp.google.com ([2620:15c:211:201:6e2a:d64:7d9d:bd4a]) by smtp.gmail.com with ESMTPSA id i5sm328287pjk.47.2021.09.20.14.36.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Sep 2021 14:36:42 -0700 (PDT) Subject: Re: [PATCH v7 09/12] sysfs: fix deadlock race with module removal To: Luis Chamberlain , tj@kernel.org, gregkh@linuxfoundation.org, akpm@linux-foundation.org, minchan@kernel.org, jeyu@kernel.org, shuah@kernel.org Cc: rdunlap@infradead.org, rafael@kernel.org, masahiroy@kernel.org, ndesaulniers@google.com, yzaikin@google.com, nathan@kernel.org, ojeda@kernel.org, penguin-kernel@I-love.SAKURA.ne.jp, vitor@massaru.org, elver@google.com, jarkko@kernel.org, glider@google.com, rf@opensource.cirrus.com, stephen@networkplumber.org, David.Laight@ACULAB.COM, jolsa@kernel.org, andriy.shevchenko@linux.intel.com, trishalfonso@google.com, andreyknvl@gmail.com, jikos@kernel.org, mbenes@suse.com, ngupta@vflare.org, sergey.senozhatsky.work@gmail.com, reinette.chatre@intel.com, fenghua.yu@intel.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, lizefan.x@bytedance.com, hannes@cmpxchg.org, daniel.vetter@ffwll.ch, bhelgaas@google.com, kw@linux.com, dan.j.williams@intel.com, senozhatsky@chromium.org, hch@lst.de, joe@perches.com, hkallweit1@gmail.com, axboe@kernel.dk, jpoimboe@redhat.com, tglx@linutronix.de, keescook@chromium.org, rostedt@goodmis.org, peterz@infradead.org, linux-spdx@vger.kernel.org, linux-doc@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, copyleft-next@lists.fedorahosted.org References: <20210918050430.3671227-1-mcgrof@kernel.org> <20210918050430.3671227-10-mcgrof@kernel.org> From: Bart Van Assche Message-ID: <6db06c27-e3af-b0aa-6f38-9c31dd8194fa@acm.org> Date: Mon, 20 Sep 2021 14:36:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210918050430.3671227-10-mcgrof@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/17/21 10:04 PM, Luis Chamberlain wrote: > A sketch of how this can happen follows: > > CPU A CPU B > whatever_store() > module_unload > mutex_lock(foo) > mutex_lock(foo) > del_gendisk(zram->disk); > device_del() > device_remove_groups() > > In this situation whatever_store() is waiting for the mutex foo to > become unlocked, but that won't happen until module removal is complete. > But module removal won't complete until the sysfs file being poked > completes which is waiting for a lock already held. If I remember correctly I encountered the deadlock scenario described above for the first time about ten years ago while working on the SCST project. We solved this deadlock by removing the sysfs attributes from the module unload code before grabbing mutex_lock(foo), e.g. by calling sysfs_remove_file(). This works because calling sysfs_remove_file() multiple times in a row is safe. Is that solution good enough for the zram driver? Thanks, Bart.