| 01:04.49 | *** join/#edev dalias (dalias@216-12-86-13.cv.mvl.ntelos.net) |
| 01:05.04 | dalias | anybody here familiar with sh (superh) kernel internals |
| 01:05.24 | dalias | namely how the syscall interface works and where/how the pt_regs are stored at syscall entry? |
| 01:05.44 | dalias | trying to track down crazy behavior that may be a kernel bug |
| 01:12.05 | *** join/#edev prpplague (~prpplague@107-206-64-184.lightspeed.rcsntx.sbcglobal.net) |
| 01:12.06 | *** mode/#edev [+o prpplague] by ChanServ |
| 02:43.14 | wmat | dalias: wow, you're taking me back |
| 02:43.21 | wmat | dalias: try here https://oss.renesas.com/ |
| 02:43.45 | dalias | i think we figured it out and it is a serious bug |
| 02:44.12 | dalias | the space for saved r0 and r1 in pt_regs overlaps with the argument space for the 5th and 6th args to the syscall function |
| 02:44.47 | dalias | this means the actual original arguments aren't saved. the syscall function clobbers them |
| 02:45.15 | dalias | which is buggy because copy_thread() later tries to access regs[0] to get the new TLS pointer |
| 02:45.16 | wmat | which chip? |
| 02:45.19 | dalias | but it's already been clobbered |
| 02:45.22 | dalias | any sh |
| 02:45.38 | wmat | hmmm, really? |
| 02:45.48 | dalias | i don't know how long it's been like this |
| 02:46.15 | dalias | i think ancient gcc would have done what the developers expected: not clobbering these stack slots unless you modify the argument variable |
| 02:46.35 | dalias | however modern gcc treats those slots as clobberable junk if they're not accessed again |
| 02:46.47 | dalias | (which is the correct thing for a compiler to do) |
| 02:47.11 | dalias | this at least horribly breaks clone() |
| 02:47.27 | dalias | but it probably also affects 5- and 6-argument syscalls that are interruptable/restartable |
| 02:47.42 | dalias | since the 5th and 6th arguments may have been clobbered before returning to userspace pending restart |
| 02:48.21 | wmat | so compiler improvements exposed the bug? |
| 02:48.36 | dalias | yeah that's our theory so far |
| 02:49.23 | dalias | (i think pread/pwrite should be affected, but they're perhaps not interruptable in the case where the file is seekable/regular-file) |
| 02:50.23 | wmat | have you compared with an older compiler, perhaps the old Codesourcery SH toolchain? |
| 02:51.55 | dalias | no, i'm not the one doing the testing directly |
| 02:52.35 | dalias | we have someone working on porting musl libc to sh |
| 02:52.42 | dalias | and he's hit the problem trying to get threads to work |
| 02:53.05 | dalias | he added some printk's in the kernel and they seem to prove regs[0] is getting clobbered before it makes it into the new thread's TLS register |
| 02:53.24 | wmat | is this a newer SH/ARM chip? |
| 02:53.35 | dalias | he's running it on qemu |
| 02:53.46 | dalias | but my reading of the source makes it look like they should be clobberable |
| 02:54.34 | dalias | because the call to the function (from the syscall table) is made without pushing its own copies of r0/r1 as arguments |
| 02:54.49 | dalias | it just uses the first 2 slots of pt_regs on the stack (which happen to be r0 and r1 :) as its arguments |
| 02:54.53 | dalias | but then it's permitted to clobber them |
| 02:55.17 | wmat | what's he emulating, SH4 |
| 02:55.30 | dalias | it looks like somebody thought they were being clever saving 2 pushes/pops... |
| 02:55.33 | dalias | yes |
| 02:56.50 | wmat | i'm sceptical, but post a patch to lkml and see what's up |
| 02:58.26 | dalias | i was too at first |
| 02:58.40 | dalias | but the source seems to match his claim |
| 02:58.45 | wmat | linux-sh is useful, at least post a question there |
| 02:58.51 | wmat | or ping magnus |
| 02:58.54 | dalias | ml or irc? |
| 02:58.59 | wmat | ml |
| 02:59.08 | dalias | whats the addr? |
| 02:59.35 | wmat | http://vger.kernel.org/vger-lists.html#linux-sh |
| 02:59.58 | dalias | we'll see once he prepares a patch |
| 03:00.05 | dalias | if it fixes the problem, i think the bug is real |
| 03:00.20 | dalias | i can't see any way the proposed patch (pushing the args properly) could fix the problem if there's not a real bug |
| 03:01.56 | wmat | bug fixes are useful ;) |
| 04:13.15 | *** join/#edev [7] (~quassel@rockbox/developer/TheSeven) |
| 04:52.03 | *** join/#edev brianjaod1 (~brianjaod@209.181.82.6) |
| 05:01.27 | *** join/#edev kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 05:21.11 | *** join/#edev kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 05:33.06 | *** join/#edev kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 05:42.03 | *** join/#edev kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 08:47.46 | *** join/#edev flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 12:11.42 | *** join/#edev dijenerate (~dijenerat@host86-145-68-101.range86-145.btcentralplus.com) |
| 12:16.43 | *** join/#edev g1powermac (~g1powerma@rrcs-74-87-150-6.west.biz.rr.com) |
| 12:16.43 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 14:40.51 | *** join/#edev roxfan (dunno@91.180.205.157) |
| 14:50.06 | *** join/#edev Crofton (~balister@pool-71-171-41-155.ronkva.east.verizon.net) |
| 15:01.44 | *** join/#edev roxfan (dunno@91.180.205.157) |
| 15:51.37 | *** join/#edev kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 17:37.44 | *** join/#edev sirdancealot (~koo5@194.228.11.172) |
| 17:57.02 | *** join/#edev djerome (~djerome@ip68-98-228-41.ph.ph.cox.net) |
| 18:00.06 | *** join/#edev kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 18:32.31 | *** join/#edev flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 21:36.59 | *** join/#edev sirdancealot (~koo5@194.228.11.172) |
| 22:31.24 | *** join/#edev landley (~landley@70.114.134.56) |
| 22:36.22 | *** join/#edev Lars_G_ (~Lars@unaffiliated/lars-g/x-000001) |
| 22:56.48 | *** part/#edev brianjaod1 (~brianjaod@209.181.82.6) |
| 23:11.22 | *** mode/#edev [+o landley] by ChanServ |