7 years agounicore32: add ioremap_nocache definition
Guan Xuetao [Thu, 18 Aug 2011 07:38:05 +0000 (15:38 +0800)]
unicore32: add ioremap_nocache definition

commit a50e4213e71adc7dde0d514aabd8af7275fee39f upstream.

Bugfix for following error messages:
lib/iomap.c: In function 'pci_iomap':
lib/iomap.c:274: error: implicit declaration of function 'ioremap_nocache'
lib/iomap.c:274: warning: return makes pointer from integer without a cast

Also see commit <f1ecc69838a2d7c8a3e1909f637d4083c071777d>
  it will hide the ioremap_nocache function for systems with an MMU

Signed-off-by: Guan Xuetao <>
Cc: Arnd Bergmann <>
Cc: Jonas Bonn <>
Signed-off-by: Ben Hutchings <>
7 years agoshmem: fix splicing from a hole while it's punched
Hugh Dickins [Wed, 23 Jul 2014 21:00:13 +0000 (14:00 -0700)]
shmem: fix splicing from a hole while it's punched

commit b1a366500bd537b50c3aad26dc7df083ec03a448 upstream.

shmem_fault() is the actual culprit in trinity's hole-punch starvation,
and the most significant cause of such problems: since a page faulted is
one that then appears page_mapped(), needing unmap_mapping_range() and
i_mmap_mutex to be unmapped again.

But it is not the only way in which a page can be brought into a hole in
the radix_tree while that hole is being punched; and Vlastimil's testing
implies that if enough other processors are busy filling in the hole,
then shmem_undo_range() can be kept from completing indefinitely.

shmem_file_splice_read() is the main other user of SGP_CACHE, which can
instantiate shmem pagecache pages in the read-only case (without holding
i_mutex, so perhaps concurrently with a hole-punch).  Probably it's
silly not to use SGP_READ already (using the ZERO_PAGE for holes): which
ought to be safe, but might bring surprises - not a change to be rushed.

shmem_read_mapping_page_gfp() is an internal interface used by
drivers/gpu/drm GEM (and next by uprobes): it should be okay.  And
shmem_file_read_iter() uses the SGP_DIRTY variant of SGP_CACHE, when
called internally by the kernel (perhaps for a stacking filesystem,
which might rely on holes to be reserved): it's unclear whether it could
be provoked to keep hole-punch busy or not.

We could apply the same umbrella as now used in shmem_fault() to
shmem_file_splice_read() and the others; but it looks ugly, and use over
a range raises questions - should it actually be per page? can these get
starved themselves?

The origin of this part of the problem is my v3.1 commit d0823576bf4b
("mm: pincer in truncate_inode_pages_range"), once it was duplicated
into shmem.c.  It seemed like a nice idea at the time, to ensure
(barring RCU lookup fuzziness) that there's an instant when the entire
hole is empty; but the indefinitely repeated scans to ensure that make
it vulnerable.

Revert that "enhancement" to hole-punch from shmem_undo_range(), but
retain the unproblematic rescanning when it's truncating; add a couple
of comments there.

Remove the "indices[0] >= end" test: that is now handled satisfactorily
by the inner loop, and mem_cgroup_uncharge_start()/end() are too light
to be worth avoiding here.

But if we do not always loop indefinitely, we do need to handle the case
of swap swizzled back to page before shmem_free_swap() gets it: add a
retry for that case, as suggested by Konstantin Khlebnikov; and for the
case of page swizzled back to swap, as suggested by Johannes Weiner.

Signed-off-by: Hugh Dickins <>
Reported-by: Sasha Levin <>
Suggested-by: Vlastimil Babka <>
Cc: Konstantin Khlebnikov <>
Cc: Johannes Weiner <>
Cc: Lukas Czerner <>
Cc: Dave Jones <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoshmem: fix faulting into a hole, not taking i_mutex
Hugh Dickins [Wed, 23 Jul 2014 21:00:10 +0000 (14:00 -0700)]
shmem: fix faulting into a hole, not taking i_mutex

commit 8e205f779d1443a94b5ae81aa359cb535dd3021e upstream.

Commit f00cdc6df7d7 ("shmem: fix faulting into a hole while it's
punched") was buggy: Sasha sent a lockdep report to remind us that
grabbing i_mutex in the fault path is a no-no (write syscall may already
hold i_mutex while faulting user buffer).

We tried a completely different approach (see following patch) but that
proved inadequate: good enough for a rational workload, but not good
enough against trinity - which forks off so many mappings of the object
that contention on i_mmap_mutex while hole-puncher holds i_mutex builds
into serious starvation when concurrent faults force the puncher to fall
back to single-page unmap_mapping_range() searches of the i_mmap tree.

So return to the original umbrella approach, but keep away from i_mutex
this time.  We really don't want to bloat every shmem inode with a new
mutex or completion, just to protect this unlikely case from trinity.
So extend the original with wait_queue_head on stack at the hole-punch
end, and wait_queue item on the stack at the fault end.

This involves further use of i_lock to guard against the races: lockdep
has been happy so far, and I see fs/inode.c:unlock_new_inode() holds
i_lock around wake_up_bit(), which is comparable to what we do here.
i_lock is more convenient, but we could switch to shmem's info->lock.

This issue has been tagged with CVE-2014-4171, which will require commit
f00cdc6df7d7 and this and the following patch to be backported: we
suggest to 3.1+, though in fact the trinity forkbomb effect might go
back as far as 2.6.16, when madvise(,,MADV_REMOVE) came in - or might
not, since much has changed, with i_mmap_mutex a spinlock before 3.0.
Anyone running trinity on 3.0 and earlier? I don't think we need care.

Signed-off-by: Hugh Dickins <>
Reported-by: Sasha Levin <>
Tested-by: Sasha Levin <>
Cc: Vlastimil Babka <>
Cc: Konstantin Khlebnikov <>
Cc: Johannes Weiner <>
Cc: Lukas Czerner <>
Cc: Dave Jones <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoshmem: fix faulting into a hole while it's punched
Hugh Dickins [Mon, 23 Jun 2014 20:22:06 +0000 (13:22 -0700)]
shmem: fix faulting into a hole while it's punched

commit f00cdc6df7d7cfcabb5b740911e6788cb0802bdb upstream.

Trinity finds that mmap access to a hole while it's punched from shmem
can prevent the madvise(MADV_REMOVE) or fallocate(FALLOC_FL_PUNCH_HOLE)
from completing, until the reader chooses to stop; with the puncher's
hold on i_mutex locking out all other writers until it can complete.

It appears that the tmpfs fault path is too light in comparison with its
hole-punching path, lacking an i_data_sem to obstruct it; but we don't
want to slow down the common case.

Extend shmem_fallocate()'s existing range notification mechanism, so
shmem_fault() can refrain from faulting pages into the hole while it's
punched, waiting instead on i_mutex (when safe to sleep; or repeatedly
faulting when not).

[ coding-style fixes]
Signed-off-by: Hugh Dickins <>
Reported-by: Sasha Levin <>
Tested-by: Sasha Levin <>
Cc: Dave Jones <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoxfs: really fix the cursor leak in xfs_alloc_ag_vextent_near
Dave Chinner [Wed, 11 Jul 2012 21:40:42 +0000 (07:40 +1000)]
xfs: really fix the cursor leak in xfs_alloc_ag_vextent_near

commit e3a746f5aab71f2dd0a83116772922fb37ae29d6 upstream.

The current cursor is reallocated when retrying the allocation, so
the existing cursor needs to be destroyed in both the restart and
the failure cases.

Signed-off-by: Dave Chinner <>
Tested-by: Mike Snitzer <>
Signed-off-by: Ben Myers <>
Signed-off-by: Ben Hutchings <>
7 years agoxfs: fix allocbt cursor leak in xfs_alloc_ag_vextent_near
Dave Chinner [Tue, 12 Jun 2012 04:20:26 +0000 (14:20 +1000)]
xfs: fix allocbt cursor leak in xfs_alloc_ag_vextent_near

commit 76d095388b040229ea1aad7dea45be0cfa20f589 upstream.

When we fail to find an matching extent near the requested extent
specification during a left-right distance search in
xfs_alloc_ag_vextent_near, we fail to free the original cursor that
we used to look up the XFS_BTNUM_CNT tree and hence leak it.

Reported-by: Chris J Arges <>
Signed-off-by: Dave Chinner <>
Reviewed-by: Christoph Hellwig <>
Signed-off-by: Ben Myers <>
Signed-off-by: Ben Hutchings <>
7 years agonetfilter: ipt_ULOG: fix info leaks
Mathias Krause [Mon, 30 Sep 2013 20:05:08 +0000 (22:05 +0200)]
netfilter: ipt_ULOG: fix info leaks

commit 278f2b3e2af5f32ea1afe34fa12a2518153e6e49 upstream.

The ulog messages leak heap bytes by the means of padding bytes and
incompletely filled string arrays. Fix those by memset(0)'ing the
whole struct before filling it.

Signed-off-by: Mathias Krause <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agos390/ptrace: fix PSW mask check
Martin Schwidefsky [Mon, 23 Jun 2014 12:43:06 +0000 (14:43 +0200)]
s390/ptrace: fix PSW mask check

commit dab6cf55f81a6e16b8147aed9a843e1691dcd318 upstream.

The PSW mask check of the PTRACE_POKEUSR_AREA command is incorrect.
For the default user_mode=home address space layout the psw_user_bits
variable has the home space address-space-control bits set. But the
PSW_MASK_USER contains PSW_MASK_ASC, the ptrace validity check for the
PSW mask will therefore always fail.

Fixes CVE-2014-3534

Signed-off-by: Martin Schwidefsky <>
Signed-off-by: Ben Hutchings <>
7 years agonohz: Fix another inconsistency between CONFIG_NO_HZ=n and nohz=off
Thomas Gleixner [Fri, 29 Nov 2013 11:18:13 +0000 (12:18 +0100)]
nohz: Fix another inconsistency between CONFIG_NO_HZ=n and nohz=off

commit 0e576acbc1d9600cf2d9b4a141a2554639959d50 upstream.

If CONFIG_NO_HZ=n tick_nohz_get_sleep_length() returns NSEC_PER_SEC/HZ.

If CONFIG_NO_HZ=y and the nohz functionality is disabled via the
command line option "nohz=off" or not enabled due to missing hardware
support, then tick_nohz_get_sleep_length() returns 0. That happens
because ts->sleep_length is never set in that case.

Set it to NSEC_PER_SEC/HZ when the NOHZ mode is inactive.

Reported-by: Michal Hocko <>
Reported-by: Borislav Petkov <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agortnetlink: fix userspace API breakage for iproute2 < v3.9.0
Michal Schmidt [Wed, 28 May 2014 12:15:19 +0000 (14:15 +0200)]
rtnetlink: fix userspace API breakage for iproute2 < v3.9.0

commit e5eca6d41f53db48edd8cf88a3f59d2c30227f8e upstream.

When running RHEL6 userspace on a current upstream kernel, "ip link"
fails to show VF information.

The reason is a kernel<->userspace API change introduced by commit
88c5b5ce5cb57 ("rtnetlink: Call nlmsg_parse() with correct header length"),
after which the kernel does not see iproute2's IFLA_EXT_MASK attribute
in the netlink request.

iproute2 adjusted for the API change in its commit 63338dca4513
("libnetlink: Use ifinfomsg instead of rtgenmsg in rtnl_wilddump_req_filter").

The problem has been noticed before:
(Subject: Re: getting VF link info seems to be broken in 3.9-rc8)

We can do better than tell those with old userspace to upgrade. We can
recognize the old iproute2 in the kernel by checking the netlink message
length. Even when including the IFLA_EXT_MASK attribute, its netlink
message is shorter than struct ifinfomsg.

With this patch "ip link" shows VF information in both old and new
iproute2 versions.

Signed-off-by: Michal Schmidt <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoipv4: fix buffer overflow in ip_options_compile()
Eric Dumazet [Mon, 21 Jul 2014 05:17:42 +0000 (07:17 +0200)]
ipv4: fix buffer overflow in ip_options_compile()

[ Upstream commit 10ec9472f05b45c94db3c854d22581a20b97db41 ]

There is a benign buffer overflow in ip_options_compile spotted by
AddressSanitizer[1] :

Its benign because we always can access one extra byte in skb->head
(because header is followed by struct skb_shared_info), and in this case
this byte is not even used.

[28504.910798] ==================================================================
[28504.912046] AddressSanitizer: heap-buffer-overflow in ip_options_compile
[28504.913170] Read of size 1 by thread T15843:
[28504.914026]  [<ffffffff81802f91>] ip_options_compile+0x121/0x9c0
[28504.915394]  [<ffffffff81804a0d>] ip_options_get_from_user+0xad/0x120
[28504.916843]  [<ffffffff8180dedf>] do_ip_setsockopt.isra.15+0x8df/0x1630
[28504.918175]  [<ffffffff8180ec60>] ip_setsockopt+0x30/0xa0
[28504.919490]  [<ffffffff8181e59b>] tcp_setsockopt+0x5b/0x90
[28504.920835]  [<ffffffff8177462f>] sock_common_setsockopt+0x5f/0x70
[28504.922208]  [<ffffffff817729c2>] SyS_setsockopt+0xa2/0x140
[28504.923459]  [<ffffffff818cfb69>] system_call_fastpath+0x16/0x1b
[28504.925106] Allocated by thread T15843:
[28504.925815]  [<ffffffff81804995>] ip_options_get_from_user+0x35/0x120
[28504.926884]  [<ffffffff8180dedf>] do_ip_setsockopt.isra.15+0x8df/0x1630
[28504.927975]  [<ffffffff8180ec60>] ip_setsockopt+0x30/0xa0
[28504.929175]  [<ffffffff8181e59b>] tcp_setsockopt+0x5b/0x90
[28504.930400]  [<ffffffff8177462f>] sock_common_setsockopt+0x5f/0x70
[28504.931677]  [<ffffffff817729c2>] SyS_setsockopt+0xa2/0x140
[28504.932851]  [<ffffffff818cfb69>] system_call_fastpath+0x16/0x1b
[28504.934377] The buggy address ffff880026382828 is located 0 bytes to the right
[28504.934377]  of 40-byte region [ffff880026382800ffff880026382828)
[28504.937474] Memory state around the buggy address:
[28504.938430]  ffff880026382300: ........ rrrrrrrr rrrrrrrr rrrrrrrr
[28504.939884]  ffff880026382400ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28504.941294]  ffff880026382500: .....rrr rrrrrrrr rrrrrrrr rrrrrrrr
[28504.942504]  ffff880026382600ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28504.943483]  ffff880026382700ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28504.944511] >ffff880026382800: .....rrr rrrrrrrr rrrrrrrr rrrrrrrr
[28504.945573]                         ^
[28504.946277]  ffff880026382900ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.094949]  ffff880026382a00ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.096114]  ffff880026382b00ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.097116]  ffff880026382c00ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.098472]  ffff880026382d00ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.099804] Legend:
[28505.100269]  f - 8 freed bytes
[28505.100884]  r - 8 redzone bytes
[28505.101649]  . - 8 allocated bytes
[28505.102406]  x=1..7 - x allocated bytes + (8-x) redzone bytes
[28505.103637] ==================================================================


Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agodns_resolver: Null-terminate the right string
Ben Hutchings [Sun, 20 Jul 2014 23:06:48 +0000 (00:06 +0100)]
dns_resolver: Null-terminate the right string

[ Upstream commit 640d7efe4c08f06c4ae5d31b79bd8740e7f6790a ]

*_result[len] is parsed as *(_result[len]) which is not at all what we
want to touch here.

Signed-off-by: Ben Hutchings <>
Fixes: 84a7c0b1db1c ("dns_resolver: assure that dns_query() result is null-terminated")
Signed-off-by: David S. Miller <>
7 years agodns_resolver: assure that dns_query() result is null-terminated
Manuel Schölling [Sat, 7 Jun 2014 21:57:25 +0000 (23:57 +0200)]
dns_resolver: assure that dns_query() result is null-terminated

[ Upstream commit 84a7c0b1db1c17d5ded8d3800228a608e1070b40 ]

dns_query() credulously assumes that keys are null-terminated and
returns a copy of a memory block that is off by one.

Signed-off-by: Manuel Schölling <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agosunvnet: clean up objects created in vnet_new() on vnet_exit()
Sowmini Varadhan [Wed, 16 Jul 2014 14:02:26 +0000 (10:02 -0400)]
sunvnet: clean up objects created in vnet_new() on vnet_exit()

[ Upstream commit a4b70a07ed12a71131cab7adce2ce91c71b37060 ]

Nothing cleans up the objects created by
vnet_new(), they are completely leaked.

vnet_exit(), after doing the vio_unregister_driver() to clean
up ports, should call a helper function that iterates over vnet_list
and cleans up those objects. This includes unregister_netdevice()
as well as free_netdev().

Signed-off-by: Sowmini Varadhan <>
Acked-by: Dave Kleikamp <>
Reviewed-by: Karl Volz <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: sctp: fix information leaks in ulpevent layer
Daniel Borkmann [Sat, 12 Jul 2014 18:30:35 +0000 (20:30 +0200)]
net: sctp: fix information leaks in ulpevent layer

[ Upstream commit 8f2e5ae40ec193bc0a0ed99e95315c3eebca84ea ]

While working on some other SCTP code, I noticed that some
structures shared with user space are leaking uninitialized
stack or heap buffer. In particular, struct sctp_sndrcvinfo
has a 2 bytes hole between .sinfo_flags and .sinfo_ppid that
remains unfilled by us in sctp_ulpevent_read_sndrcvinfo() when
putting this into cmsg. But also struct sctp_remote_error
contains a 2 bytes hole that we don't fill but place into a skb
through skb_copy_expand() via sctp_ulpevent_make_remote_error().

Both structures are defined by the IETF in RFC6458:

* Section 5.3.2. SCTP Header Information Structure:

  The sctp_sndrcvinfo structure is defined below:

  struct sctp_sndrcvinfo {
    uint16_t sinfo_stream;
    uint16_t sinfo_ssn;
    uint16_t sinfo_flags;
    <-- 2 bytes hole  -->
    uint32_t sinfo_ppid;
    uint32_t sinfo_context;
    uint32_t sinfo_timetolive;
    uint32_t sinfo_tsn;
    uint32_t sinfo_cumtsn;
    sctp_assoc_t sinfo_assoc_id;


  A remote peer may send an Operation Error message to its peer.
  This message indicates a variety of error conditions on an
  association. The entire ERROR chunk as it appears on the wire
  is included in an SCTP_REMOTE_ERROR event. Please refer to the
  SCTP specification [RFC4960] and any extensions for a list of
  possible error formats. An SCTP error notification has the
  following format:

  struct sctp_remote_error {
    uint16_t sre_type;
    uint16_t sre_flags;
    uint32_t sre_length;
    uint16_t sre_error;
    <-- 2 bytes hole  -->
    sctp_assoc_t sre_assoc_id;
    uint8_t  sre_data[];

Fix this by setting both to 0 before filling them out. We also
have other structures shared between user and kernel space in
SCTP that contains holes (e.g. struct sctp_paddrthlds), but we
copy that buffer over from user space first and thus don't need
to care about it in that cases.

While at it, we can also remove lengthy comments copied from
the draft, instead, we update the comment with the correct RFC
number where one can look it up.

Signed-off-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoappletalk: Fix socket referencing in skb
Andrey Utkin [Mon, 7 Jul 2014 20:22:50 +0000 (23:22 +0300)]
appletalk: Fix socket referencing in skb

[ Upstream commit 36beddc272c111689f3042bf3d10a64d8a805f93 ]

Setting just skb->sk without taking its reference and setting a
destructor is invalid. However, in the places where this was done, skb
is used in a way not requiring skb->sk setting. So dropping the setting
of skb->sk.
Thanks to Eric Dumazet <> for correct solution.

Reported-by: Ed Martin <>
Signed-off-by: Andrey Utkin <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoigmp: fix the problem when mc leave group
dingtianhong [Wed, 2 Jul 2014 05:50:48 +0000 (13:50 +0800)]
igmp: fix the problem when mc leave group

[ Upstream commit 52ad353a5344f1f700c5b777175bdfa41d3cd65a ]

The problem was triggered by these steps:

1) create socket, bind and then setsockopt for add mc group.
   mreq.imr_multiaddr.s_addr = inet_addr("");
   mreq.imr_interface.s_addr = inet_addr("");
   setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));

2) drop the mc group for this socket.
   mreq.imr_multiaddr.s_addr = inet_addr("");
   mreq.imr_interface.s_addr = inet_addr("");
   setsockopt(sockfd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));

3) and then drop the socket, I found the mc group was still used by the dev:

   netstat -g

   Interface       RefCnt Group
   --------------- ------ ---------------------
   eth2    1

Normally even though the IP_DROP_MEMBERSHIP return error, the mc group still need
to be released for the netdev when drop the socket, but this process was broken when
route default is NULL, the reason is that:

The ip_mc_leave_group() will choose the in_dev by the imr_interface.s_addr, if input addr
is NULL, the default route dev will be chosen, then the ifindex is got from the dev,
then polling the inet->mc_list and return -ENODEV, but if the default route dev is NULL,
the in_dev and ifIndex is both NULL, when polling the inet->mc_list, the mc group will be
released from the mc_list, but the dev didn't dec the refcnt for this mc group, so
when dropping the socket, the mc_list is NULL and the dev still keep this group.

v1->v2: According Hideaki's suggestion, we should align with IPv6 (RFC3493) and BSDs,
so I add the checking for the in_dev before polling the mc_list, make sure when
we remove the mc group, dec the refcnt to the real dev which was using the mc address.
The problem would never happened again.

Signed-off-by: Ding Tianhong <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years ago8021q: fix a potential memory leak
Li RongQing [Wed, 18 Jun 2014 05:46:02 +0000 (13:46 +0800)]
8021q: fix a potential memory leak

[ Upstream commit 916c1689a09bc1ca81f2d7a34876f8d35aadd11b ]

skb_cow called in vlan_reorder_header does not free the skb when it failed,
and vlan_reorder_header returns NULL to reset original skb when it is called
in vlan_untag, lead to a memory leak.

Signed-off-by: Li RongQing <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agotcp: fix tcp_match_skb_to_sack() for unaligned SACK at end of an skb
Neal Cardwell [Thu, 19 Jun 2014 01:15:03 +0000 (21:15 -0400)]
tcp: fix tcp_match_skb_to_sack() for unaligned SACK at end of an skb

[ Upstream commit 2cd0d743b05e87445c54ca124a9916f22f16742e ]

