commit c4b6a2eaf1c14810a4803d658f68614365978738 upstream.

netif_notify_peers() caused a kernel warning in netvsc_linkstatus_callback(),
because netvsc_linkstatus_callback() is within IRQ context. So we move
the first call to netif_notify_peers() into queued work as well, but with
zero delay.

In addition to "staging-next", this should also be back-ported to stable
kernels 2.6.32 and later.

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit cf55f4a8b6243b42fb91c56d1421db0d36d60f96 upstream.

If a LUN larger than 2 TB is attached to a Linux VM on Hyper-V, we currently
report a maximum size of 2 TB. This patch resolves the issue in hv_storvsc.
Thanks to Robert Scheck <robert.scheck@etes.de> for reporting the issue.

Reported-by: Robert Scheck <robert.scheck@etes.de>
Signed-off-by: Mike Sterling <mike.sterling@microsoft.com>
Signed-off-by: K.Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

In this code, blkvsc_req is allocated in the cache blkdev->request_pool,
but freed in the first case to the cache blkvsc_req->dev->request_pool.
blkvsc_req->dev is subsequently initialized to blkdev, making these the
same at the second call to kmem_cache_free.  But at the point of the first
call, blkvsc_req->dev is NULL.  The second call is changed too, for
uniformity.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression x,e,e1,e2,e3;
@@

x = \(kmem_cache_alloc\|kmem_cache_zalloc\)(e1,e2)
... when != x = e
(
kmem_cache_free(e1,x);
|
?-kmem_cache_free(e3,x);
+kmem_cache_free(e1,x);
)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: KY Srinivasan <kys@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

* 'staging-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6: (741 commits)
  staging:iio:meter:ade7753 should be 16 bit read not 8 bit for mode register.
  staging:iio:kfifo_buf fix double initialization of the ring device structure.
  staging:iio:accel:lis3l02dq: fix incorrect pointer passed to spi_set_drvdata.
  staging:iio:imu fix missing register table index for some channels
  spectra: enable device before poking it
  staging: rts_pstor: Fix a miswriting
  staging/lirc_bt829: Return -ENODEV when no hardware is found.
  staging/lirc_parallel: remove pointless prototypes.
  staging/lirc_parallel: fix panic on rmmod
  staging:iio:adc:ad7476: Incorrect pointer into spi_set_drvdata.
  Staging: zram: Fix kunmapping order
  Revert "gma500: Fix dependencies"
  gma500: Add medfield header
  gma500: wire up the mrst i2c bus from chip_info
  gma500: Fix DPU build
  gma500: Clean up the DPU config and make it runtime
  gma500: resync with Medfield progress
  gma500: Use the mrst helpers and power control for mode commit
  gma500@ Fix backlight range error
  gma500: More Moorestown muddle meddling means MM maybe might modeset
  ...

Fix up fairly trivial conflicts all over, mostly due to header file
cleanup conflicts, but some deleted files and some just context changes:
 - Documentation/feature-removal-schedule.txt
 - drivers/staging/bcm/headers.h
 - drivers/staging/brcm80211/brcmfmac/dhd_linux.c
 - drivers/staging/brcm80211/brcmfmac/dhd_sdio.c
 - drivers/staging/brcm80211/brcmfmac/wl_cfg80211.h
 - drivers/staging/brcm80211/brcmfmac/wl_iw.c
 - drivers/staging/et131x/et131x_netdev.c
 - drivers/staging/rtl8187se/ieee80211/ieee80211_softmac.c
 - drivers/staging/rtl8192e/r8192E.h
 - drivers/staging/usbip/userspace/src/utils.h

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Abhishek Kane <v-abkane@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

It was pointed out by 'make versioncheck' that include of
linux/version.h is not needed in drivers/staging/hv/hv_timesource.c .
This patch removes it.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Properly handle the error in hv_acpi_init().

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The transmit slots were manipulated without proper locking. Fix this bug by
making the variable tracking the transmit slots atomic.

This patch should be ported to prior stable kernels 2.6.32 and later.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

On some loaded windows hosts, we have discovered that the host may not
respond to guest requests within the specified time (one second)
as evidenced by the guest timing out. Fix this problem by increasing
the timeout to 5 seconds.

It may be useful to apply this patch to the 3.0 kernel as well.
the 3.0 kernel as well.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

On some loaded windows hosts, we have discovered that the host may not
respond to guest requests within the specified time (one second)
as evidenced by the guest timing out. Fix this problem by increasing
the timeout to 5 seconds.

It may be useful to apply this patch to the 3.0 kernel as well.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>