linux-stable.git/include/linux, branch v4.1.4

nfs: increase size of EXCHANGE_ID name string buffer

2015-08-03T16:29:17+00:00

commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 upstream.

The current buffer is much too small if you have a relatively long
hostname. Bring it up to the size of the one that SETCLIENTID has.

Reported-by: Michael Skralivetsky 
Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

gpiolib: Add missing dummies for the unified device properties interface

2015-08-03T16:29:17+00:00

commit 496e7ce2a46562938edcb74f65b26068ee8895f6 upstream.

If GPIOLIB=n:

    drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’:
    drivers/leds/leds-gpio.c:187: error: implicit declaration of function ‘devm_get_gpiod_from_child’
    drivers/leds/leds-gpio.c:187: warning: assignment makes pointer from integer without a cast

Add dummies for fwnode_get_named_gpiod() and devm_get_gpiod_from_child()
for the !GPIOLIB case to fix this.

Signed-off-by: Geert Uytterhoeven 
Fixes: 40b7318319281b1b ("gpio: Support for unified device properties interface")
Acked-by: Alexandre Courbot 
Acked-by: Linus Walleij 
Signed-off-by: Bryan Wu 
Signed-off-by: Greg Kroah-Hartman

of: return NUMA_NO_NODE from fallback of_node_to_nid()

2015-08-03T16:29:16+00:00

commit c8fff7bc5bba6bd59cad40441c189c4efe7190f6 upstream.

Node 0 might be offline as well as any other numa node,
in this case kernel cannot handle memory allocation and crashes.

Signed-off-by: Konstantin Khlebnikov 
Fixes: 0c3f061c195c ("of: implement of_node_to_nid as a weak function")
Signed-off-by: Grant Likely 
Signed-off-by: Greg Kroah-Hartman

compiler-intel: fix wrong compiler barrier() macro

2015-08-03T16:29:15+00:00

commit b86a50c3b5414eafdbee7f34af4a201a4a7817c2 upstream.

Cleanup commit 73679e508201 ("compiler-intel.h: Remove duplicate
definition") removed the double definition of __memory_barrier()
intrinsics.

However, in doing so, it also removed the preceding #undef barrier by
accident, meaning, the actual barrier() macro from compiler-gcc.h with
inline asm is still in place as __GNUC__ is provided.

Subsequently, barrier() can never be defined as __memory_barrier() from
compiler.h since it already has a definition in place and if we trust
the comment in compiler-intel.h, ecc doesn't support gcc specific asm
statements.

I don't have an ecc at hand (unsure if that's still used in the field?)
and only found this by accident during code review, a revert of that
cleanup would be simplest option.

Fixes: 73679e508201 ("compiler-intel.h: Remove duplicate definition")
Signed-off-by: Daniel Borkmann 
Reviewed-by: Pranith Kumar 
Cc: Pranith Kumar 
Cc: H. Peter Anvin 
Cc: mancha security 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage

2015-08-03T16:29:14+00:00

commit 0294112ee3135fbd15eaa70015af8283642dd970 upstream.

This effectively reverts the following three commits:

 7bc10388ccdd ACPI / resources: free memory on error in add_region_before()
 0f1b414d1907 ACPI / PNP: Avoid conflicting resource reservations
 b9a5e5e18fbf ACPI / init: Fix the ordering of acpi_reserve_resources()

(commit b9a5e5e18fbf introduced regressions some of which, but not
all, were addressed by commit 0f1b414d1907 and commit 7bc10388ccdd
was a fixup on top of the latter) and causes ACPI fixed hardware
resources to be reserved at the fs_initcall_sync stage of system
initialization.

The story is as follows.  First, a boot regression was reported due
to an apparent resource reservation ordering change after a commit
that shouldn't lead to such changes.  Investigation led to the
conclusion that the problem happened because acpi_reserve_resources()
was executed at the device_initcall() stage of system initialization
which wasn't strictly ordered with respect to driver initialization
(and with respect to the initialization of the pcieport driver in
particular), so a random change causing the device initcalls to be
run in a different order might break things.

The response to that was to attempt to run acpi_reserve_resources()
as soon as we knew that ACPI would be in use (commit b9a5e5e18fbf).
However, that turned out to be too early, because it caused resource
reservations made by the PNP system driver to fail on at least one
system and that failure was addressed by commit 0f1b414d1907.

That fix still turned out to be insufficient, though, because
calling acpi_reserve_resources() before the fs_initcall stage of
system initialization caused a boot regression to happen on the
eCAFE EC-800-H20G/S netbook.  That meant that we only could call
acpi_reserve_resources() at the fs_initcall initialization stage
or later, but then we might just as well call it after the PNP
initalization in which case commit 0f1b414d1907 wouldn't be
necessary any more.

