Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3862569pxv; Mon, 26 Jul 2021 14:14:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRVOeXZ7yQ1RrYbm5QlgZBNsCE/9TyVZ7kbTa4sVatkexTVP5UiXgv8/sJ8p6D9iQFZa5r X-Received: by 2002:a05:6e02:66e:: with SMTP id l14mr14219957ilt.211.1627334081367; Mon, 26 Jul 2021 14:14:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627334081; cv=none; d=google.com; s=arc-20160816; b=VTnEfkPl0/JMm5uqbhi7rscCZ1C3PduGYaw/3V7XyEdQioG+pMgwUxltMQQQy4bQOx 9BpyP4dQKR46eMk4lUZybUzLfKJ5I4oWLDNYMiSPMvtMDed1PdB8AqYYPFjcmydtbA6L u24wNjkXVpsi6o0ee+bKQuK5DRU3TmQ8wfGQWESj+OI+KtYOmUQN8Jn2omxg6h8oIgCZ dHpNvlmrHMzaVIWYKb3YjMtTbrU6+L63OoijVMiYbId9QhGsFXRhUBRfCZbKNBBMD8rF BAQ2s+eBHQYad+gmjsIsK2sxeAvEpVZOit+i+nOwElkvABWr/70AVe91Sose5INZCF1h leyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=gzMiAu+6hqv58f59FOXN+E6RyEGYjVzhigo/P1uv5vc=; b=VmlJTItUE9SMo2B1BMpqCbX0PpOz5WkagfxGD9jVNTfQMIXRcTvmstwydW+W5CCTJD 1ha7r1wsVgtyM7xa0jGug4n1yEwesH/dgMzhMJQU4l0Getr9n2tmCP8Y5r43M9HE9tan 7zu+W8nZCpLiAlCE+pS0MKikJeqQ7aaVO8VSDgK1xf7gdoDja32ekv5op1tSv6xFMqxe 81BHJKzS0iGDgVI9cRy9TbLZLV1N6hYmpUbWv0Qh7LLB0FR5swbJlNhw66mBOn4TR761 /TFylttXv3pVFgQ/g4TjCpLBAzUBqT6zpnJUAfMT0hZOiyZDAYkQ3LIC0FpH7uOmVDNq Yl/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tbk2vF7Y; 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 u26si1040424jam.87.2021.07.26.14.14.29; Mon, 26 Jul 2021 14:14:41 -0700 (PDT) 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=tbk2vF7Y; 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 S233125AbhGZUcj (ORCPT + 99 others); Mon, 26 Jul 2021 16:32:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232922AbhGZUcj (ORCPT ); Mon, 26 Jul 2021 16:32:39 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34A46C061757 for ; Mon, 26 Jul 2021 14:13:06 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id n2so12430425eda.10 for ; Mon, 26 Jul 2021 14:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gzMiAu+6hqv58f59FOXN+E6RyEGYjVzhigo/P1uv5vc=; b=tbk2vF7YuP+kV18pZr4EGMkFVR8482zaix0jguLF+CRuSpcHpLAYU7/xcezT1SqoNp 2EBi3qZdwi4994IVcpOAtly3DyMxkAFZIyqHg1IY7+xWhaWy6haBYP9OZMtduzcLYToe Jf8VTgxwTSLXWriaZMpDj+UpmlqbrPzDWAUdYJpukxLYgxYsBcbfvnfeIGrOQtUjiH8U FHKIUxubEBvLyd7a1+SVZ8zmHPld3amIbFnB1CwPffxTrUcbP0A3WAfHT0BDgrpXzqnR kthHwCZIp3utz8r2IgefQdDiQ72zXbUr8yLdj7DBOw8KPndH5jJK3U3HIsWz7RIxCC4a wLOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gzMiAu+6hqv58f59FOXN+E6RyEGYjVzhigo/P1uv5vc=; b=EHw2Mv8hJub51U8dwfMjnBBk8Q16zjCC2D4TE+6AdZufT2GaVtFciJeFIhdiP4vmkN 2Wq9iv9uX+T9VDIlevtJfyR2EB+oOiO3YOyXyGrsyyAKEfq81e2Gw6vj87ILiREzI3jf tRSVVD4Iq7SD9wMgQX+68CWbaGtOrh8+sGnrDOPzxBT11C7EbLwbLvNq/uE+JNpg4iq6 sRAJqhiMZVgE31GSnNNj7GwYHsT5Y2cUhd2qFEG18j/yhOZhi2PcHe+28LwrZp6zL6Ar eCFnGywvK2rixCc2gE6MSck3q1zwxGf6IkNpfqrVRZ2OvCZjcpw4wOGrMv1NNtS9Z5KP Guyw== X-Gm-Message-State: AOAM5329CthVRXPGQ/IzH9IluaTPR39chx+zw/VPs65dCvBnqfQyaL4T vY4aUhQd5drC6PAArKjdGDY= X-Received: by 2002:aa7:d146:: with SMTP id r6mr10501399edo.264.1627333984763; Mon, 26 Jul 2021 14:13:04 -0700 (PDT) Received: from [192.168.178.40] (ipbcc187b7.dynamic.kabel-deutschland.de. [188.193.135.183]) by smtp.gmail.com with ESMTPSA id t4sm231812ejo.125.2021.07.26.14.13.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jul 2021 14:13:04 -0700 (PDT) Subject: Re: [PATCH 2/4] configfs: Fix writing at a non-zero offset To: Bart Van Assche , Christoph Hellwig Cc: Joel Becker , linux-kernel@vger.kernel.org, "Martin K . Petersen" , Yanko Kaneti , Brendan Higgins References: <20210723212353.896343-1-bvanassche@acm.org> <20210723212353.896343-3-bvanassche@acm.org> <7bee65ce-f5f1-a525-c72d-221b5d23cf3e@gmail.com> From: Bodo Stroesser Message-ID: <4055ca70-7669-d00d-7c08-86fe75a3d377@gmail.com> Date: Mon, 26 Jul 2021 23:13:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26.07.21 18:26, Bart Van Assche wrote: > On 7/26/21 7:58 AM, Bodo Stroesser wrote: >> On 23.07.21 23:23, Bart Van Assche wrote: >> Let's say user writes 5 times to configfs file while keeping it open. >> On every write() call it writes 1 character only, e.g. first "A", then >> "B", ... >> >> The original code before the changes 5 times called flush_write_buffer >> for the >> strings "A\0", "B\0", ... (with the '\0' not included in the count >> parameter, >> so count is 1 always, which is the length of the last write). > > Isn't that behavior a severe violation of how POSIX specifies that the > write() system call should be implemented? Hmm. I'm not sure which detail should violate POSIX spec? Is there any definition how data should be flushed from buffer internally? (I'm by far not a POSIX expert!) I would rather say the new behavior, to call flush_write_buffer during the first write() for the data of that write, and then on the second write to call flush_write_buffer for the concatenated data of the first and the second write, could be a violation of POSIX, because the one times written data of the first write is flushed twice. I don't like the idea of breaking the "one write, one flush" principle that was implemented before. The old comment: "There is no easy way for us to know if userspace is only doing a partial write, so we don't support them. We expect the entire buffer to come on the first write." as I interpret it, makes clear that configfs code has to work according to that principle. (Or even block all but the first write, but that would even more break compatibility to old implementation.) Thank you, Bodo