Messages in this thread | | | Date | Tue, 23 Nov 2004 18:31:21 +0000 (GMT) | From | Hugh Dickins <> | Subject | Re: [PATCH 2.6.10-rc2] RLIMIT_MEMLOCK accounting of shmctl() SHM_LOCK is broken |
| |
On Tue, 23 Nov 2004, Andrew Morton wrote: > > True. We should make the same change to user_shm_unlock(), and we may as > well tweak the excessive spinlock coverage in there too. > ... > and then ask Hugh and Manfred to double-check.
Looked good to me.
Examining that code for the first time, I did wonder about a couple of minor irrelevancies with regard to lock_limit - should it too be rounded up? Well, not necessarily, you can argue that the limit should be treated strictly. And it certainly shouldn't be rounded up (wrapping to 0) if it's RLIM_INFINITY. Which raises the question, should we avoid shifting it down if it's RLIM_INFINITY? And should there be a wrapping check on locked + user->locked_shm? Well, locking that much memory will meet its own problems, probably not worth worrying here.
> Looking at the callers, we do: > > user_shm_lock(inode->i_size, ...); > > then, later: > > user_shm_unlock(inode->i_size, ...); > > which does make one wonder "what happens if the file got larger while it > was locked"?
They're only used on objects created by shmem_file_setup, and for those (unlike tmpfs files) there's no interface by which they might change their size after creation; and this isn't the only place which assumes that characteristic. So, it's okay (but not at all obvious).
Hugh
- 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/
| |