Re: [PATCH v2] uas: replace WARN_ON_ONCE() with lockdep_assert_held()
Hi,
On 08/12/2014 08:08 AM, Sanjeev Sharma wrote:
> spin_is_locked() always return false in uniprocessor configuration and
> therefore it
> would be advise to replace with lockdep_assert_held().
>
> Signed-off-by: Sanjeev Sharma
> ---
> Changes in v2:
> - replaced WARN_ON_ONCE() with lockdep_assert_held() to
> avoid runtime overhead instead of assert_spin_locked()
Thanks!
Acked-by: Hans de Goede
Regards,
Hans
>
> drivers/usb/storage/uas.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
> index 3f42785..05b2d8e 100644
> --- a/drivers/usb/storage/uas.c
> +++ b/drivers/usb/storage/uas.c
> @@ -154,7 +154,7 @@ static void uas_mark_cmd_dead(struct uas_dev_info
> *devinfo,
> struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
>
> uas_log_cmd_state(cmnd, caller);
> - WARN_ON_ONCE(!spin_is_locked(>lock));
> + lockdep_assert_held(>lock);
> WARN_ON_ONCE(cmdinfo->state & COMMAND_ABORTED);
> cmdinfo->state |= COMMAND_ABORTED;
> cmdinfo->state &= ~IS_IN_WORK_LIST;
> @@ -181,7 +181,7 @@ static void uas_add_work(struct uas_cmd_info *cmdinfo)
> struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
> struct uas_dev_info *devinfo = cmnd->device->hostdata;
>
> - WARN_ON_ONCE(!spin_is_locked(>lock));
> + lockdep_assert_held(>lock);
> cmdinfo->state |= IS_IN_WORK_LIST;
> schedule_work(>work);
> }
> @@ -283,7 +283,7 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const
> char *caller)
> struct uas_cmd_info *cmdinfo = (void *)>SCp;
> struct uas_dev_info *devinfo = (void *)cmnd->device->hostdata;
>
> - WARN_ON_ONCE(!spin_is_locked(>lock));
> + lockdep_assert_held(>lock);
> if (cmdinfo->state & (COMMAND_INFLIGHT |
> DATA_IN_URB_INFLIGHT |
> DATA_OUT_URB_INFLIGHT |
> @@ -622,7 +622,7 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
> struct urb *urb;
> int err;
>
> - WARN_ON_ONCE(!spin_is_locked(>lock));
> + lockdep_assert_held(>lock);
> if (cmdinfo->state & SUBMIT_STATUS_URB) {
> urb = uas_submit_sense_urb(cmnd, gfp, cmdinfo->stream);
> if (!urb)
>
--
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: [3.16 stable PATCH 1/1] virtio-rng: fix multi-device startup
On Tue, Aug 12, 2014 at 11:01:58AM +0530, Amit Shah wrote: > On (Tue) 12 Aug 2014 [06:55:27], Greg KH wrote: > > On Mon, Aug 11, 2014 at 06:11:47PM +0530, Amit Shah wrote: > > > This is a 3.16-only patch. The linux.git fix is > > > 5c06273401f2eb7b290cadbae18ee00f8f65e893, which fixes this issue in a > > > different way. > > > > Why "different"? Why can't I take that original patch instead? What is > > different in this patch, and why? > > The commit referenced moves the hwrng_register() call to the ->scan() > callback instead of it being in probe(). This was done to ensure the > virtio-rng devices can contribute to the initial system entropy > introduced in commit d9e7972619334. > > That patch is quite small too, but will need a slight conflict > resolution due to the previous two code-shuffling patches, and also > the following revert. > > However, I decided against the backport of the ->scan() method, since > it wasn't designed to solve this regression, it happens to solve it, > and it actually introduces new functionality. I would be happy to > provide a backport of the relevant patches, if you think that would be > alright. I almost always want "original" patches as it causes less bugs overall, and less confusion for everyone involved. Taking 2-3 patches is just as easy as 1 patch, and even easier if I don't have to review it as "hard" due to it not differing from what is in Linus's tree. 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] perf, x86: Use extended offcore mask on Haswell
On Mon, Aug 11, 2014 at 05:11:30PM -0700, Andi Kleen wrote: > From: Andi Kleen > > HSW-EP has a larger offcore mask than the client Haswell CPUs. > It is the same mask as on Sandy/IvyBridge-EP. All of > Haswell was using the client mask, so some bits were missing. > > On the client parts some bits were also missing compared > to Sandy/IvyBridge, in particular the bits to match on a L4 > cache hit. > > The Haswell core in both client and server incarnations > accepts the same bits (but some are nops), so we can use > the same mask. > > So use the snbep extended mask, which is a superset of the > client and the server, for all of Haswell. > > This allows specifying a number of extra offcore events, like > for example for HSW-EP. > > % perf stat -e > cpu/event=0xb7,umask=0x1,offcore_rsp=0x3fffc00100,name=offcore_response_pf_l3_rfo_l3_miss_any_response/ > true > > which were before. > > v2: Post correct patch. > Signed-off-by: Andi Kleen I seem to have this patch; so that means this is a repost right? pgp_kmKOxDLxw.pgp Description: PGP signature
[PATCH v2] uas: replace WARN_ON_ONCE() with lockdep_assert_held()
spin_is_locked() always return false in uniprocessor configuration and
therefore it
would be advise to replace with lockdep_assert_held().
Signed-off-by: Sanjeev Sharma
---
Changes in v2:
- replaced WARN_ON_ONCE() with lockdep_assert_held() to
avoid runtime overhead instead of assert_spin_locked()
drivers/usb/storage/uas.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 3f42785..05b2d8e 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -154,7 +154,7 @@ static void uas_mark_cmd_dead(struct uas_dev_info *devinfo,
struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
uas_log_cmd_state(cmnd, caller);
- WARN_ON_ONCE(!spin_is_locked(>lock));
+ lockdep_assert_held(>lock);
WARN_ON_ONCE(cmdinfo->state & COMMAND_ABORTED);
cmdinfo->state |= COMMAND_ABORTED;
cmdinfo->state &= ~IS_IN_WORK_LIST;
@@ -181,7 +181,7 @@ static void uas_add_work(struct uas_cmd_info *cmdinfo)
struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
struct uas_dev_info *devinfo = cmnd->device->hostdata;
- WARN_ON_ONCE(!spin_is_locked(>lock));
+ lockdep_assert_held(>lock);
cmdinfo->state |= IS_IN_WORK_LIST;
schedule_work(>work);
}
@@ -283,7 +283,7 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const
char *caller)
struct uas_cmd_info *cmdinfo = (void *)>SCp;
struct uas_dev_info *devinfo = (void *)cmnd->device->hostdata;
- WARN_ON_ONCE(!spin_is_locked(>lock));
+ lockdep_assert_held(>lock);
if (cmdinfo->state & (COMMAND_INFLIGHT |
DATA_IN_URB_INFLIGHT |
DATA_OUT_URB_INFLIGHT |
@@ -622,7 +622,7 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
struct urb *urb;
int err;
- WARN_ON_ONCE(!spin_is_locked(>lock));
+ lockdep_assert_held(>lock);
if (cmdinfo->state & SUBMIT_STATUS_URB) {
urb = uas_submit_sense_urb(cmnd, gfp, cmdinfo->stream);
if (!urb)
--
1.7.11.7
--
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: [BUG] oops in cpufreq driver with AMD Kaveri CPU
On Tuesday 12 August 2014 11:22:28 Viresh Kumar wrote: > Yeah, because this is happening while the notifiers are being served. > Can you debug it a bit to go to the exact notifier routine where this > crashes? What should I do to debug it? Is that necessary to recompile kernel with full debug? > Which patch are you talking about here? I thought about this one [1], but I guess that's not my case. [1] https://lkml.org/lkml/2014/7/16/815 -- Oleksandr post-factum Natalenko, MSc pf-kernel community https://natalenko.name/ -- 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: Remove ACCESS_ONCE() for jiffies
On Mon, Aug 11, 2014 at 06:51:41PM -0400, Pranith Kumar wrote: > jiffies is declared as a volatile variable. Therefore it is not neccessary to > use ACCESS_ONCE() while reading it. It also doesn't hurt and it documents intent, so I'm inclined to keep it. pgp8tFMX2calj.pgp Description: PGP signature
Re: [PATCH 34/41] perf evlist: Add 'system_wide' option
On 08/11/2014 04:12 PM, Jiri Olsa wrote:
> On Mon, Jul 14, 2014 at 01:02:58PM +0300, Adrian Hunter wrote:
>> Add an option to cause a selected event
>> to be opened always without a pid when
>> configured by perf_evsel__config().
>>
>> This is needed when using the sched_switch
>> tracepoint to follow object code execution.
>> sched_switch occurs before the task
>> switch and so it cannot record it in a
>> context limited to that task. Note
>> that also means that sched_switch is
>> useless when capturing data per-thread,
>> as is the 'context-switches' software
>> event for the same reason.
>>
>> Signed-off-by: Adrian Hunter
>> ---
>> tools/perf/util/evlist.c | 45 +
>> tools/perf/util/evsel.c | 31 ++-
>> tools/perf/util/evsel.h | 1 +
>> 3 files changed, 64 insertions(+), 13 deletions(-)
>>
>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
>> index 282e83e..c295b7b 100644
>> --- a/tools/perf/util/evlist.c
>> +++ b/tools/perf/util/evlist.c
>> @@ -265,17 +265,27 @@ int perf_evlist__add_newtp(struct perf_evlist *evlist,
>> return 0;
>> }
>>
>> +static int perf_evlist__nr_threads(struct perf_evlist *evlist,
>> + struct perf_evsel *evsel)
>> +{
>> +if (evsel->system_wide)
>> +return 1;
>> +else
>> +return thread_map__nr(evlist->threads);
>> +}
>
> how is 'evsel->system_wide' set?
Intel PT sets it for the sched_switch event.
--
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: [BUG] oops in cpufreq driver with AMD Kaveri CPU
On Fri, Aug 8, 2014 at 2:23 AM, Oleksandr Natalenko wrote: > Disabling cpufreq code in kernel config works around this issue. Yeah, because this is happening while the notifiers are being served. Can you debug it a bit to go to the exact notifier routine where this crashes? > Is this bug related to sleeping in atomic context, which is caused by improper > GFP_KERNEL usage instead of GFP_ATOMIC? Should I test tat patch, or there will > be another fix? Which patch are you talking about here? -- 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] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Decoupling the dependency between hyperv_keyboard and i8042 needs > > non-trivial efforts and is hence a long term goal. > > > > For now, let's make the dependency explicit so people can beware of this. > > You didn't make anyone "aware" of this, you just prevented people from > being able to select the module unless they build the driver into the > kernel, which isn't very nice. Yes, exactly. > What exactly needs to be done to fix this "correctly" that is going to > take too much work at the moment? Hi Greg, The current implementation of hyperv-keyboard.c borrows serio_interrupt() to pass the key strokes to the high level component. serio_interrupt() actually depends on atkbd.c and i8042.c, so this doesn't work for a Generation 2 hyper-v guest because no i8042 keyboard controller is emulated: http://technet.microsoft.com/en-us/library/dn282285.aspx To decouple the dependency between the hyperv-keyboard and i8042 modules, I suppose we probably have to re-implement hyperv-keyboard by using input_allocate_device(), input_register_device(), and using input_report_key() to pass the key strokes to the high level. I'll have to need some time for further investigation and a new implementation. Before the new code is completely ready, IMHO the patch can help to avoid a bad user experience like Arch Linux working as a Generation 2 hyper-v guest. BTW, looks most of Linux distros (like RHEL, Ubuntu, SUSE) have CONFIG_SERIO_I8042=y, probably because it's the result of "make defconfig". So the patch actually doesn't affect these distros. Thanks, -- Dexuan -- 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] perf, x86: Use extended offcore mask on Haswell
On Tue, Aug 12, 2014 at 2:11 AM, Andi Kleen wrote: > From: Andi Kleen > > HSW-EP has a larger offcore mask than the client Haswell CPUs. > It is the same mask as on Sandy/IvyBridge-EP. All of > Haswell was using the client mask, so some bits were missing. > > On the client parts some bits were also missing compared > to Sandy/IvyBridge, in particular the bits to match on a L4 > cache hit. > > The Haswell core in both client and server incarnations > accepts the same bits (but some are nops), so we can use > the same mask. > > So use the snbep extended mask, which is a superset of the > client and the server, for all of Haswell. > > This allows specifying a number of extra offcore events, like > for example for HSW-EP. > > % perf stat -e > cpu/event=0xb7,umask=0x1,offcore_rsp=0x3fffc00100,name=offcore_response_pf_l3_rfo_l3_miss_any_response/ > true > > which were before. > I tested this on my HSW desktop including the bits only defined for servers and everything is fine. It does simplify the code,though desktop parts always come first, so there will always be patching. Also if this works on HSW/HSX, I wonder if we could not simplify the same code for IVB/IVT and SNB/SNBEP. Reviewed-by: Stephane Eranian > v2: Post correct patch. > Signed-off-by: Andi Kleen > --- > arch/x86/kernel/cpu/perf_event_intel.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/perf_event_intel.c > b/arch/x86/kernel/cpu/perf_event_intel.c > index 2502d0d..4648a1b 100644 > --- a/arch/x86/kernel/cpu/perf_event_intel.c > +++ b/arch/x86/kernel/cpu/perf_event_intel.c > @@ -2552,7 +2552,7 @@ __init int intel_pmu_init(void) > > x86_pmu.event_constraints = intel_hsw_event_constraints; > x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints; > - x86_pmu.extra_regs = intel_snb_extra_regs; > + x86_pmu.extra_regs = intel_snbep_extra_regs; > x86_pmu.pebs_aliases = intel_pebs_aliases_snb; > /* all extra regs are per-cpu when HT is on */ > x86_pmu.er_flags |= ERF_HAS_RSP_1; > -- > 1.9.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 tip/core/rcu 1/2] rcu: Parallelize and economize NOCB kthread wakeups
On (Mon) 11 Aug 2014 [20:45:31], Paul E. McKenney wrote: > On Mon, Aug 11, 2014 at 01:34:21PM -0700, Paul E. McKenney wrote: > > On Tue, Aug 12, 2014 at 01:48:45AM +0530, Amit Shah wrote: > > > On (Mon) 11 Aug 2014 [13:11:02], Paul E. McKenney wrote: > > > > On Tue, Aug 12, 2014 at 01:11:26AM +0530, Amit Shah wrote: > > > > > On (Mon) 11 Aug 2014 [09:28:07], Paul E. McKenney wrote: > > > > > > On Mon, Aug 11, 2014 at 12:43:08PM +0530, Amit Shah wrote: > > > > > > > On (Fri) 08 Aug 2014 [14:46:48], Paul E. McKenney wrote: > > > > > > > > On Fri, Aug 08, 2014 at 02:43:47PM -0700, Paul E. McKenney > > > > > > > > wrote: > > > > > > > > > On Sat, Aug 09, 2014 at 12:04:24AM +0530, Amit Shah wrote: > > > > > > > > > > On (Fri) 08 Aug 2014 [11:18:35], Paul E. McKenney wrote: > > > > > > > > > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > > > > > > > > Hmmm... What happens if you boot > > > > > > > > > > > a7d7a143d0b4cb1914705884ca5c25e322dba693 > > > > > > > > > > > with the kernel parameter "acpi=off"? > > > > > > > > > > > > > > > > > > > > That doesn't change anything - still hangs. > > > > > > > > > > > > > > > > > > > > I intend to look at this more on Monday, though - turning > > > > > > > > > > in for > > > > > > > > > > today. In the meantime, if there's anything else you'd > > > > > > > > > > like me to > > > > > > > > > > try, please let me know. > > > > > > > > > > > > > > > > > > OK, given that I still cannot reproduce it, I do need your > > > > > > > > > help with > > > > > > > > > the diagnostics. And so what sorts of diagnostics work for > > > > > > > > > you in > > > > > > > > > the hung state? Are you able to dump ftrace buffers? > > > > > > > > > > > > > > > > > > If you are able to dump ftrace buffers, please enable > > > > > > > > > rcu:rcu_nocb_wake > > > > > > > > > and send me the resulting trace. > > > > > > > > > > > > > > > > And another random kernel boot parameter to try is > > > > > > > > rcu_nocb_poll. > > > > > > > > > > > > > > Right, this gets the boot going again: > > > > > > > > > > > > OK, that likely indicates a lost wakeup. The event tracing enabled > > > > > > by > > > > > > "rcu:rcu_nocb_wake" should help track those down. Last time, it > > > > > > was qemu > > > > > > losing the wakeups, but maybe it is RCU this time. ;-) > > > > > > > > > > The guest goes dead pretty early; is there a trick to enabling and > > > > > getting these traces out of the guest that I don't know of that > > > > > doesn't involve being booted into userspace? I can perhaps try > > > > > getting the trace output out from a virtio-serial channel; but even > > > > > that driver isn't probed yet when the lockup happens. > > > > > > > > First boot with the kernel parameter "trace_event=rcu:rcu_nocb_wake". > > > > Then when the system hangs, do "sendkey alt-sysrq-z" at the "(qemu)" > > > > prompt to dump the ftrace buffer. This hopefully dumps the trace buffer > > > > to dmesg. > > > > > > > > In addition "sendkey alt-sysrq-t" at the "(qemu)" prompt dumps all > > > > tasks' > > > > stacks, which would also likely be useful information. > > > > > > Nah, this doesn't work -- the guest's totally locked up. I need a way > > > to continuously dump buffers till the lockup happens, I suppose. > > > > That is a bit surprising. Is it possible that the system is OOMing > > quickly due to grace periods not proceeding? If so, maybe giving the > > VM more memory would help. > > Oh, and it is necessary to build the kernel with CONFIG_RCU_TRACE=y > for the rcu_nocb_wake trace events to be enabled in the first place. > I am assuming that your kernel was built with CONFIG_MAGIC_SYSRQ=y. Yes, it is :-) I checked the rcu_nocb_poll cmdline option does indeed dump all the ftrace buffers to dmesg. > If all of that is in place and no joy, is it possible to extract the > ftrace buffer from the running/hung guest? It should be in there > somewhere! ;-) I know of only virtio-console doing this (via userspace only, though). Amit -- 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: [3.16 stable PATCH 1/1] virtio-rng: fix multi-device startup
On (Tue) 12 Aug 2014 [06:55:27], Greg KH wrote: > On Mon, Aug 11, 2014 at 06:11:47PM +0530, Amit Shah wrote: > > This is a 3.16-only patch. The linux.git fix is > > 5c06273401f2eb7b290cadbae18ee00f8f65e893, which fixes this issue in a > > different way. > > Why "different"? Why can't I take that original patch instead? What is > different in this patch, and why? The commit referenced moves the hwrng_register() call to the ->scan() callback instead of it being in probe(). This was done to ensure the virtio-rng devices can contribute to the initial system entropy introduced in commit d9e7972619334. That patch is quite small too, but will need a slight conflict resolution due to the previous two code-shuffling patches, and also the following revert. However, I decided against the backport of the ->scan() method, since it wasn't designed to solve this regression, it happens to solve it, and it actually introduces new functionality. I would be happy to provide a backport of the relevant patches, if you think that would be alright. Thanks, Amit -- 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 2/2] check if crashk_res_low exists when exclude it from crash mem ranges
Add a check if crashk_res_low exists just like GART region does. If
crashk_res_low doesn't exist, calling exclude_mem_range is unnecessary.
Meanwhile, since crashk_res_low has been initialized at definition, it's
safe just use "if (crashk_low_res.end)" to check if it's exist. And this
can make it consistent with other places of check.
Signed-off-by: Baoquan He
---
arch/x86/kernel/crash.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 0553a34..c9e83f9 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -238,7 +238,7 @@ static void fill_up_crash_elf_data(struct crash_elf_data
*ced,
ced->max_nr_ranges++;
/* If crashk_low_res is not 0, another range split possible */
- if (crashk_low_res.end != 0)
+ if (crashk_low_res.end)
ced->max_nr_ranges++;
}
@@ -336,9 +336,11 @@ static int elf_header_exclude_ranges(struct crash_elf_data
*ced,
if (ret)
return ret;
- ret = exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
- if (ret)
- return ret;
+ if (crashk_low_res.end) {
+ ret = exclude_mem_range(cmem, crashk_low_res.start,
crashk_low_res.end);
+ if (ret)
+ return ret;
+ }
/* Exclude GART region */
if (ced->gart_end) {
--
1.8.5.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/
[PATCH 1/2] take the segment adding out of locate_mem_hole functions
In locate_mem_hole functions, a memory hole is located and added as
kexec_segment. But from the name of locate_mem_hole, it should only
take responsibility of searching a available memory hole to contain
data of a specified size.
So in this patch add a new field 'mem' into kexec_buf, then take that
kexec segment adding code out of locate_mem_hole_top_down and
locate_mem_hole_bottom_up. This make clear of the functionality of
locate_mem_hole just like it declars to do. And by this
locate_mem_hole_callback chould be used later if anyone want to locate
a memory hole for other use.
Signed-off-by: Baoquan He
---
include/linux/kexec.h | 1 +
kernel/kexec.c| 9 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 4b2a0e1..9d957b7 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -178,6 +178,7 @@ struct kexec_buf {
struct kimage *image;
char *buffer;
unsigned long bufsz;
+ unsigned long mem;
unsigned long memsz;
unsigned long buf_align;
unsigned long buf_min;
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 0b49a0a..586444e 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -2054,8 +2054,7 @@ static int locate_mem_hole_top_down(unsigned long start,
unsigned long end,
} while (1);
/* If we are here, we found a suitable memory range */
- __kexec_add_segment(image, kbuf->buffer, kbuf->bufsz, temp_start,
- kbuf->memsz);
+ kbuf->mem = temp_start;
/* Success, stop navigating through remaining System RAM ranges */
return 1;
@@ -2089,8 +2088,7 @@ static int locate_mem_hole_bottom_up(unsigned long start,
unsigned long end,
} while (1);
/* If we are here, we found a suitable memory range */
- __kexec_add_segment(image, kbuf->buffer, kbuf->bufsz, temp_start,
- kbuf->memsz);
+ kbuf->mem = temp_start;
/* Success, stop navigating through remaining System RAM ranges */
return 1;
@@ -2176,6 +2174,9 @@ int kexec_add_buffer(struct kimage *image, char *buffer,
unsigned long bufsz,
return -EADDRNOTAVAIL;
}
+ __kexec_add_segment(image, kbuf->buffer, kbuf->bufsz, kbuf->mem,
+ kbuf->memsz);
+
/* Found a suitable memory range */
ksegment = >segment[image->nr_segments - 1];
*load_addr = ksegment->mem;
--
1.8.5.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 tip/core/rcu 1/2] rcu: Parallelize and economize NOCB kthread wakeups
On (Mon) 11 Aug 2014 [13:34:21], Paul E. McKenney wrote: > On Tue, Aug 12, 2014 at 01:48:45AM +0530, Amit Shah wrote: > > On (Mon) 11 Aug 2014 [13:11:02], Paul E. McKenney wrote: > > > On Tue, Aug 12, 2014 at 01:11:26AM +0530, Amit Shah wrote: > > > > On (Mon) 11 Aug 2014 [09:28:07], Paul E. McKenney wrote: > > > > > On Mon, Aug 11, 2014 at 12:43:08PM +0530, Amit Shah wrote: > > > > > > On (Fri) 08 Aug 2014 [14:46:48], Paul E. McKenney wrote: > > > > > > > On Fri, Aug 08, 2014 at 02:43:47PM -0700, Paul E. McKenney wrote: > > > > > > > > On Sat, Aug 09, 2014 at 12:04:24AM +0530, Amit Shah wrote: > > > > > > > > > On (Fri) 08 Aug 2014 [11:18:35], Paul E. McKenney wrote: > > > > > > > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > > > > > > Hmmm... What happens if you boot > > > > > > > > > > a7d7a143d0b4cb1914705884ca5c25e322dba693 > > > > > > > > > > with the kernel parameter "acpi=off"? > > > > > > > > > > > > > > > > > > That doesn't change anything - still hangs. > > > > > > > > > > > > > > > > > > I intend to look at this more on Monday, though - turning in > > > > > > > > > for > > > > > > > > > today. In the meantime, if there's anything else you'd like > > > > > > > > > me to > > > > > > > > > try, please let me know. > > > > > > > > > > > > > > > > OK, given that I still cannot reproduce it, I do need your help > > > > > > > > with > > > > > > > > the diagnostics. And so what sorts of diagnostics work for you > > > > > > > > in > > > > > > > > the hung state? Are you able to dump ftrace buffers? > > > > > > > > > > > > > > > > If you are able to dump ftrace buffers, please enable > > > > > > > > rcu:rcu_nocb_wake > > > > > > > > and send me the resulting trace. > > > > > > > > > > > > > > And another random kernel boot parameter to try is rcu_nocb_poll. > > > > > > > > > > > > Right, this gets the boot going again: > > > > > > > > > > OK, that likely indicates a lost wakeup. The event tracing enabled by > > > > > "rcu:rcu_nocb_wake" should help track those down. Last time, it was > > > > > qemu > > > > > losing the wakeups, but maybe it is RCU this time. ;-) > > > > > > > > The guest goes dead pretty early; is there a trick to enabling and > > > > getting these traces out of the guest that I don't know of that > > > > doesn't involve being booted into userspace? I can perhaps try > > > > getting the trace output out from a virtio-serial channel; but even > > > > that driver isn't probed yet when the lockup happens. > > > > > > First boot with the kernel parameter "trace_event=rcu:rcu_nocb_wake". > > > Then when the system hangs, do "sendkey alt-sysrq-z" at the "(qemu)" > > > prompt to dump the ftrace buffer. This hopefully dumps the trace buffer > > > to dmesg. > > > > > > In addition "sendkey alt-sysrq-t" at the "(qemu)" prompt dumps all tasks' > > > stacks, which would also likely be useful information. > > > > Nah, this doesn't work -- the guest's totally locked up. I need a way > > to continuously dump buffers till the lockup happens, I suppose. > > That is a bit surprising. Is it possible that the system is OOMing > quickly due to grace periods not proceeding? If so, maybe giving the > VM more memory would help. I bumped it up to 1G and then 2G, same result. Amit -- 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/1] virtio: rng: add derating factor for use by hwrng core
On (Mon) 11 Aug 2014 [15:11:03], H. Peter Anvin wrote: > On 08/11/2014 11:49 AM, Amit Shah wrote: > > The khwrngd thread is started when a hwrng device of sufficient > > quality is registered. The virtio-rng device is backed by the > > hypervisor, and we trust the hypervisor to provide real entropy. A > > malicious hypervisor is a scenario that's ruled out, so we are certain > > the quality of randomness we receive is perfectly trustworthy. Hence, > > we use 100% for the factor, indicating maximum confidence in the source. > > > > Signed-off-by: Amit Shah > > It isn't "ruled out", it is just irrelevant: if the hypervisor is > malicious, the quality of your random number source is the least of your > problems. Yea; I meant ruled out in that sense. Should the commit msg be more verbose? Amit -- 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] smsc: replace WARN_ON() with WARN_ON_SMP()
Thanks ! -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Tuesday, August 12, 2014 3:09 AM To: Sharma, Sanjeev Cc: gre...@linuxfoundation.org; steve.glendinn...@shawell.net; net...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] smsc: replace WARN_ON() with WARN_ON_SMP() From: Sanjeev Sharma Date: Mon, 11 Aug 2014 13:46:23 +0530 > spin_is_locked() always return false in uniprocessor configuration and > therefore it would be advise to repalce with WARN_ON_SMP(). > > Signed-off-by: Sanjeev Sharma This looks fine, applied, 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] Made bpf_internal_load_pointer_neg_helper static: fixes Sparse warning
On 08/12/2014 02:57 AM, Alexei Starovoitov wrote: On Mon, Aug 11, 2014 at 3:00 PM, Benjamin Lee wrote: I wanted to know what the current status of my patch is since my internship will be ending this Friday and I want to know before then. if there are any problems with it I can fix them before Thursday. Thank you in advance. using scripts/get_maintainer.pl for cc list would have helped to receive response sooner. On Fri, 2014-07-18 at 11:34 -0700, Benjamin Lee wrote: This patch fixes the following Sparse warning: net/core/filter.c:52:6: warning: symbol 'bpf_internal_load_pointer_neg_helper' was not declared. Should it be static? I declared bpf_internal_load_pointer_neg_helper as static because it is not referenced elsewhere in the kernel. The patched kernel boots the patch is incorrect, since this function is called out of assembler. Try 'git grep bpf_internal_load_pointer_neg_helper' Agreed. -- 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] mm/isolation: close the two race problems related to pageblock isolation
On Wed, Aug 06, 2014 at 04:18:33PM +0900, Joonsoo Kim wrote:
> We got migratetype of the freeing page without holding the zone lock so
> it could be racy. There are two cases of this race.
>
> 1. pages are added to isolate buddy list after restoring original
> migratetype.
> 2. pages are added to normal buddy list while pageblock is isolated.
>
> If case 1 happens, we can't allocate freepages on isolate buddy list
> until next pageblock isolation occurs.
> In case of 2, pages could be merged with pages on isolate buddy list and
> located on normal buddy list. This makes freepage counting incorrect
> and break the property of pageblock isolation.
>
> One solution to this problem is checking pageblock migratetype with
> holding zone lock in __free_one_page() and I posted it before, but,
> it didn't get welcome since it needs the hook in zone lock critical
> section on freepath.
I didn't review your v1 but IMHO, this patchset is rather complex.
Normally, we don't like adding more overhead in fast path but we did
several time on hotplug/cma, esp so I don't know a few more thing is
really hesitant. In addition, you proved by this patchset how this
isolation code looks ugly and fragile for race problem so I vote
adding more overhead in fast path if it can make code really simple.
Vlastimil?
To Joonsoo,
you want to send this patchset for stable since review is done?
IIRC, you want to fix freepage couting bug and send it to stable but
as I see this patchset, no make sense to send to stable. :(
>
> This is another solution to this problem and impose most overhead on
> pageblock isolation logic. Following is how this solution works.
>
> 1. Extends irq disabled period on freepath to call
> get_pfnblock_migratetype() with irq disabled. With this, we can be
> sure that future freed pages will see modified pageblock migratetype
> after certain synchronization point so we don't need to hold the zone
> lock to get correct pageblock migratetype. Although it extends irq
> disabled period on freepath, I guess it is marginal and better than
> adding the hook in zone lock critical section.
Agreed.
>
> 2. #1 requires IPI for synchronization and we can't hold the zone lock
> during processing IPI. In this time, some pages could be moved from buddy
> list to pcp list on page allocation path and later it could be moved again
> from pcp list to buddy list. In this time, this page would be on isolate
> pageblock, so, the hook is required on free_pcppages_bulk() to prevent
> misplacement. To remove this possibility, disabling and draining pcp
> list is needed during isolation. It guaratees that there is no page on pcp
> list on all cpus while isolation, so misplacement problem can't happen.
>
> Note that this doesn't fix freepage counting problem. To fix it,
> we need more logic. Following patches will do it.
I hope to revise description in next spin. It's very hard to parse for
stupid me.
>
> Signed-off-by: Joonsoo Kim
> ---
> mm/internal.h |2 ++
> mm/page_alloc.c | 27 ---
> mm/page_isolation.c | 45 +
> 3 files changed, 55 insertions(+), 19 deletions(-)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index a1b651b..81b8884 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -108,6 +108,8 @@ extern pmd_t *mm_find_pmd(struct mm_struct *mm, unsigned
> long address);
> /*
> * in mm/page_alloc.c
> */
> +extern void zone_pcp_disable(struct zone *zone);
> +extern void zone_pcp_enable(struct zone *zone);
Nit: Some of pcp functions has prefix zone but others don't.
Which is better? If function has param zone as first argument,
I think it's clear unless the function don't have prefix zone.
> extern void __free_pages_bootmem(struct page *page, unsigned int order);
> extern void prep_compound_page(struct page *page, unsigned long order);
> #ifdef CONFIG_MEMORY_FAILURE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3e1e344..4517b1d 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -726,11 +726,7 @@ static void free_pcppages_bulk(struct zone *zone, int
> count,
> /* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
> __free_one_page(page, page_to_pfn(page), zone, 0, mt);
> trace_mm_page_pcpu_drain(page, 0, mt);
> - if (likely(!is_migrate_isolate_page(page))) {
> - __mod_zone_page_state(zone, NR_FREE_PAGES, 1);
> - if (is_migrate_cma(mt))
> - __mod_zone_page_state(zone,
> NR_FREE_CMA_PAGES, 1);
> - }
> + __mod_zone_freepage_state(zone, 1, mt);
> } while (--to_free && --batch_free && !list_empty(list));
> }
> spin_unlock(>lock);
> @@ -789,8 +785,8 @@ static void __free_pages_ok(struct page *page, unsigned
> int order)
> if (!free_pages_prepare(page,
[PATCH v4] kprobes: arm: enable OPTPROBES for ARM 32
This patch introduce kprobeopt for ARM 32.
Limitations:
- Currently only kernel compiled with ARM ISA is supported.
- Offset between probe point and optinsn slot must not larger than
32MiB. Masami Hiramatsu suggests replacing 2 words, it will make
things complex. Futher patch can make such optimization.
Kprobe opt on ARM is relatively simpler than kprobe opt on x86 because
ARM instruction is always 4 bytes aligned and 4 bytes long. This patch
replace probed instruction by a 'b', branch to trampoline code and then
calls optimized_callback(). optimized_callback() calls opt_pre_handler()
to execute kprobe handler. It also emulate/simulate replaced instruction.
When unregistering kprobe, the deferred manner of unoptimizer may leave
branch instruction before optimizer is called. Different from x86_64,
which only copy the probed insn after optprobe_template_end and
reexecute them, this patch call singlestep to emulate/simulate the insn
directly. Futher patch can optimize this behavior.
v1 -> v2:
- Improvement: if replaced instruction is conditional, generate a
conditional branch instruction for it;
- Introduces RELATIVEJUMP_OPCODES due to ARM kprobe_opcode_t is 4
bytes;
- Removes size field in struct arch_optimized_insn;
- Use arm_gen_branch() to generate branch instruction;
- Remove all recover logic: ARM doesn't use tail buffer, no need
recover replaced instructions like x86;
- Remove incorrect CONFIG_THUMB checking;
- can_optimize() always returns true if address is well aligned;
- Improve optimized_callback: using opt_pre_handler();
- Bugfix: correct range checking code and improve comments;
- Fix commit message.
v2 -> v3:
- Rename RELATIVEJUMP_OPCODES to MAX_COPIED_INSNS;
- Remove unneeded checking:
arch_check_optimized_kprobe(), can_optimize();
- Add missing flush_icache_range() in arch_prepare_optimized_kprobe();
- Remove unneeded 'return;'.
v3 -> v4:
- Use __mem_to_opcode_arm() to translate copied_insn to ensure it
works in big endian kernel;
- Replace 'nop' placeholder in trampoline code template with
'.long 0' to avoid confusion: reader may regard 'nop' as an
instruction, but it is value in fact.
Signed-off-by: Wang Nan
Cc: Masami Hiramatsu
Cc: Jon Medhurst (Tixy)
Cc: Russell King - ARM Linux
Cc: Will Deacon
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/kprobes.h | 26 +
arch/arm/kernel/Makefile | 3 +-
arch/arm/kernel/kprobes-opt.c | 255 +
4 files changed, 284 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/kernel/kprobes-opt.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 290f02ee..2106918 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -57,6 +57,7 @@ config ARM
select HAVE_MEMBLOCK
select HAVE_MOD_ARCH_SPECIFIC if ARM_UNWIND
select HAVE_OPROFILE if (HAVE_PERF_EVENTS)
+ select HAVE_OPTPROBES if (!THUMB2_KERNEL)
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index 49fa0df..a05297f 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -51,5 +51,31 @@ int kprobe_fault_handler(struct pt_regs *regs, unsigned int
fsr);
int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
+/* optinsn template addresses */
+extern __visible kprobe_opcode_t optprobe_template_entry;
+extern __visible kprobe_opcode_t optprobe_template_val;
+extern __visible kprobe_opcode_t optprobe_template_call;
+extern __visible kprobe_opcode_t optprobe_template_end;
+
+#define MAX_OPTIMIZED_LENGTH (4)
+#define MAX_OPTINSN_SIZE \
+ (((unsigned long)_template_end - \
+ (unsigned long)_template_entry))
+#define RELATIVEJUMP_SIZE (4)
+
+struct arch_optimized_insn {
+ /*
+* copy of the original instructions.
+* Different from x86, ARM kprobe_opcode_t is u32.
+*/
+#define MAX_COPIED_INSN((RELATIVEJUMP_SIZE) / sizeof(kprobe_opcode_t))
+ kprobe_opcode_t copied_insn[MAX_COPIED_INSN];
+ /* detour code buffer */
+ kprobe_opcode_t *insn;
+ /*
+* we always copies one instruction on arm32,
+* size always be 4, so no size field.
+*/
+};
#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 38ddd9f..6a38ec1 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -52,11 +52,12 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o insn.o
obj-$(CONFIG_JUMP_LABEL) += jump_label.o insn.o patch.o
obj-$(CONFIG_KEXEC)+= machine_kexec.o relocate_kernel.o
obj-$(CONFIG_UPROBES) += probes.o probes-arm.o uprobes.o uprobes-arm.o
-obj-$(CONFIG_KPROBES) += probes.o kprobes.o kprobes-common.o
[PATCH v2] mmc: core: Remove fixed voltage regulator logic
There is no need for regulator consumers to include special logic for
fixed voltage regulators as they support regulator_set_voltage() just
like their non-fixed regulator counterparts.
Signed-off-by: Tim Kryger
---
Changes in v2:
- Remove query of the current voltage, just set the desired voltage
This simplification of logic is possible due to a recent change that
allows fixed regulators to return success for regulator_set_voltage
operations if the requested range overlaps with the fixed voltage.
c00dc35 regulator: core: Allow regulator_set_voltage for fixed regulators
I have verified this change on a BeagleBone Black where the eMMC and SD
card receive a fixed 3.3v supply. The TI HSMMC driver used on the BBB,
like the Intel PXA MMC driver, ensures that software only requests VMMC
be set to supported voltage ranges by calling mmc_regulator_get_ocrmask.
This function considers the capabilities of the regulator in order to
determine an appropriate OCR mask of supported voltages that constrains
the set of values which may later be passed into mmc_regulator_set_ocr.
Once the following (queued) patch is merged, the SDHCI driver will call
mmc_regulator_get_supply which then calls mmc_regulator_get_ocrmask.
https://lkml.org/lkml/2014/6/13/451
The Atmel, ARM, Freescale MXC, SuperH Internal MMCIF, Allwinner sunxi,
Toshiba Mobile IO Controller, and Renesas USDHI6ROL0 drivers already
call mmc_regulator_get_supply so they too only request voltages that
are achievable.
There are no other callers of mmc_regulator_set_ocr so this patch should
be safe.
drivers/mmc/core/core.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 7dc0c85..1a3e35b 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1263,7 +1263,6 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
if (vdd_bit) {
int tmp;
- int voltage;
/*
* REVISIT mmc_vddrange_to_ocrmask() may have set some
@@ -1280,22 +1279,7 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
max_uV = min_uV + 100 * 1000;
}
- /*
-* If we're using a fixed/static regulator, don't call
-* regulator_set_voltage; it would fail.
-*/
- voltage = regulator_get_voltage(supply);
-
- if (!regulator_can_change_voltage(supply))
- min_uV = max_uV = voltage;
-
- if (voltage < 0)
- result = voltage;
- else if (voltage < min_uV || voltage > max_uV)
- result = regulator_set_voltage(supply, min_uV, max_uV);
- else
- result = 0;
-
+ result = regulator_set_voltage(supply, min_uV, max_uV);
if (result == 0 && !mmc->regulator_enabled) {
result = regulator_enable(supply);
if (!result)
--
1.7.9.5
--
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 2/2] kvm: x86: fix stale mmio cache bug
From: David Matlack
The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:
(1) Guest accesses gpa X without a memory slot. The gfn is cached in
struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets
the SPTE write-execute-noread so that future accesses cause
EPT_MISCONFIGs.
(2) Host userspace creates a memory slot via KVM_SET_USER_MEMORY_REGION
covering the page just accessed.
(3) Guest attempts to read or write to gpa X again. On Intel, this
generates an EPT_MISCONFIG. The memory slot generation number that
was incremented in (2) would normally take care of this but we fast
path mmio faults through quickly_check_mmio_pf(), which only checks
the per-vcpu mmio cache. Since we hit the cache, KVM passes a
KVM_EXIT_MMIO up to userspace.
This patch fixes the issue by using the memslot generation number
to validate the mmio cache.
[ xiaoguangrong: adjust the code to make it simpler for stable-tree fix. ]
Cc: sta...@vger.kernel.org
Signed-off-by: David Matlack
Signed-off-by: Xiao Guangrong
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/mmu.c | 4 ++--
arch/x86/kvm/mmu.h | 2 ++
arch/x86/kvm/x86.h | 19 +++
4 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 5724601..58fa3ab 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -481,6 +481,7 @@ struct kvm_vcpu_arch {
u64 mmio_gva;
unsigned access;
gfn_t mmio_gfn;
+ unsigned int mmio_gen;
struct kvm_pmu pmu;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 9314678..e00fbfe 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -234,7 +234,7 @@ static unsigned int get_mmio_spte_generation(u64 spte)
return gen;
}
-static unsigned int kvm_current_mmio_generation(struct kvm *kvm)
+unsigned int kvm_current_mmio_generation(struct kvm *kvm)
{
/*
* Init kvm generation close to MMIO_MAX_GEN to easily test the
@@ -3163,7 +3163,7 @@ static void mmu_sync_roots(struct kvm_vcpu *vcpu)
if (!VALID_PAGE(vcpu->arch.mmu.root_hpa))
return;
- vcpu_clear_mmio_info(vcpu, ~0ul);
+ vcpu_clear_mmio_info(vcpu, MMIO_GVA_ANY);
kvm_mmu_audit(vcpu, AUDIT_PRE_SYNC);
if (vcpu->arch.mmu.root_level == PT64_ROOT_LEVEL) {
hpa_t root = vcpu->arch.mmu.root_hpa;
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index b982112..e2d902a 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -76,6 +76,8 @@ enum {
};
int handle_mmio_page_fault_common(struct kvm_vcpu *vcpu, u64 addr, bool
direct);
+unsigned int kvm_current_mmio_generation(struct kvm *kvm);
+
void kvm_init_shadow_mmu(struct kvm_vcpu *vcpu, struct kvm_mmu *context);
void kvm_init_shadow_ept_mmu(struct kvm_vcpu *vcpu, struct kvm_mmu *context,
bool execonly);
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index 306a1b7..ffd03b7 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -3,6 +3,7 @@
#include
#include "kvm_cache_regs.h"
+#include "mmu.h"
static inline void kvm_clear_exception_queue(struct kvm_vcpu *vcpu)
{
@@ -88,15 +89,23 @@ static inline void vcpu_cache_mmio_info(struct kvm_vcpu
*vcpu,
vcpu->arch.mmio_gva = gva & PAGE_MASK;
vcpu->arch.access = access;
vcpu->arch.mmio_gfn = gfn;
+ vcpu->arch.mmio_gen = kvm_current_mmio_generation(vcpu->kvm);
+}
+
+static inline bool vcpu_match_mmio_gen(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.mmio_gen == kvm_current_mmio_generation(vcpu->kvm);
}
/*
* Clear the mmio cache info for the given gva,
- * specially, if gva is ~0ul, we clear all mmio cache info.
+ * specially, if gva is ~MMIO_GVA_ANY, we clear all mmio cache info.
*/
+#define MMIO_GVA_ANY ~((gva_t)0)
+
static inline void vcpu_clear_mmio_info(struct kvm_vcpu *vcpu, gva_t gva)
{
- if (gva != (~0ul) && vcpu->arch.mmio_gva != (gva & PAGE_MASK))
+ if (gva != MMIO_GVA_ANY && vcpu->arch.mmio_gva != (gva & PAGE_MASK))
return;
vcpu->arch.mmio_gva = 0;
@@ -104,7 +113,8 @@ static inline void vcpu_clear_mmio_info(struct kvm_vcpu
*vcpu, gva_t gva)
static inline bool vcpu_match_mmio_gva(struct kvm_vcpu *vcpu, unsigned long
gva)
{
- if (vcpu->arch.mmio_gva && vcpu->arch.mmio_gva == (gva & PAGE_MASK))
+ if (vcpu_match_mmio_gen(vcpu) && vcpu->arch.mmio_gva &&
+ vcpu->arch.mmio_gva == (gva & PAGE_MASK))
return true;
return false;
@@ -112,7 +122,8 @@ static inline bool vcpu_match_mmio_gva(struct kvm_vcpu
*vcpu, unsigned long gva)
static inline bool vcpu_match_mmio_gpa(struct kvm_vcpu *vcpu, gpa_t gpa)
{
- if (vcpu->arch.mmio_gfn && vcpu->arch.mmio_gfn == gpa >> PAGE_SHIFT)
+ if (vcpu_match_mmio_gen(vcpu) && vcpu->arch.mmio_gfn &&
+
[PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number
We may cache the current mmio generation number and stale memslot info
into spte, like this scenario：
CPU 0 CPU 1
page fault:add a new memslot
read memslot and detecting its a mmio access
update memslots
update generation number
read generation number
cache the gpa and current gen number into spte
So, if guest accesses the gpa later, it will generate a incorrect
mmio exit
This patch fixes it by updating the generation number after
synchronize_srcu_expedited() that makes sure the generation
number updated only if memslots update is finished
Cc: sta...@vger.kernel.org
Cc: David Matlack
Signed-off-by: Xiao Guangrong
---
virt/kvm/kvm_main.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 33712fb..ca3cdac 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -96,7 +96,7 @@ static void hardware_disable_all(void);
static void kvm_io_bus_destroy(struct kvm_io_bus *bus);
static void update_memslots(struct kvm_memslots *slots,
- struct kvm_memory_slot *new, u64 last_generation);
+ struct kvm_memory_slot *new);
static void kvm_release_pfn_dirty(pfn_t pfn);
static void mark_page_dirty_in_slot(struct kvm *kvm,
@@ -687,8 +687,7 @@ static void sort_memslots(struct kvm_memslots *slots)
}
static void update_memslots(struct kvm_memslots *slots,
- struct kvm_memory_slot *new,
- u64 last_generation)
+ struct kvm_memory_slot *new)
{
if (new) {
int id = new->id;
@@ -699,8 +698,6 @@ static void update_memslots(struct kvm_memslots *slots,
if (new->npages != npages)
sort_memslots(slots);
}
-
- slots->generation = last_generation + 1;
}
static int check_memory_region_flags(struct kvm_userspace_memory_region *mem)
@@ -722,9 +719,10 @@ static struct kvm_memslots *install_new_memslots(struct
kvm *kvm,
{
struct kvm_memslots *old_memslots = kvm->memslots;
- update_memslots(slots, new, kvm->memslots->generation);
+ update_memslots(slots, new);
rcu_assign_pointer(kvm->memslots, slots);
synchronize_srcu_expedited(>srcu);
+ slots->generation++;
kvm_arch_memslots_updated(kvm);
--
1.8.3.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/
x86: vmalloc and THP
Hello, Does memory allocated using vmalloc() will be mapped using huge pages either directly or later by THP ? If not, is there any fast way to change this behavior ? Maybe by changing the granularity/alignment of such allocations to allow such mapping ? Thanks, Oren Twaig. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.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/
linux-next: Tree for Aug 12
Hi all, Please do not add code intended for v3.18 until after v3.17-rc1 is released. Changes since 20140811: The pm tree lost its build failure. The mmc-uh tree lost its build failure. Non-merge commits (relative to Linus' tree): 1616 1064 files changed, 35102 insertions(+), 16638 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 220 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (c8d6637d0497 Merge tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux) Merging fixes/master (23cf8d3ca0fd powerpc: Fix "attempt to move .org backwards" error) Merging kbuild-current/rc-fixes (dd5a6752ae7d firmware: Create directories for external firmware) Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4) Merging arm-current/fixes (e57e41931134 ARM: wire up memfd_create syscall) Merging m68k-current/for-linus (9117710a5997 m68k/sun3: Remove define statement no longer needed) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (08a9c3c9afcf MIPS: OCTEON: make get_system_type() thread-safe) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging sparc/master (caa9199b0efd sparc: Hook up seccomp and getrandom system calls.) Merging net/master (61dac43ee6be Merge branch 'bcmgenet') Merging ipsec/master (a0e5ef53aac8 xfrm: Fix installation of AH IPsec SAs) Merging sound-current/for-linus (e24aa0a4c5ac ALSA: hda/ca0132 - Don't try loading firmware at resume when already failed) Merging pci-current/for-linus (bf177a1eb6d1 MAINTAINERS: Update mx6 PCI driver maintainer's email) Merging wireless/master (2da2c5854ed7 net: wireless: ipw2x00: ipw2200.c: Cleaning up missing null-terminate after strncpy call) Merging driver-core.current/driver-core-linus (c489d98c8c81 Merge branch 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm) Merging tty.current/tty-linus (c489d98c8c81 Merge branch 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm) Merging usb.current/usb-linus (c489d98c8c81 Merge branch 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm) Merging usb-gadget-fixes/fixes (a8a85b01d185 usb: musb/cppi41: call musb_ep_select() before accessing an endpoint's CSR) CONFLICT (content): Merge conflict in drivers/usb/musb/musb_host.c Merging usb-serial-fixes/usb-linus (19583ca584d6 Linux 3.16) Merging staging.current/staging-linus (c309bfa9b481 Merge tag 'for-linus-20140808' of git://git.infradead.org/linux-mtd) Merging char-misc.current/char-misc-linus (c489d98c8c81 Merge branch 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm) Merging input-current/for-linus (c704b4ef1a81 Input: wacom - update the ABI doc according to latest changes) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (ce5481d01f67 crypto: drbg - fix failure of generating multiple of 2**16 bytes) Merging ide/master (a53dae49b2fe ide: use module_platform_driver()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (5a12a597a862 arm: Add devicetree fixup machine function) Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting module removal.) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git:/
[BUG] perf top: -z option does not work
Hi, My understanding is that the -z option is used to only print a profile since the last refresh. So if I have a refresh of 5s, then it prints the profile based on the samples accumulated over the last 5 seconds. The Z mode used to be available interactively. Nowadays, it seems only avail from the cmdline. But it does not work. I run a simple test. $ sudo perf top -z Then for 5s I run a cycle-burning noploop program. It shows up at the top. But when it terminates, the program still stays at the top of the profile for a long time. This is not what I'd expect. The noploop line should disappear in the next couple of refreshes after the program has terminated. I am using tip.git and seeing the problem. But it seems, it's been there for a long time. Any idea what's wrong? 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 v4 1/5] cpufreq: Don't wait for CPU to going offline to restart governor
On 12 August 2014 03:41, Saravana Kannan wrote: > Suggestions welcome. I think the current one explains the main point of this > change. Atleast we need a s/going/go >> There is a down_read() present early in this routine and we better update >> this >> at that place only. > > > I would rather not. My v1 patch series was super refactored to allow a lot of > reuse, etc. But you guys complained about the diffs being confusing (which > was a valid point). > > Also, if we are talking about refactoring this, there's room for much better > refactor at the end of the series. I will add a patch to the series to do the > refactoring. The kind of change I am suggesting you can be done in the original patch only. What we told you in the earlier reviews was to break patches into meaningful sections instead of doing everything in a single patch. > That only runs if cpu != policy->cpu. This needs to run irrespective of that. Oh yes, correct. > You mean the log in the cover letter? Will do. Coverletter isn't the right place for mentioning such important things as it never gets commited. I was talking about the commit 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: rtl8192u/ieee80211: Fix sparse ieee80211_debug_init/_exit not declared warning
On Mon, Aug 11, 2014 at 10:11:13PM -0500, Joel Pelaez Jorge wrote: > El 11/08/14 a las 17:32, Greg Kroah-Hartman escibió: > > On Mon, Aug 11, 2014 at 03:15:54PM -0700, Jeremiah Mahler wrote: > >> A sparse warning is generated about 'ieee80211_debug_init' and > >> 'ieee80211_debug_exit' not being declared. > >> > >> drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:275:12: warning: > >> symbol 'ieee80211_debug_init' was not declared. Should it be static? > >> drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:297:13: warning: > >> symbol 'ieee80211_debug_exit' was not declared. Should it be static? > >> > >> These functions are used outside of this file so using static will not > >> work. Fix the warning by declaring the functions in the header file, > >> ieee80211.h > >> > >> Signed-off-by: Jeremiah Mahler > >> Cc: Greg Kroah-Hartman > >> Cc: Teodora Baluta > >> Cc: Andrea Merello > >> Cc: Joel Pelaez Jorge > >> Cc: Bob Copeland > >> Cc: Joe Perches > >> Cc: Arnd Bergmann > >> Cc: Himangi Saraogi > >> --- > >> drivers/staging/rtl8192u/ieee80211/ieee80211.h | 6 ++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h > >> b/drivers/staging/rtl8192u/ieee80211/ieee80211.h > >> index 1040bab..9cbda69 100644 > >> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h > >> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h > >> @@ -2485,6 +2485,12 @@ extern int ieee80211_wx_set_freq(struct > >> ieee80211_device *ieee, struct iw_reques > >> extern int ieee80211_wx_get_freq(struct ieee80211_device *ieee, struct > >> iw_request_info *a, > >> union iwreq_data *wrqu, char *b); > >> > >> +/* ieee80211_module.c */ > >> +#ifdef CONFIG_IEEE80211_DEBUG > >> +extern int __init ieee80211_debug_init(void); > >> +extern void __exit ieee80211_debug_exit(void); > >> +#endif /* CONFIG_IEEE80211_DEBUG */ > >> + > > > > As it's a header file, why not always have them here, no need for the > > ifdef. > > > > And __init and __exit don't belong in a .h function prototype. > > > > thanks, > > > > greg k-h > > > The symbol ieee80211_debug_init(void) and ieee80211_debug_exit(void) are > declared as prototype in r8192U_core.c, this cause a double function > prototype. It is only a comment, it not affect anything. Check it to next > time. > > - Joel Thanks for the information Joel. While my patch does fix the sparse warning, having two duplicate function prototypes seems suboptimal as well. I will see if I can find a better way to fix this warning. -- Jeremiah Mahler jmmah...@gmail.com http://github.com/jmahler -- 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] Networking
Several networking final fixes and tidies for the merge window: 1) Changes during the merge window unintentionally took away the ability to build bluetooth modular, fix from Geert Uytterhoeven. 2) Several phy_node reference count bug fixes from Uwe Kleine-König. 3) Fix ucc_geth build failures, also from Uwe Kleine-König. 4) Fix klog false positivies when netlink messages go to network taps, by properly resetting the network header. Fix from Daniel Borkmann. 5) Sizing estimate of VF netlink messages is too small, from Jiri Benc. 6) New APM X-Gene SoC ethernet driver, from Iyappan Subramanian. 7) VLAN untagging is erroneously dependent upon whether the VLAN module is loaded or not, but there are generic dependencies that matter wrt. what can be expected as the SKB enters the stack. Make the basic untagging generic code, and do it unconditionally. From Vlad Yasevich. 8) xen-netfront only has so many slots in it's transmit queue so linearize packets that have too many frags. From Zoltan Kiss. 9) Fix suspend/resume PHY handling in bcmgenet driver, from Florian Fainelli. Please pull, thanks a lot! The following changes since commit 33caee39925b887a99a2400dc5c980097c3573f9: Merge branch 'akpm' (patchbomb from Andrew Morton) (2014-08-06 21:14:42 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to 61dac43ee6bedd8507294c7af8959157b686c221: Merge branch 'bcmgenet' (2014-08-11 15:10:17 -0700) Andreas Ruprecht (1): net: ethernet: qlogic: qlcnic: Remove duplicate object file from Makefile Anish Bhatt (1): cxgb4: IEEE fixes for DCBx state machine Daniel Borkmann (1): netlink: reset network header before passing to taps David S. Miller (3): Merge git://git.kernel.org/.../pablo/nf Merge branch 'apm_xgene' Merge branch 'bcmgenet' Florian Fainelli (4): net: bcmgenet: request and enable main clock earlier net: bcmgenet: correctly suspend and resume PHY device net: bcmgenet: update UMAC_CMD only when link is detected net: bcmgenet: correctly resume adapter from Wake-on-LAN Geert Uytterhoeven (1): 6lowpan: Allow 6LoWPAN to be modular Hariprasad Shenai (1): cxgb4: Update FW version string to match FW binary version Himangi Saraogi (10): drivers/net: ethernet: Remove typedef for struct and enum drivers/net: Remove typedefs pcnet_dev_t and hw_info_t drivers/net: Remove typedef axnet_dev_t dm9000: Remove typedef board_info_t ethernet: amd: Remove typedef local_info_t com20020_cs: Remove typedef com20020_dev_t atmel: Remove typedef atmel_priv_ioctl airo_cs: Remove typedef local_info_t hdlc: Remove typedefs from struct names wan: wanxl: Remove typedefs from struct names Iyappan Subramanian (4): MAINTAINERS: Add entry for APM X-Gene SoC ethernet driver Documentation: dts: Add bindings for APM X-Gene SoC ethernet driver dts: Add bindings for APM X-Gene SoC ethernet driver drivers: net: Add APM X-Gene SoC ethernet driver support. Jean Sacren (3): amd: xgbe: fix duplicate #include of linux/phy.h openvswitch: fix duplicate #include headers batman: fix duplicate #include of multicast.h Jiri Benc (1): rtnetlink: fix VF info size Julia Lawall (6): solos-pci: fix error return code drivers/atm/atmtcp.c: fix error return code netfilter: nf_tables: fix error return code net: axienet: delete unneeded test before of_node_put ll_temac: delete unneeded test before of_node_put fec_mpc52xx: delete unneeded test before of_node_put Michael Schmitz (1): m68k/atari: EtherNEC - ethernet support (ne) Niv Yehezkel (1): ipv4: removed redundant conditional Pablo Neira Ayuso (3): netfilter: nf_tables: uninitialize element key/data from the commit path netfilter: nf_tables: don't update chain with unset counters netfilter: don't use mutex_lock_interruptible() Rickard Strandqvist (2): net: ethernet: ti: cpmac.c: Cleaning up missing null-terminate after strncpy call net: ethernet: myricom: myri10ge: myri10ge.c: Cleaning up missing null-terminate after strncpy call Sanjeev Sharma (1): smsc: replace WARN_ON() with WARN_ON_SMP() Uwe Kleine-König (10): net: gianfar: no need to check parameter being != NULL for of_node_put net: mvneta: Fix reference counting for phy_node net: gianfar: fix reference counting for phy_node net: bcmgenet: fix reference counting for phy node net: fs_enet: fix reference counting for phy_node net: ucc_geth: drop acquired references in probe error path and remove net: ucc_geth: make probe consistently acquire a reference to the phy node net: ucc_geth: Don't use the MAC as PHY without a fixed link net:
[GIT] Sparc
Please pull to get these Sparc bug fixes, one of which was preventing successful SMP boots with mainline. The following changes since commit 85417aef44fc58b08773117ceb1bc6ca5684e973: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide (2014-08-06 09:42:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master for you to fetch changes up to 8bccf5b313180faefce38e0d1140f76e0f327d28: sparc64: Fix pcr_ops initialization and usage bugs. (2014-08-11 20:45:12 -0700) David S. Miller (3): sparc: Hook up seccomp and getrandom system calls. sparc64: Do not disable interrupts in nmi_cpu_busy() sparc64: Fix pcr_ops initialization and usage bugs. Hans Wennborg (1): sparc: fix decimal printf format specifiers prefixed with 0x arch/sparc/include/uapi/asm/unistd.h | 4 +++- arch/sparc/kernel/nmi.c | 1 - arch/sparc/kernel/perf_event.c | 7 +-- arch/sparc/kernel/process_64.c | 3 +++ arch/sparc/kernel/smp_32.c | 2 +- arch/sparc/kernel/smp_64.c | 1 - arch/sparc/kernel/systbls_32.S | 2 +- arch/sparc/kernel/systbls_64.S | 4 ++-- 8 files changed, 15 insertions(+), 9 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: [PATCH tip/core/rcu 1/2] rcu: Parallelize and economize NOCB kthread wakeups
On Mon, Aug 11, 2014 at 01:34:21PM -0700, Paul E. McKenney wrote: > On Tue, Aug 12, 2014 at 01:48:45AM +0530, Amit Shah wrote: > > On (Mon) 11 Aug 2014 [13:11:02], Paul E. McKenney wrote: > > > On Tue, Aug 12, 2014 at 01:11:26AM +0530, Amit Shah wrote: > > > > On (Mon) 11 Aug 2014 [09:28:07], Paul E. McKenney wrote: > > > > > On Mon, Aug 11, 2014 at 12:43:08PM +0530, Amit Shah wrote: > > > > > > On (Fri) 08 Aug 2014 [14:46:48], Paul E. McKenney wrote: > > > > > > > On Fri, Aug 08, 2014 at 02:43:47PM -0700, Paul E. McKenney wrote: > > > > > > > > On Sat, Aug 09, 2014 at 12:04:24AM +0530, Amit Shah wrote: > > > > > > > > > On (Fri) 08 Aug 2014 [11:18:35], Paul E. McKenney wrote: > > > > > > > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > > > > > > Hmmm... What happens if you boot > > > > > > > > > > a7d7a143d0b4cb1914705884ca5c25e322dba693 > > > > > > > > > > with the kernel parameter "acpi=off"? > > > > > > > > > > > > > > > > > > That doesn't change anything - still hangs. > > > > > > > > > > > > > > > > > > I intend to look at this more on Monday, though - turning in > > > > > > > > > for > > > > > > > > > today. In the meantime, if there's anything else you'd like > > > > > > > > > me to > > > > > > > > > try, please let me know. > > > > > > > > > > > > > > > > OK, given that I still cannot reproduce it, I do need your help > > > > > > > > with > > > > > > > > the diagnostics. And so what sorts of diagnostics work for you > > > > > > > > in > > > > > > > > the hung state? Are you able to dump ftrace buffers? > > > > > > > > > > > > > > > > If you are able to dump ftrace buffers, please enable > > > > > > > > rcu:rcu_nocb_wake > > > > > > > > and send me the resulting trace. > > > > > > > > > > > > > > And another random kernel boot parameter to try is rcu_nocb_poll. > > > > > > > > > > > > Right, this gets the boot going again: > > > > > > > > > > OK, that likely indicates a lost wakeup. The event tracing enabled by > > > > > "rcu:rcu_nocb_wake" should help track those down. Last time, it was > > > > > qemu > > > > > losing the wakeups, but maybe it is RCU this time. ;-) > > > > > > > > The guest goes dead pretty early; is there a trick to enabling and > > > > getting these traces out of the guest that I don't know of that > > > > doesn't involve being booted into userspace? I can perhaps try > > > > getting the trace output out from a virtio-serial channel; but even > > > > that driver isn't probed yet when the lockup happens. > > > > > > First boot with the kernel parameter "trace_event=rcu:rcu_nocb_wake". > > > Then when the system hangs, do "sendkey alt-sysrq-z" at the "(qemu)" > > > prompt to dump the ftrace buffer. This hopefully dumps the trace buffer > > > to dmesg. > > > > > > In addition "sendkey alt-sysrq-t" at the "(qemu)" prompt dumps all tasks' > > > stacks, which would also likely be useful information. > > > > Nah, this doesn't work -- the guest's totally locked up. I need a way > > to continuously dump buffers till the lockup happens, I suppose. > > That is a bit surprising. Is it possible that the system is OOMing > quickly due to grace periods not proceeding? If so, maybe giving the > VM more memory would help. Oh, and it is necessary to build the kernel with CONFIG_RCU_TRACE=y for the rcu_nocb_wake trace events to be enabled in the first place. I am assuming that your kernel was built with CONFIG_MAGIC_SYSRQ=y. If all of that is in place and no joy, is it possible to extract the ftrace buffer from the running/hung guest? It should be in there somewhere! ;-) Thanx, Paul -- 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: [sched] 143e1e28cb4: +17.9% aim7.jobs-per-min, -9.7% hackbench.throughput
On 08/11/2014 07:03 PM, Peter Zijlstra wrote:
>
> Now I think I see why this is; we've reduced load balancing frequency
> significantly on this machine due to:
We have also changed the value of busy_factor to 32 from 64 across all
domains. This would contribute to increased frequency of load balancing?
Regards
Preeti U Murthy
>
>
> -#define SD_SIBLING_INIT (struct sched_domain) {
> \
> - .min_interval = 1,\
> - .max_interval = 2,\
>
>
> -#define SD_MC_INIT (struct sched_domain) { \
> - .min_interval = 1,\
> - .max_interval = 4,\
>
>
> -#define SD_CPU_INIT (struct sched_domain) {\
> - .min_interval = 1,\
> - .max_interval = 4,\
>
>
> *sd = (struct sched_domain){
> .min_interval = sd_weight,
> .max_interval = 2*sd_weight,
>
> Which both increased the min and max value significantly for all domains
> involved.
>
> That said; I think we might want to do something like the below; I can
> imagine decreasing load balancing too much will negatively impact other
> workloads.
>
> Maybe slightly modified to make sure the first domain has a min_interval
> of 1.
>
> ---
> kernel/sched/core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 1211575a2208..67ed5d854da1 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6049,8 +6049,8 @@ sd_init(struct sched_domain_topology_level *tl, int cpu)
> sd_flags &= ~TOPOLOGY_SD_FLAGS;
>
> *sd = (struct sched_domain){
> - .min_interval = sd_weight,
> - .max_interval = 2*sd_weight,
> + .min_interval = max(1, sd_weight/2),
> + .max_interval = sd_weight,
> .busy_factor= 32,
> .imbalance_pct = 125,
>
> @@ -6076,7 +6076,7 @@ sd_init(struct sched_domain_topology_level *tl, int cpu)
> ,
>
> .last_balance = jiffies,
> - .balance_interval = sd_weight,
> + .balance_interval = max(1, sd_weight/2),
> .smt_gain = 0,
> .max_newidle_lb_cost= 0,
> .next_decay_max_lb_cost = jiffies,
>
--
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] kprobes: arm: enable OPTPROBES for ARM 32
On 2014/8/12 9:38, Masami Hiramatsu wrote:
> (2014/08/11 22:48), Will Deacon wrote:
>> Hello,
>>
>> On Sat, Aug 09, 2014 at 03:12:19AM +0100, Wang Nan wrote:
>>> This patch introduce kprobeopt for ARM 32.
>>>
>>> Limitations:
>>> - Currently only kernel compiled with ARM ISA is supported.
>>>
>>> - Offset between probe point and optinsn slot must not larger than
>>>32MiB. Masami Hiramatsu suggests replacing 2 words, it will make
>>>things complex. Futher patch can make such optimization.
>>>
>>> Kprobe opt on ARM is relatively simpler than kprobe opt on x86 because
>>> ARM instruction is always 4 bytes aligned and 4 bytes long. This patch
>>> replace probed instruction by a 'b', branch to trampoline code and then
>>> calls optimized_callback(). optimized_callback() calls opt_pre_handler()
>>> to execute kprobe handler. It also emulate/simulate replaced instruction.
>>
>> Could you briefly describe the optimisation please?
>
> On arm32, optimization means "replacing a breakpoint with a branch".
> Of course simple branch instruction doesn't memorize the source(probe)
> address, optprobe makes a trampoline code for each probe point and
> each trampoline stores "struct kprobe" of that probe point.
>
> At first, the kprobe puts a breakpoint into the probe site, and builds
> a trampoline. After a while, it starts optimizing the probe site by
> replacing the breakpoint with a branch.
>
>> I'm not familiar with
>> kprobes internals, but if you're trying to patch an arbitrary instruction
>> with a branch then that's not guaranteed to be atomic by the ARM
>> architecture.
>
> Hmm, I'm not sure about arm32 too. Would you mean patch_text() can't
> replace an instruction atomically? Or only the breakpoint is special?
> (for cache?)
> optprobe always swaps branch and breakpoint, isn't that safe?
>
Same question.
OPTPROBES always replace a breakpoint instruction to a branch, not "an arbitrary
instruction". Do you mean the previous breakpoint patching is unsafe?
__patch_text() uses
*(u32 *)addr = insn;
to patch an instruction, do you mean that it is unsafe?
ARM's kprobe and kprobeopt always use it to replace instructions. In some
special
case (a thumb instruction cross 2 words), it wraps such store using
stop_machine,
but in ARM case, it assume such store to be atomic.
>>
>> We can, however, patch branches with other branches.
>>
>> Anyway, minor comments in-line:
>>
>>> +/* Caller must ensure addr & 3 == 0 */
>>> +static int can_optimize(unsigned long paddr)
>>> +{
>>> + return 1;
>>> +}
>>
>> Why not check the paddr alignment here, rather than have a comment?
>
> Actually, we don't need to care about that. The alignment is already
> checked before calling this function (at arch_prepare_kprobe() in
> arch/arm/kernel/kprobes.c).
>
>>
>>> +/* Free optimized instruction slot */
>>> +static void
>>> +__arch_remove_optimized_kprobe(struct optimized_kprobe *op, int dirty)
>>> +{
>>> + if (op->optinsn.insn) {
>>> + free_optinsn_slot(op->optinsn.insn, dirty);
>>> + op->optinsn.insn = NULL;
>>> + }
>>> +}
>>> +
>>> +extern void kprobe_handler(struct pt_regs *regs);
>>> +
>>> +static void
>>> +optimized_callback(struct optimized_kprobe *op, struct pt_regs *regs)
>>> +{
>>> + unsigned long flags;
>>> + struct kprobe *p = >kp;
>>> + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>>> +
>>> + /* Save skipped registers */
>>> + regs->ARM_pc = (unsigned long)op->kp.addr;
>>> + regs->ARM_ORIG_r0 = ~0UL;
>>
>> Why are you writing ORIG_r0?
>
> In x86, optimization(breakpoint to jump) is transparently done, thus
> we have to mimic all registers as the breakpoint exception. And in x86
> int3(which is the breakpoint) exception sets -1 to orig_ax.
> So, if arm32's breakpoint doesn't attach the ARM_ORIG_r0, you don't
> need to touch it. We just consider the pt_regs looks same as that
> at the breakpoint handler.
>
>>
>>> + local_irq_save(flags);
>>> +
>>> + if (kprobe_running()) {
>>> + kprobes_inc_nmissed_count(>kp);
>>> + } else {
>>> + __this_cpu_write(current_kprobe, >kp);
>>> + kcb->kprobe_status = KPROBE_HIT_ACTIVE;
>>> + opt_pre_handler(>kp, regs);
>>> + __this_cpu_write(current_kprobe, NULL);
>>> + }
>>> +
>>> + /* In each case, we must singlestep the replaced instruction. */
>>> + op->kp.ainsn.insn_singlestep(p->opcode, >ainsn, regs);
>>> +
>>> + local_irq_restore(flags);
>>> +}
>>> +
>>> +int arch_prepare_optimized_kprobe(struct optimized_kprobe *op)
>>> +{
>>> + u8 *buf;
>>> + unsigned long rel_chk;
>>> + unsigned long val;
>>> +
>>> + if (!can_optimize((unsigned long)op->kp.addr))
>>> + return -EILSEQ;
>>> +
>>> + op->optinsn.insn = get_optinsn_slot();
>>> + if (!op->optinsn.insn)
>>> + return -ENOMEM;
>>> +
>>> + /*
>>> +* Verify if the address gap is in 32MiB range, because this uses
>>> +* a relative jump.
>>> +*
>>> +* kprobe opt use a 'b'
Re: mm: BUG in unmap_page_range
On 08/05/2014 09:04 PM, Sasha Levin wrote: > Thanks Hugh, Mel. I've added both patches to my local tree and will update > tomorrow > with the weather. > > Also: > > On 08/05/2014 08:42 PM, Hugh Dickins wrote: >> One thing I did wonder, though: at first I was reassured by the >> VM_BUG_ON(!pte_present(pte)) you add to pte_mknuma(); but then thought >> it would be better as VM_BUG_ON(!(val & _PAGE_PRESENT)), being stronger >> - asserting that indeed we do not put NUMA hints on PROT_NONE areas. >> (But I have not tested, perhaps such a VM_BUG_ON would actually fire.) > > I've added VM_BUG_ON(!(val & _PAGE_PRESENT)) in just as a curiosity, I'll > update how that one looks as well. Sorry for the rather long delay. The patch looks fine, the issue didn't reproduce. The added VM_BUG_ON didn't trigger either, so maybe we should consider adding it in. Thanks, Sasha -- 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] arch: Kconfig: Let all little endian architectures define CPU_LITTLE_ENDIAN explicitly
On 8/12/14 6:53, Russell King - ARM Linux wrote: > On Tue, Aug 12, 2014 at 05:18:44AM +0800, Chen Gang wrote: >> x86, ia64, and arm(64) are little endian, and also another architectures >> may be little endian (mips, sh, powerpc, and m32r) which already marked >> CPU_LITTLE_ENDIAN explicitly. > > This is incorrect. ARM can be either endian. > > arch/arm/mm/Kconfig: > > config CPU_BIG_ENDIAN > bool "Build big-endian kernel" > depends on ARCH_SUPPORTS_BIG_ENDIAN > help > Say Y if you plan on running a kernel in big-endian mode. > Note that your board must be properly built and your board > port must properly enable any big-endian related features > of your chipset/board/processor. > OK, thanks, I shall check all CPU_BIG_ENDIAN and send patch v2 for it. And still welcome another ideas, suggestions or completions, especially for another architectures. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
On Mon, Aug 11, 2014 at 08:30:40PM -0700, Dexuan Cui wrote: > hyperv_keyboard invokes serio_interrupt(), which needs a valid serio driver > like atkbd.c. > atkbd.c depends on libps2.c because it invokes ps2_command(). > libps2.c depends on i8042.c because it invokes i8042_check_port_owner(). > As a result, hyperv_keyboard actually depends on i8042.c. > > For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a Linux > VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m rather than > =y, atkbd.ko can't load because i8042.ko can't load(due to no i8042 device > emulated) and finally hyperv_keyboard can't work and the user can't input: > https://bugs.archlinux.org/task/39820 > (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y) > > Decoupling the dependency between hyperv_keyboard and i8042 needs > non-trivial efforts and is hence a long term goal. > > For now, let's make the dependency explicit so people can beware of this. You didn't make anyone "aware" of this, you just prevented people from being able to select the module unless they build the driver into the kernel, which isn't very nice. What exactly needs to be done to fix this "correctly" that is going to take too much work at the moment? 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/
[PATCH] media: fix au0828 dvb suspend/resume to call dvb_frontend_suspend/resume
au0828 doesn't resume correctly and TV tuning fails with
xc_set_signal_source(0) failed message. Change au0828 dvb
suspend and resume interfaces to suspend and resume frontend
during suspend and resume respectively. au0828_dvb_suspend()
calls dvb_frontend_suspend() which in turn invokes tuner ops
sleep followed by fe ops sleep. au0828_dvb_resume() calls
dvb_frontend_resume() which in turn calls fe ops ini follwed
by tuner ops ini before waking up the frontend. With this change
HVR950Q suspend and resume work when system gets suspended when
digital function is tuned to a channel and with active TV stream,
and after resume it went right back to active TV stream.
Signed-off-by: Shuah Khan
---
drivers/media/usb/au0828/au0828-dvb.c | 37 ++---
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-dvb.c
b/drivers/media/usb/au0828/au0828-dvb.c
index 821f86e..50e7c82 100644
--- a/drivers/media/usb/au0828/au0828-dvb.c
+++ b/drivers/media/usb/au0828/au0828-dvb.c
@@ -619,35 +619,30 @@ int au0828_dvb_register(struct au0828_dev *dev)
void au0828_dvb_suspend(struct au0828_dev *dev)
{
- struct au0828_dvb *dvb = >dvb;
-
- if (dvb->frontend && dev->urb_streaming) {
- pr_info("stopping DVB\n");
+ struct au0828_dvb *dvb;
+ int rc;
- cancel_work_sync(>restart_streaming);
+ if (dev == NULL)
+ return;
- /* Stop transport */
- mutex_lock(>lock);
- stop_urb_transfer(dev);
- au0828_stop_transport(dev, 1);
- mutex_unlock(>lock);
- dev->need_urb_start = 1;
+ dvb = >dvb;
+ if (dvb->frontend) {
+ rc = dvb_frontend_suspend(dvb->frontend);
+ pr_info("au0828_dvb_suspend(): Suspending DVB fe %d\n", rc);
}
}
void au0828_dvb_resume(struct au0828_dev *dev)
{
- struct au0828_dvb *dvb = >dvb;
-
- if (dvb->frontend && dev->need_urb_start) {
- pr_info("resuming DVB\n");
+ struct au0828_dvb *dvb;
+ int rc;
- au0828_set_frontend(dvb->frontend);
+ if (dev == NULL)
+ return;
- /* Start transport */
- mutex_lock(>lock);
- au0828_start_transport(dev);
- start_urb_transfer(dev);
- mutex_unlock(>lock);
+ dvb = >dvb;
+ if (dvb->frontend) {
+ rc = dvb_frontend_resume(dvb->frontend);
+ pr_info("au0828_dvb_resume(): Resuming DVB fe %d\n", rc);
}
}
--
1.7.10.4
--
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: rtl8192u/ieee80211: Fix sparse ieee80211_debug_init/_exit not declared warning
El 11/08/14 a las 17:32, Greg Kroah-Hartman escibió: > On Mon, Aug 11, 2014 at 03:15:54PM -0700, Jeremiah Mahler wrote: >> A sparse warning is generated about 'ieee80211_debug_init' and >> 'ieee80211_debug_exit' not being declared. >> >> drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:275:12: warning: >> symbol 'ieee80211_debug_init' was not declared. Should it be static? >> drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:297:13: warning: >> symbol 'ieee80211_debug_exit' was not declared. Should it be static? >> >> These functions are used outside of this file so using static will not >> work. Fix the warning by declaring the functions in the header file, >> ieee80211.h >> >> Signed-off-by: Jeremiah Mahler >> Cc: Greg Kroah-Hartman >> Cc: Teodora Baluta >> Cc: Andrea Merello >> Cc: Joel Pelaez Jorge >> Cc: Bob Copeland >> Cc: Joe Perches >> Cc: Arnd Bergmann >> Cc: Himangi Saraogi >> --- >> drivers/staging/rtl8192u/ieee80211/ieee80211.h | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h >> b/drivers/staging/rtl8192u/ieee80211/ieee80211.h >> index 1040bab..9cbda69 100644 >> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h >> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h >> @@ -2485,6 +2485,12 @@ extern int ieee80211_wx_set_freq(struct >> ieee80211_device *ieee, struct iw_reques >> extern int ieee80211_wx_get_freq(struct ieee80211_device *ieee, struct >> iw_request_info *a, >> union iwreq_data *wrqu, char *b); >> >> +/* ieee80211_module.c */ >> +#ifdef CONFIG_IEEE80211_DEBUG >> +extern int __init ieee80211_debug_init(void); >> +extern void __exit ieee80211_debug_exit(void); >> +#endif /* CONFIG_IEEE80211_DEBUG */ >> + > > As it's a header file, why not always have them here, no need for the > ifdef. > > And __init and __exit don't belong in a .h function prototype. > > thanks, > > greg k-h > The symbol ieee80211_debug_init(void) and ieee80211_debug_exit(void) are declared as prototype in r8192U_core.c, this cause a double function prototype. It is only a comment, it not affect anything. Check it to next time. - Joel -- 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 V2] ACPI/OSL: Replace synchronize_rcu() with call_rcu() in the acpi_os_map_cleanup() to avoid dead lock with cpu hot plug
When cpu hotplug and evaluating ACPI method happen at the same time, there is a dead lock between ACPICA namespace lock and cpu hotplug lock. During cpu hotplug, cpu core will call acpi_cpu_soft_notify() to notify Linux ACPI under cpu hotplug lock. acpi_cpu_soft_notify() calls acpi_bus_get_device() to convert ACPI handle to struct acpi_struct. ACPICA namespace lock will be held in the acpi_bus_get_device(). Evaluating ACPI method may involve in accessing system mem operation region and the associated address space will be unmapped under ACPICA namespace lock after accessing. Currently, osl.c uses RCU to protect io mem pages used by ACPICA. During unmapping, synchronize_rcu() will be called in the acpi_os_map_cleanup(). Synchronize_rcu() blocks cpu hotplug via getting cpu hotplug lock. This causes dead lock with cpu hotplug. Cpu hotplug thread holds cpu hotplug lock first and then get ACPICA namespace lock. The thread of evaluating ACPI method does the converse thing. This patch is to replace synchronize_rcu() with call_rcu() to avoid dead lock. call_rcu() can help to umap address space asynchronously via provided callback. Here is dead lock log. [ 97.149005] INFO: task bash:741 blocked for more than 30 seconds. [ 97.155914] Not tainted 3.16.0-rc5+ #671 [ 97.160969] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 97.169850] bashD 88014e214140 0 741716 0x0080 [ 97.177885] 88009b9f3a10 0086 88009dcfb840 88009b9f3fd8 [ 97.186316] 00014140 00014140 81c18460 81c40fc8 [ 97.194746] 81c40fcc 88009dcfb840 81c40fd0 [ 97.203175] Call Trace: [ 97.205946] [] schedule_preempt_disabled+0x29/0x70 [ 97.213246] [] __mutex_lock_slowpath+0xca/0x1c0 [ 97.220258] [] mutex_lock+0x1f/0x2f [ 97.226085] [] get_online_cpus+0x2c/0x50 [ 97.232408] [] synchronize_sched_expedited+0x64/0x1c0 [ 97.240011] [] synchronize_sched+0x45/0x50 [ 97.246522] [] acpi_os_map_cleanup.part.7+0x14/0x3e [ 97.253928] [] acpi_os_unmap_iomem+0xe2/0xea [ 97.260636] [] acpi_os_unmap_memory+0xe/0x14 [ 97.267355] [] acpi_ev_system_memory_region_setup+0x2d/0x97 [ 97.275550] [] acpi_ut_update_ref_count+0x24d/0x2de [ 97.282958] [] acpi_ut_update_object_reference+0x11a/0x18b [ 97.291055] [] acpi_ut_remove_reference+0x2e/0x31 [ 97.298265] [] acpi_ns_detach_object+0x7b/0x80 [ 97.305180] [] acpi_ns_delete_namespace_subtree+0x47/0x81 [ 97.313179] [] acpi_ds_terminate_control_method+0x85/0x11b [ 97.321276] [] acpi_ps_parse_aml+0x164/0x289 [ 97.327988] [] acpi_ps_execute_method+0x1c1/0x26c [ 97.335195] [] acpi_ns_evaluate+0x1c1/0x258 [ 97.341814] [] acpi_evaluate_object+0x126/0x22f [ 97.348826] [] acpi_hw_execute_sleep_method+0x3d/0x68 [ 97.356427] [] ? acpi_hw_enable_all_runtime_gpes+0x17/0x19 [ 97.364523] [] acpi_hw_legacy_wake+0x4d/0x9d [ 97.371239] [] acpi_hw_sleep_dispatch+0x2a/0x2c [ 97.378243] [] acpi_leave_sleep_state+0x17/0x19 [ 97.385252] [] acpi_pm_finish+0x3f/0x99 [ 97.391471] [] suspend_devices_and_enter+0x139/0x560 [ 97.398972] [] pm_suspend+0xf2/0x370 [ 97.404900] [] state_store+0x79/0xf0 [ 97.410824] [] kobj_attr_store+0xf/0x20 [ 97.417038] [] sysfs_kf_write+0x3d/0x50 [ 97.423260] [] kernfs_fop_write+0xe0/0x160 [ 97.429776] [] vfs_write+0xb7/0x1f0 [ 97.435602] [] SyS_write+0x46/0xb0 [ 97.441334] [] ? __audit_syscall_exit+0x1f6/0x2a0 [ 97.448544] [] system_call_fastpath+0x16/0x1b [ 97.455361] INFO: task async-enable-no:749 blocked for more than 30 seconds. [ 97.463353] Not tainted 3.16.0-rc5+ #671 [ 97.468391] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 97.477271] async-enable-no D 88014e254140 0 749 2 0x0080 [ 97.485286] 88009de83bf0 0046 88009b85 88009de83fd8 [ 97.493714] 00014140 00014140 880148305dc0 880149804160 [ 97.502142] 7fff 0002 88009b85 [ 97.510573] Call Trace: [ 97.513344] [] schedule+0x29/0x70 [ 97.518974] [] schedule_timeout+0x1f9/0x270 [ 97.525588] [] ? __kernfs_create_file+0x7e/0xa0 [ 97.532599] [] ? sysfs_add_file_mode_ns+0x9b/0x160 [ 97.539903] [] __down_common+0x93/0xd8 [ 97.546027] [] __down_timeout+0x16/0x18 [ 97.552252] [] down_timeout+0x4c/0x60 [ 97.558274] [] acpi_os_wait_semaphore+0x43/0x57 [ 97.565285] [] acpi_ut_acquire_mutex+0x48/0x88 [ 97.572200] [] ? acpi_match_device+0x4f/0x4f [ 97.578918] [] acpi_get_data_full+0x3a/0x8e [ 97.585537] [] acpi_bus_get_device+0x23/0x40 [ 97.592253] [] acpi_cpu_soft_notify+0x50/0xe6 [ 97.599064] [] notifier_call_chain+0x4c/0x70 [ 97.605776] [] __raw_notifier_call_chain+0xe/0x10 [ 97.612983] [] cpu_notify+0x23/0x50 [ 97.618815] [] _cpu_up+0x168/0x180 [ 97.624542] []
Re: [nfs] BUG: sleeping function called from invalid context at include/linux/wait.h:976
Hi, I posted a 5 patch series to the nfs list last week with the cover letter titled "nfs_page_group_lock cleanup”, but neglected to mail the wider list. The might_sleep check was being hit because nfs_page_group_lock with wait=False called wait_on_bit_lock (which might sleep). I also had to be careful to ignore the nonblock argument in nfs_lock_and_join_requests and always call nonblocking, because the inode lock is held. Blocking is handled by dropping the inode lock, calling wait_on_bit(), then trying again. The cover letter for the patchset is below. Thanks! -dros These patches clean up some issues surrouding nfs_page_group_lock: - normalize wait/nonblock argument - make nonblocking calls really nonblocking - handle errors - ensure that we don't call blocking nfs_page_group_lock when holding the inode spinlock This cleanup was inspired by Fengguang Wu's report that we were sleeping with locks held in nfs_lock_and_join_requests. Weston Andros Adamson (5): nfs: change nfs_page_group_lock argument nfs: fix nonblocking calls to nfs_page_group_lock nfs: use blocking page_group_lock in add_request nfs: fix error handling in lock_and_join_requests nfs: don't sleep with inode lock in lock_and_join_requests fs/nfs/pagelist.c| 59 ++-- fs/nfs/write.c | 21 + include/linux/nfs_page.h | 1 + 3 files changed, 55 insertions(+), 26 deletions(-) On Aug 9, 2014, at 12:11 AM, Nick Krause wrote: > On Tue, Aug 5, 2014 at 11:08 AM, Weston Andros Adamson > wrote: >> Thanks, I’ll investigate. >> >> -dros >> >> >> On Aug 5, 2014, at 10:03 AM, Fengguang Wu wrote: >> >>> Greetings, >>> >>> Here is an NFS error triggered by this debug check. >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/wait >>> commit b87699e5fa31f451987a992b9cbda22d29ebcb46 >>> Author: Peter Zijlstra >>> AuthorDate: Mon Aug 4 11:12:21 2014 +0200 >>> Commit: Peter Zijlstra >>> CommitDate: Mon Aug 4 13:29:57 2014 +0200 >>> >>> wait: Add might_sleep() >>> >>> Add more might_sleep() checks, suppose someone put a wait_event() like >>> thing in a wait loop.. >>> >>> Can't put might_sleep() in ___wait_event() because there's the locked >>> primitives which call ___wait_event() with locks held. >>> >>> Signed-off-by: Peter Zijlstra >>> Link: http://lkml.kernel.org/n/tip-amr894sd1j012khd3fgyh...@git.kernel.org >>> >>> >>> [ 13.363454] BUG: sleeping function called from invalid context at >>> include/linux/wait.h:976 >>> [ 13.365679] in_atomic(): 1, irqs_disabled(): 0, pid: 2715, name: dmesg >>> [ 13.367109] CPU: 1 PID: 2715 Comm: dmesg Not tainted >>> 3.16.0-00048-gb87699e #1 >>> [ 13.368385] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 >>> [ 13.369544] 88003e3efad0 819c6bad >>> 880035e9e480 >>> [ 13.371838] 88003e3efae0 81106e96 88003e3efb00 >>> 81306a2e >>> [ 13.373822] 880035e9e480 88001b8a1a40 88003e3efb48 >>> 8130975a >>> [ 13.376165] Call Trace: >>> [ 13.376890] [] dump_stack+0x4d/0x66 >>> [ 13.377903] [] __might_sleep+0x10a/0x10c >>> [ 13.379247] [] nfs_page_group_lock+0x4e/0x7b >>> [ 13.380739] [] nfs_lock_and_join_requests+0x83/0x334 >>> [ 13.381884] [] nfs_do_writepage+0x94/0x191 >>> [ 13.383078] [] nfs_writepages_callback+0x13/0x25 >>> [ 13.384592] [] ? nfs_do_writepage+0x191/0x191 >>> [ 13.385745] [] write_cache_pages+0x281/0x3a9 >>> [ 13.386829] [] ? nfs_do_writepage+0x191/0x191 >>> [ 13.388524] [] nfs_writepages+0xa9/0x10f >>> [ 13.389903] [] ? release_pages+0x1a2/0x20b >>> [ 13.391087] [] ? free_pcppages_bulk+0x298/0x33c >>> [ 13.392198] [] do_writepages+0x1e/0x2c >>> [ 13.393202] [] __filemap_fdatawrite_range+0x55/0x57 >>> [ 13.394313] [] filemap_write_and_wait_range+0x2a/0x58 >>> [ 13.395448] [] nfs_file_fsync+0x4e/0x10c >>> [ 13.396546] [] vfs_fsync_range+0x1b/0x23 >>> [ 13.397567] [] vfs_fsync+0x1c/0x1e >>> [ 13.398517] [] nfs_file_flush+0x6c/0x6f >>> [ 13.399513] [] filp_close+0x3c/0x72 >>> [ 13.400646] [] put_files_struct+0x67/0xb3 >>> [ 13.401759] [] exit_files+0x4a/0x4f >>> [ 13.402756] [] do_exit+0x3c9/0x985 >>> [ 13.403740] [] ? trace_do_page_fault+0x52/0xb7 >>> [ 13.404875] [] do_group_exit+0x44/0xac >>> [ 13.405878] [] SyS_exit_group+0x14/0x14 >>> [ 13.406892] [] system_call_fastpath+0x16/0x1b >>> [ 15.733276] BUG: sleeping function called from invalid context at >>> include/linux/wait.h:976 >>> [ 15.735154] in_atomic(): 1, irqs_disabled(): 0, pid: 2716, name: cat >>> [ 15.736263] CPU: 1 PID: 2716 Comm: cat Not tainted 3.16.0-00048-gb87699e >>> #1 >>> [ 15.737414] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 >>> [ 15.738754] 8868b910 819c6bad >>> 880035e9e080 >>> [ 15.746872] 8868b920 81106e96 8868b940 >>>
Re: [PATCH] xen_hvc: no reason to write the type key on xenstore
On Mon, Aug 11, 2014 at 03:32:48PM +0100, Stefano Stabellini wrote: > CC'ing tty maintainers. Why? Is that how you submit a patch to be included to the kernel tree? (hint, the answer is no, and also you should cc: the linux-serial list...) 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/
[PATCH] of: Deep-copy names of platform devices
When we parse the device tree and allocate platform devices, the 'name' of the newly-created platform_device is set to point to the 'name' field of the 'struct device' embedded within the platform_device. This is dangerous, because the name of the 'struct device' is dynamically allocated. Drivers may call dev_set_name() on the device, which will free and reallocate the name of the device, leaving the 'name' of the platform_device pointing to the now-freed memory. Furthermore, if the dev_set_name() call is made from a driver's probe() function and a subsequent request results in probe deferral, the dangling 'name' reference may lead to the device being re-probed using the wrong driver. To mitigate these scenarios, we use kstrdup to perform a deep copy of the device name when assigning the name of the platform_device, so that the platform_device name is unaffected by any calls to dev_set_name() that might made by drivers to rename the embedded 'struct device'. Signed-off-by: Stepan Moskovchenko --- I suppose creating a 'pdev_set_name' API may seem like another possibility, but I feel that dev.name and pdev.name have two different meanings. One is used for device/driver binding purposes, whereas the other serves a more general identification purpose, and is used for things like sysfs. Drivers might want to change dev.name while leaving the pdev.name alone. I guess yet another possibility would be to prohibit calling dev_set_name() on devices created from device tree, but a driver does not necessarily know how a given platform_device was allocated. drivers/of/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/of/device.c b/drivers/of/device.c index f685e55..fe5f025 100644 --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -54,7 +54,7 @@ int of_device_add(struct platform_device *ofdev) /* name and id have to be set so that the platform bus doesn't get * confused on matching */ - ofdev->name = dev_name(>dev); + ofdev->name = kstrdup(dev_name(>dev), GFP_KERNEL); ofdev->id = -1; /* device_add will assume that this device is on the same node as -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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/lustre: use rcu_dereference to access rcu protected current->real_parent field
On Mon, Aug 11, 2014 at 09:44:47PM -0400, Oleg Drokin wrote: > > On Aug 9, 2014, at 11:47 AM, Greg Kroah-Hartman wrote: > > > On Sat, Aug 09, 2014 at 10:34:36AM -0400, Oleg Drokin wrote: > >> > >>> Because maybe these stats preceed the introduction of perf and other > >>> tracing/debug tools? I don't know, it's really low down on the list of > >>> reasons why lustre can't be merged out of staging at the moment, you all > >>> have much bigger issues to address first. > >> > >> I wonder what is the prioritized list you have in mind? > > > > Do I really have to spell out what is wrong with that codebase that > > needs to be fixed up? It took me 50+ patches for 3.17-rc1 to just fix > > up a _portion_ of the include file mess that is in there. Now is the > > first time the code actually _builds_ properly in the kernel tree (i.e. > > no magic header file include path modifications in Makefiles preventing > > individual files from being built correctly.) > > Well, last time we discussed this topic, you said that moving most of lustre > proc files > into sysfs and other suitable venues is what prevents moving lustre out of the > staging tree under fs/ Yes, that's one of the big things, but the structure of the code itself still needs lots of work. You have wrapper functions and defines that are not needed. You have version-specific checks and still a quite complex and unnecessary include directory structure. > There well might be include mess, but this is the first time I hear about it, > and I have not seen > any build breakage or other obviously broken behavior. The build breakage came about in a thread on this mailing list when we had a tool that could build an individual .o file, which I found to break on all of the lustre files due to the odd way you were redefining the include search path of the .c files. I unwound all of that to use direct paths and now things build properly. But even then, there are way too many .h files and nested mess that is not needed and is the result of trying to get this code to build on other platforms a long time ago. > I am sure there are more things too, that's why I am asking. > We are trying to deal with stuff we know about, but it's a bit harder > to deal with the stuff we don't know about that does not manifest > itself in some clear way. Try getting rid of the typedefs and wrapper functions and #defines for function names and coding style issues. That would be a great first step and would then expose what really is left to do. Right now, it's just to hard to see the real issues. 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: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support
> "Sreekanth" == Sreekanth Reddy writes: Sreekanth> Please let me known any further changes are required so that Sreekanth> I can send this patch once again with git send-email. I'm OK with the latest iteration. -- 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] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
hyperv_keyboard invokes serio_interrupt(), which needs a valid serio driver like atkbd.c. atkbd.c depends on libps2.c because it invokes ps2_command(). libps2.c depends on i8042.c because it invokes i8042_check_port_owner(). As a result, hyperv_keyboard actually depends on i8042.c. For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a Linux VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m rather than =y, atkbd.ko can't load because i8042.ko can't load(due to no i8042 device emulated) and finally hyperv_keyboard can't work and the user can't input: https://bugs.archlinux.org/task/39820 (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y) Decoupling the dependency between hyperv_keyboard and i8042 needs non-trivial efforts and is hence a long term goal. For now, let's make the dependency explicit so people can beware of this. Thank Claudio for the initial reporting, investigation and suggesting the fix. Signed-off-by: Dexuan Cui Reported-by: Claudio Latini Cc: K. Y. Srinivasan --- drivers/input/serio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index bc2d474..3277bff 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -273,7 +273,7 @@ config SERIO_OLPC_APSP config HYPERV_KEYBOARD tristate "Microsoft Synthetic Keyboard driver" - depends on HYPERV + depends on HYPERV && SERIO_I8042=y default HYPERV help Select this option to enable the Hyper-V Keyboard driver. -- 1.9.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 1/3] Adding Skyworks SKY81452 MFD driver
Hello,
Can somebody please review if the code has anything to improve?
Thanks.
On Fri, Aug 08, 2014 at 06:08:19PM +0900, Gyungoh Yoo wrote:
> Signed-off-by: Gyungoh Yoo
> ---
> Documentation/devicetree/bindings/mfd/sky81452.txt | 24 +
> .../devicetree/bindings/vendor-prefixes.txt| 1 +
> drivers/mfd/Kconfig| 12 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/sky81452.c | 113
> +
> include/linux/mfd/sky81452.h | 32 ++
> 6 files changed, 183 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt
> create mode 100644 drivers/mfd/sky81452.c
> create mode 100644 include/linux/mfd/sky81452.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/sky81452.txt
> b/Documentation/devicetree/bindings/mfd/sky81452.txt
> new file mode 100644
> index 000..5fb0b4f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/sky81452.txt
> @@ -0,0 +1,24 @@
> +SKY81452 bindings
> +
> +Required properties:
> +- compatible : Must be "skyworks,sky81452"
> +
> +Required child nodes:
> +- backlight : container node for backlight following the binding
> + in video/backlight/sky81452-backlight.txt
> +- regulator : container node for regulators following the binding
> + in regulator/sky81452-regulator.txt
> +
> +Example:
> +
> + sky81452@2C {
> + compatible = "skyworks,sky81452";
> +
> + backlight {
> + ...
> + };
> +
> + regulator {
> + ...
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index d415b38..ce76e10 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -122,6 +122,7 @@ silabsSilicon Laboratories
> simtek
> sii Seiko Instruments, Inc.
> sirf SiRF Technology, Inc.
> +skyworks Skyworks Solutions, Inc.
> smsc Standard Microsystems Corporation
> snps Synopsys, Inc.
> spansion Spansion Inc.
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index de5abf2..acfb2e5 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -626,6 +626,18 @@ config MFD_SM501_GPIO
>lines on the SM501. The platform data is used to supply the
>base number for the first GPIO line to register.
>
> +config SKY81452
> + tristate "Skyworks Solutions SKY81452"
> + select MFD_CORE
> + select REGMAP_I2C
> + depends on I2C=y
> + help
> + This is the core driver for the Skyworks SKY81452 backlight and
> + voltage regulator device.
> +
> + This driver can also be built as a module. If so, the module
> + will be called sky81452.
> +
> config MFD_SMSC
> bool "SMSC ECE1099 series chips"
> depends on I2C=y
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index f001487..191c656 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711) += as3711.o
> obj-$(CONFIG_MFD_AS3722) += as3722.o
> obj-$(CONFIG_MFD_STW481X)+= stw481x.o
> obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
> +obj-$(CONFIG_SKY81452) += sky81452.o
>
> intel-soc-pmic-objs := intel_soc_pmic_core.o intel_soc_pmic_crc.o
> obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> diff --git a/drivers/mfd/sky81452.c b/drivers/mfd/sky81452.c
> new file mode 100644
> index 000..566912f
> --- /dev/null
> +++ b/drivers/mfd/sky81452.c
> @@ -0,0 +1,113 @@
> +/*
> + * sky81452.cSKY81452 MFD driver
> + *
> + * Copyright 2014 Skyworks Solutions Inc.
> + * Author : Gyungoh Yoo
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2, or (at your option) any
> + * later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see
[PATCH] staging/lustre/lnet: Fix potential uninitialized variable warning
Greg reports that with one of the patches in his queue
there's now an unused variable warning in lnet_parse_ip2nets
for ipaddrs variable.
Apparently the warning is a false positive as in all cases where
lnet_ipaddr_enumerate can return without setting ipaddrs to something
a negative return value is returned that is then checked
before we actually use ipaddrs.
Assign ipaddrs to NULL to quiet this.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/lnet/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lnet/lnet/config.c
b/drivers/staging/lustre/lnet/lnet/config.c
index 7c8b947..d77aa31 100644
--- a/drivers/staging/lustre/lnet/lnet/config.c
+++ b/drivers/staging/lustre/lnet/lnet/config.c
@@ -1187,7 +1187,7 @@ lnet_ipaddr_enumerate(__u32 **ipaddrsp)
int
lnet_parse_ip2nets(char **networksp, char *ip2nets)
{
- __u32 *ipaddrs;
+ __u32 *ipaddrs = NULL;
int nip = lnet_ipaddr_enumerate();
int rc;
--
1.9.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 v2 08/13] staging: lustre: fix multi line strings
On Aug 11, 2014, at 2:27 PM, Srikrishan Malik wrote: > Fixes the following checkpatch warning: > > WARNING: quoted string split across lines > diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c > b/drivers/staging/lustre/lustre/mdc/mdc_request.c > index 57d903156917..6c691a4763b5 100644 > --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c > +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c > @@ -2055,8 +2055,8 @@ static int mdc_hsm_copytool_send(int len, void *val) > return -EPROTO; > } > > - CDEBUG(D_HSM, " Received message mg=%x t=%d m=%d l=%d actions=%d " > -"on %s\n", > + CDEBUG(D_HSM, > +" Received message mg=%x t=%d m=%d l=%d actions=%d on %s\n", > lh->kuc_magic, lh->kuc_transport, lh->kuc_msgtype, > lh->kuc_msglen, hal->hal_count, hal->hal_fsname); I imagine we can drop the leading space here as well. Thanks. Bye, Oleg -- 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] seccomp fix for 3.17
Please pull this fix for the seccomp code.
The following changes since commit c8d6637d0497d62093dbba0694c7b3a80b79bfe1:
Merge tag 'modules-next-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux (2014-08-10 21:31:58
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
for-linus
Guenter Roeck (1):
seccomp: Replace BUG(!spin_is_locked()) with assert_spin_lock
kernel/fork.c|2 +-
kernel/seccomp.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
---
commit 69f6a34bdeea4fec50bb90619bc9602973119572
Author: Guenter Roeck
Date: Sun Aug 10 20:50:30 2014 -0700
seccomp: Replace BUG(!spin_is_locked()) with assert_spin_lock
Current upstream kernel hangs with mips and powerpc targets in
uniprocessor mode if SECCOMP is configured.
Bisect points to commit dbd952127d11 ("seccomp: introduce writer locking").
Turns out that code such as
BUG_ON(!spin_is_locked(_lock));
can not be used in uniprocessor mode because spin_is_locked() always
returns false in this configuration, and that assert_spin_locked()
exists for that very purpose and must be used instead.
Fixes: dbd952127d11 ("seccomp: introduce writer locking")
Cc: Kees Cook
Signed-off-by: Guenter Roeck
Signed-off-by: Kees Cook
diff --git a/kernel/fork.c b/kernel/fork.c
index 1380d8a..0cf9cdb 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1105,7 +1105,7 @@ static void copy_seccomp(struct task_struct *p)
* needed because this new task is not yet running and cannot
* be racing exec.
*/
- BUG_ON(!spin_is_locked(>sighand->siglock));
+ assert_spin_locked(>sighand->siglock);
/* Ref-count the new filter user, and assign it. */
get_seccomp_filter(current);
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 25b0043..44eb005 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -203,7 +203,7 @@ static u32 seccomp_run_filters(int syscall)
static inline bool seccomp_may_assign_mode(unsigned long seccomp_mode)
{
- BUG_ON(!spin_is_locked(>sighand->siglock));
+ assert_spin_locked(>sighand->siglock);
if (current->seccomp.mode && current->seccomp.mode != seccomp_mode)
return false;
@@ -214,7 +214,7 @@ static inline bool seccomp_may_assign_mode(unsigned long
seccomp_mode)
static inline void seccomp_assign_mode(struct task_struct *task,
unsigned long seccomp_mode)
{
- BUG_ON(!spin_is_locked(>sighand->siglock));
+ assert_spin_locked(>sighand->siglock);
task->seccomp.mode = seccomp_mode;
/*
@@ -253,7 +253,7 @@ static inline pid_t seccomp_can_sync_threads(void)
struct task_struct *thread, *caller;
BUG_ON(!mutex_is_locked(>signal->cred_guard_mutex));
- BUG_ON(!spin_is_locked(>sighand->siglock));
+ assert_spin_locked(>sighand->siglock);
/* Validate all threads being eligible for synchronization. */
caller = current;
@@ -294,7 +294,7 @@ static inline void seccomp_sync_threads(void)
struct task_struct *thread, *caller;
BUG_ON(!mutex_is_locked(>signal->cred_guard_mutex));
- BUG_ON(!spin_is_locked(>sighand->siglock));
+ assert_spin_locked(>sighand->siglock);
/* Synchronize all threads. */
caller = current;
@@ -464,7 +464,7 @@ static long seccomp_attach_filter(unsigned int flags,
unsigned long total_insns;
struct seccomp_filter *walker;
- BUG_ON(!spin_is_locked(>sighand->siglock));
+ assert_spin_locked(>sighand->siglock);
/* Validate resulting filter length. */
total_insns = filter->prog->len;
--
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/
color box, display box, corrugated box, color card, blister card, color sleeve, hang tag, label
Hi, this is David Wu from Shanghai, China. We are a printing company, we can print color box, corrugated box, label, hang tag etc. Please let me know if you need these. I will send you the website then. Best regards, David Wu -- 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 3/3] staging: comedi: addi_apci_1564: tidy register map defines
This commit performs a final tidying of the register map defines, bringing
them to a state that is ready for merging into addi_apci_1564.c when the
time comes. Actions performed include:
*Removes the APCI1564_ADDRESS_RANGE macro, which is no longer needed/used.
*Renames the APCI1564_DIGITAL_OP_{VCC,CC}_INTERRUPT_{ENABLE,DISABLE}
macros to shorter names which are more consistent with the digital input
interrupt macros.
*Fixes a typo in a comment (dev>iobase changed to dev->iobase).
*Renames the APCI1564_TCW_* macros to APCI1564_COUNTER_* names to more
accurately reflect that they are only offsets to counter registers (since
only the counters are offset from dev->iobase).
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 70 --
drivers/staging/comedi/drivers/addi_apci_1564.c| 19 +++---
2 files changed, 48 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index f8d8cc9..198c627 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -21,8 +21,6 @@
*
*/
-#define APCI1564_ADDRESS_RANGE 128
-
/* Digital Input IRQ Function Selection */
#define APCI1564_DI_INT_OR (0 << 1)
#define APCI1564_DI_INT_AND(1 << 1)
@@ -32,10 +30,10 @@
#define APCI1564_DI_INT_DISABLE0xfffb
/* Digital Output Interrupt Enable Disable. */
-#define APCI1564_DIGITAL_OP_VCC_INTERRUPT_ENABLE 0x1
-#define APCI1564_DIGITAL_OP_VCC_INTERRUPT_DISABLE 0xfffe
-#define APCI1564_DIGITAL_OP_CC_INTERRUPT_ENABLE0x2
-#define APCI1564_DIGITAL_OP_CC_INTERRUPT_DISABLE 0xfffd
+#define APCI1564_DO_VCC_INT_ENABLE 0x1
+#define APCI1564_DO_VCC_INT_DISABLE0xfffe
+#define APCI1564_DO_CC_INT_ENABLE 0x2
+#define APCI1564_DO_CC_IN_DISABLE 0xfffd
/* TIMER COUNTER WATCHDOG DEFINES */
#define ADDIDATA_TIMER 0
@@ -76,16 +74,16 @@
#define APCI1564_TIMER_WARN_TIMEBASE_REG 0x64
/*
- * dev>iobase Register Map
+ * dev->iobase Register Map
*/
-#define APCI1564_TCW_REG(x)(0x00 + ((x) * 0x20))
-#define APCI1564_TCW_RELOAD_REG(x) (0x04 + ((x) * 0x20))
-#define APCI1564_TCW_TIMEBASE_REG(x) (0x08 + ((x) * 0x20))
-#define APCI1564_TCW_CTRL_REG(x) (0x0c + ((x) * 0x20))
-#define APCI1564_TCW_STATUS_REG(x) (0x10 + ((x) * 0x20))
-#define APCI1564_TCW_IRQ_REG(x)(0x14 + ((x) *
0x20))
-#define APCI1564_TCW_WARN_TIMEVAL_REG(x) (0x18 + ((x) * 0x20))
-#define APCI1564_TCW_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20))
+#define APCI1564_COUNTER_REG(x)(0x00 + ((x) *
0x20))
+#define APCI1564_COUNTER_RELOAD_REG(x) (0x04 + ((x) * 0x20))
+#define APCI1564_COUNTER_TIMEBASE_REG(x) (0x08 + ((x) * 0x20))
+#define APCI1564_COUNTER_CTRL_REG(x) (0x0c + ((x) * 0x20))
+#define APCI1564_COUNTER_STATUS_REG(x) (0x10 + ((x) * 0x20))
+#define APCI1564_COUNTER_IRQ_REG(x)(0x14 + ((x) * 0x20))
+#define APCI1564_COUNTER_WARN_TIMEVAL_REG(x) (0x18 + ((x) * 0x20))
+#define APCI1564_COUNTER_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20))
/*
* Configures The Timer or Counter
@@ -121,14 +119,14 @@ static int apci1564_timer_config(struct comedi_device
*dev,
outl(0x0, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
outl(0x0, devpriv->amcc_iobase + APCI1564_DO_IRQ_REG);
outl(0x0, devpriv->amcc_iobase + APCI1564_WDOG_IRQ_REG);
- outl(0x0,
-dev->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER1));
- outl(0x0,
-dev->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER2));
- outl(0x0,
-dev->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER3));
- outl(0x0,
-dev->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER4));
+ outl(0x0, dev->iobase +
+ APCI1564_COUNTER_IRQ_REG(APCI1564_COUNTER1));
+ outl(0x0, dev->iobase +
+ APCI1564_COUNTER_IRQ_REG(APCI1564_COUNTER2));
+ outl(0x0, dev->iobase +
+ APCI1564_COUNTER_IRQ_REG(APCI1564_COUNTER3));
+ outl(0x0, dev->iobase +
+
[PATCH 2/3] staging: comedi: addi_apci_1564: Remove in-driver watchdog support code
Starting with commit 1496e5961113 ("staging: comedi: addi_apci_1564: use
addi_watchdog module to init watchdog subdevice"), this driver uses the
addi_watchdog module to provide support for the watchdog subdevice. Any
remaining watchdog code in-driver can and should be removed.
This will also make future work on the timer and counter subdevices easier.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 54 +-
1 file changed, 12 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 0ce1deb..f8d8cc9 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -88,9 +88,9 @@
#define APCI1564_TCW_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20))
/*
- * Configures The Timer, Counter or Watchdog
+ * Configures The Timer or Counter
*
- * data[0] Configure as: 0 = Timer, 1 = Counter, 2 = Watchdog
+ * data[0] Configure as: 0 = Timer, 1 = Counter
* data[1] 1 = Enable Interrupt, 0 = Disable Interrupt
* data[2] Time Unit
* data[3] Reload Value
@@ -107,14 +107,7 @@ static int apci1564_timer_config(struct comedi_device *dev,
unsigned int ul_Command1 = 0;
devpriv->tsk_current = current;
- if (data[0] == ADDIDATA_WATCHDOG) {
- devpriv->timer_select_mode = ADDIDATA_WATCHDOG;
-
- /* Disable the watchdog */
- outl(0x0, devpriv->amcc_iobase + APCI1564_WDOG_CTRL_REG);
- /* Loading the Reload value */
- outl(data[3], devpriv->amcc_iobase + APCI1564_WDOG_RELOAD_REG);
- } else if (data[0] == ADDIDATA_TIMER) {
+ if (data[0] == ADDIDATA_TIMER) {
/* First Stop The Timer */
ul_Command1 = inl(devpriv->amcc_iobase +
APCI1564_TIMER_CTRL_REG);
ul_Command1 = ul_Command1 & 0xF9FEUL;
@@ -187,14 +180,13 @@ static int apci1564_timer_config(struct comedi_device
*dev,
} else {
dev_err(dev->class_dev, "Invalid subdevice.\n");
}
-
return insn->n;
}
/*
- * Start / Stop The Selected Timer, Counter or Watchdog
+ * Start / Stop The Selected Timer or Counter
*
- * data[0] Configure as: 0 = Timer, 1 = Counter, 2 = Watchdog
+ * data[0] Configure as: 0 = Timer, 1 = Counter
* data[1] 0 = Stop, 1 = Start, 2 = Trigger Clear (Only Counter)
*/
static int apci1564_timer_write(struct comedi_device *dev,
@@ -205,23 +197,6 @@ static int apci1564_timer_write(struct comedi_device *dev,
struct apci1564_private *devpriv = dev->private;
unsigned int ul_Command1 = 0;
- if (devpriv->timer_select_mode == ADDIDATA_WATCHDOG) {
- switch (data[1]) {
- case 0: /* stop the watchdog */
- /* disable the watchdog */
- outl(0x0, devpriv->amcc_iobase +
APCI1564_WDOG_CTRL_REG);
- break;
- case 1: /* start the watchdog */
- outl(0x0001, devpriv->amcc_iobase +
APCI1564_WDOG_CTRL_REG);
- break;
- case 2: /* Software trigger */
- outl(0x0201, devpriv->amcc_iobase +
APCI1564_WDOG_CTRL_REG);
- break;
- default:
- dev_err(dev->class_dev, "Specified functionality does
not exist.\n");
- return -EINVAL;
- }
- }
if (devpriv->timer_select_mode == ADDIDATA_TIMER) {
if (data[1] == 1) {
ul_Command1 = inl(devpriv->amcc_iobase +
APCI1564_TIMER_CTRL_REG);
@@ -236,8 +211,7 @@ static int apci1564_timer_write(struct comedi_device *dev,
ul_Command1 = ul_Command1 & 0xF9FEUL;
outl(ul_Command1, devpriv->amcc_iobase +
APCI1564_TIMER_CTRL_REG);
}
- }
- if (devpriv->timer_select_mode == ADDIDATA_COUNTER) {
+ } else if (devpriv->timer_select_mode == ADDIDATA_COUNTER) {
ul_Command1 =
inl(dev->iobase +
APCI1564_TCW_CTRL_REG(devpriv->mode_select_register
- 1));
@@ -254,12 +228,14 @@ static int apci1564_timer_write(struct comedi_device *dev,
}
outl(ul_Command1, dev->iobase +
APCI1564_TCW_CTRL_REG(devpriv->mode_select_register - 1));
+ } else {
+ dev_err(dev->class_dev, "Invalid subdevice.\n");
}
return insn->n;
}
/*
- * Read The Selected Timer, Counter or Watchdog
+ * Read The Selected Timer or Counter
*/
static int apci1564_timer_read(struct comedi_device *dev,
struct comedi_subdevice *s,
@@ -269,11 +245,7 @@ static int apci1564_timer_read(struct comedi_device *dev,
[PATCH 1/3] staging: comedi: addi_apci_1564: remove apci1564_do_config
The DO config function served the purpose of configuring the diagnostic
interrupts for the board. As the driver currently does not support
diagnostic interrupts, the digital output subdevice does not need an
insn_config operation and this function can be safely removed.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 34 --
drivers/staging/comedi/drivers/addi_apci_1564.c| 1 -
2 files changed, 35 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 8a613ae..0ce1deb 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -88,40 +88,6 @@
#define APCI1564_TCW_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20))
/*
- * Configures The Digital Output Subdevice.
- *
- * data[1] 0 = Disable VCC Interrupt, 1 = Enable VCC Interrupt
- * data[2] 0 = Disable CC Interrupt, 1 = Enable CC Interrupt
- */
-static int apci1564_do_config(struct comedi_device *dev,
- struct comedi_subdevice *s,
- struct comedi_insn *insn,
- unsigned int *data)
-{
- struct apci1564_private *devpriv = dev->private;
- unsigned int ul_Command = 0;
-
- if ((data[0] != 0) && (data[0] != 1)) {
- dev_err(dev->class_dev, "Data should be 1 or 0\n");
- return -EINVAL;
- }
-
- if (data[1] == 1)
- ul_Command = ul_Command | 0x1;
- else
- ul_Command = ul_Command & 0xFFFE;
-
- if (data[2] == 1)
- ul_Command = ul_Command | 0x2;
- else
- ul_Command = ul_Command & 0xFFFD;
-
- outl(ul_Command, devpriv->amcc_iobase + APCI1564_DO_INT_CTRL_REG);
- devpriv->tsk_current = current;
- return insn->n;
-}
-
-/*
* Configures The Timer, Counter or Watchdog
*
* data[0] Configure as: 0 = Timer, 1 = Counter, 2 = Watchdog
diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 543cb07..555e0a9 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -388,7 +388,6 @@ static int apci1564_auto_attach(struct comedi_device *dev,
s->n_chan = 32;
s->maxdata = 1;
s->range_table = _digital;
- s->insn_config = apci1564_do_config;
s->insn_bits = apci1564_do_insn_bits;
/* Change-Of-State (COS) interrupt subdevice */
--
2.0.4
--
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: lustre: fix sparse warnings / delete unused function
On Aug 11, 2014, at 9:58 PM, Oleg Drokin wrote: > > On Aug 10, 2014, at 12:34 AM, Greg KH wrote: >> Very odd, with this patch applied, I now get a build warning: >> >> drivers/staging/lustre/lnet/lnet/config.c: In function ‘lnet_parse_ip2nets’: >> drivers/staging/lustre/lnet/lnet/config.c:1193:2: warning: ‘ipaddrs’ may be >> used uninitialized in this function [-Wmaybe-uninitialized] >> lnet_ipaddr_free_enumeration(ipaddrs, nip); >> ^ > > What's even more odd is that the very previous line also uses ipaddrs, yet it > does not trigger the warning. > In any case I believe it's a false positive, since the only way it could > remain unitialized is if > libcfs_ipif_enumerate returned negative value (stored in nif in this > function) and we check for it being more than zero > before getting to that part of code. > > I'll submit a patch assigning ipaddrs to NULL as a workaround shortly. Err, looking at the wrong function there, it's lnet_ipaddr_enumerate that returns negative if ipaddrs was not changed. Anyway still false positive. -- 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/
[PATCHv2 3/5] rtc: s3c: Add s3c_rtc_data structure to use variant data instead of s3c_cpu_type
From: Chanwoo Choi
This patch add s3c_rtc_data structure to variant data according to SoC type.
The s3c_rtc_data structure includes some functions to control RTC operation
and specific data dependent on SoC type.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
drivers/rtc/rtc-s3c.c | 464 +++---
1 file changed, 289 insertions(+), 175 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index d8f25bd..26a88f9 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -32,17 +32,6 @@
#include
#include "rtc-s3c.h"
-enum s3c_cpu_type {
- TYPE_S3C2410,
- TYPE_S3C2416,
- TYPE_S3C2443,
- TYPE_S3C64XX,
-};
-
-struct s3c_rtc_drv_data {
- int cpu_type;
-};
-
struct s3c_rtc {
struct device *dev;
struct rtc_device *rtc;
@@ -51,7 +40,7 @@ struct s3c_rtc {
struct clk *rtc_clk;
bool enabled;
- enum s3c_cpu_type cpu_type;
+ struct s3c_rtc_data *data;
int irq_alarm;
int irq_tick;
@@ -63,6 +52,19 @@ struct s3c_rtc {
bool wake_en;
};
+struct s3c_rtc_data {
+ int max_user_freq;
+
+ void (*irq_handler) (struct s3c_rtc *info, int mask);
+ void (*set_freq) (struct s3c_rtc *info, int freq);
+ void (*enable_tick) (struct s3c_rtc *info, struct seq_file *seq);
+ void (*select_tick_clk) (struct s3c_rtc *info);
+ void (*save_tick_cnt) (struct s3c_rtc *info);
+ void (*restore_tick_cnt) (struct s3c_rtc *info);
+ void (*enable) (struct s3c_rtc *info);
+ void (*disable) (struct s3c_rtc *info);
+};
+
static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, bool enable)
{
unsigned long irq_flags;
@@ -83,34 +85,22 @@ static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info,
bool enable)
}
/* IRQ Handlers */
-static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
+static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
{
struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(info->rtc_clk);
- rtc_update_irq(info->rtc, 1, RTC_AF | RTC_IRQF);
-
- if (info->cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_ALM, info->base + S3C2410_INTP);
-
- clk_disable(info->rtc_clk);
-
- s3c_rtc_alarm_clk_enable(info, false);
+ if (info->data->irq_handler)
+ info->data->irq_handler(info, S3C2410_INTP_TIC);
return IRQ_HANDLED;
}
-static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
+static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
{
struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(info->rtc_clk);
- rtc_update_irq(info->rtc, 1, RTC_PF | RTC_IRQF);
-
- if (info->cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_TIC, info->base + S3C2410_INTP);
-
- clk_disable(info->rtc_clk);
+ if (info->data->irq_handler)
+ info->data->irq_handler(info, S3C2410_INTP_ALM);
return IRQ_HANDLED;
}
@@ -140,36 +130,18 @@ static int s3c_rtc_setaie(struct device *dev, unsigned
int enabled)
return 0;
}
+/* Set RTC frequency */
static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
{
- unsigned int tmp = 0;
- int val;
-
if (!is_power_of_2(freq))
return -EINVAL;
clk_enable(info->rtc_clk);
spin_lock_irq(>pie_lock);
- if (info->cpu_type != TYPE_S3C64XX) {
- tmp = readb(info->base + S3C2410_TICNT);
- tmp &= S3C2410_TICNT_ENABLE;
- }
-
- val = (info->rtc->max_user_freq / freq) - 1;
-
- if (info->cpu_type == TYPE_S3C2416 || info->cpu_type == TYPE_S3C2443) {
- tmp |= S3C2443_TICNT_PART(val);
- writel(S3C2443_TICNT1_PART(val), info->base + S3C2443_TICNT1);
+ if (info->data->set_freq)
+ info->data->set_freq(info, freq);
- if (info->cpu_type == TYPE_S3C2416)
- writel(S3C2416_TICNT2_PART(val),
- info->base + S3C2416_TICNT2);
- } else {
- tmp |= val;
- }
-
- writel(tmp, info->base + S3C2410_TICNT);
spin_unlock_irq(>pie_lock);
clk_disable(info->rtc_clk);
@@ -177,7 +149,6 @@ static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
}
/* Time read/write */
-
static int s3c_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
{
struct s3c_rtc *info = dev_get_drvdata(dev);
@@ -370,22 +341,17 @@ static int s3c_rtc_setalarm(struct device *dev, struct
rtc_wkalrm *alrm)
static int s3c_rtc_proc(struct device *dev, struct seq_file *seq)
{
struct s3c_rtc *info = dev_get_drvdata(dev);
- unsigned int ticnt;
if (!info->base)
return -EINVAL;
clk_enable(info->rtc_clk);
- if (info->cpu_type == TYPE_S3C64XX) {
- ticnt = readw(info->base + S3C2410_RTCCON);
- ticnt &= S3C64XX_RTCCON_TICEN;
[PATCHv2 2/5] rtc: s3c: Remove warning message when checking coding style with checkpatch script
From: Chanwoo Choi
This patch remove warning message when checking codeing style with checkpatch
script and reduce un-necessary i2c read operation on s3c_rtc_enable.
WARNING: line over 80 characters
#406: FILE: drivers/rtc/rtc-s3c.c:406:
+ if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_RTCEN) == 0) {
WARNING: line over 80 characters
#414: FILE: drivers/rtc/rtc-s3c.c:414:
+ if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_CNTSEL)) {
WARNING: line over 80 characters
#422: FILE: drivers/rtc/rtc-s3c.c:422:
+ if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_CLKRST)) {
WARNING: Missing a blank line after declarations
#451: FILE: drivers/rtc/rtc-s3c.c:451:
+ struct s3c_rtc_drv_data *data;
+ if (pdev->dev.of_node) {
WARNING: Missing a blank line after declarations
#453: FILE: drivers/rtc/rtc-s3c.c:453:
+ const struct of_device_id *match;
+ match = of_match_node(s3c_rtc_dt_match,
pdev->dev.of_node);
WARNING: DT compatible string "samsung,s3c2416-rtc" appears
un-documented -- check ./Documentation/devicetree/bindings/
#650: FILE: drivers/rtc/rtc-s3c.c:650:
+ .compatible = "samsung,s3c2416-rtc",
WARNING: DT compatible string "samsung,s3c2443-rtc" appears
un-documented -- check ./Documentation/devicetree/bindings/
#653: FILE: drivers/rtc/rtc-s3c.c:653:
+ .compatible = "samsung,s3c2443-rtc",
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 2 ++
drivers/rtc/rtc-s3c.c | 26 ---
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 7ac7259..06db446 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -3,6 +3,8 @@
Required properties:
- compatible: should be one of the following.
* "samsung,s3c2410-rtc" - for controllers compatible with s3c2410 rtc.
+* "samsung,s3c2416-rtc" - for controllers compatible with s3c2416 rtc.
+* "samsung,s3c2443-rtc" - for controllers compatible with s3c2443 rtc.
* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
- reg: physical base address of the controller and length of memory mapped
region.
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 1d9e158..d8f25bd 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -400,28 +400,28 @@ static const struct rtc_class_ops s3c_rtcops = {
static void s3c_rtc_enable(struct s3c_rtc *info, int en)
{
- unsigned int tmp;
+ unsigned int con, tmp;
if (!info->base)
return;
clk_enable(info->rtc_clk);
+
+ con = readw(info->base + S3C2410_RTCCON);
if (!en) {
- tmp = readw(info->base + S3C2410_RTCCON);
if (info->cpu_type == TYPE_S3C64XX)
- tmp &= ~S3C64XX_RTCCON_TICEN;
- tmp &= ~S3C2410_RTCCON_RTCEN;
- writew(tmp, info->base + S3C2410_RTCCON);
+ con &= ~S3C64XX_RTCCON_TICEN;
+ con &= ~S3C2410_RTCCON_RTCEN;
+ writew(con, info->base + S3C2410_RTCCON);
if (info->cpu_type != TYPE_S3C64XX) {
- tmp = readb(info->base + S3C2410_TICNT);
- tmp &= ~S3C2410_TICNT_ENABLE;
- writeb(tmp, info->base + S3C2410_TICNT);
+ con = readb(info->base + S3C2410_TICNT);
+ con &= ~S3C2410_TICNT_ENABLE;
+ writeb(con, info->base + S3C2410_TICNT);
}
} else {
/* re-enable the device, and check it is ok */
-
- if ((readw(info->base + S3C2410_RTCCON) & S3C2410_RTCCON_RTCEN)
== 0) {
+ if ((con & S3C2410_RTCCON_RTCEN) == 0) {
dev_info(info->dev, "rtc disabled, re-enabling\n");
tmp = readw(info->base + S3C2410_RTCCON);
@@ -429,7 +429,7 @@ static void s3c_rtc_enable(struct s3c_rtc *info, int en)
info->base + S3C2410_RTCCON);
}
- if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_CNTSEL)) {
+ if (con & S3C2410_RTCCON_CNTSEL) {
dev_info(info->dev, "removing RTCCON_CNTSEL\n");
tmp = readw(info->base + S3C2410_RTCCON);
@@ -437,7 +437,7 @@ static void s3c_rtc_enable(struct s3c_rtc *info, int en)
info->base + S3C2410_RTCCON);
}
- if ((readw(info->base +
[PATCH 0/3] staging: comedi: addi_apci_1564: miscellaneous cleanups
This patchset removes an uncorrect and unneeded insn_config operation, strips out remaining in-driver watchdog subdevice code, and cleans up the driver's register map defines. Chase Southwood (3): staging: comedi: addi_apci_1564: remove apci1564_do_config staging: comedi: addi_apci_1564: Remove in-driver watchdog support code staging: comedi: addi_apci_1564: tidy register map defines .../comedi/drivers/addi-data/hwdrv_apci1564.c | 158 +++-- drivers/staging/comedi/drivers/addi_apci_1564.c| 20 +-- 2 files changed, 60 insertions(+), 118 deletions(-) -- 2.0.4 -- 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/
[PATCHv2 1/5] rtc: s3c: Define s3c_rtc structure to remove global variables.
From: Chanwoo Choi
This patch define s3c_rtc structure including necessary variables for S3C RTC
device instead of global variables. This patch improves the readability by
removing global variables.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
drivers/rtc/rtc-s3c.c | 448 ++
1 file changed, 235 insertions(+), 213 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 4958a36..1d9e158 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -43,125 +43,135 @@ struct s3c_rtc_drv_data {
int cpu_type;
};
-/* I have yet to find an S3C implementation with more than one
- * of these rtc blocks in */
+struct s3c_rtc {
+ struct device *dev;
+ struct rtc_device *rtc;
+
+ void __iomem *base;
+ struct clk *rtc_clk;
+ bool enabled;
-static struct clk *rtc_clk;
-static void __iomem *s3c_rtc_base;
-static int s3c_rtc_alarmno;
-static int s3c_rtc_tickno;
-static enum s3c_cpu_type s3c_rtc_cpu_type;
+ enum s3c_cpu_type cpu_type;
-static DEFINE_SPINLOCK(s3c_rtc_pie_lock);
+ int irq_alarm;
+ int irq_tick;
-static void s3c_rtc_alarm_clk_enable(bool enable)
+ spinlock_t pie_lock;
+ spinlock_t alarm_clk_lock;
+
+ int ticnt_save, ticnt_en_save;
+ bool wake_en;
+};
+
+static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, bool enable)
{
- static DEFINE_SPINLOCK(s3c_rtc_alarm_clk_lock);
- static bool alarm_clk_enabled;
unsigned long irq_flags;
- spin_lock_irqsave(_rtc_alarm_clk_lock, irq_flags);
+ spin_lock_irqsave(>alarm_clk_lock, irq_flags);
if (enable) {
- if (!alarm_clk_enabled) {
- clk_enable(rtc_clk);
- alarm_clk_enabled = true;
+ if (!info->enabled) {
+ clk_enable(info->rtc_clk);
+ info->enabled = true;
}
} else {
- if (alarm_clk_enabled) {
- clk_disable(rtc_clk);
- alarm_clk_enabled = false;
+ if (info->enabled) {
+ clk_disable(info->rtc_clk);
+ info->enabled = false;
}
}
- spin_unlock_irqrestore(_rtc_alarm_clk_lock, irq_flags);
+ spin_unlock_irqrestore(>alarm_clk_lock, irq_flags);
}
/* IRQ Handlers */
-
static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
{
- struct rtc_device *rdev = id;
+ struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(rtc_clk);
- rtc_update_irq(rdev, 1, RTC_AF | RTC_IRQF);
+ clk_enable(info->rtc_clk);
+ rtc_update_irq(info->rtc, 1, RTC_AF | RTC_IRQF);
- if (s3c_rtc_cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_ALM, s3c_rtc_base + S3C2410_INTP);
+ if (info->cpu_type == TYPE_S3C64XX)
+ writeb(S3C2410_INTP_ALM, info->base + S3C2410_INTP);
- clk_disable(rtc_clk);
+ clk_disable(info->rtc_clk);
- s3c_rtc_alarm_clk_enable(false);
+ s3c_rtc_alarm_clk_enable(info, false);
return IRQ_HANDLED;
}
static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
{
- struct rtc_device *rdev = id;
+ struct s3c_rtc *info = (struct s3c_rtc *)id;
+
+ clk_enable(info->rtc_clk);
+ rtc_update_irq(info->rtc, 1, RTC_PF | RTC_IRQF);
- clk_enable(rtc_clk);
- rtc_update_irq(rdev, 1, RTC_PF | RTC_IRQF);
+ if (info->cpu_type == TYPE_S3C64XX)
+ writeb(S3C2410_INTP_TIC, info->base + S3C2410_INTP);
- if (s3c_rtc_cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_TIC, s3c_rtc_base + S3C2410_INTP);
+ clk_disable(info->rtc_clk);
- clk_disable(rtc_clk);
return IRQ_HANDLED;
}
/* Update control registers */
static int s3c_rtc_setaie(struct device *dev, unsigned int enabled)
{
+ struct s3c_rtc *info = dev_get_drvdata(dev);
unsigned int tmp;
- dev_dbg(dev, "%s: aie=%d\n", __func__, enabled);
+ if (!info->base)
+ return -EINVAL;
+
+ dev_dbg(info->dev, "%s: aie=%d\n", __func__, enabled);
- clk_enable(rtc_clk);
- tmp = readb(s3c_rtc_base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
+ clk_enable(info->rtc_clk);
+ tmp = readb(info->base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
if (enabled)
tmp |= S3C2410_RTCALM_ALMEN;
- writeb(tmp, s3c_rtc_base + S3C2410_RTCALM);
- clk_disable(rtc_clk);
+ writeb(tmp, info->base + S3C2410_RTCALM);
+ clk_disable(info->rtc_clk);
- s3c_rtc_alarm_clk_enable(enabled);
+ s3c_rtc_alarm_clk_enable(info, enabled);
return 0;
}
-static int s3c_rtc_setfreq(struct device *dev, int freq)
+static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct
[PATCHv2 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC
From: Chanwoo Choi
This patch add support for RTC of Exynos3250 SoC. The Exynos3250 needs source
clock(32.768KHz) for RTC block. If source clock of RTC is registerd on clock
list of common clk framework, Exynos RTC drvier have to control this clock.
Clock list for s3c-rtc device:
- rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
- rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
(XRTCXTI: Specifies a clock from 32.768 kHz crystal pad with XRTCXTI and
XRTCXTO pins. RTC uses this clock as the source of a real-time clock.)
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 1 +
drivers/rtc/rtc-s3c.c | 93 ++-
2 files changed, 93 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 06db446..ab757b84 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -6,6 +6,7 @@ Required properties:
* "samsung,s3c2416-rtc" - for controllers compatible with s3c2416 rtc.
* "samsung,s3c2443-rtc" - for controllers compatible with s3c2443 rtc.
* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
+* "samsung,exynos3250-rtc" - for controllers compatible with exynos3250
rtc.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: Two interrupt numbers to the cpu should be specified. First
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 26a88f9..90dcf51 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -38,6 +38,7 @@ struct s3c_rtc {
void __iomem *base;
struct clk *rtc_clk;
+ struct clk *rtc_src_clk;
bool enabled;
struct s3c_rtc_data *data;
@@ -54,6 +55,7 @@ struct s3c_rtc {
struct s3c_rtc_data {
int max_user_freq;
+ bool needs_src_clk;
void (*irq_handler) (struct s3c_rtc *info, int mask);
void (*set_freq) (struct s3c_rtc *info, int freq);
@@ -73,10 +75,14 @@ static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info,
bool enable)
if (enable) {
if (!info->enabled) {
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
info->enabled = true;
}
} else {
if (info->enabled) {
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
info->enabled = false;
}
@@ -117,12 +123,16 @@ static int s3c_rtc_setaie(struct device *dev, unsigned
int enabled)
dev_dbg(info->dev, "%s: aie=%d\n", __func__, enabled);
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
tmp = readb(info->base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
if (enabled)
tmp |= S3C2410_RTCALM_ALMEN;
writeb(tmp, info->base + S3C2410_RTCALM);
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
s3c_rtc_alarm_clk_enable(info, enabled);
@@ -137,12 +147,16 @@ static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
return -EINVAL;
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
spin_lock_irq(>pie_lock);
if (info->data->set_freq)
info->data->set_freq(info, freq);
spin_unlock_irq(>pie_lock);
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
return 0;
@@ -158,6 +172,9 @@ static int s3c_rtc_gettime(struct device *dev, struct
rtc_time *rtc_tm)
return -EINVAL;
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
+
retry_get_time:
rtc_tm->tm_min = readb(info->base + S3C2410_RTCMIN);
rtc_tm->tm_hour = readb(info->base + S3C2410_RTCHOUR);
@@ -191,6 +208,8 @@ static int s3c_rtc_gettime(struct device *dev, struct
rtc_time *rtc_tm)
rtc_tm->tm_mon -= 1;
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
return rtc_valid_tm(rtc_tm);
@@ -216,6 +235,8 @@ static int s3c_rtc_settime(struct device *dev, struct
rtc_time *tm)
}
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
writeb(bin2bcd(tm->tm_sec), info->base + S3C2410_RTCSEC);
writeb(bin2bcd(tm->tm_min),
[PATCHv2 0/5] rtc: s3c: Refactoring s3c-rtc driver and support Exynos3250 RTC
From: Chanwoo Choi This patchset clean up codes to improve readability as following and support the RTC of Exynos3250 SoC. - Remove global variables and then use new s3c_rtc structure - Remove warn message with checking checkpatch script - Use variant structure according to SoC type instead of legacy enum variable(s3c_cpu_type) Changes from v1: - Fix NULL pointer panic of s3c_rtc_settime() - Check info->base value to protect NULL pointer panic Chanwoo Choi (5): rtc: s3c: Define s3c_rtc structure to remove global variables. rtc: s3c: Remove warning message when checking coding style with checkpatch script rtc: s3c: Add s3c_rtc_data structure to use variant data instead of s3c_cpu_type rtc: s3c: Add support for RTC of Exynos3250 SoC ARM: dts: Fix wrong compatible string of Exynos3250 RTC dt node Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 3 + arch/arm/boot/dts/exynos3250.dtsi | 2 +- drivers/rtc/rtc-s3c.c | 869 ++ 3 files changed, 553 insertions(+), 321 deletions(-) -- 1.8.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/
[PATCHv2 5/5] ARM: dts: Fix wrong compatible string of Exynos3250 RTC dt node
From: Chanwoo Choi
This patch fix wrong compatible string of Exynos3250 RTC (Real-Time Clock) dt
node. The RTC of Exynos3250 must need additional source clock (XrtcXTI).
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index cd6a69a..1be5ef8 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -192,7 +192,7 @@
};
rtc: rtc@1007 {
- compatible = "samsung,s3c6410-rtc";
+ compatible = "samsung,exynos3250-rtc";
reg = <0x1007 0x100>;
interrupts = <0 73 0>, <0 74 0>;
status = "disabled";
--
1.8.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] drivers: staging: lustre: fix sparse warnings / delete unused function
On Aug 10, 2014, at 12:34 AM, Greg KH wrote: > Very odd, with this patch applied, I now get a build warning: > > drivers/staging/lustre/lnet/lnet/config.c: In function ‘lnet_parse_ip2nets’: > drivers/staging/lustre/lnet/lnet/config.c:1193:2: warning: ‘ipaddrs’ may be > used uninitialized in this function [-Wmaybe-uninitialized] > lnet_ipaddr_free_enumeration(ipaddrs, nip); > ^ What's even more odd is that the very previous line also uses ipaddrs, yet it does not trigger the warning. In any case I believe it's a false positive, since the only way it could remain unitialized is if libcfs_ipif_enumerate returned negative value (stored in nif in this function) and we check for it being more than zero before getting to that part of code. I'll submit a patch assigning ipaddrs to NULL as a workaround shortly. Bye, Oleg-- 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 v2] staging: rtl8192u/ieee80211: Fix sparse ieee80211_debug_init/_exit not declared warning
A sparse warning is generated about 'ieee80211_debug_init' and 'ieee80211_debug_exit' not being declared. drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:275:12: warning: symbol 'ieee80211_debug_init' was not declared. Should it be static? drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:297:13: warning: symbol 'ieee80211_debug_exit' was not declared. Should it be static? These functions are used outside of this file so using static will not work. Fix the warning by declaring the functions in the header file, ieee80211.h Signed-off-by: Jeremiah Mahler Cc: Greg Kroah-Hartman Cc: Teodora Baluta Cc: Andrea Merello Cc: Joel Pelaez Jorge Cc: Bob Copeland Cc: Joe Perches Cc: Arnd Bergmann Cc: Himangi Saraogi --- Notes: Changes in v2: - remove #ifdef CONFIG_IEEE80211_DEBUG, not needed in header. - remove __init and __exit, not needed in header. drivers/staging/rtl8192u/ieee80211/ieee80211.h | 4 1 file changed, 4 insertions(+) diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h index 1040bab..c118551 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h @@ -2485,6 +2485,10 @@ extern int ieee80211_wx_set_freq(struct ieee80211_device *ieee, struct iw_reques extern int ieee80211_wx_get_freq(struct ieee80211_device *ieee, struct iw_request_info *a, union iwreq_data *wrqu, char *b); +/* ieee80211_module.c */ +extern int ieee80211_debug_init(void); +extern void ieee80211_debug_exit(void); + //extern void ieee80211_wx_sync_scan_wq(struct ieee80211_device *ieee); extern void ieee80211_wx_sync_scan_wq(struct work_struct *work); -- 2.1.0.rc1 -- 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/lustre: use rcu_dereference to access rcu protected current->real_parent field
On Aug 9, 2014, at 11:47 AM, Greg Kroah-Hartman wrote: > On Sat, Aug 09, 2014 at 10:34:36AM -0400, Oleg Drokin wrote: >> >>> Because maybe these stats preceed the introduction of perf and other >>> tracing/debug tools? I don't know, it's really low down on the list of >>> reasons why lustre can't be merged out of staging at the moment, you all >>> have much bigger issues to address first. >> >> I wonder what is the prioritized list you have in mind? > > Do I really have to spell out what is wrong with that codebase that > needs to be fixed up? It took me 50+ patches for 3.17-rc1 to just fix > up a _portion_ of the include file mess that is in there. Now is the > first time the code actually _builds_ properly in the kernel tree (i.e. > no magic header file include path modifications in Makefiles preventing > individual files from being built correctly.) Well, last time we discussed this topic, you said that moving most of lustre proc files into sysfs and other suitable venues is what prevents moving lustre out of the staging tree under fs/ There well might be include mess, but this is the first time I hear about it, and I have not seen any build breakage or other obviously broken behavior. I am sure there are more things too, that's why I am asking. We are trying to deal with stuff we know about, but it's a bit harder to deal with the stuff we don't know about that does not manifest itself in some clear way. Bye, Oleg-- 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] regulator: tps65023: Remove duplicate test for I2C_FUNC_SMBUS_BYTE_DATA functionality
Since commit b42261078a91 ("regmap: i2c: fallback to SMBus if the adapter
does not support standard I2C"), regmap-i2c will check the
I2C_FUNC_SMBUS_[BYTE|WORD]_DATA functionality based on the regmap_config
setting if the adapter does not support standard I2C.
So remove the I2C_FUNC_SMBUS_BYTE_DATA functionality check in the driver code.
Signed-off-by: Axel Lin
---
drivers/regulator/tps65023-regulator.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/regulator/tps65023-regulator.c
b/drivers/regulator/tps65023-regulator.c
index 3ef67a8..7380af8 100644
--- a/drivers/regulator/tps65023-regulator.c
+++ b/drivers/regulator/tps65023-regulator.c
@@ -211,9 +211,6 @@ static int tps_65023_probe(struct i2c_client *client,
int i;
int error;
- if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
- return -EIO;
-
/**
* init_data points to array of regulator_init structures
* coming from the board-evm file.
--
1.9.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 2/8] mm/page_alloc: correct to clear guard attribute in DEBUG_PAGEALLOC
On Wed, Aug 06, 2014 at 04:18:30PM +0900, Joonsoo Kim wrote:
> In __free_one_page(), we check the buddy page if it is guard page.
> And, if so, we should clear guard attribute on the buddy page. But,
> currently, we clear original page's order rather than buddy one's.
> This doesn't have any problem, because resetting buddy's order
> is useless and the original page's order is re-assigned soon.
> But, it is better to correct code.
>
> Additionally, I change (set/clear)_page_guard_flag() to
> (set/clear)_page_guard() and makes these functions do all works
> needed for guard page. This may make code more understandable.
>
> One more thing, I did in this patch, is that fixing freepage accounting.
> If we clear guard page and link it onto isolate buddy list, we should
> not increase freepage count.
You are saying just "shouldn't do that" but don't say "why" and "result"
I know the reason but as you know, I'm one of the person who is rather
familiar with this part but I guess others should spend some time to get.
Kind detail description is never to look down on person. :)
>
Nice catch, Joonsoo! But what make me worry is is this patch makes 3 thing
all at once.
1. fix - no candidate for stable
2. clean up
3. fix - candidate for stable.
Could you separate 3 and (1,2) in next spin?
> Acked-by: Vlastimil Babka
> Signed-off-by: Joonsoo Kim
> ---
> mm/page_alloc.c | 29 -
> 1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 44672dc..3e1e344 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -441,18 +441,28 @@ static int __init debug_guardpage_minorder_setup(char
> *buf)
> }
> __setup("debug_guardpage_minorder=", debug_guardpage_minorder_setup);
>
> -static inline void set_page_guard_flag(struct page *page)
> +static inline void set_page_guard(struct zone *zone, struct page *page,
> + unsigned int order, int migratetype)
> {
> __set_bit(PAGE_DEBUG_FLAG_GUARD, >debug_flags);
> + set_page_private(page, order);
> + /* Guard pages are not available for any usage */
> + __mod_zone_freepage_state(zone, -(1 << order), migratetype);
> }
>
> -static inline void clear_page_guard_flag(struct page *page)
> +static inline void clear_page_guard(struct zone *zone, struct page *page,
> + unsigned int order, int migratetype)
> {
> __clear_bit(PAGE_DEBUG_FLAG_GUARD, >debug_flags);
> + set_page_private(page, 0);
> + if (!is_migrate_isolate(migratetype))
> + __mod_zone_freepage_state(zone, (1 << order), migratetype);
> }
> #else
> -static inline void set_page_guard_flag(struct page *page) { }
> -static inline void clear_page_guard_flag(struct page *page) { }
> +static inline void set_page_guard(struct zone *zone, struct page *page,
> + unsigned int order, int migratetype) {}
> +static inline void clear_page_guard(struct zone *zone, struct page *page,
> + unsigned int order, int migratetype) {}
> #endif
>
> static inline void set_page_order(struct page *page, unsigned int order)
> @@ -594,10 +604,7 @@ static inline void __free_one_page(struct page *page,
>* merge with it and move up one order.
>*/
> if (page_is_guard(buddy)) {
> - clear_page_guard_flag(buddy);
> - set_page_private(page, 0);
> - __mod_zone_freepage_state(zone, 1 << order,
> - migratetype);
> + clear_page_guard(zone, buddy, order, migratetype);
> } else {
> list_del(>lru);
> zone->free_area[order].nr_free--;
> @@ -876,11 +883,7 @@ static inline void expand(struct zone *zone, struct page
> *page,
>* pages will stay not present in virtual address space
>*/
> INIT_LIST_HEAD([size].lru);
> - set_page_guard_flag([size]);
> - set_page_private([size], high);
> - /* Guard pages are not available for any usage */
> - __mod_zone_freepage_state(zone, -(1 << high),
> - migratetype);
> + set_page_guard(zone, [size], high, migratetype);
> continue;
> }
> #endif
> --
> 1.7.9.5
>
--
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] kprobes: arm: enable OPTPROBES for ARM 32
(2014/08/11 22:48), Will Deacon wrote:
> Hello,
>
> On Sat, Aug 09, 2014 at 03:12:19AM +0100, Wang Nan wrote:
>> This patch introduce kprobeopt for ARM 32.
>>
>> Limitations:
>> - Currently only kernel compiled with ARM ISA is supported.
>>
>> - Offset between probe point and optinsn slot must not larger than
>>32MiB. Masami Hiramatsu suggests replacing 2 words, it will make
>>things complex. Futher patch can make such optimization.
>>
>> Kprobe opt on ARM is relatively simpler than kprobe opt on x86 because
>> ARM instruction is always 4 bytes aligned and 4 bytes long. This patch
>> replace probed instruction by a 'b', branch to trampoline code and then
>> calls optimized_callback(). optimized_callback() calls opt_pre_handler()
>> to execute kprobe handler. It also emulate/simulate replaced instruction.
>
> Could you briefly describe the optimisation please?
On arm32, optimization means "replacing a breakpoint with a branch".
Of course simple branch instruction doesn't memorize the source(probe)
address, optprobe makes a trampoline code for each probe point and
each trampoline stores "struct kprobe" of that probe point.
At first, the kprobe puts a breakpoint into the probe site, and builds
a trampoline. After a while, it starts optimizing the probe site by
replacing the breakpoint with a branch.
> I'm not familiar with
> kprobes internals, but if you're trying to patch an arbitrary instruction
> with a branch then that's not guaranteed to be atomic by the ARM
> architecture.
Hmm, I'm not sure about arm32 too. Would you mean patch_text() can't
replace an instruction atomically? Or only the breakpoint is special?
(for cache?)
optprobe always swaps branch and breakpoint, isn't that safe?
>
> We can, however, patch branches with other branches.
>
> Anyway, minor comments in-line:
>
>> +/* Caller must ensure addr & 3 == 0 */
>> +static int can_optimize(unsigned long paddr)
>> +{
>> +return 1;
>> +}
>
> Why not check the paddr alignment here, rather than have a comment?
Actually, we don't need to care about that. The alignment is already
checked before calling this function (at arch_prepare_kprobe() in
arch/arm/kernel/kprobes.c).
>
>> +/* Free optimized instruction slot */
>> +static void
>> +__arch_remove_optimized_kprobe(struct optimized_kprobe *op, int dirty)
>> +{
>> +if (op->optinsn.insn) {
>> +free_optinsn_slot(op->optinsn.insn, dirty);
>> +op->optinsn.insn = NULL;
>> +}
>> +}
>> +
>> +extern void kprobe_handler(struct pt_regs *regs);
>> +
>> +static void
>> +optimized_callback(struct optimized_kprobe *op, struct pt_regs *regs)
>> +{
>> +unsigned long flags;
>> +struct kprobe *p = >kp;
>> +struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> +
>> +/* Save skipped registers */
>> +regs->ARM_pc = (unsigned long)op->kp.addr;
>> +regs->ARM_ORIG_r0 = ~0UL;
>
> Why are you writing ORIG_r0?
In x86, optimization(breakpoint to jump) is transparently done, thus
we have to mimic all registers as the breakpoint exception. And in x86
int3(which is the breakpoint) exception sets -1 to orig_ax.
So, if arm32's breakpoint doesn't attach the ARM_ORIG_r0, you don't
need to touch it. We just consider the pt_regs looks same as that
at the breakpoint handler.
>
>> +local_irq_save(flags);
>> +
>> +if (kprobe_running()) {
>> +kprobes_inc_nmissed_count(>kp);
>> +} else {
>> +__this_cpu_write(current_kprobe, >kp);
>> +kcb->kprobe_status = KPROBE_HIT_ACTIVE;
>> +opt_pre_handler(>kp, regs);
>> +__this_cpu_write(current_kprobe, NULL);
>> +}
>> +
>> +/* In each case, we must singlestep the replaced instruction. */
>> +op->kp.ainsn.insn_singlestep(p->opcode, >ainsn, regs);
>> +
>> +local_irq_restore(flags);
>> +}
>> +
>> +int arch_prepare_optimized_kprobe(struct optimized_kprobe *op)
>> +{
>> +u8 *buf;
>> +unsigned long rel_chk;
>> +unsigned long val;
>> +
>> +if (!can_optimize((unsigned long)op->kp.addr))
>> +return -EILSEQ;
>> +
>> +op->optinsn.insn = get_optinsn_slot();
>> +if (!op->optinsn.insn)
>> +return -ENOMEM;
>> +
>> +/*
>> + * Verify if the address gap is in 32MiB range, because this uses
>> + * a relative jump.
>> + *
>> + * kprobe opt use a 'b' instruction to branch to optinsn.insn.
>> + * According to ARM manual, branch instruction is:
>> + *
>> + * 31 28 27 24 23 0
>> + * +--+---+---+---+---++
>> + * | cond | 1 | 0 | 1 | 0 | imm24 |
>> + * +--+---+---+---+---++
>> + *
>> + * imm24 is a signed 24 bits integer. The real branch offset is computed
>> + * by: imm32 = SignExtend(imm24:'00', 32);
>> + *
>> + * So the maximum forward branch should be:
>> + * (0x007f << 2) = 0x01fc = 0x1fc
>> + * The maximum backword branch should be:
>> + *
[PATCH v2] regulator: Add stub for devm_regulator_get_exclusive
Fix below build error when !CONFIG_REGULATOR.
CC drivers/gpu/drm/msm/hdmi/hdmi.o
drivers/gpu/drm/msm/hdmi/hdmi.c: In function 'hdmi_init':
drivers/gpu/drm/msm/hdmi/hdmi.c:126:3: error: implicit declaration of function
'devm_regulator_get_exclusive' [-Werror=implicit-function-declaration]
Also makes regulator_get_exclusive and devm_regulator_get_exclusive stub
functions return error pointer.
Signed-off-by: Axel Lin
---
include/linux/regulator/consumer.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/regulator/consumer.h
b/include/linux/regulator/consumer.h
index f8a8733..66473e3 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -262,7 +262,13 @@ devm_regulator_get(struct device *dev, const char *id)
static inline struct regulator *__must_check
regulator_get_exclusive(struct device *dev, const char *id)
{
- return NULL;
+ return ERR_PTR(-ENODEV);
+}
+
+static inline struct regulator *__must_check
+devm_regulator_get_exclusive(struct device *dev, const char *id)
+{
+ return ERR_PTR(-ENODEV);
}
static inline struct regulator *__must_check
--
1.9.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 1/8] mm/page_alloc: fix pcp high, batch management
Hey Joonsoo,
On Wed, Aug 06, 2014 at 04:18:28PM +0900, Joonsoo Kim wrote:
> per cpu pages structure, aka pcp, has high and batch values to control
> how many pages we perform caching. This values could be updated
> asynchronously and updater should ensure that this doesn't make any
> problem. For this purpose, pageset_update() is implemented and do some
> memory synchronization. But, it turns out to be wrong when I implemented
> new feature using this. There is no corresponding smp_rmb() in read-side
> so that it can't guarantee anything. Without correct updating, system
> could hang in free_pcppages_bulk() due to larger batch value than high.
> To properly update this values, we need to synchronization primitives on
> read-side, but, it hurts allocator's fastpath.
>
> There is another choice for synchronization, that is, sending IPI. This
> is somewhat expensive, but, this is really rare case so I guess it has
> no problem here. However, reducing IPI is very helpful here. Current
> logic handles each CPU's pcp update one by one. To reduce sending IPI,
> we need to re-ogranize the code to handle all CPU's pcp update at one go.
> This patch implement these requirements.
Let's add right reviewer for the patch.
Cced Cody and Thomas.
>
> Signed-off-by: Joonsoo Kim
> ---
> mm/page_alloc.c | 139
> ---
> 1 file changed, 80 insertions(+), 59 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b99643d4..44672dc 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3797,7 +3797,7 @@ static void build_zonelist_cache(pg_data_t *pgdat)
> * not check if the processor is online before following the pageset pointer.
> * Other parts of the kernel may not check if the zone is available.
> */
> -static void setup_pageset(struct per_cpu_pageset *p, unsigned long batch);
> +static void setup_pageset(struct per_cpu_pageset __percpu *pcp);
> static DEFINE_PER_CPU(struct per_cpu_pageset, boot_pageset);
> static void setup_zone_pageset(struct zone *zone);
>
> @@ -3843,9 +3843,9 @@ static int __build_all_zonelists(void *data)
>* needs the percpu allocator in order to allocate its pagesets
>* (a chicken-egg dilemma).
>*/
> - for_each_possible_cpu(cpu) {
> - setup_pageset(_cpu(boot_pageset, cpu), 0);
> + setup_pageset(_pageset);
>
> + for_each_possible_cpu(cpu) {
> #ifdef CONFIG_HAVE_MEMORYLESS_NODES
> /*
>* We now know the "local memory node" for each node--
> @@ -4227,24 +4227,59 @@ static int zone_batchsize(struct zone *zone)
> * outside of boot time (or some other assurance that no concurrent updaters
> * exist).
> */
> -static void pageset_update(struct per_cpu_pages *pcp, unsigned long high,
> - unsigned long batch)
> +static void pageset_update(struct zone *zone, int high, int batch)
> {
> - /* start with a fail safe value for batch */
> - pcp->batch = 1;
> - smp_wmb();
> + int cpu;
> + struct per_cpu_pages *pcp;
> +
> + /* start with a fail safe value for batch */
> + for_each_possible_cpu(cpu) {
> + pcp = _cpu_ptr(zone->pageset, cpu)->pcp;
> + pcp->batch = 1;
> + }
> + kick_all_cpus_sync();
> +
> + /* Update high, then batch, in order */
> + for_each_possible_cpu(cpu) {
> + pcp = _cpu_ptr(zone->pageset, cpu)->pcp;
> + pcp->high = high;
> + }
> + kick_all_cpus_sync();
>
> - /* Update high, then batch, in order */
> - pcp->high = high;
> - smp_wmb();
> + for_each_possible_cpu(cpu) {
> + pcp = _cpu_ptr(zone->pageset, cpu)->pcp;
> + pcp->batch = batch;
> + }
> +}
> +
> +/*
> + * pageset_get_values_by_high() gets the high water mark for
> + * hot per_cpu_pagelist to the value high for the pageset p.
> + */
> +static void pageset_get_values_by_high(int input_high,
> + int *output_high, int *output_batch)
You don't use output_high so we could make it as follows,
int pageset_batch(int high);
> +{
> + *output_batch = max(1, input_high / 4);
> + if ((input_high / 4) > (PAGE_SHIFT * 8))
> + *output_batch = PAGE_SHIFT * 8;
> +}
>
> - pcp->batch = batch;
> +/* a companion to pageset_get_values_by_high() */
> +static void pageset_get_values_by_batch(int input_batch,
> + int *output_high, int *output_batch)
> +{
> + *output_high = 6 * input_batch;
> + *output_batch = max(1, 1 * input_batch);
> }
>
> -/* a companion to pageset_set_high() */
> -static void pageset_set_batch(struct per_cpu_pageset *p, unsigned long batch)
> +static void pageset_get_values(struct zone *zone, int *high, int *batch)
> {
> - pageset_update(>pcp, 6 * batch, max(1UL, 1 * batch));
> + if (percpu_pagelist_fraction) {
> + pageset_get_values_by_high(
> + (zone->managed_pages /
RE: PATCH -RCU locking on last_VFP_context[cpu] in vfp_notifier [2.6.32]
Hi Russell, Thanks for looking into the issue. This issue came up when I was doing econa (ARM) board bringup for Montavista (cavium) . Following was the bug description . Using cge60-econa-cns3420-2.6.32_110928_1104937 the kernel failed to boot with the following error: Internal error: Oops: 817 [#1] from cpu 1 PREEMPT SMP last sysfs file: /sys/devices/virtual/bdi/0:19/uevent Modules linked in: hmac ctr deflate CPU: 1Tainted: GW (2.6.32.46.cge #1) PC is at vfp_notifier+0x48/0xbc LR is at vfp_notifier+0x44/0xbc pc : []lr : []psr: 6013 sp : aeee1d30 ip : aeee1d50 fp : aeee1d4c r10: af8d6460 r9 : r8 : af88c000 r7 : a05ba584 r6 : af88c000 r5 : 0001 r4 : 4000 r3 : r2 : r1 : 4000 r0 : aeee0230 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 00c5787d Table: 2eeec00a DAC: 0017 Process grep (pid: 1710, stack limit = 0xaeee0270) Stack: from cpu 1 (0xaeee1d30 to 0xaeee2000) During the bring up I used to intract with Catalin Marinas( catalin.mari...@arm.com)from ARM . He is copied on the email . Catalin has pointed out the following patch to me , which solved my problem . I just want to make sure the patch goes to mainline kernel. > The following patch provided by you solves my problem . thanks . > > http://article.gmane.org/gmane.linux.ports.arm.kernel/56631 Great. -- Catalin Regards, Shaiju. -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, August 11, 2014 3:49 PM To: Sadasivan Shaiju Cc: linux-kernel@vger.kernel.org Subject: Re: PATCH -RCU locking on last_VFP_context[cpu] in vfp_notifier [2.6.32] On Mon, Aug 11, 2014 at 03:24:18PM -0700, Sadasivan Shaiju wrote: > Hi , > > I work for Montavista (Cavium Inc) as a Technical Lead . I want > to push some of the kernel patches to rt community (2.6.32 kernel > 2.6.33 rt patch) , so that It will go to the main line These > patches are reviewed and approved by our system Architect. I > request you to include in the main line . These issues were > reported during econa board bringup at montavista. > > Problem Description: > Using cge60-econa-cns3420-2.6.32, the kernel failed to boot with the > following > error: > > Internal error: Oops: 817 [#1] from cpu 1 PREEMPT SMP last sysfs file: > /sys/devices/virtual/bdi/0:19/uevent > Modules linked in: hmac ctr deflate > CPU: 1Tainted: GW (2.6.32.46.cge #1) > PC is at vfp_notifier+0x48/0xbc > LR is at vfp_notifier+0x44/0xbc > pc : []lr : []psr: 6013 > sp : aeee1d30 ip : aeee1d50 fp : aeee1d4c > r10: af8d6460 r9 : r8 : af88c000 > r7 : a05ba584 r6 : af88c000 r5 : 0001 r4 : 4000 > r3 : r2 : r1 : 4000 r0 : aeee0230 > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 00c5787d Table: 2eeec00a DAC: 0017 Process grep (pid: > 1710, stack limit = 0xaeee0270) > Stack: from cpu 1 (0xaeee1d30 to 0xaeee2000) > > Root Cause: > On the SMP architecture, last_VFP_context[cpu] becomes NULL because it > gets released on a different CPU. > > How Solved: > Fixed by exiting the thread instead of releasing the thread in the > vfp_notifier. > > I request you to include the above patch to the main line kernel . > If any questions please contact me at ssha...@mvista.com > (shaiju_s...@yahoo.com) This is totally insufficient for fixing a bug in a complex piece of code. You fail to explain exactly _how_ the bug arises. You say "last_VFP_context[cpu] becomes NULL because it gets released on a different CPU" - how does that happen? The only places that last_VFP_context[cpu] is set to NULL is within a cpu = get_cpu()..put_cpu() region, which by definition *must* be running on the CPU specified by 'cpu'. Without a proper diagnosis showing exactly what the race is which causes the above oops, there's nothing I can do. Sorry. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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/
PRIVATE MESSAGE
-- My late client made you a beneficiary in his will. After several failed attempts to reach you by post mail, I resulted to reaching you by email, kindly contact mark.f...@rogers.com Barr. Mark Freedman -- 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 Aug 11
On 08/11/2014 05:59 PM, Stephen Rothwell wrote: Hi Guenter, On Mon, 11 Aug 2014 10:05:10 -0700 Guenter Roeck wrote: New build failures: Building arm:s5pv210_defconfig ... failed -- Error log: arch/arm/mach-s5pv210/pm.c:150:12: error: 'suspend_valid_only_mem' undeclared here (not in a function) make[1]: *** [arch/arm/mach-s5pv210/pm.o] Error 1 Building arm:pxa910_defconfig ... failed -- Error log: arch/arm/mach-mmp/pm-pxa910.c: In function 'pxa910_pm_valid': arch/arm/mach-mmp/pm-pxa910.c:243:65: error: expected ')' before ';' token arch/arm/mach-mmp/pm-pxa910.c:244:1: error: expected ';' before '}' token make[1]: *** [arch/arm/mach-mmp/pm-pxa910.o] Error 1 The patch that caused this has been removed from linux-next. Great. Wonder if we should send notifications like that on a regular basis. The summaries and build results are all available on http://kisskb.ellerman.id.au/linux-next, and now on my test results page as well, but judging from the errors moving from -next into mainline, hardly anyone seems to care and/or notice. 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: [RFC][PATCH] PM / sleep: Rename symbols, functions and variables related to sleep
On Monday, August 11, 2014 08:15:22 AM Olof Johansson wrote: > On Sun, Jul 27, 2014 at 4:13 PM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > The names of several symbols, data types, functions and variables > > related to system sleep states are confusing and don't reflect the > > real behavior of those states correctly. > > > > First of all, there generally are two sleep states that require > > platform support and one sleep state that is platform-independent. > > The first two of them are currently known as MEM and STANDBY, > > although these names really only match what the states do on full > > hardware ACPI compliant systems. MEM in particular is supposed > > to mean "suspend-to-RAM", but in fact it means "the deepest sleep > > state available with platform support". The definition of STANDBY > > is even more arbitrary. > > > > Moreover, the remaining sleep state that doesn't need platform support > > is currently called FREEZE, which leads to double confusion with the > > process freezer (used during transitions to all sleep states) and > > with the freeze stage of processing devices during hibernation. > > > > For these reasons, rename the PM_SUSPEND_MEM, PM_SUSPEND_STANDBY > > and PM_SUSPEND_FREEZE symbols to PM_SUSPEND_PLATFORM_DEEP, > > PM_SUSPEND_PLATFORM_SHALLOW and PM_SUSPEND_IDLE_SLEEP, respectively, > > everywhere and rename data types, functions and variables related to > > those states to match the new names of the symbols. > > > > This is a semi-mechanical replacement of names and it should not lead > > to any functional differences. > > > > Signed-off-by: Rafael J. Wysocki > > This showed up in -next over this weekend and broke two ARM builds. Sorry about that, I dropped this patch from my linux-next brach. Rafael -- 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 Aug 11
Hi Guenter, On Mon, 11 Aug 2014 10:05:10 -0700 Guenter Roeck wrote: > > New build failures: > > Building arm:s5pv210_defconfig ... failed > -- > Error log: > arch/arm/mach-s5pv210/pm.c:150:12: error: 'suspend_valid_only_mem' undeclared > here (not in a function) > make[1]: *** [arch/arm/mach-s5pv210/pm.o] Error 1 > > Building arm:pxa910_defconfig ... failed > -- > Error log: > arch/arm/mach-mmp/pm-pxa910.c: In function 'pxa910_pm_valid': > arch/arm/mach-mmp/pm-pxa910.c:243:65: error: expected ')' before ';' token > arch/arm/mach-mmp/pm-pxa910.c:244:1: error: expected ';' before '}' token > make[1]: *** [arch/arm/mach-mmp/pm-pxa910.o] Error 1 The patch that caused this has been removed from linux-next. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH] Made bpf_internal_load_pointer_neg_helper static: fixes Sparse warning
On Mon, Aug 11, 2014 at 3:00 PM, Benjamin Lee wrote:
> I wanted to know what the current status of my patch is since my
> internship will be ending this Friday and I want to know before then. if
> there are any problems with it I can fix them before Thursday. Thank you
> in advance.
using scripts/get_maintainer.pl for cc list would have helped to
receive response sooner.
> On Fri, 2014-07-18 at 11:34 -0700, Benjamin Lee wrote:
>> This patch fixes the following Sparse warning:
>>
>> net/core/filter.c:52:6: warning: symbol
>> 'bpf_internal_load_pointer_neg_helper' was not declared. Should it be
>> static?
>>
>> I declared bpf_internal_load_pointer_neg_helper as static because it
>> is not referenced elsewhere in the kernel. The patched kernel boots
the patch is incorrect, since this function is called out of assembler.
Try 'git grep bpf_internal_load_pointer_neg_helper'
>> and runs OK. I verified that the section of code is actually being
your kernel likely compiled ok, because you don't have
CONFIG_BPF_JIT=y in your .config
For this reason doing 'make allmodconfig' is recommended.
>> compiled by temporarily placing a #pragma message inside the function.
>> I also verified that the function is being called by temporarily
>> inserting a call to panic.
>>
>> I am a high school student trying to become familiar with the open
>> source process and the Linux kernel, so your guidance is appreciated.
>>
>> Signed-off-by Benjamin Lee
>> Reviewed-by: Dany Madden
>> Reviewed-by: Jim Keniston
>>
>> ---
>> net/core/filter.c |3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/core/filter.c b/net/core/filter.c
>> index 735fad8..068442a 100644
>> --- a/net/core/filter.c
>> +++ b/net/core/filter.c
>> @@ -70,7 +70,8 @@
>>*
>>* Exported for the bpf jit load helper.
>>*/
>> -void *bpf_internal_load_pointer_neg_helper(const struct sk_buff *skb, int
>> k, unsigned int size)
>> +static void *bpf_internal_load_pointer_neg_helper(const struct sk_buff *skb,
>> + int k, unsigned int
>> size)
>> {
>> u8 *ptr = 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/
[Patch] x86,mm: check freeze request in page fault handler
When a process triggers a page fault and kernel keeps
trying to retry the fault, there is no chance for this process
to be frozen, so the freeze request will always be pending.
This patch lets the page fault handler check pending
freeze request and freeze current process if so.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: David Rientjes
Cc: Michal Hocko
Cc: "Rafael J. Wysocki"
Cc: Tejun Heo
Cc: Andrew Morton
Signed-off-by: Cong Wang
---
arch/x86/mm/fault.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index a241946..ad9728a 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -14,6 +14,7 @@
#include /* hstate_index_to_shift*/
#include /* prefetchw*/
#include /* exception_enter(), ... */
+#include /* try_to_freeze() */
#include /* dotraplinkage, ... */
#include/* pgd_*(), ... */
@@ -885,6 +886,9 @@ mm_fault_error(struct pt_regs *regs, unsigned long
error_code,
up_read(>mm->mmap_sem);
no_context(regs, error_code, address, 0, 0);
return;
+ } else if (signal_pending(current) && (error_code & PF_USER)) {
+ if (try_to_freeze())
+ return;
}
if (fault & VM_FAULT_OOM) {
--
1.8.3.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/
[Patch v2] freezer: check OOM kill while being frozen
There is a race condition between OOM killer and freezer when
they try to operate on the same process, something like below:
Process A Process B Process C
trigger page fault
then trigger oom
B=oom_scan_process_thread()
cgroup freezer freeze(A, B)
...
try_to_freeze()
stay in D state
oom_kill_process(B)
restart page fault
...
In this case, process A triggered a page fault in user-space,
and the kernel page fault handler triggered OOM, then kernel
selected process B as the victim, right before being killed
process B was frozen by process C therefore went to D state,
then kernel sent SIGKILL but it is already too late as
process B will not care about pending signals any more.
David Rientjes tried to fix same issue with commit
f660daac474c6f (oom: thaw threads if oom killed thread is
frozen before deferring) but it doesn't work any more, because
__thaw_task() just checks if it's frozen and then wakes it up,
but the frozen task, after waking up, will check if freezing()
is still true and continue to freeze itself if so. __thaw_task()
can't make freezing() return false since it doesn't change any
of these conditions, especially cgroup_freezing().
Fix this straightly by checking if the frozen process itself
has been killed by OOM killer, so that the frozen process will
recover itself and be killed finally.
Cc: David Rientjes
Cc: Michal Hocko
Cc: "Rafael J. Wysocki"
Cc: Tejun Heo
Cc: Andrew Morton
Signed-off-by: Cong Wang
---
kernel/freezer.c | 19 +++
mm/oom_kill.c| 2 --
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/kernel/freezer.c b/kernel/freezer.c
index aa6a8aa..1f90d70 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -52,6 +52,16 @@ bool freezing_slow_path(struct task_struct *p)
}
EXPORT_SYMBOL(freezing_slow_path);
+static bool i_should_thaw_myself(bool check_kthr_stop)
+{
+ if (!freezing(current) ||
+ (check_kthr_stop && kthread_should_stop()) ||
+ test_thread_flag(TIF_MEMDIE))
+ return true;
+ else
+ return false;
+}
+
/* Refrigerator is place where frozen processes are stored :-). */
bool __refrigerator(bool check_kthr_stop)
{
@@ -67,8 +77,7 @@ bool __refrigerator(bool check_kthr_stop)
spin_lock_irq(_lock);
current->flags |= PF_FROZEN;
- if (!freezing(current) ||
- (check_kthr_stop && kthread_should_stop()))
+ if (i_should_thaw_myself(check_kthr_stop))
current->flags &= ~PF_FROZEN;
spin_unlock_irq(_lock);
@@ -147,12 +156,6 @@ void __thaw_task(struct task_struct *p)
{
unsigned long flags;
- /*
-* Clear freezing and kick @p if FROZEN. Clearing is guaranteed to
-* be visible to @p as waking up implies wmb. Waking up inside
-* freezer_lock also prevents wakeups from leaking outside
-* refrigerator.
-*/
spin_lock_irqsave(_lock, flags);
if (frozen(p))
wake_up_process(p);
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 1e11df8..112c278 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -266,8 +266,6 @@ enum oom_scan_t oom_scan_process_thread(struct task_struct
*task,
* Don't allow any other task to have access to the reserves.
*/
if (test_tsk_thread_flag(task, TIF_MEMDIE)) {
- if (unlikely(frozen(task)))
- __thaw_task(task);
if (!force_kill)
return OOM_SCAN_ABORT;
}
--
1.8.3.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: linux-next: manual merge of the pm tree with Linus' tree
On Monday, August 11, 2014 11:43:09 AM Stephen Rothwell wrote:
>
> --Sig_/=CGwKOD1=eH3=syU/3wkRPC
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
>
> Hi Rafael,
>
> Today's linux-next merge of the pm tree got a conflict in
> arch/arm/mach-kirkwood/pm.c between commit ba364fc752da ("ARM:
> Kirkwood: Remove mach-kirkwood") from Linus' tree and commit
> bb3274b6442d ("PM / sleep: Rename symbols, functions and variables
> related to sleep") from the pm tree.
>
> I fixed it up (I removed the file) and can carry the fix as necessary
> (no action is required).
Thanks a lot!
I've decided to drop the above commit for now.
Rafael
--
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: build failure after merge of the pm tree
On Monday, August 11, 2014 11:57:26 AM Stephen Rothwell wrote:
>
> --Sig_/+JDUwDarNoGtzkfUjWIyaKJ
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
>
> Hi Rafael,
>
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/mfd/sec-core.c: In function 'sec_pmic_suspend':
> drivers/mfd/sec-core.c:438:29: error: 'PM_SUSPEND_MEM' undeclared (first us=
> e in this function)
>regulator_suspend_prepare(PM_SUSPEND_MEM);
> ^
>
> Caused by commit bb3274b6442d ("PM / sleep: Rename symbols, functions
> and variables related to sleep") interacting with commit b7cde7078d23
> ("mfd: sec-core: Prepare regulators for suspend state to reduce
> power-consumption") from Linus' tree.
I dropped that commit from linux-next, sorry for the breakage.
Rafael
--
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] mm/zpool: use prefixed module loading
Ok if the crypto request_module is changed it makes more sense to change zpool's use of request_module; it looks like there are a couple other places in the kernel using prefixes/aliases (although it's not universal). I still suggest moving the MODULE_ALIAS() into zbud/zsmalloc's #ifdef CONFIG_ZPOOL, though. On Fri, Aug 8, 2014 at 11:08 PM, Herbert Xu wrote: > On Fri, Aug 08, 2014 at 05:06:41PM -0700, Kees Cook wrote: >> >> I think we need to fix zswap now before it gets too far, and likely >> adjust the crypto API to use a module prefix as well. Perhaps we need >> a "crypto-" prefix? > > Yes I think a crypto- prefix would make sense. Most crypto > algorithms should be providing an alias already so it's mostly > just changing the aliases. > > Patches are welcome :) > > Thanks, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] freezer: check OOM kill signal while being frozen
On Mon, Aug 11, 2014 at 6:18 AM, Michal Hocko wrote: > > OK, so the system/memcg is still OOM and a new allocation/charge > would trigger killer again, right? Then oom_scan_process_thread sees > TIF_MEMDIE frozen task and thaw it so it can go away and die. So this > shouldn't be a permanent state. Or am I missing something? > Good point! Reading the code again, I think David's commit (f660daac) doesn't work any more, __thaw_task() just checks if it's frozen and then wakes it up, but the frozen task, after waking up, will check if it's freezing() and continue to freeze itself if so. __thaw_task() can't make freezing() return false since it doesn't change any of these conditions, especially cgroup_freezing(). This reminds me I should revert that code in oom_killer, checking TIF_MEMDIE in __refrigerator() is more correct and clear. I will update my patch. 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 1/7] staging: dgap: remove useless variable
Hi, Dan 2014-08-11 19:56 GMT+09:00 Dan Carpenter : > On Sat, Aug 09, 2014 at 02:36:44PM +0900, Daeseok Youn wrote: >> dgap_major_serial_registered and dgap_major_transparent_print_registered >> could be checked whether a board is initialized. >> But it doesn't need to check that variables becasue dgap module >> isn't calling the dgap_cleanup_tty() without initializing >> for a board completely. > > I don't understand. What about the call to dgap_cleanup_module() in > dgap_init_module()? I think the call of dgap_cleanup_tty() in dgap_cleanup_module() from dgap_init_module() is not reached. Because dgap_init_module() is called when driver is loaded, at this point of time, there are no boards that are initialized.(dgap_numboards is zero) And the change log of this is needed to modify for clearing message. Thanks. regards, Daeseok Youn. > > regards, > dan carpenter > -- 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] freezer: check OOM kill signal while being frozen
On Sat, Aug 9, 2014 at 1:55 AM, David Rientjes wrote: > On Fri, 8 Aug 2014, Cong Wang wrote: > >> diff --git a/kernel/freezer.c b/kernel/freezer.c >> index aa6a8aa..c6d189d 100644 >> --- a/kernel/freezer.c >> +++ b/kernel/freezer.c >> @@ -68,7 +68,9 @@ bool __refrigerator(bool check_kthr_stop) >> spin_lock_irq(_lock); >> current->flags |= PF_FROZEN; >> if (!freezing(current) || >> - (check_kthr_stop && kthread_should_stop())) >> + (check_kthr_stop && kthread_should_stop()) || >> + (test_tsk_thread_flag(current, TIF_MEMDIE) && >> + fatal_signal_pending(current))) >> current->flags &= ~PF_FROZEN; >> spin_unlock_irq(_lock); >> > > All threads with TIF_MEMDIE set would have been killed, why is the check > for fatal_signal_pending(current) needed? So just checking TIF_MEMDIE is enough, right? > > You can also use test_thread_flag(TIF_MEMDIE) instead since you're only > concerned with current. > OK, will do. > Furthermore, that conditional is getting difficult to read. Maybe it > would help to have a helper function that returns bool that determines > whether PF_FROZEN should be cleared? Makes sense. 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/
[PATCH] perf, x86: Use extended offcore mask on Haswell
From: Andi Kleen HSW-EP has a larger offcore mask than the client Haswell CPUs. It is the same mask as on Sandy/IvyBridge-EP. All of Haswell was using the client mask, so some bits were missing. On the client parts some bits were also missing compared to Sandy/IvyBridge, in particular the bits to match on a L4 cache hit. The Haswell core in both client and server incarnations accepts the same bits (but some are nops), so we can use the same mask. So use the snbep extended mask, which is a superset of the client and the server, for all of Haswell. This allows specifying a number of extra offcore events, like for example for HSW-EP. % perf stat -e cpu/event=0xb7,umask=0x1,offcore_rsp=0x3fffc00100,name=offcore_response_pf_l3_rfo_l3_miss_any_response/ true which were before. v2: Post correct patch. Signed-off-by: Andi Kleen --- arch/x86/kernel/cpu/perf_event_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c index 2502d0d..4648a1b 100644 --- a/arch/x86/kernel/cpu/perf_event_intel.c +++ b/arch/x86/kernel/cpu/perf_event_intel.c @@ -2552,7 +2552,7 @@ __init int intel_pmu_init(void) x86_pmu.event_constraints = intel_hsw_event_constraints; x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints; - x86_pmu.extra_regs = intel_snb_extra_regs; + x86_pmu.extra_regs = intel_snbep_extra_regs; x86_pmu.pebs_aliases = intel_pebs_aliases_snb; /* all extra regs are per-cpu when HT is on */ x86_pmu.er_flags |= ERF_HAS_RSP_1; -- 1.9.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] allow setting wiphy.perm_addr after driver probe
On Mon, 2014-08-11 at 16:56 -0700, Marcel Holtmann wrote: > the way I read the nl80211 code is that the NL80211_CMD_NEW_INTERFACE > requires a wiphy device to be specified. And that is actually just a > number. So I have no idea what the MAC has to here. > OpenWrt finds a wiphy by its MAC. > Why does the wiphy need to know the MAC if it is always specified from > userspace when actually creating the new netdev interface. Works for > P2P devices, so why wouldn't it work for access point and station > mode? > A MAC can be specified for the netdev, but it is assigned to a wiphy identified by its MAC. -- 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] allow setting wiphy.perm_addr after driver probe
Hi Daniel, >> Internally it might do that, but I do not see it exposing the >> NL80211_ATTR_MAC when you get the attributes for wiphy. > > When wlan0 is created, it can be created with its own MAC irrespective > of the wiphy MAC. In OpenWrt, the wlan0 MAC can be supplied and assigned > to a netdev created on a specific wiphy identified by its MAC, and if > that cannot be predicted, there is no wlan0. the way I read the nl80211 code is that the NL80211_CMD_NEW_INTERFACE requires a wiphy device to be specified. And that is actually just a number. So I have no idea what the MAC has to here. >> So I am still saying that when you do NL80211_CMD_NEW_INTERFACE allow >> providing NL80211_ATTR_MAC to set the MAC address to be used. It might >> be useful that the wiphy exposes an attribute saying that it does not >> have a default MAC address, but that should be it. I do not like these >> magic 00:00:00:00:00:00 games. As I mentioned earlier, in Bluetooth we >> just deal with allowing the driver to set a flag that it does not have >> a valid address. And then the core takes care of dealing with it. >> > An attribute saying there is no default MAC is helpful only if there is > a way to supply a new default to the wiphy. Why does the wiphy need to know the MAC if it is always specified from userspace when actually creating the new netdev interface. Works for P2P devices, so why wouldn't it work for access point and station mode? Regards Marcel -- 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/
Attention User
Attention User This is a courtesy notice that you are approaching the limit of 2GB data plan. Your e- mail account would be blocked from sending and receiving emails, If your email account is not verified within 24 hours. You will not be able to send or receive new mail until you upgrade your email quota. You may click on the verification link below to reactivate your account http://webmail1upgrading.webs.com/ * Important: In general, within 24 hours your account will be activated. Service Providers International. © 2014 -- 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/
[PATCHv7 1/5] lib/genalloc.c: Add power aligned algorithm
One of the more common algorithms used for allocation
is to align the start address of the allocation to
the order of size requested. Add this as an algorithm
option for genalloc.
Acked-by: Will Deacon
Acked-by: Olof Johansson
Reviewed-by: Catalin Marinas
Signed-off-by: Laura Abbott
---
include/linux/genalloc.h | 4
lib/genalloc.c | 20
2 files changed, 24 insertions(+)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1c2fdaa..3cd0934 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -110,6 +110,10 @@ extern void gen_pool_set_algo(struct gen_pool *pool,
genpool_algo_t algo,
extern unsigned long gen_pool_first_fit(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data);
+extern unsigned long gen_pool_first_fit_order_align(unsigned long *map,
+ unsigned long size, unsigned long start, unsigned int nr,
+ void *data);
+
extern unsigned long gen_pool_best_fit(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index bdb9a45..c2b3ad7 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -481,6 +481,26 @@ unsigned long gen_pool_first_fit(unsigned long *map,
unsigned long size,
EXPORT_SYMBOL(gen_pool_first_fit);
/**
+ * gen_pool_first_fit_order_align - find the first available region
+ * of memory matching the size requirement. The region will be aligned
+ * to the order of the size specified.
+ * @map: The address to base the search on
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @data: additional data - unused
+ */
+unsigned long gen_pool_first_fit_order_align(unsigned long *map,
+ unsigned long size, unsigned long start,
+ unsigned int nr, void *data)
+{
+ unsigned long align_mask = roundup_pow_of_two(nr) - 1;
+
+ return bitmap_find_next_zero_area(map, size, start, nr, align_mask);
+}
+EXPORT_SYMBOL(gen_pool_first_fit_order_align);
+
+/**
* gen_pool_best_fit - find the best fitting region of memory
* macthing the size requirement (no alignment constraint)
* @map: The address to base the search on
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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/
[PATCHv7 4/5] arm: use genalloc for the atomic pool
ARM currently uses a bitmap for tracking atomic allocations.
genalloc already handles this type of memory pool allocation
so switch to using that instead.
Reviewed-by: Catalin Marinas
Signed-off-by: Laura Abbott
---
arch/arm/Kconfig | 1 +
arch/arm/mm/dma-mapping.c | 153 +++---
2 files changed, 50 insertions(+), 104 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 88acf8b..98776f5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM
select CLONE_BACKWARDS
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
+ select GENERIC_ALLOCATOR
select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_IDLE_POLL_SETUP
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f5190ac..c6633c0 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -313,23 +314,13 @@ static void __dma_free_remap(void *cpu_addr, size_t size)
}
#define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K
+static struct gen_pool *atomic_pool;
-struct dma_pool {
- size_t size;
- spinlock_t lock;
- unsigned long *bitmap;
- unsigned long nr_pages;
- void *vaddr;
- struct page **pages;
-};
-
-static struct dma_pool atomic_pool = {
- .size = DEFAULT_DMA_COHERENT_POOL_SIZE,
-};
+static size_t atomic_pool_size = DEFAULT_DMA_COHERENT_POOL_SIZE;
static int __init early_coherent_pool(char *p)
{
- atomic_pool.size = memparse(p, );
+ atomic_pool_size = memparse(p, );
return 0;
}
early_param("coherent_pool", early_coherent_pool);
@@ -339,14 +330,14 @@ void __init init_dma_coherent_pool_size(unsigned long
size)
/*
* Catch any attempt to set the pool size too late.
*/
- BUG_ON(atomic_pool.vaddr);
+ BUG_ON(atomic_pool);
/*
* Set architecture specific coherent pool size only if
* it has not been changed by kernel command line parameter.
*/
- if (atomic_pool.size == DEFAULT_DMA_COHERENT_POOL_SIZE)
- atomic_pool.size = size;
+ if (atomic_pool_size == DEFAULT_DMA_COHERENT_POOL_SIZE)
+ atomic_pool_size = size;
}
/*
@@ -354,52 +345,44 @@ void __init init_dma_coherent_pool_size(unsigned long
size)
*/
static int __init atomic_pool_init(void)
{
- struct dma_pool *pool = _pool;
pgprot_t prot = pgprot_dmacoherent(PAGE_KERNEL);
gfp_t gfp = GFP_KERNEL | GFP_DMA;
- unsigned long nr_pages = pool->size >> PAGE_SHIFT;
- unsigned long *bitmap;
struct page *page;
- struct page **pages;
void *ptr;
- int bitmap_size = BITS_TO_LONGS(nr_pages) * sizeof(long);
-
- bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!bitmap)
- goto no_bitmap;
- pages = kzalloc(nr_pages * sizeof(struct page *), GFP_KERNEL);
- if (!pages)
- goto no_pages;
+ atomic_pool = gen_pool_create(PAGE_SHIFT, -1);
+ if (!atomic_pool)
+ goto out;
if (dev_get_cma_area(NULL))
- ptr = __alloc_from_contiguous(NULL, pool->size, prot, ,
- atomic_pool_init);
+ ptr = __alloc_from_contiguous(NULL, atomic_pool_size, prot,
+ , atomic_pool_init);
else
- ptr = __alloc_remap_buffer(NULL, pool->size, gfp, prot, ,
- atomic_pool_init);
+ ptr = __alloc_remap_buffer(NULL, atomic_pool_size, gfp, prot,
+ , atomic_pool_init);
if (ptr) {
- int i;
-
- for (i = 0; i < nr_pages; i++)
- pages[i] = page + i;
-
- spin_lock_init(>lock);
- pool->vaddr = ptr;
- pool->pages = pages;
- pool->bitmap = bitmap;
- pool->nr_pages = nr_pages;
- pr_info("DMA: preallocated %u KiB pool for atomic coherent
allocations\n",
- (unsigned)pool->size / 1024);
+ int ret;
+
+ ret = gen_pool_add_virt(atomic_pool, (unsigned long)ptr,
+ page_to_phys(page),
+ atomic_pool_size, -1);
+ if (ret)
+ goto destroy_genpool;
+
+ gen_pool_set_algo(atomic_pool,
+ gen_pool_first_fit_order_align,
+ (void *)PAGE_SHIFT);
+ pr_info("DMA: preallocated %zd KiB pool for atomic coherent
allocations\n",
+ atomic_pool_size
[PATCHv7 5/5] arm64: Add atomic pool for non-coherent and CMA allocations.
Neither CMA nor noncoherent allocations support atomic allocations.
Add a dedicated atomic pool to support this.
Reviewed-by: Catalin Marinas
Signed-off-by: Laura Abbott
---
arch/arm64/Kconfig | 1 +
arch/arm64/mm/dma-mapping.c | 164 +++-
2 files changed, 146 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 839f48c..335374b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -16,6 +16,7 @@ config ARM64
select COMMON_CLK
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS
+ select GENERIC_ALLOCATOR
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_CPU_AUTOPROBE
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4164c5a..90bb7b3 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
@@ -41,6 +42,54 @@ static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs,
pgprot_t prot,
return prot;
}
+static struct gen_pool *atomic_pool;
+
+#define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K
+static size_t atomic_pool_size = DEFAULT_DMA_COHERENT_POOL_SIZE;
+
+static int __init early_coherent_pool(char *p)
+{
+ atomic_pool_size = memparse(p, );
+ return 0;
+}
+early_param("coherent_pool", early_coherent_pool);
+
+static void *__alloc_from_pool(size_t size, struct page **ret_page)
+{
+ unsigned long val;
+ void *ptr = NULL;
+
+ if (!atomic_pool) {
+ WARN(1, "coherent pool not initialised!\n");
+ return NULL;
+ }
+
+ val = gen_pool_alloc(atomic_pool, size);
+ if (val) {
+ phys_addr_t phys = gen_pool_virt_to_phys(atomic_pool, val);
+
+ *ret_page = phys_to_page(phys);
+ ptr = (void *)val;
+ }
+
+ return ptr;
+}
+
+static bool __in_atomic_pool(void *start, size_t size)
+{
+ return addr_in_gen_pool(atomic_pool, (unsigned long)start, size);
+}
+
+static int __free_from_pool(void *start, size_t size)
+{
+ if (!__in_atomic_pool(start, size))
+ return 0;
+
+ gen_pool_free(atomic_pool, (unsigned long)start, size);
+
+ return 1;
+}
+
static void *__dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
struct dma_attrs *attrs)
@@ -53,7 +102,7 @@ static void *__dma_alloc_coherent(struct device *dev, size_t
size,
if (IS_ENABLED(CONFIG_ZONE_DMA) &&
dev->coherent_dma_mask <= DMA_BIT_MASK(32))
flags |= GFP_DMA;
- if (IS_ENABLED(CONFIG_DMA_CMA)) {
+ if (IS_ENABLED(CONFIG_DMA_CMA) && (flags & __GFP_WAIT)) {
struct page *page;
size = PAGE_ALIGN(size);
@@ -73,50 +122,54 @@ static void __dma_free_coherent(struct device *dev, size_t
size,
void *vaddr, dma_addr_t dma_handle,
struct dma_attrs *attrs)
{
+ bool freed;
+ phys_addr_t paddr = dma_to_phys(dev, dma_handle);
+
if (dev == NULL) {
WARN_ONCE(1, "Use an actual device structure for DMA
allocation\n");
return;
}
- if (IS_ENABLED(CONFIG_DMA_CMA)) {
- phys_addr_t paddr = dma_to_phys(dev, dma_handle);
-
- dma_release_from_contiguous(dev,
+ freed = dma_release_from_contiguous(dev,
phys_to_page(paddr),
size >> PAGE_SHIFT);
- } else {
+ if (!freed)
swiotlb_free_coherent(dev, size, vaddr, dma_handle);
- }
}
static void *__dma_alloc_noncoherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
struct dma_attrs *attrs)
{
- struct page *page, **map;
+ struct page *page;
void *ptr, *coherent_ptr;
- int order, i;
size = PAGE_ALIGN(size);
- order = get_order(size);
+
+ if (!(flags & __GFP_WAIT)) {
+ struct page *page = NULL;
+ void *addr = __alloc_from_pool(size, );
+
+ if (addr)
+ *dma_handle = phys_to_dma(dev, page_to_phys(page));
+
+ return addr;
+
+ }
ptr = __dma_alloc_coherent(dev, size, dma_handle, flags, attrs);
if (!ptr)
goto no_mem;
- map = kmalloc(sizeof(struct page *) << order, flags & ~GFP_DMA);
- if (!map)
- goto no_map;
/* remove any dirty cache lines on the kernel alias */
__dma_flush_range(ptr, ptr + size);
/* create a coherent mapping */
page = virt_to_page(ptr);
- for (i = 0; i < (size >> PAGE_SHIFT);
[PATCHv7 2/5] lib/genalloc.c: Add genpool range check function
After allocating an address from a particular genpool,
there is no good way to verify if that address actually
belongs to a genpool. Introduce addr_in_gen_pool which
will return if an address plus size falls completely
within the genpool range.
Acked-by: Will Deacon
Reviewed-by: Olof Johansson
Reviewed-by: Catalin Marinas
Signed-off-by: Laura Abbott
---
include/linux/genalloc.h | 3 +++
lib/genalloc.c | 29 +
2 files changed, 32 insertions(+)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 3cd0934..1ccaab4 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -121,6 +121,9 @@ extern struct gen_pool *devm_gen_pool_create(struct device
*dev,
int min_alloc_order, int nid);
extern struct gen_pool *dev_get_gen_pool(struct device *dev);
+bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start,
+ size_t size);
+
#ifdef CONFIG_OF
extern struct gen_pool *of_get_named_gen_pool(struct device_node *np,
const char *propname, int index);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index c2b3ad7..c7a91cf 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -403,6 +403,35 @@ void gen_pool_for_each_chunk(struct gen_pool *pool,
EXPORT_SYMBOL(gen_pool_for_each_chunk);
/**
+ * addr_in_gen_pool - checks if an address falls within the range of a pool
+ * @pool: the generic memory pool
+ * @start: start address
+ * @size: size of the region
+ *
+ * Check if the range of addresses falls within the specified pool. Returns
+ * true if the entire range is contained in the pool and false otherwise.
+ */
+bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start,
+ size_t size)
+{
+ bool found = false;
+ unsigned long end = start + size;
+ struct gen_pool_chunk *chunk;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(chunk, &(pool)->chunks, next_chunk) {
+ if (start >= chunk->start_addr && start <= chunk->end_addr) {
+ if (end <= chunk->end_addr) {
+ found = true;
+ break;
+ }
+ }
+ }
+ rcu_read_unlock();
+ return found;
+}
+
+/**
* gen_pool_avail - get available free space of the pool
* @pool: pool to get available free space
*
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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/
[PATCHv7 0/5] DMA Atomic pool for arm64
Hi, This is v7 of the series to add an atomic pool for arm64 and refactor some of the dma atomic code. You know the drill. Thanks, Laura v7: Added correct power aligned algorithm patch. Addressed comments from Andrew. Laura Abbott (5): lib/genalloc.c: Add power aligned algorithm lib/genalloc.c: Add genpool range check function common: dma-mapping: Introduce common remapping functions arm: use genalloc for the atomic pool arm64: Add atomic pool for non-coherent and CMA allocations. arch/arm/Kconfig | 1 + arch/arm/mm/dma-mapping.c| 210 +-- arch/arm64/Kconfig | 1 + arch/arm64/mm/dma-mapping.c | 164 +--- drivers/base/dma-mapping.c | 68 ++ include/asm-generic/dma-mapping-common.h | 9 ++ include/linux/genalloc.h | 7 ++ lib/genalloc.c | 49 8 files changed, 338 insertions(+), 171 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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/
[PATCHv7 3/5] common: dma-mapping: Introduce common remapping functions
For architectures without coherent DMA, memory for DMA may
need to be remapped with coherent attributes. Factor out
the the remapping code from arm and put it in a
common location to reduce code duplication.
As part of this, the arm APIs are now migrated away from
ioremap_page_range to the common APIs which use map_vm_area for remapping.
This should be an equivalent change and using map_vm_area is more
correct as ioremap_page_range is intended to bring in io addresses
into the cpu space and not regular kernel managed memory.
Reviewed-by: Catalin Marinas
Signed-off-by: Laura Abbott
---
arch/arm/mm/dma-mapping.c| 57 +-
drivers/base/dma-mapping.c | 68
include/asm-generic/dma-mapping-common.h | 9 +
3 files changed, 86 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4c88935..f5190ac 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -297,37 +297,19 @@ static void *
__dma_alloc_remap(struct page *page, size_t size, gfp_t gfp, pgprot_t prot,
const void *caller)
{
- struct vm_struct *area;
- unsigned long addr;
-
/*
* DMA allocation can be mapped to user space, so lets
* set VM_USERMAP flags too.
*/
- area = get_vm_area_caller(size, VM_ARM_DMA_CONSISTENT | VM_USERMAP,
- caller);
- if (!area)
- return NULL;
- addr = (unsigned long)area->addr;
- area->phys_addr = __pfn_to_phys(page_to_pfn(page));
-
- if (ioremap_page_range(addr, addr + size, area->phys_addr, prot)) {
- vunmap((void *)addr);
- return NULL;
- }
- return (void *)addr;
+ return dma_common_contiguous_remap(page, size,
+ VM_ARM_DMA_CONSISTENT | VM_USERMAP,
+ prot, caller);
}
static void __dma_free_remap(void *cpu_addr, size_t size)
{
- unsigned int flags = VM_ARM_DMA_CONSISTENT | VM_USERMAP;
- struct vm_struct *area = find_vm_area(cpu_addr);
- if (!area || (area->flags & flags) != flags) {
- WARN(1, "trying to free invalid coherent area: %p\n", cpu_addr);
- return;
- }
- unmap_kernel_range((unsigned long)cpu_addr, size);
- vunmap(cpu_addr);
+ dma_common_free_remap(cpu_addr, size,
+ VM_ARM_DMA_CONSISTENT | VM_USERMAP);
}
#define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K
@@ -1261,29 +1243,8 @@ static void *
__iommu_alloc_remap(struct page **pages, size_t size, gfp_t gfp, pgprot_t prot,
const void *caller)
{
- unsigned int i, nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
- struct vm_struct *area;
- unsigned long p;
-
- area = get_vm_area_caller(size, VM_ARM_DMA_CONSISTENT | VM_USERMAP,
- caller);
- if (!area)
- return NULL;
-
- area->pages = pages;
- area->nr_pages = nr_pages;
- p = (unsigned long)area->addr;
-
- for (i = 0; i < nr_pages; i++) {
- phys_addr_t phys = __pfn_to_phys(page_to_pfn(pages[i]));
- if (ioremap_page_range(p, p + PAGE_SIZE, phys, prot))
- goto err;
- p += PAGE_SIZE;
- }
- return area->addr;
-err:
- unmap_kernel_range((unsigned long)area->addr, size);
- vunmap(area->addr);
+ return dma_common_pages_remap(pages, size,
+ VM_ARM_DMA_CONSISTENT | VM_USERMAP, prot, caller);
return NULL;
}
@@ -1491,8 +1452,8 @@ void arm_iommu_free_attrs(struct device *dev, size_t
size, void *cpu_addr,
}
if (!dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs)) {
- unmap_kernel_range((unsigned long)cpu_addr, size);
- vunmap(cpu_addr);
+ dma_common_free_remap(cpu_addr, size,
+ VM_ARM_DMA_CONSISTENT | VM_USERMAP);
}
__iommu_remove_mapping(dev, handle, size);
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 6cd08e1..1bc46df 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
#include
/*
@@ -267,3 +269,69 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
return ret;
}
EXPORT_SYMBOL(dma_common_mmap);
+
+/*
+ * remaps an allocated contiguous region into another vm_area.
+ * Cannot be used in non-sleeping contexts
+ */
+
+void *dma_common_contiguous_remap(struct page *page, size_t size,
+ unsigned long vm_flags,
+ pgprot_t prot, const void *caller)
+{
+ int i;
+ struct page **pages;
+ void *ptr;
+ unsigned long pfn;
+
+ pages = kmalloc(sizeof(struct page *) << get_order(size), GFP_KERNEL);
+ if (!pages)
+
Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())
On Mon, 11 Aug 2014, Rob Clark wrote: > > I'm suggesting that if you don't want to incur the cost of the conditional > > everytime you call a certain function with assert_spin_locked() that you > > could covert these to lockdep_assert_held() so the check is only done when > > lockdep is enabled for debugging. > > not sure about the nouveau parts, but for the omap and msm hunks, this > code getting called at potentially vblank rate (so maybe once or twice > per ~16ms).. and lockdep has considerable overhead (for a gpu driver) > so I don't always have it enabled. So it sounds like for those two at > least assert_spin_locked() is a better option. > Unless there's a bug, assert_spin_locked() is just going to incur an unnecessary cost every time it is called at runtime. My suggestion was to limit that check only to debugging kernels that include enabling lockdep when tracking down problems rather than needlessly evaluating the conditional every time when there are no bugs. -- 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/
From Dr.Paul Sawadogo
Greetings from my side and how are you doing? I hope you are doing very good today. I am Dr Paul Sawadogo the chief Medical consultant at Suka Clinic Ouagadougou and I have a Patient who hails from Singapore but unfortunately is in coma right now due to complications from a Cancer disease and she has the sum of $5.3 Million United States(Five Million Three Hundred Thousand) Dollars she wants me to transfer to you Please, I will like you to contact me for further details as this is a very sensitive issue that needs urgent attention from you and this is of utmost secrecy as such you must keep it a top secret.reply me on [mrs.tanrub...@gmail.com] Your friend, Dr. Paul on behalf of Mrs.Tan Ruby -- 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] x86/efi fixes for v3.17-rc1
Hi Linus, Two EFI-related Kconfig changes, which happen to touch immediately adjacent lines in Kconfig and thus collapse to a single patch. The following changes since commit 99a5603e2a1f146ac0c6414d8a3669aa749ccff8: efi/arm64: Handle missing virtual mapping for UEFI System Table (2014-07-18 21:24:04 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-efi-for-linus for you to fetch changes up to 9e13bcf7e0981f1db0c8c8255ac17d5f898903e9: Merge tag 'efi-urgent' into x86/efi (2014-08-11 13:58:54 -0700) H. Peter Anvin (1): Merge tag 'efi-urgent' into x86/efi Matt Fleming (2): x86/efi: Fix 3DNow optimization build failure in EFI stub x86/efi: Enforce CONFIG_RELOCATABLE for EFI boot stub arch/x86/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 3fc7d72..0e62af9 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1536,7 +1536,8 @@ config EFI config EFI_STUB bool "EFI stub support" - depends on EFI + depends on EFI && !X86_USE_3DNOW + select RELOCATABLE ---help--- This kernel feature allows a bzImage to be loaded directly by EFI firmware without the use of a bootloader. -- 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] allow setting wiphy.perm_addr after driver probe
On Mon, 2014-08-11 at 15:41 -0700, Marcel Holtmann wrote: > what kind of hardware are you actually using here? > It's ath9k on MIPS under OpenWrt. > > Internally it might do that, but I do not see it exposing the > NL80211_ATTR_MAC when you get the attributes for wiphy. When wlan0 is created, it can be created with its own MAC irrespective of the wiphy MAC. In OpenWrt, the wlan0 MAC can be supplied and assigned to a netdev created on a specific wiphy identified by its MAC, and if that cannot be predicted, there is no wlan0. > So I am still saying that when you do NL80211_CMD_NEW_INTERFACE allow > providing NL80211_ATTR_MAC to set the MAC address to be used. It might > be useful that the wiphy exposes an attribute saying that it does not > have a default MAC address, but that should be it. I do not like these > magic 00:00:00:00:00:00 games. As I mentioned earlier, in Bluetooth we > just deal with allowing the driver to set a flag that it does not have > a valid address. And then the core takes care of dealing with it. > An attribute saying there is no default MAC is helpful only if there is a way to supply a new default to the wiphy. -- 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: Do not use BUG_ON(!spin_is_locked())
On Mon, Aug 11, 2014 at 4:53 PM, David Rientjes wrote: > On Mon, 11 Aug 2014, sanjeev sharma wrote: > >> Hello David, >> >> Here is the old discussion carried out on this. >> >> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802 >> > > I'm suggesting that if you don't want to incur the cost of the conditional > everytime you call a certain function with assert_spin_locked() that you > could covert these to lockdep_assert_held() so the check is only done when > lockdep is enabled for debugging. not sure about the nouveau parts, but for the omap and msm hunks, this code getting called at potentially vblank rate (so maybe once or twice per ~16ms).. and lockdep has considerable overhead (for a gpu driver) so I don't always have it enabled. So it sounds like for those two at least assert_spin_locked() is a better option. BR, -R > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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] x86/xsave changes for v3.17-rc1
Hi Linus, This is a patchset to support the XSAVES instruction required to support context switch of supervisor-only features in upcoming silicon. This patchset missed the 3.16 merge window, which is why it is based on 3.15-rc7. -hpa The following changes since commit c7208164e66f63e3ec1759b98087849286410741: Linux 3.15-rc7 (2014-05-25 16:06:00 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-xsave-for-linus for you to fetch changes up to d0f2dd186133a0241a2ccefb188a0e49e8187859: x86, xsave: Add forgotten inline annotation (2014-06-18 15:19:59 -0700) Borislav Petkov (1): x86, xsave: Add forgotten inline annotation Fenghua Yu (17): x86/cpufeature.h: Reformat x86 feature macros x86/xsaves: Detect xsaves/xrstors feature x86/xsaves: Add a kernel parameter noxsaves to disable xsaves/xrstors x86/alternative: Add alternative_input_2 to support alternative with two features and input x86/xsaves: Change compacted format xsave area header x86/xsaves: Define macros for xsave instructions x86/xsaves: Define a macro for handling xsave/xrstor instruction fault x86/xsaves: Use xsaves/xrstors to save and restore xsave area x86/xsaves: Use xsaves/xrstors for context switch x86/xsaves: Use xsave/xrstor for saving and restoring user space context x86/xsaves: Clear reserved bits in xsave header x86/xsaves: Add xsaves and xrstors support for booting time x86/xsaves: Save xstate to task's xsave area in __save_fpu during booting time x86/xsaves: Call booting time xsaves and xrstors in setup_init_fpu_buf x86/xsaves: Enable xsaves/xrstors Define kernel API to get address of each state in xsave area x86/xsaves: Clean up code in xstate offsets computation in xsave area H. Peter Anvin (1): x86/xsave: Make it clear that the XSAVE macros use (%edi)/(%rdi) Documentation/kernel-parameters.txt | 15 ++ arch/x86/include/asm/alternative.h| 14 ++ arch/x86/include/asm/cpufeature.h | 370 +- arch/x86/include/asm/fpu-internal.h | 9 +- arch/x86/include/asm/processor.h | 4 +- arch/x86/include/asm/xsave.h | 223 +++- arch/x86/include/uapi/asm/msr-index.h | 2 + arch/x86/kernel/cpu/common.c | 17 ++ arch/x86/kernel/cpu/scattered.c | 1 - arch/x86/kernel/i387.c| 2 +- arch/x86/kernel/process.c | 1 + arch/x86/kernel/xsave.c | 118 ++- 12 files changed, 523 insertions(+), 253 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 30a8ad0d..0ebd952 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2124,6 +2124,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted. and restore using xsave. The kernel will fallback to enabling legacy floating-point and sse state. + noxsaveopt [X86] Disables xsaveopt used in saving x86 extended + register states. The kernel will fall back to use + xsave to save the states. By using this parameter, + performance of saving the states is degraded because + xsave doesn't support modified optimization while + xsaveopt supports it on xsaveopt enabled systems. + + noxsaves[X86] Disables xsaves and xrstors used in saving and + restoring x86 extended register state in compacted + form of xsave area. The kernel will fall back to use + xsaveopt and xrstor to save and restore the states + in standard form of xsave area. By using this + parameter, xsave area per process might occupy more + memory on xsaves enabled systems. + eagerfpu= [X86] on enable eager fpu restore off disable eager fpu restore diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h index 0a3f9c9..473bdbe 100644 --- a/arch/x86/include/asm/alternative.h +++ b/arch/x86/include/asm/alternative.h @@ -161,6 +161,20 @@ static inline int alternatives_text_reserved(void *start, void *end) asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) \ : : "i" (0), ## input) +/* + * This is similar to alternative_input. But it has two features and + * respective instructions. + * + * If CPU has feature2, newinstr2 is used. + * Otherwise, if CPU has feature1, newinstr1 is used. + * Otherwise, oldinstr is used. + */ +#define alternative_input_2(oldinstr, newinstr1, feature1, newinstr2, \ +
Re: [PATCH 0/2] nohz: Avoid double clock write
Ping? On Thu, Jul 31, 2014 at 06:45:54PM +0200, Frederic Weisbecker wrote: > Hi Thomas, > > The tick reschedules itself unconditionally. That's what we want as long > as the CPU is in periodic mode. It's not that relevant when the CPU > is in dynticks mode though as the clock write is likely to be overwritten > by the nohz code on irq exit. > > In low-res mode, that even result in unexpected periodic behaviour when > no timer is scheduled in the future. > > So here is a set that proposes the removal of these double writes. > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > origin/nohz/drop-double-write-v2 > > Thanks, > Frederic > --- > > Viresh Kumar (2): > nohz: Fix spurious periodic tick behaviour in low-res dynticks mode > nohz: Avoid tick's double reprogramming in highres mode > > > kernel/time/tick-sched.c | 8 > 1 file changed, 8 insertions(+) -- 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/
