<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include, branch v3.12.9</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include?h=v3.12.9</id>
<link rel='self' href='https://git.amat.us/linux/atom/include?h=v3.12.9'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-01-25T16:49:29Z</updated>
<entry>
<title>mm: Make {,set}page_address() static inline if WANT_PAGE_VIRTUAL</title>
<updated>2014-01-25T16:49:29Z</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2014-01-21T23:48:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1a912f30eff840b2509762f91f2eaf5769211920'/>
<id>urn:sha1:1a912f30eff840b2509762f91f2eaf5769211920</id>
<content type='text'>
commit f92f455f67fef27929e6043499414605b0c94872 upstream.

{,set}page_address() are macros if WANT_PAGE_VIRTUAL.  If
!WANT_PAGE_VIRTUAL, they're plain C functions.

If someone calls them with a void *, this pointer is auto-converted to
struct page * if !WANT_PAGE_VIRTUAL, but causes a build failure on
architectures using WANT_PAGE_VIRTUAL (arc, m68k and sparc64):

  drivers/md/bcache/bset.c: In function `__btree_sort':
  drivers/md/bcache/bset.c:1190: warning: dereferencing `void *' pointer
  drivers/md/bcache/bset.c:1190: error: request for member `virtual' in something not a structure or union

Convert them to static inline functions to fix this.  There are already
plenty of users of struct page members inside &lt;linux/mm.h&gt;, so there's
no reason to keep them as macros.

Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: David Rientjes &lt;rientjes@google.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>crash_dump: fix compilation error (on MIPS at least)</title>
<updated>2014-01-25T16:49:29Z</updated>
<author>
<name>Qais Yousef</name>
<email>qais.yousef@imgtec.com</email>
</author>
<published>2014-01-15T01:56:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a453460c57a0b2dcb3c030a35fcbc2c4110f5624'/>
<id>urn:sha1:a453460c57a0b2dcb3c030a35fcbc2c4110f5624</id>
<content type='text'>
commit 5a610fcc7390ee60308deaf09426ada87a1eeec2 upstream.

  In file included from kernel/crash_dump.c:2:0:
  include/linux/crash_dump.h:22:27: error: unknown type name `pgprot_t'

when CONFIG_CRASH_DUMP=y

The error was traced back to commit 9cb218131de1 ("vmcore: introduce
remap_oldmem_pfn_range()")

include &lt;asm/pgtable.h&gt; to get the missing definition

Signed-off-by: Qais Yousef &lt;qais.yousef@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Michael Holzheu &lt;holzheu@linux.vnet.ibm.com&gt;
Acked-by: Vivek Goyal &lt;vgoyal@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>i2c: Re-instate body of i2c_parent_is_i2c_adapter()</title>
<updated>2014-01-25T16:49:28Z</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2014-01-13T21:29:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ae117c4f7fda2f451122d1591b74ffd0a875907c'/>
<id>urn:sha1:ae117c4f7fda2f451122d1591b74ffd0a875907c</id>
<content type='text'>
commit 2fac2b891f287691c27ee8d2eeecf39571b27fea upstream.

The body of i2c_parent_is_i2c_adapter() is currently guarded by
I2C_MUX. It should be CONFIG_I2C_MUX instead.

Among potentially other problems, this resulted in i2c_lock_adapter()
only locking I2C mux child adapters, and not the parent adapter. In
turn, this could allow inter-mingling of mux child selection and I2C
transactions, which could result in I2C transactions being directed to
the wrong I2C bus, and possibly even switching between busses in the
middle of a transaction.

One concrete issue caused by this bug was corrupted HDMI EDID reads
during boot on the NVIDIA Tegra Seaboard system, although this only
became apparent in recent linux-next, when the boot timing was changed
just enough to trigger the race condition.

Fixes: 3923172b3d70 ("i2c: reduce parent checking to a NOOP in non-I2C_MUX case")
Cc: Phil Carmody &lt;phil.carmody@partner.samsung.com&gt;
Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipv4: fix tunneled VM traffic over hw VXLAN/GRE GSO NIC</title>
<updated>2014-01-15T23:31:37Z</updated>
<author>
<name>Wei-Chun Chao</name>
<email>weichunc@plumgrid.com</email>
</author>
<published>2013-12-26T21:10:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b21d217ce4403082908511d0296ee854f30a8014'/>
<id>urn:sha1:b21d217ce4403082908511d0296ee854f30a8014</id>
<content type='text'>
[ Upstream commit 7a7ffbabf99445704be01bff5d7e360da908cf8e ]

VM to VM GSO traffic is broken if it goes through VXLAN or GRE
tunnel and the physical NIC on the host supports hardware VXLAN/GRE
GSO offload (e.g. bnx2x and next-gen mlx4).

Two issues -
(VXLAN) VM traffic has SKB_GSO_DODGY and SKB_GSO_UDP_TUNNEL with
SKB_GSO_TCP/UDP set depending on the inner protocol. GSO header
integrity check fails in udp4_ufo_fragment if inner protocol is
TCP. Also gso_segs is calculated incorrectly using skb-&gt;len that
includes tunnel header. Fix: robust check should only be applied
to the inner packet.

(VXLAN &amp; GRE) Once GSO header integrity check passes, NULL segs
is returned and the original skb is sent to hardware. However the
tunnel header is already pulled. Fix: tunnel header needs to be
restored so that hardware can perform GSO properly on the original
packet.

Signed-off-by: Wei-Chun Chao &lt;weichunc@plumgrid.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>vlan: Fix header ops passthru when doing TX VLAN offload.</title>
<updated>2014-01-15T23:31:37Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2013-12-31T21:23:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=fd661199d7b4c16806f5bb1fcd76798559ba950e'/>
<id>urn:sha1:fd661199d7b4c16806f5bb1fcd76798559ba950e</id>
<content type='text'>
[ Upstream commit 2205369a314e12fcec4781cc73ac9c08fc2b47de ]

When the vlan code detects that the real device can do TX VLAN offloads
in hardware, it tries to arrange for the real device's header_ops to
be invoked directly.

But it does so illegally, by simply hooking the real device's
header_ops up to the VLAN device.

This doesn't work because we will end up invoking a set of header_ops
routines which expect a device type which matches the real device, but
will see a VLAN device instead.

Fix this by providing a pass-thru set of header_ops which will arrange
to pass the proper real device instead.

To facilitate this add a dev_rebuild_header().  There are
implementations which provide a -&gt;cache and -&gt;create but not a
-&gt;rebuild (f.e. PLIP).  So we need a helper function just like
dev_hard_header() to avoid crashes.

Use this helper in the one existing place where the
header_ops-&gt;rebuild was being invoked, the neighbour code.

With lots of help from Florian Westphal.

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>ip_gre: fix msg_name parsing for recvfrom/recvmsg</title>
<updated>2014-01-15T23:31:35Z</updated>
<author>
<name>Timo Teräs</name>
<email>timo.teras@iki.fi</email>
</author>
<published>2013-12-16T09:02:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d6e4f9236bf279e92be402319d57060303d32cfa'/>
<id>urn:sha1:d6e4f9236bf279e92be402319d57060303d32cfa</id>
<content type='text'>
[ Upstream commit 0e3da5bb8da45890b1dc413404e0f978ab71173e ]

ipgre_header_parse() needs to parse the tunnel's ip header and it
uses mac_header to locate the iphdr. This got broken when gre tunneling
was refactored as mac_header is no longer updated to point to iphdr.
Introduce skb_pop_mac_header() helper to do the mac_header assignment
and use it in ipgre_rcv() to fix msg_name parsing.

Bug introduced in commit c54419321455 (GRE: Refactor GRE tunneling code.)

Cc: Pravin B Shelar &lt;pshelar@nicira.com&gt;
Signed-off-by: Timo Teräs &lt;timo.teras@iki.fi&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: unix: allow set_peek_off to fail</title>
<updated>2014-01-15T23:31:34Z</updated>
<author>
<name>Sasha Levin</name>
<email>sasha.levin@oracle.com</email>
</author>
<published>2013-12-07T22:26:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a84305bbc625fac01f8700c26d25c99f4d846c56'/>
<id>urn:sha1:a84305bbc625fac01f8700c26d25c99f4d846c56</id>
<content type='text'>
[ Upstream commit 12663bfc97c8b3fdb292428105dd92d563164050 ]

unix_dgram_recvmsg() will hold the readlock of the socket until recv
is complete.

In the same time, we may try to setsockopt(SO_PEEK_OFF) which will hang until
unix_dgram_recvmsg() will complete (which can take a while) without allowing
us to break out of it, triggering a hung task spew.

Instead, allow set_peek_off to fail, this way userspace will not hang.

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Acked-by: Pavel Emelyanov &lt;xemul@parallels.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>ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug</title>
<updated>2014-01-09T20:25:16Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2013-12-31T12:39:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1ac9b214d81c92fc119c6ffabc21464345eb21e2'/>
<id>urn:sha1:1ac9b214d81c92fc119c6ffabc21464345eb21e2</id>
<content type='text'>
commit f244d8b623dae7a7bc695b0336f67729b95a9736 upstream.

The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
during the 3.12 development cycle uncovered a problem with VGA
switcheroo that on some systems, when the device-specific method
(ATPX in the radeon case, _DSM in the nouveau case) is used to turn
off the discrete graphics, the BIOS generates ACPI hotplug events for
that device and those events cause ACPIPHP to attempt to remove the
device from the system (they are events for a device that was present
previously and is not present any more, so that's what should be done
according to the spec).  Then, the system stops functioning correctly.

Since the hotplug events in question were simply silently ignored
previously, the least intrusive way to address that problem is to
make ACPIPHP ignore them again.  For this purpose, introduce a new
ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
events for PCI devices whose ACPI companions have that flag set.
Next, make the radeon and nouveau switcheroo detection code set the
no_hotplug flag for the discrete graphics' ACPI companion.

Fixes: bbd34fcdd1b2 (ACPI / hotplug / PCI: Register all devices under the given bridge)
References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
References: https://bugzilla.kernel.org/show_bug.cgi?id=64891
Reported-and-tested-by: Mike Lothian &lt;mike@fireburn.co.uk&gt;
Reported-and-tested-by: &lt;madcatx@atlas.cz&gt;
Reported-and-tested-by: Joaquín Aramendía &lt;samsagax@gmail.com&gt;
Cc: Alex Deucher &lt;alexdeucher@gmail.com&gt;
Cc: Dave Airlie &lt;airlied@linux.ie&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>aio/migratepages: make aio migrate pages sane</title>
<updated>2014-01-09T20:25:16Z</updated>
<author>
<name>Benjamin LaHaise</name>
<email>bcrl@kvack.org</email>
</author>
<published>2013-12-21T22:56:08Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2b9a704149ea2a1fe2679ffa2ed7c8d692e2b660'/>
<id>urn:sha1:2b9a704149ea2a1fe2679ffa2ed7c8d692e2b660</id>
<content type='text'>
commit 8e321fefb0e60bae4e2a28d20fc4fa30758d27c6 upstream.

The arbitrary restriction on page counts offered by the core
migrate_page_move_mapping() code results in rather suspicious looking
fiddling with page reference counts in the aio_migratepage() operation.
To fix this, make migrate_page_move_mapping() take an extra_count parameter
that allows aio to tell the code about its own reference count on the page
being migrated.

While cleaning up aio_migratepage(), make it validate that the old page
being passed in is actually what aio_migratepage() expects to prevent
misbehaviour in the case of races.

Signed-off-by: Benjamin LaHaise &lt;bcrl@kvack.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm: numa: guarantee that tlb_flush_pending updates are visible before page table updates</title>
<updated>2014-01-09T20:25:14Z</updated>
<author>
<name>Mel Gorman</name>
<email>mgorman@suse.de</email>
</author>
<published>2014-01-07T14:00:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=186fa6eb6131954d17457f37283e654cb079c25b'/>
<id>urn:sha1:186fa6eb6131954d17457f37283e654cb079c25b</id>
<content type='text'>
commit af2c1401e6f9177483be4fad876d0073669df9df upstream.

According to documentation on barriers, stores issued before a LOCK can
complete after the lock implying that it's possible tlb_flush_pending
can be visible after a page table update.  As per revised documentation,
this patch adds a smp_mb__before_spinlock to guarantee the correct
ordering.

Signed-off-by: Mel Gorman &lt;mgorman@suse.de&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Reviewed-by: 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>
</feed>
