Mathieu - <naa...@poolp.org> writes: > Hello everyone, > > While playing a bit with ptrace to do some debugging I stumbled upon > something that looks like a bug. > While trying to write to the ptrace'd process using PT_IO in combinaison > with PIOD_WRITE_D I kept getting EFAULTs. > PIOD_READ_D would work fine on the same address though, and even more > weirdly PIOD_WRITE_I would also work fine on the same address. > Even more strange, PT_WRITE_D works fine too on the same address. > So in effect, only PT_IO + PIOD_WRITE_D would EFAULT on this address. > > If this is the expected behavior (I really doubt it), then the man page > is wrong because it states clearly that *_I and *_D are equivalent. > > Digging a bit on the implementation I traced it back to rev 1.33 of > sys_process.c. > The old implementation used procfs_domem to do the uvm_io call, and > based the decision as to use UVM_IO_FIXPROT or not on the uio.uio_rw > field (UIO_WRITE meant FIXPROT vs UIO_READ). > However the new implementation, in process_domem takes a third > parameter, req, the ptrace request and would use UVM_IO_FIXPROT only in > the PT_WRITE_I case (rings any bell?). > That's why PT_WRITE_D will EFAULT in any case. > Oh and PT_WRITE_I and PT_WRITE_D work because they both use PT_WRITE_I > as the req parameter : > process_domem(p, t, &uio, write ? PT_WRITE_I : .... > > So I came up with the following diff (kind of the big hammer approach), > which gets rid of the req parameters and base the UVM_IO_FIXPROT > decision on the uio.uio_rw field as the previous code (10 years ago!) > was doing.
This looks correct to me. ok / can I get another review? -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
