14 Oct, 2013
19 commits
-
[ Upstream commit 95ee62083cb6453e056562d91f597552021e6ae7 ]
Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not
being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport
does not seem to have the desired effect:SCTP + IPv4:
22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116)
192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72
22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340)
192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1):SCTP + IPv6:
22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364)
fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp
1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10]Moreover, Alan says:
This problem was seen with both Racoon and Racoon2. Other people have seen
this with OpenSwan. When IPsec is configured to encrypt all upper layer
protocols the SCTP connection does not initialize. After using Wireshark to
follow packets, this is because the SCTP packet leaves Box A unencrypted and
Box B believes all upper layer protocols are to be encrypted so it drops
this packet, causing the SCTP connection to fail to initialize. When IPsec
is configured to encrypt just SCTP, the SCTP packets are observed unencrypted.In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext"
string on the other end, results in cleartext on the wire where SCTP eventually
does not report any errors, thus in the latter case that Alan reports, the
non-paranoid user might think he's communicating over an encrypted transport on
SCTP although he's not (tcpdump ... -X):...
0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000 ]p.......}.l....
0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000 ....plaintext...Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the
receiver side. Initial follow-up analysis from Alan's bug report was done by
Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this.SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit().
This has the implication that it probably never really got updated along with
changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers.SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since
a call to inet6_csk_xmit() would solve this problem, but result in unecessary
route lookups, let us just use the cached flowi6 instead that we got through
sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(),
we do the route lookup / flow caching in sctp_transport_route(), hold it in
tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in
sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect
of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst()
instead to get the correct source routed dst entry, which we assign to the skb.Also source address routing example from 625034113 ("sctp: fix sctp to work with
ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095
it is actually 'recommended' to not use that anyway due to traffic amplification [1].
So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if
we overwrite the flow destination here, the lower IPv6 layer will be unable to
put the correct destination address into IP header, as routing header is added in
ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside,
result of this patch is that we do not have any XfrmInTmplMismatch increase plus on
the wire with this patch it now looks like:SCTP + IPv6:
08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba:
AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72
08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a:
AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296This fixes Kernel Bugzilla 24412. This security issue seems to be present since
2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have
its fun with that. lksctp-tools IPv6 regression test suite passes as well with
this patch.[1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
Reported-by: Alan Chester
Reported-by: Alexey Dobriyan
Signed-off-by: Daniel Borkmann
Cc: Steffen Klassert
Cc: Hannes Frederic Sowa
Acked-by: Vlad Yasevich
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 662ca437e714caaab855b12415d6ffd815985bc0 ]
Commit c8d68e6be1c3b242f1c598595830890b65cea64a
(tuntap: multiqueue support) only call free_netdev() on error in
tun_set_iff(). This causes several issues:- memory of tun security were leaked
- use after free since the flow gc timer was not deleted and the tfile
were not detachedThis patch solves the above issues.
Reported-by: Wannes Rombouts
Cc: Michael S. Tsirkin
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit d0fe8c888b1fd1a2f84b9962cabcb98a70988aec ]
I've been hitting a NULL ptr deref while using netconsole because the
np->dev check and the pointer manipulation in netpoll_cleanup are done
without rtnl and the following sequence happens when having a netconsole
over a vlan and we remove the vlan while disabling the netconsole:
CPU 1 CPU2
removes vlan and calls the notifier
enters store_enabled(), calls
netdev_cleanup which checks np->dev
and then waits for rtnl
executes the netconsole netdev
release notifier making np->dev
== NULL and releases rtnl
continues to dereference a member of
np->dev which at this point is == NULLSigned-off-by: Nikolay Aleksandrov
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit b0dd663b60944a3ce86430fa35549fb37968bda0 ]
The received ARP request type in the Ethernet packet head is ETH_P_ARP other than ETH_P_IP.
[ Bug introduced by commit b7394d2429c198b1da3d46ac39192e891029ec0f
("netpoll: prepare for ipv6") ]Signed-off-by: Sonic Zhang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3ced8c955e74d319f3e3997f7169c79d524dfd06 ]
Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169: RxConfig
hack for the 8168evl.") regarding AMD IOMMU errors.RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the
same.Tested-by: David R
Tested-by: Frédéric Leroy
Cc: Hayes Wang
Signed-off-by: Francois Romieu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit f3ad857e3da1abaea780dc892b592cd86c541c52 ]
Fix a typo added in commit 56b765b79 ("htb: improved accuracy at high
rates")cbuffer should not be a copy of buffer.
Signed-off-by: Vimalkumar
Signed-off-by: Eric Dumazet
Cc: Jesper Dangaard Brouer
Cc: Jiri Pirko
Reviewed-by: Jiri Pirko
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit b86783587b3d1d552326d955acee37eac48800f1 ]
In commit 8ed781668dd49 ("flow_keys: include thoff into flow_keys for
later usage"), we missed that existing code was using nhoff as a
temporary variable that could not always contain transport header
offset.This is not a problem for TCP/UDP because port offset (@poff)
is 0 for these protocols.Signed-off-by: Eric Dumazet
Cc: Daniel Borkmann
Cc: Nikolay Aleksandrov
Acked-by: Nikolay Aleksandrov
Acked-by: Daniel Borkmann
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 50d1784ee4683f073c0362ee360bfae7a3333d6c ]
commit 416186fbf8c5b4e4465 ("net: Split core bits of netdev_pick_tx
into __netdev_pick_tx") added a bug that disables caching of queue
index in the socket.This is the source of packet reorders for TCP flows, and
again this is happening more often when using FQ pacing.Old code was doing
if (queue_index != old_index)
sk_tx_queue_set(sk, queue_index);Alexander renamed the variables but forgot to change sk_tx_queue_set()
2nd parameter.if (queue_index != new_index)
sk_tx_queue_set(sk, queue_index);This means we store -1 over and over in sk->sk_tx_queue_mapping
Signed-off-by: Eric Dumazet
Cc: Alexander Duyck
Acked-by: Alexander Duyck
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 88362ad8f9a6cea787420b57cc27ccacef000dbe ]
This was originally reported in [1] and posted by Neil Horman [2], he said:
Fix up a missed null pointer check in the asconf code. If we don't find
a local address, but we pass in an address length of more than 1, we may
dereference a NULL laddr pointer. Currently this can't happen, as the only
users of the function pass in the value 1 as the addrcnt parameter, but
its not hot path, and it doesn't hurt to check for NULL should that ever
be the case.The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered
from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1
while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR
so that we do *not* find a single address in the association's bind address
list that is not in the packed array of addresses. If this happens when we
have an established association with ASCONF-capable peers, then we could get
a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1
and call later sctp_make_asconf_update_ip() with NULL laddr.BUT: this actually won't happen as sctp_bindx_rem() will catch such a case
and return with an error earlier. As this is incredably unintuitive and error
prone, add a check to catch at least future bugs here. As Neil says, its not
hot path. Introduced by 8a07eb0a5 ("sctp: Add ASCONF operation on the
single-homed host").[1] http://www.spinics.net/lists/linux-sctp/msg02132.html
[2] http://www.spinics.net/lists/linux-sctp/msg02133.htmlReported-by: Dan Carpenter
Signed-off-by: Neil Horman
Signed-off-by: Daniel Borkmann
Cc: Michio Honda
Acked-By: Neil Horman
Acked-by: Vlad Yasevich
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit a0fb05d1aef0f5df936f80b726d1b3bfd4275f95 ]
If we do not add braces around ...
mask |= POLLERR |
sock_flag(sk, SOCK_SELECT_ERR_QUEUE) ? POLLPRI : 0;... then this condition always evaluates to true as POLLERR is
defined as 8 and binary or'd with whatever result comes out of
sock_flag(). Hence instead of (X | Y) ? A : B, transform it into
X | (Y ? A : B). Unfortunatelty, commit 8facd5fb73 ("net: fix
smatch warnings inside datagram_poll") forgot about SCTP. :-(Introduced by 7d4c04fc170 ("net: add option to enable error queue
packets waking select").Signed-off-by: Daniel Borkmann
Cc: Jacob Keller
Acked-by: Neil Horman
Acked-by: Vlad Yasevich
Acked-by: Jacob Keller
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit ae7b4e1f213aa659aedf9c6ecad0bf5f0476e1e2 ]
When the kernel is compiled with CONFIG_IPV6_SUBTREES, and we return
with an error in fn = fib6_add_1(), then error codes are encoded into
the return pointer e.g. ERR_PTR(-ENOENT). In such an error case, we
write the error code into err and jump to out, hence enter the if(err)
condition. Now, if CONFIG_IPV6_SUBTREES is enabled, we check for:if (pn != fn && pn->leaf == rt)
...
if (pn != fn && !pn->leaf && !(pn->fn_flags & RTN_RTINFO))
...Since pn is NULL and fn is f.e. ERR_PTR(-ENOENT), then pn != fn
evaluates to true and causes a NULL-pointer dereference on further
checks on pn. Fix it, by setting both NULL in error case, so that
pn != fn already evaluates to false and no further dereference
takes place.This was first correctly implemented in 4a287eba2 ("IPv6 routing,
NLM_F_* flag support: REPLACE and EXCL flags support, warn about
missing CREATE flag"), but the bug got later on introduced by
188c517a0 ("ipv6: return errno pointers consistently for fib6_add_1()").Signed-off-by: Daniel Borkmann
Cc: Lin Ming
Cc: Matti Vaittinen
Cc: Hannes Frederic Sowa
Acked-by: Hannes Frederic Sowa
Acked-by: Matti Vaittinen
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 8112b1fe071be01a28a774ed55909e6f4b29712d ]
In rfc4942 and rfc2460 I cannot find anything which would implicate to
drop packets which have only padding in tlv.Current behaviour breaks TAHI Test v6LC.1.2.6.
Problem was intruduced in:
9b905fe6843 "ipv6/exthdrs: strict Pad1 and PadN check"Signed-off-by: Jiri Pirko
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit e2e5c4c07caf810d7849658dca42f598b3938e21 ]
Signed-off-by: Dave Jones
Acked-by: Neal Cardwell
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 0c1db731bfcf3a9fd6c58132134f8b0f423552f0 ]
The indentation here implies this was meant to be a multi-line if.
Introduced several years back in commit c85c2951d4da1236e32f1858db418221e624aba5
("caif: Handle dev_queue_xmit errors.")Signed-off-by: Dave Jones
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit bc197eedef1ae082ec662c64c3f4aa302821fb7a upstream.
27ce4050 ("HID: fix data access in implement()") by mistake removed
a setting of buffer size in hidp. Fix that by putting it back.Reported-by: kbuild test robot
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 27ce405039bfe6d3f4143415c638f56a3df77dca upstream.
implement() is setting bytes in LE data stream. In case the data is not
aligned to 64bits, it reads past the allocated buffer. It doesn't really
change any value there (it's properly bitmasked), but in case that this
read past the boundary hits a page boundary, pagefault happens when
accessing 64bits of 'x' in implement(), and kernel oopses.This happens much more often when numbered reports are in use, as the
initial 8bit skip in the buffer makes the whole process work on values
which are not aligned to 64bits.This problem dates back to attempts in 2005 and 2006 to make implement()
and extract() as generic as possible, and even back then the problem
was realized by Adam Kroperlin, but falsely assumed to be impossible
to cause any harm:http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
I have made several attempts at fixing it "on the spot" directly in
implement(), but the results were horrible; the special casing for processing
last 64bit chunk and switching to different math makes it unreadable mess.I therefore took a path to allocate a few bytes more which will never make
it into final report, but are there as a cushion for all the 64bit math
operations happening in implement() and extract().All callers of hid_output_report() are converted at the same time to allocate
the buffer by newly introduced hid_alloc_report_buf() helper.Bruno noticed that the whole raw_size test can be dropped as well, as
hid_alloc_report_buf() makes sure that the buffer is always of a proper
size.Reviewed-by: Benjamin Tissoires
Acked-by: Gustavo Padovan
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 58f09e00ae095e46ef9edfcf3a5fd9ccdfad065e upstream.
The arg64 struct has a hole after ->buf_size which isn't cleared. Or if
any of the calls to copy_from_user() fail then that would cause an
information leak as well.This was assigned CVE-2013-2147.
Signed-off-by: Dan Carpenter
Acked-by: Mike Miller
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 627aad1c01da6f881e7f98d71fd928ca0c316b1a upstream.
The pciinfo struct has a two byte hole after ->dev_fn so stack
information could be leaked to the user.This was assigned CVE-2013-2147.
Signed-off-by: Dan Carpenter
Acked-by: Mike Miller
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 6390d88529835a8ad3563fe01a5da89fa52d6db2 upstream.
When trying to unset a previously-set multicast list (i.e. the new list
has 0 entries), mwifiex_set_multicast_list() was calling down to
mwifiex_request_set_multicast_list() while leaving
mcast_list.num_multicast_addr as an uninitialized value.We were arriving at mwifiex_cmd_mac_multicast_adr() which would then
proceed to do an often huge memcpy of
mcast_list.num_multicast_addr*ETH_ALEN bytes, causing memory corruption
and hard to debug crashes.Fix this by setting mcast_list.num_multicast_addr to 0 when no multicast
list is provided. Similarly, fix up the logic in
mwifiex_request_set_multicast_list() to unset the multicast list that
was previously sent to the hardware in such cases.Signed-off-by: Daniel Drake
Acked-by: Bing Zhao
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman
05 Oct, 2013
21 commits
-
commit 0ce99f749b3834edeb500e17d6ad17e86b60ff83 upstream.
Apparently Bspec is wrong in this case here even for gm45. Note that
Bspec is horribly misguided on i965g/gm, so we don't have any other
data points besides that it seems to make machines work better.With this changes all the bits in PORT_HOTPLUG_STAT for the digital
ports are ordered the same way. This seems to agree with what register
dumps from the hpd storm handling code shows, where the LIVE bit and
the short/long pulse STATUS bits light up at the same time with this
enumeration (but no with the one from Bspec).Also tested on my gm45 which has two DP+ ports, and everything seems
to still work as expected.References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg23054.html
Cc: Egbert Eich
Cc: Jan Niggemann
Tested-by: Jan Niggemann
[danvet: Add a big warning that Bspec seems to be wrong for these
bits, suggested by Jani.]
Acked-by: Jani Nikula
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 4028b6c4c03f213260e9290ff3a6b5439aad07ce upstream.
snd_unregister_device() should return the device type and not stream
direction.Signed-off-by: Liam Girdwood
Acked-by: Vinod Koul
Tested-by: Vinod Koul
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream.
After reports from Chris and Josh Boyer of a rare crash in applesmc,
Guenter pointed at the initialization problem fixed below. The patch
has not been verified to fix the crash, but should be applied
regardless.Reported-by:
Suggested-by: Guenter Roeck
Signed-off-by: Henrik Rydberg
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 7a9caf59f60e55a8caf96f856713bd0ef0cc25a7 upstream.
When building a kernel without CONFIG_PM, we get a link
error from referencing mxs_pm_init in the machine
descriptor. This defines a macro to NULL for that case.Signed-off-by: Arnd Bergmann
Acked-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman -
commit 58d327da9721f7a0f6e46c8dfa5cc5546fd7078a upstream.
These asics seem to use a mix of the DCE2.x and
DCE3.2 audio interfaces despite what the register spec
says.Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729
https://bugs.freedesktop.org/show_bug.cgi?id=69671Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 99d79aa2f3b7729e7290e8bda5d0dd8b0240ec62 upstream.
When dpm was merged, I added a new asic struct for
rv6xx, but it never got properly updated when the
hdmi callbacks were added due to the two patch sets
being developed in parallel.Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729Signed-off-by: Alex Deucher
Reviewed-by: Christian König
Signed-off-by: Greg Kroah-Hartman -
commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream.
The tests are only usable if the acceleration engines have
been successfully initialized.Based on an initial patch from: Alex Ivanov
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 0eb3448aa6b31fbf24c31756aba7940cac5ad6b8 upstream.
Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job.
Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to a KP if ring buffer was deallocated, e.g. on failed ring test.
Seen on PA-RISC machine having "radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD)" issue.v2: agd5f: add some parens around ring->ready check
Signed-off-by: Alex Ivanov
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 4ca5a6cba53e13b8fd153b0762b4128fab6a3cfb upstream.
If the user has forced the driver to use the internal GPU gart
rather than AGP on an AGP card, force the buffers to vram
as well.Signed-off-by: Alex Deucher
Reviewed-by: Christian König
Tested-by: Dieter Nützel
Signed-off-by: Greg Kroah-Hartman -
commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream.
There is no clear cut rules or specs for the retry interval, as there
are many factors that affect overall response time. Increase the
interval, and even more so on branch devices which may have limited i2c
bit rates.Signed-off-by: Jani Nikula
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263
Tested-by: Nicolas Suzor
Reviewed-by: Todd Previte
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 67c72a12254101d4e8d9b9f3a02646ba0be84a2d upstream.
This regression has been introduced in
commit 9f11a9e4e50006b615ba94722dfc33ced89664cf
Author: Daniel Vetter
Date: Thu Jun 13 00:54:58 2013 +0200drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
Ville brough up the idea that this is just the pipe A quirk gone
wrong.Note that after resume the bios might or might not have enabled pipe A
already. We have a bit of magic to make sure that on resume we set up
a decent mode for pipe A, but I fear if I just smash pipe A to always
on we'd enable it in a bogus state and hang the hw. Hence the
readback.v2: Clarify the logic a bit as suggested by Chris. Also amend the
commit message to clarify why we don't unconditionally enable the
pipe.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66462
References: https://lkml.org/lkml/2013/8/26/238
Cc: Meelis Roos
Cc: Chris Wilson
Cc: Ville Syrjälä
Reviewed-by: Chris Wilson
[danvet: Use |= instead of = as suggested by Chris.]
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 3f6bbd3ffd7b733dd705e494663e5761aa2cb9c1 upstream.
This doesn't really need to be initialised, but it doesn't hurt,
silences the compiler, and as it is a counter it makes sense for it to
start at zero.Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit f84cb8a46a771f36a04a02c61ea635c968ed5f6a upstream.
Workaround the SCSI layer's problematic WRITE SAME heuristics by
disabling WRITE SAME in the DM multipath device's queue_limits if an
underlying device disabled it.The WRITE SAME heuristics, with both the original commit 5db44863b6eb
("[SCSI] sd: Implement support for WRITE SAME") and the updated commit
66c28f971 ("[SCSI] sd: Update WRITE SAME heuristics"), default to enabling
WRITE SAME(10) even without successfully determining it is supported.
After the first failed WRITE SAME the SCSI layer will disable WRITE SAME
for the device (by setting sdkp->device->no_write_same which results in
'max_write_same_sectors' in device's queue_limits to be set to 0).When a device is stacked ontop of such a SCSI device any changes to that
SCSI device's queue_limits do not automatically propagate up the stack.
As such, a DM multipath device will not have its WRITE SAME support
disabled. This causes the block layer to continue to issue WRITE SAME
requests to the mpath device which causes paths to fail and (if mpath IO
isn't configured to queue when no paths are available) it will result in
actual IO errors to the upper layers.This fix doesn't help configurations that have additional devices
stacked ontop of the mpath device (e.g. LVM created linear DM devices
ontop). A proper fix that restacks all the queue_limits from the bottom
of the device stack up will need to be explored if SCSI will continue to
use this model of optimistically allowing op codes and then disabling
them after they fail for the first time.Before this patch:
EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null)
device-mapper: multipath: XXX snitm debugging: got -EREMOTEIO (-121)
device-mapper: multipath: XXX snitm debugging: failing WRITE SAME IO with error=-121
end_request: critical target error, dev dm-6, sector 528
dm-6: WRITE SAME failed. Manually zeroing.
device-mapper: multipath: Failing path 8:112.
end_request: I/O error, dev dm-6, sector 4616
dm-6: WRITE SAME failed. Manually zeroing.
end_request: I/O error, dev dm-6, sector 4616
end_request: I/O error, dev dm-6, sector 5640
end_request: I/O error, dev dm-6, sector 6664
end_request: I/O error, dev dm-6, sector 7688
end_request: I/O error, dev dm-6, sector 524288
Buffer I/O error on device dm-6, logical block 65536
lost page write due to I/O error on dm-6
JBD2: Error -5 detected when updating journal superblock for dm-6-8.
end_request: I/O error, dev dm-6, sector 524296
Aborting journal on device dm-6-8.
end_request: I/O error, dev dm-6, sector 524288
Buffer I/O error on device dm-6, logical block 65536
lost page write due to I/O error on dm-6
JBD2: Error -5 detected when updating journal superblock for dm-6-8.# cat /sys/block/sdh/queue/write_same_max_bytes
0
# cat /sys/block/dm-6/queue/write_same_max_bytes
33553920After this patch:
EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null)
device-mapper: multipath: XXX snitm debugging: got -EREMOTEIO (-121)
device-mapper: multipath: XXX snitm debugging: WRITE SAME I/O failed with error=-121
end_request: critical target error, dev dm-6, sector 528
dm-6: WRITE SAME failed. Manually zeroing.# cat /sys/block/sdh/queue/write_same_max_bytes
0
# cat /sys/block/dm-6/queue/write_same_max_bytes
0It should be noted that WRITE SAME support wasn't enabled in DM
multipath until v3.10.Signed-off-by: Mike Snitzer
Cc: Martin K. Petersen
Cc: Hannes Reinecke
Signed-off-by: Greg Kroah-Hartman -
commit 60e356f381954d79088d0455e357db48cfdd6857 upstream.
LVM2, since version 2.02.96, creates origin with zero size, then loads
the snapshot driver and then loads the origin. Consequently, the
snapshot driver sees the origin size zero and sets the hash size to the
lower bound 64. Such small hash table causes performance degradation.This patch changes it so that the hash size is determined by the size of
snapshot volume, not minimum of origin and snapshot size. It doesn't
make sense to set the snapshot size significantly larger than the origin
size, so we do not need to take origin size into account when
calculating the hash size.Signed-off-by: Mikulas Patocka
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 5ea330a75bd86b2b2a01d7b85c516983238306fb upstream.
The kernel reports a lockdep warning if a snapshot is invalidated because
it runs out of space.The lockdep warning was triggered by commit 0976dfc1d0cd80a4e9dfaf87bd87
("workqueue: Catch more locking problems with flush_work()") in v3.5.The warning is false positive. The real cause for the warning is that
the lockdep engine treats different instances of md->lock as a single
lock.This patch is a workaround - we use flush_workqueue instead of flush_work.
This code path is not performance sensitive (it is called only on
initialization or invalidation), thus it doesn't matter that we flush the
whole workqueue.The real fix for the problem would be to teach the lockdep engine to treat
different instances of md->lock as separate locks.Signed-off-by: Mikulas Patocka
Acked-by: Alasdair G Kergon
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit f123db8e9d6c84c863cb3c44d17e61995dc984fb upstream.
The put_device(dev) at the bottom of the loop of device_shutdown
may result in the dev being cleaned up. In device_create_release,
the dev is kfreed.However, device_shutdown attempts to use the dev pointer again after
put_device by referring to dev->parent.Copy the parent pointer instead to avoid this condition.
This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11.
See bug report : https://code.google.com/p/chromium/issues/detail?id=297842
This can easily be reproduced when shutting down with
hidraw devices that report battery condition.
Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse.
For example, with the magic mouse :
The dev in question is "hidraw0"
dev->parent is "magicmouse"In the course of the shutdown for this device, the input event cleanup calls
a put on hidraw0, decrementing its reference count.
When we finally get to put_device(dev) in device_shutdown, kobject_cleanup
is called and device_create_release does kfree(dev).
dev->parent is no longer valid, and we may crash in
put_device(dev->parent).This change should be applied on any kernel with this change :
d1c6c030fcec6f860d9bb6c632a3ebe62e28440bSigned-off-by: Benson Leung
Reviewed-by: Ming Lei
Signed-off-by: Greg Kroah-Hartman -
commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream.
Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).The reason is a USB control message
usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.The kernel thus rejects the IO and thus we see the failure.
Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to. The device seems to happily deal with that though (and
seems to not really care about this value much).So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)With attached patch, the app in Windows in KVM works.
usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/Signed-off-by: Kurt Garloff
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream.
Add PCI id for Intel Merrifield
Signed-off-by: David Cohen
Signed-off-by: Greg Kroah-Hartman -
commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream.
Add PCI id for Intel BayTrail.
Signed-off-by: Heikki Krogerus
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit ad1260e9fbf768d6bed227d9604ebee76a84aae3 upstream.
For controller versions greater than 1.6, setting ULPI_PHY_CLK_SEL
bit when USB_EN bit is already set causes instability issues with
PHY_CLK_VLD bit. So USB_EN is set only for IP controller version
below 1.6 before setting ULPI_PHY_CLK_SEL bitSigned-off-by: Ramneek Mehresh
Signed-off-by: Greg Kroah-Hartman
