From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f180.google.com (mail-dy1-f180.google.com [74.125.82.180]) (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 E72E5265606 for ; Tue, 7 Apr 2026 05:19:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775539151; cv=none; b=k4u7rOBGZKm04n8X6J9oGDOxvuzco62U1nj9b83irOvRJ9G5604N3zZOorl1dWr2ApKSObvywGnNJ9lxsjpCnERoCOdw3OIs6l9av5zx28OvP/HgTdn7+SovNsJi9sckgpIvCHsacxE8c2qyy3nh/fKT3IvGiBJJHToOqX8HZLE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775539151; c=relaxed/simple; bh=BIleVtqMchT8Tl8GbjBxQORlC1W+9SAKfnuSUEn7qaY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CSxNbY6EI97z2LQZrOTWi7sWs1I8lEL6XpDtH2FkzxN0v7mPMvx5A0x3HyvAEA/IuUjMhf8c25Fn7SfdF/nWsl7Ac37yXz6RL8aS64bale3Wf9kDPfd119LyvwOzV6/6SayrnsFdw/ukzoLP+v4slGkV/V15jEjxZi1mwXOw6SU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=FnCe4h8A; arc=none smtp.client-ip=74.125.82.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FnCe4h8A" Received: by mail-dy1-f180.google.com with SMTP id 5a478bee46e88-2cf1646bd11so3268321eec.1 for ; Mon, 06 Apr 2026 22:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775539149; x=1776143949; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=aJPRef6pu2ylG0bboh+7Z2QxwB192DESyzZ2pn62zC0=; b=FnCe4h8AxfC0PsPdZnwVmKxQrpAti8vZ0oKMph8Ziu9GULaBexYT8JgnrgdfPbZKBA RyePj0UkvJgiw7Tmys6liHWQG+zBkIPPXHieDacxcChkHkaJXj2SckuPfuHGlonu022H TUA9eNY6ZUnif4zcShj89jz8aAhmYn/+/mM1YDdZWxLWtlAmAwc8peDYTP3L7mJUn6VZ TIE6irgBOv+CtoB87A+TYAU0A+3p4wHbOc+nXYlOiwlyhWoIHmSQtjGwhnRwH/mGlEuu 1f0yYcQFbf8oBGxnDm4HvgDwp1UpvwQnUall6tmzasUkQ9YF+o5JsgPpnRR8GdZ1hnPZ dBqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775539149; x=1776143949; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aJPRef6pu2ylG0bboh+7Z2QxwB192DESyzZ2pn62zC0=; b=UxXqki38UcSs52tUpnSC1SxvZz/21oBARADUU+BKgLqPYqeXxkLRXpdyy9FSwCS5S3 q/sixF3yF5bRykZrTYENDtEpvLC3myGtCl1+nCojbhPcE3LIYV3ta3ATKRdmGGRXV/89 6XzUF3phG/wuRRZszvys18CwHPJbg+gOwalFHSlmDUH9N7U6nljFDpQknZW3NmowcZoH qL22xGz8MZ6DJYL8lmCFAnTRzyburfcTi57UckPADU1o3bhdMZwJZ4m0QR8mYUdbbZzD O14As4nLp0gSZ5JLvktDliZHnDrvc5rcXWCoJYqtMIQGzM7NvSLZ+Lf34zhJxtUxXxIz CNQA== X-Forwarded-Encrypted: i=1; AJvYcCVLakvezRKYNAHW2PFw47cVahNg8wtrOp3sfeSzxzfaqVIdnF6H+fq0f26VwQQqOf0DaidoYFXjFk0rXEY=@vger.kernel.org X-Gm-Message-State: AOJu0YzCLR52GiraczQ3qP9R7xGYhMWfeXVyJ4bq2xyiQlA8kh+quwiY QE3iLEsQi9O6/25je2htCFb9GgPilXV4Vo/NKTzZc/cFlflx98oUDhAD9Hi/0w== X-Gm-Gg: AeBDieuKcATeX9tmRVYIk+DO16S62BJBVqvNcoCix6UIhA9srK6yHNh1EucDZI0vSSv o+9iuJvsxHUwJq7OLUcKWswoBo0aEwV4nKtxdp1A8TBTUfdqsvyvFmTrjD0dAtlUGfeBmPNJBX9 8phgnIYXOUcQc+Z7kH28ZbBUqD2m7RG5uC846xYnY5hWahqGHrIJEkxwqFvkL2vl/6fQFwNjic6 uPNVLNmNEa41w9WJWDak6mte/x3tbw1VRNVljd1fEkgDsq80nKNJfFhXMzQ9SbLuQon6ImgB/Ps 0mcJaLFKsjxnEtudgatiI6s4NqHA4HGwQ+xTM/xeAX0jUe5agGYEGhTa9Hu8nTwv4aEc9IEvnA5 wQeb3gQb2JuwmmJKPsPk/UPnYeTTgjgk/sm45fI81gSgKiX+Tw7tgzhwzLZUwIBjvkmw1b6PZJs sSfC8mklyQnpqj5yoaGkuvPgVzSBxXsxopHgA9yZPmTjUwVkpwkhDtirt5fM4dxJqi X-Received: by 2002:a05:693c:3005:b0:2c5:60d0:7031 with SMTP id 5a478bee46e88-2cbf97f57d8mr8312335eec.4.1775539148835; Mon, 06 Apr 2026 22:19:08 -0700 (PDT) Received: from google.com ([2a00:79e0:2ebe:8:dd71:7176:b4e4:a7a5]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2d16d115c00sm1766354eec.12.2026.04.06.22.19.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2026 22:19:08 -0700 (PDT) Date: Mon, 6 Apr 2026 22:19:05 -0700 From: Dmitry Torokhov To: Mikhail Gavrilov Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core Message-ID: References: <20260228223628.472208-1-mikhail.v.gavrilov@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sorry for disappearing again... On Mon, Mar 23, 2026 at 10:39:29AM +0500, Mikhail Gavrilov wrote: > On Mon, Mar 23, 2026 at 10:34 AM Dmitry Torokhov > wrote: > > > > Hmm, I am not sure I see the issue. We are not going to change state > > back to UIST_CREATED until after uinput_destroy_device() returns so we > > will not submit more requests... > > > > What am I missing? > > You are right, there is no lock ordering issue since the state > transition is one-way. > > The reason I reused requests_lock is that uinput_request_send() > needs to atomically check state and access udev->dev. If we use a > separate state_lock and release it before calling > uinput_dev_event(), uinput_destroy_device() could run in between, > unregister the device, and we'd hit a use-after-free on udev->dev. > > A separate lock would need to be held across the same scope, > making it functionally equivalent to reusing requests_lock. I was talking about taking this new lock in both uinput_request_send() as well as in uinput_destroy_device() when updating the state. With that requests_lock will be taken only in uinput_request_alloc_id(), uinput_request_release_slot(), and uinput_flush_requests(). Thanks. -- Dmitry