<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v3.10.83</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.83</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.83'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2015-07-04T02:48:19Z</updated>
<entry>
<title>Linux 3.10.83</title>
<updated>2015-07-04T02:48:19Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2015-07-04T02:48:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c48465423908a8955cd6de09b871161324cf5205'/>
<id>urn:sha1:c48465423908a8955cd6de09b871161324cf5205</id>
<content type='text'>
</content>
</entry>
<entry>
<title>bus: mvebu: pass the coherency availability information at init time</title>
<updated>2015-07-04T02:48:09Z</updated>
<author>
<name>Greg Ungerer</name>
<email>gerg@uclinux.org</email>
</author>
<published>2014-04-14T13:47:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2667677fb84b4b92e31573f2f2ffaec7a8772747'/>
<id>urn:sha1:2667677fb84b4b92e31573f2f2ffaec7a8772747</id>
<content type='text'>
commit 5686a1e5aa436c49187a60052d5885fb1f541ce6 upstream.

Until now, the mvebu-mbus was guessing by itself whether hardware I/O
coherency was available or not by poking into the Device Tree to see
if the coherency fabric Device Tree node was present or not.

However, on some upcoming SoCs, the presence or absence of the
coherency fabric DT node isn't sufficient: in CONFIG_SMP, the
coherency can be enabled, but not in !CONFIG_SMP.

In order to clean this up, the mvebu_mbus_dt_init() function is
extended to get a boolean argument telling whether coherency is
enabled or not. Therefore, the logic to decide whether coherency is
available or not now belongs to the core SoC code instead of the
mvebu-mbus driver itself, which is much better.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Link: https://lkml.kernel.org/r/1397483228-25625-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;

[ Greg Ungerer: back ported to linux-3.10.y
  Back port necessary due to large code differences in affected files.
  This change in combination with commit e553554536 ("ARM: mvebu: disable
  I/O coherency on non-SMP situations on Armada 370/375/38x/XP") is
  critical to the hardware I/O coherency being set correctly by both the
  mbus driver and all peripheral hardware drivers. Without this change
  drivers will incorrectly enable I/O coherency window attributes and
  this causes rare unreliable system behavior including oops. ]

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: nSVM: Check for NRIPS support before updating control field</title>
<updated>2015-07-04T02:48:09Z</updated>
<author>
<name>Bandan Das</name>
<email>bsd@redhat.com</email>
</author>
<published>2015-06-11T06:05:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ea0d66be1c27f55825a80d01ad1ff72f6e005c29'/>
<id>urn:sha1:ea0d66be1c27f55825a80d01ad1ff72f6e005c29</id>
<content type='text'>
commit f104765b4f81fd74d69e0eb161e89096deade2db upstream.

If hardware doesn't support DecodeAssist - a feature that provides
more information about the intercept in the VMCB, KVM decodes the
instruction and then updates the next_rip vmcb control field.
However, NRIP support itself depends on cpuid Fn8000_000A_EDX[NRIPS].
Since skip_emulated_instruction() doesn't verify nrip support
before accepting control.next_rip as valid, avoid writing this
field if support isn't present.

Signed-off-by: Bandan Das &lt;bsd@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: clk-imx6q: refine sata's parent</title>
<updated>2015-07-04T02:48:09Z</updated>
<author>
<name>Sebastien Szymanski</name>
<email>sebastien.szymanski@armadeus.com</email>
</author>
<published>2015-05-20T14:30:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4cae4bbc1a8f5258a986801d72678752f9075a64'/>
<id>urn:sha1:4cae4bbc1a8f5258a986801d72678752f9075a64</id>
<content type='text'>
commit da946aeaeadcd24ff0cda9984c6fb8ed2bfd462a upstream.

According to IMX6D/Q RM, table 18-3, sata clock's parent is ahb, not ipg.

Signed-off-by: Sebastien Szymanski &lt;sebastien.szymanski@armadeus.com&gt;
Reviewed-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
Signed-off-by: Shawn Guo &lt;shawn.guo@linaro.org&gt;
[dirk.behme: Adjust moved file]
Signed-off-by: Dirk Behme &lt;dirk.behme@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>d_walk() might skip too much</title>
<updated>2015-07-04T02:48:09Z</updated>
<author>
<name>Jari Ruusu</name>
<email>jariruusu@users.sourceforge.net</email>
</author>
<published>2015-06-13T16:01:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b93e0acc5001b80153cb0c7efcdcc53cc56aac4a'/>
<id>urn:sha1:b93e0acc5001b80153cb0c7efcdcc53cc56aac4a</id>
<content type='text'>
When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".

3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.

The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.

Signed-off-by: Jari Ruusu &lt;jariruusu@users.sourceforge.net&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipv6: update ip6_rt_last_gc every time GC is run</title>
<updated>2015-07-04T02:48:09Z</updated>
<author>
<name>Michal Kubeček</name>
<email>mkubecek@suse.cz</email>
</author>
<published>2013-08-01T08:04:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c1e1eb159efadf28f0da0de550d696abdb30aefc'/>
<id>urn:sha1:c1e1eb159efadf28f0da0de550d696abdb30aefc</id>
<content type='text'>
commit 49a18d86f66d33a20144ecb5a34bba0d1856b260 upstream.

As pointed out by Eric Dumazet, net-&gt;ipv6.ip6_rt_last_gc should
hold the last time garbage collector was run so that we should
update it whenever fib6_run_gc() calls fib6_clean_all(), not only
if we got there from ip6_dst_gc().

Signed-off-by: Michal Kubecek &lt;mkubecek@suse.cz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Konstantin Khlebnikov &lt;khlebnikov@yandex-team.ru&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipv6: prevent fib6_run_gc() contention</title>
<updated>2015-07-04T02:48:09Z</updated>
<author>
<name>Michal Kubeček</name>
<email>mkubecek@suse.cz</email>
</author>
<published>2013-08-01T08:04:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ba310bc86f54169bf4ec414683bd61dcd2f8675f'/>
<id>urn:sha1:ba310bc86f54169bf4ec414683bd61dcd2f8675f</id>
<content type='text'>
commit 2ac3ac8f86f2fe065d746d9a9abaca867adec577 upstream.

On a high-traffic router with many processors and many IPv6 dst
entries, soft lockup in fib6_run_gc() can occur when number of
entries reaches gc_thresh.

This happens because fib6_run_gc() uses fib6_gc_lock to allow
only one thread to run the garbage collector but ip6_dst_gc()
doesn't update net-&gt;ipv6.ip6_rt_last_gc until fib6_run_gc()
returns. On a system with many entries, this can take some time
so that in the meantime, other threads pass the tests in
ip6_dst_gc() (ip6_rt_last_gc is still not updated) and wait for
the lock. They then have to run the garbage collector one after
another which blocks them for quite long.

Resolve this by replacing special value ~0UL of expire parameter
to fib6_run_gc() by explicit "force" parameter to choose between
spin_lock_bh() and spin_trylock_bh() and call fib6_run_gc() with
force=false if gc_thresh is reached but not max_size.

Signed-off-by: Michal Kubecek &lt;mkubecek@suse.cz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Konstantin Khlebnikov &lt;khlebnikov@yandex-team.ru&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xfrm: Increase the garbage collector threshold</title>
<updated>2015-07-04T02:48:09Z</updated>
<author>
<name>Steffen Klassert</name>
<email>steffen.klassert@secunet.com</email>
</author>
<published>2013-10-25T08:21:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=528555d05bde69c436bb0126ea95635da24d889e'/>
<id>urn:sha1:528555d05bde69c436bb0126ea95635da24d889e</id>
<content type='text'>
commit eeb1b73378b560e00ff1da2ef09fed9254f4e128 upstream.

With the removal of the routing cache, we lost the
option to tweak the garbage collector threshold
along with the maximum routing cache size. So git
commit 703fb94ec ("xfrm: Fix the gc threshold value
for ipv4") moved back to a static threshold.

It turned out that the current threshold before we
start garbage collecting is much to small for some
workloads, so increase it from 1024 to 32768. This
means that we start the garbage collector if we have
more than 32768 dst entries in the system and refuse
new allocations if we are above 65536.

Reported-by: Wolfgang Walter &lt;linux@stwm.de&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
Cc: Stephen Hemminger &lt;shemming@brocade.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Btrfs: make xattr replace operations atomic</title>
<updated>2015-07-04T02:48:09Z</updated>
<author>
<name>Filipe Manana</name>
<email>fdmanana@suse.com</email>
</author>
<published>2014-11-09T08:38:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=43f2e3615d181a7028ab797114c5960977669b2a'/>
<id>urn:sha1:43f2e3615d181a7028ab797114c5960977669b2a</id>
<content type='text'>
commit 5f5bc6b1e2d5a6f827bc860ef2dc5b6f365d1339 upstream.

Replacing a xattr consists of doing a lookup for its existing value, delete
the current value from the respective leaf, release the search path and then
finally insert the new value. This leaves a time window where readers (getxattr,
listxattrs) won't see any value for the xattr. Xattrs are used to store ACLs,
so this has security implications.

This change also fixes 2 other existing issues which were:

*) Deleting the old xattr value without verifying first if the new xattr will
   fit in the existing leaf item (in case multiple xattrs are packed in the
   same item due to name hash collision);

*) Returning -EEXIST when the flag XATTR_CREATE is given and the xattr doesn't
   exist but we have have an existing item that packs muliple xattrs with
   the same name hash as the input xattr. In this case we should return ENOSPC.

