xen-blkback: implement safe iterator for the list of persistent grants

Change foreach_grant iterator to a safe version, that allows freeing
the element while iterating. Also move the free code in
free_persistent_gnts to prevent freeing the element before the rb_next
call.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: xen-devel@lists.xen.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
llist/xen-blkfront: implement safe version of llist_for_each_entry

Implement a safe version of llist_for_each_entry, and use it in
blkif_free. Previously grants where freed while iterating the list,
which lead to dereferences when trying to fetch the next item.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by:  Andrew Morton <akpm@linux-foundation.org>
[v2: Move the llist_for_each_entry_safe in llist.h]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen-blkfront: handle bvecs with partial data

Currently blkfront fails to handle cases in blkif_completion like the
following:

1st loop in rq_for_each_segment
 * bv_offset: 3584
 * bv_len: 512
 * offset += bv_len
 * i: 0

2nd loop:
 * bv_offset: 0
 * bv_len: 512
 * i: 0

In the second loop i should be 1, since we assume we only wanted to
read a part of the previous page. This patches fixes this cases where
only a part of the shared page is read, and blkif_completion assumes
that if the bv_offset of a bvec is less than the previous bv_offset
plus the bv_size we have to switch to the next shared page.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: linux-kernel@vger.kernel.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
block: remove deadlock in disk_clear_events

In disk_clear_events, do not put work on system_nrt_freezable_wq.
Instead, put it on system_nrt_wq.

There is a race between probing a usb and suspending the device.  Since
probing a usb calls disk_clear_events, which puts work on a frozen
workqueue, probing cannot finish after the workqueue is frozen.  However,
suspending cannot finish until the usb probe is finished, so we get a
deadlock, causing the system to reboot.

The way to reproduce this bug is to wake up from suspend with a usb
storage device plugged in, or plugging in a usb storage device right
before suspend.  The window of time is on the order of time it takes to
probe the usb device.  As long as the workqueues are frozen before the
call to add_disk within sd_probe_async finishes, there will be a deadlock
(which calls blkdev_get, sd_open, check_disk_change, then
disk_clear_events).  This is not difficult to reproduce after figuring out
the timings.

[akpm@linux-foundation.org: fix up comment]
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
block: prevent race/cleanup

Remove a race condition which causes a warning in disk_clear_events.  This
is a race between disk_clear_events() and disk_flush_events().
ev->clearing will be altered by disk_flush_events() even though we are
blocking event checking through disk_flush_events().  If this happens
after ev->clearing was cleared for disk_clear_events(), this can cause the
WARN_ON_ONCE() in that function to be triggered.

This change also has disk_clear_events() not go through a workqueue.
Since we have to wait for the work to complete, we should just call the
function directly.  Also, since this work cannot be put on a freezable
workqueue, it will have to contend with increased demand, so calling the
function directly avoids this.

[akpm@linux-foundation.org: fix spello in comment]
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Cc: Mandeep Singh Baines <msb@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Merge branch 'stable/for-jens-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen into for-linus

Konrad writes:

Please git pull the following branch:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.8

which has a bug-fix to the xen-blkfront and xen-blkback driver
when using the persistent mode. An issue was discovered where LVM
disks could not be read correctly and this fixes it. There
is also a change in llist.h which has been blessed by akpm.
mtd: bcm47xxnflash: increase NFLASH_READY_RETRIES

Recently imlemented writing support has shown that current num of
retries is too low. Writing requires longer waiting than simple reading.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
rcu: Prevent soft-lockup complaints about no-CBs CPUs

The wait_event() at the head of the rcu_nocb_kthread() can result in
soft-lockup complaints if the CPU in question does not register RCU
callbacks for an extended period.  This commit therefore changes
the wait_event() to a wait_event_interruptible().

Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
rcu: Make rcu_nocb_poll an early_param instead of module_param

The as-documented rcu_nocb_poll will fail to enable this feature
for two reasons.  (1) there is an extra "s" in the documented
name which is not in the code, and (2) since it uses module_param,
it really is expecting a prefix, akin to "rcutree.fanout_leaf"
and the prefix isn't documented.

However, there are several reasons why we might not want to
simply fix the typo and add the prefix:

1) we'd end up with rcutree.rcu_nocb_poll, and rather probably make
a change to rcutree.nocb_poll

2) if we did #1, then the prefix wouldn't be consistent with the
rcu_nocbs=<cpumap> parameter (i.e. one with, one without prefix)

3) the use of module_param in a header file is less than desired,
since it isn't immediately obvious that it will get processed
via rcutree.c and get the prefix from that (although use of
module_param_named() could clarify that.)

4) the implied export of /sys/module/rcutree/parameters/rcu_nocb_poll
data to userspace via module_param() doesn't really buy us anything,
as it is read-only and we can tell if it is enabled already without
it, since there is a printk at early boot telling us so.

In light of all that, just change it from a module_param() to an
early_setup() call, and worry about adding it to /sys later on if
we decide to allow a dynamic setting of it.

Also change the variable to be tagged as read_mostly, since it
will only ever be fiddled with at most, once at boot.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
mtip32xx: fix for driver hang after a command timeout

If an I/O command times out when a PIO command is active,
MTIP_PF_EH_ACTIVE_BIT is not cleared. This results in I/O
hang in the driver. Fix is to clear this bit.

Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
mtip32xx: fix for crash when the device surprise removed during rebuild

When rebuild is in progress, disk->queue is yet to be created. Surprise
removing the device will call remove()-> del_gendisk(). del_gendisk()
expect disk->queue be not NULL. Fix is to call put_disk() when disk_queue
is NULL.

Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
mtd: davinci_nand: fix modular build with CONFIG_OF=y

Commit cdeadd712f52b16a9285386d61ee26fd14eb4085 (mtd: nand: davinci: add OF
support for davinci nand controller) has never been really build tested with
the driver as a module.  When the driver is built-in, the missing semicolon
after structure initializer is "compensated" by MODULE_DEVICE_TABLE() macro
being empty and so the initializer using the trailing semicolon on the next
line; when the driver is built as a module, compilation error ensues, and as
the 'davinci_all_defconfig' has the NAND driver modular, this error prevents
DaVinci family kernel from building...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: stable@vger.kernel.org # 3.7
ARM: OMAP2+: Limit omap initcalls to omap only on multiplatform kernels

We need to make sure that multiplatform kernels don't
run omap initcalls when booted on other SoCs.

Do this by adding wrapper macros for the initcalls that
return early if soc_is_omap() test fails. This allows
us to easily change the defines later if we have SoC
specific init sections available.

Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: Use omap initcalls

This way the initcalls don't run on other SoCs on multiplatform
kernels. Otherwise we'll get something like this when booting
on vexpress:

omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered
...
WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
_init_omap_device: could not find omap_hwmod for mpu
...
omap-dma-engine omap-dma-engine: OMAP DMA engine driver
...

Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP: Fix i2c cmdline initcall for multiplatform

We only want this initcall to run when the kernel is
booted on omap SoCs. Fix the issue by initializing the
the initcall from separately for omap1 and omap2+.

This fixes the issue for omap2+ multiplatform configs
as we are using omap_subsys_initcall there.

Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP: Fix dmaengine init for multiplatform

Otherwise omap dmaengine will initialized when booted
on other SoCs. Fix this by initializing the platform
device in arch/arm/*omap*/dma.c instead.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Dan Williams <djbw@fb.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: Add multiplatform debug_ll support

Add multiplatform debug_ll support by stripping away
the custom hacks to detect the port from debug-macro.S.

Note that this now requires the specific debug_ll port to
be selected in the .config.

The old debug-macro.S will be removed a bit later
once we are sure things work properly with multiplatform
enabled.

Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: Disable code that currently does not work with multiplaform

We still need to fix up few places for multiplatform support,
but that can proceed separately. Fix the issue by making the
problem drivers depends !ARCH_MULTIPLATFORM for now.

The remaining pieces that are not multiplatform compatible
for omap2+ SoCs are:

1. Some drivers are using custom omap_dm_timer calls

There are two drivers that are directly usign omap hardware
timers for PWM and DSP clocking: drivers/media/rc/ir-rx51.c and
drivers/staging/tidspbridge/core/dsp-clock.c. These can be
fixed for multiplatform by allowing a minimal set of hardware
timers to be accessed, and for some functionality by using the
hrtimer framework.

2. Hardware OMAP4_ERRATA_I688 needs to be fixed up

This can't be enabled for multiplatform configurations in
it's current form. It may be possible to fix it up to do
instruction replacement early on during init. Luckily it
looks like this errata does not seem to get hit with
mainline kernel code alone at least currently.

3. Legacy header needed for omap-sham.c

Looks like it still needs mach/irqs.h for omap1 that
does not exist for multiplatform systems. Just ifdef
it for now.

4. Mailbox is waiting to get moved to drivers

Disable it for now to avoid adding a dependency to the
mailbox patches.

Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi>
Cc: Sean Young <sean@mess.org>
Cc: "Víctor Manuel Jáquez Leal" <vjaquez@igalia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
[tony@atomide.com: updated to disable mailbox]
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support

Flip on multiplatform support for omap2+.

No changes to omap2plus_defconfig needed, but please note
that you may need to update your custom config files to
make sure you have:

CONFIG_ARCH_MULTIPLATFORM=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_OMAP2PLUS=y

And may need CONFIG_ARCH_MULTI_V6=y if booting omap2 boards.

Cc: Russell King <linux@arm.linux.org.uk>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP2+: Add minimal support for booting vexpress

With multiplatform support enabled we are now always
building in vexpress. Let's enable few drivers also as
this allows us to boot omap2plus zImage in qemu for
testing multiplaform related changes.

Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>