linux.kernel - 26 new messages in 16 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* xen-netback: Handle guests with too many frags - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5507fc94be7f133f?hl=en
* iommu/vt-d: mark internal functions as static - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/779b56bb501a9e2e?hl=en
* 3.4.76-stable review - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/54f42078f0750e24?hl=en
* hwmon/sensors: fix SENSORS_LM75 dependencies - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0b19a469dc611e35?hl=en
* sched: CPU topology try - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c41eda64a33b68cb?hl=en
* usb/core: fix NULL pointer dereference in recursively_mark_NOTATTACHED - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/40ce17b146f80934?hl=en
* ASoC: ux500_pcm: Extend Device Tree support to deal with DMA data - 10
messages, 1 author
http://groups.google.com/group/linux.kernel/t/12c5951118390658?hl=en
* dmaengine: Add support for BCM2835 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7dbc38b06cb5d064?hl=en
* Implement new PTRACE_EVENT_SYSCALL_{ENTER,EXIT} - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b5d27cb9eafa4d04?hl=en
* [PATCH] tracing: Show available event triggers when no trigger is set - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/44727c0d1226d1a4?hl=en
* vb2: Check if there are buffers before streamon - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/257ee1585451b40f?hl=en
* dt-bindings: pci: xgene pcie device tree bindings - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bb793bfb4a89dad9?hl=en
* arm64, jump label: optimize jump label implementation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/be32e1703d60bfc8?hl=en
* dm snapshot: Calling destroy_work_on_stack() to pair with INIT_WORK_ONSTACK()
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cf6b66e5d32612e6?hl=en
* Use lockless lists for smp_call_function_single() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5f85a34507b23045?hl=en
* n900 led compiler (was Re: [PATCH] Add LED pattern trigger) - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/d966e3c0c4ac5135?hl=en

==============================================================================
TOPIC: xen-netback: Handle guests with too many frags
http://groups.google.com/group/linux.kernel/t/5507fc94be7f133f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:30 am
From: Zoltan Kiss


