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 autolearn=unavailable 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 8C24EC4360F for ; Wed, 27 Feb 2019 20:26:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 599252186A for ; Wed, 27 Feb 2019 20:26:46 +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="gju1gxH8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730254AbfB0U0p (ORCPT ); Wed, 27 Feb 2019 15:26:45 -0500 Received: from mail-it1-f193.google.com ([209.85.166.193]:38583 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727240AbfB0U0p (ORCPT ); Wed, 27 Feb 2019 15:26:45 -0500 Received: by mail-it1-f193.google.com with SMTP id l66so12068831itg.3 for ; Wed, 27 Feb 2019 12:26: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=hohZ/PQkKTKsfJUn+0u4BZTBZg5f/vdpb/h42S/yGV0=; b=gju1gxH8w9Wc/2eqyuTsPNXLPp/QiTv03cV3LHrwdqtTB+QLuBx4C7P1FJrIhQSfod j1h7AwT4N1tHVXZHpX24e3G+feCTfs9pkCB0LfgW4p214lXeL9/HMmgFmGOUn2xOPd4H v8A/E35Rfvwfn5uZ0KhaXZJGUpPQBnwSAbD2U= 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=hohZ/PQkKTKsfJUn+0u4BZTBZg5f/vdpb/h42S/yGV0=; b=pbH6eNayjNkNfTTTCFaoWTBdzHIECYaogwMYfBP+tGcjHIvmcU9IWVnA8DOL0NjAr5 8cNbnGZ4h1EtNMmya7U7WLjEyiI51GKZZGwOCEkKuTaM2tshSAi+8Q7fd1he1fucrvjU r2OMMm7jE+8nO+6a/nmQ1Trv6pzX+MgZxKeaCUeZNpro8laykLJnJxZdKntFuJygltN7 1jSMYwZo9DospvtzP5IZGePVvkTeJMfRLj1Q8w76cJa2JHJkjWSCne2fChHK1hyk8x5X fNHr2b4QfY8VfM6h99xhvd+U2ni//4dRnK0GRMuBGhBaqN5q7JbUHCEfWZrKxQTrGmlF Jprw== X-Gm-Message-State: APjAAAVqxt83w3smNF2xaM6EYCMAyqUG1uxeXQoFR3g/Seo3ROM6N925 G5THdBMnj2YC4D5zkOuvH9I02LrIW3uGh6hc8ZtOuC3/ X-Google-Smtp-Source: APXvYqxUioslqKT+/WO+FkP1uLGEiw7lQOj2BBuuCq5GVFG2KuHVgPJFSmHpizeOV4Y4D62WyP7/OCsuThYI6b+fwbU= X-Received: by 2002:a24:3d0f:: with SMTP id n15mr776162itn.1.1551299204352; Wed, 27 Feb 2019 12:26:44 -0800 (PST) MIME-Version: 1.0 References: <20190219094147.32734-1-kirr@nexedi.com> <20190227200155.GA14682@deco.navytux.spb.ru> In-Reply-To: <20190227200155.GA14682@deco.navytux.spb.ru> From: Miklos Szeredi Date: Wed, 27 Feb 2019 21:26:32 +0100 Message-ID: Subject: Re: [RESEND, PATCH v2] fuse: Don't drop NOTIFY_REPLY if we promised it To: Kirill Smelkov Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org, fuse-devel , Han-Wen Nienhuys , Jakob Unterwurzacher , stable 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 Wed, Feb 27, 2019 at 9:02 PM Kirill Smelkov wrote: > > Miklos, first of all thanks for feedback. > > On Tue, Feb 26, 2019 at 04:14:22PM +0100, Miklos Szeredi wrote: > > On Tue, Feb 19, 2019 at 10:42 AM Kirill Smelkov wrote: > > > > > > A successful call to NOTIFY_RETRIEVE by filesystem carries promise from > > > the kernel to send back NOTIFY_REPLY message. However if the filesystem > > > is not reading requests with fuse_conn->max_pages capacity, > > > > That's a violation of the contract by the fuse server, not the kernel. > > Do you mean that even if filesystem server configures via > init_out.max_write that it is accepting e.g. only 32K max writes, it > still has to be issuing sys_read with buffer of 128K (= hardcoded > fuse_conn->max_pages before Linux 4.20, and default since Linux 4.20)? Filesystem is asking for a specific number of bytes to retrieve. It does not have to be less than max_writes, but it does have to fit into the request buffer it is using. If the filesystem is asking to retrieve 64k and it is using a 32k request buffer, then that obviously won't work. Kernel could limit the retrieve length to max_writes, that may make sense, but it doesn't fundamentally change the fact that if the filesystem is not properly sizing the request buffer, it may result in various forms of breakage. Thanks, Miklos