linux-stable.git/drivers, branch v3.4.78

md/raid10: fix two bugs in handling of known-bad-blocks.

2014-01-29T13:10:42+00:00

commit b50c259e25d9260b9108dc0c2964c26e5ecbe1c1 upstream.

If we discover a bad block when reading we split the request and
potentially read some of it from a different device.

The code path of this has two bugs in RAID10.
1/ we get a spin_lock with _irq, but unlock without _irq!!
2/ The calculation of 'sectors_handled' is wrong, as can be clearly
   seen by comparison with raid1.c

This leads to at least 2 warnings and a probable crash is a RAID10
ever had known bad blocks.

Fixes: 856e08e23762dfb92ffc68fd0a8d228f9e152160
Reported-by: Damian Nowak 
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid10: fix bug when raid10 recovery fails to recover a block.

2014-01-29T13:10:42+00:00

commit e8b849158508565e0cd6bc80061124afc5879160 upstream.

commit e875ecea266a543e643b19e44cf472f1412708f9
    md/raid10 record bad blocks as needed during recovery.

added code to the "cannot recover this block" path to record a bad
block rather than fail the whole recovery.
Unfortunately this new case was placed *after* r10bio was freed rather
than *before*, yet it still uses r10bio.
This is will crash with a null dereference.

So move the freeing of r10bio down where it is safe.

Fixes: e875ecea266a543e643b19e44cf472f1412708f9
Reported-by: Damian Nowak 
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

hwmon: (coretemp) Fix truncated name of alarm attributes

2014-01-29T13:10:42+00:00

commit 3f9aec7610b39521c7c69d754de7265f6994c194 upstream.

When the core number exceeds 9, the size of the buffer storing the
alarm attribute name is insufficient and the attribute name is
truncated. This causes libsensors to skip these attributes as the
truncated name is not recognized.

Reported-by: Andreas Hollmann 
Signed-off-by: Jean Delvare 
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: 8255_pci: fix for newer PCI-DIO48H

2014-01-29T13:10:42+00:00

commit 0283f7a100882684ad32b768f9f1ad81658a0b92 upstream.

At some point, Measurement Computing / ComputerBoards redesigned the
PCI-DIO48H to use a PLX PCI interface chip instead of an AMCC chip.
This meant they had to put their hardware registers in the PCI BAR 2
region instead of PCI BAR 1.  Unfortunately, they kept the same PCI
device ID for the new design.  This means the driver recognizes the
newer cards, but doesn't work (and is likely to screw up the local
configuration registers of the PLX chip) because it's using the wrong
region.

Since  the PCI subvendor and subdevice IDs were both zero on the old
design, but are the same as the vendor and device on the new design, we
can tell the old design and new design apart easily enough.  Split the
existing entry for the PCI-DIO48H in `pci_8255_boards[]` into two new
entries, referenced by different entries in the PCI device ID table
`pci_8255_pci_table[]`.  Use the same board name for both entries.

Signed-off-by: Ian Abbott 
Acked-by: H Hartley Sweeten 
Signed-off-by: Greg Kroah-Hartman

hamradio/yam: fix info leak in ioctl

2014-01-15T23:27:11+00:00

[ Upstream commit 8e3fbf870481eb53b2d3a322d1fc395ad8b367ed ]

The yam_ioctl() code fails to initialise the cmd field
of the struct yamdrv_ioctl_cfg. Add an explicit memset(0)
before filling the structure to avoid the 4-byte info leak.

Signed-off-by: Salva Peiró 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drivers/net/hamradio: Integer overflow in hdlcdrv_ioctl()

2014-01-15T23:27:11+00:00

[ Upstream commit e9db5c21d3646a6454fcd04938dd215ac3ab620a ]

The local variable 'bi' comes from userspace. If userspace passed a
large number to 'bi.data.calibrate', there would be an integer overflow
in the following line:
	s->hdlctx.calibrate = bi.data.calibrate * s->par.bitrate / 16;

Signed-off-by: Wenliang Fan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netvsc: don't flush peers notifying work during setting mtu

2014-01-15T23:27:11+00:00

[ Upstream commit 50dc875f2e6e2e04aed3b3033eb0ac99192d6d02 ]

There's a possible deadlock if we flush the peers notifying work during setting
mtu:

[   22.991149] ======================================================
[   22.991173] [ INFO: possible circular locking dependency detected ]
[   22.991198] 3.10.0-54.0.1.el7.x86_64.debug #1 Not tainted
[   22.991219] -------------------------------------------------------
[   22.991243] ip/974 is trying to acquire lock:
[   22.991261]  ((&(&net_device_ctx->dwork)->work)){+.+.+.}, at: [] flush_work+0x5/0x2e0
[   22.991307]
but task is already holding lock:
[   22.991330]  (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0x1b/0x40
[   22.991367]
which lock already depends on the new lock.

[   22.991398]
the existing dependency chain (in reverse order) is:
[   22.991426]
-> #1 (rtnl_mutex){+.+.+.}:
[   22.991449]        [] __lock_acquire+0xb19/0x1260
[   22.991477]        [] lock_acquire+0xa2/0x1f0
[   22.991501]        [] mutex_lock_nested+0x89/0x4f0
[   22.991529]        [] rtnl_lock+0x17/0x20
[   22.991552]        [] netdev_notify_peers+0x12/0x30
[   22.991579]        [] netvsc_send_garp+0x22/0x30 [hv_netvsc]
[   22.991610]        [] process_one_work+0x211/0x6e0
[   22.991637]        [] worker_thread+0x11b/0x3a0
[   22.991663]        [] kthread+0xed/0x100
[   22.991686]        [] ret_from_fork+0x7c/0xb0
[   22.991715]
-> #0 ((&(&net_device_ctx->dwork)->work)){+.+.+.}:
[   22.991715]        [] check_prevs_add+0x967/0x970
[   22.991715]        [] __lock_acquire+0xb19/0x1260
[   22.991715]        [] lock_acquire+0xa2/0x1f0
[   22.991715]        [] flush_work+0x4e/0x2e0
[   22.991715]        [] __cancel_work_timer+0x95/0x130
[   22.991715]        [] cancel_delayed_work_sync+0x13/0x20
[   22.991715]        [] netvsc_change_mtu+0x84/0x200 [hv_netvsc]
[   22.991715]        [] dev_set_mtu+0x34/0x80
[   22.991715]        [] do_setlink+0x23a/0xa00
[   22.991715]        [] rtnl_newlink+0x394/0x5e0
[   22.991715]        [] rtnetlink_rcv_msg+0x9c/0x260
[   22.991715]        [] netlink_rcv_skb+0xa9/0xc0
[   22.991715]        [] rtnetlink_rcv+0x2a/0x40
[   22.991715]        [] netlink_unicast+0xdd/0x190
[   22.991715]        [] netlink_sendmsg+0x337/0x750
[   22.991715]        [] sock_sendmsg+0x99/0xd0
[   22.991715]        [] ___sys_sendmsg+0x39e/0x3b0
[   22.991715]        [] __sys_sendmsg+0x42/0x80
[   22.991715]        [] SyS_sendmsg+0x12/0x20
[   22.991715]        [] system_call_fastpath+0x16/0x1b

This is because we hold the rtnl_lock() before ndo_change_mtu() and try to flush
the work in netvsc_change_mtu(), in the mean time, netdev_notify_peers() may be
called from worker and also trying to hold the rtnl_lock. This will lead the
flush won't succeed forever. Solve this by not canceling and flushing the work,
this is safe because the transmission done by NETDEV_NOTIFY_PEERS was
synchronized with the netif_tx_disable() called by netvsc_change_mtu().

Reported-by: Yaju Cao 
Tested-by: Yaju Cao 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Signed-off-by: Jason Wang 
Acked-by: Haiyang Zhang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tg3: Initialize REG_BASE_ADDR at PCI config offset 120 to 0

2014-01-15T23:27:11+00:00

[ Upstream commit 388d3335575f4c056dcf7138a30f1454e2145cd8 ]

The new tg3 driver leaves REG_BASE_ADDR (PCI config offset 120)
uninitialized. From power on reset this register may have garbage in it. The
Register Base Address register defines the device local address of a
register. The data pointed to by this location is read or written using
the Register Data register (PCI config offset 128). When REG_BASE_ADDR has
garbage any read or write of Register Data Register (PCI 128) will cause the
PCI bus to lock up. The TCO watchdog will fire and bring down the system.

Signed-off-by: Nat Gurumoorthy 
Acked-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvtap: signal truncated packets

2014-01-15T23:27:10+00:00

[ Upstream commit ce232ce01d61b184202bb185103d119820e1260c ]

macvtap_put_user() never return a value grater than iov length, this in fact
bypasses the truncated checking in macvtap_recvmsg(). Fix this by always
returning the size of packet plus the possible vlan header to let the trunca
checking work.

Cc: Vlad Yasevich 
Cc: Zhi Yong Wu 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Acked-by: Vlad Yasevich 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tun: update file current position

2014-01-15T23:27:10+00:00

[ Upstream commit d0b7da8afa079ffe018ab3e92879b7138977fc8f ]

Signed-off-by: Zhi Yong Wu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman