Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp6152599rwl; Thu, 29 Dec 2022 08:12:39 -0800 (PST) X-Google-Smtp-Source: AMrXdXvB0F/1MzaSfrGwtA+wEEK4lNdO5XcYnog4t/6ReOMEXOQE7O16rG4JRqKrgr79r8T+Uc5Q X-Received: by 2002:a05:6402:c14:b0:45c:835b:ac66 with SMTP id co20-20020a0564020c1400b0045c835bac66mr22925925edb.33.1672330359035; Thu, 29 Dec 2022 08:12:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672330359; cv=none; d=google.com; s=arc-20160816; b=zDh3AscDop0iejm9R2kBCxVz5HfmatfJcp18yZTutQGHdANQjDbRVh4QGAMgMnIsoQ GO1CBASUpbvGTXDQleZ67xKjuolox+AyUUMZE2qaK16qzfvKsgRbJbJoVHlKlJS/57hg ONs0AoxpmEBDgu63N+KyuxP1vjYTQ9ZFwGCATEOV13qum3xozEIZddUFvRwl8gYph8Q4 iUdKhZoXOaUs1n2OgJXs1k1QK3auYnJYDOCnnENWzbbusR/pbTgjCnMHQRKztu8duhX8 HWVZ6au63nzaKo9w8el9OimGIJRDiGUgFcv/+IZ+DSQLVt1Qat04pcxtS/VOELuq1KkW UF6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=52wkDyJgM41odNR1mvIEESkHB4XxW72pzCULKOBODro=; b=rsIIOSX4jw97Bo8Sb6EGKVo9/X8a/bp1snpmHA0/VlOJtlZeUmcIj0/YqZ7oXGTg8K t7TfTba3Ee7SFCBup/aLs5Mw1eJ7tHKGQ/zJHU6n6T2a61Ws1MEO3ceN9HKUOTNuy4Km bf0TCgXzL8PTn7EvRBgHdXDO5TctirplHlZ4z5pgiTj0zyhQKvIxagb9PkDI2uKTaGJx 6bhIN1a7NY8RBQTqQWKgzA68Wlou7L45pMIylTOYxDja26kJaUsVDzhwTmnCALdV9/qU zsK6H7PoRc7ejZA4A5HomlTN1dQ3Dnow8liihQ42FOui278m2LFW9IR4MHjCvX8qScnQ SIFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20210112.gappssmtp.com header.s=20210112 header.b="i/Q3rBBJ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c16-20020aa7df10000000b004627d582888si13651089edy.24.2022.12.29.08.12.24; Thu, 29 Dec 2022 08:12:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20210112.gappssmtp.com header.s=20210112 header.b="i/Q3rBBJ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233599AbiL2QAx (ORCPT + 61 others); Thu, 29 Dec 2022 11:00:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231241AbiL2QAv (ORCPT ); Thu, 29 Dec 2022 11:00:51 -0500 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4FD0A307 for ; Thu, 29 Dec 2022 08:00:50 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id ay40so13453586wmb.2 for ; Thu, 29 Dec 2022 08:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=52wkDyJgM41odNR1mvIEESkHB4XxW72pzCULKOBODro=; b=i/Q3rBBJia8cr7Iez0q1cdFjoD02/5KDg2mON9GRfrpaHmtxfIu5nkhdgcN/3eh9g3 PZpR2vAgobXjM89Pw2G4Jcq6DyJOMao33UjY9Yka1qz7MwrqwiLRBfxv9SumFhlZ/g/S IR6+3j1W3cRQXmPl18OCJFRHrlz5fucbLtDmv6B0Z1GqLUZytAqVANAle9Jh0fWmlb/o Vdrarrj47hY4Jd892VytWiFj83bVo/UENcTFhtjxnglMH5wtFHQlbSuL8hC9G0EjQ8He P3dcpJppwpQ5LQikz8pTmotXo7rmWiAyhVCF5FvCcuNVMG4FoMw0Jiq4n1znwkJ2QPBz pYqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=52wkDyJgM41odNR1mvIEESkHB4XxW72pzCULKOBODro=; b=c66VC79FZhKdeatASg1ZuqRM1XeXGvfRVmcYeVYaJlqWsrCN8UziZwGb/ztcTnDwSk l9Kvib3PM0MXT9M3yMJrXOjIfRyvJKjz2iw7Tui3HSGg+jOeyTqWY0Xf4SVbPKO4zh/F vjDPoSwAyx2BT2/EZF+42CgPvx9MJGU1QNqa5s6HbWt7I4vuQ8r//JXaBFDalC+ugn17 cK30CqBgFq5jNOYr+1kRuONMAktnRjZqhPAG58zaqe+mrpeBvBbGM4iGlTRlHo7ZtLz2 Pfxc5T+gZz4ndIxgWZh4zsDcH8356gYq0vP8Y0G+z72PHaDNeIxbYJb7RboVIqygr5zb rb6w== X-Gm-Message-State: AFqh2krHsWRumFwxnw4dz9JKa5DS6gCKXDi50DUJuLzGTrTnEXy2O/86 gfe0MMKQH0qL7KRKnVMy29kNnQ== X-Received: by 2002:a05:600c:34ca:b0:3d6:80b5:f948 with SMTP id d10-20020a05600c34ca00b003d680b5f948mr20626555wmq.39.1672329648876; Thu, 29 Dec 2022 08:00:48 -0800 (PST) Received: from brgl-uxlite.home ([2a01:cb1d:334:ac00:8f7a:98d8:9d8d:ced8]) by smtp.gmail.com with ESMTPSA id c12-20020a05600c0a4c00b003cfa3a12660sm42511593wmq.1.2022.12.29.08.00.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Dec 2022 08:00:48 -0800 (PST) From: Bartosz Golaszewski To: Wolfram Sang Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Bartosz Golaszewski Subject: [PATCH v2 0/2] i2c: fortify the subsystem against user-space induced deadlocks Date: Thu, 29 Dec 2022 17:00:43 +0100 Message-Id: <20221229160045.535778-1-brgl@bgdev.pl> X-Mailer: git-send-email 2.37.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Bartosz Golaszewski Several subsystems in the kernel that export device files to user-space suffer from a bug where keeping an open file descriptor associated with this device file, unbinding the device from its driver and then calling any of the supported system calls on that file descriptor will result in either a crash or - as is the case with i2c - a deadlock. This behavior has been blamed on extensive usage of device resource management interfaces but it seems that devres has nothing to do with it, the problem would be the same whether using devres or freeing resources in .remove() that should survive the driver detach. Many subsystems already deal with this by implementing some kind of flags in the character device data together with locking preventing the user-space from dropping the subsystem data from under the open device. In i2c the deadlock comes from the fact that the function unregistering the adapter waits for a completion which will not be passed until all references to the character device are dropped. The first patch in this series is just a tweak of return values of the notifier callback. The second addresses the deadlock problem in a way similar to how we fixed this issue in the GPIO subystem. Details are in the commit message. v1 -> v2: - keep the device release callback and use it to free the IDR number - rebase on top of v6.2-rc1 Bartosz Golaszewski (2): i2c: dev: fix notifier return values i2c: dev: don't allow user-space to deadlock the kernel drivers/i2c/i2c-core-base.c | 26 ++------- drivers/i2c/i2c-dev.c | 112 +++++++++++++++++++++++++++++------- include/linux/i2c.h | 2 - 3 files changed, 96 insertions(+), 44 deletions(-) -- 2.37.2