I'm hoping that the patch referenced in the URL field will help with the issue reported by Alex Efros in the twelth comment of bug 208694. I've submitted it to stable@kernel.org but, in the meantime, it's probably worth folding into genpatches. Bugs in the mm are sufficient cause for consternation, I think. There's been some other activity in this area lately but this particular patch is quite new; I don't think it has even landed in 2.6.37.x yet.
Patch applied just fine to sys-kernel/hardened-sources-2.6.36-r9, but reproducing it mean `emerge -e world` on my workstation, which will took a lot of time and CPU load… and if bug doesn't happens that will mean I should repeat that emerge one-two more times just to make sure. I'm going to do this anyway, but it may took several days to prove bug was fixed.
No, this patch doesn't fix that bug. At this time it was "rm" process, but I've no idea which one - probably one executed while emerge, but it also may be some other cron script doing rm. <0>------------[ cut here ]------------ kern.crit: kernel BUG at mm/filemap.c:128! <0>invalid opcode: 0000 [#1] SMP <0>last sysfs file: /sys/devices/virtual/vtconsole/vtcon0/uevent kern.warn: Modules linked in: act_police cls_fw cls_u32 sch_ingress sch_tbf sch_sfq sch_prio sch_cbq sch_htb nvidia(P) vmnet vmblock vmci vmmon sky2 8139too skge kern.warn: kern.warn: Pid: 28363, comm: rm Tainted: P 2.6.36-hardened-r9 #3 P5B-Deluxe/System Product Name kern.warn: EIP: 0060:[<c10743be>] EFLAGS: 00210046 CPU: 1 kern.warn: EAX: 00000000 EBX: c365c700 ECX: 00000018 EDX: 00000009 kern.warn: ESI: e13647f8 EDI: 00000214 EBP: e5587e40 ESP: e5587e34 kern.warn: DS: 0068 ES: 0068 FS: 00d8 GS: 00e0 SS: 0068 <0>Process rm (pid: 28363, ti=e5586000 task=e564b410 task.ti=e5586000) <0>Stack: kern.warn: 00000214 c365c700 e13647f8 e5587e50 c10743f7 c365c700 e13647f8 e5587e6c kern.warn: <0> c107bfce 00001000 00000000 00000000 c365c700 0000000d e5587ed8 c107c0fa kern.warn: <0> 0000000e 00000000 00000000 00000000 e13647f8 ffffffff 0000000e 00000000 <0>Call Trace: kern.warn: [<c10743f7>] ? remove_from_page_cache+0x27/0x40 kern.warn: [<c107bfce>] ? truncate_inode_page+0x7e/0xc0 kern.warn: [<c107c0fa>] ? truncate_inode_pages_range+0xea/0x2b0 kern.warn: [<c107c2da>] ? truncate_inode_pages+0x1a/0x20 kern.warn: [<c1120075>] ? ext3_evict_inode+0x35/0x170 kern.warn: [<c10b438a>] ? evict+0x1a/0xa0 kern.warn: [<c10b4c39>] ? iput+0x159/0x240 kern.warn: [<c10ab754>] ? do_unlinkat+0xf4/0x200 kern.warn: [<c13f4ee5>] ? restore_all+0x0/0x18 kern.warn: [<c10ab9e6>] ? sys_unlinkat+0x26/0x40 kern.warn: [<c13f4ecc>] ? syscall_call+0x7/0xb <0>Code: d5 08 00 00 00 89 14 24 ba ff ff ff ff e8 bb eb 16 00 53 9d 83 c4 04 5b 5e c9 c3 66 90 ba 16 00 00 00 89 d8 e8 f4 ee 00 00 eb 89 <0f> 0b eb fe 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 <0>EIP: [<c10743be>] __remove_from_page_cache+0xae/0xc0 SS:ESP 0068:e5587e34 kern.warn: ---[ end trace e81791c6ff8a81a8 ]--- Do you think it worth trying latests vanilla-sources with that patch too?
(In reply to comment #2) > No, this patch doesn't fix that bug. At this time it was "rm" process, but I've > no idea which one - probably one executed while emerge, but it also may be some > other cron script doing rm. > > <0>------------[ cut here ]------------ > kern.crit: kernel BUG at mm/filemap.c:128! > <0>invalid opcode: 0000 [#1] SMP > <0>last sysfs file: /sys/devices/virtual/vtconsole/vtcon0/uevent > kern.warn: Modules linked in: act_police cls_fw cls_u32 sch_ingress sch_tbf > sch_sfq sch_prio sch_cbq sch_htb nvidia(P) vmnet vmblock vmci vmmon sky2 > 8139too skge > kern.warn: > kern.warn: Pid: 28363, comm: rm Tainted: P 2.6.36-hardened-r9 #3 > P5B-Deluxe/System Product Name > kern.warn: EIP: 0060:[<c10743be>] EFLAGS: 00210046 CPU: 1 > kern.warn: EAX: 00000000 EBX: c365c700 ECX: 00000018 EDX: 00000009 > kern.warn: ESI: e13647f8 EDI: 00000214 EBP: e5587e40 ESP: e5587e34 > kern.warn: DS: 0068 ES: 0068 FS: 00d8 GS: 00e0 SS: 0068 > <0>Process rm (pid: 28363, ti=e5586000 task=e564b410 task.ti=e5586000) > <0>Stack: > kern.warn: 00000214 c365c700 e13647f8 e5587e50 c10743f7 c365c700 e13647f8 > e5587e6c > kern.warn: <0> c107bfce 00001000 00000000 00000000 c365c700 0000000d e5587ed8 > c107c0fa > kern.warn: <0> 0000000e 00000000 00000000 00000000 e13647f8 ffffffff 0000000e > 00000000 > <0>Call Trace: > kern.warn: [<c10743f7>] ? remove_from_page_cache+0x27/0x40 > kern.warn: [<c107bfce>] ? truncate_inode_page+0x7e/0xc0 > kern.warn: [<c107c0fa>] ? truncate_inode_pages_range+0xea/0x2b0 > kern.warn: [<c107c2da>] ? truncate_inode_pages+0x1a/0x20 > kern.warn: [<c1120075>] ? ext3_evict_inode+0x35/0x170 > kern.warn: [<c10b438a>] ? evict+0x1a/0xa0 > kern.warn: [<c10b4c39>] ? iput+0x159/0x240 > kern.warn: [<c10ab754>] ? do_unlinkat+0xf4/0x200 > kern.warn: [<c13f4ee5>] ? restore_all+0x0/0x18 > kern.warn: [<c10ab9e6>] ? sys_unlinkat+0x26/0x40 > kern.warn: [<c13f4ecc>] ? syscall_call+0x7/0xb > <0>Code: d5 08 00 00 00 89 14 24 ba ff ff ff ff e8 bb eb 16 00 53 9d 83 c4 04 > 5b 5e c9 c3 66 90 ba 16 00 00 00 89 d8 e8 f4 ee 00 00 eb 89 <0f> 0b eb fe 8d b4 > 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 > <0>EIP: [<c10743be>] __remove_from_page_cache+0xae/0xc0 SS:ESP 0068:e5587e34 > kern.warn: ---[ end trace e81791c6ff8a81a8 ]--- > > Do you think it worth trying latests vanilla-sources with that patch too? Yes please. The pax patches touch a lot of the mm subsystem. We need to rule that out.
(In reply to comment #3) > > Do you think it worth trying latests vanilla-sources with that patch too? > Yes please. The pax patches touch a lot of the mm subsystem. We need to rule > that out. In maillist gentoo-user-ru Vladimir Solomatin said replacing SEGMEXEC with PAGEEXEC solved this issue for him, so now I'm testing this (only PAGEEXEC, without mremap patch, just to test things one-by-one)... See also bug 351666 and http://forums.grsecurity.net/viewtopic.php?f=3&t=2526 (unlike Vladimir, I use Ext3, not ReiserFS). If PAGEEXEC doesn't solve this issue I'll try latests vanilla-sources too.
(In reply to comment #4) > If PAGEEXEC doesn't solve this issue I'll try latests vanilla-sources too. PAGEEXEC solved this issue.
While the patch was, alas, of no use to Alex, it still concerns a bona fide bug and I'm now posting to say that it was accepted and included in 2.6.32.33 and 2.6.37.4.
Hugh Dickins has since commented that this patch is a more worthwhile fix than the one mentioned in the URL field of this bug:- mm: prevent concurrent unmap_mapping_range() on the same inode http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2aa15890f3c191326678f1bd68af61ec6b8753ec However, this does not cleanly apply to 2.6.32. From what I gather, he's hoping to backport it for a future stable release in that branch. This might be fit for application against 2.6.36 though (I haven't tried).
Created attachment 266427 [details, diff] prevent-concurrent-unmap_mapping_range fix (backported to 2.6.32.x) This is backport of commit 2aa15890f3c191326678f1bd68af61ec6b8753ec (prevent concurrent unmap_mapping_range() on the same inode) to 2.6.32.x. Was diffed against a grsecurity patched tree but will apply cleanly to any vanilla 2.6.32.x release, albeit with some fuzz. Will be dogfooding this one shortly ...
Created attachment 266429 [details, diff] prevent-concurrent-unmap_mapping_range fix (upstream) Commit 2aa15890f3c191326678f1bd68af61ec6b8753ec, upstream patch from git.
Created attachment 266431 [details, diff] possible-cause-of-a-page_mapped-bug fix (upstream) Commit a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7, as per first comment and as has already made it into 2.6.32.33 and 2.6.37.4.
Created attachment 266435 [details, diff] prevent-concurrent-unmap_mapping_range fix (backported to 2.6.32.x) Prior patch failed to export symbol for address_space_init_once (duh). I've given this one some testing and it seems to be stable. I also performed some basic tests with a loopback mounted nilfs2 filesystem; it appeared to function correctly.
Kerin, would you consider submitting this patch to the stable mailing list?
This is included in latest gentoo-sources for .32 and .37
Re: Comment 12 - I did, thought it only just made it in as of 2.6.32.43. Hugh Dickins originally had some concern as to it suitability but drew a different conclusion upon it being independently submitted recently, for which he very graciously apologised for holding up the fix!