On 16/12/13 18:09, Wei Liu wrote:
>>>> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
>>>> index e26cdda..f6ed1c8 100644
>>>> --- a/drivers/net/xen-netback/netback.c
>>>> +++ b/drivers/net/xen-netback/netback.c
>>>> @@ -906,11 +906,15 @@ static struct gnttab_map_grant_ref *xenvif_get_requests(struct xenvif *vif,
>>>> u16 pending_idx = *((u16 *)skb->data);
>>>> int start;
>>>> pending_ring_idx_t index;
>>>> - unsigned int nr_slots;
>>>> + unsigned int nr_slots, frag_overflow = 0;
>>>>
>>>> /* At this point shinfo->nr_frags is in fact the number of
>>>> * slots, which can be as large as XEN_NETBK_LEGACY_SLOTS_MAX.
>>>> */
>>>> + if (shinfo->nr_frags > MAX_SKB_FRAGS) {
>>>> + frag_overflow = shinfo->nr_frags - MAX_SKB_FRAGS;
>>>> + shinfo->nr_frags = MAX_SKB_FRAGS;
>>>> + }
>>>> nr_slots = shinfo->nr_frags;
>>>>
>>>
>>> It is also probably better to check whether shinfo->nr_frags is too
>>> large which makes frag_overflow > MAX_SKB_FRAGS. I know skb should be
>>> already be valid at this point but it wouldn't hurt to be more careful.
>> Ok, I've added this:
>> /* At this point shinfo->nr_frags is in fact the number of
>> * slots, which can be as large as XEN_NETBK_LEGACY_SLOTS_MAX.
>> */
>> + if (shinfo->nr_frags > MAX_SKB_FRAGS) {
>> + if (shinfo->nr_frags > XEN_NETBK_LEGACY_SLOTS_MAX) return NULL;
>> + frag_overflow = shinfo->nr_frags - MAX_SKB_FRAGS;
>>
>
> What I suggested is
>
> BUG_ON(frag_overflow > MAX_SKB_FRAGS)

Ok, I've changed it.

Zoli

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: iommu/vt-d: mark internal functions as static
http://groups.google.com/group/linux.kernel/t/779b56bb501a9e2e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:30 am
From: Joerg Roedel


On Mon, Jan 06, 2014 at 02:18:16PM +0800, Jiang Liu wrote:
> Function detect_intel_iommu()/alloc_iommu()/parse_ioapics_under_ir()
> are only used internally, so mark them as static.

Doesn't seem to be true for detect_intel_iommu which is used in ia64
setup code, no?


Joerg


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: 3.4.76-stable review
http://groups.google.com/group/linux.kernel/t/54f42078f0750e24?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:30 am
From: Greg Kroah-Hartman


On Mon, Jan 06, 2014 at 09:01:12PM -0800, Guenter Roeck wrote:
> On 01/06/2014 02:39 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.4.76 release.
> > There are 43 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 Wed Jan 8 22:39:27 UTC 2014.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 104 pass: 89 skipped: 11 fail: 4
>
> qemu tests all passed.
>
> Results are as expected.
> Details are available as usual at http://server.roeck-us.net:8010/builders.

Thanks for testing.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: hwmon/sensors: fix SENSORS_LM75 dependencies
http://groups.google.com/group/linux.kernel/t/0b19a469dc611e35?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:40 am
From: Eduardo Valentin


On 07-01-2014 11:07, Jean Delvare wrote:
> On Tue, 7 Jan 2014 10:57:52 -0400, Eduardo Valentin wrote:
>> On 07-01-2014 10:05, Zhang, Rui wrote:
>>> BTW, I've been thinking of make CONFIG_THERMAL a bool since long time ago, the only thing that blocks me is that Thermal subsystem needs to register a hwmon device for each thermal zone and CONFIG_HWMON is a tristate.
>>
>> I agree with the move of having CONFIG_THERMAL as bool. Unless you have
>> use cases where users are dynamically loading and unloading thermal per
>> user demand, which I doubt.
>
> Modularity is not only about reloading modules (although this can be
> useful for developers in particular.) It's also about enabling many
> features in a generic distribution kernel and each feature only gets
> loaded/used on the hardware which needs it. This is why, as a

In fact, no one has said anything different than the above. I definitely
agree with you. Except that this needs to be taken with a bit of care.

> distribution kernel maintainer, I keep complaining when I see boolean
> options which might easily be tristates.

Well, I would say it is not that 'easy' and not that straight forward.
there a couple of items to be considered in the thermal case, the boot
requirements and API provisioning are two, just to mention. There are
use cases that waiting for init to be loaded and modules to be linked is
just no go for thermal constraints, in case the system is already booted
'hot'.

Besides, hiding APIs when a component is build is module is not very
'modular', even considering the statements you brought above.

>


--
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin






==============================================================================
TOPIC: sched: CPU topology try
http://groups.google.com/group/linux.kernel/t/c41eda64a33b68cb?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:40 am
From: Morten Rasmussen


On Tue, Jan 07, 2014 at 02:11:22PM +0000, Vincent Guittot wrote:
> On 7 January 2014 14:22, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, Jan 07, 2014 at 09:32:04AM +0100, Vincent Guittot wrote:
> >> On 6 January 2014 17:31, Peter Zijlstra <peterz@infradead.org> wrote:
> >> > On Mon, Jan 06, 2014 at 02:41:31PM +0100, Vincent Guittot wrote:
> >> >> IMHO, these settings will disappear sooner or later, as an example the
> >> >> idle/busy _idx are going to be removed by Alex's patch.
> >> >
> >> > Well I'm still entirely unconvinced by them..
> >> >
> >> > removing the cpu_load array makes sense, but I'm starting to doubt the
> >> > removal of the _idx things.. I think we want to retain them in some
> >> > form, it simply makes sense to look at longer term averages when looking
> >> > at larger CPU groups.
> >> >
> >> > So maybe we can express the things in log_2(group-span) or so, but we
> >> > need a working replacement for the cpu_load array. Ideally some
> >> > expression involving the blocked load.
> >>
> >> Using the blocked load can surely give benefit in the load balance
> >> because it gives a view of potential load on a core but it still decay
> >> with the same speed than runnable load average so it doesn't solve the
> >> issue for longer term average. One way is to have a runnable average
> >> load with longer time window

The blocked load discussion comes up again :)

I totally agree that blocked load would be useful, but only if we get
the priority problem sorted out. Blocked load is the sum of load_contrib
of blocked tasks, which means that a tiny high priority task can have a
massive contribution to the blocked load.

> >
> > Ah, another way of looking at it is that the avg without blocked
> > component is a 'now' picture. It is the load we are concerned with right
> > now.
> >
> > The more blocked we add the further out we look; with the obvious limit
> > of the entire averaging period.
> >
> > So the avg that is runnable is right now, t_0; the avg that is runnable +
> > blocked is t_0 + p, where p is the avg period over which we expect the
> > blocked contribution to appear.
> >
> > So something like:
> >
> > avg = runnable + p(i) * blocked; where p(i) \e [0,1]
> >
> > could maybe be used to replace the cpu_load array and still represent
> > the concept of looking at a bigger picture for larger sets. Leaving open
> > the details of the map p.

Figuring out p is the difficult bit. AFAIK, with blocked load in its
current form we don't have any clue when a task will reappear.

>
> That needs to be studied more deeply but that could be a way to have a
> larger picture

Agree.

>
> Another point is that we are using runnable and blocked load average
> which are the sum of load_avg_contrib of tasks but we are not using
> the runnable_avg_sum of the cpus which is not the now picture but a
> average of the past running time (without taking into account task
> weight)

Yes. The rq runnable_avg_sum is an excellent longer term load indicator.
It can't be compared with the runnable and blocked load though. The
other alternative that I can think of is to introduce an unweighted
alternative to blocked load. That is, sum of load_contrib/priority.

Morten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: usb/core: fix NULL pointer dereference in recursively_mark_NOTATTACHED
http://groups.google.com/group/linux.kernel/t/40ce17b146f80934?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:40 am
From: Alan Stern


On Tue, 7 Jan 2014, Du, ChangbinX wrote:

> > > Changbin, after looking more closely I realized there was a second
> > > aspect to this race: recursively_mark_NOTATTACHED uses hub->ports[i]
> > > while hub_disconnect removes the port devices. You ought to be able
> > > to cause an oops by inserting a delay just after the loop where
> > > usb_hub_remove_port_device is called.
> > >
> > > The updated patch below should fix both problems. Can you test it?
> > >
> > > Alan Stern
> > >
> >
> > Ok, I'll test it today or tomorrow. Please wait my response.
>
> Alan, I cannot cause a panic after inserting a delay just after
> usb_hub_remove_port_device is called, even move the delay after
> kfree(hub->ports). recursively_mark_NOTATTACHED will not access
> hub->ports[i] since maxchild has been set to 0.
>
> Alan, I think your last patch can fix this issue.

Okay, thanks for testing. I will submit the patch.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: ASoC: ux500_pcm: Extend Device Tree support to deal with DMA data
http://groups.google.com/group/linux.kernel/t/12c5951118390658?hl=en
==============================================================================

== 1 of 10 ==
Date: Tues, Jan 7 2014 7:40 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:55:04PM +0000, Lee Jones wrote:
> Soon we will strip out pdata support from the Ux500 set of ASoC drivers.
> When this happens it will have to supply a DMA slave_config to the
> dmaengine. At the moment a great deal of this comes from pdata via
> AUXDATA. We need to become independent of this soon. This patch starts
> the process by allocating memory for the associated data structures and
> fetches the MSP id used for const struct indexing.

Applied, thanks.




== 2 of 10 ==
Date: Tues, Jan 7 2014 7:40 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:55:01PM +0000, Lee Jones wrote:
> We're getting closer to fully enabling the Ux500 ASoC driver for Device
> Tree. When we switch over from using AUXDATA we'll need to match platform
> by only Device Tree nodes. In this patch we NULL out the platform_name,
> and supply nodes for each platform device.

Applied, thanks.




== 3 of 10 ==
Date: Tues, Jan 7 2014 7:40 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:55:02PM +0000, Lee Jones wrote:
> The Slave Config's addr_width attribute is populated by data_width of
> dma_cfg, which in turn is derived from dma_params' data_size attribute
> and that comes from the slot_width which is always 16 bits (2 Bytes).
> We're cutting out the middle man here and just setting the DMA Slave
> Config directly.

Applied, thanks.




== 4 of 10 ==
Date: Tues, Jan 7 2014 7:40 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:55:08PM +0000, Lee Jones wrote:
> We no longer have a means to differentiate between MSP devices at probe
> time, mainly because we don't really have to. So rather than have an over-
> sized static data structure in place, where the only difference between
> devices is the ID and name (which are unused), we'll just create one
> succinct, statically assigned and shared one instead.

Applied, thanks.




== 5 of 10 ==
Date: Tues, Jan 7 2014 7:40 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:55:00PM +0000, Lee Jones wrote:
> These drivers will not work without platform specific data, which is
> passed in via Device Tree or Platform Data. To avoid the chance of
> NULL pointer dereferencing and alike, let's ensure we have at least
> one of the methods in play before continuing.

Applied, thanks.




== 6 of 10 ==
Date: Tues, Jan 7 2014 7:40 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:55:03PM +0000, Lee Jones wrote:
> In preparation for full Device Tree enablement we must differentiate
> between the two varying ways DMA data can be held in the DAI store. If
> we're booting with Device Tree the provided 'snd_dmaengine_dai_dma_data'
> data structure shall be used, whereas in order to avoid breaking legacy
> platform data we also need to be able to translate DMA data stored using
> the UX500 specific 'ux500_msp_dma_params' method.

Applied, thanks.




== 7 of 10 ==
Date: Tues, Jan 7 2014 7:40 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:55:05PM +0000, Lee Jones wrote:
> In this patch we do two things. Firstly, instead of open coding the
> store of DMA data in to the DAI for later use, we use the API provided.
> Secondly we create and store similar DMA data for the DT case, only
> this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> by the core for this very reason.

Applied, thanks.




== 8 of 10 ==
Date: Tues, Jan 7 2014 7:40 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:54:58PM +0000, Lee Jones wrote:
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Applied, thanks.




== 9 of 10 ==
Date: Tues, Jan 7 2014 7:40 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:55:07PM +0000, Lee Jones wrote:
> If booting with full DT support (i.e. DMA too, the last piece of the
> puzzle), then we don't need to use the compatible_request_channel call
> back or require some of the historical bumph which probably isn't
> required by a platform data start-up now either. This will also be
> ripped out in upcoming commits.

Applied, thanks.




== 10 of 10 ==
Date: Tues, Jan 7 2014 7:50 am
From: Mark Brown



On Thu, Dec 19, 2013 at 03:55:06PM +0000, Lee Jones wrote:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Applied, thanks.





==============================================================================
TOPIC: dmaengine: Add support for BCM2835
http://groups.google.com/group/linux.kernel/t/7dbc38b06cb5d064?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:40 am
From: Arnd Bergmann


On Monday 06 January 2014, Florian Meier wrote:
> Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
> Currently it only supports cyclic DMA.
>
> Signed-off-by: Florian Meier <florian.meier@koalo.de>

Acked-by: Arnd Bergmann <arnd@arndb.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Implement new PTRACE_EVENT_SYSCALL_{ENTER,EXIT}
http://groups.google.com/group/linux.kernel/t/b5d27cb9eafa4d04?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:40 am
From: Oleg Nesterov


On 01/06, Sergio Durigan Junior wrote:
>
> This patch implements the new PTRACE_EVENT_SYSCALL_{ENTER,EXIT} events
> for ptrace. The goal is kind of obvious: it lets the tracer to request
> for notifications when a syscall is called or has returned in the
> tracee. This is very useful because currently there is no easy/direct
> way to inspect whether we are dealing with a call or a return of a
> syscall. GDB itself has an open bug about this, because it can get
> confused when the program being debugged is restarted in the middle of a
> syscall that has been caught by "catch syscall".

Yes, this was suggested many times, probably makes sense.

But I am not sure about semantics, let me add more cc's.

> The other nice thing that I have implemented is the ability to obtain
> the syscall number related to the event by using PTRACE_GET_EVENTMSG.
> This way, we don't need to inspect registers anymore when we want to
> know which syscall is responsible for this or that event.

I won't argue, but it is not clear to me if this is really useful,
given that the debugger can read the regs.

And even if we do this, I disagree with this implementation, please
see below.

> --- a/arch/alpha/kernel/ptrace.c
> +++ b/arch/alpha/kernel/ptrace.c
> @@ -317,7 +317,8 @@ asmlinkage unsigned long syscall_trace_enter(void)
> {
> unsigned long ret = 0;
> if (test_thread_flag(TIF_SYSCALL_TRACE) &&
> - tracehook_report_syscall_entry(current_pt_regs()))
> + tracehook_report_syscall_entry(current_pt_regs(),
> + current_pt_regs()->r0))
> ret = -1UL;
> return ret ?: current_pt_regs()->r0;
> }
> @@ -326,5 +327,6 @@ asmlinkage void
> syscall_trace_leave(void)
> {
> if (test_thread_flag(TIF_SYSCALL_TRACE))
> - tracehook_report_syscall_exit(current_pt_regs(), 0);
> + tracehook_report_syscall_exit(current_pt_regs(), 0,
> + current_pt_regs()->r0);
> }

