<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v4.1.13</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.1.13</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.1.13'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2015-11-09T22:34:10+00:00</updated>
<entry>
<title>Linux 4.1.13</title>
<updated>2015-11-09T22:34:10+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2015-11-09T22:34:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1f2ce4a2e7aea3a2123b17aff62a80553df31e21'/>
<id>urn:sha1:1f2ce4a2e7aea3a2123b17aff62a80553df31e21</id>
<content type='text'>
</content>
</entry>
<entry>
<title>dts: imx6: fix sd card gpio polarity specified in device tree</title>
<updated>2015-11-09T22:33:40+00:00</updated>
<author>
<name>Dong Aisheng</name>
<email>aisheng.dong@freescale.com</email>
</author>
<published>2015-07-22T12:53:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=50eda1546d87542d21eb5a69caf4f046a4bb416e'/>
<id>urn:sha1:50eda1546d87542d21eb5a69caf4f046a4bb416e</id>
<content type='text'>
commit 89c1a8cf63f8c69dfddb6e377c04df8b25ab1c88 upstream.

cd-gpios polarity should be changed to GPIO_ACTIVE_LOW and wp-gpios
should be changed to GPIO_ACTIVE_HIGH.
Otherwise, the SD may not work properly due to wrong polarity inversion
specified in DT after switch to common parsing function mmc_of_parse().

Signed-off-by: Dong Aisheng &lt;aisheng.dong@freescale.com&gt;
Acked-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xen: fix backport of previous kexec patch</title>
<updated>2015-11-09T22:33:40+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2015-11-06T19:07:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e4338aeff6aab3640c2925844f4e5e53746cd3d9'/>
<id>urn:sha1:e4338aeff6aab3640c2925844f4e5e53746cd3d9</id>
<content type='text'>
Fixes the backport of 0b34a166f291d255755be46e43ed5497cdd194f2 upstream

Commit 0b34a166f291d255755be46e43ed5497cdd194f2 "x86/xen: Support
kexec/kdump in HVM guests by doing a soft reset" has been added to the
4.2-stable tree" needed to correct the CONFIG variable, as
CONFIG_KEXEC_CORE only showed up in 4.3.

Reported-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Reported-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: 8250_pci: Add support for 12 port Exar boards</title>
<updated>2015-11-09T22:33:40+00:00</updated>
<author>
<name>Soeren Grunewald</name>
<email>soeren.grunewald@desy.de</email>
</author>
<published>2015-06-11T07:25:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cdfdd2ea3f8a5e80f7a350ee08b2d6fef0c6db0f'/>
<id>urn:sha1:cdfdd2ea3f8a5e80f7a350ee08b2d6fef0c6db0f</id>
<content type='text'>
commit be32c0cf0462c36f482b5ddcff1d8371be1e183c upstream.

The Exar XR17V358 can also be combined with a XR17V354 chip to act as a
single 12 port chip. This works the same way as the combining two XR17V358
chips. But the reported device id then is 0x4358.

Signed-off-by: Soeren Grunewald &lt;soeren.grunewald@desy.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>pinctrl: baytrail: Use raw_spinlock for locking</title>
<updated>2015-11-09T22:33:40+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2015-08-17T13:03:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=709adbf08f54b646159c3524144dfb09af59b8cb'/>
<id>urn:sha1:709adbf08f54b646159c3524144dfb09af59b8cb</id>
<content type='text'>
commit 78e1c896932df5b8bcdff7bf5417d8e72a4d0d6b upstream.

The Intel Baytrail pinctrl driver implements irqchip callbacks which are
called with desc-&gt;lock raw_spinlock held. In mainline this is fine because
spinlock resolves to raw_spinlock. However, running the same code in -rt we
get:

 BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
 Preemption disabled at:[&lt;ffffffff81092e9f&gt;] cpu_startup_entry+0x17f/0x480

 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #13
  ...
 Call Trace:
  &lt;IRQ&gt;  [&lt;ffffffff816283c6&gt;] dump_stack+0x4a/0x61
  [&lt;ffffffff81077e17&gt;] ___might_sleep+0xe7/0x170
  [&lt;ffffffff8162d6cf&gt;] rt_spin_lock+0x1f/0x50
  [&lt;ffffffff812e3b88&gt;] byt_gpio_clear_triggering+0x38/0x60
  [&lt;ffffffff812e3bc1&gt;] byt_irq_mask+0x11/0x20
  [&lt;ffffffff810a7013&gt;] handle_level_irq+0x83/0x150
  [&lt;ffffffff810a3457&gt;] generic_handle_irq+0x27/0x40
  [&lt;ffffffff812e3a5f&gt;] byt_gpio_irq_handler+0x7f/0xc0
  [&lt;ffffffff810050aa&gt;] handle_irq+0xaa/0x190
  ...

This is because in -rt spinlocks are preemptible so taking the driver
private spinlock in irqchip callbacks causes might_sleep() to trigger.

In order to keep -rt happy but at the same time make sure that register
accesses get serialized, convert the driver to use raw_spinlock instead.

Also shorten the critical section a bit in few places.