If there is an MSS change (or misbehaving receiver) that causes a SACK
to arrive that covers the end of an skb but is less than one MSS, then
tcp_match_skb_to_sack() was rounding up pkt_len to the full length of
the skb ("Round if necessary..."), then chopping all bytes off the skb
and creating a zero-byte skb in the write queue.

This was visible now because the recently simplified TLP logic in
bef1909ee3ed1c ("tcp: fixing TLP's FIN recovery") could find that 0-byte
skb at the end of the write queue, and now that we do not check that
skb's length we could send it as a TLP probe.

Consider the following example scenario:

 mss: 1000
 skb: seq: 0 end_seq: 4000  len: 4000
 SACK: start_seq: 3999 end_seq: 4000

The tcp_match_skb_to_sack() code will compute:

 in_sack = false
 pkt_len = start_seq - TCP_SKB_CB(skb)->seq = 3999 - 0 = 3999
 new_len = (pkt_len / mss) * mss = (3999/1000)*1000 = 3000
 new_len += mss = 4000

Previously we would find the new_len > skb->len check failing, so we
would fall through and set pkt_len = new_len = 4000 and chop off
pkt_len of 4000 from the 4000-byte skb, leaving a 0-byte segment
afterward in the write queue.

With this new commit, we notice that the new new_len >= skb->len check
succeeds, so that we return without trying to fragment.

Fixes: adb92db857ee ("tcp: Make SACK code to split only at mss boundaries")
Reported-by: Eric Dumazet <>
Signed-off-by: Neal Cardwell <>
Cc: Eric Dumazet <>
Cc: Yuchung Cheng <>
Cc: Ilpo Jarvinen <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agousb: Check if port status is equal to RxDetect
Gavin Guo [Thu, 17 Jul 2014 17:12:13 +0000 (01:12 +0800)]
usb: Check if port status is equal to RxDetect

commit bb86cf569bbd7ad4dce581a37c7fbd748057e9dc upstream.

When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd
(USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
some experiments, the bug can be fixed by avoiding executing the function
hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
XHCI Controlleris [1022:7814] is already in RxDetect
(I tried printing out the port status before setting to Disabled state),
it's reasonable to check the port status before really executing

Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.)
Signed-off-by: Gavin Guo <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: use hub device as context for dev_dbg(),
 as hub ports are not devices in their own right]
Signed-off-by: Ben Hutchings <>
7 years agodrm/radeon: avoid leaking edid data
Alex Deucher [Mon, 14 Jul 2014 21:57:19 +0000 (17:57 -0400)]
drm/radeon: avoid leaking edid data

commit 0ac66effe7fcdee55bda6d5d10d3372c95a41920 upstream.

In some cases we fetch the edid in the detect() callback
in order to determine what sort of monitor is connected.
If that happens, don't fetch the edid again in the get_modes()
callback or we will leak the edid.

Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (adt7470) Fix writes to temperature limit registers
Guenter Roeck [Thu, 17 Jul 2014 00:40:31 +0000 (17:40 -0700)]
hwmon: (adt7470) Fix writes to temperature limit registers

commit de12d6f4b10b21854441f5242dcb29ea96181e58 upstream.

Temperature limit registers are signed. Limits therefore need
to be clamped to (-128, 127) degrees C and not to (0, 255)
degrees C.

Without this fix, writing a limit of 128 degrees C sets the
actual limit to -128 degrees C.

Signed-off-by: Guenter Roeck <>
Reviewed-by: Axel Lin <>
[bwh: Backported to 3.2: driver was using SENSORS_LIMIT(), which we can
 replace with clamp_val()]
Signed-off-by: Ben Hutchings <>
7 years agolocking/mutex: Disable optimistic spinning on some architectures
Peter Zijlstra [Fri, 6 Jun 2014 17:53:16 +0000 (19:53 +0200)]
locking/mutex: Disable optimistic spinning on some architectures

commit 4badad352a6bb202ec68afa7a574c0bb961e5ebc upstream.

The optimistic spin code assumes regular stores and cmpxchg() play nice;
this is found to not be true for at least: parisc, sparc32, tile32,
metag-lock1, arc-!llsc and hexagon.

There is further wreckage, but this in particular seemed easy to
trigger, so blacklist this.

Opt in for known good archs.

Signed-off-by: Peter Zijlstra <>
Reported-by: Mikulas Patocka <>
Cc: David Miller <>
Cc: Chris Metcalf <>
Cc: James Bottomley <>
Cc: Vineet Gupta <>
Cc: Jason Low <>
Cc: Waiman Long <>
Cc: "James E.J. Bottomley" <>
Cc: Paul McKenney <>
Cc: John David Anglin <>
Cc: James Hogan <>
Cc: Linus Torvalds <>
Cc: Davidlohr Bueso <>
Cc: Benjamin Herrenschmidt <>
Cc: Catalin Marinas <>
Cc: Russell King <>
Cc: Will Deacon <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - Adjust context
 - Drop arm64 change]
Signed-off-by: Ben Hutchings <>
7 years agosched: Fix possible divide by zero in avg_atom() calculation
Mateusz Guzik [Sat, 14 Jun 2014 13:00:09 +0000 (15:00 +0200)]
sched: Fix possible divide by zero in avg_atom() calculation

commit b0ab99e7736af88b8ac1b7ae50ea287fffa2badc upstream.

proc_sched_show_task() does:

  if (nr_switches)
do_div(avg_atom, nr_switches);

nr_switches is unsigned long and do_div truncates it to 32 bits, which
means it can test non-zero on e.g. x86-64 and be truncated to zero for

Fix the problem by using div64_ul() instead.

As a side effect calculations of avg_atom for big nr_switches are now correct.

Signed-off-by: Mateusz Guzik <>
Signed-off-by: Peter Zijlstra <>
Cc: Linus Torvalds <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agoinclude/linux/math64.h: add div64_ul()
Alex Shi [Wed, 12 Jun 2013 21:05:10 +0000 (14:05 -0700)]
include/linux/math64.h: add div64_ul()

commit c2853c8df57f49620d26f317d7d43347c29bfc2e upstream.

There is div64_long() to handle the s64/long division, but no mocro do
u64/ul division.  It is necessary in some scenarios, so add this

[ coding-style fixes]
Signed-off-by: Alex Shi <>
Cc: Ingo Molnar <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agoring-buffer: Fix polling on trace_pipe
Martin Lau [Tue, 10 Jun 2014 06:06:42 +0000 (23:06 -0700)]
ring-buffer: Fix polling on trace_pipe

commit 97b8ee845393701edc06e27ccec2876ff9596019 upstream.

ring_buffer_poll_wait() should always put the poll_table to its wait_queue
even there is immediate data available.  Otherwise, the following epoll and
read sequence will eventually hang forever:

1. Put some data to make the trace_pipe ring_buffer read ready first
2. epoll_ctl(efd, EPOLL_CTL_ADD, trace_pipe_fd, ee)
3. epoll_wait()
4. read(trace_pipe_fd) till EAGAIN
5. Add some more data to the trace_pipe ring_buffer
6. epoll_wait() -> this epoll_wait() will block forever

~ During the epoll_ctl(efd, EPOLL_CTL_ADD,...) call in step 2,
  ring_buffer_poll_wait() returns immediately without adding poll_table,
  which has poll_table->_qproc pointing to ep_poll_callback(), to its
~ During the epoll_wait() call in step 3 and step 6,
  ring_buffer_poll_wait() cannot add ep_poll_callback() to its wait_queue
  because the poll_table->_qproc is NULL and it is how epoll works.
~ When there is new data available in step 6, ring_buffer does not know
  it has to call ep_poll_callback() because it is not in its wait queue.
  Hence, block forever.

Other poll implementation seems to call poll_wait() unconditionally as the very
first thing to do.  For example, tcp_poll() in tcp.c.

Fixes: 2a2cc8f7c4d0 "ftrace: allow the event pipe to be polled"
Reviewed-by: Chris Mason <>
Signed-off-by: Martin Lau <>
Signed-off-by: Steven Rostedt <>
[bwh: Backported to 3.2: the poll implementation looks rather different
 but does have a conditional return before and after the poll_wait() call;
 delete the return before it.]
Signed-off-by: Ben Hutchings <>
7 years agonet/l2tp: don't fall back on UDP [get|set]sockopt
Sasha Levin [Tue, 15 Jul 2014 00:02:31 +0000 (17:02 -0700)]
net/l2tp: don't fall back on UDP [get|set]sockopt

commit 3cf521f7dc87c031617fd47e4b7aa2593c2f3daf upstream.

The l2tp [get|set]sockopt() code has fallen back to the UDP functions
for socket option levels != SOL_PPPOL2TP since day one, but that has
never actually worked, since the l2tp socket isn't an inet socket.

As David Miller points out:

  "If we wanted this to work, it'd have to look up the tunnel and then
   use tunnel->sk, but I wonder how useful that would be"

Since this can never have worked so nobody could possibly have depended
on that functionality, just remove the broken code and return -EINVAL.

Reported-by: Sasha Levin <>
Acked-by: James Chapman <>
Acked-by: David Miller <>
Cc: Phil Turnbull <>
Cc: Vegard Nossum <>
Cc: Willy Tarreau <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agodrm/radeon/dp: return -EIO for flags not zero case
Alex Deucher [Thu, 3 Jul 2014 15:17:55 +0000 (11:17 -0400)]
drm/radeon/dp: return -EIO for flags not zero case

commit f6be5e64500abbba44e191e1ca0f3366c7d0291b upstream.

If there are error flags in the aux transaction return
-EIO rather than -EBUSY.  -EIO restarts the whole transaction
while -EBUSY jus retries.  Fixes problematic aux transfers.


Signed-off-by: Alex Deucher <>
[bwh: Backported to 3.2: error code is returned directly here]
Signed-off-by: Ben Hutchings <>
7 years agodm io: fix a race condition in the wake up code for sync_io
Joe Thornber [Fri, 27 Jun 2014 19:29:04 +0000 (15:29 -0400)]
dm io: fix a race condition in the wake up code for sync_io

commit 10f1d5d111e8aed46a0f1179faf9a3cf422f689e upstream.

There's a race condition between the atomic_dec_and_test(&io->count)
in dec_count() and the waking of the sync_io() thread.  If the thread
is spuriously woken immediately after the decrement it may exit,
making the on stack io struct invalid, yet the dec_count could still
be using it.

Fix this race by using a completion in sync_io() and dec_count().

Reported-by: Minfei Huang <>
Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Acked-by: Mikulas Patocka <>
[bwh: Backported to 3.2: use wait_for_completion() as wait_for_completion_io()
 is not available]
Signed-off-by: Ben Hutchings <>
7 years agoigb: do a reset on SR-IOV re-init if device is down
Stefan Assmann [Thu, 10 Jul 2014 10:29:39 +0000 (03:29 -0700)]
igb: do a reset on SR-IOV re-init if device is down

commit 76252723e88681628a3dbb9c09c963e095476f73 upstream.

To properly re-initialize SR-IOV it is necessary to reset the device
even if it is already down. Not doing this may result in Tx unit hangs.

Signed-off-by: Stefan Assmann <>
Tested-by: Aaron Brown <>
Signed-off-by: Jeff Kirsher <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: ftdi_sio: Add extra PID.
Bert Vermeulen [Tue, 8 Jul 2014 12:42:23 +0000 (14:42 +0200)]
USB: ftdi_sio: Add extra PID.

