<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include, branch v3.4.98</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.4.98</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.4.98'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2014-07-09T17:51:20+00:00</updated>
<entry>
<title>Bluetooth: Remove unused hci_le_ltk_reply()</title>
<updated>2014-07-09T17:51:20+00:00</updated>
<author>
<name>Syam Sidhardhan</name>
<email>s.syam@samsung.com</email>
</author>
<published>2012-04-12T15:03:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eb688f6a4b6090dbcdccc935cf074618c0f421c1'/>
<id>urn:sha1:eb688f6a4b6090dbcdccc935cf074618c0f421c1</id>
<content type='text'>
commit e10b9969f217c948c5523045f44eba4d3a758ff0 upstream.

In this API, we were using sizeof operator for an array
given as function argument, which is invalid.
However this API is not used anywhere.

Signed-off-by: Syam Sidhardhan &lt;s.syam@samsung.com&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo@padovan.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: add USB_DEVICE_INTERFACE_CLASS macro</title>
<updated>2014-07-09T17:51:19+00:00</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2012-10-31T05:08:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3943a08b97f2e36e01172d1f321e43c8067c9094'/>
<id>urn:sha1:3943a08b97f2e36e01172d1f321e43c8067c9094</id>
<content type='text'>
commit 17b72feb2be14e6d37023267dc0e199e8e0e3fdc upstream.

Matching on device and interface class with with unspecified
subclass and protocol is sometimes useful.  This is slightly
different from USB_DEVICE_AND_INTERFACE_INFO which requires
the full interface class/subclass/protocol triplet.

Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tracing: Fix syscall_*regfunc() vs copy_process() race</title>
<updated>2014-07-07T01:49:20+00:00</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2014-04-13T18:58:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0c3351a0a4815ea566d3febf82033b6c55ed4a2d'/>
<id>urn:sha1:0c3351a0a4815ea566d3febf82033b6c55ed4a2d</id>
<content type='text'>
commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream.

syscall_regfunc() and syscall_unregfunc() should set/clear
TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
with copy_process() and miss the new child which was not added to
the process/thread lists yet.

Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
under tasklist.

Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com

Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints"
Acked-by: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
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>ptrace,x86: force IRET path after a ptrace_stop()</title>
<updated>2014-07-07T01:49:20+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-07-03T19:43:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e3293b8639a90b7227be9c273af0a45015c499bb'/>
<id>urn:sha1:e3293b8639a90b7227be9c273af0a45015c499bb</id>
<content type='text'>
commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.

The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values.  That is
very much part of why it's faster than 'iret'.

Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.

However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'.  Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.

Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Acked-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>skbuff: add an api to orphan frags</title>
<updated>2014-07-01T03:01:33+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2012-07-20T09:23:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1f29351617ffe827edf80ffdfdef2da3a2494f96'/>
<id>urn:sha1:1f29351617ffe827edf80ffdfdef2da3a2494f96</id>
<content type='text'>
commit a353e0ce0fd42d8859260666d1e9b10f2abd4698 upstream.

Many places do
       if ((skb_shinfo(skb)-&gt;tx_flags &amp; SKBTX_DEV_ZEROCOPY))
		skb_copy_ubufs(skb, gfp_mask);
to copy and invoke frag destructors if necessary.
Add an inline helper for this.

Signed-off-by: Michael S. Tsirkin &lt;mst@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>genirq: Sanitize spurious interrupt detection of threaded irqs</title>
<updated>2014-07-01T03:01:33+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2013-03-07T13:53:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a97df3f22b83742deb9191d53928641ec3befb6e'/>
<id>urn:sha1:a97df3f22b83742deb9191d53928641ec3befb6e</id>
<content type='text'>
commit 1e77d0a1ed7417d2a5a52a7b8d32aea1833faa6c upstream.

Till reported that the spurious interrupt detection of threaded
interrupts is broken in two ways:

- note_interrupt() is called for each action thread of a shared
  interrupt line. That's wrong as we are only interested whether none
  of the device drivers felt responsible for the interrupt, but by
  calling multiple times for a single interrupt line we account
  IRQ_NONE even if one of the drivers felt responsible.

- note_interrupt() when called from the thread handler is not
  serialized. That leaves the members of irq_desc which are used for
  the spurious detection unprotected.

To solve this we need to defer the spurious detection of a threaded
interrupt to the next hardware interrupt context where we have
implicit serialization.

If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we
check whether the previous interrupt requested a deferred check. If
not, we request a deferred check for the next hardware interrupt and
return.

If set, we check whether one of the interrupt threads signaled
success. Depending on this information we feed the result into the
spurious detector.

If one primary handler of a shared interrupt returns IRQ_HANDLED we
disable the deferred check of irq threads on the same line, as we have
found at least one device driver who cared.

Reported-by: Till Straumann &lt;strauman@slac.stanford.edu&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Austin Schuh &lt;austin@peloton-tech.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Cc: Pavel Pisa &lt;pisa@cmp.felk.cvut.cz&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: linux-can@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>lib/lzo: Update LZO compression to current upstream version</title>
<updated>2014-06-26T19:10:29+00:00</updated>
<author>
<name>Markus F.X.J. Oberhumer</name>
<email>markus@oberhumer.com</email>
</author>
<published>2012-08-13T15:25:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39085c8966f550d4b39d18683e39e79be7660a72'/>
<id>urn:sha1:39085c8966f550d4b39d18683e39e79be7660a72</id>
<content type='text'>
commit 8b975bd3f9089f8ee5d7bbfd798537b992bbc7e7 upstream.

This commit updates the kernel LZO code to the current upsteam version
which features a significant speed improvement - benchmarking the Calgary
and Silesia test corpora typically shows a doubled performance in
both compression and decompression on modern i386/x86_64/powerpc machines.

Signed-off-by: Markus F.X.J. Oberhumer &lt;markus@oberhumer.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: control: Protect user controls against concurrent access</title>
<updated>2014-06-26T19:10:29+00:00</updated>
<author>
<name>Lars-Peter Clausen</name>
<email>lars@metafoo.de</email>
</author>
<published>2014-06-18T11:32:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e4036860a70f956370a18ef06a19fa10a25990d2'/>
<id>urn:sha1:e4036860a70f956370a18ef06a19fa10a25990d2</id>
<content type='text'>
commit 07f4d9d74a04aa7c72c5dae0ef97565f28f17b92 upstream.

The user-control put and get handlers as well as the tlv do not protect against
concurrent access from multiple threads. Since the state of the control is not
updated atomically it is possible that either two write operations or a write
and a read operation race against each other. Both can lead to arbitrary memory
disclosure. This patch introduces a new lock that protects user-controls from
concurrent access. Since applications typically access controls sequentially
than in parallel a single lock per card should be fine.

Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Acked-by: Jaroslav Kysela &lt;perex@perex.cz&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>team: fix mtu setting</title>
<updated>2014-06-26T19:10:28+00:00</updated>
<author>
<name>Jiri Pirko</name>
<email>jiri@resnulli.us</email>
</author>
<published>2014-05-29T18:46:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=843c0172bce9a30d77c85f33268b1469ead716ad'/>
<id>urn:sha1:843c0172bce9a30d77c85f33268b1469ead716ad</id>
<content type='text'>
[ Upstream commit 9d0d68faea6962d62dd501cd6e71ce5cc8ed262b ]

Now it is not possible to set mtu to team device which has a port
enslaved to it. The reason is that when team_change_mtu() calls
dev_set_mtu() for port device, notificator for NETDEV_PRECHANGEMTU
event is called and team_device_event() returns NOTIFY_BAD forbidding
the change. So fix this by returning NOTIFY_DONE here in case team is
changing mtu in team_change_mtu().

Introduced-by: 3d249d4c "net: introduce ethernet teaming device"
Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Acked-by: Flavio Leitner &lt;fbl@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>net: fix inet_getid() and ipv6_select_ident() bugs</title>
<updated>2014-06-26T19:10:28+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-05-29T15:45:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0a4474aaad97472efcd10a3e8d897d5798206f0e'/>
<id>urn:sha1:0a4474aaad97472efcd10a3e8d897d5798206f0e</id>
<content type='text'>
[ Upstream commit 39c36094d78c39e038c1e499b2364e13bce36f54 ]

I noticed we were sending wrong IPv4 ID in TCP flows when MTU discovery
is disabled.
Note how GSO/TSO packets do not have monotonically incrementing ID.

06:37:41.575531 IP (id 14227, proto: TCP (6), length: 4396)
06:37:41.575534 IP (id 14272, proto: TCP (6), length: 65212)
06:37:41.575544 IP (id 14312, proto: TCP (6), length: 57972)
06:37:41.575678 IP (id 14317, proto: TCP (6), length: 7292)
06:37:41.575683 IP (id 14361, proto: TCP (6), length: 63764)

It appears I introduced this bug in linux-3.1.

inet_getid() must return the old value of peer-&gt;ip_id_count,
not the new one.

Lets revert this part, and remove the prevention of
a null identification field in IPv6 Fragment Extension Header,
which is dubious and not even done properly.

Fixes: 87c48fa3b463 ("ipv6: make fragment identifications less predictable")
Signed-off-by: Eric Dumazet &lt;edumazet@google.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>
</feed>
