Re: writable swap cache explained (it's weird)

Re: writable swap cache explained (it's weird)

[Benjamin C.R. LaHaise]

On Wed, 29 Jul 1998, Bill Hawes wrote:

> To fix this I think we need to mark the whole mess as unswappable. It
> won't work to just test for a writable pte to a shared page -- in this
> case one of the sharings is only readable. So if the readable one gets
> swapped out first, the remaining mappings would still be a problem.
> 
> Anyone have any ideas for the best way to detect and handle this case?

There are two options:

	a) disallow MAP_SHARED mappings of anonymous memory from
/proc/self/mem

	b) implement shared anon mappings

(a) sounds like the Obvious Thing To Do in the mmap method for /proc, but
will break xdos.  Wtf were they thinking in writing that insane code?
Hmmm, this bug probably applies to 2.0 too....  in a much more subtle
fashion.

As for (b), I'll try to present code by Saturday, as it is a nice feature
to add to our cap. =)  (No, it's not going to be anything like the awful
shm code.) 

		-ben

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: writable swap cache explained (it's weird)

[Bill Hawes]

Benjamin C.R. LaHaise wrote:

> There are two options:
>
>         a) disallow MAP_SHARED mappings of anonymous memory from
> /proc/self/mem
>
>         b) implement shared anon mappings
>
> (a) sounds like the Obvious Thing To Do in the mmap method for /proc, but
> will break xdos.  Wtf were they thinking in writing that insane code?
> Hmmm, this bug probably applies to 2.0 too....  in a much more subtle
> fashion.
>
> As for (b), I'll try to present code by Saturday, as it is a nice feature
> to add to our cap. =)  (No, it's not going to be anything like the awful
> shm code.)

For implementing shared anon mapping, why can't you just mmap a temp file
and then unlink it? This should provide the expected capabilities, and the
disk image would disappear when the last mapping closes.

Seems like that should work for the xdos case, though it would require a few
changes to the code.

Regards,
Bill


--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: writable swap cache explained (it's weird)

[Linus Torvalds]

On Thu, 30 Jul 1998, Benjamin C.R. LaHaise wrote:
> 
> (a) sounds like the Obvious Thing To Do in the mmap method for /proc, but
> will break xdos.  Wtf were they thinking in writing that insane code?
> Hmmm, this bug probably applies to 2.0 too....  in a much more subtle
> fashion.

The insane code is indeed insane, but I think I understand why they did
it: they didn't want to mess around with sysv shared memory regions.

I'd love to just completely get rid of mmap() on /proc/self/mem, because
it actually is a bad idea completely (not just the shared mappings - even
a private mapping of another mapping that is shared has simply completely
untenable logical problems). 

I'd much more prefer for somebody to take the time to change dosemu to use
the standard (and supported) sysv shared memory setup than to make any
kernel changes.. 

		Linus

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: writable swap cache explained (it's weird)

[Richard Gooch]

Linus Torvalds writes:
> 
> 
> On Thu, 30 Jul 1998, Benjamin C.R. LaHaise wrote:
> > 
> > (a) sounds like the Obvious Thing To Do in the mmap method for /proc, but
> > will break xdos.  Wtf were they thinking in writing that insane code?
> > Hmmm, this bug probably applies to 2.0 too....  in a much more subtle
> > fashion.
> 
> The insane code is indeed insane, but I think I understand why they did
> it: they didn't want to mess around with sysv shared memory regions.
> 
> I'd love to just completely get rid of mmap() on /proc/self/mem, because
> it actually is a bad idea completely (not just the shared mappings - even
> a private mapping of another mapping that is shared has simply completely
> untenable logical problems). 
> 
> I'd much more prefer for somebody to take the time to change dosemu to use
> the standard (and supported) sysv shared memory setup than to make any
> kernel changes.. 

I think it would be better if they used the new POSIX.4 SHM support
(shm_open(3) and friends). To do that, though, the shmfs patch would
need to be included in the kernel, though. Yeah, yeah, I know: feature
freeze. But when has that ever stopped you? ;-)

				Regards,

					Richard....
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: writable swap cache explained (it's weird)

[Eric W Biederman]

On Thu, 30 Jul 1998, Linus Torvalds wrote:

> 
> 
> On Thu, 30 Jul 1998, Benjamin C.R. LaHaise wrote:
> > 
> > (a) sounds like the Obvious Thing To Do in the mmap method for /proc, but
> > will break xdos.  Wtf were they thinking in writing that insane code?
> > Hmmm, this bug probably applies to 2.0 too....  in a much more subtle
> > fashion.
> 
> The insane code is indeed insane, but I think I understand why they did
> it: they didn't want to mess around with sysv shared memory regions.

Good guess but no.  Dosemu already uses sysv shared memory regions
where it can.  But for some applications it needs page level control, 
and sysv doesn't give you that.

Further the dosemu history states that when it was attempted to map a
temporary file, and use the standard mmap functionality that way, the
performance became unacceptable on nfs filesystems.

So /proc/self/mem was the only solution open to dosemu, that provided
the required level of performance and control.
 
> I'd love to just completely get rid of mmap() on /proc/self/mem, because
> it actually is a bad idea completely (not just the shared mappings - even
> a private mapping of another mapping that is shared has simply completely
> untenable logical problems). 

I agree and this is why I have put a considerable amount of effort into
implementing a posix shared memory interface. 

Eric 




--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org