Messages in this thread |  | | | From | David Howells <> | | Subject | Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex | | Date | Mon, 22 Sep 2008 15:54:09 +0100 |
| |
Hugh Dickins <hugh@veritas.com> wrote:
> But now looking into it further, I see this is all a red herring, > your rearrangement is not the significant difference: before that > there was David Howells' Jan 2006 commit > b0e15190ead07056ab0c3844a499ff35e66d27cc > [PATCH] NOMMU: Make SYSV IPC SHM use ramfs facilities on NOMMU > which is the one which adds do_truncate() into tiny-shmem.c's > shmem_file_setup() but not into shmem.c's - presumably because > config SHMEM depends on MMU so it was irrelevant in shmem.c. > > *That* is the relevant commit, which introduced the bad i_mutex > within mmap_sem lock ordering, and it seems that Nick's current > patch is wrong just to remove that do_truncate(), a significant > change hidden inside his restoration of the original arrangement.
That would break SYSV IPC SHM under CONFIG_MMU=n conditions.
The truncate is necessary as I explained in my patch:
(2) ramfs files now need resizing using do_truncate() rather than by modifying the inode size directly (see shmem_file_setup()). This causes ramfs to attempt to bind a block of pages of sufficient size to the inode.
What I didn't belabour in the patch, and perhaps I should have, is that to do SYSV IPC SHM under NOMMU conditions, it is necessary to allocate a *contiguous* set of pages - something that ramfs has been taught to do under NOMMU when truncating a file upwards from zero size. This makes POSIX SHM on ramfs files viable also.
David
|  |