Prevent a preemption event causing the initialized VFP state being
overwritten by ensuring that the VFP hardware access is disabled
prior to starting initialization. We can then do this in safety
while still allowing preemption to occur.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix a hole in the VFP thread migration. Lets define two threads.
Thread 1, we'll call 'interesting_thread' which is a thread which is
running on CPU0, using VFP (so vfp_current_hw_state[0] =
&interesting_thread->vfpstate) and gets migrated off to CPU1, where
it continues execution of VFP instructions.
Thread 2, we'll call 'new_cpu0_thread' which is the thread which takes
over on CPU0. This has also been using VFP, and last used VFP on CPU0,
but doesn't use it again.
The following code will be executed twice:
cpu = thread->cpu;
/*
* On SMP, if VFP is enabled, save the old state in
* case the thread migrates to a different CPU. The
* restoring is done lazily.
*/
if ((fpexc & FPEXC_EN) && vfp_current_hw_state[cpu]) {
vfp_save_state(vfp_current_hw_state[cpu], fpexc);
vfp_current_hw_state[cpu]->hard.cpu = cpu;
}
/*
* Thread migration, just force the reloading of the
* state on the new CPU in case the VFP registers
* contain stale data.
*/
if (thread->vfpstate.hard.cpu != cpu)
vfp_current_hw_state[cpu] = NULL;
The first execution will be on CPU0 to switch away from 'interesting_thread'.
interesting_thread->cpu will be 0.
So, vfp_current_hw_state[0] points at interesting_thread->vfpstate.
The hardware state will be saved, along with the CPU number (0) that
it was executing on.
'thread' will be 'new_cpu0_thread' with new_cpu0_thread->cpu = 0.
Also, because it was executing on CPU0, new_cpu0_thread->vfpstate.hard.cpu = 0,
and so the thread migration check is not triggered.
This means that vfp_current_hw_state[0] remains pointing at interesting_thread.
The second execution will be on CPU1 to switch _to_ 'interesting_thread'.
So, 'thread' will be 'interesting_thread' and interesting_thread->cpu now
will be 1. The previous thread executing on CPU1 is not relevant to this
so we shall ignore that.
We get to the thread migration check. Here, we discover that
interesting_thread->vfpstate.hard.cpu = 0, yet interesting_thread->cpu is
now 1, indicating thread migration. We set vfp_current_hw_state[1] to
NULL.
So, at this point vfp_current_hw_state[] contains the following:
[0] = &interesting_thread->vfpstate
[1] = NULL
Our interesting thread now executes a VFP instruction, takes a fault
which loads the state into the VFP hardware. Now, through the assembly
we now have:
[0] = &interesting_thread->vfpstate
[1] = &interesting_thread->vfpstate
CPU1 stops due to ptrace (and so saves its VFP state) using the thread
switch code above), and CPU0 calls vfp_sync_hwstate().
if (vfp_current_hw_state[cpu] == &thread->vfpstate) {
vfp_save_state(&thread->vfpstate, fpexc | FPEXC_EN);
BANG, we corrupt interesting_thread's VFP state by overwriting the
more up-to-date state saved by CPU1 with the old VFP state from CPU0.
Fix this by ensuring that we have sane semantics for the various state
describing variables:
1. vfp_current_hw_state[] points to the current owner of the context
information stored in each CPUs hardware, or NULL if that state
information is invalid.
2. thread->vfpstate.hard.cpu always contains the most recent CPU number
which the state was loaded into or NR_CPUS if no CPU owns the state.
So, for a particular CPU to be a valid owner of the VFP state for a
particular thread t, two things must be true:
vfp_current_hw_state[cpu] == &t->vfpstate && t->vfpstate.hard.cpu == cpu.
and that is valid from the moment a CPU loads the saved VFP context
into the hardware. This gives clear and consistent semantics to
interpreting these variables.
This patch also fixes thread copying, ensuring that t->vfpstate.hard.cpu
is invalidated, otherwise CPU0 may believe it was the last owner. The
hole can happen thus:
- thread1 runs on CPU2 using VFP, migrates to CPU3, exits and thread_info
freed.
- New thread allocated from a previously running thread on CPU2, reusing
memory for thread1 and copying vfp.hard.cpu.
At this point, the following are true:
new_thread1->vfpstate.hard.cpu == 2
&new_thread1->vfpstate == vfp_current_hw_state[2]
Lastly, this also addresses thread flushing in a similar way to thread
copying. Hole is:
- thread runs on CPU0, using VFP, migrates to CPU1 but does not use VFP.
- thread calls execve(), so thread flush happens, leaving
vfp_current_hw_state[0] intact. This vfpstate is memset to 0 causing
thread->vfpstate.hard.cpu = 0.
- thread migrates back to CPU0 before using VFP.
At this point, the following are true:
thread->vfpstate.hard.cpu == 0
&thread->vfpstate == vfp_current_hw_state[0]
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rename this branch to more accurately reflect why its taken, rather
than what the following code does. It is the only caller of this code.
This helps to clarify following changes, yet this change results in no
actual code change.
Document the VFP hardware state at the target of this branch.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rename the slightly confusing 'last_VFP_context' variable to be more
descriptive of what it actually is. This variable stores a pointer
to the current owner's vfpstate structure for the context held in the
VFP hardware.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When a process doesn't have /dev/xt_qtaguid open, only warn once
instead of for every ctrl access.
Change-Id: I98a462a8731254ddc3bf6d2fefeef9823659b1f0
Signed-off-by: JP Abgrall <jpa@google.com>
It is possible that while one driver has already suspended,
another driver calls otg_id_notify() because it has not yet been
suspended. It would then be possible for the suspended driver's
detect callback to be called. This is undesirable.
Introduce new otg_id_suspend/otg_id_resume functions that
keep a suspended count, and if a notification happens while
someone is suspended, that notification is deferred until
all the drivers are resumed. If the notification happens before
the last driver is suspended, that suspend will be aborted
and once the final driver resumes through otg_id_resume, the
notification will be delivered.
Change-Id: I32fd32bec65e366e5f97a25c15255d94773b85b3
Signed-off-by: Dima Zavin <dima@android.com>
* Added global resource tracking based on tags.
- Can be put into passive mode via
/sys/modules/xt_qtaguid/params/tag_tracking_passive
- The number of socket tags per UID is now limited
- Adding /dev/xt_qtaguid that each process should open before starting
to tag sockets. A later change will make it a "must".
- A process should not create new tags unless it has the dev open.
A later change will make it a must.
- On qtaguid_resources release, the process' matching socket tag info
is deleted.
* Support run-time debug mask via /sys/modules parameter "debug_mask".
* split module into prettyprinting code, includes, main.
* Removed ptrdiff_t usage which didn't work in all cases.
Change-Id: I4a21d3bea55d23c1c3747253904e2a79f7d555d9
Signed-off-by: JP Abgrall <jpa@google.com>
It was using ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP_MASK as an
index.
Change-Id: I919860cc71254453e382616bce9fd5455802cb3d
Signed-off-by: JP Abgrall <jpa@google.com>
There is no need to take a wakelock for delayed lazy disable
work, it will be cancelled in the suspend handler and force
disabled. Only take the wakelock when the detect work is
queued, and make sure to drop the wakelock if the work is
cancelled.
Change-Id: I1e507a5f98848954ea21d45e23b6192c3132a349
Signed-off-by: Colin Cross <ccross@android.com>
- Add BT-Coex support to cfg80211
- Add private event logic to cfg80211 when FW hangs
- Reduce passive dwell time to 130 ms
- Fix proptx initialize fail issue
- Implement codes for WPS2.0 using cfg80211
- Clean any left virtual interfaces in primary dhd_stop context
- Skip waiting for rtnl_lock in cfg80211 callback if already taken
- Skip writing to file FW trap info
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
This patch introduces the helper of ehci_sync_mem to flush
qtd/qh into memory immediately on some ARM, so that HC can
see the up-to-date qtd/qh descriptor asap.
This patch fixs one performance bug on ARM Cortex A9 dual core
platform, which has been reported on quite a few ARM machines
(OMAP4, Tegra 2, snowball...), see details from link of
https://bugs.launchpad.net/bugs/709245.
The patch has been tested ok on OMAP4 panda A1 board, and the
performance of 'dd' over usb mass storage can be increased from
4~5MB/sec to 14~16MB/sec after applying this patch.
Change-Id: I7994c58a1001c7f46f13e09420328a3916bbfcef
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Commit 330605423c fixed l2cap conn establishment for non-ssp remote
devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
is tested (which was always returning failure on any subsequent
security checks).
However, this broke l2cap conn establishment for ssp remote devices
when an ACL link was already established at SDP-level security. This
fix ensures that encryption must be pending whenever authentication
is also pending.
Change-Id: I6876ea5134e90d1f3d0f84e8ed40b92977b3df64
Signed-off-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
This is basically a more generic respin of 23746a6 ("HID: magicmouse: ignore
'ivalid report id' while switching modes") which got reverted later by
c3a492.
It turns out that on some configurations, this is actually still the case
and we are not able to detect in runtime.
The device reponds with 'invalid report id' when feature report switching it
into multitouch mode is sent to it.
This has been silently ignored before 0825411ade ("HID: bt: Wait for ACK
on Sent Reports"), but since this commit, it propagates -EIO from the _raw
callback .
So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's
how the device reacts in normal mode.
Sad, but following reality.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022
Change-Id: Ice409708bb7bd1b43bd86adde121a353f8d03835
Reported-by: Chase Douglas <chase.douglas@canonical.com>
Reported-by: Jaikumar Ganesh <jaikumarg@android.com>
Tested-by: Chase Douglas <chase.douglas@canonical.com>
Tested-by: Jaikumar Ganesh <jaikumarg@android.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Turns out that some devices don't call the notifier chains
with NETDEV_UNREGISTER.
So now we only track up/down as the points for tracking
active/inactive transitions and saving the get_dev_stats().
Change-Id: I948755962b4c64150b4d04f294fb4889f151e42b
Signed-off-by: JP Abgrall <jpa@google.com>
Suspend attempts can abort when the FUSE daemon is already frozen
and a client is waiting uninterruptibly for a response, causing
freezing of tasks to fail.
Use the freeze-friendly wait API, but disregard other signals.
Change-Id: Icefb7e4bbc718ccb76bf3c04daaa5eeea7e0e63c
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Bug discovered by Jan Kara:
Finally, commit 1449032be1 returned back
the old IO submission code but apparently it forgot to return the old
handling of uninitialized buffers so we unconditionnaly call
block_write_full_page() without specifying end_io function. So AFAICS
we never convert unwritten extents to written in some cases. For
example when I mount the fs as: mount -t ext4 -o
nomblk_io_submit,dioread_nolock /dev/ubdb /mnt and do
int fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, 0600);
char buf[1024];
memset(buf, 'a', sizeof(buf));
fallocate(fd, 0, 0, 16384);
write(fd, buf, sizeof(buf));
I get a file full of zeros (after remounting the filesystem so that
pagecache is dropped) instead of seeing the first KB contain 'a's.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Change-Id: I349e4e807d2f8bc3573a5e1b2393212e00ca7650
Signed-off-by: Ken Sumrall <ksumrall@android.com>
If the console_lock was held while the system was rebooted, the messages
in the temporary logbuffer would not have propogated to all the console
drivers.
This force releases the console lock if it failed to be acquired.
Change-Id: I193dcf7b968be17966833e50b8b8bc70d5d9fe89
Signed-off-by: Dima Zavin <dima@android.com>
/proc/net/xt_qtaguid/ctrl will now show:
active tagged sockets: lines of "sock=%p tag=0x%llx (uid=%u)"
sockets_tagged, : the number of sockets successfully tagged.
sockets_untagged: the number of sockets successfully untagged.
counter_set_changes: ctrl counter set change requests.
delete_cmds: ctrl delete commands completed.
iface_events: number of NETDEV_* events handled.
match_found_sk: sk found in skbuff without ct assist.
match_found_sk_in_ct: the number of times the connection tracker found
a socket for us. This happens when the skbuff didn't have info.
match_found_sk_none: the number of times no sk could be determined
successfully looked up. This indicates we don't know who the
data actually belongs to. This could be unsolicited traffic.
Change-Id: I3a65613bb24852e1eea768ab0320a6a7073ab9be
Signed-off-by: JP Abgrall <jpa@google.com>
sockfd_put() risks sleeping.
So when doing a delete ctrl command, defer the sockfd_put() and
kfree() to outside of the spinlock.
Change-Id: I5f8ab51d05888d885b2fbb035f61efa5b7abb88a
Signed-off-by: JP Abgrall <jpa@google.com>
At times, it is necessary for boards to provide some additional information
as part of panic logs. Provide information on the board hardware as part
of panic logs.
It is safer to print this information at the very end in case something
bad happens as part of the information retrieval itself.
To use this, set global mach_panic_string to an appropriate string in the
board file.
Change-Id: Id12cdda87b0cd2940dd01d52db97e6162f671b4d
Signed-off-by: Nishanth Menon <nm@ti.com>
* Don't hold the sockets after tagging.
sockfd_lookup() does a get() on the associated file.
There was no matching put() so a closed socket could never be
freed.
* Don't rely on struct member order for tag_node
The structs that had a struct tag_node member would work with
the *_tree_* routines only because tag_node was 1st.
* Improve debug messages
Provide info on who the caller is. Use unsigned int for uid.
* Only process NETDEV_UP events.
* Pacifier: disable netfilter matching. Leave .../stats header.
Change-Id: Iccb8ae3cca9608210c417597287a2391010dff2c
Signed-off-by: JP Abgrall <jpa@google.com>
This change fixes two problems.
First, it ensures that the hid-multitouch driver does not incorrectly
map GenericDesktop usages that are intended for other applications,
such as a Mouse.
Second, it sets the appropriate input properties so that user-space
can distinguish TouchScreen devices (INPUT_PROP_DIRECT) from
TouchPad devices (INPUT_PROP_POINTER) and configure them accordingly.
Change-Id: I8c2d947929186ffe7cf04b37c76e29b9abecf8cb
Signed-off-by: jeffbrown@android.com
When an hidp connection is added for a boot protocol input
device, don't release a device reference that was never
acquired. The device reference is acquired when the session
is linked to the session list (which hasn't happened yet when
hidp_setup_input is called).
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
When an hidp connection is added for a boot protocol input
device, only free the allocated device if device registration fails.
Subsequent failures should only unregister the device (the input
device api documents that unregister will also free the allocated
device).
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Once the session thread is running, cleanup must be
handled by the session thread only.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Commit f4d7cd4a4c introduced the usage of kthread API.
kthread_stop is a blocking function which returns only when
the thread exits. In this case, the thread can't exit because it's
waiting for the write lock, which is being held by bnep_del_connection()
which is waiting for the thread to exit -- deadlock.
Use atomic_t/wake_up_process instead to signal to the thread to exit.
Signed-off-by: Jaikumar Ganesh <jaikumar@google.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
No command should be send before Command Complete event for HCI
reset is received. This fix regression introduced by commit
6bd32326cda(Bluetooth: Use proper timer for hci command timout)
for chips whose reset command takes longer to complete (e.g. CSR)
resulting in next command being send before HCI reset completed.
Signed-off-by: Szymon Janc <szymon@janc.net.pl>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Use DEBUG_WAKEUP flag to show wakelocks that abort suspend, in
addition to showing wakelocks held during system resume.
DEBUG_WAKEUP is enabled by default.
Change-Id: If6fa68e8afbc482a5300ffab2964694b02b34f41
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Some otg_id handlers can detect what's connected but can't detect a change.
This allows that handler to pass off the waiting for ID change to a proxy.
Change-Id: Ib38b750c3da4bffc35e37b620ecee37c5d64d31f
Signed-off-by: Erik Gilling <konkers@android.com>