For this reason, the changes made by commit 0f1b414d1907 are reverted
(along with a memory leak fixup on top of that commit), the changes
made by commit b9a5e5e18fbf that went too far are reverted too and
acpi_reserve_resources() is changed into fs_initcall_sync, which
will cause it to be executed after the PNP subsystem initialization
(which is an fs_initcall) and before device initcalls (including
the pcieport driver initialization) which should avoid the initial
issue.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581
Link: http://marc.info/?t=143092384600002&r=1&w=2
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
Link: http://marc.info/?t=143389402600001&r=1&w=2
Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
Reported-by: Roland Dreier 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

libata: add ATA_HORKAGE_MAX_SEC_1024 to revert back to previous max_sectors limit

2015-08-03T16:29:04+00:00

commit af34d637637eabaf49406eb35c948cd51ba262a6 upstream.

Since no longer limiting max_sectors to BLK_DEF_MAX_SECTORS (commit 34b48db66e08),
data corruption may occur on ST380013AS drive configured on 82801JI (ICH10 Family)
SATA controller. This patch will allow the driver to limit max_sectors as before

 # cat /sys/block/sdb/queue/max_sectors_kb
 512

I was able to double the max_sectors_kb value up to 16384 on linux-4.2.0-rc2
before seeing corruption, but seems safer to use previous limit. Without this
patch max_sectors_kb will be 32767.

tj: Minor comment update.

Reported-by: Jeff Moyer 
Signed-off-by: David Milburn 
Signed-off-by: Tejun Heo 
Fixes: 34b48db66e08 ("block: remove artifical max_hw_sectors cap")
Signed-off-by: Greg Kroah-Hartman

libata: add ATA_HORKAGE_NOTRIM

2015-08-03T16:29:04+00:00

commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 upstream.

Some devices lose data on TRIM whether queued or not.  This patch adds
a horkage to disable TRIM.

tj: Collapsed unnecessary if() nesting.

Signed-off-by: Arne Fitzenreiter 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

libata: Fall back to unqueued READ LOG EXT if the DMA variant fails

2015-08-03T16:29:04+00:00

commit 5d3abf8ff67f49271a42c0f7fa4f20f9e046bf0e upstream.

Some devices advertise support for the READ/WRITE LOG DMA EXT commands
but fail when we try to issue them. This can lead to queued TRIM being
unintentionally disabled since the relevant feature flag is located in a
general purpose log page.

Fall back to unqueued READ LOG EXT if the DMA variant fails while
reading a log page.

Signed-off-by: Martin K. Petersen 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

jbd2: fix ocfs2 corrupt when updating journal superblock fails

2015-08-03T16:29:00+00:00

commit 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a upstream.

If updating journal superblock fails after journal data has been
flushed, the error is omitted and this will mislead the caller as a
normal case.  In ocfs2, the checkpoint will be treated successfully
and the other node can get the lock to update. Since the sb_start is
still pointing to the old log block, it will rewrite the journal data
during journal recovery by the other node. Thus the new updates will
be overwritten and ocfs2 corrupts.  So in above case we have to return
the error, and ocfs2_commit_cache will take care of the error and
prevent the other node to do update first.  And only after recovering
journal it can do the new updates.

The issue discussion mail can be found at:
https://oss.oracle.com/pipermail/ocfs2-devel/2015-June/010856.html
http://comments.gmane.org/gmane.comp.file-systems.ext4/48841

[ Fixed bug in patch which allowed a non-negative error return from
  jbd2_cleanup_journal_tail() to leak out of jbd2_fjournal_flush(); this
  was causing xfstests ext4/306 to fail. -- Ted ]

Reported-by: Yiwen Jiang 
Signed-off-by: Joseph Qi 
Signed-off-by: Theodore Ts'o 
Tested-by: Yiwen Jiang 
Cc: Junxiao Bi 
Signed-off-by: Greg Kroah-Hartman

bufferhead: Add _gfp version for sb_getblk()

2015-08-03T16:29:00+00:00

commit bd7ade3cd9b0850264306f5c2b79024a417b6396 upstream.

sb_getblk() is used during ext4 (and possibly other FSes) writeback
paths. Sometimes such path require allocating memory and guaranteeing
that such allocation won't block. Currently, however, there is no way
to provide user flags for sb_getblk which could lead to deadlocks.

This patch implements a sb_getblk_gfp with the only difference it can
accept user-provided GFP flags.

Signed-off-by: Nikolay Borisov 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman