From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9452470 for ; Wed, 21 Jul 2021 15:49:57 +0000 (UTC) Received: by mail-pl1-f173.google.com with SMTP id b2so1167373plx.1 for ; Wed, 21 Jul 2021 08:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=inBYu5ag7c45MW8HDl2wJjLOE4iuBAdb1D4julHQh2I=; b=JoYCQOT90yZYg68ABYw09NUwlkvhYWyLIYIuvV9ipOkP0s5IMJzBj6Y4eWj31EP2Pj YURwAVn4LFLGmPWOH2vgvHU0VZkz5Hkb1A0c6Aw7gfCGoGDGIrZQWP9fMMSQkAQ42o/4 QUKM37vhm8hVlZ+CCg3uLAfP96bmynoBUTlPjBHECASSdEB8VZ5rJC4ElQPIlJqMEaU4 Gd9bIqliavPLOCz5lnQ0tZqQ0Z3P5gREfEUGime2KX1aUctMEb6qdkF7V2Fxe/uO6eIU sRgNrCWjgD3ZbHRvHMt81AtI8dNKiummeY/rh6pkE01/c5pW2sChVlYgTN4kwHUbqR25 l3cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=inBYu5ag7c45MW8HDl2wJjLOE4iuBAdb1D4julHQh2I=; b=sjdgr6s4SblGgxlywE4VpS6cUJHt3UndQI4Us7bLU52w61eUr3MfSnjqatE0x7TeuU ziWsdrer+ZQgQGJyPSauj/+J1uOoVHHrJN6pBjIbnxPH9iww9ijXd6Z7tbF4PCs3oDzw 1AuvnpzCi5vdBkMKiyJ4d2AT1lJ3BcniyRex47VTWWRHscKwuNikWcbtd8ay8mKqmYTx osphK5eeJjCR7x//C9HrQELHMVaTGisP7sD5NXHMSDnVHwSFxQ3WBKrt1v34WD07+y9C 4pCiwbBNE8zWgMgxka8fCwj2EOgbCtpyNk0vCXqnR/xnock3VqxjumUjwFil1DNbXgNp sh8w== X-Gm-Message-State: AOAM531nEC/HMW/8lSAFIv0slnEa1stAsMv8K2iztPjepWuDmqIvwBJv Avo7674kXRIQ5CKt60KTpcONCg9DA4MNxnnQHu4= X-Google-Smtp-Source: ABdhPJwtxXMeUt1ckwjLUEFJWmO5RZqlQfn6S4KZp6SzUCFHTOMZdyZ2jJ5TYjZwgNfAJEpk2VN3WDR6FtGvKnLyL8E= X-Received: by 2002:a17:90b:3647:: with SMTP id nh7mr36027626pjb.228.1626882597112; Wed, 21 Jul 2021 08:49:57 -0700 (PDT) Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20210707105000.GA4394@sirena.org.uk> <11c07bc291b443c2683a2baff5b180ff5b0729a5.camel@HansenPartnership.com> In-Reply-To: From: Andy Shevchenko Date: Wed, 21 Jul 2021 18:49:17 +0300 Message-ID: Subject: Re: cdev/devm_* issues (was Re: [TECH TOPIC] Rust for Linux) To: Linus Walleij Cc: Wedson Almeida Filho , Greg KH , Laurent Pinchart , James Bottomley , Mark Brown , Roland Dreier , Miguel Ojeda , "ksummit@lists.linux.dev" , Daniel Vetter , Bartosz Golaszewski , "open list:GPIO SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 21, 2021 at 4:46 PM Linus Walleij wr= ote: > On Wed, Jul 14, 2021 at 12:35 AM Andy Shevchenko > wrote: > > > To me described scenario sounds rather like an object lifetime possible= issue. > > In any case, shouldn=E2=80=99t VFS guarantee by a reference counting th= at > > gpiochip_remove() wouldn=E2=80=99t be called while file descriptor is i= n use? > > Or am I looking from the wrong end here? > > What happens is that the GPIO device disappears (such as unplugging > a USB GPIO expander) while a multithreaded userspace is hammering > exotic ioctl() commands to the same device like crazy. > > Under these circumstances (which should be rare, but you know, > developers) it could happen that an ioctl() sneak in before the > gpio_chip pointer is NULL if I read the code right. So, gpio_chip is NULL but gpiodev is not NULL, correct? If so, it means that the above mentioned scenario applies to the latter one and I understand the checks. --=20 With Best Regards, Andy Shevchenko 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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 41E53C12002 for ; Wed, 21 Jul 2021 15:49:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1DD4E6127C for ; Wed, 21 Jul 2021 15:49:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232977AbhGUPJV (ORCPT ); Wed, 21 Jul 2021 11:09:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232494AbhGUPJU (ORCPT ); Wed, 21 Jul 2021 11:09:20 -0400 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 891A5C061575 for ; Wed, 21 Jul 2021 08:49:57 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id gx2so1894620pjb.5 for ; Wed, 21 Jul 2021 08:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=inBYu5ag7c45MW8HDl2wJjLOE4iuBAdb1D4julHQh2I=; b=JoYCQOT90yZYg68ABYw09NUwlkvhYWyLIYIuvV9ipOkP0s5IMJzBj6Y4eWj31EP2Pj YURwAVn4LFLGmPWOH2vgvHU0VZkz5Hkb1A0c6Aw7gfCGoGDGIrZQWP9fMMSQkAQ42o/4 QUKM37vhm8hVlZ+CCg3uLAfP96bmynoBUTlPjBHECASSdEB8VZ5rJC4ElQPIlJqMEaU4 Gd9bIqliavPLOCz5lnQ0tZqQ0Z3P5gREfEUGime2KX1aUctMEb6qdkF7V2Fxe/uO6eIU sRgNrCWjgD3ZbHRvHMt81AtI8dNKiummeY/rh6pkE01/c5pW2sChVlYgTN4kwHUbqR25 l3cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=inBYu5ag7c45MW8HDl2wJjLOE4iuBAdb1D4julHQh2I=; b=A4YIrHEzfUNkAaYMkjdWVwG2yBadpFvMnk6O/4cVBlXMXkkIDfUKJOrOGhqtCMVREl d91T/C88tSlPKTSO6DyrfzkAdNFAtT++t1uQsyRuU4Tab/cE+uBq+U/0yE7jXgvVjWdO +QXNKA2FeiYYLny2D2AGVuQjDf4JqgFcuT9nqzto3WM/17XKsmf5prBbHKt6Ta/B/y5z Bb8nd3ZT90vXPYznzJGs3ADzLcG7cBmNcci5BHOiOuqkD0bd8bQ2z93+3t3oNa/qm9bK YytprtoZpDIzK1rqffdlMkcYLeWKnj/BmNvMa+SqSrwNrLrLAVh9mfz0nWD+gnD7XrZo qE3A== X-Gm-Message-State: AOAM532eoOjDmKXzsH24SowSvP84W0aMnSaOBP0BwJbbN43JzEcoFk0V g+hQk9T2Ias00cRhLOD/cXB3kl8835aZTx6g9d8= X-Google-Smtp-Source: ABdhPJwtxXMeUt1ckwjLUEFJWmO5RZqlQfn6S4KZp6SzUCFHTOMZdyZ2jJ5TYjZwgNfAJEpk2VN3WDR6FtGvKnLyL8E= X-Received: by 2002:a17:90b:3647:: with SMTP id nh7mr36027626pjb.228.1626882597112; Wed, 21 Jul 2021 08:49:57 -0700 (PDT) MIME-Version: 1.0 References: <20210707105000.GA4394@sirena.org.uk> <11c07bc291b443c2683a2baff5b180ff5b0729a5.camel@HansenPartnership.com> In-Reply-To: From: Andy Shevchenko Date: Wed, 21 Jul 2021 18:49:17 +0300 Message-ID: Subject: Re: cdev/devm_* issues (was Re: [TECH TOPIC] Rust for Linux) To: Linus Walleij Cc: Wedson Almeida Filho , Greg KH , Laurent Pinchart , James Bottomley , Mark Brown , Roland Dreier , Miguel Ojeda , "ksummit@lists.linux.dev" , Daniel Vetter , Bartosz Golaszewski , "open list:GPIO SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Wed, Jul 21, 2021 at 4:46 PM Linus Walleij wr= ote: > On Wed, Jul 14, 2021 at 12:35 AM Andy Shevchenko > wrote: > > > To me described scenario sounds rather like an object lifetime possible= issue. > > In any case, shouldn=E2=80=99t VFS guarantee by a reference counting th= at > > gpiochip_remove() wouldn=E2=80=99t be called while file descriptor is i= n use? > > Or am I looking from the wrong end here? > > What happens is that the GPIO device disappears (such as unplugging > a USB GPIO expander) while a multithreaded userspace is hammering > exotic ioctl() commands to the same device like crazy. > > Under these circumstances (which should be rare, but you know, > developers) it could happen that an ioctl() sneak in before the > gpio_chip pointer is NULL if I read the code right. So, gpio_chip is NULL but gpiodev is not NULL, correct? If so, it means that the above mentioned scenario applies to the latter one and I understand the checks. --=20 With Best Regards, Andy Shevchenko