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.0 required=3.0 tests=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 49B26C43381 for ; Thu, 7 Mar 2019 17:56:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2774520840 for ; Thu, 7 Mar 2019 17:56:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726275AbfCGR4u (ORCPT ); Thu, 7 Mar 2019 12:56:50 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:44469 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726227AbfCGR4u (ORCPT ); Thu, 7 Mar 2019 12:56:50 -0500 Received: by mail-qt1-f196.google.com with SMTP id d2so18099613qti.11 for ; Thu, 07 Mar 2019 09:56:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GlubaI8/tdCsyayarj1cX94BX3ry6cE1EJgMPiinZzY=; b=KLbcURRn8SHsOj2xvKpU8mZps97JktApi0QrgT8C2eChAfqtjaq0SMNIXI4KHrEVAn CK0icRs2xevDkrEB/XMqkRQyBBgS/T1x4OHvtqbNJBfp3hXjFx5hGLoeZ5fsuSI3961h RqhTD+hu+VBs974IX419sEl1iVSTbAe339bqssd4zTYxq9NyHRgNgU07gBataAn3cvlj EmV4qAUuc7umu0VQZeK73SZZCz/6YLb31aBYua422GhJwEe29ouPFmPtirD3yG8slAea XcyZzcyMwccIFY6NYiVibPke6B1fxmwq5araDY/cxTtoTro4rlTYuckJxXYHejEEIJvF l49g== X-Gm-Message-State: APjAAAXYxXb3KZrll2bJf8TTUf4jdEb03xmnNpRzQmzEtsDuCo1zrgXV 91fsl1aHeJYh2Sl1wJVJQY2m+g== X-Google-Smtp-Source: APXvYqxFRpwD4FB6daKlGFu9HAvoSSE10i1RtuQ+4HSg9M3hIccAg7z5LEuuhNtsFaAZIgZcXp6wYQ== X-Received: by 2002:ac8:354c:: with SMTP id z12mr10798499qtb.92.1551981409185; Thu, 07 Mar 2019 09:56:49 -0800 (PST) Received: from redhat.com (pool-173-76-246-42.bstnma.fios.verizon.net. [173.76.246.42]) by smtp.gmail.com with ESMTPSA id t38sm3698415qtc.12.2019.03.07.09.56.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 Mar 2019 09:56:48 -0800 (PST) Date: Thu, 7 Mar 2019 12:56:45 -0500 From: "Michael S. Tsirkin" To: Jason Wang Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, peterx@redhat.com, linux-mm@kvack.org, aarcange@redhat.com, Jerome Glisse Subject: Re: [RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address Message-ID: <20190307124700-mutt-send-email-mst@kernel.org> References: <1551856692-3384-1-git-send-email-jasowang@redhat.com> <1551856692-3384-6-git-send-email-jasowang@redhat.com> <20190307103503-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190307103503-mutt-send-email-mst@kernel.org> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Mar 07, 2019 at 10:47:22AM -0500, Michael S. Tsirkin wrote: > On Wed, Mar 06, 2019 at 02:18:12AM -0500, Jason Wang wrote: > > +static const struct mmu_notifier_ops vhost_mmu_notifier_ops = { > > + .invalidate_range = vhost_invalidate_range, > > +}; > > + > > void vhost_dev_init(struct vhost_dev *dev, > > struct vhost_virtqueue **vqs, int nvqs, int iov_limit) > > { > > I also wonder here: when page is write protected then > it does not look like .invalidate_range is invoked. > > E.g. mm/ksm.c calls > > mmu_notifier_invalidate_range_start and > mmu_notifier_invalidate_range_end but not mmu_notifier_invalidate_range. > > Similarly, rmap in page_mkclean_one will not call > mmu_notifier_invalidate_range. > > If I'm right vhost won't get notified when page is write-protected since you > didn't install start/end notifiers. Note that end notifier can be called > with page locked, so it's not as straight-forward as just adding a call. > Writing into a write-protected page isn't a good idea. > > Note that documentation says: > it is fine to delay the mmu_notifier_invalidate_range > call to mmu_notifier_invalidate_range_end() outside the page table lock. > implying it's called just later. OK I missed the fact that _end actually calls mmu_notifier_invalidate_range internally. So that part is fine but the fact that you are trying to take page lock under VQ mutex and take same mutex within notifier probably means it's broken for ksm and rmap at least since these call invalidate with lock taken. And generally, Andrea told me offline one can not take mutex under the notifier callback. I CC'd Andrea for why. That's a separate issue from set_page_dirty when memory is file backed. It's because of all these issues that I preferred just accessing userspace memory and handling faults. Unfortunately there does not appear to exist an API that whitelists a specific driver along the lines of "I checked this code for speculative info leaks, don't add barriers on data path please". > -- > MST