Age | Commit message (Collapse) | Author | Files | Lines |
|
* clocksource: sh_cmt: Add clk_prepare/unprepare support
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
Prepare the clock at probe time, as there is no other appropriate place
in the driver where we're allowed to sleep.
Cc: Daniel Lezcano <[email protected]>
Cc: [email protected]
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Simon Horman <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
bcm_timer_ids is no longer used after converting to CLOCKSOURCE_OF_DECLARE.
Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
This patch removes the use of the IRQF_DISABLED flag.
It's a NOOP since 2.6.35 and it will be removed one day.
[dlezcano] : slightly changed the changelog
Signed-off-by: Michael Opdenacker <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
This patch removes the use of the IRQF_DISABLED flag.
It's a NOOP since 2.6.35 and it will be removed one day.
[dlezcano] : slightly changed the changelog
Signed-off-by: Michael Opdenacker <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
This patch removes the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
[dlezcano] : slightly changed the changelog
Signed-off-by: Michael Opdenacker <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <[email protected]>
Acked-by: Simon Horman <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <[email protected]>
Acked-by: Simon Horman <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The current code sets the timer divider bits always. However, when
the 25 MHz timer is enabled, this is not needed and has no effect.
As this causes some confusion, rework the code so the divider is
set only when needed, i.e. when the 25 MHz timer is not in use.
Acked-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Ezequiel Garcia <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
Many platforms rely on clocksource_of_init() being implicitly
called for registering clock sources and will get zero warnings
if no working clock source is available. Let's print a critical
error message if no clock source is found.
Acked-by: Lee Jones <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.
Cc: Sebastian Hesselbarth <[email protected]>
Tested-by: Sebastian Hesselbarth <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface. While we're here, mark the sched_clock function as
notrace to prevent ftrace recursion crashes.
Cc: Maxime Ripard <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.
Cc: Soren Brinkmann <[email protected]>
Cc: Michal Simek <[email protected]>
Tested-by: Soren Brinkmann <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface. While we're here increase the number of bits that
sched_clock can handle to 64 to make full use of the counter.
Cc: Stuart Menefy <[email protected]>
Cc: Srinivas Kandagatla <[email protected]>
Acked-by: Srinivas Kandagatla <[email protected]>
Acked-by: Stuart Menefy <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The Allwinner A20 has support for four high speed timers. Apart for the
number of timers (4 vs 2), it's basically the same logic than the high
speed timers found in the sun5i chips.
Now that we have a driver to support it, we can enable them in the
device tree.
[dlezcano] : Fixed conflict with 428abbb8 "Enable the I2C controllers"
Signed-off-by: Maxime Ripard <[email protected]>
Tested-by: Emilio López <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The Allwinner A13 has support for two high speed timers. Now that we
have a driver to support it, we can enable them in the device tree.
Signed-off-by: Maxime Ripard <[email protected]>
Tested-by: Emilio López <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The Allwinner A10s has support for two high speed timers. Now that we
have a driver to support it, we can enable them in the device tree.
Signed-off-by: Maxime Ripard <[email protected]>
Tested-by: Emilio López <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
Most of the Allwinner SoCs (at this time, all but the A10) also have a
High Speed timers that are not using the 24MHz oscillator as a source
but rather the AHB clock running much faster.
The IP is slightly different between the A10s/A13 and the one used in
the A20/A31, since the latter have 4 timers available, while the former
have only 2 of them.
[dlezcano] : Fixed conflict with b788beda "Order Kconfig options
alphabetically"
Signed-off-by: Maxime Ripard <[email protected]>
Tested-by: Emilio López <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
We want to keep this driver as the default provider of the clock events
and source, yet some other driver might fit in the "desired" category of
ratings. Hence, we need to increase a bit the rating so that we can have
more flexibility in the ratings we choose.
Signed-off-by: Maxime Ripard <[email protected]>
Tested-by: Emilio López <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
|
|
The interrupt for the timer is a shared processor interrupt, so any CPU
found in the system can handle it. Switch to our cpumask to
cpu_possible_mask instead of cpumask_of(0).
Signed-off-by: Maxime Ripard <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
|
|
The clock event structure irq field was not filled previously to the
interrupt we're using.
This was resulting in the timer not being used at all when using a
configuration with SMP enabled on a system with several CPUs, and with
the cpumask set to the cpu_possible_mask.
Signed-off-by: Maxime Ripard <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks into timers/core
Pull posix cpu timer changes for v3.14 from Frederic Weisbecker:
* Remove dying thread/process timers caching that was complicating the code
for no significant win.
* Remove early task reference release on dying timer sample read. Again it was
not worth the code complication. The other timer's resources aren't released
until timer_delete() is called anyway (or when the whole process dies).
* Remove leftover arguments in reaped target cleanup
* Consolidate some timer sampling code
* Remove use of tasklist lock
* Robustify sighand locking against exec and exit by using the safer
lock_task_sighand() API instead of sighand raw locking.
* Convert some unnecessary BUG_ON() to WARN_ON()
Signed-off-by: Ingo Molnar <[email protected]>
|
|
The posix cpu timers code makes a heavy use of BUG_ON()
but none of these concern fatal issues that require
to stop the machine. So let's just warn the user when
some internal state slips out of our hands.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
The remaining uses of tasklist_lock were mostly about synchronizing
against sighand modifications, getting coherent and safe group samples
and also thread/process wide timers list handling.
All of this is already safely synchronizable with the target's
sighand lock. Let's use it on these places instead.
Also update the comments about locking.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
Timer deletion doesn't need the tasklist lock.
We need to protect against:
* concurrent access to the lists p->cputime_expires and
p->sighand->cputime_expires
* task reaping that may also delete the timer list entry
* timer firing
We already hold the timer lock which protects us against concurrent
timer firing.
The rest only need the targets sighand to be locked.
So hold it and drop the use of tasklist_lock there.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
There is no need for the tasklist_lock just to take a process
wide clock sample.
All we need is to get a coherent sample that doesn't race with
exit() and exec():
* exit() may be concurrently reaping a task and flushing its time
* sighand is unstable under exit() and exec(), and the latter also
result in group leader that can change
To protect against these, locking the target's sighand is enough.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
Consolidate the clock sampling common code used for both local
and remote targets.
Note that this introduces a tiny user ABI change: if a
PID is passed to clock_gettime() along the clockid,
we used to forbid a process wide clock sample when that
PID doesn't belong to a group leader. Now after this patch
we allow process wide clock samples if that PID belongs to
the current task, even if the current task is not the
group leader.
But local process wide clock samples are allowed if PID == 0
(current task) even if the current task is not the group leader.
So in the end this should be no big deal as this actually harmonize
the behaviour when the remote sample is actually a local one.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
a0b2062b0904ef07944c4a6e4d0f88ee44f1e9f2
("posix_timers: fix racy timer delta caching on task exit") forgot
to remove the arguments used for timer caching.
Fix this leftover.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
Now that we've removed all the optimizations that could
result in NULL timer's targets, we can remove all the
associated special case handling.
Also add some warnings on NULL targets to spot any possible
leftover.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
When a timer's target is seen to be buried, for example on calls
to timer_gettime(), the posix cpu timers code behaves a bit
like a garbage collector and releases early the reference to the
task.
Then again, this optimization complicates the code for no much
value: it's up to the user to release the timer and its associated
ressources by calling timer_delete() after it buries the target
tasks.
Remove this to simplify the code.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
Now that we removed dead thread posix cpu timers caching,
lets remove the dead process wide version. This caching
is similar to the per thread version but it should be even
more rare:
* If the process id dead, we are not reading its timers
status from a thread belonging to its group since they
are all dead. So this caching only concern remote process
timers reads. Now posix cpu timers using itimers or timer_settime()
can't do remote process timers anyway so it's not even clear if there
is actually a user for this caching.
* Unlike per thread timers caching, this only applies to
zombies targets. Buried targets' process wide timers return
0 values. But then again, timer_gettime() can't read remote
process timers, so if the process is dead, there can't be
any reader left anyway.
Then again this caching seem to complicate the code for
corner cases that are probably not worth it. So lets get
rid of it.
Also remove the sample snapshot on dying process timer
that is now useless, as suggested by Kosaki.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
When a task is exiting or has exited, its posix cpu timers
don't tick anymore and won't elapse further. It's too late
for them to expire.
So any further call to timer_gettime() on these timers will
return the same remaining expiry time.
The current code optimize this by caching the remaining delta
and storing it where we use to save the absolute expiration time.
This way, the future calls to timer_gettime() won't need to
compute the difference between the absolute expiration time and
the current time anymore.
Now this optimization doesn't seem to bring much value. Computing
the timer remaining delta is not very costly. Fetching the timer
value OTOH can be costly in two ways:
* CPUCLOCK_SCHED read requires to lock the target's rq. But some
optimizations are on the way to make task_sched_runtime() not holding
the rq lock of a non-running target.
* CPUCLOCK_VIRT/CPUCLOCK_PROF read simply consist in fetching
current->utime/current->stime except when the system uses full
dynticks cputime accounting. The latter requires a per task lock
in order to correctly compute user and system time. But once the
target is dead, this lock shouldn't be contended anyway.
All in one this caching doesn't seem to be justified.
Given that it complicates the code significantly for
few wins, let's remove it on single thread timers.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Kosaki Motohiro <[email protected]>
Cc: Andrew Morton <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks into timers/core
Pull dynticks updates from Frederic Weisbecker:
* Fix a bug where posix cpu timers requeued due to interval got ignored on full
dynticks CPUs (not a regression though as it only impacts full dynticks and the
bug is there since we merged full dynticks).
* Optimizations and cleanups on the use of per CPU APIs to improve code readability,
performance and debuggability in the nohz subsystem;
* Optimize posix cpu timer by sparing stub workqueue queue with full dynticks off case
* Rename some functions to extend with *_this_cpu() suffix for clarity
* Refine the naming of some context tracking subsystem state accessors
* Trivial spelling fix by Paul Gortmaker
Signed-off-by: Ingo Molnar <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
Pull LED subsystem bugfix from Bryan Wu.
* 'leds-fixes-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
leds: pwm: Fix for deferred probe in DT booted mode
|
|
We need to make sure that the error code from devm_of_pwm_get() is the one
the module returns in case of failure.
Restructure the code to make this possible for DT booted case.
With this patch the driver can ask for deferred probing when the board is
booted with DT.
Fixes for example omap4-sdp board's keyboard backlight led.
Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Bryan Wu <[email protected]>
|
|
In commit 7314e613d5ff ("Fix a few incorrectly checked
[io_]remap_pfn_range() calls") the uio driver started more properly
checking the passed-in user mapping arguments against the size of the
actual uio driver data.
That in turn exposed that some driver authors apparently didn't realize
that mmap can only work on a page granularity, and had tried to use it
with smaller mappings, with the new size check catching that out.
So since it's not just the user mmap() arguments that can be confused,
make the uio mmap code also verify that the uio driver has the memory
allocated at page boundaries in order for mmap to work. If the device
memory isn't properly aligned, we return
[ENODEV]
The fildes argument refers to a file whose type is not supported by mmap().
as per the open group documentation on mmap.
Reported-by: Holger Brunck <[email protected]>
Acked-by: Greg KH <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
A posix CPU timer can be rearmed while it is firing or after it is
notified with a signal. This can happen for example with timers that
were set with a non zero interval in timer_settime().
This rearming can happen in two places:
1) On timer firing time, which happens on the target's tick. If the timer
can't trigger a signal because it is ignored, it reschedules itself
to honour the timer interval.
2) On signal handling from the timer's notification target. This one
can be a different task than the timer's target itself. Once the
signal is notified, the notification target rearms the timer, again
to honour the timer interval.
When a timer is rearmed, we need to notify the full dynticks CPUs
such that they restart their tick in case they are running tasks that
may have a share in elapsing this timer.
Now the 1st case above handles full dynticks CPUs with a call to
posix_cpu_timer_kick_nohz() from the posix cpu timer firing code. But
the second case ignores the fact that some CPUs may run non-idle tasks
with their tick off. As a result, when a timer is resheduled after its signal
notification, the full dynticks CPUs may completely ignore it and not
tick on the timer as expected
This patch fixes this bug by handling both cases in one. All we need
is to move the kick to the rearming common code in posix_cpu_timer_schedule().
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Olivier Langlois <[email protected]>
|
|
After a posix cpu timer is set, a workqueue is scheduled in order to
kick the full dynticks CPUs and let them restart their tick if
necessary in case the task they are running is concerned by the
new timer.
This kick is implemented by way of IPIs, which require interrupts
to be enabled, hence the need for a workqueue to raise them because
the posix cpu timer set path has interrupts disabled.
Now if there is no full dynticks CPU on the system, the workqueue is
still scheduled but it simply won't send any IPI and return immediately.
So lets spare that worqueue when it is not needed.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Steven Rostedt <[email protected]>
|
|
context_tracking_cpu_is_enabled()
We currently have a confusing couple of API naming with the existing
context_tracking_active() and context_tracking_is_enabled().
Lets keep the latter one, context_tracking_is_enabled(), for global
context tracking state check and use context_tracking_cpu_is_enabled()
for local state check.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Steven Rostedt <[email protected]>
|
|
Use a function with a meaningful name to check the global context
tracking state. static_key_false() is a bit confusing for reviewers.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Steven Rostedt <[email protected]>
|
|
Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Steven Rostedt <[email protected]>
|
|
A few functions use remote per CPU access APIs when they
deal with local values.
Just do the right conversion to improve performance, code
readability and debug checks.
While at it, lets extend some of these function names with *_this_cpu()
suffix in order to display their purpose more clearly.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Steven Rostedt <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Thomas Gleixner:
- Correction of fuzzy and fragile IRQ_RETVAL macro
- IRQ related resume fix affecting only XEN
- ARM/GIC fix for chained GIC controllers
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip: Gic: fix boot for chained gics
irq: Enable all irqs unconditionally in irq_resume
genirq: Correct fuzzy and fragile IRQ_RETVAL() definition
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Ingo Molnar:
"Various smaller fixlets, all over the place"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/doc: Fix generation of device-drivers
sched: Expose preempt_schedule_irq()
sched: Fix a trivial typo in comments
sched: Remove unused variable in 'struct sched_domain'
sched: Avoid NULL dereference on sd_busy
sched: Check sched_domain before computing group power
MAINTAINERS: Update file patterns in the lockdep and scheduler entries
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
"Misc kernel and tooling fixes"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tools lib traceevent: Fix conversion of pointer to integer of different size
perf/trace: Properly use u64 to hold event_id
perf: Remove fragile swevent hlist optimization
ftrace, perf: Avoid infinite event generation loop
tools lib traceevent: Fix use of multiple options in processing field
perf header: Fix possible memory leaks in process_group_desc()
perf header: Fix bogus group name
perf tools: Tag thread comm as overriden
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull Xen bug-fixes from Konrad Rzeszutek Wilk:
"Fixes to patches that went in this merge window along with a latent
bug:
- Fix lazy flushing in case m2p override fails.
- Fix module compile issues with ARM/Xen
- Add missing call to DMA map page for Xen SWIOTLB for ARM"
* tag 'stable/for-linus-3.13-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/gnttab: leave lazy MMU mode in the case of a m2p override failure
xen/arm: p2m_init and p2m_lock should be static
arm/xen: Export phys_to_mach to fix Xen module link errors
swiotlb-xen: add missing xen_dma_map_page call
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A smattering of driver specific fixes here, including a bunch for a
long standing common pattern in the error handling paths, and a fix
for an embarrassing thinko in the new devm master registration code"
* tag 'spi-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi/pxa2xx: Restore private register bits.
spi/qspi: Fix qspi remove path.
spi/qspi: cleanup pm_runtime error check.
spi/qspi: set correct platform drvdata in ti_qspi_probe()
spi/pxa2xx: add new ACPI IDs
spi: core: invert success test in devm_spi_register_master
spi: spi-mxs: fix reference leak to master in mxs_spi_remove()
spi: bcm63xx: fix reference leak to master in bcm63xx_spi_remove()
spi: txx9: fix reference leak to master in txx9spi_remove()
spi: mpc512x: fix reference leak to master in mpc512x_psc_spi_do_remove()
spi: rspi: use platform drvdata correctly in rspi_remove()
spi: bcm2835: fix reference leak to master in bcm2835_spi_remove()
|
|
Pull networking updates from David Miller:
"Here is a pile of bug fixes that accumulated while I was in Europe"
1) In fixing kernel leaks to userspace during copying of socket
addresses, we broke a case that used to work, namely the user
providing a buffer larger than the in-kernel generic socket address
structure. This broke Ruby amongst other things. Fix from Dan
Carpenter.
2) Fix regression added by byte queue limit support in 8139cp driver,
from Yang Yingliang.
3) The addition of MSG_SENDPAGE_NOTLAST buggered up a few sendpage
implementations, they should just treat it the same as MSG_MORE.
Fix from Richard Weinberger and Shawn Landden.
4) Handle icmpv4 errors received on ipv6 SIT tunnels correctly, from
Oussama Ghorbel. In particular we should send an ICMPv6 unreachable
in such situations.
5) Fix some regressions in the recent genetlink fixes, in particular
get the pmcraid driver to use the new safer interfaces correctly.
From Johannes Berg.
6) macvtap was converted to use a per-cpu set of statistics, but some
code was still bumping tx_dropped elsewhere. From Jason Wang.
7) Fix build failure of xen-netback due to missing include on some
architectures, from Andy Whitecroft.
8) macvtap double counts received packets in statistics, fix from Vlad
Yasevich.
9) Fix various cases of using *_STATS_BH() when *_STATS() is more
appropriate. From Eric Dumazet and Hannes Frederic Sowa.
10) Pktgen ipsec mode doesn't update the ipv4 header length and checksum
properly after encapsulation. Fix from Fan Du.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (61 commits)
net/mlx4_en: Remove selftest TX queues empty condition
{pktgen, xfrm} Update IPv4 header total len and checksum after tranformation
virtio_net: make all RX paths handle erors consistently
virtio_net: fix error handling for mergeable buffers
virtio_net: Fixed a trivial typo (fitler --> filter)
netem: fix gemodel loss generator
netem: fix loss 4 state model
netem: missing break in ge loss generator
net/hsr: Support iproute print_opt ('ip -details ...')
net/hsr: Very small fix of comment style.
MAINTAINERS: Added net/hsr/ maintainer
ipv6: fix possible seqlock deadlock in ip6_finish_output2
ixgbe: Make ixgbe_identify_qsfp_module_generic static
ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default
ixgbe: ixgbe_fwd_ring_down needs to be static
e1000: fix possible reset_task running after adapter down
e1000: fix lockdep warning in e1000_reset_task
e1000: prevent oops when adapter is being closed and reset simultaneously
igb: Fixed Wake On LAN support
inet: fix possible seqlock deadlocks
...
|
|
The pipe code was trying (and failing) to be very careful about freeing
the pipe info only after the last access, with a pattern like:
spin_lock(&inode->i_lock);
if (!--pipe->files) {
inode->i_pipe = NULL;
kill = 1;
}
spin_unlock(&inode->i_lock);
__pipe_unlock(pipe);
if (kill)
free_pipe_info(pipe);
where the final freeing is done last.
HOWEVER. The above is actually broken, because while the freeing is
done at the end, if we have two racing processes releasing the pipe
inode info, the one that *doesn't* free it will decrement the ->files
count, and unlock the inode i_lock, but then still use the
"pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".
This is *very* hard to trigger in practice, since the race window is
very small, and adding debug options seems to just hide it by slowing
things down.
Simon originally reported this way back in July as an Oops in
kmem_cache_allocate due to a single bit corruption (due to the final
"spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
allocation that had re-used the free'd pipe-info), it's taken this long
to figure out.
Since the 'pipe->files' accesses aren't even protected by the pipe lock
(we very much use the inode lock for that), the simple solution is to
just drop the pipe lock early. And since there were two users of this
pattern, create a helper function for it.
Introduced commit ba5bb147330a ("pipe: take allocation and freeing of
pipe_inode_info out of ->i_mutex").
Reported-by: Simon Kirby <[email protected]>
Reported-by: Ian Applegate <[email protected]>
Acked-by: Al Viro <[email protected]>
Cc: [email protected] # v3.10+
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Remove waiting for TX queues to become empty during selftest.
This check is not necessary for any purpose, and might put
the driver into an infinite loop.
Signed-off-by: Eugenia Emantayev <[email protected]>
Signed-off-by: Amir Vadai <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|