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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 D7747C10F13 for ; Thu, 11 Apr 2019 16:23:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9E2D82073F for ; Thu, 11 Apr 2019 16:23:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554999799; bh=uRaUuNgJy+ETLKY+TrZW6hwLlPxxWHbreqSGUu3Em/M=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=vmIu6fPjmTILvbYgj+fM3YN68RvB8+HnX/sUC5fWJDDpCSxa2/Knp/WLYfK9jKz7s OkD721LPX5/aHpy1JZfAvDrtNpUyY5GZ9f/bIQwiuWGlRQcngK984AqLax95/+xYvh gqKjQsVKQ1jU/NvKflNfnJokkh8knAx/Nm+78cAQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726794AbfDKQXT (ORCPT ); Thu, 11 Apr 2019 12:23:19 -0400 Received: from mail-lf1-f66.google.com ([209.85.167.66]:45554 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726691AbfDKQXS (ORCPT ); Thu, 11 Apr 2019 12:23:18 -0400 Received: by mail-lf1-f66.google.com with SMTP id t11so675505lfl.12 for ; Thu, 11 Apr 2019 09:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SQG3fAkiUV20bO26Ld6sJCHOpwS1q4hdpfdFqRoHxoM=; b=Z0Q1fOHSPCHOhBg1JKd5iEmmQ0/jsnNt7NEQOMpZAIi6DdydVfjj6QnQaEXX8Gz+7s YA+8bHIkuUumGy6mZX/ZcdzE9pt3vuwrZDx20oUfvX5bVG0wUueotFvbNY6WU+TbLZyz Wi3ZJegqCN6RjJ9Nr2IbBVaSy0zQ/mtMc35l4= 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=SQG3fAkiUV20bO26Ld6sJCHOpwS1q4hdpfdFqRoHxoM=; b=nd2iZjL+kSUkGqavc7PCOGDtpfUrFrC+Vbj6yNDv0BNFEx1eKJ0IfgdhhbImC1a769 zQfqGpUwsXLFVWxgzPx0VCWf1E/LqZ44JkCJ4ZSXw1r6yVwBiITsA/pr/RWIh7OrymsF Eh2SbCXvDTLm5HbRkAwxa6RNNJu8KQD6o4uu1at2sew/fGqNjRNsraVv9Cjkz3TG8PGB WKL/Pv53HXIMqhYoO5DROovWm6ktlM8jnWOCufazKI8Onw7Za9DNGTQGNNOQpiIUXMbT r7EJ09W7kBgrd9Ho0SBoEi1WwOuDo7s7ml7e5FMxtQEsEO7fQwzjM8I6fQnIWq+QYEbU cF2w== X-Gm-Message-State: APjAAAUvQQwZ9QqDe9Iwq4D8Z0VUdLqMErtFobi8SgkQYRJlF4BS+H5r wP78srufes69i7s8dZky16EBCzCUAwE= X-Google-Smtp-Source: APXvYqwHR3RXuei7qTmcETeXRPVaS23L7O8aLzzWDPd16jU5RaHIxScJ98ob97r3Hf5bUG5pjdR/Eg== X-Received: by 2002:ac2:569b:: with SMTP id 27mr28146247lfr.24.1554999794862; Thu, 11 Apr 2019 09:23:14 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id c17sm2927489lfj.58.2019.04.11.09.23.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 09:23:13 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id t11so675355lfl.12 for ; Thu, 11 Apr 2019 09:23:13 -0700 (PDT) X-Received: by 2002:a19:a40b:: with SMTP id q11mr27540073lfc.33.1554999793169; Thu, 11 Apr 2019 09:23:13 -0700 (PDT) MIME-Version: 1.0 References: <4c4651e2-167e-bfcc-7b3e-cda118f98a69@rasmusvillemoes.dk> <20190409203807.GA13855@deco.navytux.spb.ru> <20190411123816.GA18309@deco.navytux.spb.ru> In-Reply-To: <20190411123816.GA18309@deco.navytux.spb.ru> From: Linus Torvalds Date: Thu, 11 Apr 2019 09:22:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock To: Kirill Smelkov Cc: Rasmus Villemoes , Al Viro , Arnd Bergmann , Christoph Hellwig , Greg Kroah-Hartman , linux-fsdevel , Linux List Kernel Mailing 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, Apr 11, 2019 at 5:38 AM Kirill Smelkov wrote: > > However file->f_pos writing is still there and it will bug under race > detector, e.g. under KTSAN because read and write can be running > simultaneously. Maybe it is not only race bug, but also a bit of > slowdown as read and write code paths write to the same memory thus > needing inter-cpu synchronization if read and write handlers are on > different cpus. However for this I'm not sure. I doubt it's noticeable, but it would probably be good to simply not do the write for streams. That *could* be done somewhat similarly, with just changing th address to be updated, or course. In fact, we *used* to (long ago) pass in the address of "file->f_pos" itself to the low-level read/write routines. We then changed it to do that indirection through a local copy of pos (and file_pos_read/file_pos_write) because we didn't do the proper locking, so different read/write versions could mess with each other (and with lseek). But one of the things that commit 9c225f2655e36 ("vfs: atomic f_pos accesses as per POSIX") did was to add the proper locking at least for the cases that we care about deeply, so we *could* say that we have three cases: - FMODE_ATOMIC_POS: properly locked, - FMODE_STREAM: no pos at all - otherwise a "mostly don't care - don't mix!" and so we could go back to not copying the pos at all, and instead do something like loff_t *ppos = f.file->f_mode & FMODE_STREAM ? NULL : &file->f_pos; ret = vfs_write(f.file, buf, count, ppos); and perhaps have a long-term plan to try to get rid of the "don't mix" case entirely (ie "if you use f_pos, then we'll do the proper locking") (The above is obviously surrounded by the fdget_pos()/fdput_pos() that implements the locking decision). Linus