From patchwork Thu Dec 14 10:55:27 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Yan, Zheng" X-Patchwork-Id: 10111827 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4DD5C60327 for ; Thu, 14 Dec 2017 10:55:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4238229C0D for ; Thu, 14 Dec 2017 10:55:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 36B4A29C13; Thu, 14 Dec 2017 10:55:56 +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=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable 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 DDFCB29C0D for ; Thu, 14 Dec 2017 10:55:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751909AbdLNKzh (ORCPT ); Thu, 14 Dec 2017 05:55:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45510 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751587AbdLNKzf (ORCPT ); Thu, 14 Dec 2017 05:55:35 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0EFD6C057FA4; Thu, 14 Dec 2017 10:55:35 +0000 (UTC) Received: from ovpn-12-55.pek2.redhat.com (ovpn-12-55.pek2.redhat.com [10.72.12.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id F17C66F971; Thu, 14 Dec 2017 10:55:29 +0000 (UTC) From: "Yan, Zheng" To: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, ceph-devel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: viro@zeniv.linux.org.uk, jlayton@redhat.com, "Yan, Zheng" , stable@vger.kernel.org Subject: [PATCH] mm: save/restore current->journal_info in handle_mm_fault Date: Thu, 14 Dec 2017 18:55:27 +0800 Message-Id: <20171214105527.5885-1-zyan@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 14 Dec 2017 10:55:35 +0000 (UTC) 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 We recently got an Oops report: BUG: unable to handle kernel NULL pointer dereference at (null) IP: jbd2__journal_start+0x38/0x1a2 [...] Call Trace: ext4_page_mkwrite+0x307/0x52b _ext4_get_block+0xd8/0xd8 do_page_mkwrite+0x6e/0xd8 handle_mm_fault+0x686/0xf9b mntput_no_expire+0x1f/0x21e __do_page_fault+0x21d/0x465 dput+0x4a/0x2f7 page_fault+0x22/0x30 copy_user_generic_string+0x2c/0x40 copy_page_to_iter+0x8c/0x2b8 generic_file_read_iter+0x26e/0x845 timerqueue_del+0x31/0x90 ceph_read_iter+0x697/0xa33 [ceph] hrtimer_cancel+0x23/0x41 futex_wait+0x1c8/0x24d get_futex_key+0x32c/0x39a __vfs_read+0xe0/0x130 vfs_read.part.1+0x6c/0x123 handle_mm_fault+0x831/0xf9b __fget+0x7e/0xbf SyS_read+0x4d/0xb5 ceph_read_iter() uses current->journal_info to pass context info to ceph_readpages(). Because ceph_readpages() needs to know if its caller has already gotten capability of using page cache (distinguish read from readahead/fadvise). ceph_read_iter() set current->journal_info, then calls generic_file_read_iter(). In above Oops, page fault happened when copying data to userspace. Page fault handler called ext4_page_mkwrite(). Ext4 code read current->journal_info and assumed it is journal handle. I checked other filesystems, btrfs probably suffers similar problem for its readpage. (page fault happens when write() copies data from userspace memory and the memory is mapped to a file in btrfs. verify_parent_transid() can be called during readpage) Cc: stable@vger.kernel.org Signed-off-by: "Yan, Zheng" --- mm/memory.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/mm/memory.c b/mm/memory.c index a728bed16c20..db2a50233c49 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -4044,6 +4044,7 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address, unsigned int flags) { int ret; + void *old_journal_info; __set_current_state(TASK_RUNNING); @@ -4065,11 +4066,24 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address, if (flags & FAULT_FLAG_USER) mem_cgroup_oom_enable(); + /* + * Fault can happen when filesystem A's read_iter()/write_iter() + * copies data to/from userspace. Filesystem A may have set + * current->journal_info. If the userspace memory is MAP_SHARED + * mapped to a file in filesystem B, we later may call filesystem + * B's vm operation. Filesystem B may also want to read/set + * current->journal_info. + */ + old_journal_info = current->journal_info; + current->journal_info = NULL; + if (unlikely(is_vm_hugetlb_page(vma))) ret = hugetlb_fault(vma->vm_mm, vma, address, flags); else ret = __handle_mm_fault(vma, address, flags); + current->journal_info = old_journal_info; + if (flags & FAULT_FLAG_USER) { mem_cgroup_oom_disable(); /*