From: Simon Jeons <simon.jeons@gmail.com>
To: Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
riel@redhat.com, mhocko@suse.cz, hannes@cmpxchg.org
Subject: Re: [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2
Date: Fri, 01 Mar 2013 17:21:35 +0800 [thread overview]
Message-ID: <5130731F.4000804@gmail.com> (raw)
In-Reply-To: <20130301091513.GA11787@gchen.bj.intel.com>
On 03/01/2013 05:15 PM, Chen Gong wrote:
> On Fri, Mar 01, 2013 at 02:43:53PM +0800, Simon Jeons wrote:
>> Date: Fri, 01 Mar 2013 14:43:53 +0800
>> From: Simon Jeons <simon.jeons@gmail.com>
>> To: Mel Gorman <mgorman@suse.de>
>> CC: Ingo Molnar <mingo@kernel.org>, Andrew Morton
>> <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org,
>> linux-mm@kvack.org, riel@redhat.com, mhocko@suse.cz, hannes@cmpxchg.org
>> Subject: Re: [PATCH] x86: mm: Check if PUD is large when validating a
>> kernel address v2
>> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221
>> Thunderbird/17.0.3
>>
>> On 02/13/2013 07:02 PM, Mel Gorman wrote:
>>> Andrew or Ingo, please pick up.
>>>
>>> Changelog since v1
>>> o Add reviewed-bys and acked-bys
>>>
>>> A user reported a bug whereby a backup process accessing /proc/kcore
>>> caused an oops.
>>>
>>> BUG: unable to handle kernel paging request at ffffbb00ff33b000
>>> IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
>>> PGD 0
>>> Oops: 0000 [#1] SMP
>>> CPU 6
>>> Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod
>>>
>>> Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614
>>> RIP: 0010:[<ffffffff8103157e>] [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
>>> RSP: 0018:ffff88094165fe80 EFLAGS: 00010246
>>> RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
>>> RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
>>> RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
>>> R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
>>> R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
>>> FS: 00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
>>> Stack:
>>> ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
>>> ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
>>> 0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
>>> Call Trace:
>>> [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
>>> [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
>>> [<ffffffff81151687>] vfs_read+0xc7/0x130
>>> [<ffffffff811517f3>] sys_read+0x53/0xa0
>>> [<ffffffff81449692>] system_call_fastpath+0x16/0x1b
>>>
>>> Investigation determined that the bug triggered when reading system RAM
>>> at the 4G mark. On this system, that was the first address using 1G pages
>> Do you mean there is one page which is 1G?
>>
> 1GB support in native kernel is started from 2.6.27 with these 2 commits:
Why call kernel native? Which kend of kernel is not native?
> 39c11e6 and b4718e6. For Intel CPU, from Westmere it supports 1GB page.
> BTW, IBM System x3550 M3 is a Westmere based system.
Is it only used in hugetlbfs page?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Jeons <simon.jeons@gmail.com>
To: Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
riel@redhat.com, mhocko@suse.cz, hannes@cmpxchg.org
Subject: Re: [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2
Date: Fri, 01 Mar 2013 17:21:35 +0800 [thread overview]
Message-ID: <5130731F.4000804@gmail.com> (raw)
In-Reply-To: <20130301091513.GA11787@gchen.bj.intel.com>
On 03/01/2013 05:15 PM, Chen Gong wrote:
> On Fri, Mar 01, 2013 at 02:43:53PM +0800, Simon Jeons wrote:
>> Date: Fri, 01 Mar 2013 14:43:53 +0800
>> From: Simon Jeons <simon.jeons@gmail.com>
>> To: Mel Gorman <mgorman@suse.de>
>> CC: Ingo Molnar <mingo@kernel.org>, Andrew Morton
>> <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org,
>> linux-mm@kvack.org, riel@redhat.com, mhocko@suse.cz, hannes@cmpxchg.org
>> Subject: Re: [PATCH] x86: mm: Check if PUD is large when validating a
>> kernel address v2
>> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221
>> Thunderbird/17.0.3
>>
>> On 02/13/2013 07:02 PM, Mel Gorman wrote:
>>> Andrew or Ingo, please pick up.
>>>
>>> Changelog since v1
>>> o Add reviewed-bys and acked-bys
>>>
>>> A user reported a bug whereby a backup process accessing /proc/kcore
>>> caused an oops.
>>>
>>> BUG: unable to handle kernel paging request at ffffbb00ff33b000
>>> IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
>>> PGD 0
>>> Oops: 0000 [#1] SMP
>>> CPU 6
>>> Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod
>>>
>>> Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614
>>> RIP: 0010:[<ffffffff8103157e>] [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
>>> RSP: 0018:ffff88094165fe80 EFLAGS: 00010246
>>> RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
>>> RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
>>> RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
>>> R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
>>> R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
>>> FS: 00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
>>> Stack:
>>> ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
>>> ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
>>> 0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
>>> Call Trace:
>>> [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
>>> [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
>>> [<ffffffff81151687>] vfs_read+0xc7/0x130
>>> [<ffffffff811517f3>] sys_read+0x53/0xa0
>>> [<ffffffff81449692>] system_call_fastpath+0x16/0x1b
>>>
>>> Investigation determined that the bug triggered when reading system RAM
>>> at the 4G mark. On this system, that was the first address using 1G pages
>> Do you mean there is one page which is 1G?
>>
> 1GB support in native kernel is started from 2.6.27 with these 2 commits:
Why call kernel native? Which kend of kernel is not native?
> 39c11e6 and b4718e6. For Intel CPU, from Westmere it supports 1GB page.
> BTW, IBM System x3550 M3 is a Westmere based system.
Is it only used in hugetlbfs page?
next prev parent reply other threads:[~2013-03-01 9:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-11 14:52 [PATCH] x86: mm: Check if PUD is large when validating a kernel address Mel Gorman
2013-02-11 14:52 ` Mel Gorman
2013-02-11 19:41 ` Rik van Riel
2013-02-11 19:41 ` Rik van Riel
2013-02-12 6:40 ` Johannes Weiner
2013-02-12 6:40 ` Johannes Weiner
2013-02-12 17:43 ` Michal Hocko
2013-02-12 17:43 ` Michal Hocko
2013-02-13 11:02 ` [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2 Mel Gorman
2013-02-13 11:02 ` Mel Gorman
2013-02-13 11:10 ` Ingo Molnar
2013-02-13 11:10 ` Ingo Molnar
2013-02-13 11:14 ` Mel Gorman
2013-02-13 11:14 ` Mel Gorman
2013-03-01 6:43 ` Simon Jeons
2013-03-01 6:43 ` Simon Jeons
2013-03-01 9:15 ` Chen Gong
2013-03-01 9:21 ` Simon Jeons [this message]
2013-03-01 9:21 ` Simon Jeons
2013-03-01 9:35 ` Chen Gong
2013-03-01 9:39 ` Simon Jeons
2013-03-01 9:39 ` Simon Jeons
2013-02-13 12:12 ` [tip:x86/urgent] x86/mm: Check if PUD is large when validating a kernel address tip-bot for Mel Gorman
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=5130731F.4000804@gmail.com \
--to=simon.jeons@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=mingo@kernel.org \
--cc=riel@redhat.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.