From patchwork Tue Oct 2 10:05:31 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kara X-Patchwork-Id: 10623329 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id AEC6017E0 for ; Tue, 2 Oct 2018 10:05:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9D3EF287DC for ; Tue, 2 Oct 2018 10:05:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 91776287E8; Tue, 2 Oct 2018 10:05:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 3C4B4287DC for ; Tue, 2 Oct 2018 10:05:36 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id B232C21161694; Tue, 2 Oct 2018 03:05:35 -0700 (PDT) X-Original-To: linux-nvdimm@lists.01.org Delivered-To: linux-nvdimm@lists.01.org Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=195.135.220.15; helo=mx1.suse.de; envelope-from=jack@suse.cz; receiver=linux-nvdimm@lists.01.org Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 09EF521160A3A for ; Tue, 2 Oct 2018 03:05:33 -0700 (PDT) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E952FAEDC; Tue, 2 Oct 2018 10:05:31 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 8522E1E0629; Tue, 2 Oct 2018 12:05:31 +0200 (CEST) Date: Tue, 2 Oct 2018 12:05:31 +0200 From: Jan Kara To: Dan Williams , Dave Jiang Subject: Problems with VM_MIXEDMAP removal from /proc//smaps Message-ID: <20181002100531.GC4135@quack2.suse.cz> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linux-nvdimm@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Linux-nvdimm developer list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" X-Virus-Scanned: ClamAV using ClamSMTP Hello, commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the mean time certain customer of ours started poking into /proc//smaps and looks at VMA flags there and if VM_MIXEDMAP is missing among the VMA flags, the application just fails to start complaining that DAX support is missing in the kernel. The question now is how do we go about this? Strictly speaking, this is a userspace visible regression (as much as I think that application poking into VMA flags at this level is just too bold). Is there any precedens in handling similar issues with smaps which really exposes a lot of information that is dependent on kernel implementation details? I have attached a patch that is an obvious "fix" for the issue - just fake VM_MIXEDMAP flag in smaps. But I'm open to other suggestions... Honza From a3bfac5e1582d9c31e67090b306efedf7c392d36 Mon Sep 17 00:00:00 2001 From: Jan Kara Date: Tue, 2 Oct 2018 11:58:22 +0200 Subject: [PATCH] proc: Show DAX mappings as having VM_MIXEDMAP flag Until commit e1fb4a08649 "dax: remove VM_MIXEDMAP for fsdax and device dax", userspace could distinguish DAX and non-DAX mappings in /proc//smaps by checking whether the VMA has VM_MIXEDMAP (mm in smaps) flag. And indeed some applications started doing this. Maintain backwards compatibility by faking VM_MIXEDMAP flag in smaps for DAX mappings. Fixes: e1fb4a0864958fac2fb1b23f9f4562a9f90e3e8f Signed-off-by: Jan Kara --- fs/proc/task_mmu.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 5ea1d64cb0b4..9cd8e84610a7 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -654,12 +655,18 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) #endif /* CONFIG_ARCH_HAS_PKEYS */ }; size_t i; + unsigned long flags = vma->vm_flags; + /* + * We fake VM_MIXEDMAP for DAX mappings here as some apps depend on it. + */ + if (vma_is_dax(vma)) + flags |= VM_MIXEDMAP; seq_puts(m, "VmFlags: "); for (i = 0; i < BITS_PER_LONG; i++) { if (!mnemonics[i][0]) continue; - if (vma->vm_flags & (1UL << i)) { + if (flags & (1UL << i)) { seq_putc(m, mnemonics[i][0]); seq_putc(m, mnemonics[i][1]); seq_putc(m, ' '); -- 2.16.4