- 01 Feb, 2017 24 commits
-
-
Frederic Weisbecker authored
This is one more step toward converting cputime accounting to pure nsecs. Signed-off-by:
Frederic Weisbecker <fweisbec@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@redhat.com> Cc: Stanislaw Gruszka <sgruszka@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Wanpeng Li <wanpeng.li@hotmail.com> Link: http://lkml.kernel.org/r/1485832191-26889-22-git-send-email-fweisbec@gmail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Frederic Weisbecker authored
Now that the whole cputime conversion to nsec units is complete, we can remove the compatibility accessors. Signed-off-by:
-
Frederic Weisbecker authored
Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Also convert itimers to use nsec based internal counters. This simplifies it and removes the whole game with error/inc_error which served to deal with cputime_t random granularity. Signed-off-by:
-
Frederic Weisbecker authored
Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Also convert posix-cpu-timers to use nsec based internal counters to simplify it. Signed-off-by:
-
Frederic Weisbecker authored
Signed-off-by:
-
Frederic Weisbecker authored
The irqtime is accounted is nsecs and stored in cpu_irq_time.hardirq_time and cpu_irq_time.softirq_time. Once the accumulated amount reaches a new jiffy, this one gets accounted to the kcpustat. This was necessary when kcpustat was stored in cputime_t, which could at worst have jiffies granularity. But now kcpustat is stored in nsecs so this whole discretization game with temporary irqtime storage has become unnecessary. We can now directly account the irqtime to the kcpustat. Signed-off-by:
-
Frederic Weisbecker authored
Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Signed-off-by:
-
Frederic Weisbecker authored
Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Signed-off-by:
-
Frederic Weisbecker authored
Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Signed-off-by:
-
Frederic Weisbecker authored
Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Signed-off-by:
-
Frederic Weisbecker authored
Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Signed-off-by:
-
Frederic Weisbecker authored
Not sure if MISDN stats are ABI but it displays task cputime in cputime_t raw value regardless of what type cputime_t wraps which could be either jiffies, nsecs, usecs, or whatever random time unit. Plus it wrongly assumes that cputime_t is long. Given that this dump is broken anyway, lets just display the nanosec value and stick with that. Signed-off-by:
-
Frederic Weisbecker authored
Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Signed-off-by:
-
Frederic Weisbecker authored
Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Signed-off-by:
-
Frederic Weisbecker authored
Now that most cputime readers use the transition API which return the task cputime in old style cputime_t, we can safely store the cputime in nsecs. This will eventually make cputime statistics less opaque and more granular. Back and forth convertions between cputime_t and nsecs in order to deal with cputime_t random granularity won't be needed anymore. Signed-off-by:
-
Frederic Weisbecker authored
This API returns a task's cputime in cputime_t in order to ease the conversion of cputime internals to use nsecs units instead. Blindly converting all cputime readers to use this API now will later let us convert more smoothly and step by step all these places to use the new nsec based cputime. Signed-off-by:
-
Frederic Weisbecker authored
cputime_t is being obsolete and replaced by nsecs units in order to make internal timestamps less opaque and more granular. Signed-off-by:
-
Frederic Weisbecker authored
cputime_t is going to be removed and replaced by nsecs units, so convert the drivers/macintosh/rack-meter.c use to u64.. Signed-off-by:
-
Frederic Weisbecker authored
Kernel CPU stats are stored in cputime_t which is an architecture defined type, and hence a bit opaque and requiring accessors and mutators for any operation. Converting them to nsecs simplifies the code and is one step toward the removal of cputime_t in the core code. Signed-off-by:
-
Frederic Weisbecker authored
It's a leftover from removed code. Signed-off-by:
-
Frederic Weisbecker authored
This will be needed for the cputime_t to nsec conversion. Signed-off-by:
-
Frederic Weisbecker authored
NSEC_PER_JIFFY is an ad-hoc redefinition of TICK_NSEC. Let's rather use a unique and well maintained version. Signed-off-by:
-
Ingo Molnar authored
Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-traceLinus Torvalds authored
Pull tracing fix from Steven Rostedt: "It was reported to me that the thread created by the hwlat tracer does not migrate after the first instance. I found that there was as small bug in the logic, and fixed it. It's minor, but should be fixed regardless. There's not much impact outside the hwlat tracer" * tag 'trace-4.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Fix hwlat kthread migration
-
- 31 Jan, 2017 10 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
Pull input subsystem fixes from Dmitry Torokhov: "A fix for a crash in the wm97xx driver and synaptics-rmi4 will stop throwing erroneous warnings." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: synaptics-rmi4 - fix reversed conditions in enable/disable_irq_wake Input: wm97xx - make missing platform data non-fatal
-
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroupLinus Torvalds authored
Pull cgroup fix from Tejun Heo: "The cgroup creation path was getting the order of operations wrong and exposing cgroups which don't have their names set yet to controllers which can lead to NULL derefs. This contains the fix for the bug" * 'for-4.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup: don't online subsystems before cgroup_name/path() are operational
-
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpuLinus Torvalds authored
Pull percpu fix from Tejun Heo: "Douglas found and fixed a ref leak bug in percpu_ref_tryget[_live](). The bug is caused by storing the return value of atomic_long_inc_not_zero() into an int temp variable before returning it as a bool. The interim cast to int loses the upper bits and can lead to false negatives. As percpu_ref uses a high bit to mark a draining counter, this can happen relatively easily. Fixed by using bool for the temp variable" * 'for-4.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: percpu-refcount: fix reference leak during percpu-atomic transition
-
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libataLinus Torvalds authored
Pull libata fixes from Tejun Heo: "Three libata fixes: an error handling fix, blacklist addition for another fallout from upping the default max sectors, and fix for a sense data reporting bug which affects new harddrives which can report sense data" * 'for-4.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: ata: sata_mv:- Handle return value of devm_ioremap. libata: Fix ATA request sense libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices
-
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hidLinus Torvalds authored
Pull HID fixes from Jiri Kosina: - regression fix (sleeping while atomic) for cp2112, from Johan Hovold - regression fix for proximity handling under certain circumstances in Wacom driver, from Jason Gerecke - functional fix for Logitech Rumblepad 2, from Ardinartsev Nikita * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: cp2112: fix gpio-callback error handling HID: cp2112: fix sleep-while-atomic HID: hid-lg: Fix immediate disconnection of Logitech Rumblepad 2 HID: usbhid: Quirk a AMI virtual mouse and keyboard with ALWAYS_POLL HID: wacom: Fix poor prox handling in 'wacom_pl_irq'
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull cifs fix from Steve French: "A small cifs fix for stable" * 'for-next' of git://git.samba.org/sfrench/cifs-2.6: cifs: initialize file_info_lock
-
Steven Rostedt (VMware) authored
The hwlat tracer creates a kernel thread at start of the tracer. It is pinned to a single CPU and will move to the next CPU after each period of running. If the user modifies the migration thread's affinity, it will not change after that happens. The original code created the thread at the first instance it was called, but later was changed to destroy the thread after the tracer was finished, and would not be created until the next instance of the tracer was established. The code that initialized the affinity was only called on the initial instantiation of the tracer. After that, it was not initialized, and the previous affinity did not match the current newly created one, making it appear that the user modified the thread's affinity when it did not, and the thread failed to migrate again. Cc: stable@vger.kernel.org Fixes: 0330f7aa ("tracing: Have hwlat trace migrate across tracing_cpumask CPUs") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Johan Hovold authored
In case of a zero-length report, the gpio direction_input callback would currently return success instead of an errno. Fixes: 1ffb3c40 ("HID: cp2112: make transfer buffers DMA capable") Cc: stable <stable@vger.kernel.org> # 4.9 Signed-off-by:
Johan Hovold <johan@kernel.org> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
Johan Hovold authored
A recent commit fixing DMA-buffers on stack added a shared transfer buffer protected by a spinlock. This is broken as the USB HID request callbacks can sleep. Fix this up by replacing the spinlock with a mutex. Fixes: 1ffb3c40 ("HID: cp2112: make transfer buffers DMA capable") Cc: stable <stable@vger.kernel.org> # 4.9 Signed-off-by:
-
Christophe JAILLET authored
These tests are reversed. A warning should be displayed if an error is returned, not on success. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 30 Jan, 2017 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds authored
Pull sparc fixes from David Miller: "Several small bug fixes and tidies, along with a fix for non-resumable memory errors triggered by userspace" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc64: Handle PIO & MEM non-resumable errors. sparc64: Zero pages on allocation for mondo and error queues. sparc: Fixed typo in sstate.c. Replaced panicing with panicking sparc: use symbolic names for tsb indexing
-
David S. Miller authored
Liam R. Howlett says: ==================== sparc64: Recover from userspace non-resumable PIO & MEM errors A non-resumable error from userspace is able to cause a kernel panic or trap loop due to the setup and handling of the queued traps once in the kernel. This patch series addresses both of these issues. The queues are fixed by simply zeroing the memory before use. PIO errors from userspace will result in a SIGBUS being sent to the user process. The MEM errors form userspace will result in a SIGKILL and also cause the offending pages to be claimed so they are no longer used in future tasks. SIGKILL is used to ensure that the process does not try to coredump and result in an attempt to read the memory again from within kernel space. Although there is a HV call to scrub the memory (mem_scrub), there is no easy way to guarantee that the real memory address(es) are not used by other tasks. Clearing the error with mem_scrub would zero the memory and cause the other processes to proceed with bad data. The handling of other non-resumable errors remain unchanged and will cause a panic. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Liam R. Howlett authored
User processes trying to access an invalid memory address via PIO will receive a SIGBUS signal instead of causing a panic. Memory errors will receive a SIGKILL since a SIGBUS may result in a coredump which may attempt to repeat the faulting access. Signed-off-by:
Liam R. Howlett <Liam.Howlett@Oracle.com> Signed-off-by:
-
Liam R. Howlett authored
Error queues use a non-zero first word to detect if the queues are full. Using pages that have not been zeroed may result in false positive overflow events. These queues are set up once during boot so zeroing all mondo and error queue pages is safe. Note that the false positive overflow does not always occur because the page allocation for these queues is so early in the boot cycle that higher number CPUs get fresh pages. It is only when traps are serviced with lower number CPUs who were given already used pages that this issue is exposed. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linuxLinus Torvalds authored
Pull RTC fix from Alexandre Belloni: "A single fix for this cycle. It is worth taking it for 4.10 so that distributions will not have CONFIG_RTC_DRV_JZ4740 switching from m to y in their config. Summary: - Allow jz4740 to build as a module again by using kernel_halt()" * tag 'rtc-4.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: rtc: jz4740: make the driver buildable as a module again
-
Sebastian Andrzej Siewior authored
Since the change in commit: fd7a4bed ("sched, rt: Convert switched_{from, to}_rt() / prio_changed_rt() to balance callbacks") ... we don't reschedule a task under certain circumstances: Lets say task-A, SCHED_OTHER, is running on CPU0 (and it may run only on CPU0) and holds a PI lock. This task is removed from the CPU because it used up its time slice and another SCHED_OTHER task is running. Task-B on CPU1 runs at RT priority and asks for the lock owned by task-A. This results in a priority boost for task-A. Task-B goes to sleep until the lock has been made available. Task-A is already runnable (but not active), so it receives no wake up. The reality now is that task-A gets on the CPU once the scheduler decides to remove the current task despite the fact that a high priority task is enqueued and waiting. This may take a long time. The desired behaviour is that CPU0 immediately reschedules after the priority boost which made task-A the task with the lowest priority. Suggested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
