From: Darren Hart <dvhart@linux.intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
David Oliver <david@rgmadvisors.com>,
linux-kernel@vger.kernel.org,
Shawn Bohrer <sbohrer@rgmadvisors.com>,
Zachary Vonler <zvonler@rgmadvisors.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Hugh Dickins <hughd@google.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>
Subject: Re: Change in functionality of futex() system call.
Date: Mon, 06 Jun 2011 20:13:48 -0700 [thread overview]
Message-ID: <4DED976C.90009@linux.intel.com> (raw)
In-Reply-To: <1307383898.3098.90.camel@edumazet-laptop>
On 06/06/2011 11:11 AM, Eric Dumazet wrote:
> Le lundi 06 juin 2011 à 10:53 -0700, Darren Hart a écrit :
>>
>
>> If I understand the problem correctly, RO private mapping really doesn't
>> make any sense and we should probably explicitly not support it, while
>> special casing the RO shared mapping in support of David's scenario.
>>
>
> We supported them in 2.6.18 kernels, apparently. This might sounds
> stupid but who knows ?
I guess this is actually the key point we need to agree on to provide a
solution. This particular case "worked" in 2.6.18 kernels, but that
doesn't necessarily mean it was supported, or even intentional.
It sounds to me that we agree that we should support RO shared mappings.
The question remains about whether we should introduce deliberate
support of RO private mappings, and if so, if the forced COW approach is
appropriate or not.
Does anyone with a longer history working with futexes than I have an
opinion on this? Is support for RO private mappings part of our futex
API, or was it an unintentional side effect of the futex simply being a
userspace address.
--
Darren
>
>>>
>>> In David Oliver case, this is needed : He wants to catch a change in a
>>> file/memory region written by another process.
>>
>> But with shared mapping and shared futexes. He just needs the ability to
>> FUTEX_WAIT on a RO mapping. Or is that what you were saying?
>>
>
> I am saying that in David Oliver case, he sure uses a MAP_SHARED ro
> mapping.
>
> Now, what if other software uses a MAP_PRIVATE ro mapping ?
>
> It was working in previous kernels as well.
>
> We can say its stupid, but IMHO its not.
>
> In other words, this program should work, if process never touches
> (writes) into first page.
>
> This program on previous kernels gave :
> rc=-1 errno=11
> (allowing to wait for a value change and a futex_WAKE)
>
> With new kernel :
> rc=-1 errno=14 [ no sleep allowed ]
>
> #include <errno.h>
> #include <fcntl.h>
> #include <stdint.h>
> typedef uint32_t u32; // for futex.h
> #include <linux/futex.h>
> #include <sys/mman.h>
> #include <sys/syscall.h>
> #include <unistd.h>
>
>
> int main() {
> int fd, *futex, rc;
>
> fd = open("/tmp/futex_test", O_RDWR|O_CREAT, 0644);
> write(fd, "\1\1\1\1", 4);
> futex = (int *)mmap(0, sizeof(int), PROT_READ, MAP_PRIVATE, fd, 0);
> rc = syscall(SYS_futex, futex, FUTEX_WAIT, 42, 0, 0, 0);
> printf("rc=%d errno=%d\n", rc, errno);
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2011-06-07 3:13 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 14:28 Change in functionality of futex() system call David Oliver
2011-06-06 15:23 ` Eric Dumazet
2011-06-06 15:56 ` Shawn Bohrer
2011-06-06 16:11 ` Peter Zijlstra
2011-06-06 16:16 ` Peter Zijlstra
2011-06-06 16:22 ` Eric Dumazet
2011-06-06 16:29 ` Peter Zijlstra
2011-06-06 16:42 ` Eric Dumazet
2011-06-06 17:05 ` Peter Zijlstra
2011-06-06 17:11 ` Eric Dumazet
2011-06-06 17:27 ` Steven Rostedt
2011-06-06 17:56 ` Darren Hart
2011-06-06 18:23 ` Peter Zijlstra
2011-06-06 18:27 ` Eric Dumazet
2011-06-25 0:00 ` Darren Hart
2011-06-27 16:48 ` Shawn Bohrer
2011-06-06 17:53 ` Darren Hart
2011-06-06 18:11 ` Eric Dumazet
2011-06-07 3:13 ` Darren Hart [this message]
2011-06-07 3:49 ` Eric Dumazet
2011-06-07 14:44 ` Andy Lutomirski
2011-06-07 15:56 ` Darren Hart
2011-06-07 15:58 ` Eric Dumazet
2011-06-07 18:43 ` Andrew Lutomirski
2011-06-07 19:01 ` Darren Hart
2011-06-07 19:04 ` Andrew Lutomirski
2011-06-07 19:06 ` Eric Dumazet
2011-06-07 19:10 ` David Oliver
2011-06-07 19:19 ` Andrew Lutomirski
2011-06-07 19:33 ` David Oliver
2011-06-07 19:53 ` Andrew Lutomirski
2011-06-07 20:04 ` David Oliver
2011-06-07 20:12 ` Andrew Lutomirski
2011-06-07 22:26 ` Kyle Moffett
2011-06-08 15:20 ` David Oliver
2011-06-08 15:21 ` Andrew Lutomirski
2011-06-08 16:21 ` Darren Hart
2011-06-09 11:37 ` KOSAKI Motohiro
2011-06-09 12:05 ` Peter Zijlstra
2011-06-09 17:58 ` Peter Zijlstra
2011-06-10 3:30 ` KOSAKI Motohiro
2011-06-10 3:26 ` KOSAKI Motohiro
2011-06-07 18:30 ` Joel Becker
2011-06-09 12:05 ` Peter Zijlstra
2011-06-10 12:10 ` KOSAKI Motohiro
2011-06-10 17:29 ` Darren Hart
2011-06-13 2:11 ` KOSAKI Motohiro
2011-06-13 15:50 ` Darren Hart
2011-06-15 18:50 ` Shawn Bohrer
2011-06-15 18:54 ` Darren Hart
2011-06-17 13:40 ` Shawn Bohrer
2011-06-22 19:19 ` [PATCH RFC] futex: Fix regression with read only mappings Shawn Bohrer
2011-06-22 20:14 ` Darren Hart
2011-06-23 2:51 ` KOSAKI Motohiro
2011-06-23 15:26 ` Darren Hart
2011-06-23 19:49 ` Shawn Bohrer
2011-06-24 15:59 ` [PATCH v2] " Shawn Bohrer
2011-06-25 0:37 ` Darren Hart
2011-06-25 15:10 ` KOSAKI Motohiro
2011-06-27 16:40 ` Shawn Bohrer
2011-06-27 18:15 ` Peter Zijlstra
2011-06-27 20:41 ` Darren Hart
2011-06-27 21:08 ` Shawn Bohrer
2011-06-27 21:39 ` Darren Hart
2011-06-27 22:14 ` Shawn Bohrer
2011-06-27 23:17 ` Darren Hart
2011-06-27 22:22 ` [PATCH v3] " Shawn Bohrer
2011-06-28 10:54 ` Peter Zijlstra
2011-06-28 14:52 ` Darren Hart
2011-06-28 17:38 ` Shawn Bohrer
2011-06-28 20:58 ` Darren Hart
2011-06-28 23:55 ` Darren Hart
2011-06-29 14:56 ` Shawn Bohrer
2011-06-29 15:17 ` [PATCH v4] " Shawn Bohrer
2011-06-29 18:41 ` Darren Hart
2011-06-29 23:38 ` Thomas Gleixner
2011-06-30 4:19 ` Darren Hart
2011-06-30 14:02 ` David C. Oliver
2011-06-30 15:41 ` Darren Hart
2011-06-30 16:21 ` [PATCH v5] " Shawn Bohrer
2011-07-12 15:27 ` Shawn Bohrer
2011-07-25 15:20 ` Shawn Bohrer
2011-07-25 19:28 ` Thomas Gleixner
2011-07-26 19:04 ` [tip:core/urgent] " tip-bot for Shawn Bohrer
2011-06-28 10:50 ` [PATCH v2] " Peter Zijlstra
2011-06-28 14:19 ` Darren Hart
2011-06-28 14:23 ` Peter Zijlstra
2011-06-23 3:58 ` [PATCH RFC] " Shawn Bohrer
2011-06-23 3:23 ` Change in functionality of futex() system call KOSAKI Motohiro
-- strict thread matches above, loose matches on Subject: below --
2011-06-09 0:44 George Spelvin
2011-06-09 3:02 ` Darren Hart
2011-06-09 3:38 ` Andrew Lutomirski
2011-06-09 3:54 ` Eric Dumazet
2011-06-09 4:10 ` Andrew Lutomirski
2011-06-09 5:11 ` Eric Dumazet
2011-06-09 12:12 ` Andrew Lutomirski
2011-06-09 4:43 ` George Spelvin
2011-06-09 5:25 ` Eric Dumazet
2011-06-09 4:44 ` Kyle Moffett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DED976C.90009@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=david@rgmadvisors.com \
--cc=eric.dumazet@gmail.com \
--cc=hughd@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=sbohrer@rgmadvisors.com \
--cc=tglx@linutronix.de \
--cc=zvonler@rgmadvisors.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox