<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux, branch v3.8.8</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.8.8</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.8.8'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2013-04-17T04:48:29+00:00</updated>
<entry>
<title>ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section</title>
<updated>2013-04-17T04:48:29+00:00</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2013-04-12T20:40:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=103d7cb05682db5a57e40b96f2029be91171c112'/>
<id>urn:sha1:103d7cb05682db5a57e40b96f2029be91171c112</id>
<content type='text'>
commit 7f49ef69db6bbf756c0abca7e9b65b32e999eec8 upstream.

As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to
be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the
ftrace_pid_fops is defined when DYNAMIC_FTRACE is not.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tracing: Fix possible NULL pointer dereferences</title>
<updated>2013-04-17T04:48:29+00:00</updated>
<author>
<name>Namhyung Kim</name>
<email>namhyung.kim@lge.com</email>
</author>
<published>2013-04-11T06:55:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bea692a5004128c029112632c546e320d71fe99d'/>
<id>urn:sha1:bea692a5004128c029112632c546e320d71fe99d</id>
<content type='text'>
commit 6a76f8c0ab19f215af2a3442870eeb5f0e81998d upstream.

Currently set_ftrace_pid and set_graph_function files use seq_lseek
for their fops.  However seq_open() is called only for FMODE_READ in
the fops-&gt;open() so that if an user tries to seek one of those file
when she open it for writing, it sees NULL seq_file and then panic.

It can be easily reproduced with following command:

  $ cd /sys/kernel/debug/tracing
  $ echo 1234 | sudo tee -a set_ftrace_pid

In this example, GNU coreutils' tee opens the file with fopen(, "a")
and then the fopen() internally calls lseek().

Link: http://lkml.kernel.org/r/1365663302-2170-1-git-send-email-namhyung@kernel.org

Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung.kim@lge.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>spinlocks and preemption points need to be at least compiler barriers</title>
<updated>2013-04-12T16:52:09+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-04-09T17:48:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bfd3dc9b7abeaa29c6bc10bfcaef5a7e998e0de1'/>
<id>urn:sha1:bfd3dc9b7abeaa29c6bc10bfcaef5a7e998e0de1</id>
<content type='text'>
commit 386afc91144b36b42117b0092893f15bc8798a80 upstream.

In UP and non-preempt respectively, the spinlocks and preemption
disable/enable points are stubbed out entirely, because there is no
regular code that can ever hit the kind of concurrency they are meant to
protect against.

However, while there is no regular code that can cause scheduling, we
_do_ end up having some exceptional (literally!) code that can do so,
and that we need to make sure does not ever get moved into the critical
region by the compiler.

In particular, get_user() and put_user() is generally implemented as
inline asm statements (even if the inline asm may then make a call
instruction to call out-of-line), and can obviously cause a page fault
and IO as a result.  If that inline asm has been scheduled into the
middle of a preemption-safe (or spinlock-protected) code region, we
obviously lose.

Now, admittedly this is *very* unlikely to actually ever happen, and
we've not seen examples of actual bugs related to this.  But partly
exactly because it's so hard to trigger and the resulting bug is so
subtle, we should be extra careful to get this right.

So make sure that even when preemption is disabled, and we don't have to
generate any actual *code* to explicitly tell the system that we are in
a preemption-disabled region, we need to at least tell the compiler not
to move things around the critical region.

