<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs/exec.c, branch v2.6.36</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v2.6.36</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v2.6.36'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2010-10-15T02:15:28Z</updated>
<entry>
<title>Export dump_{write,seek} to binary loader modules</title>
<updated>2010-10-15T02:15:28Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-10-15T02:15:28Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8fd01d6cfbf75465d84a4e533ed70c5f57b3ff51'/>
<id>urn:sha1:8fd01d6cfbf75465d84a4e533ed70c5f57b3ff51</id>
<content type='text'>
If you build aout support as a module, you'll want these exported.

Reported-by: Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Un-inline the core-dump helper functions</title>
<updated>2010-10-14T21:32:06Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-10-14T21:32:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3aa0ce825ade0cf5506e32ccf51d01fc8d22a9cf'/>
<id>urn:sha1:3aa0ce825ade0cf5506e32ccf51d01fc8d22a9cf</id>
<content type='text'>
Tony Luck reports that the addition of the access_ok() check in commit
0eead9ab41da ("Don't dump task struct in a.out core-dumps") broke the
ia64 compile due to missing the necessary header file includes.

Rather than add yet another include (&lt;asm/unistd.h&gt;) to make everything
happy, just uninline the silly core dump helper functions and move the
bodies to fs/exec.c where they make a lot more sense.

dump_seek() in particular was too big to be an inline function anyway,
and none of them are in any way performance-critical.  And we really
don't need to mess up our include file headers more than they already
are.

Reported-and-tested-by: Tony Luck &lt;tony.luck@gmail.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>execve: make responsive to SIGKILL with large arguments</title>
<updated>2010-09-10T15:10:26Z</updated>
<author>
<name>Roland McGrath</name>
<email>roland@redhat.com</email>
</author>
<published>2010-09-08T02:37:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9aea5a65aa7a1af9a4236dfaeb0088f1624f9919'/>
<id>urn:sha1:9aea5a65aa7a1af9a4236dfaeb0088f1624f9919</id>
<content type='text'>
An execve with a very large total of argument/environment strings
can take a really long time in the execve system call.  It runs
uninterruptibly to count and copy all the strings.  This change
makes it abort the exec quickly if sent a SIGKILL.

Note that this is the conservative change, to interrupt only for
SIGKILL, by using fatal_signal_pending().  It would be perfectly
correct semantics to let any signal interrupt the string-copying in
execve, i.e. use signal_pending() instead of fatal_signal_pending().
We'll save that change for later, since it could have user-visible
consequences, such as having a timer set too quickly make it so that
an execve can never complete, though it always happened to work before.

Signed-off-by: Roland McGrath &lt;roland@redhat.com&gt;
Reviewed-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>execve: improve interactivity with large arguments</title>
<updated>2010-09-10T15:10:26Z</updated>
<author>
<name>Roland McGrath</name>
<email>roland@redhat.com</email>
</author>
<published>2010-09-08T02:36:28Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7993bc1f4663c0db67bb8f0d98e6678145b387cd'/>
<id>urn:sha1:7993bc1f4663c0db67bb8f0d98e6678145b387cd</id>
<content type='text'>
This adds a preemption point during the copying of the argument and
environment strings for execve, in copy_strings().  There is already
a preemption point in the count() loop, so this doesn't add any new
points in the abstract sense.

When the total argument+environment strings are very large, the time
spent copying them can be much more than a normal user time slice.
So this change improves the interactivity of the rest of the system
when one process is doing an execve with very large arguments.

Signed-off-by: Roland McGrath &lt;roland@redhat.com&gt;
Reviewed-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>setup_arg_pages: diagnose excessive argument size</title>
<updated>2010-09-10T15:10:26Z</updated>
<author>
<name>Roland McGrath</name>
<email>roland@redhat.com</email>
</author>
<published>2010-09-08T02:35:49Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1b528181b2ffa14721fb28ad1bd539fe1732c583'/>
<id>urn:sha1:1b528181b2ffa14721fb28ad1bd539fe1732c583</id>
<content type='text'>
The CONFIG_STACK_GROWSDOWN variant of setup_arg_pages() does not
check the size of the argument/environment area on the stack.
When it is unworkably large, shift_arg_pages() hits its BUG_ON.
This is exploitable with a very large RLIMIT_STACK limit, to
create a crash pretty easily.

Check that the initial stack is not too large to make it possible
to map in any executable.  We're not checking that the actual
executable (or intepreter, for binfmt_elf) will fit.  So those
mappings might clobber part of the initial stack mapping.  But
that is just userland lossage that userland made happen, not a
kernel problem.

Signed-off-by: Roland McGrath &lt;roland@redhat.com&gt;
Reviewed-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6</title>
<updated>2010-08-18T16:35:08Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-08-18T16:35:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=145c3ae46b37993b0debb0b3da6256daea4a6ec5'/>
<id>urn:sha1:145c3ae46b37993b0debb0b3da6256daea4a6ec5</id>
<content type='text'>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
  fs: brlock vfsmount_lock
  fs: scale files_lock
  lglock: introduce special lglock and brlock spin locks
  tty: fix fu_list abuse
  fs: cleanup files_lock locking
  fs: remove extra lookup in __lookup_hash
  fs: fs_struct rwlock to spinlock
  apparmor: use task path helpers
  fs: dentry allocation consolidation
  fs: fix do_lookup false negative
  mbcache: Limit the maximum number of cache entries
  hostfs -&gt;follow_link() braino
  hostfs: dumb (and usually harmless) tpyo - strncpy instead of strlcpy
  remove SWRITE* I/O types
  kill BH_Ordered flag
  vfs: update ctime when changing the file's permission by setfacl
  cramfs: only unlock new inodes
  fix reiserfs_evict_inode end_writeback second call
</content>
</entry>
<entry>
<title>fs: fs_struct rwlock to spinlock</title>
<updated>2010-08-18T12:35:46Z</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@kernel.dk</email>
</author>
<published>2010-08-17T18:37:33Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2a4419b5b2a77f3f4537c14f7ad7df95770655dd'/>
<id>urn:sha1:2a4419b5b2a77f3f4537c14f7ad7df95770655dd</id>
<content type='text'>
fs: fs_struct rwlock to spinlock

struct fs_struct.lock is an rwlock with the read-side used to protect root and
pwd members while taking references to them. Taking a reference to a path
typically requires just 2 atomic ops, so the critical section is very small.
Parallel read-side operations would have cacheline contention on the lock, the
dentry, and the vfsmount cachelines, so the rwlock is unlikely to ever give a
real parallelism increase.

Replace it with a spinlock to avoid one or two atomic operations in typical
path lookup fastpath.

Signed-off-by: Nick Piggin &lt;npiggin@kernel.dk&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>Make do_execve() take a const filename pointer</title>
<updated>2010-08-18T01:07:43Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2010-08-17T22:52:56Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d7627467b7a8dd6944885290a03a07ceb28c10eb'/>
<id>urn:sha1:d7627467b7a8dd6944885290a03a07ceb28c10eb</id>
<content type='text'>
Make do_execve() take a const filename pointer so that kernel_execve() compiles
correctly on ARM:

arch/arm/kernel/sys_arm.c:88: warning: passing argument 1 of 'do_execve' discards qualifiers from pointer target type

This also requires the argv and envp arguments to be consted twice, once for
the pointer array and once for the strings the array points to.  This is
because do_execve() passes a pointer to the filename (now const) to
copy_strings_kernel().  A simpler alternative would be to cast the filename
pointer in do_execve() when it's passed to copy_strings_kernel().

do_execve() may not change any of the strings it is passed as part of the argv
or envp lists as they are some of them in .rodata, so marking these strings as
const should be fine.

Further kernel_execve() and sys_execve() need to be changed to match.

This has been test built on x86_64, frv, arm and mips.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Tested-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Acked-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.infradead.org/users/eparis/notify</title>
<updated>2010-08-10T18:39:13Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-08-10T18:39:13Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8c8946f509a494769a8c602b5ed189df01917d39'/>
<id>urn:sha1:8c8946f509a494769a8c602b5ed189df01917d39</id>
<content type='text'>
* 'for-linus' of git://git.infradead.org/users/eparis/notify: (132 commits)
  fanotify: use both marks when possible
  fsnotify: pass both the vfsmount mark and inode mark
  fsnotify: walk the inode and vfsmount lists simultaneously
  fsnotify: rework ignored mark flushing
  fsnotify: remove global fsnotify groups lists
  fsnotify: remove group-&gt;mask
  fsnotify: remove the global masks
  fsnotify: cleanup should_send_event
  fanotify: use the mark in handler functions
  audit: use the mark in handler functions
  dnotify: use the mark in handler functions
  inotify: use the mark in handler functions
  fsnotify: send fsnotify_mark to groups in event handling functions
  fsnotify: Exchange list heads instead of moving elements
  fsnotify: srcu to protect read side of inode and vfsmount locks
  fsnotify: use an explicit flag to indicate fsnotify_destroy_mark has been called
  fsnotify: use _rcu functions for mark list traversal
  fsnotify: place marks on object in order of group memory address
  vfs/fsnotify: fsnotify_close can delay the final work in fput
  fsnotify: store struct file not struct path
  ...

Fix up trivial delete/modify conflict in fs/notify/inotify/inotify.c.
</content>
</entry>
<entry>
<title>Merge branch 'bkl/core' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing</title>
<updated>2010-08-08T00:06:54Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-08-08T00:06:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=78417334b5cb6e1f915b8fdcc4fce3f1a1b4420c'/>
<id>urn:sha1:78417334b5cb6e1f915b8fdcc4fce3f1a1b4420c</id>
<content type='text'>
* 'bkl/core' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing:
  do_coredump: Do not take BKL
  init: Remove the BKL from startup code
</content>
</entry>
</feed>
