Re: kernel BUG at kernel/smpboot.c:134!
On Sat, 6 Apr 2013, Thomas Gleixner wrote: This is Hillfs proposed patch: --- a/kernel/kthread.c Sat Jan 19 13:03:52 2013 +++ b/kernel/kthread.c Sat Jan 19 13:17:54 2013 @@ -306,6 +306,7 @@ struct task_struct *kthread_create_on_cp return p; set_bit(KTHREAD_IS_PER_CPU, to_kthread(p)-flags); to_kthread(p)-cpu = cpu; + __kthread_bind(p, cpu); /* Park the thread to get it out of TASK_UNINTERRUPTIBLE state */ kthread_park(p); return p; That's bogus. Simply because when we create the thread then the thread And it's even more bogus because the cpu to which we would bind in kthread_create_on_cpu() is not yet online. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Drivers: Base: Regmap: fix warnings, use %lu instead of %d for printf format
On 2013年04月07日 17:08, Bjørn Mork wrote: Chen Gang gang.c...@asianux.com writes: fix warnings (with EXTRA_CFLAGS=-W): format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] Signed-off-by: Chen Gang gang.c...@asianux.com --- drivers/base/regmap/regcache.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c index d81f605..275a2d2 100644 --- a/drivers/base/regmap/regcache.c +++ b/drivers/base/regmap/regcache.c @@ -590,7 +590,7 @@ static int regcache_sync_block_raw_flush(struct regmap *map, const void **data, count = cur - base; - dev_dbg(map-dev, Writing %d bytes for %d registers from 0x%x-0x%x\n, + dev_dbg(map-dev, Writing %lu bytes for %d registers from 0x%x-0x%x\n, count * val_bytes, count, base, cur - 1); map-cache_bypass = 1; Please read Documentation/printk-formats.txt. Thanks. thanks, I will send patch v2 (I should use %zu instead of %lu) :-) Bjørn -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] kvm: add PV MMIO EVENTFD
On Thu, Apr 04, 2013 at 04:32:01PM -0700, Christoffer Dall wrote: [...] to give us some idea how much performance we would gain from each approach? Thoughput should be completely unaffected anyway, since virtio just coalesces kicks internally. Latency is dominated by the scheduling latency. This means virtio-net is not the best benchmark. So what is a good benchmark? E.g. ping pong stress will do but need to look at CPU utilization, that's what is affected, not latency. Is there any difference in speed at all? I strongly doubt it. One of virtio's main points is to reduce the number of kicks. For this stage of the project I think microbenchmarks are more appropriate. Doubling the price of exit is likely to be measureable. 30 cycles likely not ... I don't quite understand this point here. If we don't have anything real-world where we can measure a decent difference, then why are we doing this? I would agree with Alex that the three test scenarios proposed by him should be tried out before adding this complexity, measured in CPU utilization or latency as you wish. Sure, plan to do real world benchmarks for PV MMIO versus PIO as well. I don't see why I should bother implementing hypercalls given that the kvm maintainer says they won't be merged. FWIW, ARM always uses MMIO and provides hardware decoding of all sane (not user register-writeback) instruction, but the hypercall vs. mmio looks like this: hvc: 4,917 mmio_kernel: 6,248 So 20% difference? That's not far from what happens on my intel laptop: vmcall 1519 outl_to_kernel 1745 10% difference here. But I doubt that an hvc wrapper around mmio decoding would take care of all this difference, because the mmio operation needs to do other work not realated to emulating the instruction in software, which you'd have to do for an hvc anyway (populate kvm_mmio structure etc.) -Christoffer Instead of speculating, someone with relevant hardware could just try this, but kvm unittest doesn't seem to have arm support at the moment. Anyone working on this? -- MST -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] kvm: add PV MMIO EVENTFD
On Thu, Apr 04, 2013 at 04:14:57PM +0300, Gleb Natapov wrote: is to move to MMIO only when PIO address space is exhausted. For PCI it will be never, for PCI-e it will be after ~16 devices. Ok, let's go back a step here. Are you actually able to measure any speed in performance with this patch applied and without when going through MMIO kicks? That's the question for MST. I think he did only micro benchmarks till now and he already posted his result here: mmio-wildcard-eventfd:pci-mem 3529 mmio-pv-eventfd:pci-mem 1878 portio-wildcard-eventfd:pci-io 1846 So the patch speedup mmio by almost 100% and it is almost the same as PIO. Those numbers don't align at all with what I measured. I am trying to run vmexit test on AMD now, but something does not work there. Next week I'll fix it and see how AMD differs, bit on Intel those are the numbers. The numbers are: vmcall 1921 inl_from_kernel 4227 outl_to_kernel 2345 outl is specifically optimized to not go through the emulator since it is used for virtio kick. mmio-pv-eventfd is the same kind of optimization but for mmio. -- Gleb. -- 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] hfs: add error checking for hfs_find_init()
Hi Alexey,
On Apr 7, 2013, at 1:13 AM, Alexey Khoroshilov wrote:
Hi Vyacheslav,
On 03/30/2013 03:35 PM, Vyacheslav Dubeyko wrote:
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
fs/hfs/catalog.c | 12 +---
fs/hfs/dir.c |8 ++--
fs/hfs/extent.c | 48 +---
fs/hfs/hfs_fs.h |2 +-
fs/hfs/inode.c | 11 +--
fs/hfs/super.c |4 +++-
6 files changed, 61 insertions(+), 24 deletions(-)
diff --git a/fs/hfs/catalog.c b/fs/hfs/catalog.c
index 424b033..9569b39 100644
--- a/fs/hfs/catalog.c
+++ b/fs/hfs/catalog.c
@@ -92,7 +92,9 @@ int hfs_cat_create(u32 cnid, struct inode *dir, struct
qstr *str, struct inode *
return -ENOSPC;
sb = dir-i_sb;
- hfs_find_init(HFS_SB(sb)-cat_tree, fd);
+ err = hfs_find_init(HFS_SB(sb)-cat_tree, fd);
+ if (err)
+ return err;
hfs_cat_build_key(sb, fd.search_key, cnid, NULL);
entry_size = hfs_cat_build_thread(sb, entry, S_ISDIR(inode-i_mode) ?
@@ -214,7 +216,9 @@ int hfs_cat_delete(u32 cnid, struct inode *dir, struct
qstr *str)
dprint(DBG_CAT_MOD, delete_cat: %s,%u\n, str ? str-name : NULL,
cnid);
sb = dir-i_sb;
- hfs_find_init(HFS_SB(sb)-cat_tree, fd);
+ res = hfs_find_init(HFS_SB(sb)-cat_tree, fd);
+ if (res)
+ return res;
hfs_cat_build_key(sb, fd.search_key, dir-i_ino, str);
res = hfs_brec_find(fd);
@@ -281,7 +285,9 @@ int hfs_cat_move(u32 cnid, struct inode *src_dir,
struct qstr *src_name,
dprint(DBG_CAT_MOD, rename_cat: %u - %lu,%s - %lu,%s\n, cnid,
src_dir-i_ino, src_name-name,
dst_dir-i_ino, dst_name-name);
sb = src_dir-i_sb;
- hfs_find_init(HFS_SB(sb)-cat_tree, src_fd);
+ err = hfs_find_init(HFS_SB(sb)-cat_tree, src_fd);
+ if (err)
+ return err;
dst_fd = src_fd;
/* find the old dir entry and read the data */
diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
index 5f7f1ab..e1c8048 100644
--- a/fs/hfs/dir.c
+++ b/fs/hfs/dir.c
@@ -25,7 +25,9 @@ static struct dentry *hfs_lookup(struct inode *dir,
struct dentry *dentry,
struct inode *inode = NULL;
int res;
- hfs_find_init(HFS_SB(dir-i_sb)-cat_tree, fd);
+ res = hfs_find_init(HFS_SB(dir-i_sb)-cat_tree, fd);
+ if (res)
+ return ERR_PTR(res);
hfs_cat_build_key(dir-i_sb, fd.search_key, dir-i_ino,
dentry-d_name);
res = hfs_brec_read(fd, rec, sizeof(rec));
if (res) {
@@ -63,7 +65,9 @@ static int hfs_readdir(struct file *filp, void *dirent,
filldir_t filldir)
if (filp-f_pos = inode-i_size)
return 0;
- hfs_find_init(HFS_SB(sb)-cat_tree, fd);
+ err = hfs_find_init(HFS_SB(sb)-cat_tree, fd);
+ if (err)
+ return err;
hfs_cat_build_key(sb, fd.search_key, inode-i_ino, NULL);
err = hfs_brec_find(fd);
if (err)
diff --git a/fs/hfs/extent.c b/fs/hfs/extent.c
index a67955a..813447b 100644
--- a/fs/hfs/extent.c
+++ b/fs/hfs/extent.c
@@ -107,7 +107,7 @@ static u16 hfs_ext_lastblock(struct hfs_extent *ext)
return be16_to_cpu(ext-block) + be16_to_cpu(ext-count);
}
-static void __hfs_ext_write_extent(struct inode *inode, struct
hfs_find_data *fd)
+static int __hfs_ext_write_extent(struct inode *inode, struct
hfs_find_data *fd)
{
int res;
@@ -116,26 +116,31 @@ static void __hfs_ext_write_extent(struct inode
*inode, struct hfs_find_data *fd
res = hfs_brec_find(fd);
if (HFS_I(inode)-flags HFS_FLG_EXT_NEW) {
if (res != -ENOENT)
- return;
+ return res;
hfs_brec_insert(fd, HFS_I(inode)-cached_extents,
sizeof(hfs_extent_rec));
HFS_I(inode)-flags = ~(HFS_FLG_EXT_DIRTY|HFS_FLG_EXT_NEW);
} else {
if (res)
- return;
+ return res;
hfs_bnode_write(fd-bnode, HFS_I(inode)-cached_extents,
fd-entryoffset, fd-entrylength);
HFS_I(inode)-flags = ~HFS_FLG_EXT_DIRTY;
}
+ return 0;
}
As I see, this fix makes sense and for hfsplus also. Please, make it and for
hfsplus.
Sorry, I did not catch which fix do you mean. Could you please clarify it.
I meant:
(1) correction the issue with returning error in __hfsplus_ext_write_extent()
method (http://lxr.free-electrons.com/source/fs/hfsplus/extents.c#L86);
(2) adding error processing in hfsplus_ext_write_extent_locked() method
(http://lxr.free-electrons.com/source/fs/hfsplus/extents.c#L132);
(3) adding error processing in __hfsplus_ext_cache_extent() method
(http://lxr.free-electrons.com/source/fs/hfsplus/extents.c#L179).
Moreover, as I remember, Hin-Tak asks about adding dprint messages.
Thanks,
Vyacheslav Dubeyko.
Thank you,
Alexey
--
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to majord...@vger.kernel.org
More
[PATCH v2] Drivers: Base: Regmap: fix warnings, use %zu instead of %d for printf format
fix warnings (with EXTRA_CFLAGS=-W): format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] Signed-off-by: Chen Gang gang.c...@asianux.com --- drivers/base/regmap/regcache.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c index d81f605..a469748 100644 --- a/drivers/base/regmap/regcache.c +++ b/drivers/base/regmap/regcache.c @@ -590,7 +590,7 @@ static int regcache_sync_block_raw_flush(struct regmap *map, const void **data, count = cur - base; - dev_dbg(map-dev, Writing %d bytes for %d registers from 0x%x-0x%x\n, + dev_dbg(map-dev, Writing %zu bytes for %d registers from 0x%x-0x%x\n, count * val_bytes, count, base, cur - 1); map-cache_bypass = 1; -- 1.7.7.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/
[PATCH 1/1] mmap.c: find_vma: eliminate initial if(mm) check
As per commit 841e31e5cc6219d62054788faa289b6ed682d068,
we dont really need this if(mm) check anymore.
A WARN_ON_ONCE was added just for safety, but there have been no bug
reports about this so far.
Removing this if(mm) check.
Signed-off-by: k80c k80ck...@gmail.com
---
mm/mmap.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 0db0de1..b2c363f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1935,9 +1935,6 @@ struct vm_area_struct *find_vma(struct mm_struct *mm,
unsigned long addr)
{
struct vm_area_struct *vma = NULL;
- if (WARN_ON_ONCE(!mm)) /* Remove this in linux-3.6 */
- return NULL;
-
/* Check the cache first. */
/* (Cache hit rate is typically around 35%.) */
vma = ACCESS_ONCE(mm-mmap_cache);
--
1.7.5.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] perf/core: Fix a warning in util/trace-event-parse.c
From: chenggang@taobao.com
While I compile the perf in Red Hat Enterprise Linux Server release 5.4
(Tikanga),
I got a warning:
CC util/trace-event-parse.o
cc1: warnings being treated as errors
util/trace-event-parse.c: In function 'parse_proc_kallsyms':
util/trace-event-parse.c:232: warning: 'fmt' may be used uninitialized in this
function
make: *** [util/trace-event-parse.o] Error 1
The version of gcc is: 4.1.2
The reason is that the local variable 'fmt' is not initialized before we use it.
It is fixed in this patch.
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
---
tools/perf/util/trace-event-parse.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/trace-event-parse.c
b/tools/perf/util/trace-event-parse.c
index 3aabcd6..630e331 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -229,7 +229,7 @@ void parse_proc_kallsyms(struct pevent *pevent,
char *next = NULL;
char *addr_str;
char *mod;
- char *fmt;
+ char *fmt = NULL;
line = strtok_r(file, \n, next);
while (line) {
--
1.5.5.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/
Portege Z830 and Tecra R840 failing to resume from suspend
Bugzilla bug: https://bugzilla.kernel.org/show_bug.cgi?id=42977 Can someone please give this bug some attention? Aaron Lu from Intel has been adding people to the bug CC list but nobody seems to be responding, and per his suggestion I'm mailing the list. The Z830 and R840 suspend successfully but do not resume without the extra udelay added by acpi_sleep=s3_beep. We haven't found any 64-bit kernel builds so far which resume successfully. As for 32-bit kernels, I haven't tested them myself, but Artur in the bugzilla (CC'd) has only successfully resumed his R840 with a 32-bit kernel. - Steven -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] kvm: add PV MMIO EVENTFD
On Sun, Apr 07, 2013 at 12:30:38PM +0300, Gleb Natapov wrote: On Thu, Apr 04, 2013 at 04:14:57PM +0300, Gleb Natapov wrote: is to move to MMIO only when PIO address space is exhausted. For PCI it will be never, for PCI-e it will be after ~16 devices. Ok, let's go back a step here. Are you actually able to measure any speed in performance with this patch applied and without when going through MMIO kicks? That's the question for MST. I think he did only micro benchmarks till now and he already posted his result here: mmio-wildcard-eventfd:pci-mem 3529 mmio-pv-eventfd:pci-mem 1878 portio-wildcard-eventfd:pci-io 1846 So the patch speedup mmio by almost 100% and it is almost the same as PIO. Those numbers don't align at all with what I measured. I am trying to run vmexit test on AMD now, but something does not work there. Next week I'll fix it and see how AMD differs, bit on Intel those are the numbers. The numbers are: vmcall 1921 inl_from_kernel 4227 outl_to_kernel 2345 outl is specifically optimized to not go through the emulator since it is used for virtio kick. mmio-pv-eventfd is the same kind of optimization but for mmio. -- Gleb. Hmm so on AMD it's more like 20% overhead, like ARM. -- MST -- 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: kernel BUG at kernel/smpboot.c:134!
On Sun, Apr 07, 2013 at 11:20:10AM +0200, Thomas Gleixner wrote: And it's even more bogus because the cpu to which we would bind in kthread_create_on_cpu() is not yet online. In case you guys are wondering about reproducibility, I saw the same BUG_ON yesterday on a 32-bit atom smp qemu guest too (don't ask why? :-)) And yes, this was without kvm (software emulation only in qemu). [0.395000] [ cut here ] [0.395000] kernel BUG at kernel/smpboot.c:134! [0.395000] invalid opcode: [#1] PREEMPT SMP [0.395000] Modules linked in: [0.395000] Pid: 13, comm: ksoftirqd/1 Not tainted 3.9.0-rc5+ #31 Bochs Bochs [0.395000] EIP: 0060:[c106542c] EFLAGS: 0202 CPU: 0 [0.395000] EIP is at smpboot_thread_fn+0x20c/0x260 [0.395000] EAX: EBX: f60ba430 ECX: EDX: 0001 [0.395000] ESI: f60024f0 EDI: c1736480 EBP: f60c1f24 ESP: f60c1f04 [0.395000] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [0.395000] CR0: 8005003b CR2: ffe17000 CR3: 01943000 CR4: 06e0 [0.395000] DR0: DR1: DR2: DR3: [0.395000] DR6: DR7: [0.395000] Process ksoftirqd/1 (pid: 13, ti=f60c task=f60ba430 task.ti=f60c) [0.395000] Stack: [0.395000] f60ba430 0001 f60c1f24 c105c49d f6083e7c f60024f0 c1065220 [0.395000] f60c1fac c105c745 0001 0001 f60024f0 c1510303 dead4ead [0.395000] c1b510ac c1c28450 c167e791 c151744f [0.395000] Call Trace: [0.395000] [c105c49d] ? __kthread_parkme+0x2d/0x70 [0.395000] [c1065220] ? lg_lock_init+0x20/0x20 [0.395000] [c105c745] kthread+0x95/0xa0 [0.395000] [c1510303] ? dump_pagetable+0xa/0x101 [0.395000] [c151744f] ? wait_for_common+0xcf/0x110 [0.395000] [c106] ? __remove_hrtimer+0x90/0xa0 [0.395000] [c151a477] ret_from_kernel_thread+0x1b/0x28 [0.395000] [c105c6b0] ? __init_kthread_worker+0x60/0x60 [0.395000] Code: 0f a3 02 19 d2 85 d2 0f 95 c2 0f b6 d2 ff d1 89 f0 e8 69 25 0b 00 8d 64 24 14 31 c0 5b 5e 5f 5d c3 e8 d9 2b 4b 00 e9 68 fe ff ff 0f 0b 66 90 e8 cb 2b 4b 00 e9 ac fe ff ff 8d b6 00 00 00 00 e8 [0.395000] EIP: [c106542c] smpboot_thread_fn+0x20c/0x260 SS:ESP 0068:f60c1f04 [0.403466] ---[ end trace f5696bc4e08aa88f ]--- -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] add ftdi_sio USB ID for GDM Boost V1.x
This patch add a missing usb device id for the GDMBoost V1.x device
The patch is against 3.9-rc5
Signed-off-by: Stefani Seibold stef...@seibold.net
---
ftdi_sio.c |1 +
ftdi_sio_ids.h |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 9886180..145979f 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -189,6 +189,7 @@ static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_THROTTLE_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GATEWAY_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_BOOST_PID) },
{ USB_DEVICE(NEWPORT_VID, NEWPORT_AGILIS_PID) },
{ USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_IOBOARD_PID) },
{ USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_MINI_IOBOARD_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index e79861e..3c00351 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -74,6 +74,7 @@
#define FTDI_OPENDCC_THROTTLE_PID 0xBFDA
#define FTDI_OPENDCC_GATEWAY_PID 0xBFDB
#define FTDI_OPENDCC_GBM_PID 0xBFDC
+#define FTDI_OPENDCC_GBM_BOOST_PID 0xBFDD
/* NZR SEM 16+ USB (http://www.nzr.de) */
#define FTDI_NZR_SEM_USB_PID 0xC1E0 /* NZR SEM-LOG16+ */
--
1.8.1.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 1/1] mmap.c: find_vma: eliminate initial if(mm) check
On Sun, Apr 7, 2013 at 2:18 AM, k80c k80ck...@gmail.com wrote:
As per commit 841e31e5cc6219d62054788faa289b6ed682d068,
we dont really need this if(mm) check anymore.
A WARN_ON_ONCE was added just for safety, but there have been no bug
reports about this so far.
Removing this if(mm) check.
Signed-off-by: k80c k80ck...@gmail.com
---
mm/mmap.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 0db0de1..b2c363f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1935,9 +1935,6 @@ struct vm_area_struct *find_vma(struct mm_struct *mm,
unsigned long addr)
{
struct vm_area_struct *vma = NULL;
- if (WARN_ON_ONCE(!mm)) /* Remove this in linux-3.6 */
- return NULL;
-
/* Check the cache first. */
/* (Cache hit rate is typically around 35%.) */
vma = ACCESS_ONCE(mm-mmap_cache);
Looks good to me.
Reviewed-by: Michel Lespinasse wal...@google.com
--
Michel Walken Lespinasse
A program is never fully debugged until the last user dies.
--
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] auditsc: Use kzalloc instead of kmalloc+memset.
In function audit_alloc_context(), use kzalloc, instead of kmalloc+memset.
Patch also renames audit_zero_context() to
audit_set_context(), to represent it's inner workings properly.
Signed-off-by: Rakib Mullick rakib.mull...@gmail.com
---
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index a371f85..f5b6dc5 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1034,10 +1034,9 @@ static inline void audit_free_aux(struct audit_context
*context)
}
}
-static inline void audit_zero_context(struct audit_context *context,
+static inline void audit_set_context(struct audit_context *context,
enum audit_state state)
{
- memset(context, 0, sizeof(*context));
context-state = state;
context-prio = state == AUDIT_RECORD_CONTEXT ? ~0ULL : 0;
}
@@ -1046,9 +1045,10 @@ static inline struct audit_context
*audit_alloc_context(enum audit_state state)
{
struct audit_context *context;
- if (!(context = kmalloc(sizeof(*context), GFP_KERNEL)))
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
+ if (!context)
return NULL;
- audit_zero_context(context, state);
+ audit_set_context(context, state);
INIT_LIST_HEAD(context-killed_trees);
INIT_LIST_HEAD(context-names_list);
return context;
--
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] kernel: debug: memcpy overlaped, use memmove instead of memcpy.
in memcpy, src and dest are overlaped.
for default implementaion or some architectures, it is OK.
but we can not be sure that it is OK for all platforms.
and in this condition, the performance are not quite important.
so better to use standard ways: let memmove instead of memcpy.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
kernel/debug/kdb/kdb_support.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/debug/kdb/kdb_support.c b/kernel/debug/kdb/kdb_support.c
index d35cc2d..990b3cc 100644
--- a/kernel/debug/kdb/kdb_support.c
+++ b/kernel/debug/kdb/kdb_support.c
@@ -129,13 +129,13 @@ int kdbnearsym(unsigned long addr, kdb_symtab_t *symtab)
}
if (i = ARRAY_SIZE(kdb_name_table)) {
debug_kfree(kdb_name_table[0]);
- memcpy(kdb_name_table, kdb_name_table+1,
+ memmove(kdb_name_table, kdb_name_table+1,
sizeof(kdb_name_table[0]) *
(ARRAY_SIZE(kdb_name_table)-1));
} else {
debug_kfree(knt1);
knt1 = kdb_name_table[i];
- memcpy(kdb_name_table+i, kdb_name_table+i+1,
+ memmove(kdb_name_table+i, kdb_name_table+i+1,
sizeof(kdb_name_table[0]) *
(ARRAY_SIZE(kdb_name_table)-i-1));
}
--
1.7.7.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: [RFC PATCH 1/3] perf: Add persistent events
On Sat, Apr 06, 2013 at 05:53:17PM +0200, Robert Richter wrote:
Boris,
On 15.03.13 14:06:27, Borislav Petkov wrote:
Add the needed pieces for persistent events which makes them
process-agnostic. Also, make their buffers read-only when mmaping them
from userspace.
diff --git a/include/uapi/linux/perf_event.h
b/include/uapi/linux/perf_event.h
index 9fa9c622a7f4..4a4ae56195e1 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -270,8 +270,9 @@ struct perf_event_attr {
exclude_callchain_kernel : 1, /* exclude kernel
callchains */
exclude_callchain_user : 1, /* exclude user
callchains */
+ persistent : 1, /* always-on event */
based on the discussion we have had a couple of days ago I got the
idea that we do not necessarily need the persistent flag. The purpose
of the persistent flag is to indicate that an existing event buffer
that is already enabled should be used. This means the buffer is
shared by multiple consumers. Enabled events with the following
conditions allow this too:
* buffer mappings are readonly,
* event is systemwide,
* struct perf_event_attr is identical.
This means that an event with readonly buffers (PROT_WRITE unset,
over-write unread data) and the same struct perf_event_attr can be
simply reused. So, we don't need the flag: When setting up a
systemwide and readonly event we just check if there is already one
event running. If so we increment the use count of that event and
share its buffer, otherwise we create a new event.
This also has the advantage that the syscall i/f does not change. We
simply setup the event in the same way as we do already. Maybe the
only thing we need is a sysfs extension to report existing systemwide
events to userland.
I'm not entirely sure why we want to do that? Just for informational
purposes? I mean, if we enable the events on the kernel command line, we
already know which are the persistent ones.
Now, to have persistent events in the sense that the event is running
since system startup, we simply enable an in-kernel-counter. If
userland later sets up the same event, the kernel is aware of the
already running counter and redirects it to its buffer and all
(persistent) samples of the current buffer are now available to
userland.
The above also has the advantage of sharing systemwide events which
saves system resources, e.g. hardware counters. Suppose two processes
are collecting cpu-clocks, currently there are two hw counters and
buffers used for this, but only one counter would be sufficient.
I'm all up for efficiency. :)
I currently see the following problem with the approach. If we map to
an already running counter, there might be samples in the buffer that
had been collected before the syscall was setup. But the profiling
tool might be interested only in newer samples. So userland must be
aware of this and might be able to drop those samples. This should be
also backward compatible with the existing syscall i/f.
Hmm, so the perf tool should actually know about persistent events
after all. If we open the persistent event from userspace, we get *all*
samples. If we simply do a normal perf session, we get only the new
samples.
Another problem is different buffer size. I don't know if it is
possible to simply resize mmap'ed regions to the biggest buffer
requested. Though this problem already exist with your code.
Hmm, that needs more code staring I guess.
Maybe it's worth to look at this approach. I need to review more perf
code for this.
Yeah, me too.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] uprobes/tracing: Make uprobe_{trace,perf}_print() uretprobe-friendly
* Oleg Nesterov o...@redhat.com [2013-04-01 18:08:51]:
Change uprobe_trace_print() and uprobe_perf_print() to check
is_ret_probe() and fill ring_buffer_event accordingly.
Also change uprobe_trace_func() and uprobe_perf_func() to not
_print() if is_ret_probe() is true. Note that we keep -handler()
nontrivial even for uretprobe, we need this for filtering and for
other potential extensions.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/trace/trace_uprobe.c | 42 +-
1 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index e91a354..db2718a 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -515,15 +515,26 @@ static void uprobe_trace_print(struct trace_uprobe *tu,
int size, i;
struct ftrace_event_call *call = tu-call;
- size = SIZEOF_TRACE_ENTRY(1) + tu-size;
+ if (is_ret_probe(tu))
One nit:
Here and couple of places below .. we could check for func instead of
is_ret_probe() right?
Or is there an advantage of checking is_ret_probe() over func?
+ size = SIZEOF_TRACE_ENTRY(2);
+ else
+ size = SIZEOF_TRACE_ENTRY(1);
+
event = trace_current_buffer_lock_reserve(buffer, call-event.type,
- size, 0, 0);
+ size + tu-size, 0, 0);
if (!event)
return;
entry = ring_buffer_event_data(event);
- entry-vaddr[0] = instruction_pointer(regs);
- data = DATAOF_TRACE_ENTRY(entry, 1);
+ if (is_ret_probe(tu)) {
+ entry-vaddr[0] = func;
+ entry-vaddr[1] = instruction_pointer(regs);
+ data = DATAOF_TRACE_ENTRY(entry, 2);
+ } else {
+ entry-vaddr[0] = instruction_pointer(regs);
+ data = DATAOF_TRACE_ENTRY(entry, 1);
+ }
+
for (i = 0; i tu-nr_args; i++)
call_fetch(tu-args[i].fetch, regs, data + tu-args[i].offset);
@@ -534,7 +545,8 @@ static void uprobe_trace_print(struct trace_uprobe *tu,
/* uprobe handler */
static int uprobe_trace_func(struct trace_uprobe *tu, struct pt_regs *regs)
{
- uprobe_trace_print(tu, 0, regs);
+ if (!is_ret_probe(tu))
+ uprobe_trace_print(tu, 0, regs);
Should this hunk be in the previous patch?
Also something for the future:
Most times a user uses a return probe, the user probably wants to probe
the function entry too. So should we extend the abi from p+r to
p+r+..something else to mean it traces both function entry and return.
Esp given that uretprobe has been elegantly been designed to make this a
possibility.
return 0;
}
@@ -783,7 +795,11 @@ static void uprobe_perf_print(struct trace_uprobe *tu,
void *data;
int size, rctx, i;
- size = SIZEOF_TRACE_ENTRY(1);
+ if (is_ret_probe(tu))
+ size = SIZEOF_TRACE_ENTRY(2);
+ else
+ size = SIZEOF_TRACE_ENTRY(1);
+
size = ALIGN(size + tu-size + sizeof(u32), sizeof(u64)) - sizeof(u32);
if (WARN_ONCE(size PERF_MAX_TRACE_SIZE, profile buffer not large
enough))
return;
@@ -794,8 +810,15 @@ static void uprobe_perf_print(struct trace_uprobe *tu,
goto out;
ip = instruction_pointer(regs);
- entry-vaddr[0] = ip;
- data = DATAOF_TRACE_ENTRY(entry, 1);
+ if (is_ret_probe(tu)) {
+ entry-vaddr[0] = func;
+ entry-vaddr[1] = ip;
+ data = DATAOF_TRACE_ENTRY(entry, 2);
+ } else {
+ entry-vaddr[0] = ip;
+ data = DATAOF_TRACE_ENTRY(entry, 1);
+ }
+
for (i = 0; i tu-nr_args; i++)
call_fetch(tu-args[i].fetch, regs, data + tu-args[i].offset);
@@ -811,7 +834,8 @@ static int uprobe_perf_func(struct trace_uprobe *tu,
struct pt_regs *regs)
if (!uprobe_perf_filter(tu-consumer, 0, current-mm))
return UPROBE_HANDLER_REMOVE;
- uprobe_perf_print(tu, 0, regs);
+ if (!is_ret_probe(tu))
+ uprobe_perf_print(tu, 0, regs);
return 0;
}
--
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/
[GIT PULL] KVM fixes for 3.9-rc5
Linus, Please pull from git://git.kernel.org/pub/scm/virt/kvm/kvm.git master To receive the bugfix for the regression introduced by c300aa64ddf57. Andrew Honig (1): KVM: Allow cross page reads and writes from cached translations. arch/x86/kvm/lapic.c |2 - arch/x86/kvm/x86.c| 13 +--- include/linux/kvm_host.h |2 - include/linux/kvm_types.h |1 virt/kvm/kvm_main.c | 47 -- 5 files changed, 46 insertions(+), 19 deletions(-) -- Gleb. -- 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/5] mmc: core: call pm_runtime_put_sync in pm_runtime_get_sync failed case
Hi Li, On Thu, Feb 28, 2013 at 9:44 AM, Li Fei fei...@intel.com wrote: Even in failed case of pm_runtime_get_sync, the usage_count is incremented. In order to keep the usage_count with correct value and runtime power management to behave correctly, call pm_runtime_put(_sync) in such case. As with the remoteproc case, it is probably better to call the put_noidle variant here. This way you are sure not to erroneously invoke any underlying pm handler where your only intention is to fix usage_count. Thanks, Ohad. -- 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 v1 6/9] uretprobes: Return probe exit, invoke handlers
* Anton Arapov an...@redhat.com [2013-04-03 18:00:36]:
Uretprobe handlers are invoked when the trampoline is hit, on completion the
trampoline is replaced with the saved return address and the uretprobe
instance
deleted.
v1 changes:
* pass bp_vaddr to ret_handler()
* simplify handle_uretprobe()
RFCv6 changes:
* rework handle_uretprobe()
RFCv5 changes:
* switch to simply linked list -return_uprobes
* rework handle_uretprobe()
RFCv4 changes:
* check, whether utask is not NULL in handle_uretprobe()
* get rid of area-rp_trampoline_vaddr
* minor handle_uretprobe() fixups
RFCv3 changes:
* protected uprobe with refcounter. See put_uprobe() in handle_uretprobe()
that reflects increment in prepare_uretprobe()
RFCv2 changes:
* get rid of -return_consumers member from struct uprobe, introduce
ret_handler() in consumer instead
Signed-off-by: Anton Arapov an...@redhat.com
---
kernel/events/uprobes.c | 60
-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 08ecfff..d129c1d 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1609,6 +1609,57 @@ static void handler_chain(struct uprobe *uprobe,
struct pt_regs *regs)
up_read(uprobe-register_rwsem);
}
+static void
+handler_uretprobe_chain(struct return_instance *ri, struct pt_regs *regs)
+{
+ struct uprobe *uprobe = ri-uprobe;
+ struct uprobe_consumer *uc;
+
+ down_read(uprobe-register_rwsem);
+ for (uc = uprobe-consumers; uc; uc = uc-next) {
+ if (uc-ret_handler)
+ uc-ret_handler(uc, ri-func, regs);
+ }
+ up_read(uprobe-register_rwsem);
+}
+
+static bool handler_uretprobe(struct pt_regs *regs)
Nit: can this be renamed to handle_trampoline
+{
+ struct uprobe_task *utask;
+ struct return_instance *ri, *tmp;
+ bool chained;
+
+ utask = current-utask;
+ if (!utask)
+ return false;
+
+ ri = utask-return_instances;
+ if (!ri)
+ return false;
+
+ instruction_pointer_set(regs, ri-orig_ret_vaddr);
Should we a check here before using top most ri.
What if the application had done a longjmp and the trampoline he hit
corresponds to something thats below in the stack?
Not sure if this what you meant by leaking return instances in your next
patch.
+
+ for (;;) {
+ handler_uretprobe_chain(ri, regs);
+
+ chained = ri-chained;
+ put_uprobe(ri-uprobe);
+
+ tmp = ri;
+ ri = ri-next;
+ kfree(tmp);
+
+ if (!chained)
+ break;
+
+ BUG_ON(!ri);
+ }
+
+ utask-return_instances = ri;
+
+ return true;
+}
+
/*
* Run handler and ask thread to singlestep.
* Ensure all non-fatal signals cannot interrupt thread while it singlesteps.
@@ -1620,8 +1671,15 @@ static void handle_swbp(struct pt_regs *regs)
int uninitialized_var(is_swbp);
bp_vaddr = uprobe_get_swbp_addr(regs);
- uprobe = find_active_uprobe(bp_vaddr, is_swbp);
+ if (bp_vaddr == get_trampoline_vaddr()) {
+ if (handler_uretprobe(regs))
+ return;
+ pr_warn(uprobe: unable to handle uretprobe pid/tgid=%d/%d\n,
+ current-pid, current-tgid);
+ }
+
+ uprobe = find_active_uprobe(bp_vaddr, is_swbp);
if (!uprobe) {
if (is_swbp 0) {
/* No matching uprobe; signal SIGTRAP. */
--
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] kernel: debug: kdb: strncpy issue, using strlcpy instead of strncpy.
cmd_cur and cmd_hist[] are all NUL terminated string.
need using strlcpy instead of strncpy.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
kernel/debug/kdb/kdb_main.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index 00eb8f7..a2b04d7 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -1063,12 +1063,12 @@ static int handle_ctrl_cmd(char *cmd)
case CTRL_P:
if (cmdptr != cmd_tail)
cmdptr = (cmdptr-1) % KDB_CMD_HISTORY_COUNT;
- strncpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
+ strlcpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
return 1;
case CTRL_N:
if (cmdptr != cmd_head)
cmdptr = (cmdptr+1) % KDB_CMD_HISTORY_COUNT;
- strncpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
+ strlcpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
return 1;
}
return 0;
@@ -1260,7 +1260,7 @@ do_full_getstr:
if (*cmdbuf != '\n') {
if (*cmdbuf 32) {
if (cmdptr == cmd_head) {
- strncpy(cmd_hist[cmd_head], cmd_cur,
+ strlcpy(cmd_hist[cmd_head], cmd_cur,
CMD_BUFLEN);
*(cmd_hist[cmd_head] +
strlen(cmd_hist[cmd_head])-1) = '\0';
@@ -1270,7 +1270,7 @@ do_full_getstr:
cmdbuf = cmd_cur;
goto do_full_getstr;
} else {
- strncpy(cmd_hist[cmd_head], cmd_cur,
+ strlcpy(cmd_hist[cmd_head], cmd_cur,
CMD_BUFLEN);
}
--
1.7.7.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/
[PATCH] net: mvmdio: get and enable optional clock
Marvell mdio driver uses internal registers that can be clock gated on
some SoCs. This patch just adds optional clock handling, to allow to pass
and enable the corresponding clock.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: David S. Miller da...@davemloft.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/marvell/mvmdio.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c
b/drivers/net/ethernet/marvell/mvmdio.c
index 7b5158f..e2f6626 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -28,6 +28,7 @@
#include linux/platform_device.h
#include linux/delay.h
#include linux/io.h
+#include linux/clk.h
#include linux/of_mdio.h
#include linux/sched.h
#include linux/wait.h
@@ -46,6 +47,7 @@
struct orion_mdio_dev {
struct mutex lock;
void __iomem *regs;
+ struct clk *clk;
/*
* If we have access to the error interrupt pin (which is
* somewhat misnamed as it not only reflects internal errors
@@ -230,6 +232,10 @@ static int orion_mdio_probe(struct platform_device *pdev)
init_waitqueue_head(dev-smi_busy_wait);
+ dev-clk = devm_clk_get(pdev-dev, NULL);
+ if (!IS_ERR(dev-clk))
+ clk_prepare_enable(dev-clk);
+
dev-err_interrupt = platform_get_irq(pdev, 0);
if (dev-err_interrupt != -ENXIO) {
ret = devm_request_irq(pdev-dev, dev-err_interrupt,
@@ -258,6 +264,8 @@ static int orion_mdio_probe(struct platform_device *pdev)
return 0;
out_mdio:
+ if (!IS_ERR(dev-clk))
+ clk_disable_unprepare(dev-clk);
kfree(bus-irq);
mdiobus_free(bus);
return ret;
@@ -272,6 +280,9 @@ static int orion_mdio_remove(struct platform_device *pdev)
mdiobus_unregister(bus);
kfree(bus-irq);
mdiobus_free(bus);
+ if (!IS_ERR(dev-clk))
+ clk_disable_unprepare(dev-clk);
+
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: of_mdio: scan mdiobus for PHYs without reg property
Using DT for mdiobus and ethernet-phy requires to know the PHY address, which
is hard to guess if you don't know it. This patch extends of_mdiobus_register
to scan mdiobus for PHYs if reg property of the corresponding node is not set.
This also allows to have phy nodes in SoC DT files where the reg property can
be overwritten in the board file later. To encourage people to finally set the
actual phy address, the mdiobus scan is noisier than required.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Florian Fainelli flor...@openwrt.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/of/of_mdio.c | 64 +-
1 file changed, 58 insertions(+), 6 deletions(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index e3a8b22..23049ae 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -34,7 +34,10 @@ int of_mdiobus_register(struct mii_bus *mdio, struct
device_node *np)
{
struct phy_device *phy;
struct device_node *child;
- int rc, i;
+ const __be32 *paddr;
+ u32 addr;
+ bool is_c45, scanphys = false;
+ int rc, i, len;
/* Mask out all PHYs from auto probing. Instead the PHYs listed in
* the device tree are populated after the bus has been registered */
@@ -54,14 +57,10 @@ int of_mdiobus_register(struct mii_bus *mdio, struct
device_node *np)
/* Loop over the child nodes and register a phy_device for each one */
for_each_available_child_of_node(np, child) {
- const __be32 *paddr;
- u32 addr;
- int len;
- bool is_c45;
-
/* A PHY must have a reg property in the range [0-31] */
paddr = of_get_property(child, reg, len);
if (!paddr || len sizeof(*paddr)) {
+ scanphys = true;
dev_err(mdio-dev, %s has invalid PHY address\n,
child-full_name);
continue;
@@ -111,6 +110,59 @@ int of_mdiobus_register(struct mii_bus *mdio, struct
device_node *np)
child-name, addr);
}
+ if (!scanphys)
+ return 0;
+
+ /* auto scan for PHYs with empty reg property */
+ for_each_available_child_of_node(np, child) {
+ /* Skip PHYs with reg property set */
+ paddr = of_get_property(child, reg, len);
+ if (paddr)
+ continue;
+
+ is_c45 = of_device_is_compatible(child,
+ethernet-phy-ieee802.3-c45);
+
+ for (addr = 0; addr PHY_MAX_ADDR; addr++) {
+ /* skip already registered PHYs */
+ if (mdio-phy_map[addr])
+ continue;
+
+ /* be noisy to encourage people to set reg property */
+ dev_info(mdio-dev, scan phy %s at address %i\n,
+child-name, addr);
+
+ phy = get_phy_device(mdio, addr, is_c45);
+ if (!phy || IS_ERR(phy))
+ continue;
+
+ if (mdio-irq) {
+ mdio-irq[addr] =
+ irq_of_parse_and_map(child, 0);
+ if (!mdio-irq[addr])
+ mdio-irq[addr] = PHY_POLL;
+ }
+
+ /* Associate the OF node with the device structure so it
+* can be looked up later */
+ of_node_get(child);
+ phy-dev.of_node = child;
+
+ /* All data is now stored in the phy struct;
+* register it */
+ rc = phy_device_register(phy);
+ if (rc) {
+ phy_device_free(phy);
+ of_node_put(child);
+ continue;
+ }
+
+ dev_info(mdio-dev, registered phy %s at address
%i\n,
+child-name, addr);
+ break;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL(of_mdiobus_register);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel: debug: kdb: strncpy issue, using strlcpy instead of strncpy
kdb_prompt_str is NUL terminated string, need always set '\0' at the end.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
kernel/debug/kdb/kdb_io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 14ff484..932b436 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -442,7 +442,7 @@ poll_again:
char *kdb_getstr(char *buffer, size_t bufsize, char *prompt)
{
if (prompt kdb_prompt_str != prompt)
- strncpy(kdb_prompt_str, prompt, CMD_BUFLEN);
+ strlcpy(kdb_prompt_str, prompt, CMD_BUFLEN);
kdb_printf(kdb_prompt_str);
kdb_nextline = 1; /* Prompt and input resets line number */
return kdb_read(buffer, bufsize);
--
1.7.7.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] drivers/gpu/drm/nouveau: remove erroneous semicolon
Dear Chen,
Am Mittwoch, den 27.03.2013, 15:23 +0800 schrieb Chen Gang:
need remove semicolon, or always return true.
do you know if this cause any problems? Did you find this reading the
code or by using some tools?
Signed-off-by: Chen Gang gang.c...@asianux.com
---
drivers/gpu/drm/nouveau/nv50_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index 7f0e6c3..1ddc03e 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -479,7 +479,7 @@ nv50_display_flip_wait(void *data)
{
struct nv50_display_flip *flip = data;
if (nouveau_bo_rd32(flip-disp-sync, flip-chan-addr / 4) ==
- flip-chan-data);
+ flip-chan-data)
return true;
usleep_range(1, 2);
return false;
Acked-by: Paul Menzel paulepan...@users.sourceforge.net
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
Re: net_dropmon usage documentation/examples?
Neil Horman nhor...@tuxdriver.com wrote: On Fri, Apr 05, 2013 at 07:38:55PM +, Eric Wong wrote: Hi Neil, I'm wondering if you have or know of any public documentation/examples for using net_dropmon. If not, I'll figure it out on my own at some point. Thanks in advance! I don't think there are any particular examples at the moment, but if you download the dropwatch utility, it uses the dropmon protocol to detect frame loss in the stack, and its use is pretty self explanitory, as is the perf script that uses the same tracepoints as the dropmon protocol. https://fedorahosted.org/dropwatch/ Thanks Neil! I think I'll just use dropwatch directly instead of writing my own code, now :) -- 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] Drivers: Base: Regmap: fix warnings, use %zu instead of %d for printf format
On Sun, Apr 07, 2013 at 05:32:39PM +0800, Chen Gang wrote: fix warnings (with EXTRA_CFLAGS=-W): format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] Signed-off-by: Chen Gang gang.c...@asianux.com I've already applied a patch for this from someone else. signature.asc Description: Digital signature
Re: [PATCH] drivers/gpu/drm/nouveau: remove erroneous semicolon
On 2013年04月07日 19:24, Paul Menzel wrote: do you know if this cause any problems? Did you find this reading the code or by using some tools? sorry, I do not know if this can cause any problems. for this issue, I did not find it by reading code. I find it by using compiler warnings with EXTRA_CFLAGS=-W thanks. :-) -- Chen Gang Asianux Corporation -- 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] Drivers: Base: Regmap: fix warnings, use %zu instead of %d for printf format
On 2013年04月07日 19:33, Mark Brown wrote: On Sun, Apr 07, 2013 at 05:32:39PM +0800, Chen Gang wrote: fix warnings (with EXTRA_CFLAGS=-W): format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] Signed-off-by: Chen Gang gang.c...@asianux.com I've already applied a patch for this from someone else. ok, thanks. it seems, I am too late !! :-) -- Chen Gang Asianux Corporation -- 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] kernel: module: strncpy issue, using strlcpy instead of strncpy
ownername and namebuf are all NUL terminated string.
need always let them ended by '\0'.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
kernel/module.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 3c2c72d..597efd8 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1283,7 +1283,7 @@ static const struct kernel_symbol *resolve_symbol(struct
module *mod,
getname:
/* We must make copy under the lock if we failed to get ref. */
- strncpy(ownername, module_name(owner), MODULE_NAME_LEN);
+ strlcpy(ownername, module_name(owner), MODULE_NAME_LEN);
unlock:
mutex_unlock(module_mutex);
return sym;
@@ -3464,7 +3464,7 @@ const char *module_address_lookup(unsigned long addr,
}
/* Make a copy in here where it's safe */
if (ret) {
- strncpy(namebuf, ret, KSYM_NAME_LEN - 1);
+ strlcpy(namebuf, ret, KSYM_NAME_LEN);
ret = namebuf;
}
preempt_enable();
--
1.7.7.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 v1 1/9] uretprobes: Introduce uprobe_consumer-ret_handler()
* Anton Arapov an...@redhat.com [2013-04-03 18:00:31]:
Enclose return probes implementation, introduce -ret_handler() and update
existing code to rely on -handler() *and* -ret_handler() for uprobe and
uretprobe respectively.
v1 changes:
* add bp_vaddr argument to -ret_handler()
RFCv5 changes:
* don't remove uprobe in case there are no uprobe consumer(handler),
see handler_chain() changes.
RFCv3 changes: (the patch is introduced in v3)
* check whether at least one of the consumer's handlers were set.
* a 'TODO' cap that will be removed once return probes be implemented.
* introduce -ret_handler().
Signed-off-by: Anton Arapov an...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
include/linux/uprobes.h | 3 +++
kernel/events/uprobes.c | 17 ++---
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 02b83db..4042cad 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -46,6 +46,9 @@ enum uprobe_filter_ctx {
struct uprobe_consumer {
int (*handler)(struct uprobe_consumer *self, struct pt_regs *regs);
+ int (*ret_handler)(struct uprobe_consumer *self,
+ unsigned long func,
+ struct pt_regs *regs);
bool (*filter)(struct uprobe_consumer *self,
enum uprobe_filter_ctx ctx,
struct mm_struct *mm);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 21d8a65..27c964b 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -815,6 +815,14 @@ int uprobe_register(struct inode *inode, loff_t offset,
struct uprobe_consumer *
struct uprobe *uprobe;
int ret;
+ /* Uprobe must have at least one set consumer */
+ if (!uc-handler !uc-ret_handler)
+ return -EINVAL;
+
+ /* TODO: Implement return probes */
+ if (uc-ret_handler)
+ return -ENOSYS;
+
/* Racy, just to catch the obvious mistakes */
if (offset i_size_read(inode))
return -EINVAL;
@@ -1473,10 +1481,13 @@ static void handler_chain(struct uprobe *uprobe,
struct pt_regs *regs)
down_read(uprobe-register_rwsem);
for (uc = uprobe-consumers; uc; uc = uc-next) {
- int rc = uc-handler(uc, regs);
+ int rc = 0;
- WARN(rc ~UPROBE_HANDLER_MASK,
- bad rc=0x%x from %pf()\n, rc, uc-handler);
+ if (uc-handler) {
+ rc = uc-handler(uc, regs);
+ WARN(rc ~UPROBE_HANDLER_MASK,
+ bad rc=0x%x from %pf()\n, rc, uc-handler);
+ }
remove = rc;
}
--
1.8.1.4
--
Thanks and Regards
Srikar Dronamraju
--
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 v1 2/9] uretprobes: Reserve the first slot in xol_vma for trampoline
* Anton Arapov an...@redhat.com [2013-04-03 18:00:32]:
Allocate trampoline page, as the very first one in uprobed
task xol area, and fill it with breakpoint opcode.
Also introduce get_trampoline_vaddr() helper, to wrap the
trampoline address extraction from area-vaddr. That removes
confusion and eases the debug experience in case -vaddr
notion will be changed.
v1 changes:
* rework get_trampoline_vaddr() helper.
* init xol_area-slot_count.
Signed-off-by: Anton Arapov an...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
(one small check below:)
---
kernel/events/uprobes.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 27c964b..d3c8201 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1109,6 +1109,7 @@ static struct xol_area *get_xol_area(void)
{
struct mm_struct *mm = current-mm;
struct xol_area *area;
+ uprobe_opcode_t insn = UPROBE_SWBP_INSN;
area = mm-uprobes_state.xol_area;
if (area)
@@ -1126,7 +1127,12 @@ static struct xol_area *get_xol_area(void)
if (!area-page)
goto free_bitmap;
+ /* allocate first slot of task's xol_area for the return probes */
+ set_bit(0, area-bitmap);
+ copy_to_page(area-page, 0, insn, UPROBE_SWBP_INSN_SIZE);
+ atomic_set(area-slot_count, 1);
init_waitqueue_head(area-wq);
+
if (!xol_add_vma(area))
return area;
@@ -1323,6 +1329,25 @@ static struct uprobe_task *get_utask(void)
return current-utask;
}
+/*
+ * Current area-vaddr notion assume the trampoline address is always
+ * equal area-vaddr.
+ *
+ * Returns -1 in case the xol_area is not allocated.
+ */
+static unsigned long get_trampoline_vaddr(void)
+{
+ struct xol_area *area;
+ unsigned long trampoline_vaddr = -1;
+
+ area = current-mm-uprobes_state.xol_area;
+ smp_read_barrier_depends();
check: do we need this barrier?
+ if (area)
+ trampoline_vaddr = area-vaddr;
+
+ return trampoline_vaddr;
+}
+
/* Prepare to single-step probed instruction out of line. */
static int
pre_ssout(struct uprobe *uprobe, struct pt_regs *regs, unsigned long
bp_vaddr)
--
1.8.1.4
--
Thanks and Regards
Srikar Dronamraju
--
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] kvm: fix MMIO/PIO collision misdetection
On Thu, Apr 04, 2013 at 01:27:21PM +0300, Michael S. Tsirkin wrote:
PIO and MMIO are separate address spaces, but
ioeventfd registration code mistakenly detected
two eventfds as duplicate if they use the same address,
even if one is PIO and another one MMIO.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Applied, thanks.
---
virt/kvm/eventfd.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index adb17f2..93e5b05 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -577,6 +577,7 @@ struct _ioeventfd {
struct eventfd_ctx *eventfd;
u64 datamatch;
struct kvm_io_device dev;
+ u8 bus_idx;
bool wildcard;
};
@@ -669,7 +670,8 @@ ioeventfd_check_collision(struct kvm *kvm, struct
_ioeventfd *p)
struct _ioeventfd *_p;
list_for_each_entry(_p, kvm-ioeventfds, list)
- if (_p-addr == p-addr _p-length == p-length
+ if (_p-bus_idx == p-bus_idx
+ _p-addr == p-addr _p-length == p-length
(_p-wildcard || p-wildcard ||
_p-datamatch == p-datamatch))
return true;
@@ -717,6 +719,7 @@ kvm_assign_ioeventfd(struct kvm *kvm, struct
kvm_ioeventfd *args)
INIT_LIST_HEAD(p-list);
p-addr= args-addr;
+ p-bus_idx = bus_idx;
p-length = args-len;
p-eventfd = eventfd;
@@ -775,7 +778,8 @@ kvm_deassign_ioeventfd(struct kvm *kvm, struct
kvm_ioeventfd *args)
list_for_each_entry_safe(p, tmp, kvm-ioeventfds, list) {
bool wildcard = !(args-flags KVM_IOEVENTFD_FLAG_DATAMATCH);
- if (p-eventfd != eventfd ||
+ if (p-bus_idx != bus_idx ||
+ p-eventfd != eventfd ||
p-addr != args-addr ||
p-length != args-len ||
p-wildcard != wildcard)
--
MST
--
Gleb.
--
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 v1 3/9] uretprobes/x86: Hijack return address
* Anton Arapov an...@redhat.com [2013-04-03 18:00:33]:
Hijack the return address and replace it with a trampoline address.
v1 changes:
* use force_sig_info()
* rework and simplify logic
RFCv5 changes:
* change the fail return code, because orig_ret_vaddr=0 is possible
* style fixup
RFCv2 changes:
* remove -doomed flag, kill task immediately
Signed-off-by: Anton Arapov an...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
arch/x86/include/asm/uprobes.h | 1 +
arch/x86/kernel/uprobes.c | 29 +
2 files changed, 30 insertions(+)
diff --git a/arch/x86/include/asm/uprobes.h b/arch/x86/include/asm/uprobes.h
index 8ff8be7..6e51979 100644
--- a/arch/x86/include/asm/uprobes.h
+++ b/arch/x86/include/asm/uprobes.h
@@ -55,4 +55,5 @@ extern int arch_uprobe_post_xol(struct arch_uprobe *aup,
struct pt_regs *regs);
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);
#endif /* _ASM_UPROBES_H */
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 0ba4cfb..2ed8459 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -697,3 +697,32 @@ bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe,
struct pt_regs *regs)
send_sig(SIGTRAP, current, 0);
return ret;
}
+
+unsigned long
+arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr, struct
pt_regs *regs)
+{
+ int rasize, ncopied;
+ unsigned long orig_ret_vaddr = 0; /* clear high bits for 32-bit apps */
+
+ rasize = is_ia32_task() ? 4 : 8;
+ ncopied = copy_from_user(orig_ret_vaddr, (void __user *)regs-sp,
rasize);
+ if (unlikely(ncopied))
+ return -1;
+
+ /* check whether address has been already hijacked */
+ if (orig_ret_vaddr == trampoline_vaddr)
+ return orig_ret_vaddr;
+
+ ncopied = copy_to_user((void __user *)regs-sp, trampoline_vaddr,
rasize);
+ if (likely(!ncopied))
+ return orig_ret_vaddr;
+
+ if (ncopied != rasize) {
+ pr_err(uprobe: return address clobbered: pid=%d, %%sp=%#lx,
+ %%ip=%#lx\n, current-pid, regs-sp, regs-ip);
+
+ force_sig_info(SIGSEGV, SEND_SIG_FORCED, current);
+ }
+
+ return -1;
+}
--
1.8.1.4
--
Thanks and Regards
Srikar Dronamraju
--
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 v1 4/9] uretprobes/ppc: Hijack return address
* Anton Arapov an...@redhat.com [2013-04-03 18:00:34]:
Hijack the return address and replace it with a trampoline address.
PowerPC implementation.
Signed-off-by: Anton Arapov an...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/uprobes.h | 1 +
arch/powerpc/kernel/uprobes.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/arch/powerpc/include/asm/uprobes.h
b/arch/powerpc/include/asm/uprobes.h
index b532060..2301602 100644
--- a/arch/powerpc/include/asm/uprobes.h
+++ b/arch/powerpc/include/asm/uprobes.h
@@ -51,4 +51,5 @@ extern int arch_uprobe_post_xol(struct arch_uprobe *aup,
struct pt_regs *regs);
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);
#endif /* _ASM_UPROBES_H */
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index bc77834..567b975 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -188,3 +188,16 @@ bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe,
struct pt_regs *regs)
return false;
}
+
+unsigned long
+arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr, struct
pt_regs *regs)
+{
+ unsigned long orig_ret_vaddr;
+
+ orig_ret_vaddr = regs-link;
+
+ /* Replace the return addr with trampoline addr */
+ regs-link = trampoline_vaddr;
+
+ return orig_ret_vaddr;
+}
--
1.8.1.4
--
Thanks and Regards
Srikar Dronamraju
--
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 v1 5/9] uretprobes: Return probe entry, prepare_uretprobe()
* Anton Arapov an...@redhat.com [2013-04-03 18:00:35]:
When a uprobe with return probe consumer is hit, prepare_uretprobe()
function is invoked. It creates return_instance, hijacks return address
and replaces it with the trampoline.
* Return instances are kept as stack per uprobed task.
* Return instance is chained, when the original return address is
trampoline's page vaddr (e.g. recursive call of the probed function).
v1 changes:
* preserve address of the breakpoint in return_instance.
* don't forget NULLify return_instances on free_utask.
* simplify prepare_uretprobe().
RFCv6 changes:
* rework prepare_uretprobe() logic in order to make further unwinding
in handler_uretprobe() simplier.
* introduce the 'dirty' field.
RFCv5 changes:
* switch from hlist to simply linked list for tracking -*return_uprobes.
* preallocate first slot xol_area for return probes, see xol_get_area()
changes.
* add get_trampoline_vaddr() helper, to emphasize area-vaddr overload.
RFCv4 changes:
* get rid of area-rp_trampoline_vaddr as it always the same as -vaddr.
* cleanup -return_uprobes list in uprobe_free_utask(), because the
task can exit from inside the ret-probe'd function(s).
* in find_active_uprobe(): Once we inserted int3 we must ensure that
handle_swbp() will be called even if this uprobe goes away. We have
the reference but it only protects uprobe itself, it can't protect
agains delete_uprobe().
IOW, we must ensure that uprobe_pre_sstep_notifier() can't return 0.
RFCv3 changes:
* protected uprobe with refcounter. See atomic_inc in prepare_uretprobe()
and put_uprobe() in a following patch in handle_uretprobe().
RFCv2 changes:
* get rid of -return_consumers member from struct uprobe, introduce
ret_handler() in consumer.
Signed-off-by: Anton Arapov an...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 92
-
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 4042cad..5f8960e 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -71,6 +71,7 @@ struct uprobe_task {
enum uprobe_task_state state;
struct arch_uprobe_task autask;
+ struct return_instance *return_instances;
struct uprobe *active_uprobe;
unsigned long xol_vaddr;
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index d3c8201..08ecfff 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -75,6 +75,15 @@ 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 */
+};
+
/*
* valid_vma: Verify if the specified vma is an executable vma
* Relax restrictions while unregistering: vm_flags might have
@@ -1294,6 +1303,7 @@ unsigned long __weak uprobe_get_swbp_addr(struct
pt_regs *regs)
void uprobe_free_utask(struct task_struct *t)
{
struct uprobe_task *utask = t-utask;
+ struct return_instance *ri, *tmp;
if (!utask)
return;
@@ -1301,6 +1311,15 @@ void uprobe_free_utask(struct task_struct *t)
if (utask-active_uprobe)
put_uprobe(utask-active_uprobe);
+ ri = utask-return_instances;
+ while (ri) {
+ tmp = ri;
+ ri = ri-next;
+
+ put_uprobe(tmp-uprobe);
+ kfree(tmp);
+ }
+
xol_free_insn_slot(t);
kfree(utask);
t-utask = NULL;
@@ -1348,6 +1367,65 @@ static unsigned long get_trampoline_vaddr(void)
return trampoline_vaddr;
}
+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;
+
+ if (!get_xol_area())
+ return;
+
+ utask = get_utask();
+ if (!utask)
+ return;
+
+ ri = kzalloc(sizeof(struct return_instance), GFP_KERNEL);
+ if (!ri)
+ goto fail;
+
+ trampoline_vaddr = get_trampoline_vaddr();
+ orig_ret_vaddr = arch_uretprobe_hijack_return_addr(trampoline_vaddr,
regs);
+ if (orig_ret_vaddr == -1)
+ goto fail;
+
+ /*
+ * 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 ==
Re: [PATCH v1 7/9] uretprobes: Limit the depth of return probe nestedness
* Anton Arapov an...@redhat.com [2013-04-03 18:00:37]:
Unlike the kretprobes we can't trust userspace, thus must have
protection from user space attacks. User-space have unlimited
stack, and this patch limits the return probes nestedness as a
simple remedy for it.
Note that this implementation leaks return_instance on siglongjmp
until exit()/exec().
The intention is to have KISS and bare minimum solution for the
initial implementation in order to not complicate the uretprobes
code.
In the future we may come up with more sophisticated solution that
remove this depth limitation. It is not easy task and lays beyond
this patchset.
Signed-off-by: Anton Arapov an...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
include/linux/uprobes.h | 3 +++
kernel/events/uprobes.c | 11 +++
2 files changed, 14 insertions(+)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 5f8960e..d7bcf10 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -38,6 +38,8 @@ struct inode;
#define UPROBE_HANDLER_REMOVE1
#define UPROBE_HANDLER_MASK 1
+#define MAX_URETPROBE_DEPTH 64
+
enum uprobe_filter_ctx {
UPROBE_FILTER_REGISTER,
UPROBE_FILTER_UNREGISTER,
@@ -72,6 +74,7 @@ struct uprobe_task {
struct arch_uprobe_task autask;
struct return_instance *return_instances;
+ unsigned intdepth;
struct uprobe *active_uprobe;
unsigned long xol_vaddr;
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index d129c1d..489f5e3 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1381,6 +1381,13 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
if (!utask)
return;
+ if (utask-depth = MAX_URETPROBE_DEPTH) {
+ printk_ratelimited(KERN_INFO uprobe: omit uretprobe due to
+ nestedness limit pid/tgid=%d/%d\n,
+ current-pid, current-tgid);
+ return;
+ }
+
ri = kzalloc(sizeof(struct return_instance), GFP_KERNEL);
if (!ri)
goto fail;
@@ -1416,6 +1423,8 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
ri-orig_ret_vaddr = orig_ret_vaddr;
ri-chained = chained;
+ utask-depth++;
+
/* add instance to the stack */
ri-next = utask-return_instances;
utask-return_instances = ri;
@@ -1652,6 +1661,8 @@ static bool handler_uretprobe(struct pt_regs *regs)
if (!chained)
break;
+ utask-depth--;
+
BUG_ON(!ri);
}
--
1.8.1.4
--
Thanks and Regards
Srikar Dronamraju
--
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 v1 8/9] uretprobes: Remove -ENOSYS as return probes implemented
* Anton Arapov an...@redhat.com [2013-04-03 18:00:38]: Enclose return probes implementation. Signed-off-by: Anton Arapov an...@redhat.com --- Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com kernel/events/uprobes.c | 4 1 file changed, 4 deletions(-) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 489f5e3..9af52f7 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -828,10 +828,6 @@ int uprobe_register(struct inode *inode, loff_t offset, struct uprobe_consumer * if (!uc-handler !uc-ret_handler) return -EINVAL; - /* TODO: Implement return probes */ - if (uc-ret_handler) - return -ENOSYS; - /* Racy, just to catch the obvious mistakes */ if (offset i_size_read(inode)) return -EINVAL; -- 1.8.1.4 -- Thanks and Regards Srikar Dronamraju -- 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 v1 9/9] uretprobes: Documentation update
* Anton Arapov an...@redhat.com [2013-04-03 18:00:39]: add the uretprobe syntax and update an example Signed-off-by: Anton Arapov an...@redhat.com --- Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com Documentation/trace/uprobetracer.txt | 114 --- 1 file changed, 67 insertions(+), 47 deletions(-) diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.txt index 24ce682..d9c3e68 100644 --- a/Documentation/trace/uprobetracer.txt +++ b/Documentation/trace/uprobetracer.txt @@ -1,6 +1,8 @@ - Uprobe-tracer: Uprobe-based Event Tracing - = - Documentation written by Srikar Dronamraju +Uprobe-tracer: Uprobe-based Event Tracing += + + Documentation written by Srikar Dronamraju + Overview @@ -13,78 +15,94 @@ current_tracer. Instead of that, add probe points via /sys/kernel/debug/tracing/events/uprobes/EVENT/enabled. However unlike kprobe-event tracer, the uprobe event interface expects the -user to calculate the offset of the probepoint in the object +user to calculate the offset of the probepoint in the object. Synopsis of uprobe_tracer - - p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a probe + p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a uprobe + r[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a return uprobe (uretprobe) + -:[GRP/]EVENT : Clear uprobe or uretprobe event - GRP : Group name. If omitted, use uprobes for it. - EVENT : Event name. If omitted, the event name is generated - based on SYMBOL+offs. - PATH: path to an executable or a library. - SYMBOL[+offs] : Symbol+offset where the probe is inserted. + GRP : Group name. If omitted, uprobes is the default value. + EVENT : Event name. If omitted, the event name is generated based + on SYMBOL+offs. + PATH : Path to an executable or a library. + SYMBOL[+offs] : Symbol+offset where the probe is inserted. - FETCHARGS : Arguments. Each probe can have up to 128 args. - %REG : Fetch register REG + FETCHARGS : Arguments. Each probe can have up to 128 args. + %REG : Fetch register REG Event Profiling --- - You can check the total number of probe hits and probe miss-hits via +You can check the total number of probe hits and probe miss-hits via /sys/kernel/debug/tracing/uprobe_profile. - The first column is event name, the second is the number of probe hits, +The first column is event name, the second is the number of probe hits, the third is the number of probe miss-hits. Usage examples -- -To add a probe as a new event, write a new definition to uprobe_events -as below. + * Add a probe as a new uprobe event, write a new definition to uprobe_events +as below: (sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash) + +echo 'p: /bin/bash:0x4245c0' /sys/kernel/debug/tracing/uprobe_events + + * Add a probe as a new uretprobe event: + +echo 'r: /bin/bash:0x4245c0' /sys/kernel/debug/tracing/uprobe_events + + * Unset registered event: - echo 'p: /bin/bash:0x4245c0' /sys/kernel/debug/tracing/uprobe_events +echo '-:bash_0x4245c0' /sys/kernel/debug/tracing/uprobe_events - This sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash + * Print out the events that are registered: - echo /sys/kernel/debug/tracing/uprobe_events +cat /sys/kernel/debug/tracing/uprobe_events - This clears all probe points. + * Clear all events: -The following example shows how to dump the instruction pointer and %ax -a register at the probed text address. Here we are trying to probe -function zfree in /bin/zsh +echo /sys/kernel/debug/tracing/uprobe_events + +Following example shows how to dump the instruction pointer and %ax register +at the probed text address. Probe zfree function in /bin/zsh: # cd /sys/kernel/debug/tracing/ -# cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp +# cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp 0040-0048a000 r-xp 08:03 130904 /bin/zsh # objdump -T /bin/zsh | grep -w zfree 00446420 gDF .text 0012 Basezfree -0x46420 is the offset of zfree in object /bin/zsh that is loaded at -0x0040. Hence the command to probe would be : + 0x46420 is the offset of zfree in object /bin/zsh that is loaded at + 0x0040. Hence the command to uprobe would be: + +# echo 'p:zfree_entry /bin/zsh:0x46420 %ip %ax' uprobe_events + + And the same for the uretprobe would be: -# echo 'p /bin/zsh:0x46420 %ip %ax'
[PATCH] gpio: lpc32xx: Fix off-by-one valid range checking for bank
The valid bank should be 0 ... ARRAY_SIZE(lpc32xx_gpiochip) - 1.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/gpio/gpio-lpc32xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-lpc32xx.c b/drivers/gpio/gpio-lpc32xx.c
index 36d7dee..dda6a75 100644
--- a/drivers/gpio/gpio-lpc32xx.c
+++ b/drivers/gpio/gpio-lpc32xx.c
@@ -533,7 +533,7 @@ static int lpc32xx_of_xlate(struct gpio_chip *gc,
{
/* Is this the correct bank? */
u32 bank = gpiospec-args[0];
- if ((bank ARRAY_SIZE(lpc32xx_gpiochip) ||
+ if ((bank = ARRAY_SIZE(lpc32xx_gpiochip) ||
(gc != lpc32xx_gpiochip[bank].chip)))
return -EINVAL;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
AMD Vi error and lost networking with r8169
I'm been seeing some problems with my new ish AMD motherboard/processor combo and networking (r8169). I see the following page fault :- Apr 7 12:25:14 david kernel: [156421.436545] AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0015 address=0x3000 flags=0x0050] Followed by the transmit queue timing out. This seems to hit randomly, sometimes it can take a day or so. A hard reset is the only way to recover networking. (Userspace is Ubuntu 10.04, kernel 3.9.0 rc5+) Cheers David Apr 7 12:26:09 david kernel: [156475.568257] [ cut here ] Apr 7 12:26:09 david kernel: [156475.568273] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x250/0x260() Apr 7 12:26:09 david kernel: [156475.568278] Hardware name: To be filled by O.E.M. Apr 7 12:26:09 david kernel: [156475.568282] NETDEV WATCHDOG: eth2 (r8169): transmit queue 0 timed out Apr 7 12:26:09 david kernel: [156475.568285] Modules linked in: xfs exportfs libcrc32c nls_iso8859_1 nls_cp437 vfat fat ecryptfs encrypted_keys nfsv3 nfs_acl nfs lockd sunrpc binfmt_misc ppdev dm_crypt hid_logitech uvcvideo ff_memless videobuf2_core videodev snd_usb_audio videobuf2_vmalloc snd_usbmidi_lib videobuf2_memops usbhid snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_seq_dummy snd_hwdep snd_seq_oss fbcon ttm tileblit font bitblit snd_pcm_oss softcursor snd_seq_midi drm_kms_helper snd_rawmidi snd_mixer_oss drm snd_seq_midi_event crc32_pclmul serio_raw snd_pcm snd_seq i2c_piix4 r8169 snd_timer snd_seq_device mii snd i2c_algo_bit soundcore snd_page_alloc lp parport Apr 7 12:26:09 david kernel: [156475.568348] Pid: 0, comm: swapper/0 Not tainted 3.9.0-rc5+ #17 Apr 7 12:26:09 david kernel: [156475.568351] Call Trace: Apr 7 12:26:09 david kernel: [156475.568354] IRQ [81039c2a] warn_slowpath_common+0x7a/0xc0 Apr 7 12:26:09 david kernel: [156475.568366] [81039d11] warn_slowpath_fmt+0x41/0x50 Apr 7 12:26:09 david kernel: [156475.568374] [81544630] dev_watchdog+0x250/0x260 Apr 7 12:26:09 david kernel: [156475.568380] [815443e0] ? __netdev_watchdog_up+0x80/0x80 Apr 7 12:26:09 david kernel: [156475.568386] [810497a4] call_timer_fn+0x44/0x120 Apr 7 12:26:09 david kernel: [156475.568391] [815443e0] ? __netdev_watchdog_up+0x80/0x80 Apr 7 12:26:09 david kernel: [156475.568396] [81049d83] run_timer_softirq+0x213/0x280 Apr 7 12:26:09 david kernel: [156475.568402] [81041dbf] __do_softirq+0xdf/0x260 Apr 7 12:26:09 david kernel: [156475.568408] [81042025] irq_exit+0xb5/0xc0 Apr 7 12:26:09 david kernel: [156475.568413] [81023fc9] smp_apic_timer_interrupt+0x69/0xa0 Apr 7 12:26:09 david kernel: [156475.568418] [81638e8a] apic_timer_interrupt+0x6a/0x70 Apr 7 12:26:09 david kernel: [156475.568420] EOI [8106e9a5] ? sched_clock_cpu+0xc5/0x100 Apr 7 12:26:09 david kernel: [156475.568432] [814e5542] ? cpuidle_wrap_enter+0x42/0x80 Apr 7 12:26:09 david kernel: [156475.568437] [814e553e] ? cpuidle_wrap_enter+0x3e/0x80 Apr 7 12:26:09 david kernel: [156475.568443] [814e5590] cpuidle_enter_tk+0x10/0x20 Apr 7 12:26:09 david kernel: [156475.568448] [814e4fc2] cpuidle_enter_state+0x12/0x50 Apr 7 12:26:09 david kernel: [156475.568453] [814e57d2] cpuidle_idle_call+0xa2/0x100 Apr 7 12:26:09 david kernel: [156475.568459] [8100a3b7] cpu_idle+0xc7/0x120 Apr 7 12:26:09 david kernel: [156475.568463] [8161fddd] rest_init+0x6d/0x80 Apr 7 12:26:09 david kernel: [156475.568470] [81cc7fe3] start_kernel+0x3b6/0x3c3 Apr 7 12:26:09 david kernel: [156475.568475] [81cc7a4d] ? repair_env_string+0x5b/0x5b Apr 7 12:26:09 david kernel: [156475.568481] [81cc75a1] x86_64_start_reservations+0x2a/0x2c Apr 7 12:26:09 david kernel: [156475.568486] [81cc76cc] x86_64_start_kernel+0x129/0x130 Apr 7 12:26:09 david kernel: [156475.568489] ---[ end trace 31688db2ca49b077 ]--- Apr 7 12:26:09 david kernel: [156475.720834] r8169 :02:00.0 eth2: link up dmesg.log.bz2 Description: application/bzip config.bz2 Description: application/bzip
Re: [PATCH] do not try to sync identity map for non-mapped pages
Hey Dave, On Thu, Mar 07, 2013 at 08:31:51AM -0800, Dave Hansen wrote: The original bug reporter says this fixes it for him, so I'm broadening the cc list a bit. I assume this should just get sucked in to the x86 tree. looks like we haven't whacked all the moles - I keep seeing this when testing 32-bit builds in qemu on latest Linus + tip. I'd guess this is still that /dev/mem accessing thing called wdm. I'm still wondering though whether we should BUG_ON on a /dev/mem access? I've added debug output to show why we're triggering: [ 471.102902] slow_virt_to_phys((void *)x): 0x0, phys_addr: 0x37bfe000 [ 471.119500] [ cut here ] [ 471.119500] kernel BUG at arch/x86/mm/physaddr.c:85! [ 471.119500] invalid opcode: [#1] PREEMPT SMP [ 471.119500] Modules linked in: [ 471.119500] Pid: 1571, comm: wdm Not tainted 3.9.0-rc5+ #42 Bochs Bochs [ 471.119500] EIP: 0060:[c1032f56] EFLAGS: 0206 CPU: 0 [ 471.119500] EIP is at __phys_addr+0x86/0xb0 [ 471.119500] EAX: 37bfe000 EBX: 37bfe000 ECX: 0001 EDX: 37bfe000 [ 471.119500] ESI: f7bfe000 EDI: 2000 EBP: f67f1f3c ESP: f67f1f28 [ 471.119500] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 471.119500] CR0: 8005003b CR2: bfeb12d4 CR3: 35edd000 CR4: 06f0 [ 471.119500] DR0: DR1: DR2: DR3: [ 471.119500] DR6: DR7: [ 471.119500] Process wdm (pid: 1571, ti=f67f task=f5c9 task.ti=f67f) [ 471.119500] Stack: [ 471.119500] c16b1f2c 37bfe000 2000 f67f1f64 c131d074 2000 [ 471.119500] 0246 bfeb12ec f67a6c40 c131d040 2000 f67f1f8c [ 471.119500] c1129c85 f67f1f98 f67f f5ebe864 c131d040 0020 f67a6c40 [ 471.119500] Call Trace: [ 471.119500] [c131d074] read_mem+0x34/0x100 [ 471.119500] [c131d040] ? write_mem+0x110/0x110 [ 471.119500] [c1129c85] vfs_read+0x85/0x130 [ 471.119500] [c131d040] ? write_mem+0x110/0x110 [ 471.119500] [c1129e87] sys_read+0x47/0xa0 [ 471.119500] [c1546e5e] sysenter_do_call+0x12/0x36 [ 471.119500] Code: 0b a1 88 ae 0c c2 05 00 00 80 00 39 c6 72 bb a1 ac 1a 76 c1 2d 00 a0 3e 00 25 00 00 e0 ff 2d 00 20 00 00 39 c6 73 a3 0f 0b 0f 0b 0f 0b 89 f0 e8 41 ca ff ff 89 5c 24 08 89 44 24 04 c7 04 24 2c [ 471.119500] EIP: [c1032f56] __phys_addr+0x86/0xb0 SS:ESP 0068:f67f1f28 [ 471.508967] ---[ end trace 5fc00ac35d61284a ]--- Hmmm. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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/6] uprobes/tracing: Introduce uprobe_{trace,perf}_print() helpers
* Oleg Nesterov o...@redhat.com [2013-04-01 18:08:45]:
Extract the output code from uprobe_trace_func() and uprobe_perf_func()
into the new helpers, they will be used by -ret_handler() too. We also
add the unused unsigned long func argument in advance, to simplify the
next changes.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
kernel/trace/trace_uprobe.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 92a4b08..2ea9961 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -496,8 +496,8 @@ static const struct file_operations uprobe_profile_ops = {
.release= seq_release,
};
-/* uprobe handler */
-static int uprobe_trace_func(struct trace_uprobe *tu, struct pt_regs *regs)
+static void uprobe_trace_print(struct trace_uprobe *tu,
+ unsigned long func, struct pt_regs *regs)
{
struct uprobe_trace_entry_head *entry;
struct ring_buffer_event *event;
@@ -510,7 +510,7 @@ static int uprobe_trace_func(struct trace_uprobe *tu,
struct pt_regs *regs)
event = trace_current_buffer_lock_reserve(buffer, call-event.type,
size, 0, 0);
if (!event)
- return 0;
+ return;
entry = ring_buffer_event_data(event);
entry-vaddr[0] = instruction_pointer(regs);
@@ -520,7 +520,12 @@ static int uprobe_trace_func(struct trace_uprobe *tu,
struct pt_regs *regs)
if (!filter_current_check_discard(buffer, call, entry, event))
trace_buffer_unlock_commit(buffer, event, 0, 0);
+}
+/* uprobe handler */
+static int uprobe_trace_func(struct trace_uprobe *tu, struct pt_regs *regs)
+{
+ uprobe_trace_print(tu, 0, regs);
return 0;
}
@@ -753,8 +758,8 @@ static bool uprobe_perf_filter(struct uprobe_consumer *uc,
return ret;
}
-/* uprobe profile handler */
-static int uprobe_perf_func(struct trace_uprobe *tu, struct pt_regs *regs)
+static void uprobe_perf_print(struct trace_uprobe *tu,
+ unsigned long func, struct pt_regs *regs)
{
struct ftrace_event_call *call = tu-call;
struct uprobe_trace_entry_head *entry;
@@ -763,13 +768,10 @@ static int uprobe_perf_func(struct trace_uprobe *tu,
struct pt_regs *regs)
void *data;
int size, rctx, i;
- if (!uprobe_perf_filter(tu-consumer, 0, current-mm))
- return UPROBE_HANDLER_REMOVE;
-
size = SIZEOF_TRACE_ENTRY(1);
size = ALIGN(size + tu-size + sizeof(u32), sizeof(u64)) - sizeof(u32);
if (WARN_ONCE(size PERF_MAX_TRACE_SIZE, profile buffer not large
enough))
- return 0;
+ return;
preempt_disable();
entry = perf_trace_buf_prepare(size, call-event.type, regs, rctx);
@@ -786,6 +788,15 @@ static int uprobe_perf_func(struct trace_uprobe *tu,
struct pt_regs *regs)
perf_trace_buf_submit(entry, size, rctx, ip, 1, regs, head, NULL);
out:
preempt_enable();
+}
+
+/* uprobe profile handler */
+static int uprobe_perf_func(struct trace_uprobe *tu, struct pt_regs *regs)
+{
+ if (!uprobe_perf_filter(tu-consumer, 0, current-mm))
+ return UPROBE_HANDLER_REMOVE;
+
+ uprobe_perf_print(tu, 0, regs);
return 0;
}
#endif /* CONFIG_PERF_EVENTS */
--
1.5.5.1
--
Thanks and Regards
Srikar Dronamraju
--
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 0/9] extend hugepage migration
Please refer to hugetlb_fault for more information. Thanks for your pointing out. So my assume is correct, is it? Can pmd which support 2MB map 32MB pages work well? Simon, Please stop hijaking unrelated threads. This is not question and answer thread. -- 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/6] uprobes/tracing: Introduce is_ret_probe() and uretprobe_dispatcher()
* Oleg Nesterov o...@redhat.com [2013-04-01 18:08:48]:
Create the new functions we need to support uretprobes, and change
alloc_trace_uprobe() to initialize consumer.ret_handler if the new
is_ret argument is true. Curently this argument is always false,
so the new code is never called and is_ret_probe(tu) is false too.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
kernel/trace/trace_uprobe.c | 42 --
1 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 2ea9961..e91a354 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -75,6 +75,8 @@ static DEFINE_MUTEX(uprobe_lock);
static LIST_HEAD(uprobe_list);
static int uprobe_dispatcher(struct uprobe_consumer *con, struct pt_regs
*regs);
+static int uretprobe_dispatcher(struct uprobe_consumer *con,
+ unsigned long func, struct pt_regs *regs);
static inline void init_trace_uprobe_filter(struct trace_uprobe_filter
*filter)
{
@@ -88,11 +90,16 @@ static inline bool uprobe_filter_is_empty(struct
trace_uprobe_filter *filter)
return !filter-nr_systemwide list_empty(filter-perf_events);
}
+static inline bool is_ret_probe(struct trace_uprobe *tu)
+{
+ return tu-consumer.ret_handler != NULL;
+}
+
/*
* Allocate new trace_uprobe and initialize it (including uprobes).
*/
static struct trace_uprobe *
-alloc_trace_uprobe(const char *group, const char *event, int nargs)
+alloc_trace_uprobe(const char *group, const char *event, int nargs, bool
is_ret)
{
struct trace_uprobe *tu;
@@ -117,6 +124,8 @@ alloc_trace_uprobe(const char *group, const char *event,
int nargs)
INIT_LIST_HEAD(tu-list);
tu-consumer.handler = uprobe_dispatcher;
+ if (is_ret)
+ tu-consumer.ret_handler = uretprobe_dispatcher;
init_trace_uprobe_filter(tu-filter);
return tu;
@@ -314,7 +323,7 @@ static int create_trace_uprobe(int argc, char **argv)
kfree(tail);
}
- tu = alloc_trace_uprobe(group, event, argc);
+ tu = alloc_trace_uprobe(group, event, argc, false);
if (IS_ERR(tu)) {
pr_info(Failed to allocate trace_uprobe.(%d)\n,
(int)PTR_ERR(tu));
ret = PTR_ERR(tu);
@@ -529,6 +538,12 @@ static int uprobe_trace_func(struct trace_uprobe *tu,
struct pt_regs *regs)
return 0;
}
+static void uretprobe_trace_func(struct trace_uprobe *tu, unsigned long func,
+ struct pt_regs *regs)
+{
+ uprobe_trace_print(tu, func, regs);
+}
+
/* Event entry printers */
static enum print_line_t
print_uprobe_event(struct trace_iterator *iter, int flags, struct
trace_event *event)
@@ -799,6 +814,12 @@ static int uprobe_perf_func(struct trace_uprobe *tu,
struct pt_regs *regs)
uprobe_perf_print(tu, 0, regs);
return 0;
}
+
+static void uretprobe_perf_func(struct trace_uprobe *tu, unsigned long func,
+ struct pt_regs *regs)
+{
+ uprobe_perf_print(tu, func, regs);
+}
#endif /* CONFIG_PERF_EVENTS */
static
@@ -853,6 +874,23 @@ static int uprobe_dispatcher(struct uprobe_consumer
*con, struct pt_regs *regs)
return ret;
}
+static int uretprobe_dispatcher(struct uprobe_consumer *con,
+ unsigned long func, struct pt_regs *regs)
+{
+ struct trace_uprobe *tu;
+
+ tu = container_of(con, struct trace_uprobe, consumer);
+
+ if (tu-flags TP_FLAG_TRACE)
+ uretprobe_trace_func(tu, func, regs);
+
+#ifdef CONFIG_PERF_EVENTS
+ if (tu-flags TP_FLAG_PROFILE)
+ uretprobe_perf_func(tu, func, regs);
+#endif
+ return 0;
+}
+
static struct trace_event_functions uprobe_funcs = {
.trace = print_uprobe_event
};
--
1.5.5.1
--
Thanks and Regards
Srikar Dronamraju
--
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 4/6] uprobes/tracing: Make register_uprobe_event() paths uretprobe-friendly
* Oleg Nesterov o...@redhat.com [2013-04-01 18:08:54]:
Change uprobe_event_define_fields(), and __set_print_fmt() to check
is_ret_probe() and use the appropriate format/fields.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
kernel/trace/trace_uprobe.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index db2718a..f75e52d 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -631,8 +631,14 @@ static int uprobe_event_define_fields(struct
ftrace_event_call *event_call)
struct uprobe_trace_entry_head field;
struct trace_uprobe *tu = event_call-data;
- DEFINE_FIELD(unsigned long, vaddr[0], FIELD_STRING_IP, 0);
- size = SIZEOF_TRACE_ENTRY(1);
+ if (is_ret_probe(tu)) {
+ DEFINE_FIELD(unsigned long, vaddr[0], FIELD_STRING_FUNC, 0);
+ DEFINE_FIELD(unsigned long, vaddr[1], FIELD_STRING_RETIP, 0);
+ size = SIZEOF_TRACE_ENTRY(2);
+ } else {
+ DEFINE_FIELD(unsigned long, vaddr[0], FIELD_STRING_IP, 0);
+ size = SIZEOF_TRACE_ENTRY(1);
+ }
/* Set argument names as fields */
for (i = 0; i tu-nr_args; i++) {
ret = trace_define_field(event_call, tu-args[i].type-fmttype,
@@ -655,8 +661,13 @@ static int __set_print_fmt(struct trace_uprobe *tu, char
*buf, int len)
int i;
int pos = 0;
- fmt = (%lx);
- arg = REC- FIELD_STRING_IP;
+ if (is_ret_probe(tu)) {
+ fmt = (%lx - %lx);
+ arg = REC- FIELD_STRING_FUNC , REC- FIELD_STRING_RETIP;
+ } else {
+ fmt = (%lx);
+ arg = REC- FIELD_STRING_IP;
+ }
/* When len=0, we just calculate the needed length */
--
1.5.5.1
--
Thanks and Regards
Srikar Dronamraju
--
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 5/6] uprobes/tracing: Make seq_printf() code uretprobe-friendly
* Oleg Nesterov o...@redhat.com [2013-04-01 18:08:57]:
Change probes_seq_show() and print_uprobe_event() to check
is_ret_probe() and print the correct data.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
kernel/trace/trace_uprobe.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index f75e52d..1b3622a 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -434,9 +434,10 @@ static void probes_seq_stop(struct seq_file *m, void *v)
static int probes_seq_show(struct seq_file *m, void *v)
{
struct trace_uprobe *tu = v;
+ char c = is_ret_probe(tu) ? 'r' : 'p';
int i;
- seq_printf(m, p:%s/%s, tu-call.class-system, tu-call.name);
+ seq_printf(m, %c:%s/%s, c, tu-call.class-system, tu-call.name);
seq_printf(m, %s:0x%p, tu-filename, (void *)tu-offset);
for (i = 0; i tu-nr_args; i++)
@@ -569,10 +570,18 @@ print_uprobe_event(struct trace_iterator *iter, int
flags, struct trace_event *e
entry = (struct uprobe_trace_entry_head *)iter-ent;
tu = container_of(event, struct trace_uprobe, call.event);
- if (!trace_seq_printf(s, %s: (0x%lx), tu-call.name, entry-vaddr[0]))
- goto partial;
+ if (is_ret_probe(tu)) {
+ if (!trace_seq_printf(s, %s: (0x%lx - 0x%lx), tu-call.name,
+ entry-vaddr[1], entry-vaddr[0]))
+ goto partial;
+ data = DATAOF_TRACE_ENTRY(entry, 2);
+ } else {
+ if (!trace_seq_printf(s, %s: (0x%lx), tu-call.name,
+ entry-vaddr[0]))
+ goto partial;
+ data = DATAOF_TRACE_ENTRY(entry, 1);
+ }
- data = DATAOF_TRACE_ENTRY(entry, 1);
for (i = 0; i tu-nr_args; i++) {
if (!tu-args[i].type-print(s, tu-args[i].name,
data + tu-args[i].offset, entry))
--
1.5.5.1
--
Thanks and Regards
Srikar Dronamraju
--
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 6/6] uprobes/tracing: Change create_trace_uprobe() to support uretprobes
* Oleg Nesterov o...@redhat.com [2013-04-01 18:09:00]:
Finally change create_trace_uprobe() to check if argv[0][0] == 'r'
and pass the correct is_ret to alloc_trace_uprobe().
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
kernel/trace/trace_uprobe.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 1b3622a..2773d2a 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -200,7 +200,7 @@ end:
/*
* Argument syntax:
- * - Add uprobe: p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS]
+ * - Add uprobe: p|r[:[GRP/]EVENT] PATH:SYMBOL [FETCHARGS]
*
* - Remove uprobe: -:[GRP/]EVENT
*/
@@ -212,20 +212,23 @@ static int create_trace_uprobe(int argc, char **argv)
char buf[MAX_EVENT_NAME_LEN];
struct path path;
unsigned long offset;
- bool is_delete;
+ bool is_delete, is_return;
int i, ret;
inode = NULL;
ret = 0;
is_delete = false;
+ is_return = false;
event = NULL;
group = NULL;
/* argc must be = 1 */
if (argv[0][0] == '-')
is_delete = true;
+ else if (argv[0][0] == 'r')
+ is_return = true;
else if (argv[0][0] != 'p') {
- pr_info(Probe definition must be started with 'p' or '-'.\n);
+ pr_info(Probe definition must be started with 'p', 'r' or
'-'.\n);
return -EINVAL;
}
@@ -323,7 +326,7 @@ static int create_trace_uprobe(int argc, char **argv)
kfree(tail);
}
- tu = alloc_trace_uprobe(group, event, argc, false);
+ tu = alloc_trace_uprobe(group, event, argc, is_return);
if (IS_ERR(tu)) {
pr_info(Failed to allocate trace_uprobe.(%d)\n,
(int)PTR_ERR(tu));
ret = PTR_ERR(tu);
--
1.5.5.1
--
Thanks and Regards
Srikar Dronamraju
--
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] kernel: module: strncpy issue, using strlcpy instead of strncpy
On Sun, Apr 7, 2013 at 1:38 PM, Chen Gang gang.c...@asianux.com wrote:
ownername and namebuf are all NUL terminated string.
need always let them ended by '\0'.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
kernel/module.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 3c2c72d..597efd8 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3464,7 +3464,7 @@ const char *module_address_lookup(unsigned long addr,
}
/* Make a copy in here where it's safe */
if (ret) {
- strncpy(namebuf, ret, KSYM_NAME_LEN - 1);
+ strlcpy(namebuf, ret, KSYM_NAME_LEN);
ret = namebuf;
}
preempt_enable();
Is this buffer ever copied to userspace?
If yes, it may leak innocent kernel stack to userspace, as strlcpy()
doesn't fill
the remaining of the buffer with zeroes, while strncpy() does.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 arm: initial TI-Nspire support]
On Sunday 07 April 2013, Daniel Tang wrote:
On 07/04/2013, at 12:24 AM, Arnd Bergmann a...@arndb.de wrote:
@@ -313,7 +314,7 @@ define archhelp
echo ' Image - Uncompressed kernel image
(arch/$(ARCH)/boot/Image)'
echo '* xipImage - XIP kernel image, if configured
(arch/$(ARCH)/boot/xipImage)'
echo ' uImage- U-Boot wrapped zImage'
- echo ' bootpImage- Combined zImage and initial RAM disk'
+ echo ' bootpImage- Combined zImage and initial RAM disk'
echo ' (supply initrd image via make variable
INITRD=path)'
echo '* dtbs - Build device tree blobs for enabled boards'
echo ' install - Install uncompressed kernel'
This looks like it wasn't meant to be in the patch.
It probably isn't. I think there was trailing whitespace on that and my
editor happened to remove it automatically.
Should this be a separate patch to fix up formatting or should I leave it in
as a drive-by fix?
Any cleanups like this should be separate patches, and ideally even
part of a different patch series.
+ uart: uart@9002 {
+ reg = 0x9002 0x1000;
+ interrupts = 1;
+
+ clocks = uart_clk;
+ clock-names = uart_clk;
+ };
The name for a uart should be serial. Since this is a pl01x, please add
the required properties for the device, e.g.
compatible = arm,pl011, arm,primecell;
You will need the arm,primecell bit to make the device appear on the
amba bus rather than the platform bus.
That was actually deliberate because different models of the TI-NSPIRE have
different
serial hardware. On the newer CX models, it is a PL01x and on the older
models, it has
a 8250-like interface. They all reside at the same address with the same IRQ
though.
I thought it might be cleaner to specify the interrupts and registers in the
common file
and leave it to the board specific ones to implement the compatible
property.
I see. It seems a little confusing to the reader though. I don't have a good
answer,
but there are two other options how this can be handled:
* Put both devices in the devicetree and mark them as status=disabled in the
main file,
but enable one of them in the version specific files.
* leave them out of the .dtsi file and only define them in the specific .dts
files.
+ err = of_property_read_string(of_aliases, timer0, path);
+ if (WARN_ON(err))
+ return;
+
+ timer = of_find_node_by_path(path);
+ base = of_iomap(timer, 0);
+ if (WARN_ON(!base))
+ return;
+
+ clk = of_clk_get_by_name(timer, NULL);
+ clk_register_clkdev(clk, timer-name, sp804);
+
+ sp804_clocksource_init(base, timer-name);
+
+ err = of_property_read_string(of_aliases, timer1, path);
+ if (WARN_ON(err))
+ return;
In particular, I think the method of using aliases to pick the right sp804
instance is being deprecated now. If both timers are identical, the kernel
will now just pick one of them.
Sorry, I don't quite understand.
Out of the timers, I want to add one as a clocksource and one as a clockevent.
If they're identical (i.e. without using aliases), how should I tell the
kernel,
Take the first timer you see and make it a clocksource, take the next one you
see and make it a clockevent?
The modified sp804 driver will have logic to do that. I think in the end we
decided that the driver should first look for any device that can be used as
a clocksource and use it that way. If it finds a second device, that can be
used as clockevent.
Arnd
--
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] ARM: at91: remove trailing semicolon from macros
Remove trailing semicolon from register-access macros. Signed-off-by: Johan Hovold jhov...@gmail.com --- arch/arm/mach-at91/at91_rstc.h| 2 +- arch/arm/mach-at91/at91_shdwc.h | 2 +- arch/arm/mach-at91/at91x40_time.c | 2 +- arch/arm/mach-at91/include/mach/at91_matrix.h | 2 +- arch/arm/mach-at91/include/mach/at91_st.h | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-at91/at91_rstc.h b/arch/arm/mach-at91/at91_rstc.h index 875fa33..a600e69 100644 --- a/arch/arm/mach-at91/at91_rstc.h +++ b/arch/arm/mach-at91/at91_rstc.h @@ -23,7 +23,7 @@ extern void __iomem *at91_rstc_base; __raw_readl(at91_rstc_base + field) #define at91_rstc_write(field, value) \ - __raw_writel(value, at91_rstc_base + field); + __raw_writel(value, at91_rstc_base + field) #else .extern at91_rstc_base #endif diff --git a/arch/arm/mach-at91/at91_shdwc.h b/arch/arm/mach-at91/at91_shdwc.h index 60478ea..9e29f31 100644 --- a/arch/arm/mach-at91/at91_shdwc.h +++ b/arch/arm/mach-at91/at91_shdwc.h @@ -23,7 +23,7 @@ extern void __iomem *at91_shdwc_base; __raw_readl(at91_shdwc_base + field) #define at91_shdwc_write(field, value) \ - __raw_writel(value, at91_shdwc_base + field); + __raw_writel(value, at91_shdwc_base + field) #endif #define AT91_SHDW_CR 0x00/* Shut Down Control Register */ diff --git a/arch/arm/mach-at91/at91x40_time.c b/arch/arm/mach-at91/at91x40_time.c index 0e57e44..f4c81c2 100644 --- a/arch/arm/mach-at91/at91x40_time.c +++ b/arch/arm/mach-at91/at91x40_time.c @@ -33,7 +33,7 @@ __raw_readl(AT91_IO_P2V(AT91_TC) + field) #define at91_tc_write(field, value) \ - __raw_writel(value, AT91_IO_P2V(AT91_TC) + field); + __raw_writel(value, AT91_IO_P2V(AT91_TC) + field) /* * 3 counter/timer units present. diff --git a/arch/arm/mach-at91/include/mach/at91_matrix.h b/arch/arm/mach-at91/include/mach/at91_matrix.h index 02fae9d..f8996c9 100644 --- a/arch/arm/mach-at91/include/mach/at91_matrix.h +++ b/arch/arm/mach-at91/include/mach/at91_matrix.h @@ -14,7 +14,7 @@ extern void __iomem *at91_matrix_base; __raw_readl(at91_matrix_base + field) #define at91_matrix_write(field, value) \ - __raw_writel(value, at91_matrix_base + field); + __raw_writel(value, at91_matrix_base + field) #else .extern at91_matrix_base diff --git a/arch/arm/mach-at91/include/mach/at91_st.h b/arch/arm/mach-at91/include/mach/at91_st.h index 969aac2..67fdbd1 100644 --- a/arch/arm/mach-at91/include/mach/at91_st.h +++ b/arch/arm/mach-at91/include/mach/at91_st.h @@ -23,7 +23,7 @@ extern void __iomem *at91_st_base; __raw_readl(at91_st_base + field) #define at91_st_write(field, value) \ - __raw_writel(value, at91_st_base + field); + __raw_writel(value, at91_st_base + field) #else .extern at91_st_base #endif -- 1.8.1.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 1/2] ARM: at91/setup: fix trivial typos
Fix a few trivial typos in panic, warning and debug messages.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
arch/arm/mach-at91/setup.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index 4b67847..9e7c1e1 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -333,7 +333,7 @@ static void at91_dt_rstc(void)
of_id = of_match_node(rstc_ids, np);
if (!of_id)
- panic(AT91: rtsc no restart function availlable\n);
+ panic(AT91: rtsc no restart function available\n);
arm_pm_restart = of_id-data;
@@ -353,7 +353,7 @@ static void at91_dt_ramc(void)
np = of_find_matching_node(NULL, ramc_ids);
if (!np)
- panic(unable to find compatible ram conroller node in dtb\n);
+ panic(unable to find compatible ram controller node in dtb\n);
at91_ramc_base[0] = of_iomap(np, 0);
if (!at91_ramc_base[0])
@@ -403,7 +403,7 @@ static void at91_dt_shdwc(void)
np = of_find_matching_node(NULL, shdwc_ids);
if (!np) {
- pr_debug(AT91: unable to find compatible shutdown (shdwc)
conroller node in dtb\n);
+ pr_debug(AT91: unable to find compatible shutdown (shdwc)
controller node in dtb\n);
return;
}
@@ -419,7 +419,7 @@ static void at91_dt_shdwc(void)
if (!of_property_read_u32(np, atmel,wakeup-counter, reg)) {
if (reg AT91_SHDW_CPTWK0_MAX) {
- pr_warn(AT91: shdwc wakeup conter 0x%x 0x%x reduce
it to 0x%x\n,
+ pr_warn(AT91: shdwc wakeup counter 0x%x 0x%x reduce
it to 0x%x\n,
reg, AT91_SHDW_CPTWK0_MAX,
AT91_SHDW_CPTWK0_MAX);
reg = AT91_SHDW_CPTWK0_MAX;
}
--
1.8.1.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: [RFC PATCH] wfcqueue: implement __wfcq_enqueue_head() (v2)
* Eric Wong (normalper...@yhbt.net) wrote: Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: Implement enqueue-to-head. It can run concurrently with enqueue, splice to queue, and iteration, but requires a mutex against dequeue and splice from queue operations. Useful for special-cases where a queue needs to have nodes enqueued into its head. This patch is only compile-tested. Changes since v1: * Don't require mutual exclusion between traversals and __wfcq_enqueue_head(). Signed-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com Thanks! The first hunk (sync table comment) conflicted with my __wfcq_enqueue patch, but other than that I could not benchmark any regression with my 4-core machine with v4 of my epoll: avoid spinlock contention with wfcqueue patch. All I needed was s/__wfcq_prepend/__wfcq_enqueue_head/g to my original patch to use the updated API. I was worried about the cmpxchg at first, but it does not seem to hurt performance on my 4-core system. In fact, it was slightly better (but within margin of error) time ./eponeshotmt -c 100 -w 4 -t 4 -f 10 real0m 5.78s user0m 1.20s sys 0m 21.90s Tested-by: Eric Wong normalper...@yhbt.net Hopefully somebody can test my epoll patches with more cores/threads :) Thanks for testing. Taking care of your comments, and of memory barriers, brings me to send a v3 of this patch shortly. Testing is welcome! Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.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 v4, part3 00/15] accurately calculate memory statisitic information
On 04/07/2013 09:34 AM, Simon Jeons wrote: Hi Jiang, On 04/06/2013 09:54 PM, Jiang Liu wrote: Jiang Liu (15): mm: fix build warnings caused by free_reserved_area() mm: enhance free_reserved_area() to support poisoning memory with zero mm/ARM64: kill poison_init_mem() mm/x86: use free_reserved_area() to simplify code mm/tile: use common help functions to free reserved pages mm, powertv: use free_reserved_area() to simplify code mm, acornfb: use free_reserved_area() to simplify code mm: fix some trivial typos in comments mm: use managed_pages to calculate default zonelist order mm: accurately calculate zone-managed_pages for highmem zones mm: use a dedicated lock to protect totalram_pages and zone-managed_pages mm: make __free_pages_bootmem() only available at boot time mm: correctly update zone-mamaged_pages mm: concentrate modification of totalram_pages into the mm core mm: report available pages as MemTotal for each NUMA node What I interested in is how you test different platform? I don't think you can have all the physical platform. Hi Simon, That's one issue I'm facing, I only have limited hardware platforms for testing, so I could ask for help from the community to review and test the patch series. Regards! Gerry -- 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/4] regulator: ab8500: Get rid of is_enabled from struct ab8500_regulator_info
The intention of this patch is to simplify the code.
Maintain the is_enabled flag is not trivial, it not only needs to set/clear the
flag in disable()/enable() but also needs to set the flag in is_enable() to get
initial status. The only benefit of keeping is_enabled flag is just save a
register read when set_mode(). Remove is_enabled flag makes the code simpler.
This patch also moves ab8500_regulator_is_enabled() close to
ab8500_regulator_[en|dis]able functions.
This is required to avoid a forward declaration because now we call
ab8500_regulator_is_enabled() in ab8500_regulator_set_mode().
This change also makes the code better in readability by moving similar
functions to one place.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/regulator/ab8500.c | 72
1 file changed, 32 insertions(+), 40 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 517305e..9ebd131 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -46,7 +46,6 @@ struct ab8500_shared_mode {
* @desc: regulator description
* @regulator_dev: regulator device
* @shared_mode: used when mode is shared between two regulators
- * @is_enabled: status of regulator (on/off)
* @load_lp_uA: maximum load in idle (low power) mode
* @update_bank: bank to control on/off
* @update_reg: register to control on/off
@@ -69,7 +68,6 @@ struct ab8500_regulator_info {
struct regulator_desc desc;
struct regulator_dev*regulator;
struct ab8500_shared_mode *shared_mode;
- bool is_enabled;
int load_lp_uA;
u8 update_bank;
u8 update_reg;
@@ -259,8 +257,6 @@ static int ab8500_regulator_enable(struct regulator_dev
*rdev)
return ret;
}
- info-is_enabled = true;
-
dev_vdbg(rdev_get_dev(rdev),
%s-enable (bank, reg, mask, value): 0x%x, 0x%x, 0x%x, 0x%x\n,
info-desc.name, info-update_bank, info-update_reg,
@@ -288,8 +284,6 @@ static int ab8500_regulator_disable(struct regulator_dev
*rdev)
return ret;
}
- info-is_enabled = false;
-
dev_vdbg(rdev_get_dev(rdev),
%s-disable (bank, reg, mask, value): 0x%x, 0x%x, 0x%x, 0x%x\n,
info-desc.name, info-update_bank, info-update_reg,
@@ -298,6 +292,37 @@ static int ab8500_regulator_disable(struct regulator_dev
*rdev)
return ret;
}
+static int ab8500_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ int ret;
+ struct ab8500_regulator_info *info = rdev_get_drvdata(rdev);
+ u8 regval;
+
+ if (info == NULL) {
+ dev_err(rdev_get_dev(rdev), regulator info null pointer\n);
+ return -EINVAL;
+ }
+
+ ret = abx500_get_register_interruptible(info-dev,
+ info-update_bank, info-update_reg, regval);
+ if (ret 0) {
+ dev_err(rdev_get_dev(rdev),
+ couldn't read 0x%x register\n, info-update_reg);
+ return ret;
+ }
+
+ dev_vdbg(rdev_get_dev(rdev),
+ %s-is_enabled (bank, reg, mask, value): 0x%x, 0x%x, 0x%x,
+0x%x\n,
+ info-desc.name, info-update_bank, info-update_reg,
+ info-update_mask, regval);
+
+ if (regval info-update_mask)
+ return 1;
+ else
+ return 0;
+}
+
static unsigned int ab8500_regulator_get_optimum_mode(
struct regulator_dev *rdev, int input_uV,
int output_uV, int load_uA)
@@ -398,7 +423,7 @@ static int ab8500_regulator_set_mode(struct regulator_dev
*rdev,
mask = info-update_mask;
}
- if (info-is_enabled || dmr) {
+ if (dmr || ab8500_regulator_is_enabled(rdev)) {
ret = abx500_mask_and_set_register_interruptible(info-dev,
bank, reg, mask, val);
if (ret 0)
@@ -464,39 +489,6 @@ static unsigned int ab8500_regulator_get_mode(struct
regulator_dev *rdev)
return ret;
}
-static int ab8500_regulator_is_enabled(struct regulator_dev *rdev)
-{
- int ret;
- struct ab8500_regulator_info *info = rdev_get_drvdata(rdev);
- u8 regval;
-
- if (info == NULL) {
- dev_err(rdev_get_dev(rdev), regulator info null pointer\n);
- return -EINVAL;
- }
-
- ret = abx500_get_register_interruptible(info-dev,
- info-update_bank, info-update_reg, regval);
- if (ret 0) {
- dev_err(rdev_get_dev(rdev),
- couldn't read 0x%x register\n, info-update_reg);
- return ret;
- }
-
- dev_vdbg(rdev_get_dev(rdev),
- %s-is_enabled (bank, reg, mask, value): 0x%x, 0x%x, 0x%x,
-0x%x\n,
- info-desc.name, info-update_bank, info-update_reg,
- info-update_mask, regval);
-
-
[RFC PATCH] wfcqueue: implement __wfcq_enqueue_head() (v3)
Implement enqueue-to-head. It can run concurrently with enqueue, splice
to queue, and iteration, but requires a mutex against dequeue and splice
from queue operations.
Useful for special-cases where a queue needs to have nodes enqueued into
its head.
This patch is only compile-tested.
Changes since v1:
* Don't require mutual exclusion between traversals and
__wfcq_enqueue_head().
Changes since v2:
* Only issue cmpxchg() if queue was empty.
* Add missing memory barrier.
Signed-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com
---
include/linux/wfcqueue.h | 76 ++-
1 file changed, 69 insertions(+), 7 deletions(-)
Index: linux/include/linux/wfcqueue.h
===
--- linux.orig/include/linux/wfcqueue.h
+++ linux/include/linux/wfcqueue.h
@@ -55,14 +55,16 @@
* [4] __wfcq_splice (source queue)
* [5] __wfcq_first
* [6] __wfcq_next
+ * [7] __wfcq_enqueue_head
*
- * [1] [2] [3] [4] [5] [6]
- * [1] - - - - - -
- * [2] - - - - - -
- * [3] - - X X X X
- * [4] - - X - X X
- * [5] - - X X - -
- * [6] - - X X - -
+ * [1] [2] [3] [4] [5] [6] [7]
+ * [1] - - - - - - -
+ * [2] - - - - - - X
+ * [3] - - X X X X X
+ * [4] - - X - X X X
+ * [5] - - X X - - -
+ * [6] - - X X - - -
+ * [7] - X X X - - X
*
* Besides locking, mutual exclusion of dequeue, splice and iteration
* can be ensured by performing all of those operations from a single
@@ -230,6 +232,66 @@ ___wfcq_node_sync_next(struct wfcq_node
}
/*
+ * __wfcq_enqueue_head: prepend a node into a queue.
+ *
+ * Issues a write memory barrier before enqueue to head. Mutual
+ * exclusion is the responsibility of the caller.
+ *
+ * Returns false if the queue was empty prior to adding the node.
+ * Returns true otherwise.
+ */
+static inline bool __wfcq_enqueue_head(struct wfcq_head *head,
+ struct wfcq_tail *tail,
+ struct wfcq_node *node)
+{
+ bool not_empty = 0;
+
+/*
+* Move tail if queue was empty. Tail pointer is the
+* linearisation point of enqueuers.
+*/
+ if (CMM_LOAD_SHARED(tail-p) != head-node
+ || cmpxchg(tail-p, head-node, node)
+ != head-node) {
+ not_empty = 1;
+
+ /*
+* Queue was non-empty. We need to wait for
+* head-node.next to become non-NULL, because a
+* concurrent wfcq_append may be updating it.
+*/
+ CMM_STORE_SHARED(node-next,
+ ___wfcq_node_sync_next(head-node));
+ }
+
+ /*
+* If cmpxchg succeeds (queue was empty), tail now points to
+* node, but head-node.next is still NULL. Concurrent
+* traversals seeing this state will busy-wait until we set
+* head-node.next.
+*
+* Else, queue was observed as not empty: traversals will only
+* see node after we set head-node.next.
+*/
+
+ /*
+* Orders earlier stores to data structure containing node and
+* setting node-next to NULL (or to previous head-node.next
+* value) before publication.
+*/
+ smp_wmb();
+
+ /*
+* From this point, we know that wfcq_append cannot touch
+* head-node.next, either because we successfully moved tail-p
+* to node, or because we waited for head-node.next to become
+* non-NULL. It is therefore safe to update it.
+*/
+ CMM_STORE_SHARED(head-node.next, node);
+ return not_empty;
+}
+
+/*
* __wfcq_first: get first node of a queue, without dequeuing.
*
* Content written into the node before enqueue is guaranteed to be
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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/
[PATCH 2/4] regulator: ab8500-ext: Get rid of is_enabled from struct ab8500_ext_regulator_info
The intention of this patch is to simplify the code.
Maintain the is_enabled flag is not trivial, it not only needs to set/clear the
flag in disable()/enable() but also needs to set the flag in is_enable() to get
initial status. The only benefit of keeping is_enabled flag is just save a
register read when set_mode(). Remove is_enabled flag makes the code simpler.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/regulator/ab8500-ext.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 57d43a1..5e604a2 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -29,7 +29,6 @@
* @desc: regulator description
* @rdev: regulator device
* @cfg: regulator configuration (extension of regulator FW configuration)
- * @is_enabled: status of regulator (on/off)
* @update_bank: bank to control on/off
* @update_reg: register to control on/off
* @update_mask: mask to enable/disable and set mode of regulator
@@ -46,7 +45,6 @@ struct ab8500_ext_regulator_info {
struct regulator_desc desc;
struct regulator_dev *rdev;
struct ab8500_ext_regulator_cfg *cfg;
- bool is_enabled;
u8 update_bank;
u8 update_reg;
u8 update_mask;
@@ -78,8 +76,6 @@ static int enable(struct ab8500_ext_regulator_info *info, u8
*regval)
return ret;
}
- info-is_enabled = true;
-
return ret;
}
@@ -125,8 +121,6 @@ static int disable(struct ab8500_ext_regulator_info *info,
u8 *regval)
return ret;
}
- info-is_enabled = false;
-
return ret;
}
@@ -177,11 +171,9 @@ static int ab8500_ext_regulator_is_enabled(struct
regulator_dev *rdev)
if (((regval info-update_mask) == info-update_val_lp) ||
((regval info-update_mask) == info-update_val_hp))
- info-is_enabled = true;
+ return 1;
else
- info-is_enabled = false;
-
- return info-is_enabled;
+ return 0;
}
static int ab8500_ext_regulator_set_mode(struct regulator_dev *rdev,
@@ -207,7 +199,7 @@ static int ab8500_ext_regulator_set_mode(struct
regulator_dev *rdev,
return -EINVAL;
}
- if (info-is_enabled) {
+ if (ab8500_ext_regulator_is_enabled(rdev)) {
u8 regval;
ret = enable(info, regval);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] regulator: ab8500-ext: Remove unnecessary checking for ab9540 and ab8540
This code was added by commit 0fe17e20a6
regulator: ab8500-ext: Add support for AB9540 regulators
and commit bd44e2cb regulator: ab8500: Also check for AB8505 based platforms
The original patch[1] is to set info-desc.ops = ab9540_ext_regulator_ops.
However, ab9540_ext_regulator_ops is identical to ab8500_ext_regulator_ops[2].
Thus we can complete remove the unnecessary checking for ab9540 and ab8540.
[1] https://lkml.org/lkml/2013/3/28/333
[2] https://lkml.org/lkml/2013/4/1/178
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/regulator/ab8500-ext.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 5e604a2..c7896af 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -389,15 +389,8 @@ int ab8500_ext_regulator_init(struct platform_device *pdev)
config.init_data = pdata-ext_regulator[i];
config.driver_data = info;
- if ((is_ab9540(ab8500) || is_ab8540(ab8500))
- ((info-desc.id == AB8500_EXT_SUPPLY1) ||
-(info-desc.id == AB8500_EXT_SUPPLY2) ||
-(info-desc.id == AB8500_EXT_SUPPLY3)))
- info-desc.ops = ab8500_ext_regulator_ops;
-
/* register regulator with framework */
info-rdev = regulator_register(info-desc, config);
-
if (IS_ERR(info-rdev)) {
err = PTR_ERR(info-rdev);
dev_err(pdev-dev, failed to register regulator %s\n,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] regulator: ab8500-ext: Remove get_voltage to avoid duplicate implementation
The implementation of ab8500_ext_fixed_get_voltage is identical to
ab8500_ext_list_voltage. We can avoid the duplicate implementation by just
remove get_voltage. For fixed regulator, regulator core will call
list_voltage(rdev, 0) to get voltage if both get_voltage get_voltage_sel are
not implemented.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/regulator/ab8500-ext.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index c7896af..9aee21c 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -237,21 +237,6 @@ static unsigned int ab8500_ext_regulator_get_mode(struct
regulator_dev *rdev)
return ret;
}
-static int ab8500_ext_fixed_get_voltage(struct regulator_dev *rdev)
-{
- struct regulation_constraints *regu_constraints = rdev-constraints;
-
- if (regu_constraints == NULL) {
- dev_err(rdev_get_dev(rdev), regulator constraints null
pointer\n);
- return -EINVAL;
- }
- if (regu_constraints-min_uV regu_constraints-max_uV) {
- if (regu_constraints-min_uV == regu_constraints-max_uV)
- return regu_constraints-min_uV;
- }
- return -EINVAL;
-}
-
static int ab8500_ext_list_voltage(struct regulator_dev *rdev,
unsigned selector)
{
@@ -275,7 +260,6 @@ static struct regulator_ops ab8500_ext_regulator_ops = {
.is_enabled = ab8500_ext_regulator_is_enabled,
.set_mode = ab8500_ext_regulator_set_mode,
.get_mode = ab8500_ext_regulator_get_mode,
- .get_voltage= ab8500_ext_fixed_get_voltage,
.list_voltage = ab8500_ext_list_voltage,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: fixup changers of per cpu pageset's -high and -batch
(4/5/13 4:33 PM), Cody P Schafer wrote: In one case while modifying the -high and -batch fields of per cpu pagesets we're unneededly using stop_machine() (patches 1 2), and in another we don't have any syncronization at all (patch 3). This patchset fixes both of them. Note that it results in a change to the behavior of zone_pcp_update(), which is used by memory_hotplug. I _think_ that I've diserned (and preserved) the essential behavior (changing -high and -batch), and only eliminated unneeded actions (draining the per cpu pages), but this may not be the case. at least, memory hotplug need to drain. -- 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] AVR32: fix building warnings caused by redifinitions of HZ
On 04/07/2013 03:55 PM, Hans-Christian Egtvedt wrote: Around Sun 07 Apr 2013 00:43:36 +0800 or thereabout, Jiang Liu wrote: Fix building warnings caused by redifinitions of HZ: In file included from /ws/linux/kernel/linux.git/include/uapi/linux/param.h:4, from include/linux/timex.h:63, from include/linux/jiffies.h:8, from include/linux/ktime.h:25, from include/linux/timer.h:5, from include/linux/workqueue.h:8, from include/linux/srcu.h:34, from include/linux/notifier.h:15, from include/linux/memory_hotplug.h:6, from include/linux/mmzone.h:777, from include/linux/gfp.h:4, from arch/avr32/mm/init.c:10: /ws/linux/kernel/linux.git/arch/avr32/include/asm/param.h:6:1: warning: HZ redefined In file included from /ws/linux/kernel/linux.git/arch/avr32/include/asm/param.h:4, from /ws/linux/kernel/linux.git/include/uapi/linux/param.h:4, from include/linux/timex.h:63, from include/linux/jiffies.h:8, from include/linux/ktime.h:25, from include/linux/timer.h:5, from include/linux/workqueue.h:8, from include/linux/srcu.h:34, from include/linux/notifier.h:15, from include/linux/memory_hotplug.h:6, from include/linux/mmzone.h:777, from include/linux/gfp.h:4, from arch/avr32/mm/init.c:10: /ws/linux/kernel/linux.git/arch/avr32/include/uapi/asm/param.h:6:1: warning: this is the location of the previous definition Thanks for fixing. Signed-off-by: Jiang Liu jiang@huawei.com Cc: Haavard Skinnemoen hskinnem...@gmail.com Cc: Hans-Christian Egtvedt egtv...@samfundet.no Cc: linux-kernel@vger.kernel.org Acked-by: Hans-Christian Egtvedt egtv...@samfundet.no --- arch/avr32/include/uapi/asm/param.h |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/avr32/include/uapi/asm/param.h b/arch/avr32/include/uapi/asm/param.h index d28aa5e..abda103 100644 --- a/arch/avr32/include/uapi/asm/param.h +++ b/arch/avr32/include/uapi/asm/param.h @@ -2,7 +2,11 @@ #define _UAPI__ASM_AVR32_PARAM_H -#ifndef HZ +#ifndef __KERNEL__ + /* +* Technically, this is wrong, but some old apps still refer to it. +* The proper way to get the HZ value is via sysconf(_SC_CLK_TCK). +*/ With this comment, are there AVR32 drivers/users that should be fixed? Or is it parts of the tree in general? Hi Hans, It's copied from arch/ia64/include/uapi/asm/param.h, I feel it should be the same for AVR32 too. Regards! Gerry # define HZ 100 #endif -- 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] PM/reboot: call syscore_shutdown() after disable_nonboot_cpus()
On Sun, Apr 07, 2013 at 10:46:00AM +0200, Rafael J. Wysocki wrote: On Sunday, April 07, 2013 10:14:14 AM Huacai Chen wrote: As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core subsystems PM) say, syscore_ops operations should be carried with one CPU on-line and interrupts disabled. However, after commit f96972f2d (kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()), syscore_shutdown() is called before disable_nonboot_cpus(), so break the rules. We have a MIPS machine with a 8259A PIC, and there is an external timer (HPET) linked at 8259A. Since 8259A has been shutdown too early (by syscore_shutdown()), disable_nonboot_cpus() runs without timer interrupt, so it hangs and reboot fails. This patch call syscore_shutdown() a little later (after disable_nonboot_cpus()) to avoid reboot failure, this is the same way as poweroff does. BTW, add disable_nonboot_cpus() in kernel_halt() for consistency. Signed-off-by: Huacai Chen che...@lemote.com Cc: sta...@vger.kernel.org While I agree with the changes, I'm not sure if I'm the right maintainer, as this isn't really PM code. Andrew, should I take this? Andrew is on vacation for a few weeks, so you might need to take this through your tree. 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/3] mm/page_alloc: convert zone_pcp_update() to use on_each_cpu() instead of stop_machine()
(4/5/13 4:33 PM), Cody P Schafer wrote: No off-cpu users of the percpu pagesets exist. zone_pcp_update()'s goal is to adjust the -high and -mark members of a percpu pageset based on a zone's -managed_pages. We don't need to drain the entire percpu pageset just to modify these fields. Avoid calling setup_pageset() (and the draining required to call it) and instead just set the fields' values. This does change the behavior of zone_pcp_update() as the percpu pagesets will not be drained when zone_pcp_update() is called (they will end up being shrunk, not completely drained, later when a 0-order page is freed in free_hot_cold_page()). Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com NAK. 1) zone_pcp_update() is only used from memory hotplug and it require page drain. 2) stop_machin is used for avoiding race. just removing it is insane. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mm: when handling percpu_pagelist_fraction, use on_each_cpu() to set percpu pageset fields.
(4/5/13 4:33 PM), Cody P Schafer wrote: In free_hot_cold_page(), we rely on pcp-batch remaining stable. Updating it without being on the cpu owning the percpu pageset potentially destroys this stability. Change for_each_cpu() to on_each_cpu() to fix. Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.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: [PATCHSET] cgroup: unexport locking interface
On Sun, Apr 07, 2013 at 01:38:21PM +0800, Li Zefan wrote: On 2013/4/5 7:36, Tejun Heo wrote: Hello, Most cgroup_mutex abuses outside cgroup core proper have been eradicated but there's still one use remaining and locking interface is still exported. This patchset updates the last user and unexports the locking interface and is composed of the following five patches. 0001-cgroup-cpuset-replace-move_member_tasks_to_cpuset-wi.patch 0002-cgroup-relocate-cgroup_lock_live_group-and-cgroup_at.patch 0003-cgroup-unexport-locking-interface-and-cgroup_attach_.patch 0004-cgroup-kill-cgroup_-un-lock.patch 0005-cgroup-remove-cgroup_lock_is_held.patch Acked-by: Li Zefan lize...@huawei.com Applied to cgroup/for-3.10. Thanks. -- tejun -- 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] do not try to sync identity map for non-mapped pages
On 04/07/2013 06:33 AM, Borislav Petkov wrote: looks like we haven't whacked all the moles - I keep seeing this when testing 32-bit builds in qemu on latest Linus + tip. I'd guess this is still that /dev/mem accessing thing called wdm. I'm still wondering though whether we should BUG_ON on a /dev/mem access? We shouldn't, no. /dev/mem really needs to be fixed along a bunch of axes. Yes, it is privileged and extra creepy, but it should either work or it should fail cleanly. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: add uid and gid to devtmpfs
On Sat, Apr 6, 2013 at 7:58 PM, Greg KH gre...@linuxfoundation.org wrote: On Sat, Apr 06, 2013 at 06:45:12PM +0100, Al Viro wrote: On Sat, Apr 06, 2013 at 10:26:12AM -0700, Greg KH wrote: Why not? closed systems, like Android and other embedded systems, have assigned uid and gid values that never change. Right now they have to have a horrible shell-script to set these values in devtmpfs when the device shows up to the needed numbers. This tiny patch gets rid of that shell script entirely, allowing them to specify it from the kernel as needed. What's to stop them from using static /dev? Has an extra benefit of getting rid of devtmpfs shite completely... True, it would, but they like using devtmpfs :) This change also allows systems that have control devices to properly be able to pass in the uid for the device they are creating, like rawctl (which I know is obsolete), and probably dm and lvm. I thought loop devices might also want this, as they can now be created by normal users, but I don't think that's needed for them. It is generally useful to be able to control the uid/gid of userspace-initiated device nodes, instead of racy post-adjusting this setting from udev rules with an unpredictable long window between the request and the adjustment. The created device node can inherit the ownership of the calling process, in a similar way like we do for devpts. We have the same for the mode already, and want to be able to do the same for the other permissions properties. Thanks, Kay -- 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] F2FS: Fix the logic of IS_DNODE()
Signed-off-by: Zhihui Zhang zzhs...@gmail.com
---
fs/f2fs/node.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index afdb130..2be47b2 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -239,7 +239,7 @@ static inline bool IS_DNODE(struct page *node_page)
return false;
if (ofs = 6 + 2 * NIDS_PER_BLOCK) {
ofs -= 6 + 2 * NIDS_PER_BLOCK;
- if ((long int)ofs % (NIDS_PER_BLOCK + 1))
+ if (!((long int)ofs % (NIDS_PER_BLOCK + 1)))
return false;
}
return true;
--
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] regulator: mc13783: Add device tree probe support
Patch adds device tree probe support for mc13783-regulator driver.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
drivers/regulator/mc13783-regulator.c | 55 ++
drivers/regulator/mc13xxx-regulator-core.c | 2 ++
2 files changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/regulator/mc13783-regulator.c
b/drivers/regulator/mc13783-regulator.c
index c46c670..fba8d5e 100644
--- a/drivers/regulator/mc13783-regulator.c
+++ b/drivers/regulator/mc13783-regulator.c
@@ -398,33 +398,62 @@ static int mc13783_regulator_probe(struct platform_device
*pdev)
struct mc13xxx *mc13783 = dev_get_drvdata(pdev-dev.parent);
struct mc13xxx_regulator_platform_data *pdata =
dev_get_platdata(pdev-dev);
- struct mc13xxx_regulator_init_data *init_data;
+ struct mc13xxx_regulator_init_data *mc13xxx_data;
struct regulator_config config = { };
- int i, ret;
+ int i, ret, num_regulators, num_parsed;
- dev_dbg(pdev-dev, %s id %d\n, __func__, pdev-id);
+ num_regulators = mc13xxx_get_num_regulators_dt(pdev);
- if (!pdata)
+ if (num_regulators = 0 pdata)
+ num_regulators = pdata-num_regulators;
+ if (num_regulators = 0)
return -EINVAL;
+ num_parsed = num_regulators;
+
priv = devm_kzalloc(pdev-dev, sizeof(*priv) +
- pdata-num_regulators * sizeof(priv-regulators[0]),
+ num_regulators * sizeof(priv-regulators[0]),
GFP_KERNEL);
if (!priv)
return -ENOMEM;
+ priv-num_regulators = num_regulators;
priv-mc13xxx_regulators = mc13783_regulators;
priv-mc13xxx = mc13783;
+ platform_set_drvdata(pdev, priv);
- for (i = 0; i pdata-num_regulators; i++) {
- struct regulator_desc *desc;
+ mc13xxx_data = mc13xxx_parse_regulators_dt(pdev, mc13783_regulators,
+ ARRAY_SIZE(mc13783_regulators),
+ num_parsed);
+ if (num_parsed != num_regulators) {
+ dev_warn(pdev-dev,
+ parsed %d != regulators %d - check your device tree!\n,
+ num_parsed, num_regulators);
- init_data = pdata-regulators[i];
- desc = mc13783_regulators[init_data-id].desc;
+ num_regulators = num_parsed;
+ priv-num_regulators = num_regulators;
+ }
+
+ for (i = 0; i num_regulators; i++) {
+ struct regulator_init_data *init_data;
+ struct regulator_desc *desc;
+ struct device_node *node = NULL;
+ int id;
+
+ if (mc13xxx_data) {
+ id = mc13xxx_data[i].id;
+ init_data = mc13xxx_data[i].init_data;
+ node = mc13xxx_data[i].node;
+ } else {
+ id = pdata-regulators[i].id;
+ init_data = pdata-regulators[i].init_data;
+ }
+ desc = mc13783_regulators[id].desc;
config.dev = pdev-dev;
- config.init_data = init_data-init_data;
+ config.init_data = init_data;
config.driver_data = priv;
+ config.of_node = node;
priv-regulators[i] = regulator_register(desc, config);
if (IS_ERR(priv-regulators[i])) {
@@ -435,8 +464,6 @@ static int mc13783_regulator_probe(struct platform_device
*pdev)
}
}
- platform_set_drvdata(pdev, priv);
-
return 0;
err:
while (--i = 0)
@@ -448,13 +475,11 @@ err:
static int mc13783_regulator_remove(struct platform_device *pdev)
{
struct mc13xxx_regulator_priv *priv = platform_get_drvdata(pdev);
- struct mc13xxx_regulator_platform_data *pdata =
- dev_get_platdata(pdev-dev);
int i;
platform_set_drvdata(pdev, NULL);
- for (i = 0; i pdata-num_regulators; i++)
+ for (i = 0; i priv-num_regulators; i++)
regulator_unregister(priv-regulators[i]);
return 0;
diff --git a/drivers/regulator/mc13xxx-regulator-core.c
b/drivers/regulator/mc13xxx-regulator-core.c
index 23cf9f9..836e21e 100644
--- a/drivers/regulator/mc13xxx-regulator-core.c
+++ b/drivers/regulator/mc13xxx-regulator-core.c
@@ -205,6 +205,8 @@ struct mc13xxx_regulator_init_data
*mc13xxx_parse_regulators_dt(
for_each_child_of_node(parent, child) {
for (i = 0; i num_regulators; i++) {
+ if (!regulators[i].desc.name)
+ continue;
if (!of_node_cmp(child-name,
regulators[i].desc.name)) {
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Re: [PATCH] do not try to sync identity map for non-mapped pages
On Sun, Apr 07, 2013 at 09:34:07AM -0700, H. Peter Anvin wrote: We shouldn't, no. /dev/mem really needs to be fixed along a bunch of axes. Yes, it is privileged and extra creepy, but it should either work or it should fail cleanly. Can't we filter out accesses through /dev/mem and not BUG_ON in __phys_addr() if they come through /dev/mem? Simply fail cleanly. No idea whether we'll break something still reading /dev/mem though. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 cgroup/for-3.10] devcg: remove broken_hierarchy tag
From f913fbedbdfc08eeff742c4b3077e267d8fc867f Mon Sep 17 00:00:00 2001
From: Tejun Heo t...@kernel.org
Date: Sun, 7 Apr 2013 10:25:39 -0700
bd2953ebbb (devcg: propagate local changes down the hierarchy)
implemented proper hierarchy support. Remove the broken tag.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Aristeu Rozanski a...@redhat.com
---
Applying to cgroup/for-3.10.
Thanks.
security/device_cgroup.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 221967d..994aecc 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -739,15 +739,6 @@ struct cgroup_subsys devices_subsys = {
.css_offline = devcgroup_offline,
.subsys_id = devices_subsys_id,
.base_cftypes = dev_cgroup_files,
-
- /*
-* While devices cgroup has the rudimentary hierarchy support which
-* checks the parent's restriction, it doesn't properly propagates
-* config changes in ancestors to their descendents. A child
-* should only be allowed to add more restrictions to the parent's
-* configuration. Fix it and remove the following.
-*/
- .broken_hierarchy = true,
};
/**
--
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/
Re: [PATCH v6] pstore/ram: Add ramoops support for the Flattened Device Tree.
On Thu, Apr 04, 2013 at 09:03:47PM -0500, Rob Herring wrote: On Mon, Sep 17, 2012 at 1:23 AM, Anton Vorontsov cbouatmai...@gmail.com wrote: On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote: On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote: When called with a non-zero of_node, fill out a new ramoops_platform_data with data from the specified Flattened Device Tree node. Update ramoops documentation with the new FDT interface. Update devicetree/binding documentation with pstore/ramoops.txt. Thanks for your work, Bryan! There were a few issues, I fixed them myself but I need your confirmation if you're OK w/ all the changes. [...] So, the resulting patch is down below. But I have not pushed it out yet, I'm waiting for your sign off. If you're OK with the changes, please reply with 'Signed-off-by: Bryan Freed bfr...@chromium.org' Bryan, have you had a chance to look into this? Whatever happened to this? Olof was also looking at doing a binding back in Jan 2012: http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg09905.html I don't know. Bryan's patch looked good, I'd happily apply it. But I still need Bryan's Signed-off-by tag. :-/ Or, somebody needs to sign off on his behalf (anyone from Chromium project?). Or redo the patch. Thanks, Anton -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] backports: adds regulator and media susbsystems
On Sat, Apr 6, 2013 at 7:37 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Sat, Apr 6, 2013 at 7:35 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
Segmentation fault
make[8]: *** [/home/mcgrof/tmp/build/compat/core.o] Error 139
I've narrowed the segfault to a core.c file with just:
#include linux/async.h
#include linux/module.h
void poo(void)
{
}
EXPORT_SYMBOL_GPL(poo);
Removing asynch.h fixes it. Doing this on an standalone module works
Luis
--
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 part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently
From: Wanpeng Li [mailto:liw...@linux.vnet.ibm.com] Subject: Re: [PATCH part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently Hi Dan, Some issues against Ramster: - Ramster who takes advantage of zcache also should support zero-filled pages more efficiently, correct? It doesn't handle zero-filled pages well currently. When you first posted your patchset I took a quick look at ramster and it looked like your patchset should work for ramster also. However I didn't actually run ramster to try it so there may be a bug. If it doesn't work, I would very much appreciate a patch. - Ramster DebugFS counters are exported in /sys/kernel/mm/, but zcache/frontswap/cleancache all are exported in /sys/kernel/debug/, should we unify them? That would be great. - If ramster also should move DebugFS counters to a single file like zcache do? Sure! I am concerned about Konrad's patches adding debug.c as they add many global variables. They are only required when ZCACHE_DEBUG is enabled so they may be ok. If not, adding ramster variables to debug.c may make the problem worse. If you confirm these issues are make sense to fix, I will start coding. ;-) That would be great. Note that I have a how-to for ramster here: https://oss.oracle.com/projects/tmem/dist/files/RAMster/HOWTO-120817 If when you are testing you find that this how-to has mistakes, please let me know. Or feel free to add the (corrected) how-to file as a patch in your patchset. Thanks very much, Wanpeng, for your great contributions! (Ric, since you have expressed interest in ramster, if you try it and find corrections to the how-to file above, your input would be very much appreciated also!) Dan -- 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 part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently
From: Dan Magenheimer Subject: RE: [PATCH part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently From: Wanpeng Li [mailto:liw...@linux.vnet.ibm.com] Subject: Re: [PATCH part2 v6 0/3] staging: zcache: Support zero-filled pages more efficiently Hi Dan, Some issues against Ramster: Sure! I am concerned about Konrad's patches adding debug.c as they add many global variables. They are only required when ZCACHE_DEBUG is enabled so they may be ok. If not, adding ramster variables to debug.c may make the problem worse. Oops, I just noticed/remembered that ramster uses BOTH debugfs and sysfs. The sysfs variables are all currently required, i.e. for configuration so should not be tied to debugfs or a DEBUG config option. However, if there is a more acceptable way to implement the function of those sysfs variables, that would be fine. Thanks, Dan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
On Sat, Apr 06, 2013 at 10:11:32PM +0200, Wolfram Sang wrote: Hi, Very interesting discussion, especially the argument that we already shipped would not be a convincing argument. I had senior kernel maintainers tell me and the company I work for that we should submit _all_ our platform specific kernel code and drivers for inclusion into the upstream kernel. Yes, great. Really! Yes, though, thinking about it, it was submit and didn't say anything about potential for acceptance. This exchange suggests that it is a shipping product does not count for such submissions, and that Benefit for the kernel would be the deciding factor instead. Which of course is a very vague statement - if code supporting Chromebookis is of no benefit for the kernel, support for my company's products for sure is much less so. First, let me state that I did not intend to say that the arbitrator muxer here has NO benefit for the kernel. I was aware there might be arguments for that and I wanted some more discussion to make that clearer to me. Simon's mail was very helpful in that regard and I will comment on that somewhen later. Still, I do have problems with we already shipped it. If the driver is bad or the underlying concept is fragile, I want the freedom to reject a patch, product shipped or not. I will be supportive to find a proper solution, promised. If all fails, there is still staging/ or the possibility of out-of-tree patches. I think there is a difference between a bad driver or underlying hardware. To me, shipped applies to hardware or firmware which can not be upgraded, not to the software running on it. Which kind of leaves me in a bind. On one side I promote that we should submit all our kernel code, on the other side there is a very compelling case to be made that it won't be accepted anyway. That doesn't make my life easier - Concentrate on argumenting why the driver is useful and it will be fine. we already shipped this feels a bit like blackmailing to me. And since most drivers do have well thought reasons for their existance, I'd primarily like to hear about those. essentially since it supports those who say that we should not submit anything in the first place. And believe me, there are many of those. Just to give some examples: - I2C multiplexers. We have a bunch of those. Looking at this exchange, it doesn't look good to get that code included. Multiplexers should be easy going, it is the arbitration which is discussed here. I am open to consider some generic arbitration schemes. What I am reluctant to do is to allow every board to have its own arbitration scheme. This would be board support hosted in the I2C directory. Meh. board support hosted in the I2C directory. But that is exactly what I am talking about, isn't it ? I have board specific multiplexers and a board specific I2C controller, and that is just talking about the I2C code. It would be nice have to get some well defined guidelines for acceptable contributions. Benefit for the kernel sure isn't one. I don't think it is possible to write down concrete guidelines for this. According to rule 4a) of the guidelines you have to accept my patch? That would be a mess, I think. Looking at it from a maintainer perspective, I agree. Where it gets murky is really the hardware part. The (in my opinion) philosophical arguments around not permitting device-tree based instantiation of uio devices is one example. Another practical example I had to deal with in my previous company is VGA memory space. Some hw geniuses decided to re-use the VGA memory space in an embedded x86 device for an EEPROM. Guess what - the x86 kernel writes into that space no matter what. A patch to address that problem was rejected because you should not re-use VGA memory space. As if I had a choice. A better example might be Kontron board support. They implement gpio, I2C mux, and a watchdog in a PLD. They too have an access arbitration scheme where one has to acquire a hardware mutex before accessing the pld, if I understand correctly because some microcontroller might need to access it as well. Leaving the actual code aside, would you reject that too if you don't like the arbitration scheme, or because you don't want to have board support in the i2c directory ? Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.8.6
On Sun, Apr 7, 2013 at 12:56 AM, Lucas canolu...@gmail.com wrote: Thanks for reporting in. Somehow the thread got all messed up in LKML. It didn't parse correctly there, but it seems that Gmane did. Here is the link: http://comments.gmane.org/gmane.linux.kernel.stable/48872 Those patches still have an unresolved regression against them. Unfortunately I can't reproduce it despite that I have a very similar system, and obviously a bunch of other people like you reported that the exact same patches which regressed actually fix the lvds panel fitter. So for now this stays in limbo :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: mc13783: Add device tree probe support
On Sun, Apr 07, 2013 at 09:02:11PM +0400, Alexander Shiyan wrote:
Patch adds device tree probe support for mc13783-regulator driver.
I'd expect to see a document describing the binding for any new binding.
+ if (num_parsed != num_regulators) {
+ dev_warn(pdev-dev,
+ parsed %d != regulators %d - check your device tree!\n,
+ num_parsed, num_regulators);
- init_data = pdata-regulators[i];
- desc = mc13783_regulators[init_data-id].desc;
+ num_regulators = num_parsed;
+ priv-num_regulators = num_regulators;
Why is this something we warn about? Users should be able to omit
unused regulators, no point in adding nodes that don't have any real
information.
signature.asc
Description: Digital signature
[PATCH] Revert tty/8250_pnp: serial port detection regression since v3.7
This reverts commit 77e372a3d82e5e4878ce1962207edd766773cc76.
Checking for disabled resources board breaks detection pnp on another
board AMI UEFI implementation (Version: 0406 Release Date: 06/06/2012).
I'm working with the reporter of the original bug to write and test
a better fix.
https://bugzilla.redhat.com/show_bug.cgi?id=928246
Signed-off-by: Sean Young s...@mess.org
Cc: stable sta...@kernel.org
---
drivers/tty/serial/8250/8250_pnp.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pnp.c
b/drivers/tty/serial/8250/8250_pnp.c
index b3455a9..35d9ab9 100644
--- a/drivers/tty/serial/8250/8250_pnp.c
+++ b/drivers/tty/serial/8250/8250_pnp.c
@@ -429,7 +429,6 @@ serial_pnp_probe(struct pnp_dev *dev, const struct
pnp_device_id *dev_id)
{
struct uart_8250_port uart;
int ret, line, flags = dev_id-driver_data;
- struct resource *res = NULL;
if (flags UNKNOWN_DEV) {
ret = serial_pnp_guess_board(dev);
@@ -440,12 +439,11 @@ serial_pnp_probe(struct pnp_dev *dev, const struct
pnp_device_id *dev_id)
memset(uart, 0, sizeof(uart));
if (pnp_irq_valid(dev, 0))
uart.port.irq = pnp_irq(dev, 0);
- if ((flags CIR_PORT) pnp_port_valid(dev, 2))
- res = pnp_get_resource(dev, IORESOURCE_IO, 2);
- else if (pnp_port_valid(dev, 0))
- res = pnp_get_resource(dev, IORESOURCE_IO, 0);
- if (pnp_resource_enabled(res)) {
- uart.port.iobase = res-start;
+ if ((flags CIR_PORT) pnp_port_valid(dev, 2)) {
+ uart.port.iobase = pnp_port_start(dev, 2);
+ uart.port.iotype = UPIO_PORT;
+ } else if (pnp_port_valid(dev, 0)) {
+ uart.port.iobase = pnp_port_start(dev, 0);
uart.port.iotype = UPIO_PORT;
} else if (pnp_mem_valid(dev, 0)) {
uart.port.mapbase = pnp_mem_start(dev, 0);
--
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] tty: mxser: fix cycle termination condition in mxser_probe() and mxser_module_init()
There is a bug in resources deallocation code in mxser_probe() and
mxser_module_init().
As soon as variable 'i' is unsigned int, cycle termination condition i = 0 is
always true.
The patch fixes the issue.
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/tty/mxser.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 484b6a3..302909c 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -2643,9 +2643,9 @@ static int mxser_probe(struct pci_dev *pdev,
mxvar_sdriver, brd-idx + i, pdev-dev);
if (IS_ERR(tty_dev)) {
retval = PTR_ERR(tty_dev);
- for (i--; i = 0; i--)
+ for (; i 0; i--)
tty_unregister_device(mxvar_sdriver,
- brd-idx + i);
+ brd-idx + i - 1);
goto err_relbrd;
}
}
@@ -2751,9 +2751,9 @@ static int __init mxser_module_init(void)
tty_dev = tty_port_register_device(brd-ports[i].port,
mxvar_sdriver, brd-idx + i, NULL);
if (IS_ERR(tty_dev)) {
- for (i--; i = 0; i--)
+ for (; i 0; i--)
tty_unregister_device(mxvar_sdriver,
- brd-idx + i);
+ brd-idx + i - 1);
for (i = 0; i brd-info-nports; i++)
tty_port_destroy(brd-ports[i].port);
free_irq(brd-irq, brd);
--
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: [RFC][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup
On Sun 07-04-13 16:44:07, Li Zefan wrote: Hi, I'm rebasing this patchset against latest linux-next, and it conflicts with [PATCH v2] memcg: debugging facility to access dangling memcgs. slightly. That is a debugging patch and will never be pushed into mainline, so should I still base this patchset on that debugging patch? Could you split CONFIG_MEMCG_DEBUG_ASYNC_DESTROY changes into a separate patch so that Andrew could put it on top of the mentioned patch? Also that patch needs update (and can be simplified) after this patchset: - move memcg_dangling_add() to mem_cgroup_css_offline() - remove memcg-memcg_name, and use cgroup_path() in mem_cgroup_dangling_read()? Every improvement is welcome. Thanks -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup
On Sun 07-04-13 14:00:24, Li Zefan wrote: On 2013/4/4 20:00, Michal Hocko wrote: On Wed 03-04-13 17:11:15, Li Zefan wrote: (I'll be off from my office soon, and I won't be responsive in the following 3 days.) I'm working on converting memcg to use cgroup-id, and then we can kill css_id. Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg can still be alive. This patchset converts memcg to always use css_get/put, so memcg will have the same life cycle as its corresponding cgroup, and then it's always safe for memcg to use cgroup-id. The historical reason that memcg didn't use css_get in some cases, is that cgroup couldn't be removed if there're still css refs. The situation has changed so that rmdir a cgroup will succeed regardless css refs, but won't be freed until css refs goes down to 0. This is an early post, and it's NOT TESTED. I just want to see if the changes are fine in general. yes, I like the approach and it looks correct as well (some minor things mentioned in the patches). Thanks a lot Li! This will make our lifes much easier. The separate ref counting was PITA especially after introduction of kmem accounting which made its usage even more trickier. btw, after this patchset I think we don't need to free memcg via RCU, because cgroup is already freed in RCU callback. But this depends on changes waiting in for-3.10 branch, right? What changes? memcg changes or cgroup core changes? I don't think this depends on anything in cgroup 3.10 branch. cgroup (be445626 e.g.) but now I've noticed that those are already merged in Linus tree. FYI: I've cherry-picked themo my -mm git tree. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: MT - handle semi-mt devices in core
Most semi-mt drivers use the slots in a manual way, but really only
need to treat the finger count manually. With this patch, a semi-mt
driver may use the input-mt core for everything else.
Signed-off-by: Henrik Rydberg rydb...@euromail.se
---
Hi Dmitry,
an earlier version of this patch came about as a test to handle the
synaptics profile sensor without too much extra work. I do not know
how that test panned out (no response), but this patch will likely be
useful regardless.
Henrik
drivers/input/input-mt.c | 8 +++-
include/linux/input/mt.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
index 71db193..d398f13 100644
--- a/drivers/input/input-mt.c
+++ b/drivers/input/input-mt.c
@@ -79,6 +79,8 @@ int input_mt_init_slots(struct input_dev *dev, unsigned int
num_slots,
}
if (flags INPUT_MT_DIRECT)
__set_bit(INPUT_PROP_DIRECT, dev-propbit);
+ if (flags INPUT_MT_SEMI_MT)
+ __set_bit(INPUT_PROP_SEMI_MT, dev-propbit);
if (flags INPUT_MT_TRACK) {
unsigned int n2 = num_slots * num_slots;
mt-red = kcalloc(n2, sizeof(*mt-red), GFP_KERNEL);
@@ -246,6 +248,7 @@ void input_mt_sync_frame(struct input_dev *dev)
{
struct input_mt *mt = dev-mt;
struct input_mt_slot *s;
+ bool use_count = false;
if (!mt)
return;
@@ -259,7 +262,10 @@ void input_mt_sync_frame(struct input_dev *dev)
}
}
- input_mt_report_pointer_emulation(dev, (mt-flags INPUT_MT_POINTER));
+ if ((mt-flags INPUT_MT_POINTER) !(mt-flags INPUT_MT_SEMI_MT))
+ use_count = true;
+
+ input_mt_report_pointer_emulation(dev, use_count);
mt-frame++;
}
diff --git a/include/linux/input/mt.h b/include/linux/input/mt.h
index 2e86bd0..1b1dfa8 100644
--- a/include/linux/input/mt.h
+++ b/include/linux/input/mt.h
@@ -19,6 +19,7 @@
#define INPUT_MT_DIRECT0x0002 /* direct device, e.g.
touchscreen */
#define INPUT_MT_DROP_UNUSED 0x0004 /* drop contacts not seen in frame */
#define INPUT_MT_TRACK 0x0008 /* use in-kernel tracking */
+#define INPUT_MT_SEMI_MT 0x0010 /* semi-mt device, finger count handled
manually */
/**
* struct input_mt_slot - represents the state of an input MT slot
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 net-next 1/8] r8169: Remove firmware code
From: Francois Romieu rom...@fr.zoreil.com Date: Fri, 5 Apr 2013 01:42:29 +0200 David Miller da...@davemloft.net : [...] If so, should I just apply this series as-is ? Yes. - the series is imho -stable unfriendly: whoever wants to figure what should be fed into a -stable branch will have a hard time. :o/ - the driver could had been more careful about firmware version/magic checks and firmware opcodes recycling. It's a bit late. It won't necessarily hurt. - there is a whole release cycle ahead to find problems - if any - due to the hw_start flow change. It seems sane. - the relative amount of binary like cruft is going down. I am not overflowed with enthusiasm but the gain should exceed the pain. All applied to net-next, thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM/reboot: call syscore_shutdown() after disable_nonboot_cpus()
On Sunday, April 07, 2013 08:29:32 AM Greg KH wrote: On Sun, Apr 07, 2013 at 10:46:00AM +0200, Rafael J. Wysocki wrote: On Sunday, April 07, 2013 10:14:14 AM Huacai Chen wrote: As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core subsystems PM) say, syscore_ops operations should be carried with one CPU on-line and interrupts disabled. However, after commit f96972f2d (kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()), syscore_shutdown() is called before disable_nonboot_cpus(), so break the rules. We have a MIPS machine with a 8259A PIC, and there is an external timer (HPET) linked at 8259A. Since 8259A has been shutdown too early (by syscore_shutdown()), disable_nonboot_cpus() runs without timer interrupt, so it hangs and reboot fails. This patch call syscore_shutdown() a little later (after disable_nonboot_cpus()) to avoid reboot failure, this is the same way as poweroff does. BTW, add disable_nonboot_cpus() in kernel_halt() for consistency. Signed-off-by: Huacai Chen che...@lemote.com Cc: sta...@vger.kernel.org While I agree with the changes, I'm not sure if I'm the right maintainer, as this isn't really PM code. Andrew, should I take this? Andrew is on vacation for a few weeks, so you might need to take this through your tree. OK But, it looks like we should actually disable interrupts on the remaining CPU after we've called disable_nonboot_cpus() so that the syscore_shutdown() assumptions are satisfied which the patch doesn't do. Chen (I apologize if that's not the right part of your full name to use here), do you think that's not necessary and if so, then for what reason? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] 802.15.4 and 6LoWPAN Buffering Fixes
From: Alan Ott a...@signal11.us Date: Wed, 3 Apr 2013 10:00:54 -0400 Version 2 of this patch series: Differences from v1: 1. Patches previously numbered 5 and 6 were squashed (to become current patch #4) at the request of Alexander Smirnov. 2. Current patch #2 had extraneous braces removed. 3. Current patch #1 was changed. It is now a patch to make mac802154 _not_ retry sending packets on failure. I believe this to be consistent with the 802.15.4 specification (Section 7.5.6.4.3 of IEEE 802.15.4-2006) Series applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch -next] usb, gadget: use appropriate warning accessors
Use the appropriate WARN() and WARN_ON() accessors to avoid a build error
when CONFIG_BUG=n:
drivers/usb/gadget/configfs.c: In function 'config_usb_cfg_unlink':
drivers/usb/gadget/configfs.c:442:2: error: implicit declaration of
function '__WARN_printf'
drivers/usb/gadget/configfs.c: In function 'configfs_do_nothing':
drivers/usb/gadget/configfs.c:733:2: error: implicit declaration of
function '__WARN'
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: David Rientjes rient...@google.com
---
drivers/usb/gadget/configfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -439,7 +439,7 @@ static int config_usb_cfg_unlink(
}
}
mutex_unlock(gi-lock);
- __WARN_printf(Unable to locate function to unbind\n);
+ WARN(1, Unable to locate function to unbind\n);
return 0;
}
@@ -730,7 +730,7 @@ USB_CONFIG_STRINGS_LANG(gadget_strings, gadget_info);
static int configfs_do_nothing(struct usb_composite_dev *cdev)
{
- __WARN();
+ WARN_ON(1);
return -EINVAL;
}
--
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] netdev/phy: Implement ieee802.3 clause 45 in mdio-octeon.c
From: David Daney ddaney.c...@gmail.com Date: Wed, 3 Apr 2013 12:25:32 -0700 From: David Daney david.da...@cavium.com The Octeon SMI/MDIO interfaces can do clause 45 communications, so implement this in the driver. Also fix some comment formatting to make it consistent and to comply with the netdev style. Signed-off-by: David Daney david.da...@cavium.com Applied to net-next. -- 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 -next 1/3] bcache: Add missing #include linux/prefetch.h
On Wed, 27 Mar 2013, Kent Overstreet wrote:
Nope - looks like __WARN() doesn't exist if CONFIG_BUG=n, whoops.
Adding this to the queue:
commit 796c213186b850b3e6e8d5fd5799b0fd74721ea3
Author: Kent Overstreet koverstr...@google.com
Date: Wed Mar 27 12:47:45 2013 -0700
bcache: Use WARN_ONCE() instead of __WARN()
Signed-off-by: Kent Overstreet koverstr...@google.com
diff --git a/drivers/md/bcache/bset.c b/drivers/md/bcache/bset.c
index d4f2164..cb4578a 100644
--- a/drivers/md/bcache/bset.c
+++ b/drivers/md/bcache/bset.c
@@ -883,7 +883,7 @@ struct bkey *bch_btree_iter_next(struct btree_iter *iter)
iter-data-k = bkey_next(iter-data-k);
if (iter-data-k iter-data-end) {
- __WARN();
+ WARN_ONCE(1, bset was corrupt!\n);
iter-data-k = iter-data-end;
}
This problem still persists in linux-next as of today, how is this fix
being pushed?
--
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: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL
On Fri, 2013-04-05 at 00:47 -0400, David Miller wrote: From: Sven Joachim svenj...@gmx.de Date: Wed, 03 Apr 2013 13:41:32 +0200 On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote: 3.8-stable review patch. If anyone has any objections, please let me know. I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and 3.9-rc5: udevd[56]: sender uid=65534, message ignored. Reverting the patch below on top of 3.8.6-rc1 fixes that. I'm using udev version 175 here, and 65534 is the uid of user nobody. Greg and Ben, please stop this patch from all of the -stable trees. I'm going to revert it and use Eric Biederman's fix instead. Thanks! OK, dropped it. Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
[PATCH 1/2] hfsplus: add error propagation to __hfsplus_ext_write_extent()
__hfsplus_ext_write_extent() suppresses errors coming from hfs_brec_find().
The patch implements error code propagation.
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
fs/hfsplus/extents.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/fs/hfsplus/extents.c b/fs/hfsplus/extents.c
index a94f0f7..fed73f7 100644
--- a/fs/hfsplus/extents.c
+++ b/fs/hfsplus/extents.c
@@ -83,7 +83,7 @@ static u32 hfsplus_ext_lastblock(struct hfsplus_extent *ext)
return be32_to_cpu(ext-start_block) + be32_to_cpu(ext-block_count);
}
-static void __hfsplus_ext_write_extent(struct inode *inode,
+static int __hfsplus_ext_write_extent(struct inode *inode,
struct hfs_find_data *fd)
{
struct hfsplus_inode_info *hip = HFSPLUS_I(inode);
@@ -98,13 +98,13 @@ static void __hfsplus_ext_write_extent(struct inode *inode,
res = hfs_brec_find(fd, hfs_find_rec_by_key);
if (hip-extent_state HFSPLUS_EXT_NEW) {
if (res != -ENOENT)
- return;
+ return res;
hfs_brec_insert(fd, hip-cached_extents,
sizeof(hfsplus_extent_rec));
hip-extent_state = ~(HFSPLUS_EXT_DIRTY | HFSPLUS_EXT_NEW);
} else {
if (res)
- return;
+ return res;
hfs_bnode_write(fd-bnode, hip-cached_extents,
fd-entryoffset, fd-entrylength);
hip-extent_state = ~HFSPLUS_EXT_DIRTY;
@@ -117,11 +117,13 @@ static void __hfsplus_ext_write_extent(struct inode
*inode,
* to explicily mark the inode dirty, too.
*/
set_bit(HFSPLUS_I_EXT_DIRTY, hip-flags);
+
+ return 0;
}
static int hfsplus_ext_write_extent_locked(struct inode *inode)
{
- int res;
+ int res = 0;
if (HFSPLUS_I(inode)-extent_state HFSPLUS_EXT_DIRTY) {
struct hfs_find_data fd;
@@ -129,10 +131,10 @@ static int hfsplus_ext_write_extent_locked(struct inode
*inode)
res = hfs_find_init(HFSPLUS_SB(inode-i_sb)-ext_tree, fd);
if (res)
return res;
- __hfsplus_ext_write_extent(inode, fd);
+ res = __hfsplus_ext_write_extent(inode, fd);
hfs_find_exit(fd);
}
- return 0;
+ return res;
}
int hfsplus_ext_write_extent(struct inode *inode)
@@ -175,8 +177,11 @@ static inline int __hfsplus_ext_cache_extent(struct
hfs_find_data *fd,
WARN_ON(!mutex_is_locked(hip-extents_lock));
- if (hip-extent_state HFSPLUS_EXT_DIRTY)
- __hfsplus_ext_write_extent(inode, fd);
+ if (hip-extent_state HFSPLUS_EXT_DIRTY) {
+ res = __hfsplus_ext_write_extent(inode, fd);
+ if (res)
+ return res;
+ }
res = __hfsplus_ext_read_extent(fd, hip-cached_extents, inode-i_ino,
block, HFSPLUS_IS_RSRC(inode) ?
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] hfsplus: add printk to log allocation failure in hfs_find_init()
Add printk to log allocation failure in hfs_find_init(),
so that there is a sign in dmesg when the error condition is triggered.
(per Hin-Tak Leung request)
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
fs/hfsplus/bfind.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/hfsplus/bfind.c b/fs/hfsplus/bfind.c
index d73c98d..067ddb5 100644
--- a/fs/hfsplus/bfind.c
+++ b/fs/hfsplus/bfind.c
@@ -18,8 +18,10 @@ int hfs_find_init(struct hfs_btree *tree, struct
hfs_find_data *fd)
fd-tree = tree;
fd-bnode = NULL;
ptr = kmalloc(tree-max_key_len * 2 + 4, GFP_KERNEL);
- if (!ptr)
+ if (!ptr) {
+ printk(KERN_ERR hfs: allocation failed in hfs_find_init()\n);
return -ENOMEM;
+ }
fd-search_key = ptr;
fd-key = ptr + tree-max_key_len + 2;
dprint(DBG_BNODE_REFS, find_init: %d (%p)\n,
--
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: [RFC PATCH arm: initial TI-Nspire support]
On Sunday 07 April 2013, Daniel Tang wrote: Here's an updated patch that enables support for the LCD. I looked into drivers/video/of_display_timing.c but it doesn't have the fields to describe the PL11x specific options needed in struct clcd_panel. At the moment, it is implemented by hardcoding the values in the kernel and using the device tree to select the correct configuration. Signed-off-by: Daniel Tang dt.ta...@gmail.com I think you should for now keep the clcd stuff in a separate file, since it will be replaced with DT logic eventually. For now, the auxdata method is ok, but Linus Walleij might already have thought about how pl111 should get all its data from the device tree. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] kvm: add PV MMIO EVENTFD
On Sun, Apr 7, 2013 at 12:41 AM, Michael S. Tsirkin m...@redhat.com wrote: On Thu, Apr 04, 2013 at 04:32:01PM -0700, Christoffer Dall wrote: [...] to give us some idea how much performance we would gain from each approach? Thoughput should be completely unaffected anyway, since virtio just coalesces kicks internally. Latency is dominated by the scheduling latency. This means virtio-net is not the best benchmark. So what is a good benchmark? E.g. ping pong stress will do but need to look at CPU utilization, that's what is affected, not latency. Is there any difference in speed at all? I strongly doubt it. One of virtio's main points is to reduce the number of kicks. For this stage of the project I think microbenchmarks are more appropriate. Doubling the price of exit is likely to be measureable. 30 cycles likely not ... I don't quite understand this point here. If we don't have anything real-world where we can measure a decent difference, then why are we doing this? I would agree with Alex that the three test scenarios proposed by him should be tried out before adding this complexity, measured in CPU utilization or latency as you wish. Sure, plan to do real world benchmarks for PV MMIO versus PIO as well. I don't see why I should bother implementing hypercalls given that the kvm maintainer says they won't be merged. the implementation effort to simply measure the hypercall performance should be minimal, no? If we can measure a true difference in performance, I'm sure we can revisit the issue of what will be merged and what won't be, but until we have those numbers it's all speculation. FWIW, ARM always uses MMIO and provides hardware decoding of all sane (not user register-writeback) instruction, but the hypercall vs. mmio looks like this: hvc: 4,917 mmio_kernel: 6,248 So 20% difference? That's not far from what happens on my intel laptop: vmcall 1519 outl_to_kernel 1745 10% difference here. But I doubt that an hvc wrapper around mmio decoding would take care of all this difference, because the mmio operation needs to do other work not realated to emulating the instruction in software, which you'd have to do for an hvc anyway (populate kvm_mmio structure etc.) Instead of speculating, someone with relevant hardware could just try this, but kvm unittest doesn't seem to have arm support at the moment. Anyone working on this? We have a branch called kvm-selftest that replicates much of the functionality, which is what I run to get these measurements. I can port it over to unittest at some point, but I'm not active working on that. I can measure it, but we have bigger fish to fry on the ARM side right now, so it'll be a while until I get to that. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] gpio: remove GENERIC_GPIO completely
Hi Chen,
Cool, thanks! Can you send a formatted patch to include in the series,
or do you prefer me to squash it in the relevant patch and add your
signoff for this file?
Alex.
2013/4/6 Chen Baozi baoz...@gmail.com:
On Fri, Mar 29, 2013 at 06:11:15AM -0700, Alexandre Courbot wrote:
Another issue, I could not update the Chinese documentation in a satisfying
manner due to my absence of Chinese skills. Hope that will be forgiven.
Hi Alexandre,
I have changed the Chinese documentation according to your update as
follows. Hopefully it would be helpful, :)
---
Documentation/zh_CN/gpio.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/zh_CN/gpio.txt b/Documentation/zh_CN/gpio.txt
index 4fa7b4e..d5b8f01 100644
--- a/Documentation/zh_CN/gpio.txt
+++ b/Documentation/zh_CN/gpio.txt
@@ -84,10 +84,10 @@ GPIO 公约
控制器的抽象函数来实现它。(有一些可选的代码能支持这种策略的实现,本文档
后面会介绍，但作为 GPIO 接口的客户端驱动程序必须与它的实现无关。)
-也就是说,如果在他们的平台上支持这个公约，驱动应尽可能的使用它。平台
-必须在 Kconfig 中声明对 GENERIC_GPIO的支持 (布尔型 true)，并提供
-一个 asm/gpio.h 文件。那些调用标准 GPIO 函数的驱动应该在 Kconfig
-入口中声明依赖GENERIC_GPIO。当驱动包含文件:
+也就是说,如果在他们的平台上支持这个公约，驱动应尽可能的使用它。同时，平台
+必须在 Kconfig 中选择 ARCH_REQUIRE_GPIOLIB 或者 ARCH_WANT_OPTIONAL_GPIOLIB
+选项。那些调用标准 GPIO 函数的驱动应该在 Kconfig
入口中声明依赖GENERIC_GPIO。
+当驱动包含文件:
#include linux/gpio.h
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: AMD Vi error and lost networking with r8169
David R da...@unsolicited.net : I'm been seeing some problems with my new ish AMD motherboard/processor combo and networking (r8169). I see the following page fault :- Apr 7 12:25:14 david kernel: [156421.436545] AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0015 address=0x3000 flags=0x0050] Can you give the hack below a try ? diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 28fb50a..ed8625d 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -4125,6 +4125,8 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp) case RTL_GIGA_MAC_VER_23: case RTL_GIGA_MAC_VER_24: case RTL_GIGA_MAC_VER_34: + case RTL_GIGA_MAC_VER_35: + case RTL_GIGA_MAC_VER_36: RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST); break; default: -- 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] hfsplus: add printk to log allocation failure in hfs_find_init()
On Mon, 2013-04-08 at 01:21 +0400, Alexey Khoroshilov wrote:
Add printk to log allocation failure in hfs_find_init(),
so that there is a sign in dmesg when the error condition is triggered.
(per Hin-Tak Leung request)
Not needed. There already is a generic dump_stack
on all allocation failures without __GFP_NOWARN.
diff --git a/fs/hfsplus/bfind.c b/fs/hfsplus/bfind.c
[]
@@ -18,8 +18,10 @@ int hfs_find_init(struct hfs_btree *tree, struct
hfs_find_data *fd)
+ if (!ptr) {
+ printk(KERN_ERR hfs: allocation failed in hfs_find_init()\n);
return -ENOMEM;
--
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: Excessive stall times on ext4 in 3.9-rc2
Hi - tytso wrote: So I tried to reproduce the problem, and so I installed systemtap (bleeding edge, since otherwise it won't work with development kernel), and then rebuilt a kernel with all of the necessary CONFIG options enabled: CONFIG_DEBUG_INFO, CONFIG_KPROBES, CONFIG_RELAY, CONFIG_DEBUG_FS, CONFIG_MODULES, CONFIG_MODULE_UNLOAD [...] That sounds about right. I then pulled down mmtests, and tried running watch-dstate.pl, which is what I assume you were using [...] I just took a look at the mmtests, particularly the stap-fix.sh stuff. The heroics therein are really not called for. git kernel developers should use git systemtap, as has always been the case. All compatibility hacks in stap-fix.sh have already been merged, in many cases for months. [...] semantic error: while resolving probe point: identifier 'kprobe' at /tmp/stapdjN4_l:18:7 source: probe kprobe.function(get_request_wait) ^ Pass 2: analysis failed. [man error::pass2] Unexpected exit of STAP script at ./watch-dstate.pl line 296. I have no clue what to do next. Can you give me a hint? You should see the error::pass2 man page, which refers to error::reporting, which refers to involving stap folks and running stap-report to gather needed info. But in this case, that's unnecessary: the problem is most likely that the get_request_wait function does not actually exist any longer, since commit a06e05e6afab70b4b23c0a7975aaeae24b195cd6 Author: Tejun Heo t...@kernel.org Date: Mon Jun 4 20:40:55 2012 -0700 block: refactor get_request[_wait]() Systemtap could endavour to list roughly-matching functions that do exist, if you think that's be helpful. - FChE -- 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: IMX23 usb instability on 3.9-rc5
On Sat, Apr 6, 2013 at 4:44 PM, Fabio Estevam feste...@gmail.com wrote: Maybe bad DDR initialization? Are using U-boot or bootlets to setup the DDR? What is your DDR frequency: 133 or 96MHz? I saw some posts in the olimex forum that people had to run it at 96MHz to get stable operation. Thanks Fabio, That seems to be the case. I did two of the mods sugested on olimex forums. 1) Remove R17. 2) Drop DDR speed to 96MHZ. The first improved the behavior a lot, but still have crashes. The second have almost eliminated them. On Sat, Apr 6, 2013 at 4:44 PM, Fabio Estevam feste...@gmail.com wrote: Alexandre, On Sat, Apr 6, 2013 at 4:39 PM, Alexandre Pereira da Silva aletes@gmail.com wrote: Hello, I am testing a usb key connected on a IMX23-Olinuxino board. The kernel panics at heavy usb trafic. This was build with the mxs defconfig This happens everytime with dd if=/dev/sda of=/dev/null bs=4k. The messages of the failure varies a lot from run to run. Maybe bad DDR initialization? Are using U-boot or bootlets to setup the DDR? What is your DDR frequency: 133 or 96MHz? I saw some posts in the olimex forum that people had to run it at 96MHz to get stable operation. -- 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] efivars: Implement no_storage_paranoia parameter
Using this parameter one can disable the storage_size/2 check if he is really sure that the UEFI does sane gc. Signed-off-by: Richard Weinberger rich...@nod.at --- drivers/firmware/efivars.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c index 60c9899..0926471 100644 --- a/drivers/firmware/efivars.c +++ b/drivers/firmware/efivars.c @@ -105,8 +105,10 @@ MODULE_VERSION(EFIVARS_VERSION); static bool efivars_pstore_disable = IS_ENABLED(CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE); +static bool efivars_no_storage_paranoia; module_param_named(pstore_disable, efivars_pstore_disable, bool, 0644); +module_param_named(no_storage_paranoia, efivars_no_storage_paranoia, bool, 0644); /* * The maximum size of VariableName + Data = 1024 @@ -453,7 +455,10 @@ check_var_size_locked(struct efivars *efivars, u32 attributes, printk_once(KERN_ERR FW_BUG Broken EFI implementation is returning MaxVariableSize=0\n); if (!storage_size || size remaining_size || - (max_size size max_size) || + (max_size size max_size)) + return EFI_OUT_OF_RESOURCES; + + if (!efivars_no_storage_paranoia (remaining_size - size) (storage_size / 2)) return EFI_OUT_OF_RESOURCES; -- 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/