And every arch/ is changed the same way. I do not think this is needed.
We already have syscall_get_nr(), this is what ptrace_report_syscall()
needs. So afaics this patch do not need to touch arch/ at all.


> +static inline int ptrace_report_syscall(struct pt_regs *regs, int entry,
> + unsigned int sysno)
> {
> int ptrace = current->ptrace;
> + int is_sysenter = ptrace & PT_TRACE_SYSCALL_ENTER;
> + int is_sysexit = ptrace & PT_TRACE_SYSCALL_EXIT;
> + int is_ptsysgood = ptrace & PT_TRACESYSGOOD;
>
> if (!(ptrace & PT_PTRACED))
> return 0;
>
> - ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
> + if (is_sysenter || is_sysexit) {
> + if (entry && is_sysenter)
> + ptrace_event(PTRACE_EVENT_SYSCALL_ENTER, sysno);
> + else if (!entry && is_sysexit)
> + ptrace_event(PTRACE_EVENT_SYSCALL_EXIT, sysno);
> + else
> + return 0;
> + } else
> + ptrace_notify(SIGTRAP | (is_ptsysgood ? 0x80 : 0));

OK. So PTRACE_O_SYSCALL_ENTER acts like PTRACE_O_TRACESYSGOOD, you still
need ptrace(PTRACE_SYSCALL) if you want PTRACE_EVENT_SYSCALL_ENTER.

If we add the new API, perhaps we should change ptrace_resume ?
I mean,

--- x/kernel/ptrace.c
+++ x/kernel/ptrace.c
@@ -723,7 +723,9 @@ static int ptrace_resume(struct task_str
if (!valid_signal(data))
return -EIO;

- if (request == PTRACE_SYSCALL)
+ if (request == PTRACE_SYSCALL ||
+ ptrace_event_enabled(PTRACE_EVENT_SYSCALL_ENTER) ||
+ ptrace_event_enabled(PTRACE_EVENT_SYSCALL_EXIT))
set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
else
clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);


This way PTRACE_O_SYSCALL_* will work like other ptrace options which
ask to report an event.

Or. Instead, perhaps we can add a single option PTRACE_O_TRACESYSREALLYGOOD
which doesn't report the new event and simply does something like

current->ptrace_message = syscall_get_nr() | (entry << 31);
ptrace_notify(SIGTRAP | 0x80);

Finally. If we add this feature, we should probably also report
is_compat_task() somehow. Currently the debugger can't know if, say,
a 64bit tracee does int80.

OTOH, perhaps it would be better to report this via regs->flags as
(iirc) Linus suggested.

Once again, personally I am fine either way. Just I think we should
discuss every possible option.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: [PATCH] tracing: Show available event triggers when no trigger is set
http://groups.google.com/group/linux.kernel/t/44727c0d1226d1a4?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:40 am
From: Steven Rostedt



Currently there's no way to know what triggers exist on a kernel without
looking at the source of the kernel or randomly trying out triggers.
Instead of creating another file in the debugfs system, simply show
what available triggers are there when cat'ing the trigger file when
it has no events:

[root /sys/kernel/debug/tracing]# cat events/sched/sched_switch/trigger
# Available triggers:
# disable_event enable_event stacktrace snapshot traceoff traceon

This stays consistent with other debugfs files where meta data like
this is always proceeded with a '#' at the start of the line so that
tools can strip these out.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/trace/trace_events_trigger.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)

diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index a53e0da..90cf83c 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -115,10 +115,15 @@ event_triggers_post_call(struct ftrace_event_file *file,
}
EXPORT_SYMBOL_GPL(event_triggers_post_call);

+#define SHOW_AVAILABLE_TRIGGERS (void *)(1UL)
+
static void *trigger_next(struct seq_file *m, void *t, loff_t *pos)
{
struct ftrace_event_file *event_file = event_file_data(m->private);

+ if (t == SHOW_AVAILABLE_TRIGGERS)
+ return NULL;
+
return seq_list_next(t, &event_file->triggers, pos);
}

@@ -132,6 +137,9 @@ static void *trigger_start(struct seq_file *m, loff_t *pos)
if (unlikely(!event_file))
return ERR_PTR(-ENODEV);

+ if (list_empty(&event_file->triggers))
+ return *pos == 0 ? SHOW_AVAILABLE_TRIGGERS : NULL;
+
return seq_list_start(&event_file->triggers, *pos);
}

@@ -143,6 +151,18 @@ static void trigger_stop(struct seq_file *m, void *t)
static int trigger_show(struct seq_file *m, void *v)
{
struct event_trigger_data *data;
+ struct event_command *p;
+
+ if (v == SHOW_AVAILABLE_TRIGGERS) {
+ seq_puts(m, "# Available triggers:\n");
+ seq_putc(m, '#');
+ mutex_lock(&trigger_cmd_mutex);
+ list_for_each_entry(p, &trigger_commands, list)
+ seq_printf(m, " %s", p->name);
+ seq_putc(m, '\n');
+ mutex_unlock(&trigger_cmd_mutex);
+ return 0;
+ }

data = list_entry(v, struct event_trigger_data, list);
data->ops->print(m, data->ops, data);
--
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: vb2: Check if there are buffers before streamon
http://groups.google.com/group/linux.kernel/t/257ee1585451b40f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:40 am
From: Marek Szyprowski


Hi,

On 2014-01-07 14:55, Ricardo Ribalda Delgado wrote:
> This patch adds a test preventing streamon() if there is no buffer
> ready.
>
> Without this patch, a user could call streamon() before
> preparing any buffer. This leads to a situation where if he calls
> close() before calling streamoff() the device is kept streaming.
>
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
> ---
> drivers/media/v4l2-core/videobuf2-core.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
> index 098df28..6f20e5a 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1776,6 +1776,11 @@ static int vb2_internal_streamon(struct vb2_queue *q, enum v4l2_buf_type type)
> return 0;
> }
>
> + if (!q->num_buffers) {
> + dprintk(1, "streamon: no frames have been requested\n");

I think that "streamon: error - no buffers have been allocated\n"
message is a bit
more descriptive and it matches the definitions used elsewhere in the
debug messages.
Please don't mix buffers and frames.

> + return -EINVAL;
> + }
> +
> /*
> * If any buffers were queued before streamon,
> * we can now pass them to driver for processing.

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: dt-bindings: pci: xgene pcie device tree bindings
http://groups.google.com/group/linux.kernel/t/bb793bfb4a89dad9?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 7 2014 7:40 am
From: Arnd Bergmann


On Tuesday 07 January 2014, Tanmay Inamdar wrote:
> On Fri, Jan 3, 2014 at 1:49 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> +Required properties:
> >> +- status: Either "ok" or "disabled".
> >> +- device_type: set to "pci"
> >> +- compatible: should contain "xgene,pcie" to identify the core.
> >> +- reg: base addresses and lengths of the pcie controller configuration
> >> + space register.
> >> +- #address-cells: set to <3>
> >> +- #size-cells: set to <2>
> >> +- ranges: ranges for the PCI memory, I/O regions, config and MSI regions
> >> +- #interrupt-cells: set to <1>
> >> +- interrupt-map-mask and interrupt-map: standard PCI properties
> >> + to define the mapping of the PCIe interface to interrupt
> >> + numbers.
> >> +- clocks: from common clock binding: handle to pci clock.
> >> +- clock-names: from common clock binding. Should be "pcieclk".
> >> +
> >
> > Better use an anonymous clock?
>
> Sorry. Can you please elaborate?

I mean drop the "clock-names" property.

> >> +SoC specific DT Entry:
> >> + pcie0: pcie@1f2b0000 {
> >> + status = "disabled";
> >> + device_type = "pci";
> >> + compatible = "xgene,pcie";
> >> + #interrupt-cells = <1>;
> >> + #size-cells = <2>;
> >> + #address-cells = <3>;
> >> + reg = < 0x00 0x1f2b0000 0x0 0x00010000>;
> >> + ranges = <0x02000000 0x0 0x00000000 0xe0 0x00000000 0x0 0x10000000 /* mem*/
> >
> >
> > Also, do you support no prefetchable memory?
>
> HW has either IO or Memory regions for mapping device's memory space.
> There is no separate prefetchable memory space.

