<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs/proc, branch v3.3</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/fs/proc?h=v3.3</id>
<link rel='self' href='https://git.amat.us/linux/atom/fs/proc?h=v3.3'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-02-02T20:55:17Z</updated>
<entry>
<title>Fix race in process_vm_rw_core</title>
<updated>2012-02-02T20:55:17Z</updated>
<author>
<name>Christopher Yeoh</name>
<email>cyeoh@au1.ibm.com</email>
</author>
<published>2012-02-02T01:04:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8cdb878dcb359fd1137e9abdee9322f5e9bcfdf8'/>
<id>urn:sha1:8cdb878dcb359fd1137e9abdee9322f5e9bcfdf8</id>
<content type='text'>
This fixes the race in process_vm_core found by Oleg (see

  http://article.gmane.org/gmane.linux.kernel/1235667/

for details).

This has been updated since I last sent it as the creation of the new
mm_access() function did almost exactly the same thing as parts of the
previous version of this patch did.

In order to use mm_access() even when /proc isn't enabled, we move it to
kernel/fork.c where other related process mm access functions already
are.

Signed-off-by: Chris Yeoh &lt;yeohc@au1.ibm.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>proc: make sure mem_open() doesn't pin the target's memory</title>
<updated>2012-02-01T22:39:01Z</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2012-01-31T16:15:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6d08f2c7139790c268820a2e590795cb8333181a'/>
<id>urn:sha1:6d08f2c7139790c268820a2e590795cb8333181a</id>
<content type='text'>
Once /proc/pid/mem is opened, the memory can't be released until
mem_release() even if its owner exits.

Change mem_open() to do atomic_inc(mm_count) + mmput(), this only
pins mm_struct. Change mem_rw() to do atomic_inc_not_zero(mm_count)
before access_remote_vm(), this verifies that this mm is still alive.

I am not sure what should mem_rw() return if atomic_inc_not_zero()
fails. With this patch it returns zero to match the "mm == NULL" case,
may be it should return -EINVAL like it did before e268337d.

Perhaps it makes sense to add the additional fatal_signal_pending()
check into the main loop, to ensure we do not hold this memory if
the target task was oom-killed.

Cc: stable@kernel.org
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>proc: unify mem_read() and mem_write()</title>
<updated>2012-02-01T22:39:01Z</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2012-01-31T16:14:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=572d34b946bae070debd42db1143034d9687e13f'/>
<id>urn:sha1:572d34b946bae070debd42db1143034d9687e13f</id>
<content type='text'>
No functional changes, cleanup and preparation.

mem_read() and mem_write() are very similar. Move this code into the
new common helper, mem_rw(), which takes the additional "int write"
argument.

Cc: stable@kernel.org
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>proc: mem_release() should check mm != NULL</title>
<updated>2012-02-01T22:39:01Z</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2012-01-31T16:14:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=71879d3cb3dd8f2dfdefb252775c1b3ea04a3dd4'/>
<id>urn:sha1:71879d3cb3dd8f2dfdefb252775c1b3ea04a3dd4</id>
<content type='text'>
mem_release() can hit mm == NULL, add the necessary check.

Cc: stable@kernel.org
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>proc: clear_refs: do not clear reserved pages</title>
<updated>2012-01-23T16:38:48Z</updated>
<author>
<name>Will Deacon</name>
<email>will.deacon@arm.com</email>
</author>
<published>2012-01-20T22:34:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=85e72aa5384b1a614563ad63257ded0e91d1a620'/>
<id>urn:sha1:85e72aa5384b1a614563ad63257ded0e91d1a620</id>
<content type='text'>
/proc/pid/clear_refs is used to clear the Referenced and YOUNG bits for
pages and corresponding page table entries of the task with PID pid, which
includes any special mappings inserted into the page tables in order to
provide things like vDSOs and user helper functions.

