From: Jan Kara <jack@suse.cz> To: Dan Williams <dan.j.williams@intel.com>, Dave Jiang <dave.jiang@intel.com> 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/<pid>/smaps Date: Tue, 2 Oct 2018 12:05:31 +0200 Message-ID: <20181002100531.GC4135@quack2.suse.cz> (raw) [-- Attachment #1: Type: text/plain, Size: 951 bytes --] 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/<pid>/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 -- Jan Kara <jack@suse.com> SUSE Labs, CR [-- Attachment #2: 0001-proc-Show-DAX-mappings-as-having-VM_MIXEDMAP-flag.patch --] [-- Type: text/x-patch, Size: 1651 bytes --] >From a3bfac5e1582d9c31e67090b306efedf7c392d36 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack@suse.cz> 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/<pid>/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 <jack@suse.cz> --- 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 <linux/shmem_fs.h> #include <linux/uaccess.h> #include <linux/pkeys.h> +#include <linux/fs.h> #include <asm/elf.h> #include <asm/tlb.h> @@ -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
next reply index Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-02 10:05 Jan Kara [this message] 2018-10-02 10:50 ` Michal Hocko 2018-10-02 13:32 ` Jan Kara 2018-10-02 12:10 ` Johannes Thumshirn 2018-10-02 14:20 ` Johannes Thumshirn 2018-10-02 14:45 ` Christoph Hellwig 2018-10-02 15:01 ` Johannes Thumshirn 2018-10-02 15:06 ` Christoph Hellwig 2018-10-04 10:09 ` Johannes Thumshirn 2018-10-05 6:25 ` Christoph Hellwig 2018-10-05 6:35 ` Johannes Thumshirn 2018-10-06 1:17 ` Dan Williams 2018-10-14 15:47 ` Dan Williams 2018-10-17 20:01 ` Dan Williams 2018-10-18 17:43 ` Jan Kara 2018-10-18 19:10 ` Dan Williams 2018-10-19 3:01 ` Dave Chinner 2018-10-02 14:29 ` Jan Kara 2018-10-02 14:37 ` Christoph Hellwig 2018-10-02 14:44 ` Johannes Thumshirn 2018-10-02 14:52 ` Christoph Hellwig 2018-10-02 15:31 ` Jan Kara 2018-10-02 20:18 ` Dan Williams 2018-10-03 12:50 ` Jan Kara 2018-10-03 14:38 ` Dan Williams 2018-10-03 15:06 ` Jan Kara 2018-10-03 15:13 ` Dan Williams 2018-10-03 16:44 ` Jan Kara 2018-10-03 21:13 ` Dan Williams 2018-10-04 10:04 ` Johannes Thumshirn 2018-10-02 15:07 ` Jan Kara 2018-10-17 20:23 ` Jeff Moyer 2018-10-18 0:25 ` Dave Chinner 2018-10-18 14:55 ` Jan Kara 2018-10-19 0:43 ` Dave Chinner 2018-10-30 6:30 ` Dan Williams 2018-10-30 22:49 ` Dave Chinner 2018-10-30 22:59 ` Dan Williams 2018-10-31 5:59 ` y-goto 2018-11-01 23:00 ` Dave Chinner 2018-11-02 1:43 ` y-goto 2018-10-18 21:05 ` Jeff Moyer 2018-10-09 19:43 ` Jeff Moyer 2018-10-16 8:25 ` Jan Kara 2018-10-16 12:35 ` Jeff Moyer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181002100531.GC4135@quack2.suse.cz \ --to=jack@suse.cz \ --cc=dan.j.williams@intel.com \ --cc=dave.jiang@intel.com \ --cc=jthumshirn@suse.de \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Fsdevel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \ linux-fsdevel@vger.kernel.org public-inbox-index linux-fsdevel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git