03 Apr, 2012
40 commits
-
commit 1a5a9906d4e8d1976b701f889d8f35d54b928f25 upstream.
In some cases it may happen that pmd_none_or_clear_bad() is called with
the mmap_sem hold in read mode. In those cases the huge page faults can
allocate hugepmds under pmd_none_or_clear_bad() and that can trigger a
false positive from pmd_bad() that will not like to see a pmd
materializing as trans huge.It's not khugepaged causing the problem, khugepaged holds the mmap_sem
in write mode (and all those sites must hold the mmap_sem in read mode
to prevent pagetables to go away from under them, during code review it
seems vm86 mode on 32bit kernels requires that too unless it's
restricted to 1 thread per process or UP builds). The race is only with
the huge pagefaults that can convert a pmd_none() into a
pmd_trans_huge().Effectively all these pmd_none_or_clear_bad() sites running with
mmap_sem in read mode are somewhat speculative with the page faults, and
the result is always undefined when they run simultaneously. This is
probably why it wasn't common to run into this. For example if the
madvise(MADV_DONTNEED) runs zap_page_range() shortly before the page
fault, the hugepage will not be zapped, if the page fault runs first it
will be zapped.Altering pmd_bad() not to error out if it finds hugepmds won't be enough
to fix this, because zap_pmd_range would then proceed to call
zap_pte_range (which would be incorrect if the pmd become a
pmd_trans_huge()).The simplest way to fix this is to read the pmd in the local stack
(regardless of what we read, no need of actual CPU barriers, only
compiler barrier needed), and be sure it is not changing under the code
that computes its value. Even if the real pmd is changing under the
value we hold on the stack, we don't care. If we actually end up in
zap_pte_range it means the pmd was not none already and it was not huge,
and it can't become huge from under us (khugepaged locking explained
above).All we need is to enforce that there is no way anymore that in a code
path like below, pmd_trans_huge can be false, but pmd_none_or_clear_bad
can run into a hugepmd. The overhead of a barrier() is just a compiler
tweak and should not be measurable (I only added it for THP builds). I
don't exclude different compiler versions may have prevented the race
too by caching the value of *pmd on the stack (that hasn't been
verified, but it wouldn't be impossible considering
pmd_none_or_clear_bad, pmd_bad, pmd_trans_huge, pmd_none are all inlines
and there's no external function called in between pmd_trans_huge and
pmd_none_or_clear_bad).if (pmd_trans_huge(*pmd)) {
if (next-addr != HPAGE_PMD_SIZE) {
VM_BUG_ON(!rwsem_is_locked(&tlb->mm->mmap_sem));
split_huge_page_pmd(vma->vm_mm, pmd);
} else if (zap_huge_pmd(tlb, vma, pmd, addr))
continue;
/* fall through */
}
if (pmd_none_or_clear_bad(pmd))Because this race condition could be exercised without special
privileges this was reported in CVE-2012-1179.The race was identified and fully explained by Ulrich who debugged it.
I'm quoting his accurate explanation below, for reference.====== start quote =======
mapcount 0 page_mapcount 1
kernel BUG at mm/huge_memory.c:1384!At some point prior to the panic, a "bad pmd ..." message similar to the
following is logged on the console:mm/memory.c:145: bad pmd ffff8800376e1f98(80000000314000e7).
The "bad pmd ..." message is logged by pmd_clear_bad() before it clears
the page's PMD table entry.143 void pmd_clear_bad(pmd_t *pmd)
144 {
-> 145 pmd_ERROR(*pmd);
146 pmd_clear(pmd);
147 }After the PMD table entry has been cleared, there is an inconsistency
between the actual number of PMD table entries that are mapping the page
and the page's map count (_mapcount field in struct page). When the page
is subsequently reclaimed, __split_huge_page() detects this inconsistency.1381 if (mapcount != page_mapcount(page))
1382 printk(KERN_ERR "mapcount %d page_mapcount %d\n",
1383 mapcount, page_mapcount(page));
-> 1384 BUG_ON(mapcount != page_mapcount(page));The root cause of the problem is a race of two threads in a multithreaded
process. Thread B incurs a page fault on a virtual address that has never
been accessed (PMD entry is zero) while Thread A is executing an madvise()
system call on a virtual address within the same 2 MB (huge page) range.virtual address space
.---------------------.
| |
| |
.-|---------------------|
| | |
| | |< |/////////////////////| > A(range)
page | |/////////////////////|-'
| | |
| | |
'-|---------------------|
| |
| |
'---------------------'- Thread A is executing an madvise(..., MADV_DONTNEED) system call
on the virtual address range "A(range)" shown in the picture.sys_madvise
// Acquire the semaphore in shared mode.
down_read(¤t->mm->mmap_sem)
...
madvise_vma
switch (behavior)
case MADV_DONTNEED:
madvise_dontneed
zap_page_range
unmap_vmas
unmap_page_range
zap_pud_range
zap_pmd_range
//
// Assume that this huge page has never been accessed.
// I.e. content of the PMD entry is zero (not mapped).
//
if (pmd_trans_huge(*pmd)) {
// We don't get here due to the above assumption.
}
//
// Assume that Thread B incurred a page fault and
.---------> // sneaks in here as shown below.
| //
| if (pmd_none_or_clear_bad(pmd))
| {
| if (unlikely(pmd_bad(*pmd)))
| pmd_clear_bad
| {
| pmd_ERROR
| // Log "bad pmd ..." message here.
| pmd_clear
| // Clear the page's PMD entry.
| // Thread B incremented the map count
| // in page_add_new_anon_rmap(), but
| // now the page is no longer mapped
| // by a PMD entry (-> inconsistency).
| }
| }
|
v
- Thread B is handling a page fault on virtual address "B(fault)" shown
in the picture....
do_page_fault
__do_page_fault
// Acquire the semaphore in shared mode.
down_read_trylock(&mm->mmap_sem)
...
handle_mm_fault
if (pmd_none(*pmd) && transparent_hugepage_enabled(vma))
// We get here due to the above assumption (PMD entry is zero).
do_huge_pmd_anonymous_page
alloc_hugepage_vma
// Allocate a new transparent huge page here.
...
__do_huge_pmd_anonymous_page
...
spin_lock(&mm->page_table_lock)
...
page_add_new_anon_rmap
// Here we increment the page's map count (starts at -1).
atomic_set(&page->_mapcount, 0)
set_pmd_at
// Here we set the page's PMD entry which will be cleared
// when Thread A calls pmd_clear_bad().
...
spin_unlock(&mm->page_table_lock)The mmap_sem does not prevent the race because both threads are acquiring
it in shared mode (down_read). Thread B holds the page_table_lock while
the page's map count and PMD table entry are updated. However, Thread A
does not synchronize on that lock.====== end quote =======
[akpm@linux-foundation.org: checkpatch fixes]
Reported-by: Ulrich Obergfell
Signed-off-by: Andrea Arcangeli
Acked-by: Johannes Weiner
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Dave Jones
Acked-by: Larry Woodman
Acked-by: Rik van Riel
Cc: Mark Salter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream.
With the recent changes to clear_IO_APIC_pin() which tries to
clear remoteIRR bit explicitly, some of the users started to see
"Unable to reset IRR for apic .." messages.Close look shows that these are related to bogus IO-APIC entries
which return's all 1's for their io-apic registers. And the
above mentioned error messages are benign. But kernel should
have ignored such io-apic's in the first place.Check if register 0, 1, 2 of the listed io-apic are all 1's and
ignore such io-apic.Reported-by: Álvaro Castillo
Tested-by: Jon Dufresne
Signed-off-by: Suresh Siddha
Cc: yinghai@kernel.org
Cc: kernel-team@fedoraproject.org
Cc: Josh Boyer
Link: http://lkml.kernel.org/r/1331577393.31585.94.camel@sbsiddha-desk.sc.intel.com
[ Performed minor cleanup of affected code. ]
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit f4a0391dfa91155bd961673b31eb42d9d45c799d upstream.
Fix the following build warning:
warning: (IMA) selects TCG_TPM which has unmet direct dependencies
(HAS_IOMEM && EXPERIMENTAL)Suggested-by: Rajiv Andrade
Signed-off-by: Fabio Estevam
Signed-off-by: Rajiv Andrade
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit 89e984e2c2cd14f77ccb26c47726ac7f13b70ae8 upstream.
An iser target may send iscsi NO-OP PDUs as soon as it marks the iSER
iSCSI session as fully operative. This means that there is window
where there are no posted receive buffers on the initiator side, so
it's possible for the iSER RC connection to break because of RNR NAK /
retry errors. To fix this, rely on the flags bits in the login
request to have FFP (0x3) in the lower nibble as a marker for the
final login request, and post an initial chunk of receive buffers
before sending that login request instead of after getting the login
response.Signed-off-by: Or Gerlitz
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman -
commit 48752f6513012a1b078da08b145d5c40a644f058 upstream.
Add VF spoof check to IFLA policy. The original patch I submitted to
add the spoof checking feature to rtnl failed to add the proper policy
rule that identifies the data type and len. This patch corrects that
oversight. No bugs have been reported against this but it may cause
some problem for the netlink message parsing that uses the policy
table.Signed-off-by: Greg Rose
Tested-by: Sibai Li
Signed-off-by: Jeff Kirsher
Signed-off-by: Greg Kroah-Hartman -
commit 62ebeed8d00aef75eac4fd6c161cae75a41965ca upstream.
This makes it possible to reload driver if insmod has failed due to
missing firmware.Signed-off-by: Max Filippov
Acked-by: Christian Lamparter
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 41c7f7424259ff11009449f87c95656f69f9b186 upstream.
Currently, the RTC code does not disable the alarm in the hardware.
This means that after a sequence such as the one below (the files are in the
RTC sysfs), the box will boot up after 2 minutes even though we've
asked for the alarm to be turned off.# echo $((`cat since_epoch`)+120) > wakealarm
# echo 0 > wakealarm
# poweroffFix this by disabling the alarm when there are no timers to run.
The original version of this patch was reverted. This version
disables the irq directly instead of setting a disabled timer
in the future.Cc: John Stultz
Signed-off-by: Rabin Vincent
[Merged in the second revision from Rabin]
Signed-off-by: John Stultz
Signed-off-by: Greg Kroah-Hartman -
commit 540b60e24f3f4781d80e47122f0c4486a03375b8 upstream.
We do not want a bitwise AND between boolean operands
Signed-off-by: Alexander Gordeev
Cc: Oleg Nesterov
Link: http://lkml.kernel.org/r/20120309135912.GA2114@dhcp-26-207.brq.redhat.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 upstream.
In 2008, commit 0c5d1eb77a8be ("genirq: record trigger type") modified the
way set_irq_type() handles the 'no trigger' condition. However, this has
an adverse effect on PCMCIA support on Intel StrongARM and probably PXA
platforms.PCMCIA has several status signals on the socket which can trigger
interrupts; some of these status signals depend on the card's mode
(whether it is configured in memory or IO mode). For example, cards have
a 'Ready/IRQ' signal: in memory mode, this provides an indication to
PCMCIA that the card has finished its power up initialization. In IO
mode, it provides the device interrupt signal. Other status signals
switch between on-board battery status and loud speaker output.In classical PCMCIA implementations, where you have a specific socket
controller, the controller provides a method to mask interrupts from the
socket, and importantly ignore any state transitions on the pins which
correspond with interrupts once masked. This masking prevents unwanted
events caused by the removal and application of socket power being
forwarded.However, on platforms where there is no socket controller, the PCMCIA
status and interrupt signals are routed to standard edge-triggered GPIOs.
These GPIOs can be configured to interrupt on rising edge, falling edge,
or never. This is where the problems start.Edge triggered interrupts are required to record events while disabled via
the usual methods of {free,request,disable,enable}_irq() to prevent
problems with dropped interrupts (eg, the 8390 driver uses disable_irq()
to defer the delivery of interrupts). As a result, these interfaces can
not be used to implement the desired behaviour.The side effect of this is that if the 'Ready/IRQ' GPIO is disabled via
disable_irq() on suspend, and enabled via enable_irq() after resume, we
will record the state transitions caused by powering events as valid
interrupts, and foward them to the card driver, which may attempt to
access a card which is not powered up.This leads delays resume while drivers spin in their interrupt handlers,
and complaints from drivers before they realize what's happened.Moreover, in the case of the 'Ready/IRQ' signal, this is requested and
freed by the card driver itself; the PCMCIA core has no idea whether the
interrupt is requested, and, therefore, whether a call to disable_irq()
would be valid. (We tried this around 2.4.17 / 2.5.1 kernel era, and
ended up throwing it out because of this problem.)Therefore, it was decided back in around 2002 to disable the edge
triggering instead, resulting in all state transitions on the GPIO being
ignored. That's what we actually need the hardware to do.The commit above changes this behaviour; it explicitly prevents the 'no
trigger' state being selected.The reason that request_irq() does not accept the 'no trigger' state is
for compatibility with existing drivers which do not provide their desired
triggering configuration. The set_irq_type() function is 'new' and not
used by non-trigger aware drivers.Therefore, revert this change, and restore previously working platforms
back to their former state.Signed-off-by: Russell King
Cc: linux@arm.linux.org.uk
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 7b60a18da393ed70db043a777fd9e6d5363077c4 upstream.
The queue handling in the udev daemon assumes that the events are
ordered.Before this patch uevent_seqnum is incremented under sequence_lock,
than an event is send uner uevent_sock_mutex. I want to say that code
contained a window between incrementing seqnum and sending an event.This patch locks uevent_sock_mutex before incrementing uevent_seqnum.
v2: delete sequence_lock, uevent_seqnum is protected by uevent_sock_mutex
v3: unlock the mutex before the goto exitThanks for Kay for the comments.
Signed-off-by: Andrew Vagin
Tested-By: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
commit a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33 upstream.
'long secs' is passed as divisor to div_s64, which accepts a 32bit
divisor. On 64bit machines that value is trimmed back from 8 bytes
back to 4, causing a divide by zero when the number is bigger than
(1 << 32) - 1 and all 32 lower bits are 0.Use div64_long() instead.
Signed-off-by: Sasha Levin
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1331829374-31543-2-git-send-email-levinsasha928@gmail.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit f910381a55cdaa097030291f272f6e6e4380c39a upstream.
Add a div64_long macro which is used to devide a 64bit number by a long (which
can be 4 bytes on 32bit systems and 8 bytes on 64bit systems).Suggested-by: Thomas Gleixner
Signed-off-by: Sasha Levin
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1331829374-31543-1-git-send-email-levinsasha928@gmail.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912 upstream.
If we only monitor while associated, the following
can happen:
- we're associated, and the queue stuck check
runs, setting the queue "touch" time to X
- we disassociate, stopping the monitoring,
which leaves the time set to X
- almost 2s later, we associate, and enqueue
a frame
- before the frame is transmitted, we monitor
for stuck queues, and find the time set to
X, although it is now later than X + 2000ms,
so we decide that the queue is stuck and
erroneously restart the deviceIt happens more with P2P because there we can
go between associated/unassociated frequently.Reported-by: Ben Cahill
Signed-off-by: Johannes Berg
Signed-off-by: Wey-Yi Guy
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit a9b89e2567c743483e6354f64d7a7e3a8c101e9e upstream.
Driver rtl8192ce when used with the RTL8188CE device would start at about
20 Mbps on a 54 Mbps connection, but quickly drop to 1 Mbps. One of the
symptoms is that the AP would need to retransmit each packet 4 of 5 times
before the driver would acknowledge it. Recovery is possible only by
unloading and reloading the driver. This problem was reported at
https://bugzilla.redhat.com/show_bug.cgi?id=770207.The problem is due to a missing update of the gain setting.
Signed-off-by: Jingjun Wu
Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit ebecdcc12fed5d3c81853dea61a0a78a5aefab52 upstream.
When driver rtl8192cu is used with the debug level set to 3 or greater,
the result is "sleeping function called from invalid context" due to
an rcu_read_lock() call in the DM refresh routine in driver rtl8192c.
This lock is not necessary as the USB driver does not use the struct
being protected, thus the lock is set only when a PCI interface is
active.This bug is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42775.
Reported-by: Ronald Wahl
Tested-by: Ronald Wahl
Signed-off-by: Larry Finger
Cc: Ronald Wahl
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 7f66c2f93e5779625c10d262c84537427a2673ca upstream.
Handle previous allocation failures when freeing device memory
Signed-off-by: Simon Graham
Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 76a92be537f1c8c259e393632301446257ca3ea9 upstream.
In https://bugzilla.redhat.com/show_bug.cgi?id=771656, a kernel bug was
triggered due to a failed skb allocation that was not checked. This event
lead to an audit of all memory allocations in the complete rtlwifi family
of drivers. This patch fixes the rest.Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit d42a179b941a9e4cc6cf41d0f3cbadd75fc48a89 upstream.
This is an RT3070 based device.
Reported-by: Mikhail Kryshen
Signed-off-by: Gertjan van Wingerde
Acked-by: Ivo van Doorn
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 093ea2d3a766cb8a4c4de57efec6c0a127a58792 upstream.
A MCS7820 device supports two serial ports and a MCS7840 device supports
four serial ports. Both devices use the same driver, but the attach function
in driver was unable to correctly handle the port numbers for MCS7820
device. This problem has been fixed in this patch and this fix has been
verified on x86 Linux kernel 3.2.9 with both MCS7820 and MCS7840 devices.Signed-off-by: Donald Lee
Signed-off-by: Greg Kroah-Hartman -
commit a5360a53a7ccad5ed9ccef210b94fef13c6e5529 upstream.
This patch updates the cp210x driver to support CP210x multiple
interface devices devices from Silicon Labs. The existing driver
always sends control requests to interface 0, which is hardcoded in
the usb_control_msg function calls. This only allows for single
interface devices to be used, and causes a bug when using ports on an
interface other than 0 in the multiple interface devices.Here are the changes included in this patch:
- Updated the device list to contain the Silicon Labs factory default
VID/PID for multiple interface CP210x devices
- Created a cp210x_port_private struct created for each port on
startup, this struct holds the interface number
- Added a cp210x_release function to clean up the cp210x_port_private
memory created on startup
- Modified usb_get_config and usb_set_config to get a pointer to the
cp210x_port_private struct, and use the interface number there in the
usb_control_message wIndex paramSigned-off-by: Preston Fick
Signed-off-by: Greg Kroah-Hartman -
commit 6d161b99f875269ad4ffa44375e1e54bca6fd02e upstream.
This patch adds new device IDs to the ftdi_sio module to support
the new Sealevel SeaLINK+8 2038-ROHS device.Signed-off-by: Scott Dial
Signed-off-by: Greg Kroah-Hartman -
commit c192c8e71a2ded01170c1a992cd21aaedc822756 upstream.
Gobi 1000 devices have a different port layout, which wasn't respected
by the current driver, and thus it grabbed the QMI/net port. In the
near future we'll be attaching another driver to the QMI/net port for
these devices (cdc-wdm and qmi_wwan) so make sure the qcserial driver
doesn't claim them. This patch also prevents qcserial from binding to
interfaces 0 and 1 on 1K devices because those interfaces do not
respond.Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit 2db4d87070e87d198ab630e66a898b45eff316d9 upstream.
Signed-off-by: Thomas Tuttle
Signed-off-by: Greg Kroah-Hartman -
commit 4898e07174b79013afd2b422ef6c4336ef8e6783 upstream.
__do_config_autodelink passes the data variable to the transport function.
If the calling functions pass a stack variable, this will eventually trigger
a DMA-API debug backtrace for mapping stack memory in the DMA buffer. Fix
this by calling kmemdup for the passed data instead.Signed-off-by: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit e90fc3cb087ce5c5f81e814358222cd6d197b5db upstream.
When build i.mx platform with imx_v6_v7_defconfig, and after adding
USB Gadget support, it has below build error:CC drivers/usb/host/fsl-mph-dr-of.o
drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register':
drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata'
has no member named 'dma_mask'It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html
For PowerPC, there is dma_mask at struct pdev_archdata, but there is
no dma_mask at struct pdev_archdata for ARM. The pdev_archdata is
related to specific platform, it should NOT be accessed by
cross platform drivers, like USB.The code for pdev_archdata should be useless, as for PowerPC,
it has already gotten the value for pdev->dev.dma_mask at function
arch_setup_pdev_archdata of arch/powerpc/kernel/setup-common.c.Tested-by: Ramneek Mehresh
Signed-off-by: Peter Chen
Signed-off-by: Greg Kroah-Hartman -
commit c5cc5ed86667d4ae74fe40ee4ed893f4b46aba05 upstream.
When loading g_ether gadget, there is below message:
Backtrace:
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c)
r7:00000000 r6:80512000 r5:8052bef8 r4:80513f30
[] (dump_stack+0x0/0x1c) from [] (show_regs+0x44/0x50)
[] (show_regs+0x0/0x50) from [] (__schedule_bug+0x68/0x84)
r5:8052bef8 r4:80513f30
[] (__schedule_bug+0x0/0x84) from [] (__schedule+0x4b0/0x528)
r5:8052bef8 r4:809aad00
[] (__schedule+0x0/0x528) from [] (_cond_resched+0x44/0x58)
[] (_cond_resched+0x0/0x58) from [] (dma_pool_alloc+0x184/0x250)
r5:9f9b4000 r4:9fb4fb80
[] (dma_pool_alloc+0x0/0x250) from [] (fsl_req_to_dtd+0xac/0x180)
[] (fsl_req_to_dtd+0x0/0x180) from [] (fsl_ep_queue+0x138/0x274)
[] (fsl_ep_queue+0x0/0x274) from [] (composite_setup+0x2d4/0xfac [g_ether])
[] (composite_setup+0x0/0xfac [g_ether]) from [] (fsl_udc_irq+0x8dc/0xd38)
[] (fsl_udc_irq+0x0/0xd38) from [] (handle_irq_event_percpu+0x54/0x188)
[] (handle_irq_event_percpu+0x0/0x188) from [] (handle_irq_event+0x48/0x68)
[] (handle_irq_event+0x0/0x68) from [] (handle_level_irq+0xb4/0x138)
r5:80514f94 r4:80514f40
[] (handle_level_irq+0x0/0x138) from [] (generic_handle_irq+0x38/0x44)
r7:00000012 r6:80510b1c r5:80529860 r4:80512000
[] (generic_handle_irq+0x0/0x44) from [] (handle_IRQ+0x54/0xb4)
[] (handle_IRQ+0x0/0xb4) from [] (tzic_handle_irq+0x64/0x94)
r9:412fc085 r8:00000000 r7:80513f30 r6:00000001 r5:00000000
r4:00000000
[] (tzic_handle_irq+0x0/0x94) from [] (__irq_svc+0x40/0x60)The reason of above dump message is calling dma_poll_alloc with can-schedule
mem_flags at atomic context.To fix this problem, below changes are made:
- fsl_req_to_dtd doesn't need to be protected by spin_lock_irqsave,
as struct usb_request can be access at process context. Move lock
to beginning of hardware visit (fsl_queue_td).
- Change the memory flag which using to allocate dTD descriptor buffer,
the memory flag can be from gadget layer.It is tested at i.mx51 bbg board with g_mass_storage, g_ether, g_serial.
Signed-off-by: Peter Chen
Acked-by: Li Yang
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit b7a205545345578712611106b371538992e142ff upstream.
The WDM_READ flag is cleared later iff desc->length is reduced to 0.
Signed-off-by: Ben Hutchings
Tested-by: Bjørn Mork
Cc: Oliver Neukum
Signed-off-by: Greg Kroah-Hartman -
commit 711c68b3c0f7a924ffbee4aa962d8f62b85188ff upstream.
We must not allow the input buffer length to change while we're
shuffling the buffer contents. We also mustn't clear the WDM_READ
flag after more data might have arrived. Therefore move both of these
into the spinlocked region at the bottom of wdm_read().When reading desc->length without holding the iuspin lock, use
ACCESS_ONCE() to ensure the compiler doesn't re-read it with
inconsistent results.Signed-off-by: Ben Hutchings
Tested-by: Bjørn Mork
Cc: Oliver Neukum
Signed-off-by: Greg Kroah-Hartman -
commit 548dd4b6da8a8e428453d55f7fa7b8a46498d147 upstream.
Do not report errors in write path if port is used as a console as this
may trigger the same error (and error report) resulting in a loop.Reported-by: Stephen Hemminger
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 4a4c61b7ce26bfc9d49ea4bd121d52114bad9f99 upstream.
Bugzilla 40012: PIO_UNIMAP bug: error updating Unicode-to-font map
https://bugzilla.kernel.org/show_bug.cgi?id=40012The unicode font map for the virtual console is a 32x32x64 table which
allocates rows dynamically as entries are added. The unicode value
increases sequentially and should count all entries even in empty
rows. The defect is when copying the unicode font map in con_set_unimap(),
the unicode value is not incremented properly. The wrong unicode value
is entered in the new font map.Signed-off-by: Liz Clark
Signed-off-by: Greg Kroah-Hartman -
commit 58112dfbfe02d803566a2c6c8bd97b5fa3c62cdc upstream.
This is supposed to be doing a shift before the comparison instead of
just doing a bitwise AND directly. The current code means the start()
just returns without doing anything.Signed-off-by: Dan Carpenter
Acked-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
commit 93518dd2ebafcc761a8637b2877008cfd748c202 upstream.
This patch fixies follwing two memory leak patterns that reported by kmemleak.
sysfs_sd_setsecdata() is called during sys_lsetxattr() operation.
It checks sd->s_iattr is NULL or not. Then if it is NULL, it calls
sysfs_init_inode_attrs() to allocate memory.
That code is this.iattrs = sd->s_iattr;
if (!iattrs)
iattrs = sysfs_init_inode_attrs(sd);The iattrs recieves sysfs_init_inode_attrs()'s result, but sd->s_iattr
doesn't know the address. so it needs to set correct address to
sd->s_iattr to free memory in other function.unreferenced object 0xffff880250b73e60 (size 32):
comm "systemd", pid 1, jiffies 4294683888 (age 94.553s)
hex dump (first 32 bytes):
73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f system_u:object_
72 3a 73 79 73 66 73 5f 74 3a 73 30 00 00 00 00 r:sysfs_t:s0....
backtrace:
[] kmemleak_alloc+0x73/0x98
[] __kmalloc+0x100/0x12c
[] context_struct_to_string+0x106/0x210
[] security_sid_to_context_core+0x10b/0x129
[] security_sid_to_context+0x10/0x12
[] selinux_inode_getsecurity+0x7d/0xa8
[] selinux_inode_getsecctx+0x22/0x2e
[] security_inode_getsecctx+0x16/0x18
[] sysfs_setxattr+0x96/0x117
[] __vfs_setxattr_noperm+0x73/0xd9
[] vfs_setxattr+0x83/0xa1
[] setxattr+0xcf/0x101
[] sys_lsetxattr+0x6a/0x8f
[] system_call_fastpath+0x16/0x1b
[] 0xffffffffffffffff
unreferenced object 0xffff88024163c5a0 (size 96):
comm "systemd", pid 1, jiffies 4294683888 (age 94.553s)
hex dump (first 32 bytes):
00 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 .....A..........
00 00 00 00 00 00 00 00 0c 64 42 4f 00 00 00 00 .........dBO....
backtrace:
[] kmemleak_alloc+0x73/0x98
[] kmem_cache_alloc_trace+0xc4/0xee
[] sysfs_init_inode_attrs+0x2a/0x83
[] sysfs_setxattr+0xbf/0x117
[] __vfs_setxattr_noperm+0x73/0xd9
[] vfs_setxattr+0x83/0xa1
[] setxattr+0xcf/0x101
[] sys_lsetxattr+0x6a/0x8f
[] system_call_fastpath+0x16/0x1b
[] 0xffffffffffffffff
`Signed-off-by: Masami Ichikawa
Signed-off-by: Greg Kroah-Hartman -
commit 59263b513c11398cd66a52d4c5b2b118ce1e0359 upstream.
Some of the newer futex PI opcodes do not check the cmpxchg enabled
variable and call unconditionally into the handling functions. Cover
all PI opcodes in a separate check.Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Darren Hart
Signed-off-by: Greg Kroah-Hartman -
commit 33d2832ab0149a26418d360af3c444969a63fb28 upstream.
HID devices should specify this in their interface descriptors, not in the
device descriptor. This fixes a "missing hardware id" bug under Windows 7 with
a VIA VL800 (3.0) controller.Signed-off-by: Orjan Friberg
Cc: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 85b4b3c8c189e0159101f7628a71411af072ff69 upstream.
A read from GadgetFS endpoint 0 during the data stage of a control
request would always return 0 on success (as returned by
wait_event_interruptible) despite having written data into the user
buffer.
This patch makes it correctly set the return value to the number of
bytes read.Signed-off-by: Thomas Faber
Signed-off-by: Greg Kroah-Hartman -
commit 3b2a2e47174cd978258bbb0fdf2e2b1b5ec2144c upstream.
This patch fixup below warning on device_unregister()
renesas_usbhs renesas_usbhs.1: host probed
renesas_usbhs renesas_usbhs.1: gadget probed
renesas_usbhs renesas_usbhs.1: irq request err
------------[ cut here ]------------
WARNING: at ${LINUX}/drivers/base/core.c:1)
Device 'gadget' does not have a release() function, it is broken and must be fi.
Modules linked in:
[] (unwind_backtrace+0x0/0xe4) from [] (warn_slowpath_commo)
[] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_)
[] (warn_slowpath_fmt+0x2c/0x3c) from [] (device_release+0x)
[] (device_release+0x70/0x84) from [] (kobject_cleanup+0x58)
[] (kobject_cleanup+0x58/0x6c) from [] (usbhs_mod_gadget_re)
[] (usbhs_mod_gadget_remove+0x3c/0x6c) from [] (usbhs_mod_p)
[] (usbhs_mod_probe+0x68/0x80) from [] (usbhs_probe+0x1cc/0)
...Signed-off-by: Kuninori Morimoto
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 39287076e46d2c19aaceaa6f0a44168ae4d257ec upstream.
musb INDEX register is getting modified/corrupted during temporary
un-locking in a SMP system. Set this register with proper value
after re-acquiring the lockScenario:
---------
CPU1 is handling a data transfer completion interrupt received for
the CLASS1 EP
CPU2 is handling a CLASS2 thread which is queuing data to musb for
transferBelow is the error sequence:
CPU1 | CPU2
--------------------------------------------------------------------
Data transfer completion inter- |
rupt recieved. |
|
musb INDEX reg set to CLASS1 EP |
|
musb LOCK is acquired. |
|
| CLASS2 thread queues data.
|
| CLASS2 thread tries to acquire musb
| LOCK but lock is already taken by
| CLASS1, so CLASS2 thread is
| spinning.
|
From Interrupt Context musb |
giveback function is called |
|
The giveback function releases | CLASS2 thread now acquires LOCK
LOCK |
|
ClASS1 Request's completion cal-| ClASS2 schedules the data transfer and
lback is called | sets the MUSB INDEX to Class2 EP number
|
Interrupt handler for CLASS1 EP |
tries to acquire LOCK and is |
spinning |
|
Interrupt for Class1 EP acquires| Class2 completes the scheduling etc and
the MUSB LOCK | releases the musb LOCK
|
Interrupt for Class1 EP schedul-|
es the next data transfer |
but musb INDEX register is still|
set to CLASS2 EP |Since the MUSB INDEX register is set to a different endpoint, we
read and modify the wrong registers. Hence data transfer will not
happen properly. This results in unpredictable behaviorSo, the MUSB INDEX register is set to proper value again when
interrupt re-acquires the lockSigned-off-by: Supriya Karanth
Signed-off-by: Praveena Nadahally
Reviewed-by: srinidhi kasagar
Signed-off-by: Felipe Balbi -
commit 27a78d6a283d6782438f72306746afe4bf44c215 upstream.
It's wrong to use the size of array as an argument for strncat.
Memory corruption is possible. strlcat is exactly what we need here.Signed-off-by: Anton Tikhomirov
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 9bafa56c7cee5c6fa68de5924220abb220c7e229 upstream.
Zero is a valid value for a microframe number. So remove the bogus
test for non-zero in dwc3_gadget_start_isoc().Signed-off-by: Paul Zimmerman
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit da3e6ec2f443ac00aa623c5921e3521f5f38efe4 upstream.
In commit c6dc001 "staging: r8712u: Merging Realtek's latest (v2.6.6).
Various fixes", the returned qual.qual member of the iw_statistics
struct was changed. For strong signals, this change made no difference;
however for medium and weak signals it results in a low signal that
shows considerable fluctuation, When using wicd for a medium-strength
AP, the value reported in the status line is reduced from 100% to 60% by
this bug.This problem is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42826.
Reported-and-tested-by: Robert Crawford
Signed-off-by: Larry Finger
Signed-off-by: Greg Kroah-Hartman