On ARM this causes a problem because the vectors page is mapped as a
global mapping and since ec706dab ("ARM: add a vma entry for the user
accessible vector page"), a VMA is also inserted into each task for this
page to aid unwinding through signals and syscall restarts.  Since the
vectors page is required for handling faults, clearing the YOUNG bit (and
subsequently writing a faulting pte) means that we lose the vectors page
*globally* and cannot fault it back in.  This results in a system deadlock
on the next exception.

To see this problem in action, just run:

	$ echo 1 &gt; /proc/self/clear_refs

on an ARM platform (as any user) and watch your system hang.  I think this
has been the case since 2.6.37

This patch avoids clearing the aforementioned bits for reserved pages,
therefore leaving the vectors page intact on ARM.  Since reserved pages
are not candidates for swap, this change should not have any impact on the
usefulness of clear_refs.

Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Reported-by: Moussa Ba &lt;moussaba@micron.com&gt;
Acked-by: Hugh Dickins &lt;hughd@google.com&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Cc: Matt Mackall &lt;mpm@selenic.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;		[2.6.37+]
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branches 'sched-urgent-for-linus', 'perf-urgent-for-linus' and 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2012-01-19T22:53:06Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-01-19T22:53:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=567e47935a7cddd8e823c73bb8ee0b2805cd4940'/>
<id>urn:sha1:567e47935a7cddd8e823c73bb8ee0b2805cd4940</id>
<content type='text'>
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/accounting, proc: Fix /proc/stat interrupts sum

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tracepoints/module: Fix disabling tracepoints with taint CRAP or OOT
  x86/kprobes: Add arch/x86/tools/insn_sanity to .gitignore
  x86/kprobes: Fix typo transferred from Intel manual

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, syscall: Need __ARCH_WANT_SYS_IPC for 32 bits
  x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
  x86, opcode: ANDN and Group 17 in x86-opcode-map.txt
  x86/kconfig: Move the ZONE_DMA entry under a menu
  x86/UV2: Add accounting for BAU strong nacks
  x86/UV2: Ack BAU interrupt earlier
  x86/UV2: Remove stale no-resources test for UV2 BAU
  x86/UV2: Work around BAU bug
  x86/UV2: Fix BAU destination timeout initialization
  x86/UV2: Fix new UV2 hardware by using native UV2 broadcast mode
  x86: Get rid of dubious one-bit signed bitfield
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit</title>
<updated>2012-01-18T00:41:31Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-01-18T00:06:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f429ee3b808118591d1f3cdf3c0d0793911a5677'/>
<id>urn:sha1:f429ee3b808118591d1f3cdf3c0d0793911a5677</id>
<content type='text'>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit: (29 commits)
  audit: no leading space in audit_log_d_path prefix
  audit: treat s_id as an untrusted string
  audit: fix signedness bug in audit_log_execve_info()
  audit: comparison on interprocess fields
  audit: implement all object interfield comparisons
  audit: allow interfield comparison between gid and ogid
  audit: complex interfield comparison helper
  audit: allow interfield comparison in audit rules
  Kernel: Audit Support For The ARM Platform
  audit: do not call audit_getname on error
  audit: only allow tasks to set their loginuid if it is -1
  audit: remove task argument to audit_set_loginuid
  audit: allow audit matching on inode gid
  audit: allow matching on obj_uid
  audit: remove audit_finish_fork as it can't be called
  audit: reject entry,always rules
  audit: inline audit_free to simplify the look of generic code
  audit: drop audit_set_macxattr as it doesn't do anything
  audit: inline checks for not needing to collect aux records
  audit: drop some potentially inadvisable likely notations
  ...

Use evil merge to fix up grammar mistakes in Kconfig file.

Bad speling and horrible grammar (and copious swearing) is to be
expected, but let's keep it to commit messages and comments, rather than
expose it to users in config help texts or printouts.
</content>
</entry>
<entry>
<title>proc: clean up and fix /proc/&lt;pid&gt;/mem handling</title>
<updated>2012-01-17T23:21:19Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-01-17T23:21:19Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e268337dfe26dfc7efd422a804dbb27977a3cccc'/>
<id>urn:sha1:e268337dfe26dfc7efd422a804dbb27977a3cccc</id>
<content type='text'>
Jüri Aedla reported that the /proc/&lt;pid&gt;/mem handling really isn't very
robust, and it also doesn't match the permission checking of any of the
other related files.

This changes it to do the permission checks at open time, and instead of
tracking the process, it tracks the VM at the time of the open.  That
simplifies the code a lot, but does mean that if you hold the file
descriptor open over an execve(), you'll continue to read from the _old_
VM.

That is different from our previous behavior, but much simpler.  If
somebody actually finds a load where this matters, we'll need to revert
this commit.

I suspect that nobody will ever notice - because the process mapping
addresses will also have changed as part of the execve.  So you cannot
actually usefully access the fd across a VM change simply because all
the offsets for IO would have changed too.

Reported-by: Jüri Aedla &lt;asd@ut.ee&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>audit: only allow tasks to set their loginuid if it is -1</title>
<updated>2012-01-17T21:17:00Z</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2012-01-03T19:23:08Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=633b45454503489209b0d9a45f9e3cd1b852c614'/>
<id>urn:sha1:633b45454503489209b0d9a45f9e3cd1b852c614</id>
<content type='text'>
At the moment we allow tasks to set their loginuid if they have
CAP_AUDIT_CONTROL.  In reality we want tasks to set the loginuid when they
log in and it be impossible to ever reset.  We had to make it mutable even
after it was once set (with the CAP) because on update and admin might have
to restart sshd.  Now sshd would get his loginuid and the next user which
logged in using ssh would not be able to set his loginuid.

Systemd has changed how userspace works and allowed us to make the kernel
work the way it should.  With systemd users (even admins) are not supposed
to restart services directly.  The system will restart the service for
them.  Thus since systemd is going to loginuid==-1, sshd would get -1, and
sshd would be allowed to set a new loginuid without special permissions.

If an admin in this system were to manually start an sshd he is inserting
himself into the system chain of trust and thus, logically, it's his
loginuid that should be used!  Since we have old systems I make this a
Kconfig option.

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
</content>
</entry>
<entry>
<title>audit: remove task argument to audit_set_loginuid</title>
<updated>2012-01-17T21:17:00Z</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2012-01-03T19:23:08Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0a300be6d5be8f66cd96609334710c268d0bfdce'/>
<id>urn:sha1:0a300be6d5be8f66cd96609334710c268d0bfdce</id>
<content type='text'>
The function always deals with current.  Don't expose an option
pretending one can use it for something.  You can't.

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
</content>
</entry>
</feed>
