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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 D067FC8300A for ; Thu, 30 Apr 2020 08:58:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 545D020575 for ; Thu, 30 Apr 2020 08:58:56 +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="rR0MeDwL" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726684AbgD3I6z (ORCPT ); Thu, 30 Apr 2020 04:58:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726453AbgD3I6z (ORCPT ); Thu, 30 Apr 2020 04:58:55 -0400 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21BCFC035494 for ; Thu, 30 Apr 2020 01:58:55 -0700 (PDT) Received: by mail-ej1-x643.google.com with SMTP id k8so4058384ejv.3 for ; Thu, 30 Apr 2020 01:58:55 -0700 (PDT) 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=kw+MyCs5dnbWUnTLkNShmUXXjXtDqqnuyJ0rA7GvwNk=; b=rR0MeDwLsqLjJaQdT1+3OxUtjA48WjUu9U89zLWzhaRRkxBJYsDbWWgFlryNlBJuWS RlC15OhCP+UiHqNZ3K5zasmIuk0uZbtd9IbSkW+UN8FMW9o+hs+dsejvZd2B3MKUrYBe BlxJv71jqbQ6BAu+sZrbMcTn/GEPNA3Zfdwzk= 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=kw+MyCs5dnbWUnTLkNShmUXXjXtDqqnuyJ0rA7GvwNk=; b=BHKx2ongPIB5PMasO7g2EiTeWOplwu7Oa0ZnYYCShUUGjnPtmwLCK/yYi+jvyg8D1A j8QzgI+vLiTOni9BjDQ+yXdVf5qsN+LwbBl2b01acNVnyhhymNSMUF1ozK4bldOWbwnx J64xYsrF3fkPxsd7Ztydj0Bsvq7YyQSkTLqGVftK56vXY6Q2aoBG8jnsJQgCOF7KSoZ5 wRPPtzHMRRzjQe1MwvbtvVhAjGUdn3kLjN4c2mZ+qQO3bTfpNbF6w0hA+MUeFjCWdk2d bJf6Puq+6JBNrn3NqgueFy1WgtqZTYxo7VX1wyWIxyNlTidmZmtOZNcD7ud4uV+nipo1 2O1g== X-Gm-Message-State: AGi0PuazJV3i8zZwr0YCOZ7g8JsMcvfCokAjLQ9NOlZRSoF9vMdpLZ0J lCORBBxAITcozoIBdJLhb5raqh61RQ4ZAX9oWmMelQ== X-Google-Smtp-Source: APiQypJv8Ln6ovkcVWMQJ8v0WFDp/TJibJtI/QxfXgSqPpbZ2gOXoeHTVwvyhAaUV+24TjAqtrmn8OFO5OYT3/t1UPk= X-Received: by 2002:a17:906:8549:: with SMTP id h9mr1670848ejy.145.1588237133730; Thu, 30 Apr 2020 01:58:53 -0700 (PDT) MIME-Version: 1.0 References: <20200427180354.GD146096@redhat.com> In-Reply-To: <20200427180354.GD146096@redhat.com> From: Miklos Szeredi Date: Thu, 30 Apr 2020 10:58:42 +0200 Message-ID: Subject: Re: [PATCH] fuse, virtiofs: Do not alloc/install fuse device in fuse_fill_super_common() To: Vivek Goyal Cc: linux-fsdevel@vger.kernel.org, Chirantan Ekbote , virtio-fs-list , Stefan Hajnoczi 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 Mon, Apr 27, 2020 at 8:04 PM Vivek Goyal wrote: > > As of now fuse_fill_super_common() allocates and installs one fuse device. > Filesystems like virtiofs can have more than one filesystem queues and > can have one fuse device per queue. Given, fuse_fill_super_common() only > handles one device, virtiofs allocates and installes fuse devices for > all queues except one. > > This makes logic little twisted and hard to understand. It probably > is better to not do any device allocation/installation in > fuse_fill_super_common() and let caller take care of it instead. I don't have the details about the fuse super block setup in my head, but leaving the fuse_dev_alloc_install() call inside fuse_fill_super_common() and adding new fuse_dev_alloc()/fuse_dev_install() calls looks highly suspicious. Thanks, Miklos