A test case for xfstests follows soon.

Thanks to Alexandre Oliva for reporting the non-atomicity of the xattr replace
implementation.

Reported-by: Alexandre Oliva &lt;oliva@gnu.org&gt;
Signed-off-by: Filipe Manana &lt;fdmanana@suse.com&gt;
Signed-off-by: Chris Mason &lt;clm@fb.com&gt;
[shengyong: backport to 3.10
 - FIX: CVE-2014-9710
 - adjust context
 - ASSERT() was added v3.12, so we do check with if statement
 - set the first parameter of btrfs_item_nr() as NULL, because it is not
   used, and is removed in v3.13
]
Signed-off-by: Sheng Yong &lt;shengyong1@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>x86/microcode/intel: Guard against stack overflow in the loader</title>
<updated>2015-07-04T02:48:09Z</updated>
<author>
<name>Quentin Casasnovas</name>
<email>quentin.casasnovas@oracle.com</email>
</author>
<published>2015-02-03T12:00:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=66bd44e6a5c8f24805f94d19f943301d7a7f418e'/>
<id>urn:sha1:66bd44e6a5c8f24805f94d19f943301d7a7f418e</id>
<content type='text'>
commit f84598bd7c851f8b0bf8cd0d7c3be0d73c432ff4 upstream.

mc_saved_tmp is a static array allocated on the stack, we need to make
sure mc_saved_count stays within its bounds, otherwise we're overflowing
the stack in _save_mc(). A specially crafted microcode header could lead
to a kernel crash or potentially kernel execution.

Signed-off-by: Quentin Casasnovas &lt;quentin.casasnovas@oracle.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Link: http://lkml.kernel.org/r/1422964824-22056-1-git-send-email-quentin.casasnovas@oracle.com
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Signed-off-by: Sheng Yong &lt;shengyong1@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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