01 Jul, 2014
40 commits
-
commit edfbbf388f293d70bf4b7c0bc38774d05e6f711a upstream.
A kernel memory disclosure was introduced in aio_read_events_ring() in v3.10
by commit a31ad380bed817aa25f8830ad23e1a0480fef797. The changes made to
aio_read_events_ring() failed to correctly limit the index into
ctx->ring_pages[], allowing an attacked to cause the subsequent kmap() of
an arbitrary page with a copy_to_user() to copy the contents into userspace.
This vulnerability has been assigned CVE-2014-0206. Thanks to Mateusz and
Petr for disclosing this issue.This patch applies to v3.12+. A separate backport is needed for 3.10/3.11.
Signed-off-by: Benjamin LaHaise
Cc: Mateusz Guzik
Cc: Petr Matousek
Cc: Kent Overstreet
Cc: Jeff Moyer
Signed-off-by: Greg Kroah-Hartman -
commit f8567a3845ac05bb28f3c1b478ef752762bd39ef upstream.
The aio cleanups and optimizations by kmo that were merged into the 3.10
tree added a regression for userspace event reaping. Specifically, the
reference counts are not decremented if the event is reaped in userspace,
leading to the application being unable to submit further aio requests.
This patch applies to 3.12+. A separate backport is required for 3.10/3.11.
This issue was uncovered as part of CVE-2014-0206.Signed-off-by: Benjamin LaHaise
Cc: Kent Overstreet
Cc: Mateusz Guzik
Cc: Petr Matousek
Signed-off-by: Greg Kroah-Hartman -
commit 1e77d0a1ed7417d2a5a52a7b8d32aea1833faa6c upstream.
Till reported that the spurious interrupt detection of threaded
interrupts is broken in two ways:- note_interrupt() is called for each action thread of a shared
interrupt line. That's wrong as we are only interested whether none
of the device drivers felt responsible for the interrupt, but by
calling multiple times for a single interrupt line we account
IRQ_NONE even if one of the drivers felt responsible.- note_interrupt() when called from the thread handler is not
serialized. That leaves the members of irq_desc which are used for
the spurious detection unprotected.To solve this we need to defer the spurious detection of a threaded
interrupt to the next hardware interrupt context where we have
implicit serialization.If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we
check whether the previous interrupt requested a deferred check. If
not, we request a deferred check for the next hardware interrupt and
return.If set, we check whether one of the interrupt threads signaled
success. Depending on this information we feed the result into the
spurious detector.If one primary handler of a shared interrupt returns IRQ_HANDLED we
disable the deferred check of irq threads on the same line, as we have
found at least one device driver who cared.Reported-by: Till Straumann
Signed-off-by: Thomas Gleixner
Tested-by: Austin Schuh
Cc: Oliver Hartkopp
Cc: Wolfgang Grandegger
Cc: Pavel Pisa
Cc: Marc Kleine-Budde
Cc: linux-can@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos
Signed-off-by: Greg Kroah-Hartman -
commit 68986c9f0f4552c34c248501eb0c690553866d6e upstream.
This reverts commit e1edf18b20076da83dd231dbd2146cbbc31c0b14.
This patch was a misguided attempt at fixing offb for LE ppc64
kernels on BE qemu but is just wrong ... it breaks real LE/LE
setups, LE with real HW, and existing mixed endian systems
that did the fight thing with the appropriate device-tree
property. Bad reviewing on my part, sorry.The right fix is to either make qemu change its endian when
the guest changes endian (working on that) or to use the
existing foreign endian support.Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 0690a229c69f40a6c9c459ab455c85df49822525 upstream.
This caused reduced performance for some users with advanced post
processing enabled. We need a better method to pick the
UVD state based on the amount of post processing required or tune
the advanced post processing to fit within the lower power state
envelope.This reverts commit 14a9579ddbf15dd1992a9481a4ec80b0b91656d5.
Signed-off-by: Greg Kroah-Hartman
-
commit 7fd44dacdd803c0bbf38bf478d51d280902bb0f1 upstream.
The io_setup takes a pointer to a context id of type aio_context_t.
This in turn is typed to a __kernel_ulong_t. We could tweak the
exported headers to define this as a 64bit quantity for specific
ABIs, but since we already have a 32bit compat shim for the x86 ABI,
let's just re-use that logic. The libaio package is also written to
expect this as a pointer type, so a compat shim would simplify that.The io_submit func operates on an array of pointers to iocb structs.
Padding out the array to be 64bit aligned is a huge pain, so convert
it over to the existing compat shim too.We don't convert io_getevents to the compat func as its only purpose
is to handle the timespec struct, and the x32 ABI uses 64bit times.With this change, the libaio package can now pass its testsuite when
built for the x32 ABI.Signed-off-by: Mike Frysinger
Link: http://lkml.kernel.org/r/1399250595-5005-1-git-send-email-vapier@gentoo.org
Cc: H.J. Lu
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 246f2d2ee1d715e1077fc47d61c394569c8ee692 upstream.
It is not safe to use LAR to filter when to go down the espfix path,
because the LDT is per-process (rather than per-thread) and another
thread might change the descriptors behind our back. Fortunately it
is always *safe* (if a bit slow) to go down the espfix path, and a
32-bit LDT stack segment is extremely rare.Signed-off-by: H. Peter Anvin
Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
commit e3a920afc3482e954834a4ed95908c4bc5e4c000 upstream.
This should be a plain old '&' and could easily lead to undefined
behaviour if the target of a pmd_mknotpresent invocation was the same
as the parameter.Fixes: 9c7e535fcc17 (arm64: mm: Route pmd thp functions through pte equivalents)
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit f3a183cb422574014538017b5b291a416396f97e upstream.
Arm64 does not define dma_get_required_mask() function.
Therefore, it should not define the ARCH_HAS_DMA_GET_REQUIRED_MASK.
This causes build errors in some device drivers (e.g. mpt2sas)Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit 34c65c43f1518bf85f93526ad373adc6a683b4c5 upstream.
Whilst native arm64 applications don't have the 16-bit UID/GID syscalls
wired up, compat tasks can still access them. The 16-bit wrappers for
these syscalls use __kernel_old_uid_t and __kernel_old_gid_t, which must
be 16-bit data types to maintain compatibility with the 16-bit UIDs used
by compat applications.This patch defines 16-bit __kernel_old_{gid,uid}_t types for arm64
instead of using the 32-bit types provided by asm-generic.Signed-off-by: Will Deacon
Acked-by: Arnd Bergmann
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit e47043aea3853a74a9aa5726a1faa916d7462ab7 upstream.
The OpenBlocks AX3-4 has a non-DT bootloader. It also comes with 1GB of
soldered on RAM, and a DIMM slot for expansion.Unfortunately, atags_to_fdt() doesn't work in big-endian mode, so we see
the following failure when attempting to boot a big-endian kernel:686 slab pages
17 pages shared
0 pages swap cached
[ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Kernel panic - not syncing: Out of memory and no killable processes...CPU: 1 PID: 351 Comm: kworker/u4:0 Not tainted 3.15.0-rc8-next-20140603 #1
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x78/0x94)
[] (dump_stack) from [] (panic+0x90/0x21c)
[] (panic) from [] (out_of_memory+0x320/0x340)
[] (out_of_memory) from [] (__alloc_pages_nodemask+0x874/0x930)
[] (__alloc_pages_nodemask) from [] (handle_mm_fault+0x744/0x96c)
[] (handle_mm_fault) from [] (__get_user_pages+0xd0/0x4c0)
[] (__get_user_pages) from [] (get_arg_page+0x54/0xbc)
[] (get_arg_page) from [] (copy_strings+0x278/0x29c)
[] (copy_strings) from [] (copy_strings_kernel+0x20/0x28)
[] (copy_strings_kernel) from [] (do_execve+0x3a8/0x4c8)
[] (do_execve) from [] (____call_usermodehelper+0x15c/0x194)
[] (____call_usermodehelper) from [] (ret_from_fork+0x14/0x3c)
CPU0: stopping
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140603 #1
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x78/0x94)
[] (dump_stack) from [] (handle_IPI+0x138/0x174)
[] (handle_IPI) from [] (armada_370_xp_handle_irq+0xb0/0xcc)
[] (armada_370_xp_handle_irq) from [] (__irq_svc+0x40/0x50)
Exception stack(0xc0b6bf68 to 0xc0b6bfb0)
bf60: e9fad598 00000000 00f509a3 00000000 c0b6a000 c0b724c4
bf80: c0b72458 c0b6a000 00000000 00000000 c0b66da0 c0b6a000 00000000 c0b6bfb0
bfa0: c027bb94 c027bb24 60000313 ffffffff
[] (__irq_svc) from [] (cpu_startup_entry+0x54/0x214)
[] (cpu_startup_entry) from [] (start_kernel+0x318/0x37c)
[] (start_kernel) from [] (0x208078)
---[ end Kernel panic - not syncing: Out of memory and no killable processes...A similar failure will also occur if ARM_ATAG_DTB_COMPAT isn't selected.
Fix this by setting a sane default (1 GB) in the dts file.
Signed-off-by: Jason Cooper
Tested-by: Kevin Hilman
Signed-off-by: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman -
commit 2aea39eca6b68d6ae7eb545332df0695f56a3d3f upstream.
If f2fs_write_data_page is called through the reclaim path, we should submit
the bio right away.This patch resolves the following issue that Marc Dietrich reported.
"It took me a while to bisect a problem which causes my ARM (tegra2) netbook to
frequently stall for 5-10 seconds when I enable EXA acceleration (opentegra
experimental ddx)."
And this patch fixes that.Reported-by: Marc Dietrich
Signed-off-by: Jaegeuk Kim
Signed-off-by: Greg Kroah-Hartman -
commit e2a4f55c6498b59a17a85a1bb6db122a993ffe02 upstream.
In various areas of the code, it is assumed that
se_cmd->data_length describes pure data. In case
that protection information exists over the wire
(protect bits is are on) the target core re-calculates
the data length from the CDB and the backed device
block size (instead of each transport peeking in the cdb).Modify loopback device to include protection information
in the transferred data length (like other scsi transports).Signed-off-by: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit d77e65350f2d82dfa0557707d505711f5a43c8fd upstream.
In case protection information exists over the wire
iscsi header data length is required to include it.
Use protection information aware scsi helpers to set
the correct transfer length.In order to avoid breakage, remove iser transfer length
checks for each task as they are not always true and
somewhat redundant anyway.Signed-off-by: Sagi Grimberg
Reviewed-by: Mike Christie
Acked-by: Mike Christie
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 8846bab180fa2bcfe02d4ba5288fbaba12c8f4f3 upstream.
In case protection information exists on the wire
scsi transports should include it in the transfer
byte count (even if protection information does not
exist in the host memory space). This helper will
compute the total transfer length from the scsi
command data length and protection attributes.Signed-off-by: Sagi Grimberg
Signed-off-by: Martin K. Petersen
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 2426bd456a61407388b6e61fc5f98dbcbebc50e2 upstream.
When an initiator sends an allocation length bigger than what its
command consumes, the target should only return the actual response data
and set the residual length to the unused part of the allocation length.Add a helper function that command handlers (INQUIRY, READ CAPACITY,
etc) can use to do this correctly, and use this code to get the correct
residual for commands that don't use the full initiator allocation in the
handlers for READ CAPACITY, READ CAPACITY(16), INQUIRY, MODE SENSE and
REPORT LUNS.This addresses a handful of failures as reported by Christophe with
the Windows Certification Kit:http://permalink.gmane.org/gmane.linux.scsi.target.devel/6515
Signed-off-by: Roland Dreier
Tested-by: Christophe Vu-Brugier
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 22c7aaa57e80853b4904a46c18f97db0036a3b97 upstream.
In case the transport is iser we should not include the
iscsi target info in the sendtargets text response pdu.
This causes sendtargets response to include the target
info twice.Modify iscsit_build_sendtargets_response to filter
transport types that don't match.Signed-off-by: Sagi Grimberg
Reported-by: Slava Shwartsman
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit e0546fc1ba66c90cb38a5764357366267d3e58e4 upstream.
In case the discovery session is carried over iser, we can't
access the assumed network portal since the default portal is
used. In this case we don't really need to allocate the fastreg
pool, just prepare to the text pdu that will follow.Signed-off-by: Sagi Grimberg
Reported-by: Alex Tabachnik
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit bbc050488525e1ab1194c27355f63c66814385b8 upstream.
This patch fixes a iscsi_queue_req memory leak when ABORT_TASK response
has been queued by TFO->queue_tm_rsp() -> lio_queue_tm_rsp() after a
long standing I/O completes, but the connection has already reset and
waiting for cleanup to complete in iscsit_release_commands_from_conn()
-> transport_generic_free_cmd() -> transport_wait_for_tasks() code.It moves iscsit_free_queue_reqs_for_conn() after the per-connection command
list has been released, so that the associated se_cmd tag can be completed +
released by target-core before freeing any remaining iscsi_queue_req memory
for the connection generated by lio_queue_tm_rsp().Cc: Thomas Glanzmann
Cc: Charalampos Pournaris
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit a95d6511303b848da45ee27b35018bb58087bdc6 upstream.
This patch fixes a bug where multiple waiters on ->t_transport_stop_comp
occurs due to a concurrent ABORT_TASK and session reset both invoking
transport_wait_for_tasks(), while waiting for the associated se_cmd
descriptor backend processing to complete.For this case, complete_all() should be invoked in order to wake up
both waiters in core_tmr_abort_task() + transport_generic_free_cmd()
process contexts.Cc: Thomas Glanzmann
Cc: Charalampos Pournaris
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit f15e9cd910c4d9da7de43f2181f362082fc45f0f upstream.
This patch fixes a bug where se_cmd descriptors associated with a
Task Management Request (TMR) where not setting CMD_T_ACTIVE before
being dispatched into target_tmr_work() process context.This is required in order for transport_generic_free_cmd() ->
transport_wait_for_tasks() to wait on se_cmd->t_transport_stop_comp
if a session reset event occurs while an ABORT_TASK is outstanding
waiting for another I/O to complete.Cc: Thomas Glanzmann
Cc: Charalampos Pournaris
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 5f80ff8eccba50832dcc640ac89add4c7fced963 upstream.
In case user chose to set T10-PI enable on the target while
the IB device does not support it, gracefully reject the request.Reported-by: Slava Shwartsman
Signed-off-by: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit f5ebec9629cf78eeeea4b8258882a9f439ab2404 upstream.
disconnected_handler works are scheduled on system_wq.
When attempting to unload, first make sure all works
have cleaned up.Signed-off-by: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 88c4015fda6d014392f76d3b1688347950d7a12d upstream.
There are 4 RDMA_CM events that all basically mean that
the user should teardown the IB connection:
- DISCONNECTED
- ADDR_CHANGE
- DEVICE_REMOVAL
- TIMEWAIT_EXITOnly in DISCONNECTED/ADDR_CHANGE it makes sense to
call rdma_disconnect (send DREQ/DREP to our initiator).
So we keep the same teardown handler for all of them
but only indicate calling rdma_disconnect for the relevant
events.This patch also removes redundant debug prints for each single
event.v2 changes:
- Call isert_disconnected_handler() for DEVICE_REMOVAL (Or + Sag)Signed-off-by: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 9d49f5e284e700576f3b65f1e28dea8539da6661 upstream.
In ungraceful teardowns isert close flows seem racy such that
isert_wait_conn hangs as RDMA_CM_EVENT_DISCONNECTED never
gets invoked (no one called rdma_disconnect).Both graceful and ungraceful teardowns will have rx flush errors
(isert posts a batch once connection is established). Once all
flush errors are consumed we invoke isert_wait_conn and it will
be responsible for calling rdma_disconnect. This way it can be
sure that rdma_disconnect was called and it won't wait forever.This patch also removes the logout_posted indicator. either the
logout completion was consumed and no problem decrementing the
post_send_buf_count, or it was consumed as a flush error. no point
of keeping it for isert_wait_conn as there is no danger that
isert_conn will be accidentally removed while it is running.(Drop unnecessary sleep_on_conn_wait_comp check in
isert_cq_rx_comp_err - nab)Signed-off-by: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit e346ab343f4f58c12a96725c7b13df9cc2ad56f6 upstream.
In case np_thread state is in RESET/SHUTDOWN/EXIT states,
no point for isert to stall there as we may get a hang in
case no one will wake it up later.Signed-off-by: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit f3fb0b58c85666f73139963a7a04d7878f3d22c9 upstream.
When checking whether a legacy link key provides at least HIGH security
level we also need to check for FIPS level which is one step above HIGH.
This patch fixes a missing check in the hci_link_key_request_evt()
function.Signed-off-by: Johan Hedberg
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 79897d2097a629179e142014ecd3cdce6eac7f0e upstream.
Due to recent changes to the way that the MITM requirement is set for
outgoing pairing attempts we can no longer rely on the hcon->auth_type
variable (which is actually good since it was formed from BR/EDR
concepts that don't really exist for SMP).To match the logic that BR/EDR now uses simply rely on the local IO
capability and/or needed security level to set the MITM requirement for
outgoing pairing requests.Signed-off-by: Johan Hedberg
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 7e3691e13ab51f3491e996e2edaf99b173621288 upstream.
When checking whether we need to request authentication or not we should
include HCI_SECURITY_FIPS to the levels that always need authentication.
This patch fixes check for it in the hci_outgoing_auth_needed()
function.Signed-off-by: Johan Hedberg
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 8a96f3cd22878fc0bb564a8478a6e17c0b8dca73 upstream.
-[0x01 Introduction
We have found a programming error causing a deadlock in Bluetooth subsystem
of Linux kernel. The problem is caused by missing release_sock() call when
L2CAP connection creation fails due full accept queue.The issue can be reproduced with 3.15-rc5 kernel and is also present in
earlier kernels.-[0x02 Details
The problem occurs when multiple L2CAP connections are created to a PSM which
contains listening socket (like SDP) and left pending, for example,
configuration (the underlying ACL link is not disconnected between
connections).When L2CAP connection request is received and listening socket is found the
l2cap_sock_new_connection_cb() function (net/bluetooth/l2cap_sock.c) is called.
This function locks the 'parent' socket and then checks if the accept queue
is full.1178 lock_sock(parent);
1179
1180 /* Check for backlog size */
1181 if (sk_acceptq_is_full(parent)) {
1182 BT_DBG("backlog full %d", parent->sk_ack_backlog);
1183 return NULL;
1184 }If case the accept queue is full NULL is returned, but the 'parent' socket
is not released. Thus when next L2CAP connection request is received the code
blocks on lock_sock() since the parent is still locked.Also note that for connections already established and waiting for
configuration to complete a timeout will occur and l2cap_chan_timeout()
(net/bluetooth/l2cap_core.c) will be called. All threads calling this
function will also be blocked waiting for the channel mutex since the thread
which is waiting on lock_sock() alread holds the channel mutex.We were able to reproduce this by sending continuously L2CAP connection
request followed by disconnection request containing invalid CID. This left
the created connections pending configuration.After the deadlock occurs it is impossible to kill bluetoothd, btmon will not
get any more data etc. requiring reboot to recover.-[0x03 Fix
Releasing the 'parent' socket when l2cap_sock_new_connection_cb() returns NULL
seems to fix the issue.Signed-off-by: Jukka Taimisto
Reported-by: Tommi Mäkilä
Signed-off-by: Johan Hedberg
Signed-off-by: Greg Kroah-Hartman -
commit 62bbd5b35994eaf30519f126765d7f6af9cd3526 upstream.
The universal/local bit handling was incorrectly done in the code.
So when setting EUI address from BD address we do this:
- If BD address type is PUBLIC, then we clear the universal bit
in EUI address. If the address type is RANDOM, then the universal
bit is set (BT 6lowpan draft chapter 3.2.2)
- After this we invert the universal/local bit according to RFC 2464When figuring out BD address we do the reverse:
- Take EUI address from stateless IPv6 address, invert the
universal/local bit according to RFC 2464
- If universal bit is 1 in this modified EUI address, then address
type is set to RANDOM, otherwise it is PUBLICNote that 6lowpan_iphc.[ch] does the final toggling of U/L bit
before sending or receiving the network packet.Signed-off-by: Jukka Rissanen
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit da64c27d3c93ee9f89956b9de86c4127eb244494 upstream.
LDISCs shouldn't call tty->ops->write() from within
->write_wakeup().->write_wakeup() is called with port lock taken and
IRQs disabled, tty->ops->write() will try to acquire
the same port lock and we will deadlock.Acked-by: Marcel Holtmann
Reviewed-by: Peter Hurley
Reported-by: Huang Shijie
Signed-off-by: Felipe Balbi
Tested-by: Andreas Bießmann
Signed-off-by: Greg Kroah-Hartman -
commit 086abb58590a4df73e8a6ed71fd418826937cd46 upstream.
In of_init_opp_table function, if a failure to add an OPP is
detected, the count of OPPs, yet to be added is not updated.
Fix this by decrementing this count on failure as well.Signed-off-by: Chander Kashyap
Signed-off-by: Inderpal Singh
Acked-by: Viresh Kumar
Acked-by: Nishanth Menon
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 2e091d13e65d26f21159323b95b426e5bc42670c upstream.
Fixes: commit 0611c41934ab35ce84dea34ab291897ad3cbc7be
ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms and ECC schemesThough the commit log of above commit mentions AM43xx platforms, but code change
missed AM43xx. This patch adds AM43xx to list of those SoC which have built-in
ELM hardware engine, so that BCH ecc-schemes with hardware error-correction can
be enabled on AM43xx devices.Reported-by: Roger Quadros
Signed-off-by: Pekon Gupta
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 86f40622af7329375e38f282f6c0aab95f3e5f72 upstream.
When enable LPAE and big-endian in a hisilicon board, while specify
mem=384M mem=512M@7680M, will get bad page state:Freeing unused kernel memory: 180K (c0466000 - c0493000)
BUG: Bad page state in process init pfn:fa442
page:c7749840 count:0 mapcount:-1 mapping: (null) index:0x0
page flags: 0x40000400(reserved)
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 3.10.27+ #66
[] (unwind_backtrace+0x0/0x11c) from [] (show_stack+0x10/0x14)
[] (show_stack+0x10/0x14) from [] (bad_page+0xd4/0x104)
[] (bad_page+0xd4/0x104) from [] (free_pages_prepare+0xa8/0x14c)
[] (free_pages_prepare+0xa8/0x14c) from [] (free_hot_cold_page+0x18/0xf0)
[] (free_hot_cold_page+0x18/0xf0) from [] (handle_pte_fault+0xcf4/0xdc8)
[] (handle_pte_fault+0xcf4/0xdc8) from [] (handle_mm_fault+0xf4/0x120)
[] (handle_mm_fault+0xf4/0x120) from [] (do_page_fault+0xfc/0x354)
[] (do_page_fault+0xfc/0x354) from [] (do_DataAbort+0x2c/0x90)
[] (do_DataAbort+0x2c/0x90) from [] (__dabt_usr+0x34/0x40)The bad pfn:fa442 is not system memory(mem=384M mem=512M@7680M), after debugging,
I find in page fault handler, will get wrong pfn from pte just after set pte,
as follow:
do_anonymous_page()
{
...
set_pte_at(mm, address, page_table, entry);//debug code
pfn = pte_pfn(entry);
pr_info("pfn:0x%lx, pte:0x%llxn", pfn, pte_val(entry));//read out the pte just set
new_pte = pte_offset_map(pmd, address);
new_pfn = pte_pfn(*new_pte);
pr_info("new pfn:0x%lx, new pte:0x%llxn", pfn, pte_val(entry));
...
}pfn: 0x1fa4f5, pte:0xc00001fa4f575f
new_pfn:0xfa4f5, new_pte:0xc00000fa4f5f5f //new pfn/pte is wrong.The bug is happened in cpu_v7_set_pte_ext(ptep, pte):
An LPAE PTE is a 64bit quantity, passed to cpu_v7_set_pte_ext in the r2 and r3 registers.
On an LE kernel, r2 contains the LSB of the PTE, and r3 the MSB.
On a BE kernel, the assignment is reversed.Unfortunately, the current code always assumes the LE case,
leading to corruption of the PTE when clearing/setting bits.This patch fixes this issue much like it has been done already in the
cpu_v7_switch_mm case.Signed-off-by: Jianguo Wu
Acked-by: Marc Zyngier
Acked-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit 3683f44c42e991d313dc301504ee0fca1aeb8580 upstream.
While debugging the FEC ethernet driver using stacktrace, it was noticed
that the stacktraces always begin as follows:[] save_stack_trace_tsk+0x0/0x98
[] save_stack_trace+0x24/0x28
...This is because the stack trace code includes the stack frames for itself.
This is incorrect behaviour, and also leads to "skip" doing the wrong
thing (which is the number of stack frames to avoid recording.)Perversely, it does the right thing when passed a non-current thread. Fix
this by ensuring that we have a known constant number of frames above the
main stack trace function, and always skip these.Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit 17e7f1b515803e1a79b246688aacbddd2e34165d upstream.
This solves this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73361
The problem is that when you quit tvtime it calls STREAMOFF, but then it queues a
bunch of buffers for no good reason before closing the file descriptor.In the past closing the fd would free the vb queue since that was part of the file
handle struct. Since that was moved to the global struct that no longer happened.This wouldn't be a problem, but the extra QBUF calls that tvtime does meant that
the buffer list in videobuf (q->stream) contained buffers, so REQBUFS would fail
with -EBUSY.The solution is to init the list head explicitly when releasing the file
descriptor and to not free the video resource when calling streamoff.The real fix will hopefully go into kernel 3.16 when the vb2 conversion is
merged. Basically the saa7134 driver with the old videobuf is so full of holes it
ain't funny anymore, so consider this a band-aid for kernels 3.14 and 15.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 5d60122b7e30f275593df93b39a76d3c2663cfc2 upstream.
This patch fixes an off by one check in bcm2048_set_region().
Reported-by: Dan Carpenter
Signed-off-by: Pali Rohár
Signed-off-by: Pavel Machek
Signed-off-by: Dan Carpenter
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 3b35fc81e7ec552147a4fd843d0da0bbbe4ef253 upstream.
timestamps in v4l2 buffers returned to userspace are updated in
uvc_video_clock_update() which uses timestamps fetched from
uvc_video_clock_decode() by calling unconditionally ktime_get_ts().Hence setting the module clock param to realtime has no effect before
this patch.This has been tested with ffmpeg:
ffmpeg -y -f v4l2 -input_format yuyv422 -video_size 640x480 -framerate 30 -i /dev/video0 \
-f alsa -acodec pcm_s16le -ar 16000 -ac 1 -i default \
-c:v libx264 -preset ultrafast \
-c:a libfdk_aac \
out.mkvand inspecting the v4l2 input starting timestamp.
Signed-off-by: Olivier Langlois
Signed-off-by: Laurent Pinchart
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 27e35715df54cbc4f2d044f681802ae30479e7fb upstream.
When the rtmutex fast path is enabled the slow unlock function can
create the following situation:spin_lock(foo->m->wait_lock);
foo->m->owner = NULL;
rt_mutex_lock(foo->m); refcnt);
rt_mutex_unlock(foo->m); m->wait_lock); owner */
clear_rt_mutex_waiters(m);
owner = rt_mutex_owner(m);
spin_unlock(m->wait_lock);
if (cmpxchg(m->owner, owner, 0) == owner)
return;
spin_lock(m->wait_lock);
}So in case of a new waiter incoming while the owner tries the slow
path unlock we have two situations:unlock(wait_lock);
lock(wait_lock);
cmpxchg(p, owner, 0) == owner
mark_rt_mutex_waiters(lock);
acquire(lock);Or:
unlock(wait_lock);
lock(wait_lock);
mark_rt_mutex_waiters(lock);
cmpxchg(p, owner, 0) != owner
enqueue_waiter();
unlock(wait_lock);
lock(wait_lock);
wakeup_next waiter();
unlock(wait_lock);
lock(wait_lock);
acquire(lock);If the fast path is disabled, then the simple
m->owner = NULL;
unlock(m->wait_lock);is sufficient as all access to m->owner is serialized via
m->wait_lock;Also document and clarify the wakeup_next_waiter function as suggested
by Oleg Nesterov.Reported-by: Steven Rostedt
Signed-off-by: Thomas Gleixner
Reviewed-by: Steven Rostedt
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20140611183852.937945560@linutronix.de
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
