Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
On Wednesday 04 September 2013 07:14 AM, Seiji Aguchi wrote: Aruna, Sorry for the late response. Seiji, Could you let us know the efivars buffer size with which the pstore is registered when the failure occurred. I looked into the issue today. I added some debug message just before pstore_compress(). As you can see below, the buffer size is a fixed value(1024). Therefore, the size doesn't seem to be related to the failure directly. Also, in the failure case, zlib_deflate() returns Z_OK and stream.avail_out is zero. So, I thought big_oops_buf_sz is too big in my environment. And then, I tuned big_oops_buf_sz to (psinfo-bufsize * 100) / 53. Seiji, Thank you for the analysis. The reason behind compression failure is the size of big_oops_buf which is too big for efivars case. I will do some experiments with different kind of texts for buffer size 1024 to check if 100/53 suits for all the cases. At the same time, while looking into this issue, I had two concerns about current cording. 1) In pstore_decompress(), why not use zlib_inflateInit2() instead of zlib_inflateInit()? If you use zlib_deflateInit2() for specifying window_bit at compressing time, zlib_inflateInit2() seems to be appropriate for decompressing. (Please see a comment about inflateInit2() in include/linux/zlib.h and source code of crypto/deflate.c) Yes this can be changed to zlib_inflateInit2(). 2) As looking at crypto/deflate.c, stream-workspace is kzalloced at the beginning of compressing/decompressing time. So, in pstore case, stream.workspace must be initialized to 0 with memset() in pstore_compress()/decompress(). Hmm.. I don't think this is a issue. If you see fs/logfs/compr.c from which I derived the compression algorithms for pstore as well, they have not initialized stream.workspace. Since the space will be overwritten during the calculation, I dont think it will matter. The above 2 things you have suggested are good to have. But the reason behind compression failure is the big_oops_buf_sz which is too big for efivars. I did three things above, tuning big_oops_buf_sz, using zlib_inflateInit2() and initializing stream.workspace , in my environment. As a result, compressions/decmpressions of all entries succeeded with efivars driver. snip Panic#2 Part1 4[ 75.665020] [811af59c] SyS_write+0x4c/0xa0 4[ 75.665020] [8168be82] system_call_fastpath+0x16/0x1b 4[ 75.665020] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae f8 c6 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e 1[ 75.665020] RIP [813d3946] sysrq_handle_crash+0x16/0x20 4[ 75.665020] RSP 88007852de80 4[ 75.665020] CR2: 4[ 75.665020] ---[ end trace 97bb4a1f8d3fe7b2 ]--- 3[ 75.665020] pstore_dump hsize=13 len=2155 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore_dump hsize=13 len=2246 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore: compression failed for Part 2 returned -5 3[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 2 3[ 75.665020] pstore_dump hsize=13 len=2239 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore_dump hsize=13 len=2231 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore_dump hsize=13 len=2185 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore: compression failed for Part 5 returned -5 3[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 5 3[ 75.665020] pstore_dump hsize=13 len=2234 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore_dump hsize=13 len=2208 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore_dump hsize=13 len=2218 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore_dump hsize=13 len= big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore: compression failed for Part 9 returned -5 3[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 9 3[ 75.665020] pstore_dump hsize=14 len=2256 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore_dump hsize=14 len=2219 big_oops_buf_sz=2275 psinfo-bufsize=1024 3[ 75.665020] pstore_dump hsize=14 len=2226 big_oops_buf_sz=2275 psinfo-bufsize=1024 0[ 75.665020] Kernel panic - not syncing: Fatal exception 3[ 75.665020] drm_kms_helper: panic occurred, switching back to text console snip Seiji ___ Linuxppc-dev mailing list linuxppc-...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 net-next 3/5] driver/net: enic: Try DMA 64 first, then failover to DMA
Hi Dave The subject for this should be driver/net: enic: Try DMA 64 first, then failover to DMA 32 The 32 got truncated, please add this while committing. Let me know if you want me to send another patch. thanks //govind On Wed, 4 Sep 2013, Govindarajulu Varadarajan wrote: In servers with more than 1.1 TB of RAM, the existing 40/32 bit DMA could cause failure as the DMA-able address could go outside the range addressable using 40/32 bits. The following patch first tried 64 bit DMA if possible, failover to 32 bit. Signed-off-by: Sujith Sankar ssuj...@cisco.com Signed-off-by: Christian Benvenuti be...@cisco.com Signed-off-by: Govindarajulu Varadarajan govindarajul...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v4 3/3] sched: Periodically decay max cost of idle balance
On Fri, 2013-08-30 at 12:29 +0200, Peter Zijlstra wrote:
rcu_read_lock();
for_each_domain(cpu, sd) {
+ /*
+ * Decay the newidle max times here because this is a regular
+ * visit to all the domains. Decay ~0.5% per second.
+ */
+ if (time_after(jiffies, sd-next_decay_max_lb_cost)) {
+ sd-max_newidle_lb_cost =
+ (sd-max_newidle_lb_cost * 254) / 256;
I initially picked 0.5%, but after trying it out, it appears to decay very
slowing when the max is at a high value. Should we increase the decay a
little bit more? Maybe something like:
sd-max_newidle_lb_cost = (sd-max_newidle_lb_cost * 63) / 64;
+ /*
+ * Stop the load balance at this level. There is another
+ * CPU in our sched group which is doing load balancing more
+ * actively.
+ */
+ if (!continue_balancing) {
Is continue_balancing named balance in older kernels?
Here are the AIM7 results with the other 2 patches + this patch with the
slightly higher decay value.
workload | % improvement | % improvement | % improvement
| with patch | with patch | with patch
| 1100-2000 users | 200-1000 users | 10-100 users
alltests | +9.2% | +5.2% | +0.3%
compute | +0.0% | -0.9% | +0.6%
custom | +18.6% | +15.3% | +7.0%
disk | +4.0% | +16.5% | +7.1%
fserver | +64.8% | +27.5% | -0.6%
high_systime | +15.1% | +7.9% | +0.0%
new_fserver | +51.0% | +20.1% | -1.3%
shared | +6.3% | +8.8% | +2.8%
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/2] Perf support to SDT markers
Hi Hemant, On Tue, 03 Sep 2013 13:06:40 +0530, Hemant Kumar Shaw wrote: This series adds support to perf to list and probe into the SDT markers. The first patch implements listing of all the SDT markers present in the ELFs (executables or libraries). The SDT markers are present in the .note.stapsdt section of the elf. That section can be traversed to list all the markers. Recognition of markers follows the SystemTap approach. The second patch will allow perf to probe into these markers. This is done by writing the marker name and its offset into the uprobe_events file in the tracing directory. Then, perf tools can be used to analyze perf.data file. First, thanks for your work! In fact, I was working on the same topic of support SDT markers. But I started it by adding support for accessing arguments in uprobes [1]. The patchset is floating around the list for now but I hope it'll get merged soon. I guess you want to have it too :). Anyway, it'd great if you add me to CC next time. Thanks, Namhyung [1] http://thread.gmane.org/gmane.linux.kernel/1555044 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] x86, apic: Disable BSP if boot cpu is AP
On Mon, Sep 02, 2013 at 06:42:44PM +0900, HATAYAMA Daisuke wrote: The reason why I don't lookup BSP flag in MSR is that it's impossible. To read MSR of some CPU, we need to use rdmsr instruction on the CPU. However, in case of this issue, the BSP is halting or running in the kdump 1st kernel. Yes, and on the AP, that flag would be cleared which makes it not a BSP. A whole explanation is written in the patch description. Those tend to get lost in git history when a bunch of whitespace jerk offs appear ontop. So a nicely written comment in the code could be very helpful. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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:No Change] xHCI:Fixing xhci_readl definition and function call
On Tuesday 03 September 2013 09:34 PM, Sarah Sharp wrote: I'm confused. I said the last version of this patch didn't apply against usb-next, and you should rebase it. Why did you put No Change in the subject prefix? I miss understood what Dan said. he said me to add no change if there's no change from previous patch, but he didn't meant in subject (my bad). On Sat, Aug 31, 2013 at 11:02:45PM +0530, Kumar Gaurav wrote: This patch redefine function xhci_readl. xhci_readl function doesn't use xhci_hcd argument. Hence there is no need of keeping it in the function arguments. Redefining this function breaks other functions which calls this function. This phatch also correct those calls in xhci driver. Signed-off-by: Kumar Gaurav kumargauravgup...@gmail.com --- You didn't describe why you're resending this, or what changed. If you did rebase this against usb-next, you should have left the subject prefix as PATCH v4 and said here: v4: - rebased against usb-next You can do this by generating the patch with `git format-patch`, edit the patch manually (in whatever directory it was created it), and then send it by passing the file to `git send-email`. Sarah Sharp I rebased it against linux-next and i'll send the same patch as you discribed but please do let me know if i need to mark that as patch v5 as this patch won't have any change in changelog drivers/usb/host/xhci-dbg.c | 36 - drivers/usb/host/xhci-hub.c | 72 - drivers/usb/host/xhci-mem.c | 20 - drivers/usb/host/xhci-ring.c | 12 +++--- drivers/usb/host/xhci.c | 92 +- drivers/usb/host/xhci.h |3 +- 6 files changed, 117 insertions(+), 118 deletions(-) diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c index 73503a8..229e312 100644 --- a/drivers/usb/host/xhci-dbg.c +++ b/drivers/usb/host/xhci-dbg.c @@ -32,7 +32,7 @@ void xhci_dbg_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, // xHCI capability registers at %p:\n, xhci-cap_regs); - temp = xhci_readl(xhci, xhci-cap_regs-hc_capbase); + temp = xhci_readl(xhci-cap_regs-hc_capbase); xhci_dbg(xhci, // @%p = 0x%x (CAPLENGTH AND HCIVERSION)\n, xhci-cap_regs-hc_capbase, temp); xhci_dbg(xhci, // CAPLENGTH: 0x%x\n, @@ -44,13 +44,13 @@ void xhci_dbg_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, // xHCI operational registers at %p:\n, xhci-op_regs); - temp = xhci_readl(xhci, xhci-cap_regs-run_regs_off); + temp = xhci_readl(xhci-cap_regs-run_regs_off); xhci_dbg(xhci, // @%p = 0x%x RTSOFF\n, xhci-cap_regs-run_regs_off, (unsigned int) temp RTSOFF_MASK); xhci_dbg(xhci, // xHCI runtime registers at %p:\n, xhci-run_regs); - temp = xhci_readl(xhci, xhci-cap_regs-db_off); + temp = xhci_readl(xhci-cap_regs-db_off); xhci_dbg(xhci, // @%p = 0x%x DBOFF\n, xhci-cap_regs-db_off, temp); xhci_dbg(xhci, // Doorbell array at %p:\n, xhci-dba); } @@ -61,7 +61,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, xHCI capability registers at %p:\n, xhci-cap_regs); - temp = xhci_readl(xhci, xhci-cap_regs-hc_capbase); + temp = xhci_readl(xhci-cap_regs-hc_capbase); xhci_dbg(xhci, CAPLENGTH AND HCIVERSION 0x%x:\n, (unsigned int) temp); xhci_dbg(xhci, CAPLENGTH: 0x%x\n, @@ -69,7 +69,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, HCIVERSION: 0x%x\n, (unsigned int) HC_VERSION(temp)); - temp = xhci_readl(xhci, xhci-cap_regs-hcs_params1); + temp = xhci_readl(xhci-cap_regs-hcs_params1); xhci_dbg(xhci, HCSPARAMS 1: 0x%x\n, (unsigned int) temp); xhci_dbg(xhci, Max device slots: %u\n, @@ -79,7 +79,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, Max ports: %u\n, (unsigned int) HCS_MAX_PORTS(temp)); - temp = xhci_readl(xhci, xhci-cap_regs-hcs_params2); + temp = xhci_readl(xhci-cap_regs-hcs_params2); xhci_dbg(xhci, HCSPARAMS 2: 0x%x\n, (unsigned int) temp); xhci_dbg(xhci, Isoc scheduling threshold: %u\n, @@ -87,7 +87,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, Maximum allowed segments in event ring: %u\n, (unsigned int) HCS_ERST_MAX(temp)); - temp = xhci_readl(xhci, xhci-cap_regs-hcs_params3); + temp = xhci_readl(xhci-cap_regs-hcs_params3); xhci_dbg(xhci, HCSPARAMS 3 0x%x:\n, (unsigned int) temp); xhci_dbg(xhci, Worst case U1 device exit latency: %u\n, @@ -95,14 +95,14 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, Worst case U2 device exit latency: %u\n,
[tip:irq/core] x86/irq: Correct comment about i8259 initialization
Commit-ID: 7752572f18f98ee796e173334b088a1d621d2da4 Gitweb: http://git.kernel.org/tip/7752572f18f98ee796e173334b088a1d621d2da4 Author: Yanchuan Nian ycn...@gmail.com AuthorDate: Wed, 4 Sep 2013 09:25:24 +0800 Committer: Ingo Molnar mi...@kernel.org CommitDate: Wed, 4 Sep 2013 07:46:04 +0200 x86/irq: Correct comment about i8259 initialization 0x30-0x3f have been used for ISA interrupts on i386 as well since 5 years ago, but old comments about i8259 initialization were still referring to the old i386 usage of this port range. Signed-off-by: Yanchuan Nian ycn...@gmail.com Cc: ying...@kernel.org Cc: pa...@suse.cz Link: http://lkml.kernel.org/r/1378257924-29446-1-git-send-email-ycn...@gmail.com Signed-off-by: Ingo Molnar mi...@kernel.org --- arch/x86/kernel/i8259.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c index 9a5c460..2e977b5 100644 --- a/arch/x86/kernel/i8259.c +++ b/arch/x86/kernel/i8259.c @@ -312,8 +312,7 @@ static void init_8259A(int auto_eoi) */ outb_pic(0x11, PIC_MASTER_CMD); /* ICW1: select 8259A-1 init */ - /* ICW2: 8259A-1 IR0-7 mapped to 0x30-0x37 on x86-64, - to 0x20-0x27 on i386 */ + /* ICW2: 8259A-1 IR0-7 mapped to 0x30-0x37 */ outb_pic(IRQ0_VECTOR, PIC_MASTER_IMR); /* 8259A-1 (the master) has a slave on IR2 */ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] Send audit/procinfo/cgroup data in socket-level control message
Hi, this patchset against net-next (applies also to linux-next) adds 3 new types of Socket-level control message (SCM_AUDIT, SCM_PROCINFO and SCM_CGROUP). Server-like processes in many cases need credentials and other metadata of the peer, to decide if the calling process is allowed to request a specific action, or the server just wants to log away this type of information for auditing tasks. The current practice to retrieve such process metadata is to look that information up in procfs with the $PID received over SCM_CREDENTIALS. This is sufficient for long-running tasks, but introduces a race which cannot be worked around for short-living processes; the calling process and all the information in /proc/$PID/ is gone before the receiver of the socket message can look it up. Changes introduced in this patchset can also increase performance of such server-like processes, because current way of opening and parsing /proc/$PID/* files is much more expensive than receiving these metadata using SCM. Changes in v3: - Better description of patches (Thanks to Kay Sievers) Changes in v2: - use PATH_MAX instead of PAGE_SIZE in SCM_CGROUP patch - describe each patch individually Jan Kaluza (3): Send loginuid and sessionid in SCM_AUDIT Send comm and cmdline in SCM_PROCINFO Send cgroup_path in SCM_CGROUP include/linux/socket.h | 9 ++ include/net/af_unix.h | 10 ++ include/net/scm.h | 67 ++-- net/core/scm.c | 83 ++ net/unix/af_unix.c | 70 ++ 5 files changed, 237 insertions(+), 2 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] Send cgroup_path in SCM_CGROUP
Server-like processes in many cases need credentials and other
metadata of the peer, to decide if the calling process is allowed to
request a specific action, or the server just wants to log away this
type of information for auditing tasks.
The current practice to retrieve such process metadata is to look that
information up in procfs with the $PID received over SCM_CREDENTIALS.
This is sufficient for long-running tasks, but introduces a race which
cannot be worked around for short-living processes; the calling
process and all the information in /proc/$PID/ is gone before the
receiver of the socket message can look it up.
This introduces a new SCM type called SCM_CGROUP to allow the direct
attaching of cgroup_path to SCM, which is significantly more
efficient and will reliably avoid the race with the round-trip over
procfs.
Signed-off-by: Jan Kaluza jkal...@redhat.com
---
include/linux/socket.h | 1 +
include/net/af_unix.h | 1 +
include/net/scm.h | 15 +++
net/core/scm.c | 18 ++
net/unix/af_unix.c | 20
5 files changed, 55 insertions(+)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 6c7ace0..621fff1 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -133,6 +133,7 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr
*__msg, struct cmsghdr
#define SCM_AUDIT 0x04/* rw: struct uaudit*/
#define SCM_PROCINFO 0x05/* rw: comm + cmdline (NULL terminated
array of char *) */
+#define SCM_CGROUP 0x06/* rw: cgroup path */
struct ucred {
__u32 pid;
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 05c7678..c49bf35 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -32,6 +32,7 @@ struct unix_skb_parms_scm {
unsigned int sessionid;
char *procinfo;
int procinfo_len;
+ char *cgroup_path;
};
struct unix_skb_parms {
diff --git a/include/net/scm.h b/include/net/scm.h
index 3346030..5398826 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -41,6 +41,7 @@ struct scm_cookie {
struct scm_credscreds; /* Skb credentials */
struct scm_auditaudit; /* Skb audit*/
struct scm_procinfo procinfo; /* Skb procinfo */
+ char *cgroup_path;
#ifdef CONFIG_SECURITY_NETWORK
u32 secid; /* Passed security ID */
#endif
@@ -52,6 +53,7 @@ extern int __scm_send(struct socket *sock, struct msghdr
*msg, struct scm_cookie
extern void __scm_destroy(struct scm_cookie *scm);
extern struct scm_fp_list * scm_fp_dup(struct scm_fp_list *fpl);
extern int scm_get_current_procinfo(char **procinfo);
+extern int scm_get_current_cgroup_path(char **cgroup_path);
#ifdef CONFIG_SECURITY_NETWORK
static __inline__ void unix_get_peersec_dgram(struct socket *sock, struct
scm_cookie *scm)
@@ -86,6 +88,12 @@ static inline void scm_set_procinfo(struct scm_cookie *scm,
scm-procinfo.len = len;
}
+static inline void scm_set_cgroup_path(struct scm_cookie *scm,
+ char *cgroup_path)
+{
+ scm-cgroup_path = cgroup_path;
+}
+
static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
{
put_pid(scm-pid);
@@ -140,6 +148,9 @@ static inline void scm_passec(struct socket *sock, struct
msghdr *msg, struct sc
security_release_secctx(secdata, seclen);
}
}
+
+ kfree(scm-cgroup_path);
+ scm-cgroup_path = NULL;
}
#else
static inline void scm_passec(struct socket *sock, struct msghdr *msg, struct
scm_cookie *scm)
@@ -172,6 +183,10 @@ static __inline__ void scm_recv(struct socket *sock,
struct msghdr *msg,
put_cmsg(msg, SOL_SOCKET, SCM_AUDIT, sizeof(uaudits), uaudits);
put_cmsg(msg, SOL_SOCKET, SCM_PROCINFO, scm-procinfo.len,
scm-procinfo.procinfo);
+ if (scm-cgroup_path) {
+ put_cmsg(msg, SOL_SOCKET, SCM_CGROUP,
+strlen(scm-cgroup_path), scm-cgroup_path);
+ }
}
scm_destroy_cred(scm);
diff --git a/net/core/scm.c b/net/core/scm.c
index 09ec044..2d408b9 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -404,3 +404,21 @@ out:
return res;
}
EXPORT_SYMBOL(scm_get_current_procinfo);
+
+int scm_get_current_cgroup_path(char **cgroup_path)
+{
+ int ret = 0;
+
+ *cgroup_path = kmalloc(PATH_MAX, GFP_KERNEL);
+ if (!(*cgroup_path))
+ return -ENOMEM;
+
+ ret = task_cgroup_path(current, *cgroup_path, PATH_MAX);
+ if (ret 0) {
+ kfree(*cgroup_path);
+ *cgroup_path = NULL;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(scm_get_current_cgroup_path);
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index
[PATCH v3 1/3] Send loginuid and sessionid in SCM_AUDIT
Server-like processes in many cases need credentials and other
metadata of the peer, to decide if the calling process is allowed to
request a specific action, or the server just wants to log away this
type of information for auditing tasks.
The current practice to retrieve such process metadata is to look that
information up in procfs with the $PID received over SCM_CREDENTIALS.
This is sufficient for long-running tasks, but introduces a race which
cannot be worked around for short-living processes; the calling
process and all the information in /proc/$PID/ is gone before the
receiver of the socket message can look it up.
This introduces a new SCM type called SCM_AUDIT to allow the direct
attaching of loginuid and sessionid to SCM, which is significantly more
efficient and will reliably avoid the race with the round-trip over
procfs.
Signed-off-by: Jan Kaluza jkal...@redhat.com
---
include/linux/socket.h | 6 ++
include/net/af_unix.h | 2 ++
include/net/scm.h | 28 ++--
net/unix/af_unix.c | 7 +++
4 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 445ef75..505047a 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -130,6 +130,7 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr
*__msg, struct cmsghdr
#defineSCM_RIGHTS 0x01/* rw: access rights (array of
int) */
#define SCM_CREDENTIALS 0x02 /* rw: struct ucred */
#define SCM_SECURITY 0x03/* rw: security label */
+#define SCM_AUDIT 0x04/* rw: struct uaudit*/
struct ucred {
__u32 pid;
@@ -137,6 +138,11 @@ struct ucred {
__u32 gid;
};
+struct uaudit {
+ __u32 loginuid;
+ __u32 sessionid;
+};
+
/* Supported address families. */
#define AF_UNSPEC 0
#define AF_UNIX1 /* Unix domain sockets */
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index a175ba4..3b9d22a 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -36,6 +36,8 @@ struct unix_skb_parms {
u32 secid; /* Security ID */
#endif
u32 consumed;
+ kuid_t loginuid;
+ unsigned intsessionid;
};
#define UNIXCB(skb)(*(struct unix_skb_parms *)((skb)-cb))
diff --git a/include/net/scm.h b/include/net/scm.h
index 8de2d37..e349a25 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -6,6 +6,7 @@
#include linux/security.h
#include linux/pid.h
#include linux/nsproxy.h
+#include linux/audit.h
/* Well, we should have at least one descriptor open
* to accept passed FDs 8)
@@ -18,6 +19,11 @@ struct scm_creds {
kgid_t gid;
};
+struct scm_audit {
+ kuid_t loginuid;
+ unsigned int sessionid;
+};
+
struct scm_fp_list {
short count;
short max;
@@ -28,6 +34,7 @@ struct scm_cookie {
struct pid *pid; /* Skb credentials */
struct scm_fp_list *fp;/* Passed files */
struct scm_credscreds; /* Skb credentials */
+ struct scm_auditaudit; /* Skb audit*/
#ifdef CONFIG_SECURITY_NETWORK
u32 secid; /* Passed security ID */
#endif
@@ -58,6 +65,13 @@ static __inline__ void scm_set_cred(struct scm_cookie *scm,
scm-creds.gid = gid;
}
+static inline void scm_set_audit(struct scm_cookie *scm,
+ kuid_t loginuid, unsigned int sessionid)
+{
+ scm-audit.loginuid = loginuid;
+ scm-audit.sessionid = sessionid;
+}
+
static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
{
put_pid(scm-pid);
@@ -77,8 +91,12 @@ static __inline__ int scm_send(struct socket *sock, struct
msghdr *msg,
memset(scm, 0, sizeof(*scm));
scm-creds.uid = INVALID_UID;
scm-creds.gid = INVALID_GID;
- if (forcecreds)
- scm_set_cred(scm, task_tgid(current), current_uid(),
current_gid());
+ if (forcecreds) {
+ scm_set_cred(scm, task_tgid(current), current_uid(),
+current_gid());
+ scm_set_audit(scm, audit_get_loginuid(current),
+ audit_get_sessionid(current));
+ }
unix_get_peersec_dgram(sock, scm);
if (msg-msg_controllen = 0)
return 0;
@@ -123,7 +141,13 @@ static __inline__ void scm_recv(struct socket *sock,
struct msghdr *msg,
.uid = from_kuid_munged(current_ns, scm-creds.uid),
.gid = from_kgid_munged(current_ns, scm-creds.gid),
};
+ struct uaudit uaudits = {
+ .loginuid = from_kuid_munged(current_ns,
+
[PATCH v3 2/3] Send comm and cmdline in SCM_PROCINFO
Server-like processes in many cases need credentials and other
metadata of the peer, to decide if the calling process is allowed to
request a specific action, or the server just wants to log away this
type of information for auditing tasks.
The current practice to retrieve such process metadata is to look that
information up in procfs with the $PID received over SCM_CREDENTIALS.
This is sufficient for long-running tasks, but introduces a race which
cannot be worked around for short-living processes; the calling
process and all the information in /proc/$PID/ is gone before the
receiver of the socket message can look it up.
This introduces a new SCM type called SCM_PROCINFO to allow the direct
attaching of comm and cmdline to SCM, which is significantly more
efficient and will reliably avoid the race with the round-trip over
procfs.
To achieve that, new struct called unix_skb_parms_scm had to be created,
because otherwise unix_skb_parms would be too big.
scm_get_current_procinfo is inspired by ./fs/proc/base.c.
Signed-off-by: Jan Kaluza jkal...@redhat.com
---
include/linux/socket.h | 2 ++
include/net/af_unix.h | 11 +++--
include/net/scm.h | 24 +++
net/core/scm.c | 65 ++
net/unix/af_unix.c | 57 +--
5 files changed, 150 insertions(+), 9 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 505047a..6c7ace0 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -131,6 +131,8 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr
*__msg, struct cmsghdr
#define SCM_CREDENTIALS 0x02 /* rw: struct ucred */
#define SCM_SECURITY 0x03/* rw: security label */
#define SCM_AUDIT 0x04/* rw: struct uaudit*/
+#define SCM_PROCINFO 0x05/* rw: comm + cmdline (NULL terminated
+ array of char *) */
struct ucred {
__u32 pid;
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 3b9d22a..05c7678 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -27,6 +27,13 @@ struct unix_address {
struct sockaddr_un name[0];
};
+struct unix_skb_parms_scm {
+ kuid_t loginuid;
+ unsigned int sessionid;
+ char *procinfo;
+ int procinfo_len;
+};
+
struct unix_skb_parms {
struct pid *pid; /* Skb credentials */
kuid_t uid;
@@ -36,12 +43,12 @@ struct unix_skb_parms {
u32 secid; /* Security ID */
#endif
u32 consumed;
- kuid_t loginuid;
- unsigned intsessionid;
+ struct unix_skb_parms_scm *scm;
};
#define UNIXCB(skb)(*(struct unix_skb_parms *)((skb)-cb))
#define UNIXSID(skb) (UNIXCB((skb)).secid)
+#define UNIXSCM(skb) (*(UNIXCB((skb)).scm))
#define unix_state_lock(s) spin_lock(unix_sk(s)-lock)
#define unix_state_unlock(s) spin_unlock(unix_sk(s)-lock)
diff --git a/include/net/scm.h b/include/net/scm.h
index e349a25..3346030 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -30,11 +30,17 @@ struct scm_fp_list {
struct file *fp[SCM_MAX_FD];
};
+struct scm_procinfo {
+ char *procinfo;
+ int len;
+};
+
struct scm_cookie {
struct pid *pid; /* Skb credentials */
struct scm_fp_list *fp;/* Passed files */
struct scm_credscreds; /* Skb credentials */
struct scm_auditaudit; /* Skb audit*/
+ struct scm_procinfo procinfo; /* Skb procinfo */
#ifdef CONFIG_SECURITY_NETWORK
u32 secid; /* Passed security ID */
#endif
@@ -45,6 +51,7 @@ extern void scm_detach_fds_compat(struct msghdr *msg, struct
scm_cookie *scm);
extern int __scm_send(struct socket *sock, struct msghdr *msg, struct
scm_cookie *scm);
extern void __scm_destroy(struct scm_cookie *scm);
extern struct scm_fp_list * scm_fp_dup(struct scm_fp_list *fpl);
+extern int scm_get_current_procinfo(char **procinfo);
#ifdef CONFIG_SECURITY_NETWORK
static __inline__ void unix_get_peersec_dgram(struct socket *sock, struct
scm_cookie *scm)
@@ -72,10 +79,20 @@ static inline void scm_set_audit(struct scm_cookie *scm,
scm-audit.sessionid = sessionid;
}
+static inline void scm_set_procinfo(struct scm_cookie *scm,
+ char *procinfo, int len)
+{
+ scm-procinfo.procinfo = procinfo;
+ scm-procinfo.len = len;
+}
+
static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
{
put_pid(scm-pid);
scm-pid = NULL;
+ kfree(scm-procinfo.procinfo);
+ scm-procinfo.procinfo = NULL;
+ scm-procinfo.len = 0;
}
static __inline__ void
[PATCH] DRM: TTM: Fix memory leak issue in ttm_agp_tt_create().
From: Jeyaraman R jeyaraman.rangas...@lge.com
This patch adds kfree() in ttm_agp_tt_create() to avoide the
memory leak, without this there is a chance of memory leak in
ttm_tt_init() fail case.
Signed-off-by: Jeyaraman R jeyaraman.rangas...@lge.com
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: David Airlie airl...@linux.ie
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: David Howells dhowe...@redhat.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Dave Jones da...@redhat.com
Cc: Dave Airlie airl...@redhat.com
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 3302f99..764be36 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -126,6 +126,7 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_bo_device *bdev,
agp_be-ttm.func = ttm_agp_func;
if (ttm_tt_init(agp_be-ttm, bdev, size, page_flags, dummy_read_page))
{
+ kfree(agp_be);
return NULL;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SDT markers listing by perf
On Tue, 03 Sep 2013 13:06:55 +0530, Hemant Kumar wrote:
[SNIP]
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index e8a66f9..3d8dcdf 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -55,6 +55,7 @@ static struct {
bool show_funcs;
bool mod_events;
bool uprobes;
+ bool sdt;
int nevents;
struct perf_probe_event events[MAX_PROBES];
struct strlist *dellist;
@@ -325,6 +326,8 @@ int cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
opt_set_filter),
OPT_CALLBACK('x', exec, NULL, executable|path,
target executable name or path, opt_set_target),
+ OPT_BOOLEAN('S', sdt, params.sdt,
+ Show and probe on the SDT markers),
You need to add it to Documentation/perf-probe.txt too. In addition if
the --sdt option is only able to work with libelf, it should be wrapped
into the #ifdef LIBELF_SUPPORT pair.
And I'm not sure that it's a good idea to have two behavior on a single
option (S) - show and probe (add). Maybe it can be separated into two
or the S option can be used as a flag with existing --list and --add
option?
OPT_END()
};
int ret;
@@ -355,6 +358,28 @@ int cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
*/
symbol_conf.try_vmlinux_path = (symbol_conf.vmlinux_name == NULL);
+ if (params.sdt) {
+ if (params.show_lines) {
+ pr_err( Error: Don't use --sdt with --line.\n);
+ usage_with_options(probe_usage, options);
+ }
+ if (params.show_vars) {
+ pr_err( Error: Don't use --sdt with --vars.\n);
+ usage_with_options(probe_usage, options);
+ }
+ if (params.show_funcs) {
+ pr_err( Error: Don't use --sdt with --funcs.\n);
+ usage_with_options(probe_usage, options);
+ }
+ if (params.list_events) {
+ ret = show_available_markers(params.target);
+ if (ret 0)
+ pr_err( Error: Failed to show markers.
+ (%d)\n, ret);
+ return ret;
+ }
+ }
+
if (params.list_events) {
if (params.mod_events) {
pr_err( Error: Don't use --list with --add/--del.\n);
@@ -382,6 +407,7 @@ int cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
ret);
return ret;
}
+
if (params.show_funcs) {
if (params.nevents != 0 || params.dellist) {
pr_err( Error: Don't use --funcs with
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index aa04bf9..7f846f9 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2372,3 +2372,9 @@ out:
free(name);
return ret;
}
+
+int show_available_markers(const char *target)
+{
+ setup_pager();
+ return list_markers(target);
+}
Did you build it with NO_LIBELF=1 ? I guess not. At least you need a
dummy list_markers() function which just returns -1 for such case.
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 4b12bf8..f3630f2 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -846,6 +846,211 @@ out_elf_end:
return err;
}
+/* Populate the name, type, offset and argument fields in the note structure
*/
+static struct sdt_note *populate_note(Elf **elf, const char *data, size_t
len,
+ int type)
Hmm.. I think the name needs to be changed more specific like
populate_sdt_note() or something?
+{
+ const char *provider, *name, *args;
+ struct sdt_note *note;
+
+ /*
+ * There are 3 address values to be obtained: marker offset, base
address
+ * and semaphore
+ */
+ union {
+ Elf64_Addr a64[3];
+ Elf32_Addr a32[3];
+ } buf;
+
+ /*
+ * dst and src (of Elf_Data) are required for translation from file
+ * to memory representation
+ */
+ Elf_Data dst = {
+ .d_buf = buf, .d_type = ELF_T_ADDR, .d_version = EV_CURRENT,
+ .d_size = gelf_fsize((*elf), ELF_T_ADDR, 3, EV_CURRENT),
+ .d_off = 0, .d_align = 0
+ };
+
+ Elf_Data src = {
+ .d_buf = (void *) data, .d_type = ELF_T_ADDR,
+ .d_version = EV_CURRENT, .d_size = dst.d_size, .d_off = 0,
+ .d_align = 0
+ };
+
+ if (type != SDT_NOTE_TYPE)
+ goto out_ret;
+
+ note = zalloc(sizeof(struct sdt_note));
+ if (note == NULL) {
+ pr_err(memory allocation error\n);
Re: [PATCH 1/2] SDT markers listing by perf
On Tue, 03 Sep 2013 13:49:35 +0530, Hemant wrote: On 09/03/2013 01:06 PM, Hemant Kumar wrote: This patch will enable perf to list all the sdt markers present in an elf file. The markers are present in the .note.stapsdt section of the elf. We can traverse through this section and collect the required info about the markers. This hasn't been thoroughly tested with the other options of perf. Usage : ./perf probe --list -x /lib64/libc.so.6 There is a mismatch between usage and the patch here. This should be: perf probe --list -S /lib64/libc.so.6 I guess it should be perf probe -S -x /lib64/libc.so.6 Thanks, Namhyung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/7] regulator: anatop-regulator: Use devm_regulator_register
devm_* simplifies the code.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
This series is compile tested.
---
drivers/regulator/anatop-regulator.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/regulator/anatop-regulator.c
b/drivers/regulator/anatop-regulator.c
index 0d4a8cc..e42bfd1 100644
--- a/drivers/regulator/anatop-regulator.c
+++ b/drivers/regulator/anatop-regulator.c
@@ -200,7 +200,7 @@ static int anatop_regulator_probe(struct platform_device
*pdev)
config.regmap = sreg-anatop;
/* register regulator */
- rdev = regulator_register(rdesc, config);
+ rdev = devm_regulator_register(dev, rdesc, config);
if (IS_ERR(rdev)) {
dev_err(dev, failed to register %s\n,
rdesc-name);
@@ -223,7 +223,6 @@ static int anatop_regulator_remove(struct platform_device
*pdev)
struct anatop_regulator *sreg = rdev_get_drvdata(rdev);
const char *name = sreg-name;
- regulator_unregister(rdev);
kfree(name);
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] regulator: isl6271a-regulator: Use devm_regulator_register
devm_* simplifies the code.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/regulator/isl6271a-regulator.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/regulator/isl6271a-regulator.c
b/drivers/regulator/isl6271a-regulator.c
index b99c49b..40c224f 100644
--- a/drivers/regulator/isl6271a-regulator.c
+++ b/drivers/regulator/isl6271a-regulator.c
@@ -112,7 +112,7 @@ static int isl6271a_probe(struct i2c_client *i2c,
struct regulator_config config = { };
struct regulator_init_data *init_data = i2c-dev.platform_data;
struct isl_pmic *pmic;
- int err, i;
+ int i;
if (!i2c_check_functionality(i2c-adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -EIO;
@@ -133,32 +133,17 @@ static int isl6271a_probe(struct i2c_client *i2c,
config.init_data = NULL;
config.driver_data = pmic;
- pmic-rdev[i] = regulator_register(isl_rd[i], config);
+ pmic-rdev[i] = devm_regulator_register(i2c-dev, isl_rd[i],
+ config);
if (IS_ERR(pmic-rdev[i])) {
dev_err(i2c-dev, failed to register %s\n, id-name);
- err = PTR_ERR(pmic-rdev[i]);
- goto error;
+ return PTR_ERR(pmic-rdev[i]);
}
}
i2c_set_clientdata(i2c, pmic);
return 0;
-
-error:
- while (--i = 0)
- regulator_unregister(pmic-rdev[i]);
- return err;
-}
-
-static int isl6271a_remove(struct i2c_client *i2c)
-{
- struct isl_pmic *pmic = i2c_get_clientdata(i2c);
- int i;
-
- for (i = 0; i 3; i++)
- regulator_unregister(pmic-rdev[i]);
- return 0;
}
static const struct i2c_device_id isl6271a_id[] = {
@@ -174,7 +159,6 @@ static struct i2c_driver isl6271a_i2c_driver = {
.owner = THIS_MODULE,
},
.probe = isl6271a_probe,
- .remove = isl6271a_remove,
.id_table = isl6271a_id,
};
--
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/2] Perf support to SDT markers
On Tue, 03 Sep 2013 18:53:17 +0530, Hemant wrote: On 09/03/2013 02:47 PM, Masami Hiramatsu wrote: (2013/09/03 17:25), Ingo Molnar wrote: * Hemant Kumar Shaw hks...@linux.vnet.ibm.com wrote: This series adds support to perf to list and probe into the SDT markers. The first patch implements listing of all the SDT markers present in the ELFs (executables or libraries). The SDT markers are present in the .note.stapsdt section of the elf. That section can be traversed to list all the markers. Recognition of markers follows the SystemTap approach. The second patch will allow perf to probe into these markers. This is done by writing the marker name and its offset into the uprobe_events file in the tracing directory. Then, perf tools can be used to analyze perf.data file. Please provide a better high level description that explains the history and scope of SDT markers, how SDT markers get into binaries, how they can be used for probing, a real-life usage example that shows something interesting not possible via other ways, etc. Indeed, and also I'd like to know what versions of SDT this support, and where we can see the technical document of that. As far as I know, the previous(?) SDT implementation also involves ugly semaphores. Have that already gone? It seems it's not. I see the SDT v3 document still mentions semaphores. This link shows an example of marker probing with Systemtap: https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps I think the link below would be more helpful for us :) http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation Thanks, Namhyung - Markers in binaries : These SDT markers are present in the ELF in the section named .note.stapsdt. Here, the name of the marker, its provider, type, location, base address, semaphore address, arguments are present. We can retrieve these values using the members name_off and desc_off in Nhdr structure. If these are not enabled, they are present in the ELF as nop. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] regulator: palmas: Use devm_regulator_register
devm_* simplifies the code.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/regulator/palmas-regulator.c | 38 ++
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index d0c8785..37b1068 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -852,7 +852,7 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
if (ret 0) {
dev_err(pdev-dev,
reading TSTEP reg failed: %d\n, ret);
- goto err_unregister_regulator;
+ return ret;
}
pmic-desc[id].ramp_delay =
palmas_smps_ramp_delay[reg 0x3];
@@ -864,7 +864,7 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
reg_init = pdata-reg_init[id];
ret = palmas_smps_init(palmas, id, reg_init);
if (ret)
- goto err_unregister_regulator;
+ return ret;
}
/* Register the regulators */
@@ -897,7 +897,7 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
ret = palmas_smps_read(pmic-palmas, addr, reg);
if (ret)
- goto err_unregister_regulator;
+ return ret;
if (reg PALMAS_SMPS12_VOLTAGE_RANGE)
pmic-range[id] = 1;
@@ -913,7 +913,7 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
addr = palmas_regs_info[id].ctrl_addr;
ret = palmas_smps_read(pmic-palmas, addr, reg);
if (ret)
- goto err_unregister_regulator;
+ return ret;
pmic-current_reg_mode[id] = reg
PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
}
@@ -929,13 +929,13 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
pmic-desc[id].supply_name = palmas_regs_info[id].sname;
config.of_node = palmas_matches[id].of_node;
- rdev = regulator_register(pmic-desc[id], config);
+ rdev = devm_regulator_register(pdev-dev, pmic-desc[id],
+ config);
if (IS_ERR(rdev)) {
dev_err(pdev-dev,
failed to register %s regulator\n,
pdev-name);
- ret = PTR_ERR(rdev);
- goto err_unregister_regulator;
+ return PTR_ERR(rdev);
}
/* Save regulator for cleanup */
@@ -997,13 +997,13 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
pmic-desc[id].supply_name = palmas_regs_info[id].sname;
config.of_node = palmas_matches[id].of_node;
- rdev = regulator_register(pmic-desc[id], config);
+ rdev = devm_regulator_register(pdev-dev, pmic-desc[id],
+ config);
if (IS_ERR(rdev)) {
dev_err(pdev-dev,
failed to register %s regulator\n,
pdev-name);
- ret = PTR_ERR(rdev);
- goto err_unregister_regulator;
+ return PTR_ERR(rdev);
}
/* Save regulator for cleanup */
@@ -1021,7 +1021,7 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
id, reg_init);
if (ret) {
regulator_unregister(pmic-rdev[id]);
- goto err_unregister_regulator;
+ return ret;
}
}
}
@@ -1029,21 +1029,6 @@ static int palmas_regulators_probe(struct
platform_device *pdev)
return 0;
-
-err_unregister_regulator:
- while (--id = 0)
- regulator_unregister(pmic-rdev[id]);
- return ret;
-}
-
-static int palmas_regulators_remove(struct platform_device *pdev)
-{
- struct palmas_pmic *pmic = platform_get_drvdata(pdev);
- int id;
-
- for (id = 0; id PALMAS_NUM_REGS; id++)
- regulator_unregister(pmic-rdev[id]);
- return 0;
}
static struct of_device_id of_palmas_match_tbl[] = {
@@ -1065,7 +1050,6 @@
[PATCH 6/7] regulator: rc5t583: Use devm_regulator_register
devm_* simplifies the code.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/regulator/rc5t583-regulator.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/regulator/rc5t583-regulator.c
b/drivers/regulator/rc5t583-regulator.c
index 5885b45..b58affb 100644
--- a/drivers/regulator/rc5t583-regulator.c
+++ b/drivers/regulator/rc5t583-regulator.c
@@ -173,33 +173,16 @@ skip_ext_pwr_config:
config.driver_data = reg;
config.regmap = rc5t583-regmap;
- rdev = regulator_register(ri-desc, config);
+ rdev = devm_regulator_register(pdev-dev, ri-desc, config);
if (IS_ERR(rdev)) {
dev_err(pdev-dev, Failed to register regulator %s\n,
ri-desc.name);
- ret = PTR_ERR(rdev);
- goto clean_exit;
+ return PTR_ERR(rdev);
}
reg-rdev = rdev;
}
platform_set_drvdata(pdev, regs);
return 0;
-
-clean_exit:
- while (--id = 0)
- regulator_unregister(regs[id].rdev);
-
- return ret;
-}
-
-static int rc5t583_regulator_remove(struct platform_device *pdev)
-{
- struct rc5t583_regulator *regs = platform_get_drvdata(pdev);
- int id;
-
- for (id = 0; id RC5T583_REGULATOR_MAX; ++id)
- regulator_unregister(regs[id].rdev);
- return 0;
}
static struct platform_driver rc5t583_regulator_driver = {
@@ -208,7 +191,6 @@ static struct platform_driver rc5t583_regulator_driver = {
.owner = THIS_MODULE,
},
.probe = rc5t583_regulator_probe,
- .remove = rc5t583_regulator_remove,
};
static int __init rc5t583_regulator_init(void)
--
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 7/7] regulator: ti-abb: Use devm_regulator_register
devm_* simplifies the code.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/regulator/ti-abb-regulator.c | 82 ++
1 file changed, 23 insertions(+), 59 deletions(-)
diff --git a/drivers/regulator/ti-abb-regulator.c
b/drivers/regulator/ti-abb-regulator.c
index 3753ed0..02392f8 100644
--- a/drivers/regulator/ti-abb-regulator.c
+++ b/drivers/regulator/ti-abb-regulator.c
@@ -696,22 +696,17 @@ static int ti_abb_probe(struct platform_device *pdev)
match = of_match_device(ti_abb_of_match, dev);
if (!match) {
/* We do not expect this to happen */
- ret = -ENODEV;
dev_err(dev, %s: Unable to match device\n, __func__);
- goto err;
+ return -ENODEV;
}
if (!match-data) {
- ret = -EINVAL;
dev_err(dev, %s: Bad data in match\n, __func__);
- goto err;
+ return -EINVAL;
}
abb = devm_kzalloc(dev, sizeof(struct ti_abb), GFP_KERNEL);
- if (!abb) {
- dev_err(dev, %s: Unable to allocate ABB struct\n, __func__);
- ret = -ENOMEM;
- goto err;
- }
+ if (!abb)
+ return -ENOMEM;
abb-regs = match-data;
/* Map ABB resources */
@@ -719,21 +714,17 @@ static int ti_abb_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pname);
if (!res) {
dev_err(dev, Missing '%s' IO resource\n, pname);
- ret = -ENODEV;
- goto err;
+ return -ENODEV;
}
abb-base = devm_ioremap_resource(dev, res);
- if (IS_ERR(abb-base)) {
- ret = PTR_ERR(abb-base);
- goto err;
- }
+ if (IS_ERR(abb-base))
+ return PTR_ERR(abb-base);
pname = int-address;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pname);
if (!res) {
dev_err(dev, Missing '%s' IO resource\n, pname);
- ret = -ENODEV;
- goto err;
+ return -ENODEV;
}
/*
* We may have shared interrupt register offsets which are
@@ -743,8 +734,7 @@ static int ti_abb_probe(struct platform_device *pdev)
resource_size(res));
if (!abb-int_base) {
dev_err(dev, Unable to map '%s'\n, pname);
- ret = -ENOMEM;
- goto err;
+ return -ENOMEM;
}
/* Map Optional resources */
@@ -764,8 +754,7 @@ static int ti_abb_probe(struct platform_device *pdev)
resource_size(res));
if (!abb-efuse_base) {
dev_err(dev, Unable to map '%s'\n, pname);
- ret = -ENOMEM;
- goto err;
+ return -ENOMEM;
}
pname = ldo-address;
@@ -776,10 +765,8 @@ static int ti_abb_probe(struct platform_device *pdev)
goto skip_opt;
}
abb-ldo_base = devm_ioremap_resource(dev, res);
- if (IS_ERR(abb-ldo_base)) {
- ret = PTR_ERR(abb-ldo_base);
- goto err;
- }
+ if (IS_ERR(abb-ldo_base))
+ return PTR_ERR(abb-ldo_base);
/* IF ldo_base is set, the following are mandatory */
pname = ti,ldovbb-override-mask;
@@ -788,12 +775,11 @@ static int ti_abb_probe(struct platform_device *pdev)
abb-ldovbb_override_mask);
if (ret) {
dev_err(dev, Missing '%s' (%d)\n, pname, ret);
- goto err;
+ return ret;
}
if (!abb-ldovbb_override_mask) {
dev_err(dev, Invalid property:'%s' set as 0!\n, pname);
- ret = -EINVAL;
- goto err;
+ return -EINVAL;
}
pname = ti,ldovbb-vset-mask;
@@ -802,12 +788,11 @@ static int ti_abb_probe(struct platform_device *pdev)
abb-ldovbb_vset_mask);
if (ret) {
dev_err(dev, Missing '%s' (%d)\n, pname, ret);
- goto err;
+ return ret;
}
if (!abb-ldovbb_vset_mask) {
dev_err(dev, Invalid property:'%s' set as 0!\n, pname);
- ret = -EINVAL;
- goto err;
+ return -EINVAL;
}
skip_opt:
@@ -817,31 +802,29 @@ skip_opt:
abb-txdone_mask);
if (ret) {
dev_err(dev, Missing '%s' (%d)\n, pname, ret);
- goto err;
+ return ret;
}
if (!abb-txdone_mask) {
dev_err(dev, Invalid property:'%s' set as 0!\n, pname);
- ret = -EINVAL;
- goto err;
+ return -EINVAL;
}
initdata = of_get_regulator_init_data(dev,
[PATCH 4/7] regulator: mc13892: Use devm_regulator_register
devm_* simplifies the code.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/regulator/mc13892-regulator.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/regulator/mc13892-regulator.c
b/drivers/regulator/mc13892-regulator.c
index 1037e07..96c9f80 100644
--- a/drivers/regulator/mc13892-regulator.c
+++ b/drivers/regulator/mc13892-regulator.c
@@ -611,43 +611,27 @@ static int mc13892_regulator_probe(struct platform_device
*pdev)
config.driver_data = priv;
config.of_node = node;
- priv-regulators[i] = regulator_register(desc, config);
+ priv-regulators[i] = devm_regulator_register(pdev-dev, desc,
+ config);
if (IS_ERR(priv-regulators[i])) {
dev_err(pdev-dev, failed to register regulator %s\n,
mc13892_regulators[i].desc.name);
- ret = PTR_ERR(priv-regulators[i]);
- goto err;
+ return PTR_ERR(priv-regulators[i]);
}
}
return 0;
-err:
- while (--i = 0)
- regulator_unregister(priv-regulators[i]);
- return ret;
err_unlock:
mc13xxx_unlock(mc13892);
return ret;
}
-static int mc13892_regulator_remove(struct platform_device *pdev)
-{
- struct mc13xxx_regulator_priv *priv = platform_get_drvdata(pdev);
- int i;
-
- for (i = 0; i priv-num_regulators; i++)
- regulator_unregister(priv-regulators[i]);
-
- return 0;
-}
-
static struct platform_driver mc13892_regulator_driver = {
.driver = {
.name = mc13892-regulator,
.owner = THIS_MODULE,
},
- .remove = mc13892_regulator_remove,
.probe = mc13892_regulator_probe,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation/kmemcheck: update kmemcheck documentation
On Sat, Aug 24, 2013 at 3:31 AM, Libin huawei.li...@huawei.com wrote: Kmemcheck configuration menu location correction in Documentation/ kmemcheck.txt Signed-off-by: Libin huawei.li...@huawei.com Looks good to me. Andrew mind picking this up? Acked-by: Pekka Enberg penb...@kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/7] regulator: mc13783: Use devm_regulator_register
devm_* simplifies the code.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/regulator/mc13783-regulator.c | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/regulator/mc13783-regulator.c
b/drivers/regulator/mc13783-regulator.c
index 5ff99d2..f036b26 100644
--- a/drivers/regulator/mc13783-regulator.c
+++ b/drivers/regulator/mc13783-regulator.c
@@ -400,7 +400,7 @@ static int mc13783_regulator_probe(struct platform_device
*pdev)
dev_get_platdata(pdev-dev);
struct mc13xxx_regulator_init_data *mc13xxx_data;
struct regulator_config config = { };
- int i, ret, num_regulators;
+ int i, num_regulators;
num_regulators = mc13xxx_get_num_regulators_dt(pdev);
@@ -444,32 +444,16 @@ static int mc13783_regulator_probe(struct platform_device
*pdev)
config.driver_data = priv;
config.of_node = node;
- priv-regulators[i] = regulator_register(desc, config);
+ priv-regulators[i] = devm_regulator_register(pdev-dev, desc,
+ config);
if (IS_ERR(priv-regulators[i])) {
dev_err(pdev-dev, failed to register regulator %s\n,
mc13783_regulators[i].desc.name);
- ret = PTR_ERR(priv-regulators[i]);
- goto err;
+ return PTR_ERR(priv-regulators[i]);
}
}
return 0;
-err:
- while (--i = 0)
- regulator_unregister(priv-regulators[i]);
-
- return ret;
-}
-
-static int mc13783_regulator_remove(struct platform_device *pdev)
-{
- struct mc13xxx_regulator_priv *priv = platform_get_drvdata(pdev);
- int i;
-
- for (i = 0; i priv-num_regulators; i++)
- regulator_unregister(priv-regulators[i]);
-
- return 0;
}
static struct platform_driver mc13783_regulator_driver = {
@@ -477,7 +461,6 @@ static struct platform_driver mc13783_regulator_driver = {
.name = mc13783-regulator,
.owner = THIS_MODULE,
},
- .remove = mc13783_regulator_remove,
.probe = mc13783_regulator_probe,
};
--
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: [-next] openvswitch BUILD_BUG_ON failed
On Tue, Sep 3, 2013 at 11:44 PM, Jesse Gross je...@nicira.com wrote:
On Sat, Aug 31, 2013 at 5:11 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Fri, Aug 30, 2013 at 3:11 AM, Jesse Gross je...@nicira.com wrote:
On Thu, Aug 29, 2013 at 3:10 PM, David Miller da...@davemloft.net wrote:
From: Jesse Gross je...@nicira.com
Date: Thu, 29 Aug 2013 14:42:22 -0700
On Thu, Aug 29, 2013 at 2:21 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
However, I have some doubts about other alignment enforcements:
__aligned(__alignof__(long)) makes the whole struct aligned to the
alignment rule for long:
1. This is only 2 bytes on m68k, i.e. != sizeof(long).
2. This is 4 bytes on many 32-bit platforms, which may be less than
the
default alignment for __be64 (cfr. some members of struct
ovs_key_ipv4_tunnel), so this may make those 64-bit members
unaligned.
Do any of those 32-bit architectures actually care about alignment of
64 bit values? On 32-bit x86, a long is 32 bits but the alignment
requirement of __be64 is also 32 bit.
All except x86-32 do, it is in fact the odd man out with respect to this
issue.
Thanks, good to know.
Andy, do you want to modify your patch to just drop the alignment
specification as Geert suggested (but definitely keep the new build
assert that you added)? It's probably better to just send the patch to
netdev (against net-next) as well since you'll likely get better
comments there and we can fix this faster if you cut out the
middleman.
Why do you want to keep the build asserts?
Is this in-memory structure also transfered as-is over the network?
If yes, you definitely want the padding.
Well they caught this bug and really don't cost anything.
Nevertheless, as the struct contains u32 and even __be64 members, the
size of the struct will always be a multiple of the alignment unit for
64-bit quantities (and thus also for long), as per the C standard.
Hence the check
BUILD_BUG_ON(sizeof(struct sw_flow_key) % __alignof__(long));
will only catch bad compiler bugs or people adding __packed to the struct.
It's possible that we might want to pack the structure in the future.
More generally though, the contents of the struct is really
independent of the alignment requirements here because we're accessing
it as an array of bytes in long-sized chunks so implicitly depending
on the size of the members is not that great.
So you're accessing it as an array of bytes in long-sized chunks.
What are you doing with this accessed data?
Transfering over the network?
Storing on disk?
Then it must be portable across machines and architectures, right?
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: [PATCH 2/2] Support to perf to probe on SDT markers:
On Tue, 03 Sep 2013 13:07:03 +0530, Hemant Kumar wrote:
This patch enables perf to probe on the marker name specified on the command
line.
It looks like you didn't consider prelinked libraries. You need to check
the address of .stapsdt.base section too. And obviously this patch
ignores any argument the SDT has which I think pretty important info.
But we can add it later once the uprobes arg fetch patches are in.
Also please see my previous comment on mixed usage of 'note' and
'marker'.
Thanks,
Namhyung
---
tools/perf/builtin-probe.c|7 +++
tools/perf/util/probe-event.c | 11
tools/perf/util/symbol-elf.c | 112
+
tools/perf/util/symbol.h |5 ++
4 files changed, 135 insertions(+)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 3d8dcdf..8382853 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -378,6 +378,13 @@ int cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
(%d)\n, ret);
return ret;
}
+ params.uprobes = true;
+ ret = probe_marker(params.target,
+params.events[0].point.function);
+ if (ret 0)
+ pr_err(Could not probe at %s marker\n,
+params.events[0].point.function);
+ return ret;
}
if (params.list_events) {
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 7f846f9..014d642 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2378,3 +2378,14 @@ int show_available_markers(const char *target)
setup_pager();
return list_markers(target);
}
+
+int probe_marker(const char *name, char *mark)
+{
+ int fd;
+
+ fd = open_uprobe_events(true);
+ if (fd == -1)
+ return fd;
+ else
+ return probe__marker(name, mark, fd);
+}
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index f3630f2..60938a5 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1040,6 +1040,118 @@ out_ret:
return ret;
}
+static void extract_first_name(const char *target, char *fname)
+{
+ int i, len;
+ char *file;
+
+ file = strrchr(target, DIR_SEP);
+ file++;
+ len = strlen(file);
+ for (i = 0; i = len; i++) {
+ if (!isalpha(file[i]))
+ break;
+ fname[i] = file[i];
+ }
+ fname[i] = '\0';
+}
+
+static int probe_at_note(struct sdt_note *r_note, const char *target, bool
exec,
+ int fd)
+{
+ char buf[MAX_CMDLEN];
+ int len, err = -1;
+ Elf64_Addr offset;
+ char *fname = NULL;
+
+ if (exec)
+ offset = r_note-addr.a64[0] - TEXT_SCN;
+ else
+ offset = r_note-addr.a64[0];
+
+ fname = (char *)zalloc(sizeof(char) * strlen(target));
+ if (fname == NULL) {
+ pr_err(Error in allocating memory to fname\n);
+ goto out_ret;
+ }
+
+ extract_first_name(target, fname);
+ len = snprintf(buf, MAX_CMDLEN, %c:%s%s/%s %s:0x%x, 'p', probe_,
+fname, r_note-name, target, (unsigned)offset);
+
+ len = write(fd, buf, MAX_CMDLEN);
+ if (len 0) {
+ pr_err(Couldn't write into uprobe_events!\n);
+ goto out_close;
+ } else {
+ printf(Added new event :\n);
+ printf(event = %s \t (on 0x%x)\n\n, r_note-name,
+(unsigned)offset);
+ printf(You can now use it on all perf tools such as :\n\n);
+ printf(\t perf record -e %s%s:%s -aR sleep 1\n\n, probe_,
fname, r_note-name);
+ err = 0;
+ }
+
+out_close:
+ close(fd);
+ free(fname);
+out_ret:
+ return err;
+}
+
+static int search_and_probe_at_note(char *key, struct sdt_note **start,
+ const char *target, bool exec, int fd)
+{
+ int ret = -1;
+ struct sdt_note *req;
+
+ for (req = (*start); req != NULL; req = req-next) {
+ if (!strcmp(key, req-name))
+ break;
+ }
+ if (!req) {
+ pr_err(Could not find marker %s\n, key);
+ return ret;
+ }
+
+ ret = probe_at_note(req, target, exec, fd);
+ return ret;
+}
+
+int probe__marker(const char *name, char *mark, int evfd)
+{
+ int ret = -1, fd;
+ Elf *elf;
+ bool exec = false;
+ struct sdt_note *head = NULL;
+
+ fd = open(name, O_RDONLY);
+ if (fd 0) {
+ pr_err(Failed to open the file\n);
+ goto out_ret;
+ }
+
+ symbol__elf_init();
+ elf = elf_begin(fd, PERF_ELF_C_READ_MMAP, NULL);
+ if (elf == NULL) {
[PATCH 1/1] regulator: s2mps11: Use devm_regulator_register
Commit e398b51a (regulator: s2mps11: Convert to devm_regulator_register())
intended to do this conversion. However the actual conversion to devm_* got
missed out. Fix this.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/regulator/s2mps11.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 163b232..7a90a16 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -293,7 +293,8 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
config.init_data = pdata-regulators[i].initdata;
config.driver_data = s2mps11;
- s2mps11-rdev[i] = regulator_register(regulators[i], config);
+ s2mps11-rdev[i] = devm_regulator_register(pdev-dev,
+ regulators[i], config);
if (IS_ERR(s2mps11-rdev[i])) {
ret = PTR_ERR(s2mps11-rdev[i]);
dev_err(pdev-dev, regulator init failed for %d\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: [PATCH trivial] UAPI: Kbuild: add/modify comments for uapi/Kbuild and uapi/linux/Kbuild
On Wed, Sep 4, 2013 at 3:08 AM, Chen Gang gang.c...@asianux.com wrote:
On 09/04/2013 12:41 AM, Geert Uytterhoeven wrote:
On Tue, Aug 6, 2013 at 3:46 AM, Chen Gang gang.c...@asianux.com wrote:
--- a/include/uapi/Kbuild
+++ b/include/uapi/Kbuild
@@ -1,7 +1,6 @@
# UAPI Header export list
-# Top-level Makefile calls into asm-$(ARCH)
-# List only non-arch directories below
-
+# Except linux/, UAPI means Universal API.
Sorry for my silly question, but what's the purpose of this Universal
API comment?
Firstly, at least for me, I don't think it is a silly question (maybe
it means I should give additional explanations). :-)
I 'guess' the Universal API means:
the API which can be used under multiple OS (independent from Linux), it
may be used under kernel mode or user mode.
It is just my 'guess', welcome additional suggestions or completions by
any members.
When we get this correct additional explanation after discussing, if
suitable, I should add the final explanation to current patch.
Thanks. As this is not related at all to Linux, I don't see a reason
to add this comment.
Here, UAPI means userspace API only.
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/
[PATCH v3 1/3] gpio: pcf857x: change to devm_request_threaded_irq
Remove the request_irq and use devm_request_threaded_irq
also cleanup free_irq. devm_* takes care of that.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/gpio/gpio-pcf857x.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 947cff4..4d0d28c 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -191,6 +191,25 @@ static int pcf857x_to_irq(struct gpio_chip *chip, unsigned
offset)
return irq_create_mapping(gpio-irq_domain, offset);
}
+static irqreturn_t pcf857x_irq(int irq, void *data)
+{
+ struct pcf857x *gpio = data;
+ unsigned long change, i, status, flags;
+
+ status = gpio-read(gpio-client);
+
+ spin_lock_irqsave(gpio-slock, flags);
+
+ change = gpio-status ^ status;
+ for_each_set_bit(i, change, gpio-chip.ngpio)
+ generic_handle_irq(irq_find_mapping(gpio-irq_domain, i));
+ gpio-status = status;
+
+ spin_unlock_irqrestore(gpio-slock, flags);
+
+ return IRQ_HANDLED;
+}
+
static void pcf857x_irq_demux_work(struct work_struct *work)
{
struct pcf857x *gpio = container_of(work,
@@ -241,8 +260,6 @@ static void pcf857x_irq_domain_cleanup(struct pcf857x *gpio)
if (gpio-irq_domain)
irq_domain_remove(gpio-irq_domain);
- if (gpio-irq)
- free_irq(gpio-irq, gpio);
}
static int pcf857x_irq_domain_init(struct pcf857x *gpio,
@@ -258,8 +275,11 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
goto fail;
/* enable real irq */
- status = request_irq(client-irq, pcf857x_irq_demux, 0,
-dev_name(client-dev), gpio);
+ status = devm_request_threaded_irq(client-dev, client-irq,
+ NULL, pcf857x_irq, IRQF_ONESHOT |
+ IRQF_TRIGGER_FALLING,
+ dev_name(client-dev), gpio);
+
if (status)
goto fail;
--
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 v3 2/3] gpio: pcf857x: remove the irq_demux_work and gpio-irq
Now that we are using devm_request_threaded_irq no need for
irq_demux_work and gpio-irq. Remove all its references.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/gpio/gpio-pcf857x.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 4d0d28c..ef52ee3 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -30,7 +30,6 @@
#include linux/of_device.h
#include linux/slab.h
#include linux/spinlock.h
-#include linux/workqueue.h
static const struct i2c_device_id pcf857x_id[] = {
@@ -89,12 +88,10 @@ struct pcf857x {
struct gpio_chipchip;
struct i2c_client *client;
struct mutexlock; /* protect 'out' */
- struct work_struct work; /* irq demux work */
struct irq_domain *irq_domain;/* for irq demux */
spinlock_t slock; /* protect irq demux */
unsignedout;/* software latch */
unsignedstatus; /* current status */
- int irq;/* real irq number */
int (*write)(struct i2c_client *client, unsigned data);
int (*read)(struct i2c_client *client);
@@ -210,38 +207,6 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
return IRQ_HANDLED;
}
-static void pcf857x_irq_demux_work(struct work_struct *work)
-{
- struct pcf857x *gpio = container_of(work,
- struct pcf857x,
- work);
- unsigned long change, i, status, flags;
-
- status = gpio-read(gpio-client);
-
- spin_lock_irqsave(gpio-slock, flags);
-
- change = gpio-status ^ status;
- for_each_set_bit(i, change, gpio-chip.ngpio)
- generic_handle_irq(irq_find_mapping(gpio-irq_domain, i));
- gpio-status = status;
-
- spin_unlock_irqrestore(gpio-slock, flags);
-}
-
-static irqreturn_t pcf857x_irq_demux(int irq, void *data)
-{
- struct pcf857x *gpio = data;
-
- /*
-* pcf857x can't read/write data here,
-* since i2c data access might go to sleep.
-*/
- schedule_work(gpio-work);
-
- return IRQ_HANDLED;
-}
-
static int pcf857x_irq_domain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hw)
{
@@ -284,9 +249,7 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
goto fail;
/* enable gpio_to_irq() */
- INIT_WORK(gpio-work, pcf857x_irq_demux_work);
gpio-chip.to_irq = pcf857x_to_irq;
- gpio-irq = client-irq;
return 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 v4 0/3] cleanup of gpio_pcf857x.c
This patch series - removes the irq_demux_work - Uses devm_request_threaded_irq - Call the user handler iff gpio_to_irq is done. v1 -- v2 Split v1 to 3 patches v2 -- v3 Remove the unnecessary dts patches. v3 -- v4 Remove gpio-irq (in patch 2) Note: these patches were made after applying [1]. [1] - [PATCH v5] gpio: pcf857x: Add OF support - https://lkml.org/lkml/2013/8/27/70 George Cherian (3): gpio: pcf857x: change to devm_request_threaded_irq gpio: pcf857x: remove the irq_demux_work and gpio-irq gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done drivers/gpio/gpio-pcf857x.c | 53 ++--- 1 file changed, 26 insertions(+), 27 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] uas: add dead request list
On Di, 2013-09-03 at 10:39 -0700, Sarah Sharp wrote: Don't you need to send an ABORT TASK message to the device to cancel the outstanding request for that stream ID? I don't see that in this code. I see lots of URB cancellation code, but nothing to remove the request from the device-side queue. It is there. uas_eh_abort_handler() cancels a single request. There is also uas_eh_device_reset_handler() which will try a LOGICAL UNIT RESET. Those might not work though, depending on the failure mode. If your usb3 streams stop working you can't cancel scsi requests that way. Or does it simply ensure that SCSI bus reset works? The scsi layer invokes the uas_eh_bus_reset_handler() as last resort, when everything else fails. So, yes, there we'll have the sledge hammer approach to recover: cancel all usb urbs, abort all requests, full usb device reset + re-initialization. But we hardly have another chance when the less invasive methods to cancel a requests didn't work ... Plus, as Joe mentioned, this code is full of BUG_ON(), which is not friendly to users, and doesn't increase my confidence that the driver is ready to have CONFIG_BROKEN removed. Huh? Why you are thinking BUG_ON() is a indicator for bad code quality? I'm using BUG_ON() like assert() in userspace, i.e. they are extra sanity checks which should never ever trigger. I can switch them to less disruptive WARN_ON() if that is the preferred way these says. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done
For pcf857x driver if the initial state is not set properly (proper
n_latch is not passed), we get bad irq prints on console.
We get this only for the first interrupt and doesnot repeat for further
interrupts unles and until there are other gpio pins which are not flipping
continously.
following prints are seen on console.
[ 40.983924] irq 0, desc: ce004080, depth: 1, count: 0, unhandled: 0
[ 40.990511] -handle_irq(): c00aa538, handle_bad_irq+0x0/0x260
[ 40.996768] -irq_data.chip(): c080b6ec, no_irq_chip+0x0/0x60
[ 41.002842] -action(): (null)
[ 41.006242]IRQ_NOPROBE set
[ 41.009465] IRQ_NOREQUEST set
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/gpio/gpio-pcf857x.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index ef52ee3..4887b8c 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -92,6 +92,7 @@ struct pcf857x {
spinlock_t slock; /* protect irq demux */
unsignedout;/* software latch */
unsignedstatus; /* current status */
+ unsignedirq_mapped; /* mapped gpio irqs */
int (*write)(struct i2c_client *client, unsigned data);
int (*read)(struct i2c_client *client);
@@ -184,8 +185,13 @@ static void pcf857x_set(struct gpio_chip *chip, unsigned
offset, int value)
static int pcf857x_to_irq(struct gpio_chip *chip, unsigned offset)
{
struct pcf857x *gpio = container_of(chip, struct pcf857x, chip);
+ int ret;
- return irq_create_mapping(gpio-irq_domain, offset);
+ ret = irq_create_mapping(gpio-irq_domain, offset);
+ if (ret 0)
+ gpio-irq_mapped |= (1 offset);
+
+ return ret;
}
static irqreturn_t pcf857x_irq(int irq, void *data)
@@ -197,7 +203,12 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
spin_lock_irqsave(gpio-slock, flags);
- change = gpio-status ^ status;
+ /*
+* call the interrupt handler iff gpio is used as
+* interrupt source, just to avoid bad irqs
+*/
+
+ change = ((gpio-status ^ status) gpio-irq_mapped);
for_each_set_bit(i, change, gpio-chip.ngpio)
generic_handle_irq(irq_find_mapping(gpio-irq_domain, i));
gpio-status = status;
@@ -210,9 +221,14 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
static int pcf857x_irq_domain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hw)
{
+ struct pcf857x *gpio = domain-host_data;
+
irq_set_chip_and_handler(virq,
dummy_irq_chip,
handle_level_irq);
+ set_irq_flags(virq, IRQF_VALID);
+ gpio-irq_mapped |= (1 hw);
+
return 0;
}
@@ -235,7 +251,7 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
gpio-irq_domain = irq_domain_add_linear(client-dev.of_node,
gpio-chip.ngpio,
pcf857x_irq_domain_ops,
-NULL);
+gpio);
if (!gpio-irq_domain)
goto fail;
--
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 10/13] tracing/uprobes: Fetch args before reserving a ring buffer
On Tue, 03 Sep 2013 19:50:28 +0900, Masami Hiramatsu wrote:
(2013/09/03 14:44), Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a per-cpu mutex to protect concurrent accesses.
This is needed since we'll be able to fetch args from an user memory
which can be swapped out. Before that uprobes could fetch args from
registers only which saved in a kernel space.
While at it, use __get_data_size() and store_trace_args() to reduce
code duplication.
[SNIP]
+size = esize + tu-p.size + dsize;
event = trace_current_buffer_lock_reserve(buffer, call-event.type,
- size + tu-p.size, 0, 0);
-if (!event)
+ size, 0, 0);
+if (!event) {
+mutex_unlock(mutex);
return;
Just for a maintenance reason, I personally like to use goto in this case
to fold up the mutex_unlock. :)
Other parts are good for me.
Reviewed-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Thank you for review!
I'll change it as you said and fix atomic_dec bug that Jovi found.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: cris/for-next
ping (new merge window)?
On Wed, Jul 31, 2013 at 10:22 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
Hi Jesper,
Is there any chance cris/for-next will land in mainline anytime soon?
It's last change was more than 3 months ago.
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 v4 3/3] sched: Periodically decay max cost of idle balance
On Fri, 2013-08-30 at 12:18 +0200, Peter Zijlstra wrote:
On Thu, Aug 29, 2013 at 01:05:36PM -0700, Jason Low wrote:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 58b0514..bba5a07 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1345,7 +1345,7 @@ ttwu_do_wakeup(struct rq *rq, struct task_struct *p,
int wake_flags)
if (rq-idle_stamp) {
u64 delta = rq_clock(rq) - rq-idle_stamp;
- u64 max = 2*rq-max_idle_balance_cost;
+ u64 max = 2*(sysctl_sched_migration_cost +
rq-max_idle_balance_cost);
You re-introduce sched_migration_cost here because max_idle_balance_cost
can now drop down to 0 again?
Yes it was so that max_idle_balance_cost would be at least sched_migration_cost
and that we would still skip idle_balance if avg_idle sched_migration_cost.
I also initially thought that adding sched_migration_cost would also account for
the extra costs of idle balancing that are not accounted for in the time spent
on each newidle load balance. Come to think of it though, sched_migration_cost
might be too large when used in that context considering we're already using the
max cost.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 10/13] tracing/uprobes: Fetch args before reserving a ring buffer
Hi Jovi,
[SNIP]
On Tue, 3 Sep 2013 19:10:04 +0800, zhangwei wrote:
+if (atomic_inc_return(uprobe_buffer_ref) == 1) {
+int cpu;
+
+uprobe_cpu_buffer = __alloc_percpu(PAGE_SIZE, PAGE_SIZE);
+if (uprobe_cpu_buffer == NULL)
+return -ENOMEM;
+
Do we need add atomic_dec if allocate percpu buffer failed?
Good catch! I'll fix it. :)
Thanks,
Namhyung
+for_each_possible_cpu(cpu)
+mutex_init(per_cpu(uprobe_cpu_mutex, cpu));
+}
+
WARN_ON(!uprobe_filter_is_empty(tu-filter));
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] hugetlbfs: support split page table lock
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. So when a process have many threads and they heavily
access to the memory, lock contention happens and impacts the performance.
This patch makes hugepage support split page table lock so that we use
page-ptl of the leaf node of page table tree which is pte for normal pages
but can be pmd and/or pud for hugepages of some architectures.
ChangeLog v2:
- add split ptl on other archs missed in v1
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
---
arch/powerpc/mm/hugetlbpage.c | 6 ++-
arch/tile/mm/hugetlbpage.c| 6 ++-
include/linux/hugetlb.h | 20 ++
mm/hugetlb.c | 92
++-
mm/mempolicy.c| 5 ++-
mm/migrate.c | 4 +-
mm/rmap.c | 2 +-
7 files changed, 90 insertions(+), 45 deletions(-)
diff --git v3.11-rc3.orig/arch/powerpc/mm/hugetlbpage.c
v3.11-rc3/arch/powerpc/mm/hugetlbpage.c
index d67db4b..7e56cb7 100644
--- v3.11-rc3.orig/arch/powerpc/mm/hugetlbpage.c
+++ v3.11-rc3/arch/powerpc/mm/hugetlbpage.c
@@ -124,6 +124,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t
*hpdp,
{
struct kmem_cache *cachep;
pte_t *new;
+ spinlock_t *ptl;
#ifdef CONFIG_PPC_FSL_BOOK3E
int i;
@@ -141,7 +142,8 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t
*hpdp,
if (! new)
return -ENOMEM;
- spin_lock(mm-page_table_lock);
+ ptl = huge_pte_lockptr(mm, new);
+ spin_lock(ptl);
Are you sure we can do that for ppc ?
new = kmem_cache_zalloc(cachep, GFP_KERNEL|__GFP_REPEAT);
The page for new(pte_t) could be shared right ? which mean a deadlock ?
May be you should do it at the pmd level itself for ppc
#ifdef CONFIG_PPC_FSL_BOOK3E
/*
* We have multiple higher-level entries that point to the same
@@ -174,7 +176,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t
*hpdp,
#endif
}
#endif
- spin_unlock(mm-page_table_lock);
+ spin_unlock(ptl);
return 0;
}
-aneesh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] media: i2c: adv7343: add OF support
Hi Mark, On Mon, Sep 2, 2013 at 9:47 PM, Mark Rutland mark.rutl...@arm.com wrote: On Wed, Aug 28, 2013 at 03:43:04AM +0100, Prabhakar Lad wrote: Hi Mark, On Tue, Aug 27, 2013 at 8:54 PM, Mark Rutland mark.rutl...@arm.com wrote: [fixing up devicetree list address] Thanks! On Mon, Aug 26, 2013 at 03:41:45AM +0100, Prabhakar Lad wrote: Hi Sylwester, On Fri, Aug 23, 2013 at 11:33 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: Cc: DT binding maintainers Cheers! On 07/20/2013 08:21 AM, Lad, Prabhakar wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com add OF support for the adv7343 driver. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- [...] .../devicetree/bindings/media/i2c/adv7343.txt | 48 drivers/media/i2c/adv7343.c| 46 ++- 2 files changed, 93 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/adv7343.txt diff --git a/Documentation/devicetree/bindings/media/i2c/adv7343.txt b/Documentation/devicetree/bindings/media/i2c/adv7343.txt new file mode 100644 index 000..5653bc2 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adv7343.txt @@ -0,0 +1,48 @@ +* Analog Devices adv7343 video encoder + +The ADV7343 are high speed, digital-to-analog video encoders in a 64-lead LQFP +package. Six high speed, 3.3 V, 11-bit video DACs provide support for composite +(CVBS), S-Video (Y-C), and component (YPrPb/RGB) analog outputs in standard +definition (SD), enhanced definition (ED), or high definition (HD) video +formats. + +Required Properties : +- compatible: Must be adi,adv7343 + +Optional Properties : +- adi,power-mode-sleep-mode: on enable the current consumption is reduced to + micro ampere level. All DACs and the internal PLL + circuit are disabled. This seems to be a boolean property, and I couldn't find any description in the linked datasheet of the constraints under which the unit may be put into sleep mode. Why do we require this property in the dt? Can the driver not always put a adv734x into sleep mode if it wants to, and then wake it up as required? The adv7343 decoder, fits on da850/dm6467 etc.. For the da850 it supports only SD where as the dm6467 supports HD/SD/ED for which DAC 1-6 of Register 0x0 varies for this board so I added them as the platform data but I got a review comment in the ML asking to add entire register as the pdata instead of DAC 1-6, so because of which it is being converted in the same way for DT. Not everything that appears in platform data should appear in the dt. This seems more like a run-time decision that a description of the hardware. I don't see why we need the adi,power-mode-sleep-mode property. Ok I will drop adi,power-mode-sleep-mode and adi,power-mode-pll-ctrl property from the DT bindings and just have adi,dac-enable, adi,sd-dac-enable properties as this cannot be handled runtime. Regards, --Prabhakar Lad -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] cramfs: mark as obsolete
Who needs cramfs when you have squashfs? At least, we should warn people that cramfs is obsolete. Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com --- MAINTAINERS | 2 +- fs/cramfs/Kconfig | 5 - 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5b32bc2..6218be0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2313,7 +2313,7 @@ F:kernel/cpuset.c CRAMFS FILESYSTEM W: http://sourceforge.net/projects/cramfs/ -S: Orphan +S: Orphan / Obsolete F: Documentation/filesystems/cramfs.txt F: fs/cramfs/ diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig index cd06466..15c36fe 100644 --- a/fs/cramfs/Kconfig +++ b/fs/cramfs/Kconfig @@ -1,5 +1,5 @@ config CRAMFS - tristate Compressed ROM file system support (cramfs) + tristate Compressed ROM file system support (cramfs) (OBSOLETE) depends on BLOCK select ZLIB_INFLATE help @@ -16,4 +16,7 @@ config CRAMFS cramfs. Note that the root file system (the one containing the directory /) cannot be compiled as a module. + This filesystem is obsoleted by SquashFS, which is much better + in terms of performance and features. + If unsure, say N. -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor
On 03.09.13 at 20:30, K. Y. Srinivasan k...@microsoft.com wrote:
@@ -76,6 +80,26 @@ static void __init ms_hyperv_init_platform(void)
printk(KERN_INFO HyperV: features 0x%x, hints 0x%x\n,
ms_hyperv.features, ms_hyperv.hints);
+ if (ms_hyperv.features HV_X64_MSR_APIC_FREQUENCY_AVAILABLE) {
+ /*
+ * Get the APIC frequency.
+ */
+ rdmsrl(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
+ hv_lapic_frequency /= HZ;
+ lapic_timer_frequency = hv_lapic_frequency;
+ printk(KERN_INFO HyperV: LAPIC Timer Frequency: %#x\n,
+ lapic_timer_frequency);
+
+ /*
+ * On Hyper-V, when we are booting off an EFI firmware stack,
+ * we do not have many legacy devices including PIC, PIT etc.
+ */
+ if (efi_enabled(EFI_BOOT)) {
+ printk(KERN_INFO HyperV: Using null_legacy_pic\n);
+ legacy_pic = null_legacy_pic;
+ }
And this check is really connected to the feature check around the
whole block, rather than being independent? (I'd also think that
this latter message would suffice to be KERN_DEBUG).
Jan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/4] AHCI: Conserve interrupts with pci_enable_msi_block_part() interface
On Tue, Sep 03, 2013 at 02:27:31PM -0400, Tejun Heo wrote: Hello, On Tue, Sep 03, 2013 at 06:19:06PM +0200, Alexander Gordeev wrote: We must enable maximum possible number of MSIs - the one reported in Multiple Message Capable register. Otherwise ICH device will fallback to MRSM. IOW, if the result of roundup_pow_of_two(n_ports) is not what in Multiple Message Capable register (i.e. as roundup_pow_of_two(6) vs 16) ICH will enforce MRSM mode. Hmmm... I think the interface in general is pretty messy. Wouldn't it be much cleaner to have a separate function to query MSICAP and let the function just return success / failure? Actually, sorry for misleading. It is only ICH (I am aware of) that works this way and I was focused on. I think a general approach that will cover it all (including ICH and undesired sharing of interrupt vectors) - start MME from roundup_pow_of_two(n_ports) and ensure MRSM bit is unset. If not - double MME and retry. If still not and the limit is reached - fall back to single MSI. Makes sense? Thanks. -- tejun -- Regards, Alexander Gordeev agord...@redhat.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 1/2] SDT markers listing by perf
(2013/09/03 16:36), Hemant Kumar wrote:
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 5f720dc..f2d17b7 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -197,6 +197,17 @@ struct symsrc {
#endif
};
+/* Note structure */
+struct sdt_note {
+ const char *name;
+ const char *provider;
+ union {
+ Elf64_Addr a64[3];
+ Elf32_Addr a32[3];
+ } addr;
+ struct sdt_note *next;
+};
Hmm, could you use struct list_head for listing up the data?
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] Send loginuid and sessionid in SCM_AUDIT
Jan Kaluza jkal...@redhat.com writes:
Server-like processes in many cases need credentials and other
metadata of the peer, to decide if the calling process is allowed to
request a specific action, or the server just wants to log away this
type of information for auditing tasks.
The current practice to retrieve such process metadata is to look that
information up in procfs with the $PID received over SCM_CREDENTIALS.
This is sufficient for long-running tasks, but introduces a race which
cannot be worked around for short-living processes; the calling
process and all the information in /proc/$PID/ is gone before the
receiver of the socket message can look it up.
This introduces a new SCM type called SCM_AUDIT to allow the direct
attaching of loginuid and sessionid to SCM, which is significantly more
efficient and will reliably avoid the race with the round-trip over
procfs.
Unless I am misreading something this patch will break the build if
CONFIG_AUDITSYSCALL is not defined.
Eric
Signed-off-by: Jan Kaluza jkal...@redhat.com
---
include/linux/socket.h | 6 ++
include/net/af_unix.h | 2 ++
include/net/scm.h | 28 ++--
net/unix/af_unix.c | 7 +++
4 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 445ef75..505047a 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -130,6 +130,7 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr
*__msg, struct cmsghdr
#define SCM_RIGHTS 0x01/* rw: access rights (array of
int) */
#define SCM_CREDENTIALS 0x02 /* rw: struct ucred */
#define SCM_SECURITY 0x03/* rw: security label */
+#define SCM_AUDIT0x04/* rw: struct uaudit*/
struct ucred {
__u32 pid;
@@ -137,6 +138,11 @@ struct ucred {
__u32 gid;
};
+struct uaudit {
+ __u32 loginuid;
+ __u32 sessionid;
+};
+
/* Supported address families. */
#define AF_UNSPEC0
#define AF_UNIX 1 /* Unix domain sockets */
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index a175ba4..3b9d22a 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -36,6 +36,8 @@ struct unix_skb_parms {
u32 secid; /* Security ID */
#endif
u32 consumed;
+ kuid_t loginuid;
+ unsigned intsessionid;
};
#define UNIXCB(skb) (*(struct unix_skb_parms *)((skb)-cb))
diff --git a/include/net/scm.h b/include/net/scm.h
index 8de2d37..e349a25 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -6,6 +6,7 @@
#include linux/security.h
#include linux/pid.h
#include linux/nsproxy.h
+#include linux/audit.h
/* Well, we should have at least one descriptor open
* to accept passed FDs 8)
@@ -18,6 +19,11 @@ struct scm_creds {
kgid_t gid;
};
+struct scm_audit {
+ kuid_t loginuid;
+ unsigned int sessionid;
+};
+
struct scm_fp_list {
short count;
short max;
@@ -28,6 +34,7 @@ struct scm_cookie {
struct pid *pid; /* Skb credentials */
struct scm_fp_list *fp;/* Passed files */
struct scm_credscreds; /* Skb credentials */
+ struct scm_auditaudit; /* Skb audit*/
#ifdef CONFIG_SECURITY_NETWORK
u32 secid; /* Passed security ID */
#endif
@@ -58,6 +65,13 @@ static __inline__ void scm_set_cred(struct scm_cookie *scm,
scm-creds.gid = gid;
}
+static inline void scm_set_audit(struct scm_cookie *scm,
+ kuid_t loginuid, unsigned int sessionid)
+{
+ scm-audit.loginuid = loginuid;
+ scm-audit.sessionid = sessionid;
+}
+
static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
{
put_pid(scm-pid);
@@ -77,8 +91,12 @@ static __inline__ int scm_send(struct socket *sock, struct
msghdr *msg,
memset(scm, 0, sizeof(*scm));
scm-creds.uid = INVALID_UID;
scm-creds.gid = INVALID_GID;
- if (forcecreds)
- scm_set_cred(scm, task_tgid(current), current_uid(),
current_gid());
+ if (forcecreds) {
+ scm_set_cred(scm, task_tgid(current), current_uid(),
+ current_gid());
+ scm_set_audit(scm, audit_get_loginuid(current),
+ audit_get_sessionid(current));
+ }
unix_get_peersec_dgram(sock, scm);
if (msg-msg_controllen = 0)
return 0;
@@ -123,7 +141,13 @@ static __inline__ void scm_recv(struct socket *sock,
struct msghdr *msg,
.uid = from_kuid_munged(current_ns, scm-creds.uid),
.gid =
Re: [Query] CPUFreq: Does these machines have separate clock domains for CPUs?
Hi Viresh, On Fri, Aug 30, 2013 at 4:33 PM, Viresh Kumar viresh.ku...@linaro.org wrote: On 30 August 2013 12:18, Magnus Damm magnus.d...@gmail.com wrote: Hi Viresh, On Thu, Aug 29, 2013 at 7:15 PM, Viresh Kumar viresh.ku...@linaro.org wrote: Hi, I have been doing some CPUFreq cleanup work and wanted to know if the below mentioned machines have separate clock domains for their CPUs or all share the same domain? So, that we can use some generic routines for these drivers which would eventually do: cpumask_setall(policy-cpus); And I wanted to make sure that this doesn't break them.. :) .. The drivers are: ... drivers/cpufreq/sh-cpufreq.c ... The above SH cpufreq driver seems to be written with SMP in mind, but I would say SMP is a very rare case for SH. So I believe it can be considered as UP-only at this point. If Paul disagrees I'm quite sure he will tell us. Okay.. The problem isn't really SMP but different clock domains for CPUs in a SMP system.. So, even if we have a SMP SH machine, will it have same clock line for all CPUs? Yeah, I understand your question but I'm afraid that I don't know the answer myself. I will go with the change anyway.. Good plan. Thanks for cleaning up the cpufreq bits. Cheers, / magnus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HW timers question (clocksource vs event)
Hi all,
I'd like to install one timer that provokes IRQ on timeout to measure
IRQ latencies. I can see that in dw_apb_timer.c Linux driver that
there is clocksource and event type of timers.
Can someone please explain me what is really the difference between clocksource
and event type of timers? If I'd like to produce an interrupt every
100mS which one should be used?
Based on your instructions I have added test_timer to dw_apb_timer_of.c :
static void __init timer_init(void)
{
struct device_node *event_timer, *source_timer, *test_timer;
event_timer = of_find_matching_node(NULL, osctimer_ids);
if (!event_timer)
panic(No timer for clockevent);
add_clockevent(event_timer);
source_timer = of_find_matching_node(NULL, sptimer_ids);
if (!source_timer)
panic(No timer for clocksource);
add_clocksource(source_timer);
//test_timer = of_find_matching_node(source_timer, sptimer_ids);
test_timer = of_find_node_by_path(/soc/timer1@ffc09000);
if (!test_timer)
panic(test_TIMER: No timer for clockevent);
add_clockevent(test_timer);
of_node_put(event_timer);
of_node_put(source_timer);
of_node_put(test_timer);
init_sched_clock();
}
I can now see the timer1 when I do cat proc/interrupts:
root@socfpga_cyclone5:~# cat /proc/interrupts
CPU0 CPU1
525: 2242 2252 GIC twd
648: 19 0 GIC eth0
653: 0 0 GIC dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
656: 0 0 GIC dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb2
667: 54610 0 GIC dw-mci
679: 0 0 GIC ff705000.spi
682: 0 0 GIC dw_spi0
684: 0 0 GIC dw_spi1
686: 6 0 GIC ffc04000.i2c
687: 0 0 GIC ffc05000.i2c
690:839 0 GIC serial
696: 0 0 GIC timer1
697: 9 0 GIC timer2
IPI0: 0 0 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 1117 1139 Rescheduling interrupts
IPI3: 0 0 Function call interrupts
IPI4: 2 1 Single function call interrupts
IPI5: 0 0 CPU stop interrupts
Err: 0
However, it provokes 0 interruptions. Looks like it is not enabled,
although enabling procedure is same like for timer2.
I tried then initializing it to CPU1, this did not help neither.
I tried defining it as a clocksource - then it was not visible at all.
I have questions at this point - how to enable timer1 to start
periodically provoking interrupt?
Thanks and best regards,
Drasko
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] Send audit/procinfo/cgroup data in socket-level control message
Jan Kaluza jkal...@redhat.com writes: Hi, this patchset against net-next (applies also to linux-next) adds 3 new types of Socket-level control message (SCM_AUDIT, SCM_PROCINFO and SCM_CGROUP). Server-like processes in many cases need credentials and other metadata of the peer, to decide if the calling process is allowed to request a specific action, or the server just wants to log away this type of information for auditing tasks. The current practice to retrieve such process metadata is to look that information up in procfs with the $PID received over SCM_CREDENTIALS. This is sufficient for long-running tasks, but introduces a race which cannot be worked around for short-living processes; the calling process and all the information in /proc/$PID/ is gone before the receiver of the socket message can look it up. Changes introduced in this patchset can also increase performance of such server-like processes, because current way of opening and parsing /proc/$PID/* files is much more expensive than receiving these metadata using SCM. Can I just say ick, blech, barf, gag. You don't require this information to be passed. You are asking people to suport a lot of new code for the forseeable future. The only advantage appears to be for short lived racy processes that don't even bother to make certain their message was acknowleged before exiting. You sent this during the merge window which is the time for code integration and testing not new code. By my count you have overflowed cb in struct sk_buff and are stomping on _skb_refdest. If you are going to go crazy and pass things is there a reason you do not add a patch to pass the bsd SCM_CREDS? That information seems more relevant in a security context and for making security decisions than about half the information you are passing. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 14/10] sched, fair: Fix the group_capacity computation
On 28 August 2013 13:16, Peter Zijlstra pet...@infradead.org wrote:
Subject: sched, fair: Fix the group_capacity computation
From: Peter Zijlstra pet...@infradead.org
Date: Wed Aug 28 12:40:38 CEST 2013
Do away with 'phantom' cores due to N*frac(smt_power) = 1 by limiting
the capacity to the actual number of cores.
Peter,
your patch also solves the 'phantom' big cores that can appear on HMP
system because big cores have a cpu_power = SCHED_POWER_SCALE in
order to express a higher capacity than LITTLE cores.
Acked-by Vincent Guittot vincent.gui...@linaro.org
Vincent
The assumption of 1 smt_power 2 is an actual requirement because
of what SMT is so this should work regardless of the SMT
implementation.
It can still be defeated by creative use of cpu hotplug, but if you're
one of those freaks, you get to live with it.
Signed-off-by: Peter Zijlstra pet...@infradead.org
---
kernel/sched/fair.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4554,18 +4554,24 @@ static inline int sg_imbalanced(struct s
/*
* Compute the group capacity.
*
- * For now the capacity is simply the number of power units in the
group_power.
- * A power unit represents a full core.
- *
- * This has an issue where N*frac(smt_power) = 1, in that case we'll see
extra
- * 'cores' that aren't actually there.
+ * Avoid the issue where N*frac(smt_power) = 1 creates 'phantom' cores by
+ * first dividing out the smt factor and computing the actual number of cores
+ * and limit power unit capacity with that.
*/
static inline int sg_capacity(struct lb_env *env, struct sched_group *group)
{
+ unsigned int capacity, smt, cpus;
+ unsigned int power, power_orig;
+
+ power = group-sgp-power;
+ power_orig = group-sgp-power_orig;
+ cpus = group-group_weight;
- unsigned int power = group-sgp-power;
- unsigned int capacity = DIV_ROUND_CLOSEST(power, SCHED_POWER_SCALE);
+ /* smt := ceil(cpus / power), assumes: 1 smt_power 2 */
+ smt = DIV_ROUND_UP(SCHED_POWER_SCALE * cpus, power_orig);
+ capacity = cpus / smt; /* cores */
+ capacity = min_t(capacity, DIV_ROUND_CLOSEST(power,
SCHED_POWER_SCALE));
if (!capacity)
capacity = fix_small_capacity(env-sd, group);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [gcv v3 32/35] arc: Replace __get_cpu_var uses
Hi Christoph, On 08/29/2013 10:13 PM, Christoph Lameter wrote: On Thu, 29 Aug 2013, Vineet Gupta wrote: On 08/29/2013 01:18 AM, Christoph Lameter wrote: Acked-by: Vineet Gupta vgu...@synopsys.com Signed-off-by: Christoph Lameter c...@linux.com Applied to for-next. Ok dropping it from patchset. Considering other discussions on this thread, shall I drop this from my for-curr for this merge window ? I don't see any other arch changes to that effect in latest linux-next. -Vineet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 08/35] mm: Demarcate and maintain pageblocks in region-order in the zones' freelists
(2013/08/30 22:16), Srivatsa S. Bhat wrote:
The zones' freelists need to be made region-aware, in order to influence
page allocation and freeing algorithms. So in every free list in the zone, we
would like to demarcate the pageblocks belonging to different memory regions
(we can do this using a set of pointers, and thus avoid splitting up the
freelists).
Also, we would like to keep the pageblocks in the freelists sorted in
region-order. That is, pageblocks belonging to region-0 would come first,
followed by pageblocks belonging to region-1 and so on, within a given
freelist. Of course, a set of pageblocks belonging to the same region need
not be sorted; it is sufficient if we maintain the pageblocks in
region-sorted-order, rather than a full address-sorted-order.
For each freelist within the zone, we maintain a set of pointers to
pageblocks belonging to the various memory regions in that zone.
Eg:
|---Region0---| |---Region1---| |---Region2-|
-- ||-- ||-- ||-- ||-- ||-- ||-- ||--
^ ^ ^
| | |
Reg0 Reg1 Reg2
Page allocation will proceed as usual - pick the first item on the free list.
But we don't want to keep updating these region pointers every time we allocate
a pageblock from the freelist. So, instead of pointing to the *first* pageblock
of that region, we maintain the region pointers such that they point to the
*last* pageblock in that region, as shown in the figure above. That way, as
long as there are 1 pageblocks in that region in that freelist, that region
pointer doesn't need to be updated.
Page allocation algorithm:
-
The heart of the page allocation algorithm remains as it is - pick the first
item on the appropriate freelist and return it.
Arrangement of pageblocks in the zone freelists:
---
This is the main change - we keep the pageblocks in region-sorted order,
where pageblocks belonging to region-0 come first, followed by those belonging
to region-1 and so on. But the pageblocks within a given region need *not* be
sorted, since we need them to be only region-sorted and not fully
address-sorted.
This sorting is performed when adding pages back to the freelists, thus
avoiding any region-related overhead in the critical page allocation
paths.
Strategy to consolidate allocations to a minimum no. of regions:
---
Page allocation happens in the order of increasing region number. We would
like to do light-weight page reclaim or compaction (for the purpose of memory
power management) in the reverse order, to keep the allocated pages within
a minimum number of regions (approximately). The latter part is implemented
in subsequent patches.
Increasing region number--
Direction of allocation------Direction of reclaim/compaction
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
mm/page_alloc.c | 154 +--
1 file changed, 138 insertions(+), 16 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index fd6436d0..398b62c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -514,6 +514,111 @@ static inline int page_is_buddy(struct page *page, struct
page *buddy,
return 0;
}
+static void add_to_freelist(struct page *page, struct free_list *free_list)
+{
+ struct list_head *prev_region_list, *lru;
+ struct mem_region_list *region;
+ int region_id, i;
+
+ lru = page-lru;
+ region_id = page_zone_region_id(page);
+
+ region = free_list-mr_list[region_id];
+ region-nr_free++;
+
+ if (region-page_block) {
+ list_add_tail(lru, region-page_block);
+ return;
+ }
+
+#ifdef CONFIG_DEBUG_PAGEALLOC
+ WARN(region-nr_free != 1, %s: nr_free is not unity\n, __func__);
+#endif
+
+ if (!list_empty(free_list-list)) {
+ for (i = region_id - 1; i = 0; i--) {
+ if (free_list-mr_list[i].page_block) {
+ prev_region_list =
+ free_list-mr_list[i].page_block;
+ goto out;
+ }
+ }
+ }
+
+ /* This is the first region, so add to the head of the list */
+ prev_region_list = free_list-list;
+
+out:
+ list_add(lru, prev_region_list);
+
+ /* Save pointer to page block of this region */
+ region-page_block = lru;
+}
+
+static void del_from_freelist(struct page *page, struct free_list *free_list)
+{
+ struct list_head *prev_page_lru, *lru, *p;
Re: [patch 0/7] improve memcg oom killer robustness v2
On Mon, Sep 02, 2013 at 12:38:02PM +0200, azurIt wrote: Hi azur, here is the x86-only rollup of the series for 3.2. Thanks! Johannes --- Johannes, unfortunately, one problem arises: I have (again) cgroup which cannot be deleted :( it's a user who had very high memory usage and was reaching his limit very often. Do you need any info which i can gather now? Did the OOM killer go off in this group? # cat /cgroups/cannot_rm_01/memory.oom_control oom_kill_disable 0 under_oom 1 # Was there a warning in the syslog (Fixing unhandled memcg OOM context)? Really don't know cos i don't know the exact day when it happens. I just find that out on 30.8. but it could happen anytime before. Uptime on that server is 27 days so maybe i can grep all syslog logs i have if it helps. I just need to find out the original name of that cgroup cos i renamed it to 'cannot_rm_01' so my software will ignore it. If it happens again, could you check if there are tasks left in the cgroup? And provide /proc/pid/stack of the hung task trying to delete the cgroup? # cat /cgroups/cannot_rm_01/tasks # Now i can definitely confirm that problem is NOT fixed :( it happened again but i don't have any data because i already disabled all debug output. Which debug output? Debug output from my own scripts which are suppose to handle this situation and kill frozen processes. I already reactivated it, it is grabbing content of 'stacks' from all processes before killing them. Do you still have access to the syslog? From that day (30.8.)? Yes. It's possible that, as your system does not deadlock on the OOMing cgroup anymore, you hit a separate bug... 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: SEO Trial For your wesbite : mail-archive.com
Hello Sir / Mam Hope you had a great week end ! Does your website rank page 1 on major search engines like google bing for your most converting keywords ? OR have your website lost rankings in last 1 year with Googles new algorithm changes? For your information 85% of users searching the web will never find your website unless you're ranked on first page of Google, MSN and other major search engines. On the top of this with all these new google update around ( Penguin Pandas ) its not easy to get page 1 and stay there for long to keep getting business from the web. Why our program is very unique : 15 days free seo trial We are presently offering a free 15 days SEO trial that has never been offered on the web so far. We will work on your website for 15 days and show you substantial growth in rankings for all keywords. You only move to paid service if satisfied with our service else you can opt out. Our Top Selling Packages - Package A) 10 keywords optimized - $99 / M - Package B) 20 Keywords optimized - $149 / M - Package C) 30 keywords optimized - $199 / M Company Information We rank top 10 on Google for terms like Online SEO Company, online seo consultants and many more. We are working for hundreds of clients online and all rank top 10 for their best keywords. We would like to have a chance to rank your website page 1 for best keywords in your niche. To opt-in for our free seo trial please email us back with the information below - Package you would like to OPT for - Website Address You want To Optimize - Recommended keywords ( Optional ) - SEO done previously ( Yes / No ) We guarantee you top 10 google listings in max 3 months of our program. We use the most ethical white hat Search Engine Optimization techniques to deliver rankings that will not get your website banned or penalized. Reply Awaited Regards Rose J SEO Manager (TOB) B7 Green Avenue, Amritsar 143001 Punjab -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SDT markers listing by perf
(2013/09/04 15:42), Namhyung Kim wrote:
On Tue, 03 Sep 2013 13:06:55 +0530, Hemant Kumar wrote:
[SNIP]
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index e8a66f9..3d8dcdf 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -55,6 +55,7 @@ static struct {
bool show_funcs;
bool mod_events;
bool uprobes;
+bool sdt;
int nevents;
struct perf_probe_event events[MAX_PROBES];
struct strlist *dellist;
@@ -325,6 +326,8 @@ int cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
opt_set_filter),
OPT_CALLBACK('x', exec, NULL, executable|path,
target executable name or path, opt_set_target),
+OPT_BOOLEAN('S', sdt, params.sdt,
+Show and probe on the SDT markers),
You need to add it to Documentation/perf-probe.txt too. In addition if
the --sdt option is only able to work with libelf, it should be wrapped
into the #ifdef LIBELF_SUPPORT pair.
And I'm not sure that it's a good idea to have two behavior on a single
option (S) - show and probe (add). Maybe it can be separated into two
or the S option can be used as a flag with existing --list and --add
option?
Good catch! :)
No, that is really bad idea. All probes must be added by --add action.
So we need a new probe syntax for specifying sdt marker.
How about the below syntax?
[EVENT=]%PROVIDER:MARKER [ARG ...]
Of course, this will require to list up all markers with % prefix for
continuity.
And since --list option is to list up all existing(defined) probe events,
I think --markers (as like as --funcs) is better for listing it up.
Thank you!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] AHCI: Conserve interrupts with pci_enable_msi_block_part() interface
On Tue, Sep 03, 2013 at 12:24:11PM -0400, Tejun Heo wrote: Hello, On Tue, Sep 03, 2013 at 04:57:19PM +0200, Alexander Gordeev wrote: Multiple MSI support enables threaded IRQ handling, because at the time of posting I did not want to intrude into the existing single-MSI codebase while multiple MSI/multipe CPU approach gained good numbers (below). Please separate out threaded IRQ support from multiple MSI. This series does not really bring any structural change to the AHCI code - just tweaks the MSI initialization. As threaded IRQ support vs multiple MSI is a separate issue what about addressing it in a separate effort? I would have to think on how to do it eigher :) Thanks. -- tejun -- Regards, Alexander Gordeev agord...@redhat.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: Re: [PATCH 2/2] Support to perf to probe on SDT markers:
(2013/09/04 16:00), Namhyung Kim wrote: On Tue, 03 Sep 2013 13:07:03 +0530, Hemant Kumar wrote: This patch enables perf to probe on the marker name specified on the command line. It looks like you didn't consider prelinked libraries. You need to check the address of .stapsdt.base section too. And obviously this patch ignores any argument the SDT has which I think pretty important info. But we can add it later once the uprobes arg fetch patches are in. Agreed, I'd like to see the argument support afterward. Thanks! -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On Sunday 11 August 2013 20:36:40 Ивайло Димитров wrote:
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v3 1/2] ARM: OMAP: Add secure function
omap_smc3() which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Понеделник, 2013, Август 5 16:29:44 EEST
On Sun, Aug 04, 2013 at 10:45:00AM +0200, Pali Rohár wrote:
Here is new version (v3) of omap secure part patch:
Other secure functions omap_smc1() and omap_smc2() calling
instruction smc #0 but Nokia RX-51 board needs to call
smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h index
0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32
nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32
pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S
b/arch/arm/mach-omap2/omap-smc.S index f6441c1..7bbc043
100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* This program is free software,you can redistribute it
and/or modify * it under the terms of the GNU General
Public License version 2 as
@@ -54,6 +56,23 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32
flag, u32 pargs) + * Low level common routine for secure
HAL and PPA APIs via smc #1 + * r0 - @service_id: Secure
Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of
operation + * r3 - @pargs: Physical address of parameter
list + */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r11, lr}
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb @ Memory Barrier
Can you explain _why_ the barrier is there? The reader
doesn't need to be told that a barrier instruction is a
barrier instruction.
Cheers
---Dave
Hi Dave,
Would quoting Santosh's explanation DSBs were needed on OMAP
for power sequencing. do the job? Something like @ Needed
on OMAP for power sequencing instead of @ Memory Barrier.
I want to be sure I correctly understand your requirement.
Regards,
Ivo
Hello,
I'd like to know what happened with this patch? What is needed
for including it into mainline? Note that without with this patch
series Thumb-2 user space binaries crashing.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
[GIT PULL] pin control changes for v3.12
Hi Linus, here is the bulk of pin control changes for the v3.12 series. Most of the relevant information is in the tag. I merged in v3.11-rc7 last week to get rid of a largeish conflict within the sunxi (AllWinner) driver in linux-next and fix up the non-trivial merge the right way. That driver had a rather large fix adding locking late in the release cycle. Overall the bulk changes this time is cleanups and refactorings and not much new features, which is nice. Please pull it in! Yours, Linus Walleij The following changes since commit d8dfad3876e438b759da3c833d62fb8b2267: Linux 3.11-rc7 (2013-08-25 17:43:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-v3.12-1 for you to fetch changes up to c9e3b2d8f75d84c7b333761471f6cef98ec4429a: pinctrl: sunxi: Fix off-by-one for valid offset range checking (2013-08-30 10:37:36 +0200) Bulk pin control changes for the v3.12 series: - Refactorings for generic pin config handling in the core. - Factor out a set of device tree utilities for use in all drivers, to parse and allocate maps from the device tree. - Some fixes to the core such as more nitpicky locking. - Pushed down config array iteration into the drivers. This patch is necessary for drivers that want to iterate over configs and pile up a stack of alterations to the same register(s), or if the driver wants to take a local spinlock when committing the configuration. - A new driver for the Texas Instruments Palmas PMIC by Laxman Dewangan. This is used on the Tegra systems. - A major cleanup and modernization of the PFC (Super Hitachi and ARM SHmobile) pin controller and subdrivers. - Support for the A20 and A31 sunxi (AllWinner) SoCs. - A huge pile of fixes and cleanups: Axel Lin, Jingoo Han Dan Carpenter, Julia Lawall and Sachin Kamat did an excellent job here. Andy Shevchenko (5): pinctrl-baytrail: fix indentations pinctrl-baytrail: change lvl to level pinctrl-baytrail: remove redundant ptr variable pinctrl-baytrail: introduce to_byt_gpio() macro pinctrl-baytrail: fix to avoid sparse warnings Axel Lin (17): pinctrl: core: Hold pinctrldev_list_mutex mutex while traversing pinctrldev_list pinctrl: core: Hold pctldev-mutex mutex lock while traversing gpio_ranges list Documentation: pinctrl: Fix example code for pinctrl_register pinctrl: core: Remove unnecessary test for desc-name pinctrl: SPEAr310: Pass correct of_device_id table name to MODULE_DEVICE_TABLE pinctrl: rockchip: Simplify for loop iteration pinctrl: core: Add proper mutex lock in pinctrl_request_gpio pinctrl: palmas: PINCTRL_PALMAS needs to select PINMUX pinctrl: rockchip: Remove of_match_ptr macro for DT only driver pinctrl: spear: Convert to devm_ioremap_resource pinctrl: rockchip: Simplify pin_to_bank equation pinctrl: tegra: Convert to devm_ioremap_resource pinctrl: tz1090: Convert to devm_ioremap_resource pinctrl: tz1090-pdc: Convert to devm_ioremap_resource pinctrl: rockchip: Implement .request() and .free() callbacks pinctrl: pinconf-generic: Remove ti prefix in dev_err messages pinctrl: sunxi: Fix off-by-one for valid offset range checking Barry Song (1): pinctrl: sirf: add freeze and restore entries for hibernation support Boris BREZILLON (2): pinctrl: at91: choose appropriate handler for level interrupts pinctrl: at91: fix get_pullup/down function return Dan Carpenter (3): pinctrl: abx500: fix bitwise AND test pinctrl: mvebu: testing the wrong variable pinctrl: s3c24xx: off by one in s3c24xx_eint_init() Fabio Estevam (1): pinctrl: pinctrl-imx: Remove unneeded check for platform_get_resource() Heiko Stübner (1): pinctrl: rockchip: include correct clk header Jingoo Han (3): pinctrl: pinconf: fix comparison of different types pinctrl: sirf: add missing __iomem annotation pinctrl: sh-pfc: remove unnecessary platform_set_drvdata() Jisheng Zhang (1): pinctrl: mvebu: Convert to use devm_ioremap_resource Joe Perches (1): MAINTAINERS: Update sirf patterns John Crispin (1): pinctrl/lantiq: add missing gphy led setup Julia Lawall (1): pinctrl: nomadik: simplify use of devm_ioremap_resource Kunihito Higashiyama (1): sh-pfc: r8a7790: Add MSIOF pin groups and functions Laurent Pinchart (34): sh-pfc: sh7720: Remove unused input_pu range sh-pfc: sh7722: Remove unused input_pd and input_pu ranges sh-pfc: sh7723: Remove unused input_pu range sh-pfc: sh7724: Remove unused input_pu range sh-pfc: sh7757: Remove unused input_pu range sh-pfc: sh7785: Remove unused input_pu range sh-pfc: sh7786: Remove unused input_pu range
Re: [PATCH trivial] UAPI: Kbuild: add/modify comments for uapi/Kbuild and uapi/linux/Kbuild
On 09/04/2013 03:02 PM, Geert Uytterhoeven wrote:
On Wed, Sep 4, 2013 at 3:08 AM, Chen Gang gang.c...@asianux.com wrote:
On 09/04/2013 12:41 AM, Geert Uytterhoeven wrote:
On Tue, Aug 6, 2013 at 3:46 AM, Chen Gang gang.c...@asianux.com wrote:
--- a/include/uapi/Kbuild
+++ b/include/uapi/Kbuild
@@ -1,7 +1,6 @@
# UAPI Header export list
-# Top-level Makefile calls into asm-$(ARCH)
-# List only non-arch directories below
-
+# Except linux/, UAPI means Universal API.
Sorry for my silly question, but what's the purpose of this Universal
API comment?
Firstly, at least for me, I don't think it is a silly question (maybe
it means I should give additional explanations). :-)
I 'guess' the Universal API means:
the API which can be used under multiple OS (independent from Linux), it
may be used under kernel mode or user mode.
It is just my 'guess', welcome additional suggestions or completions by
any members.
When we get this correct additional explanation after discussing, if
suitable, I should add the final explanation to current patch.
Thanks. As this is not related at all to Linux, I don't see a reason
to add this comment.
Here, UAPI means userspace API only.
Hmm... why we need uapi/linux/ ? (I can not find some related
documents, so I have to 'guess').
And in my opinion, most of APIs can be independent from Linux, for in
semantics, most of them are really independent from Linux.
e.g. net protocol, scsi protocol, usb protocol, pci protocol...
So in my opinion (ideal world), the API which is not only used under
Linux (e.g. Windows, MacOS, AIX, HPUX, SPARC ...), recommend to let
them be Universal API.
BTW: if this patch was really applied, it seems most of files under
include/uapi/ would need be improvement.
Thanks.
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
--
Chen Gang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] hwspinlock/omap: add support for dt nodes
Hi Suman, Thanks for the patch. On 09/03/2013 08:52 PM, Suman Anna wrote: HwSpinlock IP is present only on OMAP4 and other newer SoCs, which are all device-tree boot only. This patch adds the base support for parsing the DT nodes, and removes the code dealing with the traditional platform device instantiation. Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++ arch/arm/mach-omap2/Makefile | 3 -- arch/arm/mach-omap2/hwspinlock.c | 60 -- drivers/hwspinlock/omap_hwspinlock.c | 21 ++-- 4 files changed, 45 insertions(+), 67 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt new file mode 100644 index 000..adfb8ad --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt @@ -0,0 +1,28 @@ +OMAP4+ HwSpinlock Driver + +Required properties: +- compatible:Currently supports only ti,omap4-hwspinlock for + OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs +- reg: Contains the hwspinlock register address range (base + address and length) +- ti,hwmods: Name of the hwmod associated with the hwspinlock device + +Optional properties: +- base_id: Base Id for the locks for a particular hwspinlock Could you rename base_id to base-id. The property name convention is to use dashes in DT world. regards, Stan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 deadlock
Hi John,
On 09/03/2013 07:26 PM, John Stultz wrote:
On 09/03/2013 07:57 AM, Gerlando Falauto wrote:
Hi,
I tried again from scratch, so let me recap the whole situation, so we
can all view it from the same standpoint. This should make the problem
easier to see and reproduce.
I can confirm that running a stock 3.10 kernel with HRTICK enabled:
[snip]
makes the following program (and the whole board, as a matter of fact)
hang with no further notice:
[snip]
If I then revert everything up to (and including) the offending commit
(mind the '~'):
$ git log --oneline ...06c017f~ -- kernel/time/timekeeping.c
kernel/time/ntp.c | cut -f1 -d' ' | xargs git revert
The problem disappears.
If I then cherry-pick again the offending commit:
$ git cherry-pick 06c017f; git log -1
commit 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40
Author: John Stultz john.stu...@linaro.org
Date: Fri Mar 22 11:37:28 2013 -0700
timekeeping: Hold timekeepering locks in do_adjtimex and hardpps
[snip]
And as soon as I also cherry-pick (notice there is another commit in
between, which seems not to be relevant on this matter):
$ git cherry-pick a076b2146fabb0894cae5e0189a8ba3f1502d737; git show
commit a076b2146fabb0894cae5e0189a8ba3f1502d737
Author: John Stultz john.stu...@linaro.org
Date: Fri Mar 22 11:52:03 2013 -0700
ntp: Remove ntp_lock, using the timekeeping locks to protect ntp
state
[snip]
I end up in the situation where the system hangs completely and NO
deadlock report whatsoever is output.
So it looks like 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40 introduces
the deadlock, while a076b2146fabb0894cae5e0189a8ba3f1502d737 cares to
hide the report.
Notice how I tested the above on an ARM board; on PowerPC I get
similar results, although I am not able to see the deadlock report
under any circumstances (enabling CONFIG_PROVE_LOCKING, which is the
flag that triggers the deadlock report, causes the kernel to hang at
startup even on a vanilla 3.10 kernel).
John, could you please confirm whether you're at least able to
reproduce it somehow?
Thanks again for the detailed notes. I've so far been unable to
reproduce this, but I'm still looking at it.
Enabling the SCHED_FEAT(HRTICK, true) bit tends to cause lots of issues
on the various hardware I have, tripping the lockdep warnings on various
other issues:
[4.224487] ==
[4.230987] [ INFO: possible circular locking dependency detected ]
[4.237579] 3.9.0-rc2-00148-g06c017f-dirty #8 Not tainted
[4.243255] ---
[4.249847] kworker/0:1H/1329 is trying to acquire lock:
[4.255432] (p-pi_lock){-.-.-.}, at: [c006d184]
try_to_wake_up+0x30/0x3c
[4.263092]
[4.263092] but task is already holding lock:
[4.269226] (rq-lock){-.-.-.}, at: [c0721f18] __schedule+0xb8/0x7d0
[4.276306]
[4.276306] which lock already depends on the new lock.
and
[2.360591] =
[2.363072] [ INFO: possible recursive locking detected ]
[2.364882] 3.9.0-rc2+ #9 Not tainted
[2.365486] -
[2.366345] blkid/999 is trying to acquire lock:
[2.367092] (p-pi_lock){-.-.-.}, at: [810c763c]
try_to_wake_up+0x2c/0x300
[2.367275]
[2.367275] but task is already holding lock:
[2.367275] (p-pi_lock){-.-.-.}, at: [810c763c]
try_to_wake_up+0x2c/0x300
[2.367275]
[2.367275] other info that might help us debug this:
[2.367275] Possible unsafe locking scenario:
[2.367275]
These warnings disable lockdep, so it may just be I'm not getting a
chance to see the warning you describe.
That said, the one system that doesn't throw those lockdep warnings,
doesn't seem to hit your lockdep warning either, and I've not been able
to trigger any hang using the test code you provided.
So by the sounds of it, it is more of an issue with HRTICK than with
your changes...
Just in case there's something else here at play, could you send me your
.config that you're using?
Yes, it's definitely possible that there's something else.
Even though my rate of failure (2 out of 2 boards tested) had me
thinking this problem would have been quite common instead...
Here is my km_kirkwood_defconfig (hope that's the right way to send it):
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_PHYS_OFFSET=0x0
CONFIG_SYSVIPC=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_CGROUPS=y
CONFIG_CGROUP_SCHED=y
CONFIG_NAMESPACES=y
CONFIG_EMBEDDED=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_ARCH_KIRKWOOD=y
CONFIG_MACH_D2NET_V2=y
CONFIG_MACH_DOCKSTAR=y
CONFIG_MACH_ESATA_SHEEVAPLUG=y
CONFIG_MACH_GURUPLUG=y
CONFIG_MACH_INETSPACE_V2=y
CONFIG_MACH_MV88F6281GTW_GE=y
CONFIG_MACH_NET2BIG_V2=y
CONFIG_MACH_NET5BIG_V2=y
CONFIG_MACH_NETSPACE_MAX_V2=y
linux-next: Tree for Sep 4
Hi all, Please do not add any code for v3.13 to your linux-next included branches until after v3.12-rc1 is released. Changes since 20130902: The arm tree still had its build failure. The net-next tree lost its build failure. The tip tree gained s conflict against Linus' tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use git pull to do so as that will try to merge the new linux-next release with the old one. You should use git fetch as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 222 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (a923874 Merge tag 'pci-v3.12-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging fixes/master (fa8218d Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1) Merging arc-current/for-curr (26f8136 Kconfig.debug: Add FRAME_POINTER anti-dependency for ARC) Merging arm-current/fixes (e1f0203 Merge branch 'security-fixes' into fixes) Merging m68k-current/for-linus (5549005 m68k/atari: ARAnyM - Always use physical addresses in NatFeat calls) Merging metag-fixes/fixes (3b2f64d Linux 3.11-rc2) Merging powerpc-merge/merge (d220980 powerpc/hvsi: Increase handshake timeout from 200ms to 400ms.) Merging sparc/master (63d4996 sparc64: Fix off by one in trampoline TLB mapping installation loop.) Merging net/master (a878764 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (302a50b xfrm: Fix potential null pointer dereference in xdst_queue_output) Merging sound-current/for-linus (fb61549 ALSA: opti9xx: Fix conflicting driver object name) Merging pci-current/for-linus (a923874 Merge tag 'pci-v3.12-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging wireless/master (19c3616 ath9k: Enable PLL fix only for AR9340/AR9330) Merging driver-core.current/driver-core-linus (5ae90d8 Linux 3.11-rc3) Merging tty.current/tty-linus (c095ba7 Linux 3.11-rc4) Merging usb.current/usb-linus (d347404 USB: OHCI: fix build error related to ohci_suspend/resume) Merging staging.current/staging-linus (d8dfad3 Linux 3.11-rc7) Merging char-misc.current/char-misc-linus (b36f4be Linux 3.11-rc6) Merging input-current/for-linus (fa46c79 Input: i8042 - disable the driver on ARC platforms) Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' and 'recovery'.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (e70308e Revert crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform framework) Merging ide/master (6d128e1 Revert Makefile: Fix install error with make -j option) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct resource to 0 in of_irq_to_resource()) Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32) Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work without pdata) Merging vfio-fixes/for-linus (d24cdbf vfio-pci: Avoid deadlock on remove) Merging
[PATCH v5.1 10/13] tracing/uprobes: Fetch args before reserving a ring buffer
From: Namhyung Kim namhyung@lge.com
Fetching from user space should be done in a non-atomic context. So
use a per-cpu buffer and copy its content to the ring buffer
atomically. Note that we can migrate during accessing user memory
thus use a per-cpu mutex to protect concurrent accesses.
This is needed since we'll be able to fetch args from an user memory
which can be swapped out. Before that uprobes could fetch args from
registers only which saved in a kernel space.
While at it, use __get_data_size() and store_trace_args() to reduce
code duplication.
Reviewed-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Srikar Dronamraju sri...@linux.vnet.ibm.com
Cc: Oleg Nesterov o...@redhat.com
Cc: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
kernel/trace/trace_uprobe.c | 98 +
1 file changed, 82 insertions(+), 16 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 9f2d12d2311d..c32f8f2ddc11 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -530,21 +530,44 @@ static const struct file_operations uprobe_profile_ops = {
.release= seq_release,
};
+static atomic_t uprobe_buffer_ref = ATOMIC_INIT(0);
+static void __percpu *uprobe_cpu_buffer;
+static DEFINE_PER_CPU(struct mutex, uprobe_cpu_mutex);
+
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;
struct ring_buffer *buffer;
- void *data;
- int size, i;
+ struct mutex *mutex;
+ void *data, *arg_buf;
+ int size, dsize, esize;
+ int cpu;
struct ftrace_event_call *call = tu-p.call;
- size = SIZEOF_TRACE_ENTRY(is_ret_probe(tu));
+ dsize = __get_data_size(tu-p, regs);
+ esize = SIZEOF_TRACE_ENTRY(is_ret_probe(tu));
+
+ if (WARN_ON_ONCE(!uprobe_cpu_buffer || tu-p.size + dsize PAGE_SIZE))
+ return;
+
+ cpu = raw_smp_processor_id();
+ mutex = per_cpu(uprobe_cpu_mutex, cpu);
+ arg_buf = per_cpu_ptr(uprobe_cpu_buffer, cpu);
+
+ /*
+* Use per-cpu buffers for fastest access, but we might migrate
+* so the mutex makes sure we have sole access to it.
+*/
+ mutex_lock(mutex);
+ store_trace_args(esize, tu-p, regs, arg_buf, dsize);
+
+ size = esize + tu-p.size + dsize;
event = trace_current_buffer_lock_reserve(buffer, call-event.type,
- size + tu-p.size, 0, 0);
+ size, 0, 0);
if (!event)
- return;
+ goto out;
entry = ring_buffer_event_data(event);
if (is_ret_probe(tu)) {
@@ -556,13 +579,13 @@ static void uprobe_trace_print(struct trace_uprobe *tu,
data = DATAOF_TRACE_ENTRY(entry, false);
}
- for (i = 0; i tu-p.nr_args; i++) {
- call_fetch(tu-p.args[i].fetch, regs,
- data + tu-p.args[i].offset);
- }
+ memcpy(data, arg_buf, tu-p.size + dsize);
if (!filter_current_check_discard(buffer, call, entry, event))
trace_buffer_unlock_commit(buffer, event, 0, 0);
+
+out:
+ mutex_unlock(mutex);
}
/* uprobe handler */
@@ -630,6 +653,19 @@ probe_event_enable(struct trace_uprobe *tu, int flag,
filter_func_t filter)
if (trace_probe_is_enabled(tu-p))
return -EINTR;
+ if (atomic_inc_return(uprobe_buffer_ref) == 1) {
+ int cpu;
+
+ uprobe_cpu_buffer = __alloc_percpu(PAGE_SIZE, PAGE_SIZE);
+ if (uprobe_cpu_buffer == NULL) {
+ atomic_dec(uprobe_buffer_ref);
+ return -ENOMEM;
+ }
+
+ for_each_possible_cpu(cpu)
+ mutex_init(per_cpu(uprobe_cpu_mutex, cpu));
+ }
+
WARN_ON(!uprobe_filter_is_empty(tu-filter));
tu-p.flags |= flag;
@@ -646,6 +682,11 @@ static void probe_event_disable(struct trace_uprobe *tu,
int flag)
if (!trace_probe_is_enabled(tu-p))
return;
+ if (atomic_dec_and_test(uprobe_buffer_ref)) {
+ free_percpu(uprobe_cpu_buffer);
+ uprobe_cpu_buffer = NULL;
+ }
+
WARN_ON(!uprobe_filter_is_empty(tu-filter));
uprobe_unregister(tu-inode, tu-offset, tu-consumer);
@@ -776,11 +817,33 @@ static void uprobe_perf_print(struct trace_uprobe *tu,
struct ftrace_event_call *call = tu-p.call;
struct uprobe_trace_entry_head *entry;
struct hlist_head *head;
- void *data;
- int size, rctx, i;
+ struct mutex *mutex;
+ void *data, *arg_buf;
+ int size, dsize,
Re: [patch 0/7] improve memcg oom killer robustness v2
CC: Andrew Morton a...@linux-foundation.org, Michal Hocko mho...@suse.cz, David Rientjes rient...@google.com, KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com, KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com, linux...@kvack.org, cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, linux-kernel@vger.kernel.org Hello azur, On Mon, Sep 02, 2013 at 12:38:02PM +0200, azurIt wrote: Hi azur, here is the x86-only rollup of the series for 3.2. Thanks! Johannes --- Johannes, unfortunately, one problem arises: I have (again) cgroup which cannot be deleted :( it's a user who had very high memory usage and was reaching his limit very often. Do you need any info which i can gather now? Did the OOM killer go off in this group? Was there a warning in the syslog (Fixing unhandled memcg OOM context)? Ok, i see this message several times in my syslog logs, one of them is also for this unremovable cgroup (but maybe all of them cannot be removed, should i try?). Example of the log is here (don't know where exactly it starts and ends so here is the full kernel log): http://watchdog.sk/lkml/oom_syslog.gz azur -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] UBI: fix refill_wl_user_pool()
Am 26.08.2013 12:08, schrieb Richard Weinberger:
If no free PEBs are available refill_wl_user_pool() must not
return with -ENOSPC immediately.
It has to block till produce_free_peb() produced a free PEB.
Reported-and-Tested-by: Richard Genoud richard.gen...@gmail.com
Signed-off-by: Richard Weinberger rich...@nod.at
---
drivers/mtd/ubi/wl.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index c95bfb1..02317c1 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -599,10 +599,6 @@ static void refill_wl_user_pool(struct ubi_device *ubi)
return_unused_pool_pebs(ubi, pool);
for (pool-size = 0; pool-size pool-max_size; pool-size++) {
- if (!ubi-free.rb_node ||
-(ubi-free_count - ubi-beb_rsvd_pebs 1))
- break;
-
pool-pebs[pool-size] = __wl_get_peb(ubi);
if (pool-pebs[pool-size] 0)
break;
Artem, please don't forget do apply this patch.
Thanks,
//richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] kconfig: do not special-case 'MODULES' symbol
Dne 3.9.2013 23:12, Yann E. MORIN napsal(a): Doh... I forgot to send an intro mail first. Seems holidays really were a good break! :-) :-) Anyway, this series might be a bit late to go in for 3.12, but it has previously been discussed with you and Sam. If you feel it's too touchy for 3.12, then I believe it can easily wait for 3.13. If you want it for 3.12, I can send a pull-request if that's easier for you. Please send me a pull request regardless, so that the second commit's changelog references the right commit id. I'll play with this and will merge it into kbuild.git if there are no problems. It's two days into the merge window, so no big deal (shh!). Michal -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: Re: [RFC PATCH 0/2] Perf support to SDT markers
(2013/09/04 15:49), Namhyung Kim wrote: On Tue, 03 Sep 2013 18:53:17 +0530, Hemant wrote: On 09/03/2013 02:47 PM, Masami Hiramatsu wrote: (2013/09/03 17:25), Ingo Molnar wrote: * Hemant Kumar Shaw hks...@linux.vnet.ibm.com wrote: This series adds support to perf to list and probe into the SDT markers. The first patch implements listing of all the SDT markers present in the ELFs (executables or libraries). The SDT markers are present in the .note.stapsdt section of the elf. That section can be traversed to list all the markers. Recognition of markers follows the SystemTap approach. The second patch will allow perf to probe into these markers. This is done by writing the marker name and its offset into the uprobe_events file in the tracing directory. Then, perf tools can be used to analyze perf.data file. Please provide a better high level description that explains the history and scope of SDT markers, how SDT markers get into binaries, how they can be used for probing, a real-life usage example that shows something interesting not possible via other ways, etc. Indeed, and also I'd like to know what versions of SDT this support, and where we can see the technical document of that. As far as I know, the previous(?) SDT implementation also involves ugly semaphores. Have that already gone? It seems it's not. I see the SDT v3 document still mentions semaphores. Uh, how the current implementation can avoid those semaphores? (It seems that this patch doesn't mention it.) I had discussed that the semaphore problem 3 years ago with systemtap guys, it should be there to keep the main process away from heavy argument processing when the marker is disabled, especially for python vm. If those are still there, we can't enable markers without tweaking the semaphore by using systemtap or a debugger. This link shows an example of marker probing with Systemtap: https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps I think the link below would be more helpful for us :) http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation Thank you :) -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 09/35] mm: Track the freepage migratetype of pages accurately
(2013/09/03 17:45), Srivatsa S. Bhat wrote:
On 09/03/2013 12:08 PM, Yasuaki Ishimatsu wrote:
(2013/08/30 22:16), Srivatsa S. Bhat wrote:
Due to the region-wise ordering of the pages in the buddy allocator's
free lists, whenever we want to delete a free pageblock from a free list
(for ex: when moving blocks of pages from one list to the other), we need
to be able to tell the buddy allocator exactly which migratetype it
belongs
to. For that purpose, we can use the page's freepage migratetype
(which is
maintained in the page's -index field).
So, while splitting up higher order pages into smaller ones as part of
buddy
operations, keep the new head pages updated with the correct freepage
migratetype information (because we depend on tracking this info
accurately,
as outlined above).
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
mm/page_alloc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 398b62c..b4b1275 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -947,6 +947,13 @@ static inline void expand(struct zone *zone,
struct page *page,
add_to_freelist(page[size], area-free_list[migratetype]);
area-nr_free++;
set_page_order(page[size], high);
+
+/*
+ * Freepage migratetype is tracked using the index field of the
+ * first page of the block. So we need to update the new first
+ * page, when changing the page order.
+ */
+set_freepage_migratetype(page[size], migratetype);
}
}
It this patch a bug fix patch?
If so, I want you to split the patch from the patch-set.
No, its not a bug-fix. We need to take care of this only when using the
sorted-buddy design to maintain the freelists, which is introduced only in
this patchset. So mainline doesn't need this patch.
In mainline, we can delete a page from a buddy freelist by simply calling
list_del() by passing a pointer to page-lru. It doesn't matter which freelist
the page was belonging to. However, in the sorted-buddy design introduced
in this patchset, we also need to know which particular freelist we are
deleting that page from, because apart from breaking the -lru link from
the linked-list, we also need to update certain other things such as the
region-page_block pointer etc, which are part of that particular freelist.
Thus, it becomes essential to know which freelist we are deleting the page
from. And for that, we need this patch to maintain that information accurately
even during buddy operations such as splitting buddy pages in expand().
I may be wrong because I do not know this part clearly.
Original code is here:
---
static inline void expand(struct zone *zone, struct page *page,
int low, int high, struct free_area *area,
int migratetype)
{
...
list_add(page[size].lru, area-free_list[migratetype]);
area-nr_free++;
set_page_order(page[size], high);
---
It seems that migratietype of page[size] page is changed. So even if not
applying your patch, I think migratetype of the page should be changed.
thanks,
Yasuaki Ishimatsu
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 00/16] slab: overload struct slab over struct page to reduce memory usage
On Wed, Sep 04, 2013 at 11:38:04AM +0800, Wanpeng Li wrote: Hi Joonsoo, On Fri, Aug 23, 2013 at 03:35:39PM +0900, Joonsoo Kim wrote: On Thu, Aug 22, 2013 at 04:47:25PM +, Christoph Lameter wrote: On Thu, 22 Aug 2013, Joonsoo Kim wrote: [...] struct slab's free = END kmem_bufctl_t array: ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE we get object at index 0 Is there a real item for END in kmem_bufctl_t array as you mentioned above? I think the kmem_bufctl_t array doesn't include that and the last step is not present. Yes, there is. BUFCTL_END is what I told for END. A slab is initialized in cache_init_objs() and a last step in that function is to set last entry of a free array of a slab to BUFCTL_END. This value remains in the whole life cycle of a slab. 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: [RFC PATCH 0/2] Perf support to SDT markers
On Wed, 2013-09-04 at 15:49 +0900, Namhyung Kim wrote: On Tue, 03 Sep 2013 18:53:17 +0530, Hemant wrote: On 09/03/2013 02:47 PM, Masami Hiramatsu wrote: Indeed, and also I'd like to know what versions of SDT this support, and where we can see the technical document of that. As far as I know, the previous(?) SDT implementation also involves ugly semaphores. Have that already gone? It seems it's not. I see the SDT v3 document still mentions semaphores. It mentions them, but should normally not be used. They are there for dtrace (source) compatibility. And you don't have to use them. Since normally a SDT probe marker is just a NOP it doesn't have any overhead. But if you want to add complicated arguments that you would normally not generate in your code, then you might want to add a semaphore. That way you can have probes with a bit more overhead that still have zero overhead when not being probed. Note that if you use the normal DTRACE_PROBE macros no semaphore will be inserted. And you can opt to not support probes that have a semaphore in perf if you think that is easier (just check the semaphore link-time address for the probe, it should normally be zero). Just warn: No way I am going to probe something that might have a little extra overhead! I am no debugger... :) This link shows an example of marker probing with Systemtap: https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps I think the link below would be more helpful for us :) http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation Yes, that should be the canonical description. Cheers, Mark -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/4] slab: implement byte sized indexes for the freelist of a slab
On Wed, Sep 04, 2013 at 10:17:46AM +0800, Wanpeng Li wrote: Hi Joonsoo, On Mon, Sep 02, 2013 at 05:38:54PM +0900, Joonsoo Kim wrote: This patchset implements byte sized indexes for the freelist of a slab. Currently, the freelist of a slab consist of unsigned int sized indexes. Most of slabs have less number of objects than 256, so much space is wasted. To reduce this overhead, this patchset implements byte sized indexes for the freelist of a slab. With it, we can save 3 bytes for each objects. This introduce one likely branch to functions used for setting/getting objects to/from the freelist, but we may get more benefits from this change. Below is some numbers of 'cat /proc/slabinfo' related to my previous posting and this patchset. * Before * # nameactive_objs num_objs objsize objperslab pagesperslab : tunables [snip...] kmalloc-512 52564051281 : tunables 54 270 : slabdata 80 80 0 kmalloc-256 210210256 151 : tunables 120 600 : slabdata 14 14 0 kmalloc-192 1016 1040192 201 : tunables 120 600 : slabdata 52 52 0 kmalloc-96 560620128 311 : tunables 120 600 : slabdata 20 20 0 kmalloc-64 2148 2280 64 601 : tunables 120 600 : slabdata 38 38 0 kmalloc-128 647682128 311 : tunables 120 600 : slabdata 22 22 0 kmalloc-32 11360 11413 32 1131 : tunables 120 600 : slabdata101101 0 kmem_cache 197200192 201 : tunables 120 600 : slabdata 10 10 0 * After my previous posting(overload struct slab over struct page) * # nameactive_objs num_objs objsize objperslab pagesperslab : tunables [snip...] kmalloc-512 52760051281 : tunables 54 270 : slabdata 75 75 0 kmalloc-256 210210256 151 : tunables 120 600 : slabdata 14 14 0 kmalloc-192 1040 1040192 201 : tunables 120 600 : slabdata 52 52 0 kmalloc-96 750750128 301 : tunables 120 600 : slabdata 25 25 0 kmalloc-64 2773 2773 64 591 : tunables 120 600 : slabdata 47 47 0 kmalloc-128 660690128 301 : tunables 120 600 : slabdata 23 23 0 kmalloc-32 11200 11200 32 1121 : tunables 120 600 : slabdata100100 0 kmem_cache 197200192 201 : tunables 120 600 : slabdata 10 10 0 kmem_caches consisting of objects less than or equal to 128 byte have one more objects in a slab. You can see it at objperslab. I think there is one less objects in a slab after observing objperslab. Yes :) I did a mistake when I attached the data about this patchset. The results of *Before* and *After* should be exchanged. Thanks for pointing out that. 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] clocksource: em_sti: Set cpu_possible_mask to fix SMP broadcast
On Wed, Sep 04, 2013 at 05:01:51PM +0900, Magnus Damm wrote: From: Magnus Damm d...@opensource.se Update the STI driver by setting cpu_possible_mask to make EMEV2 SMP work as expected together with the ARM broadcast timer. This breakage was introduced by: f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event Without this fix SMP operation is broken on EMEV2 since no broadcast timer interrupts trigger on the secondary CPU cores. Signed-off-by: Magnus Damm d...@opensource.se --- Thanks to feedback from Stephen Boyd this is is a reworked version of: [PATCH] clocksource: em_sti: Adjust clock event rating to fix SMP broadcast drivers/clocksource/em_sti.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Simon Horman horms+rene...@verge.net.au I will let this sit for a few days to see if there is any further feedback. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/4] slab: implement byte sized indexes for the freelist of a slab
On Tue, Sep 03, 2013 at 02:15:42PM +, Christoph Lameter wrote: On Mon, 2 Sep 2013, Joonsoo Kim wrote: This patchset implements byte sized indexes for the freelist of a slab. Currently, the freelist of a slab consist of unsigned int sized indexes. Most of slabs have less number of objects than 256, so much space is wasted. To reduce this overhead, this patchset implements byte sized indexes for the freelist of a slab. With it, we can save 3 bytes for each objects. This introduce one likely branch to functions used for setting/getting objects to/from the freelist, but we may get more benefits from this change. Below is some numbers of 'cat /proc/slabinfo' related to my previous posting and this patchset. You may also want to run some performance tests. The cache footprint should also be reduced with this patchset and therefore performance should be better. Yes, I did a hackbench test today, but I'm not ready for posting it. The performance is improved for my previous posting and futher improvement is founded by this patchset. Perhaps I will post it tomorrow. 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 01/24] perf tools: Fix 'make install prefix=...' build rule
Hi Jiri, On Sun, 1 Sep 2013 12:48:26 +0200, Jiri Olsa wrote: Currently we fail for following make command: $ sudo make install prefix=/opt/perf ... GEN python/perf.so install -d -m 755 '/opt/perf/bin' install perf '/opt/perf/bin' install perf-archive -t '/opt/perf/libexec/perf-core' install: accessing `/opt/perf/libexec/perf-core': No such file or directory make: *** [install-bin] Error 1 Fixing this by properly creating '/opt/perf/libexec/perf-core' directory. Acked-by: Namhyung Kim namhy...@kernel.org Thanks, Namhyung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] gpio: interrupt consistency check for OF GPIO IRQs
On Wednesday 04 September 2013 11:29:47, Stephen Warren wrote: On 09/03/2013 06:35 AM, Linus Walleij wrote: On Fri, Aug 30, 2013 at 9:53 PM, Stephen Warren swar...@wwwdotorg.org wrote: I still haven't seen an answer to why we really care about this; how many times has code actually allocated the same GPIO/IRQ when it shouldn't, in a way that it wasn't detectable by some other mechanism, i.e. the feature just not working? Why are we even trying to solve this issue? I'm not totally convinced it even makes sense to try and solve it. We care about this because a number of OMAP boards are not working properly when booted from device tree, and they have a hard time figuring out a solution to the problem. Last try exploded. Now they are looking to create a patch that will fix the actual problem. Is something missing from /proc/interrupts or /sys/kernel/debug/gpios? If so, let's just add it. That would require procfs to be mounted to /proc and even CONFIG_PROC_FS to be compiled in. Drivers have to work without that requirement. That would require CONFIG_DEBUG_FS to be set, right? Drivers have to work without 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 02/24] perf tools: Remove unused trace-event-* code
On Sun, 1 Sep 2013 12:48:27 +0200, Jiri Olsa wrote: Removing unused trace-event-* code. Acked-by: Namhyung Kim namhy...@kernel.org Thanks, Namhyung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] clocksource: em_sti: Set cpu_possible_mask to fix SMP broadcast
[ Droped johnstu...@linaro.org CC, the address seems to bounce Added Daniel Lezcano CC, I believe he handles clocksource these days ] On Wed, Sep 04, 2013 at 05:01:51PM +0900, Magnus Damm wrote: From: Magnus Damm d...@opensource.se Update the STI driver by setting cpu_possible_mask to make EMEV2 SMP work as expected together with the ARM broadcast timer. This breakage was introduced by: f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event Without this fix SMP operation is broken on EMEV2 since no broadcast timer interrupts trigger on the secondary CPU cores. Signed-off-by: Magnus Damm d...@opensource.se Tested-by: Simon Horman horms+rene...@verge.net.au I will let this sit for a few days to see if there is any further feedback. --- Thanks to feedback from Stephen Boyd this is is a reworked version of: [PATCH] clocksource: em_sti: Adjust clock event rating to fix SMP broadcast drivers/clocksource/em_sti.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 0001/drivers/clocksource/em_sti.c +++ work/drivers/clocksource/em_sti.c 2013-09-04 16:51:42.0 +0900 @@ -301,7 +301,7 @@ static void em_sti_register_clockevent(s ced-name = dev_name(p-pdev-dev); ced-features = CLOCK_EVT_FEAT_ONESHOT; ced-rating = 200; - ced-cpumask = cpumask_of(0); + ced-cpumask = cpu_possible_mask; ced-set_next_event = em_sti_clock_event_next; ced-set_mode = em_sti_clock_event_mode; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/24] perf tools: Unify page_size usage
On Sun, 1 Sep 2013 12:48:28 +0200, Jiri Olsa wrote: Making page_size global from the util object. Removing the not needed one. Acked-by: Namhyung Kim namhy...@kernel.org Thanks, Namhyung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: Acceptance of proprietary kernel modules
On 08/30/2013 09:35:18 AM, Richard Weinberger wrote: Hi, over the last months I've reviewed lot's of Linux based products, mostly networking related devices like firewalls, WiFi access points, DSL routers, IPMI, etc... The vast majority of them had proprietary kernel modules loaded. I'm not talking about single self contained device drivers. In the wild you'll find whole kernel subsystems such as complete firewalling stacks, deep packet inspection, IPsec implementations, anti virus scanners, network introduction detection systems (yes, in kernel!), protocol implementations like MPLS, in-kernel VNC servers, and so on as proprietary kernel modules. Of course, all of them use EXPORT_SYMBOL() symbols only, but nobody can tell me that these modules are self contained and not a derived work of the kernel. One vendor even applied a patch on the kernel which did a s/EXPORT_SYMBOL_GPL/ EXPORT_SYMBOL/g on a few files, but that's a different story. Reading the disassembly of said modules showed that most of them are clearly designed to run only on Linux. (e.g. every single function references a random Linux kernel symbol). It's not like NVIDIA's GPU driver which clearly is designed to work on many operating systems and Linux is one of that. I have the feeling that such doubtful modules are no longer isolated cases, they are the common case. This leads me to one question. Have we reached a state where proprietary kernel modules are just accepted and nobody cares? I don't speak for the linux kernel, but: 1) I started the first GPL enforcement suits on behalf of the busybox project (both through the SFLC and another suit in europe suit along with gpl-violations.org and FSF europe against some french company), and I spent over a year pursuing them, resulting in exactly zero lines of code being added to busybox from any of the companies we sued. 2) I'm giving a talk about the rise and fall of the copyleft at Ohio LinuxFest later this month. (We have a greying of fandom problem where almost nobody under 30 really seems to care about copyleft, and the most common license on github is no license specified.) 3) I touched on this topic in my ELC talk in February, maybe 5 minutes starting at: http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=15m09s (Google broke youtube's time link syntax recently, but that's 15 minutes and 9 seconds into the talk. You'll probably have to advance by hand.) The short version is: people who aren't in a position to do anything about it care very deeply in a fairly useless way. People with nontrivial standing are too busy with programming to spend time on lawsuits, pretty much by definition. After 20 years, don't expect sudden change unless somebody retires from programming to file lawsuits instead, and when they do expect them to burn out after about a year or two with nothing to show for it except maybe some money. Sometimes care in a deep but useless way and too busy to do anything about it overlaps. Greg KH declared kernel modules flatly illegal in 2006: http://www.kroah.com/log/linux/ols_2006_keynote.html And you can see how many suits he's filed over the past 8 years to enforce that view... What I found out experimentally is that when you _do_ pursue this stuff, the actual pragmatic payoff to the project, in engineering terms, is exactly zero. Think about the fact that the guy who wrote Squashfs spent seven years trying to get the code in, had it in every major distro but not vanilla, and still had to take a YEAR off from work to volunteer full time to finally get it merged into Linus's tree. (And yet somehow, he still didn't qualify for the recent call for hobbyists at the private invitation-only kernel summit.) He wrote about that here: https://lwn.net/Articles/563578/ Think about Android too: an enormous chunk of divergent crap with source dropped along with each release, which spent years outside the kernel before the kernel guys even figured out what they wanted to _do_ with it, and then they wound up rewriting most of it along different design lines, and _still_ dealing with the backlog. (Android was fully in compliance with the GPL every step of the way, even provided source repositories with history rather than one big tarball, guess what to diff this against. And yet...) If that's what it takes to get large chunks of widely used code upstream, with the active participation of the people who wrote it, the likelihood of any of the code you're talking about ever going into vanilla if it _was_ released (let alone as the result of a lawsuit) is essentially zero. And the companies behind it know it. And the kernel guys know it too. There's some posturing and chest beating, but a couple decades of precedent have made that pretty widely ignored, as you've noticed. What the kernel being GPL really meant that Apple, Sun, Oracle, and IBM couldn't
Re: Re: [RFC PATCH 0/2] Perf support to SDT markers
(2013/09/04 17:25), Mark Wielaard wrote: On Wed, 2013-09-04 at 15:49 +0900, Namhyung Kim wrote: On Tue, 03 Sep 2013 18:53:17 +0530, Hemant wrote: On 09/03/2013 02:47 PM, Masami Hiramatsu wrote: Indeed, and also I'd like to know what versions of SDT this support, and where we can see the technical document of that. As far as I know, the previous(?) SDT implementation also involves ugly semaphores. Have that already gone? It seems it's not. I see the SDT v3 document still mentions semaphores. It mentions them, but should normally not be used. They are there for dtrace (source) compatibility. And you don't have to use them. Since normally a SDT probe marker is just a NOP it doesn't have any overhead. But if you want to add complicated arguments that you would normally not generate in your code, then you might want to add a semaphore. That way you can have probes with a bit more overhead that still have zero overhead when not being probed. Note that if you use the normal DTRACE_PROBE macros no semaphore will be inserted. And you can opt to not support probes that have a semaphore in perf if you think that is easier (just check the semaphore link-time address for the probe, it should normally be zero). Just warn: No way I am going to probe something that might have a little extra overhead! I am no debugger... :) OK, I see. And in that case, we'd better filter out the markers which use a semaphore when list it up, since we can not enable it. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] Documentation/kvm: Update cpuid documentation for steal time and pv eoi
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com --- Changes in V2: Correction in the description of steal time and added msr info (Michael S Tsirkin) Documentation/virtual/kvm/cpuid.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 22ff659..6c4fb20 100644 --- a/Documentation/virtual/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt @@ -43,6 +43,16 @@ KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock available at msrs KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by || || writing to msr 0x4b564d02 -- +KVM_FEATURE_STEAL_TIME || 5 || Steal time available at msr + || || 0x4b564d03. The feature is enabled + || || by guest when host has schedstat + || || or task delay accounting support. +-- +KVM_FEATURE_PV_EOI || 6 || overrides the generic EOI + || || implementation with a + || || paravirtualized version. Available + || || at msr 0x4b564d04. +-- KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit || || before enabling paravirtualized || || spinlock support. -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clocksource: em_sti: Set cpu_possible_mask to fix SMP broadcast
On 09/04/2013 10:37 AM, Simon Horman wrote: [ Droped johnstu...@linaro.org CC, the address seems to bounce The address is john.stu...@linaro.org Added Daniel Lezcano CC, I believe he handles clocksource these days ] Right. On Wed, Sep 04, 2013 at 05:01:51PM +0900, Magnus Damm wrote: From: Magnus Damm d...@opensource.se Update the STI driver by setting cpu_possible_mask to make EMEV2 SMP work as expected together with the ARM broadcast timer. This breakage was introduced by: f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event Without this fix SMP operation is broken on EMEV2 since no broadcast timer interrupts trigger on the secondary CPU cores. Signed-off-by: Magnus Damm d...@opensource.se Tested-by: Simon Horman horms+rene...@verge.net.au I will let this sit for a few days to see if there is any further feedback. --- Thanks to feedback from Stephen Boyd this is is a reworked version of: [PATCH] clocksource: em_sti: Adjust clock event rating to fix SMP broadcast drivers/clocksource/em_sti.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 0001/drivers/clocksource/em_sti.c +++ work/drivers/clocksource/em_sti.c2013-09-04 16:51:42.0 +0900 @@ -301,7 +301,7 @@ static void em_sti_register_clockevent(s ced-name = dev_name(p-pdev-dev); ced-features = CLOCK_EVT_FEAT_ONESHOT; ced-rating = 200; -ced-cpumask = cpumask_of(0); +ced-cpumask = cpu_possible_mask; ced-set_next_event = em_sti_clock_event_next; ced-set_mode = em_sti_clock_event_mode; -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 19/20] mm, hugetlb: retry if failed to allocate and there is concurrent user
On Fri, Aug 09, 2013 at 06:26:37PM +0900, Joonsoo Kim wrote: If parallel fault occur, we can fail to allocate a hugepage, because many threads dequeue a hugepage to handle a fault of same address. This makes reserved pool shortage just for a little while and this cause faulting thread who can get hugepages to get a SIGBUS signal. To solve this problem, we already have a nice solution, that is, a hugetlb_instantiation_mutex. This blocks other threads to dive into a fault handler. This solve the problem clearly, but it introduce performance degradation, because it serialize all fault handling. Now, I try to remove a hugetlb_instantiation_mutex to get rid of performance degradation. For achieving it, at first, we should ensure that no one get a SIGBUS if there are enough hugepages. For this purpose, if we fail to allocate a new hugepage when there is concurrent user, we return just 0, instead of VM_FAULT_SIGBUS. With this, these threads defer to get a SIGBUS signal until there is no concurrent user, and so, we can ensure that no one get a SIGBUS if there are enough hugepages. Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com Hello, David. May I ask to you to review this one? I guess that you already thought about the various race condition, so I think that you are the most appropriate reviewer to this patch. :) Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Resend: [PATCH 2/2] s390: provide hardware randomness from zcrypt card to /dev/random
[Checkpatch'ed, IBM folks Cc'ed]
Running completely virtualised, system Z severely lacks good true random
sources.
Gathering entropy in a virtual environment is difficult. To compensate, there is
specialised crypto hardware which includes a source for hardware randomness;
the zcrypt driver is able to access this random source. This patch adds a kernel
thread that feeds the random bits via the interface created with the previous
patch.
Signed-off-by: Torsten Duwe d...@lst.de
---
zcrypt_api.c | 51 +++
1 file changed, 51 insertions(+)
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -38,6 +38,8 @@
#include linux/atomic.h
#include asm/uaccess.h
#include linux/hw_random.h
+#include linux/kthread.h
+#include linux/delay.h
#include linux/debugfs.h
#include asm/debug.h
@@ -99,6 +99,13 @@ static ssize_t zcrypt_online_store(struc
if (sscanf(buf, %d\n, online) != 1 || online 0 || online 1)
return -EINVAL;
+ if (zdev-ops-rng) {
+ if (zdev-online == 0 online == 1)
+ zcrypt_rng_device_add();
+ if (zdev-online == 1 online == 0)
+ zcrypt_rng_device_remove();
+
+ }
zdev-online = online;
ZCRYPT_DBF_DEV(DBF_INFO, zdev, dev%04xo%dman, zdev-ap_dev-qid,
zdev-online);
@@ -1117,6 +1119,7 @@ static int zcrypt_rng_device_count;
static u32 *zcrypt_rng_buffer;
static int zcrypt_rng_buffer_index;
static DEFINE_MUTEX(zcrypt_rng_mutex);
+static struct task_struct *zcrypt_hwrng_fill;
static int zcrypt_rng_data_read(struct hwrng *rng, u32 *data)
{
@@ -1141,6 +1144,36 @@ static struct hwrng zcrypt_rng_dev = {
.data_read = zcrypt_rng_data_read,
};
+static int zcrypt_hwrng_fillfn(void *unused)
+{
+ long rc;
+
+ while (!kthread_should_stop()) {
+ rc = zcrypt_rng((char *)zcrypt_rng_buffer);
+ if (rc == -ENODEV || rc == -EINVAL || rc == -ENOMEM) {
+ pr_err(zcrypt_rng unavailable: %ld, rc);
+ break;
+ }
+ if (rc == -EAGAIN || rc == -ERESTARTSYS) {
+ pr_info(zcrypt_rng interrupted: %ld, rc);
+ msleep_interruptible(1000);
+ continue;
+ }
+ if (rc == 0) {
+ pr_err(zcrypt_rng: no data available);
+ msleep_interruptible(1);
+ continue;
+ }
+ if (rc 0) {
+ pr_err(zcrypt_rng unknown error: %ld, rc);
+ break;
+ }
+ add_hwgenerator_randomness((void *)zcrypt_rng_buffer, rc);
+ }
+ zcrypt_hwrng_fill = 0;
+ return 0;
+}
+
static int zcrypt_rng_device_add(void)
{
int rc = 0;
@@ -1157,6 +1189,12 @@ static int zcrypt_rng_device_add(void)
if (rc)
goto out_free;
zcrypt_rng_device_count = 1;
+ zcrypt_hwrng_fill = kthread_run(zcrypt_hwrng_fillfn,
+ NULL, zc_hwrng);
+ if (zcrypt_hwrng_fill == ERR_PTR(-ENOMEM)) {
+ pr_err(zcrypt_hwrng_fill thread creation failed);
+ zcrypt_hwrng_fill = 0;
+ }
} else
zcrypt_rng_device_count++;
mutex_unlock(zcrypt_rng_mutex);
@@ -1174,6 +1211,10 @@ static void zcrypt_rng_device_remove(voi
mutex_lock(zcrypt_rng_mutex);
zcrypt_rng_device_count--;
if (zcrypt_rng_device_count == 0) {
+ if (zcrypt_hwrng_fill) {
+ kthread_stop(zcrypt_hwrng_fill);
+ zcrypt_hwrng_fill = 0;
+ }
hwrng_unregister(zcrypt_rng_dev);
free_page((unsigned long) zcrypt_rng_buffer);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] HID: Correct the USB IDs for the new Macbook Air 6
On Tue, 3 Sep 2013, Dmitry Torokhov wrote: A recent patch (9d9a04ee) added support for the new machine, but got the sequence of USB ids wrong. Reports from both Ian and Linus T show that the 0x0291 id is for ISO, not ANSI, which should have the missing number 0x0290. This patchs moves the three numbers accordingly, fixing the problem. Cc: Dmitry Torokhov dmitry.torok...@gmail.com Reported-and-tested-by: Ian Munsie darkstarsw...@gmail.com Tested-by: Linus G Thiel li...@hanssonlarsson.se Signed-off-by: Henrik Rydberg rydb...@euromail.se --- Hi Jiri, Dmitry, it looks like this change has been sufficiently tested now, in addition to making perfect sense. Jiri, would you mind taking it, if Dmitry approves? Absolutely ... waiting for Dmitry's Ack. And here it is: Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com Perfect, thanks. Will push it to Linus this merge window. -- Jiri Kosina 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] pps : add non blocking option to PPS_FETCH ioctl.
Signed-off-by: Paul Chavent paul.chav...@onera.fr
---
drivers/pps/pps.c | 57 +--
1 file changed, 30 insertions(+), 27 deletions(-)
diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 7173e3a..86ff57e 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -152,35 +152,38 @@ static long pps_cdev_ioctl(struct file *file,
if (err)
return -EFAULT;
- ev = pps-last_ev;
-
- /* Manage the timeout */
- if (fdata.timeout.flags PPS_TIME_INVALID)
- err = wait_event_interruptible(pps-queue,
- ev != pps-last_ev);
- else {
- unsigned long ticks;
-
- dev_dbg(pps-dev, timeout %lld.%09d\n,
- (long long) fdata.timeout.sec,
- fdata.timeout.nsec);
- ticks = fdata.timeout.sec * HZ;
- ticks += fdata.timeout.nsec / (NSEC_PER_SEC / HZ);
-
- if (ticks != 0) {
- err = wait_event_interruptible_timeout(
- pps-queue,
- ev != pps-last_ev,
- ticks);
- if (err == 0)
- return -ETIMEDOUT;
+ if (!(file-f_flags O_NONBLOCK)) {
+ ev = pps-last_ev;
+
+ /* Manage the timeout */
+ if (fdata.timeout.flags PPS_TIME_INVALID)
+ err = wait_event_interruptible(pps-queue,
+ ev != pps-last_ev);
+ else {
+ unsigned long ticks;
+
+ dev_dbg(pps-dev, timeout %lld.%09d\n,
+ (long long) fdata.timeout.sec,
+ fdata.timeout.nsec);
+ ticks = fdata.timeout.sec * HZ;
+ ticks += fdata.timeout.nsec /
+ (NSEC_PER_SEC / HZ);
+
+ if (ticks != 0) {
+ err = wait_event_interruptible_timeout(
+ pps-queue,
+ ev != pps-last_ev,
+ ticks);
+ if (err == 0)
+ return -ETIMEDOUT;
+ }
}
- }
- /* Check for pending signals */
- if (err == -ERESTARTSYS) {
- dev_dbg(pps-dev, pending signal caught\n);
- return -EINTR;
+ /* Check for pending signals */
+ if (err == -ERESTARTSYS) {
+ dev_dbg(pps-dev, pending signal caught\n);
+ return -EINTR;
+ }
}
/* Return the fetched timestamp */
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/7] DMA: shdma: switch DT to use OF device ID tables
On Thu, Aug 29, 2013 at 01:24:31PM +0200, Guennadi Liakhovetski wrote: Hi Simon, On Mon, 26 Aug 2013, Simon Horman wrote: On Sun, Aug 25, 2013 at 01:06:57PM +0530, Vinod Koul wrote: On Fri, Aug 02, 2013 at 04:50:35PM +0200, Guennadi Liakhovetski wrote: In this version of shdma Device Tree support I preserved the DT configuration approach via OF device ID tables from v4, but now it is only used for the DT-mode, the C-version is left untouched. In this series I only include one platform: r8a73a4-based APE6EVM, if accepted, others can be added easily. I also took care not to include mach/*.h headers in driver .c files. To illustrate the use of DT DMA support for MMC DMA on APE6EVM a patch from a previously separate patch series DMA for MMCIF and SDHI devices in DT mode I have applied all the dma patches, the ARM ones fail for me so should possible go thru ARM tree. Guennadi, if you need me to queue up any patches please repost them once their dependencies are available in a stable branch. I've just verified, that the current -next has all DMA and MMCIF prerequisites for the following my patches: ARM: shmobile: armadillo800eva-reference: add MMCIF and SDHI DT nodes ARM: shmobile: r8a73a4: add a DMAC platform device and clock for it ARM: shmobile: r8a73a4: add a DT node and a clock alias for the DMAC ARM: shmobile: ape6evm-reference: enable DMA for the MMC interface ARM: shmobile: ape6evm: disable MMCIF Command Completion Signal ARM: shmobile: ape6evm: add DMA support to MMCIF ARM: shmobile: armadillo800eva: disable MMCIF Command Completion Signal ARM: shmobile: kzm9g: disable MMCIF Command Completion Signal ARM: shmobile: lager: disable MMCIF Command Completion Signal, add CLK_CTRL2 I can re-send them all to your privetly as an archive, if you like, or you can pick their latest versions from an archive or from patchwork. Thanks, I can pick them out of patchwork. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 v11 0/8] PHY framework
On Tuesday 03 September 2013 09:20 PM, Greg KH wrote: On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: Hi Greg, On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: Hi, On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing Looks like there are not further comments on this series. Can you take this in your misc tree? Do you want me to queue these for you ? There are quite a few users for this framework already and I know of at least 2 others which will show up for v3.13. Can you queue this patch series? There are quite a few users already for this framework. It will have to wait for 3.13 as the merge window for new features has been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 is out. Alright, thanks. -Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] mm/vmscan : use vmcan_swappiness( ) basing on MEMCG config to elimiate unnecessary runtime cost
On Wed, Sep 4, 2013 at 6:47 AM, Johannes Weiner han...@cmpxchg.org wrote: On Mon, Aug 26, 2013 at 09:36:58PM +0800, larmbr wrote: Currently, we get the vm_swappiness via vmscan_swappiness(), which calls global_reclaim() to check if this is a global reclaim. Besides, the current implementation of global_reclaim() always returns true for the !CONFIG_MEGCG case, and judges the other case by checking whether scan_control-target_mem_cgroup is null or not. Thus, we could just use two versions of vmscan_swappiness() based on MEMCG Kconfig , to eliminate the unnecessary run-time cost for the !CONFIG_MEMCG at all, and to squash all memcg-related checking into the CONFIG_MEMCG version. The compiler can easily detect that global_reclaim() always returns true for !CONFIG_MEMCG during compile time and not even generate a branch for this. Hi, Johannes Weiner, Thanks for your comment ;) Andrew has pointed this out and this patch is abandoned. -- Regards, Zhan Jianyu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 an entry in MAINTAINERS for VMware's hypervisor interface
Hey, This change adds an entry to the maintainers file to explicitly state that any changes to vmware.c should be sent to the authors of the file as well. If you are thinking why do this now, off late we have seen quite a few changes that touched the arch/x86/kernel/cpu/vmware.c file but were not directed to me, someone else made me aware of those changes. It could be that my use of different SOB lines Alok N Kataria vs Alok Kataria confuses get_maintainer.pl, but adding this entry in MAINTAINERS should solve the problem at hand. For one of the changes [1], I did verify that get_maintainer.pl, now expectedly includes me in the cc list. Thanks, Alok [1] http://marc.info/?l=linux-kernelm=137571112610984w=2 From : Alok Kataria akata...@vmware.com Add an entry in MAINTAINERS file to reflect the authors of a file. Signed-off-by: Alok Kataria akata...@vmware.com Index: linux-2.6/MAINTAINERS === --- linux-2.6.orig/MAINTAINERS 2013-09-04 14:07:34.404027068 +0530 +++ linux-2.6/MAINTAINERS 2013-09-04 14:20:39.714026943 +0530 @@ -9038,6 +9038,12 @@ F: drivers/vme/ F: include/linux/vme* +VMWARE HYPERVISOR INTERFACE +M: Alok Kataria akata...@vmware.com +L: virtualizat...@lists.linux-foundation.org +S: Supported +F: arch/x86/kernel/cpu/vmware.c + VMWARE VMXNET3 ETHERNET DRIVER M: Shreyas Bhatewara sbhatew...@vmware.com M: VMware, Inc. pv-driv...@vmware.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 trivial] UAPI: Kbuild: add/modify comments for uapi/Kbuild and uapi/linux/Kbuild
On Wed, Sep 4, 2013 at 10:09 AM, Chen Gang gang.c...@asianux.com wrote:
On 09/04/2013 03:02 PM, Geert Uytterhoeven wrote:
On Wed, Sep 4, 2013 at 3:08 AM, Chen Gang gang.c...@asianux.com wrote:
On 09/04/2013 12:41 AM, Geert Uytterhoeven wrote:
On Tue, Aug 6, 2013 at 3:46 AM, Chen Gang gang.c...@asianux.com wrote:
--- a/include/uapi/Kbuild
+++ b/include/uapi/Kbuild
@@ -1,7 +1,6 @@
# UAPI Header export list
-# Top-level Makefile calls into asm-$(ARCH)
-# List only non-arch directories below
-
+# Except linux/, UAPI means Universal API.
Sorry for my silly question, but what's the purpose of this Universal
API comment?
Firstly, at least for me, I don't think it is a silly question (maybe
it means I should give additional explanations). :-)
I 'guess' the Universal API means:
the API which can be used under multiple OS (independent from Linux), it
may be used under kernel mode or user mode.
It is just my 'guess', welcome additional suggestions or completions by
any members.
When we get this correct additional explanation after discussing, if
suitable, I should add the final explanation to current patch.
Thanks. As this is not related at all to Linux, I don't see a reason
to add this comment.
Here, UAPI means userspace API only.
Hmm... why we need uapi/linux/ ? (I can not find some related
documents, so I have to 'guess').
The uapi subdirectories are there to distinguish userspace headers from
kernelspace headers, and allow both to live in the kernel source tree.
When running make headers_install, the (processed) headers in the
various uapi subdirectories are copied to /usr/include.
Hence uapi/linux/foo.h becomes linux/foo.h in userspace.
In userspace there are no uapi subdirectories anymore.
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: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs
On Wednesday 04 September 2013 11:27:12, Stephen Warren wrote: On 09/02/2013 03:25 AM, Lars Poeschel wrote: Some leagcy drivers currently do this: request_gpio(gpio); gpio_direction_input(gpio); request_irq(gpio_to_irq(gpio)); In that case request_irq should not fail because the driver is already the correct owner of this gpio. But if some other entity owns this gpio it should fail. Yes. Also if I understand you correct the other way round should also possible: request_irq(gpio_to_irq(gpio)); request_gpio(gpio); gpio_direction_input(gpio); request_irq() also requests the gpio then but the following request_gpio() should also not fail. I don't believe that code sequence is currently banned. If we want to ban it, we should document that. Until this is documented as being banned, I think we must fully support that code sequence. To have it work that way we have to track the owners of all requested gpios somewhere. Or am I wrong here? Where and how to record these owners? Can gpio system achieve this? gpios are requested without an owning device. Yes. But, I believe we need to fully track every GPIO/IRQ owner already right now; if a driver (not the GPIO/IRQ chip driver, but a driver that uses the GPIOs/IRQs) calls gpio_request()/request_irq(), and this patch has already requested them, then we already need to fully track GPIO/IRQ ownership to make sure that the driver's own requests aren't failed because the DT/GPIO core has already requested them on its behalf. The driver that tries to use the GPIO requested by this patch before HAS to fail. This is exactly the intention of this patch. We don't want the GPIO to be requested any more, if it is used as an interrupt pin. To be able to implement the way you proposed some mails before, I have to be able to do some checks that to my opinion (and if I understand Linus correctly) aren't possible at the moment. So I asked, where and how to record these owners of the GPIOs? And can the GPIO system achieve this and how? Can you please shed some light on this! 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 v3 1/3] Send loginuid and sessionid in SCM_AUDIT
On 09/04/2013 09:22 AM, Eric W. Biederman wrote:
Jan Kaluza jkal...@redhat.com writes:
Server-like processes in many cases need credentials and other
metadata of the peer, to decide if the calling process is allowed to
request a specific action, or the server just wants to log away this
type of information for auditing tasks.
The current practice to retrieve such process metadata is to look that
information up in procfs with the $PID received over SCM_CREDENTIALS.
This is sufficient for long-running tasks, but introduces a race which
cannot be worked around for short-living processes; the calling
process and all the information in /proc/$PID/ is gone before the
receiver of the socket message can look it up.
This introduces a new SCM type called SCM_AUDIT to allow the direct
attaching of loginuid and sessionid to SCM, which is significantly more
efficient and will reliably avoid the race with the round-trip over
procfs.
Unless I am misreading something this patch will break the build if
CONFIG_AUDITSYSCALL is not defined.
It does build. In this case, audit_get_loginuid returns INVALID_UID and
audit_get_sessionid returns -1.
Jan Kaluza
Eric
Signed-off-by: Jan Kaluza jkal...@redhat.com
---
include/linux/socket.h | 6 ++
include/net/af_unix.h | 2 ++
include/net/scm.h | 28 ++--
net/unix/af_unix.c | 7 +++
4 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 445ef75..505047a 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -130,6 +130,7 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr
*__msg, struct cmsghdr
#define SCM_RIGHTS 0x01/* rw: access rights (array of
int) */
#define SCM_CREDENTIALS 0x02 /* rw: struct ucred */
#define SCM_SECURITY 0x03/* rw: security label */
+#define SCM_AUDIT 0x04/* rw: struct uaudit*/
struct ucred {
__u32 pid;
@@ -137,6 +138,11 @@ struct ucred {
__u32 gid;
};
+struct uaudit {
+ __u32 loginuid;
+ __u32 sessionid;
+};
+
/* Supported address families. */
#define AF_UNSPEC 0
#define AF_UNIX 1 /* Unix domain sockets */
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index a175ba4..3b9d22a 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -36,6 +36,8 @@ struct unix_skb_parms {
u32 secid; /* Security ID */
#endif
u32 consumed;
+ kuid_t loginuid;
+ unsigned intsessionid;
};
#define UNIXCB(skb) (*(struct unix_skb_parms *)((skb)-cb))
diff --git a/include/net/scm.h b/include/net/scm.h
index 8de2d37..e349a25 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -6,6 +6,7 @@
#include linux/security.h
#include linux/pid.h
#include linux/nsproxy.h
+#include linux/audit.h
/* Well, we should have at least one descriptor open
* to accept passed FDs 8)
@@ -18,6 +19,11 @@ struct scm_creds {
kgid_t gid;
};
+struct scm_audit {
+ kuid_t loginuid;
+ unsigned int sessionid;
+};
+
struct scm_fp_list {
short count;
short max;
@@ -28,6 +34,7 @@ struct scm_cookie {
struct pid *pid; /* Skb credentials */
struct scm_fp_list *fp;/* Passed files */
struct scm_credscreds; /* Skb credentials */
+ struct scm_auditaudit; /* Skb audit*/
#ifdef CONFIG_SECURITY_NETWORK
u32 secid; /* Passed security ID */
#endif
@@ -58,6 +65,13 @@ static __inline__ void scm_set_cred(struct scm_cookie *scm,
scm-creds.gid = gid;
}
+static inline void scm_set_audit(struct scm_cookie *scm,
+ kuid_t loginuid, unsigned int sessionid)
+{
+ scm-audit.loginuid = loginuid;
+ scm-audit.sessionid = sessionid;
+}
+
static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
{
put_pid(scm-pid);
@@ -77,8 +91,12 @@ static __inline__ int scm_send(struct socket *sock, struct
msghdr *msg,
memset(scm, 0, sizeof(*scm));
scm-creds.uid = INVALID_UID;
scm-creds.gid = INVALID_GID;
- if (forcecreds)
- scm_set_cred(scm, task_tgid(current), current_uid(),
current_gid());
+ if (forcecreds) {
+ scm_set_cred(scm, task_tgid(current), current_uid(),
+current_gid());
+ scm_set_audit(scm, audit_get_loginuid(current),
+ audit_get_sessionid(current));
+ }
unix_get_peersec_dgram(sock, scm);
if (msg-msg_controllen = 0)
return 0;
@@ -123,7 +141,13 @@ static __inline__ void scm_recv(struct
Re: [PATCH trivial] UAPI: Kbuild: add/modify comments for uapi/Kbuild and uapi/linux/Kbuild
On 09/04/2013 05:02 PM, Geert Uytterhoeven wrote:
On Wed, Sep 4, 2013 at 10:09 AM, Chen Gang gang.c...@asianux.com wrote:
On 09/04/2013 03:02 PM, Geert Uytterhoeven wrote:
On Wed, Sep 4, 2013 at 3:08 AM, Chen Gang gang.c...@asianux.com wrote:
On 09/04/2013 12:41 AM, Geert Uytterhoeven wrote:
On Tue, Aug 6, 2013 at 3:46 AM, Chen Gang gang.c...@asianux.com wrote:
--- a/include/uapi/Kbuild
+++ b/include/uapi/Kbuild
@@ -1,7 +1,6 @@
# UAPI Header export list
-# Top-level Makefile calls into asm-$(ARCH)
-# List only non-arch directories below
-
+# Except linux/, UAPI means Universal API.
Sorry for my silly question, but what's the purpose of this Universal
API comment?
Firstly, at least for me, I don't think it is a silly question (maybe
it means I should give additional explanations). :-)
I 'guess' the Universal API means:
the API which can be used under multiple OS (independent from Linux),
it may be used under kernel mode or user mode.
It is just my 'guess', welcome additional suggestions or completions by
any members.
When we get this correct additional explanation after discussing, if
suitable, I should add the final explanation to current patch.
Thanks. As this is not related at all to Linux, I don't see a reason
to add this comment.
Here, UAPI means userspace API only.
Hmm... why we need uapi/linux/ ? (I can not find some related
documents, so I have to 'guess').
The uapi subdirectories are there to distinguish userspace headers from
kernelspace headers, and allow both to live in the kernel source tree.
When running make headers_install, the (processed) headers in the
various uapi subdirectories are copied to /usr/include.
Hence uapi/linux/foo.h becomes linux/foo.h in userspace.
In userspace there are no uapi subdirectories anymore.
Yeah, so why need another uapi/* excluding uapi/linux ?
Are they also truly still Userspace API but which need not distinguish
? (at least, it seems that idea is not quite good).
Hmm... maybe the uapi/* except uapi/linux are also installed? Is it
for compatible (originally they are here, and now we have to follow, it
is no reason to change if not find related critical issues)?
Thanks.
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
--
Chen Gang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the scsi tree
On 9/2/2013 1:58 PM, Stephen Rothwell wrote: Hi James, After merging the scsi tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/scsi/ufs/ufshcd.c: In function 'ufshcd_eh_host_reset_handler': drivers/scsi/ufs/ufshcd.c:2740:3: warning: 'flush_work_sync' is deprecated (declared at /scratch/sfr/next/include/linux/workqueue.h:624) [-Wdeprecated-declarations] flush_work_sync(hba-eh_work); ^ James, would you like to pick up follow-up patch @ http://marc.info/?l=linux-scsim=137819519527432w=2 or let me update the commit c1e846ab4422 fixing this? Introduced by commit c1e846ab4422 ([SCSI] ufs: Fix device and host reset methods). flush_work_sync was deprecated by commit 43829731dd37 (workqueue: deprecate flush[_delayed]_work_sync()) before v3.7-rc1. -- Regards, Sujit -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] gpio: interrupt consistency check for OF GPIO IRQs
On Wednesday 04 September 2013 11:29:00, Stephen Warren wrote: On 09/02/2013 03:38 AM, Lars Poeschel wrote: Am Freitag, 30. August 2013, 13:53:45 schrieb Stephen Warren: ... Yet the current patch only addresses a limited set of cases, since it doesn't hook the APIs but rather parses the DT. It doesn't cover the non-DT case. It should if the feature is useful. As pointed out before, only DT has this problem, that, That's completely false. Both DT and non-DT can represent the exact same HW, and use the exact same drivers. It's equally possible to write a bug in a board file or a DT file (i.e. a typo or incorrect reading of the schematic) that causes the wrong GPIO or IRQ ID to be used, and hence for there to be conflicts. Any solution to this issue needs to address both cases. This is again not the point. This is not what this patch is trying to solve. The patch is trying to solve problem A. But you are talking about problem B. Sure I can write a bug in board files and I can write a bug in DT files. The patch is not trying to prevent that. This is a completly different thing. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: i8042 - add PNP modaliases
This allows the module to be autoloaded in the common case.
In order to work on non-PnP systems the module should be compiled in or loaded
unconditionally at boot (c.f. modules-load.d(5)), as before.
Cc: Matthew Garrett mj...@srcf.ucam.org
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Signed-off-by: Tom Gundersen t...@jklm.no
---
This appears to work for me (though I don't have the real hardware to test), I
get the following aliases:
alias: acpi*:CPQA0D7:*
alias: pnp:dCPQA0D7*
alias: acpi*:PNP0345:*
alias: pnp:dPNP0345*
alias: acpi*:PNP0344:*
alias: pnp:dPNP0344*
alias: acpi*:PNP0343:*
alias: pnp:dPNP0343*
alias: acpi*:PNP0320:*
alias: pnp:dPNP0320*
alias: acpi*:PNP030B:*
alias: pnp:dPNP030b*
alias: acpi*:PNP030A:*
alias: pnp:dPNP030a*
alias: acpi*:PNP0309:*
alias: pnp:dPNP0309*
alias: acpi*:PNP0306:*
alias: pnp:dPNP0306*
alias: acpi*:PNP0305:*
alias: pnp:dPNP0305*
alias: acpi*:PNP0304:*
alias: pnp:dPNP0304*
alias: acpi*:PNP0303:*
alias: pnp:dPNP0303*
alias: acpi*:PNP0302:*
alias: pnp:dPNP0302*
alias: acpi*:PNP0301:*
alias: pnp:dPNP0301*
alias: acpi*:PNP0300:*
alias: pnp:dPNP0300*
drivers/input/serio/i8042-x86ia64io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 5f306f7..0ec9abb 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -765,6 +765,7 @@ static struct pnp_device_id pnp_kbd_devids[] = {
{ .id = CPQA0D7, .driver_data = 0 },
{ .id = , },
};
+MODULE_DEVICE_TABLE(pnp, pnp_kbd_devids);
static struct pnp_driver i8042_pnp_kbd_driver = {
.name = i8042 kbd,
@@ -786,6 +787,7 @@ static struct pnp_device_id pnp_aux_devids[] = {
{ .id = SYN0801, .driver_data = 0 },
{ .id = , },
};
+MODULE_DEVICE_TABLE(pnp, pnp_aux_devids);
static struct pnp_driver i8042_pnp_aux_driver = {
.name = i8042 aux,
--
1.8.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: [E1000-devel] [PATCH 5/7] ixgbe: use pcie_capability_read_word() to simplify code
On Tue, 2013-09-03 at 15:35 +0800, Yijing Wang wrote: use pcie_capability_read_word() to simplify code. Signed-off-by: Yijing Wang wangyij...@huawei.com Cc: e1000-de...@lists.sourceforge.net Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) Thanks Yijing, I will add it to my queue. signature.asc Description: This is a digitally signed message part
Re: [PATCH trivial] UAPI: Kbuild: add/modify comments for uapi/Kbuild and uapi/linux/Kbuild
On Wed, Sep 4, 2013 at 11:13 AM, Chen Gang gang.c...@asianux.com wrote:
Hmm... why we need uapi/linux/ ? (I can not find some related
documents, so I have to 'guess').
The uapi subdirectories are there to distinguish userspace headers from
kernelspace headers, and allow both to live in the kernel source tree.
When running make headers_install, the (processed) headers in the
various uapi subdirectories are copied to /usr/include.
Hence uapi/linux/foo.h becomes linux/foo.h in userspace.
In userspace there are no uapi subdirectories anymore.
Yeah, so why need another uapi/* excluding uapi/linux ?
Are they also truly still Userspace API but which need not distinguish
? (at least, it seems that idea is not quite good).
Hmm... maybe the uapi/* except uapi/linux are also installed? Is it
for compatible (originally they are here, and now we have to follow, it
is no reason to change if not find related critical issues)?
All uapi files are installed, a.o. /usr/include/scsi/, /usr/include/video/, ...
Historically, everything under include in the kernel source tree was
installed in /usr/include/, after (semi)manual cleanup.
Since the uapi split, everything is handled automatically.
Because of compatibility reasons (do not break userspace), paths had to
stay the same.
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/
[PATCH] regulator: palmas: fix the n_voltages for smps to 122
With the following change
-
commit ad02e846878ca35e9d3fa584be8ee770e9e14fce
Author: Axel Lin axel@ingics.com
regulator: palmas: Return raw register values as the selectors in
[get|set]_voltage_sel
Don't adjust the selector in [get|set]_voltage_sel, fix it in
list_voltage() instead.
For smps*(except smps10), the vsel reg-value and voltage mapping as below:
--
The list_voltage() takes the true value of selector which is
programmed in the register. As per smsp voltage table
reg-value volt (uV) ( Assume RANGE is x1 )
0 0
1 50
2 50
3 50
4 50
5 50
6 50 (0.49V + 1 * 0.01V) * RANGE
7 51 (0.49V + 2 * 0.01V) * RANGE
8 52 (0.49V + 3 * 0.01V) * RANGE
9 53 (0.49V + 4 * 0.01V) * RANGE
121165 (0.49V + 116 * 0.1) * RANGE
Hence making n_voltages for smps to 122.
Signed-off-by: Laxman Dewangan ldewan...@nvidia.com
---
drivers/regulator/palmas-regulator.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 488dfe7..cb65c6f 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -207,7 +207,7 @@ static unsigned int palmas_smps_ramp_delay[4] = {0, 1,
5000, 2500};
*
* So they are basically (maxV-minV)/stepV
*/
-#define PALMAS_SMPS_NUM_VOLTAGES 117
+#define PALMAS_SMPS_NUM_VOLTAGES 122
#define PALMAS_SMPS10_NUM_VOLTAGES 2
#define PALMAS_LDO_NUM_VOLTAGES50
--
1.7.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/11] iio: ST clean-ups and new pressure sensor device
This patch-set includes a few clean-ups surrounding error handling and non-mandatory functionality along with regulator support and the addition of a new pressure/temperature sensor (LPS001WP). Everything has been tested with Device Tree. arch/arm/boot/dts/ste-dbx5x0.dtsi | 5 -- arch/arm/boot/dts/ste-snowball.dts | 10 arch/arm/configs/u8500_defconfig| 4 ++ drivers/iio/common/st_sensors/st_sensors_core.c | 11 ++-- drivers/iio/pressure/st_pressure.h | 1 + drivers/iio/pressure/st_pressure_core.c | 276 ++- drivers/iio/pressure/st_pressure_i2c.c | 18 +++ include/linux/iio/common/st_sensors.h | 4 ++ 8 files changed, 230 insertions(+), 99 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/11] iio: pressure-core: st: Allow for number of channels to vary
At the moment the number of channels specified is dictated by the first
sensor supported by the driver. As we add support for more sensors this
is likely to vary. Instead of using the ARRAY_SIZE() of the LPS331AP's
channel specifier we'll use a new adaptable 'struct st_sensors' element
instead.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/iio/pressure/st_pressure_core.c | 3 ++-
include/linux/iio/common/st_sensors.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/pressure/st_pressure_core.c
b/drivers/iio/pressure/st_pressure_core.c
index 423ed6a..3cf54ed 100644
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -101,6 +101,7 @@ static const struct st_sensors st_press_sensors[] = {
[0] = LPS331AP_PRESS_DEV_NAME,
},
.ch = (struct iio_chan_spec *)st_press_lsp331ap_channels,
+ .num_ch = ARRAY_SIZE(st_press_lsp331ap_channels),
.odr = {
.addr = ST_PRESS_LPS331AP_ODR_ADDR,
.mask = ST_PRESS_LPS331AP_ODR_MASK,
@@ -237,7 +238,7 @@ int st_press_common_probe(struct iio_dev *indio_dev)
pdata-num_data_channels = ST_PRESS_NUMBER_DATA_CHANNELS;
pdata-multiread_bit = pdata-sensor-multi_read_bit;
indio_dev-channels = pdata-sensor-ch;
- indio_dev-num_channels = ARRAY_SIZE(st_press_lsp331ap_channels);
+ indio_dev-num_channels = pdata-sensor-num_ch;
if (pdata-sensor-fs.addr != 0)
pdata-current_fullscale = (struct st_sensor_fullscale_avl *)
diff --git a/include/linux/iio/common/st_sensors.h
b/include/linux/iio/common/st_sensors.h
index 72b2694..4aef925 100644
--- a/include/linux/iio/common/st_sensors.h
+++ b/include/linux/iio/common/st_sensors.h
@@ -180,6 +180,7 @@ struct st_sensors {
u8 wai;
char sensors_supported[ST_SENSORS_MAX_4WAI][ST_SENSORS_MAX_NAME];
struct iio_chan_spec *ch;
+ int num_ch;
struct st_sensor_odr odr;
struct st_sensor_power pw;
struct st_sensor_axis enable_axis;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
