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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 5A038C433E1 for ; Fri, 29 May 2020 07:03:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 19C912074D for ; Fri, 29 May 2020 07:03:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 19C912074D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7F9E48001A; Fri, 29 May 2020 03:03:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AA9180010; Fri, 29 May 2020 03:03:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 698FF8001A; Fri, 29 May 2020 03:03:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id 4E4FE80010 for ; Fri, 29 May 2020 03:03:47 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 130888248076 for ; Fri, 29 May 2020 07:03:47 +0000 (UTC) X-FDA: 76868866494.23.noise81_78477ee3db509 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id E28E637617 for ; Fri, 29 May 2020 07:03:46 +0000 (UTC) X-HE-Tag: noise81_78477ee3db509 X-Filterd-Recvd-Size: 3494 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Fri, 29 May 2020 07:03:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2323EB001; Fri, 29 May 2020 07:03:44 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 796C61E1289; Fri, 29 May 2020 09:03:43 +0200 (CEST) Date: Fri, 29 May 2020 09:03:43 +0200 From: Jan Kara To: John Hubbard Cc: Jan Kara , Linux-MM , linux-fsdevel@vger.kernel.org, Alex Williamson Subject: Re: Question: "Bare" set_page_dirty_lock() call in vhost.c Message-ID: <20200529070343.GL14550@quack2.suse.cz> References: <3b2db4da-9e4e-05d1-bf89-a261f0eb6de0@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b2db4da-9e4e-05d1-bf89-a261f0eb6de0@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: E28E637617 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi! On Thu 28-05-20 17:59:30, John Hubbard wrote: > While trying to figure out which things to convert from > get_user_pages*() to put_user_pages*(), I came across an interesting use > of set_page_dirty_lock(), and wanted to ask about it. > > Is it safe to call set_page_dirty_lock() like this (for the case > when this is file-backed memory): > > // drivers/vhost/vhost.c:1757: > static int set_bit_to_user(int nr, void __user *addr) > { > unsigned long log = (unsigned long)addr; > struct page *page; > void *base; > int bit = nr + (log % PAGE_SIZE) * 8; > int r; > > r = get_user_pages_fast(log, 1, FOLL_WRITE, &page); > if (r < 0) > return r; > BUG_ON(r != 1); > base = kmap_atomic(page); > set_bit(bit, base); > kunmap_atomic(base); > set_page_dirty_lock(page); > put_page(page); > return 0; > } > > ? > > That is, after the page is unmapped, but before unpinning it? > Specifically, I'd expect that the writeback and reclaim code code can end > up calling drop_buffers() (because the set_bit() call actually did > dirty the pte), after the kunmap_atomic() call. So then when > set_page_dirty_lock() runs, it could bug check on ext4_writepage()'s > attempt to buffer heads: > > ext4_writepage() > page_bufs = page_buffers(page); > #define page_buffers(page) \ > ({ \ > BUG_ON(!PagePrivate(page)); \ > ((struct buffer_head *)page_private(page)); \ > }) > > ...which actually is the the case that pin_user_pages*() is ultimately > helping to avoid, btw. But in this case, it's all code that runs on a > CPU, so no DMA or DIO is involved. But still, the "bare" use of > set_page_dirty_lock() seems like a problem here. I agree that the site like above needs pin_user_pages(). The problem has actually nothing to do with kmap_atomic() - that actually doesn't do anything interesting on x86_64. The moment GUP_fast() returns, page can be unmapped from page tables and written back so this site has exactly same problems as any other using DMA or DIO. As we discussed earlier when designing the patch set, the problem is really with GUP reference being used to access page data. And the method of access (DMA, CPU access, GPU access, ...) doesn't really matter... Honza -- Jan Kara SUSE Labs, CR