commit 5a7fbe7e9ea0b1b9d7ffdba64db1faa3a259164c upstream.

This patch adds PID 0x0003 to the VID 0x128d (Testo). At least the
Testo 435-4 uses this, likely other gear as well.

Signed-off-by: Bert Vermeulen <>
Cc: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoalarmtimer: Fix bug where relative alarm timers were treated as absolute
John Stultz [Mon, 7 Jul 2014 21:06:11 +0000 (14:06 -0700)]
alarmtimer: Fix bug where relative alarm timers were treated as absolute

commit 16927776ae757d0d132bdbfabbfe2c498342bd59 upstream.

Sharvil noticed with the posix timer_settime interface, using the
tried to specify a relative time timer, it would incorrectly be
treated as absolute regardless of the state of the flags argument.

This patch corrects this, properly checking the absolute/relative flag,
as well as adds further error checking that no invalid flag bits are set.

Reported-by: Sharvil Nanavati <>
Signed-off-by: John Stultz <>
Cc: Thomas Gleixner <>
Cc: Ingo Molnar <>
Cc: Prarit Bhargava <>
Cc: Sharvil Nanavati <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (emc2103) Clamp limits instead of bailing out
Guenter Roeck [Sun, 6 Jul 2014 18:39:24 +0000 (11:39 -0700)]
hwmon: (emc2103) Clamp limits instead of bailing out

commit f6c2dd20108c35e30e2c1f3c6142d189451a626b upstream.

It is customary to clamp limits instead of bailing out with an error
if a configured limit is out of the range supported by the driver.
This simplifies limit configuration, since the user will not typically
know chip and/or driver specific limits.

Reviewed-by: Jean Delvare <>
Signed-off-by: Guenter Roeck <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agofuse: handle large user and group ID
Miklos Szeredi [Mon, 7 Jul 2014 13:28:51 +0000 (15:28 +0200)]
fuse: handle large user and group ID

commit 233a01fa9c4c7c41238537e8db8434667ff28a2f upstream.

If the number in "user_id=N" or "group_id=N" mount options was larger than
INT_MAX then fuse returned EINVAL.

Fix this to handle all valid uid/gid values.

Signed-off-by: Miklos Szeredi <>
[bwh: Backported to 3.2: no user namespace conversion]
Signed-off-by: Ben Hutchings <>
7 years agofuse: timeout comparison fix
Miklos Szeredi [Mon, 7 Jul 2014 13:28:50 +0000 (15:28 +0200)]
fuse: timeout comparison fix

commit 126b9d4365b110c157bc4cbc32540dfa66c9c85a upstream.

As suggested by, use time_before64() instead of direct
comparison of jiffies64 values.

Signed-off-by: Miklos Szeredi <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (adm1031) Fix writes to limit registers
Guenter Roeck [Thu, 3 Jul 2014 20:44:23 +0000 (13:44 -0700)]
hwmon: (adm1031) Fix writes to limit registers

commit 145e74a4e5022225adb84f4e5d4fff7938475c35 upstream.

Upper limit for write operations to temperature limit registers
was clamped to a fractional value. However, limit registers do
not support fractional values. As a result, upper limits of 127.5
degrees C or higher resulted in a rounded limit of 128 degrees C.
Since limit registers are signed, this was stored as -128 degrees C.
Clamp limits to (-55, +127) degrees C to solve the problem.

Value on writes to auto_temp[12]_min and auto_temp[12]_max were not
clamped at all, but masked. As a result, out-of-range writes resulted
in a more or less arbitrary limit. Clamp those attributes to (0, 127)
degrees C for more predictable results.

Cc: Axel Lin <>
Reviewed-by: Jean Delvare <>
Signed-off-by: Guenter Roeck <>
[bwh: Backported to 3.2:
 - Adjust context
 - Driver was using SENSORS_LIMIT(), which we can replace with clamp_val()]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / battery: Retry to get battery information if failed during probing
Lan Tianyu [Mon, 7 Jul 2014 07:47:12 +0000 (15:47 +0800)]
ACPI / battery: Retry to get battery information if failed during probing

commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream.

Some machines (eg. Lenovo Z480) ECs are not stable during boot up
and causes battery driver fails to be loaded due to failure of getting
battery information from EC sometimes. After several retries, the
operation will work. This patch is to retry to get battery information 5
times if the first try fails.

Reported-and-tested-by: naszar <>
Signed-off-by: Lan Tianyu <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: acpi_battery_update() doesn't take a second parameter]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Fix race condition in ec_transaction_completed()
Lv Zheng [Sun, 15 Jun 2014 00:42:07 +0000 (08:42 +0800)]
ACPI / EC: Fix race condition in ec_transaction_completed()

commit c0d653412fc8450370167a3268b78fc772ff9c87 upstream.

There is a race condition in ec_transaction_completed().

When ec_transaction_completed() is called in the GPE handler, it could
return true because of (ec->curr == NULL). Then the wake_up() invocation
could complete the next command unexpectedly since there is no lock between
the 2 invocations. With the previous cleanup, the IBF=0 waiter race need
not be handled any more. It's now safe to return a flag from
advance_condition() to indicate the requirement of wakeup, the flag is
returned from a locked context.

The ec_transaction_completed() is now only invoked by the ec_poll() where
the ec->curr is ensured to be different from NULL.

After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup
condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a
QR_SC command.

Reported-and-tested-by: Gareth Williams <>
Reported-and-tested-by: Hans de Goede <>
Reported-by: Barton Xu <>
Tested-by: Steffen Weber <>
Tested-by: Arthur Chen <>
Signed-off-by: Lv Zheng <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Remove duplicated ec_wait_ibf0() waiter
Lv Zheng [Sun, 15 Jun 2014 00:41:48 +0000 (08:41 +0800)]
ACPI / EC: Remove duplicated ec_wait_ibf0() waiter

commit 9b80f0f73ae1583c22325ede341c74195847618c upstream.

After we've added the first command byte write into advance_transaction(),
the IBF=0 waiter is duplicated with the command completion waiter
implemented in the ec_poll() because:
   If IBF=1 blocked the first command byte write invoked in the task
   context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed
   out and retried again in the task context.

Remove this seperate and duplicate IBF=0 waiter.  By doing so we can
reduce the overall number of times to access the EC_SC(R) status

Reported-and-tested-by: Gareth Williams <>
Reported-and-tested-by: Hans de Goede <>
Reported-by: Barton Xu <>
Tested-by: Steffen Weber <>
Tested-by: Arthur Chen <>
Signed-off-by: Lv Zheng <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Add asynchronous command byte write support
Lv Zheng [Sun, 15 Jun 2014 00:41:35 +0000 (08:41 +0800)]
ACPI / EC: Add asynchronous command byte write support

commit f92fca0060fc4dc9227342d0072d75df98c1e5a5 upstream.

Move the first command byte write into advance_transaction() so that all
EC register accesses that can affect the command processing state machine
can happen in this asynchronous state machine advancement function.

The advance_transaction() function then can be a complete implementation
of an asyncrhonous transaction for a single command so that:
 1. The first command byte can be written in the interrupt context;
 2. The command completion waiter can also be used to wait the first command
    byte's timeout;
 3. In BURST mode, the follow-up command bytes can be written in the
    interrupt context directly, so that it doesn't need to return to the
    task context. Returning to the task context reduces the throughput of
    the BURST mode and in the worst cases where the system workload is very
    high, this leads to the hardware driven automatic BURST mode exit.

In order not to increase memory consumption, convert 'done' into 'flags'
to contain multiple indications:
 1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition,
    indicating the completion of the command transaction.
 2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first
    command byte. A new command can utilize this flag to compete for the
    right of accessing the underlying hardware. There is a follow-up bug
    fix that has utilized this new flag.

The 2 flags are important because it also reflects a key concept of IO
programs' design used in the system softwares. Normally an IO program
running in the kernel should first be implemented in the asynchronous way.
And the 2 flags are the most common way to implement its synchronous
operations on top of the asynchronous operations:
1. POLL: This flag can be used to block until the asynchronous operations
         can happen.
2. COMPLETE: This flag can be used to block until the asynchronous
             operations have completed.
By constructing code cleanly in this way, many difficult problems can be
solved smoothly.

Reported-and-tested-by: Gareth Williams <>
Reported-and-tested-by: Hans de Goede <>
Reported-by: Barton Xu <>
Tested-by: Steffen Weber <>
Tested-by: Arthur Chen <>
Signed-off-by: Lv Zheng <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/ec->lock/ec->curr_lock/]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Don't count a SCI interrupt as a false one
Feng Tang [Mon, 22 Oct 2012 23:30:12 +0000 (01:30 +0200)]
ACPI / EC: Don't count a SCI interrupt as a false one

commit a3cd8d2789c2e265e09377f260e7d2ac9cec81bb upstream.

Currently when advance_transaction() is called in EC interrupt handler,
if there is nothing driver can do with the interrupt, it will be taken
as a false one.

But this is not always true, as there may be a SCI EC interrupt fired
during normal read/write operation, which should not be counted as a
false one. This patch fixes the problem.

Signed-off-by: Feng Tang <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Avoid race condition related to advance_transaction()
Lv Zheng [Sun, 15 Jun 2014 00:41:17 +0000 (08:41 +0800)]
ACPI / EC: Avoid race condition related to advance_transaction()

commit 66b42b78bc1e816f92b662e8888c89195e4199e1 upstream.

The advance_transaction() will be invoked from the IRQ context GPE handler
and the task context ec_poll(). The handling of this function is locked so
that the EC state machine are ensured to be advanced sequentially.

But there is a problem. Before invoking advance_transaction(), EC_SC(R) is
read. Then for advance_transaction(), there could be race condition around
the lock from both contexts. The first one reading the register could fail
this race and when it passes the stale register value to the state machine
advancement code, the hardware condition is totally different from when
the register is read. And the hardware accesses determined from the wrong
hardware status can break the EC state machine. And there could be cases
that the functionalities of the platform firmware are seriously affected.
For example:
 1. When 2 EC_DATA(W) writes compete the IBF=0, the 2nd EC_DATA(W) write may
    be invalid due to IBF=1 after the 1st EC_DATA(W) write. Then the
    hardware will either refuse to respond a next EC_SC(W) write of the next
    command or discard the current WR_EC command when it receives a EC_SC(W)
    write of the next command.
 2. When 1 EC_SC(W) write and 1 EC_DATA(W) write compete the IBF=0, the
    EC_DATA(W) write may be invalid due to IBF=1 after the EC_SC(W) write.
    The next EC_DATA(R) could never be responded by the hardware. This is
    the root cause of the reported issue.

Fix this issue by moving the EC_SC(R) access into the lock so that we can
ensure that the state machine is advanced consistently.

Reported-and-tested-by: Gareth Williams <>
Reported-and-tested-by: Hans de Goede <>
Reported-by: Barton Xu <>
Tested-by: Steffen Weber <>
Tested-by: Arthur Chen <>
Signed-off-by: Lv Zheng <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use PREFIX in log message]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Ensure lock is acquired before accessing ec struct members
Puneet Kumar [Fri, 15 Nov 2013 19:41:29 +0000 (11:41 -0800)]
ACPI / EC: Ensure lock is acquired before accessing ec struct members

commit 36b15875a7819a2ec4cb5748ff7096ad7bd86cbb upstream.

