On Tue, Feb 10, 2009 at 08:46:58PM +0530, naresh kamboju wrote: > Hi Mr. Ralf, > > I have tried to test cacheflush system call to generate EINVAL > > on Toshiba RBTX4927/RBTX4937 board with 2.6.23 kernel. > > I have referred latest Man pages there is a bug column. > > Please let me know whether this is bug in source code or in the man page. > > (arch/mips/mm/cache.c) The answer is probably a bit of both. The API and error behaviour was defined by the earlier MIPS UNIX variant RISC/os or possibly even earlier. Gcc relies on the existence of this syscall - or rather a library function which usually will be implemented to execute this syscall because the operating requires kernel priviledges - so Linux had to get an implementation as well. Now in practice there is only one good reason to perform explicit cacheflushes from userspace and that's to ensure I-cache coherency and that's the one thing the Linux implementation of cacheflush(2) is trying to do. Therefore the implementation ignores the cache argument and will instead perform whatever is necessary to guarantee I-cache coherency - whatever this means on a particlar implementation. Similarly the implementation won't verify that every byte of the range is accessible. For a large range it instead may choose to perform a full writeback / invalidation of some or all parts of the cache hierarchy which might mean there will not be an error return even though part of the address space may not be accessible. Talking about bugs - the "BUGS" section of the man page is wrong. A full cacheflush is only performed if this is considered to be faster than a cacheline-by-cacheline flush. Ralf