Are you sure the memory is non-prefetchable then? I would have expected
0x42000000 rather than 0x02000000, but I could be misremembering it.

> >
> >> + 0x00000000 0x0 0xd0000000 0xe0 0xd0000000 0x0 0x00200000 /* cfg */
> >
> > config space is not normally in the ranges property, and I think you will need
> > it in the pcie node itself as a 'reg' property so the code can access it.
>
> pcie-designware.c does it that way. I just followed their implementation.

I don't remember what led to that, it still seems wrong and I can't find anything
in the PCI binding for host bridges telling their config space this way.

> >> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> >> + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1>;
> >
> > Only one IRQ for all devices?
>
> The node represents a port. I believe that Linux framework uses only
> one of the legacy IRQs per port. Rest all remain unused. Hence I
> removed them. Please correct me if I am wrong.

Any PCI device can normally have four interrupts (IntA through IntD), which are
traditionally separate pins on a PCI bus, but get emulated on PCIe. While it's
not common for any normal device to use more than one IRQ, a bridge device
will swizzle these (virtual) IRQ lines, so a device behind the bridge actually
gets a different host IRQ.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Tues, Jan 7 2014 7:50 am
From: Arnd Bergmann


On Tuesday 07 January 2014 16:35:01 Arnd Bergmann wrote:
> > >> +SoC specific DT Entry:
> > >> + pcie0: pcie@1f2b0000 {
> > >> + status = "disabled";
> > >> + device_type = "pci";
> > >> + compatible = "xgene,pcie";
> > >> + #interrupt-cells = <1>;
> > >> + #size-cells = <2>;
> > >> + #address-cells = >;
> > >> + reg = < 0x00 0x1f2b0000 0x0 0x00010000>;
> > >> + ranges = <0x02000000 0x0 0x00000000 0xe0 0x00000000 0x0 0x10000000 /* mem*/
> > >
> > >
> > > Also, do you support no prefetchable memory?
> >
> > HW has either IO or Memory regions for mapping device's memory space.
> > There is no separate prefetchable memory space.
>
> Are you sure the memory is non-prefetchable then? I would have expected
> 0x42000000 rather than 0x02000000, but I could be misremembering it.

Nevermind. I just checked and you are right: if you only have
one memory range, it has to be non-prefetchable.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: arm64, jump label: optimize jump label implementation
http://groups.google.com/group/linux.kernel/t/be32e1703d60bfc8?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:50 am
From: Will Deacon


On Tue, Jan 07, 2014 at 02:17:13PM +0000, Jiang Liu wrote:
> Optimize jump label implementation for ARM64 by dynamically patching
> kernel text.
>
> Signed-off-by: Jiang Liu <liuj97@gmail.com>
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/jump_label.h | 52 +++++++++++++++++++++++++++++++++
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/jump_label.c | 58 +++++++++++++++++++++++++++++++++++++
> 4 files changed, 112 insertions(+)
> create mode 100644 arch/arm64/include/asm/jump_label.h
> create mode 100644 arch/arm64/kernel/jump_label.c

Reviewed-by: Will Deacon <will.deacon@arm.com>

Thanks for sticking with this! I think this series is good for merging now.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: dm snapshot: Calling destroy_work_on_stack() to pair with INIT_WORK_
ONSTACK()
http://groups.google.com/group/linux.kernel/t/cf6b66e5d32612e6?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:50 am
From: Mike Snitzer


On Tue, Jan 07 2014 at 3:56am -0500,
Chuansheng Liu <chuansheng.liu@intel.com> wrote:

>
> In case CONFIG_DEBUG_OBJECTS_WORK is defined, it is needed to
> call destroy_work_on_stack() which frees the debug object to pair
> with INIT_WORK_ONSTACK().
>
> Signed-off-by: Liu, Chuansheng <chuansheng.liu@intel.com>

Applied to linux-dm.git's 'for-next' branch.

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Use lockless lists for smp_call_function_single()
http://groups.google.com/group/linux.kernel/t/5f85a34507b23045?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:50 am
From: Christoph Hellwig


On Thu, Dec 19, 2013 at 08:31:54AM -0700, Jens Axboe wrote:
> On Wed, Dec 18 2013, Jan Kara wrote:
> > Hello,
> >
> > these three patches make smp_call_function_single() use lockless lists and
> > cleanup abuse of csd.list in the block layer. I have some use for lockless
> > smp_call_function_single() in printk code and that's why I've picked up
> > Christoph's patch. Jens, can you have a look at the series please?
> >
> > Changes since v1:
> > * Reordered patches to a more sensible order.
>
> Thanks Jan, I'll throw this into the testing mix for 3.14. Will be a
> little delayed over christmas, with holidays and family visiting.

Did you make any progress? Btw, I'd love if you could queue up the
patch to use __smp_call_function_single directly in the block layer
for 3.14. Independent of wether a llist using
__smp_call_function_single is faster than one using the lock we get
down from a list plus llist to just one of them, so I can't see how
that patch will cause an issue. With all the prep patches already in
it can be queue up independently of Jan's series as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: n900 led compiler (was Re: [PATCH] Add LED pattern trigger)
http://groups.google.com/group/linux.kernel/t/d966e3c0c4ac5135?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 7 2014 7:50 am
From: Linus Walleij


On Sun, Jan 5, 2014 at 11:23 PM, Pavel Machek <pavel@ucw.cz> wrote:

> I implemented compiler for it (should we put it into tools/ somewhere?)

We have a precedent for putting firmware compilers into the kernel
tree:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/aic7xxx/aicasm

But that one used FLEX. And I think the assumption is that then
you store the firmware source with the driver, and the sysfs (or similar)
interface would just load and trigger one of the pre-defined firmware
programs, not have it be sent in from userspace.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en