Suggested-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: Lucas De Marchi &lt;lucas.de.marchi@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>pinctrl: baytrail: Serialize all register access</title>
<updated>2015-11-09T22:33:40+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2015-08-04T12:03:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b4744eee459a9c521e538907ee822318e9b303e'/>
<id>urn:sha1:7b4744eee459a9c521e538907ee822318e9b303e</id>
<content type='text'>
commit 39ce8150a079e3ae6ed9abf26d7918a558ef7c19 upstream.

There is a hardware issue in Intel Baytrail where concurrent GPIO register
access might result reads of 0xffffffff and writes might get dropped
completely.

Prevent this from happening by taking the serializing lock in all places
where it is possible that more than one thread might be accessing the
hardware concurrently.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: Lucas De Marchi &lt;lucas.de.marchi@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>thp: use is_zero_pfn() only after pte_present() check</title>
<updated>2015-11-09T22:33:39+00:00</updated>
<author>
<name>Minchan Kim</name>
<email>minchan@kernel.org</email>
</author>
<published>2015-10-22T20:32:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc14f050d2a7bd60b32179f842a72e376cfd467b'/>
<id>urn:sha1:dc14f050d2a7bd60b32179f842a72e376cfd467b</id>
<content type='text'>
commit 47aee4d8e314384807e98b67ade07f6da476aa75 upstream.

Use is_zero_pfn() on pteval only after pte_present() check on pteval
(It might be better idea to introduce is_zero_pte() which checks
pte_present() first).

Otherwise when working on a swap or migration entry and if pte_pfn's
result is equal to zero_pfn by chance, we lose user's data in
__collapse_huge_page_copy().  So if you're unlucky, the application
segfaults and finally you could see below message on exit:

BUG: Bad rss-counter state mm:ffff88007f099300 idx:2 val:3

Fixes: ca0984caa823 ("mm: incorporate zero pages into transparent huge pages")
Signed-off-by: Minchan Kim &lt;minchan@kernel.org&gt;
Reviewed-by: Andrea Arcangeli &lt;aarcange@redhat.com&gt;
Acked-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Mel Gorman &lt;mgorman@suse.de&gt;
Acked-by: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Hugh Dickins &lt;hughd@google.com&gt;
Cc: Rik van Riel &lt;riel@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@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>drm/vmwgfx: Fix up user_dmabuf refcounting</title>
<updated>2015-11-09T22:33:39+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2015-09-14T08:13:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=435d5d7f3a0dd62dc1465c314e338f159fb7d43a'/>
<id>urn:sha1:435d5d7f3a0dd62dc1465c314e338f159fb7d43a</id>
<content type='text'>
commit 54c12bc374408faddbff75dbf1a6167c19af39c4 upstream.

If user space calls unreference on a user_dmabuf it will typically
kill the struct ttm_base_object member which is responsible for the
user-space visibility. However the dmabuf part may still be alive and
refcounted. In some situations, like for shared guest-backed surface
referencing/opening, the driver may try to reference the
struct ttm_base_object member again, causing an immediate kernel warning
and a later kernel NULL pointer dereference.

Fix this by always maintaining a reference on the struct
ttm_base_object member, in situations where it might subsequently be
referenced.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Brian Paul &lt;brianp@vmware.com&gt;
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NVMe: Fix memory leak on retried commands</title>
<updated>2015-11-09T22:33:39+00:00</updated>
<author>
<name>Keith Busch</name>
<email>keith.busch@intel.com</email>
</author>
<published>2015-10-15T19:38:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a1638a11d9fb9457a8a5a9cc1a00e59ca56c8fe3'/>
<id>urn:sha1:a1638a11d9fb9457a8a5a9cc1a00e59ca56c8fe3</id>
<content type='text'>
commit 0dfc70c33409afc232ef0b9ec210535dfbf9bc61 upstream.

Resources are reallocated for requeued commands, so unmap and release
the iod for the failed command.

It's a pretty bad memory leak and causes a kernel hang if you remove a
drive because of a busy dma pool. You'll get messages spewing like this:

  nvme 0000:xx:xx.x: dma_pool_destroy prp list 256, ffff880420dec000 busy

and lock up pci and the driver since removal never completes while
holding a lock.

Signed-off-by: Keith Busch &lt;keith.busch@intel.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>arm64: compat: fix stxr failure case in SWP emulation</title>
<updated>2015-11-09T22:33:39+00:00</updated>
<author>
<name>Will Deacon</name>
<email>will.deacon@arm.com</email>
</author>
<published>2015-10-15T12:55:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=599f528a90026dd61533aa5145e64cc0ac3625ae'/>
<id>urn:sha1:599f528a90026dd61533aa5145e64cc0ac3625ae</id>
<content type='text'>
commit 589cb22bbedacf325951014c07a35a2b01ca57f6 upstream.

If the STXR instruction fails in the SWP emulation code, we leave *data
overwritten with the loaded value, therefore corrupting the data written
by a subsequent, successful attempt.

This patch re-jigs the code so that we only write back to *data once we
know that the update has happened.

Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Reported-by: Shengjiu Wang &lt;shengjiu.wang@freescale.com&gt;
Reported-by: Vladimir Murzin &lt;vladimir.murzin@arm.com&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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