Subject: Linux/SGI: MAP_AUTOGROW, F_ALLOCSP

From: Miguel de Icaza <[email-masked]>
Date: Wed, 10 Sep 1997 21:04:06 -0500

Hello,

   I am running into a new problem: the X server is doing the
following:

	unlink ("/tmp/.Xshmtrans0");
	tfd = open ("/tmp/.Xshmtrans0", O_RDWR | O_CREAT);
	fcntl(tfd, F_SETFD, 1);
	fcntl(tfd, F_SETLKW, type=F_WRLCL, whence=SEEK_SET start=0 len=1)
	read(6, 0x7fff1b04, 4096) = 0;
	fstat(6, 0x7fff18e0) = 0;
	lseek(6, 0, SEEK_SET) = 0
	fcntl(6, F_ALLOCSP, whence=SEEK_SET, start=5224 len=0)
	mmap(0xe800000, 2149480, PROT_WRITE|PROT_READ, MAP_SHARED|MAP_AUTOGROW, 6, 0) = 0xe800000

   OK, my problem right now is that the code is using the MAP_AUTOGROW
flag for mmap.  And the second problem is that I do not understand
what the role for F_ALLOCSP is (thanks to all of you that sent me
information on this flag), but it still does not make sense.

   Regarding F_ALLOCSP: I am ignoring it.

   Regarding mmap (..., MAP_AUTOGROW,...) I have implemented two
solutions: 

	1. The "this does not have a chance of being accepted by the
	   Main Penguin" approach which implemented MAP_AUTOGROW:

		basically: new flag, and an extra if in mm/filemap.c:
	        filemap_nopage () routine.

	   This flag is not even on the opengroup web pages, so it has
           a very little chance of being accepted just for Xsgi's
           sake. 

	2. The "this sucks, but it will get into the main
           kernel real fast": on irix_mmap () if the MAP_AUTOGROW flag
           is set, it will check if the top limit for the mmap is
           bigger that the current file size, if it is it does:
	
		o = sys_lseek (fd, offset + len - 1, SEEK_SET);
		sys_write (fd, "", 1);
		sys_lseek (fd, o, SEEK_SET);

     Any ideas, comments?  I am ready to commit approach (2) ;-)

Cheers,
Miguel.

---

From: "William J. Earl" <[email-masked]>
Date: Wed, 10 Sep 1997 19:16:48 -0700

Miguel de Icaza writes:
...
 >      Any ideas, comments?  I am ready to commit approach (2) ;-)
...

     This seems reasonable enough.  This code supports the "shm" shared
memory transport of Xsgi; other process mmap() the file to communicate
with the server.  It is something of a hack (being not particularly secure).

---

From: [email-masked] (Alan Cox)
Date: Thu, 11 Sep 1997 08:26:10 +0100 (BST)

> with the server.  It is something of a hack (being not particularly secure).

So you use mmap() based XShm rather than the SYS5 ipc based shm Linux currently
uses. Makes some sense. As to secure well last time I looked nobody had yet
fixed the auth bug so X and security aren't related anyway