* Re: OCFS2 mainline state?
2013-02-25 20:33 OCFS2 mainline state? Richard Weinberger
@ 2013-02-25 21:11 ` Mark Fasheh
2013-02-25 21:16 ` Al Viro
2013-02-25 21:30 ` Mark Fasheh
2013-02-25 21:37 ` Smart Weblications GmbH - Florian Wiessner
2013-03-02 10:15 ` Vincent ETIENNE
2 siblings, 2 replies; 8+ messages in thread
From: Mark Fasheh @ 2013-02-25 21:11 UTC (permalink / raw)
To: Richard Weinberger
Cc: ocfs2-devel, ocfs2-user, linux-kernel, viro, jlbec, linux-fsdevel,
david
On Mon, Feb 25, 2013 at 09:33:34PM +0100, Richard Weinberger wrote:
> Today I encountered the following problem on v3.8:
> [ 28.940032] general protection fault: 0000 [#1] PREEMPT SMP
> ...
> [ 28.984953] Call Trace:
> [ 28.986628 [<ffffffffa04cb200>] ocfs2_fast_symlink_readpage+0x70/0x1b0 [ocfs2]
> [ 28.988302] [<ffffffff8110dc49>] ? add_to_page_cache_lru+0x29/0x40
> [ 28.989942] [<ffffffff8110ddca>] do_read_cache_page+0x7a/0x170
> [ 28.991573] [<ffffffff8110def4>] read_cache_page_async+0x14/0x20
> [ 28.993212] [<ffffffff8110df09>] read_cache_page+0x9/0x20
> [ 28.994827] [<ffffffff81170ae5>] page_getlink.isra.9+0x25/0x80
> [ 28.996442] [<ffffffff81170b61>] page_follow_link_light+0x21/0x40
> [ 28.998049] [<ffffffff8117090d>] generic_readlink+0x3d/0xa0
> [ 28.999653] [<ffffffff8116c0db>] sys_readlinkat+0xfb/0x130
> [ 29.001246] [<ffffffff8116c126>] sys_readlink+0x16/0x20
> [ 29.002839] [<ffffffff815d8dad>] system_call_fastpath+0x1a/0x1f
I've seen that patch actually and yes it should have been in mainline
already. I didn't see whether it's in -mm (Andrew is pickup up some of the
patches for us right now).
I'll check and if it's not I'll try to send him a version of it today.
--Mark
--
Mark Fasheh
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: OCFS2 mainline state?
2013-02-25 21:11 ` Mark Fasheh
@ 2013-02-25 21:16 ` Al Viro
2013-02-25 21:28 ` Mark Fasheh
2013-03-02 10:05 ` Joel Becker
2013-02-25 21:30 ` Mark Fasheh
1 sibling, 2 replies; 8+ messages in thread
From: Al Viro @ 2013-02-25 21:16 UTC (permalink / raw)
To: Mark Fasheh
Cc: Richard Weinberger, ocfs2-devel, ocfs2-user, linux-kernel, jlbec,
linux-fsdevel, david
On Mon, Feb 25, 2013 at 01:11:03PM -0800, Mark Fasheh wrote:
> I've seen that patch actually and yes it should have been in mainline
> already. I didn't see whether it's in -mm (Andrew is pickup up some of the
> patches for us right now).
>
> I'll check and if it's not I'll try to send him a version of it today.
Normally filesystem trees are fed to Linus... Or I can pick that patch via
VFS tree (and send it to Linus tomorrow). There also had been Jan's ocfs2
patch a while ago; I picked only the VFS part of that series, ext* and
IIRC xfs ones went to corresponding filesystem trees. Should I just pick
the ocfs2 stuff from now on?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: OCFS2 mainline state?
2013-02-25 21:16 ` Al Viro
@ 2013-02-25 21:28 ` Mark Fasheh
2013-03-02 10:05 ` Joel Becker
1 sibling, 0 replies; 8+ messages in thread
From: Mark Fasheh @ 2013-02-25 21:28 UTC (permalink / raw)
To: Al Viro
Cc: Richard Weinberger, ocfs2-devel, ocfs2-user, linux-kernel, jlbec,
linux-fsdevel, david
On Mon, Feb 25, 2013 at 09:16:18PM +0000, Al Viro wrote:
> On Mon, Feb 25, 2013 at 01:11:03PM -0800, Mark Fasheh wrote:
>
> > I've seen that patch actually and yes it should have been in mainline
> > already. I didn't see whether it's in -mm (Andrew is pickup up some of the
> > patches for us right now).
> >
> > I'll check and if it's not I'll try to send him a version of it today.
>
> Normally filesystem trees are fed to Linus... Or I can pick that patch via
> VFS tree (and send it to Linus tomorrow). There also had been Jan's ocfs2
> patch a while ago; I picked only the VFS part of that series, ext* and
> IIRC xfs ones went to corresponding filesystem trees. Should I just pick
> the ocfs2 stuff from now on?
I personally would absolutely be fine (and grateful) with you picking up the
Ocfs2 stuff.
--Mark
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: OCFS2 mainline state?
2013-02-25 21:16 ` Al Viro
2013-02-25 21:28 ` Mark Fasheh
@ 2013-03-02 10:05 ` Joel Becker
1 sibling, 0 replies; 8+ messages in thread
From: Joel Becker @ 2013-03-02 10:05 UTC (permalink / raw)
To: Al Viro
Cc: Mark Fasheh, Richard Weinberger, ocfs2-devel, ocfs2-user,
linux-kernel, linux-fsdevel, david
On Mon, Feb 25, 2013 at 09:16:18PM +0000, Al Viro wrote:
> On Mon, Feb 25, 2013 at 01:11:03PM -0800, Mark Fasheh wrote:
>
> > I've seen that patch actually and yes it should have been in mainline
> > already. I didn't see whether it's in -mm (Andrew is pickup up some of the
> > patches for us right now).
> >
> > I'll check and if it's not I'll try to send him a version of it today.
>
> Normally filesystem trees are fed to Linus... Or I can pick that patch via
> VFS tree (and send it to Linus tomorrow). There also had been Jan's ocfs2
> patch a while ago; I picked only the VFS part of that series, ext* and
> IIRC xfs ones went to corresponding filesystem trees. Should I just pick
> the ocfs2 stuff from now on?
Andrew's been picking it up. I'm doing the Acked-by thing, until I have
a test environment back. Thank you for offering, and if Andrew gets
tired of it before I'm fully operational, we'll happily take you up on
this.
Joel
--
"There is no more evil thing on earth than race prejudice, none at
all. I write deliberately -- it is the worst single thing in life
now. It justifies and holds together more baseness, cruelty and
abomination than any other sort of error in the world."
- H. G. Wells
http://www.jlbec.org/
jlbec@evilplan.org
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: OCFS2 mainline state?
2013-02-25 21:11 ` Mark Fasheh
2013-02-25 21:16 ` Al Viro
@ 2013-02-25 21:30 ` Mark Fasheh
1 sibling, 0 replies; 8+ messages in thread
From: Mark Fasheh @ 2013-02-25 21:30 UTC (permalink / raw)
To: Richard Weinberger
Cc: david, ocfs2-user, linux-kernel, linux-fsdevel, ocfs2-devel, viro
On Mon, Feb 25, 2013 at 01:11:03PM -0800, Mark Fasheh wrote:
> On Mon, Feb 25, 2013 at 09:33:34PM +0100, Richard Weinberger wrote:
> > Today I encountered the following problem on v3.8:
> > [ 28.940032] general protection fault: 0000 [#1] PREEMPT SMP
> > ...
> > [ 28.984953] Call Trace:
> > [ 28.986628 [<ffffffffa04cb200>] ocfs2_fast_symlink_readpage+0x70/0x1b0 [ocfs2]
> > [ 28.988302] [<ffffffff8110dc49>] ? add_to_page_cache_lru+0x29/0x40
> > [ 28.989942] [<ffffffff8110ddca>] do_read_cache_page+0x7a/0x170
> > [ 28.991573] [<ffffffff8110def4>] read_cache_page_async+0x14/0x20
> > [ 28.993212] [<ffffffff8110df09>] read_cache_page+0x9/0x20
> > [ 28.994827] [<ffffffff81170ae5>] page_getlink.isra.9+0x25/0x80
> > [ 28.996442] [<ffffffff81170b61>] page_follow_link_light+0x21/0x40
> > [ 28.998049] [<ffffffff8117090d>] generic_readlink+0x3d/0xa0
> > [ 28.999653] [<ffffffff8116c0db>] sys_readlinkat+0xfb/0x130
> > [ 29.001246] [<ffffffff8116c126>] sys_readlink+0x16/0x20
> > [ 29.002839] [<ffffffff815d8dad>] system_call_fastpath+0x1a/0x1f
>
> I've seen that patch actually and yes it should have been in mainline
> already. I didn't see whether it's in -mm (Andrew is pickup up some of the
> patches for us right now).
>
> I'll check and if it's not I'll try to send him a version of it today.
Checked - this is in linux-next so I would expect to see it upstream
eventually.
--Mark
--
Mark Fasheh
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: OCFS2 mainline state?
2013-02-25 20:33 OCFS2 mainline state? Richard Weinberger
2013-02-25 21:11 ` Mark Fasheh
@ 2013-02-25 21:37 ` Smart Weblications GmbH - Florian Wiessner
2013-03-02 10:15 ` Vincent ETIENNE
2 siblings, 0 replies; 8+ messages in thread
From: Smart Weblications GmbH - Florian Wiessner @ 2013-02-25 21:37 UTC (permalink / raw)
To: Richard Weinberger
Cc: ocfs2-devel, ocfs2-user, linux-kernel, viro, mfasheh, jlbec,
linux-fsdevel, david
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
Am 25.02.2013 21:33, schrieb Richard Weinberger:
> Hi!
>
> Today I encountered the following problem on v3.8:
> [ 28.940032] general protection fault: 0000 [#1] PREEMPT SMP
> ...
> [ 28.984953] Call Trace:
> [ 28.986628 [<ffffffffa04cb200>] ocfs2_fast_symlink_readpage+0x70/0x1b0 [ocfs2]
> [ 28.988302] [<ffffffff8110dc49>] ? add_to_page_cache_lru+0x29/0x40
> [ 28.989942] [<ffffffff8110ddca>] do_read_cache_page+0x7a/0x170
> [ 28.991573] [<ffffffff8110def4>] read_cache_page_async+0x14/0x20
> [ 28.993212] [<ffffffff8110df09>] read_cache_page+0x9/0x20
> [ 28.994827] [<ffffffff81170ae5>] page_getlink.isra.9+0x25/0x80
> [ 28.996442] [<ffffffff81170b61>] page_follow_link_light+0x21/0x40
> [ 28.998049] [<ffffffff8117090d>] generic_readlink+0x3d/0xa0
> [ 28.999653] [<ffffffff8116c0db>] sys_readlinkat+0xfb/0x130
> [ 29.001246] [<ffffffff8116c126>] sys_readlink+0x16/0x20
> [ 29.002839] [<ffffffff815d8dad>] system_call_fastpath+0x1a/0x1f
>
> To my utter astonishment I found out that the issue is known since August 2012.
> And there is also a trivial fix for it.[0]
> The said fix found it's way into Oracle Unbreakable Linux very quickly,
> but not into mainline.[1]
>
> Now I'm wondering how much Oracle really cares about OCFS2 in mainline?
> Maybe there are some more unfixed vulnerabilities?
>
I noticed and reported this on 07.02.2013 but got no reply ;(
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
[-- Attachment #2: Nachricht als Anhang --]
[-- Type: message/rfc822, Size: 10406 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 5118 bytes --]
Hi All,
Today i found a problem in linux 3.7.6 with ocfs2 when using ocfs2 from inside a
chroot or linux-vserver guest. This problem also exists at least in 3.6.11.
how to reproduce:
node:~# cat /etc/debian_version
6.0.6
node:~# rbd showmapped
id pool image snap device
1 rbd ocfs2 - /dev/rbd1
mounted ocfs2 fs on rdb device on /ocfs2:
/dev/rbd1 on /ocfs2 type ocfs2 (rw,_netdev,noatime,data=writeback,heartbeat=local)
mount --bind /ocfs2 /var/lib/vservers/www/ocfs2
chroot /var/lib/vservers/www
www:/# cat /etc/debian_version
5.0.10
DocumentRoots for apache are on ocfs2
/etc/init.d/apache2 start
Then apache hangs and i have to reboot, see trace (annotated with addr2line
where available):
[ 225.548824] general protection fault: 0000[#1] PREEMPT SMP
[ 225.549067] Modules linked in: ipt_REJECT xt_multiport arpt_mangle
arptable_filter arp_tables ip6table_filter ip6_tables iptable_filter ip_tables
ebtable_nat ebtables x_tables cpufreq_userspace cpufreq_powersave
cpufreq_ondemand cpufreq_conservative ocfs2_stack_o2cb bridge stp llc bonding
fuse ocfs2_dlm ocfs2_dlmfs dlm sctp ocfs2 ocfs2_nodemanager ocfs2_stackglue
configfs rbd acpi_cpufreq mperf coretemp kvm_intel kvm psmouse serio_raw lpc_ich
mfd_core i2c_i801 evdev i2c_core btrfs lzo_compress
[ 225.551698] CPU 1
[ 225.551755] Pid: 5888, comm: apache2 Not tainted 3.7.6 #1 Supermicro
X9SCI/X9SCA/X9SCI/X9SCA
[ 225.551913] RIP: 0010:[<ffffffff81299f30>] [<ffffffff81299f30>]
strnlen+0x10/0x19 /lib/string.c:405
[ 225.552059] RSP: 0018:ffff8808160a3b80 EFLAGS: 00010216
[ 225.552135] RAX: e8894402000000a5 RBX: e8894402000000a5 RCX: 000000000063ea4c
[ 225.552215] RDX: 000000000063ea4c RSI: 0000000000000f3f RDI: e8894402000000a5
[ 225.552294] RBP: ffffea00170650b8 R08: ffffffff810b8c7e R09: 0000000000000000
[ 225.552374] R10: ffff880816b50100 R11: ffff880816b50100 R12: ffff8806974afbf8
[ 225.552450] R13: 00000000000200da R14: 00000000000201da R15: 0000000000000000
[ 225.552530] FS: 00007eff6d9e2750(0000) GS:ffff88083fc40000(0000)
knlGS:0000000000000000
[ 225.552625] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 225.552701] CR2: 00007fa71e7fbd40 CR3: 00000007f7849000 CR4: 00000000000407e0
[ 225.552778] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 225.552858] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 225.552938] Process apache2 (pid: 5888, threadinfo ffff8808160a2000, task
ffff880816b50100)
[ 225.553032] Stack:
[ 225.553103] ffffffffa06d7d27 ffffea00170650b8 ffff8806974afd38 ffffea00170650b8
[ 225.553408] ffffffff810b8c7e 0000000000000000 ffff8806974afd38 ffffea00170650b8
[ 225.553711] ffffffff810b8ddd ffff8808160a3ca8 ffffffffa06d7c20 ffff8806974d2440
[ 225.554016] Call Trace:
[ 225.554098] [<ffffffffa06d7d27>] ?
ocfs2_fast_symlink_readpage+0x107/0x1a0[ocfs2] ??:0
[ 225.554194] [<ffffffff810b8c7e>] ? add_to_page_cache_lru+0x2c/0x36
/include/linux/swap.h:253
[ 225.554272] [<ffffffff810b8ddd>] ? do_read_cache_page+0x8f/0x132
/mm/filemap.c:1802
[ 225.554359] [<ffffffffa06d7c20>] ? ocfs2_osb_debug_open+0x670/0x670[ocfs2]
??:0
[ 225.554442] [<ffffffff810b8ebf>] ? read_cache_page+0x9/0x12
/mm/filemap.c:1921
[ 225.554521] [<ffffffff8110d1e1>] ? page_getlink+0x25/0x86
/fs/namei.c:3956
[ 225.554598] [<ffffffff8110d25d>] ? page_follow_link_light+0x1b/0x2c
/include/linux/namei.h:88
[ 225.554675] [<ffffffff8110e90c>] ? link_path_walk+0x400/0x7c5
/fs/namei.c:851
[ 225.554751] [<ffffffff8110f133>] ? path_lookupat+0x52/0x6cf
/fs/namei.c:1983
[ 225.554835] [<ffffffff8110f7d0>] ? filename_lookup+0x20/0x92
/fs/namei.c:2024
[ 225.554922] [<ffffffff81111a78>] ? getname_flags+0x70/0x146
/fs/namei.c:159
[ 225.554997] [<ffffffff81112376>] ? user_path_at_empty+0x49/0x7d
/fs/namei.c:2172
[ 225.555077] [<ffffffff8104dbee>] ? autoremove_wake_function+0x2a/0x2a
/kernel/wait.c:174
[ 225.555155] [<ffffffff811093d4>] ? cp_new_stat+0x10d/0x11f
/fs/stat.c:241
[ 225.555231] [<ffffffff811095d1>] ? vfs_fstatat+0x39/0x66
/fs/stat.c:89
[ 225.555314] [<ffffffff811096c8>] ? sys_newstat+0x11/0x2d
/fs/stat.c:248
[ 225.555402] [<ffffffff81542dd2>] ? system_call_fastpath+0x16/0x1b
/arch/x86/kernel/entry_64.S:645
[ 225.555480] Code: f6 82 30 a9 58 81 20 75 f1 c3 48 89 f8 eb 03 48 ff c0 80 38
00 75 f8 48 29 f8 c3 48 89 f8 eb 03 48 ff c0 48 85 f6 74 08 48 ff ce <80> 38 00
75 f0 48 29 f8 c3 31 c0 eb 14 44 38 c1 74 0c 48 ff c2
[ 225.559020] RIP [<ffffffff81299f30>] strnlen+0x10/0x19
/lib/string.c:405
[ 225.559143] RSP <ffff8808160a3b80>
[ 225.559254] ---[ end trace 10bd8a6b280d52b1 ]---
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
[-- Attachment #2.1.2: trace.txt --]
[-- Type: text/plain, Size: 4258 bytes --]
[ 225.548824] general protection fault: 0000[#1] PREEMPT SMP
[ 225.549067] Modules linked in: ipt_REJECT xt_multiport arpt_mangle arptable_filter arp_tables ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative ocfs2_stack_o2cb bridge stp llc bonding fuse ocfs2_dlm ocfs2_dlmfs dlm sctp ocfs2 ocfs2_nodemanager ocfs2_stackglue configfs rbd acpi_cpufreq mperf coretemp kvm_intel kvm psmouse serio_raw lpc_ich mfd_core i2c_i801 evdev i2c_core btrfs lzo_compress
[ 225.551698] CPU 1
[ 225.551755] Pid: 5888, comm: apache2 Not tainted 3.7.6 #1 Supermicro X9SCI/X9SCA/X9SCI/X9SCA
[ 225.551913] RIP: 0010:[<ffffffff81299f30>] [<ffffffff81299f30>] strnlen+0x10/0x19 /lib/string.c:405
[ 225.552059] RSP: 0018:ffff8808160a3b80 EFLAGS: 00010216
[ 225.552135] RAX: e8894402000000a5 RBX: e8894402000000a5 RCX: 000000000063ea4c
[ 225.552215] RDX: 000000000063ea4c RSI: 0000000000000f3f RDI: e8894402000000a5
[ 225.552294] RBP: ffffea00170650b8 R08: ffffffff810b8c7e R09: 0000000000000000
[ 225.552374] R10: ffff880816b50100 R11: ffff880816b50100 R12: ffff8806974afbf8
[ 225.552450] R13: 00000000000200da R14: 00000000000201da R15: 0000000000000000
[ 225.552530] FS: 00007eff6d9e2750(0000) GS:ffff88083fc40000(0000) knlGS:0000000000000000
[ 225.552625] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 225.552701] CR2: 00007fa71e7fbd40 CR3: 00000007f7849000 CR4: 00000000000407e0
[ 225.552778] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 225.552858] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 225.552938] Process apache2 (pid: 5888, threadinfo ffff8808160a2000, task ffff880816b50100)
[ 225.553032] Stack:
[ 225.553103] ffffffffa06d7d27 ffffea00170650b8 ffff8806974afd38 ffffea00170650b8
[ 225.553408] ffffffff810b8c7e 0000000000000000 ffff8806974afd38 ffffea00170650b8
[ 225.553711] ffffffff810b8ddd ffff8808160a3ca8 ffffffffa06d7c20 ffff8806974d2440
[ 225.554016] Call Trace:
[ 225.554098] [<ffffffffa06d7d27>] ? ocfs2_fast_symlink_readpage+0x107/0x1a0[ocfs2] ??:0
[ 225.554194] [<ffffffff810b8c7e>] ? add_to_page_cache_lru+0x2c/0x36 /include/linux/swap.h:253
[ 225.554272] [<ffffffff810b8ddd>] ? do_read_cache_page+0x8f/0x132 /mm/filemap.c:1802
[ 225.554359] [<ffffffffa06d7c20>] ? ocfs2_osb_debug_open+0x670/0x670[ocfs2] ??:0
[ 225.554442] [<ffffffff810b8ebf>] ? read_cache_page+0x9/0x12 /mm/filemap.c:1921
[ 225.554521] [<ffffffff8110d1e1>] ? page_getlink+0x25/0x86 /fs/namei.c:3956
[ 225.554598] [<ffffffff8110d25d>] ? page_follow_link_light+0x1b/0x2c /include/linux/namei.h:88
[ 225.554675] [<ffffffff8110e90c>] ? link_path_walk+0x400/0x7c5 /fs/namei.c:851
[ 225.554751] [<ffffffff8110f133>] ? path_lookupat+0x52/0x6cf /fs/namei.c:1983
[ 225.554835] [<ffffffff8110f7d0>] ? filename_lookup+0x20/0x92 /fs/namei.c:2024
[ 225.554922] [<ffffffff81111a78>] ? getname_flags+0x70/0x146 /fs/namei.c:159
[ 225.554997] [<ffffffff81112376>] ? user_path_at_empty+0x49/0x7d /fs/namei.c:2172
[ 225.555077] [<ffffffff8104dbee>] ? autoremove_wake_function+0x2a/0x2a /kernel/wait.c:174
[ 225.555155] [<ffffffff811093d4>] ? cp_new_stat+0x10d/0x11f /fs/stat.c:241
[ 225.555231] [<ffffffff811095d1>] ? vfs_fstatat+0x39/0x66 /fs/stat.c:89
[ 225.555314] [<ffffffff811096c8>] ? sys_newstat+0x11/0x2d /fs/stat.c:248
[ 225.555402] [<ffffffff81542dd2>] ? system_call_fastpath+0x16/0x1b /arch/x86/kernel/entry_64.S:645
[ 225.555480] Code: f6 82 30 a9 58 81 20 75 f1 c3 48 89 f8 eb 03 48 ff c0 80 38 00 75 f8 48 29 f8 c3 48 89 f8 eb 03 48 ff c0 48 85 f6 74 08 48 ff ce <80> 38 00 75 f0 48 29 f8 c3 31 c0 eb 14 44 38 c1 74 0c 48 ff c2
[ 225.559020] RIP [<ffffffff81299f30>] strnlen+0x10/0x19 /lib/string.c:405
[ 225.559143] RSP <ffff8808160a3b80>
[ 225.559254] ---[ end trace 10bd8a6b280d52b1 ]---
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: OCFS2 mainline state?
2013-02-25 20:33 OCFS2 mainline state? Richard Weinberger
2013-02-25 21:11 ` Mark Fasheh
2013-02-25 21:37 ` Smart Weblications GmbH - Florian Wiessner
@ 2013-03-02 10:15 ` Vincent ETIENNE
2 siblings, 0 replies; 8+ messages in thread
From: Vincent ETIENNE @ 2013-03-02 10:15 UTC (permalink / raw)
To: Richard Weinberger
Cc: ocfs2-devel, ocfs2-user, linux-kernel, viro, mfasheh, jlbec,
linux-fsdevel, david
Hi
I was testing this path in august and i have two patch applied for ocfs2
The one your referring and also a changed in file.c
At the time of the test, the two patch were necessary ( and both
suppress a BUG although
not the same one)
Sorry i have no idea if it's still necessary or not, but i prefer to
send you a notice
Vincent ETIENNE
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1998,7 +1998,7 @@ static long ocfs2_fallocate(struct file *file, int
mode, loff_t offset,
sr.l_start = (s64)offset;
sr.l_len = (s64)len;
- return __ocfs2_change_file_space(NULL, inode, offset, cmd, &sr,
+ return __ocfs2_change_file_space(file, inode, offset, cmd, &sr,
change_size);
}
diff --git a/fs/ocfs2/symlink.c b/fs/ocfs2/symlink.c
index f1fbb4b..66edce7 100644
--- a/fs/ocfs2/symlink.c
+++ b/fs/ocfs2/symlink.c
@@ -57,7 +57,7 @@
static int ocfs2_fast_symlink_readpage(struct file *unused, struct page
*page)
{
struct inode *inode = page->mapping->host;
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
int status = ocfs2_read_inode_block(inode, &bh);
struct ocfs2_dinode *fe;
const char *link;
Le 25/02/2013 21:33, Richard Weinberger a écrit :
> Hi!
>
> Today I encountered the following problem on v3.8:
> [ 28.940032] general protection fault: 0000 [#1] PREEMPT SMP
> ...
> [ 28.984953] Call Trace:
> [ 28.986628 [<ffffffffa04cb200>]
> ocfs2_fast_symlink_readpage+0x70/0x1b0 [ocfs2]
> [ 28.988302] [<ffffffff8110dc49>] ? add_to_page_cache_lru+0x29/0x40
> [ 28.989942] [<ffffffff8110ddca>] do_read_cache_page+0x7a/0x170
> [ 28.991573] [<ffffffff8110def4>] read_cache_page_async+0x14/0x20
> [ 28.993212] [<ffffffff8110df09>] read_cache_page+0x9/0x20
> [ 28.994827] [<ffffffff81170ae5>] page_getlink.isra.9+0x25/0x80
> [ 28.996442] [<ffffffff81170b61>] page_follow_link_light+0x21/0x40
> [ 28.998049] [<ffffffff8117090d>] generic_readlink+0x3d/0xa0
> [ 28.999653] [<ffffffff8116c0db>] sys_readlinkat+0xfb/0x130
> [ 29.001246] [<ffffffff8116c126>] sys_readlink+0x16/0x20
> [ 29.002839] [<ffffffff815d8dad>] system_call_fastpath+0x1a/0x1f
>
> To my utter astonishment I found out that the issue is known since
> August 2012.
> And there is also a trivial fix for it.[0]
> The said fix found it's way into Oracle Unbreakable Linux very quickly,
> but not into mainline.[1]
>
> Now I'm wondering how much Oracle really cares about OCFS2 in mainline?
> Maybe there are some more unfixed vulnerabilities?
>
> Not amused,
> //richard
>
> [0] http://www.mail-archive.com/ocfs2-devel@oss.oracle.com/msg07774.html
> [1] https://oss.oracle.com/pipermail/el-errata/2012-October/003103.html
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply related [flat|nested] 8+ messages in thread