This patch grew out of the same discussion that caused commits
79e5f05edcbf ("ARC: Add implicit compiler barrier to raw_local_irq*
functions") and 3e2e0d2c222b ("tile: comment assumption about
__insn_mtspr for &lt;asm/irqflags.h&gt;") to come about.

Note for stable: use discretion when/if applying this.  As mentioned,
this bug may never have actually bitten anybody, and gcc may never have
done the required code motion for it to possibly ever trigger in
practice.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Steven Rostedt &lt;srostedt@redhat.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: Set max sector to 65535 for Slimtype DVD A DS8A8SH drive</title>
<updated>2013-04-12T16:52:06+00:00</updated>
<author>
<name>Shan Hai</name>
<email>shan.hai@windriver.com</email>
</author>
<published>2013-03-18T02:30:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e584d9d2a25b79fcf07d66dbdccef6646623b9e7'/>
<id>urn:sha1:e584d9d2a25b79fcf07d66dbdccef6646623b9e7</id>
<content type='text'>
commit a32450e127fc6e5ca6d958ceb3cfea4d30a00846 upstream.

The Slimtype DVD A  DS8A8SH drive locks up when max sector is smaller than
65535, and the blow backtrace is observed on locking up:

INFO: task flush-8:32:1130 blocked for more than 120 seconds.
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
flush-8:32      D ffffffff8180cf60     0  1130      2 0x00000000
 ffff880273aef618 0000000000000046 0000000000000005 ffff880273aee000
 ffff880273aee000 ffff880273aeffd8 ffff880273aee010 ffff880273aee000
 ffff880273aeffd8 ffff880273aee000 ffff88026e842ea0 ffff880274a10000
Call Trace:
 [&lt;ffffffff8168fc2d&gt;] schedule+0x5d/0x70
 [&lt;ffffffff8168fccc&gt;] io_schedule+0x8c/0xd0
 [&lt;ffffffff81324461&gt;] get_request+0x731/0x7d0
 [&lt;ffffffff8133dc60&gt;] ? cfq_allow_merge+0x50/0x90
 [&lt;ffffffff81083aa0&gt;] ? wake_up_bit+0x40/0x40
 [&lt;ffffffff81320443&gt;] ? bio_attempt_back_merge+0x33/0x110
 [&lt;ffffffff813248ea&gt;] blk_queue_bio+0x23a/0x3f0
 [&lt;ffffffff81322176&gt;] generic_make_request+0xc6/0x120
 [&lt;ffffffff81322308&gt;] submit_bio+0x138/0x160
 [&lt;ffffffff811d7596&gt;] ? bio_alloc_bioset+0x96/0x120
 [&lt;ffffffff811d1f61&gt;] submit_bh+0x1f1/0x220
 [&lt;ffffffff811d48b8&gt;] __block_write_full_page+0x228/0x340
 [&lt;ffffffff811d3650&gt;] ? attach_nobh_buffers+0xc0/0xc0
 [&lt;ffffffff811d8960&gt;] ? I_BDEV+0x10/0x10
 [&lt;ffffffff811d8960&gt;] ? I_BDEV+0x10/0x10
 [&lt;ffffffff811d4ab6&gt;] block_write_full_page_endio+0xe6/0x100
 [&lt;ffffffff811d4ae5&gt;] block_write_full_page+0x15/0x20
 [&lt;ffffffff811d9268&gt;] blkdev_writepage+0x18/0x20
 [&lt;ffffffff81142527&gt;] __writepage+0x17/0x40
 [&lt;ffffffff811438ba&gt;] write_cache_pages+0x34a/0x4a0
 [&lt;ffffffff81142510&gt;] ? set_page_dirty+0x70/0x70
 [&lt;ffffffff81143a61&gt;] generic_writepages+0x51/0x80
 [&lt;ffffffff81143ab0&gt;] do_writepages+0x20/0x50
 [&lt;ffffffff811c9ed6&gt;] __writeback_single_inode+0xa6/0x2b0
 [&lt;ffffffff811ca861&gt;] writeback_sb_inodes+0x311/0x4d0
 [&lt;ffffffff811caaa6&gt;] __writeback_inodes_wb+0x86/0xd0
 [&lt;ffffffff811cad43&gt;] wb_writeback+0x1a3/0x330
 [&lt;ffffffff816916cf&gt;] ? _raw_spin_lock_irqsave+0x3f/0x50
 [&lt;ffffffff811b8362&gt;] ? get_nr_inodes+0x52/0x70
 [&lt;ffffffff811cb0ac&gt;] wb_do_writeback+0x1dc/0x260
 [&lt;ffffffff8168dd34&gt;] ? schedule_timeout+0x204/0x240
 [&lt;ffffffff811cb232&gt;] bdi_writeback_thread+0x102/0x2b0
 [&lt;ffffffff811cb130&gt;] ? wb_do_writeback+0x260/0x260
 [&lt;ffffffff81083550&gt;] kthread+0xc0/0xd0
 [&lt;ffffffff81083490&gt;] ? kthread_worker_fn+0x1b0/0x1b0
 [&lt;ffffffff8169a3ec&gt;] ret_from_fork+0x7c/0xb0
 [&lt;ffffffff81083490&gt;] ? kthread_worker_fn+0x1b0/0x1b0

 The above trace was triggered by
   "dd if=/dev/zero of=/dev/sr0 bs=2048 count=32768"

 It was previously working by accident, since another bug introduced
 by 4dce8ba94c7 (libata: Use 'bool' return value for ata_id_XXX) caused
 all drives to use maxsect=65535.

Signed-off-by: Shan Hai &lt;shan.hai@windriver.com&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: Use integer return value for atapi_command_packet_set</title>
<updated>2013-04-12T16:52:05+00:00</updated>
<author>
<name>Shan Hai</name>
<email>shan.hai@windriver.com</email>
</author>
<published>2013-03-18T02:30:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c2d2cd83e221156d11cd5f8945630e8509a852a6'/>
<id>urn:sha1:c2d2cd83e221156d11cd5f8945630e8509a852a6</id>
<content type='text'>
commit d8668fcb0b257d9fdcfbe5c172a99b8d85e1cd82 upstream.

The function returns type of ATAPI drives so it should return integer value.
The commit 4dce8ba94c7 (libata: Use 'bool' return value for ata_id_XXX) since
v2.6.39 changed the type of return value from int to bool, the change would
cause all of the ATAPI class drives to be treated as TYPE_TAPE and the
max_sectors of the drives to be set to 65535 because of the commit
f8d8e5799b7(libata: increase 128 KB / cmd limit for ATAPI tape drives), for the
function would return true for all ATAPI class drives and the TYPE_TAPE is
defined as 0x01.

Signed-off-by: Shan Hai &lt;shan.hai@windriver.com&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>thermal: shorten too long mcast group name</title>
<updated>2013-04-05T16:26:17+00:00</updated>
<author>
<name>Masatake YAMATO</name>
<email>yamato@redhat.com</email>
</author>
<published>2013-04-01T18:50:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3ae217a9770eb723640bc07587359a2b86d96e13'/>
<id>urn:sha1:3ae217a9770eb723640bc07587359a2b86d96e13</id>
<content type='text'>
[ Upstream commits 73214f5d9f33b79918b1f7babddd5c8af28dd23d
  and f1e79e208076ffe7bad97158275f1c572c04f5c7, the latter
  adds an assertion to genetlink to prevent this from happening
  again in the future. ]

The original name is too long.

Signed-off-by: Masatake YAMATO &lt;yamato@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: serial: add modem-status-change wait queue</title>
<updated>2013-04-05T16:26:03+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2013-03-19T08:21:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=86be053a795c17acaa6721dcc501a876368fd9d4'/>
<id>urn:sha1:86be053a795c17acaa6721dcc501a876368fd9d4</id>
<content type='text'>
commit e5b33dc9d16053c2ae4c2c669cf008829530364b upstream.

Add modem-status-change wait queue to struct usb_serial_port that
subdrivers can use to implement TIOCMIWAIT.

Currently subdrivers use a private wait queue which may have been
released when waking up after device disconnected.

Note that we're adding a new wait queue rather than reusing the tty-port
one as we do not want to get woken up at hangup (yet).

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>userns: Restrict when proc and sysfs can be mounted</title>
<updated>2013-04-05T16:26:02+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2013-03-24T21:28:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cfc13c72f4642f811c159cceb921df69cd158725'/>
<id>urn:sha1:cfc13c72f4642f811c159cceb921df69cd158725</id>
<content type='text'>
commit 87a8ebd637dafc255070f503909a053cf0d98d3f upstream.

Only allow unprivileged mounts of proc and sysfs if they are already
mounted when the user namespace is created.

proc and sysfs are interesting because they have content that is
per namespace, and so fresh mounts are needed when new namespaces
are created while at the same time proc and sysfs have content that
is shared between every instance.

Respect the policy of who may see the shared content of proc and sysfs
by only allowing new mounts if there was an existing mount at the time
the user namespace was created.

In practice there are only two interesting cases: proc and sysfs are
mounted at their usual places, proc and sysfs are not mounted at all
(some form of mount namespace jail).

Acked-by: Serge Hallyn &lt;serge.hallyn@canonical.com&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>vfs: Add a mount flag to lock read only bind mounts</title>
<updated>2013-04-05T16:26:01+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2013-03-22T10:10:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2f8d2ffe267ddb8d28dbed0ebb2d8dcf47c629fd'/>
<id>urn:sha1:2f8d2ffe267ddb8d28dbed0ebb2d8dcf47c629fd</id>
<content type='text'>
commit 90563b198e4c6674c63672fae1923da467215f45 upstream.

When a read-only bind mount is copied from mount namespace in a higher
privileged user namespace to a mount namespace in a lesser privileged
user namespace, it should not be possible to remove the the read-only
restriction.

Add a MNT_LOCK_READONLY mount flag to indicate that a mount must
remain read-only.

Acked-by: Serge Hallyn &lt;serge.hallyn@canonical.com&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>userns: Don't allow creation if the user is chrooted</title>
<updated>2013-04-05T16:26:01+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2013-03-15T08:45:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7f60ac1533f522fe257dca74fbb4c4d3820a9b0f'/>
<id>urn:sha1:7f60ac1533f522fe257dca74fbb4c4d3820a9b0f</id>
<content type='text'>
commit 3151527ee007b73a0ebd296010f1c0454a919c7d upstream.

Guarantee that the policy of which files may be access that is
established by setting the root directory will not be violated
by user namespaces by verifying that the root directory points
to the root of the mount namespace at the time of user namespace
creation.

Changing the root is a privileged operation, and as a matter of policy
it serves to limit unprivileged processes to files below the current
root directory.

For reasons of simplicity and comprehensibility the privilege to
change the root directory is gated solely on the CAP_SYS_CHROOT
capability in the user namespace.  Therefore when creating a user
namespace we must ensure that the policy of which files may be access
can not be violated by changing the root directory.

Anyone who runs a processes in a chroot and would like to use user
namespace can setup the same view of filesystems with a mount
namespace instead.  With this result that this is not a practical
limitation for using user namespaces.

Acked-by: Serge Hallyn &lt;serge.hallyn@canonical.com&gt;
Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
