Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1550199 > unrolled thread
| Started by | Pavel Machek <pavel@ucw.cz> |
|---|---|
| First post | 2017-01-03 22:10 +0100 |
| Last post | 2017-01-12 23:00 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [Question] New mmap64 syscall? Pavel Machek <pavel@ucw.cz> - 2017-01-03 22:10 +0100
Re: [Question] New mmap64 syscall? Florian Weimer <fweimer@redhat.com> - 2017-01-12 17:20 +0100
Re: [Question] New mmap64 syscall? Pavel Machek <pavel@ucw.cz> - 2017-01-12 23:00 +0100
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2017-01-03 22:10 +0100 |
| Subject | Re: [Question] New mmap64 syscall? |
| Message-ID | <sVEvh-3xp-71@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
> >Hi Florian, > > > >I frankly don't understand what you mean, All syscalls you mentioned > >doesn't take off_t or other 64-bit arguments. 'VM changes' - virtual > >memory? If so, I don't see any changes in VM with this approach, just > >correct handling of big offsets. > > What I was trying to suggest is a completely different interface which is > not subject to register size constraints and which has been requested before > (a mechanism for batching mm updates). While I agree that batching might be good idea, I believe mmap64() makes sense, too. Yes, I guess libc could do the translation, but indirection will cost some performance, and will be problematic for stuff such as strace. ...actually, with strace and batched interface, it will be impossible to see what is going on because of races. So I'm not sure if I like the batched interface at all... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [next] | [standalone]
| From | Florian Weimer <fweimer@redhat.com> |
|---|---|
| Date | 2017-01-12 17:20 +0100 |
| Message-ID | <sYQgy-66R-27@gated-at.bofh.it> |
| In reply to | #1550199 |
On 01/03/2017 09:54 PM, Pavel Machek wrote: > ...actually, with strace and batched interface, it will be impossible > to see what is going on because of races. So I'm not sure if I like > the batched interface at all... I'm not sure if I understand this problem. ioctl, fcntl, most socket system calls, even open all have this problem as well, right? Thanks, Florian
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2017-01-12 23:00 +0100 |
| Message-ID | <sYVzA-GY-9@gated-at.bofh.it> |
| In reply to | #1557569 |
[Multipart message — attachments visible in raw view] — view raw
On Thu 2017-01-12 17:13:25, Florian Weimer wrote: > On 01/03/2017 09:54 PM, Pavel Machek wrote: > >...actually, with strace and batched interface, it will be impossible > >to see what is going on because of races. So I'm not sure if I like > >the batched interface at all... > > I'm not sure if I understand this problem. > > ioctl, fcntl, most socket system calls, even open all have this problem as > well, right? Yes, ioctl() and similar are problematic. Still it is possible to implement secure sandbox using ptrace. Dealing with indirect mmap() would difficult AFAICT. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web