Linus Torvalds wrote:
>
> On Tue, 24 Mar 1998, Itai Nahshon wrote:
> >
> > The release function should IMHO also be an inode operation
> > and not a file operation.
>
> Both open and release need the "struct file" for flags handling etc.
>
> > Thomas Sailer has shown that it is possible to keep a file
> > memory mapped after it has been closed. This causes some
> > security problems mainly with the sound driver.
>
> This is no longer true as of 2.1.88 or so..
My mistake... I did not notice that change (2.1.89 include/linux/mm.h):
- struct dentry * vm_dentry;
+ struct file * vm_file;
>
> > There is no safe and easy way to know when is the
> > REALLY-LAST munmap on an inode from a device-driver's side.
>
> There is now, in later kernels.
>
> Linus
If it is already in pre-2.1.91-1, then it is not used properly
by ipc/shm.c. The attached program causes an oops.
The problem is in partial munmap, close is called before
open (unmap_fixup in mm/mmap.c). I think it is safe to call
open before close.
I looked around and the only place where the open and close
callbacks from vm_operations_struct are in ipc/shm.c.
Itai
--
Itai Nahshon nahshon@actcom.co.il
Also nahshon@vnet.ibm.com
--------------833570C93221409DE22C10F4
Content-Type: text/plain; charset=us-ascii; name="shm-test.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="shm-test.c"
#include <sys/types.h>
#include <fcntl.h>
#include <sys/ipc.h>
#include <sys/shm.h>
main() {
int shmid;
char *addr;
shmid = shmget(12342, 1024*1024, IPC_CREAT|IPC_PRIVATE|O_RDWR);
if(shmid < 0) {
perror("shmget");
exit(0);
}
printf("shmid = %d\n", shmid);
addr = shmat(shmid, NULL, 0);
strcpy(addr, "Hello world! test1");
if (shmctl(shmid, IPC_RMID, NULL) < 0) {
perror("shmctl IPC_RMID");
exit(0);
}
strcpy(addr, "Hello world! test2");
if(munmap(addr+1024*1020, 1024*4) < 0) {
perror("munmap");
exit(0);
}
strcpy(addr, "Hello world! test3");
sleep(100);
}
--------------833570C93221409DE22C10F4--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu