floppy: do put_disk on current dr if blk_init_queue fails

commit 238ab78469c6ab7845b43d5061cd3c92331b2452 upstream.

If blk_init_queue fails, we do not call put_disk on the current dr
(dr is decremented first in the error handling loop).

Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86: Remove the ancient and deprecated disable_hlt() and enable_hlt() facility

commit f6365201d8a21fb347260f89d6e9b3e718d63c70 upstream.

The X86_32-only disable_hlt/enable_hlt mechanism was used by the
32-bit floppy driver. Its effect was to replace the use of the
HLT instruction inside default_idle() with cpu_relax() - essentially
it turned off the use of HLT.

This workaround was commented in the code as:

 "disable hlt during certain critical i/o operations"

 "This halt magic was a workaround for ancient floppy DMA
  wreckage. It should be safe to remove."

H. Peter Anvin additionally adds:

 "To the best of my knowledge, no-hlt only existed because of
  flaky power distributions on 386/486 systems which were sold to
  run DOS.  Since DOS did no power management of any kind,
  including HLT, the power draw was fairly uniform; when exposed
  to the much hhigher noise levels you got when Linux used HLT
  caused some of these systems to fail.

  They were by far in the minority even back then."

Alan Cox further says:

 "Also for the Cyrix 5510 which tended to go castors up if a HLT
  occurred during a DMA cycle and on a few other boxes HLT during
  DMA tended to go astray.

  Do we care ? I doubt it. The 5510 was pretty obscure, the 5520
  fixed it, the 5530 is probably the oldest still in any kind of
  use."

So, let's finally drop this.

Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Stephen Hemminger <shemminger@vyatta.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/n/tip-3rhk9bzf0x9rljkv488tloib@git.kernel.org
[ If anyone cares then alternative instruction patching could be
  used to replace HLT with a one-byte NOP instruction. Much simpler. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mm: fix XFS oops due to dirty pages without buffers on s390

commit ef5d437f71afdf4afdbab99213add99f4b1318fd upstream.

On s390 any write to a page (even from kernel itself) sets architecture
specific page dirty bit.  Thus when a page is written to via buffered
write, HW dirty bit gets set and when we later map and unmap the page,
page_remove_rmap() finds the dirty bit and calls set_page_dirty().

Dirtying of a page which shouldn't be dirty can cause all sorts of
problems to filesystems.  The bug we observed in practice is that
buffers from the page get freed, so when the page gets later marked as
dirty and writeback writes it, XFS crashes due to an assertion
BUG_ON(!PagePrivate(page)) in page_buffers() called from
xfs_count_page_state().

Similar problem can also happen when zero_user_segment() call from
xfs_vm_writepage() (or block_write_full_page() for that matter) set the
hardware dirty bit during writeback, later buffers get freed, and then
page unmapped.

Fix the issue by ignoring s390 HW dirty bit for page cache pages of
mappings with mapping_cap_account_dirty().  This is safe because for
such mappings when a page gets marked as writeable in PTE it is also
marked dirty in do_wp_page() or do_page_fault().  When the dirty bit is
cleared by clear_page_dirty_for_io(), the page gets writeprotected in
page_mkclean().  So pagecache page is writeable if and only if it is
dirty.

Thanks to Hugh Dickins for pointing out mapping has to have
mapping_cap_account_dirty() for things to work and proposing a cleaned
up variant of the patch.

The patch has survived about two hours of running fsx-linux on tmpfs
while heavily swapping and several days of running on out build machines
where the original problem was triggered.

Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/nouveau: silence modesetting spam on pre-gf8 chipsets

commit cee59f15a60cc6269a25e3f6fbf1a577d6ab8115 upstream.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.51
msm: kgsl: Add new sysfs node to list GPU clock frequencies

Add a new sysfs node to communicate available GPU clock frequencies
to userspace for the power daemons.

Signed-off-by: Anshuman Dani <adani@codeaurora.org>
(cherry picked from commit 0e80b365d2b6e15344a774667a1e273edb2d64ff)

Conflicts:

	drivers/gpu/msm/kgsl_pwrctrl.c

Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
(cherry picked from commit 9ca738c3c746017e5a4c8d5fe64e1ed3e6128cc1)

Change-Id: I623a36148ae86a9a527f28e7d768535f67ceaa01
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
msm: kgsl: Fix the address translation ranges for GPU IOMMU

Set the address translation to happen via ttbr0 for GPU IOMMU till
address 0x80000000 instead of 0x40000000. Also, adjust the size of
virtual pool so that it does not allocate an address greater
than 0x80000000.

CRs-fixed: 401364
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
(cherry picked from commit 54aa5c08ddbdb2255102758237f8717302558c63)

Change-Id: I051a2197fc6a56285d153f3200b4b4500035de7f
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
msm: rpc: hold spinlock while doing wait_event

To prevent a race condition between wake_up called by
msm_rpcrouter_xprt_notify and wait_event in rr_read
hold a spinlock irqsave to prevent the system from going into
sleep when there is pending SMD data to process.

CRs-Fixed: 393416
Signed-off-by: Angshuman Sarkar <angshuman@codeaurora.org>
(cherry picked from commit 902de08f6670ddba147609e8b9f895dadf2275d9)

Change-Id: Ib7d8a868e1e968fcc8eeca53e2c1c2eeec8dd965
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
msm: bam_dmux: handle system wide low memory conditions

When A2 turns on, queue_rx() is first run from the SMSM thread, and
attempts to allocate 32 2kB-buffers with GFP_KERNEL for DMA transactions.
If the system is low on memory, the allocation could put the thread to
sleep while the memory allocator scavenges for enough memory to satisfy
the request.  This is not desired as it stalls a critical system thread
that is communicating with a real-time system.

Instead, use GFP_NOWAIT which will return immediately if no memory is
available for the allocation request so that bam_dmux may handle the
situation gracefully and possibly reschedule the allocations for a later
time.

CRs-Fixed: 406946
Change-Id: Ibff8c2d75c56b41c8d947a49e5a477fea7b31a36
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>