Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2965275pxb; Fri, 12 Feb 2021 06:09:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJz8KHRpI2nfiY5EMSG7bDx6OQdQh1UZPsA5N6IDehhcEQHTz4Dv1UuxmKrszrK5e5i2Wp7+ X-Received: by 2002:a2e:9582:: with SMTP id w2mr1776272ljh.218.1613138974536; Fri, 12 Feb 2021 06:09:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613138974; cv=none; d=google.com; s=arc-20160816; b=w/jDAkM++Gfl0IYWxqsCph1N49CiIwEKEmISqr+4pJn7LECggPz2CtkgFN71xRQdSu CZYv5C0d7YHIaBQbGpml+Oz/Z4Z36zhTeIaXGQ3/sfkb04v9vK2Zr0WpHx1OAZLs5kVN DmkqcnSECBrLxEr7Qv8xCzeGCIvgjGoXzy4wpDbr317UnU12fEhc4/0pAALbJjhZUdt3 efqtKIiV1Q3xRSxD5YRcGrXZK7NHGWmzFpTRZaYX5o2WfGctveTTRf1zeLhW16Zip83u +x3u0f+tobBzmsf2ECXFMB+UlOnMXpIiR3nh444RxI0vpZvZzRF0w0LJZM91V49BiKES R1wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ZZgcR0GXQOuQH7akp/dBCCzUPB9l3DB+PduIt221Fus=; b=0iTL8Yw2l/riAWPiAehF2/08JK/P8eX4TT1zHFMZGt1cPwHClhN1r3hghQNGuKoLGH efQrNZyOx2oqlKc+HKvBGC6xZMBn1LWJFp0V9SGdbrr5hlZEVjir1x1EBxqoJ4BWdrMl OJsTZl347jZqHnJ1r9dDoHRfew38ZOaZKJxXMPuqZ/LN6/oc4qcPv/qVNioAaW//1ss0 I1GdT5aIojPLcoHEBSqAfd2081I8NXJ/iyhrG29iULHN4DxcyRxHywKSMsOljSLtO6X/ VnubbVCPdOAKhzHhu08mJWyiHRsBS8YmB4LpqD1mJazE+bAD+YKVRaCxMmCbxnsRFlgO nWsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LwSJnQ9R; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e1si6005056eja.255.2021.02.12.06.09.10; Fri, 12 Feb 2021 06:09:34 -0800 (PST) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LwSJnQ9R; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231553AbhBLOIS (ORCPT + 99 others); Fri, 12 Feb 2021 09:08:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230174AbhBLOIQ (ORCPT ); Fri, 12 Feb 2021 09:08:16 -0500 Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28972C061574; Fri, 12 Feb 2021 06:07:36 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id 67so2919022uao.1; Fri, 12 Feb 2021 06:07:36 -0800 (PST) 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; bh=ZZgcR0GXQOuQH7akp/dBCCzUPB9l3DB+PduIt221Fus=; b=LwSJnQ9Rf7hYrkwVZMRDzruVm0i2SDp4GtwQaF5CkTY3sHxUJlqfaTiUG7vBZXAysI WOoNc4c7DZJ90E9NDXYemZqoZftzw8SueDOMpxFaprmEeIWxuupOI48xua7PFgZI8TS2 MuCOrmK594Wcb0qTFn9LPw7GwTDNCwh9ncvLk+z6UtHWdktN5PfbBC/eqFOXGzQgSFRX 6mL3Xf0H7pWjn/qdsrKfrV6cCXfXLaCFmLaPkchfA9iTlodzvz2zBkByjRw0CbCAg6C2 v4D6aUG3BvdFwACvMlf+yXZRTcYmAiy+DnflKtJ+Lel3IL+BqQIuvkeYDunVhLXs8/TL 78+Q== 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; bh=ZZgcR0GXQOuQH7akp/dBCCzUPB9l3DB+PduIt221Fus=; b=RyTUMBqqRIyEooJbQzYse8B8ZLYEyk7BhiabW6fyVxtChtaH/fzT2PrlwFY44JpBHO DxsPf8jEdXUFH+E6nQgxXLC6+JyO0ybPtrRdBZWp/kTE2PAVMmvtnY+vPmiCXHrHA9T8 w62EcOBeEzMds5sqqwB/475YE9HN81kQhZn7A8JhwbdJcG5/Si3DAuzoxu6XN3r+UCAe NQalUkTO5QqIjEpftJf4WiIQThWos78TA3VS14UXOvu1OnmNqRTMwZmEC3VDTxjtMpt8 LE32kRq6eLMQYZtg5csHYK2LNBdrxTQ2ssHuyE5U/TigyVxQUYZ4aYRBqHvTADiQhlcM HW1A== X-Gm-Message-State: AOAM531tynFG4FL6PfeGy583hzRdiBEZlacKVv+l2qe6qogdgo2gAj6T vK+yV92usjV8UfXUbfE8TUWcoJoaFFhPrKcJ9wpboVRByxNCtQ== X-Received: by 2002:ab0:338d:: with SMTP id y13mr1550050uap.64.1613138855360; Fri, 12 Feb 2021 06:07:35 -0800 (PST) MIME-Version: 1.0 References: <20210205163752.11932-1-chris@chris-wilson.co.uk> <20210205220012.1983-1-chris@chris-wilson.co.uk> In-Reply-To: From: Emil Velikov Date: Fri, 12 Feb 2021 14:07:23 +0000 Message-ID: Subject: Re: [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE To: Simon Ser Cc: Chris Wilson , Will Drewry , Kees Cook , Daniel Vetter , Intel Graphics Development , Rasmus Villemoes , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , Andy Lutomirski , Cyrill Gorcunov , "# 3.13+" , Andrew Morton Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 12 Feb 2021 at 13:14, Simon Ser wrote: > > On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov wrote: > > > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote: > > > > > > Userspace has discovered the functionality offered by SYS_kcmp and has > > > started to depend upon it. In particular, Mesa uses SYS_kcmp for > > > os_same_file_description() in order to identify when two fd (e.g. device > > > or dmabuf) > > > > As you rightfully point out, SYS_kcmp is a bit of a two edged sword. > > While you mention the CONFIG issue, there is also a portability aspect > > (mesa runs on more than just linux) and as well as sandbox filtering > > of the extra syscall. > > > > Last time I looked, the latter was still an issue and mesa was using > > SYS_kcmp to compare device node fds. > > A far shorter and more portable solution is possible, so let me > > prepare a Mesa patch. > > Comparing two DMA-BUFs can be done with their inode number, I think. > > Comparing two device FDs is more subtle, because of GEM handle > ref'counting. You sometimes really want to check whether two FDs are > backed by the same file *description*. See [1] for details. > Thanks for the correction and the reference. Seems like I've short circuited file description table vs file descriptor. Emil