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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 0BD22C282CC for ; Thu, 7 Feb 2019 19:08:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C63FA21925 for ; Thu, 7 Feb 2019 19:08:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="DiBorQqs" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726733AbfBGTIr (ORCPT ); Thu, 7 Feb 2019 14:08:47 -0500 Received: from mail-it1-f194.google.com ([209.85.166.194]:40006 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727002AbfBGTIp (ORCPT ); Thu, 7 Feb 2019 14:08:45 -0500 Received: by mail-it1-f194.google.com with SMTP id h193so2479588ita.5 for ; Thu, 07 Feb 2019 11:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b2nE7qIiS+6gxKEBlirTtJrR36SmIXPOF3JmCVu6kGM=; b=DiBorQqs1Ek9B2OqqvtMvESlRjKQ87XsTHAmupJIwJeBoTaaY4XUDhJdXPHui3J0nJ y1vqLYDV/E2HpfS/ASGdf5XMJ1fyUa+WM8MgyLPMy912wv0f2p9Ua/FFm4iC3o9DHObL 6ncxsuDKnYEt3i+uUx1YzJD5Y2QzpbZl0IjYY= 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=b2nE7qIiS+6gxKEBlirTtJrR36SmIXPOF3JmCVu6kGM=; b=WMKbeHmg8JNKNtmccZAIVjx6CNEw7bmkEIoUou1D8gNBrrCUbUjFLlqQTbzuEuYz+7 BRenoQRxyzd5L7AsYGwST0eL5bTjTDWZdiqluXnBnhjeDUwFeBlH3/N3zWDPU/cSWVzg S17zyeGoJc8Wb3WdVvwl6Q7l4cCe/bYN2UCQzx8NLMXaNXIBgBaVdslW9OLr2A5gxzOM Wwd/Cc2u4E2FZBVXDkfgh2QEBBWHsIN12mlxV164auVgHMOYTK3YH2YiWphLTLRmVJcT vQRQF2snNawjkIgdXmSDysgR9PpHQMoPuYuMBkiqHds6SbuBUokjzfM1mid8KGpmlqNL 1mrQ== X-Gm-Message-State: AHQUAuZZxbZECwJB/6kOePHWn+NGF4zrFjTXEXhOj30jdK6uy5RTuPgD beNWT31ipstm4PlkoBaBgUMsg/X1K37T83dmjuKQXA== X-Google-Smtp-Source: AHgI3IYcbNj07Gt2/Dteg7tD6dKOfVWRzUy4aoKp8OW1W7fzdXKQLCaP7OZy241J9MVtWb5uqOeHyu9pxF9veOw/6DI= X-Received: by 2002:a24:7907:: with SMTP id z7mr5044663itc.69.1549566524315; Thu, 07 Feb 2019 11:08:44 -0800 (PST) MIME-Version: 1.0 References: <2b2137ed-8107-f7b6-f0ca-202dcfb87c97@kernel.dk> <40b27e78-9ee8-1395-feb3-a73aac87c9a7@kernel.dk> <20190206005638.GU2217@ZenIV.linux.org.uk> <8f124de2-d6da-d656-25e4-b4d9e58f880e@kernel.dk> <20190207040058.GW2217@ZenIV.linux.org.uk> <20190207092253.GD19821@veci.piliscsaba.redhat.com> <20190207133135.GZ2217@ZenIV.linux.org.uk> <20190207152002.GC2217@ZenIV.linux.org.uk> <20190207162605.GD2217@ZenIV.linux.org.uk> In-Reply-To: <20190207162605.GD2217@ZenIV.linux.org.uk> From: Miklos Szeredi Date: Thu, 7 Feb 2019 20:08:32 +0100 Message-ID: Subject: Re: [PATCH 13/18] io_uring: add file set registration To: Al Viro Cc: Jens Axboe , Jann Horn , linux-aio , linux-block@vger.kernel.org, Linux API , Christoph Hellwig , Jeff Moyer , Avi Kivity , linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Feb 7, 2019 at 5:26 PM Al Viro wrote: > I'm trying to put together some formal description of what's going on in there. > Another question, BTW: updates of user->unix_inflight would seem to be movable > into the callers of unix_{not,}inflight(). Any objections against lifting > it into unix_{attach,detach}_fds()? We do, after all, have fp->count right > there, so what's the point incrementing/decrementing the sucker one-by-one? > _And_ we are checking it right there (in too_many_unix_fds() called from > unix_attach_fds())... I see no issues with that. Also shouldn't the rlimit check be made against user->unix_inflight + fp->count? Althought I'm not quite following if fp->user can end up different from current_user() and what should happen in that case... Thanks, Miklos