[PATCH] cris: arch-v32: gpio: Use kzalloc instead of kmalloc/memset
Turn a kmalloc/memset into an equivalent kzalloc. Doing so also move the zero'ing of the memory outside of a mutex. Signed-off-by: Christophe Jaillet --- A simililar patch has already been applied against arch/cris/arch-v32/drivers/mach-fs/gpio.c --- arch/cris/arch-v32/drivers/mach-a3/gpio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/cris/arch-v32/drivers/mach-a3/gpio.c b/arch/cris/arch-v32/drivers/mach-a3/gpio.c index 74f9fe8..75f0264 100644 --- a/arch/cris/arch-v32/drivers/mach-a3/gpio.c +++ b/arch/cris/arch-v32/drivers/mach-a3/gpio.c @@ -386,13 +386,12 @@ static int gpio_open(struct inode *inode, struct file *filp) (p > GPIO_MINOR_LAST && p < GPIO_MINOR_PWM0)) return -EINVAL; - priv = kmalloc(sizeof(struct gpio_private), GFP_KERNEL); + priv = kzalloc(sizeof(struct gpio_private), GFP_KERNEL); if (!priv) return -ENOMEM; mutex_lock(_mutex); - memset(priv, 0, sizeof(*priv)); priv->minor = p; filp->private_data = priv; -- 2.1.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/
linux-next: stats (Was: Linux 4.2-rc1)
Hi all, [These will be easier in the future as I have now scripted this message] As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20150623 was the first linux-next after the merge window opened.) Commits in v4.2-rc1 (relative to v4.1):12092 Commits in next-20150623: 11851 Commits with the same SHA1:10679 Commits with the same patch_id: 615 (1) Commits with the same subject line: 54 (1) (1) not counting those in the lines above. So commits in -rc1 that were in next-20150623: 11294 93% Some breakdown of the list of extra commits (relative to next-20150623) in -rc1: Top ten first word of commit summary: 54 perf 52 drm 46 net 35 kvm 25 btrfs 25 acpica 24 arcv2 22 ntb 22 ceph 13 nfs Top ten authors: 32 jo...@kernel.org 29 vgu...@synopsys.com 26 anand.j...@oracle.com 24 t...@linutronix.de 23 z...@redhat.com 15 human.hw...@samsung.com 15 guangrong.x...@linux.intel.com 14 idryo...@gmail.com 14 christian.koe...@amd.com 13 lv.zh...@intel.com Top ten commiters: 122 da...@davemloft.net 53 a...@redhat.com 40 idryo...@gmail.com 36 pbonz...@redhat.com 34 rafael.j.wyso...@intel.com 32 vgu...@synopsys.com 30 t...@linutronix.de 30 alexander.deuc...@amd.com 29 trond.mykleb...@primarydata.com 26 dste...@suse.cz There are also 503 commits in next-20150623 that didn't make it into v4.2-rc1. Top ten first word of commit summary: 51 kdbus 31 userfaultfd 31 arm 23 rcu 21 mm 19 ocfs2 17 documentation 17 coresight 16 cris 14 page-flags Top ten authors: 37 a...@linux-foundation.org 30 aarca...@redhat.com 29 ser...@s15v.net 21 dh.herrm...@gmail.com 20 ra...@rab.in 20 dan...@zonque.org 19 paul...@linux.vnet.ibm.com 16 kirill.shute...@linux.intel.com 14 ttynkky...@nvidia.com 13 tred...@nvidia.com Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Top ten commiters: 153 m...@ellerman.id.au 59 gre...@linuxfoundation.org 32 paul...@linux.vnet.ibm.com 32 mathieu.poir...@linaro.org 30 tred...@nvidia.com 26 jesp...@axis.com 19 dh.herrm...@gmail.com 18 mma...@suse.cz 17 s...@canb.auug.org.au 16 a...@arndb.de Those commits by m...@ellerman.id.au and me are from the quilt series (mainly Andrew's mmotm tree). -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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] cxl: Fix off by one error allowing subsequent mmap page to be accessed
From: Ian Munsie
It was discovered that if a process mmaped their problem state area they
were able to access one page more than expected, potentially allowing
them to access the problem state area of an unrelated process.
This was due to a simple off by one error in the mmap fault handler
introduced in 0712dc7e73e59d79bcead5d5520acf4e9e917e87 ("cxl: Fix issues
when unmapping contexts"), which is fixed in this patch.
Cc: sta...@vger.kernel.org
Fixes: 0712dc7e73e5 ("cxl: Fix issues when unmapping contexts")
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c
index 2a4c80a..6c1ce51 100644
--- a/drivers/misc/cxl/context.c
+++ b/drivers/misc/cxl/context.c
@@ -113,11 +113,11 @@ static int cxl_mmap_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
if (ctx->afu->current_mode == CXL_MODE_DEDICATED) {
area = ctx->afu->psn_phys;
- if (offset > ctx->afu->adapter->ps_size)
+ if (offset >= ctx->afu->adapter->ps_size)
return VM_FAULT_SIGBUS;
} else {
area = ctx->psn_phys;
- if (offset > ctx->psn_size)
+ if (offset >= ctx->psn_size)
return VM_FAULT_SIGBUS;
}
--
2.1.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/
[PATCH 2/2] cxl: Fail mmap if requested mapping is larger than assigned problem state area
From: Ian Munsie
This patch makes the mmap call fail outright if the requested region is
larger than the problem state area assigned to the context so the error
is reported immediately rather than waiting for an attempt to access an
address out of bounds.
Although we never expect users to map more than the assigned problem
state area and are not aware of anyone doing this (other than for
testing), this does have the potential to break users if someone has
used a larger range regardless. I'm submitting it for consideration, but
if this change is not considered acceptable the previous patch is
sufficient to prevent access out of bounds without breaking anyone.
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/context.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c
index 6c1ce51..1287148 100644
--- a/drivers/misc/cxl/context.c
+++ b/drivers/misc/cxl/context.c
@@ -145,8 +145,16 @@ static const struct vm_operations_struct cxl_mmap_vmops = {
*/
int cxl_context_iomap(struct cxl_context *ctx, struct vm_area_struct *vma)
{
+ u64 start = vma->vm_pgoff << PAGE_SHIFT;
u64 len = vma->vm_end - vma->vm_start;
- len = min(len, ctx->psn_size);
+
+ if (ctx->afu->current_mode == CXL_MODE_DEDICATED) {
+ if (start + len > ctx->afu->adapter->ps_size)
+ return -EINVAL;
+ } else {
+ if (start + len > ctx->psn_size)
+ return -EINVAL;
+ }
if (ctx->afu->current_mode != CXL_MODE_DEDICATED) {
/* make sure there is a valid per process space for this AFU */
--
2.1.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/
[PATCH] [SCSI] FlashPoint: optimize string comparison
Stop comparing the strings as soon as we know that they don't match.
Signed-off-by: Christophe JAILLET
---
drivers/scsi/FlashPoint.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/FlashPoint.c b/drivers/scsi/FlashPoint.c
index 5c74e4c..24a4d1a 100644
--- a/drivers/scsi/FlashPoint.c
+++ b/drivers/scsi/FlashPoint.c
@@ -6280,8 +6280,10 @@ static unsigned char FPT_scmachid(unsigned char p_card,
match = 1;
for (k = 0; k < ID_STRING_LENGTH; k++) {
- if (p_id_string[k] != FPT_scamInfo[i].id_string[k])
+ if (p_id_string[k] != FPT_scamInfo[i].id_string[k]) {
match = 0;
+ break;
+ }
}
if (match) {
--
2.1.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/
[PATCH] rtc: rtc-ds1685: Use module_platform_driver
Use module_platform_driver for drivers whose init and exit functions
only register and unregister, respectively.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@a@
identifier f, x;
@@
-static f(...) { return platform_driver_register(); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { platform_driver_unregister(); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_platform_driver;
@@
-module_exit(e);
+module_platform_driver(x);
Signed-off-by: Vaishali Thakkar
---
drivers/rtc/rtc-ds1685.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/rtc/rtc-ds1685.c b/drivers/rtc/rtc-ds1685.c
index 818a363..05a51ef 100644
--- a/drivers/rtc/rtc-ds1685.c
+++ b/drivers/rtc/rtc-ds1685.c
@@ -2145,27 +2145,7 @@ static struct platform_driver ds1685_rtc_driver = {
.probe = ds1685_rtc_probe,
.remove = ds1685_rtc_remove,
};
-
-/**
- * ds1685_rtc_init - rtc module init.
- */
-static int __init
-ds1685_rtc_init(void)
-{
- return platform_driver_register(_rtc_driver);
-}
-
-/**
- * ds1685_rtc_exit - rtc module exit.
- */
-static void __exit
-ds1685_rtc_exit(void)
-{
- platform_driver_unregister(_rtc_driver);
-}
-
-module_init(ds1685_rtc_init);
-module_exit(ds1685_rtc_exit);
+module_platform_driver(ds1685_rtc_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/
[PATCH] sched: make decaying sched_avg's variables happen on period boundary
From: Byungchul Park
decaying time happens on every period boundary. if it does not reach
the period boundary yet, the partial time needs to be kept so that
the time can be decayed on exactly period boundary at next update.
sa->avg_period is not appropriate for getting partial delta_w because
the value is a decayed average value, with which we cannnot get partial
delta at all which does not reach the period boundary yet.
Signed-off-by: Byungchul Park
---
include/linux/sched.h |6 ++
kernel/sched/fair.c |4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8aa4a25..2fdea70 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1192,6 +1192,12 @@ struct sched_avg {
* running_avg_sum.
*/
u32 runnable_avg_sum, avg_period, running_avg_sum;
+ /*
+* decaying time happens on every period boundary. if it does not reach
+* the period boundary yet, the partial time needs to be kept so that
+* the time can be decayed on exactly period boundary at next update.
+*/
+ u32 last_delta;
};
#ifdef CONFIG_SCHEDSTATS
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 09456fc..54ca11e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -680,6 +680,7 @@ void init_task_runnable_average(struct task_struct *p)
slice = sched_slice(task_cfs_rq(p), >se) >> 10;
p->se.avg.runnable_avg_sum = p->se.avg.running_avg_sum = slice;
p->se.avg.avg_period = slice;
+ p->se.avg.last_delta = 0;
__update_task_entity_contrib(>se);
__update_task_entity_utilization(>se);
}
@@ -2576,7 +2577,7 @@ static __always_inline int
__update_entity_runnable_avg(u64 now, int cpu,
sa->last_runnable_update = now;
/* delta_w is the amount already accumulated against our next period */
- delta_w = sa->avg_period % 1024;
+ delta_w = sa->last_delta % 1024;
if (delta + delta_w >= 1024) {
/* period roll-over */
decayed = 1;
@@ -2624,6 +2625,7 @@ static __always_inline int
__update_entity_runnable_avg(u64 now, int cpu,
sa->running_avg_sum += delta * scale_freq
>> SCHED_CAPACITY_SHIFT;
sa->avg_period += delta;
+ sa->last_delta = delta;
return decayed;
}
--
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] Input: elan_i2c - Change the hover event from MT to ST
We want the hover event like BTN_LEFT, even no contract object,
it still can be reported to upper OS system.
Signed-off by: Duson Lin
---
drivers/input/mouse/elan_i2c_core.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index 62641f2..5b5f403 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -771,7 +771,7 @@ static const struct attribute_group *elan_sysfs_groups[] = {
*/
static void elan_report_contact(struct elan_tp_data *data,
int contact_num, bool contact_valid,
- bool hover_event, u8 *finger_data)
+ u8 *finger_data)
{
struct input_dev *input = data->input;
unsigned int pos_x, pos_y;
@@ -815,9 +815,7 @@ static void elan_report_contact(struct elan_tp_data *data,
input_mt_report_slot_state(input, MT_TOOL_FINGER, true);
input_report_abs(input, ABS_MT_POSITION_X, pos_x);
input_report_abs(input, ABS_MT_POSITION_Y, data->max_y - pos_y);
- input_report_abs(input, ABS_MT_DISTANCE, hover_event);
- input_report_abs(input, ABS_MT_PRESSURE,
-hover_event ? 0 : scaled_pressure);
+ input_report_abs(input, ABS_MT_PRESSURE, scaled_pressure);
input_report_abs(input, ABS_TOOL_WIDTH, mk_x);
input_report_abs(input, ABS_MT_TOUCH_MAJOR, major);
input_report_abs(input, ABS_MT_TOUCH_MINOR, minor);
@@ -839,14 +837,14 @@ static void elan_report_absolute(struct elan_tp_data
*data, u8 *packet)
hover_event = hover_info & 0x40;
for (i = 0; i < ETP_MAX_FINGERS; i++) {
contact_valid = tp_info & (1U << (3 + i));
- elan_report_contact(data, i, contact_valid, hover_event,
- finger_data);
+ elan_report_contact(data, i, contact_valid, finger_data);
if (contact_valid)
finger_data += ETP_FINGER_DATA_LEN;
}
input_report_key(input, BTN_LEFT, tp_info & 0x01);
+ input_report_abs(input, ABS_DISTANCE, hover_event != 0);
input_mt_report_pointer_emulation(input, true);
input_sync(input);
}
@@ -922,6 +920,7 @@ static int elan_setup_input_device(struct elan_tp_data
*data)
input_abs_set_res(input, ABS_Y, data->y_res);
input_set_abs_params(input, ABS_PRESSURE, 0, ETP_MAX_PRESSURE, 0, 0);
input_set_abs_params(input, ABS_TOOL_WIDTH, 0, ETP_FINGER_WIDTH, 0, 0);
+ input_set_abs_params(input, ABS_DISTANCE, 0, 1, 0, 0);
/* And MT parameters */
input_set_abs_params(input, ABS_MT_POSITION_X, 0, data->max_x, 0, 0);
@@ -934,7 +933,6 @@ static int elan_setup_input_device(struct elan_tp_data
*data)
ETP_FINGER_WIDTH * max_width, 0, 0);
input_set_abs_params(input, ABS_MT_TOUCH_MINOR, 0,
ETP_FINGER_WIDTH * min_width, 0, 0);
- input_set_abs_params(input, ABS_MT_DISTANCE, 0, 1, 0, 0);
data->input = input;
--
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: lock-up with module: Optimize __module_address() using a latched RB-tree
I had a single, non-reproducible case of the same lock-up happening on my other machine running the Linus git head kernel in 64-bit mode. The kernel was built very similarly to the 32-bit mode kernel, using: CONCURRENCY_LEVEL=4 MAKEFLAGS="CC=gcc-5 LD=ld.gold KCFLAGS=-march=athlon64" \ make-kpkg --config menuconfig --initrd linux-image That machine has the following cpu: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 5 model name : AMD Athlon(tm) II X4 640 Processor stepping: 3 microcode : 0x1c8 cpu MHz : 3000.000 cache size : 512 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save vmmcall bugs: tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs bogomips: 6015.47 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate The start of dmesg shows: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.2.0-rc1+ (root@am64) (gcc version 5.1.1 20150622 (Debian 5.1.1-12) ) #1815 SMP PREEMPT Tue Jul 7 13:13:00 ACST 2015 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.2.0-rc1+ root=UUID=39706f53-7c27-4310-b22a-36c7b042d1a1 ro radeon.audio=1 [0.00] tseg: 00 [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'lazy' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcffa] usable [0.00] BIOS-e820: [mem 0xcffb-0xcffbdfff] ACPI data [0.00] BIOS-e820: [mem 0xcffbe000-0xcffd] ACPI NVS [0.00] BIOS-e820: [mem 0xcffe-0xcfff] reserved [0.00] BIOS-e820: [mem 0xff70-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00022fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.5 present. [0.00] DMI: System manufacturer System Product Name/M3A78 PRO, BIOS 170101/27/2011 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x23 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 8000 mask C000 write-back [0.00] 2 base C000 mask F000 write-back [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00023000 aka 8960M [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] e820: update [mem 0xd000-0x] usable ==> reserved [0.00] e820: last_pfn = 0xcffb0 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [880ff780] [0.00] Base memory trampoline at [88098000] 98000 size 28672 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x0292e000, 0x0292efff] PGTABLE [0.00] BRK [0x0292f000, 0x0292] PGTABLE [0.00] BRK [0x0293, 0x02930fff] PGTABLE [0.00] init_memory_mapping: [mem 0x22fe0-0x22fff] [0.00] [mem 0x22fe0-0x22fff] page 2M [0.00] BRK [0x02931000, 0x02931fff] PGTABLE [0.00] init_memory_mapping: [mem 0x22000-0x22fdf] [0.00] [mem 0x22000-0x22fdf] page 2M [0.00] init_memory_mapping: [mem 0x2-0x21fff] [0.00] [mem
[PATCH] coresight: replicator: Use module_platform_driver
Use module_platform_driver for drivers whose init and exit functions
only register and unregister, respectively.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@a@
identifier f, x;
@@
-static f(...) { return platform_driver_register(); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { platform_driver_unregister(); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_platform_driver;
@@
-module_exit(e);
+module_platform_driver(x);
Signed-off-by: Vaishali Thakkar
---
drivers/hwtracing/coresight/coresight-replicator.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c
b/drivers/hwtracing/coresight/coresight-replicator.c
index 7974b7c..df45932 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -183,18 +183,7 @@ static struct platform_driver replicator_driver = {
.pm = _dev_pm_ops,
},
};
-
-static int __init replicator_init(void)
-{
- return platform_driver_register(_driver);
-}
-module_init(replicator_init);
-
-static void __exit replicator_exit(void)
-{
- platform_driver_unregister(_driver);
-}
-module_exit(replicator_exit);
+module_platform_driver(replicator_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("CoreSight Replicator 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: Query: Clock driver requests mailbox channel
On Mon, Jul 6, 2015 at 5:03 PM, Leo Yan wrote: > Hi all, > > i'm working with one clock driver, which will invoke mailbox API to > request the mailbox channel and send message. > > Usually clock driver will init with devicetree, below is the example: > CLK_OF_DECLARE(hi6220_clk_power, "hisilicon,hi6220-clock-power", > hi6220_clk_power_init); > > Clock init function it will pass the pointer of struct device_node > but not the pointer of struct device. So finally it's difficult to > invoke mailbox API *mbox_request_channel()*, due it need use the > struct device to search DT's property "mboxes". > > I want to find which is the best way to resolve this issue, so do you > suggest clock driver to manually register one device? Or can we add > one more API to request the mailbox channel directly with device_node? > IIUC, such clocks (that require platform resources) should be populated from the platform_device's probe()? -- 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] Tools: hv: kvp: fix a build warning -Wformat-security
It is to fix:
hv_kvp_daemon.c:705:2: warning: format not a string literal and no format
arguments [-Wformat-security]
Signed-off-by: Dexuan Cui
---
tools/hv/hv_kvp_daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 0d9f48e..f9d5089 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -702,7 +702,7 @@ static char *kvp_mac_to_if_name(char *mac)
if (dir == NULL)
return NULL;
- snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
+ snprintf(dev_id, sizeof(dev_id), "%s", kvp_net_dir);
q = dev_id + strlen(kvp_net_dir);
while ((entry = readdir(dir)) != NULL) {
--
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: [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support
Hello Stefan,
On 15-07-06 12:16:34, Stefan Wahren wrote:
> Hi Sanchayan,
>
> > Sanchayan Maity hat am 29. Juni 2015 um 13:22
> > geschrieben:
> >
> >
> > The patch adds support for the On Chip One Time Programmable Peripheral
> > (OCOTP) on the Vybrid platform.
>
> please provide a changelog in your cover letter and a new version after
> changes.
>
> I think it's important to note that the driver only support read-only access.
Ok. Will mention this explicitly in the next version.
>
> >
> > Signed-off-by: Sanchayan Maity
> > ---
> > drivers/nvmem/Kconfig | 10 ++
> > drivers/nvmem/Makefile | 2 +
> > drivers/nvmem/vf610-ocotp.c | 250
> >
> > 3 files changed, 262 insertions(+)
> > create mode 100644 drivers/nvmem/vf610-ocotp.c
> >
> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> > index 17f1a57..84c830d 100644
> > --- a/drivers/nvmem/Kconfig
> > +++ b/drivers/nvmem/Kconfig
> > @@ -33,4 +33,14 @@ config NVMEM_SUNXI_SID
> > This driver can also be built as a module. If so, the module
> > will be called eeprom-sunxi-sid.
> >
> > +config NVMEM_VF610_OCOTP
> > + tristate "VF610 SoCs OCOTP support"
> > + depends on SOC_VF610
> > + help
> > + This is a driver for the 'OCOTP' available on various Vybrid
> > + devices.
>
> I don't know much about Vybrid. But this driver is specific for VF610, isn't
> it?
Sorry. I only checked on VF50 and VF61. Will check if is it available with the
other Vybrid devices and change if it is not so.
>
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called nvmem-vf610-ocotp.
> > +
> > endif
> > diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> > index cc46791..a9ed113 100644
> > --- a/drivers/nvmem/Makefile
> > +++ b/drivers/nvmem/Makefile
> > @@ -11,3 +11,5 @@ obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
> > nvmem_qfprom-y := qfprom.o
> > obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem-sunxi-sid.o
> > nvmem-sunxi-sid-y := sunxi-sid.o
> > +obj-$(CONFIG_NVMEM_VF610_OCOTP) += nvmem-vf610-ocotp.o
> > +nvmem-vf610-ocotp-y := vf610-ocotp.o
> > diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
> > new file mode 100644
> > index 000..b7a782c
> > --- /dev/null
> > +++ b/drivers/nvmem/vf610-ocotp.c
> > @@ -0,0 +1,250 @@
> > +/*
> > + * Copyright (C) 2015 Sanchayan Maity
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * 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.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* OCOTP Register Offsets */
> > +#define OCOTP_CTRL_REG 0x00
> > +#define OCOTP_CTRL_SET 0x04
> > +#define OCOTP_CTRL_CLR 0x08
> > +#define OCOTP_TIMING 0x10
> > +#define OCOTP_DATA 0x20
> > +#define OCOTP_READ_CTRL_REG 0x30
> > +#define OCOTP_READ_FUSE_DATA 0x40
> > +
> > +/* OCOTP Register bits and masks */
> > +#define OCOTP_CTRL_WR_UNLOCK 16
> > +#define OCOTP_CTRL_WR_UNLOCK_KEY 0x3E77
> > +#define OCOTP_CTRL_WR_UNLOCK_MASK 0x
> > +#define OCOTP_CTRL_ADDR 0
> > +#define OCOTP_CTRL_ADDR_MASK 0x7F
> > +#define OCOTP_CTRL_RELOAD_SHADOWS (0x1 << 10)
> > +#define OCOTP_CTRL_ERROR (0x1 << 9)
> > +#define OCOTP_CTRL_BUSY (0x1 << 8)
>
> You can use the BIT() macro here.
Ok.
>
> > +
> > +#define OCOTP_TIMING_STROBE_READ 16
> > +#define OCOTP_TIMING_STROBE_READ_MASK 0x003F
> > +#define OCOTP_TIMING_RELAX 12
> > +#define OCOTP_TIMING_RELAX_MASK 0xF000
> > +#define OCOTP_TIMING_STROBE_PROG 0
> > +#define OCOTP_TIMING_STROBE_PROG_MASK 0x0FFF
> > +
> > +#define OCOTP_READ_CTRL_READ_FUSE 0x1
> > +
> > +#define VF610_OCOTP_TIMEOUT 10
> > +
> > +#define BF(value, field) (((value) << field) & field##_MASK)
> > +
> > +#define DEF_RELAX 20
> > +
> > +struct vf610_ocotp_dev {
> > + void __iomem *base;
> > + struct clk *clk;
> > + struct device *dev;
> > + struct resource *res;
> > + struct regmap *regmap;
> > + struct nvmem_device *nvmem;
> > +};
>
> Some member of this struct seems unnecessary to me. Please
> remove the unused one.
>
> > +
> > +static int ocotp_timing;
>
> How about storing the timings in struct above?
Ok.
>
> > +
> > +static u8 valid_fuse_addr[] = {
> > + 0x00, 0x01, 0x02, 0x04, 0x0F, 0x20, 0x21, 0x22, 0x23, 0x24,
> > + 0x25, 0x26, 0x27, 0x28, 0x2F, 0x38, 0x39, 0x3A, 0x3B, 0x3C,
> > + 0x3D, 0x3E, 0x3F
> > +};
>
> const?
Right.
>
> > +
> > +static int vf610_ocotp_wait_busy(void __iomem *base)
> > +{
> > + int timeout = VF610_OCOTP_TIMEOUT;
> > +
> > + while ((readl(base) &
RE: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails
Hi Felipe, > -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Monday, July 06, 2015 10:38 PM > To: Subbaraya Sundeep Bhatta > Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; sta...@vger.kernel.org > Subject: Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command > sent to DEPCMD register fails > > On Wed, Jul 01, 2015 at 07:29:28AM +, Subbaraya Sundeep Bhatta > wrote: > > Hi Felipe, > > > > > -Original Message- > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > Sent: Tuesday, June 30, 2015 3:17 AM > > > To: Subbaraya Sundeep Bhatta > > > Cc: ba...@ti.com; gre...@linuxfoundation.org; > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > sta...@vger.kernel.org; Subbaraya Sundeep Bhatta > > > Subject: Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if > > > command sent to DEPCMD register fails > > > > > > Hi, > > > > > > On Thu, May 21, 2015 at 03:46:48PM +0530, Subbaraya Sundeep > Bhatta > > > wrote: > > > > We need to return error to caller if command is not sent to > > > > controller succesfully. > > > > > > > > Signed-off-by: Subbaraya Sundeep Bhatta > > > > Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) > > > > Cc: > > > > --- > > > > v2 changes: > > > > Added Fixes and Cc in commit message. > > > > > > I noticed that this breaks at least my AM437x silicon with DWC3 > > > 2.40a when used with g_zero and testusb. As of now, it could be that > > > silicon is mis-behaving because I got a Transfer Complete before the > > > failing Set Endpoint Transfer Resource command. > > > > > > In any case, can you run on your setup with g_zero and > > > test.sh/testusb [1]/[2] just to verify that it really works for you ? > > > > Ok I will do that. > > Did you manage to run the test I asked ? If we don't get down to this, I'll > have to revert your patch as it regresses my platforms. Sorry I caught up with some other customer reported issue on Zynq (Chipidea). I will do it by this weekend at any cost. Please wait. Thanks, Sundeep.B.S. > > -- > balbi -- 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] ipc: Modify message queue accounting to not take kernel data structures into account
On Mon, 2015-07-06 at 17:49 +0200, Marcus Gelderie wrote: > A while back, the message queue implementation in the kernel was > improved to use btrees to speed up retrieval of messages (commit > d6629859b36). The patch introducing the improved kernel handling of > message queues (using btrees) has, as a by-product, changed the > meaning of the QSIZE field in the pseudo-file created for the queue. > Before, this field reflected the size of the user-data in the queue. > Since, it also takes kernel data structures into account. For > example, if 13 bytes of user data are in the queue, on my machine the > file reports a size of 61 bytes. > > There was some discussion on this topic before (for example > https://lkml.org/lkml/2014/10/1/115). Commenting on a th lkml, Michael > Kerrisk gave the following background (https://lkml.org/lkml/2015/6/16/74): > > The pseudofiles in the mqueue filesystem (usually mounted at > /dev/mqueue) expose fields with metadata describing a message > queue. One of these fields, QSIZE, as originally implemented, > showed the total number of bytes of user data in all messages in > the message queue, and this feature was documented from the > beginning in the mq_overview(7) page. In 3.5, some other (useful) > work happened to break the user-space API in a couple of places, > including the value exposed via QSIZE, which now includes a measure > of kernel overhead bytes for the queue, a figure that renders QSIZE > useless for its original purpose, since there's no way to deduce > the number of overhead bytes consumed by the implementation. > (The other user-space breakage was subsequently fixed.) Michael, this breakage was never finally documented in the manpage, right? I took a look and there is no mention, but it was a quick look. It's just that if this patch goes in, I'd hate ending up with something like this in the manpage: as of 3.5 as of 4.3 If there are changes to be made to the manpage, it should probably be posted with this patch, methinks. > > This patch removes the accounting of kernel data structures in the > queue. Reporting the size of these data-structures in the QSIZE field > was a breaking change (see Michael's comment above). Without the QSIZE > field reporting the total size of user-data in the queue, there is no > way to deduce this number. > > It should be noted that the resource limit RLIMIT_MSGQUEUE is counted > against the worst-case size of the queue (in both the old and the new > implementation). Therefore, the kernel overhead accounting in QSIZE is > not necessary to help the user understand the limitations RLIMIT imposes > on the processes. Also, I would suggest adding some comment in struct mqueue_inode_info for future reference, ie: - unsigned long qsize; /* size of queue in memory (sum of all msgs) */ + /* +* Size of queue in memory (sum of all msgs). Accounts for +* only userspace overhead; ignoring any in-kernel rbtree nodes. +*/ + unsigned long qsize; But no big deal in any case. I think this is the right approach, but would still like to know if Doug has any concerns about it. Thanks, Davidlohr -- 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: [PATCHv2 5/6] clk: sunxi: make use of of_clk_parent_fill helper function
Hi Dinh, On Mon, Jul 06, 2015 at 10:59:05PM -0500, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock names' array. > > Signed-off-by: Dinh Nguyen > Cc: Maxime Ripard > Cc: "Emilio López" Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v4] clk: change clk_ops' ->determine_rate() prototype
Hi Stephen,
On Mon, 6 Jul 2015 14:32:10 -0700
Stephen Boyd wrote:
> On 07/06, Boris Brezillon wrote:
> > Clock rates are stored in an unsigned long field, but ->determine_rate()
> > (which returns a rounded rate from a requested one) returns a long
> > value (errors are reported using negative error codes), which can lead
> > to long overflow if the clock rate exceed 2Ghz.
> >
> > Change ->determine_rate() prototype to return 0 or an error code, and pass
> > a pointer to a clk_rate_request structure containing the expected target
> > rate and the rate constraints imposed by clk users.
> >
> > The clk_rate_request structure might be extended in the future to contain
> > other kind of constraints like the rounding policy, the maximum clock
> > inaccuracy or other things that are not yet supported by the CCF
> > (power consumption constraints ?).
> >
> > Signed-off-by: Boris Brezillon
>
> Which files did you compile?
>
> drivers/clk/mmp/clk-mix.c: In function ‘mmp_clk_mix_determine_rate’:
> drivers/clk/mmp/clk-mix.c:221:13: error: ‘rate’ undeclared (first use in this
> function)
>
Hm, I only compile tested the multi_v5 and multi_v7 defconfigs, and
obviously it was a bad idea (just thought all the impacted platforms
were already converted to multiplatform support).
[...]
> > -long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long
> > rate,
> > - unsigned long min_rate,
> > - unsigned long max_rate,
> > - unsigned long *best_parent_rate,
> > - struct clk_hw **best_parent_clk)
> > +int omap3_noncore_dpll_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req)
> > {
> > struct clk_hw_omap *clk = to_clk_hw_omap(hw);
> > struct dpll_data *dd;
> >
> > - if (!hw || !rate)
> > + if (!hw || !req || !req->rate)
>
> Why do we need to check for req? It shouldn't be NULL.
We don't, I'll remove this test.
[...]
> > -long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long
> > rate,
> > - unsigned long min_rate,
> > - unsigned long max_rate,
> > - unsigned long *best_parent_rate,
> > - struct clk_hw **best_parent_clk)
> > +int omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req)
> > {
> > struct clk_hw_omap *clk = to_clk_hw_omap(hw);
> > struct dpll_data *dd;
> >
> > - if (!hw || !rate)
> > + if (!hw || !req || !req->rate)
>
> Same comment here. And why would we care about hw being NULL
> either for that matter.
Yes, but I'm not sure this removal should be done in the same patch.
Let me know if you think otherwise.
> > -static long mmc_clk_determine_rate(struct clk_hw *hw, unsigned long rate,
> > - unsigned long min_rate,
> > - unsigned long max_rate,
> > - unsigned long *best_parent_rate,
> > - struct clk_hw **best_parent_p)
> > +static int mmc_clk_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req)
> > {
> > struct clk_mmc *mclk = to_mmc(hw);
> > - unsigned long best = 0;
> >
> > - if ((rate <= 1300) && (mclk->id == HI3620_MMC_CIUCLK1)) {
> > - rate = 1300;
> > - best = 2600;
> > - } else if (rate <= 2600) {
> > - rate = 2500;
> > - best = 18000;
> > - } else if (rate <= 5200) {
> > - rate = 5000;
> > - best = 36000;
> > - } else if (rate <= 1) {
> > - rate = 1;
> > - best = 72000;
> > + req->best_parent_hw = __clk_get_hw(__clk_get_parent(hw->clk));
> > +
>
> Where did this come from? We weren't setting the best_parent_p
> pointer before.
It comes from a previous version where I was not assigning the
->best_parent_hw field to the current parent in the core code.
I fixed it in the meantime, but forgot to remove this assignment.
> > -static long
> > -clk_pll_determine_rate(struct clk_hw *hw, unsigned long rate,
> > - unsigned long min_rate, unsigned long max_rate,
> > - unsigned long *p_rate, struct clk_hw **p)
> > +static int
> > +clk_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
> > {
> > + struct clk *parent = __clk_get_parent(hw->clk);
> > struct clk_pll *pll = to_clk_pll(hw);
> > const struct pll_freq_tbl *f;
> >
> > - f = find_freq(pll->freq_tbl, rate);
> > + req->best_parent_hw = __clk_get_hw(parent);
> > + req->best_parent_rate = __clk_get_rate(parent);
> > +
> > + f = find_freq(pll->freq_tbl, req->rate);
> > if (!f)
> > - return clk_pll_recalc_rate(hw, *p_rate);
> > +
Re: [PATCH] staging: lustre: obdclass: fix macro coding style issue in uuid.c
On Mon, 2015-07-06 at 19:36 -0700, Greg KH wrote: > On Fri, Jun 26, 2015 at 11:04:49PM -0700, Joe Perches wrote: > > On Sat, 2015-06-27 at 06:36 +0100, Vasiliy Korchagin wrote: [] > > > Here is another version with macro expansion. Inline function > > > expansion doesn't > > > seem like a good idea to me as it would make things overcomplicated. > > > > It looks like it'd be simpler to use vsprintf extension %pU [] > > diff --git a/drivers/staging/lustre/lustre/obdclass/uuid.c > > b/drivers/staging/lustre/lustre/obdclass/uuid.c [] > > + sprintf(out->uuid, "%pU", uu); > > } > > EXPORT_SYMBOL(class_uuid_unparse); > > I agree, much better, can you resend this in a form I can apply? Vasiliy, you started this, can you submit this under your name please? -- 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] bio integrity: do not assume bio_integrity_pool exists if bioset exists
On Wed, Jul 01 2015 at 12:57pm -0400,
Mike Snitzer wrote:
> bio_integrity_alloc() and bio_integrity_free() assume that if a bio was
> allocated from a bioset that that bioset also had its bio_integrity_pool
> allocated using bioset_integrity_create(). This is a very bad
> assumption given that bioset_create() and bioset_integrity_create() are
> completely disjoint. Not all callers of bioset_create() have been
> trained to also call bioset_integrity_create() -- and they may not care
> to be.
>
> Fix this by falling back to kmalloc'ing 'struct bio_integrity_payload'
> rather than force all bioset consumers to (wastefully) preallocate a
> bio_integrity_pool that they very likely won't actually need (given the
> niche nature of the current block integrity support).
>
> Otherwise, a NULL pointer "Kernel BUG" with a trace like the following
> will be observed (as seen on s390x using zfcp storage) because dm-io
> doesn't use bioset_integrity_create() when creating its bioset:
>
> [ 791.643338] Call Trace:
> [ 791.643339] ([<0003df98b848>] 0x3df98b848)
> [ 791.643341] [<002c5de8>] bio_integrity_alloc+0x48/0xf8
> [ 791.643348] [<002c6486>] bio_integrity_prep+0xae/0x2f0
> [ 791.643349] [<00371e38>] blk_queue_bio+0x1c8/0x3d8
> [ 791.643355] [<0036f8d0>] generic_make_request+0xc0/0x100
> [ 791.643357] [<0036f9b2>] submit_bio+0xa2/0x198
> [ 791.643406] [<03ff801f9774>] dispatch_io+0x15c/0x3b0 [dm_mod]
> [ 791.643419] [<03ff801f9b3e>] dm_io+0x176/0x2f0 [dm_mod]
> [ 791.643423] [<03ff8074b28a>] do_reads+0x13a/0x1a8 [dm_mirror]
> [ 791.643425] [<03ff8074b43a>] do_mirror+0x142/0x298 [dm_mirror]
> [ 791.643428] [<00154fca>] process_one_work+0x18a/0x3f8
> [ 791.643432] [<0015598a>] worker_thread+0x132/0x3b0
> [ 791.643435] [<0015d49a>] kthread+0xd2/0xd8
> [ 791.643438] [<005bc0ca>] kernel_thread_starter+0x6/0xc
> [ 791.643446] [<005bc0c4>] kernel_thread_starter+0x0/0xc
>
> Signed-off-by: Mike Snitzer
> Cc: sta...@vger.kernel.org
> ---
> block/bio-integrity.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> NOTE: this serves as a more generic fix in the block layer rather than
> the dm-io specific fix which isn't ideal (due to potential for memory
> waste), see:
> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next=17dbe96d4f8a6f87004e6cfb5944872dfe2edb9f
>
> diff --git a/block/bio-integrity.c b/block/bio-integrity.c
> index 0436c21..719b715 100644
> --- a/block/bio-integrity.c
> +++ b/block/bio-integrity.c
> @@ -51,7 +51,7 @@ struct bio_integrity_payload *bio_integrity_alloc(struct
> bio *bio,
> unsigned long idx = BIO_POOL_NONE;
> unsigned inline_vecs;
>
> - if (!bs) {
> + if (!bs || !bs->bio_integrity_pool) {
> bip = kmalloc(sizeof(struct bio_integrity_payload) +
> sizeof(struct bio_vec) * nr_vecs, gfp_mask);
> inline_vecs = nr_vecs;
> @@ -104,7 +104,7 @@ void bio_integrity_free(struct bio *bio)
> kfree(page_address(bip->bip_vec->bv_page) +
> bip->bip_vec->bv_offset);
>
> - if (bs) {
> + if (bs && bs->bio_integrity_pool) {
> if (bip->bip_slab != BIO_POOL_NONE)
> bvec_free(bs->bvec_integrity_pool, bip->bip_vec,
> bip->bip_slab);
> --
> 2.3.2 (Apple Git-55)
>
>
Both the above block patch and the referenced dm-io patch fix the
following issue. I really prefer the block fix over the dm-io one. As
such I'd like to see it go upstream during 4.2-rc.
Jens, what do you think?
Here is an updated NULL pointer trace using 4.2-rc1 (which is easily hit
using the attached reproducer script):
[ 239.425111] BUG: unable to handle kernel NULL pointer dereference at
0048
[ 239.426010] IP: [] mempool_alloc+0x60/0x180
[ 239.426010] PGD 0
[ 239.426010] Oops: [#1] SMP
[ 239.426010] Modules linked in: dm_mirror dm_region_hash dm_log scsi_debug sg
nfsv3 nfs fscache crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel aesni_intel glue_helper lrw gf128mul ablk_helper dm_mod
cryptd pcspkr serio_raw virtio_balloon 8139too i2c_piix4 nfsd auth_rpcgss
nfs_acl lockd grace sunrpc ext4 mbcache jbd2 ata_generic sd_mod pata_acpi
cirrus syscopyarea sysfillrect sysimgblt drm_kms_helper virtio_scsi ttm
virtio_blk drm ata_piix libata virtio_pci virtio_ring 8139cp virtio mii
i2c_core floppy
[ 239.426010] CPU: 2 PID: 134 Comm: kworker/2:2 Not tainted 4.2.0-rc1+ #59
[ 239.426010] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 239.426010] Workqueue: kcopyd do_work [dm_mod]
[ 239.426010] task: 88011a701bc0 ti: 880036a1 task.ti:
880036a1
[ 239.426010] RIP: 0010:[] []
mempool_alloc+0x60/0x180
[ 239.426010] RSP: 0018:880036a13878 EFLAGS:
Re: [PATCHv6 1/2] dts: Adding docs for Xilinx LogiCORE IP mailbox driver.
On Mon, Jul 6, 2015 at 10:57 PM, Sören Brinkmann
wrote:
> On Mon, 2015-07-06 at 10:16AM -0700, Moritz Fischer wrote:
>> Signed-off-by: Moritz Fischer
>> Acked-by: Michal Simek
>> ---
>> .../devicetree/bindings/mailbox/xilinx-mailbox.txt | 44
>> ++
>> 1 file changed, 44 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
>> b/Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
>> new file mode 100644
>> index 000..97b81f8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
>> @@ -0,0 +1,44 @@
>> +Xilinx Mailbox Driver
>> +=
>> +
>> +Required properties:
>> +- compatible : "xlnx,mailbox-2.1".
>> +- reg : physical base address of the mailbox and length of
>> + memory mapped region.
>> +- #mbox-cells : common mailbox binding property to identify the number
>> + of cells required for the mailbox specifier, should
>> be 0
>> +- clocks : phandle to clock provider
>> +- clock-names : must be 'mbox'
>> +
>> +Optional properties:
>> +- interrupt-parent : interrupt source phandle
>> +- interrupts : interrupt number, The interrupt specifier format
>> + depends on the interrupt controller parent.
>> +
>> +Example:
>> + mbox: mailbox@4040 {
>> + compatible = "xlnx,mailbox-2.1";
>> + reg = <0x4040 0x100>;
>> + interrupt-parent = <>;
>> + interrupts = <5>;
>> + #mbox-cells = <0>;
>> + clocks = < 15>;
>> + clock-names = "mbox";
>> + };
>> +
>> +Mailbox client
>> +===
>> +"mboxes" and the optional "mbox-names" (please see
>> +Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each
>> value
>> +of the mboxes property should contain a phandle to the mailbox controller
>> +device node and second argument is the channel index. It must be 0 (hardware
>> +support only one channel). The equivalent "mbox-names" property value can be
>> +used to give a name to the communication channel to be used by the client
>> user.
>> +
>> +Example:
>> + mclient0: mclient0@400 {
>> + compatible = "client-1.0";
>> + reg = <0x400 0x10>;
>> + mbox-names = "mbox";
>> + mboxes = < 0>;
>
> Sorry, to bring this up again, but I'm confused regarding the #mbox-cells
> thing. Above it says #mbox-cells is 0. In that case, shouldn't the
> 'mboxes' property not only be '<>'?
>
Yeah, this is inconsistent. Either provide your own of_xlate() for
#cells=0 or have #cells=1 to use stock of_xlate() and specify <
0> for the channel.
--
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] sched: let __sched_period() use rq cfs's nr_running
From: Byungchul Park
__sched_period() returns a period which a rq can have. the period has to be
stretched by the number of task *the rq has*, when nr_running > nr_latency.
otherwise, task slice can be very smaller than sysctl_sched_min_granularity
depending on the position of tg hierarchy when CONFIG_FAIR_GROUP_SCHED.
Signed-off-by: Byungchul Park
---
kernel/sched/fair.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 09456fc..1adacb8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -635,7 +635,7 @@ static u64 __sched_period(unsigned long nr_running)
*/
static u64 sched_slice(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
- u64 slice = __sched_period(cfs_rq->nr_running + !se->on_rq);
+ u64 slice = __sched_period(rq_of(cfs_rq)->cfs.nr_running + !se->on_rq);
for_each_sched_entity(se) {
struct load_weight *load;
--
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/
[RFCv3 2/5] mm/compaction: enable mobile-page migration
From: Gioh Kim
Add framework to register callback functions and check page mobility.
There are some modes for page isolation so that isolate interface
has arguments of page address and isolation mode while putback
interface has only page address as argument.
Signed-off-by: Gioh Kim
---
fs/proc/page.c | 3 ++
include/linux/compaction.h | 76 ++
include/linux/fs.h | 2 +
include/linux/page-flags.h | 19 +
include/uapi/linux/kernel-page-flags.h | 1 +
5 files changed, 101 insertions(+)
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 7eee2d8..a4f5a00 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -146,6 +146,9 @@ u64 stable_page_flags(struct page *page)
if (PageBalloon(page))
u |= 1 << KPF_BALLOON;
+ if (PageMobile(page))
+ u |= 1 << KPF_MOBILE;
+
u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);
u |= kpf_copy_bit(k, KPF_SLAB, PG_slab);
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index aa8f61c..c375a89 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -1,6 +1,9 @@
#ifndef _LINUX_COMPACTION_H
#define _LINUX_COMPACTION_H
+#include
+#include
+
/* Return values for compact_zone() and try_to_compact_pages() */
/* compaction didn't start as it was deferred due to past failures */
#define COMPACT_DEFERRED 0
@@ -51,6 +54,66 @@ extern void compaction_defer_reset(struct zone *zone, int
order,
bool alloc_success);
extern bool compaction_restarting(struct zone *zone, int order);
+static inline bool mobile_page(struct page *page)
+{
+ return page->mapping && page->mapping->a_ops &&
+ (PageMobile(page) || PageBalloon(page));
+}
+
+static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
+{
+ bool ret;
+
+ /*
+* Avoid burning cycles with pages that are yet under __free_pages(),
+* or just got freed under us.
+*
+* In case we 'win' a race for a mobile page being freed under us and
+* raise its refcount preventing __free_pages() from doing its job
+* the put_page() at the end of this block will take care of
+* release this page, thus avoiding a nasty leakage.
+*/
+ if (likely(get_page_unless_zero(page))) {
+ /*
+* As mobile pages are not isolated from LRU lists, concurrent
+* compaction threads can race against page migration functions
+* as well as race against the releasing a page.
+*
+* In order to avoid having an already isolated mobile page
+* being (wrongly) re-isolated while it is under migration,
+* or to avoid attempting to isolate pages being released,
+* lets be sure we have the page lock
+* before proceeding with the mobile page isolation steps.
+*/
+ if (likely(trylock_page(page))) {
+ if (mobile_page(page) &&
+ page->mapping->a_ops->isolatepage) {
+ ret = page->mapping->a_ops->isolatepage(page,
+ mode);
+ unlock_page(page);
+ return ret;
+ }
+ unlock_page(page);
+ }
+ put_page(page);
+ }
+ return false;
+}
+
+static inline void putback_mobilepage(struct page *page)
+{
+ /*
+* 'lock_page()' stabilizes the page and prevents races against
+* concurrent isolation threads attempting to re-isolate it.
+*/
+ lock_page(page);
+ if (mobile_page(page) && page->mapping->a_ops->putbackpage) {
+ page->mapping->a_ops->putbackpage(page);
+ /* drop the extra ref count taken for mobile page isolation */
+ put_page(page);
+ }
+ unlock_page(page);
+}
#else
static inline unsigned long try_to_compact_pages(gfp_t gfp_mask,
unsigned int order, int alloc_flags,
@@ -83,6 +146,19 @@ static inline bool compaction_deferred(struct zone *zone,
int order)
return true;
}
+static inline bool mobile_page(struct page *page)
+{
+ return false;
+}
+
+static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
+{
+ return false;
+}
+
+static inline void putback_mobilepage(struct page *page)
+{
+}
#endif /* CONFIG_COMPACTION */
#if defined(CONFIG_COMPACTION) && defined(CONFIG_SYSFS) && defined(CONFIG_NUMA)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 35ec87e..33c9aa5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -395,6 +395,8 @@ struct address_space_operations {
[RFCv3 1/5] fs/anon_inodes: new interface to create new inode
From: Gioh Kim
The anon_inodes has already complete interfaces to create manage
many anonymous inodes but don't have interface to get
new inode. Other sub-modules can create anonymous inode
without creating and mounting it's own pseudo filesystem.
Signed-off-by: Gioh Kim
---
fs/anon_inodes.c| 6 ++
include/linux/anon_inodes.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 80ef38c..1d51f96 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -162,6 +162,12 @@ err_put_unused_fd:
}
EXPORT_SYMBOL_GPL(anon_inode_getfd);
+struct inode *anon_inode_new(void)
+{
+ return alloc_anon_inode(anon_inode_mnt->mnt_sb);
+}
+EXPORT_SYMBOL_GPL(anon_inode_new);
+
static int __init anon_inode_init(void)
{
anon_inode_mnt = kern_mount(_inode_fs_type);
diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
index 8013a45..ddbd67f 100644
--- a/include/linux/anon_inodes.h
+++ b/include/linux/anon_inodes.h
@@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
void *priv, int flags);
int anon_inode_getfd(const char *name, const struct file_operations *fops,
void *priv, int flags);
+struct inode *anon_inode_new(void);
#endif /* _LINUX_ANON_INODES_H */
--
2.1.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/
[RFCv3 5/5] mm: remove direct calling of migration
From: Gioh Kim
Migration is completely generalized so that migrating mobile page
is processed with lru-pages in move_to_new_page.
Signed-off-by: Gioh Kim
---
mm/balloon_compaction.c | 8
mm/migrate.c| 13 -
2 files changed, 21 deletions(-)
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index 0dd0b0d..9d07ed9 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -170,13 +170,6 @@ int balloon_page_migrate(struct address_space *mapping,
if (!isolated_balloon_page(page))
return rc;
- /*
-* Block others from accessing the 'newpage' when we get around to
-* establishing additional references. We should be the only one
-* holding a reference to the 'newpage' at this point.
-*/
- BUG_ON(!trylock_page(newpage));
-
if (WARN_ON(!__is_movable_balloon_page(page))) {
dump_page(page, "not movable balloon page");
unlock_page(newpage);
@@ -186,7 +179,6 @@ int balloon_page_migrate(struct address_space *mapping,
if (balloon && balloon->migratepage)
rc = balloon->migratepage(balloon, newpage, page, mode);
- unlock_page(newpage);
return rc;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index e22be67..b82539b 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -844,19 +844,6 @@ static int __unmap_and_move(struct page *page, struct page
*newpage,
}
}
- if (unlikely(mobile_page(page))) {
- /*
-* A mobile page does not need any special attention from
-* physical to virtual reverse mapping procedures.
-* Skip any attempt to unmap PTEs or to remap swap cache,
-* in order to avoid burning cycles at rmap level, and perform
-* the page migration right away (proteced by page lock).
-*/
- rc = page->mapping->a_ops->migratepage(page->mapping,
- newpage, page, mode);
- goto out_unlock;
- }
-
/*
* Corner case handling:
* 1. When a new swap-cache page is read into, it is added to the LRU
--
2.1.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/
[RFCv3 0/5] enable migration of driver pages
From: Gioh Kim Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver and zram are non-movable pages. So I reported Minchan Kim, the maintainer of zram, and he made the internal compaction logic of zram. And I made the internal compaction of GPU driver. They reduced some fragmentation but they are not enough effective. They are activated by its own interface, /sys, so they are not cooperative with kernel compaction. If there is too much fragmentation and kernel starts to compaction, zram and GPU driver cannot work with the kernel compaction. This patch set combines 5 patches. 1. patch 1/5: get inode from anon_inodes This patch adds new interface to create inode from anon_inodes. 2. patch 2/5: framework to isolate/migrate/putback page Add isolatepage, putbackpage into address_space_operations and wrapper function to call them 3. patch 3/5: apply the framework into balloon driver The balloon driver is applied into the framework. It gets a inode from anon_inodes and register operations in the inode. Any other drivers can register operations via inode like this to migrate it's pages. 4. patch 4/5: compaction/migration call the generic interfaces Compaction and migration pages call the generic interfaces of the framework, instead of calling balloon migration directly. 5. patch 5/5: remove direct calling of migration of driver pages Non-lru pages are migrated with lru pages by move_to_new_page(). This patch set is tested: - turn on Ubuntu 14.04 with 1G memory on qemu. - do kernel building - after several seconds check more than 512MB is used with free command - command "balloon 512" in qemu monitor - check hundreds MB of pages are migrated My thanks to Konstantin Khlebnikov for his reviews of the v2 patch set. Most of the changes were based on his feedback. Changes since v2: - change the name of page type from migratable page into mobile page - get and lock page to isolate page - add wrapper interfaces for page->mapping->a_ops->isolate/putback - leave balloon pages marked as balloon This patch-set is based on v4.1 Gioh Kim (5): fs/anon_inodes: new interface to create new inode mm/compaction: enable mobile-page migration mm/balloon: apply mobile page migratable into balloon mm/compaction: call generic migration callbacks mm: remove direct calling of migration drivers/virtio/virtio_balloon.c| 3 ++ fs/anon_inodes.c | 6 +++ fs/proc/page.c | 3 ++ include/linux/anon_inodes.h| 1 + include/linux/balloon_compaction.h | 15 +-- include/linux/compaction.h | 76 ++ include/linux/fs.h | 2 + include/linux/page-flags.h | 19 + include/uapi/linux/kernel-page-flags.h | 1 + mm/balloon_compaction.c| 71 ++- mm/compaction.c| 8 ++-- mm/migrate.c | 24 +++ 12 files changed, 154 insertions(+), 75 deletions(-) -- 2.1.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/
[RFCv3 3/5] mm/balloon: apply mobile page migratable into balloon
From: Gioh Kim
Apply mobile page migration into balloon driver.
The balloong driver has an anonymous inode that manages
address_space_operation for page migration.
Signed-off-by: Gioh Kim
---
drivers/virtio/virtio_balloon.c| 3 ++
include/linux/balloon_compaction.h | 15 +++--
mm/balloon_compaction.c| 65 +-
mm/compaction.c| 2 +-
mm/migrate.c | 2 +-
5 files changed, 39 insertions(+), 48 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 82e80e0..ef5b9b5 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -505,6 +506,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
balloon_devinfo_init(>vb_dev_info);
#ifdef CONFIG_BALLOON_COMPACTION
vb->vb_dev_info.migratepage = virtballoon_migratepage;
+ vb->vb_dev_info.inode = anon_inode_new();
+ vb->vb_dev_info.inode->i_mapping->a_ops = _aops;
#endif
err = init_vqs(vb);
diff --git a/include/linux/balloon_compaction.h
b/include/linux/balloon_compaction.h
index 9b0a15d..a9e0bde 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
/*
* Balloon device information descriptor.
@@ -62,6 +63,7 @@ struct balloon_dev_info {
struct list_head pages; /* Pages enqueued & handled to Host */
int (*migratepage)(struct balloon_dev_info *, struct page *newpage,
struct page *page, enum migrate_mode mode);
+ struct inode *inode;
};
extern struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info);
@@ -73,12 +75,16 @@ static inline void balloon_devinfo_init(struct
balloon_dev_info *balloon)
spin_lock_init(>pages_lock);
INIT_LIST_HEAD(>pages);
balloon->migratepage = NULL;
+ balloon->inode = NULL;
}
#ifdef CONFIG_BALLOON_COMPACTION
-extern bool balloon_page_isolate(struct page *page);
+extern const struct address_space_operations balloon_aops;
+extern bool balloon_page_isolate(struct page *page,
+isolate_mode_t mode);
extern void balloon_page_putback(struct page *page);
-extern int balloon_page_migrate(struct page *newpage,
+extern int balloon_page_migrate(struct address_space *mapping,
+ struct page *newpage,
struct page *page, enum migrate_mode mode);
/*
@@ -124,6 +130,7 @@ static inline void balloon_page_insert(struct
balloon_dev_info *balloon,
struct page *page)
{
__SetPageBalloon(page);
+ page->mapping = balloon->inode->i_mapping;
SetPagePrivate(page);
set_page_private(page, (unsigned long)balloon);
list_add(>lru, >pages);
@@ -140,6 +147,7 @@ static inline void balloon_page_insert(struct
balloon_dev_info *balloon,
static inline void balloon_page_delete(struct page *page)
{
__ClearPageBalloon(page);
+ page->mapping = NULL;
set_page_private(page, 0);
if (PagePrivate(page)) {
ClearPagePrivate(page);
@@ -191,7 +199,8 @@ static inline bool isolated_balloon_page(struct page *page)
return false;
}
-static inline bool balloon_page_isolate(struct page *page)
+static inline bool balloon_page_isolate(struct page *page,
+ isolate_mode_t mode)
{
return false;
}
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index fcad832..0dd0b0d 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -131,43 +131,16 @@ static inline void __putback_balloon_page(struct page
*page)
}
/* __isolate_lru_page() counterpart for a ballooned page */
-bool balloon_page_isolate(struct page *page)
+bool balloon_page_isolate(struct page *page, isolate_mode_t mode)
{
/*
-* Avoid burning cycles with pages that are yet under __free_pages(),
-* or just got freed under us.
-*
-* In case we 'win' a race for a balloon page being freed under us and
-* raise its refcount preventing __free_pages() from doing its job
-* the put_page() at the end of this block will take care of
-* release this page, thus avoiding a nasty leakage.
+* A ballooned page, by default, has PagePrivate set.
+* Prevent concurrent compaction threads from isolating
+* an already isolated balloon page by clearing it.
*/
- if (likely(get_page_unless_zero(page))) {
- /*
-* As balloon pages are not isolated from LRU lists, concurrent
-* compaction threads can race against page migration functions
-* as well as race
[RFCv3 4/5] mm: call generic migration callbacks
From: Gioh Kim
Compaction calls interfaces of mobile page migration
instead of calling balloon migration directly.
Signed-off-by: Gioh Kim
---
mm/compaction.c | 8
mm/migrate.c| 19 ++-
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 81bafaf..60e4cbb 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include "internal.h"
@@ -714,12 +714,12 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
/*
* Check may be lockless but that's ok as we recheck later.
-* It's possible to migrate LRU pages and balloon pages
+* It's possible to migrate LRU pages and mobile pages
* Skip any other type of page
*/
if (!PageLRU(page)) {
- if (unlikely(balloon_page_movable(page))) {
- if (balloon_page_isolate(page, isolate_mode)) {
+ if (unlikely(mobile_page(page))) {
+ if (isolate_mobilepage(page, isolate_mode)) {
/* Successfully isolated */
goto isolate_success;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index c94038e..e22be67 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -76,7 +76,7 @@ int migrate_prep_local(void)
* from where they were once taken off for compaction/migration.
*
* This function shall be used whenever the isolated pageset has been
- * built from lru, balloon, hugetlbfs page. See isolate_migratepages_range()
+ * built from lru, mobile, hugetlbfs page. See isolate_migratepages_range()
* and isolate_huge_page().
*/
void putback_movable_pages(struct list_head *l)
@@ -92,8 +92,8 @@ void putback_movable_pages(struct list_head *l)
list_del(>lru);
dec_zone_page_state(page, NR_ISOLATED_ANON +
page_is_file_cache(page));
- if (unlikely(isolated_balloon_page(page)))
- balloon_page_putback(page);
+ if (unlikely(mobile_page(page)))
+ putback_mobilepage(page);
else
putback_lru_page(page);
}
@@ -844,15 +844,16 @@ static int __unmap_and_move(struct page *page, struct
page *newpage,
}
}
- if (unlikely(isolated_balloon_page(page))) {
+ if (unlikely(mobile_page(page))) {
/*
-* A ballooned page does not need any special attention from
+* A mobile page does not need any special attention from
* physical to virtual reverse mapping procedures.
* Skip any attempt to unmap PTEs or to remap swap cache,
* in order to avoid burning cycles at rmap level, and perform
* the page migration right away (proteced by page lock).
*/
- rc = balloon_page_migrate(page->mapping, newpage, page, mode);
+ rc = page->mapping->a_ops->migratepage(page->mapping,
+ newpage, page, mode);
goto out_unlock;
}
@@ -960,8 +961,8 @@ out:
if (rc != MIGRATEPAGE_SUCCESS && put_new_page) {
ClearPageSwapBacked(newpage);
put_new_page(newpage, private);
- } else if (unlikely(__is_movable_balloon_page(newpage))) {
- /* drop our reference, page already in the balloon */
+ } else if (unlikely(mobile_page(newpage))) {
+ /* drop our reference */
put_page(newpage);
} else
putback_lru_page(newpage);
--
2.1.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/
[PATCH v3] arm64: Modify the dump mem for 64 bit addresses
From: Rohit Thapliyal
On 64bit kernel, the dump_mem gives 32 bit addresses
on the stack dump. This gives unorganized information regarding
the 64bit values on the stack. Hence, modified to get a complete
64bit memory dump.
With patch:
[ 93.534801] Process insmod (pid: 1587, stack limit = 0xffc976be4058)
[ 93.541441] Stack: (0xffc976be7cf0 to 0xffc976be8000)
[ 93.547136] 7ce0: ffc976be7d00
ffc8163c
[ 93.554898] 7d00: ffc976be7d40 ffcf8a44 ffc00098ef38
ffbffc88
[ 93.562659] 7d20: ffc00098ef50 ffbffcc0 0001
ffbffc70
[ 93.570419] 7d40: ffc976be7e40 ffcf935c
2b424090
[ 93.578179] 7d60: 2b424010 007facc555f4 8000
0015
[ 93.585937] 7d80: 0116 0069 ffc00097b000
ffc976be4000
[ 93.593694] 7da0: 0064 0072 006e
003f
[ 93.601453] 7dc0: feff fff1 ffbffc002028
0124
[ 93.609211] 7de0: ffc976be7e10 0001 ff80
ffbb
[ 93.616969] 7e00: ffc976be7e60
[ 93.624726] 7e20:
[ 93.632484] 7e40: 007fcc474550 ffc841ec 2b424010
007facda0710
[ 93.640241] 7e60: ffcbe6dc ff80007d2000
0001c010
[ 93.647999] 7e80: ff80007e0ae0 ff80007e09d0 ff80007edf70
0288
[ 93.655757] 7ea0: 02e8
001c001b
[ 93.663514] 7ec0: 0009 0007 2b424090
0001c010
[ 93.671272] 7ee0: 2b424010 007faccd3a48
[ 93.679030] 7f00: 007fcc4743f8 007fcc4743f8 0069
0003
[ 93.686787] 7f20: 0101010101010101 0004 0020
03f3
[ 93.694544] 7f40: 007facb95664 007facda7030 007facc555d0
00498378
[ 93.702301] 7f60: 2b424010 007facda0710
2b424090
[ 93.710058] 7f80: 007fcc474698 00498000 007fcc474ebb
00474f58
[ 93.717815] 7fa0: 00498000
007fcc474550
[ 93.725573] 7fc0: 004104bc 007fcc474430 007facc555f4
8000
[ 93.70] 7fe0: 2b424090 0069 0950020128000244
41040804
[ 93.741084] Call trace:
The above output makes a debugger life a lot more easier.
Signed-off-by: Rohit Thapliyal
Signed-off-by: Maninder Singh
---
v1: added new function dump_mem64
v2: Removed the separate function dump_mem64 and accommodated
a field width based on which the dump shall be created of
width either 4 or 8 as suggested by Catalin.
v3: Changelog modified
arch/arm64/kernel/traps.c | 44 +---
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 1ef2940..53d57db 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -51,8 +51,9 @@ int show_unhandled_signals = 1;
/*
* Dump out the contents of some memory nicely...
*/
+
static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
-unsigned long top)
+unsigned long top, unsigned int width)
{
unsigned long first;
mm_segment_t fs;
@@ -70,18 +71,27 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
for (first = bottom & ~31; first < top; first += 32) {
unsigned long p;
- char str[sizeof(" 12345678") * 8 + 1];
+ char str[sizeof(" 1234567812345678") * 8 + 1];
memset(str, ' ', sizeof(str));
str[sizeof(str) - 1] = '\0';
- for (p = first, i = 0; i < 8 && p < top; i++, p += 4) {
+ for (p = first, i = 0; i < (width > 4 ? width-4 : width+4)
+ && p < top; i++, p += width) {
if (p >= bottom && p < top) {
- unsigned int val;
- if (__get_user(val, (unsigned int *)p) == 0)
- sprintf(str + i * 9, " %08x", val);
- else
- sprintf(str + i * 9, " ");
+ unsigned long val;
+
+ if (width == 8) {
+ if (__get_user(val, (unsigned long *)p)
== 0)
+ sprintf(str + i * 17, "
%016lx", val);
+ else
+
Re: [RESEND][PATCH v2] arm64:Modify the dump mem for 64 bit addresses
2015-07-07 12:56 GMT+09:00 Maninder Singh : > From: Rohit Thapliyal > > V1 = added new function dump_mem64 > v1->v2 > Removed the separate function dump_mem64 and accommodated > a field width based on which the dump shall be created of > width either 4 or 8 as suggested by Catalin. Hi, Please put the changelog after the commit message under separator (---) so it won't be included in commit. If you really, really want to include the changelog inside the commit then please put it at the end because it is the least important piece of information (from history point of view). > > On 64bit kernel, the dump_mem gives 32 bit addresses > on the stack dump. This gives unorganized information regarding > the 64bit values on the stack. Hence, modified to get a complete > 64bit memory dump. > > With patch: > [ 93.534801] Process insmod (pid: 1587, stack limit = 0xffc976be4058) > [ 93.541441] Stack: (0xffc976be7cf0 to 0xffc976be8000) > [ 93.547136] 7ce0: ffc976be7d00 > ffc8163c > [ 93.554898] 7d00: ffc976be7d40 ffcf8a44 ffc00098ef38 > ffbffc88 > [ 93.562659] 7d20: ffc00098ef50 ffbffcc0 0001 > ffbffc70 > [ 93.570419] 7d40: ffc976be7e40 ffcf935c > 2b424090 > [ 93.578179] 7d60: 2b424010 007facc555f4 8000 > 0015 > [ 93.585937] 7d80: 0116 0069 ffc00097b000 > ffc976be4000 > [ 93.593694] 7da0: 0064 0072 006e > 003f > [ 93.601453] 7dc0: feff fff1 ffbffc002028 > 0124 > [ 93.609211] 7de0: ffc976be7e10 0001 ff80 > ffbb > [ 93.616969] 7e00: ffc976be7e60 > > [ 93.624726] 7e20: > > [ 93.632484] 7e40: 007fcc474550 ffc841ec 2b424010 > 007facda0710 > [ 93.640241] 7e60: ffcbe6dc ff80007d2000 > 0001c010 > [ 93.647999] 7e80: ff80007e0ae0 ff80007e09d0 ff80007edf70 > 0288 > [ 93.655757] 7ea0: 02e8 > 001c001b > [ 93.663514] 7ec0: 0009 0007 2b424090 > 0001c010 > [ 93.671272] 7ee0: 2b424010 007faccd3a48 > > [ 93.679030] 7f00: 007fcc4743f8 007fcc4743f8 0069 > 0003 > [ 93.686787] 7f20: 0101010101010101 0004 0020 > 03f3 > [ 93.694544] 7f40: 007facb95664 007facda7030 007facc555d0 > 00498378 > [ 93.702301] 7f60: 2b424010 007facda0710 > 2b424090 > [ 93.710058] 7f80: 007fcc474698 00498000 007fcc474ebb > 00474f58 > [ 93.717815] 7fa0: 00498000 > 007fcc474550 > [ 93.725573] 7fc0: 004104bc 007fcc474430 007facc555f4 > 8000 > [ 93.70] 7fe0: 2b424090 0069 0950020128000244 > 41040804 > [ 93.741084] Call trace: > > The above output makes a debugger life a lot more easier. > > Signed-off-by: Rohit Thapliyal > Signed-off-by: Maninder Singh > Reviewed-by: Akhilesh kumar The first patch you sent, already contained Akhilesh kumar's reviewed-by tag. But there was no email from him with actual review. Reviews should be performed publicly and should have a public trace. The person is not even cc-ed so he cannot verify whether the tag is appropriate. Best regards, Krzysztof -- 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 net-next] tcp: always send a quick ack when quickacks are enabled
I ran some tests and after setting the "ip route change quickack 1"
knob there were still many delayed ACKs sent. This occured
because when icsk_ack.quick=0 the !icsk_ack.pingpong value is
subsequently ignored as tcp_in_quickack_mode() checks both these
values. The condition for a quick ack to trigger requires
that both icsk_ack.quick != 0 and icsk_ack.pingpong=0. Currently
only icsk_ack.pingpong is controlled by the knob. But the
icsk_ack.quick value changes dynamically depending on heuristics.
The crux of the matter is that delayed acks still cannot be entirely
disabled even with the RTAX_QUICKACK per dst knob enabled. This
patch ensures that a quick ack is always sent when the RTAX_QUICKACK
per dst knob is turned on.
The "ip route change quickack 1" knob was recently added to enable
quickacks. It was modeled around the TCP_QUICKACK setsockopt() option.
This issue is that even with "ip route change quickack 1" enabled
we still see delayed ACKs under some conditions. It would be nice
to be able to completely disable delayed ACKs.
Here is an example:
# netstat -s|grep dela
3 delayed acks sent
For all routes enable the knob
# ip route change quickack 1
Generate some traffic across a slow link and we still see the delayed
acks.
# netstat -s|grep dela
106 delayed acks sent
1 delayed acks further delayed because of locked socket
The issue is that both the "ip route change quickack 1" knob and
the TCP_QUICKACK option set the icsk_ack.pingpong variable to 0.
However at the business end in the __tcp_ack_snd_check() routine,
tcp_in_quickack_mode() checks that both icsk_ack.quick != 0
and icsk_ack.pingpong=0 in order to trigger a quickack. As
icsk_ack.quick is determined by heuristics it can be 0. When
that occurs the icsk_ack.pingpong value is ignored and a delayed
ACK is sent regardless.
This patch moves the RTAX_QUICKACK per dst check into the
__tcp_ack_snd_check() routine which ensures that a quickack is
always sent when the quickack knob is enabled for that dst.
Signed-off-by: Jon Maxwell
---
net/ipv4/tcp_input.c | 8
net/ipv4/tcp_output.c | 6 ++
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 684f095..1af7d74 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3948,7 +3948,6 @@ void tcp_reset(struct sock *sk)
static void tcp_fin(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- const struct dst_entry *dst;
inet_csk_schedule_ack(sk);
@@ -3960,9 +3959,7 @@ static void tcp_fin(struct sock *sk)
case TCP_ESTABLISHED:
/* Move to CLOSE_WAIT */
tcp_set_state(sk, TCP_CLOSE_WAIT);
- dst = __sk_dst_get(sk);
- if (!dst || !dst_metric(dst, RTAX_QUICKACK))
- inet_csk(sk)->icsk_ack.pingpong = 1;
+ inet_csk(sk)->icsk_ack.pingpong = 1;
break;
case TCP_CLOSE_WAIT:
@@ -4887,6 +4884,7 @@ static inline void tcp_data_snd_check(struct sock *sk)
static void __tcp_ack_snd_check(struct sock *sk, int ofo_possible)
{
struct tcp_sock *tp = tcp_sk(sk);
+ const struct dst_entry *dst = __sk_dst_get(sk);
/* More than one full frame received... */
if (((tp->rcv_nxt - tp->rcv_wup) > inet_csk(sk)->icsk_ack.rcv_mss &&
@@ -4896,6 +4894,8 @@ static void __tcp_ack_snd_check(struct sock *sk, int
ofo_possible)
__tcp_select_window(sk) >= tp->rcv_wnd) ||
/* We ACK each frame or... */
tcp_in_quickack_mode(sk) ||
+ /* quickack on dst */
+ (dst && dst_metric(dst, RTAX_QUICKACK)) ||
/* We have out of order data. */
(ofo_possible && skb_peek(>out_of_order_queue))) {
/* Then ack it now */
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index b1c218d..7105784 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -163,7 +163,6 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
{
struct inet_connection_sock *icsk = inet_csk(sk);
const u32 now = tcp_time_stamp;
- const struct dst_entry *dst = __sk_dst_get(sk);
if (sysctl_tcp_slow_start_after_idle &&
(!tp->packets_out && (s32)(now - tp->lsndtime) > icsk->icsk_rto))
@@ -174,9 +173,8 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
/* If it is a reply for ato after last received
* packet, enter pingpong mode.
*/
- if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato &&
- (!dst || !dst_metric(dst, RTAX_QUICKACK)))
- icsk->icsk_ack.pingpong = 1;
+ if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato)
+ icsk->icsk_ack.pingpong = 1;
}
/* Account for an ACK we sent. */
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH] dmaengine: imx-sdma: Add device to device support
On Tue, Jun 23, 2015 at 04:42:54PM +0800, Shengjiu Wang wrote:
> +static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
> +{
> + struct sdma_engine *sdma = sdmac->sdma;
> +
> + int lwml = sdmac->watermark_level & 0xff;
> + int hwml = (sdmac->watermark_level >> 16) & 0xff;
> +
> + if (sdmac->event_id0 > 31) {
> + sdmac->event_mask[0] |= 0;
> + __set_bit(28, >watermark_level);
why not use set_bit(), you are modifying driver memory
> + sdmac->event_mask[1] |=
> + BIT(sdmac->event_id0 % 32);
and then why not use set_bit() here too?
> + } else {
> + sdmac->event_mask[0] |= 0;
> + sdmac->event_mask[1] |=
> + BIT(sdmac->event_id0 % 32);
> + }
> + if (sdmac->event_id1 > 31) {
> + sdmac->event_mask[1] |= 0;
> + __set_bit(29, >watermark_level);
> + sdmac->event_mask[0] |=
> + BIT(sdmac->event_id1 % 32);
> + } else {
> + sdmac->event_mask[1] |= 0;
> + sdmac->event_mask[0] |=
> + BIT(sdmac->event_id1 % 32);
> + }
pattern for eventidX is repeated, also in that we can make generic macro to
handle and reduce code size
> +
> + /*
> + * If LWML(src_maxburst) > HWML(dst_maxburst), we need
> + * swap LWML and HWML of INFO(A.3.2.5.1), also need swap
> + * r0(event_mask[1]) and r1(event_mask[0]).
> + */
> + if (lwml > hwml) {
> + sdmac->watermark_level &= ~0xff00ff;
Magic number?
> static int sdma_config_channel(struct dma_chan *chan)
> {
> struct sdma_channel *sdmac = to_sdma_chan(chan);
> @@ -869,6 +945,12 @@ static int sdma_config_channel(struct dma_chan *chan)
> sdma_event_enable(sdmac, sdmac->event_id0);
> }
>
> + if (sdmac->event_id1) {
> + if (sdmac->event_id1 >= sdmac->sdma->drvdata->num_events)
> + return -EINVAL;
> + sdma_event_enable(sdmac, sdmac->event_id1);
> + }
> +
> switch (sdmac->peripheral_type) {
> case IMX_DMATYPE_DSP:
> sdma_config_ownership(sdmac, false, true, true);
> @@ -887,19 +969,21 @@ static int sdma_config_channel(struct dma_chan *chan)
> (sdmac->peripheral_type != IMX_DMATYPE_DSP)) {
> /* Handle multiple event channels differently */
> if (sdmac->event_id1) {
> - sdmac->event_mask[1] = BIT(sdmac->event_id1 % 32);
> - if (sdmac->event_id1 > 31)
> - __set_bit(31, >watermark_level);
> - sdmac->event_mask[0] = BIT(sdmac->event_id0 % 32);
> - if (sdmac->event_id0 > 31)
> - __set_bit(30, >watermark_level);
> - } else {
> + if (sdmac->peripheral_type == IMX_DMATYPE_ASRC_SP ||
> + sdmac->peripheral_type == IMX_DMATYPE_ASRC)
> + sdma_set_watermarklevel_for_p2p(sdmac);
> + } else
> __set_bit(sdmac->event_id0, sdmac->event_mask);
> - }
> +
> /* Watermark Level */
> sdmac->watermark_level |= sdmac->watermark_level;
> /* Address */
> - sdmac->shp_addr = sdmac->per_address;
> + if (sdmac->direction == DMA_DEV_TO_DEV) {
Okay the direction is depreciated, so can you store both source and
destination and use them based on direction in prepare()
Also I see driver is not doing this, so while at it, can you fix this is
current code as well
--
~Vinod
--
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/
spoluprace
Mam prospesne resení pro nas oba. byste mi mel odpovedet na nize pro vysvetlení na e-mailovou adresu. E-mail: jgg.c...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] base: power: wakeirq: don't leak dev->power.wakeirq
Hi On Mon, Jul 6, 2015 at 8:09 PM, Felipe Balbi wrote: > On Mon, Jul 06, 2015 at 08:06:17PM +0200, Michael Trimarchi wrote: >> Hi >> >> On Jul 6, 2015 8:01 PM, "Felipe Balbi" wrote: >> > >> > on a first call to dev_pm_attach_wake_irq(), if it >> > fails, it will leave dev->power.wakeirq set to a >> > dangling pointer. Instead, let's clear it to make >> > sure a subsequent call to dev_pm_attach_wake_irq() >> > has chance to succeed. >> > >> > Cc: Tony Lindgren >> > Signed-off-by: Felipe Balbi >> > --- >> > drivers/base/power/wakeirq.c | 9 - >> > 1 file changed, 8 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c >> > index 7470004ca810..394d250a1ad8 100644 >> > --- a/drivers/base/power/wakeirq.c >> > +++ b/drivers/base/power/wakeirq.c >> > @@ -50,9 +50,16 @@ static int dev_pm_attach_wake_irq(struct device *dev, >> int irq, >> > >> > err = device_wakeup_attach_irq(dev, wirq); >> > if (err) >> > - return err; >> > + goto err_cleanup; >> > >> > return 0; >> > + >> > +err_cleanup: >> > + spin_lock_irqsave(>power.lock, flags); >> > + dev->power.wakeirq = NULL; >> > + spin_unlock_irqrestore(>power.lock, flags); >> > + >> >> Why here and not in the fuction that return the error? > > because the field was set here, why would I clear it elsewhere ? > Clear now and even more from the other patch proposal. Michael > -- > balbi -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.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/
MM: Query about different memory types(mem_types)__mmu.c
Hi All,
I have been exploring ARM reference manual about ARM weak memory model
and mmu page table setting from some time.
I think i understand different memory types, mmu settings for
page/section, TEX, AP, B, C, S bits well.
My target is to to dig further and fully understand setting of all
parameters for different memory types in ARM
[File mmu.c: "static struct mem_type mem_types"].
But i am not able to find any good source to refer for fully
understanding all below parameters.
Could you please help me to understand mappings for below mem types.
If you can point me to some references which can help me understand
more.
Thank you in advance for your help.
[MT_DEVICE] = { /* Strongly ordered / ARMv6 shared device */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_SHARED |
L_PTE_SHARED,
.prot_pte_s2= s2_policy(PROT_PTE_S2_DEVICE) |
s2_policy(L_PTE_S2_MT_DEV_SHARED) |
L_PTE_SHARED,
.prot_l1= PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE | PMD_SECT_S,
.domain = DOMAIN_IO,
},
[MT_MEMORY_RW] = {
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
L_PTE_XN,
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE,
.domain= DOMAIN_KERNEL,
},
[MT_MEMORY_DMA_READY] = {
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
L_PTE_XN,
.prot_l1 = PMD_TYPE_TABLE,
.domain= DOMAIN_KERNEL,
},
Regards,
Sumit Gupta
--
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 6/6] clk: ti: make use of of_clk_parent_fill helper function
From: Dinh Nguyen
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen
Cc: Tero Kristo
---
drivers/clk/ti/apll.c |4 +---
drivers/clk/ti/composite.c |4 +---
drivers/clk/ti/dpll.c |4 +---
drivers/clk/ti/fapll.c |3 +--
drivers/clk/ti/mux.c |4 +---
5 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/ti/apll.c b/drivers/clk/ti/apll.c
index 49baf38..523880e 100644
--- a/drivers/clk/ti/apll.c
+++ b/drivers/clk/ti/apll.c
@@ -170,7 +170,6 @@ static void __init of_dra7_apll_setup(struct device_node
*node)
struct clk_hw_omap *clk_hw = NULL;
struct clk_init_data *init = NULL;
const char **parent_names = NULL;
- int i;
ad = kzalloc(sizeof(*ad), GFP_KERNEL);
clk_hw = kzalloc(sizeof(*clk_hw), GFP_KERNEL);
@@ -195,8 +194,7 @@ static void __init of_dra7_apll_setup(struct device_node
*node)
if (!parent_names)
goto cleanup;
- for (i = 0; i < init->num_parents; i++)
- parent_names[i] = of_clk_get_parent_name(node, i);
+ of_clk_parent_fill(node, parent_names, init->num_parents);
init->parent_names = parent_names;
diff --git a/drivers/clk/ti/composite.c b/drivers/clk/ti/composite.c
index 96f83ce..dbef218 100644
--- a/drivers/clk/ti/composite.c
+++ b/drivers/clk/ti/composite.c
@@ -276,7 +276,6 @@ int __init ti_clk_add_component(struct device_node *node,
struct clk_hw *hw,
int num_parents;
const char **parent_names;
struct component_clk *clk;
- int i;
num_parents = of_clk_get_parent_count(node);
@@ -289,8 +288,7 @@ int __init ti_clk_add_component(struct device_node *node,
struct clk_hw *hw,
if (!parent_names)
return -ENOMEM;
- for (i = 0; i < num_parents; i++)
- parent_names[i] = of_clk_get_parent_name(node, i);
+ of_clk_parent_fill(node, parent_names, num_parents);
clk = kzalloc(sizeof(*clk), GFP_KERNEL);
if (!clk) {
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 2aacf7a..49acdf2 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -341,7 +341,6 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
struct clk_init_data *init = NULL;
const char **parent_names = NULL;
struct dpll_data *dd = NULL;
- int i;
u8 dpll_mode = 0;
dd = kzalloc(sizeof(*dd), GFP_KERNEL);
@@ -370,8 +369,7 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (!parent_names)
goto cleanup;
- for (i = 0; i < init->num_parents; i++)
- parent_names[i] = of_clk_get_parent_name(node, i);
+ of_clk_parent_fill(node, parent_names, init->num_parents);
init->parent_names = parent_names;
diff --git a/drivers/clk/ti/fapll.c b/drivers/clk/ti/fapll.c
index 730aa62..b1c741b 100644
--- a/drivers/clk/ti/fapll.c
+++ b/drivers/clk/ti/fapll.c
@@ -558,8 +558,7 @@ static void __init ti_fapll_setup(struct device_node *node)
goto free;
}
- parent_name[0] = of_clk_get_parent_name(node, 0);
- parent_name[1] = of_clk_get_parent_name(node, 1);
+ of_clk_parent_fill(node, parent_name, 2);
init->parent_names = parent_name;
fd->clk_ref = of_clk_get(node, 0);
diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
index 5cdeed5..99fe27e 100644
--- a/drivers/clk/ti/mux.c
+++ b/drivers/clk/ti/mux.c
@@ -190,7 +190,6 @@ static void of_mux_clk_setup(struct device_node *node)
void __iomem *reg;
int num_parents;
const char **parent_names;
- int i;
u8 clk_mux_flags = 0;
u32 mask = 0;
u32 shift = 0;
@@ -205,8 +204,7 @@ static void of_mux_clk_setup(struct device_node *node)
if (!parent_names)
goto cleanup;
- for (i = 0; i < num_parents; i++)
- parent_names[i] = of_clk_get_parent_name(node, i);
+ of_clk_parent_fill(node, parent_names, num_parents);
reg = ti_clk_get_reg_addr(node, 0);
--
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/
[PATCHv2 0/6] clk: make use of of_clk_parent_fill helper function
From: Dinh Nguyen Hello, This is v2 of the patchset that makes use of of_clk_parent_fill helper function on various platforms. Thanks, Dinh Nguyen (6): clk: at91: make use of of_clk_parent_fill helper function clk: qoriq: make use of of_clk_parent_fill helper function clk: keystone: make use of of_clk_parent_fill helper function clk: st: make use of of_clk_parent_fill helper function clk: sunxi: make use of of_clk_parent_fill helper function clk: ti: make use of of_clk_parent_fill helper function drivers/clk/at91/clk-main.c |7 +-- drivers/clk/at91/clk-master.c |7 +-- drivers/clk/at91/clk-programmable.c |7 +-- drivers/clk/at91/clk-slow.c | 14 ++ drivers/clk/at91/clk-smd.c |7 +-- drivers/clk/at91/clk-usb.c |7 +-- drivers/clk/clk-qoriq.c |5 ++--- drivers/clk/keystone/pll.c |3 +-- drivers/clk/st/clk-flexgen.c|6 ++ drivers/clk/st/clkgen-mux.c |7 ++- drivers/clk/sunxi/clk-a20-gmac.c|4 +--- drivers/clk/sunxi/clk-factors.c |4 +--- drivers/clk/sunxi/clk-sun6i-ar100.c |3 +-- drivers/clk/sunxi/clk-sunxi.c | 10 ++ drivers/clk/ti/apll.c |4 +--- drivers/clk/ti/composite.c |4 +--- drivers/clk/ti/dpll.c |4 +--- drivers/clk/ti/fapll.c |3 +-- drivers/clk/ti/mux.c|4 +--- 19 files changed, 24 insertions(+), 86 deletions(-) -- 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/
[PATCHv2 1/6] clk: at91: make use of of_clk_parent_fill helper function
From: Dinh Nguyen
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen
Cc: Boris Brezillon
---
drivers/clk/at91/clk-main.c |7 +--
drivers/clk/at91/clk-master.c |7 +--
drivers/clk/at91/clk-programmable.c |7 +--
drivers/clk/at91/clk-slow.c | 14 ++
drivers/clk/at91/clk-smd.c |7 +--
drivers/clk/at91/clk-usb.c |7 +--
6 files changed, 7 insertions(+), 42 deletions(-)
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
index c240045..13f481b 100644
--- a/drivers/clk/at91/clk-main.c
+++ b/drivers/clk/at91/clk-main.c
@@ -612,17 +612,12 @@ void __init of_at91sam9x5_clk_main_setup(struct
device_node *np,
int num_parents;
unsigned int irq;
const char *name = np->name;
- int i;
num_parents = of_clk_get_parent_count(np);
if (num_parents <= 0 || num_parents > 2)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
of_property_read_string(np, "clock-output-names", );
diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index f98eafe..38f646d 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -218,7 +218,6 @@ of_at91_clk_master_setup(struct device_node *np, struct
at91_pmc *pmc,
{
struct clk *clk;
int num_parents;
- int i;
unsigned int irq;
const char *parent_names[MASTER_SOURCE_MAX];
const char *name = np->name;
@@ -228,11 +227,7 @@ of_at91_clk_master_setup(struct device_node *np, struct
at91_pmc *pmc,
if (num_parents <= 0 || num_parents > MASTER_SOURCE_MAX)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
of_property_read_string(np, "clock-output-names", );
diff --git a/drivers/clk/at91/clk-programmable.c
b/drivers/clk/at91/clk-programmable.c
index 8c86c0f..21492ac 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -230,7 +230,6 @@ of_at91_clk_prog_setup(struct device_node *np, struct
at91_pmc *pmc,
{
int num;
u32 id;
- int i;
struct clk *clk;
int num_parents;
const char *parent_names[PROG_SOURCE_MAX];
@@ -241,11 +240,7 @@ of_at91_clk_prog_setup(struct device_node *np, struct
at91_pmc *pmc,
if (num_parents <= 0 || num_parents > PROG_SOURCE_MAX)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
num = of_get_child_count(np);
if (!num || num > (PROG_ID_MAX + 1))
diff --git a/drivers/clk/at91/clk-slow.c b/drivers/clk/at91/clk-slow.c
index 98a84a8..84c19d7 100644
--- a/drivers/clk/at91/clk-slow.c
+++ b/drivers/clk/at91/clk-slow.c
@@ -371,17 +371,12 @@ void __init of_at91sam9x5_clk_slow_setup(struct
device_node *np,
const char *parent_names[2];
int num_parents;
const char *name = np->name;
- int i;
num_parents = of_clk_get_parent_count(np);
if (num_parents <= 0 || num_parents > 2)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
of_property_read_string(np, "clock-output-names", );
@@ -449,17 +444,12 @@ void __init of_at91sam9260_clk_slow_setup(struct
device_node *np,
const char *parent_names[2];
int num_parents;
const char *name = np->name;
- int i;
num_parents = of_clk_get_parent_count(np);
if (num_parents != 2)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
of_property_read_string(np, "clock-output-names", );
diff --git a/drivers/clk/at91/clk-smd.c b/drivers/clk/at91/clk-smd.c
index 3817ea8..a7f8501 100644
--- a/drivers/clk/at91/clk-smd.c
+++ b/drivers/clk/at91/clk-smd.c
@@ -145,7 +145,6 @@ void __init of_at91sam9x5_clk_smd_setup(struct device_node
*np,
struct at91_pmc *pmc)
{
struct clk *clk;
-
[PATCHv2 4/6] clk: st: make use of of_clk_parent_fill helper function
From: Dinh Nguyen
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen
Tested-by Gabriel Fernandez
Cc: Peter Griffin
---
drivers/clk/st/clk-flexgen.c |6 ++
drivers/clk/st/clkgen-mux.c |7 ++-
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/st/clk-flexgen.c b/drivers/clk/st/clk-flexgen.c
index 657ca14..ed0696c 100644
--- a/drivers/clk/st/clk-flexgen.c
+++ b/drivers/clk/st/clk-flexgen.c
@@ -243,7 +243,7 @@ static const char ** __init flexgen_get_parents(struct
device_node *np,
int *num_parents)
{
const char **parents;
- int nparents, i;
+ int nparents;
nparents = of_clk_get_parent_count(np);
if (WARN_ON(nparents <= 0))
@@ -253,10 +253,8 @@ static const char ** __init flexgen_get_parents(struct
device_node *np,
if (!parents)
return NULL;
- for (i = 0; i < nparents; i++)
- parents[i] = of_clk_get_parent_name(np, i);
+ *num_parents = of_clk_parent_fill(np, parents, nparents);
- *num_parents = nparents;
return parents;
}
diff --git a/drivers/clk/st/clkgen-mux.c b/drivers/clk/st/clkgen-mux.c
index 4fbe6e0..b83654a 100644
--- a/drivers/clk/st/clkgen-mux.c
+++ b/drivers/clk/st/clkgen-mux.c
@@ -24,7 +24,7 @@ static const char ** __init clkgen_mux_get_parents(struct
device_node *np,
int *num_parents)
{
const char **parents;
- int nparents, i;
+ int nparents;
nparents = of_clk_get_parent_count(np);
if (WARN_ON(nparents <= 0))
@@ -34,10 +34,7 @@ static const char ** __init clkgen_mux_get_parents(struct
device_node *np,
if (!parents)
return ERR_PTR(-ENOMEM);
- for (i = 0; i < nparents; i++)
- parents[i] = of_clk_get_parent_name(np, i);
-
- *num_parents = nparents;
+ *num_parents = of_clk_parent_fill(np, parents, nparents);
return parents;
}
--
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/
[PATCHv2 5/6] clk: sunxi: make use of of_clk_parent_fill helper function
From: Dinh Nguyen Use of_clk_parent_fill to fill in the parent clock names' array. Signed-off-by: Dinh Nguyen Cc: Maxime Ripard Cc: "Emilio López" --- v2: Add if (of_clk_parent_fill(node, parents, 2) != 2) to clk-a20-gmac.c --- drivers/clk/sunxi/clk-a20-gmac.c|4 +--- drivers/clk/sunxi/clk-factors.c |4 +--- drivers/clk/sunxi/clk-sun6i-ar100.c |3 +-- drivers/clk/sunxi/clk-sunxi.c | 10 ++ 4 files changed, 5 insertions(+), 16 deletions(-) diff --git a/drivers/clk/sunxi/clk-a20-gmac.c b/drivers/clk/sunxi/clk-a20-gmac.c index 0dcf4f2..1611b03 100644 --- a/drivers/clk/sunxi/clk-a20-gmac.c +++ b/drivers/clk/sunxi/clk-a20-gmac.c @@ -80,9 +80,7 @@ static void __init sun7i_a20_gmac_clk_setup(struct device_node *node) goto free_mux; /* gmac clock requires exactly 2 parents */ - parents[0] = of_clk_get_parent_name(node, 0); - parents[1] = of_clk_get_parent_name(node, 1); - if (!parents[0] || !parents[1]) + if (of_clk_parent_fill(node, parents, 2) != 2) goto free_gate; reg = of_iomap(node, 0); diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c index 8c20190..2589457 100644 --- a/drivers/clk/sunxi/clk-factors.c +++ b/drivers/clk/sunxi/clk-factors.c @@ -174,9 +174,7 @@ struct clk *sunxi_factors_register(struct device_node *node, int i = 0; /* if we have a mux, we will have >1 parents */ - while (i < FACTORS_MAX_PARENTS && - (parents[i] = of_clk_get_parent_name(node, i)) != NULL) - i++; + i = of_clk_parent_fill(node, parents, FACTORS_MAX_PARENTS); /* * some factor clocks, such as pll5 and pll6, may have multiple diff --git a/drivers/clk/sunxi/clk-sun6i-ar100.c b/drivers/clk/sunxi/clk-sun6i-ar100.c index 63cf149..6f229ff 100644 --- a/drivers/clk/sunxi/clk-sun6i-ar100.c +++ b/drivers/clk/sunxi/clk-sun6i-ar100.c @@ -195,8 +195,7 @@ static int sun6i_a31_ar100_clk_probe(struct platform_device *pdev) if (nparents > SUN6I_AR100_MAX_PARENTS) nparents = SUN6I_AR100_MAX_PARENTS; - for (i = 0; i < nparents; i++) - parents[i] = of_clk_get_parent_name(np, i); + of_clk_parent_fill(np, parents, nparents); of_property_read_string(np, "clock-output-names", _name); diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c index 9a82f17..eed66f8 100644 --- a/drivers/clk/sunxi/clk-sunxi.c +++ b/drivers/clk/sunxi/clk-sunxi.c @@ -202,10 +202,7 @@ static void __init sun6i_ahb1_clk_setup(struct device_node *node) return; /* we have a mux, we will have >1 parents */ - while (i < SUN6I_AHB1_MAX_PARENTS && - (parents[i] = of_clk_get_parent_name(node, i)) != NULL) - i++; - + of_clk_parent_fill(node, parents, SUN6I_AHB1_MAX_PARENTS); of_property_read_string(node, "clock-output-names", _name); ahb1 = kzalloc(sizeof(struct sun6i_ahb1_clk), GFP_KERNEL); @@ -790,10 +787,7 @@ static void __init sunxi_mux_clk_setup(struct device_node *node, reg = of_iomap(node, 0); - while (i < SUNXI_MAX_PARENTS && - (parents[i] = of_clk_get_parent_name(node, i)) != NULL) - i++; - + of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS); of_property_read_string(node, "clock-output-names", _name); clk = clk_register_mux(NULL, clk_name, parents, i, -- 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/
[PATCHv2 3/6] clk: keystone: make use of of_clk_parent_fill helper function
From: Dinh Nguyen
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen
Acked-by: Santosh Shilimkar
---
drivers/clk/keystone/pll.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/keystone/pll.c b/drivers/clk/keystone/pll.c
index 4a375ea..d6ef063 100644
--- a/drivers/clk/keystone/pll.c
+++ b/drivers/clk/keystone/pll.c
@@ -309,8 +309,7 @@ static void __init of_pll_mux_clk_init(struct device_node
*node)
return;
}
- parents[0] = of_clk_get_parent_name(node, 0);
- parents[1] = of_clk_get_parent_name(node, 1);
+ of_clk_parent_fill(node, parents, 2);
if (!parents[0] || !parents[1]) {
pr_err("%s: missing parent clocks\n", __func__);
return;
--
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/
[PATCHv2 2/6] clk: qoriq: make use of of_clk_parent_fill helper function
From: Dinh Nguyen Use of_clk_parent_fill to fill in the parent clock names' array. Signed-off-by: Dinh Nguyen --- drivers/clk/clk-qoriq.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c index cda90a9..d3f4570 100644 --- a/drivers/clk/clk-qoriq.c +++ b/drivers/clk/clk-qoriq.c @@ -70,7 +70,7 @@ static void __init core_mux_init(struct device_node *np) struct clk_init_data init; struct cmux_clk *cmux_clk; struct device_node *node; - int rc, count, i; + int rc, count; u32 offset; const char *clk_name; const char **parent_names; @@ -92,8 +92,7 @@ static void __init core_mux_init(struct device_node *np) if (!parent_names) return; - for (i = 0; i < count; i++) - parent_names[i] = of_clk_get_parent_name(np, i); + of_clk_parent_fill(np, parent_names, count); cmux_clk = kzalloc(sizeof(*cmux_clk), GFP_KERNEL); if (!cmux_clk) -- 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] Warnings : Fixed 80 character length warning in rtw_ap.c
On Mon, Jul 06, 2015 at 09:53:26PM -0400, Sreenath Madasu wrote: > When the checkpatch.pl script was run, it showed lines with length > more than 80 characters in rtw_ap.c file. Fixed line number 382 by > breaking it up into two lines within 80 characters. > > Signed-off-by: Sreenath Madasu > --- > drivers/staging/rtl8188eu/core/rtw_ap.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Any reason why you didn't cc: the maintainer of the staging subsystem for this? Please use scripts/get_maintainer to determine who to send stuff to. Also, can you fix up the Subject line to show the subsystem and driver you are modifying? Can you fix that up and resend? 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] x86: Fix detection of GCC -mpreferred-stack-boundary support
On Mon, 2015-07-06 at 10:59 -0700, Andy Lutomirski wrote: > On Mon, Jul 6, 2015 at 10:40 AM, Ingo Molnar wrote: > > > > * Andy Lutomirski wrote: > > > >> > My reasoning: on modern uarchs there's no penalty for 32-bit > >> > misalignment of > >> > 64-bit variables, only if they cross 64-byte cache lines, which should > >> > be rare > >> > with a chance of 1:16. This small penalty (of at most +1 cycle in some > >> > circumstances IIRC) should be more than counterbalanced by the > >> > compression of > >> > the stack by 5% on average. > >> > >> I'll counter with: what's the benefit? There are no operations that will > >> naturally change RSP by anything that isn't a multiple of 8 (there's no > >> pushl in > >> 64-bit mode, or at least not on AMD chips -- the Intel manual is a bit > >> vague on > >> this point), so we'll end up with RSP being a multiple of 8 regardless. > >> Even if > >> we somehow shaved 4 bytes off in asm, that still wouldn't buy us anything, > >> as a > >> dangling 4 bytes at the bottom of the stack isn't useful for anything. > > > > Yeah, so it might be utilized in frame-pointer less builds (which we might > > be able > > to utilize in the future if sane Dwarf code comes around), which does not > > use > > push/pop to manage the stack but often has patterns like: > > > > 8102aa90 : > > 8102aa90: 48 83 ec 18 sub$0x18,%rsp > > > > and uses MOVs to manage the stack. Those kinds of stack frames could be > > 4-byte > > granular as well. > > > > But yeah ... it's pretty marginal. > > To get even that, we'd need an additional ABI-changing GCC flag to > change GCC's idea of the alignment of long from 8 to 4. (I just > checked: g++ thinks that alignof(long) == 8. I was too lazy to look > up how to ask the equivalent question in C.) I just want to point out that long itself is 8 bytes on 64-bit x86, but only 4 bytes on 32-bit x86. Perhaps we should keep in mind sizeof(long) and not just alignof(long)? My opinion btw, is that if long is 8 bytes wide, it should also be 8 bytes aligned. > --Andy > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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/2] staging: wilc1000: Delete unnecessary checks before two function calls
On Sat, Jun 27, 2015 at 04:36:14PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 27 Jun 2015 15:56:57 +0200 Why is this in the body of the email? Please fix your email client or just use git send-email properly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE
On Mon, 2015-07-06 at 15:41 -0400, Josef Bacik wrote: > So the NO_WAKE_WIDE_IDLE results are very good, almost the same as the > baseline with a slight regression at lower RPS and a slight improvement > at high RPS. Good. I can likely drop the rest then (I like dinky, so do CPUs;). I'm not real keen on the feature unless your numbers are really good, and odds are that ain't gonna happen. -Mike -- 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: obdclass: fix macro coding style issue in uuid.c
On Fri, Jun 26, 2015 at 11:04:49PM -0700, Joe Perches wrote:
> On Sat, 2015-06-27 at 06:36 +0100, Vasiliy Korchagin wrote:
> > This patch fixes the checkpatch.pl error:
> >
> > ERROR: Macros with complex values should be enclosed in parentheses
> > +#define CONSUME(val, ptr) (val) = consume(sizeof(val), (ptr))
> >
> > by expanding it as this macro is used only once.
> []
> > Notes:
> > Here is another version with macro expansion. Inline function expansion
> > doesn't
> > seem like a good idea to me as it would make things overcomplicated.
>
> It looks like it'd be simpler to use vsprintf extension %pU
> ---
> drivers/staging/lustre/lustre/obdclass/uuid.c | 34
> +--
> 1 file changed, 1 insertion(+), 33 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/uuid.c
> b/drivers/staging/lustre/lustre/obdclass/uuid.c
> index ff0a01b..b0b0157 100644
> --- a/drivers/staging/lustre/lustre/obdclass/uuid.c
> +++ b/drivers/staging/lustre/lustre/obdclass/uuid.c
> @@ -43,40 +43,8 @@
> #include "../include/obd_support.h"
> #include "../include/obd_class.h"
>
> -
> -static inline __u32 consume(int nob, __u8 **ptr)
> -{
> - __u32 value;
> -
> - LASSERT(nob <= sizeof(value));
> -
> - for (value = 0; nob > 0; --nob)
> - value = (value << 8) | *((*ptr)++);
> - return value;
> -}
> -
> -#define CONSUME(val, ptr) (val) = consume(sizeof(val), (ptr))
> -
> -static void uuid_unpack(class_uuid_t in, __u16 *uu, int nr)
> -{
> - __u8 *ptr = in;
> -
> - LASSERT(nr * sizeof(*uu) == sizeof(class_uuid_t));
> -
> - while (nr-- > 0)
> - CONSUME(uu[nr], );
> -}
> -
> void class_uuid_unparse(class_uuid_t uu, struct obd_uuid *out)
> {
> - /* uu as an array of __u16's */
> - __u16 uuid[sizeof(class_uuid_t) / sizeof(__u16)];
> -
> - CLASSERT(ARRAY_SIZE(uuid) == 8);
> -
> - uuid_unpack(uu, uuid, ARRAY_SIZE(uuid));
> - sprintf(out->uuid, "%04x%04x-%04x-%04x-%04x-%04x%04x%04x",
> - uuid[0], uuid[1], uuid[2], uuid[3],
> - uuid[4], uuid[5], uuid[6], uuid[7]);
> + sprintf(out->uuid, "%pU", uu);
> }
> EXPORT_SYMBOL(class_uuid_unparse);
I agree, much better, can you resend this in a form I can apply?
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 2/2] staging: wilc1000: One function call less in mac_ioctl() after error detection
On Sat, Jun 27, 2015 at 04:37:24PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 27 Jun 2015 16:00:59 +0200 Again, please fix. > > The kfree() function was called in two cases by the mac_ioctl() function > during error handling even if the passed variable did not contain a pointer > for a valid data item. > > * This implementation detail could be improved by the introduction > of another jump label. > > * Drop an unnecessary initialisation for the variable "buff" then. That's a different issue, please fix it in a separate patch. 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 v2] usb: move assignment out of if condition
On Thu, Jul 02, 2015 at 06:23:59PM -0400, Kris Borer wrote: > Fix four occurrences of checkpatch.pl error: > > ERROR: do not use assignment in if condition > > Signed-off-by: Kris Borer > --- > drivers/usb/core/hcd.c | 19 +-- > 1 file changed, 13 insertions(+), 6 deletions(-) Again, please use Coccinelle for something like this, otherwise I'm not going to trust that it is correct :) 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] dmaengine: pl330: Really fix choppy sound because of wrong residue calculation
On Mon, Jun 15, 2015 at 11:00:09PM +0900, Krzysztof Kozlowski wrote: > When pl330 driver was used during sound playback, after some time or > after a number of plays the sound became choppy or totally noisy. For > example on Odroid XU3 board the first four executions of aplay with > small WAVE worked fine, but fifth was unrecognizable with errors: > $ aplay /usr/share/sounds/alsa/Front_Right.wava > underrun!!! (at least 0.095 ms long) > > Issue was caused by wrong residue reported by pl330 driver to > pcm_dmaengine for its cyclic dma transfers. > > The pl330_tx_status(), residue reporting function, used a "last" flag in > a descriptor to indicate that there is no more data to send. > > The pl330_tx_submit() iterated over descriptors trying to remove this > flag from them and then mark last descriptor as "last". However when > iterating it actually removed the flag not from descriptors but always > from last of it (and then reset it). Thus effectively once some > descriptor was marked as last, then it stayed like this forever causing > residue to be reported too low. Applied, thanks -- ~Vinod -- 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 7/8] xtensa: implement counting and sampling perf events
Hi Max,
We could probably still use NMI with a separate stack. However, for
exception handling while in NMI, we might have to implement something
similar to x86_64 (https://lwn.net/Articles/484932/).
Cheers!
-Chris
On Mon, Jul 6, 2015 at 7:22 AM, Max Filippov wrote:
> On Mon, Jul 6, 2015 at 5:05 PM, Peter Zijlstra wrote:
>> On Mon, Jul 06, 2015 at 04:56:09PM +0300, Max Filippov wrote:
>>> On Mon, Jul 6, 2015 at 4:47 PM, Peter Zijlstra wrote:
>>> > On Mon, Jul 06, 2015 at 04:32:48PM +0300, Max Filippov wrote:
>>> >> +static int __init xtensa_pmu_init(void)
>>> >> +{
>>> >> + int ret;
>>> >> + int irq = irq_create_mapping(NULL, XCHAL_PROFILING_INTERRUPT);
>>> >
>>> > Does this platform have interrupt priorities which you can partially
>>> > mask in order to create NMI like behaviour?
>>>
>>> Not sure what you mean by "NMI like".
>>
>> There's a number of archs where we implement NMIs by having
>> local_irq_disable() only disable part of the interrupt priority range
>> and making sure all 'normal' IRQs are mapped in that priority range.
>>
>> We then map our NMI handlers to a priority above the 'normal' range,
>> such that these interrupts can indeed happen when interrupts are
>> 'disabled.
>>
>> See for example:
>>
>> b4f4372f96e0 ("sparc64: Make %pil level 15 a pseudo-NMI.")
>> 0c25e9e6cbe7 ("sparc64: Adjust __raw_local_irq_save() to cooperate in NMIs.")
>> c011f80ba091 ("sparc64: Add some more commentary to __raw_local_irq_save()")
>
> Ok, I see. I guess I can change IRQ disabling logic to not mask perf IRQ
> in case it's configured as the only interrupt on its level and it's the
> highest
> medium-level IRQ.
>
>>> Interrupt priorities are fixed in the current xtensa architecture, and
>>> we can in theory mask certain level and below, but practically we
>>> always mask all low- and medium- level interrupts.
>>>
>>> Also we currently can't have handlers for high priority interrupts written
>>> in C.
>>
>> Why not? Surely this can be cured with an assembly stub?
>
> IIUC that was a deliberate architecture design choice and working around
> it penalizes all interrupt handlers. But let me take another close look.
>
>> The advantage of having NMIs is that profiling information for the
>> kernel becomes much more useful. Without this local_irq_enable() will be
>> a very 'hot' function.
>
> I haven't noticed that in my testing.
>
> --
> Thanks.
> -- Max
--
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/
[RESEND][PATCH v2] arm64:Modify the dump mem for 64 bit addresses
From: Rohit Thapliyal
V1 = added new function dump_mem64
v1->v2
Removed the separate function dump_mem64 and accommodated
a field width based on which the dump shall be created of
width either 4 or 8 as suggested by Catalin.
On 64bit kernel, the dump_mem gives 32 bit addresses
on the stack dump. This gives unorganized information regarding
the 64bit values on the stack. Hence, modified to get a complete
64bit memory dump.
With patch:
[ 93.534801] Process insmod (pid: 1587, stack limit = 0xffc976be4058)
[ 93.541441] Stack: (0xffc976be7cf0 to 0xffc976be8000)
[ 93.547136] 7ce0: ffc976be7d00
ffc8163c
[ 93.554898] 7d00: ffc976be7d40 ffcf8a44 ffc00098ef38
ffbffc88
[ 93.562659] 7d20: ffc00098ef50 ffbffcc0 0001
ffbffc70
[ 93.570419] 7d40: ffc976be7e40 ffcf935c
2b424090
[ 93.578179] 7d60: 2b424010 007facc555f4 8000
0015
[ 93.585937] 7d80: 0116 0069 ffc00097b000
ffc976be4000
[ 93.593694] 7da0: 0064 0072 006e
003f
[ 93.601453] 7dc0: feff fff1 ffbffc002028
0124
[ 93.609211] 7de0: ffc976be7e10 0001 ff80
ffbb
[ 93.616969] 7e00: ffc976be7e60
[ 93.624726] 7e20:
[ 93.632484] 7e40: 007fcc474550 ffc841ec 2b424010
007facda0710
[ 93.640241] 7e60: ffcbe6dc ff80007d2000
0001c010
[ 93.647999] 7e80: ff80007e0ae0 ff80007e09d0 ff80007edf70
0288
[ 93.655757] 7ea0: 02e8
001c001b
[ 93.663514] 7ec0: 0009 0007 2b424090
0001c010
[ 93.671272] 7ee0: 2b424010 007faccd3a48
[ 93.679030] 7f00: 007fcc4743f8 007fcc4743f8 0069
0003
[ 93.686787] 7f20: 0101010101010101 0004 0020
03f3
[ 93.694544] 7f40: 007facb95664 007facda7030 007facc555d0
00498378
[ 93.702301] 7f60: 2b424010 007facda0710
2b424090
[ 93.710058] 7f80: 007fcc474698 00498000 007fcc474ebb
00474f58
[ 93.717815] 7fa0: 00498000
007fcc474550
[ 93.725573] 7fc0: 004104bc 007fcc474430 007facc555f4
8000
[ 93.70] 7fe0: 2b424090 0069 0950020128000244
41040804
[ 93.741084] Call trace:
The above output makes a debugger life a lot more easier.
Signed-off-by: Rohit Thapliyal
Signed-off-by: Maninder Singh
Reviewed-by: Akhilesh kumar
---
arch/arm64/kernel/traps.c | 44 +---
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 1ef2940..53d57db 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -51,8 +51,9 @@ int show_unhandled_signals = 1;
/*
* Dump out the contents of some memory nicely...
*/
+
static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
-unsigned long top)
+unsigned long top, unsigned int width)
{
unsigned long first;
mm_segment_t fs;
@@ -70,18 +71,27 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
for (first = bottom & ~31; first < top; first += 32) {
unsigned long p;
- char str[sizeof(" 12345678") * 8 + 1];
+ char str[sizeof(" 1234567812345678") * 8 + 1];
memset(str, ' ', sizeof(str));
str[sizeof(str) - 1] = '\0';
- for (p = first, i = 0; i < 8 && p < top; i++, p += 4) {
+ for (p = first, i = 0; i < (width > 4 ? width-4 : width+4)
+ && p < top; i++, p += width) {
if (p >= bottom && p < top) {
- unsigned int val;
- if (__get_user(val, (unsigned int *)p) == 0)
- sprintf(str + i * 9, " %08x", val);
- else
- sprintf(str + i * 9, " ");
+ unsigned long val;
+
+ if (width == 8) {
+ if (__get_user(val, (unsigned long *)p)
== 0)
+ sprintf(str + i * 17, "
%016lx", val);
+ else
+
Re: [PATCH] dmaengine: pl330: Fix overflow when reporting residue in memcpy
On Mon, Jun 15, 2015 at 05:25:16PM +0900, Krzysztof Kozlowski wrote: > During memcpy operations the residue was always set to an u32 overflowed > value. > > In pl330_tx_status() function number of currently transferred bytes was > subtracted from internal "bytes_requested" field. However this > "bytes_requested" was not initialized at start to length of memcpy > buffer so transferred bytes were subtracted from 0 causing overflow. Applied, thanks -- ~Vinod -- 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: perf, kprobes: fuzzer generates huge number of WARNings
On Tue, 7 Jul 2015, Masami Hiramatsu wrote: > On 2015/07/07 6:27, Vince Weaver wrote: > > Hello > > > > I've been working on trying to get the perf_fuzzer to start fuzzing the > > PERF_EVENT_IOC_SET_BPF so I've added some really hackish kprobe support. > > > > However before I can get to the BPF testing the kprobe code generates a > > constant stream of WARNINGS which make the machine more or less useless > > until I stop it. I've included a small selection here. > > > > Is this expected? > > Did you get same message without BPF hack? And also, could you tell us > your kernel version and configuration? It's a Hawell machine running 4.2-rc1. I can post the .config if it's of interest. Well the BPF hack is in the fuzzer, not the kernel. And it's not really a hack, it just turned out to be a huge pain to figure out how to manually create a valid BPF program in conjunction with a valid kprobe event. I did have to sprinkle printks in the kprobe and bpf code to find out where various EINVAL returns were coming from, so potentially this is just a problem of printks happening where they shouldn't. I'll remove those changes and try to reproduce this tomorrow. This is possibly a long standing issue, until now I never ran the fuzzer as root so these particular code paths weren't tested. Vince -- 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: perf, kprobes: fuzzer generates huge number of WARNings
On Mon, 6 Jul 2015, Steven Rostedt wrote: > On Mon, 6 Jul 2015 17:27:04 -0400 (EDT) > Vince Weaver wrote: > > [ 3521.650521] ---[ end trace a413501925547ed5 ]--- > > [ 3521.655960] ftrace failed to modify [] > > handle_mm_fault+0x0/0x1750 > > [ 3521.664767] actual: e8:cb:18:ef:1e > > Hmm, it was not expecting to see this address above in the mcount slot. > Did you have other tracing going on, or did you add a kprobe to > handle_mm_fault too? it's fuzzing so there were potentially a large number of tracepoint events active at the time. Only one kprobe event, p:probe/VMW _text+1664816 and I forget what that actually mapped to originally. Vince -- 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 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Mon, Jul 6, 2015 at 7:00 PM, Andrew Lunn wrote:
> On Tue, Jul 07, 2015 at 01:38:04AM +0200, Andrew Lunn wrote:
>> On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote:
>> > Hi all,
>> >
>> > This patchset brings full support for hardware VLANs in DSA, and the
>> > Marvell
>> > 88E6xxx compatible switch chips.
>>
>> Hi Vivien
>>
>> I just booted these patches on my board, and i'm getting WARNINGS:
>>
>> [ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265
>> switchdev_port_obj_add+0xd4/0xdc()
>
> Hi Vivien
>
> I debugged this a bit.
>
> The problem comes from:
>
> static int dsa_slave_port_obj_add(struct net_device *dev,
> struct switchdev_obj *obj)
> {
> int err;
>
> /*
> * Skip the prepare phase, since currently the DSA drivers don't need
> to
> * allocate any memory for operations and they will not fail to HW
> * (unless something horrible goes wrong on the MDIO bus, in which
> case
> * the prepare phase wouldn't have been able to predict anyway).
> */
> if (obj->trans != SWITCHDEV_TRANS_COMMIT)
> return 0;
>
> switch (obj->id) {
> case SWITCHDEV_OBJ_PORT_VLAN:
> err = dsa_slave_port_vlans_add(dev, obj);
> break;
> default:
> err = -EOPNOTSUPP;
> break;
> }
>
> return err;
> }
>
> It is being called with obj->id of 2, which is
> SWITCHDEV_OBJ_IPV4_FIB. This function is called twice. The first time
> it is with SWITCHDEV_TRANS_PREPARE and we are allowed to return an
> error. The second time, with SWITCHDEV_TRANS_COMMIT, errors are not
> allowed.
>
> EOPNOTSUPP is considered an error, so since we don't support
> SWITCHDEV_OBJ_IPV4_FIB we error out the COMMIT phase.
>
> Not sure which is cleaner. Test to see if we support the object during
> the prepare, or allow the commit to accept EOPNOTSUPP as not being an
> error?
I think we should return EOPNOTSUPP on PREPARE, so move the trans !=
COMMIT test inside the case for PORT_VLAN. That would future-proof
the func when new objects are added to switchdev (and not supported by
dsa_slave).
Does that sound OK?
-scott
--
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] perf tools: Allow passing perf's own pid to '--filter'
This patch allows passing perf's own PID to '--filter' by using
'$PERFPID'. This should be useful when system-widely capturing
tracepoints events.
Before this patch, when doing something like:
# perf record -a -e syscalls:sys_enter_write
One could easily get result like this:
# perf report --stdio
...
# Overhead Command Shared Object Symbol
# ... ..
#
99.99% perf libpthread-2.18.so [.] __write_nocancel
0.01% ls libc-2.18.so[.] write
0.01% sshd libc-2.18.so[.] write
...
Where most events are generated by perf itself.
A shell trick can be done to filter perf itself out:
# cat << EOF > ./tmp
> #!/bin/sh
> exec perf record -e ... --filter="common_pid != \$\$" -a sleep 10
> EOF
# chmod a+x ./tmp
# ./tmp
However, doing so is user unfriendly.
This patch introduces '$PERFPID' placeholder to perf's filter. Now
user is allowed to do the above work with:
# perf record -e ... --filter='common_pid != $PERFPID' -a sleep 10
This patch adds the variable replacement code to perf_evsel__apply_filter(),
before PERF_EVENT_IOC_SET_FILTER ioctl, so not only 'perf record', all
subcommands which uses filter can utilize $PERFPID.
Andi Kleen sent a similar patch at 2014, but wasn't applied, the
reason is not clear.
Signed-off-by: Wang Nan
---
This patch is based on Arnaldo Carvalho de Melo's git tree:
https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/commit/?h=perf/core
---
tools/perf/Documentation/perf-record.txt | 5 +-
tools/perf/util/evsel.c | 110 ++-
2 files changed, 111 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 9b9d9d0..9c67482 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -61,7 +61,10 @@ OPTIONS
"perf report" to view group events together.
--filter=::
-Event filter.
+Event filter. $PERFPID is allowed to be used to represent perf's own
pid.
+Note that '$' has special meaning for shell. Don't forget to use ''
+quotation marks or to use '\' to escape when using '$PERFPID' in
command
+line.
-a::
--all-cpus::
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 83c0803..7f2a1a5 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -816,12 +816,116 @@ static int perf_evsel__run_ioctl(struct perf_evsel
*evsel, int ncpus, int nthrea
return 0;
}
+static int
+perf_evsel__append_filter_token(const char *key, char *new_filter,
+ ssize_t *pspace)
+{
+ if (strcmp(key, "PERFPID") == 0) {
+ char pid_buf[32];
+ pid_t self_pid = getpid();
+
+ snprintf(pid_buf, sizeof(pid_buf), "%d", self_pid);
+ strncat(new_filter, pid_buf, *pspace);
+ *pspace -= strlen(pid_buf);
+ if (*pspace < 0)
+ return -1;
+ return 0;
+ }
+
+ return -1;
+}
+
+static const char *
+perf_evsel__postproc_filter(const char *filter)
+{
+ char *dollar = NULL, *sep = NULL, *p;
+ char *old_filter = NULL, *new_filter = NULL;
+ ssize_t space;
+
+ if (!filter)
+ return NULL;
+
+ dollar = strchr(filter, '$');
+ if (!dollar)
+ return filter;
+
+ p = old_filter = strdup(filter);
+ if (!old_filter) {
+ pr_warning("Can't alloc memory when postprocing filter '%s'\n",
+ filter);
+ return filter;
+ }
+
+ dollar = old_filter + (dollar - filter);
+
+ /*
+* See perf_event_set_filter(). Length of a valid filter is
+* limited by page_size.
+*/
+ new_filter = malloc(page_size);
+ if (!new_filter) {
+ pr_warning("Can't alloc memory when postprocing filter '%s'\n",
+ filter);
+ goto errout;
+ }
+
+ *new_filter = '\0';
+ space = page_size - 1;
+
+ while (1) {
+ if (dollar)
+ *dollar = '\0';
+ strncat(new_filter, p, space);
+ space -= strlen(p);
+ if (space < 0)
+ goto errout;
+ if (!dollar)
+ break;
+
+ sep = strchr(dollar + 1, ' ');
+ if (sep)
+ *sep = '\0';
+
+ if (perf_evsel__append_filter_token(dollar + 1, new_filter,
+ )) {
+ pr_warning("Filter become too long: '%s'\n", filter);
+ goto errout;
+ }
+
+ if (!sep)
+ break;
+
+ p = sep;
+ *p = ' ';
+
[PATCH 2/6] xen/x86: Remove unnecessary memset() call
Since ctxt is kzalloc'd there is no need to call a memset for
ctxt->fpu_ctxt.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/smp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index ca7ee1f..7cf0765 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -377,7 +377,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct
*idle)
ctxt->user_regs.fs = __KERNEL_PERCPU;
ctxt->user_regs.gs = __KERNEL_STACK_CANARY;
#endif
- memset(>fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
--
1.8.1.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/
[PATCH 6/6] xen/x86/pvh: Allow building 32-bit PVH guests
Signed-off-by: Boris Ostrovsky --- arch/x86/xen/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index e88fda8..891031e 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -48,5 +48,5 @@ config XEN_DEBUG_FS config XEN_PVH bool "Support for running as a PVH guest" - depends on X86_64 && XEN && XEN_PVHVM + depends on XEN && XEN_PVHVM def_bool n -- 1.8.1.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/
[PATCH 1/6] xen/x86/pvh: Save %rbx in xen_pvh_early_cpu_init()
x86-64 ABI requires that functions preserve %rbx. When
xen_pvh_early_cpu_init() is executed on boot cpu it is invoked as a
function and 'cpuid' instruction will clobber %rbx. (This is not a
concern on secondary processors since there xen_pvh_early_cpu_init() is
the entry point and thus does not need to preserve registers.)
Since we cannot access stack on secondary processors (PTE's NX bit will
cause #GP on AMD --- see commit a2ef5dc2c7cb ("x86/xen: Set EFER.NX and
EFER.SCE in PVH guests")) we can't always save %rbx on the stack. We
work around this by creating a new entry point for those processors ---
xen_pvh_early_cpu_init_secondary(). Note that on secondary CPUs we will
load %rbx with garbage, which is OK.
As a side effect of these changes we don't need to save %rsi anymore,
since we can use %rbx instead of %rsi as a temporary register.
(We could store %rbx into another scratch register such as %r8 but since
we will need new entry point for 32-bit PVH anyway we go with this
approach for symmetry)
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/smp.c | 3 ++-
arch/x86/xen/smp.h | 4
arch/x86/xen/xen-head.S | 14 +++---
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 8648438..ca7ee1f 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -423,7 +423,8 @@ cpu_initialize_context(unsigned int cpu, struct task_struct
*idle)
* bit set. This means before DS/SS is touched, NX in
* EFER must be set. Hence the following assembly glue code.
*/
- ctxt->user_regs.eip = (unsigned long)xen_pvh_early_cpu_init;
+ ctxt->user_regs.eip =
+ (unsigned long)xen_pvh_early_cpu_init_secondary;
ctxt->user_regs.rdi = cpu;
ctxt->user_regs.rsi = true; /* entry == true */
}
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index 963d62a..bf2b43c 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -10,10 +10,14 @@ extern void xen_send_IPI_self(int vector);
#ifdef CONFIG_XEN_PVH
extern void xen_pvh_early_cpu_init(int cpu, bool entry);
+extern void xen_pvh_early_cpu_init_secondary(int cpu, bool entry);
#else
static inline void xen_pvh_early_cpu_init(int cpu, bool entry)
{
}
+static inline void xen_pvh_early_cpu_init_secondary(int cpu, bool entry)
+{
+}
#endif
#endif
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 8afdfcc..b1508a8 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -56,28 +56,28 @@ ENTRY(startup_xen)
* @entry: true if this is a secondary vcpu coming up on this entry
* point, false if this is the boot CPU being initialized for
* the first time (%rsi)
- *
- * Note: This is called as a function on the boot CPU, and is the entry point
- * on the secondary CPU.
*/
ENTRY(xen_pvh_early_cpu_init)
- mov %rsi, %r11
+ mov %rbx, -8(%rsp)
+/* Entry point for secondary CPUs */
+ENTRY(xen_pvh_early_cpu_init_secondary)
/* Gather features to see if NX implemented. */
mov $0x8001, %eax
cpuid
- mov %edx, %esi
+ mov %edx, %ebx
mov $MSR_EFER, %ecx
rdmsr
bts $_EFER_SCE, %eax
- bt $20, %esi
+ bt $20, %ebx
jnc 1f /* No NX, skip setting it */
bts $_EFER_NX, %eax
1: wrmsr
+ mov -8(%rsp), %rbx
#ifdef CONFIG_SMP
- cmp $0, %r11b
+ cmp $0, %esi
jne cpu_bringup_and_idle
#endif
ret
--
1.8.1.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/
[PATCH 0/6] 32-bit PVH domU support
A set of PVH-related patches. The first patch is x86-64 ABI fix for PVH guests. The second is a small update that removes redundant memset (both on PV and PVH code paths) The rest is to enable non-privileged 32-bit PVH guests. This requires hypervisor patches from http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg04817.html Boris Ostrovsky (6): xen/x86/pvh: Save %rbx in xen_pvh_early_cpu_init() xen/x86: Remove unnecessary memset() call xen/x86/pvh: Properly set page tables for 32-bit PVH guests xen/x86/pvh: Set up descriptors for 32-bit PVH guests xen/x86/pvh: Add 32-bit PVH initialization code xen/x86/pvh: Allow building 32-bit PVH guests arch/x86/xen/Kconfig | 2 +- arch/x86/xen/enlighten.c | 20 arch/x86/xen/mmu.c | 22 +- arch/x86/xen/smp.c | 21 - arch/x86/xen/smp.h | 4 arch/x86/xen/xen-head.S | 29 + 6 files changed, 63 insertions(+), 35 deletions(-) -- 1.8.1.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/
[PATCH 4/6] xen/x86/pvh: Set up descriptors for 32-bit PVH guests
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0b95c9b..7953e68 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1362,12 +1362,12 @@ static void __init xen_boot_params_init_edd(void)
static void __ref xen_setup_gdt(int cpu)
{
if (xen_feature(XENFEAT_auto_translated_physmap)) {
-#ifdef CONFIG_X86_64
unsigned long dummy;
- load_percpu_segment(cpu); /* We need to access per-cpu area */
+ setup_stack_canary_segment(cpu);
switch_to_new_gdt(cpu); /* GDT and GS set */
+#ifdef CONFIG_X86_64
/* We are switching of the Xen provided GDT to our HVM mode
* GDT. The new GDT has __KERNEL_CS with CS.L = 1
* and we are jumping to reload it.
@@ -1392,8 +1392,16 @@ static void __ref xen_setup_gdt(int cpu)
loadsegment(ds, 0);
loadsegment(fs, 0);
#else
- /* PVH: TODO Implement. */
- BUG();
+ asm volatile ("ljmp %1,$1f\n"
+ "1:\n"
+ "movl %2,%0\n"
+ "movl %0,%%ss\n"
+ "movl %3,%0\n"
+ "movl %0,%%ds\n"
+ "movl %0,%%es\n"
+ : "=" (dummy)
+ : "i" (__KERNEL_CS), "i" (__KERNEL_DS),
+ "i" (__USER_DS));
#endif
return; /* PVH does not need any PV GDT ops. */
}
--
1.8.1.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/
[PATCH 3/6] xen/x86/pvh: Properly set page tables for 32-bit PVH guests
32-bit PVH guests don't want to write-protect/pin page tables.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/mmu.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index dd151b2..b473df8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1762,8 +1762,9 @@ void __init xen_setup_machphys_mapping(void)
machine_to_phys_nr = MACH2PHYS_NR_ENTRIES;
}
#ifdef CONFIG_X86_32
- WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1))
- < machine_to_phys_mapping);
+ if (!xen_feature(XENFEAT_auto_translated_physmap))
+ WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1))
+ < machine_to_phys_mapping);
#endif
}
@@ -1958,15 +1959,18 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
initial_page_table[KERNEL_PGD_BOUNDARY] =
__pgd(__pa(initial_kernel_pmd) | _PAGE_PRESENT);
- set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO);
- set_page_prot(initial_page_table, PAGE_KERNEL_RO);
- set_page_prot(empty_zero_page, PAGE_KERNEL_RO);
+ if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO);
+ set_page_prot(initial_page_table, PAGE_KERNEL_RO);
+ set_page_prot(empty_zero_page, PAGE_KERNEL_RO);
- pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
+ pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
- pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE,
- PFN_DOWN(__pa(initial_page_table)));
- xen_write_cr3(__pa(initial_page_table));
+ pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE,
+ PFN_DOWN(__pa(initial_page_table)));
+ xen_write_cr3(__pa(initial_page_table));
+ } else
+ native_write_cr3(__pa(initial_page_table));
memblock_reserve(__pa(xen_start_info->pt_base),
xen_start_info->nr_pt_frames * PAGE_SIZE);
--
1.8.1.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/
[PATCH 5/6] xen/x86/pvh: Add 32-bit PVH initialization code
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 4
arch/x86/xen/smp.c | 17 ++---
arch/x86/xen/xen-head.S | 17 +++--
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 7953e68..807337e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1464,10 +1464,6 @@ static void __init xen_pvh_early_guest_init(void)
xen_pvh_early_cpu_init(0, false);
xen_pvh_set_cr_flags(0);
-
-#ifdef CONFIG_X86_32
- BUG(); /* PVH: Implement proper support. */
-#endif
}
#endif/* CONFIG_XEN_PVH */
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 7cf0765..99be53b 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -372,11 +372,8 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle)
gdt = get_cpu_gdt_table(cpu);
-#ifdef CONFIG_X86_32
- /* Note: PVH is not yet supported on x86_32. */
- ctxt->user_regs.fs = __KERNEL_PERCPU;
- ctxt->user_regs.gs = __KERNEL_STACK_CANARY;
-#endif
+ ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+ ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
@@ -403,6 +400,8 @@ cpu_initialize_context(unsigned int cpu, struct task_struct
*idle)
ctxt->kernel_sp = idle->thread.sp0;
#ifdef CONFIG_X86_32
+ ctxt->user_regs.fs = __KERNEL_PERCPU;
+ ctxt->user_regs.gs = __KERNEL_STACK_CANARY;
ctxt->event_callback_cs = __KERNEL_CS;
ctxt->failsafe_callback_cs = __KERNEL_CS;
#else
@@ -424,12 +423,16 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle)
*/
ctxt->user_regs.eip =
(unsigned long)xen_pvh_early_cpu_init_secondary;
+#ifdef CONFIG_X86_64
ctxt->user_regs.rdi = cpu;
ctxt->user_regs.rsi = true; /* entry == true */
+#else
+ *((uint32_t *)ctxt->user_regs.esp + 1) = cpu;
+ *((uint32_t *)ctxt->user_regs.esp + 2) = true;
+#endif
}
#endif
- ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
- ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
+
if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
BUG();
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index b1508a8..12c4e2a 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -51,14 +51,18 @@ ENTRY(startup_xen)
#ifdef CONFIG_XEN_PVH
/*
- * xen_pvh_early_cpu_init() - early PVH VCPU initialization
+ * xen_pvh_early_cpu_init(cpu, entry) - early PVH VCPU initialization
* @cpu: this cpu number (%rdi)
* @entry: true if this is a secondary vcpu coming up on this entry
* point, false if this is the boot CPU being initialized for
* the first time (%rsi)
*/
ENTRY(xen_pvh_early_cpu_init)
+#ifdef CONFIG_X86_64
mov %rbx, -8(%rsp)
+#else
+ mov %ebx, -4(%esp)
+#endif
/* Entry point for secondary CPUs */
ENTRY(xen_pvh_early_cpu_init_secondary)
@@ -69,15 +73,24 @@ ENTRY(xen_pvh_early_cpu_init_secondary)
mov $MSR_EFER, %ecx
rdmsr
+#ifdef CONFIG_X86_64
bts $_EFER_SCE, %eax
+#endif
bt $20, %ebx
jnc 1f /* No NX, skip setting it */
bts $_EFER_NX, %eax
1: wrmsr
+
+#ifdef CONFIG_X86_64
mov -8(%rsp), %rbx
-#ifdef CONFIG_SMP
cmp $0, %esi
+#else
+ mov -4(%esp), %ebx
+ cmp $0, 8(%esp) /* second argument */
+#endif
+
+#ifdef CONFIG_SMP
jne cpu_bringup_and_idle
#endif
ret
--
1.8.1.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/
[PATCH 1/1] regmap: add fast_io_disable_irq property for regmap_config
(please ignore the last email which contain HTML format and was rejected, sorry
for the inconvenience caused)
This patch aims to fix an issue when using the regmap function in different
drivers.
I describe the issue here:
We want to use the the same regmap handler to access the same hardware module
using syscon interface in different drivers.
Some driver will read the register in interrupt handler to get the hardware
information while other drivers will access some other registers by regmap at
the same time, so there will be a synchronization issue because the
spin_lock/spin_unlock is used in regmap_read/regmap_write. a dead lock maybe
happen on the current CPU.
This patch adds a property named fast_io_disable_irq and when this property is
set to true the spin_lock_irqsave/spin_lockirqrestore lock function will be
used in regmap_read/regmap_write to disable the local IRQ when accessing the
register to avoid the lock issue.
Change-Id: I07424191f3ab65d3f89bfee81fe2b4422cf84e74
Signed-off-by: Xuewen Zhou
---
drivers/base/regmap/internal.h | 1 +
drivers/base/regmap/regmap.c | 18 +-
include/linux/regmap.h | 1 +
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 5a22bd3..6a66e6b 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -54,6 +54,7 @@ struct regmap {
regmap_lock lock;
regmap_unlock unlock;
void *lock_arg; /* This is passed to lock/unlock functions */
+ unsigned long flags;
struct device *dev; /* Device we do I/O on */
void *work_buf; /* Scratch buffer used to format I/O */
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 58cfb32..b9b188e 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -297,6 +297,18 @@ static void regmap_unlock_spinlock(void *__map)
spin_unlock(>spinlock);
}
+static void regmap_lock_spinlock_irqsave(void *__map)
+{
+ struct regmap *map = __map;
+ spin_lock_irqsave(>spinlock, map->flags);
+}
+
+static void regmap_unlock_spinlock_irqrestore(void *__map)
+{
+ struct regmap *map = __map;
+ spin_unlock_irqrestore(>spinlock, map->flags);
+}
+
static void dev_get_regmap_release(struct device *dev, void *res)
{
/*
@@ -403,7 +415,11 @@ struct regmap *regmap_init(struct device *dev,
map->unlock = config->unlock;
map->lock_arg = config->lock_arg;
} else {
- if ((bus && bus->fast_io) ||
+ if (config->fast_io_disable_irq) {
+ spin_lock_init(>spinlock);
+ map->lock = regmap_lock_spinlock_irqsave;
+ map->unlock = regmap_unlock_spinlock_irqrestore;
+ } else if ((bus && bus->fast_io) ||
config->fast_io) {
spin_lock_init(>spinlock);
map->lock = regmap_lock_spinlock;
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index bf77dfd..ca3c637 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -193,6 +193,7 @@ struct regmap_config {
int (*reg_write)(void *context, unsigned int reg, unsigned int val);
bool fast_io;
+ bool fast_io_disable_irq;
unsigned int max_register;
const struct regmap_access_table *wr_table;
--
Best regards,
Xuewen Zhou From fcac70930f1a8e48795585234335aef92797e296 Mon Sep 17 00:00:00 2001
From: Xuewen Zhou
Date: Thu, 2 Jul 2015 15:50:36 +0800
Subject: [PATCH] regmap: add fast_io_disable_irq property for regmap_config
different drivers can share the same regmap handler to access the same
hardware module registers by syscon or other mechanism.
there will be a synchronization issue if one of the driver access the
register in interrupt handler because the spin_lock maybe has been hold
by other regsiter access using the same regmap handler and it will cause
a dead lock.
when fast_io_disable_irq is set to true, the regmap_read/reagmap_write
will use spin_lock_irqsave/spin_lockirqrestore to do the syncrhonization
to avoid the lock issue.
Change-Id: I07424191f3ab65d3f89bfee81fe2b4422cf84e74
Signed-off-by: Xuewen Zhou
---
drivers/base/regmap/internal.h | 1 +
drivers/base/regmap/regmap.c | 18 +-
include/linux/regmap.h | 1 +
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 5a22bd3..6a66e6b 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -54,6 +54,7 @@ struct regmap {
regmap_lock lock;
regmap_unlock unlock;
void *lock_arg; /* This is passed to lock/unlock functions */
+ unsigned long flags;
struct device *dev; /* Device we do I/O on */
void *work_buf; /* Scratch buffer used to format I/O */
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 58cfb32..b9b188e 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -297,6 +297,18 @@ static void regmap_unlock_spinlock(void *__map)
spin_unlock(>spinlock);
}
+static void regmap_lock_spinlock_irqsave(void *__map)
+{
+
Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails
Hi, On Tue, Jul 07, 2015 at 02:10:26AM +, John Youn wrote: > On 7/1/2015 8:00 PM, Felipe Balbi wrote: > > On Thu, Jul 02, 2015 at 02:03:14AM +, John Youn wrote: > >> On 6/29/2015 2:48 PM, Felipe Balbi wrote: > >>> Hi again, > >>> > >>> On Mon, Jun 29, 2015 at 04:47:01PM -0500, Felipe Balbi wrote: > On Thu, May 21, 2015 at 03:46:48PM +0530, Subbaraya Sundeep Bhatta wrote: > > We need to return error to caller if command is not sent to > > controller succesfully. > > > > Signed-off-by: Subbaraya Sundeep Bhatta > > Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) > > Cc: > > --- > > v2 changes: > > Added Fixes and Cc in commit message. > > I noticed that this breaks at least my AM437x silicon with DWC3 2.40a > when used with g_zero and testusb. As of now, it could be that silicon > is mis-behaving because I got a Transfer Complete before the failing Set > Endpoint Transfer Resource command. > > In any case, can you run on your setup with g_zero and test.sh/testusb > [1]/[2] just to verify that it really works for you ? > > Meanwhile, I'll continue testing on my end. > > cheers > > [1] > https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:testusb.c > [2] > https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:test.sh > >>> > >>> Adding John here. John, any chance you could fire up dwc3 on HAPS and > >>> see wether it works or fails for you ? > >>> > >>> cheers > >>> > >> > >> Hi Felipe, > >> > >> Just an update on this. > >> > >> I'm trying to get this working with our latest IP with dwc3 from your > >> testing/next branch. It fails the usbtest with a problem unrelated to > >> this patch. > >> > >> It passes on 4.1.1. > >> > >> I'll have to look into the failure but I won't get to it until next > >> week as I'm off the rest of this week. > > > > interesting... If you could post failure signature, I can help looking > > at it, but I guess it's too late to ask :-) > > > > thanks for helping though > > > > > Hi Felipe, > > Nevermind about my issue, it ended up being a setup-related > problem. > > I actually do see the same error as you due to this series of > patches. Except I see it happening before even the first > iteration. I get a completion status of 1 for the Set Endpoint > Transfer Resources command. I'm not sure why this is. > > I don't see any conflict with any previous Transfer Complete. > > I will have to consult with some hardware engineers tomorrow to > look into it further. cool, thanks. Just let me know if it ends up being something larger, then we can revert that commit for the time being until we come to a conclusion. Thanks a lot for helping with testing. > The trace is attached. thanks a lot :-) Do you mind letting me know which version are you using? 3.00a ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] arm64: dts: mt8173-evb: Add PMIC support
On Mon, 2015-07-06 at 18:39 +0200, Matthias Brugger wrote:
> On Monday, July 06, 2015 03:43:57 PM Eddie Huang wrote:
> > On Mon, 2015-06-22 at 21:19 +0800, Henry Chen wrote:
> > > From: Eddie Huang
> > >
[...]
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > > b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts index 43d5401..b967914
> > > 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > > @@ -33,6 +33,180 @@
> > >
> > > chosen { };
> > >
> > > };
> > >
> > > + {
> > > + pmic: mt6397 {
> > > + compatible = "mediatek,mt6397";
> > > + interrupt-parent = <>;
> > > + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <2>;
> > > +
> > > + mt6397regulator: mt6397regulator {
> > > + compatible = "mediatek,mt6397-regulator";
> > > + mt6397_vpca15_reg: buck_vpca15 {
> > > + regulator-compatible = "buck_vpca15";
> > > + regulator-name = "vpca15";
> > > + regulator-min-microvolt = < 70>;
> > > + regulator-max-microvolt = <135>;
> > > + regulator-ramp-delay = <12500>;
> > > + regulator-always-on;
> >
> > I see you pull da9211 regulator dts patch, but not this one. How about
> > this patch ?
>
> I inserted some new-lines and added it to v4.2-next/arm64
>
Thanks the pull. Normally we put alias node in alphabetical order, make
later merge more easily. I think you can do the modification and squeeze
into the same commit.
Thanks
Eddie
--
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 Jul 7
Hi all, Now that -rc1 is out, please clean up your trees if necessary. Changes since 20150706: My fixes tree contains: Merge branch 'perf-urgent-for-linus' of ../../tip The device-mapper tree lost its build failure. Non-merge commits (relative to Linus' tree): 676 725 files changed, 51320 insertions(+), 11448 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, a multi_v7_defconfig for arm and a native build of tools/perf. 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 221 trees (counting Linus' and 31 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 (1c4c7159ed24 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging fixes/master (a7142cb42468 Merge branch 'perf-urgent-for-linus' of ../../tip) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (11b8b25ce4f8 ARM: fix lockdep unannotated irqs-off warning) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (a8956a7b7232 powerpc/powernv: Fix opal-elog interrupt handler) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (fda8b18c515a cxgb4: Fix incorrect sequence numbers shown in devlog) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (e828b23734bf ALSA: hda - add codec ID for Broxton display audio codec) Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during alignment reordering) Merging wireless-drivers/master (38fe44e61a89 Merge tag 'iwlwifi-for-kalle-2015-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (d770e558e219 Linux 4.2-rc1) Merging tty.current/tty-linus (d770e558e219 Linux 4.2-rc1) Merging usb.current/usb-linus (d770e558e219 Linux 4.2-rc1) Merging usb-gadget-fixes/fixes (d770e558e219 Linux 4.2-rc1) Merging usb-serial-fixes/usb-linus (f98a7aa81eee USB: cp210x: add ID for Aruba Networks controllers) Merging staging.current/staging-linus (59b750006ae2 staging: make board support depend on OF_IRQ and CLKDEV_LOOKUP) Merging char-misc.current/char-misc-linus (d770e558e219 Linux 4.2-rc1) Merging input-current/for-linus (a5cba18c4de2 Merge branch 'next' into for-linus) Merging crypto-current/master (acb33cc541d7 crypto: omap-des - Fix unmapping of dma channels) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first => cpumask_local_spread, lament) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging drm-intel-fixes/for-linux-next-fixes (b953c0d234bc Linux 4.1) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into a
Re: [Intel-gfx] [Announcement] 2015-Q2 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
Hi all, We're pleased to announce a public update to Intel Graphics Virtualization Technology(Intel GVT-g, formerly known as XenGT). Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Xen is currently supported on Intel Processor Graphics (a.k.a. XenGT); and the core logic can be easily ported to other hypervisors, for example, the experimental code has been released to support GVT-g running on a KVM hypervisor (a.k.a KVMGT). Tip of repositories - Kernel: 5b73653d5ca, Branch: master-2015Q2-3.18.0 Qemu: 2a75bbff62c1, Branch: master Xen: 38c36f0f511b1, Branch: master-2015Q2-4.5 This update consists of: - Change time based scheduler timer to be configurable to enhance stability - Fix stability issues that VM/Dom0 got tdr when hang up at some specific instruction on BDW - Optimize the emulation of el_status register to enhance stability - 2D/3D performance in linux VMs has been improved about 50% on BDW - Fix abnormal idle power consumption issue due to wrong forcewake policy - Fix tdr issue when running 2D/3D/Media workloads in Windows VMs simultaneously - KVM support is still in a separate branch as prototype work. We plan to integrate KVM/Xen support together in the future releases - Next update will be around early Oct, 2015 Notice that this release can support both Intel 4th generation Core CPU(code name: Haswell) and Intel 5th generation Core CPU (code name: Broadwell), while the limitation of the latter include: * 3D conformance may have some failure * Under high demand 3D workloads, stability issues are detected * Multi-monitor scenario is not fully tested, while single monitor of VGA/HDMI/DP/eDP should just work * Hotplug DP may cause black screen even on native environment Where to get kernel: https://github.com/01org/XenGT-Preview-kernel.git xen: https://github.com/01org/XenGT-Preview-xen.git qemu: https://github.com/01org/XenGT-Preview-qemu.git We have a mailing list for GVT-g development, bug report and technical discussion: https://lists.01.org/mailman/listinfo/igvt-g More information about Intel GVT-g background, architecture, etc can be found at: https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt Note: The XenGT project should be considered a work in progress. As such it is not a complete product nor should it be considered one. Extra care should be taken when testing and configuring a system to use the XenGT project. -- Thanks, Jike On 04/10/2015 09:23 PM, Jike Song wrote: Hi all, We're pleased to announce a public update to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors. Tip of repositories - Kernel: a011c9f953e, Branch: master-2015Q1-3.18.0 Qemu: 2a75bbff62c1, Branch: master Xen: 38c36f0f511b1, Branch: master-2015Q1-4.5 Summary this update - - Preliminary Broadwell support. - kernel update from drm-intel 3.17.0 to drm-intel 3.18.0(tag: drm-intel-next-fixes-2014-12-17, notice that i915 driver code is much newer than kernel stable version). - Next update will be around early July, 2015. - KVM support is still in a separate branch as prototype work. We plan to integrate KVM/Xen support together in future releases. This update consists of: - gvt-g core logic code was moved into i915 driver directory. - Host mediation is used for dom0 i915 driver access, instead of de-privileged dom0. - The Xen-specific code was separated from vgt core logic into a new file "driver/xen/xengt.c". - Broadwell is preliminarily supported in this release. Users could start multiple linux/windows 64-bit
Re: [PATCH] perf record: Allow passing perf's own pid to '--filter'
On 2015/7/6 23:40, Arnaldo Carvalho de Melo wrote: Em Mon, Jul 06, 2015 at 11:00:10PM +0800, pi3orama escreveu: 发自我的 iPhone 在 2015年7月6日，下午9:56，Arnaldo Carvalho de Melo 写道： I.e. having something in the filter expression that gets transformed into the tools' pid, I have no problem with that, just curious about what would be the best character to signal that a substitution needs to be performed, if it is really '@VAR', as my first selection would be '$VAR', $ has special meaning for shell. Using $ in cmdline require users use escaping or '' quoted string. Therefore I believe @ should be better. What do you think? Yeah, that gets in the way, as it gets in the way for '!', i.e. negating, and even tho, that is what is used in strace (and in 'perf trace'): strace -e \!open,write ls Or: strace -e '!open,write' ls But apart from that, it would be good if expressions used in 'perf probe' and here could have as much as possible the same semantics for those markers, i.e. 'perf probe' already uses @ for some stuff, probably the meaning is for "at", i.e. something at some place. '$' strongly associated with variables, so I don't think it would be a big problem to enclose expressions where variables (we may end having others, no?) in '', i.e. perf record -e sched:*switch --filter 'common_pid != $PERF_PID' -a Doesn't look so ugly or cumbersome :-) But what about user want to use real shell variables also? perf record -e raw_syscalls:* "common_pid !="'$PERF_PID'" && common_pid != $X_PID" Or perf record -e raw_syscalls:* "common_pid !=\$PERF_PID && common_pid != $X_PID" right? However, since you and Steven prefer '$' than '@' and '@' has its own meaning 'at' in 'perf probe', I'll use '$' in my next version. I looked your new code. You added perf_evsel__append_filter() to enable us append a filter expression in '(%s) (%s)' manner, and also perf_evlist__set_filter_pid() to add 'common_pid != %d' expression. They are nice scaffolds if we'd like to add a new cmdline option '--filter-pids' and '--filter-perf'. However, I think we should let users who use --filter take full control of their filters, instead of providing many helpers which can do similar things to confuse them. So I decide not to use those functions you added these days in my next version. Thank you. - Arnaldo -- 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: perf, kprobes: fuzzer generates huge number of WARNings
On 2015/07/07 6:27, Vince Weaver wrote: > Hello > > I've been working on trying to get the perf_fuzzer to start fuzzing the > PERF_EVENT_IOC_SET_BPF so I've added some really hackish kprobe support. > > However before I can get to the BPF testing the kprobe code generates a > constant stream of WARNINGS which make the machine more or less useless > until I stop it. I've included a small selection here. > > Is this expected? Did you get same message without BPF hack? And also, could you tell us your kernel version and configuration? > > Vince > > > [ 3521.350839] ftrace: Failed on adding breakpoints (6056): > [ 3521.357877] [ cut here ] > [ 3521.363007] WARNING: CPU: 1 PID: 5080 at kernel/trace/ftrace.c:1951 > ftrace_bug+0x245/0x320() > [ 3521.449830] CPU: 1 PID: 5080 Comm: perf_fuzzer Not tainted 4.2.0-rc1+ #168 > [ 3521.457543] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS > 01/26/2014 > [ 3521.465820] 81a28cf6 8800cd9f7b48 816a10a3 > > [ 3521.474274] 8800cd9f7b88 8106ec8a > 8800cd9f7b68 > [ 3521.482680] 880119bd7a80 81196730 880119bd7a80 > 17a8 > [ 3521.491143] Call Trace: > [ 3521.494128] [] dump_stack+0x45/0x57 > [ 3521.500016] [] warn_slowpath_common+0x8a/0xc0 > [ 3521.506810] [] ? vm_insert_mixed+0x40/0x40 > [ 3521.513389] [] warn_slowpath_null+0x1a/0x20 > [ 3521.520025] [] ftrace_bug+0x245/0x320 > [ 3521.526147] [] ftrace_replace_code+0x24c/0x360 > [ 3521.533102] [] ftrace_modify_all_code+0x9c/0x120 > [ 3521.540241] [] arch_ftrace_update_code+0x10/0x20 > [ 3521.547396] [] ftrace_run_update_code+0x20/0x80 > [ 3521.554425] [] ftrace_startup_enable+0x2f/0x40 > [ 3521.561376] [] ftrace_startup+0xd6/0x230 > [ 3521.567772] [] register_ftrace_function+0x54/0x70 > [ 3521.575025] [] perf_ftrace_event_register+0x47/0x140 > [ 3521.582537] [] perf_trace_init+0xc4/0x2c0 > [ 3521.589050] [] perf_tp_event_init+0x2a/0x50 > [ 3521.595771] [] perf_try_init_event+0x8b/0xa0 > [ 3521.602572] [] perf_init_event+0x133/0x160 > [ 3521.609181] [] ? perf_bp_event+0x90/0x90 > [ 3521.615647] [] perf_event_alloc+0x42a/0x680 > [ 3521.622388] [] SYSC_perf_event_open+0x3c7/0xd20 > [ 3521.629487] [] ? __do_page_fault+0x1ab/0x3f0 > [ 3521.636320] [] SyS_perf_event_open+0x9/0x10 > [ 3521.643087] [] entry_SYSCALL_64_fastpath+0x16/0x7a > [ 3521.650521] ---[ end trace a413501925547ed5 ]--- > [ 3521.655960] ftrace failed to modify [] > handle_mm_fault+0x0/0x1750 > [ 3521.664767] actual: e8:cb:18:ef:1e Hmm, this seems to happen when disarming kprobes from handle_mm_fault+0. However, with this easy test, I couldn't reproduce it on the latest tip/master. [root@localhost tracing]# echo p handle_mm_fault > kprobe_events [root@localhost tracing]# echo 1 > events/kprobes/p_handle_mm_fault_0/enable [root@localhost tracing]# echo 0 > events/kprobes/p_handle_mm_fault_0/enable We'd better know how to reproduce this issue. Thank you, > [ 3521.669202] ftrace record flags: ec02 > [ 3521.673993] (2) R tramp: 0xa009 expected tramp: > a009 > > > [ 3521.834024] [ cut here ] > [ 3521.839442] WARNING: CPU: 2 PID: 5177 at kernel/kprobes.c:955 > disarm_kprobe+0xf8/0x100() > [ 3521.848577] Failed to init kprobe-ftrace (-19) > [ 3521.931384] CPU: 2 PID: 5177 Comm: perf_fuzzer Tainted: GW > 4.2.0-rc1+ #168 > [ 3521.940498] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS > 01/26/2014 > [ 3521.948854] 81a28976 8800bf6d7a48 816a10a3 > > [ 3521.957335] 8800bf6d7a98 8800bf6d7a88 8106ec8a > 81124f6a > [ 3521.965839] 8800cd4e2010 8800cd4e2010 8800cd4e2000 > 8800cd28a000 > [ 3521.974275] Call Trace: > [ 3521.977335] [] dump_stack+0x45/0x57 > [ 3521.983302] [] warn_slowpath_common+0x8a/0xc0 > [ 3521.990170] [] ? unregister_ftrace_function+0x1a/0x50 > [ 3521.997784] [] warn_slowpath_fmt+0x46/0x50 > [ 3522.004418] [] ? mutex_unlock+0xe/0x10 > [ 3522.010640] [] disarm_kprobe+0xf8/0x100 > [ 3522.016972] [] __disable_kprobe+0x99/0xc0 > [ 3522.023491] [] disable_kprobe+0x27/0x50 > [ 3522.029827] [] disable_trace_kprobe+0xc3/0xf0 > [ 3522.036708] [] kprobe_register+0x2d/0xe0 > [ 3522.043102] [] perf_trace_event_unreg.isra.1+0x33/0x90 > [ 3522.050808] [] perf_trace_destroy+0x3c/0x50 > [ 3522.057482] [] tp_perf_event_destroy+0x9/0x10 > [ 3522.064354] [] _free_event+0xc1/0x250 > [ 3522.070474] [] ? put_event+0x2b/0x150 > [ 3522.076625] [] free_event+0x1f/0x50 > [ 3522.082531] [] perf_event_exit_task+0x245/0x300 > [ 3522.089575] [] do_exit+0x3b2/0xa90 > [ 3522.095444] [] ? get_signal+0xe2/0x720 > [ 3522.101659] [] do_group_exit+0x54/0xe0 > [ 3522.107892] [] get_signal+0x280/0x720 > [ 3522.114046] [] do_signal+0x28/0xb50 > [ 3522.119984] [] ? __lock_acquire.isra.31+0x3a6/0xf90 > [ 3522.127411] [] ?
Re: [PATCH v2] add stealth mode
From: Matteo Croce Date: Mon, 6 Jul 2015 21:44:06 +0200 > 2015-07-06 12:49 GMT+02:00 : >> On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said: >>> Add option to disable any reply not related to a listening socket, >>> like RST/ACK for TCP and ICMP Port-Unreachable for UDP. >>> Also disables ICMP replies to echo request and timestamp. >>> The stealth mode can be enabled selectively for a single interface. >> >> A few notes. >> >> 1) Do you have an actual use case where an iptables '-j DROP' isn't usable? > > If you mean using a default DROP policy and allowing only the traffic > do you want, > then the use case is where the port can change at runtime and you may not want > to update the firewall every time Dynamically updated firewalls are "a thing" and quite effective for solving problems like this one. With nftables such updates are even extremely efficient. -- 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 1/3] net: dsa: mv88e6xxx: add debugfs interface for VTU
> +static int _mv88e6xxx_vtu_getnext(struct dsa_switch *ds, u16 vid,
> + struct mv88e6xxx_vtu_entry *entry)
> +{
> + int ret, i;
> +
> + ret = _mv88e6xxx_vtu_wait(ds);
> + if (ret < 0)
> + return ret;
> +
> + ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_VID,
> +vid & GLOBAL_VTU_VID_MASK);
> + if (ret < 0)
> + return ret;
> +
> + ret = _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_VTU_GET_NEXT);
> + if (ret < 0)
> + return ret;
> +
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_VID);
> + if (ret < 0)
> + return ret;
> +
> + entry->vid = ret & GLOBAL_VTU_VID_MASK;
> + entry->valid = !!(ret & GLOBAL_VTU_VID_VALID);
> +
> + if (entry->valid) {
> + /* Ports 0-3, offsets 0, 4, 8, 12 */
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_DATA_0_3);
> + if (ret < 0)
> + return ret;
> +
> + for (i = 0; i < 4; ++i)
> + entry->tags[i] = (ret >> (i * 4)) & 3;
> +
> + /* Ports 4-6, offsets 0, 4, 8 */
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_DATA_4_7);
> + if (ret < 0)
> + return ret;
> +
> + for (i = 4; i < 7; ++i)
> + entry->tags[i] = (ret >> ((i - 4) * 4)) & 3;
Hi Vivien
It looks like you still have up to 7 ports, rather than use
ps->num_ports. I have a ten port switch i would like to use VLANs with
:-)
> +
> + if (mv88e6xxx_6097_family(ds) || mv88e6xxx_6165_family(ds) ||
> + mv88e6xxx_6351_family(ds) || mv88e6xxx_6352_family(ds)) {
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL,
> + GLOBAL_VTU_FID);
> + if (ret < 0)
> + return ret;
> +
> + entry->fid = ret & GLOBAL_VTU_FID_MASK;
> +
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL,
> + GLOBAL_VTU_SID);
> + if (ret < 0)
> + return ret;
> +
> + entry->sid = ret & GLOBAL_VTU_SID_MASK;
> + } else {
> + entry->fid = 0;
> + entry->sid = 0;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch *ds,
> + struct mv88e6xxx_vtu_entry *entry)
> +{
> + u16 data = 0;
> + int ret, i;
> +
> + ret = _mv88e6xxx_vtu_wait(ds);
> + if (ret < 0)
> + return ret;
> +
> + if (entry->valid) {
> + /* Set Data Register, ports 0-3, offsets 0, 4, 8, 12 */
> + for (data = i = 0; i < 4; ++i)
> + data |= entry->tags[i] << (i * 4);
> + ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_0_3,
> +data);
> + if (ret < 0)
> + return ret;
> +
> + /* Set Data Register, ports 4-6, offsets 0, 4, 8 */
> + for (data = 0, i = 4; i < 7; ++i)
> + data |= entry->tags[i] << ((i - 4) * 4);
> + ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_4_7,
> +data);
Same again here.
Andrew
--
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 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails
On 7/1/2015 8:00 PM, Felipe Balbi wrote: > On Thu, Jul 02, 2015 at 02:03:14AM +, John Youn wrote: >> On 6/29/2015 2:48 PM, Felipe Balbi wrote: >>> Hi again, >>> >>> On Mon, Jun 29, 2015 at 04:47:01PM -0500, Felipe Balbi wrote: On Thu, May 21, 2015 at 03:46:48PM +0530, Subbaraya Sundeep Bhatta wrote: > We need to return error to caller if command is not sent to > controller succesfully. > > Signed-off-by: Subbaraya Sundeep Bhatta > Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) > Cc: > --- > v2 changes: > Added Fixes and Cc in commit message. I noticed that this breaks at least my AM437x silicon with DWC3 2.40a when used with g_zero and testusb. As of now, it could be that silicon is mis-behaving because I got a Transfer Complete before the failing Set Endpoint Transfer Resource command. In any case, can you run on your setup with g_zero and test.sh/testusb [1]/[2] just to verify that it really works for you ? Meanwhile, I'll continue testing on my end. cheers [1] https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:testusb.c [2] https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:test.sh >>> >>> Adding John here. John, any chance you could fire up dwc3 on HAPS and >>> see wether it works or fails for you ? >>> >>> cheers >>> >> >> Hi Felipe, >> >> Just an update on this. >> >> I'm trying to get this working with our latest IP with dwc3 from your >> testing/next branch. It fails the usbtest with a problem unrelated to >> this patch. >> >> It passes on 4.1.1. >> >> I'll have to look into the failure but I won't get to it until next >> week as I'm off the rest of this week. > > interesting... If you could post failure signature, I can help looking > at it, but I guess it's too late to ask :-) > > thanks for helping though > Hi Felipe, Nevermind about my issue, it ended up being a setup-related problem. I actually do see the same error as you due to this series of patches. Except I see it happening before even the first iteration. I get a completion status of 1 for the Set Endpoint Transfer Resources command. I'm not sure why this is. I don't see any conflict with any previous Transfer Complete. I will have to consult with some hardware engineers tomorrow to look into it further. The trace is attached. John # tracer: nop # # entries-in-buffer/entries-written: 518/518 #P:8 # # _-=> irqs-off # / _=> need-resched #| / _---=> hardirq/softirq #|| / _--=> preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | -0 [000] d.h. 2443.493013: dwc3_readl: addr c9ea040c value 0008 -0 [000] d.h. 2443.493019: dwc3_readl: addr c9ea0408 value 0100 -0 [000] d.h. 2443.493020: dwc3_writel: addr c9ea0408 value 8100 -0 [003] d.h. 2443.493128: dwc3_readl: addr c9ea040c value 0008 -0 [003] d.h. 2443.493132: dwc3_readl: addr c9ea0408 value 8100 -0 [003] d.h. 2443.493133: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493186: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493188: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493189: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493192: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493194: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493195: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493198: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493200: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493201: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493204: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493206: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493207: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493210: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493212: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493213: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493216: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493218: dwc3_readl: addr
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Tue, Jul 07, 2015 at 01:38:04AM +0200, Andrew Lunn wrote:
> On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote:
> > Hi all,
> >
> > This patchset brings full support for hardware VLANs in DSA, and the Marvell
> > 88E6xxx compatible switch chips.
>
> Hi Vivien
>
> I just booted these patches on my board, and i'm getting WARNINGS:
>
> [ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265
> switchdev_port_obj_add+0xd4/0xdc()
Hi Vivien
I debugged this a bit.
The problem comes from:
static int dsa_slave_port_obj_add(struct net_device *dev,
struct switchdev_obj *obj)
{
int err;
/*
* Skip the prepare phase, since currently the DSA drivers don't need
to
* allocate any memory for operations and they will not fail to HW
* (unless something horrible goes wrong on the MDIO bus, in which case
* the prepare phase wouldn't have been able to predict anyway).
*/
if (obj->trans != SWITCHDEV_TRANS_COMMIT)
return 0;
switch (obj->id) {
case SWITCHDEV_OBJ_PORT_VLAN:
err = dsa_slave_port_vlans_add(dev, obj);
break;
default:
err = -EOPNOTSUPP;
break;
}
return err;
}
It is being called with obj->id of 2, which is
SWITCHDEV_OBJ_IPV4_FIB. This function is called twice. The first time
it is with SWITCHDEV_TRANS_PREPARE and we are allowed to return an
error. The second time, with SWITCHDEV_TRANS_COMMIT, errors are not
allowed.
EOPNOTSUPP is considered an error, so since we don't support
SWITCHDEV_OBJ_IPV4_FIB we error out the COMMIT phase.
Not sure which is cleaner. Test to see if we support the object during
the prepare, or allow the commit to accept EOPNOTSUPP as not being an
error?
Andrew
--
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 12/15] SH: kill off set_irq_flags usage
On Tue, Jul 07, 2015 at 09:53:39AM +0900, Simon Horman wrote:
> On Tue, Jun 09, 2015 at 01:26:38PM -0500, Rob Herring wrote:
> > set_irq_flags is ARM specific with custom flags which have genirq
> > equivalents. Convert drivers to use the genirq interfaces directly, so we
> > can kill off set_irq_flags. The translation of flags is as follows:
> >
> > IRQF_VALID -> !IRQ_NOREQUEST
> > IRQF_PROBE -> !IRQ_NOPROBE
> > IRQF_NOAUTOEN -> IRQ_NOAUTOEN
> >
> > For IRQs managed by an irqdomain, the irqdomain core code handles clearing
> > and setting IRQ_NOREQUEST already, so there is no need to do this in
> > .map() functions and we can simply remove the set_irq_flags calls. Some
> > users also set IRQ_NOPROBE and this has been maintained although it is not
> > clear that is really needed. There appears to be a great deal of blind
> > copy and paste of this code.
> >
> > Signed-off-by: Rob Herring
> > Cc: Simon Horman
> > Cc: Magnus Damm
> > Cc: linux...@vger.kernel.org
>
> I am trusting the description above coupled with the comments in
> the original code (that this patch removes). Assuming those ducks are
> aligned:
>
> Acked-by: Simon Horman
As I usually take patches for drivers/sh/ (there have not been many of late)
please let me know if you would like me to pick up this change.
Also, a very minor nit, the prefix for patches to this file is usually
'sh:' rather than 'SH:'.
>
> > ---
> > drivers/sh/intc/internals.h | 10 +-
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/drivers/sh/intc/internals.h b/drivers/sh/intc/internals.h
> > index 7dff08e..897ffb1 100644
> > --- a/drivers/sh/intc/internals.h
> > +++ b/drivers/sh/intc/internals.h
> > @@ -99,15 +99,7 @@ static inline struct intc_desc_int
> > *get_intc_desc(unsigned int irq)
> > */
> > static inline void activate_irq(int irq)
> > {
> > -#ifdef CONFIG_ARM
> > - /* ARM requires an extra step to clear IRQ_NOREQUEST, which it
> > -* sets on behalf of every irq_chip. Also sets IRQ_NOPROBE.
> > -*/
> > - set_irq_flags(irq, IRQF_VALID);
> > -#else
> > - /* same effect on other architectures */
> > - irq_set_noprobe(irq);
> > -#endif
> > + irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
> > }
> >
> > static inline int intc_handle_int_cmp(const void *a, const void *b)
> > --
> > 2.1.0
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c
When the checkpatch.pl script was run, it showed lines with length
more than 80 characters in rtw_ap.c file. Fixed line number 382 by
breaking it up into two lines within 80 characters.
Signed-off-by: Sreenath Madasu
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 581af88..293510e 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -379,7 +379,8 @@ voidexpire_timeout_chk(struct adapter *padapter)
if (pmlmeext->active_keep_alive_check) {
int stainfo_offset;
- stainfo_offset = rtw_stainfo_offset(pstapriv,
psta);
+ stainfo_offset =
+ rtw_stainfo_offset(pstapriv, psta);
if (stainfo_offset_valid(stainfo_offset))
chk_alive_list[chk_alive_num++] =
stainfo_offset;
continue;
--
2.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: exynos4: add DMA support for serial ports
2015-06-30 9:56 GMT+09:00 Krzysztof Kozlowski :
> On 29.06.2015 22:22, Robert Baldyga wrote:
>> Enable DMA transfers for serial ports.
>>
>> Signed-off-by: Robert Baldyga
>> ---
>> arch/arm/boot/dts/exynos4.dtsi | 8
>> 1 file changed, 8 insertions(+)
>
> Reviewed-by: Krzysztof Kozlowski
Unfortunately the commit (applied on 4.2-rc1) exposes lock-ups during
Trats2 boot.
Board: Trats2
Config: exynos
Tree: https://github.com/krzk/linux.git
branch: for-next (v4.2-rc1-29-g1ce41c343055)
Lockdep indicated issue in Samsung serial driver
(dma_async_issue_pending called while holding port->lock which leads
to calling back the driver's tx_dma_complete).
I tried to locate the dead lock. To me the excessive locking in serial
driver causes such recursive locking but I am not quite sure (I am not
familiar with the serial driver).
Anyway, till this get fixed I am dropping the patch from my tree.
Best regards,
Krzysztof
Bug (I hope line wrapping won't mess up with it...):
[ 74.480535] BUG: spinlock recursion on CPU#1, systemd/1
[ 74.484293] lock: 0xeeb1a9f4, .magic: dead4ead, .owner: systemd/1,
.owner_cpu: 1
[ 74.491756] CPU: 1 PID: 1 Comm: systemd Not tainted
4.2.0-rc1-00029-g1ce41c343055 #100
[ 74.499649] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 74.505752] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 74.513461] [] (show_stack) from []
(dump_stack+0x70/0xbc)
[ 74.520668] [] (dump_stack) from []
(do_raw_spin_lock+0x178/0x1a0)
[ 74.528568] [] (do_raw_spin_lock) from []
(_raw_spin_lock_irqsave+0x20/0x28)
[ 74.537330] [] (_raw_spin_lock_irqsave) from []
(dma_pl330_rqcb.isra.4+0x24/0x58)
[ 74.546529] [] (dma_pl330_rqcb.isra.4) from []
(pl330_release_channel.part.5+0x38/0x98)
[ 74.556249] [] (pl330_release_channel.part.5) from
[] (pl330_free_chan_resources+0x54/0xd8)
[ 74.566324] [] (pl330_free_chan_resources) from
[] (dma_chan_put+0x88/0x8c)
[ 74.575001] [] (dma_chan_put) from []
(dma_release_channel+0x24/0x94)
[ 74.583163] [] (dma_release_channel) from []
(s3c24xx_serial_shutdown+0x18c/0x1d8)
[ 74.592447] [] (s3c24xx_serial_shutdown) from
[] (uart_port_shutdown+0x2c/0x38)
[ 74.601472] [] (uart_port_shutdown) from []
(uart_shutdown+0xac/0xec)
[ 74.609630] [] (uart_shutdown) from []
(uart_close+0x64/0x1f0)
[ 74.617184] [] (uart_close) from []
(tty_release+0xf0/0x464)
[ 74.624566] [] (tty_release) from [] (__fput+0x80/0x1bc)
[ 74.631594] [] (__fput) from [] (task_work_run+0xa8/0xdc)
[ 74.638711] [] (task_work_run) from []
(do_work_pending+0x94/0xb4)
[ 74.646610] [] (do_work_pending) from []
(work_pending+0xc/0x20)
Lockdep:
[ 109.696678] Requested RX ee0d4a2c@TX ee0d4ac4
[ 109.701699]
[ 109.701928] =
[ 109.707310] [ INFO: possible recursive locking detected ]
[ 109.712694] 4.2.0-rc1-00029-g1ce41c343055-dirty #111 Not tainted
[ 109.718680] -
[ 109.724063] swapper/0/0 is trying to acquire lock:
[ 109.728836] (_lock_key){-.-...}, at: []
s3c24xx_serial_tx_dma_complete+0x8c/0xfc
[ 109.737603]
[ 109.737603] but task is already holding lock:
[ 109.743418] (_lock_key){-.-...}, at: []
s3c24xx_serial_tx_chars+0x18/0x180
[ 109.751664]
[ 109.751664] other info that might help us debug this:
[ 109.758174] Possible unsafe locking scenario:
[ 109.758174]
[ 109.764076]CPU0
[ 109.766507]
[ 109.768936] lock(_lock_key);
[ 109.772408] lock(_lock_key);
[ 109.775881]
[ 109.775881] *** DEADLOCK ***
[ 109.775881]
[ 109.781784] May be due to missing lock nesting notation
[ 109.781784]
[ 109.788556] 1 lock held by swapper/0/0:
[ 109.792373] #0: (_lock_key){-.-...}, at: []
s3c24xx_serial_tx_chars+0x18/0x180
[ 109.801053]
[ 109.801053] stack backtrace:
[ 109.805399] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.2.0-rc1-00029-g1ce41c343055-dirty #111
[ 109.813988] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 109.820084] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 109.827801] [] (show_stack) from []
(dump_stack+0x70/0xbc)
[ 109.835003] [] (dump_stack) from []
(validate_chain.isra.24+0x7b4/0x8b8)
[ 109.843419] [] (validate_chain.isra.24) from []
(__lock_acquire+0x464/0xb28)
[ 109.852185] [] (__lock_acquire) from []
(lock_acquire+0x6c/0x8c)
[ 109.859915] [] (lock_acquire) from []
(_raw_spin_lock_irqsave+0x48/0x5c)
[ 109.868335] [] (_raw_spin_lock_irqsave) from []
(s3c24xx_serial_tx_dma_complete+0x8c/0xfc)
[ 109.878322] [] (s3c24xx_serial_tx_dma_complete) from
[] (pl330_tasklet+0x16c/0x4cc)
[ 109.887690] [] (pl330_tasklet) from []
(s3c24xx_serial_start_tx_dma+0x1a4/0x1f4)
[ 109.896803] [] (s3c24xx_serial_start_tx_dma) from
[] (s3c24xx_serial_tx_chars+0x158/0x180)
[ 109.906784] [] (s3c24xx_serial_tx_chars) from
[] (s3c64xx_serial_handle_irq+0x34/0x60)
[ 109.916424] [] (s3c64xx_serial_handle_irq) from
[] (handle_irq_event_percpu+0x50/0x154)
[ 109.926142] [] (handle_irq_event_percpu) from
Re: [PATCH 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory feature
On 2015/7/6 22:03, PINTU KUMAR wrote: > Hi, > >> -Original Message- >> From: Xishi Qiu [mailto:qiuxi...@huawei.com] >> Sent: Monday, July 06, 2015 3:53 PM >> To: Pintu Kumar >> Cc: cor...@lwn.net; a...@linux-foundation.org; vba...@suse.cz; >> gorcu...@openvz.org; mho...@suse.cz; emun...@akamai.com; >> kirill.shute...@linux.intel.com; standby2...@gmail.com; >> han...@cmpxchg.org; vdavy...@parallels.com; hu...@google.com; >> minc...@kernel.org; t...@kernel.org; rient...@google.com; >> xypron.g...@gmx.de; dzic...@redhat.com; pra...@redhat.com; >> ebied...@xmission.com; rost...@goodmis.org; uober...@redhat.com; >> paul...@linux.vnet.ibm.com; iamjoonsoo@lge.com; ddstr...@ieee.org; >> sasha.le...@oracle.com; koc...@gmail.com; mgor...@suse.de; c...@linux.com; >> opensource.gan...@gmail.com; vinme...@codeaurora.org; linux- >> d...@vger.kernel.org; linux-kernel@vger.kernel.org; linux...@kvack.org; >> linux- >> p...@vger.kernel.org; c...@samsung.com; pintu_agar...@yahoo.com; >> vishnu...@samsung.com; rohit...@samsung.com; iqbal@samsung.com >> Subject: Re: [PATCH 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory >> feature >> >> On 2015/7/3 21:20, Pintu Kumar wrote: >> >>> This patch provides 2 things: >>> 1. Add new control called shrink_memory in /proc/sys/vm/. >>> This control can be used to aggressively reclaim memory system-wide in >>> one shot from the user space. A value of 1 will instruct the kernel to >>> reclaim as much as totalram_pages in the system. >>> Example: echo 1 > /proc/sys/vm/shrink_memory >>> >>> 2. Enable shrink_all_memory API in kernel with new >> CONFIG_SHRINK_MEMORY. >>> Currently, shrink_all_memory function is used only during hibernation. >>> With the new config we can make use of this API for non-hibernation >>> case also without disturbing the hibernation case. >>> >>> The detailed paper was presented in Embedded Linux Conference, >>> Mar-2015 http://events.linuxfoundation.org/sites/events/files/slides/ >>> %5BELC-2015%5D-System-wide-Memory-Defragmenter.pdf >>> >>> Scenarios were this can be used and helpful are: >>> 1) Can be invoked just after system boot-up is finished. >>> 2) Can be invoked just before entering entire system suspend. >>> 3) Can be invoked from kernel when order-4 pages starts failing. >>> 4) Can be helpful to completely avoid or delay the kerenl OOM condition. >>> 5) Can be developed as a system-tool to quickly defragment entire system >>>from user space, without the need to kill any application. >>> >> >> Hi Pintu, >> >> How about increase min_free_kbytes and Android lowmemorykiller's level? >> > Thanks for the review. > Actually in Tizen, we don't use Android LMK and we wanted to delay the LMK > with > aggressive direct_reclaim offline. > And increasing min_free value also may not help much. > Currently, in our case free memory never falls below 10MB, with 512MB RAM > configuration. > How about the performance as you reclaim so much memory? (e.g. shrink page cache, use zram, ksm, compaction...) When launching the same app next time, it may be slow, right? How about use cgroup to manage the apps, but I don't know how to do the detail. Thanks, Xishi Qiu > > -- 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: [alsa-devel][PATCH 1/2] ASoC: fsl_ssi: Add driver suspend and resume to support MEGA Fast
On Jul 6, 2015, at 4:49 AM, Zidan Wang wrote:
> +static bool fsl_ssi_readable_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case CCSR_SSI_STX0:
> + case CCSR_SSI_STX1:
> + case CCSR_SSI_SRX0:
> + case CCSR_SSI_SRX1:
> + case CCSR_SSI_SCR:
> + case CCSR_SSI_SISR:
> + case CCSR_SSI_SIER:
> + case CCSR_SSI_STCR:
> + case CCSR_SSI_SRCR:
> + case CCSR_SSI_STCCR:
> + case CCSR_SSI_SRCCR:
> + case CCSR_SSI_SFCSR:
> + case CCSR_SSI_STR:
> + case CCSR_SSI_SOR:
> + case CCSR_SSI_SACNT:
> + case CCSR_SSI_SACADD:
> + case CCSR_SSI_SACDAT:
> + case CCSR_SSI_SATAG:
> + case CCSR_SSI_STMSK:
> + case CCSR_SSI_SRMSK:
> + case CCSR_SSI_SACCST:
> + case CCSR_SSI_SACCEN:
> + case CCSR_SSI_SACCDIS:
> + return true;
> + default:
> + return false;
> + }
> +}
This should be the other way around: return true by default, and false it is
one of the few registers that is not readable.--
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: [alsa-devel][PATCH 2/2] ASoC: fsl_ssi: sound is wrong after suspend/resume
On Jul 6, 2015, at 4:49 AM, Zidan Wang wrote: > The register SFCSR is volatile, but some bits in it need to be > recovered after suspend/resume. > > Signed-off-by: Zidan Wang Shouldn't this be part of patch #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 02/11] uprobes: Introduce free_ret_instance()
We can simplify uprobe_free_utask() and handle_uretprobe_chain()
if we add a simple helper which does put_uprobe/kfree and returns
the ->next return_instance.
Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
---
kernel/events/uprobes.c | 27 +--
1 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index a9847b4..d8c702f 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1378,6 +1378,14 @@ unsigned long uprobe_get_trap_addr(struct pt_regs *regs)
return instruction_pointer(regs);
}
+static struct return_instance *free_ret_instance(struct return_instance *ri)
+{
+ struct return_instance *next = ri->next;
+ put_uprobe(ri->uprobe);
+ kfree(ri);
+ return next;
+}
+
/*
* Called with no locks held.
* Called in context of a exiting or a exec-ing thread.
@@ -1385,7 +1393,7 @@ unsigned long uprobe_get_trap_addr(struct pt_regs *regs)
void uprobe_free_utask(struct task_struct *t)
{
struct uprobe_task *utask = t->utask;
- struct return_instance *ri, *tmp;
+ struct return_instance *ri;
if (!utask)
return;
@@ -1394,13 +1402,8 @@ void uprobe_free_utask(struct task_struct *t)
put_uprobe(utask->active_uprobe);
ri = utask->return_instances;
- while (ri) {
- tmp = ri;
- ri = ri->next;
-
- put_uprobe(tmp->uprobe);
- kfree(tmp);
- }
+ while (ri)
+ ri = free_ret_instance(ri);
xol_free_insn_slot(t);
kfree(utask);
@@ -1770,7 +1773,7 @@ handle_uretprobe_chain(struct return_instance *ri, struct
pt_regs *regs)
static bool handle_trampoline(struct pt_regs *regs)
{
struct uprobe_task *utask;
- struct return_instance *ri, *tmp;
+ struct return_instance *ri;
bool chained;
utask = current->utask;
@@ -1792,11 +1795,7 @@ static bool handle_trampoline(struct pt_regs *regs)
handle_uretprobe_chain(ri, regs);
chained = ri->chained;
- put_uprobe(ri->uprobe);
-
- tmp = ri;
- ri = ri->next;
- kfree(tmp);
+ ri = free_ret_instance(ri);
utask->depth--;
if (!chained)
--
1.5.5.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 05/11] uprobes: Change handle_trampoline() to find the next chain beforehand
No functional changes, preparation.
Add the new helper, find_next_ret_chain(), which finds the first !chained
entry and returns its ->next. Yes, it is suboptimal. We probably want to
turn ->chained into ->start_of_this_chain pointer and avoid another loop.
But this needs the boring changes in dup_utask(), so lets do this later.
Change the main loop in handle_trampoline() to unwind the stack until ri
is equal to the pointer returned by this new helper.
Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
---
kernel/events/uprobes.c | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 4c941fe..98e4d97 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1766,11 +1766,22 @@ handle_uretprobe_chain(struct return_instance *ri,
struct pt_regs *regs)
up_read(>register_rwsem);
}
+static struct return_instance *find_next_ret_chain(struct return_instance *ri)
+{
+ bool chained;
+
+ do {
+ chained = ri->chained;
+ ri = ri->next; /* can't be NULL if chained */
+ } while (chained);
+
+ return ri;
+}
+
static void handle_trampoline(struct pt_regs *regs)
{
struct uprobe_task *utask;
- struct return_instance *ri;
- bool chained;
+ struct return_instance *ri, *next;
utask = current->utask;
if (!utask)
@@ -1780,24 +1791,18 @@ static void handle_trampoline(struct pt_regs *regs)
if (!ri)
goto sigill;
+ next = find_next_ret_chain(ri);
/*
* TODO: we should throw out return_instance's invalidated by
* longjmp(), currently we assume that the probed function always
* returns.
*/
instruction_pointer_set(regs, ri->orig_ret_vaddr);
-
- for (;;) {
+ do {
handle_uretprobe_chain(ri, regs);
-
- chained = ri->chained;
ri = free_ret_instance(ri);
utask->depth--;
-
- if (!chained)
- break;
- BUG_ON(!ri);
- }
+ } while (ri != next);
utask->return_instances = ri;
return;
--
1.5.5.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 08/11] uprobes: Change handle_trampoline() to flush the frames invalidated by longjmp()
Test-case:
#include
#include
jmp_buf jmp;
void func_2(void)
{
longjmp(jmp, 1);
}
void func_1(void)
{
if (setjmp(jmp))
return;
func_2();
printf("ERR!! I am running on the caller's stack\n");
}
int main(void)
{
func_1();
return 0;
}
fails if you probe func_1() and func_2() because handle_trampoline()
assumes that the probed function should must return and hit the bp
installed be prepare_uretprobe(). But in this case func_2() does not
return, so when func_1() returns the kernel uses the no longer valid
return_instance of func_2().
Change handle_trampoline() to unwind ->return_instances until we know
that the next chain is alive or NULL, this ensures that the current
chain is the last we need to report and free.
Alternatively, every return_instance could use unique trampoline_vaddr,
in this case we could use it as a key. And this could solve the problem
with sigaltstack() automatically.
But this approach needs more changes, and it puts the "hard" limit on
MAX_URETPROBE_DEPTH. Plus it can not solve another problem partially
fixed by the next patch.
Note: this change has no effect on !x86, the arch-agnostic version of
arch_uretprobe_is_alive() just returns "true".
TODO: as documented by the previous change, arch_uretprobe_is_alive()
can be fooled by sigaltstack/etc.
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 29 ++---
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index c5f316e..93d939c 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1774,6 +1774,7 @@ static void handle_trampoline(struct pt_regs *regs)
{
struct uprobe_task *utask;
struct return_instance *ri, *next;
+ bool valid;
utask = current->utask;
if (!utask)
@@ -1783,18 +1784,24 @@ static void handle_trampoline(struct pt_regs *regs)
if (!ri)
goto sigill;
- next = find_next_ret_chain(ri);
- /*
-* TODO: we should throw out return_instance's invalidated by
-* longjmp(), currently we assume that the probed function always
-* returns.
-*/
- instruction_pointer_set(regs, ri->orig_ret_vaddr);
do {
- handle_uretprobe_chain(ri, regs);
- ri = free_ret_instance(ri);
- utask->depth--;
- } while (ri != next);
+ /*
+* We should throw out the frames invalidated by longjmp().
+* If this chain is valid, then the next one should be alive
+* or NULL; the latter case means that nobody but ri->func
+* could hit this trampoline on return. TODO: sigaltstack().
+*/
+ next = find_next_ret_chain(ri);
+ valid = !next || arch_uretprobe_is_alive(next, regs);
+
+ instruction_pointer_set(regs, ri->orig_ret_vaddr);
+ do {
+ if (valid)
+ handle_uretprobe_chain(ri, regs);
+ ri = free_ret_instance(ri);
+ utask->depth--;
+ } while (ri != next);
+ } while (!valid);
utask->return_instances = ri;
return;
--
1.5.5.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 06/11] uprobes: Export struct return_instance, introduce arch_uretprobe_is_alive()
Add the new "weak" helper, arch_uretprobe_is_alive(), used by the next
patches. It should return true if this return_instance is still valid.
The arch agnostic version just always returns true.
The patch exports "struct return_instance" for the architectures which
want to override this hook. We can also cleanup prepare_uretprobe() if
we pass the new return_instance to arch_uretprobe_hijack_return_addr().
Signed-off-by: Oleg Nesterov
---
include/linux/uprobes.h | 10 ++
kernel/events/uprobes.c | 14 +-
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 60beb5d..50d2764 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -92,6 +92,15 @@ struct uprobe_task {
unsigned intdepth;
};
+struct return_instance {
+ struct uprobe *uprobe;
+ unsigned long func;
+ unsigned long orig_ret_vaddr; /* original return address */
+ boolchained;/* true, if instance is nested
*/
+
+ struct return_instance *next; /* keep as stack */
+};
+
struct xol_area;
struct uprobes_state {
@@ -128,6 +137,7 @@ extern bool arch_uprobe_xol_was_trapped(struct task_struct
*tsk);
extern int arch_uprobe_exception_notify(struct notifier_block *self, unsigned
long val, void *data);
extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs
*regs);
extern unsigned long arch_uretprobe_hijack_return_addr(unsigned long
trampoline_vaddr, struct pt_regs *regs);
+extern bool arch_uretprobe_is_alive(struct return_instance *ret, struct
pt_regs *regs);
extern bool arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs);
extern void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
void *src, unsigned long len);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 98e4d97..1c71b62 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -86,15 +86,6 @@ struct uprobe {
struct arch_uprobe arch;
};
-struct return_instance {
- struct uprobe *uprobe;
- unsigned long func;
- unsigned long orig_ret_vaddr; /* original return address */
- boolchained;/* true, if instance is nested
*/
-
- struct return_instance *next; /* keep as stack */
-};
-
/*
* Execute out of line area: anonymous executable mapping installed
* by the probed task to execute the copy of the original instruction
@@ -1818,6 +1809,11 @@ bool __weak arch_uprobe_ignore(struct arch_uprobe *aup,
struct pt_regs *regs)
return false;
}
+bool __weak arch_uretprobe_is_alive(struct return_instance *ret, struct
pt_regs *regs)
+{
+ return true;
+}
+
/*
* Run handler and ask thread to singlestep.
* Ensure all non-fatal signals cannot interrupt thread while it singlesteps.
--
1.5.5.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 10/11] uprobes: Add the "enum rp_check ctx" arg to arch_uretprobe_is_alive()
arch/x86 doesn't care (so far), but as Pratyush Anand pointed out
other architectures might want why arch_uretprobe_is_alive() was
called and use different checks depending on the context. Add the
new argument to distinguish 2 callers.
Signed-off-by: Oleg Nesterov
---
arch/x86/kernel/uprobes.c |3 ++-
include/linux/uprobes.h |7 ++-
kernel/events/uprobes.c |9 ++---
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 9d5f570..67eb168 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -994,7 +994,8 @@ arch_uretprobe_hijack_return_addr(unsigned long
trampoline_vaddr, struct pt_regs
return -1;
}
-bool arch_uretprobe_is_alive(struct return_instance *ret, struct pt_regs *regs)
+bool arch_uretprobe_is_alive(struct return_instance *ret, enum rp_check ctx,
+ struct pt_regs *regs)
{
return regs->sp <= ret->stack;
}
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 7ab6d2c..c0a5402 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -102,6 +102,11 @@ struct return_instance {
struct return_instance *next; /* keep as stack */
};
+enum rp_check {
+ RP_CHECK_CALL,
+ RP_CHECK_RET,
+};
+
struct xol_area;
struct uprobes_state {
@@ -138,7 +143,7 @@ extern bool arch_uprobe_xol_was_trapped(struct task_struct
*tsk);
extern int arch_uprobe_exception_notify(struct notifier_block *self, unsigned
long val, void *data);
extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs
*regs);
extern unsigned long arch_uretprobe_hijack_return_addr(unsigned long
trampoline_vaddr, struct pt_regs *regs);
-extern bool arch_uretprobe_is_alive(struct return_instance *ret, struct
pt_regs *regs);
+extern bool arch_uretprobe_is_alive(struct return_instance *ret, enum rp_check
ctx, struct pt_regs *regs);
extern bool arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs);
extern void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
void *src, unsigned long len);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 7e61c8c..df5661a 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1514,7 +1514,9 @@ static unsigned long get_trampoline_vaddr(void)
static void cleanup_return_instances(struct uprobe_task *utask, struct pt_regs
*regs)
{
struct return_instance *ri = utask->return_instances;
- while (ri && !arch_uretprobe_is_alive(ri, regs)) {
+ enum rp_check ctx = RP_CHECK_CALL;
+
+ while (ri && !arch_uretprobe_is_alive(ri, ctx, regs)) {
ri = free_ret_instance(ri);
utask->depth--;
}
@@ -1805,7 +1807,7 @@ static void handle_trampoline(struct pt_regs *regs)
* could hit this trampoline on return. TODO: sigaltstack().
*/
next = find_next_ret_chain(ri);
- valid = !next || arch_uretprobe_is_alive(next, regs);
+ valid = !next || arch_uretprobe_is_alive(next, RP_CHECK_RET,
regs);
instruction_pointer_set(regs, ri->orig_ret_vaddr);
do {
@@ -1830,7 +1832,8 @@ bool __weak arch_uprobe_ignore(struct arch_uprobe *aup,
struct pt_regs *regs)
return false;
}
-bool __weak arch_uretprobe_is_alive(struct return_instance *ret, struct
pt_regs *regs)
+bool __weak arch_uretprobe_is_alive(struct return_instance *ret, enum rp_check
ctx,
+ struct pt_regs *regs)
{
return true;
}
--
1.5.5.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 11/11] uprobes/x86: Make arch_uretprobe_is_alive(RP_CHECK_CALL) more clever
The previous change documents that cleanup_return_instances() can't
always detect the dead frames, the stack can grow. But there is one
special case which imho worth fixing: arch_uretprobe_is_alive() can
return true when the stack didn't actually grow, but the next "call"
insn uses the already invalidated frame.
Test-case:
#include
#include
jmp_buf jmp;
int nr = 1024;
void func_2(void)
{
if (--nr == 0)
return;
longjmp(jmp, 1);
}
void func_1(void)
{
setjmp(jmp);
func_2();
}
int main(void)
{
func_1();
return 0;
}
If you ret-probe func_1() and func_2() prepare_uretprobe() hits the
MAX_URETPROBE_DEPTH limit and "return" from func_2() is not reported.
When we know that the new call is not chained, we can do the more
strict check. In this case "sp" points to the new ret-addr, so every
frame which uses the same "sp" must be dead. The only complication is
that arch_uretprobe_is_alive() needs to know was it chained or not, so
we add the new RP_CHECK_CHAIN_CALL enum and change prepare_uretprobe()
to pass RP_CHECK_CALL only if !chained.
Note: arch_uretprobe_is_alive() could also re-read *sp and check if
this word is still trampoline_vaddr. This could obviously improve the
logic, but I would like to avoid another copy_from_user() especially
in the case when we can't avoid the false "alive == T" positives.
Signed-off-by: Oleg Nesterov
---
arch/x86/kernel/uprobes.c |5 -
include/linux/uprobes.h |1 +
kernel/events/uprobes.c | 14 +++---
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 67eb168..a5c59f2 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -997,5 +997,8 @@ arch_uretprobe_hijack_return_addr(unsigned long
trampoline_vaddr, struct pt_regs
bool arch_uretprobe_is_alive(struct return_instance *ret, enum rp_check ctx,
struct pt_regs *regs)
{
- return regs->sp <= ret->stack;
+ if (ctx == RP_CHECK_CALL) /* sp was just decremented by "call" insn */
+ return regs->sp < ret->stack;
+ else
+ return regs->sp <= ret->stack;
}
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index c0a5402..0bdc72f 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -104,6 +104,7 @@ struct return_instance {
enum rp_check {
RP_CHECK_CALL,
+ RP_CHECK_CHAIN_CALL,
RP_CHECK_RET,
};
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index df5661a..0f370ef 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1511,10 +1511,11 @@ static unsigned long get_trampoline_vaddr(void)
return trampoline_vaddr;
}
-static void cleanup_return_instances(struct uprobe_task *utask, struct pt_regs
*regs)
+static void cleanup_return_instances(struct uprobe_task *utask, bool chained,
+ struct pt_regs *regs)
{
struct return_instance *ri = utask->return_instances;
- enum rp_check ctx = RP_CHECK_CALL;
+ enum rp_check ctx = chained ? RP_CHECK_CHAIN_CALL : RP_CHECK_CALL;
while (ri && !arch_uretprobe_is_alive(ri, ctx, regs)) {
ri = free_ret_instance(ri);
@@ -1528,7 +1529,7 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
struct return_instance *ri;
struct uprobe_task *utask;
unsigned long orig_ret_vaddr, trampoline_vaddr;
- bool chained = false;
+ bool chained;
if (!get_xol_area())
return;
@@ -1554,14 +1555,15 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
goto fail;
/* drop the entries invalidated by longjmp() */
- cleanup_return_instances(utask, regs);
+ chained = (orig_ret_vaddr == trampoline_vaddr);
+ cleanup_return_instances(utask, chained, regs);
/*
* We don't want to keep trampoline address in stack, rather keep the
* original return address of first caller thru all the consequent
* instances. This also makes breakpoint unwrapping easier.
*/
- if (orig_ret_vaddr == trampoline_vaddr) {
+ if (chained) {
if (!utask->return_instances) {
/*
* This situation is not possible. Likely we have an
@@ -1570,8 +1572,6 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
uprobe_warn(current, "handle tail call");
goto fail;
}
-
- chained = true;
orig_ret_vaddr = utask->return_instances->orig_ret_vaddr;
}
--
1.5.5.1
--
To unsubscribe from this
[PATCH v2 09/11] uprobes: Change prepare_uretprobe() to (try to) flush the dead frames
Change prepare_uretprobe() to flush the !arch_uretprobe_is_alive()
return_instance's. This is not needed correctness-wise, but can help
to avoid the failure caused by MAX_URETPROBE_DEPTH.
Note: in this case arch_uretprobe_is_alive() can be false positive,
the stack can grow after longjmp(). Unfortunately, the kernel can't
100% solve this problem, but see the next patch.
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 93d939c..7e61c8c 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1511,6 +1511,16 @@ static unsigned long get_trampoline_vaddr(void)
return trampoline_vaddr;
}
+static void cleanup_return_instances(struct uprobe_task *utask, struct pt_regs
*regs)
+{
+ struct return_instance *ri = utask->return_instances;
+ while (ri && !arch_uretprobe_is_alive(ri, regs)) {
+ ri = free_ret_instance(ri);
+ utask->depth--;
+ }
+ utask->return_instances = ri;
+}
+
static void prepare_uretprobe(struct uprobe *uprobe, struct pt_regs *regs)
{
struct return_instance *ri;
@@ -1541,6 +1551,9 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
if (orig_ret_vaddr == -1)
goto fail;
+ /* drop the entries invalidated by longjmp() */
+ cleanup_return_instances(utask, regs);
+
/*
* We don't want to keep trampoline address in stack, rather keep the
* original return address of first caller thru all the consequent
--
1.5.5.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 03/11] uprobes: Send SIGILL if handle_trampoline() fails
1. It doesn't make sense to continue if handle_trampoline() fails,
change handle_swbp() to always return after this call.
2. Turn pr_warn() into uprobe_warn(), and change handle_trampoline()
to send SIGILL on failure. It is pointless to return to user mode
with the corrupted instruction_pointer() which we can't restore.
Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
---
kernel/events/uprobes.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index d8c702f..eabdc21 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1770,7 +1770,7 @@ handle_uretprobe_chain(struct return_instance *ri, struct
pt_regs *regs)
up_read(>register_rwsem);
}
-static bool handle_trampoline(struct pt_regs *regs)
+static void handle_trampoline(struct pt_regs *regs)
{
struct uprobe_task *utask;
struct return_instance *ri;
@@ -1778,11 +1778,11 @@ static bool handle_trampoline(struct pt_regs *regs)
utask = current->utask;
if (!utask)
- return false;
+ goto sigill;
ri = utask->return_instances;
if (!ri)
- return false;
+ goto sigill;
/*
* TODO: we should throw out return_instance's invalidated by
@@ -1804,8 +1804,12 @@ static bool handle_trampoline(struct pt_regs *regs)
}
utask->return_instances = ri;
+ return;
+
+ sigill:
+ uprobe_warn(current, "handle uretprobe, sending SIGILL.");
+ force_sig_info(SIGILL, SEND_SIG_FORCED, current);
- return true;
}
bool __weak arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs)
@@ -1824,13 +1828,8 @@ static void handle_swbp(struct pt_regs *regs)
int uninitialized_var(is_swbp);
bp_vaddr = uprobe_get_swbp_addr(regs);
- if (bp_vaddr == get_trampoline_vaddr()) {
- if (handle_trampoline(regs))
- return;
-
- pr_warn("uprobe: unable to handle uretprobe pid/tgid=%d/%d\n",
- current->pid, current->tgid);
- }
+ if (bp_vaddr == get_trampoline_vaddr())
+ return handle_trampoline(regs);
uprobe = find_active_uprobe(bp_vaddr, _swbp);
if (!uprobe) {
--
1.5.5.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 01/11] uprobes: Introduce get_uprobe()
Cosmetic. Add the new trivial helper, get_uprobe(). It matches
put_uprobe() we already have and we can simplify a couple of its
users.
Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
---
kernel/events/uprobes.c | 39 ---
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index cb346f2..a9847b4 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -366,6 +366,18 @@ set_orig_insn(struct arch_uprobe *auprobe, struct
mm_struct *mm, unsigned long v
return uprobe_write_opcode(mm, vaddr, *(uprobe_opcode_t
*)>insn);
}
+static struct uprobe *get_uprobe(struct uprobe *uprobe)
+{
+ atomic_inc(>ref);
+ return uprobe;
+}
+
+static void put_uprobe(struct uprobe *uprobe)
+{
+ if (atomic_dec_and_test(>ref))
+ kfree(uprobe);
+}
+
static int match_uprobe(struct uprobe *l, struct uprobe *r)
{
if (l->inode < r->inode)
@@ -393,10 +405,8 @@ static struct uprobe *__find_uprobe(struct inode *inode,
loff_t offset)
while (n) {
uprobe = rb_entry(n, struct uprobe, rb_node);
match = match_uprobe(, uprobe);
- if (!match) {
- atomic_inc(>ref);
- return uprobe;
- }
+ if (!match)
+ return get_uprobe(uprobe);
if (match < 0)
n = n->rb_left;
@@ -432,10 +442,8 @@ static struct uprobe *__insert_uprobe(struct uprobe
*uprobe)
parent = *p;
u = rb_entry(parent, struct uprobe, rb_node);
match = match_uprobe(uprobe, u);
- if (!match) {
- atomic_inc(>ref);
- return u;
- }
+ if (!match)
+ return get_uprobe(u);
if (match < 0)
p = >rb_left;
@@ -472,12 +480,6 @@ static struct uprobe *insert_uprobe(struct uprobe *uprobe)
return u;
}
-static void put_uprobe(struct uprobe *uprobe)
-{
- if (atomic_dec_and_test(>ref))
- kfree(uprobe);
-}
-
static struct uprobe *alloc_uprobe(struct inode *inode, loff_t offset)
{
struct uprobe *uprobe, *cur_uprobe;
@@ -1039,14 +1041,14 @@ static void build_probe_list(struct inode *inode,
if (u->inode != inode || u->offset < min)
break;
list_add(>pending_list, head);
- atomic_inc(>ref);
+ get_uprobe(u);
}
for (t = n; (t = rb_next(t)); ) {
u = rb_entry(t, struct uprobe, rb_node);
if (u->inode != inode || u->offset > max)
break;
list_add(>pending_list, head);
- atomic_inc(>ref);
+ get_uprobe(u);
}
}
spin_unlock(_treelock);
@@ -1437,7 +1439,7 @@ static int dup_utask(struct task_struct *t, struct
uprobe_task *o_utask)
return -ENOMEM;
*n = *o;
- atomic_inc(>uprobe->ref);
+ get_uprobe(n->uprobe);
n->next = NULL;
*p = n;
@@ -1565,8 +1567,7 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
orig_ret_vaddr = utask->return_instances->orig_ret_vaddr;
}
- atomic_inc(>ref);
- ri->uprobe = uprobe;
+ ri->uprobe = get_uprobe(uprobe);
ri->func = instruction_pointer(regs);
ri->orig_ret_vaddr = orig_ret_vaddr;
ri->chained = chained;
--
1.5.5.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 07/11] uprobes/x86: Reimplement arch_uretprobe_is_alive()
Add the x86-specific version of arch_uretprobe_is_alive() helper.
It returns true if the stack frame mangled by prepare_uretprobe()
is still on stack. So if it returns false, we know that the probed
function has already returned.
We add the new return_instance->stack member and change the generic
code to initialize it in prepare_uretprobe, but it should be equally
useful for other architectures.
TODO: this assumes that the probed application can't use multiple
stacks (say sigaltstack). We will try to improve this logic later.
Signed-off-by: Oleg Nesterov
---
arch/x86/kernel/uprobes.c |5 +
include/linux/uprobes.h |1 +
kernel/events/uprobes.c |1 +
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 0b81ad6..9d5f570 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -993,3 +993,8 @@ arch_uretprobe_hijack_return_addr(unsigned long
trampoline_vaddr, struct pt_regs
return -1;
}
+
+bool arch_uretprobe_is_alive(struct return_instance *ret, struct pt_regs *regs)
+{
+ return regs->sp <= ret->stack;
+}
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 50d2764..7ab6d2c 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -95,6 +95,7 @@ struct uprobe_task {
struct return_instance {
struct uprobe *uprobe;
unsigned long func;
+ unsigned long stack; /* stack pointer */
unsigned long orig_ret_vaddr; /* original return address */
boolchained;/* true, if instance is nested
*/
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 1c71b62..c5f316e 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1562,6 +1562,7 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
ri->uprobe = get_uprobe(uprobe);
ri->func = instruction_pointer(regs);
+ ri->stack = user_stack_pointer(regs);
ri->orig_ret_vaddr = orig_ret_vaddr;
ri->chained = chained;
--
1.5.5.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 04/11] uprobes: Change prepare_uretprobe() to use uprobe_warn()
Turn the last pr_warn() in uprobes.c into uprobe_warn().
While at it:
- s/kzalloc/kmalloc, we initialize every member of ri
- remove the pointless comment above the obvious code
Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
---
kernel/events/uprobes.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index eabdc21..4c941fe 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1541,9 +1541,9 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
return;
}
- ri = kzalloc(sizeof(struct return_instance), GFP_KERNEL);
+ ri = kmalloc(sizeof(struct return_instance), GFP_KERNEL);
if (!ri)
- goto fail;
+ return;
trampoline_vaddr = get_trampoline_vaddr();
orig_ret_vaddr = arch_uretprobe_hijack_return_addr(trampoline_vaddr,
regs);
@@ -1561,8 +1561,7 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
* This situation is not possible. Likely we have an
* attack from user-space.
*/
- pr_warn("uprobe: unable to set uretprobe
pid/tgid=%d/%d\n",
- current->pid, current->tgid);
+ uprobe_warn(current, "handle tail call");
goto fail;
}
@@ -1576,13 +1575,10 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
ri->chained = chained;
utask->depth++;
-
- /* add instance to the stack */
ri->next = utask->return_instances;
utask->return_instances = ri;
return;
-
fail:
kfree(ri);
}
--
1.5.5.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 00/11] uprobes: longjmp fixes
Sorry for delay, Currently ret-probes can't work (the application will likely crash) if the probed function does not return, and this is even documented in handle_trampoline(). This series tries to make the first step to fix the problem, assuming that the probed functions use the same stack. TODO: sigaltstack() can obviously break this assumption. NOTE: I don't think it is possible to make this logic 100% correct, the user-space can do everything with its stack. For example, the application can do longjmp-like tricks to implement the coroutines, the kernel can do nothing in this case. The application (or debugger) should cooperate somehow to let the kernel know whats going on. v2, based on disccsussion with Srikar and Pratyush: 1-5: Unchanged, I preserved the acks from Srikar. 6-11: The only essential change is that we do not add the (ugly) arch_uretprobe, we just export return_instance to arch/. This means that we do not need to touch the !x86 code, and return_instance->stack can be initialized by the generic code. Srikar, I hope you can ack v2 too. 10/11: New. As Pratyush pointed out "bool on_call" is too limited. Plus v2 fixes the problem mentioned in "self nack" email, we must not do cleanup_return_instances() after prepare_uretprobe() checks chained && utask->return_instances != NULL. Oleg. arch/x86/kernel/uprobes.c |9 ++ include/linux/uprobes.h | 17 kernel/events/uprobes.c | 184 + 3 files changed, 128 insertions(+), 82 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 v2] mm: nommu: fix typos in comment blocks
Hi Paul 2015-07-07 4:25 GMT+09:00 Paul Gortmaker : > [[PATCH v2] mm: nommu: fix typos in comment blocks] On 06/07/2015 (Mon 13:01) > Masahiro Yamada wrote: > >> continguos -> contiguous >> >> Signed-off-by: Masahiro Yamada > > I'd suggested this go via the trivial tree, but instead I see it is in > my inbox now, and still in everyone else's inbox, and yet not Cc'd to > the trivial tree, which leaves me confused... > > Paul. I found more misspelled "contiguous" in other files, so this patch has been replaced with the following: https://lkml.org/lkml/2015/7/6/954 The new one has been sent to Jiri Kosina. -- Best Regards Masahiro Yamada -- 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] suspend: delete sys_sync()
On Mon, Jul 06, 2015 at 03:52:25PM +0200, Rafael J. Wysocki wrote: > On Monday, July 06, 2015 10:06:14 AM Dave Chinner wrote: > > On Sat, Jul 04, 2015 at 03:03:46AM +0200, Rafael J. Wysocki wrote: > > > > No, your observation was that "sync is slow". Your *solution* is "we > > > > need to remove sync". > > > > > > Not only slow, but pointless too. The argument goes: "It is slow and > > > pointless and so it may be dropped." > > > > > > Now, I can agree that it wasn't clearly demonstrated that the > > > unconditional > > > sys_sync() in the suspend code path was pointless, but it also has never > > > been clearly shown why it is not pointless on systems that suspend and > > > resume > > > reliably. > > > > I just gave you an example of why sync is needed: Suspend, pull out > > USB drive when putting laptop in bag. > > Exactly the same thing can happen while not suspended. What does make suspend > special with respect to that? Stop being obtuse. If you remember that you need to pull the USB stick before you suspend, then you damn well remember to "safely eject" the USB stick and that syncs, unmounts and flushes the drive caches before telling you it is safe to pull the stick. > > > Moreover, question is if we really need to carry out the sync on *every* > > > suspend even if it is not pointless overall. That shouldn't really be > > > necessary if we suspend and resume often enough or if we resume only for > > > a while and then suspend again. Maybe it should be rate limited somehow > > > at least? > > > > If you suspend and resume frequently, then the cost of the sync > > shoul dbe negliable because the amount of data dirtied between > > resume/suspend shoul dbe negliable. hence my questions about where > > sync is spending too much time, and whether we've actually fixed > > those problems or not. If sync speed on clean filesystems is a > > problem then we need to fix sync, not work around it. > > Well, say you never suspend, but you also only shut down the system when you > need to replace the kernel on it. How often would you invoke global sync on > that system? Never, because: - the kernel does background writeback of dirty data so you don't need to run sync while the system is running; and - unmount during shutdown runs sync_filesystem() internally (just like sys_sync does) to ensure the filesystem is clean and no data is lost. Seriously, stop being making ignorant arguments to justify removing sys_sync(). *If* there's a problem sys_sync() we need to *fix it*, not ignore it. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
On 07/07/2015 05:52 AM, Michael Ellerman wrote: > On Tue, 2015-07-07 at 01:39 +0530, Shreyas B. Prabhu wrote: >> Signed-off-by: Shreyas B. Prabhu >> Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline >> cpus' > > The sha is wrong, it should be 77b54e9f213f. > Argh! Sorry > Also please don't wrap the description. > > I recommend creating an alias or script that does: > > $ git log --pretty=fixes -n 1 $commit | xclip > Will use this from next time. > > I've fixed it up, no need to resend. > Thanks! --Shreyas -- 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] trivial: fix typos in comment blocks
Looks like the word "contiguous" is often mistyped.
Signed-off-by: Masahiro Yamada
---
Hi Jiri,
Please consider applying this into your trivial.git tree
Thanks,
arch/mips/kernel/setup.c | 2 +-
drivers/gpio/gpiolib-acpi.c | 2 +-
drivers/gpu/drm/via/via_dmablit.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +-
drivers/media/platform/exynos4-is/fimc-m2m.c | 2 +-
drivers/media/v4l2-core/videobuf2-memops.c | 2 +-
drivers/net/ethernet/amd/xgbe/xgbe.h | 2 +-
drivers/net/wireless/ath/ath6kl/wmi.c| 4 ++--
drivers/usb/gadget/udc/bdc/bdc.h | 2 +-
fs/ocfs2/ocfs2_fs.h | 4 ++--
include/media/videobuf-core.h| 2 +-
mm/nommu.c | 10 +-
12 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index be73c49..82419f2 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -479,7 +479,7 @@ static void __init bootmem_init(void)
* o bootmem_init()
* o sparse_init()
* o paging_init()
- * o dma_continguous_reserve()
+ * o dma_contiguous_reserve()
*
* At this stage the bootmem allocator is ready to use.
*
diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index 533fe5d..143a9bd 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -68,7 +68,7 @@ static int acpi_gpiochip_find(struct gpio_chip *gc, void
*data)
* GPIO controller driver.
*
* Typically the returned offset is same as @pin, but if the GPIO
- * controller uses pin controller and the mapping is not contigous the
+ * controller uses pin controller and the mapping is not contiguous the
* offset might be different.
*/
static int acpi_gpiochip_pin_to_gpio_offset(struct gpio_chip *chip, int pin)
diff --git a/drivers/gpu/drm/via/via_dmablit.c
b/drivers/gpu/drm/via/via_dmablit.c
index ba33cf6..d0cbd5e 100644
--- a/drivers/gpu/drm/via/via_dmablit.c
+++ b/drivers/gpu/drm/via/via_dmablit.c
@@ -260,7 +260,7 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,
drm_via_dmablit_t *xfer)
/*
* Allocate DMA capable memory for the blit descriptor chain, and an array
that keeps track of the
* pages we allocate. We don't want to use kmalloc for the descriptor chain
because it may be
- * quite large for some blits, and pages don't need to be contingous.
+ * quite large for some blits, and pages don't need to be contiguous.
*/
static int
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index d26a6da..0336d49 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -227,7 +227,7 @@ enum vmw_dma_map_mode {
* device-specific information.
*
* @sgt: Pointer to a struct sg_table with binding information
- * @num_regions: Number of regions with device-address contigous pages
+ * @num_regions: Number of regions with device-address contiguous pages
*/
struct vmw_sg_table {
enum vmw_dma_map_mode mode;
diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c
b/drivers/media/platform/exynos4-is/fimc-m2m.c
index 0ad1b6f..d2bfe7c 100644
--- a/drivers/media/platform/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/exynos4-is/fimc-m2m.c
@@ -188,7 +188,7 @@ static int fimc_queue_setup(struct vb2_queue *vq, const
struct v4l2_format *fmt,
if (IS_ERR(f))
return PTR_ERR(f);
/*
-* Return number of non-contigous planes (plane buffers)
+* Return number of non-contiguous planes (plane buffers)
* depending on the configured color format.
*/
if (!f->fmt)
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c
b/drivers/media/v4l2-core/videobuf2-memops.c
index 81c1ad8..0d49b79 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -125,7 +125,7 @@ int vb2_get_contig_userptr(unsigned long vaddr, unsigned
long size,
}
/*
-* Memory is contigous, lock vma and return to the caller
+* Memory is contiguous, lock vma and return to the caller
*/
*res_vma = vb2_get_vma(vma);
if (*res_vma == NULL)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe.h
b/drivers/net/ethernet/amd/xgbe/xgbe.h
index 63d72a1..88721d2 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe.h
+++ b/drivers/net/ethernet/amd/xgbe/xgbe.h
@@ -140,7 +140,7 @@
#define XGBE_TX_MAX_BUF_SIZE (0x3fff & ~(64 - 1))
-/* Descriptors required for maximum contigous TSO/GSO packet */
+/* Descriptors required for maximum contiguous TSO/GSO packet */
#define XGBE_TX_MAX_SPLIT ((GSO_MAX_SIZE / XGBE_TX_MAX_BUF_SIZE) + 1)
/* Maximum possible descriptors needed for an SKB:
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c
b/drivers/net/wireless/ath/ath6kl/wmi.c
index b921005..a5e1de7 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
[PATCH v2] sched: separate operations only for SMP from account_entity_en(de)queue
From: Byungchul Park
manipulating rq->cfs_tasks and numa-accounting are not meaningless on !SMP.
separate the operations from account_entity_en(de)queue.
Signed-off-by: Byungchul Park
---
kernel/sched/fair.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 09456fc..a22f255 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2314,20 +2314,36 @@ static inline void account_numa_dequeue(struct rq *rq,
struct task_struct *p)
}
#endif /* CONFIG_NUMA_BALANCING */
+#ifdef CONFIG_SMP
+static void account_task_enqueue(struct rq *rq, struct sched_entity *se)
+{
+ account_numa_enqueue(rq, task_of(se));
+ list_add(>group_node, >cfs_tasks);
+}
+
+static void account_task_dequeue(struct rq *rq, struct sched_entity *se)
+{
+ account_numa_dequeue(rq, task_of(se));
+ list_del_init(>group_node);
+}
+#else
+static inline void account_task_enqueue(struct rq *rq, struct sched_entity *se)
+{
+}
+
+static inline void account_task_dequeue(struct rq *rq, struct sched_entity *se)
+{
+}
+#endif /* CONFIG_SMP */
+
static void
account_entity_enqueue(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
update_load_add(_rq->load, se->load.weight);
if (!parent_entity(se))
update_load_add(_of(cfs_rq)->load, se->load.weight);
-#ifdef CONFIG_SMP
- if (entity_is_task(se)) {
- struct rq *rq = rq_of(cfs_rq);
-
- account_numa_enqueue(rq, task_of(se));
- list_add(>group_node, >cfs_tasks);
- }
-#endif
+ if (entity_is_task(se))
+ account_task_enqueue(rq_of(cfs_rq), se);
cfs_rq->nr_running++;
}
@@ -2337,15 +2353,13 @@ account_entity_dequeue(struct cfs_rq *cfs_rq, struct
sched_entity *se)
update_load_sub(_rq->load, se->load.weight);
if (!parent_entity(se))
update_load_sub(_of(cfs_rq)->load, se->load.weight);
- if (entity_is_task(se)) {
- account_numa_dequeue(rq_of(cfs_rq), task_of(se));
- list_del_init(>group_node);
- }
+ if (entity_is_task(se))
+ account_task_dequeue(rq_of(cfs_rq), se);
cfs_rq->nr_running--;
}
#ifdef CONFIG_FAIR_GROUP_SCHED
-# ifdef CONFIG_SMP
+#ifdef CONFIG_SMP
static inline long calc_tg_weight(struct task_group *tg, struct cfs_rq *cfs_rq)
{
long tg_weight;
--
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] pinctrl: qcom: Hook pm_power_down for shutdown support
Assign pm_power_off() if we have the PS_HOLD functionality so
that we can properly shutdown the SoC. Otherwise, shutdown won't
do anything besides put the CPU into a tight loop. Unfortunately,
we have to use a singleton here because pm_power_off() doesn't
take any arguments. Fortunately there's only one instance of the
pinctrl device on a running system so this isn't a problem.
Cc: Bjorn Andersson
Cc: Pramod Gurav
Signed-off-by: Stephen Boyd
---
drivers/pinctrl/qcom/pinctrl-msm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index e457d52302a2..6242af8a42d5 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "../core.h"
#include "../pinconf.h"
@@ -855,6 +856,13 @@ static int msm_ps_hold_restart(struct notifier_block *nb,
unsigned long action,
return NOTIFY_DONE;
}
+static struct msm_pinctrl *poweroff_pctrl;
+
+static void msm_ps_hold_poweroff(void)
+{
+ msm_ps_hold_restart(_pctrl->restart_nb, 0, NULL);
+}
+
static void msm_pinctrl_setup_pm_reset(struct msm_pinctrl *pctrl)
{
int i;
@@ -867,6 +875,8 @@ static void msm_pinctrl_setup_pm_reset(struct msm_pinctrl
*pctrl)
if (register_restart_handler(>restart_nb))
dev_err(pctrl->dev,
"failed to setup restart handler.\n");
+ poweroff_pctrl = pctrl;
+ pm_power_off = msm_ps_hold_poweroff;
break;
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: pmic8xxx-pwrkey - Support shutdown
On pm8xxx PMICs, shutdown and restart are signaled to the PMIC
via a pin called PS_HOLD. When this pin goes low, the PMIC
performs a configurable power sequence. Add a .shutdown hook so
that we can properly configure this power sequence for shutdown
or restart depending on the system state.
Signed-off-by: Stephen Boyd
---
drivers/input/misc/pmic8xxx-pwrkey.c | 287 ++-
1 file changed, 280 insertions(+), 7 deletions(-)
diff --git a/drivers/input/misc/pmic8xxx-pwrkey.c
b/drivers/input/misc/pmic8xxx-pwrkey.c
index c4ca20e63221..ce0492031bc3 100644
--- a/drivers/input/misc/pmic8xxx-pwrkey.c
+++ b/drivers/input/misc/pmic8xxx-pwrkey.c
@@ -20,17 +20,75 @@
#include
#include
#include
+#include
#define PON_CNTL_1 0x1C
#define PON_CNTL_PULL_UP BIT(7)
#define PON_CNTL_TRIG_DELAY_MASK (0x7)
+#define PON_CNTL_1_PULL_UP_EN 0xe0
+#define PON_CNTL_1_USB_PWR_EN 0x10
+#define PON_CNTL_1_WD_EN_RESET 0x08
+
+#define PM8058_SLEEP_CTRL 0x02b
+#define PM8921_SLEEP_CTRL 0x10a
+
+#define SLEEP_CTRL_SMPL_EN_RESET 0x04
+
+/* Regulator master enable addresses */
+#define REG_PM8058_VREG_EN_MSM 0x018
+#define REG_PM8058_VREG_EN_GRP_5_4 0x1C8
+
+/* Regulator control registers for shutdown/reset */
+#define PM8058_S0_CTRL 0x004
+#define PM8058_S1_CTRL 0x005
+#define PM8058_S3_CTRL 0x111
+#define PM8058_L21_CTRL0x120
+#define PM8058_L22_CTRL0x121
+
+#define PM8058_REGULATOR_ENABLE_MASK 0x80
+#define PM8058_REGULATOR_ENABLE0x80
+#define PM8058_REGULATOR_DISABLE 0x00
+#define PM8058_REGULATOR_PULL_DOWN_MASK0x40
+#define PM8058_REGULATOR_PULL_DOWN_EN 0x40
+
+/* Buck CTRL register */
+#define PM8058_SMPS_LEGACY_VREF_SEL0x20
+#define PM8058_SMPS_LEGACY_VPROG_MASK 0x1F
+#define PM8058_SMPS_ADVANCED_BAND_MASK 0xC0
+#define PM8058_SMPS_ADVANCED_BAND_SHIFT6
+#define PM8058_SMPS_ADVANCED_VPROG_MASK0x3F
+
+/* Buck TEST2 registers for shutdown/reset */
+#define PM8058_S0_TEST20x084
+#define PM8058_S1_TEST20x085
+#define PM8058_S3_TEST20x11A
+
+#define PM8058_REGULATOR_BANK_WRITE0x80
+#define PM8058_REGULATOR_BANK_MASK 0x70
+#define PM8058_REGULATOR_BANK_SHIFT4
+#define PM8058_REGULATOR_BANK_SEL(n) ((n) << PM8058_REGULATOR_BANK_SHIFT)
+
+/* Buck TEST2 register bank 1 */
+#define PM8058_SMPS_LEGACY_VLOW_SEL0x01
+
+/* Buck TEST2 register bank 7 */
+#define PM8058_SMPS_ADVANCED_MODE_MASK 0x02
+#define PM8058_SMPS_ADVANCED_MODE 0x02
+#define PM8058_SMPS_LEGACY_MODE0x00
/**
* struct pmic8xxx_pwrkey - pmic8xxx pwrkey information
* @key_press_irq: key press irq number
+ * @regmap: device regmap
*/
struct pmic8xxx_pwrkey {
int key_press_irq;
+ struct regmap *regmap;
+ int (*shutdown_fn)(struct pmic8xxx_pwrkey *, bool);
+};
+
+struct pm8xxx_nbs {
+ int (*shutdown_fn)(struct pmic8xxx_pwrkey *, bool);
};
static irqreturn_t pwrkey_press_irq(int irq, void *_pwr)
@@ -76,6 +134,220 @@ static int __maybe_unused pmic8xxx_pwrkey_resume(struct
device *dev)
static SIMPLE_DEV_PM_OPS(pm8xxx_pwr_key_pm_ops,
pmic8xxx_pwrkey_suspend, pmic8xxx_pwrkey_resume);
+static void pmic8xxx_pwrkey_shutdown(struct platform_device *pdev)
+{
+ struct pmic8xxx_pwrkey *pwrkey = platform_get_drvdata(pdev);
+ int ret;
+ u8 mask, val;
+ bool reset = system_state == SYSTEM_RESTART;
+
+ if (pwrkey->shutdown_fn) {
+ ret = pwrkey->shutdown_fn(pwrkey, reset);
+ if (ret)
+ return;
+ }
+
+ /*
+* Select action to perform (reset or shutdown) when PS_HOLD goes low.
+* Also ensure that KPD, CBL0, and CBL1 pull ups are enabled and that
+* USB charging is enabled.
+*/
+ mask = PON_CNTL_1_PULL_UP_EN | PON_CNTL_1_USB_PWR_EN;
+ mask |= PON_CNTL_1_WD_EN_RESET;
+ val = mask;
+ if (!reset)
+ val &= ~PON_CNTL_1_WD_EN_RESET;
+
+ regmap_update_bits(pwrkey->regmap, PON_CNTL_1, mask, val);
+}
+
+/*
+ * Set an SMPS regulator to be disabled in its CTRL register, but enabled
+ * in the master enable register. Also set it's pull down enable bit.
+ * Take care to make sure that the output voltage doesn't change if switching
+ * from advanced mode to legacy mode.
+ */
+static int pm8058_disable_smps_locally_set_pull_down(struct regmap *regmap,
+ u16 ctrl_addr, u16 test2_addr, u16 master_enable_addr,
+ u8 master_enable_bit)
+{
+ int ret = 0;
+
[PATCH] block/blk-cgroup.c: free per-blkcg data when freeing the blkcg
Currently, per-blkcg data is freed each time a policy is deactivated,
that is also upon scheduler switch. However, when switching from a
scheduler implementing a policy which requires per-blkcg data to
another one, that same policy might be active on other devices, and
therefore those same per-blkcg data could be still in use.
This commit lets per-blkcg data be freed when the blkcg is freed
instead of on policy deactivation.
Signed-off-by: Arianna Avanzini
Reported-and-tested-by: Michael Kaminsky
Fixes: e48453c3 ("block, cgroup: implement policy-specific per-blkcg data")
---
block/blk-cgroup.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 9f97da5..5e2723f 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -822,8 +822,13 @@ static void blkcg_css_free(struct cgroup_subsys_state *css)
{
struct blkcg *blkcg = css_to_blkcg(css);
- if (blkcg != _root)
+ if (blkcg != _root) {
+ int i;
+
+ for (i = 0; i < BLKCG_MAX_POLS; i++)
+ kfree(blkcg->pd[i]);
kfree(blkcg);
+ }
}
static struct cgroup_subsys_state *
@@ -1162,8 +1167,6 @@ void blkcg_deactivate_policy(struct request_queue *q,
kfree(blkg->pd[pol->plid]);
blkg->pd[pol->plid] = NULL;
- kfree(blkg->blkcg->pd[pol->plid]);
- blkg->blkcg->pd[pol->plid] = NULL;
spin_unlock(>blkcg->lock);
}
--
2.1.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/
