linux.git, branch v3.18.20

Linux 3.18.20

2015-08-07T19:08:04+00:00

Signed-off-by: Sasha Levin

blk-mq: fix CPU hotplug handling

2015-08-06T18:49:50+00:00

[ Upstream commit 2a34c0872adf252f23a6fef2d051a169ac796cef ]

hctx->tags has to be set as NULL in case that it is to be unmapped
no matter if set->tags[hctx->queue_num] is NULL or not in blk_mq_map_swqueue()
because shared tags can be freed already from another request queue.

The same situation has to be considered during handling CPU online too.
Unmapped hw queue can be remapped after CPU topo is changed, so we need
to allocate tags for the hw queue in blk_mq_map_swqueue(). Then tags
allocation for hw queue can be removed in hctx cpu online notifier, and it
is reasonable to do that after mapping is updated.

Cc: 
Reported-by: Dongsu Park 
Tested-by: Dongsu Park 
Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

SCSI: add 1024 max sectors black list flag

2015-08-06T18:49:50+00:00

[ Upstream commit 35e9a9f93994d7f7d12afa41169c7ba05513721b ]

This works around a issue with qnap iscsi targets not handling large IOs
very well.

The target returns:

VPD INQUIRY: Block limits page (SBC)
  Maximum compare and write length: 1 blocks
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 4294967295 blocks
  Optimal transfer length: 4294967295 blocks
  Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
  Maximum unmap LBA count: 8388607
  Maximum unmap block descriptor count: 1
  Optimal unmap granularity: 16383
  Unmap granularity alignment valid: 0
  Unmap granularity alignment: 0
  Maximum write same length: 0xffffffff blocks
  Maximum atomic transfer length: 0
  Atomic alignment: 0
  Atomic transfer length granularity: 0

and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
have seen in traces where it will sometimes work, but other times it
looks like it fails and it looks like it returns failures if we send
multiple large IOs sometimes. Also it looks like it can return 2 different
errors. It will sometimes send iscsi reject errors indicating out of
resources or it will send invalid cdb illegal requests check conditions.
And then when it sends iscsi rejects it does not seem to handle retries
when there are command sequence holes, so I could not just add code to
try and gracefully handle that error code.

The problem is that we do not have a good contact for the company,
so we are not able to determine under what conditions it returns
which error and why it sometimes works.

So, this patch just adds a new black list flag to set targets like this to
the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
caused this regression, so I also ccing stable.

Reported-by: Christian Hesse 
Signed-off-by: Mike Christie 
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig 
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

Fix firmware loader uevent buffer NULL pointer dereference

2015-08-04T18:43:38+00:00

[ Upstream commit 6f957724b94cb19f5c1c97efd01dd4df8ced323c ]

The firmware class uevent function accessed the "fw_priv->buf" buffer
without the proper locking and testing for NULL.  This is an old bug
(looks like it goes back to 2012 and commit 1244691c73b2: "firmware
loader: introduce firmware_buf"), but for some reason it's triggering
only now in 4.2-rc1.

Shuah Khan is trying to bisect what it is that causes this to trigger
more easily, but in the meantime let's just fix the bug since others are
hitting it too (at least Ingo reports having seen it as well).

Reported-and-tested-by: Shuah Khan 
Acked-by: Ming Lei 
Cc: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

arm64: Don't report clear pmds and puds as huge

2015-08-04T18:43:02+00:00

[ Upstream commit fd28f5d439fca77348c129d5b73043a56f8a0296 ]

The current pmd_huge() and pud_huge() functions simply check if the table
bit is not set and reports the entries as huge in that case.  This is
counter-intuitive as a clear pmd/pud cannot also be a huge pmd/pud, and
it is inconsistent with at least arm and x86.

To prevent others from making the same mistake as me in looking at code
that calls these functions and to fix an issue with KVM on arm64 that
causes memory corruption due to incorrect page reference counting
resulting from this mistake, let's change the behavior.

Signed-off-by: Christoffer Dall 
Reviewed-by: Steve Capper 
Acked-by: Marc Zyngier 
Fixes: 084bd29810a5 ("ARM64: mm: HugeTLB support.")
Cc:  # 3.11+
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

9p: don't leave a half-initialized inode sitting around

2015-08-04T18:41:56+00:00

[ Upstream commit 0a73d0a204a4a04a1e110539c5a524ae51f91d6d ]

Cc: stable@vger.kernel.org # all branches
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

9p: forgetting to cancel request on interrupted zero-copy RPC

2015-08-04T18:41:41+00:00

[ Upstream commit a84b69cb6e0a41e86bc593904faa6def3b957343 ]

If we'd already sent a request and decide to abort it, we *must*
issue TFLUSH properly and not just blindly reuse the tag, or
we'll get seriously screwed when response eventually arrives
and we confuse it for response to later request that had reused
the same tag.

Cc: stable@vger.kernel.org # v3.2 and later
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

NFS: Fix size of NFSACL SETACL operations

2015-08-04T18:40:20+00:00

[ Upstream commit d683cc49daf7c5afca8cd9654aaa1bf63cdf2ad9 ]

When encoding the NFSACL SETACL operation, reserve just the estimated
size of the ACL rather than a fixed maximum. This eliminates needless
zero padding on the wire that the server ignores.

Fixes: ee5dc7732bd5 ('NFS: Fix "kernel BUG at fs/nfs/nfs3xdr.c:1338!"')
Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

watchdog: omap: assert the counter being stopped before reprogramming

2015-08-04T18:39:52+00:00

[ Upstream commit 530c11d432727c697629ad5f9d00ee8e2864d453 ]

The omap watchdog has the annoying behaviour that writes to most
registers don't have any effect when the watchdog is already running.
Quoting the AM335x reference manual:

	To modify the timer counter value (the WDT_WCRR register),
	prescaler ratio (the WDT_WCLR[4:2] PTV bit field), delay
	configuration value (the WDT_WDLY[31:0] DLY_VALUE bit field), or
	the load value (the WDT_WLDR[31:0] TIMER_LOAD bit field), the
	watchdog timer must be disabled by using the start/stop sequence
	(the WDT_WSPR register).

Currently the timer is stopped in the .probe callback but still there
are possibilities that yield to a situation where omap_wdt_start is
entered with the timer running (e.g. when /dev/watchdog is closed
without stopping and then reopened). In such a case programming the
timeout silently fails!

To circumvent this stop the timer before reprogramming.

Assuming one of the first things the watchdog user does is setting the
timeout explicitly nothing too bad should happen because this explicit
setting works fine.

Fixes: 7768a13c252a ("[PATCH] OMAP: Add Watchdog driver support")
Signed-off-by: Uwe Kleine-König 
Reviewed-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

of: return NUMA_NO_NODE from fallback of_node_to_nid()

2015-08-04T18:39:26+00:00

[ Upstream commit c8fff7bc5bba6bd59cad40441c189c4efe7190f6 ]

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: Sasha Levin