Re: [PATCH 2.6.10-rc2] RLIMIT_MEMLOCK accounting of shmctl() SHM_LOCK is broken

[Hugh Dickins]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/