Re: [PATCH RFC] setns: return 0 directly if try to reassociate with current namespace
"Chen, Hanxiao" writes:
>> -Original Message-
>> From: Eric W. Biederman [mailto:ebied...@xmission.com]
>> Sent: Thursday, October 09, 2014 1:56 AM
>>
>> Serge Hallyn writes:
>>
>> > Quoting Chen Hanxiao (chenhanx...@cn.fujitsu.com):
>> >> We could use setns to join the current ns,
>> >> which did a lot of unnecessary work.
>> >> This patch will check this senario and
>> >> return 0 directly.
>> >>
>> >> Signed-off-by: Chen Hanxiao
>> >
>> > Plus it's just asking for trouble.
>> >
>> > I would ack this, except you need to fclose(file) on the
>> > return paths. So just set err = 0 and goto out.
>>
>> I completely disagree.
>>
>> Nacked-by: "Eric W. Biederman"
>>
>> This patch adds a new code path to test, and gets that new code path
>> wrong. So unless there is a performance advantage for some real world
>> case I don't see the point. Is there real software that is rejoining
>> the a current namespace.
>>
>> This patch changes the behavior of CLONE_NEWNS (which always does a
>> chdir and chroot) when you change into the current namespace.
>>
>> This patch changes the behavior of CLONE_NEWUSER which current errors
>> out.
>>
>
> As reentering the same namespace looks meaningless,
> and handling reentering same ns we behaved differently,
It is not meaningless in the case of CLONE_NEWNS. It is weird but not
meaningless. Further return -EINVAL won't make the weird semantics go
away it just makes them more expensive to take advantage of.
> How about just *reject* the behaviour of setns to current namespace?
Because we don't break userspace applications without a darn good reason.
> + switch (ops->type) {
> + case CLONE_NEWIPC:
> + if (ei->ns == tsk->nsproxy->ipc_ns) {
> +err = -EINVAL;
> + goto out;
> +}
> ...
>
> And things became easy, 6 simply cases could cover the whole scenario
> and will not bring troubles to users.
Since you are cavalierly suggesting changing the semantics presented to
user space I don't belive the assertion that it will not bring trouble
to users.
Maybe on a day when I am not up to my neck in weird breakage in the
mount namespace. Because people now care because unprivileged users can
use it we are starting to see bugs as old as 2.4 and they are a pain to
deal with.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/exynos: fix vblank handling during dpms off
On 10/02/2014 08:52 PM, Andrzej Hajda wrote:
Hi,
+CC possible victims
On 10/02/2014 12:52 PM, Inki Dae wrote:
On 2014년 10월 02일 17:58, Joonyoung Shim wrote:
Hi Andrzej,
On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
The patch disables vblanks during dpms off only if pagefilp has
not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_put.
It fixes issue with page_flip ioctl not being able to acquire vblank counter.
This problem isn't related with pageflip, it just causes from
7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
drm_vblank_get() after drm_vblank_off()).
We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
after the commit .
This patch should break also other drivers, it seems at least following
drms could be affected:
armada, sti, tegra.
Indeed we (tegra) have just been hit by this. The problem seems to come
from the fact that we have been using drm_vblank_pre_modeset,
drm_vblank_post_modeset and drm_vblank_off conjointly. All these
functions depend on the value of vblank->inmodeset, and 7ffd7a68511
increases the vblank reference counter only in drm_vblank_off, which can
result in the acquired reference never being released.
The following seems to fix this for Tegra, by stopping using
drm_vblank_pre/post_modeset and relying on drm_vblank_off/on instead:
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b08df07cad47..3955d81236d0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -739,7 +739,6 @@ static const struct drm_crtc_funcs tegra_crtc_funcs = {
static void tegra_crtc_disable(struct drm_crtc *crtc)
{
- struct tegra_dc *dc = to_tegra_dc(crtc);
struct drm_device *drm = crtc->dev;
struct drm_plane *plane;
@@ -755,7 +754,7 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
}
}
- drm_vblank_off(drm, dc->pipe);
+ drm_crtc_vblank_off(crtc);
}
static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -844,7 +843,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
u32 value;
int err;
- drm_vblank_pre_modeset(crtc->dev, dc->pipe);
+ drm_crtc_vblank_off(crtc);
err = tegra_crtc_setup_clk(crtc, mode);
if (err) {
@@ -946,7 +945,7 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
- drm_vblank_post_modeset(crtc->dev, dc->pipe);
+ drm_crtc_vblank_on(crtc);
}
static void tegra_crtc_load_lut(struct drm_crtc *crtc)
Thierry, does this look ok to you?
But there might be another issue, which is that calls to
drm_vblank_get() will return -EINVAL if invoked between drm_blank_off
and drm_blank_on. Is this really the desired behavior? Can it at least
happen? If so, how are drivers supposed to react to this situation?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched/fair: Care divide error in update_task_scan_period()
(2014/10/08 20:51), Wanpeng Li wrote:
>
> 于 10/8/14, 2:43 PM, Yasuaki Ishimatsu 写道:
>> While offling node by hot removing memory, the following divide error
>> occurs:
>>
>>divide error: [#1] SMP
>>[...]
>>Call Trace:
>> [...] handle_mm_fault
>> [...] ? try_to_wake_up
>> [...] ? wake_up_state
>> [...] __do_page_fault
>> [...] ? do_futex
>> [...] ? put_prev_entity
>> [...] ? __switch_to
>> [...] do_page_fault
>> [...] page_fault
>>[...]
>>RIP [] task_numa_fault
>> RSP
>>
>> The issue occurs as follows:
>>1. When page fault occurs and page is allocated from node 1,
>> task_struct->numa_faults_buffer_memory[] of node 1 is
>> incremented and p->numa_faults_locality[] is also incremented
>> as follows:
>>
>> o numa_faults_buffer_memory[] o numa_faults_locality[]
>>NR_NUMA_HINT_FAULT_TYPES
>> | 0 | 1 |
>> -- --
>>node 0 | 0 | 0 | remote | 0 |
>>node 1 | 0 | 1 | locale | 1 |
>> -- --
>>
>>2. node 1 is offlined by hot removing memory.
>>
>>3. When page fault occurs, fault_types[] is calculated by using
>> p->numa_faults_buffer_memory[] of all online nodes in
>> task_numa_placement(). But node 1 was offline by step 2. So
>> the fault_types[] is calculated by using only
>> p->numa_faults_buffer_memory[] of node 0. So both of fault_types[]
>> are set to 0.
>>
>>4. The values(0) of fault_types[] pass to update_task_scan_period().
>>
>>5. numa_faults_locality[1] is set to 1. So the following division is
>> calculated.
>>
>> static void update_task_scan_period(struct task_struct *p,
>> unsigned long shared, unsigned long
>> private){
>> ...
>> ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS, (private
>> + shared));
>> }
>>
>>6. But both of private and shared are set to 0. So divide error
>> occurs here.
>>
>>The divide error is rare case because the trigger is node offline.
>>By this patch, when both of private and shared are set to 0, diff
>>is just set to 0, not calculating the division.
>>
>> Signed-off-by: Yasuaki Ishimatsu
>> ---
>> kernel/sched/fair.c | 30 +++---
>> 1 file changed, 19 insertions(+), 11 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index bfa3c86..fb7dc3f 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -1496,18 +1496,26 @@ static void update_task_scan_period(struct
>> task_struct *p,
>> slot = 1;
>> diff = slot * period_slot;
>> } else {
>> -diff = -(NUMA_PERIOD_THRESHOLD - ratio) * period_slot;
>> +if (unlikely((private + shared) == 0))
>> +/*
>> + * This is a rare case. The trigger is node offline.
>> + */
>> +diff = 0;
>> +else {
>> +diff = -(NUMA_PERIOD_THRESHOLD - ratio) * period_slot;
>>
>> -/*
>> - * Scale scan rate increases based on sharing. There is an
>> - * inverse relationship between the degree of sharing and
>> - * the adjustment made to the scanning period. Broadly
>> - * speaking the intent is that there is little point
>> - * scanning faster if shared accesses dominate as it may
>> - * simply bounce migrations uselessly
>> - */
>> -ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS, (private +
>> shared));
>> -diff = (diff * ratio) / NUMA_PERIOD_SLOTS;
>> +/*
>> + * Scale scan rate increases based on sharing. There is
>> + * an inverse relationship between the degree of sharing
>> + * and the adjustment made to the scanning period.
>> + * Broadly speaking the intent is that there is little
>> + * point scanning faster if shared accesses dominate as
>> + * it may simply bounce migrations uselessly
>> + */
>> +ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS,
>> +(private + shared));
>> +diff = (diff * ratio) / NUMA_PERIOD_SLOTS;
>> +}
>> }
>
> How about just
>
> ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS, (private + shared + 1));
Thank you for providing sample code. Rik also provided other idea.
So I am confirming which is better idea.
Thanks,
Yasuaki Ishimatsu
>
>
> Regards,
> Wanpeng Li
>
>> p->numa_scan_period = clamp(p->numa_scan_period +
Re: [PATCH 0/2] net: fs_enet: Remove non NAPI RX and add NAPI for TX
Le 08/10/2014 22:03, David Miller a écrit : From: Christophe Leroy Date: Tue, 7 Oct 2014 15:04:53 +0200 (CEST) When using a MPC8xx as a router, 'perf' shows a significant time spent in fs_enet_interrupt() and fs_enet_start_xmit(). 'perf annotate' shows that the time spent in fs_enet_start_xmit is indeed spent between spin_unlock_irqrestore() and the following instruction, hence in interrupt handling. This is due to the TX complete interrupt that fires after each transmitted packet. This patchset first remove all non NAPI handling as NAPI has become the only mode for RX, then adds NAPI for handling TX complete. This improves NAT TCP throughput by 21% on MPC885 with FEC. Tested on MPC885 with FEC. [PATCH 1/2] net: fs_enet: Remove non NAPI RX [PATCH 2/2] net: fs_enet: Add NAPI TX Signed-off-by: Christophe Leroy Series applied, thanks. Any particular reason you didn't just put the TX reclaim calls into the existing NAPI handler? Not really. I used the gianfar.c driver as a model. That's what other drivers do, because TX reclaim can make SKBs available for RX packet receive on the local cpu. So generally you have one NAPI context that first does any pending TX reclaim, then polls the RX ring for new packets. Is that a better approach ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched/fair: Care divide error in update_task_scan_period()
(2014/10/09 1:54), Peter Zijlstra wrote: On Wed, Oct 08, 2014 at 12:42:24PM -0400, Rik van Riel wrote: On 10/08/2014 02:43 AM, Yasuaki Ishimatsu wrote: The divide error is rare case because the trigger is node offline. By this patch, when both of private and shared are set to 0, diff is just set to 0, not calculating the division. How about a simple if (private + shared) == 0) return; higher up in the function, to avoid adding an extra layer of indentation and confusion to the main part of the function? At which point we'll have 3 different return semantics. Should we not clear numa_faults_localityp[], even in this case? I'm not familiar with Numa balancing feature. So I want to know it too. If it's not necessary to clear numa_faults_locality[], I'll apply the idea. Thanks, Yasuaki Ishimatsu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpusets: Make cpus_allowed and mems_allowed masks hotplug invariant
Hi Raghu, On 10/08/2014 08:24 PM, Raghavendra KT wrote: > On Wed, Oct 8, 2014 at 12:37 PM, Preeti U Murthy > wrote: >> There are two masks associated with cpusets. The cpus/mems_allowed >> and effective_cpus/mems. On the legacy hierarchy both these masks >> are consistent with each other. This is the intersection of their >> value and the currently active cpus. This means that we destroy the >> original values set in these masks on each cpu/mem hot unplug operation. >> As a consequence when we hot plug back the cpus/mems, the tasks >> no longer run on them and performance degrades, inspite of having >> resources to run on. >> >> This effect is not seen in the default hierarchy since the >> allowed and effective masks are distinctly maintained. >> allowed masks are never touched once configured and effective masks >> alone are hotplug variant. >> >> This patch replicates the above design even for the legacy hierarchy, >> so that: >> >> 1. Tasks always run on the cpus/memory nodes that they are allowed to run on >> as long as they are online. The allowed masks are hotplug invariant. >> >> 2. When all cpus/memory nodes in a cpuset are hot unplugged out, the tasks >> are moved to their nearest ancestor which has resources to run on. > > Hi Preeti, > > I may be missing some thing here could you please explain when do we get > tasks move out of a cpuset after this patch and why it is even necessary? On the legacy hierarchy the tasks are moved to their parents cpusets if the cpuset to which they were initially bound becomes empty. What the patch does has nothing to do with moving tasks when the cpuset to which they are bound becomes empty.The point 2 above was mentioned to merely state that this part of the behavior is not really changed with the patch. The patch merely ensures that the original cpuset configuration is not messed with during hotplug operations. > > IIUC, with default hierarchy we should never hit a case where we have empty > effective cpuset and hence remove_tasks_in_empty_cpuset should never happen. > no? > > if my assumption is correct then we should remove > remove_tasks_in_empty_cpuset itself... remove_tasks_in_empty_cpuset() is called on the legacy hierarchy when the cpuset becomes empty, hence we require it. But you are right its not called on the default hierarchy. Regards Preeti U Murthy > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver/base/node: remove unnecessary kfree of node struct from unregister_one_node
(2014/10/09 13:10), Xishi Qiu wrote:
> On 2014/10/3 18:06, Yasuaki Ishimatsu wrote:
>
>> Commit 92d585ef067d ("numa: fix NULL pointer access and memory
>> leak in unregister_one_node()") added kfree() of node struct in
>> unregister_one_node(). But node struct is freed by node_device_release()
>> which is called in unregister_node(). So by adding the kfree(),
>
> Hi,
>
> Is this path?
> unregister_node()
>device_unregister()
> device_del()
>bus_remove_device()
> device_release_driver()
>__device_release_driver()
> devres_release_all()
>release_nodes()
> dr->node.release(dev, dr->data);
>then which function is be called?
node_device_release is called as follows:
unregister_one_node()
-> unregister_node()
-> device_unregister()
-> put_device()
-> kobject_put()
-> kref_put()
-> kref_sub()
-> kobject_release()
-> kobject_cleanup()
-> device_release()
-> node_device_release()
Thanks,
Yasuaki Ishimatsu
>
> Thanks,
> Xishi Qiu
>
>> node struct is freed two times.
>>
>> While hot removing memory, the commit leads the following BUG_ON():
>>
>>kernel BUG at mm/slub.c:3346!
>>invalid opcode: [#1] SMP
>>[...]
>>Call Trace:
>> [...] unregister_one_node
>> [...] try_offline_node
>> [...] remove_memory
>> [...] acpi_memory_device_remove
>> [...] acpi_bus_trim
>> [...] acpi_bus_trim
>> [...] acpi_device_hotplug
>> [...] acpi_hotplug_work_fn
>> [...] process_one_work
>> [...] worker_thread
>> [...] ? rescuer_thread
>> [...] kthread
>> [...] ? kthread_create_on_node
>> [...] ret_from_fork
>> [...] ? kthread_create_on_node
>>
>> This patch removes unnecessary kfree() from unregister_one_node().
>>
>> Signed-off-by: Yasuaki Ishimatsu
>> Cc: Xishi Qiu
>> Cc: Greg Kroah-Hartman
>> Cc: Andrew Morton
>> Cc: sta...@vger.kernel.org # v3.16+
>> Fixes: 92d585ef067d "numa: fix NULL pointer access and memory leak in
>> unregister_one_node()"
>> ---
>> drivers/base/node.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/base/node.c b/drivers/base/node.c
>> index c6d3ae0..d51c49c 100644
>> --- a/drivers/base/node.c
>> +++ b/drivers/base/node.c
>> @@ -603,7 +603,6 @@ void unregister_one_node(int nid)
>> return;
>>
>> unregister_node(node_devices[nid]);
>> -kfree(node_devices[nid]);
>> node_devices[nid] = NULL;
>> }
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] powerpc, ptrace: Enable support for transactional memory register sets
On 08/28/2014 03:05 AM, Sukadev Bhattiprolu wrote:
> Anshuman Khandual [khand...@linux.vnet.ibm.com] wrote:
> | This patch enables get and set of transactional memory related register
> | sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
> | four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
> | REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
> | ELF core note types added previously in this regard.
> |
> | (1) NT_PPC_TM_SPR
> | (2) NT_PPC_TM_CGPR
> | (3) NT_PPC_TM_CFPR
> | (4) NT_PPC_TM_CVMX
> |
> | Signed-off-by: Anshuman Khandual
> | ---
> | arch/powerpc/include/asm/switch_to.h | 8 +
> | arch/powerpc/kernel/process.c| 24 ++
> | arch/powerpc/kernel/ptrace.c | 792
> +--
> | 3 files changed, 795 insertions(+), 29 deletions(-)
> |
> | diff --git a/arch/powerpc/include/asm/switch_to.h
> b/arch/powerpc/include/asm/switch_to.h
> | index 0e83e7d..2737f46 100644
> | --- a/arch/powerpc/include/asm/switch_to.h
> | +++ b/arch/powerpc/include/asm/switch_to.h
> | @@ -80,6 +80,14 @@ static inline void flush_spe_to_thread(struct
> task_struct *t)
> | }
> | #endif
> |
> | +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> | +extern void flush_tmregs_to_thread(struct task_struct *);
> | +#else
> | +static inline void flush_tmregs_to_thread(struct task_struct *t)
> | +{
> | +}
> | +#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
> | +
> | static inline void clear_task_ebb(struct task_struct *t)
> | {
> | #ifdef CONFIG_PPC_BOOK3S_64
> | diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> | index 31d0215..e247898 100644
> | --- a/arch/powerpc/kernel/process.c
> | +++ b/arch/powerpc/kernel/process.c
> | @@ -695,6 +695,30 @@ static inline void __switch_to_tm(struct task_struct
> *prev)
> | }
> | }
> |
> | +void flush_tmregs_to_thread(struct task_struct *tsk)
> | +{
> | + /*
> | +* If task is not current, it should have been flushed
> | +* already to it's thread_struct during __switch_to().
> | +*/
> | + if (tsk != current)
> | + return;
> | +
> | + preempt_disable();
> | + if (tsk->thread.regs) {
> | + /*
> | +* If we are still current, the TM state need to
> | +* be flushed to thread_struct as it will be still
> | +* present in the current cpu.
> | +*/
> | + if (MSR_TM_ACTIVE(tsk->thread.regs->msr)) {
> | + __switch_to_tm(tsk);
> | + tm_recheckpoint_new_task(tsk);
> | + }
> | + }
> | + preempt_enable();
> | +}
> | +
> | /*
> | * This is called if we are on the way out to userspace and the
> | * TIF_RESTORE_TM flag is set. It checks if we need to reload
> | diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> | index 2e3d2bf..17642ef 100644
> | --- a/arch/powerpc/kernel/ptrace.c
> | +++ b/arch/powerpc/kernel/ptrace.c
> | @@ -357,6 +357,17 @@ static int gpr_set(struct task_struct *target, const
> struct user_regset *regset,
> | return ret;
> | }
> |
> | +/*
> | + * When any transaction is active, "thread_struct->transact_fp" holds
> | + * the current running value of all FPR registers and "thread_struct->
> | + * fp_state" holds the last checkpointed FPR registers state for the
> | + * current transaction.
> | + *
> | + * struct data {
> | + * u64 fpr[32];
> | + * u64 fpscr;
> | + * };
> | + */
>
> Maybe a reference to 'struct thread_fp_state' in the comments will help ?
Okay, will try to add.
>
>
> | static int fpr_get(struct task_struct *target, const struct user_regset
> *regset,
> |unsigned int pos, unsigned int count,
> |void *kbuf, void __user *ubuf)
> | @@ -365,21 +376,41 @@ static int fpr_get(struct task_struct *target, const
> struct user_regset *regset,
> | u64 buf[33];
> | int i;
> | #endif
> | - flush_fp_to_thread(target);
> | + if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
> | + flush_fp_to_thread(target);
> | + flush_altivec_to_thread(target);
> | + flush_tmregs_to_thread(target);
> | + } else {
> | + flush_fp_to_thread(target);
> | + }
>
> flush_fp_to_thread(target) is uncondtional - so could be outside
> the if and else blocks ?
yes
>
> |
> | #ifdef CONFIG_VSX
> | /* copy to local buffer then write that out */
> | - for (i = 0; i < 32 ; i++)
> | - buf[i] = target->thread.TS_FPR(i);
> | - buf[32] = target->thread.fp_state.fpscr;
> | + if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
> | + for (i = 0; i < 32 ; i++)
> | + buf[i] = target->thread.TS_TRANS_FPR(i);
> | + buf[32] = target->thread.transact_fp.fpscr;
> | + } else {
> | + for (i = 0; i < 32 ; i++)
> | + buf[i] = target->thread.TS_FPR(i);
> | + buf[32] = target->thread.fp_state.fpscr;
Re: Please backport commit 3812c8c8f39 to stable
On Tue, Oct 7, 2014 at 5:33 AM, Michal Hocko wrote: > On Fri 03-10-14 11:16:31, Cong Wang wrote: >> I am sorry to confuse you that it is my the above test case which caused >> this bug. No, we saw this bug in *production* in our data center, it happened >> on 30+ machines!! :) The above insane test case is ONLY to draw your >> attention on how serious the bug is, nothing else. > > Sure then the issue definitely needs to be fixed. > > You have written in other email, that you have a backport. I will help > you with the review if you post it publicly. > Cool! Note that I only have time to backport them to 3.10 and test on it. Currently there are 8 patches backported to fix this bug, I am still checking if we need more. I will post them soon and Cc you of course. Thanks for looking at it! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the percpu tree with the tip tree
Hi all,
Today's linux-next merge of the percpu tree got a conflict in
kernel/irq_work.c between commit 76a33061b932 ("irq_work: Force raised
irq work to run on irq work interrupt") from the tip tree and commit
22127e93c587 ("time: Replace __get_cpu_var uses") from the percpu tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/irq_work.c
index 385b85aded19,345d19edcdae..
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@@ -113,12 -113,10 +113,12 @@@ bool irq_work_needs_cpu(void
{
struct llist_head *raised, *lazy;
- raised = &__get_cpu_var(raised_list);
- lazy = &__get_cpu_var(lazy_list);
+ raised = this_cpu_ptr(_list);
+ lazy = this_cpu_ptr(_list);
- if (llist_empty(raised) && llist_empty(lazy))
- return false;
+
+ if (llist_empty(raised) || arch_irq_work_has_interrupt())
+ if (llist_empty(lazy))
+ return false;
/* All work should have been flushed before going offline */
WARN_ON_ONCE(cpu_is_offline(smp_processor_id()));
signature.asc
Description: PGP signature
[PATCH V2] staging: dgap: introduce dgap_stop()
The dgap_init_module() need to unwind for cleanup variables properly.
Because dgap_init_module() calls dgap_cleanup_module() for freeing
variables but this function is possible to free variables
which are not allocated.
Signed-off-by: Daeseok Youn
---
V2: change ulong which is non-standard to "unsigned long".
drivers/staging/dgap/dgap.c | 27 ++-
1 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 7c79fe6..290ca3b 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -71,6 +71,7 @@ MODULE_DESCRIPTION("Driver for the Digi International EPCA
PCI based product lin
MODULE_SUPPORTED_DEVICE("dgap");
static int dgap_start(void);
+static void dgap_stop(void);
static void dgap_init_globals(void);
static struct board_t *dgap_found_board(struct pci_dev *pdev, int id,
int boardnum);
@@ -479,19 +480,20 @@ static int dgap_init_module(void)
rc = pci_register_driver(_driver);
if (rc)
- goto err_cleanup;
+ goto err_stop;
rc = dgap_create_driver_sysfiles(_driver);
if (rc)
- goto err_cleanup;
+ goto err_unregister;
dgap_driver_state = DRIVER_READY;
return 0;
-err_cleanup:
-
- dgap_cleanup_module();
+err_unregister:
+ pci_unregister_driver(_driver);
+err_stop:
+ dgap_stop();
return rc;
}
@@ -561,6 +563,21 @@ failed_class:
return rc;
}
+static void dgap_stop(void)
+{
+ unsigned long lock_flags;
+
+ spin_lock_irqsave(_poll_lock, lock_flags);
+ dgap_poll_stop = 1;
+ spin_unlock_irqrestore(_poll_lock, lock_flags);
+
+ del_timer_sync(_poll_timer);
+
+ device_destroy(dgap_class, MKDEV(DIGI_DGAP_MAJOR, 0));
+ class_destroy(dgap_class);
+ unregister_chrdev(DIGI_DGAP_MAJOR, "dgap");
+}
+
static int dgap_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
int rc;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] OOM vs. freezer interaction fixes
Hi, Michal On Wed, Oct 8, 2014 at 7:07 AM, Michal Hocko wrote: > Hi Andrew, Rafael, > > this has been originally discussed here [1] but didn't lead anywhere AFAICS > so I would like to resurrect them. > Thanks a lot for taking them for me! I was busy with some networking stuffs and also actually waiting for Rafael's response to your patch. > The first and third patch are regression fixes and they are a stable > material IMO. The second patch is a simple cleanup. > > The 1st patch is fixing a regression introduced in 3.3 since when OOM > killer is not able to kill any frozen task and live lock as a result. > The fix gets us back to the 3.2. As it turned out during the discussion [2] > this was still not 100% sufficient and that's why we need the 3rd patch. > > I was thinking about the proper 1st vs. 3rd patch ordering because > the 1st patch basically opens a race window fixed by the later patch. > Original patch from Cong Wang has covered this by cgroup_freezing(current) > check in should_thaw_current(). But this approach still suffers from OOM > vs. PM freezer interaction (OOM killer would still live lock waiting for a > PM frozen task this time). It should be very rare OOM happens during PM frozen. > > So I think the most straight forward way is to address only OOM vs. > frozen task interaction in the first patch, mark it for stable 3.3+ and > leave the race to a separate follow up patch which is applicable to > stable 3.2+ (before a3201227f803 made it inefficient). > > Switching 1st and 3rd patches would make some sense as well but then > it might end up even more confusing because we would be fixing a > non-existent issue in upstream first... > Agreed. Up to you, I have no strong opinions here. :) Again, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/6] arm64: ptrace: allow tracer to skip a system call
On 10/08/2014 11:23 PM, Will Deacon wrote:
On Thu, Oct 02, 2014 at 10:46:12AM +0100, AKASHI Takahiro wrote:
If tracer specifies -1 as a syscall number, this traced system call should
be skipped with a value in x0 used as a return value.
This patch implements this semantics, but there is one restriction here:
when syscall(-1) is issued by user, tracer cannot skip this system call
and modify a return value at syscall entry.
In order to ease this flavor, we need to take whatever value x0 has as
a return value, but this might result in a bogus value being returned,
especially when tracer doesn't do anything against this syscall.
So we always return ENOSYS instead, while we still have another chance to
change a return value at syscall exit.
Please also note:
* syscall entry tracing and syscall exit tracing (ftrace tracepoint and
audit) are always executed, if enabled, even when skipping a system call
(that is, -1).
In this way, we can avoid a potential bug where audit_syscall_entry()
might be called without audit_syscall_exit() at the previous system call
being called, that would cause OOPs in audit_syscall_entry().
* syscallno may also be set to -1 if a fatal signal (SIGKILL) is detected
in tracehook_report_syscall_entry(), but since a value set to x0 (ENOSYS)
is not used in this case, we may neglect the case.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/asm/ptrace.h |8
arch/arm64/kernel/entry.S |4
arch/arm64/kernel/ptrace.c | 23 ++-
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 41ed9e1..736ebc3 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -65,6 +65,14 @@
#define COMPAT_PT_TEXT_ADDR 0x1
#define COMPAT_PT_DATA_ADDR 0x10004
#define COMPAT_PT_TEXT_END_ADDR 0x10008
+
+/*
+ * System call will be skipped if a syscall number is changed to -1
+ * with ptrace(PTRACE_SET_SYSCALL).
+ * Upper 32-bit should be ignored for safe check.
+ */
+#define IS_SKIP_SYSCALL(no)((int)(no & 0x) == -1)
I don't think this macro is very useful, especially considering that we
already use ~0UL explicitly in other places. Just move the comment into
syscall_trace_enter and be done with it. I also don't think you need the
mask (the cast is enough).
I remember it was necessary for compat PTRACE_SET_SYSCALL, but
will double-check it anyway.
+
#ifndef __ASSEMBLY__
/* sizeof(struct user) for AArch32 */
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index f0b5e51..b53a1c5 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -671,6 +672,8 @@ ENDPROC(el0_svc)
__sys_trace:
mov x0, sp
bl syscall_trace_enter
+ cmp w0, #-1 // skip the syscall?
+ b.eq__sys_trace_return_skipped
adr lr, __sys_trace_return // return address
uxtwscno, w0// syscall number (possibly new)
mov x1, sp // pointer to regs
@@ -685,6 +688,7 @@ __sys_trace:
__sys_trace_return:
str x0, [sp]// save returned x0
+__sys_trace_return_skipped:
mov x0, sp
bl syscall_trace_exit
b ret_to_user
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 2842f9f..6b11c6a 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1126,6 +1126,8 @@ static void tracehook_report_syscall(struct pt_regs *regs,
asmlinkage int syscall_trace_enter(struct pt_regs *regs)
{
+ unsigned int orig_syscallno = regs->syscallno;
+
if (test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
@@ -1133,7 +1135,26 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
trace_sys_enter(regs, regs->syscallno);
audit_syscall_entry(syscall_get_arch(), regs->syscallno,
- regs->orig_x0, regs->regs[1], regs->regs[2], regs->regs[3]);
+ regs->orig_x0, regs->regs[1],
+ regs->regs[2], regs->regs[3]);
+
+ if (IS_SKIP_SYSCALL(regs->syscallno) &&
+ IS_SKIP_SYSCALL(orig_syscallno)) {
+ /*
+* For compatibility, we handles user-issued syscall(-1).
Compatibility with what? arch/arm/?
with the case where a process is *not* traced (including audit).
+*
+* RESTRICTION: we can't modify a return value here in this
+* specific case. In order to ease this flavor, we have to
+* take whatever value x0 has as a return value, but this
+* might result in
RE: [PATCH RFC] setns: return 0 directly if try to reassociate with current namespace
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Thursday, October 09, 2014 1:56 AM
>
> Serge Hallyn writes:
>
> > Quoting Chen Hanxiao (chenhanx...@cn.fujitsu.com):
> >> We could use setns to join the current ns,
> >> which did a lot of unnecessary work.
> >> This patch will check this senario and
> >> return 0 directly.
> >>
> >> Signed-off-by: Chen Hanxiao
> >
> > Plus it's just asking for trouble.
> >
> > I would ack this, except you need to fclose(file) on the
> > return paths. So just set err = 0 and goto out.
>
> I completely disagree.
>
> Nacked-by: "Eric W. Biederman"
>
> This patch adds a new code path to test, and gets that new code path
> wrong. So unless there is a performance advantage for some real world
> case I don't see the point. Is there real software that is rejoining
> the a current namespace.
>
> This patch changes the behavior of CLONE_NEWNS (which always does a
> chdir and chroot) when you change into the current namespace.
>
> This patch changes the behavior of CLONE_NEWUSER which current errors
> out.
>
As reentering the same namespace looks meaningless,
and handling reentering same ns we behaved differently,
How about just *reject* the behaviour of setns to current namespace?
+ switch (ops->type) {
+ case CLONE_NEWIPC:
+ if (ei->ns == tsk->nsproxy->ipc_ns) {
+err = -EINVAL;
+ goto out;
+}
...
And things became easy, 6 simply cases could cover the whole scenario
and will not bring troubles to users.
Thanks,
- Chen
> This code adds a big switch statement to code that is otherwise table
> driven. With the result that two pieces of code must be looked at
> and modified whenever we want to tweak the behavior of setns for a
> namespace.
>
> So in general I think this piece of code is a maintenance disaster,
> with no apparent redeem virtues.
>
> Eric
Re: [PATCH] driver/base/node: remove unnecessary kfree of node struct from unregister_one_node
On 2014/10/3 18:06, Yasuaki Ishimatsu wrote:
> Commit 92d585ef067d ("numa: fix NULL pointer access and memory
> leak in unregister_one_node()") added kfree() of node struct in
> unregister_one_node(). But node struct is freed by node_device_release()
> which is called in unregister_node(). So by adding the kfree(),
Hi,
Is this path?
unregister_node()
device_unregister()
device_del()
bus_remove_device()
device_release_driver()
__device_release_driver()
devres_release_all()
release_nodes()
dr->node.release(dev, dr->data);
then which function is be called?
Thanks,
Xishi Qiu
> node struct is freed two times.
>
> While hot removing memory, the commit leads the following BUG_ON():
>
> kernel BUG at mm/slub.c:3346!
> invalid opcode: [#1] SMP
> [...]
> Call Trace:
>[...] unregister_one_node
>[...] try_offline_node
>[...] remove_memory
>[...] acpi_memory_device_remove
>[...] acpi_bus_trim
>[...] acpi_bus_trim
>[...] acpi_device_hotplug
>[...] acpi_hotplug_work_fn
>[...] process_one_work
>[...] worker_thread
>[...] ? rescuer_thread
>[...] kthread
>[...] ? kthread_create_on_node
>[...] ret_from_fork
>[...] ? kthread_create_on_node
>
> This patch removes unnecessary kfree() from unregister_one_node().
>
> Signed-off-by: Yasuaki Ishimatsu
> Cc: Xishi Qiu
> Cc: Greg Kroah-Hartman
> Cc: Andrew Morton
> Cc: sta...@vger.kernel.org # v3.16+
> Fixes: 92d585ef067d "numa: fix NULL pointer access and memory leak in
> unregister_one_node()"
> ---
> drivers/base/node.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index c6d3ae0..d51c49c 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -603,7 +603,6 @@ void unregister_one_node(int nid)
> return;
>
> unregister_node(node_devices[nid]);
> - kfree(node_devices[nid]);
> node_devices[nid] = NULL;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with the mips tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/arm64/include/asm/Kbuild between commit 2f06dbe4e4fc ("arm64: use
generic dma-contiguous.h") from the mips tree and commit c5c38ef3d703
("irq_work: Introduce arch_irq_work_has_interrupt()") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm64/include/asm/Kbuild
index 55c179b32dd9,c1968475cc4e..
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@@ -9,9 -9,8 +9,9 @@@ generic-y += current.
generic-y += delay.h
generic-y += div64.h
generic-y += dma.h
+generic-y += dma-contiguous.h
- generic-y += emergency-restart.h
generic-y += early_ioremap.h
+ generic-y += emergency-restart.h
generic-y += errno.h
generic-y += ftrace.h
generic-y += hash.h
signature.asc
Description: PGP signature
[PATCH] net: Missing @ before descriptions cause make xmldocs warning
This patch fix following warning. Warning(.//net/core/skbuff.c:4142): No description found for parameter 'header_len' Warning(.//net/core/skbuff.c:4142): No description found for parameter 'data_len' Warning(.//net/core/skbuff.c:4142): No description found for parameter 'max_page_order' Warning(.//net/core/skbuff.c:4142): No description found for parameter 'errcode' Warning(.//net/core/skbuff.c:4142): No description found for parameter 'gfp_mask' Acutually the descriptions exist, but missing "@" in front. This problem start to happen when following commit was merged into Linus's tree during 3.18-rc1 merge period. commit 2e4e44107176d552f8bb1bb76053e850e3809841 net: add alloc_skb_with_frags() helper Signed-off-by: Masanari Iida --- net/core/skbuff.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 7b3df0d..a30d750 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4126,11 +4126,11 @@ EXPORT_SYMBOL(skb_vlan_untag); /** * alloc_skb_with_frags - allocate skb with page frags * - * header_len: size of linear part - * data_len: needed length in frags - * max_page_order: max page order desired. - * errcode: pointer to error code if any - * gfp_mask: allocation mask + * @header_len: size of linear part + * @data_len: needed length in frags + * @max_page_order: max page order desired. + * @errcode: pointer to error code if any + * @gfp_mask: allocation mask * * This can be used to allocate a paged skb, given a maximal order for frags. */ -- 2.1.2.374.g63a4513 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hrtimer deadlock caused by nohz_full
On Thu, Oct 09, 2014 at 05:30:20AM +0200, Frederic Weisbecker wrote: > > Do I miss some other essential patch ? > > If you have used the diff in that URL then you've missed: > > x86: Tell irq work about self IPI support > > Without that the whole patchset has no effect. Ok. Thanks, I'll rerun with that. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: armv7: perf: fix armv7 ref-cycles error
On Thu, Oct 09, 2014 at 11:07:04AM +0800, zhangzhiqiang wrote: > On 2014/10/8 21:38, Will Deacon wrote: > > On Wed, Oct 08, 2014 at 02:31:47PM +0100, gre...@linuxfoundation.org wrote: > >> On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote: > >>> On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote: > hi all, > > > ref-cycles event is specially to Intel core, but can still used in arm > architecture > with the wrong return value with 3.10 stable. for instance: > > perf stat -e ref-cycles sleep 1 > > Performance counter stats for 'sleep 1': > > 0 ref-cycles > > 1.002381916 seconds time elapsed > > this patch fix the bug and make it return NOT SUPPORTED > distinctly. > > In upstream this bug has been fixed by other way(not primary for the > bug), which changes more than one file > and more than 1000 lines. the primary commit is > 6b7658ec8a100b608e59e3cde353434db51f5be0. > besides we can not simply cherry-pick. > >>> > >>> I thought I saw Greg pick this up the other day? > >> > >> Yes, it's in 3.16.4, did I do something wrong by accepting it? > > > > Nah, it's a trivial patch that I struggle to get excited about. I'm just not > > sure why it's being sent again, after you already accepted it. > > Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into 3.10 > or > do we have the plan? Does it apply to 3.10-stable? Did you test it there and see if it resolves your issue? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] allow cpufreq drivers to export flags
On 9 October 2014 05:31, Mike Turquette wrote: > Whether you merge the patches now or later is fine by me. I prefer to > get my patches out early and often so I can avoid any surprises later > on. If you have a fundamental objection to these patches then please let > me know. Otherwise it would be wonderful to have an Ack. Acked-by: Viresh Kumar But I would still ask you to get these merged with scheduler changes. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hrtimer deadlock caused by nohz_full
On Wed, Oct 08, 2014 at 10:02:40PM -0400, Dave Jones wrote: > On Tue, Oct 07, 2014 at 07:42:47PM +0200, Thomas Gleixner wrote: > > On Tue, 7 Oct 2014, Dave Jones wrote: > > > > > On Tue, Oct 07, 2014 at 05:30:27PM +0200, Frederic Weisbecker wrote: > > > > > > > > > Right, this patchset fixes it: "[PATCH 0/8] nohz: Fix nohz kick > irq work on tick v3" > > > > > > > > > > > > I was about to make the pull request, the branch is acked by > peterz. > > > > > > Would you like to pull it? It's all merge window material. > > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > > > > > nohz/fixes-v3 > > > > > > > > > > I'm now hitting this with such regularity that it's preventing me > from > > > > > tracking down other bugs. Can we get this merged soon please ? > > > > > > > > I asked Thomas to pull but he probably missed it. So I did a formal > pull request > > > > to Ingo a few days later but he told me that the pull request was > made too late > > > > as the merge window was too close. I told him it fixes annoying bugs > but that was on IRC > > > > so this probably got lost. > > > > Aarg. Lemme get this done. > > So, time for sad news. > This still doesn't solve the problem for me. > > Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 2 > CPU: 2 PID: 8193 Comm: kworker/u8:1 Not tainted 3.17.0+ #67 > Workqueue: netns cleanup_net > 2a473fb8 880244c06c00 9f81ea56 > 9fc63e00 880244c06c80 9f819003 0010 > 880244c06c90 880244c06c30 2a473fb8 > Call Trace: >[] dump_stack+0x4e/0x7a > [] panic+0xd7/0x20a > [] ? restart_watchdog_hrtimer+0x50/0x50 > [] watchdog_overflow_callback+0x118/0x120 > [] __perf_event_overflow+0xac/0x350 > [] ? x86_perf_event_set_period+0xde/0x150 > [] perf_event_overflow+0x14/0x20 > [] intel_pmu_handle_irq+0x206/0x410 > [] perf_event_nmi_handler+0x2b/0x50 > [] nmi_handle+0xd2/0x3b0 > [] ? nmi_handle+0x5/0x3b0 > [] ? get_lock_stats+0x19/0x60 > [] default_do_nmi+0x72/0x1c0 > [] ? hrtimer_try_to_cancel+0x58/0x1f0 > [] do_nmi+0xb8/0xf0 > [] end_repeat_nmi+0x1e/0x2e > [] ? hrtimer_try_to_cancel+0x58/0x1f0 > [] ? get_lock_stats+0x19/0x60 > [] ? get_lock_stats+0x19/0x60 > [] ? get_lock_stats+0x19/0x60 > <>[] lock_release_holdtime.part.29+0x50/0x160 > [] lock_release+0x235/0x300 > [] _raw_spin_unlock_irqrestore+0x24/0x70 > [] hrtimer_try_to_cancel+0x58/0x1f0 > [] hrtimer_cancel+0x1a/0x30 > [] tick_nohz_restart+0x17/0x90 > [] __tick_nohz_full_check+0xc8/0xe0 > [] nohz_full_kick_work_func+0xe/0x10 > [] irq_work_run_list+0x4f/0x70 > [] irq_work_tick+0x2b/0x50 > [] update_process_times+0x5b/0x70 > [] tick_sched_handle.isra.21+0x25/0x60 > [] tick_sched_timer+0x41/0x60 > [] __run_hrtimer+0x81/0x480 > [] ? tick_sched_do_timer+0x90/0x90 > [] hrtimer_interrupt+0x107/0x260 > [] local_apic_timer_interrupt+0x34/0x60 > [] smp_apic_timer_interrupt+0x3f/0x60 > [] apic_timer_interrupt+0x6f/0x80 >[] ? cache_clean+0x66/0x2f0 [sunrpc] > [] cache_flush+0x37/0x70 [sunrpc] > [] cache_purge+0x4f/0x80 [sunrpc] > [] svcauth_unix_purge+0xca/0x1c0 [sunrpc] > [] ? svcauth_unix_purge+0x5/0x1c0 [sunrpc] > [] nfsd_export_shutdown+0x112/0x250 [nfsd] > [] ? nfsd_export_shutdown+0x5/0x250 [nfsd] > [] nfsd_exit_net+0x1a/0x20 [nfsd] > [] ops_exit_list.isra.1+0x39/0x60 > [] cleanup_net+0x100/0x1e0 > [] process_one_work+0x1e0/0x6b0 > [] ? process_one_work+0x177/0x6b0 > [] worker_thread+0x11b/0x490 > [] ? process_one_work+0x6b0/0x6b0 > [] kthread+0xf6/0x110 > [] ? kthread_create_on_node+0x250/0x250 > [] ret_from_fork+0x7c/0xb0 > [] ? kthread_create_on_node+0x250/0x250 > > Here's what I have on top of Linus' current tree.. > http://paste.fedoraproject.org/140505/20075141/raw/ > > Do I miss some other essential patch ? If you have used the diff in that URL then you've missed: x86: Tell irq work about self IPI support Without that the whole patchset has no effect. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] thermal: core: fix: Check return code of the ->get_max_state() callback
On Fri, 2014-10-03 at 12:40 +0200, Lukasz Majewski wrote: > Hi Eduardo, Rui, > > > On Wed, Sep 24, 2014 at 10:27:12AM +0200, Lukasz Majewski wrote: > > > Without this check it was possible to execute cooling device > > > binding code even when wrong max cooling state was read. > > > > > > Signed-off-by: Lukasz Majewski > > > > Acked-by: Eduardo Valentin > > > > Rui, are you taking these patches? Do you prefer me to collect them? > > I'd like to ask you NOT to apply those patches. > > In short: It will cause regression on all non Exynos boards. > > Explanation: > > Up till now the cpu_cooling device was bind even when the > get_max_state() returned -EINVAL and everything worked after late > cpufreq policy initialization. > > However, during this time window the thermal driver is not properly > configured. > > Applying PATCH2/3 and PATCH3/3 would cause bind error without any > further occasion for re-bind. As a result THERAL will not be present > on the target system. > > It works on the Exynos boards, since at the report_trigger() function, > when first trip point is reached, it is checked if cpu_cooling device > is bind. If it is not (due to "fixes" at PATCH2/3 and PATCH3/3) it > is rebind then. > > Due to above, I think that it would be best to leave things as they are > now and prepare proper fix as suggested by Eduardo. > Agreed. Can anyone please propose such a patch? thanks, rui > > > > Cheers > > > > Eduardo > > > > > --- > > > drivers/thermal/thermal_core.c | 6 -- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/thermal/thermal_core.c > > > b/drivers/thermal/thermal_core.c index 747618a..8a4dc35 100644 > > > --- a/drivers/thermal/thermal_core.c > > > +++ b/drivers/thermal/thermal_core.c > > > @@ -928,7 +928,7 @@ int thermal_zone_bind_cooling_device(struct > > > thermal_zone_device *tz, struct thermal_zone_device *pos1; > > > struct thermal_cooling_device *pos2; > > > unsigned long max_state = 0; > > > - int result; > > > + int result, ret; > > > > > > if (trip >= tz->trips || (trip < 0 && trip != > > > THERMAL_TRIPS_NONE)) return -EINVAL; > > > @@ -945,7 +945,9 @@ int thermal_zone_bind_cooling_device(struct > > > thermal_zone_device *tz, if (tz != pos1 || cdev != pos2) > > > return -EINVAL; > > > > > > - cdev->ops->get_max_state(cdev, _state); > > > + ret = cdev->ops->get_max_state(cdev, _state); > > > + if (ret) > > > + return ret; > > > > > > /* lower default 0, upper default max_state */ > > > lower = lower == THERMAL_NO_LIMIT ? 0 : lower; > > > -- > > > 2.0.0.rc2 > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] thermal: step_wise: fix: Prevent from binary overflow when trend is dropping
On Wed, 2014-09-24 at 10:27 +0200, Lukasz Majewski wrote:
> It turns out that some boards can have instance->lower greater than 0 and
> when thermal trend is dropping it results with next_target equal to -1.
>
> Since the next_target is defined as unsigned long it is interpreted as
> 0x and larger than instance->upper.
> As a result the next_target is set to instance->upper which ramps up to
> maximal cooling device target when the temperature is steadily decreasing.
>
> Signed-off-by: Lukasz Majewski
applied.
thanks,
rui
> ---
> drivers/thermal/step_wise.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
> index 3b54c2c..fdd1f52 100644
> --- a/drivers/thermal/step_wise.c
> +++ b/drivers/thermal/step_wise.c
> @@ -77,7 +77,7 @@ static unsigned long get_target_state(struct
> thermal_instance *instance,
> next_target = instance->upper;
> break;
> case THERMAL_TREND_DROPPING:
> - if (cur_state == instance->lower) {
> + if (cur_state <= instance->lower) {
> if (!throttle)
> next_target = THERMAL_NO_TARGET;
> } else {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: armv7: perf: fix armv7 ref-cycles error
On 2014/10/8 21:38, Will Deacon wrote: > On Wed, Oct 08, 2014 at 02:31:47PM +0100, gre...@linuxfoundation.org wrote: >> On Wed, Oct 08, 2014 at 10:17:41AM +0100, Will Deacon wrote: >>> On Wed, Oct 08, 2014 at 04:06:12AM +0100, zhangzhiqiang wrote: hi all, ref-cycles event is specially to Intel core, but can still used in arm architecture with the wrong return value with 3.10 stable. for instance: perf stat -e ref-cycles sleep 1 Performance counter stats for 'sleep 1': 0 ref-cycles 1.002381916 seconds time elapsed this patch fix the bug and make it return NOT SUPPORTED distinctly. In upstream this bug has been fixed by other way(not primary for the bug), which changes more than one file and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0. besides we can not simply cherry-pick. >>> >>> I thought I saw Greg pick this up the other day? >> >> Yes, it's in 3.16.4, did I do something wrong by accepting it? > > Nah, it's a trivial patch that I struggle to get excited about. I'm just not > sure why it's being sent again, after you already accepted it. Yes, it's in 3.16.4, in my opinion 3.10 need it too, can we put it into 3.10 or do we have the plan? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reset: socfpga: use arch_initcall for early initialization
From: Dinh Nguyen
There are certain drivers that are required to get loaded very early using
arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
This driver has to get loaded early because it needs to enable FPGA components
that are connected to the bridge.
This FPGA bridge driver will using the reset controller API to toggle it's
reset bits, thus, it needs the reset driver to be loaded as early as possible
in order for it to get used properly.
Signed-off-by: Dinh Nguyen
---
drivers/reset/reset-socfpga.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index 79c32ca..a5e8d37 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -139,7 +139,20 @@ static struct platform_driver socfpga_reset_driver = {
.of_match_table = socfpga_reset_dt_ids,
},
};
-module_platform_driver(socfpga_reset_driver);
+
+static int __init socfpga_reset_init(void)
+{
+ return platform_driver_probe(_reset_driver,
+ socfpga_reset_probe);
+}
+
+static void __exit socfpga_reset_exit(void)
+{
+ platform_driver_unregister(_reset_driver);
+}
+
+arch_initcall(socfpga_reset_init);
+module_exit(socfpga_reset_exit);
MODULE_AUTHOR("Steffen Trumtrar http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] ARM: sunxi: Add basic support for Allwinner A80 SoC
Hi, Am 08.10.2014 um 15:02 schrieb Chen-Yu Tsai: > This is v3 of the initial Allwinner A80 support series. > This patch series adds very basic support for Allwinner's A80 SoC, > a big.LITTLE architecture with 4 Cortex-A7s and 4 Cortex-A15s. > > Development is done on the A80 Optimus Board, the defacto development > board for the A80, with the accompanying SDK as a reference. > > So far I've been unable to get the board to boot from MMC, or > using Android fastboot. I'm using Allwinner's FEL mode to load > the bootloader and kernel+dtb image over USB. Notes on my attempts > can be found here: http://linux-sunxi.org/User:Wens#A80_Optimus Tested-by: Andreas Färber With this patch set on top of Maxime's sunxi-next branch, I get as far as searching for the rootfs. CPUs 1-7 fail to boot with -38, which I guess is due to the vendor U-Boot not yet supporting PSCI. Thanks a lot for your work and help, Chen-Yu! Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg signature.asc Description: OpenPGP digital signature
Re: [PATCH v7 5/6] arm64: add SIGSYS siginfo for compat task
On 10/08/2014 11:30 PM, Will Deacon wrote:
On Thu, Oct 02, 2014 at 10:46:15AM +0100, AKASHI Takahiro wrote:
SIGSYS is primarily used in secure computing to notify tracer.
This patch allows signal handler on compat task to get correct information
with SA_SIGINFO specified when this signal is delivered.
Reviewed-by: Kees Cook
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/asm/compat.h |7 +++
arch/arm64/kernel/signal32.c|6 ++
2 files changed, 13 insertions(+)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 253e33b..c877915 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -205,6 +205,13 @@ typedef struct compat_siginfo {
compat_long_t _band;/* POLL_IN, POLL_OUT, POLL_MSG
*/
int _fd;
} _sigpoll;
+
+ /* SIGSYS */
+ struct {
+ compat_uptr_t _call_addr; /* calling user insn */
+ int _syscall; /* triggering system call number */
+ unsigned int _arch; /* AUDIT_ARCH_* of syscall */
nit, but compat_uint_t looks better here (I have no idea why I didn't do
this for the signed int types, but hey).
I will fix it.
-Takahiro AKASHI
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [x86LKP] PANIC: double fault, error_code: 0xffffffffffffffff
> As the table shows, it's not an easily reproducible bug -- the possibility is > less than 10%: I think i found the problem. Thanks. Hopefully tests will pass now. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, October 09, 2014 7:48 AM
> To: Jia Hongtao-B38951
> Cc: Guenter Roeck; Benjamin Herrenschmidt; Paul Mackerras; Michael
> Ellerman; linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> Jojy G Varghese; Guenter Roeck
> Subject: Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check
> exception on E500MC / E5500
>
> On Tue, 2014-10-07 at 22:08 -0500, Jia Hongtao-B38951 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, September 30, 2014 2:36 AM
> > > To: Guenter Roeck
> > > Cc: Benjamin Herrenschmidt; Paul Mackerras; Michael Ellerman;
> > > linuxppc- d...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Jojy G
> > > Varghese; Guenter Roeck; Jia Hongtao-B38951
> > > Subject: Re: [PATCH] powerpc/fsl: Add support for pci(e) machine
> > > check exception on E500MC / E5500
> > >
> > > On Mon, 2014-09-29 at 09:48 -0700, Guenter Roeck wrote:
> > > > From: Jojy G Varghese
> > > >
> > > > For E500MC and E5500, a machine check exception in pci(e) memory
> > > > space crashes the kernel.
> > > >
> > > > Testing shows that the MCAR(U) register is zero on a MC exception
> > > > for the
> > > > E5500 core. At the same time, DEAR register has been found to have
> > > > the address of the faulty load address during an MC exception for
> this core.
> > > >
> > > > This fix changes the current behavior to fixup the result register
> > > > and instruction pointers in the case of a load operation on a
> > > > faulty PCI address.
> > > >
> > > > The changes are:
> > > > - Added the hook to pci machine check handing to the e500mc
> > > > machine
> > > check
> > > > exception handler.
> > > > - For the E5500 core, load faulting address from SPRN_DEAR register.
> > > > As mentioned above, this is necessary because the E5500 core does
> not
> > > > report the fault address in the MCAR register.
> > > >
> > > > Cc: Scott Wood
> > > > Signed-off-by: Jojy G Varghese [Guenter Roeck:
> > > > updated description]
> > > > Signed-off-by: Guenter Roeck
> > > > Signed-off-by: Guenter Roeck
> > > > ---
> > > > arch/powerpc/kernel/traps.c | 3 ++-
> > > > arch/powerpc/sysdev/fsl_pci.c | 5 +
> > > > 2 files changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/powerpc/kernel/traps.c
> > > > b/arch/powerpc/kernel/traps.c index 0dc43f9..ecb709b 100644
> > > > --- a/arch/powerpc/kernel/traps.c
> > > > +++ b/arch/powerpc/kernel/traps.c
> > > > @@ -494,7 +494,8 @@ int machine_check_e500mc(struct pt_regs *regs)
> > > > int recoverable = 1;
> > > >
> > > > if (reason & MCSR_LD) {
> > > > - recoverable = fsl_rio_mcheck_exception(regs);
> > > > + recoverable = fsl_rio_mcheck_exception(regs) ||
> > > > + fsl_pci_mcheck_exception(regs);
> > > > if (recoverable == 1)
> > > > goto silent_out;
> > > > }
> > > > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > > > b/arch/powerpc/sysdev/fsl_pci.c index c507767..bdb956b 100644
> > > > --- a/arch/powerpc/sysdev/fsl_pci.c
> > > > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > > > @@ -1021,6 +1021,11 @@ int fsl_pci_mcheck_exception(struct pt_regs
> > > > *regs) #endif
> > > > addr += mfspr(SPRN_MCAR);
> > > >
> > > > +#ifdef CONFIG_E5500_CPU
> > > > + if (mfspr(SPRN_EPCR) & SPRN_EPCR_ICM)
> > > > + addr = PFN_PHYS(vmalloc_to_pfn((void
> *)mfspr(SPRN_DEAR)));
> > > #endif
> > >
> > > Kconfig tells you what hardware is supported, not what hardware
> > > you're actually running on.
> > >
> > > Jia Hongtao, do you know anything about this issue? Is there an
> erratum?
> >
> > Sorry for the late response, I just return from my vacation.
> > I don't know this issue.
> >
> > > What chips are affected by the the erratum covered by
> > >
Re: [RFC v1 01/28] x86, irq: Kill unused setup_timer_IRQ0_pin()
Hi Thomas,
This patch has dependency on your patchset to remove
the last caller of setup_timer_IRQ0_pin(). What's the best
way to solve this dependency? Should I pull your patches or
just keeping the temporary "#if 0"?
Regards!
Gerry
On 2014/9/26 22:57, Jiang Liu wrote:
> Now there's no user of setup_timer_IRQ0_pin(), so kill it.
>
> Signed-off-by: Jiang Liu
> ---
> Hi all,
> This patch depends on Thomas' work to remove the last caller of
> setup_timer_IRQ0_pin(). So the "#if 0" is intended, so it won't block
> following up patches.
> Regards!
> Gerry
> ---
> arch/x86/include/asm/io_apic.h |1 -
> arch/x86/kernel/apic/io_apic.c | 17 -
> arch/x86/platform/intel-mid/intel-mid.c |2 ++
> 3 files changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
> index 7bf86bfe05b1..f9a99bc28981 100644
> --- a/arch/x86/include/asm/io_apic.h
> +++ b/arch/x86/include/asm/io_apic.h
> @@ -204,7 +204,6 @@ extern int mp_irqdomain_map(struct irq_domain *domain,
> unsigned int virq,
> irq_hw_number_t hwirq);
> extern void mp_irqdomain_unmap(struct irq_domain *domain, unsigned int virq);
> extern int mp_set_gsi_attr(u32 gsi, int trigger, int polarity, int node);
> -extern void __init pre_init_apic_IRQ0(void);
>
> extern void mp_save_irq(struct mpc_intsrc *m);
> extern bool mp_should_keep_irq(struct device *dev);
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index 37796fcd33e2..5cccf8989507 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -3091,20 +3091,3 @@ bool mp_should_keep_irq(struct device *dev)
>
> return false;
> }
> -
> -/* Enable IOAPIC early just for system timer */
> -void __init pre_init_apic_IRQ0(void)
> -{
> - struct io_apic_irq_attr attr = { 0, 0, 0, 0 };
> -
> - printk(KERN_INFO "Early APIC setup for system timer0\n");
> -#ifndef CONFIG_SMP
> - physid_set_mask_of_physid(boot_cpu_physical_apicid,
> - _cpu_present_map);
> -#endif
> - setup_local_APIC();
> -
> - io_apic_setup_irq_pin(0, 0, );
> - irq_set_chip_and_handler_name(0, _chip, handle_edge_irq,
> - "edge");
> -}
> diff --git a/arch/x86/platform/intel-mid/intel-mid.c
> b/arch/x86/platform/intel-mid/intel-mid.c
> index 1bbedc4b0f88..f8855b703cab 100644
> --- a/arch/x86/platform/intel-mid/intel-mid.c
> +++ b/arch/x86/platform/intel-mid/intel-mid.c
> @@ -99,7 +99,9 @@ static void __init intel_mid_time_init(void)
> return;
> }
> /* we need at least one APB timer */
> +#if 0
> pre_init_apic_IRQ0();
> +#endif
> apbt_time_init();
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] HID: wacom: Prevent potential null dereference after disconnect
On Wed, Oct 8, 2014 at 5:28 PM, Dmitry Torokhov wrote: > On Wed, Oct 08, 2014 at 05:24:32PM -0700, Jason Gerecke wrote: >> On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov >> wrote: >> > On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote: >> >> Repeated connect/disconnect cycles under GNOME can trigger an occasional >> >> OOPS from within e.g. wacom_led_select_store, presumably due to a timing >> >> issue where userspace begins setting a value immediately before the >> >> device disconnects and our shared data is whisked away. >> >> >> >> Signed-off-by: Jason Gerecke >> >> --- >> >> Changes in v2: >> >> * Added in missing escape character >> >> >> >> drivers/hid/wacom_sys.c | 13 - >> >> 1 file changed, 12 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c >> >> index 8593047..265429b 100644 >> >> --- a/drivers/hid/wacom_sys.c >> >> +++ b/drivers/hid/wacom_sys.c >> >> @@ -641,6 +641,9 @@ static ssize_t wacom_led_select_store(struct device >> >> *dev, int set_id, >> >> unsigned int id; >> >> int err; >> >> >> >> + if (!wacom) >> >> + return -ENODEV; >> >> + >> > >> > Strong NAK. If device could disappear before this check it could as well >> > disappear after your check. >> > >> > This patch does not solve anything. >> > >> >> I assume I'll want to either disable interrupts or take a lock >> depending on if `wacom_remove` is called from within the interrupt >> context, but I haven't had to deal with concurrency in the kernel >> before so I'm not entirely sure which option (or which primitive if >> locking) would be appropriate... > > Actually the sysfs core should not allow anyone descend into sysfs > show/store methods once you return from sysfs_remove*(). So you need to > make sure that pointer is valid until then. > > Thanks. > > -- > Dmitry Hmm. That's odd. The `wacom_remove` function calls `wacom_destroy_leds` (which is responsible for removing those sysfs nodes) prior to calling `wacom_remove_shared_data` (which is responsible for freeing that pointer). I could imagine that a disconnect which occurred after the sysfs checks were satisfied but before our function was called would be able to get around that, but I don't know if the kernel can be interrupted while the sysfs write is being handled. I'll double-check what the actual state of things is when the OOPS happens... Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[mm] BUG: Int 6: CR2 (null)
Hi Marek,
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 478e86d7c8c5f41e29abb81b05b459d24bdc71a2 ("mm: cma: adjust address limit
to avoid hitting low/high memory boundary")
+--+++
| | 81febe58a8 | 478e86d7c8 |
+--+++
| boot_successes | 10 | 0 |
| boot_failures| 5 | 10 |
| kernel_BUG_at_arch/x86/mm/physaddr.c | 5 ||
| invalid_opcode | 5 ||
| EIP_is_at__phys_addr | 5 ||
| Kernel_panic-not_syncing:Fatal_exception | 5 ||
| backtrace:vm_mmap_pgoff | 5 ||
| backtrace:SyS_mmap_pgoff | 5 ||
| BUG:Int_CR2(null)| 0 | 10 |
+--+++
[0.00] BRK [0x025ee000, 0x025eefff] PGTABLE
[0.00] cma: dma_contiguous_reserve(limit 13ffe000)
[0.00] cma: dma_contiguous_reserve: reserving 31 MiB for global area
[0.00] BUG: Int 6: CR2 (null)
[0.00] EDI c000 ESI (null) EBP 41c11ea4 EBX 425cc101
[0.00] ESP 41c11e98 ES 007b DS 007b
[0.00] EDX 0001 ECX (null) EAX 41cd8150
[0.00] vec 0006 err (null) EIP 41072227 CS 0060 flg
00210002
[0.00] Stack: 425cc150 (null) (null) 41c11ef4 41d4ee4d (null)
13ffe000 41c11ec4
[0.00]41c2d900 (null) 13ffe000 (null) 4185793e 002e
410c2982 41c11f00
[0.00]410c2df5 (null) (null) (null) 425cc150 00013efe
(null) 41c11f28
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-next-20141008 #815
[0.00] 425cc101 41c11e48 41850786 41c11ea4 41d2b1db 41d95f71
0006
[0.00] c000 41c11ea4 425cc101 41c11e98 007b
007b
[0.00] 0001 41cd8150 0006 41072227 0060
00210002
[0.00] Call Trace:
[0.00] [<41850786>] dump_stack+0x16/0x18
[0.00] [<41d2b1db>] early_idt_handler+0x6b/0x6b
[0.00] [<41072227>] ? __phys_addr+0x2e/0xca
[0.00] [<41d4ee4d>] cma_declare_contiguous+0x3c/0x2d7
[0.00] [<4185793e>] ? _raw_spin_unlock_irqrestore+0x59/0x91
[0.00] [<410c2982>] ? wake_up_klogd+0x8/0x33
[0.00] [<410c2df5>] ? console_unlock+0x448/0x461
[0.00] [<41d6d359>] dma_contiguous_reserve_area+0x27/0x47
[0.00] [<41d6d4d1>] dma_contiguous_reserve+0x158/0x163
[0.00] [<41d33e0f>] setup_arch+0x79b/0xc68
[0.00] [<4184c0b4>] ? printk+0x1c/0x1e
[0.00] [<41d2b7cf>] start_kernel+0x9c/0x456
[0.00] [<41d2b2ca>] i386_start_kernel+0x79/0x7d
Elapsed time: 5
qemu-system-i386 -enable-kvm -kernel
/kernel/i386-randconfig-hxb2-1008/099669ed953121e1b00248f65326b6b092fa47c8/vmlinuz-3.17.0-next-20141008
-append 'user=lkp
job=/lkp/scheduled/vm-kbuild-yocto-i386-58/rand_boot-1-yocto-minimal-i386.cgz-i386-randconfig-hxb2-1008-099669ed953121e1b00248f65326b6b092fa47c8-0.yaml
ARCH=i386
BOOT_IMAGE=/kernel/i386-randconfig-hxb2-1008/099669ed953121e1b00248f65326b6b092fa47c8/vmlinuz-3.17.0-next-20141008
kconfig=i386-randconfig-hxb2-1008
commit=099669ed953121e1b00248f65326b6b092fa47c8 branch=next/master
root=/dev/ram0 max_uptime=3600
RESULT_ROOT=/result/vm-kbuild-yocto-i386/boot/1/yocto-minimal-i386.cgz/i386-randconfig-hxb2-1008/099669ed953121e1b00248f65326b6b092fa47c8/0
ip=vm-kbuild-yocto-i386-58::dhcp earlyprintk=ttyS0,115200 debug apic=debug
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw
drbd.minor_count=8' -initrd /fs/sdf1/initrd-vm-kbuild-yocto-i386-58 -m 320
-smp 2 -net nic,vlan=1,model=e1000 -net user,vlan=1 -boot order=nc -no-reboot
-watchdog i6300esb -rtc base=localtime -drive
file=/fs/sdf1/disk0-vm-kbuild-yocto-i386-58,media=disk,if=virtio -drive
file=/fs/sdf1/disk1-vm-kbuild-yocto-i386-58,media=disk,if=virtio -drive
file=/fs/sdf1/disk2-vm-kbuild-yocto-i386-58,media=disk,if=virtio -drive
file=/fs/sdf1/disk3-vm-kbuild-yocto-i386-58,media=disk,if=virtio -drive
file=/fs/sdf1/disk4-vm-kbuild-yocto-i386-58,media=disk,if=virtio -drive
file=/fs/sdf1/disk5-vm-kbuild-yocto-i386-58,media=disk,if=virtio -pidfile
/dev/shm/kboot/pid-vm-kbuild-yocto-i386-58 -serial
file:/dev/shm/kboot/serial-vm-kbuild-yocto-i386-58 -daemonize -display none
-monitor null
Thanks,
Fenggua
Re: hrtimer deadlock caused by nohz_full
On Tue, Oct 07, 2014 at 07:42:47PM +0200, Thomas Gleixner wrote: > On Tue, 7 Oct 2014, Dave Jones wrote: > > > On Tue, Oct 07, 2014 at 05:30:27PM +0200, Frederic Weisbecker wrote: > > > > > > > Right, this patchset fixes it: "[PATCH 0/8] nohz: Fix nohz kick > > irq work on tick v3" > > > > > > > > > > I was about to make the pull request, the branch is acked by > > peterz. > > > > > Would you like to pull it? It's all merge window material. > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > > > >nohz/fixes-v3 > > > > > > > > I'm now hitting this with such regularity that it's preventing me from > > > > tracking down other bugs. Can we get this merged soon please ? > > > > > > I asked Thomas to pull but he probably missed it. So I did a formal > > pull request > > > to Ingo a few days later but he told me that the pull request was made > > too late > > > as the merge window was too close. I told him it fixes annoying bugs > > but that was on IRC > > > so this probably got lost. > > Aarg. Lemme get this done. So, time for sad news. This still doesn't solve the problem for me. Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 2 CPU: 2 PID: 8193 Comm: kworker/u8:1 Not tainted 3.17.0+ #67 Workqueue: netns cleanup_net 2a473fb8 880244c06c00 9f81ea56 9fc63e00 880244c06c80 9f819003 0010 880244c06c90 880244c06c30 2a473fb8 Call Trace: [] dump_stack+0x4e/0x7a [] panic+0xd7/0x20a [] ? restart_watchdog_hrtimer+0x50/0x50 [] watchdog_overflow_callback+0x118/0x120 [] __perf_event_overflow+0xac/0x350 [] ? x86_perf_event_set_period+0xde/0x150 [] perf_event_overflow+0x14/0x20 [] intel_pmu_handle_irq+0x206/0x410 [] perf_event_nmi_handler+0x2b/0x50 [] nmi_handle+0xd2/0x3b0 [] ? nmi_handle+0x5/0x3b0 [] ? get_lock_stats+0x19/0x60 [] default_do_nmi+0x72/0x1c0 [] ? hrtimer_try_to_cancel+0x58/0x1f0 [] do_nmi+0xb8/0xf0 [] end_repeat_nmi+0x1e/0x2e [] ? hrtimer_try_to_cancel+0x58/0x1f0 [] ? get_lock_stats+0x19/0x60 [] ? get_lock_stats+0x19/0x60 [] ? get_lock_stats+0x19/0x60 <>[] lock_release_holdtime.part.29+0x50/0x160 [] lock_release+0x235/0x300 [] _raw_spin_unlock_irqrestore+0x24/0x70 [] hrtimer_try_to_cancel+0x58/0x1f0 [] hrtimer_cancel+0x1a/0x30 [] tick_nohz_restart+0x17/0x90 [] __tick_nohz_full_check+0xc8/0xe0 [] nohz_full_kick_work_func+0xe/0x10 [] irq_work_run_list+0x4f/0x70 [] irq_work_tick+0x2b/0x50 [] update_process_times+0x5b/0x70 [] tick_sched_handle.isra.21+0x25/0x60 [] tick_sched_timer+0x41/0x60 [] __run_hrtimer+0x81/0x480 [] ? tick_sched_do_timer+0x90/0x90 [] hrtimer_interrupt+0x107/0x260 [] local_apic_timer_interrupt+0x34/0x60 [] smp_apic_timer_interrupt+0x3f/0x60 [] apic_timer_interrupt+0x6f/0x80 [] ? cache_clean+0x66/0x2f0 [sunrpc] [] cache_flush+0x37/0x70 [sunrpc] [] cache_purge+0x4f/0x80 [sunrpc] [] svcauth_unix_purge+0xca/0x1c0 [sunrpc] [] ? svcauth_unix_purge+0x5/0x1c0 [sunrpc] [] nfsd_export_shutdown+0x112/0x250 [nfsd] [] ? nfsd_export_shutdown+0x5/0x250 [nfsd] [] nfsd_exit_net+0x1a/0x20 [nfsd] [] ops_exit_list.isra.1+0x39/0x60 [] cleanup_net+0x100/0x1e0 [] process_one_work+0x1e0/0x6b0 [] ? process_one_work+0x177/0x6b0 [] worker_thread+0x11b/0x490 [] ? process_one_work+0x6b0/0x6b0 [] kthread+0xf6/0x110 [] ? kthread_create_on_node+0x250/0x250 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x250/0x250 Here's what I have on top of Linus' current tree.. http://paste.fedoraproject.org/140505/20075141/raw/ Do I miss some other essential patch ? Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/6] arm64: ptrace: add PTRACE_SET_SYSCALL
On 10/09/2014 12:30 AM, Kees Cook wrote:
On Wed, Oct 8, 2014 at 9:13 AM, Will Deacon wrote:
Hi Akashi,
On Thu, Oct 02, 2014 at 10:46:11AM +0100, AKASHI Takahiro wrote:
To allow tracer to be able to change/skip a system call by re-writing
a syscall number, there are several approaches:
(1) modify x8 register with ptrace(PTRACE_SETREGSET), and handle this case
later on in syscall_trace_enter(), or
(2) support ptrace(PTRACE_SET_SYSCALL) as on arm
Thinking of the fact that user_pt_regs doesn't expose 'syscallno' to
tracer as well as that secure_computing() expects a changed syscall number
to be visible, especially case of -1, before this function returns in
syscall_trace_enter(), we'd better take (2).
Reviewed-by: Kees Cook
Signed-off-by: AKASHI Takahiro
---
arch/arm64/include/uapi/asm/ptrace.h |1 +
arch/arm64/kernel/ptrace.c | 14 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/uapi/asm/ptrace.h
b/arch/arm64/include/uapi/asm/ptrace.h
index 6913643..49c6174 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -23,6 +23,7 @@
#include
+#define PTRACE_SET_SYSCALL 23
/*
* PSR bits
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index fe63ac5..2842f9f 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1082,7 +1082,19 @@ const struct user_regset_view
*task_user_regset_view(struct task_struct *task)
long arch_ptrace(struct task_struct *child, long request,
unsigned long addr, unsigned long data)
{
- return ptrace_request(child, request, addr, data);
+ int ret;
+
+ switch (request) {
+ case PTRACE_SET_SYSCALL:
+ task_pt_regs(child)->syscallno = data;
+ ret = 0;
+ break;
+ default:
+ ret = ptrace_request(child, request, addr, data);
+ break;
+ }
+
+ return ret;
}
I still don't understand why this needs to be in arch-specific code. Can't
we implement this in generic code and get architectures to implement
something like syscall_set_nr if they want the generic interface?
Personally, I'd rather see this land as-is in the arm64 tree, and then
later optimize PTRACE_SET_SYSCALL out of arm/ and arm64/, especially
since only these architectures implement this at the moment.
+1 :)
-Takahiro AKASHI
This is my plan for the asm-generic seccomp.h too -- I'd rather avoid
touching other architectures in this series, as it's easier to review
this way. Then we can optimize the code in a separate series, which
will have those changes isolated, etc.
-Kees
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] staging: dgap: introduce dgap_stop()
Hi, Dan
2014-10-08 20:37 GMT+09:00 Dan Carpenter :
> All three of these patches are good and a nice improvement. This one is
> a good bugfix. I have some notes for later, though below.
>
> On Wed, Oct 08, 2014 at 08:13:56PM +0900, Daeseok Youn wrote:
>> diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
>> index 7c79fe6..00f34b5 100644
>> --- a/drivers/staging/dgap/dgap.c
>> +++ b/drivers/staging/dgap/dgap.c
>> @@ -71,6 +71,7 @@ MODULE_DESCRIPTION("Driver for the Digi International EPCA
>> PCI based product lin
>> MODULE_SUPPORTED_DEVICE("dgap");
>>
>> static int dgap_start(void);
>> +static void dgap_stop(void);
>
> These kinds of forward declarations are annoying. The whole file needs
> to be re-arranged so that we don't have to deal with them.
OK. I will try to re-arrange and remove forward declarations.
>
>> @@ -561,6 +563,21 @@ failed_class:
>> return rc;
>> }
>>
>> +static void dgap_stop(void)
>> +{
>> + ulong lock_flags;
OK. I will send this patch again after changing ulong to "unsigned long".
>
> This is non-standard. Traditionally it would be:
>
> unsigned long flags;
>
> regards,
> dan carpenter
Thanks
regards,
Daeseok Youn
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 8 (media/usb/gspca)
Em Wed, 08 Oct 2014 13:53:33 -0700
Randy Dunlap escreveu:
> On 10/08/14 11:31, Mauro Carvalho Chehab wrote:
> > Em Wed, 08 Oct 2014 10:13:39 -0700
> > Randy Dunlap escreveu:
> >
> >> On 10/07/14 23:49, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Please do not add any material intended for v3.19 to you linux-next
> >>> included trees until after v3.18-rc1 has been released.
> >>>
> >>> Changes since 20141007:
> >>>
> >>
> >> I saw these build errors in gspca when CONFIG_INPUT=m but the gspca
> >> sub-drivers are builtin:
> >>
> >> drivers/built-in.o: In function `gspca_dev_probe2':
> >> (.text+0x10ef43): undefined reference to `input_allocate_device'
> >> drivers/built-in.o: In function `gspca_dev_probe2':
> >> (.text+0x10efdd): undefined reference to `input_register_device'
> >> drivers/built-in.o: In function `gspca_dev_probe2':
> >> (.text+0x10f002): undefined reference to `input_free_device'
> >> drivers/built-in.o: In function `gspca_dev_probe2':
> >> (.text+0x10f0ac): undefined reference to `input_unregister_device'
> >> drivers/built-in.o: In function `gspca_disconnect':
> >> (.text+0x10f186): undefined reference to `input_unregister_device'
> >> drivers/built-in.o: In function `sd_int_pkt_scan':
> >> se401.c:(.text+0x11373d): undefined reference to `input_event'
> >> se401.c:(.text+0x11374e): undefined reference to `input_event'
> >> drivers/built-in.o: In function `sd_pkt_scan':
> >> t613.c:(.text+0x119f0e): undefined reference to `input_event'
> >> t613.c:(.text+0x119f1f): undefined reference to `input_event'
> >> drivers/built-in.o: In function `sd_stopN':
> >> t613.c:(.text+0x11a047): undefined reference to `input_event'
> >> drivers/built-in.o:t613.c:(.text+0x11a058): more undefined references to
> >> `input_event' follow
> >>
> >> These could be fixed in Kconfig by something like (for each sub-driver
> >> that tests
> >> CONFIG_INPUT):
> >>
> >>depends on INPUT || INPUT=n
> >>
> >> Do you have another preference for fixing this?
> >
> > Hmm... The code at the gspca subdrivers looks like:
> >
> > #if IS_ENABLED(CONFIG_INPUT)
>
> For builtin only, that should be
>
> #if IS_BUILTIN(CONFIG_INPUT)
>
> > if (data[0] & 0x20) {
> > input_report_key(gspca_dev->input_dev, KEY_CAMERA, 1);
> > input_sync(gspca_dev->input_dev);
> > input_report_key(gspca_dev->input_dev, KEY_CAMERA, 0);
> > input_sync(gspca_dev->input_dev);
> > }
> > #endif
> >
> > As we never got any report about such bug, and this is there for a long
> > time, I suspect that maybe the IS_ENABLED() macro had some changes on
> > its behavior. So, IMHO, we should first check if something changed there.
>
> I don't see any changes in .
Perhaps some changes at the Kbuild source code or scripts badly affected it.
>
> > From gpsca's PoV, IMHO, it should be fine to disable the webcam buttons if
> > the webcam was compiled as builtin and the input subsystem is compiled as
> > module. The core feature expected on a camera is to capture streams.
> > Buttons are just a plus.
> >
> > Also, most cams don't even have buttons. The gspca subdriver has support
> > for buttons for the few models that have it.
> >
> > So, IMHO, it should be ok to have GSPCA=y and INPUT=m, provided that
> > the buttons will be disabled.
>
> Then all of the sub-drivers that use IS_ENABLED(CONFIG_INPUT) should be
> changed to use IS_BUILTIN(CONFIG_INPUT).
>
> But that is too restrictive IMO. The input subsystem will work fine when
> CONFIG_INPUT=m and the GSPCA drivers are also loadable modules.
Agreed.
Maybe the solution would be something more complex like
(for drivers/media/usb/gspca/zc3xx.c):
#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) &&
!IS_BUILTIN(CONFIG_USB_GSPCA_ZC3XX))
Probably the best would be to write another macro that would evaluate
like the above.
> That's simple to express in Kconfig language but probly more messy in CPP.
>
>
> Thanks.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i915.ko WC writes are slow after ea8596bb2d8d379
(2014/10/09 2:47), Chuck Ebbert wrote: > On Wed, 8 Oct 2014 10:03:36 +0100 > Chris Wilson wrote: > >> and adding that back into the current build, e.g. >> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >> index 3632743..48a8a69 100644 >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -87,6 +87,7 @@ config X86 >> select HAVE_USER_RETURN_NOTIFIER >> select ARCH_BINFMT_ELF_RANDOMIZE_PIE >> select HAVE_ARCH_JUMP_LABEL >> + select STOP_MACHINE >> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE >> select SPARSE_IRQ >> select GENERIC_FIND_FIRST_BIT >> >> fixes the regression. >> > > Looking closer at this, it seems most configs work by accident, > because they have MOD_UNLOAD and/or HOTPLUG_CPU enabled. I take it > you disabled both of those? stop_machine() is called from all kinds > of places and almost none of them make sure STOP_MACHINE is selected. I guess most of them expects stop_machine() is not a configurable feature... If some of them requires stop_machine(), it should enable it on its kconfig entry (including ftrace, kprobes). > $ find -name Kconf\* | xargs grep STOP_MACHINE > ./init/Kconfig:config STOP_MACHINE > > All these places use stop_machine(): > > mm/page_alloc.c, line 3886 > drivers/xen/manage.c, line 130 > drivers/char/hw_random/intel-rng.c, line 373 > arch/powerpc/mm/numa.c: > line 1616 > line 1623 > arch/powerpc/platforms/powernv/subcore.c, line 324 > arch/arm/kernel/kprobes.c, line 165 > arch/arm/kernel/patch.c: > line 64 > line 71 > arch/s390/kernel/jump_label.c, line 61 > arch/s390/kernel/kprobes.c: > line 311 > line 320 > arch/s390/kernel/time.c: > line 820 > line 1590 > arch/x86/kernel/cpu/mtrr/main.c, line 231 > arch/arm64/kernel/insn.c, line 181 > kernel/time/timekeeping.c, line 892 > kernel/trace/ftrace.c, line 2219 > kernel/module.c: > line 770 > line 1861 > BTW, as I sent a series of patches, the last two can be removed. https://lkml.org/lkml/2014/8/25/142 Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/8] Per-user clock constraints
On 10/07/2014 08:21 AM, Tomeu Vizoso wrote: Hello, this second version of the series adds several cleanups that were suggested by Stephen Boyd and contains several improvements to the seventh patch (clk: Make clk API return per-user struct clk instances) that were suggested by him during the review of v1. The first six patches are just cleanups that should be desirable on their own, and that should make easier to review the actual per-user clock patch. The seventh patch actually moves the per-clock data that was stored in struct clk to a new struct clk_core and adds references to it from both struct clk and struct clk_hw. struct clk is now ready to contain information that is specific to a given clk consumer. The eighth patch adds API for setting floor and ceiling constraints and stores that information on the per-user struct clk, which is iterable from struct clk_core. As said in the patches, can you please indicate which baseline this is on? Also can you rebase onto clk-next if you send again before that is merged into 3.18-rc1? There are some changes in the debugfs part that will conflict. I'll review the more complicated parts in detail soon. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 6/8] clk: Change clk_ops->determine_rate to return a clk_hw as the best parent
On 10/07/2014 08:21 AM, Tomeu Vizoso wrote: This is in preparation for clock providers to not have to deal with struct clk. Signed-off-by: Tomeu Vizoso --- drivers/clk/at91/clk-programmable.c | 4 ++-- drivers/clk/bcm/clk-kona.c | 4 ++-- drivers/clk/clk-composite.c | 9 + drivers/clk/clk.c | 11 +++ drivers/clk/hisilicon/clk-hi3620.c | 2 +- drivers/clk/qcom/clk-rcg.c | 20 drivers/clk/qcom/clk-rcg2.c | 28 +--- drivers/clk/sunxi/clk-factors.c | 4 ++-- drivers/clk/sunxi/clk-sun6i-ar100.c | 4 ++-- include/linux/clk-provider.h| 4 ++-- 10 files changed, 52 insertions(+), 38 deletions(-) What is this based on? I see one in arch/mips/alchemy/common/clock.c as well. Can you also update Documentation/clk.txt please? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/8] clk: change clk_debugfs_add_file to take a struct clk_hw
On 10/07/2014 08:21 AM, Tomeu Vizoso wrote: Instead of struct clk, as this should be only used by providers. Signed-off-by: Tomeu Vizoso Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/8] clk: Don't expose __clk_get_accuracy
On 10/07/2014 08:21 AM, Tomeu Vizoso wrote: As it's only used internally, in drivers/clk/clk.c. Signed-off-by: Tomeu Vizoso Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/8] clk: Remove unused function __clk_get_prepare_count
On 10/07/2014 08:21 AM, Tomeu Vizoso wrote: Signed-off-by: Tomeu Vizoso --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH V3 0/3] PM/CPU: Parallel enalbing nonboot cpus with resume devices
On 2014年10月09日 04:54, Peter Zijlstra wrote: > On Thu, Sep 25, 2014 at 04:32:02PM +0800, Lan Tianyu wrote: >> This patchset is to parallel enabling nonboot cpus with resuming devices >> during system resume in order to accelerate S2RAM. From test result on >> a 8 logical core Haswell machine, system resume time reduces from 347ms >> to 217ms with this patchset. >> >> In the current world, all nonboot cpus are enabled serially during system >> resume. System resume sequence is that boot cpu enables nonboot cpu one by >> one and then resume devices. Before resuming devices, there are few tasks >> assigned to nonboot cpus after they are brought up. This wastes cpu usage. >> >> This patchset is to allow boot cpu to go forward to resume devices after >> bringing up one nonboot cpu and starting a thread. The thread will be in >> charge of bringing up other frozen cpus. The thread will be scheduled to >> the first online cpu to run . This makes enabling cpu2~x parallel with >> resuming devices. > > So I feel we should really clean up hotplug before doing anything like > this. Its a trainwreck and just piling more and more hacks ontop isn't > going to help any. > Hi Peter: Sorry, I don't know the gap of hotplug clearly. Could you elaborate it? -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH 0/2] tracing: Minor fixes to the start up tests
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: 0cd8f5614fbf8a598a0a47526ac7dc42ab2ba8cd Peter Zijlstra (1): tracing: Robustify wait loop Steven Rostedt (1): tracing: Clean up scheduling in trace_wakeup_test_thread() kernel/trace/trace_events.c | 5 - kernel/trace/trace_selftest.c | 47 +++ 2 files changed, 34 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH 2/2] tracing: Clean up scheduling in trace_wakeup_test_thread()
From: Steven Rostedt
Peter's new debugging tool triggers when tasks exit with !TASK_RUNNING.
The code in trace_wakeup_test_thread() also has a single schedule() call
that should be encompassed by a loop.
This cleans up the code a little to make it a bit more robust and
also makes the return exit properly with TASK_RUNNING.
Link: http://lkml.kernel.org/p/20141008135216.76142...@gandalf.local.home
Reported-by: Peter Zijlstra
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_selftest.c | 47 +++
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index 5ef60499dc8e..593f52b73551 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -1025,6 +1025,12 @@ trace_selftest_startup_nop(struct tracer *trace, struct
trace_array *tr)
#endif
#ifdef CONFIG_SCHED_TRACER
+
+struct wakeup_test_data {
+ struct completion is_ready;
+ int go;
+};
+
static int trace_wakeup_test_thread(void *data)
{
/* Make this a -deadline thread */
@@ -1034,51 +1040,56 @@ static int trace_wakeup_test_thread(void *data)
.sched_deadline = 1000ULL,
.sched_period = 1000ULL
};
- struct completion *x = data;
+ struct wakeup_test_data *x = data;
sched_setattr(current, );
/* Make it know we have a new prio */
- complete(x);
+ complete(>is_ready);
/* now go to sleep and let the test wake us up */
set_current_state(TASK_INTERRUPTIBLE);
- schedule();
+ while (!x->go) {
+ schedule();
+ set_current_state(TASK_INTERRUPTIBLE);
+ }
- complete(x);
+ complete(>is_ready);
+
+ set_current_state(TASK_INTERRUPTIBLE);
/* we are awake, now wait to disappear */
while (!kthread_should_stop()) {
- /*
-* This will likely be the system top priority
-* task, do short sleeps to let others run.
-*/
- msleep(100);
+ schedule();
+ set_current_state(TASK_INTERRUPTIBLE);
}
+ __set_current_state(TASK_RUNNING);
+
return 0;
}
-
int
trace_selftest_startup_wakeup(struct tracer *trace, struct trace_array *tr)
{
unsigned long save_max = tr->max_latency;
struct task_struct *p;
- struct completion is_ready;
+ struct wakeup_test_data data;
unsigned long count;
int ret;
- init_completion(_ready);
+ memset(, 0, sizeof(data));
+
+ init_completion(_ready);
/* create a -deadline thread */
- p = kthread_run(trace_wakeup_test_thread, _ready, "ftrace-test");
+ p = kthread_run(trace_wakeup_test_thread, , "ftrace-test");
if (IS_ERR(p)) {
printk(KERN_CONT "Failed to create ftrace wakeup test thread ");
return -1;
}
/* make sure the thread is running at -deadline policy */
- wait_for_completion(_ready);
+ wait_for_completion(_ready);
/* start the tracing */
ret = tracer_init(trace, tr);
@@ -1099,18 +1110,20 @@ trace_selftest_startup_wakeup(struct tracer *trace,
struct trace_array *tr)
msleep(100);
}
- init_completion(_ready);
+ init_completion(_ready);
+
+ data.go = 1;
+ /* memory barrier is in the wake_up_process() */
wake_up_process(p);
/* Wait for the task to wake up */
- wait_for_completion(_ready);
+ wait_for_completion(_ready);
/* stop the tracing. */
tracing_stop();
/* check both trace buffers */
ret = trace_test_buffer(>trace_buffer, NULL);
- printk("ret = %d\n", ret);
if (!ret)
ret = trace_test_buffer(>max_buffer, );
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH 1/2] tracing: Robustify wait loop
From: Peter Zijlstra
The pending nested sleep debugging triggered on the potential stale
TASK_INTERRUPTIBLE in this code.
While there, fix the loop such that we won't revert to a while(1)
yield() 'spin' loop if we ever get a spurious wakeup.
And fix the actual issue by properly terminating the 'wait' loop by
setting TASK_RUNNING.
Link:
http://lkml.kernel.org/p/20141008165110.ga14...@worktop.programming.kicks-ass.net
Reported-by: Fengguang Wu
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index ef06ce7e9cf8..0cc51edde3a8 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2513,8 +2513,11 @@ static __init int event_test_thread(void *unused)
kfree(test_malloc);
set_current_state(TASK_INTERRUPTIBLE);
- while (!kthread_should_stop())
+ while (!kthread_should_stop()) {
schedule();
+ set_current_state(TASK_INTERRUPTIBLE);
+ }
+ __set_current_state(TASK_RUNNING);
return 0;
}
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] HID: wacom: Prevent potential null dereference after disconnect
On Wed, Oct 08, 2014 at 05:24:32PM -0700, Jason Gerecke wrote: > On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov > wrote: > > On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote: > >> Repeated connect/disconnect cycles under GNOME can trigger an occasional > >> OOPS from within e.g. wacom_led_select_store, presumably due to a timing > >> issue where userspace begins setting a value immediately before the > >> device disconnects and our shared data is whisked away. > >> > >> Signed-off-by: Jason Gerecke > >> --- > >> Changes in v2: > >> * Added in missing escape character > >> > >> drivers/hid/wacom_sys.c | 13 - > >> 1 file changed, 12 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c > >> index 8593047..265429b 100644 > >> --- a/drivers/hid/wacom_sys.c > >> +++ b/drivers/hid/wacom_sys.c > >> @@ -641,6 +641,9 @@ static ssize_t wacom_led_select_store(struct device > >> *dev, int set_id, > >> unsigned int id; > >> int err; > >> > >> + if (!wacom) > >> + return -ENODEV; > >> + > > > > Strong NAK. If device could disappear before this check it could as well > > disappear after your check. > > > > This patch does not solve anything. > > > > I assume I'll want to either disable interrupts or take a lock > depending on if `wacom_remove` is called from within the interrupt > context, but I haven't had to deal with concurrency in the kernel > before so I'm not entirely sure which option (or which primitive if > locking) would be appropriate... Actually the sysfs core should not allow anyone descend into sysfs show/store methods once you return from sysfs_remove*(). So you need to make sure that pointer is valid until then. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: of: Lower the severity of the error with no container
On Thu, Oct 09, 2014 at 01:12:13AM +0100, Mark Brown wrote: > On Wed, Oct 08, 2014 at 05:05:55PM -0700, Guenter Roeck wrote: > > On Thu, Oct 09, 2014 at 12:45:41AM +0100, Mark Brown wrote: > > > > definitely at least add a boot argument or something to suppress them, > > > let me have a think if we want to do that by default. > > > It is a nuisance, so I might just disable it in our tree if we don't > > find some other solution. > > We'll do something, just a question of what and what the default is. > Ok. Note that a boot parameter would not work well for our use case, so it would be great if we can find something else. > > Did you notice the problem with debugfs I had mentioned earlier ? > > With all those regulators, not all of them being used, I end up with > > many having the same name. This causes issues with debugfs, which is > > trying to create the same file several times. > > > Any idea how we could solve this ? The constraints message is annoying, > > but this one is a real issue. > > Shove a dev_name() on the front if we get a collision? I have to say > I've never cared, the debugfs isn't that important so it doesn't matter > too much if it fails. Sure, but, again, I am getting lots and lots of those error messages. I probably would not care either (and probably not even have noticed) if not for those messages. Want me to submit a patch with the dev_name solution ? Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] HID: wacom: Prevent potential null dereference after disconnect
On Wed, Oct 8, 2014 at 2:40 PM, Dmitry Torokhov wrote: > On Wed, Oct 08, 2014 at 11:25:42AM -0700, Jason Gerecke wrote: >> Repeated connect/disconnect cycles under GNOME can trigger an occasional >> OOPS from within e.g. wacom_led_select_store, presumably due to a timing >> issue where userspace begins setting a value immediately before the >> device disconnects and our shared data is whisked away. >> >> Signed-off-by: Jason Gerecke >> --- >> Changes in v2: >> * Added in missing escape character >> >> drivers/hid/wacom_sys.c | 13 - >> 1 file changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c >> index 8593047..265429b 100644 >> --- a/drivers/hid/wacom_sys.c >> +++ b/drivers/hid/wacom_sys.c >> @@ -641,6 +641,9 @@ static ssize_t wacom_led_select_store(struct device >> *dev, int set_id, >> unsigned int id; >> int err; >> >> + if (!wacom) >> + return -ENODEV; >> + > > Strong NAK. If device could disappear before this check it could as well > disappear after your check. > > This patch does not solve anything. > I assume I'll want to either disable interrupts or take a lock depending on if `wacom_remove` is called from within the interrupt context, but I haven't had to deal with concurrency in the kernel before so I'm not entirely sure which option (or which primitive if locking) would be appropriate... Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours >> err = kstrtouint(buf, 10, ); >> if (err) >> return err; > > Thanks. > > -- > Dmitry > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] block: fix alignment_offset math that assumes io_min is a power-of-2
> "Mike" == Mike Snitzer writes:
Mike> The math in both blk_stack_limits() and
Mike> queue_limit_alignment_offset() assume that a block device's io_min
Mike> (aka minimum_io_size) is always a power-of-2. Fix the math such
Mike> that it works for non-power-of-2 io_min.
Mike> This issue (of alignment_offset != 0) became apparent when testing
Mike> dm-thinp with a thinp blocksize that matches a RAID6 stripesize of
Mike> 1280K. Commit fdfb4c8c1 ("dm thin: set minimum_io_size to pool's
Mike> data block size") unlocked the potential for alignment_offset != 0
Mike> due to the dm-thin-pool's io_min possibly being a non-power-of-2.
Looks good to me, Mike.
Acked-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CXL: Fix afu_read() not doing finish_wait() on signal or non-blocking
From: Ian Munsie
If afu_read() returned due to a signal or the AFU file descriptor being
opened non-blocking it would not call finish_wait() before returning,
which could lead to a crash later when something else wakes up the wait
queue.
This patch restructures the wait logic to ensure that the cleanup is
done correctly.
Signed-off-by: Ian Munsie
---
Resending with correct whitespace as my mailer decided to replace tabs with
spaces on the last try.
drivers/misc/cxl/file.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c
index 847b7e6..378b099 100644
--- a/drivers/misc/cxl/file.c
+++ b/drivers/misc/cxl/file.c
@@ -273,6 +273,7 @@ static ssize_t afu_read(struct file *file, char __user
*buf, size_t count,
struct cxl_context *ctx = file->private_data;
struct cxl_event event;
unsigned long flags;
+ int rc;
DEFINE_WAIT(wait);
if (count < CXL_READ_MIN_SIZE)
@@ -285,13 +286,17 @@ static ssize_t afu_read(struct file *file, char __user
*buf, size_t count,
if (ctx_event_pending(ctx))
break;
- spin_unlock_irqrestore(>lock, flags);
- if (file->f_flags & O_NONBLOCK)
- return -EAGAIN;
+ if (file->f_flags & O_NONBLOCK) {
+ rc = -EAGAIN;
+ goto out;
+ }
- if (signal_pending(current))
- return -ERESTARTSYS;
+ if (signal_pending(current)) {
+ rc = -ERESTARTSYS;
+ goto out;
+ }
+ spin_unlock_irqrestore(>lock, flags);
pr_devel("afu_read going to sleep...\n");
schedule();
pr_devel("afu_read woken up\n");
@@ -336,6 +341,11 @@ static ssize_t afu_read(struct file *file, char __user
*buf, size_t count,
if (copy_to_user(buf, , event.header.size))
return -EFAULT;
return event.header.size;
+
+out:
+ finish_wait(>wq, );
+ spin_unlock_irqrestore(>lock, flags);
+ return rc;
}
static const struct file_operations afu_fops = {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vdso_standalone_test_x86.c build failure on Linus' tree
On 10/08/14 16:18, Andy Lutomirski wrote: > On Wed, Oct 8, 2014 at 4:11 PM, Peter Foley wrote: >> On Wed, Oct 8, 2014 at 5:21 PM, H. Peter Anvin wrote: >>> That we can't solve, but it is not okay to break the kernel build. >> >> Should I just make CONFIG_BUILD_DOCSRC depend on CROSS_COMPILE=""? >> I'm not sure how much value would be added by implementing targetprogs >> in kbuild, simply to increase build testing of Documentation/ > > Yes, IMO. Let the kselftest people solve it, because they might have > extra requirements. > > --Andy As I have said in the past, there are probably lots of source files in Documentation/ that should be in tools/ or tools/testing/ instead. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: of: Lower the severity of the error with no container
On Wed, Oct 08, 2014 at 05:05:55PM -0700, Guenter Roeck wrote: > On Thu, Oct 09, 2014 at 12:45:41AM +0100, Mark Brown wrote: > > definitely at least add a boot argument or something to suppress them, > > let me have a think if we want to do that by default. > It is a nuisance, so I might just disable it in our tree if we don't > find some other solution. We'll do something, just a question of what and what the default is. > Did you notice the problem with debugfs I had mentioned earlier ? > With all those regulators, not all of them being used, I end up with > many having the same name. This causes issues with debugfs, which is > trying to create the same file several times. > Any idea how we could solve this ? The constraints message is annoying, > but this one is a real issue. Shove a dev_name() on the front if we get a collision? I have to say I've never cared, the debugfs isn't that important so it doesn't matter too much if it fails. signature.asc Description: Digital signature
Re: [PATCH] regulator: of: Lower the severity of the error with no container
On Thu, Oct 09, 2014 at 12:45:41AM +0100, Mark Brown wrote: > On Wed, Oct 08, 2014 at 03:59:12PM -0700, Guenter Roeck wrote: > > > There is a log message "no parameters" for each regulator. This is printed > > unconditionally from print_constraints(). > > > Looking through the code again, looks like this is on purpose. It is just a > > bit > > annoying to get lots of those messages. One of the systems I am dealing > > with has > > 17 LTC2978 chips in it, with 8 channels each. That results in 136 times "no > > parameters" in the boot log. And that is not even a fully populated system; > > if fully populated, there can be more than 60 of those chips. 500+ lines of > > similar log messages is really a bit on the high side. > > > It might help if there was a way to silence the messages, ie to make > > "print_constraints" optional. > > Ah, from the constraints rather than from the DT parsing. I do like > having it there since it's enormously helpful in debugging and that is > a... specialist number of regulators you have in your system. We can Yes, this is a pretty large backbone switch. Kind of amazing how many sensors are in those systems. > definitely at least add a boot argument or something to suppress them, > let me have a think if we want to do that by default. It is a nuisance, so I might just disable it in our tree if we don't find some other solution. Did you notice the problem with debugfs I had mentioned earlier ? With all those regulators, not all of them being used, I end up with many having the same name. This causes issues with debugfs, which is trying to create the same file several times. Any idea how we could solve this ? The constraints message is annoying, but this one is a real issue. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] allow cpufreq drivers to export flags
Quoting Viresh Kumar (2014-10-08 01:19:40) > On 8 October 2014 13:41, Thomas Petazzoni > wrote: > > On Wed, 8 Oct 2014 13:24:30 +0530, Viresh Kumar wrote: > >> On 8 October 2014 13:18, Mike Turquette wrote: > > >> > This series is partially in response to a discussion around DT bindings > >> > for CPUfreq drivers [0], but it is also needed for on-going work to > >> > integrate CPUfreq with the scheduler. In particular a scheduler-driven > > > Well, when one has to merge a large number of changes, we often > > recommend to merge them piece by piece, which is what Mike is trying to > > do here. So we cannot at the same time ask developers to merge things > > in small pieces that are easy to review and to merge everything > > together because the users of a given API are not there yet. > > From the wording of Mike it looks like: > - This is required by cpufreq drivers - today > - And this will also be useful for scheduler Hi Viresh and Thomas, Apologies if my wording was confusing. Without getting into a grammar war, I did say that these patches were "in response" to this thread (entirely accurate) and only necessary for the "on-going work" I'm doing with the scheduler. Sorry if any of that came across as me stating that these patches were necessary to solve Thomas' problem. > > The first point doesn't stand true anymore. Lets wait for Mike's reply and > see his opinion. > > And then the patches are so small and there are no objections against > them. I don't think getting them with the scheduler changes is that bad > of an idea. In worst case, what if he has to redesign his idea? The new > routines will stay without a caller then :) Whether you merge the patches now or later is fine by me. I prefer to get my patches out early and often so I can avoid any surprises later on. If you have a fundamental objection to these patches then please let me know. Otherwise it would be wonderful to have an Ack. Thanks! Mike > > -- > viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
md/raid allows metadata management to be performed in user-space.
A various times, particularly on device failure, the metadata needs
to be updated before further writes can be permitted.
This means that the user-space program which updates metadata much
not block on writeout, and so must not allocate memory.
mlockall(MCL_CURRENT|MCL_FUTURE) and pre-allocation can avoid all
memory allocation issues for user-memory, but that does not help
kernel memory.
Several kernel objects can be pre-allocated. e.g. files opened before
any writes to the array are permitted.
However some kernel allocation happens in places that cannot be
pre-allocated.
In particular, writes to sysfs files (to tell md that it can now
allow writes to the array) allocate a buffer using GFP_KERNEL.
This patch allows attributes to be marked as "PREALLOC". In that case
the maximal buffer is allocated when the file is opened, and then used
on each write instead of allocating a new buffer.
As the same buffer is now shared for all writes on the same file
description, the mutex is extended to cover full use of the buffer
including the copy_from_user().
The new __ATTR_PREALLOC() 'or's a new flag in to the 'mode', which is
inspected by sysfs_add_file_mode_ns() to determine if the file should be
marked as requiring prealloc.
Signed-off-by: NeilBrown
---
fs/kernfs/file.c | 44 +---
fs/sysfs/file.c| 31 ---
include/linux/kernfs.h |2 ++
include/linux/sysfs.h |9 +
4 files changed, 64 insertions(+), 22 deletions(-)
diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 4429d6d9217f..137c172bccc5 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -106,7 +106,7 @@ static void *kernfs_seq_start(struct seq_file *sf, loff_t
*ppos)
const struct kernfs_ops *ops;
/*
-* @of->mutex nests outside active ref and is just to ensure that
+* @of->mutex nests outside active ref and is primarily to ensure that
* the ops aren't called concurrently for the same open file.
*/
mutex_lock(>mutex);
@@ -194,7 +194,7 @@ static ssize_t kernfs_file_direct_read(struct
kernfs_open_file *of,
return -ENOMEM;
/*
-* @of->mutex nests outside active ref and is just to ensure that
+* @of->mutex nests outside active ref and is primarily to ensure that
* the ops aren't called concurrently for the same open file.
*/
mutex_lock(>mutex);
@@ -278,19 +278,16 @@ static ssize_t kernfs_fop_write(struct file *file, const
char __user *user_buf,
len = min_t(size_t, count, PAGE_SIZE);
}
- buf = kmalloc(len + 1, GFP_KERNEL);
+ buf = of->prealloc_buf;
+ if (!buf)
+ buf = kmalloc(len + 1, GFP_KERNEL);
if (!buf)
return -ENOMEM;
- if (copy_from_user(buf, user_buf, len)) {
- len = -EFAULT;
- goto out_free;
- }
- buf[len] = '\0';/* guarantee string termination */
-
/*
-* @of->mutex nests outside active ref and is just to ensure that
-* the ops aren't called concurrently for the same open file.
+* @of->mutex nests outside active ref and is used both to ensure that
+* the ops aren't called concurrently for the same open file, and
+* to provide exclusive access to ->prealloc_buf (when that exists).
*/
mutex_lock(>mutex);
if (!kernfs_get_active(of->kn)) {
@@ -299,19 +296,27 @@ static ssize_t kernfs_fop_write(struct file *file, const
char __user *user_buf,
goto out_free;
}
+ if (copy_from_user(buf, user_buf, len)) {
+ len = -EFAULT;
+ goto out_unlock;
+ }
+ buf[len] = '\0';/* guarantee string termination */
+
ops = kernfs_ops(of->kn);
if (ops->write)
len = ops->write(of, buf, len, *ppos);
else
len = -EINVAL;
- kernfs_put_active(of->kn);
- mutex_unlock(>mutex);
-
if (len > 0)
*ppos += len;
+
+out_unlock:
+ kernfs_put_active(of->kn);
+ mutex_unlock(>mutex);
out_free:
- kfree(buf);
+ if (buf != of->prealloc_buf)
+ kfree(buf);
return len;
}
@@ -685,6 +690,13 @@ static int kernfs_fop_open(struct inode *inode, struct
file *file)
*/
of->atomic_write_len = ops->atomic_write_len;
+ if (ops->prealloc) {
+ int len = of->atomic_write_len ?: PAGE_SIZE;
+ of->prealloc_buf = kmalloc(len + 1, GFP_KERNEL);
+ error = -ENOMEM;
+ if (!of->prealloc_buf)
+ goto err_free;
+ }
/*
* Always instantiate seq_file even if read access doesn't use
* seq_file or is not requested. This unifies private data access
@@ -715,6 +727,7 @@ static
[PATCH 2/2] sysfs/kernfs: make read requests on pre-alloc files use the buffer.
To match the previous patch which used the pre-alloc buffer for
writes, this patch causes reads to use the same buffer.
This is not strictly necessary as the current seq_read() will allocate
on first read, so user-space can trigger the required pre-alloc. But
consistency is valuable.
The read function is somewhat simpler than seq_read() and, for example,
does not support reading from an offset into the file: reads must be
at the start of the file.
As seq_read() does not use the prealloc buffer, ->seq_show is
incompatible with ->prealloc and caused an EINVAL return from open().
sysfs code which calls into kernfs always chooses the correct function.
As the buffer is shared with writes and other reads, the mutex is
extended to cover the copy_to_user.
Signed-off-by: NeilBrown
---
fs/kernfs/file.c | 28 +++-
fs/sysfs/file.c | 31 +++
2 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 137c172bccc5..e055c6a01495 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -189,13 +189,16 @@ static ssize_t kernfs_file_direct_read(struct
kernfs_open_file *of,
const struct kernfs_ops *ops;
char *buf;
- buf = kmalloc(len, GFP_KERNEL);
+ buf = of->prealloc_buf;
+ if (!buf)
+ buf = kmalloc(len, GFP_KERNEL);
if (!buf)
return -ENOMEM;
/*
-* @of->mutex nests outside active ref and is primarily to ensure that
-* the ops aren't called concurrently for the same open file.
+* @of->mutex nests outside active ref and is used both to ensure that
+* the ops aren't called concurrently for the same open file, and
+* to provide exclusive access to ->prealloc_buf (when that exists).
*/
mutex_lock(>mutex);
if (!kernfs_get_active(of->kn)) {
@@ -210,21 +213,22 @@ static ssize_t kernfs_file_direct_read(struct
kernfs_open_file *of,
else
len = -EINVAL;
- kernfs_put_active(of->kn);
- mutex_unlock(>mutex);
-
if (len < 0)
- goto out_free;
+ goto out_unlock;
if (copy_to_user(user_buf, buf, len)) {
len = -EFAULT;
- goto out_free;
+ goto out_unlock;
}
*ppos += len;
+ out_unlock:
+ kernfs_put_active(of->kn);
+ mutex_unlock(>mutex);
out_free:
- kfree(buf);
+ if (buf != of->prealloc_buf)
+ kfree(buf);
return len;
}
@@ -690,6 +694,12 @@ static int kernfs_fop_open(struct inode *inode, struct
file *file)
*/
of->atomic_write_len = ops->atomic_write_len;
+ error = -EINVAL;
+ if (ops->prealloc && ops->seq_show)
+ /* ->seq_show is incompatible with ->prealloc,
+* ->read must be used instead.
+*/
+ goto err_free;
if (ops->prealloc) {
int len = of->atomic_write_len ?: PAGE_SIZE;
of->prealloc_buf = kmalloc(len + 1, GFP_KERNEL);
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 4a959d231b43..0b02cc515273 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -102,6 +102,21 @@ static ssize_t sysfs_kf_bin_read(struct kernfs_open_file
*of, char *buf,
return battr->read(of->file, kobj, battr, buf, pos, count);
}
+/* kernfs read callback for regular sysfs files with pre-alloc */
+static ssize_t sysfs_kf_read(struct kernfs_open_file *of, char *buf,
+size_t count, loff_t pos)
+{
+ const struct sysfs_ops *ops = sysfs_file_ops(of->kn);
+ struct kobject *kobj = of->kn->parent->priv;
+
+ if (pos || buf != of->prealloc_buf)
+ /* If buf != of->prealloc_buf, we don't know how
+ * large it is, so cannot safely pass it to ->show
+ */
+ return 0;
+ return ops->show(kobj, of->kn->priv, buf);
+}
+
/* kernfs write callback for regular sysfs files */
static ssize_t sysfs_kf_write(struct kernfs_open_file *of, char *buf,
size_t count, loff_t pos)
@@ -184,13 +199,18 @@ static const struct kernfs_ops sysfs_file_kfops_rw = {
.write = sysfs_kf_write,
};
+static const struct kernfs_ops sysfs_prealloc_kfops_ro = {
+ .read = sysfs_kf_read,
+ .prealloc = true,
+};
+
static const struct kernfs_ops sysfs_prealloc_kfops_wo = {
.write = sysfs_kf_write,
.prealloc = true,
};
static const struct kernfs_ops sysfs_prealloc_kfops_rw = {
- .seq_show = sysfs_kf_seq_show,
+ .read = sysfs_kf_read,
.write = sysfs_kf_write,
.prealloc = true,
};
@@ -238,9 +258,12 @@ int sysfs_add_file_mode_ns(struct kernfs_node *parent,
ops = _prealloc_kfops_rw;
else
[PATCH 0/2 V2] Allow access to sysfs attributes without mem allocations.
Hi Tejun, thanks for the review. This version incorporates your suggestions. You are certainly right about there being issues deeper than just the sysfs/kernfs level - I've been cleaning up the locking in md to avoid the "reconfig_mutex" as much as possible. It is something that has been at the back of my mind for a while, but this need has pushed it to the fore-front. All the attributes that mdmon needs to touch will soon only take a spinlock or nothing. On the topic of inadvertently locking in semantics, I noticed that prior to kernfs, sysfs would allocate a buffer on first read or write, and continue to use that buffer. I could try to argue that I was using those semantics, which have now changed ... though I wasn't doing it consciously... Certainly this is a thorny issue. As well as checking that ->seq_show isn't used with ->prealloc, I've also made sure that sysfs_kf_read() doesn't call the attribute ->show() function unless it is certain it has a preallocated (and hence >= PAGE_SIZE) buffer. Thanks, NeilBrown --- NeilBrown (2): sysfs/kernfs: allow attributes to request write buffer be pre-allocated. sysfs/kernfs: make read requests on pre-alloc files use the buffer. fs/kernfs/file.c | 70 fs/sysfs/file.c| 53 +++- include/linux/kernfs.h |2 + include/linux/sysfs.h |9 ++ 4 files changed, 103 insertions(+), 31 deletions(-) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: status of the logfs tree?
Hi all, The top commit in the logfs tree was committed in November 2012. Is there any intention to ask Linus to merge this tree? Or should I just drop it completely? It is a pain because it takes considerable time for git to actually merge it. $ git log --oneline origin/master..logfs/master 339466142b3f Fix the call to BUG() caused by no free segment found ab2ec19f42dc logfs: fix possible memory leak in logfs_mtd_can_write_buf() $ git diff --stat origin/master...logfs/master fs/logfs/dev_mtd.c | 2 +- fs/logfs/super.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500
On Tue, 2014-10-07 at 22:08 -0500, Jia Hongtao-B38951 wrote:
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, September 30, 2014 2:36 AM
> > To: Guenter Roeck
> > Cc: Benjamin Herrenschmidt; Paul Mackerras; Michael Ellerman; linuxppc-
> > d...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Jojy G Varghese;
> > Guenter Roeck; Jia Hongtao-B38951
> > Subject: Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check
> > exception on E500MC / E5500
> >
> > On Mon, 2014-09-29 at 09:48 -0700, Guenter Roeck wrote:
> > > From: Jojy G Varghese
> > >
> > > For E500MC and E5500, a machine check exception in pci(e) memory space
> > > crashes the kernel.
> > >
> > > Testing shows that the MCAR(U) register is zero on a MC exception for
> > > the
> > > E5500 core. At the same time, DEAR register has been found to have the
> > > address of the faulty load address during an MC exception for this core.
> > >
> > > This fix changes the current behavior to fixup the result register and
> > > instruction pointers in the case of a load operation on a faulty PCI
> > > address.
> > >
> > > The changes are:
> > > - Added the hook to pci machine check handing to the e500mc machine
> > check
> > > exception handler.
> > > - For the E5500 core, load faulting address from SPRN_DEAR register.
> > > As mentioned above, this is necessary because the E5500 core does not
> > > report the fault address in the MCAR register.
> > >
> > > Cc: Scott Wood
> > > Signed-off-by: Jojy G Varghese [Guenter Roeck:
> > > updated description]
> > > Signed-off-by: Guenter Roeck
> > > Signed-off-by: Guenter Roeck
> > > ---
> > > arch/powerpc/kernel/traps.c | 3 ++-
> > > arch/powerpc/sysdev/fsl_pci.c | 5 +
> > > 2 files changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> > > index 0dc43f9..ecb709b 100644
> > > --- a/arch/powerpc/kernel/traps.c
> > > +++ b/arch/powerpc/kernel/traps.c
> > > @@ -494,7 +494,8 @@ int machine_check_e500mc(struct pt_regs *regs)
> > > int recoverable = 1;
> > >
> > > if (reason & MCSR_LD) {
> > > - recoverable = fsl_rio_mcheck_exception(regs);
> > > + recoverable = fsl_rio_mcheck_exception(regs) ||
> > > + fsl_pci_mcheck_exception(regs);
> > > if (recoverable == 1)
> > > goto silent_out;
> > > }
> > > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > > b/arch/powerpc/sysdev/fsl_pci.c index c507767..bdb956b 100644
> > > --- a/arch/powerpc/sysdev/fsl_pci.c
> > > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > > @@ -1021,6 +1021,11 @@ int fsl_pci_mcheck_exception(struct pt_regs
> > > *regs) #endif
> > > addr += mfspr(SPRN_MCAR);
> > >
> > > +#ifdef CONFIG_E5500_CPU
> > > + if (mfspr(SPRN_EPCR) & SPRN_EPCR_ICM)
> > > + addr = PFN_PHYS(vmalloc_to_pfn((void *)mfspr(SPRN_DEAR)));
> > #endif
> >
> > Kconfig tells you what hardware is supported, not what hardware you're
> > actually running on.
> >
> > Jia Hongtao, do you know anything about this issue? Is there an erratum?
>
> Sorry for the late response, I just return from my vacation.
> I don't know this issue.
>
> > What chips are affected by the the erratum covered by
> >
Re: Tightening up rdpmc permissions?
On Mon, Sep 29, 2014 at 11:42 AM, Andy Lutomirski wrote: > On Sep 29, 2014 10:36 AM, wrote: >> >> On Mon, 29 Sep 2014 09:39:16 -0700, Andy Lutomirski said: >> >> > Would it make sense to restrict rdpmc to tasks that are in mms that >> > have a perf_event mapping? After all, unless I misunderstand >> > something, user code can't reliably use rdpmc unless they've mapped a >> > perf_event object to check the rdpmc bit and figure out what ecx value >> > to use. >> >> Wouldn't that be trivially easy for an attacker to bypass? Just map a dummy >> perf_event object and then go to town? > > Depends on the paranoia setting. We could require that the mapped > object actually have an rdpmc-able counter running. > > Seccomp can (and often does) block access to perf_event_open entirely. > We could certainly change the code to only twiddle CR4 if TIF_SECCOMP > or TIF_NOTSC is set. I think that the real thing we should optimize > for is to minimize the chance that a given context switch actually > needs to *change* cr4. Since perf_event maps are relatively unusual, > at least only perf-using programs would have overhead if we just gated > it on the existence of a useful rdpmc-able mapping. > > (Also, why on earth is TIF_NOTSC a thread_info flag? Wouldn't just > adding a field "cr4" to task_struct or something be simpler and quite > possibly faster? We have a branch anyway...) I have a prototype patch that seems to work and should have relatively little overhead. I'll send it either when the merge window closes or when some pending dependencies get resolved. --Andy > > --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter
On Wed, Oct 8, 2014 at 12:18 AM, Alexandre Courbot wrote:
> On Wed, Oct 8, 2014 at 4:09 PM, Muthu Mani wrote:
>>> -Original Message-
>>> From: Alexandre Courbot [mailto:gnu...@gmail.com]
>>> Sent: Tuesday, October 07, 2014 3:34 PM
>>> To: Muthu Mani
>>> Cc: Samuel Ortiz; Lee Jones; Wolfram Sang; Linus Walleij; Greg Kroah-
>>> Hartman; linux-...@vger.kernel.org; linux-g...@vger.kernel.org; linux-
>>> u...@vger.kernel.org; Linux Kernel Mailing List; Rajaram Regupathy; Johan
>>> Hovold
>>> Subject: Re: [PATCH v3 3/3] gpio: add support for Cypress CYUSBS234 USB-
>>> GPIO adapter
>>>
>>> On Mon, Oct 6, 2014 at 11:47 PM, Muthu Mani wrote:
>>> > +
>>> > +static int cy_gpio_direction_input(struct gpio_chip *chip,
>>> > + unsigned offset) {
>>> > + return 0;
>>> > +}
>>> > +
>>> > +static int cy_gpio_direction_output(struct gpio_chip *chip,
>>> > + unsigned offset, int value) {
>>> > + return 0;
>>> > +}
>>>
>>> If that chip is capable of both output and input, shouldn't these functions
>>> be
>>> implemented? I think this has already been pointed out in a previous version
>>> but you did not reply.
>>
>> Thanks for your inputs.
>>
>> Only the GPIOs which are configured to be output GPIO can be set.
>
> In that case cy_gpio_set() should return an error for GPIOs which are
> not configured as outputs. Is that guaranteed by the current
> implementation?
>
>> The set operation would fail trying to set the input or unconfigured GPIOs.
>> In this version of driver, this support is not added, it can be introduced
>> in future versions.
>> I will add a TODO note in the code.
>
> Argh, no TODO please. Actual code that will turn this code into a
> solid driver that can be merged.
Does a driver targeted for a custom device has to implement every
functionality in the 1st version ? My understanding is that Linux
follows incremental model and allows incremental merge.
(On a side note the driver is functionally verified with the necessary hardware)
Please correct me if I am missing something
>
> Can all GPIOs be set as input or output? If so, please implement
> cy_gpio_direction_*() and make sure that cy_gpio_set() behaves
> properly if a GPIO is not an output. If the input/output GPIOs are
> fixed, please make cy_gpio_direction_*() return an error if the GPIO
> capabilities does not correspond to what is asked, and again ensure
> that cy_gpio_set() works as expected.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: of: Lower the severity of the error with no container
On Wed, Oct 08, 2014 at 03:59:12PM -0700, Guenter Roeck wrote: > There is a log message "no parameters" for each regulator. This is printed > unconditionally from print_constraints(). > Looking through the code again, looks like this is on purpose. It is just a > bit > annoying to get lots of those messages. One of the systems I am dealing with > has > 17 LTC2978 chips in it, with 8 channels each. That results in 136 times "no > parameters" in the boot log. And that is not even a fully populated system; > if fully populated, there can be more than 60 of those chips. 500+ lines of > similar log messages is really a bit on the high side. > It might help if there was a way to silence the messages, ie to make > "print_constraints" optional. Ah, from the constraints rather than from the DT parsing. I do like having it there since it's enormously helpful in debugging and that is a... specialist number of regulators you have in your system. We can definitely at least add a boot argument or something to suppress them, let me have a think if we want to do that by default. signature.asc Description: Digital signature
Re: [PATCH] [RFC] mnt: add ability to clone mntns starting with the current root
On Wed, Oct 8, 2014 at 4:38 PM, Serge Hallyn wrote: > Quoting Andy Lutomirski (l...@amacapital.net): >> On Wed, Oct 8, 2014 at 2:36 PM, Rob Landley wrote: >> > On 10/08/14 14:31, Andy Lutomirski wrote: >> >> On Wed, Oct 8, 2014 at 12:23 PM, Eric W. Biederman >> >> wrote: >> >>> Andy Lutomirski writes: >> > Maybe we want to say that rootfs should not be used if we are going to >> > create containers... >> >>> >> >>> Today it is an assumption of the vfs that rootfs is mounted. With >> >>> rootfs mounted and pivot_root at the base of the mount stack you can >> >>> make as minimal of a set of mounts as the vfs allows. >> >>> >> >>> Removing rootfs from the vfs requires an audit of everything that >> >>> manipulates mounts. It is not remotely a local excercise. >> >> >> >> Would it be a less invasive audit to allow different mount namespaces >> >> to have different rootfses? >> > >> > I.E. The same way different namespaces have different init tasks? >> > >> > The abstraction containers has implemented here should be logically >> > consistent. >> > >> Could we have an extra rootfs-like fs that is always completely empty, >> doesn't allow any writes, and can sit at the bottom of container >> namespace hierarchies? If so, and if we add a new syscall that's like >> pivot_root (or unshare) but prunes the hierarchy, then we could switch >> to that rootfs then. >> >>> >> >>> Or equally have something that guarantees that rootfs is empty and >> >>> read-only at the time the normal root filesystem is mounted. That is >> >>> certainly a much more localized change if we want to go there. >> >>> >> >>> I am half tempted to suggest that mount --move /some/path / be updated >> >>> to make the old / just go away (perhaps to be replaced with a read-only >> >>> empty rootfs). That gets us into figuring out if we break userspace >> >>> which is a big challenge. >> >> >> >> Hence my argument for a new syscall or entirely new operation. >> > >> > I'm still waiting for somebody to explain to my why chroot() shouldn't >> > be changed to do this instead of adding a new syscall. (At least when >> > mount namespace support is enabled.) >> >> Because chroot has no effect on the namespace at all. If you fork and >> the child chroots, the parent isn't chrooted. And, more importantly >> for my example, is a process has it's cwd as /foo, and then it forks >> and the child chroots, then parent's ".." isn't changed as a result of >> the chroot. >> >> > >> >> mount(2) and friends are way too multiplexed right now. I just found >> >> yet another security bug due to the insanely complicated semantics of >> >> the vfs syscalls. (Yes, a different one from the one yesterday.) >> > >> > As the guy who rewrote busybox mount 3 times, and who just implemented a >> > brand new one (toybox) from scratch: >> > >> > It's a bit fiddly, yes. >> > >> >> A new operation kills several birds with one stone. It could look like: >> >> >> >> int mntns_change_root(int dfd, const char *path, int flags); >> >> >> >> return -EPERM if chrooted. >> > >> > Really? >> >> Now that CVE-2014-7970 is public: what the heck is pivot_root supposed >> to do if the caller is chrooted? The current behavior is obviously >> incorrect (it leaks memory), but it's not entirely clear to me what >> should happen. I think it should either be disallowed or should have >> well-defined semantics. >> >> For simplicity, if a new syscall for this is added, then I think that >> the caller-is-chrooted case should be disallowed. If someone needs it >> and can articulate what the semantics should be, then I have no >> problem with allowing it going forward. > > It's not that I'd have a need for that, but rather if for some > reason I started out chrooted due to some bogus initramfs, I'd > prefer to not have to feel like a criminial and escape the chroot > first. You already can't create a userns if you're chrooted (even if you have global privilege). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] hwmon updates for v3.18
Hi Linus, Please pull hwmon updates for Linux v3.18 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v3.18 Thanks, Guenter -- The following changes since commit 4e66cd13ff9cd7eaae69e2fae0335d8d99d8afdf: hwmon: (tmp103) Fix resource leak bug in tmp103 temperature sensor driver (2014-09-22 11:11:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/hwmon-for-linus-v3.18 for you to fetch changes up to 3afb57fa721f94206e642f8fda51f5a89dda3dfb: hwmon: (ab8500) Call kernel_power_off instead of pm_power_off (2014-10-03 08:19:02 -0700) New driver for menf21bmc. Convert k10temp, smsc47b397, da9052, da9055 to new hwmon API. Register ntc_thermistor driver with thermal subsystem. Add support for F15h M60h to k10temp driver. Add driver for MEN14F021P00 BMC HWMON driver; this required a merge with tag mfd-hwmon-leds-watchdog-v3.18. Andreas Werner (4): mfd: menf21bmc: Introduce MEN 14F021P00 BMC MFD Core driver watchdog: menf21bmc_wdt: Introduce MEN 14F021P00 BMC Watchdog driver leds: leds-menf21bmc: Introduce MEN 14F021P00 BMC LED driver hwmon: (menf21bmc) Introduce MEN14F021P00 BMC HWMON driver Aravind Gopalakrishnan (1): hwmon: (k10temp) Add support for F15h M60h Axel Lin (4): hwmon: (ads1015) Use of_property_read_u32 at appropriate places hwmon: (da9055) Convert to devm_hwmon_device_register_with_groups hwmon: (da9052) Convert to devm_hwmon_device_register_with_groups hwmon: (smsc47b397) Convert to devm_hwmon_device_register_with_groups Guenter Roeck (3): hwmon: (k10temp) Convert to devm_hwmon_device_register_with_groups Merge tag 'mfd-hwmon-leds-watchdog-v3.18' into hwmon-next hwmon: (ab8500) Call kernel_power_off instead of pm_power_off Jonghwa Lee (1): hwmon: (ntc_thermistor) Add ntc thermistor to thermal subsystem as a sensor. Kamil Debski (1): MAINTAINERS: add entry for the PWM fan driver .../devicetree/bindings/hwmon/ntc_thermistor.txt | 3 + Documentation/hwmon/k10temp| 2 +- Documentation/hwmon/menf21bmc | 50 + MAINTAINERS| 8 + drivers/hwmon/Kconfig | 15 +- drivers/hwmon/Makefile | 1 + drivers/hwmon/ab8500.c | 5 +- drivers/hwmon/ads1015.c| 21 +- drivers/hwmon/da9052-hwmon.c | 54 + drivers/hwmon/da9055-hwmon.c | 52 + drivers/hwmon/k10temp.c| 157 +++--- drivers/hwmon/menf21bmc_hwmon.c| 230 + drivers/hwmon/ntc_thermistor.c | 25 +++ drivers/hwmon/smsc47b397.c | 51 + drivers/leds/Kconfig | 9 + drivers/leds/Makefile | 1 + drivers/leds/leds-menf21bmc.c | 131 drivers/mfd/Kconfig| 15 ++ drivers/mfd/Makefile | 1 + drivers/mfd/menf21bmc.c| 132 drivers/watchdog/Kconfig | 10 + drivers/watchdog/Makefile | 1 + drivers/watchdog/menf21bmc_wdt.c | 203 ++ 23 files changed, 949 insertions(+), 228 deletions(-) create mode 100644 Documentation/hwmon/menf21bmc create mode 100644 drivers/hwmon/menf21bmc_hwmon.c create mode 100644 drivers/leds/leds-menf21bmc.c create mode 100644 drivers/mfd/menf21bmc.c create mode 100644 drivers/watchdog/menf21bmc_wdt.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] mnt: add ability to clone mntns starting with the current root
Quoting Andy Lutomirski (l...@amacapital.net): > On Wed, Oct 8, 2014 at 2:36 PM, Rob Landley wrote: > > On 10/08/14 14:31, Andy Lutomirski wrote: > >> On Wed, Oct 8, 2014 at 12:23 PM, Eric W. Biederman > >> wrote: > >>> Andy Lutomirski writes: > > Maybe we want to say that rootfs should not be used if we are going to > > create containers... > >>> > >>> Today it is an assumption of the vfs that rootfs is mounted. With > >>> rootfs mounted and pivot_root at the base of the mount stack you can > >>> make as minimal of a set of mounts as the vfs allows. > >>> > >>> Removing rootfs from the vfs requires an audit of everything that > >>> manipulates mounts. It is not remotely a local excercise. > >> > >> Would it be a less invasive audit to allow different mount namespaces > >> to have different rootfses? > > > > I.E. The same way different namespaces have different init tasks? > > > > The abstraction containers has implemented here should be logically > > consistent. > > > Could we have an extra rootfs-like fs that is always completely empty, > doesn't allow any writes, and can sit at the bottom of container > namespace hierarchies? If so, and if we add a new syscall that's like > pivot_root (or unshare) but prunes the hierarchy, then we could switch > to that rootfs then. > >>> > >>> Or equally have something that guarantees that rootfs is empty and > >>> read-only at the time the normal root filesystem is mounted. That is > >>> certainly a much more localized change if we want to go there. > >>> > >>> I am half tempted to suggest that mount --move /some/path / be updated > >>> to make the old / just go away (perhaps to be replaced with a read-only > >>> empty rootfs). That gets us into figuring out if we break userspace > >>> which is a big challenge. > >> > >> Hence my argument for a new syscall or entirely new operation. > > > > I'm still waiting for somebody to explain to my why chroot() shouldn't > > be changed to do this instead of adding a new syscall. (At least when > > mount namespace support is enabled.) > > Because chroot has no effect on the namespace at all. If you fork and > the child chroots, the parent isn't chrooted. And, more importantly > for my example, is a process has it's cwd as /foo, and then it forks > and the child chroots, then parent's ".." isn't changed as a result of > the chroot. > > > > >> mount(2) and friends are way too multiplexed right now. I just found > >> yet another security bug due to the insanely complicated semantics of > >> the vfs syscalls. (Yes, a different one from the one yesterday.) > > > > As the guy who rewrote busybox mount 3 times, and who just implemented a > > brand new one (toybox) from scratch: > > > > It's a bit fiddly, yes. > > > >> A new operation kills several birds with one stone. It could look like: > >> > >> int mntns_change_root(int dfd, const char *path, int flags); > >> > >> return -EPERM if chrooted. > > > > Really? > > Now that CVE-2014-7970 is public: what the heck is pivot_root supposed > to do if the caller is chrooted? The current behavior is obviously > incorrect (it leaks memory), but it's not entirely clear to me what > should happen. I think it should either be disallowed or should have > well-defined semantics. > > For simplicity, if a new syscall for this is added, then I think that > the caller-is-chrooted case should be disallowed. If someone needs it > and can articulate what the semantics should be, then I have no > problem with allowing it going forward. It's not that I'd have a need for that, but rather if for some reason I started out chrooted due to some bogus initramfs, I'd prefer to not have to feel like a criminial and escape the chroot first. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Only build Documentation/ when not cross-compiling
Don't build Documentation targets when cross-compiling. They are only for build testing, and use the host headers and compiler which can cause cross-compiles to fail. Signed-off-by: Peter Foley --- lib/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index a285900..1beeb84 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1610,7 +1610,7 @@ config PROVIDE_OHCI1394_DMA_INIT config BUILD_DOCSRC bool "Build targets in Documentation/ tree" - depends on HEADERS_CHECK + depends on HEADERS_CHECK && CROSS_COMPILE="" help This option attempts to build objects from the source files in the kernel Documentation/ tree. -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] serial_core: Handle TIOC[GS]RS485 ioctls.
On Wed, 2014-10-08 at 22:43 +0200, Ricardo Ribalda Delgado wrote: > Hello Alan > > This patchset adds no extra locking features, if the drivers did not > implement a locking mechanism (and none did) there is chance of > conflict. > > I can add a call to lock/unlock around uart_[gs]et_rs485_config. And > then, inside the drivers, use the lock when the structure is used. > > I would prefer to add it as new patches in the patchset, so in case > this adds some bugs they can be bisected easily. Makes sense. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] restart handler infrastructure
Hi Linus, this series was supposed to be pulled through various trees using it, and I did not plan to send a separate pull request. As it turns out, the pinctrl tree did not merge with it, is now upstream, and uses it, meaning there are now build failures. Please consider pulling this series directly to fix those build failures. If you don't want to pull it directly, you should also get it through the clk, power/reboot, and watchdog pull requests. Thanks, Guenter -- The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef: Linux 3.17-rc2 (2014-08-25 15:36:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/restart-handler-for-v3.18 for you to fetch changes up to 6cd6d94d96d9b1cd8a62da91aac44cf56e301e75: arm/arm64: unexport restart handlers (2014-09-26 00:00:48 -0700) Immutable branch with restart handler patches for v3.18 Guenter Roeck (8): kernel: add support for kernel restart handler call chain power/restart: call machine_restart instead of arm_pm_restart arm64: support restart through restart handler call chain arm: support restart through restart handler call chain watchdog: moxart: register restart handler with kernel restart handler watchdog: alim7101: register restart handler with kernel restart handler watchdog: sunxi: register restart handler with kernel restart handler arm/arm64: unexport restart handlers arch/arm/kernel/process.c | 12 +++-- arch/arm64/kernel/process.c| 3 +- drivers/power/reset/restart-poweroff.c | 3 +- drivers/watchdog/alim7101_wdt.c| 42 +- drivers/watchdog/moxart_wdt.c | 32 +- drivers/watchdog/sunxi_wdt.c | 31 - include/linux/reboot.h | 3 ++ kernel/reboot.c| 81 ++ 8 files changed, 165 insertions(+), 42 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] New Mailbox framework for 3.18
On 10/08/2014 12:39 AM, Jassi Brar wrote:
> Hi Linus,
>
> A framework for Mailbox controllers and clients have been cooking for
> more than a year now. Everybody in the CC list had been copied on
> patchset revisions and most of them have made sounds of approval,
> though just one concrete Reviewed-by. The patchset has also been in
> linux-next for a couple of weeks now and no conflict has been
> reported. The framework has the backing of at least 5 platforms,
> though I can't say if/when they upstream their drivers (some
> businesses have 'changed').
Thanks Jassi. OMAP is ready, and because of merge order dependencies is
held back. We should be able to have the framework adaptation merged on
the next kernel version once this is in.
regards
Suman
>
>
> The following changes since commit 9a50aaefc1b896e734bf7faf3d085f71a360ce97:
>
> Merge tag 'scsi-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2014-10-07
> 21:29:18 -0400)
>
> are available in the git repository at:
>
>
> git://git.linaro.org/landing-teams/working/fujitsu/integration.git
> mailbox-for-linus
>
> for you to fetch changes up to 9f3e3cacb2ffdefe28c7cf490bf543e4dcb2770a:
>
> dt: mailbox: add generic bindings (2014-10-08 10:39:42 +0530)
>
>
> Jassi Brar (3):
> mailbox: Introduce framework for mailbox
> doc: add documentation for mailbox framework
> dt: mailbox: add generic bindings
>
> Suman Anna (1):
> mailbox: rename pl320-ipc specific mailbox.h
>
> .../devicetree/bindings/mailbox/mailbox.txt| 38 ++
> Documentation/mailbox.txt | 122 ++
> MAINTAINERS| 8 +
> arch/arm/mach-highbank/highbank.c | 2 +-
> drivers/cpufreq/highbank-cpufreq.c | 2 +-
> drivers/mailbox/Makefile | 4 +
> drivers/mailbox/mailbox.c | 465
> +
> drivers/mailbox/pl320-ipc.c| 2 +-
> include/linux/mailbox_client.h | 46 ++
> include/linux/mailbox_controller.h | 133 ++
> include/linux/{mailbox.h => pl320-ipc.h} | 0
> 11 files changed, 819 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mailbox.txt
> create mode 100644 Documentation/mailbox.txt
> create mode 100644 drivers/mailbox/mailbox.c
> create mode 100644 include/linux/mailbox_client.h
> create mode 100644 include/linux/mailbox_controller.h
> rename include/linux/{mailbox.h => pl320-ipc.h} (100%)
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vdso_standalone_test_x86.c build failure on Linus' tree
On Wed, Oct 8, 2014 at 4:11 PM, Peter Foley wrote: > On Wed, Oct 8, 2014 at 5:21 PM, H. Peter Anvin wrote: >> That we can't solve, but it is not okay to break the kernel build. > > Should I just make CONFIG_BUILD_DOCSRC depend on CROSS_COMPILE=""? > I'm not sure how much value would be added by implementing targetprogs > in kbuild, simply to increase build testing of Documentation/ Yes, IMO. Let the kselftest people solve it, because they might have extra requirements. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pinctrl-msm build error on Linus' tree
On Wed, Oct 08, 2014 at 07:09:18PM -0400, Josh Boyer wrote: > On Wed, Oct 8, 2014 at 6:49 PM, Josh Cartwright wrote: > > Hey Josh- > > > > On Wed, Oct 08, 2014 at 06:42:55PM -0400, Josh Boyer wrote: > >> We're hitting a build error on ARM with Linus' tree as of Linux > >> v3.17-2860-gef0625b70dac : > >> > >> drivers/pinctrl/qcom/pinctrl-msm.c: In function > >> 'msm_pinctrl_setup_pm_reset': > >> drivers/pinctrl/qcom/pinctrl-msm.c:875:4: error: implicit declaration > >> of function 'register_restart_handler' > >> [-Werror=implicit-function-declaration] > >> if (register_restart_handler(>restart_nb)) > >> ^ > >> drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_pinctrl_remove': > >> drivers/pinctrl/qcom/pinctrl-msm.c:949:2: error: implicit declaration > >> of function 'unregister_restart_handler' > >> [-Werror=implicit-function-declaration] > >> unregister_restart_handler(>restart_nb); > >> ^ > >> cc1: some warnings being treated as errors > >> > >> Looking at the git logs it seems this was added via: > >> > >> commit cf1fc187628913070c3e418ce0e205732435aa2f > >> Author: Josh Cartwright > >> Date: Tue Sep 23 15:59:53 2014 -0500 > >> > >> pinctrl: qcom: use restart_notifier mechanism for ps_hold > >> > >> > >> However, there is literally nothing else in the tree that calls or > >> provides those functions: > >> > >> [jwboyer@vader linux]$ git grep unregister_restart_handler > >> drivers/pinctrl/qcom/pinctrl-msm.c: > >> unregister_restart_handler(>resta > >> [jwboyer@vader linux]$ > >> > >> > >> I'm rather confused. How was this commit built and tested? > > > > This may be my fault for not clearly stating that this particular patch > > was dependent on Guenter's restart notifier patchset. This patch was > > applied to linusw's tree without these patches. Perhaps it should be > > dropped for now until the restart_notifier stuff lands? > > Thanks, that explains things. I'm not sure if Linus would do a revert > at this point. I guess it depends on how fast he's going to merge > Guenter's patches. > > Is there a reason this wasn't all brought in via one tree? Seems like > it should have been. > Too many dependencies all over the place, and thus risk to create merge-time conflicts. Besides pinctrl, the restart handler infrastructure is already used by clock, power/restart, and watchdog drivers. The idea was for me to provide a pointer to an immutable branch with the infrastructure (which I did), and for all trees using it to merge with that branch. This way the infrastructure would have been merged automatically with its first user, and no separate pull request would have been necessary. Again, I thought we had this well covered. Apparently not, and of course the one tree who didn't merge the infrastructure got into mainline first :-(. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] staging: comedi: (regression) channel list must be set for COMEDI_CMD ioctl
On Wednesday, October 08, 2014 8:09 AM, Ian Abbott wrote:
> `do_cmd_ioctl()`, the handler for the `COMEDI_CMD` ioctl can incorrectly
> call the Comedi subdevice's `do_cmd()` handler with a NULL channel list
> pointer. This is a regression as the `do_cmd()` handler has never been
> expected to deal with that, leading to a kernel OOPS when it tries to
> dereference it.
>
> A NULL channel list pointer is allowed for the `COMEDI_CMDTEST` ioctl,
> handled by `do_cmdtest_ioctl()` and the subdevice's `do_cmdtest()`
> handler, but not for the `COMEDI_CMD` ioctl and its handlers.
>
> Both `do_cmd_ioctl()` and `do_cmdtest_ioctl()` call
> `__comedi_get_user_chanlist()` to copy the channel list from user memory
> into dynamically allocated kernel memory and check it for consistency.
> That function currently returns 0 if the `user_chanlist` parameter
> (pointing to the channel list in user memory) is NULL. That's fine for
> `do_cmdtest_ioctl()`, but `do_cmd_ioctl()` incorrectly assumes the
> kernel copy of the channel list has been set-up correctly.
>
> Fix it by not allowing the `user_chanlist` parameter to be NULL in
> `__comedi_get_user_chanlist()`, and only calling it from
> `do_cmdtest_ioctl()` if the parameter is non-NULL.
>
> Thanks to Bernd Porr for reporting the bug via an initial patch sent
> privately.
>
> Fixes: c6cd0eefb27b ("staging: comedi: comedi_fops: introduce
> __comedi_get_user_chanlist()")
> Reported-by: Bernd Porr
> Signed-off-by: Ian Abbott
> Cc: Bernd Porr
> Cc: # 3.15.y 3.16.y 3.17.y
> ---
> drivers/staging/comedi/comedi_fops.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/comedi/comedi_fops.c
> b/drivers/staging/comedi/comedi_fops.c
> index 495969f..a9b7fe5 100644
> --- a/drivers/staging/comedi/comedi_fops.c
> +++ b/drivers/staging/comedi/comedi_fops.c
> @@ -1462,10 +1462,6 @@ static int __comedi_get_user_chanlist(struct
> comedi_device *dev,
> unsigned int *chanlist;
> int ret;
>
> - /* user_chanlist could be NULL for do_cmdtest ioctls */
> - if (!user_chanlist)
> - return 0;
> -
I think you need a check here to avoid a NULL pointer getting
passed to the memdup_user().
If (!user_chanlist || cmd->chanlist_len == 0)
return -EINVAL;
> chanlist = memdup_user(user_chanlist,
> cmd->chanlist_len * sizeof(unsigned int));
> if (IS_ERR(chanlist))
> @@ -1609,10 +1605,13 @@ static int do_cmdtest_ioctl(struct comedi_device *dev,
>
> s = >subdevices[cmd.subdev];
>
> - /* load channel/gain list */
> - ret = __comedi_get_user_chanlist(dev, s, user_chanlist, );
> - if (ret)
> - return ret;
> + /* user_chanlist can be NULL for COMEDI_CMDTEST ioctl */
> + if (user_chanlist) {
> + /* load channel/gain list */
> + ret = __comedi_get_user_chanlist(dev, s, user_chanlist, );
> + if (ret)
> + return ret;
> + }
>
> ret = s->do_cmdtest(dev, s, );
The reset looks ok.
Side-note on mem_dupuser(). That function does a kmalloc to copy the
user data to the kernel. Shouldn't we be freeing it when we are done with
it?
do_become_nonbusy() does a kfree(async->cmd.chanlist) which will free
the memory for do_cmd_ioctl().
But, do_cmdtest_ioctl() actually copies the user data into a local variable.
I think we are missing a kfree() there.
Regards,
Hartley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pinctrl-msm build error on Linus' tree
On Wed, Oct 08, 2014 at 06:42:55PM -0400, Josh Boyer wrote: > We're hitting a build error on ARM with Linus' tree as of Linux > v3.17-2860-gef0625b70dac : > > drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_pinctrl_setup_pm_reset': > drivers/pinctrl/qcom/pinctrl-msm.c:875:4: error: implicit declaration > of function 'register_restart_handler' > [-Werror=implicit-function-declaration] > if (register_restart_handler(>restart_nb)) > ^ > drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_pinctrl_remove': > drivers/pinctrl/qcom/pinctrl-msm.c:949:2: error: implicit declaration > of function 'unregister_restart_handler' > [-Werror=implicit-function-declaration] > unregister_restart_handler(>restart_nb); > ^ > cc1: some warnings being treated as errors > > Looking at the git logs it seems this was added via: > > commit cf1fc187628913070c3e418ce0e205732435aa2f > Author: Josh Cartwright > Date: Tue Sep 23 15:59:53 2014 -0500 > > pinctrl: qcom: use restart_notifier mechanism for ps_hold > > > However, there is literally nothing else in the tree that calls or > provides those functions: > > [jwboyer@vader linux]$ git grep unregister_restart_handler > drivers/pinctrl/qcom/pinctrl-msm.c: > unregister_restart_handler(>resta > [jwboyer@vader linux]$ > > > I'm rather confused. How was this commit built and tested? > Looks like the pinctrl tree did not include the merge with the immutable branch with the necessary infrastructure in its pull request to Linus :-(. As for how it was tested in the pinctrl tree, no idea. Maybe pinctrl-msm has some dependency which was missing in the pinctrl tree and came in through a different pull request. For this to build, you'll need to merge git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git restart-handler-for-v3.18 which was supposed to be merged by all trees using it, to avoid exactly this problem (clk, power/restart, and watchdog are the other trees I am aware of). Best solution might be for Linus to pull the above tag directly, after screaming at me appropriately. Sorry, I thought we had this well covered. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vdso_standalone_test_x86.c build failure on Linus' tree
On Wed, Oct 8, 2014 at 5:21 PM, H. Peter Anvin wrote: > That we can't solve, but it is not okay to break the kernel build. Should I just make CONFIG_BUILD_DOCSRC depend on CROSS_COMPILE=""? I'm not sure how much value would be added by implementing targetprogs in kbuild, simply to increase build testing of Documentation/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pinctrl-msm build error on Linus' tree
On Wed, Oct 8, 2014 at 6:49 PM, Josh Cartwright wrote: > Hey Josh- > > On Wed, Oct 08, 2014 at 06:42:55PM -0400, Josh Boyer wrote: >> We're hitting a build error on ARM with Linus' tree as of Linux >> v3.17-2860-gef0625b70dac : >> >> drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_pinctrl_setup_pm_reset': >> drivers/pinctrl/qcom/pinctrl-msm.c:875:4: error: implicit declaration >> of function 'register_restart_handler' >> [-Werror=implicit-function-declaration] >> if (register_restart_handler(>restart_nb)) >> ^ >> drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_pinctrl_remove': >> drivers/pinctrl/qcom/pinctrl-msm.c:949:2: error: implicit declaration >> of function 'unregister_restart_handler' >> [-Werror=implicit-function-declaration] >> unregister_restart_handler(>restart_nb); >> ^ >> cc1: some warnings being treated as errors >> >> Looking at the git logs it seems this was added via: >> >> commit cf1fc187628913070c3e418ce0e205732435aa2f >> Author: Josh Cartwright >> Date: Tue Sep 23 15:59:53 2014 -0500 >> >> pinctrl: qcom: use restart_notifier mechanism for ps_hold >> >> >> However, there is literally nothing else in the tree that calls or >> provides those functions: >> >> [jwboyer@vader linux]$ git grep unregister_restart_handler >> drivers/pinctrl/qcom/pinctrl-msm.c: >> unregister_restart_handler(>resta >> [jwboyer@vader linux]$ >> >> >> I'm rather confused. How was this commit built and tested? > > This may be my fault for not clearly stating that this particular patch > was dependent on Guenter's restart notifier patchset. This patch was > applied to linusw's tree without these patches. Perhaps it should be > dropped for now until the restart_notifier stuff lands? Thanks, that explains things. I'm not sure if Linus would do a revert at this point. I guess it depends on how fast he's going to merge Guenter's patches. Is there a reason this wasn't all brought in via one tree? Seems like it should have been. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vdso_standalone_test_x86.c build failure on Linus' tree
On Wed, 08 Oct 2014 14:21:00 -0700 "H. Peter Anvin" wrote: > On 10/08/2014 02:09 PM, Chuck Ebbert wrote: > >> > >> Breaking cross-compilation is not okay, though, regardless of what > >> Fedora does. It should be okay to, for example, build an i386 kernel on > >> an ARM box. > >> > > > > I think they tried that for a while, and ended up chasing compiler > > and makefile bugs all day. And then there's the software that wants > > to run self-tests as part of its build... > > > > That we can't solve, but it is not okay to break the kernel build. > Also, as Andy pointed out, when building for x86_64 we probably want to build both 32-bit and 64-bit versions of most test programs like this one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: of: Lower the severity of the error with no container
On Wed, Oct 08, 2014 at 11:36:01PM +0100, Mark Brown wrote: > On Wed, Oct 08, 2014 at 03:34:03PM -0700, Guenter Roeck wrote: > > > Would it also be possible to lower the severity of the "no parameters" > > message ? > > Could you be more specific please? There is a log message "no parameters" for each regulator. This is printed unconditionally from print_constraints(). Looking through the code again, looks like this is on purpose. It is just a bit annoying to get lots of those messages. One of the systems I am dealing with has 17 LTC2978 chips in it, with 8 channels each. That results in 136 times "no parameters" in the boot log. And that is not even a fully populated system; if fully populated, there can be more than 60 of those chips. 500+ lines of similar log messages is really a bit on the high side. It might help if there was a way to silence the messages, ie to make "print_constraints" optional. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: staging: imx-drm driver cleanup
On Wed, Oct 08, 2014 at 08:34:48PM +0200, Rene Kolarik wrote: > Wrapping two too long lines in two files of the imx-drm driver. > > Signed-off-by: Rene Kolarik > --- > drivers/staging/imx-drm/imx-drm-core.c | 3 ++- > drivers/staging/imx-drm/imx-tve.c | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/imx-drm/imx-drm-core.c > b/drivers/staging/imx-drm/imx-drm-core.c > index 9cb222e..9d1f861 100644 > --- a/drivers/staging/imx-drm/imx-drm-core.c > +++ b/drivers/staging/imx-drm/imx-drm-core.c > @@ -632,7 +632,8 @@ static int imx_drm_platform_probe(struct platform_device > *pdev) > continue; > } > > - component_match_add(>dev, , compare_of, > remote); > + component_match_add(>dev, , compare_of, > + remote); Please line this up with the ( character on the line above. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8188eu: coding style fixup
On Tue, Oct 07, 2014 at 01:11:42PM +0400, Igor Bogomazov wrote: > checkpatch.pk tiny fix > get rid of 2 warnings and 2 errors for hal/fw.c > > Signed-off-by: Igor Bogomazov > Cc: Greg Kroah-Hartman > Cc: navin patidar > Cc: Stephen Rothwell > --- > linux-next 3.17.0 I think someone else already did this before you sent it in, as this doesn't apply to my tree, sorry :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [PATCH] x86, MCE, AMD: save IA32_MCi_STATUS before machine_check_poll() resets it
On Wed, Oct 08, 2014 at 04:52:06PM -0500, Aravind Gopalakrishnan wrote:
> I am not understanding why m.bank is assigned this value..
That's a very good question, see below for some history.
>
> It only causes incorrect decoding-
> [ 608.832916] DEBUG: raise_amd_threshold_event
> [ 608.832926] [Hardware Error]: Corrected error, no action required.
> [ 608.833143] [Hardware Error]: CPU:26 (15:2:0)
> MC165_STATUS[-|CE|MiscV|-|AddrV|-|-]: 0x8c00
> [ 608.833551] [Hardware Error]: MC165_ADDR: 0x
> [ 608.833777] [Hardware Error]: cache level: RESV, tx: INSN
> [ 608.834034] amd_inject module loaded ...
>
>
> (Obviously, as in amd_decode_mce() we switch (m->bank) for decoding the
> status and there is no bank 165)
>
> OTOH, if m.bank = bank;
> Then we get correct decoding info-
Yes, and I think we should do that only if we're using the *last* error
to report the overflow with: we're reporting a thresholding counter
overflow and the bank on which it was detected on should, of course, be
part of the report.
The "funny" bank is some sort of a software defined banks thing which
got added in 2005 (see the patch I dug out below) and it was supposed
to be used (I'm guessing here) for reporting thermal events using MCA
(dumb idea, if you ask me) so since thermal events don't really have
a bank, they decided to have some sort of a software-defined MCA bank
which doesn't correspond to any hardware bank.
Then Jacob decided to use it for some reason too:
95268664390b ("[PATCH] x86_64: mce_amd support for family 0x10 processors")
maybe because thresholding errors don't have a bank associated with them
but if I'm not missing anything, they do!
Oh oh, ok, it just dawned on me! I think I know what it *might* have
been: they wanted to report the overflowing with a special error
signature which uses a software-defined bank. Ok, that actually makes
sense: when you see an error for a sw-defined bank, you're reporting an
thresholding counter overflow.
Which means that we shouldn't be populating m.status either, i.e. what
we did earlier:
rdmsrl(MSR_IA32_MCx_STATUS(bank), m.status);
because this is a special error type.
Hmm, it is too late here to think straight, more tomorrow. But Aravind,
that was a very good question, you actually made me dig into git history
:-)
Good night.
>From d2b6331397e634477b76f6fec119b7caf3ac564e Mon Sep 17 00:00:00 2001
From: Zwane Mwaikambo
Date: Mon, 3 Jan 2005 04:42:52 -0800
Subject: [PATCH] [PATCH] Intel thermal monitor for x86_64
Patch adds support for notification of overheating conditions on intel
x86_64 processors. Tested on EM64T, test booted on AMD64.
Hardware courtesy of Intel Corporation
Signed-off-by: Zwane Mwaikambo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
---
arch/x86_64/Kconfig| 7 +++
arch/x86_64/kernel/Makefile| 1 +
arch/x86_64/kernel/entry.S | 3 ++
arch/x86_64/kernel/i8259.c | 2 +
arch/x86_64/kernel/mce.c | 14 +-
arch/x86_64/kernel/mce_intel.c | 99 ++
arch/x86_64/kernel/traps.c | 4 ++
include/asm-x86_64/mce.h | 13 ++
8 files changed, 142 insertions(+), 1 deletion(-)
create mode 100644 arch/x86_64/kernel/mce_intel.c
diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index 4ffa04271050..bc317049ebed 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -338,6 +338,13 @@ config X86_MCE
machine check error logs. See
ftp://ftp.x86-64.org/pub/linux/tools/mcelog
+config X86_MCE_INTEL
+ bool "Intel MCE features"
+ depends on X86_MCE && X86_LOCAL_APIC
+ default y
+ help
+ Additional support for intel specific MCE features such as
+ the thermal monitor.
endmenu
#
diff --git a/arch/x86_64/kernel/Makefile b/arch/x86_64/kernel/Makefile
index 2c0f3af82e5e..96a5111e96c6 100644
--- a/arch/x86_64/kernel/Makefile
+++ b/arch/x86_64/kernel/Makefile
@@ -10,6 +10,7 @@ obj-y := process.o semaphore.o signal.o entry.o traps.o irq.o
\
setup64.o bootflag.o e820.o reboot.o warmreboot.o quirks.o
obj-$(CONFIG_X86_MCE) += mce.o
+obj-$(CONFIG_X86_MCE_INTEL)+= mce_intel.o
obj-$(CONFIG_MTRR) += ../../i386/kernel/cpu/mtrr/
obj-$(CONFIG_ACPI_BOOT)+= acpi/
obj-$(CONFIG_X86_MSR) += msr.o
diff --git a/arch/x86_64/kernel/entry.S b/arch/x86_64/kernel/entry.S
index d8d906a7d8e1..ca050e729a85 100644
--- a/arch/x86_64/kernel/entry.S
+++ b/arch/x86_64/kernel/entry.S
@@ -538,6 +538,9 @@ retint_kernel:
CFI_ENDPROC
.endm
+ENTRY(thermal_interrupt)
+ apicinterrupt THERMAL_APIC_VECTOR,smp_thermal_interrupt
+
#ifdef CONFIG_SMP
ENTRY(reschedule_interrupt)
apicinterrupt RESCHEDULE_VECTOR,smp_reschedule_interrupt
diff --git a/arch/x86_64/kernel/i8259.c b/arch/x86_64/kernel/i8259.c
index 7929a2e534a6..04e6fdab46b6 100644
--- a/arch/x86_64/kernel/i8259.c
+++
Re: [PATCH] drivers: staging: wlan-ng: fix sparse warnings
On Sat, Oct 04, 2014 at 10:24:28AM +0800, Cheng-wei Lee wrote: > This patch fix the sparse warnings in wlan-ng/cfg80211.c > The following functions were only used in this file, so done by > declaring them into static. > > drivers/staging/wlan-ng/cfg80211.c:710:6: warning: symbol > 'prism2_connect_result' was not declared. Should it be static? > drivers/staging/wlan-ng/cfg80211.c:719:6: warning: symbol > 'prism2_disconnected' was not declared. Should it be static? > drivers/staging/wlan-ng/cfg80211.c:725:6: warning: symbol > 'prism2_roamed' was not declared. Should it be static? > > Signed-off-by: Quentin Lee > --- > drivers/staging/wlan-ng/cfg80211.c |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) This patch doesn't apply to my staging-testing branch of staging.git, can you refresh it and resend please? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pinctrl-msm build error on Linus' tree
Hey Josh- On Wed, Oct 08, 2014 at 06:42:55PM -0400, Josh Boyer wrote: > We're hitting a build error on ARM with Linus' tree as of Linux > v3.17-2860-gef0625b70dac : > > drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_pinctrl_setup_pm_reset': > drivers/pinctrl/qcom/pinctrl-msm.c:875:4: error: implicit declaration > of function 'register_restart_handler' > [-Werror=implicit-function-declaration] > if (register_restart_handler(>restart_nb)) > ^ > drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_pinctrl_remove': > drivers/pinctrl/qcom/pinctrl-msm.c:949:2: error: implicit declaration > of function 'unregister_restart_handler' > [-Werror=implicit-function-declaration] > unregister_restart_handler(>restart_nb); > ^ > cc1: some warnings being treated as errors > > Looking at the git logs it seems this was added via: > > commit cf1fc187628913070c3e418ce0e205732435aa2f > Author: Josh Cartwright > Date: Tue Sep 23 15:59:53 2014 -0500 > > pinctrl: qcom: use restart_notifier mechanism for ps_hold > > > However, there is literally nothing else in the tree that calls or > provides those functions: > > [jwboyer@vader linux]$ git grep unregister_restart_handler > drivers/pinctrl/qcom/pinctrl-msm.c: > unregister_restart_handler(>resta > [jwboyer@vader linux]$ > > > I'm rather confused. How was this commit built and tested? This may be my fault for not clearly stating that this particular patch was dependent on Guenter's restart notifier patchset. This patch was applied to linusw's tree without these patches. Perhaps it should be dropped for now until the restart_notifier stuff lands? Josh -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block: copy bi_vcnt in __bio_clone_fast
Commit 05f1dd53152173 (block: add queue flag for disabling SG merging) uses bi_vcnt to assign bio->bi_phys_segments if sg merging is disabled. When using device mapper on top of a blk-mq device (virtio_blk in my test), we'd end up overflowing the scatterlist in __blk_bios_map_sg. __bio_clone_fast copies bi_iter and bi_io_vec but not bi_vcnt, so blk_recount_segments would report bi_phys_segments as 0. Since rq->nr_phys_segments is 0 as well, the checks to ensure that we don't exceed the queue's segment limit end up allowing more bios (and segments) to attach the a request until we finally map it. That also means we pass the BUG_ON at the beginning of virtio_queue_rq, ultimately causing memory corruption and a crash. If we copy bi_vcnt in __bio_clone_fast, the bios and requests properly report the number of segments and everything works as expected. Originally reported at http://bugzilla.opensuse.org/show_bug.cgi?id=888259 Reported-by: Stephen Kulow Signed-off-by: Jeff Mahoney --- block/bio.c |1 + 1 file changed, 1 insertion(+) --- a/block/bio.c +++ b/block/bio.c @@ -564,6 +564,7 @@ void __bio_clone_fast(struct bio *bio, s bio->bi_rw = bio_src->bi_rw; bio->bi_iter = bio_src->bi_iter; bio->bi_io_vec = bio_src->bi_io_vec; + bio->bi_vcnt = bio_src->bi_vcnt; } EXPORT_SYMBOL(__bio_clone_fast); -- Jeff Mahoney SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: fix vdso_standalone_test_x86 on 32-bit
On Wed, Oct 8, 2014 at 3:54 PM, H. Peter Anvin wrote: > This still has the cross-build problems, no? > Yes, but that issue is more general to CONFIG_BUILD_DOCSRC. This is just a build failure on x86-32. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reset: add reset_control_status helper function
From: Dinh Nguyen
There are cases where a system will want to read a reset status bit before
doing any other toggling. Add a reset_control_status helper function to the
reset controller API.
Signed-off-by: Dinh Nguyen
---
drivers/reset/core.c | 13 +
include/linux/reset-controller.h | 1 +
include/linux/reset.h| 7 +++
3 files changed, 21 insertions(+)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index baeaf82..06387a4 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -126,6 +126,19 @@ int reset_control_deassert(struct reset_control *rstc)
EXPORT_SYMBOL_GPL(reset_control_deassert);
/**
+ * reset_control_status - returns a status of a reset bit
+ * @rstc: reset controller
+ */
+unsigned int reset_control_status(struct reset_control *rstc)
+{
+ if (rstc->rcdev->ops->status)
+ return rstc->rcdev->ops->status(rstc->rcdev, rstc->id);
+
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(reset_control_status);
+
+/**
* of_reset_control_get - Lookup and obtain a reference to a reset controller.
* @node: device to be reset by the controller
* @id: reset line name
diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
index 41a4695..8e659d5 100644
--- a/include/linux/reset-controller.h
+++ b/include/linux/reset-controller.h
@@ -17,6 +17,7 @@ struct reset_control_ops {
int (*reset)(struct reset_controller_dev *rcdev, unsigned long id);
int (*assert)(struct reset_controller_dev *rcdev, unsigned long id);
int (*deassert)(struct reset_controller_dev *rcdev, unsigned long id);
+ unsigned int (*status)(struct reset_controller_dev *rcdev, unsigned
long id);
};
struct module;
diff --git a/include/linux/reset.h b/include/linux/reset.h
index 349f150..09233ee 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -10,6 +10,7 @@ struct reset_control;
int reset_control_reset(struct reset_control *rstc);
int reset_control_assert(struct reset_control *rstc);
int reset_control_deassert(struct reset_control *rstc);
+unsigned int reset_control_status(struct reset_control *rstc);
struct reset_control *reset_control_get(struct device *dev, const char *id);
void reset_control_put(struct reset_control *rstc);
@@ -57,6 +58,12 @@ static inline int reset_control_deassert(struct
reset_control *rstc)
return 0;
}
+static inline unsigned int reset_control_status(struct reset_control *rstc)
+{
+ WARN_ON(1);
+ return 0;
+}
+
static inline void reset_control_put(struct reset_control *rstc)
{
WARN_ON(1);
--
2.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16 00/26] 3.16.5-stable review
On Wed, Oct 08, 2014 at 02:05:22PM -0600, Shuah Khan wrote: > On 10/07/2014 05:19 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.16.5 release. > > There are 26 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Oct 9 23:18:40 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.5-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] staging: gs_fpgaboot: Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning
On Tue, Oct 07, 2014 at 05:54:48PM +0200, Dzmitry Sledneu wrote:
> Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning
>
> Signed-off-by: Dzmitry Sledneu
>
> ---
> drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
> b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
> index 9764a9a..0c18c4c 100644
> --- a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
> +++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
> @@ -295,10 +295,8 @@ static int gs_fpgaboot(void)
> struct fpgaimage*fimage;
>
> fimage = kmalloc(sizeof(struct fpgaimage), GFP_KERNEL);
> - if (fimage == NULL) {
> - pr_err("No memory is available\n");
> - goto err_out;
> - }
> + if (!fimage)
> + return -ENOMEM;
>
> err = gs_load_image(fimage, file);
> if (err) {
> @@ -340,7 +338,6 @@ err_out2:
> err_out1:
> kfree(fimage);
>
> -err_out:
> return -1;
>
> }
Doesn't apply to my tree properly :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/1] fsnotify: next_i is freed during fsnotify_unmount_inodes.
During list_for_each_entry_safe, next_i is becoming free causing
the loop to never terminate. Advance next_i in those cases where
__iget is not done.
Signed-off-by: Jerry Hoemann
---
fs/notify/inode_mark.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/fs/notify/inode_mark.c b/fs/notify/inode_mark.c
index 9ce0622..e849714 100644
--- a/fs/notify/inode_mark.c
+++ b/fs/notify/inode_mark.c
@@ -288,20 +288,25 @@ void fsnotify_unmount_inodes(struct list_head *list)
spin_unlock(>i_lock);
/* In case the dropping of a reference would nuke next_i. */
- if ((_i->i_sb_list != list) &&
- atomic_read(_i->i_count)) {
+ while (_i->i_sb_list != list) {
spin_lock(_i->i_lock);
- if (!(next_i->i_state & (I_FREEING | I_WILL_FREE))) {
+ if (!(next_i->i_state & (I_FREEING | I_WILL_FREE)) &&
+ atomic_read(_i->i_count)) {
__iget(next_i);
need_iput = next_i;
+ spin_unlock(_i->i_lock);
+ break;
}
spin_unlock(_i->i_lock);
+ next_i = list_entry(next_i->i_sb_list.next,
+ struct inode, i_sb_list);
}
/*
-* We can safely drop inode_sb_list_lock here because we hold
-* references on both inode and next_i. Also no new inodes
-* will be added since the umount has begun.
+* We can safely drop inode_sb_list_lock here because either
+* we actually hold references on both inode and next_i or
+* end of list. Also no new inodes will be added since the
+* umount has begun.
*/
spin_unlock(_sb_list_lock);
--
1.7.11.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/1] fsnotify: next_i is freed during fsnotify_unmount_inodes.
During file system stress testing on 3.10 and 3.12 based kernels,
the umount command occasionally hung in fsnotify_unmount_inodes
in the section of code:
spin_lock(>i_lock);
if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) {
spin_unlock(>i_lock);
continue;
}
As this section of code holds the global inode_sb_list_lock, eventually
the system hangs trying to acquire the lock.
Multiple crash dumps showed:
The inode->i_state == 0x60 and i_count == 0 and i_sb_list would point
back at itself. As this is not the value of list upon entry to the
function, the kernel never exits the loop.
To help narrow down problem, the call to list_del_init in inode_sb_list_del
was changed to list_del. This poisons the pointers in the i_sb_list
and causes a kernel to panic if it transverse a freed inode.
Subsequent stress testing paniced in fsnotify_unmount_inodes at the bottom
of the list_for_each_entry_safe loop showing next_i had become free.
We believe the root cause of the problem is that next_i is being freed during
the window of time that the list_for_each_entry_safe loop temporarily releases
inode_sb_list_lock to call fsnotify and fsnotify_inode_delete.
The code in fsnotify_unmount_inodes attempts to prevent the freeing
of inode and next_i by calling __iget. However, the code doesn't
do the __iget call on next_i
if i_count == 0 or
if i_state & (I_FREEING | I_WILL_FREE)
The patch addresses this issue by advancing next_i in the above two
cases until we either find a next_i which we can __iget or we reach
the end of the list. This makes the handling of next_i more closely
match the handling of the variable "inode."
The time to reproduce the hang is highly variable (from hours to days.)
We ran the stress test on a 3.10 kernel with the proposed patch for a
week without failure.
Jerry Hoemann (1):
fsnotify: next_i is freed during fsnotify_unmount_inodes.
fs/notify/inode_mark.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
--
1.7.11.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: block: fix alignment_offset math that assumes io_min is a power-of-2
On Wed, Oct 08 2014 at 6:38pm -0400,
Jens Axboe wrote:
> On 10/08/2014 04:28 PM, Mike Snitzer wrote:
> > On Wed, Oct 08 2014 at 6:12pm -0400,
> > Jens Axboe wrote:
> >
> >> On 10/08/2014 04:05 PM, Mike Snitzer wrote:
> >>> The math in both blk_stack_limits() and queue_limit_alignment_offset()
> >>> assume that a block device's io_min (aka minimum_io_size) is always a
> >>> power-of-2. Fix the math such that it works for non-power-of-2 io_min.
> >>>
> >>> This issue (of alignment_offset != 0) became apparent when testing
> >>> dm-thinp with a thinp blocksize that matches a RAID6 stripesize of
> >>> 1280K. Commit fdfb4c8c1 ("dm thin: set minimum_io_size to pool's data
> >>> block size") unlocked the potential for alignment_offset != 0 due to
> >>> the dm-thin-pool's io_min possibly being a non-power-of-2.
> >>
> >> Well that sucks, AND with a mask is considerably cheaper than a MOD...
> >
> > Yeah, certainly does suck (please note v2 that I just sent). The MODs
> > shouldn't kill us, these functions aren't called in any real hot path.
> > A storm at boot maybe.. or SCSI rescan but...
>
> I had it mixed up with the recent blk_max_size_offset() - you are right,
> this is not in a hot path. For that case, I don't really care, it's fine.
>
> Is v2 runtime tested?
Yes.
Here is the DM stack for an lvm created dm-thin-pool (dm-5).
# lsblk /dev/skd0
NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT
skd0252:00 745.3G 0 disk
├─bricks-mypool_tmeta 253:20 15.8G 0 lvm
│ └─bricks-mypool-tpool 253:40 512G 0 lvm
│ └─bricks-mypool 253:50 512G 0 lvm
└─bricks-mypool_tdata 253:30 512G 0 lvm
└─bricks-mypool-tpool 253:40 512G 0 lvm
└─bricks-mypool 253:50 512G 0 lvm
Before patch:
# cat /sys/block/dm-5/alignment_offset
1048576
After patch:
# cat /sys/block/dm-5/alignment_offset
0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] Staging: rtl8712 removed unnecessary else after return
On Thu, Oct 02, 2014 at 02:32:26PM +0200, Nitin Kuppelur wrote:
> Removed unnecessary else after return to solve
> checkpatch.pl warning
>
> Signed-off-by: Nitin Kuppelur
> ---
> drivers/staging/rtl8712/hal_init.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/rtl8712/hal_init.c
> b/drivers/staging/rtl8712/hal_init.c
> index 81cd654..fbaba11 100644
> --- a/drivers/staging/rtl8712/hal_init.c
> +++ b/drivers/staging/rtl8712/hal_init.c
> @@ -387,12 +387,9 @@ uint rtl8712_hal_deinit(struct _adapter *padapter)
> uint rtl871x_hal_init(struct _adapter *padapter)
> {
> padapter->hw_init_completed = false;
> - if (padapter->halpriv.hal_bus_init == NULL)
> + if (padapter->halpriv.hal_bus_init == NULL ||
> + padapter->halpriv.hal_bus_init(padapter) != _SUCCESS)
> return _FAIL;
> - else {
> - if (padapter->halpriv.hal_bus_init(padapter) != _SUCCESS)
> - return _FAIL;
> - }
> if (rtl8712_hal_init(padapter) == _SUCCESS)
> padapter->hw_init_completed = true;
> else {
This doesn't apply to my tree :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
pinctrl-msm build error on Linus' tree
We're hitting a build error on ARM with Linus' tree as of Linux v3.17-2860-gef0625b70dac : drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_pinctrl_setup_pm_reset': drivers/pinctrl/qcom/pinctrl-msm.c:875:4: error: implicit declaration of function 'register_restart_handler' [-Werror=implicit-function-declaration] if (register_restart_handler(>restart_nb)) ^ drivers/pinctrl/qcom/pinctrl-msm.c: In function 'msm_pinctrl_remove': drivers/pinctrl/qcom/pinctrl-msm.c:949:2: error: implicit declaration of function 'unregister_restart_handler' [-Werror=implicit-function-declaration] unregister_restart_handler(>restart_nb); ^ cc1: some warnings being treated as errors Looking at the git logs it seems this was added via: commit cf1fc187628913070c3e418ce0e205732435aa2f Author: Josh Cartwright Date: Tue Sep 23 15:59:53 2014 -0500 pinctrl: qcom: use restart_notifier mechanism for ps_hold However, there is literally nothing else in the tree that calls or provides those functions: [jwboyer@vader linux]$ git grep unregister_restart_handler drivers/pinctrl/qcom/pinctrl-msm.c: unregister_restart_handler(>resta [jwboyer@vader linux]$ I'm rather confused. How was this commit built and tested? josh Full build log here: http://koji.fedoraproject.org/koji/getfile?taskID=7803166=build.log -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: bcm: remove unnecessary else statement
On Tue, Sep 30, 2014 at 11:29:00PM +0530, Karthik Nayak wrote:
> Removed the else statement occurring after an if statement with a
> return value as per checkpatch warning.
>
> Signed-off-by: Karthik Nayak
> ---
> drivers/staging/bcm/InterfaceMisc.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/bcm/InterfaceMisc.c
> b/drivers/staging/bcm/InterfaceMisc.c
> index e5bcfec..1f31b8f 100644
> --- a/drivers/staging/bcm/InterfaceMisc.c
> +++ b/drivers/staging/bcm/InterfaceMisc.c
> @@ -102,12 +102,11 @@ int InterfaceWRM(struct bcm_interface_adapter
> *psIntfAdapter,
> DBG_LVL_ALL, "WRM failed status :%d", retval);
> psIntfAdapter->psAdapter->DeviceAccess = false;
> return retval;
> - } else {
> - psIntfAdapter->psAdapter->DeviceAccess = false;
> - BCM_DEBUG_PRINT(psIntfAdapter->psAdapter, DBG_TYPE_OTHERS, WRM,
> - DBG_LVL_ALL, "WRM sent %d", retval);
> - return STATUS_SUCCESS;
> }
> + psIntfAdapter->psAdapter->DeviceAccess = false;
> + BCM_DEBUG_PRINT(psIntfAdapter->psAdapter, DBG_TYPE_OTHERS, WRM,
> + DBG_LVL_ALL, "WRM sent %d", retval);
> + return STATUS_SUCCESS;
> }
>
> int BcmRDM(void *arg,
> --
> 2.1.0
This doesn't apply either, someone else must have done this change
already.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: bcm: multiple checkpatch fixes for InterfaceIdleMode.c
On Tue, Sep 30, 2014 at 10:56:17PM +0530, Karthik Nayak wrote: > 1. WARNING: else is not generally useful after a break or return > > 2. WARNING: quoted string split across lines > > 3. WARNING: break quoted strings at a space character > > Signed-off-by: Karthik Nayak > --- > drivers/staging/bcm/InterfaceIdleMode.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) Doesn't apply to my tree :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block: fix alignment_offset math that assumes io_min is a power-of-2
On 10/08/2014 04:28 PM, Mike Snitzer wrote:
> On Wed, Oct 08 2014 at 6:12pm -0400,
> Jens Axboe wrote:
>
>> On 10/08/2014 04:05 PM, Mike Snitzer wrote:
>>> The math in both blk_stack_limits() and queue_limit_alignment_offset()
>>> assume that a block device's io_min (aka minimum_io_size) is always a
>>> power-of-2. Fix the math such that it works for non-power-of-2 io_min.
>>>
>>> This issue (of alignment_offset != 0) became apparent when testing
>>> dm-thinp with a thinp blocksize that matches a RAID6 stripesize of
>>> 1280K. Commit fdfb4c8c1 ("dm thin: set minimum_io_size to pool's data
>>> block size") unlocked the potential for alignment_offset != 0 due to
>>> the dm-thin-pool's io_min possibly being a non-power-of-2.
>>
>> Well that sucks, AND with a mask is considerably cheaper than a MOD...
>
> Yeah, certainly does suck (please note v2 that I just sent). The MODs
> shouldn't kill us, these functions aren't called in any real hot path.
> A storm at boot maybe.. or SCSI rescan but...
I had it mixed up with the recent blk_max_size_offset() - you are right,
this is not in a hot path. For that case, I don't really care, it's fine.
Is v2 runtime tested?
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: of: Lower the severity of the error with no container
On Wed, Oct 08, 2014 at 03:34:03PM -0700, Guenter Roeck wrote: > Would it also be possible to lower the severity of the "no parameters" > message ? Could you be more specific please? signature.asc Description: Digital signature
Re: [GIT pull] timer changes for 3.18
On Wed, Oct 08, 2014 at 05:54:49PM -0400, Linus Torvalds wrote: > On Wed, Oct 8, 2014 at 2:12 PM, Thomas Gleixner wrote: > > > > please pull the latest timers-core-for-linus git tree from: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > timers-core-for-linus > > > > Nothing really exciting this time: > > > > - A few fixlets in the NOHZ code > > .. but apparently *still* not the fixes from Frederic for the issue > that people are complaining about killing their machines in 3.17. > > WTF? What happened to those? Thomas just pulled these in -tip today. I'm pretty sure he plans to make a 2nd timers pile after this one during the merge window. We just found a non-trivial conflict in my branch against the RCU tree so this probably needs a bit of last minute adjustment and testing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: of: Lower the severity of the error with no container
On Wed, Oct 08, 2014 at 11:09:59PM +0100, Mark Brown wrote:
> Description of regulators should generally be optional so if there is no
> DT node for the regulators container then we shouldn't print an error
> message. Lower the severity of the message to debug level (it might help
> someone work out what went wrong) and while we're at it say what we were
> looking for.
>
> Reported-by: Guenter Roeck
> Signed-off-by: Mark Brown
Excellent.
Reviewed-by: Guenter Roeck
Would it also be possible to lower the severity of the "no parameters"
message ?
Thanks,
Guenter
> ---
> drivers/regulator/of_regulator.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/of_regulator.c
> b/drivers/regulator/of_regulator.c
> index 7a51814abdc5..5a1d4afa4776 100644
> --- a/drivers/regulator/of_regulator.c
> +++ b/drivers/regulator/of_regulator.c
> @@ -211,7 +211,8 @@ struct regulator_init_data
> *regulator_of_get_init_data(struct device *dev,
> search = dev->of_node;
>
> if (!search) {
> - dev_err(dev, "Failed to find regulator container node\n");
> + dev_dbg(dev, "Failed to find regulator container node '%s'\n",
> + desc->regulators_node);
> return NULL;
> }
>
> --
> 2.1.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: block: fix alignment_offset math that assumes io_min is a power-of-2
On Wed, Oct 08 2014 at 6:12pm -0400,
Jens Axboe wrote:
> On 10/08/2014 04:05 PM, Mike Snitzer wrote:
> > The math in both blk_stack_limits() and queue_limit_alignment_offset()
> > assume that a block device's io_min (aka minimum_io_size) is always a
> > power-of-2. Fix the math such that it works for non-power-of-2 io_min.
> >
> > This issue (of alignment_offset != 0) became apparent when testing
> > dm-thinp with a thinp blocksize that matches a RAID6 stripesize of
> > 1280K. Commit fdfb4c8c1 ("dm thin: set minimum_io_size to pool's data
> > block size") unlocked the potential for alignment_offset != 0 due to
> > the dm-thin-pool's io_min possibly being a non-power-of-2.
>
> Well that sucks, AND with a mask is considerably cheaper than a MOD...
Yeah, certainly does suck (please note v2 that I just sent). The MODs
shouldn't kill us, these functions aren't called in any real hot path.
A storm at boot maybe.. or SCSI rescan but...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