A bug was introduced by commit b76b51ba0cef ('ACPI / EC: Add more debug
info and trivial code cleanup') that erroneously caused the struct member
to be accessed before acquiring the required lock.  This change fixes
it by ensuring the lock acquisition is done first.

Found by Aaron Durbin <>

Fixes: b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup')
Signed-off-by: Puneet Kumar <>
Reviewed-by: Aaron Durbin <>
[olof: Commit message reworded a bit]
Signed-off-by: Olof Johansson <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Add more debug info and trivial code cleanup
Feng Tang [Mon, 22 Oct 2012 23:29:38 +0000 (01:29 +0200)]
ACPI / EC: Add more debug info and trivial code cleanup

commit b76b51ba0cef13980813373a548a12206e3cd3c9 upstream.

Add more debug info for EC transaction debugging, like the interrupt
status register value, the detail info of a EC transaction.

Signed-off-by: Feng Tang <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agousb: option: Add ID for Telewell TW-LTE 4G v2
Bernd Wachter [Wed, 2 Jul 2014 09:36:48 +0000 (12:36 +0300)]
usb: option: Add ID for Telewell TW-LTE 4G v2

commit 3d28bd840b2d3981cd28caf5fe1df38f1344dd60 upstream.

Add ID of the Telewell 4G v2 hardware to option driver to get legacy
serial interface working

Signed-off-by: Bernd Wachter <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: cp210x: add support for Corsair usb dongle
Andras Kovacs [Fri, 27 Jun 2014 12:50:11 +0000 (14:50 +0200)]
USB: cp210x: add support for Corsair usb dongle

commit b9326057a3d8447f5d2e74a7b521ccf21add2ec0 upstream.

Corsair USB Dongles are shipped with Corsair AXi series PSUs.
These are cp210x serial usb devices, so make driver detect these.
I have a program, that can get information from these PSUs.

Tested with 2 different dongles shipped with Corsair AX860i and
AX1200i units.

Signed-off-by: Andras Kovacs <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
7 years agoext4: disable synchronous transaction batching if max_batch_time==0
Eric Sandeen [Sat, 5 Jul 2014 23:18:22 +0000 (19:18 -0400)]
ext4: disable synchronous transaction batching if max_batch_time==0

commit 5dd214248f94d430d70e9230bda72f2654ac88a8 upstream.

The mount manpage says of the max_batch_time option,

This optimization can be turned off entirely
by setting max_batch_time to 0.

But the code doesn't do that.  So fix the code to do

Signed-off-by: Eric Sandeen <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2: option parsing looks different]
Signed-off-by: Ben Hutchings <>
7 years agoext4: clarify error count warning messages
Theodore Ts'o [Sat, 5 Jul 2014 22:40:52 +0000 (18:40 -0400)]
ext4: clarify error count warning messages

commit ae0f78de2c43b6fadd007c231a352b13b5be8ed2 upstream.

Make it clear that values printed are times, and that it is error
since last fsck. Also add note about fsck version required.

Signed-off-by: Pavel Machek <>
Signed-off-by: Theodore Ts'o <>
Reviewed-by: Andreas Dilger <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div
Axel Lin [Wed, 2 Jul 2014 00:29:55 +0000 (08:29 +0800)]
hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div

commit 1035a9e3e9c76b64a860a774f5b867d28d34acc2 upstream.

Writing to fanX_div does not clear the cache. As a result, reading
from fanX_div may return the old value for up to two seconds
after writing a new value.

This patch ensures the fan_div cache is updated in set_fan_div().

Reported-by: Guenter Roeck <>
Signed-off-by: Axel Lin <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (amc6821) Fix permissions for temp2_input
Axel Lin [Tue, 1 Jul 2014 23:44:44 +0000 (07:44 +0800)]
hwmon: (amc6821) Fix permissions for temp2_input

commit df86754b746e9a0ff6f863f690b1c01d408e3cdc upstream.

temp2_input should not be writable, fix it.

Reported-by: Guenter Roeck <>
Signed-off-by: Axel Lin <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
7 years agodrm/vmwgfx: Fix incorrect write to read-only register v2:
Thomas Hellstrom [Wed, 2 Jul 2014 13:47:04 +0000 (15:47 +0200)]
drm/vmwgfx: Fix incorrect write to read-only register v2:

commit 4e578080ed3262ed2c3985868539bc66218d25c0 upstream.

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to

This patch is Cc'd stable because of the unknown effects writing to this
register might have, particularly on older device versions.

v2: Updated log message.

Cc: Christopher Friedt <>
Tested-by: Christopher Friedt <>
Signed-off-by: Thomas Hellstrom <>
Reviewed-by: Jakob Bornecrantz <>
Signed-off-by: Ben Hutchings <>
7 years agoiwlwifi: dvm: don't enable CTS to self
Emmanuel Grumbach [Wed, 25 Jun 2014 06:12:30 +0000 (09:12 +0300)]
iwlwifi: dvm: don't enable CTS to self

commit 43d826ca5979927131685cc2092c7ce862cb91cd upstream.

We should always prefer to use full RTS protection. Using
CTS to self gives a meaningless improvement, but this flow
is much harder for the firmware which is likely to have
issues with it.

Signed-off-by: Emmanuel Grumbach <>
[bwh: Backported to 3.2:
 - Adjust filename
 - Condition for RXON_FLG_SELF_CTS_EN in iwlagn_commit_rxon() was different]
Signed-off-by: Ben Hutchings <>
7 years agoxen/manage: fix potential deadlock when resuming the console
David Vrabel [Wed, 2 Jul 2014 16:25:23 +0000 (17:25 +0100)]
xen/manage: fix potential deadlock when resuming the console

commit 1b6478231c6f5f844185acb32045cf195028cfce upstream.

Calling xen_console_resume() in xen_suspend() causes a warning because
it locks irq_mapping_update_lock (a mutex) and this may sleep.  If a
userspace process is using the evtchn device then this mutex may be
locked at the point of the stop_machine() call and
xen_console_resume() would then deadlock.

Resuming the console after stop_machine() returns avoids this

Signed-off-by: David Vrabel <>
Reviewed-by: Boris Ostrovsky <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agomd: flush writes before starting a recovery.
NeilBrown [Wed, 2 Jul 2014 02:04:14 +0000 (12:04 +1000)]
md: flush writes before starting a recovery.

commit 133d4527eab8d199a62eee6bd433f0776842df2e upstream.

When we write to a degraded array which has a bitmap, we
make sure the relevant bit in the bitmap remains set when
the write completes (so a 're-add' can quickly rebuilt a
temporarily-missing device).

If, immediately after such a write starts, we incorporate a spare,
commence recovery, and skip over the region where the write is
happening (because the 'needs recovery' flag isn't set yet),
then that write will not get to the new device.

Once the recovery finishes the new device will be trusted, but will
have incorrect data, leading to possible corruption.

We cannot set the 'needs recovery' flag when we start the write as we
do not know easily if the write will be "degraded" or not.  That
depends on details of the particular raid level and particular write

This patch fixes a corruption issue of long standing and so it
suitable for any -stable kernel.  It applied correctly to 3.0 at
least and will minor editing to earlier kernels.

Reported-by: Bill <>
Tested-by: Bill <>
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
7 years agoperf/x86/intel: ignore CondChgd bit to avoid false NMI handling
HATAYAMA Daisuke [Wed, 25 Jun 2014 01:09:07 +0000 (10:09 +0900)]
perf/x86/intel: ignore CondChgd bit to avoid false NMI handling

commit b292d7a10487aee6e74b1c18b8d95b92f40d4a4f upstream.

Currently, any NMI is falsely handled by a NMI handler of NMI watchdog
if CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR is set.

For example, we use external NMI to make system panic to get crash
dump, but in this case, the external NMI is falsely handled do to the

This commit deals with the issue simply by ignoring CondChgd bit.

Here is explanation in detail.

On x86 NMI watchdog uses performance monitoring feature to
periodically signal NMI each time performance counter gets overflowed.

intel_pmu_handle_irq() is called as a NMI_LOCAL handler from a NMI
handler of NMI watchdog, perf_event_nmi_handler(). It identifies an
owner of a given NMI by looking at overflow status bits in
MSR_CORE_PERF_GLOBAL_STATUS MSR. If some of the bits are set, then it
handles the given NMI as its own NMI.

The problem is that the intel_pmu_handle_irq() doesn't distinguish
CondChgd bit from other bits. Unlike the other status bits, CondChgd
bit doesn't represent overflow status for performance counters. Thus,
CondChgd bit cannot be thought of as a mark indicating a given NMI is
NMI watchdog's.

As a result, if CondChgd bit is set, any NMI is falsely handled by the
NMI handler of NMI watchdog. Also, if type of the falsely handled NMI
is either NMI_UNKNOWN, NMI_SERR or NMI_IO_CHECK, the corresponding
action is never performed until CondChgd bit is cleared.

I noticed this behavior on systems with Ivy Bridge processors: Intel
Xeon CPU E5-2630 v2 and Intel Xeon CPU E7-8890 v2. On both systems,
CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR has already been set
in the beginning at boot. Then the CondChgd bit is immediately cleared
by next wrmsr to MSR_CORE_PERF_GLOBAL_CTRL MSR and appears to remain

On the other hand, on older processors such as Nehalem, Xeon E7540,
CondChgd bit is not set in the beginning at boot.

I'm not sure about exact behavior of CondChgd bit, in particular when
this bit is set. Although I read Intel System Programmer's Manual to
figure out that, the descriptions I found are:

  In 18.9.1:

  "The MSR_PERF_GLOBAL_STATUS MSR also provides a ¡sticky bit¢ to
   indicate changes to the state of performancmonitoring hardware"

  In Table 35-2 IA-32 Architectural MSRs

  63 CondChg: status bits of this register has changed.

These are different from the bahviour I see on the actual system as I
explained above.

At least, I think ignoring CondChgd bit should be enough for NMI
watchdog perspective.

Signed-off-by: HATAYAMA Daisuke <>
Acked-by: Don Zickus <>
Signed-off-by: Peter Zijlstra <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Linus Torvalds <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
7 years agousb-storage/SCSI: Add broken_fua blacklist flag
Alan Stern [Mon, 30 Jun 2014 15:04:21 +0000 (11:04 -0400)]
usb-storage/SCSI: Add broken_fua blacklist flag

commit b14bf2d0c0358140041d1c1805a674376964d0e0 upstream.

Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs.  This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by: Alan Stern <>
Reported-by: Michael Büsch <>
Tested-by: Michael Büsch <>
Acked-by: James Bottomley <>
CC: Matthew Dharm <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use sd_printk() not sd_first_printk()]
Signed-off-by: Ben Hutchings <>
7 years agotools: ffs-test: fix header values endianess
Michal Nazarewicz [Fri, 13 Jun 2014 13:38:05 +0000 (15:38 +0200)]
tools: ffs-test: fix header values endianess

commit f35f71244da6e51db4e1f2c7e318581f498ececf upstream.

It appears that no one ever run ffs-test on a big-endian machine,
since it used cpu-endianess for fs_count and hs_count fields which
should be in little-endian format.  Fix by wrapping the numbers in

Signed-off-by: Michal Nazarewicz <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
7 years agonfsd: fix rare symlink decoding bug
J. Bruce Fields [Thu, 19 Jun 2014 20:44:48 +0000 (16:44 -0400)]
nfsd: fix rare symlink decoding bug

