lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTin1ENdh-TUmycZp_gn5kjHvcSGUfQ@mail.gmail.com>
Date:	Sun, 26 Jun 2011 00:10:48 +0900
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Darren Hart <dvhart@...ux.intel.com>
Cc:	Shawn Bohrer <sbohrer@...advisors.com>, peterz@...radead.org,
	eric.dumazet@...il.com, david@...advisors.com,
	linux-kernel@...r.kernel.org, zvonler@...advisors.com,
	hughd@...gle.com, tglx@...utronix.de, mingo@...e.hu
Subject: Re: [PATCH v2] futex: Fix regression with read only mappings

>> commit 7485d0d3758e8e6491a5c9468114e74dc050785d (futexes: Remove rw
>> parameter from get_futex_key()) in 2.6.33 introduced a user-mode
>> regression in that it additionally prevented futex operations on a
>> region within a read only memory mapped file.  For example this breaks
>> workloads that have one or more reader processes doing a FUTEX_WAIT on a
>> futex within a read only shared mapping, and a writer processes that has
>> a writable mapping issuing the FUTEX_WAKE.
>>
>> This fixes the regression for futex operations that should be valid on
>> RO mappings by trying a RO get_user_pages_fast() when the RW
>> get_user_pages_fast() fails so as not to slow down the common path of
>> writable anonymous maps and bailing when we used the RO path on
>> anonymous memory.
>
> The goal here is to bail with EFAULT when we use a RO MAP_PRIVATE
> mapping on file-backed memory correct?

The problem is, mapping knowledge is contained vma and it's required mma_sem
(ie performance hurt). Therefore we have only three ways, maybe.

1) always take mmap_sem and walk vma,  likes 2.6.18. (cons. slow)
2) prefault, likes current linus-tree. (cons don't work RO mappings)
3) combination prefault and mmap_sem. likes my previous post.
  http://groups.google.com/group/linux.kernel/msg/c41c819207e519c2?dmode=source

In other words, you hope to care RO private mapping thing, you can't avoid
mmap_sem anymore. unfortunatelly. So, we have to select either cons.

> Final concern:
> Are shared memory segments (shmget, etc.) considered "file backed?

It's another corner case. It similar with shared file mapping, but,

   PageSwapBacked(page) => 1
   PageAnon(page) => 0

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