From patchwork Thu Mar 14 10:45:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kirill Smelkov X-Patchwork-Id: 10852615 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 59C04139A for ; Thu, 14 Mar 2019 11:00:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 41CC22A1FC for ; Thu, 14 Mar 2019 11:00:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 360B92A2C0; Thu, 14 Mar 2019 11:00:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.6 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,URIBL_GREY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 965B32A1FC for ; Thu, 14 Mar 2019 11:00:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727413AbfCNLA6 (ORCPT ); Thu, 14 Mar 2019 07:00:58 -0400 Received: from mail134-29.atl141.mandrillapp.com ([198.2.134.29]:19378 "EHLO mail134-29.atl141.mandrillapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726337AbfCNLA5 (ORCPT ); Thu, 14 Mar 2019 07:00:57 -0400 X-Greylist: delayed 900 seconds by postgrey-1.27 at vger.kernel.org; Thu, 14 Mar 2019 07:00:56 EDT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=mandrill; d=nexedi.com; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; i=kirr@nexedi.com; bh=bsSLS02v9z3I9CX88H2IZaKZTi+CEsxOVwufmyLrCIU=; b=j6KBv90oS7RMnq9ZFGue9t3J7Z4kfippex8AxfMDgUaTJbGZo/wxmjpQK0j1EGMHq+FH1E1zwzU9 SXNjVRowlZlDE5fOIxmVNDJ7Gp3kB+mFmEI2BGtMhSIKQiVz5XZCTpj2R0MWkOp5yd0UWgQ+MY9N DRKKjUbTxvvb5W5gBWU= Received: from pmta03.mandrill.prod.atl01.rsglab.com (127.0.0.1) by mail134-29.atl141.mandrillapp.com id hh8q6g1sau85 for ; Thu, 14 Mar 2019 10:45:55 +0000 (envelope-from ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; i=@mandrillapp.com; q=dns/txt; s=mandrill; t=1552560355; h=From : Subject : To : Cc : Message-Id : In-Reply-To : References : Date : MIME-Version : Content-Type : Content-Transfer-Encoding : From : Subject : Date : X-Mandrill-User : List-Unsubscribe; bh=bsSLS02v9z3I9CX88H2IZaKZTi+CEsxOVwufmyLrCIU=; b=GVfCduQ4ffLUoQyWKVgk10yx7fZyRTBOqsksNYbPJDJoq//eDvsFWZyiWrNcaVoLwMrNIo ldFVgyfmKlcv6cs2HLlIEzl3aOK+keGPF2jgGpQZFCNqsMOXS94PH4IOeAHDr6CRrAizfStF 2E16HpWmPeCKpori8dNvVZ5HuNzAc= From: Kirill Smelkov Subject: [RESEND3, PATCH 0/2] fuse: don't stuck clients on retrieve_notify with size > max_write Received: from [87.98.221.171] by mandrillapp.com id 21324245ddb7437c96ec02782112fbc3; Thu, 14 Mar 2019 10:45:55 +0000 X-Mailer: git-send-email 2.21.0.225.g810b269d1a To: Miklos Szeredi , Miklos Szeredi Cc: , , Kirill Smelkov , Han-Wen Nienhuys , Jakob Unterwurzacher Message-Id: In-Reply-To: <20190307093421.GA4620@deco.navytux.spb.ru> References: <20190307093421.GA4620@deco.navytux.spb.ru> X-Report-Abuse: Please forward a copy of this message, including all headers, to abuse@mandrill.com X-Report-Abuse: You can also report abuse here: http://mandrillapp.com/contact/abuse?id=31050260.21324245ddb7437c96ec02782112fbc3 X-Mandrill-User: md_31050260 Date: Thu, 14 Mar 2019 10:45:55 +0000 MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Miklos, On Thu, Feb 28, 2019 at 02:47:57PM +0300, Kirill Smelkov wrote: > On Thu, Feb 28, 2019 at 09:10:15AM +0100, Miklos Szeredi wrote: > > On Wed, Feb 27, 2019 at 9:39 PM Kirill Smelkov wrote: > > > > > I more or less agree with this statement. However can we please make the > > > breakage to be explicitly visible with an error instead of exhibiting it > > > via harder to debug stucks/deadlocks? For example sys_read < max_write > > > -> error instead of getting stuck. And if notify_retrieve requests > > > buffer larger than max_write -> error or cut to max_write, but don't > > > return OK when we know we will never send what was requested to > > > filesystem even if it uses max_write sized reads. What is the point of > > > breaking in hard to diagnose way when we can make the breakage showing > > > itself explicitly? Would a patch for such behaviour accepted? > > > > Sure, if it's only adds a couple of lines. Adding more than say ten > > lines for such a non-bug fix is definitely excessive. > > Ok, thanks. Please consider applying the following patch. (It's a bit > pity to hear the problem is not considered to be a bug, but anyway). > > I will also send the second patch as another mail, since I could not > made `git am --scissors` to apply several patched extracted from one > mail successfully. [...] On Thu, Mar 07, 2019 at 12:34:21PM +0300, Kirill Smelkov wrote: > Ping. Miklos, is there anything wrong with this patch and its > second counterpart? As we were talking here are those patches. The first one cuts notify_retrieve request to max_write and is one line only. The second one returns error to filesystem server if it is buggy and does sys_read with buffer size < max_write. It is 2 lines of code and 7 lines of comments. I still think that the patches fix real bugs. It is a bug if server behaviour is a bit non-confirming or simply on an edge of being correct or questionable, and instead of properly getting plain error from kernel, the whole system gets stuck. It is a bug because bug amplification factor here is at least one order of magnitude instead of staying ~1x. I'm sending the patches for the third time already, but did not get any feedback. Could you please have a look? Thanks beforehand, Kirill Kirill Smelkov (2): fuse: retrieve: cap requested size to negotiated max_write fuse: require /dev/fuse reads to have enough buffer capacity as negotiated fs/fuse/dev.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)