On Wed, Feb 27, 2013 at 01:46:09PM -0500, Chris Metcalf wrote: > On 2/24/2013 7:29 PM, Al Viro wrote: > > Unless I'm seriously misreading your code, you have all arguments of > > compat syscall sign-extended by asm glue. If that's the case, consider > > what will happen to 32bit binary doing > > llseek(fd, 0, 0xffffffff, &pos, SEEK_CUR) > > on 32bit and 64bit hosts resp. The former will move the current position > > by 4Gb forward; the latter - by one byte backwards... > > Without testing this (I'm in an airport), I think you might be right. But the fix seems like it might just be changing the parameters of the llseek syscall in read_write.c to be "unsigned int" for offset_high and offset_low. That would let the usual syscall-wrappers code properly zero-extend the high bits. ... and screw binary compatibility on 64bit architectures that have llseek(2). I also thought that there's no such thing - after all, any such architecture has perfectly usable lseek(2). No such luck - parisc64, ppc64, sparc64, s390x and sh64 all have both of those. AFAICS, glibc does not use llseek(2) on any of those and any userland code directly using that syscall would be rather dumb, but then this is precisely the sort of userland code likely to screw it up. I don't know; it's a borderline case, but strictly speaking we would be breaking syscall ABI compatibility on those architectures by doing that. OTOH, the real rule is more squishy - "don't break real userland code", so... Hell knows. Linus, do you have any comments on that proposal? Basically, that would make sys_llseek() ignore upper 32 bits of offset_low on 64bit targets. Benefit: fixes bug in tile compat, removes the need of compat wrapper on mips, slightly simpler rules for populating compat syscall tables. Cost: changes behaviour of llseek(2) for 64bit binaries on parisc, ppc, sparc, s390, sh64. AFAIK, glibc ignores that syscall on those targets, so affected userland would have to do it manually via syscall(__NR_llseek,...). TBH, I'd rather solve it by providing a mips-style wrapper for tile, but... -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