commit 76f47128f9b33af1e96819746550d789054c9664 upstream.

An NFS operation that creates a new symlink includes the symlink data,
which is xdr-encoded as a length followed by the data plus 0 to 3 bytes
of zero-padding as required to reach a 4-byte boundary.

The vfs, on the other hand, wants null-terminated data.

The simple way to handle this would be by copying the data into a newly
allocated buffer with space for the final null.

The current nfsd_symlink code tries to be more clever by skipping that
step in the (likely) case where the byte following the string is already

But that assumes that the byte following the string is ours to look at.
In fact, it might be the first byte of a page that we can't read, or of
some object that another task might modify.

Worse, the NFSv4 code tries to fix the problem by actually writing to
that byte.

In the NFSv2/v3 cases this actually appears to be safe:

- nfs3svc_decode_symlinkargs explicitly null-terminates the data
  (after first checking its length and copying it to a new
- NFSv2 limits symlinks to 1k.  The buffer holding the rpc
  request is always at least a page, and the link data (and
  previous fields) have maximum lengths that prevent the request
  from reaching the end of a page.

In the NFSv4 case the CREATE op is potentially just one part of a long
compound so can end up on the end of a page if you're unlucky.

The minimal fix here is to copy and null-terminate in the NFSv4 case.
The nfsd_symlink() interface here seems too fragile, though.  It should
really either do the copy itself every time or just require a
null-terminated string.

Reported-by: Jeff Layton <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
7 years agomwifiex: fix Tx timeout issue
Amitkumar Karwar [Fri, 20 Jun 2014 18:45:25 +0000 (11:45 -0700)]
mwifiex: fix Tx timeout issue

commit d76744a93246eccdca1106037e8ee29debf48277 upstream.

It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.

The root cause is uninitialized fields in tx_info(skb->cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.

Reported-by: Andrew Wiley <>
Reported-by: Linus Gasser <>
Reported-by: Michael Hirsch <>
Tested-by: Xinming Hu <>
Signed-off-by: Amitkumar Karwar <>
Signed-off-by: Maithili Hinge <>
Signed-off-by: Avinash Patil <>
Signed-off-by: Bing Zhao <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agocpuset,mempolicy: fix sleeping function called from invalid context
Gu Zheng [Wed, 25 Jun 2014 01:57:18 +0000 (09:57 +0800)]
cpuset,mempolicy: fix sleeping function called from invalid context

commit 391acf970d21219a2a5446282d3b20eace0c0d7a upstream.

When runing with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python
[ 9969.441175] INFO: lockdep is turned off.
[ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G       A      3.15.0-rc7+ #85
[ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012
[ 9969.706052]  ffffffff81a20e60 ffff8803e941fbd0 ffffffff8162f523 ffff8803e941fd18
[ 9969.795323]  ffff8803e941fbe0 ffffffff8109995a ffff8803e941fc58 ffffffff81633e6c
[ 9969.884710]  ffffffff811ba5dc ffff880405c6b480 ffff88041fdd90a0 0000000000002000
[ 9969.974071] Call Trace:
[ 9970.003403]  [<ffffffff8162f523>] dump_stack+0x4d/0x66
[ 9970.065074]  [<ffffffff8109995a>] __might_sleep+0xfa/0x130
[ 9970.130743]  [<ffffffff81633e6c>] mutex_lock_nested+0x3c/0x4f0
[ 9970.200638]  [<ffffffff811ba5dc>] ? kmem_cache_alloc+0x1bc/0x210
[ 9970.272610]  [<ffffffff81105807>] cpuset_mems_allowed+0x27/0x140
[ 9970.344584]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.409282]  [<ffffffff811b1385>] __mpol_dup+0xe5/0x150
[ 9970.471897]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.536585]  [<ffffffff81068c86>] ? copy_process.part.23+0x606/0x1d40
[ 9970.613763]  [<ffffffff810bf28d>] ? trace_hardirqs_on+0xd/0x10
[ 9970.683660]  [<ffffffff810ddddf>] ? monotonic_to_bootbased+0x2f/0x50
[ 9970.759795]  [<ffffffff81068cf0>] copy_process.part.23+0x670/0x1d40
[ 9970.834885]  [<ffffffff8106a598>] do_fork+0xd8/0x380
[ 9970.894375]  [<ffffffff81110e4c>] ? __audit_syscall_entry+0x9c/0xf0
[ 9970.969470]  [<ffffffff8106a8c6>] SyS_clone+0x16/0x20
[ 9971.030011]  [<ffffffff81642009>] stub_clone+0x69/0x90
[ 9971.091573]  [<ffffffff81641c29>] ? system_call_fastpath+0x16/0x1b

The cause is that cpuset_mems_allowed() try to take
mutex_lock(&callback_mutex) under the rcu_read_lock(which was hold in
__mpol_dup()). And in cpuset_mems_allowed(), the access to cpuset is
under rcu_read_lock, so in __mpol_dup, we can reduce the rcu_read_lock
protection region to protect the access to cpuset only in
current_cpuset_is_being_rebound(). So that we can avoid this bug.

This patch is a temporary solution that just addresses the bug
mentioned above, can not fix the long-standing issue about cpuset.mems
rebinding on fork():

"When the forker's task_struct is duplicated (which includes
 ->mems_allowed) and it races with an update to cpuset_being_rebound
 in update_tasks_nodemask() then the task's mems_allowed doesn't get
 updated. And the child task's mems_allowed can be wrong if the
 cpuset's nodemask changes before the child has been added to the
 cgroup's tasklist."

Signed-off-by: Gu Zheng <>
Acked-by: Li Zefan <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
7 years agoibmvscsi: Add memory barriers for send / receive
Brian King [Fri, 23 May 2014 15:52:11 +0000 (10:52 -0500)]
ibmvscsi: Add memory barriers for send / receive

commit 7114aae02742d6b5c5a0d39a41deb61d415d3717 upstream.

Add a memory barrier prior to sending a new command to the VIOS
to ensure the VIOS does not receive stale data in the command buffer.
Also add a memory barrier when processing the CRQ for completed commands.

Signed-off-by: Brian King <>
Acked-by: Nathan Fontenot <>
Signed-off-by: Christoph Hellwig <>
[bwh: Backported to 3.2: as the iSeries code is still present, these
 functions have different names and live in rpa_vscsi.c.]
Signed-off-by: Ben Hutchings <>
7 years agoibmvscsi: Abort init sequence during error recovery
Brian King [Fri, 23 May 2014 15:52:10 +0000 (10:52 -0500)]
ibmvscsi: Abort init sequence during error recovery

commit 9ee755974bea2f9880e517ec985dc9dede1b3a36 upstream.

If a CRQ reset is triggered for some reason while in the middle
of performing VSCSI adapter initialization, we don't want to
call the done function for the initialization MAD commands as
this will only result in two threads attempting initialization
at the same time, resulting in failures.

Signed-off-by: Brian King <>
Acked-by: Nathan Fontenot <>
Signed-off-by: Christoph Hellwig <>
Signed-off-by: Ben Hutchings <>
7 years agoxhci: Fix runtime suspended xhci from blocking system suspend.
Wang, Yu [Tue, 24 Jun 2014 14:14:44 +0000 (17:14 +0300)]
xhci: Fix runtime suspended xhci from blocking system suspend.

commit d6236f6d1d885aa19d1cd7317346fe795227a3cc upstream.

The system suspend flow as following:
1, Freeze all user processes and kenrel threads.

2, Try to suspend all devices.

2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.

2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2&usb3 roothub devices.

2.3, Call suspend callbacks of devices.

2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.

2.3.2, Finally, hcd_pci_suspend callback is called.

Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.

The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.

For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.

xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.

This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb
"USB: XHCI: resume root hubs when the controller resumes"

Signed-off-by: Wang, Yu <>
Acked-by: Alan Stern <>
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoxhci: clear root port wake on bits if controller isn't wake-up capable
Lu Baolu [Tue, 24 Jun 2014 14:14:43 +0000 (17:14 +0300)]
xhci: clear root port wake on bits if controller isn't wake-up capable

commit ff8cbf250b448aac35589f6075082c3fcad8a8fe upstream.

When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel
platforms may get a spurious wakeup, even if PCI PME# is disabled.

This patch should be back-ported to kernels as old as 2.6.37, that
contains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569
"USB: xHCI: bus power management implementation".

Signed-off-by: Lu Baolu <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoxhci: correct burst count field for isoc transfers on 1.0 xhci hosts
Mathias Nyman [Tue, 24 Jun 2014 14:14:41 +0000 (17:14 +0300)]
xhci: correct burst count field for isoc transfers on 1.0 xhci hosts

commit 3213b151387df0b95f4eada104f68eb1c1409cb3 upstream.

The transfer burst count (TBC) field in xhci 1.0 hosts should be set
to the number of bursts needed to transfer all packets in a isoc TD.
Supported values are 0-2 (1 to 3 bursts per service interval).

Formula for TBC calculation is given in xhci spec section
TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1

This patch should be applied to stable kernels since 3.0 that contain
the commit 5cd43e33b9519143f06f507dd7cbee6b7a621885
"xhci 1.0: Set transfer burst count field."

Suggested-by: ShiChun Ma <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agousb: option: add/modify Olivetti Olicard modems
Bjørn Mork [Fri, 6 Jun 2014 15:25:56 +0000 (17:25 +0200)]
usb: option: add/modify Olivetti Olicard modems

commit b0ebef36e93703e59003ad6a1a20227e47714417 upstream.

Adding a couple of Olivetti modems and blacklisting the net
function on a couple which are already supported.

Reported-by: Lars Melin <>
Signed-off-by: Bjørn Mork <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: ftdi_sio: fix null deref at port probe
Johan Hovold [Thu, 5 Jun 2014 14:05:52 +0000 (16:05 +0200)]
USB: ftdi_sio: fix null deref at port probe

commit aea1ae8760314e072bf1b773521e9de5d5dda10d upstream.

Fix NULL-pointer dereference when probing an interface with no

These devices have two bulk endpoints per interface, but this avoids
crashing the kernel if a user forces a non-FTDI device to be probed.

Note that the iterator variable was made unsigned in order to avoid
a maybe-uninitialized compiler warning for ep_desc after the loop.

Fixes: 895f28badce9 ("USB: ftdi_sio: fix hi-speed device packet size

Reported-by: Mike Remski <>
Tested-by: Mike Remski <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
7 years agousb: gadget: f_fs: fix NULL pointer dereference when there are no strings
Michal Nazarewicz [Tue, 17 Jun 2014 15:47:41 +0000 (17:47 +0200)]
usb: gadget: f_fs: fix NULL pointer dereference when there are no strings

commit f0688c8b81d2ea239c3fb0b848f623b579238d99 upstream.

If the descriptors do not need any strings and user space sends empty
set of strings, the ffs->stringtabs field remains NULL.  Thus
*ffs->stringtabs in functionfs_bind leads to a NULL pointer

The bug was introduced by commit [fd7c9a007f: “use usb_string_ids_n()”].

While at it, remove double initialisation of lang local variable in
that function.

ffs->strings_count does not need to be checked in any way since in
the above scenario it will remain zero and usb_string_ids_n() is
a no-operation when colled with 0 argument.

Signed-off-by: Michal Nazarewicz <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
7 years agoKVM: x86: preserve the high 32-bits of the PAT register
Paolo Bonzini [Thu, 19 Jun 2014 09:40:18 +0000 (11:40 +0200)]
KVM: x86: preserve the high 32-bits of the PAT register

commit 7cb060a91c0efc5ff94f83c6df3ed705e143cdb9 upstream.

KVM does not really do much with the PAT, so this went unnoticed for a
long time.  It is exposed however if you try to do rdmsr on the PAT

Reported-by: Valentine Sinitsyn <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
7 years agoKVM: x86: Increase the number of fixed MTRR regs to 10
Nadav Amit [Wed, 18 Jun 2014 14:21:19 +0000 (17:21 +0300)]
KVM: x86: Increase the number of fixed MTRR regs to 10

commit 682367c494869008eb89ef733f196e99415ae862 upstream.

Recent Intel CPUs have 10 variable range MTRRs. Since operating systems
sometime make assumptions on CPUs while they ignore capability MSRs, it is
better for KVM to be consistent with recent CPUs. Reporting more MTRRs than
actually supported has no functional implications.

Signed-off-by: Nadav Amit <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
7 years agoARM: OMAP2+: Fix parser-bug in platform muxing code
David R. Piegdon [Mon, 16 Jun 2014 23:42:51 +0000 (23:42 +0000)]
ARM: OMAP2+: Fix parser-bug in platform muxing code

commit c021f241f4fab2bb4fc4120a38a828a03dd3f970 upstream.

Fix a parser-bug in the omap2 muxing code where muxtable-entries will be
wrongly selected if the requested muxname is a *prefix* of their
m0-entry and they have a matching mN-entry. Fix by additionally checking
that the length of the m0_entry is equal.

For example muxing of "dss_data2.dss_data2" on omap32xx will fail
because the prefix "dss_data2" will match the mux-entries "dss_data2" as
well as "dss_data20", with the suffix "dss_data2" matching m0 (for
dss_data2) and m4 (for dss_data20). Thus both are recognized as signal
path candidates:

Relevant muxentries from mux34xx.c:
        _OMAP3_MUXENTRY(DSS_DATA20, 90,
                "dss_data20", NULL, "mcspi3_somi", "dss_data2",
                "gpio_90", NULL, NULL, "safe_mode"),
        _OMAP3_MUXENTRY(DSS_DATA2, 72,
                "dss_data2", NULL, NULL, NULL,
                "gpio_72", NULL, NULL, "safe_mode"),

This will result in a failure to mux the pin at all:

 _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2

Patch should apply to linus' latest master down to rather old linux-2.6

Signed-off-by: David R. Piegdon <>
[ updated description to include full description]
Signed-off-by: Tony Lindgren <>
Signed-off-by: Ben Hutchings <>
7 years agoRevert "net: ip, ipv6: handle gso skbs in forwarding path"
Ben Hutchings [Sat, 12 Jul 2014 20:00:54 +0000 (21:00 +0100)]
Revert "net: ip, ipv6: handle gso skbs in forwarding path"

This reverts commit caa5344994778a2b4725b2d75c74430f76925e4a, which
was commit fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream.  In 3.2,
the transport header length is not calculated in the forwarding path,
so skb_gso_network_seglen() returns an incorrect result.  We also have
problems due to the local_df flag not being set correctly.

Signed-off-by: Ben Hutchings <>
7 years agoRevert "net: ipv4: ip_forward: fix inverted local_df test"
Ben Hutchings [Fri, 11 Jul 2014 19:01:52 +0000 (20:01 +0100)]
Revert "net: ipv4: ip_forward: fix inverted local_df test"

This reverts commit 59d9f389df3cdf72833d5ee17c3fe959b6bdc792, which
was commit ca6c5d4ad216d5942ae544bbf02503041bd802aa upstream.  It is a
valid fix, but depends on sk_buff::local_df being set in all the right
cases, which it wasn't in 3.2.  We need to defer it unless and until
the other fixes are also backported to 3.2.y.

Signed-off-by: Ben Hutchings <>
7 years agoLinux 3.2.61 v3.2.61
Ben Hutchings [Fri, 11 Jul 2014 12:34:01 +0000 (13:34 +0100)]
Linux 3.2.61

7 years agoskbuff: skb_segment: orphan frags before copying
Michael S. Tsirkin [Mon, 10 Mar 2014 17:28:08 +0000 (19:28 +0200)]
skbuff: skb_segment: orphan frags before copying

commit 1fd819ecb90cc9b822cd84d3056ddba315d3340f upstream.

skb_segment copies frags around, so we need
to copy them carefully to avoid accessing
user memory after reporting completion to userspace
through a callback.

skb_segment doesn't normally happen on datapath:
TSO needs to be disabled - so disabling zero copy
in this case does not look like a big deal.

Signed-off-by: Michael S. Tsirkin <>
Acked-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2.  As skb_segment() only supports page-frags *or* a
 frag list, there is no need for the additional frag_skb pointer or the
 preparatory renaming.]
Signed-off-by: Ben Hutchings <>
7 years agoskbuff: export skb_copy_ubufs
Michael S. Tsirkin [Fri, 20 Jul 2012 09:23:20 +0000 (09:23 +0000)]
skbuff: export skb_copy_ubufs

commit dcc0fb782b3a6e2abfeaaeb45dd88ed09596be0f upstream.

Export skb_copy_ubufs so that modules can orphan frags.

Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoskbuff: add an api to orphan frags
Michael S. Tsirkin [Fri, 20 Jul 2012 09:23:07 +0000 (09:23 +0000)]
skbuff: add an api to orphan frags

commit a353e0ce0fd42d8859260666d1e9b10f2abd4698 upstream.

Many places do
       if ((skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY))
skb_copy_ubufs(skb, gfp_mask);
to copy and invoke frag destructors if necessary.
Add an inline helper for this.

Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoptrace,x86: force IRET path after a ptrace_stop()
Tejun Heo [Thu, 3 Jul 2014 19:43:15 +0000 (15:43 -0400)]
ptrace,x86: force IRET path after a ptrace_stop()

commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.

The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values.  That is
very much part of why it's faster than 'iret'.

Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.

However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'.  Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.

Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().

Signed-off-by: Tejun Heo <>
Reported-by: Andy Lutomirski <>
Acked-by: Oleg Nesterov <>
Suggested-by: Linus Torvalds <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agoDocumentation: Update stable address in Chinese and Japanese translations
Geert Uytterhoeven [Mon, 14 Apr 2014 16:52:14 +0000 (18:52 +0200)]
Documentation: Update stable address in Chinese and Japanese translations

commit 98b0f811aade1b7c6e7806c86aa0befd5919d65f upstream.

The English and Korean translations were updated, the Chinese and Japanese

Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr
Liu Hua [Thu, 27 Mar 2014 05:56:18 +0000 (06:56 +0100)]
ARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr

commit 8fad87bca7ac9737e413ba5f1656f1114a8c314d upstream.

When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will
overflow if pfn >= 0x100000 in copy_oldmem_page.
So use __pfn_to_phys for converting.

Signed-off-by: Liu Hua <>
Signed-off-by: Russell King <>
Signed-off-by: Ben Hutchings <>
7 years agoiommu/vt-d: Fix missing IOTLB flush in intel_iommu_unmap()
David Woodhouse [Mon, 9 Jun 2014 13:09:53 +0000 (14:09 +0100)]
iommu/vt-d: Fix missing IOTLB flush in intel_iommu_unmap()

Part of commit ea8ea460c9ace60bbb5ac6e5521d637d5c15293d upstream.

This missing IOTLB flush was added as a minor, inconsequential bug-fix
in commit ea8ea460c ("iommu/vt-d: Clean up and fix page table clear/free
behaviour") in 3.15. It wasn't originally intended for -stable but a
couple of users have reported issues which turn out to be fixed by
adding the missing flush.

Signed-off-by: David Woodhouse <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use &dmar_domain->iommu_bmp, as it is a single word not an array]
Signed-off-by: Ben Hutchings <>
7 years agomegaraid: Use resource_size_t for PCI resources, not long
Ben Collins [Fri, 13 Sep 2013 16:46:44 +0000 (12:46 -0400)]
megaraid: Use resource_size_t for PCI resources, not long

commit 11f8a7b31f2140b0dc164bb484281235ffbe51d3 upstream.

The assumption that sizeof(long) >= sizeof(resource_size_t) can lead to
truncation of the PCI resource address, meaning this driver didn't work
on 32-bit systems with 64-bit PCI adressing ranges.

Signed-off-by: Ben Collins <>
Acked-by: Sumit Saxena <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoFix spurious request sense in error handling
James Bottomley [Fri, 28 Mar 2014 17:50:17 +0000 (10:50 -0700)]
Fix spurious request sense in error handling

commit d555a2abf3481f81303d835046a5ec2c4fb3ca8e upstream.

We unconditionally execute scsi_eh_get_sense() to make sure all failed
commands that should have sense attached, do.  However, the routine forgets
that some commands, because of the way they fail, will not have any sense code
... we should not bother them with a REQUEST_SENSE command.  Fix this by
testing to see if we actually got a CHECK_CONDITION return and skip asking for
sense if we don't.

Tested-by: Alan Stern <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agotarget: Explicitly clear ramdisk_mcp backend pages
Nicholas Bellinger [Mon, 16 Jun 2014 20:59:52 +0000 (20:59 +0000)]
target: Explicitly clear ramdisk_mcp backend pages

Part of commit 4442dc8a92b8f9ad8ee9e7f8438f4c04c03a22dc upstream.

This patch changes rd_allocate_sgl_table() to explicitly clear
ramdisk_mcp backend memory pages by passing __GFP_ZERO into

This addresses a potential security issue where reading from a
ramdisk_mcp could return sensitive information, and follows what
>= v3.15 does to explicitly clear ramdisk_mcp memory at backend
device initialization time.

Reported-by: Jorge Daniel Sequeira Matias <>
Cc: Jorge Daniel Sequeira Matias <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
7 years agonet/mlx4_core: Preserve pci_dev_data after __mlx4_remove_one()
Wei Yang [Sun, 1 Jun 2014 07:25:41 +0000 (15:25 +0800)]
net/mlx4_core: Preserve pci_dev_data after __mlx4_remove_one()

[ Upstream commit befdf8978accecac2e0739e6b5075afc62db37fe ]

This patch wrap up a helper function __mlx4_remove_one() which does the tear
down function but preserve the drv_data. Functions like
mlx4_pci_err_detected() and mlx4_restart_one() will call this one with out
releasing drvdata.

Signed-off-by: Wei Yang <>
Signed-off-by: Ben Hutchings <>
7 years agomlx4_core: Stash PCI ID driver_data in mlx4_priv structure
Wei Yang [Sun, 1 Jun 2014 07:25:40 +0000 (15:25 +0800)]
mlx4_core: Stash PCI ID driver_data in mlx4_priv structure

[ No upstream commit, this is a cherry picked backport enabler. ]

That way we can check flags later on, when we've finished with the
pci_device_id structure.

This is a backport.

Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
7 years agosctp: Fix sk_ack_backlog wrap-around problem
Xufeng Zhang [Thu, 12 Jun 2014 02:53:36 +0000 (10:53 +0800)]
sctp: Fix sk_ack_backlog wrap-around problem

[ Upstream commit d3217b15a19a4779c39b212358a5c71d725822ee ]

Consider the scenario:
For a TCP-style socket, while processing the COOKIE_ECHO chunk in
sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check,
a new association would be created in sctp_unpack_cookie(), but afterwards,
some processing maybe failed, and sctp_association_free() will be called to
free the previously allocated association, in sctp_association_free(),
sk_ack_backlog value is decremented for this socket, since the initial
value for sk_ack_backlog is 0, after the decrement, it will be 65535,
a wrap-around problem happens, and if we want to establish new associations
afterward in the same socket, ABORT would be triggered since sctp deem the
accept queue as full.
Fix this issue by only decrementing sk_ack_backlog for associations in
the endpoint's list.

Fix-suggested-by: Neil Horman <>
Signed-off-by: Xufeng Zhang <>
Acked-by: Daniel Borkmann <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: fix inet_getid() and ipv6_select_ident() bugs
Eric Dumazet [Thu, 29 May 2014 15:45:14 +0000 (08:45 -0700)]
net: fix inet_getid() and ipv6_select_ident() bugs

[ Upstream commit 39c36094d78c39e038c1e499b2364e13bce36f54 ]

I noticed we were sending wrong IPv4 ID in TCP flows when MTU discovery
is disabled.
Note how GSO/TSO packets do not have monotonically incrementing ID.

06:37:41.575531 IP (id 14227, proto: TCP (6), length: 4396)
06:37:41.575534 IP (id 14272, proto: TCP (6), length: 65212)
06:37:41.575544 IP (id 14312, proto: TCP (6), length: 57972)
06:37:41.575678 IP (id 14317, proto: TCP (6), length: 7292)
06:37:41.575683 IP (id 14361, proto: TCP (6), length: 63764)

It appears I introduced this bug in linux-3.1.

inet_getid() must return the old value of peer->ip_id_count,
not the new one.

Lets revert this part, and remove the prevention of
a null identification field in IPv6 Fragment Extension Header,
which is dubious and not even done properly.

Fixes: 87c48fa3b463 ("ipv6: make fragment identifications less predictable")
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: tunnels - enable module autoloading
Tom Gundersen [Thu, 15 May 2014 21:21:30 +0000 (23:21 +0200)]
net: tunnels - enable module autoloading

[ Upstream commit f98f89a0104454f35a62d681683c844f6dbf4043 ]

Enable the module alias hookup to allow tunnel modules to be autoloaded on demand.

This is in line with how most other netdev kinds work, and will allow userspace
to create tunnels without having CAP_SYS_MODULE.

Signed-off-by: Tom Gundersen <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonetlink: rate-limit leftover bytes warning and print process name
Michal Schmidt [Mon, 2 Jun 2014 16:25:02 +0000 (18:25 +0200)]
netlink: rate-limit leftover bytes warning and print process name

[ Upstream commit bfc5184b69cf9eeb286137640351c650c27f118a ]

Any process is able to send netlink messages with leftover bytes.
Make the warning rate-limited to prevent too much log spam.

The warning is supposed to help find userspace bugs, so print the
triggering command name to implicate the buggy program.

[v2: Use pr_warn_ratelimited instead of printk_ratelimited.]

Signed-off-by: Michal Schmidt <>
Signed-off-by: David S. Miller <>
[bwh: Add #include of <linux/sched.h> for definition of struct task_struct,
 as in 3.2 it doesn't get included indirectly on all architectures.  Thanks
 to Guenter Roeck for debugging this.]
Signed-off-by: Ben Hutchings <>
7 years agoMIPS: asm: thread_info: Add _TIF_SECCOMP flag
Markos Chandras [Wed, 22 Jan 2014 14:40:00 +0000 (14:40 +0000)]
MIPS: asm: thread_info: Add _TIF_SECCOMP flag

commit 137f7df8cead00688524c82360930845396b8a21 upstream.

Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate
that the system call needs to be checked against a seccomp filter.

Signed-off-by: Markos Chandras <>
Reviewed-by: Paul Burton <>
Reviewed-by: James Hogan <>
Signed-off-by: Ralf Baechle <>
[bwh: Backported to 3.2: various other flags are not included in
Signed-off-by: Ben Hutchings <>
7 years agoMIPS: Cleanup flags in syscall flags handlers.
Ralf Baechle [Tue, 28 May 2013 23:02:18 +0000 (01:02 +0200)]
MIPS: Cleanup flags in syscall flags handlers.

commit e7f3b48af7be9f8007a224663a5b91340626fed5 upstream.

This will simplify further modifications.

Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
7 years agoperf: Fix race in removing an event
Peter Zijlstra [Fri, 2 May 2014 14:56:01 +0000 (16:56 +0200)]
perf: Fix race in removing an event

commit 46ce0fe97a6be7532ce6126bb26ce89fed81528c upstream.

When removing a (sibling) event we do:




Now, assuming the event is a sibling, it will be 'unreachable' for
things like ctx_sched_out() because that iterates the
groups->siblings, and we just unhooked the sibling.

So, if during <hole> we get ctx_sched_out(), it will miss the event
and not call event_sched_out() on it, leaving it programmed on the

The subsequent perf_remove_from_context() call will find the ctx is
inactive and only call list_del_event() to remove the event from all
other lists.

Hereafter we can proceed to free the event; while still programmed!

Close this hole by moving perf_group_detach() inside the same
ctx->lock region(s) perf_remove_from_context() has.

The condition on inherited events only in __perf_event_exit_task() is
likely complete crap because non-inherited events are part of groups
too and we're tearing down just the same. But leave that for another

Most-likely-Fixes: e03a9a55b4e ("perf: Change close() semantics for group events")
Reported-by: Vince Weaver <>
Tested-by: Vince Weaver <>
Much-staring-at-traces-by: Vince Weaver <>
Much-staring-at-traces-by: Thomas Gleixner <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Linus Torvalds <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: drop change in perf_pmu_migrate_context()]
Signed-off-by: Ben Hutchings <>
7 years agodual scan thread bug fix
James Bottomley [Tue, 21 Jan 2014 15:01:41 +0000 (07:01 -0800)]
dual scan thread bug fix

commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream.

In the highly unusual case where two threads are running concurrently through
the scanning code scanning the same target, we run into the situation where
one may allocate the target while the other is still using it.  In this case,
because the reap checks for STARGET_CREATED and kills the target without
reference counting, the second thread will do the wrong thing on reap.

Fix this by reference counting even creates and doing the STARGET_CREATED
check in the final put.

Tested-by: Sarah Sharp <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
7 years agofix our current target reap infrastructure
James Bottomley [Tue, 21 Jan 2014 15:00:50 +0000 (07:00 -0800)]
fix our current target reap infrastructure

commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream.

This patch eliminates the reap_ref and replaces it with a proper kref.
On last put of this kref, the target is removed from visibility in
sysfs.  The final call to scsi_target_reap() for the device is done from
__scsi_remove_device() and only if the device was made visible.  This
ensures that the target disappears as soon as the last device is gone
rather than waiting until final release of the device (which is often
too long).

Reviewed-by: Alan Stern <>
Tested-by: Sarah Sharp <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
7 years agoStop accepting SCSI requests before removing a device
Bart Van Assche [Fri, 29 Jun 2012 15:36:07 +0000 (15:36 +0000)]
Stop accepting SCSI requests before removing a device

commit b485462aca7df4e32bcf7efb6f84a69e8b640243 upstream.

Avoid that the code for requeueing SCSI requests triggers a
crash by making sure that that code isn't scheduled anymore
after a device has been removed.

Also, source code inspection of __scsi_remove_device() revealed
a race condition in this function: no new SCSI requests must be
accepted for a SCSI device after device removal started.

Signed-off-by: Bart Van Assche <>
Reviewed-by: Mike Christie <>
Acked-by: Tejun Heo <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agotarget: Fix left-over se_lun->lun_sep pointer OOPs
Nicholas Bellinger [Mon, 16 Jun 2014 20:25:54 +0000 (20:25 +0000)]
target: Fix left-over se_lun->lun_sep pointer OOPs

commit 83ff42fcce070801a3aa1cd6a3269d7426271a8d upstream.

This patch fixes a left-over se_lun->lun_sep pointer OOPs when one
of the /sys/kernel/config/target/$FABRIC/$WWPN/$TPGT/lun/$LUN/alua*
attributes is accessed after the $DEVICE symlink has been removed.

To address this bug, go ahead and clear se_lun->lun_sep memory in
core_dev_unexport(), so that the existing checks for show/store
ALUA attributes in target_core_fabric_configfs.c work as expected.

Reported-by: Sebastian Herbszt <>
Tested-by: Sebastian Herbszt <>
Signed-off-by: Nicholas Bellinger <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoMIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region
Markos Chandras [Mon, 23 Jun 2014 08:48:51 +0000 (09:48 +0100)]
MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region

commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream.

Previously, the lower limit for the MIPS SC initialization loop was
set incorrectly allowing one extra loop leading to writes
beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
in the last loop increased beyond the msc_irqmap_t boundaries and
as a result of which, the 'n' variable was loaded with an incorrect
value. This value was used later on to calculate the offset in the
MSC01_IC_SUP which led to random crashes like the following one:

CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
epc == 8058dba4, ra == 8058db90
Call Trace:
[<8058dba4>] init_msc_irqs+0x104/0x154
[<8058b5bc>] arch_init_irq+0xd8/0x154
[<805897b0>] start_kernel+0x220/0x36c

Kernel panic - not syncing: Attempted to kill the idle task!

This patch fixes the problem

Signed-off-by: Markos Chandras <>
Reviewed-by: James Hogan <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
7 years agorecordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules
Alex Smith [Tue, 17 Jun 2014 09:39:53 +0000 (10:39 +0100)]
recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules

commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream.

On MIPS calls to _mcount in modules generate 2 instructions to load
the _mcount address (and therefore 2 relocations). The mcount_loc
table should only reference the first of these, so the second is
filtered out by checking the relocation offset and ignoring ones that
immediately follow the previous one seen.

However if a module has an _mcount call at offset 0, the second
relocation would not be filtered out due to old_r_offset == 0
being taken to mean that the current relocation is the first one
seen, and both would end up in the mcount_loc table.

This results in ftrace_make_nop() patching both (adjacent)
instructions to branches over the _mcount call sequence like so:

  0xffffffffc08a8000:  04 00 00 10     b       0xffffffffc08a8014
  0xffffffffc08a8004:  04 00 00 10     b       0xffffffffc08a8018
  0xffffffffc08a8008:  2d 08 e0 03     move    at,ra

The second branch is in the delay slot of the first, which is
defined to be unpredictable - on the platform on which this bug was
encountered, it triggers a reserved instruction exception.

Fix by initializing old_r_offset to ~0 and using that instead of 0
to determine whether the current relocation is the first seen.

Signed-off-by: Alex Smith <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
7 years agodrm: fix NULL pointer access by wrong ioctl
Zhaowei Yuan [Wed, 18 Jun 2014 06:33:59 +0000 (14:33 +0800)]
drm: fix NULL pointer access by wrong ioctl

commit 1539fb9bd405ee32282ea0a38404f9e008ac5b7a upstream.

If user uses wrong ioctl command with _IOC_NONE and argument size
greater than 0, it can cause NULL pointer access from memset of line
463. If _IOC_NONE, don't memset to 0 for kdata.

Signed-off-by: Zhaowei Yuan <>
Reviewed-by: David Herrmann <>
Signed-off-by: Dave Airlie <>
[bwh: Backported to 3.2: adjust indentation]
Signed-off-by: Ben Hutchings <>