search for: bad_page

...e at free_hot_cold_page (in process 'star', page 00000102382b1ec8) Mar 22 22:02:59 lh10 kernel: flags:0x0100000c mapping:00000102146a4240 mapcount:2 count:0 Mar 22 22:02:59 lh10 kernel: Backtrace: Mar 22 22:02:59 lh10 kernel: Mar 22 22:02:59 lh10 kernel: Call Trace:<ffffffff8015f0cf>{bad_page+112} <ffffffff8015f7b1>{free_hot_cold_page+130} Mar 22 22:02:59 lh10 kernel: <ffffffffa00d17b8>{:st:sgl_unmap_user_pages+67} <ffffffffa00d17df>{:st:release_buffering+27} Mar 22 22:02:59 lh10 kernel: <ffffffffa00d6196>{:st:st_write+2692} <ffffffff80194b39&g...

...e() in mm/page_alloc.c should prevent reallocation of PageHWPoison. > > As you pointed out, memory error handler doens't remove it from buddy freelists. > > Oh, I see. It's using __PG_HWPOISON wrapper, so I didn't notice it when > searching. In any case that results in a bad_page() warning, right? Is > it desirable for a soft-offlined page? That's right, and the bad_page warning might be too strong for soft offlining. We can't tell which of memory_failure/soft_offline_page a PageHWPoison came from, but users can find other lines in dmesg which should tell that....

...e() in mm/page_alloc.c should prevent reallocation of PageHWPoison. > > As you pointed out, memory error handler doens't remove it from buddy freelists. > > Oh, I see. It's using __PG_HWPOISON wrapper, so I didn't notice it when > searching. In any case that results in a bad_page() warning, right? Is > it desirable for a soft-offlined page? That's right, and the bad_page warning might be too strong for soft offlining. We can't tell which of memory_failure/soft_offline_page a PageHWPoison came from, but users can find other lines in dmesg which should tell that....

...t up, but a reboot is needed == And the instance was no longer running. Fortunately, it was able to log the oops to kern.log(following): == Bad page state at prep_new_page (in process ''postmaster'', page c1326ca0) flags:0x00000068 mapping:cd26914c mapcount:0 count:2 Backtrace: [bad_page+112/176] bad_page+0x70/0xb0 [prep_new_page+60/96] prep_new_page+0x3c/0x60 [buffered_rmqueue+250/544] buffered_rmqueue+0xfa/0x220 [__set_page_dirty_nobuffers+170/272] __set_page_dirty_nobuffers+0xaa/0x110 [__alloc_pages+913/960] __alloc_pages+0x391/0x3c0 [generic_file_buffered_write+310/1520] g...

...hat: [154590.284201] BUG: Bad page state in process smbd pfn:15a54 [154590.284225] page:c1786a80 flags:40000000 count:0 mapcount:-8 mapping:(null) index:9682 [154590.284251] Pid: 638, comm: smbd Tainted: G B 2.6.32-5-686 #1 [154590.284254] Call Trace: [154590.284269] [<c108a666>] ? bad_page+0xd7/0xeb [154590.284276] [<c108b94c>] ? get_page_from_freelist+0x2e7/0x3c7 [154590.284291] [<c10ac6e1>] ? add_partial+0xe/0x40 [154590.284297] [<c11d2317>] ? __kfree_skb+0xf/0x6e [154590.284302] [<c108bced>] ? __alloc_pages_nodemask+0xf3/0x4d9 [154590.284308] [<c126...

...h another error: Jul 2 16:40:40 lvs2 kernel: Bad page state at free_hot_cold_page (in process 'smtp', page c10a2140) Jul 2 16:40:40 lvs2 kernel: flags:0x20000014 mapping:00000000 mapcount:256 count:0 Jul 2 16:40:40 lvs2 kernel: Backtrace: Jul 2 16:40:40 lvs2 kernel: [<c014eaad>] bad_page+0x58/0x89 Jul 2 16:40:40 lvs2 kernel: [<c014f2e1>] free_hot_cold_page+0x5f/0xc8 Jul 2 16:40:40 lvs2 kernel: [<c0159b6a>] zap_pte_range+0x1d9/0x226 Jul 2 16:40:40 lvs2 kernel: [<c0159bf9>] zap_pmd_range+0x42/0x68 Jul 2 16:40:40 lvs2 kernel: [<c0159c58>] unmap_page_ran...

...4076e00 > kernel: ffffffff81e658a0 ffff8801124c7420 ffffffff811e9b63 0000000000000000 > kernel: ffffea0004076e00 ffffffff81e658a0 ffff8801124c7440 ffffffff811e9ca9 > kernel: Call Trace: > kernel: [<ffffffff814d69b0>] dump_stack+0x68/0x92 > kernel: [<ffffffff811e9b63>] bad_page+0x158/0x1a2 > kernel: [<ffffffff811e9ca9>] free_pages_check_bad+0xfc/0x101 > kernel: [<ffffffff811ee516>] free_hot_cold_page+0x135/0x5de > kernel: [<ffffffff811eea26>] __free_pages+0x67/0x72 > kernel: [<ffffffff81227c63>] release_freepages+0x13a/0x191 > ke...

...4076e00 > kernel: ffffffff81e658a0 ffff8801124c7420 ffffffff811e9b63 0000000000000000 > kernel: ffffea0004076e00 ffffffff81e658a0 ffff8801124c7440 ffffffff811e9ca9 > kernel: Call Trace: > kernel: [<ffffffff814d69b0>] dump_stack+0x68/0x92 > kernel: [<ffffffff811e9b63>] bad_page+0x158/0x1a2 > kernel: [<ffffffff811e9ca9>] free_pages_check_bad+0xfc/0x101 > kernel: [<ffffffff811ee516>] free_hot_cold_page+0x135/0x5de > kernel: [<ffffffff811eea26>] __free_pages+0x67/0x72 > kernel: [<ffffffff81227c63>] release_freepages+0x13a/0x191 > ke...

On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: ... > >>> > >>> Also (but not your fault) the put_page() preceding > >>> test_set_page_hwpoison(page)) IMHO deserves a comment saying which > >>> pin we are

On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: ... > >>> > >>> Also (but not your fault) the put_page() preceding > >>> test_set_page_hwpoison(page)) IMHO deserves a comment saying which > >>> pin we are

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > > > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > > > [

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > > > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > > > [

...0000000000 Jun 20 16:31:13 metamora kernel: 000fffff00000000 ffff883d6a677cc0 ffffffff811711ad fff00000fe000000 Jun 20 16:31:13 metamora kernel: Call Trace: Jun 20 16:31:13 metamora kernel: [<ffffffff8163571c>] dump_stack+0x19/0x1b Jun 20 16:31:13 metamora kernel: [<ffffffff81630935>] bad_page.part.59+0xdf/0xfc Jun 20 16:31:13 metamora kernel: [<ffffffff811711ad>] free_pages_prepare+0x16d/0x190 Jun 20 16:31:13 metamora kernel: [<ffffffff81171589>] free_compound_page+0x29/0x40 Jun 20 16:31:13 metamora kernel: [<ffffffff81176ddf>] __put_compound_page+0x1f/0x30 Jun 20 1...

...ffffffff81e658a0 ffff8801124c7420 ffffffff811e9b63 0000000000000000 > > kernel: ffffea0004076e00 ffffffff81e658a0 ffff8801124c7440 ffffffff811e9ca9 > > kernel: Call Trace: > > kernel: [<ffffffff814d69b0>] dump_stack+0x68/0x92 > > kernel: [<ffffffff811e9b63>] bad_page+0x158/0x1a2 > > kernel: [<ffffffff811e9ca9>] free_pages_check_bad+0xfc/0x101 > > kernel: [<ffffffff811ee516>] free_hot_cold_page+0x135/0x5de > > kernel: [<ffffffff811eea26>] __free_pages+0x67/0x72 > > kernel: [<ffffffff81227c63>] release_freepages...

...fffffff814d69b0 ffffea0004076e00 kernel: ffffffff81e658a0 ffff8801124c7420 ffffffff811e9b63 0000000000000000 kernel: ffffea0004076e00 ffffffff81e658a0 ffff8801124c7440 ffffffff811e9ca9 kernel: Call Trace: kernel: [<ffffffff814d69b0>] dump_stack+0x68/0x92 kernel: [<ffffffff811e9b63>] bad_page+0x158/0x1a2 kernel: [<ffffffff811e9ca9>] free_pages_check_bad+0xfc/0x101 kernel: [<ffffffff811ee516>] free_hot_cold_page+0x135/0x5de kernel: [<ffffffff811eea26>] __free_pages+0x67/0x72 kernel: [<ffffffff81227c63>] release_freepages+0x13a/0x191 kernel: [<ffffffff8122b...

These mappings are in fact special and require special handling in privcmd, which already exists. Failure to mark the PTE as special on arm64 causes all sorts of bad PTE fun. x86 already gets this correct. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: xen-devel@lists.xenproject.org --- arch/arm/xen/enlighten.c |

...> check_new_page() in mm/page_alloc.c should prevent reallocation of PageHWPoison. > As you pointed out, memory error handler doens't remove it from buddy freelists. Oh, I see. It's using __PG_HWPOISON wrapper, so I didn't notice it when searching. In any case that results in a bad_page() warning, right? Is it desirable for a soft-offlined page? If we didn't free poisoned pages to buddy system, they wouldn't trigger this warning. > BTW, it might be a bit off-topic, but recently I felt that check_new_page() > might be improvable, because when check_new_page() returns...

...c ata_piix megaraid_sas [ 643.146109] Pid: 5651, comm: sshd Tainted: G D 3.7.9-27-xen #1 [ 643.146114] Call Trace: [ 643.146129] [<ffffffff80008ad5>] dump_trace+0x85/0x1c0 [ 643.146138] [<ffffffff804f8949>] dump_stack+0x69/0x6f [ 643.146146] [<ffffffff804fac88>] bad_page+0xe7/0xfb [ 643.146155] [<ffffffff800edf4a>] get_page_from_freelist+0x63a/0x750 [ 643.146164] [<ffffffff800ee1da>] __alloc_pages_nodemask+0x17a/0x950 [ 643.146172] [<ffffffff8010e17b>] handle_pte_fault+0x41b/0x7d0 [ 643.146182] [<ffffffff80506ece>] __do_page_fault+0x...

...fff8801124c7420 ffffffff811e9b63 0000000000000000 > > > kernel: ffffea0004076e00 ffffffff81e658a0 ffff8801124c7440 ffffffff811e9ca9 > > > kernel: Call Trace: > > > kernel: [<ffffffff814d69b0>] dump_stack+0x68/0x92 > > > kernel: [<ffffffff811e9b63>] bad_page+0x158/0x1a2 > > > kernel: [<ffffffff811e9ca9>] free_pages_check_bad+0xfc/0x101 > > > kernel: [<ffffffff811ee516>] free_hot_cold_page+0x135/0x5de > > > kernel: [<ffffffff811eea26>] __free_pages+0x67/0x72 > > > kernel: [<ffffffff81227c63&gt...

...fff8801124c7420 ffffffff811e9b63 0000000000000000 > > > kernel: ffffea0004076e00 ffffffff81e658a0 ffff8801124c7440 ffffffff811e9ca9 > > > kernel: Call Trace: > > > kernel: [<ffffffff814d69b0>] dump_stack+0x68/0x92 > > > kernel: [<ffffffff811e9b63>] bad_page+0x158/0x1a2 > > > kernel: [<ffffffff811e9ca9>] free_pages_check_bad+0xfc/0x101 > > > kernel: [<ffffffff811ee516>] free_hot_cold_page+0x135/0x5de > > > kernel: [<ffffffff811eea26>] __free_pages+0x67/0x72 > > > kernel: [<ffffffff81227c63&gt...