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: 10623327 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 473AC17E0 for ; Tue, 2 Oct 2018 10:05:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 43B08287DC for ; Tue, 2 Oct 2018 10:05:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3785B287EA; Tue, 2 Oct 2018 10:05:35 +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=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C261D287E6 for ; Tue, 2 Oct 2018 10:05:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726866AbeJBQsC (ORCPT ); Tue, 2 Oct 2018 12:48:02 -0400 Received: from mx2.suse.de ([195.135.220.15]:38184 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726178AbeJBQsC (ORCPT ); Tue, 2 Oct 2018 12:48:02 -0400 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 Cc: linux-nvdimm@lists.01.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, jthumshirn@suse.de 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) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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