Re: [PATCH] rcu: Eliminate softirq processing from rcutree

[Mike Galbraith]

On Sun, 2013-12-22 at 04:07 +0100, Mike Galbraith wrote: 
> On Sat, 2013-12-21 at 20:39 +0100, Sebastian Andrzej Siewior wrote: 
> > From: "Paul E. McKenney" 
> > 
> > Running RCU out of softirq is a problem for some workloads that would
> > like to manage RCU core processing independently of other softirq work,
> > for example, setting kthread priority.  This commit therefore moves the
> > RCU core work from softirq to a per-CPU/per-flavor SCHED_OTHER kthread
> > named rcuc.  The SCHED_OTHER approach avoids the scalability problems
> > that appeared with the earlier attempt to move RCU core processing to
> > from softirq to kthreads.  That said, kernels built with RCU_BOOST=y
> > will run the rcuc kthreads at the RCU-boosting priority.
> 
> I'll take this for a spin on my 64 core test box.
> 
> I'm pretty sure I'll still end up having to split softirq threads again
> though, as big box has been unable to meet jitter requirements without,
> and last upstream rt kernel tested still couldn't.

Still can't fwiw, but whatever, back to $subject.  I'll let the box give
RCU something to do for a couple days.  No news is good news.

-Mike

30 minute isolated core jitter test says tinkering will definitely be
required.  3.0-rt does single digit worst case on same old box.  Darn.

(test is imperfect, but good enough)

FREQ=960 FRAMES=1728000 LOOP=5 using CPUs 4 - 23
FREQ=1000 FRAMES=180 LOOP=48000 using CPUs 24 - 43
FREQ=300 FRAMES=54 LOOP=16 using CPUs 44 - 63
on your marks... get set... POW!
Cpu FramesMin Max(Frame)  Avg Sigma LastTrans 
Fliers(Frames) 
4   1727979   0.0159  181.66 (1043545)0.4492  0.58760 (0) 16 
(828505,828506,859225,859226,889945,..1043546)
5   1727980   0.0159  181.90 (1013305)0.4560  0.61180 (0) 16 
(798265,798266,828985,828986,859705,..1013306)
6   1727981   0.0159  189.05 (1013785)0.3691  0.62250 (0) 16 
(798745,798746,829465,829466,860185,..1013786)
7   1727982   0.0159  177.88 (983546) 0.2885  0.52690 (0) 16 
(768505,768506,799225,799226,829945,..983546)
8   1727984   0.0159  192.63 (984025) 0.3131  0.63070 (0) 18 
(738265,738266,768985,768986,799705,..984026)
9   1727985   0.0159  16.43 (801406)  0.6562  0.57940 (0) 
10  1727986   0.0159  186.94 (954266) 0.3514  0.62520 (0) 16 
(739225,739226,769945,769946,800665,..954266)
11  1727987   0.0159  194.06 (954745) 0.4341  0.65470 (0) 18 
(708985,708986,739705,739706,770425,..954746)
12  1727989   0.0159  13.61 (67116)   0.3364  0.42940 (0) 
13  1727990   0.0159  186.19 (894265) 0.3955  0.61130 (0) 16 
(679225,679226,709945,709946,740665,..894266)
14  1727991   0.0159  192.18 (894746) 0.4410  0.64490 (0) 18 
(648985,648986,679705,679706,710425,..894746)
15  1727993   0.0159  183.36 (833786) 0.5582  0.66550 (0) 16 
(618745,618746,649465,649466,680185,..833786)
16  1727994   0.0159  193.61 (895706) 0.6073  0.73820 (0) 17 
(649945,680665,680666,711385,711386,..895706)
17  1727995   0.0159  36.94 (739943)  0.7135  0.75430 (0) 6 
(173558,173559,739943,739944,1224751,1224752)
18  1727996   0.0159  167.39 (835226) 0.8385  0.82870 (0) 16 
(620185,620186,650905,650906,681625,..835226)
19  1727997   0.0159  172.84 (804985) 0.5110  0.69590 (0) 17 
(589946,620665,620666,651385,651386,..835706)
20  1727999   0.0159  180.47 (774745) 0.7566  0.75620 (0) 16 
(559705,559706,590425,590426,621145,..774746)
21  1728000   0.0159  169.74 (744505) 0.7719  0.81540 (0) 16 
(560185,560186,590905,590906,621625,..775226)
22  1728000   0.0159  194.80 (836667) 0.6799  0.70630 (0) 16 
(590906,590907,622105,622106,652346,..836667)
23  1728000   0.0159  183.12 (745466) 0.6733  0.70910 (0) 16 
(530425,530426,561145,561146,591865,..745466)
24  180   0.0725  7.46 (132730)   0.5375  0.44620 (0) 
25  180   0.0725  7.23 (132730)   0.5725  0.48160 (0) 
26  180   0.0725  7.23 (132730)   0.5119  0.41940 (0) 
27  180   0.0725  4.93 (132730)   0.4102  0.33790 (0) 
28  180   0.0725  5.08 (444312)   0.4275  0.35100 (0) 
29  180   0.0725  6.75 (132717)   0.5501  0.52320 (0) 
30  180   0.0725  11.61 (12026)   0.3811  0.39340 (0) 
31  180   0.0725  11.61 (12526)   0.4054  0.45510 (0) 
32  180   0.0725  50.95 (13026)   0.6015  0.56170 (0) 31 
(13026,13027,45026,45027,77026,..909027)
33  180   0.0725  62.63 (13526)   0.5643  0.59220 (0) 112 
(13526,13527,45526,45527,77526,..1773527)
34  180   0.0725  70.26 (14026)   0.3698  0.61320 (0) 112 
(14026,14027,46026,46027,78026,..1774027)
35  180   0.0725  84.57 (14526)   0.6490  0.79810 (0) 112 
(14526,14527,46526,46527,78526,..1774527)
36  180   0.0725  81.94 (943026)  0.3917  0.63870 (0) 112 
(15026,15027,47026,47027,79026,..1775027)
37  180   0.0725  93.86 (15526)   0.6346  0.85800 (0) 11

Re: [PATCH] drivers: target: target_core_mod: use div64_u64_rem() instead of operator '%' for u64

[Chen Gang]

On 12/22/2013 10:56 AM, Nicholas A. Bellinger wrote:
> Hi Chen,
> 
> On Sat, 2013-12-21 at 10:08 +0800, Chen Gang wrote:
>> In kernel, need use div64_u64_rem() instead of operator '%' for u64, or
>> can not pass compiling (with allmodconfig under metag):
>>
>> MODPOST 2909 modules
>>   ERROR: "__umoddi3" [drivers/target/target_core_mod.ko] undefined!
>>
>> Also need u64 type cast for u32 variable multiply u32 variable, or will
>> cause type overflow issue.
>>
>>
>> Signed-off-by: Chen Gang 
>> ---
>>  drivers/target/target_core_alua.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
> 
> FYI, this unsigned long long division in core_alua_state_lba_dependent()
> was fixed for 32-bit in linux-next >= 12192013 code.
> 

OK, thanks.

The related fix patch changed "start_lba = lba % ..." to "start_lba =
lba / ...", and also assumed "segment_size * segment_mult" is still
within u32 (can not cause type over flow).

I guess the original author already knew about them, and intended to do
like that (if not, please let me know, thanks).


> Regardless, thanks for your patch.
> 

Thank you too.

> --nab
> 
>> diff --git a/drivers/target/target_core_alua.c 
>> b/drivers/target/target_core_alua.c
>> index dc0d399..ff2aadc 100644
>> --- a/drivers/target/target_core_alua.c
>> +++ b/drivers/target/target_core_alua.c
>> @@ -489,7 +489,8 @@ static inline int core_alua_state_lba_dependent(
>>  u64 first_lba = map->lba_map_first_lba;
>>  
>>  if (segment_mult) {
>> -start_lba = lba % (segment_size * segment_mult);
>> +u64 tmp = (u64)segment_size * segment_mult;
>> +div64_u64_rem(lba, tmp, &start_lba);
>>  last_lba = first_lba + segment_size - 1;
>>  if (start_lba >= first_lba &&
>>  start_lba <= last_lba) {
> 
> 


-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] drivers: net: APM X-Gene SoC Ethernet driver error handling

[Arnd Bergmann]

On Saturday 21 December 2013, Iyappan Subramanian wrote:

> +#define CFG_RSIF_FPBUFF_TIMEOUT_EN_WR(src) \
> + (((u32)(src)<<31) & 0x8000)
> +#define RSIF_LCL_RXBUF_FIFO_OVERFL_INTR_RXPRT10_MASK 
> 0x2000
> +#define RSIF_LCL_RXBUF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \
> + (((src) & 0x2000)>>29)
> +#define RSIF_LCL_RXBUF_FIFO_UNDERFL_INTR_RXPRT10_MASK
> 0x1000
> +#define RSIF_LCL_RXBUF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \
> + (((src) & 0x1000)>>28)
> +#define RSIF_CHKSUM_BUFF_FIFO_OVERFL_INTR_RXPRT10_MASK   
> 0x0800
> +#define RSIF_CHKSUM_BUFF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \
> + (((src) & 0x0800)>>27)
> +#define RSIF_CHKSUM_BUFF_FIFO_UNDERFL_INTR_RXPRT10_MASK  
> 0x0400
> +#define RSIF_CHKSUM_BUFF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \
> + (((src) & 0x0400)>>26)
> +#define RSIF_TIMESTAMP_BUFF_FIFO_OVERFL_INTR_RXPRT10_MASK
> 0x0200
> +#define RSIF_TIMESTAMP_BUFF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \
> + (((src) & 0x0200)>>25)
> +#define RSIF_TIMESTAMP_BUFF_FIFO_UNDERFL_INTR_RXPRT10_MASK   
> 0x0100
> +#define RSIF_TIMESTAMP_BUFF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \
> + (((src) & 0x0100)>>24)
> +#define RSIF_ERR_BUFF_FIFO_OVERFL_INTR_RXPRT10_MASK  
> 0x0080
> +#define RSIF_ERR_BUFF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \
> + (((src) & 0x0080)>>23)
> +#define RSIF_ERR_BUFF_FIFO_UNDERFL_INTR_RXPRT10_MASK 
> 0x0040
> +#define RSIF_ERR_BUFF_FIFO_UNDERFL_INTR_RXPRT10_RD(src) \
> + (((src) & 0x0040)>>22)
> +#define RSIF_CLEBUFF_FIFO_OVERFL_INTR_RXPRT10_MASK   
> 0x0020
> +#define RSIF_CLEBUFF_FIFO_OVERFL_INTR_RXPRT10_RD(src) \
> + (((src) & 0x0020)>>21)

I think you can just remove all the above obfuscation, since all you ever
do is this:

> + rc = xgene_enet_rd(priv, BLOCK_MCX_MAC_CSR, MAC_INT_REG0_ADDR, &data);
> + if (data) {
> + pr_err("Received MAC Error Interrupt\n");
> +
> + if (ICM_DATA_FIFO_UNDERFL_INTR_PRT10_RD(data)) {
> + pr_err("RxPort1 ICM Data fifo underflow intr\n");
> + int_mask |= ICM_DATA_FIFO_UNDERFL_INTR_PRT10_MASK;
> + }
> + if (ICM_DATA_FIFO_OVERFL_INTR_PRT10_RD(data)) {
> + pr_err("RxPort1 ICM Data fifo overflow intr\n");
> + int_mask |= ICM_DATA_FIFO_OVERFL_INTR_PRT10_MASK;
> + }
> + if (ICM_CTRL_FIFO_UNDERFL_INTR_PRT10_RD(data)) {
> + pr_err("RxPort1 ICM Ctrl fifo underflow intr\n");
> + int_mask |= ICM_CTRL_FIFO_UNDERFL_INTR_PRT10_MASK;
> + }
> + if (ICM_CTRL_FIFO_OVERFL_INTR_PRT10_RD(data)) {
> + pr_err("RxPort1 ICM Ctrl fifo overflow intr\n");
> + int_mask |= ICM_CTRL_FIFO_OVERFL_INTR_PRT10_MASK;
> + }
> + if (ECM_DATA_FIFO_UNDERN_INTR_PRT10_RD(data)) {
> + pr_err("RxPort1 ECM Data fifo underrun intr\n");
> + int_mask |= ECM_DATA_FIFO_UNDERN_INTR_PRT10_MASK;
> + }

So there is one string you print per bit. Just use an array of strings
and for_each_set_bit() loop.

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

Re: [PATCH 0/5] drivers: net: Adding support for APM X-Gene SoC Ethernet base driver

[Arnd Bergmann]

On Saturday 21 December 2013, Iyappan Subramanian wrote:
> Iyappan Subramanian (5):
>   Documentation: APM X-Gene SoC Ethernet DTS binding documentation
>   arm64: dts: APM X-Gene SoC Ethernet device tree nodes
>   drivers: net: APM X-Gene SoC Ethernet base driver
>   drivers: net: APM X-Gene SoC Ethernet driver error handling
>   drivers: net: APM X-Gene SoC Ethernet driver ethtool support

The third patch (the actual driver) didn't make it to the ARM mailing list.
Maybe it's too large?

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

Re: [PATCH 1/5] Documentation: APM X-Gene SoC Ethernet DTS binding documentation

[Arnd Bergmann]

On Saturday 21 December 2013, Iyappan Subramanian wrote:
> @@ -0,0 +1,67 @@
> +APM X-Gene SoC Ethernet nodes
> +
> +Ethernet nodes are defined to describe on-chip ethernet interfaces in
> +APM X-Gene SoC. Ethernet subsystem communicates with a central Queue Manager
> +(QMTM) using messages for transmit, receive and allocating data buffers.
> +There are multiple ethernet interfaces in APM X-Gene SoC. Each ethernet
> +interface has its own node. Its corresponding clock nodes are shown below.
> +
> +Required properties:
> +- compatible : Shall be "apm,xgene-enet"
> +- reg: First memory resource shall be the Ethernet 
> CSR
> +   memory resource for indirect MAC access.
> +   Second memory resource shall be the Ethernet CSR
> +   memory resource.
> +   Third memory resource shall be the Ethernet CSR
> +   memory resource for indirect MII access.

What is a "CSR"?

> +- interrupts : First interrupt resource shall be the Ethernet global
> +   Error interrupt.
> + : Second interrupt resource shall be the Ethernet MAC
> +   Error interrupt.
> + : Third interrupt resource shall be the Ethernet QM
> +   interface interrupt.

No regular interrupts?

> +- clocks : Reference to the clock entry.
> +- local-mac-address  : Shall be ethernet mac address.
> +- max-frame-size : Shall be maximum ethernet frame size.
> +- devid  : Shall be ethernet interface number.
> +- phyid  : Shall be ethernet MII phy address.
> +- phy-mode   : Shall be ethernet MII mode.

Can you explain what the interface number is for?

Is the phy actually part of the ethernet device? Since it has its
own register range, it seems likely that it's actually a separate
device that just happens to be used together with the mac and should
have its own device node and driver.

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

[PATCH 2/2] binder: implement namepsace support for Android binder driver

[Oren Laadan]

Add namespaces support for the Android binder driver.
As binder is an IPC mechanism, tie its namespace to IPC_NS.

In binder, the first process to call BINDER_SET_CONTEXT_MGR ioctl
becomes the manager with context 0, and thereafter IPC is realized
through binder handles obtained from this manager.

For namespaces, associate a separate binder state with each namespace
so each namespace has its own context manager. Binder users within a
namespace interact only with the context manager there. This suffices
because binder does not allow IPC not via the context manager.

Currently, statistics remain global, except for the list of processes
that hold an open binder device (reported per namespace).

Signed-off-by: Oren Laadan 
Acked-by: Amir Goldstein 
---
 drivers/staging/android/Kconfig  |   1 +
 drivers/staging/android/binder.c | 172 ---
 2 files changed, 143 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 1e9ab6d..208685e 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -11,6 +11,7 @@ if ANDROID
 config ANDROID_BINDER_IPC
bool "Android Binder IPC Driver"
depends on MMU
+   select SYSVIPC
default n
---help---
  Binder is used in Android for both communication between processes,
diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index eaec1da..6f97f89 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -36,24 +36,104 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "binder.h"
 #include "binder_trace.h"
 
+/*
+ * Using a private context manager for each binder namespace is sufficient
+ * to isolate between namespaces, because in binder all IPC must be realized
+ * via hanldes obtained from the context manager.
+ *
+ * TODO: currently, most debugfs data is not tracked per binder namespaces.
+ * Except for "procs" which are properly virtualized, everything else is
+ * global, including stats, logs, and dead nodes.
+ */
+struct binder_namespace {
+   struct kref kref;
+
+   struct binder_node *context_mgr_node;
+   kuid_t context_mgr_uid;
+   int last_id;
+
+   struct hlist_head procs;
+};
+
+static struct binder_namespace *create_binder_ns(void)
+{
+   struct binder_namespace *binder_ns;
+
+   binder_ns = kzalloc(sizeof(struct binder_namespace), GFP_KERNEL);
+   if (binder_ns) {
+   kref_init(&binder_ns->kref);
+   binder_ns->context_mgr_uid = INVALID_UID;
+   INIT_HLIST_HEAD(&binder_ns->procs);
+   }
+   return binder_ns;
+}
+
+static void free_binder_ns(struct kref *kref)
+{
+   kfree(container_of(kref, struct binder_namespace, kref));
+}
+
+static void get_binder_ns(struct binder_namespace *binder_ns)
+{
+   kref_get(&binder_ns->kref);
+}
+
+static void put_binder_ns(struct binder_namespace *binder_ns)
+{
+   kref_put(&binder_ns->kref, free_binder_ns);
+}
+
+/*
+ * Binder is an IPC mechanism, so tie its namespace to IPC_NS
+ * using the generic data pointer and per-ipc operations.
+ */
+static struct binder_namespace *current_binder_ns(void)
+{
+   return ipc_access_generic(current->nsproxy->ipc_ns);
+}
+
+int binder_init_ns(struct ipc_namespace *ipcns)
+{
+   struct binder_namespace *binder_ns;
+   int ret = -ENOMEM;
+
+   binder_ns = create_binder_ns();
+   if (binder_ns) {
+   ipc_assign_generic(ipcns, binder_ns);
+   ret = 0;
+   }
+   return ret;
+}
+
+void binder_exit_ns(struct ipc_namespace *ipcns)
+{
+   struct binder_namespace *binder_ns;
+
+   binder_ns = ipc_access_generic(ipcns);
+   if (binder_ns)
+   put_binder_ns(binder_ns);
+}
+
+struct peripc_operations binder_peripc_ops = {
+   .init = binder_init_ns,
+   .exit = binder_exit_ns,
+};
+
 static DEFINE_MUTEX(binder_main_lock);
 static DEFINE_MUTEX(binder_deferred_lock);
 static DEFINE_MUTEX(binder_mmap_lock);
 
-static HLIST_HEAD(binder_procs);
 static HLIST_HEAD(binder_deferred_list);
 static HLIST_HEAD(binder_dead_nodes);
 
 static struct dentry *binder_debugfs_dir_entry_root;
 static struct dentry *binder_debugfs_dir_entry_proc;
-static struct binder_node *binder_context_mgr_node;
-static kuid_t binder_context_mgr_uid = INVALID_UID;
-static int binder_last_id;
 static struct workqueue_struct *binder_deferred_workqueue;
 
 #define BINDER_DEBUG_ENTRY(name) \
@@ -319,6 +399,8 @@ struct binder_proc {
int ready_threads;
long default_priority;
struct dentry *debugfs_entry;
+
+   struct binder_namespace *binder_ns;
 };
 
 enum {
@@ -900,7 +982,7 @@ static struct binder_node *binder_new_node(struct 
binder_proc *proc,
binder_stats_created(BINDER_STAT_NODE);
rb_link_node(&node->rb_node, parent, p);
rb_insert_color(&node->rb_node, &proc->nodes);
-   node->debug_

[PATCH 0/2] Namespace support for Android binder (under ipc-ns)

[Oren Laadan]

Hi,

This patch-duo adds namespaces support for the Android binder driver. As
discussed in Plumbers 2013, binder is a form of IPC and therefore will be
tied to ipc namespace.

On the ipc-ns side, the implementation is modelled after generic net-ns
pointers (see commit dec827d), but simplified to suit single user/caller
for now, to reduce complexity.

The binder driver registers with ipc-ns and uses the generic pointer to
store and retrieve its namespace data. That is, each namespace maintains
its own binder context manager - which suffices for separation, since all
transactions require binder handles provided by the context manager.

Thanks,

Oren.


Oren Laadan (2):
  ipc namespace: a generic per-ipc pointer and peripc_ops
  binder: implement namepsace support for Android binder driver

 drivers/staging/android/Kconfig  |   1 +
 drivers/staging/android/binder.c | 172 ---
 include/linux/ipc_namespace.h|  29 +++
 ipc/namespace.c  |   9 ++
 ipc/util.c   |  60 ++
 ipc/util.h   |   3 +
 6 files changed, 244 insertions(+), 30 deletions(-)

-- 
1.8.3.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/

[PATCH 1/2] ipc namespace: a generic per-ipc pointer and peripc_ops

[Oren Laadan]

Add a void * pointer to struct ipc_namespace. The access rules are:
1. (un)register ops with (un)register_peripc_operations()
2. call ipc_assign_generic() to put private data on the ipc_namespace
3. call ipc_access_generic() to access the private data
4. do not change the pointer during the lifetime of ipc_namespace

Modeled after generic net-ns pointers (commit dec827d), but simplified
to accommodate a single user for now (reduce code churn):
5. only one caller can register at a time
6. caller must register at boot time (not to be used by modules)

Signed-off-by: Oren Laadan 
Signed-off-by: Amir Goldstein 
---
 include/linux/ipc_namespace.h | 29 +
 ipc/namespace.c   |  9 +++
 ipc/util.c| 60 +++
 ipc/util.h|  3 +++
 4 files changed, 101 insertions(+)

diff --git a/include/linux/ipc_namespace.h b/include/linux/ipc_namespace.h
index f6c82de..72da9bf 100644
--- a/include/linux/ipc_namespace.h
+++ b/include/linux/ipc_namespace.h
@@ -70,8 +70,37 @@ struct ipc_namespace {
struct user_namespace *user_ns;
 
unsigned intproc_inum;
+
+   /* allow others to piggyback on ipc_namesspaces */
+   void *gen;  /* for others' private stuff */
 };
 
+/*
+ * To access to the per-ipc generic data:
+ * 1. (un)register ops with (un)register_peripc_operations()
+ * 2. call ipc_assign_generic() to put private data on the ipc_namespace
+ * 3. call ipc_access_generic() to access the private data
+ * 4. do not change the pointer during the lifetime of ipc_namespace
+ *
+ * Modeled after generic net-ns pointers (commit dec827d), simplified for
+ * a single user case for now:
+ * 5. only one caller can register at a time
+ * 6. caller must register at boot time (not to be used by modules)
+ */
+struct peripc_operations {
+   int (*init)(struct ipc_namespace *);
+   void (*exit)(struct ipc_namespace *);
+};
+
+static inline void ipc_assign_generic(struct ipc_namespace *ns, void *data)
+{ ns->gen = data; }
+
+static inline void *ipc_access_generic(struct ipc_namespace *ns)
+{ return ns->gen; }
+
+extern int register_peripc_ops(struct peripc_operations *ops);
+extern void unregister_peripc_ops(struct peripc_operations *ops);
+
 extern struct ipc_namespace init_ipc_ns;
 extern atomic_t nr_ipc_ns;
 
diff --git a/ipc/namespace.c b/ipc/namespace.c
index 59451c1..83968b6 100644
--- a/ipc/namespace.c
+++ b/ipc/namespace.c
@@ -33,9 +33,17 @@ static struct ipc_namespace *create_ipc_ns(struct 
user_namespace *user_ns,
}
 
atomic_set(&ns->count, 1);
+
+   err = init_peripc_ns(ns);
+   if (err) {
+   kfree(ns);
+   return ERR_PTR(err);
+   }
+
err = mq_init_ns(ns);
if (err) {
proc_free_inum(ns->proc_inum);
+   exit_peripc_ns(ns);
kfree(ns);
return ERR_PTR(err);
}
@@ -111,6 +119,7 @@ static void free_ipc_ns(struct ipc_namespace *ns)
sem_exit_ns(ns);
msg_exit_ns(ns);
shm_exit_ns(ns);
+   exit_peripc_ns(ns);
atomic_dec(&nr_ipc_ns);
 
/*
diff --git a/ipc/util.c b/ipc/util.c
index 3ae17a4..8cb9949 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -71,6 +71,66 @@ struct ipc_proc_iface {
int (*show)(struct seq_file *, void *);
 };
 
+/* allow others to piggyback on ipc_namespace */
+static DEFINE_MUTEX(peripc_mutex);
+static struct peripc_operations *peripc_ops;
+
+/*
+ * peripc_operations is a simplified pernet_operations:
+ * - allow only one entity to register
+ * - allow to register only at boot time (no modules)
+ * (these assumptions make the code much simpler)
+ */
+
+static int init_peripc_count;
+
+/* caller hold peripc_mutex */
+int init_peripc_ns(struct ipc_namespace *ns)
+{
+   int ret = 0;
+
+   if (peripc_ops && peripc_ops->init)
+   ret = peripc_ops->init(ns);
+   if (ret == 0)
+   init_peripc_count++;
+   return ret;
+}
+
+/* caller hold peripc_mutex */
+void exit_peripc_ns(struct ipc_namespace *ns)
+{
+   if (peripc_ops && peripc_ops->exit)
+   peripc_ops->exit(ns);
+   init_peripc_count--;
+}
+
+int register_peripc_ops(struct peripc_operations *ops)
+{
+   int ret = -EBUSY;
+
+   mutex_lock(&peripc_mutex);
+   /* must be first register, and only init ipc_namespace exists */
+   if (peripc_ops == NULL && init_peripc_count == 0) {
+   peripc_ops = ops;
+   ret = init_peripc_ns(&init_ipc_ns);
+   if (ret < 0)
+   peripc_ops = NULL;
+   }
+   mutex_unlock(&peripc_mutex);
+   return ret;
+}
+
+void unregister_peripc_ops(struct peripc_operations *ops)
+{
+   mutex_lock(&peripc_mutex);
+   /* sanity:  be same as registered, and no other ipc ns (beyond init) */
+   BUG_ON(peripc_ops != ops);
+   BUG_ON(init_peripc_count != 1);
+   if (ops

Re: Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver

[Linus Walleij]

On Wed, Dec 18, 2013 at 12:25 AM, Sebastian Reichel  wrote:

> I had a look at both ofono's and freesmartphone.org's implementation
> for the GPIO handling and both implementations are very similar. I
> think it should be possible to move the state machine described in
> [0] into the kernel and provide a simple sysfs/uevent interface.
>
> I was thinking of something like /sys/devices/platform/nokia-cmt/state,
> which accepts "enable", "disable" and "reset" as input and outputs the
> current state.
>
> [0] 
> https://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c

Yes this looks like kernel code shoehorned into userspace. As it
deals with suspending/resuming hardware for example, and that is
something the kernel needs to coordinate and do uniformly across
all devices (IMO).

A while back Arun Murthy was working on creating an embedded
modem subsystem but the development stopped. However such a
subsystem is a generic problem of general interest and this would be
one of the candidates for drivers/modem I think. Sadly creating it
may be a lot of work, I don't know exactly.
http://marc.info/?l=linux-kernel&m=135027904405680&w=2

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] docs: Update FireWire debugging documentation

[Lubomir Rintel]

The old firewire stack is long dead now and a new version firescope has been
released with support for current kernels.

Cc: Rob Landley 
Cc: Justin P. Mattock 
Cc: Bernhard Kaindl 
Signed-off-by: Lubomir Rintel 
---
 Documentation/debugging-via-ohci1394.txt   | 24 +---
 Documentation/power/basic-pm-debugging.txt |  2 +-
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/Documentation/debugging-via-ohci1394.txt 
b/Documentation/debugging-via-ohci1394.txt
index 611f5a5..14d1944 100644
--- a/Documentation/debugging-via-ohci1394.txt
+++ b/Documentation/debugging-via-ohci1394.txt
@@ -36,17 +36,13 @@ available (notebooks) or too slow for extensive debug 
information (like ACPI).
 Drivers
 ---
 
-The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers
-to a working state and enables physical DMA by default for all remote nodes.
-This can be turned off by ohci1394's module parameter phys_dma=0.
-
-The alternative firewire-ohci driver in drivers/firewire uses filtered physical
+The firewire-ohci driver in drivers/firewire uses filtered physical
 DMA by default, which is more secure but not suitable for remote debugging.
 Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
 Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
 DMA.
 
-Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
+Because the firewire-ohci driver depends on the PCI enumeration to be
 completed, an initialization routine which runs pretty early has been
 implemented for x86.  This routine runs long before console_init() can be
 called, i.e. before the printk buffer appears on the console.
@@ -64,7 +60,7 @@ be used to view the printk buffer of a remote machine, even 
with live update.
 
 Bernhard Kaindl enhanced firescope to support accessing 64-bit machines
 from 32-bit firescope and vice versa:
-- http://halobates.de/firewire/firescope-0.2.2.tar.bz2
+- http://v3.sk/~lkundrak/firescope/
 
 and he implemented fast system dump (alpha version - read README.txt):
 - http://halobates.de/firewire/firedump-0.1.tar.bz2
@@ -92,11 +88,11 @@ Step-by-step instructions for using firescope with early 
OHCI initialization:
 
 1) Verify that your hardware is supported:
 
-   Load the ohci1394 or the fw-ohci module and check your kernel logs.
+   Load the firewire-ohci module and check your kernel logs.
You should see a line similar to
 
-   ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18]  MMIO=[fe9ff800-fe9f]
-   ... Max Packet=[2048]  IR/IT contexts=[4/8]
+   firewire_ohci :15:00.1: added OHCI v1.0 device as card 2, 4 IR + 4 IT
+   ... contexts, quirks 0x11
 
when loading the driver. If you have no supported controller, many PCI,
CardBus and even some Express cards which are fully compliant to OHCI-1394
@@ -113,20 +109,18 @@ Step-by-step instructions for using firescope with early 
OHCI initialization:
 
If an driver is running on both machines you should see a line like
 
-   ieee1394: Node added: ID:BUS[0-01:1023]  GUID[0090270001b84bba]
+   firewire_core :15:00.1: created device fw1: GUID 00061b0020105917, S400
 
on both machines in the kernel log when the cable is plugged in
and connects the two machines.
 
 3) Test physical DMA using firescope:
 
-   On the debug host,
-   - load the raw1394 module,
-   - make sure that /dev/raw1394 is accessible,
+   On the debug host, make sure that /dev/fw* is accessible,
then start firescope:
 
$ firescope
-   Port 0 (ohci1394) opened, 2 nodes detected
+   Port 0 (/dev/fw1) opened, 2 nodes detected
 
FireScope
-
diff --git a/Documentation/power/basic-pm-debugging.txt 
b/Documentation/power/basic-pm-debugging.txt
index e9b54de8..edeecd4 100644
--- a/Documentation/power/basic-pm-debugging.txt
+++ b/Documentation/power/basic-pm-debugging.txt
@@ -172,7 +172,7 @@ you can boot the kernel with the 'no_console_suspend' 
parameter and try to log
 kernel messages using the serial console.  This may provide you with some
 information about the reasons of the suspend (resume) failure.  Alternatively,
 it may be possible to use a FireWire port for debugging with firescope
-(ftp://ftp.firstfloor.org/pub/ak/firescope/).  On x86 it is also possible to
+(http://v3.sk/~lkundrak/firescope/).  On x86 it is also possible to
 use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt .
 
 2. Testing suspend to RAM (STR)
-- 
1.8.4.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/

[PATCH] ohci: Turn remote DMA support into a module parameter

[Lubomir Rintel]

This makes it possible to debug kernel over FireWire without the need to
recompile it.

Cc: Stefan Richter 
Cc: Dave Hansen 
Signed-off-by: Lubomir Rintel 
---
 Documentation/debugging-via-ohci1394.txt |  4 +---
 drivers/firewire/ohci.c  | 19 +++
 lib/Kconfig.debug| 11 ---
 3 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/Documentation/debugging-via-ohci1394.txt 
b/Documentation/debugging-via-ohci1394.txt
index 14d1944..73473aa 100644
--- a/Documentation/debugging-via-ohci1394.txt
+++ b/Documentation/debugging-via-ohci1394.txt
@@ -38,9 +38,7 @@ Drivers
 
 The firewire-ohci driver in drivers/firewire uses filtered physical
 DMA by default, which is more secure but not suitable for remote debugging.
-Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
-Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
-DMA.
+Pass the remote_dma=1 parameter to the driver to get unfiltered physical DMA.
 
 Because the firewire-ohci driver depends on the PCI enumeration to be
 completed, an initialization routine which runs pretty early has been
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index 6aa8a86..6313735 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -370,6 +370,10 @@ MODULE_PARM_DESC(debug, "Verbose logging (default = 0"
", busReset events = "  __stringify(OHCI_PARAM_DEBUG_BUSRESETS)
", or a combination, or all = -1)");
 
+static bool param_remote_dma;
+module_param_named(remote_dma, param_remote_dma, bool, 0444);
+MODULE_PARM_DESC(remote_dma, "Enable unfiltered remote DMA (default = 0)");
+
 static void log_irqs(struct fw_ohci *ohci, u32 evt)
 {
if (likely(!(param_debug &
@@ -2050,10 +2054,10 @@ static void bus_reset_work(struct work_struct *work)
  be32_to_cpu(ohci->next_header));
}
 
-#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
-   reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
-   reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
-#endif
+   if (param_remote_dma) {
+   reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
+   reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
+   }
 
spin_unlock_irq(&ohci->lock);
 
@@ -2587,13 +2591,13 @@ static int ohci_cancel_packet(struct fw_card *card, 
struct fw_packet *packet)
 static int ohci_enable_phys_dma(struct fw_card *card,
int node_id, int generation)
 {
-#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
-   return 0;
-#else
struct fw_ohci *ohci = fw_ohci(card);
unsigned long flags;
int n, ret = 0;
 
+   if (param_remote_dma)
+   return 0;
+
/*
 * FIXME:  Make sure this bitmask is cleared when we clear the busReset
 * interrupt bit.  Clear physReqResourceAllBuses on bus reset.
@@ -2622,7 +2626,6 @@ static int ohci_enable_phys_dma(struct fw_card *card,
spin_unlock_irqrestore(&ohci->lock, flags);
 
return ret;
-#endif /* CONFIG_FIREWIRE_OHCI_REMOTE_DMA */
 }
 
 static u32 ohci_read_csr(struct fw_card *card, int csr_offset)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index db25707..dc30284 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1547,17 +1547,6 @@ config PROVIDE_OHCI1394_DMA_INIT
 
  See Documentation/debugging-via-ohci1394.txt for more information.
 
-config FIREWIRE_OHCI_REMOTE_DMA
-   bool "Remote debugging over FireWire with firewire-ohci"
-   depends on FIREWIRE_OHCI
-   help
- This option lets you use the FireWire bus for remote debugging
- with help of the firewire-ohci driver. It enables unfiltered
- remote DMA in firewire-ohci.
- See Documentation/debugging-via-ohci1394.txt for more information.
-
- If unsure, say N.
-
 config BUILD_DOCSRC
bool "Build targets in Documentation/ tree"
depends on HEADERS_CHECK
-- 
1.8.4.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 2/2] binder: implement namepsace support for Android binder driver

[Stefan Beller]

>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "binder.h"
>  #include "binder_trace.h"
>  
> +/*
> + * Using a private context manager for each binder namespace is sufficient
> + * to isolate between namespaces, because in binder all IPC must be realized
> + * via hanldes obtained from the context manager.

handles

> + *
> + * TODO: currently, most debugfs data is not tracked per binder namespaces.
> + * Except for "procs" which are properly virtualized, everything else is
> + * global, including stats, logs, and dead nodes.
> + */
> +struct binder_namespace {
> + struct kref kref;
> +
> + struct binder_node *context_mgr_node;
> + kuid_t context_mgr_uid;
> + int last_id;

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

fff4068cba48: +82.0% vm-scalability.throughput

[fengguang . wu]

Johannes,

I'm glad to report that the below commit results in large increase of
performance in our vm-scalability/1T-anon-w-seq testcase.

commit fff4068cba484e6b0abe334ed6b15d5a215a3b25
Author: Johannes Weiner 
Date:   Fri Dec 20 14:54:12 2013 +

mm: page_alloc: revert NUMA aspect of fair allocation policy

Signed-off-by: Johannes Weiner 
Reviewed-by: Michal Hocko 
Signed-off-by: Mel Gorman 
Cc:  # 3.12
Signed-off-by: Linus Torvalds 

The detailed numbers are

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  27965631 ~ 0% +82.0%   50892168 ~ 0%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  27965631  +82.0%   50892168   TOTAL vm-scalability.throughput

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  24936524 ~ 0% -99.8%  58291 ~37%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  24936524  -99.8%  58291   TOTAL numa-vmstat.node3.numa_other

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  4186 ~ 9% -99.8%  9 ~35%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  4186  -99.8%  9   TOTAL 
numa-vmstat.node3.nr_inactive_anon

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  49623735 ~ 0%-100.0%  0 ~200%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  49623735 -100.0%  0   TOTAL numa-numastat.node3.other_node

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  25510007 ~ 0% -99.8%  44126 ~49%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  25510007  -99.8%  44126   TOTAL numa-vmstat.node2.numa_other

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  4543 ~ 4% -98.2% 80 ~43%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  4543  -98.2% 80   TOTAL numa-vmstat.node2.nr_shmem

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  4428 ~ 1% -99.2% 35 ~100%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  4428  -99.2% 35   TOTAL 
numa-vmstat.node2.nr_inactive_anon

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  50735073 ~ 0%-100.0%  0 ~133%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  50735073 -100.0%  0   TOTAL numa-numastat.node2.other_node

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  25892047 ~ 0% -99.7%  69142 ~ 0%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  25892047  -99.7%  69142   TOTAL numa-vmstat.node1.numa_other

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  4244 ~ 9% -99.6% 16 ~25%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  4244  -99.6% 16   TOTAL numa-vmstat.node3.nr_shmem

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  32472773 ~ 0% -99.9%  35954 ~74%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  32472773  -99.9%  35954   TOTAL numa-vmstat.node0.numa_other

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
  51431667 ~ 0%-100.0%  3 ~35%  
brickland2/micro/vm-scalability/1T-anon-w-seq
  51431667 -100.0%  3   TOTAL numa-numastat.node1.other_node

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
 16988 ~ 9% -99.6% 67 ~26%  
brickland2/micro/vm-scalability/1T-anon-w-seq
 16988  -99.6% 67   TOTAL numa-meminfo.node3.Shmem

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
 16756 ~ 9% -99.8% 38 ~36%  
brickland2/micro/vm-scalability/1T-anon-w-seq
 16756  -99.8% 38   TOTAL 
numa-meminfo.node3.Inactive(anon)

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
 18184 ~ 4% -98.2%325 ~43%  
brickland2/micro/vm-scalability/1T-anon-w-seq
 18184  -98.2%325   TOTAL numa-meminfo.node2.Shmem

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
 17723 ~ 1% -99.2%142 ~98%  
brickland2/micro/vm-scalability/1T-anon-w-seq
 17723  -99.2%142   TOTAL 
numa-meminfo.node2.Inactive(anon)

8798cee2f90292c  fff4068cba484e6b0abe334ed  
---  -  
   351 ~ 6% -80.0% 70 ~ 5%  
brickland2/micro/vm-scalability/1T-anon-w-seq
   351  -80.0% 70   TOTAL buddyinfo.Node.3.zone.Normal.9

8798cee2f90292c  fff4068cba484e6b0abe334e

Re: [PATCHSET 00/17] tracing/uprobes: Add support for more fetch methods (v9)

[Namhyung Kim]

Hi Steve,

2013-12-21 (토), 00:22 -0500, Steven Rostedt:
> I applied all the patches and started testing and it failed to build,
> with this error:
> 
> 
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c: In 
> function ‘kprobe_trace_self_tests_init’:
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1400:7: 
> error: ‘create_trace_probe’ undeclared (first use in this function)
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1400:7: 
> note: each undeclared identifier is reported only once for each function it 
> appears in
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1406:3: 
> error: implicit declaration of function ‘find_trace_probe’ 
> [-Werror=implicit-function-declaration]
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1406:6: 
> warning: assignment makes pointer from integer without a cast [enabled by 
> default]
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1416:5: 
> error: implicit declaration of function ‘enable_trace_probe’ 
> [-Werror=implicit-function-declaration]
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1427:6: 
> warning: assignment makes pointer from integer without a cast [enabled by 
> default]
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1447:5: 
> warning: assignment makes pointer from integer without a cast [enabled by 
> default]
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1457:4: 
> error: implicit declaration of function ‘disable_trace_probe’ 
> [-Werror=implicit-function-declaration]
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1460:5: 
> warning: assignment makes pointer from integer without a cast [enabled by 
> default]
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c:1486:2: 
> error: implicit declaration of function ‘release_all_trace_probes’ 
> [-Werror=implicit-function-declaration
> ]
> cc1: some warnings being treated as errors
> distcc[17703] ERROR: compile 
> /home/rostedt/work/git/linux-trace.git/kernel/trace/trace_kprobe.c on 
> localhost failed
> make[3]: *** [kernel/trace/trace_kprobe.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> 
> I applied it to my "ftrace/core" branch.
> 
> I attached my config.

Oops, sorry.  I forgot to enable FTRACE_STARTUP_TEST.  I've fixed it,
rebased it onto ftrace/core and pushed to my "uprobe/fetch-v10" branch.
Please test it again when you have time. :)

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/

[GIT PULL] RAS for 3.14, p2

[Borislav Petkov]

Hi guys,

this is a second set of smallish stuff for 3.14.

Please pull.

Thanks.

--
The following changes since commit 42139eb356e3384759ca143ae04d82376346eb4c:

  ACPI, eMCA: Combine eMCA/EDAC event reporting priority (2013-12-11 19:04:37 
+0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/ras_for_3.14_p2

for you to fetch changes up to ca104edc17841da87850b20ab77e57fe0a99ead6:

  ACPI, APEI, GHES: Cleanup ghes memory error handling (2013-12-21 13:35:59 
+0100)


SCI reporting for other error types not only correctable ones
+ APEI GHES cleanups


Chen, Gong (3):
  ACPI, APEI, GHES: Do not report only correctable errors with SCI
  ACPI, APEI: Cleanup alignment-aware accesses
  ACPI, APEI, GHES: Cleanup ghes memory error handling

 arch/x86/kernel/cpu/mcheck/mce-apei.c | 14 ++
 drivers/acpi/apei/apei-base.c |  4 ++--
 drivers/acpi/apei/einj.c  | 19 +--
 drivers/acpi/apei/erst.c  |  2 +-
 drivers/acpi/apei/ghes.c  | 39 
+--
 5 files changed, 43 insertions(+), 35 deletions(-)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[git pull] FireWire fixlet

[Stefan Richter]

Linus,

please pull from the tag "firewire-fix" at

git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git 
firewire-fix

to receive a one-liner fix/ revert.  This reenables WRITE SAME over SBP-2
like in v3.8...v3.12 (or v3.8-rc1...v3.13-rc2 to be overly precise).
Buggy targets which could malfunction when being subjected to this command
are already sufficiently protected by a scsi_level check in sd + SCSI core.

Stefan Richter (1):
  firewire: sbp2: bring back WRITE SAME support

 drivers/firewire/sbp2.c | 1 -
 1 file changed, 1 deletion(-)

>From ce027ed98fd176710fb14be9d6015697b62436f0 Mon Sep 17 00:00:00 2001
From: Stefan Richter 
Date: Sun, 15 Dec 2013 16:18:01 +0100
Subject: [PATCH] firewire: sbp2: bring back WRITE SAME support

Commit 54b2b50c20a6 "[SCSI] Disable WRITE SAME for RAID and virtual
host adapter drivers" disabled WRITE SAME support for all SBP-2 attached
targets.  But as described in the changelog of commit b0ea5f19d3d8
"firewire: sbp2: allow WRITE SAME and REPORT SUPPORTED OPERATION CODES",
it is not required to blacklist WRITE SAME.

Bring the feature back by reverting the sbp2.c hunk of commit 54b2b50c20a6.

Signed-off-by: Stefan Richter 
Cc: sta...@kernel.org
---
 drivers/firewire/sbp2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/firewire/sbp2.c b/drivers/firewire/sbp2.c
index b0bb056458a3..281029daf98c 100644
--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
@@ -1623,7 +1623,6 @@ static struct scsi_host_template scsi_driver_template = {
.cmd_per_lun= 1,
.can_queue  = 1,
.sdev_attrs = sbp2_scsi_sysfs_attrs,
-   .no_write_same  = 1,
 };
 
 MODULE_AUTHOR("Kristian Hoegsberg ");
-- 
Stefan Richter
-=-===-= ==-- =-==-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma-buf: avoid using IS_ERR_OR_NULL

[Mauro Carvalho Chehab]

Em Sat, 21 Dec 2013 07:42:17 -0500
Rob Clark  escreveu:

> On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross  wrote:
> > dma_buf_map_attachment and dma_buf_vmap can return NULL or
> > ERR_PTR on a error.  This encourages a common buggy pattern in
> > callers:
> > sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> > if (IS_ERR_OR_NULL(sgt))
> > return PTR_ERR(sgt);
> >
> > This causes the caller to return 0 on an error.  IS_ERR_OR_NULL
> > is almost always a sign of poorly-defined error handling.
> >
> > This patch converts dma_buf_map_attachment to always return
> > ERR_PTR, and fixes the callers that incorrectly handled NULL.
> > There are a few more callers that were not checking for NULL
> > at all, which would have dereferenced a NULL pointer later.
> > There are also a few more callers that correctly handled NULL
> > and ERR_PTR differently, I left those alone but they could also
> > be modified to delete the NULL check.
> >
> > This patch also converts dma_buf_vmap to always return NULL.
> > All the callers to dma_buf_vmap only check for NULL, and would
> > have dereferenced an ERR_PTR and panic'd if one was ever
> > returned. This is not consistent with the rest of the dma buf
> > APIs, but matches the expectations of all of the callers.
> >
> > Signed-off-by: Colin Cross 
> > ---
> >  drivers/base/dma-buf.c | 18 +++---
> >  drivers/gpu/drm/drm_prime.c|  2 +-
> >  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  2 +-
> >  drivers/media/v4l2-core/videobuf2-dma-contig.c |  2 +-
> >  4 files changed, 14 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> > index 1e16cbd61da2..cfe1d8bc7bb8 100644
> > --- a/drivers/base/dma-buf.c
> > +++ b/drivers/base/dma-buf.c
> > @@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> >   * @dmabuf:[in]buffer to attach device to.
> >   * @dev:   [in]device to be attached.
> >   *
> > - * Returns struct dma_buf_attachment * for this attachment; may return 
> > negative
> > - * error codes.
> > - *
> > + * Returns struct dma_buf_attachment * for this attachment; returns 
> > ERR_PTR on
> > + * error.
> >   */
> >  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> >   struct device *dev)
> > @@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
> >   * @attach:[in]attachment whose scatterlist is to be returned
> >   * @direction: [in]direction of DMA transfer
> >   *
> > - * Returns sg_table containing the scatterlist to be returned; may return 
> > NULL
> > - * or ERR_PTR.
> > - *
> > + * Returns sg_table containing the scatterlist to be returned; returns 
> > ERR_PTR
> > + * on error.
> >   */
> >  struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
> > enum dma_data_direction direction)
> > @@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct 
> > dma_buf_attachment *attach,
> > return ERR_PTR(-EINVAL);
> >
> > sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> > +   if (!sg_table)
> > +   sg_table = ERR_PTR(-ENOMEM);
> >
> > return sg_table;
> >  }
> > @@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
> >   * These calls are optional in drivers. The intended use for them
> >   * is for mapping objects linear in kernel space for high use objects.
> >   * Please attempt to use kmap/kunmap before thinking about these 
> > interfaces.
> > + *
> > + * Returns NULL on error.
> >   */
> >  void *dma_buf_vmap(struct dma_buf *dmabuf)
> >  {
> > @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
> > BUG_ON(dmabuf->vmap_ptr);
> >
> > ptr = dmabuf->ops->vmap(dmabuf);
> > -   if (IS_ERR_OR_NULL(ptr))
> > +   if (WARN_ON_ONCE(IS_ERR(ptr)))
> 
> since vmap is optional, the WARN_ON might be a bit strong..  although
> it would be a bit strange for an exporter to supply a vmap fxn which
> always returned NULL, not sure about that.  Just thought I'd mention
> it in case anyone else had an opinion about that.
> 
> But either way:
> 
> Reviewed-by: Rob Clark 

IMHO, a WARN_ON_ONCE() here (or some other error report printk) seems ok, 
as, if this function is called, the caller would be expecting it to not
fail.

Either way:

Reviewed-by: Mauro Carvalho Chehab 

> 
> 
> > +   ptr = NULL;
> > +   if (!ptr)
> > goto out_unlock;
> >
> > dmabuf->vmap_ptr = ptr;
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 56805c39c906..bb516fdd195d 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -471,7 +471,7 @@ struct drm_gem_object *drm_gem_prime_import(struct 
> > drm_device *dev,
> > get_dma_buf(dma_buf);
> >
> > sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> >

Re: [PATCH] secure unlock_task_sighand() call

[Oleg Nesterov]

Naveen,

sorry for the terse and neglectful reply yesterday.

Actually, when I re-read the Linus's email, I think he already explained
everything, so let me repeat:

On 12/21, Linus Torvalds wrote:
>
> Did you actually *see* the problem, or was this just from looking at the code?

Yes. Because this code assumes that lock_task_sighand() must not fail.
If it fails, we have a problem which should be fixed.

> We have coredump serialization in exit_mm() that I think *should* make
> this all ok - if we still see p->mm matching our mm, I don't think it
> should be able to get to __exit_signal() and make the sighand go away,
> so the lock_task_sighand() shouldn't ever fail.

Yes, exactly.

Note that if we ignore exec, we do not need lock_task_sighand() at all,
we could simply do spin_lock_irq(p->sighand->siglock).

The caller holds mm->mmap_sem for writing, if we see p->mm == mm it
simply can not pass exit_mm() which does down_read(&mm->mmap_sem), so
this task can not exit.

The problem is, this task can change its ->sighand in de_thread(), that
is why we need lock_task_sighand(). But if it does exec, it can't pass
exec_mmap() by the same reason, we hold mmap_sem.

> > if (p->mm) {
> > if (unlikely(p->mm == mm)) {
> > -   lock_task_sighand(p, &flags);
> > -   nr += zap_process(p, exit_code);
> > -   unlock_task_sighand(p, &flags);
> > +   if (lock_task_sighand(p, &flags) {
> > +   nr += zap_process(p, 
> > exit_code);

But we can't silently skip a process with the same ->mm. We can't even
skip the execing thread task if it is going to change its ->mm, even if
it is single-threaded. Note that exec_mmap() will notice mm->core_state
and fail. So every task with the same mm should be accounted because it
will play with core_state->nr_threads in exit_mm(). And it should be
killed because otherwise coredump_wait() can sleep "forever".

So this is not the right change in any case. If lock_task_sighand() can
fail we should fix something else.

Oleg.

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

Re: [PATCH] skip increamenting nr for TASK_UNINTERRUPTIBLE

[Oleg Nesterov]

Vaibhav,

again, I think that everything was explained by Linus, let me
add some details.

> > In coredump case, where thread_1 faults while thread_2 is in
> > TASK_UNINTERRUPTIBLE state, it cannot handle the SIGKILL.
> > Thus the process hangs on event.
> > The coredump routine freezes until the thread state is
> > uninterruptible.

Yes. But why we should even try to "fix" coredump in this case?

> > Solution: Continue for coredump, without waiting for uninterruptible
> >  thread,

This can't work, please see below.

> > as it will get killed as soon as it returns from
> >  uninterruptible state.

Not necessarily. It can play with ->mm before it notices the pending
SIGKILL. And, if nothing else, the coredumping paths do not even take
mmap_sem because we assume that the dumper is the only user.

But even if this doesn't happen,

> >  Therefore do not increament thread count for threads with
> >  TASK_UNINTERRUPTIBLE.

This is very wrong too. This means that we can start the coredump before
the _accounted_ thread exits (because a skipped thread can exit first and
decrement the counter). This also means that coredump_finish() can race
with the unaccounted threads.

> >   sigaddset(&t->pending.signal, SIGKILL);
> >   signal_wake_up(t, 1);
> > - nr++;
> > + if(!(t->state & TASK_UNINTERRUPTIBLE))
> > + nr++;

Again, we can't simply check t->state & TASK_UNINTERRUPTIBLE. This can
be false positive or it can sleep in TASK_UNINTERRUPTIBLE right after
the check. And even "& TASK_UNINTERRUPTIBLE" is wrong, please look at
TASK_KILLABLE.

Oleg.

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

[PATCH v7 0/7] Optimize jump label implementation for ARM64

[Jiang Liu]

This patchset tries to optimize arch specfic jump label implementation
for ARM64 by dynamic kernel text patching.

To enable this feature, your toolchain must support "asm goto" extension
and "%c" constraint extesion. Current GCC for AARCH64 doesn't support
"%c", and there's a patch for it now:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01314.html

It has been tested on ARM Fast mode and a real hardware platform.

Any comments are welcomed!

V6->V7:
1) Minor format clean up
2) Remove smp_mb() pair

V5->V6:
1) optimize stop_machine() related code
2) simplify aarch64_insn_patch_text_nosync() interface
3) refine comments

V4->V5:
1) rework the stop_machine() related code
2) rework aarch64_insn_gen_nop()

V3->V4:
1) resolve a race condition in kernel text patching
2) address other review comments

V2->V3:
1) fix a bug in comparing signed and unsigned values
2) detect big endian by checking __AARCH64EB__

V1->V2: address review comments of V1
1) refine comments
2) add a new interface to always synchronize with stop_machine()
   when patching code
3) handle endian issue when patching code

Jiang Liu (7):
  arm64: introduce basic aarch64 instruction decoding helpers
  arm64: introduce interfaces to hotpatch kernel and module code
  arm64: move encode_insn_immediate() from module.c to insn.c
  arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions
  arm64, jump label: detect %c support for ARM64
  arm64, jump label: optimize jump label implementation
  jump_label: use defined macros instead of hard-coding for better
readability

 arch/arm64/Kconfig  |   1 +
 arch/arm64/include/asm/insn.h   | 108 +
 arch/arm64/include/asm/jump_label.h |  51 ++
 arch/arm64/kernel/Makefile  |   3 +-
 arch/arm64/kernel/insn.c| 304 
 arch/arm64/kernel/jump_label.c  |  58 +++
 arch/arm64/kernel/module.c  | 157 ++-
 include/linux/jump_label.h  |  19 ++-
 scripts/gcc-goto.sh |   2 +-
 9 files changed, 584 insertions(+), 119 deletions(-)
 create mode 100644 arch/arm64/include/asm/insn.h
 create mode 100644 arch/arm64/include/asm/jump_label.h
 create mode 100644 arch/arm64/kernel/insn.c
 create mode 100644 arch/arm64/kernel/jump_label.c

-- 
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/

[PATCH v7 1/7] arm64: introduce basic aarch64 instruction decoding helpers

[Jiang Liu]

Introduce basic aarch64 instruction decoding helper
aarch64_get_insn_class() and aarch64_insn_hotpatch_safe().

Reviewed-by: Will Deacon 
Signed-off-by: Jiang Liu 
---
 arch/arm64/include/asm/insn.h | 77 
 arch/arm64/kernel/Makefile|  2 +-
 arch/arm64/kernel/insn.c  | 91 +++
 3 files changed, 169 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/include/asm/insn.h
 create mode 100644 arch/arm64/kernel/insn.c

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
new file mode 100644
index 000..1bdc44c
--- /dev/null
+++ b/arch/arm64/include/asm/insn.h
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu 
+ *
+ * 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
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef__ASM_INSN_H
+#define__ASM_INSN_H
+#include 
+
+/*
+ * ARM Architecture Reference Manual for ARMv8 Profile-A, Issue A.a
+ * Section C3.1 "A64 instruction index by encoding":
+ * AArch64 main encoding table
+ *  Bit position
+ *   28 27 26 25   Encoding Group
+ *   0  0  -  -Unallocated
+ *   1  0  0  -Data processing, immediate
+ *   1  0  1  -Branch, exception generation and system 
instructions
+ *   -  1  -  0Loads and stores
+ *   -  1  0  1Data processing - register
+ *   0  1  1  1Data processing - SIMD and floating point
+ *   1  1  1  1Data processing - SIMD and floating point
+ * "-" means "don't care"
+ */
+enum aarch64_insn_encoding_class {
+   AARCH64_INSN_CLS_UNKNOWN,   /* UNALLOCATED */
+   AARCH64_INSN_CLS_DP_IMM,/* Data processing - immediate */
+   AARCH64_INSN_CLS_DP_REG,/* Data processing - register */
+   AARCH64_INSN_CLS_DP_FPSIMD, /* Data processing - SIMD and FP */
+   AARCH64_INSN_CLS_LDST,  /* Loads and stores */
+   AARCH64_INSN_CLS_BR_SYS,/* Branch, exception generation and
+* system instructions */
+};
+
+enum aarch64_insn_hint_op {
+   AARCH64_INSN_HINT_NOP   = 0x0 << 5,
+   AARCH64_INSN_HINT_YIELD = 0x1 << 5,
+   AARCH64_INSN_HINT_WFE   = 0x2 << 5,
+   AARCH64_INSN_HINT_WFI   = 0x3 << 5,
+   AARCH64_INSN_HINT_SEV   = 0x4 << 5,
+   AARCH64_INSN_HINT_SEVL  = 0x5 << 5,
+};
+
+#define__AARCH64_INSN_FUNCS(abbr, mask, val)   \
+static __always_inline bool aarch64_insn_is_##abbr(u32 code) \
+{ return (code & (mask)) == (val); } \
+static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
+{ return (val); }
+
+__AARCH64_INSN_FUNCS(b,0xFC00, 0x1400)
+__AARCH64_INSN_FUNCS(bl,   0xFC00, 0x9400)
+__AARCH64_INSN_FUNCS(svc,  0xFFE0001F, 0xD401)
+__AARCH64_INSN_FUNCS(hvc,  0xFFE0001F, 0xD402)
+__AARCH64_INSN_FUNCS(smc,  0xFFE0001F, 0xD403)
+__AARCH64_INSN_FUNCS(brk,  0xFFE0001F, 0xD420)
+__AARCH64_INSN_FUNCS(hint, 0xF01F, 0xD503201F)
+
+#undef __AARCH64_INSN_FUNCS
+
+bool aarch64_insn_is_nop(u32 insn);
+
+enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+
+bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
+
+#endif /* __ASM_INSN_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 5ba2fd4..cd95a25 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -9,7 +9,7 @@ AFLAGS_head.o   := -DTEXT_OFFSET=$(TEXT_OFFSET)
 arm64-obj-y:= cputable.o debug-monitors.o entry.o irq.o fpsimd.o   
\
   entry-fpsimd.o process.o ptrace.o setup.o signal.o   
\
   sys.o stacktrace.o time.o traps.o io.o vdso.o
\
-  hyp-stub.o psci.o cpu_ops.o
+  hyp-stub.o psci.o cpu_ops.o insn.o
 
 arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o 
\
   sys_compat.o
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
new file mode 100644
index 000..56a2498
--- /dev/null
+++ b/arch/arm64/kernel/insn.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu 
+ *
+ * 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
+ * published by the Free Software Foundatio

[PATCH v7 3/7] arm64: move encode_insn_immediate() from module.c to insn.c

[Jiang Liu]

Function encode_insn_immediate() will be used by other instruction
manipulate related functions, so move it into insn.c and rename it
as aarch64_insn_encode_immediate().

Reviewed-by: Will Deacon 
Signed-off-by: Jiang Liu 
---
 arch/arm64/include/asm/insn.h |  13 
 arch/arm64/kernel/insn.c  |  54 +++
 arch/arm64/kernel/module.c| 157 +-
 3 files changed, 114 insertions(+), 110 deletions(-)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index bf8085f..fb44660 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -55,6 +55,17 @@ enum aarch64_insn_hint_op {
AARCH64_INSN_HINT_SEVL  = 0x5 << 5,
 };
 
+enum aarch64_insn_imm_type {
+   AARCH64_INSN_IMM_ADR,
+   AARCH64_INSN_IMM_26,
+   AARCH64_INSN_IMM_19,
+   AARCH64_INSN_IMM_16,
+   AARCH64_INSN_IMM_14,
+   AARCH64_INSN_IMM_12,
+   AARCH64_INSN_IMM_9,
+   AARCH64_INSN_IMM_MAX
+};
+
 #define__AARCH64_INSN_FUNCS(abbr, mask, val)   \
 static __always_inline bool aarch64_insn_is_##abbr(u32 code) \
 { return (code & (mask)) == (val); } \
@@ -76,6 +87,8 @@ bool aarch64_insn_is_nop(u32 insn);
 int aarch64_insn_read(void *addr, u32 *insnp);
 int aarch64_insn_write(void *addr, u32 insn);
 enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
+ u32 insn, u64 imm);
 bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
 
 int aarch64_insn_patch_text_nosync(void *addr, u32 insn);
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index b9dac57..7df0807 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -208,3 +208,57 @@ int __kprobes aarch64_insn_patch_text(void *addrs[], u32 
insns[], int cnt)
 
return aarch64_insn_patch_text_sync(addrs, insns, cnt);
 }
+
+u32 __kprobes aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
+ u32 insn, u64 imm)
+{
+   u32 immlo, immhi, lomask, himask, mask;
+   int shift;
+
+   switch (type) {
+   case AARCH64_INSN_IMM_ADR:
+   lomask = 0x3;
+   himask = 0x7;
+   immlo = imm & lomask;
+   imm >>= 2;
+   immhi = imm & himask;
+   imm = (immlo << 24) | (immhi);
+   mask = (lomask << 24) | (himask);
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_26:
+   mask = BIT(26) - 1;
+   shift = 0;
+   break;
+   case AARCH64_INSN_IMM_19:
+   mask = BIT(19) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_16:
+   mask = BIT(16) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_14:
+   mask = BIT(14) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_12:
+   mask = BIT(12) - 1;
+   shift = 10;
+   break;
+   case AARCH64_INSN_IMM_9:
+   mask = BIT(9) - 1;
+   shift = 12;
+   break;
+   default:
+   pr_err("aarch64_insn_encode_immediate: unknown immediate 
encoding %d\n",
+   type);
+   return 0;
+   }
+
+   /* Update the immediate field. */
+   insn &= ~(mask << shift);
+   insn |= (imm & mask) << shift;
+
+   return insn;
+}
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index e2ad0d8..1eb1cc9 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -25,6 +25,10 @@
 #include 
 #include 
 #include 
+#include 
+
+#defineAARCH64_INSN_IMM_MOVNZ  AARCH64_INSN_IMM_MAX
+#defineAARCH64_INSN_IMM_MOVK   AARCH64_INSN_IMM_16
 
 void *module_alloc(unsigned long size)
 {
@@ -94,28 +98,18 @@ static int reloc_data(enum aarch64_reloc_op op, void 
*place, u64 val, int len)
return 0;
 }
 
-enum aarch64_imm_type {
-   INSN_IMM_MOVNZ,
-   INSN_IMM_MOVK,
-   INSN_IMM_ADR,
-   INSN_IMM_26,
-   INSN_IMM_19,
-   INSN_IMM_16,
-   INSN_IMM_14,
-   INSN_IMM_12,
-   INSN_IMM_9,
-};
-
-static u32 encode_insn_immediate(enum aarch64_imm_type type, u32 insn, u64 imm)
+static int reloc_insn_movw(enum aarch64_reloc_op op, void *place, u64 val,
+  int lsb, enum aarch64_insn_imm_type imm_type)
 {
-   u32 immlo, immhi, lomask, himask, mask;
-   int shift;
+   u64 imm, limit = 0;
+   s64 sval;
+   u32 insn = le32_to_cpu(*(u32 *)place);
 
-   /* The instruction stream is always little endian. */
-   insn = le32_to_cpu(insn);
+   sval = do_reloc(op, place, val);
+   sval >>= lsb;
+   imm = sval & 0x;
 
-   switch (type) {
-   case INSN_IMM_MOVNZ:
+   if (imm_type == AARCH64_INSN_IMM

[PATCH v7 2/7] arm64: introduce interfaces to hotpatch kernel and module code

[Jiang Liu]

Introduce three interfaces to patch kernel and module code:
aarch64_insn_patch_text_nosync():
patch code without synchronization, it's caller's responsibility
to synchronize all CPUs if needed.
aarch64_insn_patch_text_sync():
patch code and always synchronize with stop_machine()
aarch64_insn_patch_text():
patch code and synchronize with stop_machine() if needed

Signed-off-by: Jiang Liu 
---
 arch/arm64/include/asm/insn.h |  10 +++-
 arch/arm64/kernel/insn.c  | 119 ++
 2 files changed, 128 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 1bdc44c..bf8085f 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -18,6 +18,9 @@
 #define__ASM_INSN_H
 #include 
 
+/* A64 instructions are always 32 bits. */
+#defineAARCH64_INSN_SIZE   4
+
 /*
  * ARM Architecture Reference Manual for ARMv8 Profile-A, Issue A.a
  * Section C3.1 "A64 instruction index by encoding":
@@ -70,8 +73,13 @@ __AARCH64_INSN_FUNCS(hint,   0xF01F, 0xD503201F)
 
 bool aarch64_insn_is_nop(u32 insn);
 
+int aarch64_insn_read(void *addr, u32 *insnp);
+int aarch64_insn_write(void *addr, u32 insn);
 enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
-
 bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
 
+int aarch64_insn_patch_text_nosync(void *addr, u32 insn);
+int aarch64_insn_patch_text_sync(void *addrs[], u32 insns[], int cnt);
+int aarch64_insn_patch_text(void *addrs[], u32 insns[], int cnt);
+
 #endif /* __ASM_INSN_H */
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 56a2498..b9dac57 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -16,6 +16,10 @@
  */
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
 static int aarch64_insn_encoding_class[] = {
@@ -60,6 +64,28 @@ bool __kprobes aarch64_insn_is_nop(u32 insn)
}
 }
 
+/*
+ * In ARMv8-A, A64 instructions have a fixed length of 32 bits and are always
+ * little-endian.
+ */
+int __kprobes aarch64_insn_read(void *addr, u32 *insnp)
+{
+   int ret;
+   u32 val;
+
+   ret = probe_kernel_read(&val, addr, AARCH64_INSN_SIZE);
+   if (!ret)
+   *insnp = le32_to_cpu(val);
+
+   return ret;
+}
+
+int __kprobes aarch64_insn_write(void *addr, u32 insn)
+{
+   insn = cpu_to_le32(insn);
+   return probe_kernel_write(addr, &insn, AARCH64_INSN_SIZE);
+}
+
 static bool __kprobes __aarch64_insn_hotpatch_safe(u32 insn)
 {
if (aarch64_get_insn_class(insn) != AARCH64_INSN_CLS_BR_SYS)
@@ -89,3 +115,96 @@ bool __kprobes aarch64_insn_hotpatch_safe(u32 old_insn, u32 
new_insn)
return __aarch64_insn_hotpatch_safe(old_insn) &&
   __aarch64_insn_hotpatch_safe(new_insn);
 }
+
+int __kprobes aarch64_insn_patch_text_nosync(void *addr, u32 insn)
+{
+   u32 *tp = addr;
+   int ret;
+
+   /* A64 instructions must be word aligned */
+   if ((uintptr_t)tp & 0x3)
+   return -EINVAL;
+
+   ret = aarch64_insn_write(tp, insn);
+   if (ret == 0)
+   flush_icache_range((uintptr_t)tp,
+  (uintptr_t)tp + AARCH64_INSN_SIZE);
+
+   return ret;
+}
+
+struct aarch64_insn_patch {
+   void**text_addrs;
+   u32 *new_insns;
+   int insn_cnt;
+   atomic_tcpu_count;
+};
+
+static int __kprobes aarch64_insn_patch_text_cb(void *arg)
+{
+   int i, ret = 0;
+   struct aarch64_insn_patch *pp = arg;
+
+   /* The first CPU becomes master */
+   if (atomic_inc_return(&pp->cpu_count) == 1) {
+   for (i = 0; ret == 0 && i < pp->insn_cnt; i++)
+   ret = aarch64_insn_patch_text_nosync(pp->text_addrs[i],
+pp->new_insns[i]);
+   /*
+* aarch64_insn_patch_text_nosync() calls flush_icache_range(),
+* which ends with "dsb; isb" pair guaranteeing global
+* visibility.
+*/
+   atomic_set(&pp->cpu_count, -1);
+   } else {
+   while (atomic_read(&pp->cpu_count) != -1)
+   cpu_relax();
+   isb();
+   }
+
+   return ret;
+}
+
+int __kprobes aarch64_insn_patch_text_sync(void *addrs[], u32 insns[], int cnt)
+{
+   struct aarch64_insn_patch patch = {
+   .text_addrs = addrs,
+   .new_insns = insns,
+   .insn_cnt = cnt,
+   .cpu_count = ATOMIC_INIT(0),
+   };
+
+   if (cnt <= 0)
+   return -EINVAL;
+
+   return stop_machine(aarch64_insn_patch_text_cb, &patch,
+   cpu_online_mask);
+}
+
+int __kprobes aarch64_insn_patch_text(void *addrs[], u32 insns[], int cnt)
+{
+   int ret;
+   u32 insn;
+
+   /* Unsafe to pa

[PATCH v7 4/7] arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions

[Jiang Liu]

Introduce aarch64_insn_gen_{nop|branch_imm}() helper functions, which
will be used to implement jump label on ARM64.

Reviewed-by: Will Deacon 
Signed-off-by: Jiang Liu 
---
 arch/arm64/include/asm/insn.h | 10 ++
 arch/arm64/kernel/insn.c  | 40 
 2 files changed, 50 insertions(+)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index fb44660..c44ad39 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -66,6 +66,11 @@ enum aarch64_insn_imm_type {
AARCH64_INSN_IMM_MAX
 };
 
+enum aarch64_insn_branch_type {
+   AARCH64_INSN_BRANCH_NOLINK,
+   AARCH64_INSN_BRANCH_LINK,
+};
+
 #define__AARCH64_INSN_FUNCS(abbr, mask, val)   \
 static __always_inline bool aarch64_insn_is_##abbr(u32 code) \
 { return (code & (mask)) == (val); } \
@@ -89,6 +94,11 @@ int aarch64_insn_write(void *addr, u32 insn);
 enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
 u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
  u32 insn, u64 imm);
+u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
+   enum aarch64_insn_branch_type type);
+u32 aarch64_insn_gen_hint(enum aarch64_insn_hint_op op);
+u32 aarch64_insn_gen_nop(void);
+
 bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
 
 int aarch64_insn_patch_text_nosync(void *addr, u32 insn);
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 7df0807..92f3683 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -14,6 +14,7 @@
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see .
  */
+#include 
 #include 
 #include 
 #include 
@@ -262,3 +263,42 @@ u32 __kprobes aarch64_insn_encode_immediate(enum 
aarch64_insn_imm_type type,
 
return insn;
 }
+
+u32 __kprobes aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
+ enum aarch64_insn_branch_type type)
+{
+   u32 insn;
+   long offset;
+
+   /*
+* PC: A 64-bit Program Counter holding the address of the current
+* instruction. A64 instructions must be word-aligned.
+*/
+   BUG_ON((pc & 0x3) || (addr & 0x3));
+
+   /*
+* B/BL support [-128M, 128M) offset
+* ARM64 virtual address arrangement guarantees all kernel and module
+* texts are within +/-128M.
+*/
+   offset = ((long)addr - (long)pc);
+   BUG_ON(offset < -SZ_128M || offset >= SZ_128M);
+
+   if (type == AARCH64_INSN_BRANCH_LINK)
+   insn = aarch64_insn_get_bl_value();
+   else
+   insn = aarch64_insn_get_b_value();
+
+   return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_26, insn,
+offset >> 2);
+}
+
+u32 __kprobes aarch64_insn_gen_hint(enum aarch64_insn_hint_op op)
+{
+   return aarch64_insn_get_hint_value() | op;
+}
+
+u32 __kprobes aarch64_insn_gen_nop(void)
+{
+   return aarch64_insn_gen_hint(AARCH64_INSN_HINT_NOP);
+}
-- 
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/

[PATCH v7 6/7] arm64, jump label: optimize jump label implementation

[Jiang Liu]

Optimize jump label implementation for ARM64 by dynamically patching
kernel text.

Signed-off-by: Jiang Liu 
---
 arch/arm64/Kconfig  |  1 +
 arch/arm64/include/asm/jump_label.h | 51 
 arch/arm64/kernel/Makefile  |  1 +
 arch/arm64/kernel/jump_label.c  | 58 +
 4 files changed, 111 insertions(+)
 create mode 100644 arch/arm64/include/asm/jump_label.h
 create mode 100644 arch/arm64/kernel/jump_label.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d4dd22..5f962e8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -19,6 +19,7 @@ config ARM64
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
select HARDIRQS_SW_RESEND
+   select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_TRACEHOOK
select HAVE_DEBUG_BUGVERBOSE
select HAVE_DEBUG_KMEMLEAK
diff --git a/arch/arm64/include/asm/jump_label.h 
b/arch/arm64/include/asm/jump_label.h
new file mode 100644
index 000..47cd130
--- /dev/null
+++ b/arch/arm64/include/asm/jump_label.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu 
+ *
+ * Based on arch/arm/include/asm/jump_label.h
+ *
+ * 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
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef _ASM_JUMP_LABEL_H
+#define _ASM_JUMP_LABEL_H
+#include 
+
+#ifdef __KERNEL__
+
+#define JUMP_LABEL_NOP_SIZE4
+
+static __always_inline bool arch_static_branch(struct static_key *key)
+{
+   asm goto("1: nop\n\t"
+".pushsection __jump_table,  \"aw\"\n\t"
+".align 3\n\t"
+".quad 1b, %l[l_yes], %c0\n\t"
+".popsection\n\t"
+:  :  "i"(key) :  : l_yes);
+
+   return false;
+l_yes:
+   return true;
+}
+
+#endif /* __KERNEL__ */
+
+typedef u64 jump_label_t;
+
+struct jump_entry {
+   jump_label_t code;
+   jump_label_t target;
+   jump_label_t key;
+};
+
+#endif /* _ASM_JUMP_LABEL_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index cd95a25..e155d56 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -18,6 +18,7 @@ arm64-obj-$(CONFIG_SMP)   += smp.o 
smp_spin_table.o
 arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
 arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
 arm64-obj-$(CONFIG_EARLY_PRINTK)   += early_printk.o
+arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/jump_label.c b/arch/arm64/kernel/jump_label.c
new file mode 100644
index 000..263a166
--- /dev/null
+++ b/arch/arm64/kernel/jump_label.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu 
+ *
+ * Based on arch/arm/kernel/jump_label.c
+ *
+ * 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
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+
+#ifdef HAVE_JUMP_LABEL
+
+static void __arch_jump_label_transform(struct jump_entry *entry,
+   enum jump_label_type type,
+   bool is_static)
+{
+   void *addr = (void *)entry->code;
+   u32 insn;
+
+   if (type == JUMP_LABEL_ENABLE) {
+   insn = aarch64_insn_gen_branch_imm(entry->code,
+  entry->target,
+  AARCH64_INSN_BRANCH_NOLINK);
+   } else {
+   insn = aarch64_insn_gen_nop();
+   }
+
+   if (is_static)
+   aarch64_insn_patch_text_nosync(addr, insn);
+   else
+   aarch64_insn_patch_text(&addr, &insn, 1);
+}
+
+void arch_jump_label_transform(struct jump_entry *entry,
+  enum jump_label_type type)
+{
+   __arch_jump_label_

[PATCH v7 5/7] arm64, jump label: detect %c support for ARM64

[Jiang Liu]

As commit a9468f30b5eac6 "ARM: 7333/2: jump label: detect %c
support for ARM", this patch detects the same thing for ARM64
because some ARM64 GCC versions have the same issue.

Some versions of ARM64 GCC which do support asm goto, do not
support the %c specifier. Since we need the %c to support jump
labels on ARM64, detect that too in the asm goto detection script
to avoid build errors with these versions.

Acked-by: Will Deacon 
Signed-off-by: Jiang Liu 
---
 scripts/gcc-goto.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
index a2af2e8..c9469d3 100644
--- a/scripts/gcc-goto.sh
+++ b/scripts/gcc-goto.sh
@@ -5,7 +5,7 @@
 cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
 int main(void)
 {
-#ifdef __arm__
+#if defined(__arm__) || defined(__aarch64__)
/*
 * Not related to asm goto, but used by jump label
 * and broken on some ARM GCC versions (see GCC Bug 48637).
-- 
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/

[PATCH v7 7/7] jump_label: use defined macros instead of hard-coding for better readability

[Jiang Liu]

Use macro JUMP_LABEL_TRUE_BRANCH instead of hard-coding for better
readability.

Acked-by: Steven Rostedt 
Acked-by: Jason Baron 
Signed-off-by: Jiang Liu 
---
 include/linux/jump_label.h | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 377..5c1dfb2 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -81,18 +81,21 @@ struct module;
 #include 
 #ifdef HAVE_JUMP_LABEL
 
-#define JUMP_LABEL_TRUE_BRANCH 1UL
+#define JUMP_LABEL_TYPE_FALSE_BRANCH   0UL
+#define JUMP_LABEL_TYPE_TRUE_BRANCH1UL
+#define JUMP_LABEL_TYPE_MASK   1UL
 
 static
 inline struct jump_entry *jump_label_get_entries(struct static_key *key)
 {
return (struct jump_entry *)((unsigned long)key->entries
-   & ~JUMP_LABEL_TRUE_BRANCH);
+   & ~JUMP_LABEL_TYPE_MASK);
 }
 
 static inline bool jump_label_get_branch_default(struct static_key *key)
 {
-   if ((unsigned long)key->entries & JUMP_LABEL_TRUE_BRANCH)
+   if (((unsigned long)key->entries & JUMP_LABEL_TYPE_MASK) ==
+   JUMP_LABEL_TYPE_TRUE_BRANCH)
return true;
return false;
 }
@@ -122,10 +125,12 @@ extern void static_key_slow_inc(struct static_key *key);
 extern void static_key_slow_dec(struct static_key *key);
 extern void jump_label_apply_nops(struct module *mod);
 
-#define STATIC_KEY_INIT_TRUE ((struct static_key) \
-   { .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
-#define STATIC_KEY_INIT_FALSE ((struct static_key) \
-   { .enabled = ATOMIC_INIT(0), .entries = (void *)0 })
+#define STATIC_KEY_INIT_TRUE ((struct static_key)  \
+   { .enabled = ATOMIC_INIT(1),\
+ .entries = (void *)JUMP_LABEL_TYPE_TRUE_BRANCH })
+#define STATIC_KEY_INIT_FALSE ((struct static_key) \
+   { .enabled = ATOMIC_INIT(0),\
+ .entries = (void *)JUMP_LABEL_TYPE_FALSE_BRANCH })
 
 #else  /* !HAVE_JUMP_LABEL */
 
-- 
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 2/2] gpio: davinci: reuse for Keystone SoC

[Sekhar Nori]

Rob,

On Wednesday 18 December 2013 03:37 PM, Grygorii Strashko wrote:
> The similar GPIO HW block is used by keystone SoCs as
> in Davinci SoCs.
> Hence, reuse Davinci GPIO driver for Keystone taking into
> account that Keystone contains ARM GIC IRQ controller which
> is implemented using IRQ Chip.
> 
> Documentation:
>   http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
> 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Sekhar Nori 
> Cc: devicet...@vger.kernel.org
> 
> Acked-by: Santosh Shilimkar 
> Signed-off-by: Grygorii Strashko 
> ---
>  .../devicetree/bindings/gpio/gpio-davinci.txt  |4 +-
>  drivers/gpio/gpio-davinci.c|   46 
> 
>  2 files changed, 40 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
> index a2e839d..4ce9862 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
> @@ -1,7 +1,7 @@
> -Davinci GPIO controller bindings
> +Davinci/Keystone GPIO controller bindings
>  
>  Required Properties:
> -- compatible: should be "ti,dm6441-gpio"
> +- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"

Can I get your ack for this change? Its pretty trivial, but still..

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

Re: [PATCH v2 2/2] gpio: davinci: reuse for Keystone SoC

[Sekhar Nori]

On Wednesday 18 December 2013 03:37 PM, Grygorii Strashko wrote:
> The similar GPIO HW block is used by keystone SoCs as
> in Davinci SoCs.
> Hence, reuse Davinci GPIO driver for Keystone taking into
> account that Keystone contains ARM GIC IRQ controller which
> is implemented using IRQ Chip.
> 
> Documentation:
>   http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
> 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Sekhar Nori 
> Cc: devicet...@vger.kernel.org
> 
> Acked-by: Santosh Shilimkar 
> Signed-off-by: Grygorii Strashko 
> ---
>  .../devicetree/bindings/gpio/gpio-davinci.txt  |4 +-
>  drivers/gpio/gpio-davinci.c|   46 
> 
>  2 files changed, 40 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
> index a2e839d..4ce9862 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
> @@ -1,7 +1,7 @@
> -Davinci GPIO controller bindings
> +Davinci/Keystone GPIO controller bindings
>  
>  Required Properties:
> -- compatible: should be "ti,dm6441-gpio"
> +- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"
>  
>  - reg: Physical base address of the controller and the size of memory mapped
> registers.
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index 1b33806..38741cc 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -413,6 +413,26 @@ static const struct irq_domain_ops davinci_gpio_irq_ops 
> = {
>   .xlate = irq_domain_xlate_onetwocell,
>  };
>  
> +static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)
> +{
> + static struct irq_chip_type gpio_unbanked;
> +
> + gpio_unbanked = *container_of(irq_get_chip(irq),
> +   struct irq_chip_type, chip);
> +
> + return &gpio_unbanked.chip;
> +};
> +
> +static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
> +{
> + static struct irq_chip gpio_unbanked;
> +
> + gpio_unbanked = *irq_get_chip(irq);
> + return &gpio_unbanked;
> +};
> +
> +static const struct of_device_id davinci_gpio_ids[];
> +
>  /*
>   * NOTE:  for suspend/resume, probably best to make a platform_device with
>   * suspend_late/resume_resume calls hooking into results of the set_wake()
> @@ -433,6 +453,18 @@ static int davinci_gpio_irq_setup(struct platform_device 
> *pdev)
>   struct davinci_gpio_platform_data *pdata = dev->platform_data;
>   struct davinci_gpio_regs __iomem *g;
>   struct irq_domain   *irq_domain = NULL;
> + const struct of_device_id *match;
> + struct irq_chip *irq_chip;
> + struct irq_chip *(*gpio_get_irq_chip)(unsigned int irq);
> +
> + /*
> +  * Use davinci_gpio_get_irq_chip by default to handle non DT cases
> +  */
> + gpio_get_irq_chip = davinci_gpio_get_irq_chip;
> + match = of_match_device(of_match_ptr(davinci_gpio_ids),
> + dev);
> + if (match)
> + gpio_get_irq_chip = match->data;

This produces a sparse warning:

  CHECK   drivers/gpio/gpio-davinci.c
drivers/gpio/gpio-davinci.c:467:35: warning: incorrect type in assignment 
(different modifiers)
drivers/gpio/gpio-davinci.c:467:35:expected struct irq_chip *( *[assigned] 
gpio_get_irq_chip )( ... )
drivers/gpio/gpio-davinci.c:467:35:got void const *const data

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] gpio: davinci: don't create irq_domain in case of unbanked irqs

[Sekhar Nori]

On Wednesday 18 December 2013 03:37 PM, Grygorii Strashko wrote:
> The system may crash if:
> - there are more then 1 bank

s/then/than

> - unbanked irqs are enabled
> - someone will call gpio_to_irq() for GPIO from bank2 or above
> 
> Hence, fix it by not creating irq_domain if unbanked irqs are enabled
> and correct gpio_to_irq_banked() to handle this properly.
> 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Sekhar Nori 
> 
> Acked-by: Santosh Shilimkar 
> Signed-off-by: Grygorii Strashko 
> ---
>  drivers/gpio/gpio-davinci.c |   34 +++---
>  1 file changed, 19 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index 5d163c0..1b33806 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -351,7 +351,10 @@ static int gpio_to_irq_banked(struct gpio_chip *chip, 
> unsigned offset)
>  {
>   struct davinci_gpio_controller *d = chip2controller(chip);
>  
> - return irq_create_mapping(d->irq_domain, d->chip.base + offset);
> + if (d->irq_domain)
> + return irq_create_mapping(d->irq_domain, d->chip.base + offset);
> + else
> + return -ENXIO;
>  }
>  
>  static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
> @@ -429,7 +432,7 @@ static int davinci_gpio_irq_setup(struct platform_device 
> *pdev)
>   struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
>   struct davinci_gpio_platform_data *pdata = dev->platform_data;
>   struct davinci_gpio_regs __iomem *g;
> - struct irq_domain   *irq_domain;
> + struct irq_domain   *irq_domain = NULL;
>  
>   ngpio = pdata->ngpio;
>   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> @@ -453,18 +456,20 @@ static int davinci_gpio_irq_setup(struct 
> platform_device *pdev)
>   }
>   clk_prepare_enable(clk);
>  
> - irq = irq_alloc_descs(-1, 0, ngpio, 0);
> - if (irq < 0) {
> - dev_err(dev, "Couldn't allocate IRQ numbers\n");
> - return irq;
> - }
> + if (!pdata->gpio_unbanked) {
> + irq = irq_alloc_descs(-1, 0, ngpio, 0);
> + if (irq < 0) {
> + dev_err(dev, "Couldn't allocate IRQ numbers\n");
> + return -ENODEV;

The code was correct before moving. Any objections to doing

return irq;

instead?

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pid: change task_struct::pid to read-only

[Oleg Nesterov]

On 12/20, Peter Zijlstra wrote:
>
> On Fri, Dec 20, 2013 at 08:01:57PM +0100, Oleg Nesterov wrote:
> > The only problem is that
> >
> > #define ASSIGN_CONST(l, r)  (*(typeof(r) *)&(l) = (r))
> >
> > obviously can't work in this case ;) We need something more clever.
>
> Hmm indeed, C++ has both the const_cast<>() thingy and the template
> system is powerful enough to actually implement const_cast<>() inside
> the language.
>
> But I cannot find anything useful for C. Your attempt to use the rvalue
> type to hopefully obtain a const-less lvalue type is clever, but does
> indeed fail where the rvalue is const too.

Yes.

We can probably do

#define ASSIGN_CONST(l, r) ({   \
typeof (l) const r__ = (r); \
memcpy((void *)&(l), &(r__), sizeof(l));\
(l);\
})

gcc can actually avoid a temporary if you do

ASSIGN_CONST(tsk->pid, leader->pid);

but this doesn't look very nice and assumes __builtin_memcpy().


So, how about

#define CONST_CAST(type, lval)  \
(*({\
(void)((type *)0 == &(lval));   \
(type *)&(lval);\
})) \

?

de_thread/copy_process can do

CONST_CAST(pid_t, tsk->pid) = leader->pid;

and if "type" is wrong we have a warning.

Oleg.

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

Re: [PATCH 1/5] iio: ti_am335x_adc: Adjust the closing bracket in tiadc_read_raw()

[Jonathan Cameron]

On 12/19/13 15:28, Sebastian Andrzej Siewior wrote:
> It somehow looks like the ending bracket belongs to the if statement but
> it does belong to the while loop. This patch moves the bracket where it
> belongs.
> 
> Reviewed-by: Lee Jones 
> Signed-off-by: Sebastian Andrzej Siewior 
Acked-by: Jonathan Cameron 

Lee, I'm assuming you are fine taking the whole series!
> ---
>  drivers/iio/adc/ti_am335x_adc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index d4d7482..e948454 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -341,7 +341,7 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
>   while (tiadc_readl(adc_dev, REG_ADCFSM) & SEQ_STATUS) {
>   if (time_after(jiffies, timeout))
>   return -EAGAIN;
> - }
> + }
>   map_val = chan->channel + TOTAL_CHANNELS;
>  
>   /*
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] ARM: Fixes for 3.13-rc

[Olof Johansson]

Hi Linus,

arm-soc fixes pull request, Christmas edition 2013. No glögg included, sorry!

God Jul,


-Olof

The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d:

  Linux 3.13-rc4 (2013-12-15 12:31:33 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/fixes-for-linus

for you to fetch changes up to 95fcfa70f3bc4b3b82bf582fa5b24a39bdbd23ae:

  Merge tag 'renesas-fixes-for-v3.13' of 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes 
(2013-12-20 11:28:30 -0800)



ARM: SoC fixes for 3.13-rc

Much smaller batch of fixes this week.

Biggest one is a revert of an OMAP display change that removed some non-DT
pinmux code that was still needed for 3.13 to get DSI displays to work.

There's also a fix that resolves some misdescribed GPIO controller
resources on shmobile. The rest are mostly smaller fixes, a couple of
MAINTAINERS updates, etc.


Kevin Hilman (3):
  Merge tag 'keystone/maintainer-file' of 
git://git.kernel.org/.../ssantosh/linux-keystone into fixes
  Merge tag 'omap-for-v3.13/display-fix' of 
git://git.kernel.org/.../tmlind/linux-omap into fixes
  Merge tag 'renesas-fixes-for-v3.13' of 
git://git.kernel.org/.../horms/renesas into fixes

Laurent Pinchart (1):
  irqchip: renesas-intc-irqpin: Fix register bitfield shift calculation

Magnus Damm (1):
  ARM: shmobile: r8a7790: Fix GPIO resources in DTS

Santosh Shilimkar (2):
  MAINTAINERS: Add keystone git tree information
  MAINTAINERS: Add keystone clock drivers

Simon Horman (1):
  ARM: shmobile: lager: phy fixup needs CONFIG_PHYLIB

Tomasz Figa (1):
  ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

Tomi Valkeinen (1):
  Revert "ARM: OMAP2+: Remove legacy mux code for display.c"

 MAINTAINERS   |  2 ++
 arch/arm/boot/dts/r8a7790.dtsi| 24 +--
 arch/arm/mach-omap2/display.c | 38 +++
 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c   | 11 +
 arch/arm/mach-shmobile/board-lager.c  |  4 +++-
 drivers/irqchip/irq-renesas-intc-irqpin.c |  8 ---
 6 files changed, 61 insertions(+), 26 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] mfd: ti_am335x_tscadc: Don't read back REG_SE

[Jonathan Cameron]

On 12/19/13 15:28, Sebastian Andrzej Siewior wrote:
> The purpose of reg_se_cache has been defeated. It should avoid the
> read-back of the register to avoid the latency and the fact that the
> bits are reset to 0 after the individual conversation took place.
> 
> The reason why this is required like this to work, is that read-back of
> the register removes the bits of the ADC so they do not start another
> conversation after the register is re-written from the TSC side for the
> update.
> To avoid the not required read-back I introduce a "set once" variant which
> does not update the cache mask. After the conversation completes, the
> bit is removed from the SE register anyway and we don't plan a new
> conversation "any time soon". The current set function is renamed to
> set_cache to distinguish the two operations.
> This is a small preparation for a larger sync-rework.
> 
> Acked-by: Lee Jones 
> Signed-off-by: Sebastian Andrzej Siewior 
Acked-by: Jonathan Cameron 

> ---
>  drivers/iio/adc/ti_am335x_adc.c   |  4 ++--
>  drivers/input/touchscreen/ti_am335x_tsc.c |  4 ++--
>  drivers/mfd/ti_am335x_tscadc.c| 16 
>  include/linux/mfd/ti_am335x_tscadc.h  |  3 ++-
>  4 files changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index e948454..b5197a0 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -181,7 +181,7 @@ static int tiadc_buffer_postenable(struct iio_dev 
> *indio_dev)
>   enb |= (get_adc_step_bit(adc_dev, bit) << 1);
>   adc_dev->buffer_en_ch_steps = enb;
>  
> - am335x_tsc_se_set(adc_dev->mfd_tscadc, enb);
> + am335x_tsc_se_set_cache(adc_dev->mfd_tscadc, enb);
>  
>   tiadc_writel(adc_dev,  REG_IRQSTATUS, IRQENB_FIFO1THRES
>   | IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW);
> @@ -335,7 +335,7 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
>   return -EBUSY;
>  
>   step_en = get_adc_step_mask(adc_dev);
> - am335x_tsc_se_set(adc_dev->mfd_tscadc, step_en);
> + am335x_tsc_se_set_once(adc_dev->mfd_tscadc, step_en);
>  
>   /* Wait for ADC sequencer to complete sampling */
>   while (tiadc_readl(adc_dev, REG_ADCFSM) & SEQ_STATUS) {
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
> b/drivers/input/touchscreen/ti_am335x_tsc.c
> index 68beada..2ca5a7b 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -198,7 +198,7 @@ static void titsc_step_config(struct titsc *ts_dev)
>   /* The steps1 … end and bit 0 for TS_Charge */
>   stepenable = (1 << (end_step + 2)) - 1;
>   ts_dev->step_mask = stepenable;
> - am335x_tsc_se_set(ts_dev->mfd_tscadc, ts_dev->step_mask);
> + am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
>  }
>  
>  static void titsc_read_coordinates(struct titsc *ts_dev,
> @@ -322,7 +322,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
>  
>   if (irqclr) {
>   titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
> - am335x_tsc_se_set(ts_dev->mfd_tscadc, ts_dev->step_mask);
> + am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
>   return IRQ_HANDLED;
>   }
>   return IRQ_NONE;
> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index 67d0eb4..cb0c211 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -53,24 +53,32 @@ static void am335x_tsc_se_update(struct ti_tscadc_dev 
> *tsadc)
>   tscadc_writel(tsadc, REG_SE, tsadc->reg_se_cache);
>  }
>  
> -void am335x_tsc_se_set(struct ti_tscadc_dev *tsadc, u32 val)
> +void am335x_tsc_se_set_cache(struct ti_tscadc_dev *tsadc, u32 val)
>  {
>   unsigned long flags;
>  
>   spin_lock_irqsave(&tsadc->reg_lock, flags);
> - tsadc->reg_se_cache = tscadc_readl(tsadc, REG_SE);
>   tsadc->reg_se_cache |= val;
>   am335x_tsc_se_update(tsadc);
>   spin_unlock_irqrestore(&tsadc->reg_lock, flags);
>  }
> -EXPORT_SYMBOL_GPL(am335x_tsc_se_set);
> +EXPORT_SYMBOL_GPL(am335x_tsc_se_set_cache);
> +
> +void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&tsadc->reg_lock, flags);
> + tscadc_writel(tsadc, REG_SE, tsadc->reg_se_cache | val);
> + spin_unlock_irqrestore(&tsadc->reg_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(am335x_tsc_se_set_once);
>  
>  void am335x_tsc_se_clr(struct ti_tscadc_dev *tsadc, u32 val)
>  {
>   unsigned long flags;
>  
>   spin_lock_irqsave(&tsadc->reg_lock, flags);
> - tsadc->reg_se_cache = tscadc_readl(tsadc, REG_SE);
>   tsadc->reg_se_cache &= ~val;
>   am335x_tsc_se_update(tsadc);
>   spin_unlock_irqrestore(&tsadc->reg_lock, flags);
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
> b/include/linux/mfd/ti_am335x_tscadc.h
> in

Re: [PATCH 4/5] mfd: ti_am335x: Drop am335x_tsc_se_update() from resume path

[Jonathan Cameron]

On 12/19/13 15:28, Sebastian Andrzej Siewior wrote:
> The update of the SE register in MFD doesn't look right as it has
> nothing to do with it. The better place to do it is in TSC driver (which
> is already doing it) and in the ADC driver which needs this only in the
> continues mode.
> 
> Acked-by: Lee Jones   [MFD part]
> Signed-off-by: Sebastian Andrzej Siewior 
Acked-by: Jonathan Cameron 
> ---
>  drivers/iio/adc/ti_am335x_adc.c | 2 ++
>  drivers/mfd/ti_am335x_tscadc.c  | 1 -
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index b5197a0..6822b9f 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -199,6 +199,7 @@ static int tiadc_buffer_predisable(struct iio_dev 
> *indio_dev)
>   tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
>   IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW));
>   am335x_tsc_se_clr(adc_dev->mfd_tscadc, adc_dev->buffer_en_ch_steps);
> + adc_dev->buffer_en_ch_steps = 0;
>  
>   /* Flush FIFO of leftover data in the time it takes to disable adc */
>   fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
> @@ -494,6 +495,7 @@ static int tiadc_resume(struct device *dev)
>   tiadc_writel(adc_dev, REG_CTRL, restore);
>  
>   tiadc_step_config(indio_dev);
> + am335x_tsc_se_set(adc_dev->mfd_tscadc, adc_dev->buffer_en_ch_steps);
>  
>   return 0;
>  }
> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index cb0c211..157f569 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -309,7 +309,6 @@ static int tscadc_resume(struct device *dev)
>  
>   if (tscadc_dev->tsc_cell != -1)
>   tscadc_idle_config(tscadc_dev);
> - am335x_tsc_se_update(tscadc_dev);
>   restore = tscadc_readl(tscadc_dev, REG_CTRL);
>   tscadc_writel(tscadc_dev, REG_CTRL,
>   (restore | CNTRLREG_TSCSSENB));
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: max8997: Use "IS_ENABLED(CONFIG_OF)" for DT code.

[Manish Badarkhe]

Instead of "#if define CONFIG_OF" use "IS_ENABLED(CONFIG_OF)"
option for DT code to avoid if-deffery in code.

Signed-off-by: Manish Badarkhe 
---
:100644 100644 791aea3... be9a8b0... M  drivers/mfd/max8997.c
 drivers/mfd/max8997.c |   14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/mfd/max8997.c b/drivers/mfd/max8997.c
index 791aea3..be9a8b0 100644
--- a/drivers/mfd/max8997.c
+++ b/drivers/mfd/max8997.c
@@ -133,7 +133,6 @@ int max8997_update_reg(struct i2c_client *i2c, u8 reg, u8 
val, u8 mask)
 }
 EXPORT_SYMBOL_GPL(max8997_update_reg);
 
-#ifdef CONFIG_OF
 /*
  * Only the common platform data elements for max8997 are parsed here from the
  * device tree. Other sub-modules of max8997 such as pmic, rtc and others have
@@ -164,24 +163,15 @@ static struct max8997_platform_data 
*max8997_i2c_parse_dt_pdata(
 
return pd;
 }
-#else
-static struct max8997_platform_data *max8997_i2c_parse_dt_pdata(
-   struct device *dev)
-{
-   return 0;
-}
-#endif
 
 static inline int max8997_i2c_get_driver_data(struct i2c_client *i2c,
const struct i2c_device_id *id)
 {
-#ifdef CONFIG_OF
-   if (i2c->dev.of_node) {
+   if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node) {
const struct of_device_id *match;
match = of_match_node(max8997_pmic_dt_match, i2c->dev.of_node);
return (int)match->data;
}
-#endif
return (int)id->driver_data;
 }
 
@@ -203,7 +193,7 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
max8997->type = max8997_i2c_get_driver_data(i2c, id);
max8997->irq = i2c->irq;
 
-   if (max8997->dev->of_node) {
+   if (IS_ENABLED(CONFIG_OF) && max8997->dev->of_node) {
pdata = max8997_i2c_parse_dt_pdata(max8997->dev);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
-- 
1.7.10.4

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

Re: [PATCH 5/5] mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization

[Jonathan Cameron]

On 12/19/13 15:28, Sebastian Andrzej Siewior wrote:
> The ADC driver always programs all possible ADC values and discards
> them except for the value IIO asked for. On the am335x-evm the driver
> programs four values and it takes 500us to gather them. Reducing the number
> of conversations down to the (required) one also reduces the busy loop down
> to 125us.
> 
> This leads to another error, namely the FIFOCOUNT register is sometimes
> (like one out of 10 attempts) not updated in time leading to EBUSY.
> The next read has the FIFOCOUNT register updated.
> Checking for the ADCSTAT register for being idle isn't a good choice either.
> The problem is that if TSC is used at the same time, the HW completes the
> conversation for ADC *and* before the driver noticed it, the HW begins to
> perform a TSC conversation and so the driver never seen the HW idle. The
> next time we would have two values in the FIFO but since the driver reads
> everything we always see the current one.
> So instead of polling for the IDLE bit in ADCStatus register, we should
> check the FIFOCOUNT register. It should be one instead of zero because we
> request one value.
> 
> This change in turn leads to another error. Sometimes if TSC & ADC are
> used together the TSC starts becoming interrupts even if nobody
becoming -> generating?
> actually touched the touchscreen. The interrupts seem valid because TSC's
> FIFO is filled with values for each channel of the TSC. This condition stops
> after a few ADC reads but will occur again. Not good.
> 
> On top of this (even without the changes I just mentioned) there is a ADC
> & TSC lockup condition which was reported to me by Jeff Lance including the
> following test case:
> A busy loop of "cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw"
> and a mug on touch screen. With this setup, the hardware will lockup after
> something between 20 minutes and it could take up to a couple of hours.
> During that lockup, the ADCSTAT register says 0x30 (or 0x70) which means
> STEP_ID = IDLE and FSM_BUSY = yes. That means the hardware says that it is
> idle and busy at the same time which is an invalid condition.
> 
yikes.
> For all this reasons I decided to rework this TSC/ADC part and add a
> handshake / synchronization here:
> First the ADC signals that it needs the HW and writes a 0 mask into the
> SE register. The HW (if active) will complete the current conversation
> and become idle. The TSC driver will gather the values from the FIFO
> (woken up by an interrupt) and won't "enable" another conversation.
> Instead it will wake up the ADC driver which is already waiting. The ADC
> driver will start "its" conversation and once it is done, it will
> enable the TSC steps so the TSC will work again.
> 
> After this rework I haven't observed the lockup so far. Plus the busy
> loop has been reduced from 500us to 125us.
> 
> The continues-read mode remains unchanged.
>
Thanks for the detailed explanation.

> Signed-off-by: Sebastian Andrzej Siewior 
Hmm. I'm not really an expert in this complex driver, but your explanation is 
clear
and the code appears to implement what you describe.  Hopefully we'll see a fix 
for
the continuous reads as well.

Fiddly little device!

Acked-by: Jonathan Cameron 

> ---
>  drivers/iio/adc/ti_am335x_adc.c  | 64 
> ++--
>  drivers/mfd/ti_am335x_tscadc.c   | 63 +--
>  include/linux/mfd/ti_am335x_tscadc.h |  4 +++
>  3 files changed, 103 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index 6822b9f..31e786e 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -60,6 +60,24 @@ static u32 get_adc_step_mask(struct tiadc_device *adc_dev)
>   return step_en;
>  }
>  
> +static u32 get_adc_chan_step_mask(struct tiadc_device *adc_dev,
> + struct iio_chan_spec const *chan)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(adc_dev->channel_step); i++) {
> + if (chan->channel == adc_dev->channel_line[i]) {
> + u32 step;
> +
> + step = adc_dev->channel_step[i];
> + /* +1 for the charger */
> + return 1 << (step + 1);
> + }
> + }
> + WARN_ON(1);
> + return 0;
> +}
> +
>  static u32 get_adc_step_bit(struct tiadc_device *adc_dev, int chan)
>  {
>   return 1 << adc_dev->channel_step[chan];
> @@ -329,34 +347,43 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
>   unsigned int fifo1count, read, stepid;
>   bool found = false;
>   u32 step_en;
> - unsigned long timeout = jiffies + usecs_to_jiffies
> - (IDLE_TIMEOUT * adc_dev->channels);
> + unsigned long timeout;
>  
>   if (iio_buffer_enabled(indio_dev))
>   return -EBUSY;
>  
> - step_en = get_adc_step_mask(adc_dev);
> + step_en = get_adc_chan_s

Re: [PATCH] iio: at91: document ADC clock properties

[Jonathan Cameron]

On 12/19/13 15:54, Nicolas Ferre wrote:
> On 17/12/2013 17:16, Boris BREZILLON :
>> Document the clock properties required by the at91 ADC driver.
>>
>> Signed-off-by: Boris BREZILLON 
> 
> Acked-by: Nicolas Ferre 
Looks fine to me.  I'm just waiting on an ack from a device tree maintainer
(or the 3 weeks to pass so I can pick it up anyway ;)

> 
>> ---
>>  .../devicetree/bindings/arm/atmel-adc.txt  |5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt 
>> b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> index d106146..9a1175b 100644
>> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> @@ -5,6 +5,9 @@ Required properties:
>>   can be "at91sam9260", "at91sam9g45" or "at91sam9x5"
>>- reg: Should contain ADC registers location and length
>>- interrupts: Should contain the IRQ line for the ADC
>> +  - clock-names: tuple listing input clock names.
>> +Required elements: "adc_clk", "adc_op_clk".
>> +  - clocks: phandles to input clocks.
>>- atmel,adc-channels-used: Bitmask of the channels muxed and enable for 
>> this
>>  device
>>- atmel,adc-startup-time: Startup Time of the ADC in microseconds as
>> @@ -44,6 +47,8 @@ adc0: adc@fffb {
>>  compatible = "atmel,at91sam9260-adc";
>>  reg = <0xfffb 0x100>;
>>  interrupts = <20 4>;
>> +clocks = <&adc_clk>, <&adc_op_clk>;
>> +clock-names = "adc_clk", "adc_op_clk";
>>  atmel,adc-channel-base = <0x30>;
>>  atmel,adc-channels-used = <0xff>;
>>  atmel,adc-drdy-mask = <0x1>;
>>
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHes - aio / migrate page, please review] Re: bad page state in 3.13-rc4

[Linus Torvalds]

On Sat, Dec 21, 2013 at 3:06 PM, Benjamin LaHaise  wrote:
>
> Linus, feel free to add my Signed-off-by: to your sanitization of
> aio_setup_ring() as well, as it works okay in my testing.

Nobody commented on your request for comments, so I applied my patch
and pulled your branch, because I'm going to do -rc5 in a few and at
least we want this to get testing.

Dave, let's hope that the leak fixes and reference count fixes solve
your problem.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powercap/rapl: add support for ValleyView Soc

[Vince Weaver]

On Sun, 22 Dec 2013, Rafael J. Wysocki wrote:
> On Wednesday, December 11, 2013 02:39:27 PM Jacob Pan wrote:

> > @@ -941,6 +949,7 @@ static void package_power_limit_irq_restore(int 
> > package_id)
> >  static const struct x86_cpu_id rapl_ids[] = {
> > { X86_VENDOR_INTEL, 6, 0x2a},/* SNB */
> > { X86_VENDOR_INTEL, 6, 0x2d},/* SNB EP */
> > +   { X86_VENDOR_INTEL, 6, 0x37},/* VLV */
> > { X86_VENDOR_INTEL, 6, 0x3a},/* IVB */
> > { X86_VENDOR_INTEL, 6, 0x45},/* HSW */
> > /* TODO: Add more CPU IDs after testing */

This isn't a problem introduced in this patch, but it made me notice it...

Would it really hurt anyone to spell out the architectures here, rather
than using obscure 3-letter abbreviations?  It's bad enough trying to
map the hex model numbers to the decimal ones in /proc/cpuinfo without
also having to remember what a VLV is.

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

status of block-integrity

[Christoph Hellwig]

We have the block integrity code to support DIF/DIX in the the tree for
about 5 and a half years, and we still don't have a single consumer of
it.  By normal kernel rules it should never have been merged, or at
least the bitrot long removed.

Given that we'll have a lot of work to do in this area with block
multiqueue I think it's time to either kill it off for good or make sure
we can actually use and test it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] closures: move to lib/

[Christoph Hellwig]

On Thu, Dec 19, 2013 at 04:21:07AM -0800, Kent Overstreet wrote:
> Grep through drivers/md/bcache/...

While that will require a fair amount of work I'm pretty sure we could
untangle that mess as well.  But what I meant was whatever piece of code
that motivated you to move the code to lib/.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] at91: drivers for 3.14 #1

[Olof Johansson]

Hi,

On Fri, Dec 13, 2013 at 10:05:45AM +0100, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> This is a "drivers" series that adds Device Tree support to 
> Atmel crypto drivers (AES/[T]DES/SHA). As the DT part of this
> addition is in at91-3.14-dt I thought it would be simpler to take
> this series through arm-soc. I asked and got Herbert's blessing.
> 
> The Device Tree entries documented in these patches are very simple
> and only declare the reg/irq values and the link to DMA.
> 
> Thanks, best regards,
> 
> The following changes since commit b46e837d8ef1f3c777bbf9513e2cdb5d87d6c374:
> 
>   ARM: at91/dt: remove old clk material (2013-12-02 15:31:29 +0100)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-drivers
> 
> for you to fetch changes up to 1ca5b7d95315c42cf0b78d33cd316e404a9f137c:
> 
>   crypto: atmel-sha - add sha information to the log (2013-12-12 18:39:36 
> +0100)
> 
> 
> AT91 crypto drivers DT support:
> - add DT to sha/des/aes existing drivers
> - add DMA DT
> - all documentation added to crypto/atmel-crypto.txt file
> 
> 
> Nicolas Ferre (4):
>   crypto: atmel-aes - add support for Device Tree
>   crypto: atmel-tdes - add support for Device Tree
>   crypto: atmel-sha - add support for Device Tree
>   crypto: atmel-sha - add sha information to the log

Pulled. In the future make sure to cc binding changes to
devicet...@vger.kernel.org for review. These bindings all seemed to be
trivial though so I merged anyway.


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

Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files

[Olof Johansson]

On Fri, Dec 13, 2013 at 03:33:07PM +0100, Jonas Jensen wrote:
> The MOXA ART SoC is based on Faraday's FA526. This is a ARMv4 32-bit
> 192 MHz CPU with MMU and 16KB/8KB D/I-cache.
> 
> Add platform support for this SoC.
> 
> Also add UC-7112-LX as a machine.
> 
> Signed-off-by: Jonas Jensen 

Applied to next/soc for 3.14. Please follow up on the comments and submit
patches as needed on top of this.

Also, I renamed the patch to be ARM: moxart: ... since we normally leave out
the mach- part.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files

[Olof Johansson]

Hi,


On Fri, Dec 13, 2013 at 03:33:08PM +0100, Jonas Jensen wrote:
> Add a generic (dtsi) include file for MOXA ART SoCs.
> 
> Also add a file for UC-7112-LX.
> 
> Signed-off-by: Jonas Jensen 

Applied to next/dt. Again, please follow up with some of the comments -- in
particular the requests to keep the SoC IP blocks in the dtsi file and only
enable/disable or amend the entries in the per-board file depending on actual
board configuration. But I didn't see a reason to not merge it while that's
being cleaned up, etc.


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

Re: [PATCH v6 0/2] ARM: mach-moxart: add MOXA ART SoC support

[Olof Johansson]

On Wed, Dec 18, 2013 at 01:58:44PM +0100, Jonas Jensen wrote:
> Thanks for the replies!
> 
> This should tick the boxes on feedback except for one detail
> on the fixed rate clock:
> 
> Moving fixed-clock "ref12" from .dtsi to .dts proved problematic
> for other clocks, this is why ref12 is still in SoC.
> 
> My assertion is that "fixed-clock" clocks are probed later when
> placed in .dts (see diff and boot log below).
> of_clk_get() from clk_pll in .dtsi fails, i.e. fixed-clock ref12
> is not added as a provider in time before clk_pll loads.

Argh, I didn't see this version before I applied v5. So I dropped v5 and
replaced with v6.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 0/2] ARM: mach-moxart: add MOXA ART SoC support

[Olof Johansson]

On Thu, Dec 19, 2013 at 11:47:42AM +0100, Jonas Jensen wrote:
> The reason behind why fixed rate clock "ref12" couldn't be moved from
> .dtsi to .dts:
> 
> There was nothing else in "clocks { .. }", the entire block was then
> deleted from .dtsi.
> 
> If a skeleton "clocks { .. }" remain in .dtsi, the node can then be
> moved to .dts, and of_clk_get() works again.
> 
> Changes since v6:
> 
> 1. move fixed rate clock "ref12" from .dtsi to .dts
> 2. sort new entry alphabetically in arch/arm/Kconfig
> 3. rebase to next-20131219: arch/arm/Makefile arch/arm/Kconfig
> 
> Applies to next-20131219
> 
> Jonas Jensen (2):
>   ARM: mach-moxart: add MOXA ART SoC platform files
>   ARM: mach-moxart: add MOXA ART SoC device tree files

Please just send an incremental patch to fixup, I'm not going to rebuild
branches yet again because of a third version within a few hours when I've
already applied and dropped twice. :)

-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAINTAINERS: take maintainership for Energy Micro efm32 SoCs

[Olof Johansson]

On Fri, Dec 20, 2013 at 09:21:59PM +0100, Uwe Kleine-König wrote:
> Acked-by: Greg Kroah-Hartman 
> Acked-by: Mark Brown 
> Signed-off-by: Uwe Kleine-König 
> ---
> Hello,
> 
> On Fri, Dec 20, 2013 at 11:55:30PM +0400, Alexander Shiyan wrote:
> > [...]
> > > +F: arch/arm/boot/dts/efm32*
> > > +F: arch/arm/configs/efm32_defconfig
> > > +F: arch/arm/include/debug/efm32.S
> > > +F: arch/arm/mach-efm32/
> > > +F: drivers/clk/clk-efm32gg.c
> > > +F: drivers/clocksource/time-efm32.c
> > > +F: drivers/spi/spi-efm32.c
> > > +F: drivers/tty/serial/efm32-uart.c
> > > +F: include/dt-bindings/clock/efm32-cmu.h
> > > +F: include/linux/platform_data/efm32-*
> > 
> > Maybe "N" keyword with "efm32" is better here?
> ah, didn't know about that. Nice.
> 
> So the changes since v1 are:
>  - use N: efm32
>  - add acks from Greg and Mark
>I assume it's ok to keep them for v2 assuming they mean them being OK with
>me maintaining the efm32 stuff and not the way to express that in
>MAINTAINERS.

Applied, thanks.

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

kernfs: gpf when offlining cpus

[Sasha Levin]

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on 
the following spew.


Beyond regular trinity fuzzing, the machine was in the middle of attempting to offline all of it's 
cpus (64 of them).


[  696.029538] general protection fault:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  696.030042] Dumping ftrace buffer:
[  696.030042](ftrace buffer empty)
[  696.030042] Modules linked in:
[  696.030042] CPU: 49 PID: 18975 Comm: trinity-c574 Tainted: GW
3.13.0-rc4-
next-20131220-sasha-00013-gf9a57f1-dirty #6
[  696.030042] task: 8801ced5b000 ti: 8801d384e000 task.ti: 
8801d384e000
[  696.030042] RIP: 0010:[]  [] 
sysfs_file_ops+0x5b
/0x70
[  696.030042] RSP: 0018:8801d384f858  EFLAGS: 00010202
[  696.030042] RAX:  RBX: 88010bd938e0 RCX: 0001
[  696.030042] RDX: 6b6b6b6b6b6b6b6b RSI: 88007de8e6c8 RDI: 0286
[  696.030042] RBP: 8801d384f868 R08:  R09: 0003
[  696.030042] R10: 0001 R11:  R12: 88012c1537c8
[  696.030042] R13: 88010bd938e0 R14: 88001b8ecb48 R15: 8801d384f8f0
[  696.030042] FS:  7f63221d6700() GS:88003f40() 
knlGS:

[  696.030042] CS:  0010 DS:  ES:  CR0: 8005003b
[  696.030042] CR2: 0068c000 CR3: 0001e8d66000 CR4: 06e0
[  696.030042] DR0: 00697000 DR1:  DR2: 
[  696.030042] DR3:  DR6: 0ff0 DR7: 00010602
[  696.030042] Stack:
[  696.030042]  8801d384f878 88012c1537c8 8801d384f898 
8135d68d
[  696.030042]  88001a21f900 88012c1537c8 0001 
8801d384f978
[  696.030042]  8801d384f8a8 813608b9 8801d384f928 
812fdfba
[  696.030042] Call Trace:
[  696.030042]  [] sysfs_kf_seq_show+0x3d/0x130
[  696.030042]  [] kernfs_seq_show+0x29/0x30
[  696.030042]  [] seq_read+0x1ba/0x430
[  696.030042]  [] kernfs_fop_read+0x29/0x40
[  696.030042]  [] do_readv_writev+0x18c/0x2e0
[  696.030042]  [] ? kernfs_file_direct_read+0x130/0x130
[  696.030042]  [] ? alloc_pages_current+0x1f4/0x230
[  696.030042]  [] ? default_file_splice_read+0x12c/0x330
[  696.030042]  [] ? sched_clock_local+0x25/0x90
[  696.030042]  [] vfs_readv+0x43/0x50
[  696.030042]  [] default_file_splice_read+0x1f1/0x330
[  696.030042]  [] ? put_lock_stats+0xe/0x30
[  696.030042]  [] ? deactivate_slab+0x8cf/0x920
[  696.030042]  [] ? _raw_spin_unlock+0x35/0x60
[  696.030042]  [] ? deactivate_slab+0x8cf/0x920
[  696.030042]  [] ? dump_trace+0x2c1/0x2f0
[  696.030042]  [] ? get_partial_node+0x471/0x4b0
[  696.030042]  [] ? alloc_pipe_info+0x46/0xd0
[  696.030042]  [] ? set_track+0xab/0x100
[  696.030042]  [] ? __slab_alloc+0x677/0x6c0
[  696.030042]  [] ? trace_hardirqs_on+0xd/0x10
[  696.030042]  [] ? __lock_release+0x1da/0x1f0
[  696.030042]  [] ? __do_page_fault+0x530/0x5a0
[  696.030042]  [] ? alloc_pipe_info+0x46/0xd0
[  696.030042]  [] ? page_cache_pipe_buf_release+0x30/0x30
[  696.030042]  [] do_splice_to+0x8a/0xa0
[  696.030042]  [] splice_direct_to_actor+0xd3/0x1e0
[  696.030042]  [] ? splice_from_pipe_begin+0x20/0x20
[  696.030042]  [] do_splice_direct+0xa6/0xc0
[  696.030042]  [] ? rw_verify_area+0xcc/0x100
[  696.030042]  [] do_sendfile+0x1d7/0x3a0
[  696.030042]  [] SyS_sendfile64+0x61/0xc0
[  696.030042]  [] tracesys+0xdd/0xe2
[  696.030042] Code: e8 eb 12 e3 ff 85 c0 75 17 be 21 00 00 00 48 c7 c7 1b 0d 
7c 85 e8
b6 23 dd ff 66 0f 1f 44 00 00 48 8b 53 28 31 c0 48 85 d2 74 04 <48> 8b 42 08 48 
83 c4 0
8 5b c9 c3 66 2e 0f 1f 84 00 00 00 00 00
[  696.030042] RIP  [] sysfs_file_ops+0x5b/0x70
[  696.030042]  RSP 


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

Re: GPF in aio_migratepage

[Kristian Nielsen]

Gu Zheng  writes:

> This issue seems like a problem that has been fixed yet:
> http://article.gmane.org/gmane.linux.kernel.aio.general/3741/match=potential+use+after+free+aio%5fmigratepage
> commit 5e9ae2e5da0beb93f8557fc92a8f4fbc05ea448f
> aio: fix use-after-free in aio_migratepage
> So I think maybe you can run with latest Linus' tree or 3.13-rc4 to
> check whether this issue still appears.

Hm. I checked that thread, and as far as I can see, that patch was already
included in the tree I hit the BUG in (3.13-rc1):


http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e9ae2e5da0beb93f8557fc92a8f4fbc05ea448f

There are other changes in that area since 3.13-rc1 though.

Anyway, I am now running with 3.13-rc4 and will report if I see anything.
Given that I do not have any way to reproduce (I only ever saw this once),
this seems the best that can be done for now.

Thanks for following up on this!

 - Kristian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: status of block-integrity

[Nicholas A. Bellinger]

On Sun, 2013-12-22 at 11:21 -0800, Christoph Hellwig wrote:
> We have the block integrity code to support DIF/DIX in the the tree for
> about 5 and a half years, and we still don't have a single consumer of
> it.  By normal kernel rules it should never have been merged, or at
> least the bitrot long removed.

Is not sd_dif.c a consumer of blk_integrity.c logic..?

> Given that we'll have a lot of work to do in this area with block
> multiqueue I think it's time to either kill it off for good or make sure
> we can actually use and test it.

Speak of the devil..

I've been working on enabling DIF support in scsi-mq recently, and
AFAICT the only part that is required in blk-mq for DIF emulation to
function with scsi-debug is the following patch.

commit 1428a390cc16025f93905852777d4afd8aeba05d
Author: Nicholas Bellinger 
Date:   Sun Dec 22 11:58:49 2013 +

blk-mq: Add bio_integrity setup to blk_mq_make_request

This patch adds the missing bio_integrity_enabled() +
bio_integrity_prep() setup into blk_mq_make_request()
in order to use DIF protection with scsi-mq.

Cc: Jens Axboe 
Cc: Martin K. Petersen 
Signed-off-by: Nicholas Bellinger 

diff --git a/block/blk-mq.c b/block/blk-mq.c
index c79126e..a520c39 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -916,6 +916,11 @@ static void blk_mq_make_request(struct request_queue *q, 
struct bio *bio)
 
blk_queue_bounce(q, &bio);
 
+   if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
+   bio_endio(bio, -EIO);
+   return;
+   }
+
if (use_plug && blk_attempt_plug_merge(q, bio, &request_count))
return;

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

kernfs: WARNING: CPU: 59 PID: 10414 at lib/debugobjects.c:260

[Sasha Levin]

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on 
the following spew.


Beyond regular trinity fuzzing, the machine was in the middle of attempting to offline all of it's 
cpus (64 of them).


[  645.148744] WARNING: CPU: 59 PID: 10414 at lib/debugobjects.c:260 
debug_print_object
+0x8d/0xb0()
[  645.150844] ODEBUG: free active (active state 0) object type: timer_list 
hint: delay
ed_work_timer_fn+0x0/0x20
[  645.152178] Modules linked in:
[  645.152699] CPU: 59 PID: 10414 Comm: sh Tainted: GW
3.13.0-rc4-next-20131
220-sasha-00013-gf9a57f1-dirty #6
[  645.154113]  0104 88001a74fa68 845d3d3c 
858006ee
[  645.155294]  88001a74fab8 88001a74faa8 8112f93c 
88001a74fad8
[  645.155294]  8594fab2 880168f10a10 86068c00 
8891eaf8
[  645.157180] Call Trace:
[  645.157697]  [] dump_stack+0x52/0x7f
[  645.157975]  [] warn_slowpath_common+0x8c/0xc0
[  645.158744]  [] warn_slowpath_fmt+0x46/0x50
[  645.158744]  [] debug_print_object+0x8d/0xb0
[  645.158744]  [] ? __queue_work+0x3f0/0x3f0
[  645.158744]  [] __debug_check_no_obj_freed+0xa5/0x220
[  645.158744]  [] ? cpuid4_cache_sysfs_exit+0x46/0xc0
[  645.158744]  [] ? cpuid4_cache_sysfs_exit+0x46/0xc0
[  645.158744]  [] debug_check_no_obj_freed+0x15/0x20
[  645.158744]  [] kfree+0x21f/0x2e0
[  645.158744]  [] cpuid4_cache_sysfs_exit+0x46/0xc0
[  645.158744]  [] cache_remove_dev+0x11a/0x130
[  645.158744]  [] cacheinfo_cpu_callback+0x78/0x90
[  645.158744]  [] notifier_call_chain+0xee/0x130
[  645.158744]  [] __raw_notifier_call_chain+0xe/0x10
[  645.158744]  [] __cpu_notify+0x20/0x40
[  645.158744]  [] cpu_notify_nofail+0x15/0x30
[  645.158744]  [] _cpu_down+0x195/0x2e0
[  645.158744]  [] ? cpu_maps_update_begin+0x17/0x20
[  645.158744]  [] ? device_offline+0x55/0xd0
[  645.158744]  [] ? klist_next+0xf5/0x120
[  645.158744]  [] ? mutex_trylock+0x1fd/0x270
[  645.158744]  [] cpu_down+0x36/0x50
[  645.158744]  [] cpu_subsys_offline+0x14/0x20
[  645.158744]  [] device_offline+0x82/0xd0
[  645.158744]  [] online_store+0x58/0x80
[  645.158744]  [] dev_attr_store+0x20/0x30
[  645.158744]  [] sysfs_kf_write+0x4f/0x70
[  645.158744]  [] kernfs_fop_write+0xdb/0x140
[  645.158744]  [] vfs_write+0xf3/0x1e0
[  645.158744]  [] SyS_write+0x62/0xa0
[  645.158744]  [] tracesys+0xdd/0xe2


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

Re: [PATCH v2] MAINTAINERS: take maintainership for Energy Micro efm32 SoCs

[Mike Turquette]

Quoting Uwe Kleine-König (2013-12-20 12:21:59)
> Acked-by: Greg Kroah-Hartman 
> Acked-by: Mark Brown 
> Signed-off-by: Uwe Kleine-König 
> ---
> Hello,
> 
> On Fri, Dec 20, 2013 at 11:55:30PM +0400, Alexander Shiyan wrote:
> > [...]
> > > +F: arch/arm/boot/dts/efm32*
> > > +F: arch/arm/configs/efm32_defconfig
> > > +F: arch/arm/include/debug/efm32.S
> > > +F: arch/arm/mach-efm32/
> > > +F: drivers/clk/clk-efm32gg.c
> > > +F: drivers/clocksource/time-efm32.c
> > > +F: drivers/spi/spi-efm32.c
> > > +F: drivers/tty/serial/efm32-uart.c
> > > +F: include/dt-bindings/clock/efm32-cmu.h
> > > +F: include/linux/platform_data/efm32-*
> > 
> > Maybe "N" keyword with "efm32" is better here?
> ah, didn't know about that. Nice.
> 
> So the changes since v1 are:
>  - use N: efm32
>  - add acks from Greg and Mark
>I assume it's ok to keep them for v2 assuming they mean them being OK with
>me maintaining the efm32 stuff and not the way to express that in
>MAINTAINERS.

Ack for the clock driver.

Mike

> 
> Thanks
> Uwe
> 
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 95648eb..6ea1fb2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -867,6 +867,12 @@ S: Maintained
>  F: arch/arm/mach-ebsa110/
>  F: drivers/net/ethernet/amd/am79c961a.*
>  
> +ARM/ENERGY MICRO (SILICON LABS) EFM32 SUPPORT
> +M: Uwe Kleine-König 
> +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
> +S: Maintained
> +N: efm32
> +
>  ARM/EZX SMARTPHONES (A780, A910, A1200, E680, ROKR E2 and ROKR E6)
>  M: Daniel Ribeiro 
>  M: Stefan Schmidt 
> -- 
> 1.8.5.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] powercap/rapl: add support for ValleyView Soc

[Rafael J. Wysocki]

On Sunday, December 22, 2013 02:22:48 PM Vince Weaver wrote:
> On Sun, 22 Dec 2013, Rafael J. Wysocki wrote:
> > On Wednesday, December 11, 2013 02:39:27 PM Jacob Pan wrote:
> 
> > > @@ -941,6 +949,7 @@ static void package_power_limit_irq_restore(int 
> > > package_id)
> > >  static const struct x86_cpu_id rapl_ids[] = {
> > >   { X86_VENDOR_INTEL, 6, 0x2a},/* SNB */
> > >   { X86_VENDOR_INTEL, 6, 0x2d},/* SNB EP */
> > > + { X86_VENDOR_INTEL, 6, 0x37},/* VLV */
> > >   { X86_VENDOR_INTEL, 6, 0x3a},/* IVB */
> > >   { X86_VENDOR_INTEL, 6, 0x45},/* HSW */
> > >   /* TODO: Add more CPU IDs after testing */
> 
> This isn't a problem introduced in this patch, but it made me notice it...
> 
> Would it really hurt anyone to spell out the architectures here, rather
> than using obscure 3-letter abbreviations?  It's bad enough trying to
> map the hex model numbers to the decimal ones in /proc/cpuinfo without
> also having to remember what a VLV is.

I guess you can prepare a patch for that?

Rafael

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

Re: [PATCH -tip v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(), cleanup and fixes crash bugs

[Masami Hiramatsu]

(2013/12/20 19:46), Ingo Molnar wrote:
> 
> * Masami Hiramatsu  wrote:
> 
>> (2013/12/20 17:20), Ingo Molnar wrote:
>>>
>>> * Masami Hiramatsu  wrote:
>>>
>  But a closer look indicates that the insertion of kprobes is 
> taking about three (!!) orders of magnitude longer than before, as 
> judged by the rate of increase of 'wc -l 
> /sys/kernel/debug/kprobes/list'.

 Right, because kprobes are not designed for thousands of probes.
>>>
>>> Then this needs to be fixed, because right now this bug is making it 
>>> near impossible to properly test kprobes robustness.
>>>
>>> For example a hash table (hashed by probe address) could be used in 
>>> addition to the list, to speed up basic operations.
>>
>> kprobe itself is already using hlist (6bits hash table).
>> Maybe we'd better expand the table bits. However, the iteration
>> of the list on debugfs is just doing seq_printf()s. I'm not exactly
>> sure what Frank complaints about...
> 
> Well, Frank reported that the test he performed takes hours to finish, 
> and he mentioned a specific script line he used to produce that:
> 
>   # stap -te "probe kprobe.function("*") {}"
> 
> I suspect an equivalent perf probe sequence would be something like:
> 
>   # for FUNC in $(grep -iw t /proc/kallsyms | cut -d' ' -f3); do date; perf 
> probe -a $FUNC; done
> 
> (totally untested.)
> 
> Can you reproduce that slowdown, using his method?

Yes I could, but there are some differences between them.
- perf probe itself opens debuginfo file repeatedly for each event,
  this is just slow. Thus I recommend you to use tracing/kprobe-events
  directly.
  (this can be relaxed by introducing the wildcard support on perf
   probe, however, it still requires to walk through the debuginfo,
   this means it'll take a long time and consume huge memory)
- perf probe/kprobe tracer will slowdown registration process when
  the number of events blown up, because the "kprobe-tracer" itself
  using the linear search on a list for checking event-name conflicts.
  (this can be fixed by using the rbtree instead of the list)
- kprobe-tracer registers events as disabled, but systemtap does it
  as enabled. This means that we'll have no system slowdown which
  comes from probing overhead.

I guess the last one (runtime overhead) is what Frank complaints
about, isn't it? That is actually bigger when we add thousands of
probes. (since the hash table has only 64 slots)

> I can reproduce one weirdness, with just 13 probes added, 'perf probe 
> -l' [which should really be 'perf probe list'!] executes very slowly:
> 
>  # perf stat --null --repeat 3 perf probe -l
> 
>  Performance counter stats for 'perf probe -l' (3 runs):
> 
>0.763640098 seconds time elapsed   
>( +-  1.61% )
> 
> 0.7 seconds is ridiculously long.

This comes from the perf-probe's internal issue. It tries to get
actual lines and files by using debuginfo. I guess most of the time
consumed when processing huge kernel debuginfo.

> 
> Also, here's another bugreport as well: while playing around with 
> 'perf probe' I found that its usability is still very poor. For 
> example I mis-remembered the syntax and typed the obvious way to :
> 
>  # perf probe add __schedule
>  Failed to find path of kernel module.
>  Failed to open debuginfo file.
>Error: Failed to add events. (-2)
> 
> why the heck does a simple and obvious 'perf probe add' not work, why 
> is the strange syntax of 'perf probe -a' forced? Every other perf 
> subcommand uses clean command spaces - see for example 'perf bench'.

But what happens if we have the function names "add"?
And also, as you commented 4years ago, for adding new event,
you don't need -a/--add. you just can do

 # perf probe __schedule

for that purpose. :)

> Also, the error message is totally misleading and uninformative to the 
> level of being passive-aggressive. An error message should directly 
> relate to the mistake performed and should give a good way out of the 
> situation. Who the heck cares that there was no debuginfo file to 
> open? Who cares that the 'path of kernel module' was not found? It has 
> no relation to the bug.

Sorry for confusion, but that is because syntax misunderstanding.
As I said above, the perf probe understand the options as below

 # perf probe (--add ")add (arg1=)__schedule(")

This means that perf needs a debuginfo to get the location of
"__schedule" local variable at "add" function. So, it tried to
open debuginfo and failed.

> 
> An informative error message would be:
> 
>  # perf probe add __schedule
>  Error: Could not find symbol 'add'.
> 
> and that's it. No 'failed to add events' message - obviously the event 
> is not enabled if we cannot find the symbol name.

Yeah, if you run it without __schedule, it shows such kind of error.

$ ./perf probe add
Kernel symbol 'add' not found.
  Error: Failed to add events. (-2)

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Te

[PATCH] drivers: firmware: edd: fixed coding style errors

[Derek Perrin]

Fixed coding style errors. Spaces, tab and parenthesis errors.

Signed-off-by: Derek Perrin 
---
 drivers/firmware/edd.c | 62 +-
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/firmware/edd.c b/drivers/firmware/edd.c
index e229576..c3540d6 100644
--- a/drivers/firmware/edd.c
+++ b/drivers/firmware/edd.c
@@ -62,8 +62,8 @@ struct edd_device {
 
 struct edd_attribute {
struct attribute attr;
-   ssize_t(*show) (struct edd_device * edev, char *buf);
-   int (*test) (struct edd_device * edev);
+   ssize_t(*show) (struct edd_device *edev, char *buf);
+   int (*test) (struct edd_device *edev);
 };
 
 /* forward declarations */
@@ -72,7 +72,7 @@ static struct pci_dev *edd_get_pci_dev(struct edd_device 
*edev);
 
 static struct edd_device *edd_devices[EDD_MBR_SIG_MAX];
 
-#define EDD_DEVICE_ATTR(_name,_mode,_show,_test) \
+#define EDD_DEVICE_ATTR(_name, _mode, _show, _test) \
 struct edd_attribute edd_attr_##_name = {  \
.attr = {.name = __stringify(_name), .mode = _mode },   \
.show   = _show,\
@@ -107,11 +107,11 @@ edd_dev_set_info(struct edd_device *edev, int i)
edev->info = &edd.edd_info[i];
 }
 
-#define to_edd_attr(_attr) container_of(_attr,struct edd_attribute,attr)
-#define to_edd_device(obj) container_of(obj,struct edd_device,kobj)
+#define to_edd_attr(_attr) container_of(_attr, struct edd_attribute, attr)
+#define to_edd_device(obj) container_of(obj, struct edd_device, kobj)
 
 static ssize_t
-edd_attr_show(struct kobject * kobj, struct attribute *attr, char *buf)
+edd_attr_show(struct kobject *kobj, struct attribute *attr, char *buf)
 {
struct edd_device *dev = to_edd_device(kobj);
struct edd_attribute *edd_attr = to_edd_attr(attr);
@@ -169,7 +169,7 @@ edd_show_host_bus(struct edd_device *edev, char *buf)
p += scnprintf(p, left, "\tunknown: %llx\n",
 info->params.interface_path.unknown.reserved);
}
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -228,7 +228,7 @@ edd_show_interface(struct edd_device *edev, char *buf)
 info->params.device_path.unknown.reserved2);
}
 
-   return (p - buf);
+   return p - buf;
 }
 
 /**
@@ -272,7 +272,7 @@ edd_show_version(struct edd_device *edev, char *buf)
return -EINVAL;
 
p += scnprintf(p, left, "0x%02x\n", info->version);
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -280,7 +280,7 @@ edd_show_mbr_signature(struct edd_device *edev, char *buf)
 {
char *p = buf;
p += scnprintf(p, left, "0x%08x\n", edev->mbr_signature);
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -306,7 +306,7 @@ edd_show_extensions(struct edd_device *edev, char *buf)
if (info->interface_support & EDD_EXT_64BIT_EXTENSIONS) {
p += scnprintf(p, left, "64-bit extensions\n");
}
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -336,7 +336,7 @@ edd_show_info_flags(struct edd_device *edev, char *buf)
p += scnprintf(p, left, "no media present\n");
if (info->params.info_flags & EDD_INFO_USE_INT13_FN50)
p += scnprintf(p, left, "use int13 fn50\n");
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -351,7 +351,7 @@ edd_show_legacy_max_cylinder(struct edd_device *edev, char 
*buf)
return -EINVAL;
 
p += snprintf(p, left, "%u\n", info->legacy_max_cylinder);
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -366,7 +366,7 @@ edd_show_legacy_max_head(struct edd_device *edev, char *buf)
return -EINVAL;
 
p += snprintf(p, left, "%u\n", info->legacy_max_head);
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -381,7 +381,7 @@ edd_show_legacy_sectors_per_track(struct edd_device *edev, 
char *buf)
return -EINVAL;
 
p += snprintf(p, left, "%u\n", info->legacy_sectors_per_track);
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -396,7 +396,7 @@ edd_show_default_cylinders(struct edd_device *edev, char 
*buf)
return -EINVAL;
 
p += scnprintf(p, left, "%u\n", info->params.num_default_cylinders);
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -411,7 +411,7 @@ edd_show_default_heads(struct edd_device *edev, char *buf)
return -EINVAL;
 
p += scnprintf(p, left, "%u\n", info->params.num_default_heads);
-   return (p - buf);
+   return p - buf;
 }
 
 static ssize_t
@@ -426,7 +426,7 @@ edd_show_default_sectors_per_track(struct edd_device *edev, 
char *buf)
return -EINVAL;
 
p += scnprintf(p, left, "%u\n", info->params.sectors_per_track);
-   return (p - buf);
+   return p -

Re: [PATCHes - aio / migrate page, please review] Re: bad page state in 3.13-rc4

[Dave Jones]

On Sun, Dec 22, 2013 at 11:09:34AM -0800, Linus Torvalds wrote:
 > On Sat, Dec 21, 2013 at 3:06 PM, Benjamin LaHaise  wrote:
 > >
 > > Linus, feel free to add my Signed-off-by: to your sanitization of
 > > aio_setup_ring() as well, as it works okay in my testing.
 > 
 > Nobody commented on your request for comments, so I applied my patch
 > and pulled your branch, because I'm going to do -rc5 in a few and at
 > least we want this to get testing.
 > 
 > Dave, let's hope that the leak fixes and reference count fixes solve
 > your problem.

Yeah, I'm not really going to have time to run tests again until after
the holidays. I'll shout when I get back if things still don't look right.
(or more likely, if I find something else ;-)

Dave

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

Re: [PATCH -tip v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(), cleanup and fixes crash bugs

[Masami Hiramatsu]

(2013/12/20 22:40), Frank Ch. Eigler wrote:
> Hi -
> 
> mingo wrote:
>> [...]
>> For example a hash table (hashed by probe address) could be used in 
>> addition to the list, to speed up basic operations.
> 
> In the past, when this sort of behavior popped up, it was due to
> machine-wide halt/sync operations being done too eagerly.  At one
> point, the kprobes-unregistration interface grew a mass-unregister API
> to batch them (and save the machine sync's between operations).  Maybe
> with the new checks/logic, a similar batching API may be needed for
> the registration side.

Hmm, OK. Since now kprobes uses ftrace if possible, it will also
takes a time to enabling ftrace entries one by one. Perhaps
we'd better add "enable_kprobes" for it.

> I'll try to get more perf data once the VM comes back up; after a
> couple of hours of the test getting started, it died (for possibly
> unrelated reasons).

Yeah, possibly unrelated one... Hmm, is this reproducable?


> [  133.073670] stap_bc6054113aa63134d411836da0afefc3_123_1261: module 
> verification failed: signature and/or  required key missing - tainting kernel
> [  404.357210] stap_4c53547addc9f25dd87ac4afa0407ed6_36_1948: systemtap: 
> 2.5/0.157, base: a0201000, memory: 
> 15882data/24text/1ctx/2058net/4625alloc kb, probes: 34692
> [ 1655.745075] hrtimer: interrupt took 1225946 ns
> [ 3969.175039] [sched_delayed] sched: RT throttling activated
> [10812.665534] kernel tried to execute NX-protected page - exploit attempt? 
> (uid: 0)
> [10812.665534] BUG: unable to handle kernel paging request at 88007902f038
> [10812.665534] IP: [] 0x88007902f038
> [10812.665534] PGD 2d90067 PUD 2d93067 PMD 8000790001e3 
> [10812.665534] Oops: 0010 [#1] SMP 
> [10812.665534] Modules linked in: 
> stap_4c53547addc9f25dd87ac4afa0407ed6_36_1948(OF) rpcsec_gss_krb5 auth_rpcgss 
> nfsv4 dns_resolver nfs lockd sunrpc fscache ppdev microcode parport_pc 
> parport i2c_piix4 virtio_balloon i2c_core serio_raw virtio_net virtio_pci 
> ata_generic virtio_ring pata_acpi virtio [last unloaded: 
> stap_89fcd2b984e11a30dd08d141e6b47e13_123_1681]
> [10812.665534] CPU: 1 PID: -30720 Comm: x Tainted: GF  O 
> 3.13.0-rc4-01828-g8b349c29efae #1
> [10812.665534] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [10812.665534] BUG: unable to handle kernel paging request at 8f896e09
> [10812.665534] IP: [] do_raw_spin_trylock+0x5/0x60
> [10812.665534] PGD 0 
> [10812.665534] Thread overran stack, or stack corrupted
> [10812.665534] Oops:  [#2] SMP 
> [10812.665534] Modules linked in: 
> stap_4c53547addc9f25dd87ac4afa0407ed6_36_1948(OF) rpcsec_gss_krb5 auth_rpcgss 
> nfsv4 dns_resolver nfs lockd sunrpc fscache ppdev microcode parport_pc 
> parport i2c_piix4 virtio_balloon i2c_core serio_raw virtio_net virtio_pci 
> ata_generic virtio_ring pata_acpi virtio [last unloaded: 
> stap_89fcd2b984e11a30dd08d141e6b47e13_123_1681]
> [10812.665534] CPU: 1 PID: -30720 Comm: x Tainted: GF  O 
> 3.13.0-rc4-01828-g8b349c29efae #1
> [10812.665534] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [10812.665534] BUG: unable to handle kernel paging request at 8f896e09
> [10812.665534] IP: [] do_raw_spin_trylock+0x5/0x60
> [10812.665534] PGD 0 
> [10812.665534] Thread overran stack, or stack corrupted
> [10812.665534] Oops:  [#3] SMP 
> [10812.665534] Modules linked in: 
> stap_4c53547addc9f25dd87ac4afa0407ed6_36_1948(OF) rpcsec_gss_krb5 auth_rpcgss 
> nfsv4 dns_resolver nfs lockd sunrpc fscache ppdev microcode parport_pc 
> parport i2c_piix4 virtio_balloon i2c_core serio_raw virtio_net virtio_pci 
> ata_generic virtio_ring pata_acpi virtio [last unloaded: 
> stap_89fcd2b984e11a30dd08d141e6b47e13_123_1681]
> [10812.665534] CPU: 1 PID: -30720 Comm: x Tainted: GF  O 
> 3.13.0-rc4-01828-g8b349c29efae #1
> [10812.665534] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [10812.665534] BUG: unable to handle kernel paging request at 8f896e09
> [10812.665534] IP: [] do_raw_spin_trylock+0x5/0x60
> [10812.665534] PGD 0 
> [10812.665534] Thread overran stack, or stack corrupted
> [10812.665534] Oops:  [#4] SMP 
> [10812.665534] Modules linked in: 
> stap_4c53547addc9f25dd87ac4afa0407ed6_36_1948(OF) rpcsec_gss_krb5 auth_rpcgss 
> nfsv4 dns_resolver nfs lockd sunrpc fscache ppdev microcode parport_pc 
> parport i2c_piix4 virtio_balloon i2c_core serio_raw virtio_net virtio_pci 
> ata_generic virtio_ring pata_acpi virtio [last unloaded: 
> stap_89fcd2b984e11a30dd08d141e6b47e13_123_1681]
> [10812.665534] CPU: 1 PID: -30720 Comm: x Tainted: GF  O 
> 3.13.0-rc4-01828-g8b349c29efae #1
> [10812.665534] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [10812.665534] BUG: unable to handle kernel paging request at 8f896e09
> [10812.665534] IP: [] do_raw_spin_trylock+0x5/0x60
> [10812.665534] PGD 0 
> [10812.665534] Thread overran stack, or stack corrupted
> [10812.665042] [ cut here ]
> [10812.665042] WARNING: CP

Re: [PATCH v7 00/12] kexec kernel efi runtime support

[Toshi Kani]

On Sat, 2013-12-21 at 17:35 +, Matt Fleming wrote:
> On Fri, 20 Dec, at 06:02:10PM, Dave Young wrote:
> > Here is the V7 patchset for supporting kexec kernel efi runtime.
> > Per pervious discussion I pass the 1st kernel efi runtime mapping
> > via setup_data to 2nd kernel. Besides of the runtime mapping
> > info I also pass the fw_vendor, runtime, config table, smbios
> > physical address in setup_data. EFI spec mentioned fw_vendor,
> > runtime, config table addresses will be converted to virt address
> > after entering virtual mode, but we will use it as physical address
> > in efi_init. For smbios EFI spec did not mention about the address
> > updating, but during my test on a HP workstation, the bios will
> > convert it to Virt addr, thus pass it in setup_data as well.
> 
> OK Dave, I've pulled patches 3-12 into the 'kexec' branch at,
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
> 
> I plan on sending this branch to the tip folks this week for further
> testing.
> 
> Please have a look and make sure I haven't messed anything up when
> dropping the first two patches (though they were very small and trival).
> 
> Toshi, if you could grab that branch and give it a test, that'd be
> excellent.

The kexec branch is missing the following change, which is required for
fast reboot with multi-cpus.

   commit 279f1df915c3a6ed3075d98a849705bf53851f99
   Author: Vivek Goyal 
   Date:   Tue Nov 26 10:25:28 2013 +0800

   kexec: migrate to reboot cpu

With this change added, I confirmed that the branch kernel works fine.

Thanks,
-Toshi

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

Linux 3.13-rc5

[Linus Torvalds]

Ho ho ho,
 Christmas is almost upon us, and -rc5 is the last rc before most of
us gorge ourselves into insensibility. Or cry into our lonely beers.
Or go out for Chinese food. Or whatever you happen to do.

Things seem to be slowly calming down, and I expect that the next week
is going to be calmer yet, for all the obvious reasons. This might
also be a good time to say that even _if_ things continue to calm
down, I think we'll be going to at least -rc8 regardless, since LCA is
fairly early this year, and I won't be opening the merge window for
3.14 until after I'm back from those travels.

Anyway, about rc5: about 40% drivers (gpu, networking, sound,
misc-you-name-it), 15% architecture updates (mainly powerpc this
time), 10% filesystems (ceph/cifs), 10% documentation, and the rest
"misc", including some core kernel (scheduler) and mm (numa) fixes.

Nothing really exciting stands out. The bugs I was involved with were
all sufficiently subtle and unusual that I didn't feel like they
raised any red flags at this point, which is just how I want it. It's
the "how did that ever even pass cursory testing" bugs that make me
upset, and if those existed, people were appropriately ashamed and
quiet about them ;)

So despite me planning on dragging out the rc's a bit, there doesn't
actually look to be any real technical reason for doing that, at least
so far. It all looks good, so please jump in and help test,

  Linus

---
Alex Deucher (4):
  drm/radeon: Fix sideport problems on certain RS690 boards
  drm/radeon/cik: plug in missing blit callback
  drm/radeon: add missing display tiling setup for oland
  Revert "drm/radeon: Implement radeon_pci_shutdown"

Alexander Graf (4):
  KVM: PPC: Book3S: PR: Don't clobber our exit handler id
  KVM: PPC: Book3S: PR: Export kvmppc_copy_to|from_svcpu
  KVM: PPC: Book3S: PR: Make svcpu -> vcpu store preempt savvy
  KVM: PPC: Book3S: PR: Enable interrupts earlier

Alexander Shishkin (1):
  perf: Disable all pmus on unthrottling and rescheduling

Alexey Khoroshilov (1):
  can: ems_usb: fix urb leaks on failure paths

Andy Grover (1):
  target: Remove extra percpu_ref_init

Aneesh Kumar K.V (1):
  powerpc: book3s: kvm: Don't abuse host r2 in exit path

Anton Blanchard (8):
  powerpc: Fix endian issue in setup-common.c
  powerpc: Fix topology core_id endian issue on LE builds
  powerpc/pseries: Fix endian issues in /proc/ppc64/lparcfg
  powerpc/pseries: Fix endian issues in nvram code
  powerpc/pseries: Fix PCIE link speed endian issue
  powerpc/pseries: Fix endian issues in MSI code
  powerpc: Fix endian issues in crash dump code
  powerpc/powernv: Fix endian issue in opal_xscom_read

Axel Lin (1):
  clocksource: time-efm32: Select CLKSRC_MMIO

Ben Widawsky (7):
  drm/i915/bdw: Add BDW to ULT macro
  drm/i915/bdw: GEN8 backlight support
  drm/i915/bdw: Do gen6 style reset for gen8
  drm/i915/bdw: Free correct number of ppgtt pages
  drm/i915/bdw: Add comment about gen8 HWS PGA
  drm/i915/bdw: Limit GTT to 2GB
  drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell

Benjamin Herrenschmidt (1):
  powerpc/powernv: Fix OPAL LPC access in Little Endian

Benjamin LaHaise (2):
  aio: fix kioctx leak introduced by "aio: Fix a trinity splat"
  aio/migratepages: make aio migrate pages sane

Beomho Seo (1):
  iio: cm36651: Changed return value of read function

Bjørn Mork (1):
  usb: cdc-wdm: manage_power should always set needs_remote_wakeup

Bo Shen (3):
  ASoC: atmel_ssc_dai: add dai trigger ops
  ASoC: sam9x5_wm8731: change to work in DSP A mode
  ASoC: wm8904: fix DSP mode B configuration

Bob Gilligan (1):
  neigh: Netlink notification for administrative NUD state change

Boris BREZILLON (1):
  usb: ohci-at91: fix irq and iomem resource retrieval

Charles Keepax (2):
  ASoC: wm5110: Correct HPOUT3 DAPM route typo
  ASoC: wm_adsp: Add small delay while polling DSP RAM start

Chris Ruehl (1):
  usb: phy-tegra-usb.c: wrong pointer check for remap UTMI

Chris Wilson (3):
  drm/i915: Do not clobber config status after a forced restore of hw state
  drm/i915: Hold mutex across i915_gem_release
  drm/i915: Repeat eviction search after idling the GPU

Christian König (1):
  drm/radeon: fix typo in cik_copy_dma

Christoph Hellwig (1):
  xfs: remove xfsbdstrat error

Dan Carpenter (2):
  usb: phy: twl6030-usb: signedness bug in twl6030_readb()
  drivers: phy: tweaks to phy_create()

Dan Williams (7):
  dma: fix build warnings in ppc4xx
  dma: fix fsldma build warnings
  dmatest: fix build warning on mips
  dma: fix build warnings in txx9
  dmaengine: fix enable for high order unmap pools
  dmaengine: fix sleep in atomic
  net_dma: mark broken

Daniel Vetter (3):
  drm/i915: fix pm init ordering
  drm/i915: Fix use-after-free in do_switch
  drm/i915: don't update 

Re: GPF in aio_migratepage

[Benjamin LaHaise]

Hi Kristian,

On Sun, Dec 22, 2013 at 09:44:45PM +0100, Kristian Nielsen wrote:
> There are other changes in that area since 3.13-rc1 though.
> 
> Anyway, I am now running with 3.13-rc4 and will report if I see anything.
> Given that I do not have any way to reproduce (I only ever saw this once),
> this seems the best that can be done for now.

Linus just pushed out 3.13-rc5 that has changes to aio_migratepage() that 
should make it much more robust, as well as other fixes.  Can you please 
give it a spin as well and let me know if it works?  Thanks a bunch!

-ben

> Thanks for following up on this!
> 
>  - Kristian.

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

Re: [PATCH -tip 1/3] [CLEANUP] perf-probe: Expand given path to absolute path

[Masami Hiramatsu]

(2013/12/21 3:00), Arnaldo Carvalho de Melo wrote:
> Em Fri, Dec 20, 2013 at 10:02:57AM +, Masami Hiramatsu escreveu:
>> Expand given path to absolute path in option parser,
>> except for a module name. Instead of expanding it later,
>> this get the absolute path in early stage.
> 
> What is the problem this solves?
> 
> Can you provide some output showing the problem, i.e. before you apply
> this patch?

No, this is just a code cleanup, for the later enhancements.
Should I put it into the next patch?

Thank you,

> 
> Then can you provide the output after the patch is applied?
> 
> - Arnaldo
>  
>> Signed-off-by: Masami Hiramatsu 
>> ---
>>  tools/perf/builtin-probe.c|9 +
>>  tools/perf/util/probe-event.c |   11 ++-
>>  2 files changed, 11 insertions(+), 9 deletions(-)
>>
>> diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
>> index 6ea9e85..b40d064 100644
>> --- a/tools/perf/builtin-probe.c
>> +++ b/tools/perf/builtin-probe.c
>> @@ -180,6 +180,15 @@ static int opt_set_target(const struct option *opt, 
>> const char *str,
>>  else
>>  return ret;
>>  
>> +/* Expand given path to absolute path, except for modulename */
>> +if (params.uprobes || strchr(str, '/')) {
>> +str = realpath(str, NULL);
>> +if (!str) {
>> +pr_warning("Failed to find the path of %s.\n",
>> +   str);
>> +return ret;
>> +}
>> +}
>>  params.target = str;
>>  ret = 0;
>>  }
>> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>> index d7cff57..05be5de 100644
>> --- a/tools/perf/util/probe-event.c
>> +++ b/tools/perf/util/probe-event.c
>> @@ -2281,7 +2281,7 @@ static int convert_name_to_addr(struct 
>> perf_probe_event *pev, const char *exec)
>>  struct perf_probe_point *pp = &pev->point;
>>  struct symbol *sym;
>>  struct map *map = NULL;
>> -char *function = NULL, *name = NULL;
>> +char *function = NULL;
>>  int ret = -EINVAL;
>>  unsigned long long vaddr = 0;
>>  
>> @@ -2297,12 +2297,7 @@ static int convert_name_to_addr(struct 
>> perf_probe_event *pev, const char *exec)
>>  goto out;
>>  }
>>  
>> -name = realpath(exec, NULL);
>> -if (!name) {
>> -pr_warning("Cannot find realpath for %s.\n", exec);
>> -goto out;
>> -}
>> -map = dso__new_map(name);
>> +map = dso__new_map(exec);
>>  if (!map) {
>>  pr_warning("Cannot find appropriate DSO for %s.\n", exec);
>>  goto out;
>> @@ -2367,7 +2362,5 @@ out:
>>  }
>>  if (function)
>>  free(function);
>> -if (name)
>> -free(name);
>>  return ret;
>>  }
>>
> 


-- 
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 -tip 2/3] perf-probe: Support dwarf on uprobe events

[Masami Hiramatsu]

(2013/12/21 3:01), Arnaldo Carvalho de Melo wrote:
> Em Fri, Dec 20, 2013 at 10:02:59AM +, Masami Hiramatsu escreveu:
>> Support dwarf(debuginfo) based operations for uprobe events.
>> With this change, perf probe can analyze debuginfo of user
>> application binary to set up new uprobe event.
>> This allows perf-probe --add/--line works with -x option.
>> (Actually, --vars has already accepted -x option)
> 
> Can you provide an example?
> 

OK, here is the examples from 0/3. :)
Or, should I better put this into the patch description too?

For example)
- Shows the probe-able lines of the given function

# ./perf probe -x perf --line map__load

  0  int map__load(struct map *map, symbol_filter_t filter)
  1  {
  2 const char *name = map->dso->long_name;
int nr;

  5 if (dso__loaded(map->dso, map->type))
  6 return 0;

  8 nr = dso__load(map->dso, map, filter);
  9 if (nr < 0) {
 10 if (map->dso->has_build_id) {


- Shows the available variables of the given line

# ./perf probe -x perf --vars map__load:8
Available variables at map__load:8
@
char*   name
struct map* map
symbol_filter_t filter
@
char*   name
symbol_filter_t filter
@
char*   name
symbol_filter_t filter
@
char*   name
struct map* map
symbol_filter_t filter


- Set a probe with available vars on the given line

# ./perf probe -x perf --add 'map__load:8 $vars'

Added new events:
  probe_perf:map__load (on map__load:8 with $vars)
  probe_perf:map__load_1 (on map__load:8 with $vars)
  probe_perf:map__load_2 (on map__load:8 with $vars)
  probe_perf:map__load_3 (on map__load:8 with $vars)

You can now use it in all perf tools, such as:

perf record -e probe_perf:map__load_3 -aR sleep 1


> Showing output from commands when new features are implemented can speed
> up the process of having it used :-)
> 
> - Arnaldo
>  
>> Signed-off-by: Masami Hiramatsu 
>> ---
>>  tools/perf/builtin-probe.c|2 
>>  tools/perf/util/probe-event.c |  230 
>> +++--
>>  2 files changed, 155 insertions(+), 77 deletions(-)
>>
>> diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
>> index b40d064..7fc566a 100644
>> --- a/tools/perf/builtin-probe.c
>> +++ b/tools/perf/builtin-probe.c
>> @@ -420,7 +420,7 @@ int cmd_probe(int argc, const char **argv, const char 
>> *prefix __maybe_unused)
>>  }
>>  
>>  #ifdef HAVE_DWARF_SUPPORT
>> -if (params.show_lines && !params.uprobes) {
>> +if (params.show_lines) {
>>  if (params.mod_events) {
>>  pr_err("  Error: Don't use --line with"
>> " --add/--del.\n");
>> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>> index 05be5de..e27cecb 100644
>> --- a/tools/perf/util/probe-event.c
>> +++ b/tools/perf/util/probe-event.c
>> @@ -186,6 +186,90 @@ static int init_user_exec(void)
>>  return ret;
>>  }
>>  
>> +static const char *__target_symbol;
>> +static struct symbol *__result_sym;
>> +
>> +static int filter_target_symbol(struct map *map __maybe_unused,
>> +struct symbol *sym)
>> +{
>> +if (strcmp(__target_symbol, sym->name) == 0) {
>> +__result_sym = sym;
>> +return 0;
>> +}
>> +return 1;
>> +}
>> +
>> +/* Find the offset of the symbol in the executable binary */
>> +static int find_symbol_offset(const char *exec, const char *function,
>> +  unsigned long *offs)
>> +{
>> +struct symbol *sym;
>> +struct map *map = NULL;
>> +int ret = -EINVAL;
>> +
>> +if (!offs)
>> +return -EINVAL;
>> +
>> +map = dso__new_map(exec);
>> +if (!map) {
>> +pr_warning("Cannot find appropriate DSO for %s.\n", exec);
>> +goto out;
>> +}
>> +pr_debug("Search %s in %s\n", function, exec);
>> +__target_symbol = function;
>> +__result_sym = NULL;
>> +if (map__load(map, filter_target_symbol)) {
>> +pr_err("Failed to find %s in %s.\n", function, exec);
>> +goto out;
>> +}
>> +sym = __result_sym;
>> +if (!sym) {
>> +pr_warning("Cannot find %s in DSO %s\n", function, exec);
>> +goto out;
>> +}
>> +
>> +*offs = (map->start > sym->start) ?  map->start : 0;
>> +*offs += sym->start + map->pgoff;
>> +ret = 0;
>> +out:
>> +if (map) {
>> +dso__delete(map->dso);
>> +map__delete(map);
>> +}
>> +return ret;
>> +}
>> +
>> +static int convert_exec_to_group(const char *exec, char **result)
>> +{
>> +char *ptr1, *ptr2, *exec_copy;
>> +char buf[64];
>> +int ret;
>> +
>> +exec_copy = strdup(exec);

[ANNOUNCE] kmod 16

[Lucas De Marchi]

kmod 16 is out:

ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-16.tar.xz
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-16.tar.sign

Most important change besides the bug fixes are:

 * we don't have an option in rmmod to wait module removal anymore.
This is gone from kernel and now is gone from kmod too. The constant
KMOD_REMOVE_NOWAIT in libkmod is still there for backward
compatibility but it's always enforced, passing O_NONBLOCK to
delete_module(2).

 * warn on wrong devname specification in depmod to help kernel
developers catch the bug earlier.

Shortlog is below.


Lucas De Marchi

---

Anders Olofsson (1):
  build: Allow disabling maintainer mode

John Spencer (1):
  testsuite: fix usage of reserved names

Lucas De Marchi (19):
  Fix usage of readdir_r()
  build: remove check for typeof
  util: Add ALIGN_POWER2
  libkmod-hash: always align n_buckets to power of 2
  libkmod: always pass O_NONBLOCK to kernel
  rmmod: remove --wait option
  NEWS: add entries
  build-sys: enable colored diagnostics if available
  testsuite: Move test-alias to test-util
  util: Add cleanup attribute
  config: Use _cleanup_free_
  util: use _cleanup_free_ on path_make_absolute_cwd()
  testsuite: add basic test for getline_wrapped
  util: Be OOM-safe and use _cleanup_free_
  array: avoid duplicate code to reallocate
  file: use _cleanup_free_
  module: use _cleanup_free and remove useless call to free()
  Use C11's noreturn
  kmod 16

Saul Wold (2):
  Makefile.am: Add target to all cross-compilation of testsuite
  Makefile.am: add mkdir testsuite

Thomas Petazzoni (1):
  Add configure check for _Static_assert()

Tom Gundersen (1):
  depmod: warn on invalid devname specification
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -tip 3/3] perf-probe: Use the actual address as a hint for uprobes

[Masami Hiramatsu]

(2013/12/21 3:03), Arnaldo Carvalho de Melo wrote:
> Em Fri, Dec 20, 2013 at 10:03:02AM +, Masami Hiramatsu escreveu:
>> Use the actual address of tracepoint as a hint to find
>> different local symbols. Since sometimes there are local
>> symbols which have same name, it is impossible to determine
>> which symbol should be used. This saves the actual address
>> from debuginfo and use it as a hint later.
>>
>> The reason why we don't use the address directly is that
>> the address stored in the debuginfo has some section offset.
>> Thus this just uses the last 12 bits of the address as a
>> hint when searching the symbol in the map.
> 
> Again, can you provide an example of cases where before this patch the
> problem happens, with actual command output?

Ok, here is what the problem I've met,

Without this patch;
# perf probe -vfn -x perf scnprintf 2>&1
[...]
Writing event: p:probe_perf/scnprintf 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x8fd10
Writing event: p:probe_perf/scnprintf_1 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0xc02d0
Writing event: p:probe_perf/scnprintf_2 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0xc02d0
Writing event: p:probe_perf/scnprintf_3 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x9ea00
Writing event: p:probe_perf/scnprintf_4 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x25f36
Writing event: p:probe_perf/scnprintf_5 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x29f90
Writing event: p:probe_perf/scnprintf_6 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x29f90
Writing event: p:probe_perf/scnprintf_7 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0xc02d0
Writing event: p:probe_perf/scnprintf_8 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0xc02d0
Writing event: p:probe_perf/scnprintf_9 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0xc02d0

You can see there are many 0xc02d0, which is the last symbol of scnprintf in 
perf.
# nm perf | grep scnprintf
[...]
004a3a30 t scnprintf
0041dad0 t scnprintf
00425480 t scnprintf
00442b20 t scnprintf
00448b20 t scnprintf
004525e0 t scnprintf
004555f0 t scnprintf
004678c0 t scnprintf
004c02d0 t scnprintf

With this patch,
# perf probe -vfn -x perf scnprintf 2>&1
[...]
Writing event: p:probe_perf/scnprintf 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x1a820
Writing event: p:probe_perf/scnprintf_1 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x1dad0
Writing event: p:probe_perf/scnprintf_2 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x25480
Writing event: p:probe_perf/scnprintf_3 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x25560
Writing event: p:probe_perf/scnprintf_4 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x25f36
Writing event: p:probe_perf/scnprintf_5 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x29f90
Writing event: p:probe_perf/scnprintf_6 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x3e050
Writing event: p:probe_perf/scnprintf_7 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x48b20
Writing event: p:probe_perf/scnprintf_8 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x48b20
Writing event: p:probe_perf/scnprintf_9 
/kbuild/ksrc/linux-2.6/tools/perf/perf:0x525e0

Oops, I thought 12bits are enough, but it seems not...

BTW, I'm not sure why debuginfo and nm shows symbol address + 0x40,
and why the perf's map/symbol can remove this offset. Could you tell me
how it works?
If I can get the offset (0x40) from binary, I don't need this kind
of ugly hacks...

Thank you,

> 
> Then output from the same command with the patch applied, showing how it
> works after the fix.
> 
> This way users can more quickly use your work and, among others, I can
> help you by validating it in my test machines.
> 
> Thanks,
> 
> - Arnaldo
>  
>> Signed-off-by: Masami Hiramatsu 
>> ---
>>  tools/perf/util/probe-event.c  |   16 +---
>>  tools/perf/util/probe-event.h  |1 +
>>  tools/perf/util/probe-finder.c |1 +
>>  3 files changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>> index e27cecb..e5fbda3 100644
>> --- a/tools/perf/util/probe-event.c
>> +++ b/tools/perf/util/probe-event.c
>> @@ -187,11 +187,18 @@ static int init_user_exec(void)
>>  }
>>  
>>  static const char *__target_symbol;
>> +static unsigned long __target_hint;
>>  static struct symbol *__result_sym;
>> +#define HINT_MASK   0xfff
>>  
>>  static int filter_target_symbol(struct map *map __maybe_unused,
>>  struct symbol *sym)
>>  {
>> +/* Check the last bits is same */
>> +if (__target_hint)
>> +if ((sym->start & HINT_MASK) != (__target_hint & HINT_MASK))
>> +return 0;
>> +
>>  if (strcmp(__target_symbol, sym->name) == 0) {
>>  __result_sym = sym;
>>  return 0;
>> @@ -201,7 +208,7 @@ static int filter_target_symbol(struct map *map 
>> __maybe_unused,
>>  
>>  /* Find the offset of the symbol in the executable binary */
>>  static int find_symbol_offset(const char *exec, const char *function,
>> -

Re: [PATCH] drivers: firmware: edd: fixed coding style errors

[Joe Perches]

On Sun, 2013-12-22 at 15:17 -0600, Derek Perrin wrote:
> Fixed coding style errors. Spaces, tab and parenthesis errors.

There's a real error in this patch.

When you do whitespace only changes, please
verify that the old and new object files produced
are unchanged.

One trivial bit too,

> diff --git a/drivers/firmware/edd.c b/drivers/firmware/edd.c
[]
> @@ -62,8 +62,8 @@ struct edd_device {
>  
>  struct edd_attribute {
>   struct attribute attr;
> - ssize_t(*show) (struct edd_device * edev, char *buf);
> - int (*test) (struct edd_device * edev);
> + ssize_t(*show) (struct edd_device *edev, char *buf);
> + int (*test) (struct edd_device *edev);

I think most prefer function pointer prototypes like:

size_t (*show)(struct edd_device *edev, char *buf);
int (*test)(struct edd_device *edev);

> @@ -791,7 +791,7 @@ edd_exit(void)
>   struct edd_device *edev;
>  
>   for (i = 0; i < edd_num_devices(); i++) {
> - if ((edev = edd_devices[i]))
> + if ((edev == edd_devices[i]))
>   edd_device_unregister(edev);
>   }
>   kset_unregister(edd_kset);

This is wrong.
It's an assignment in the block and it's important.

This could be rewritten as:

for (i = 0; i < edd_num_devices(); i++) {
edev = edd_devices[i];
if (edev)
edd_device_unregister(edev);
}

or just remove the temporary.

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

Re: 3.12.5 CRASH/FREEZE

[Pavel Vasilyev]

20.12.2013 19:05, Sebastian Andrzej Siewior пишет:
> On 12/20/2013 03:57 PM, Pavel Vasilyev wrote:
>>
>> Same bug if attach to ehci hub.
>>
>> ksoftird/0 process of loading the CPU upto 100% Sometimes process
>> irq17/0 - ehci_hcd  or xhci_hcd. After taking the camera out of the
>> socket, the load does not fall, keyboard and console blocked
> 
> Okay, but this problem is unique to your webcam. Keyboard & mice to
> work as usual?
> Could please provide me the addr2line either for the ehci or xhci? I've
> been browsing to the code and I didn't see anything obvious.
> 

Too many bugs, too many computers ...

3.12.5-rt7 work ONLY in UP-mode!!! cmdline: nosmp maxcpus=1

In SMP mode, problems arise in different places on different computers.
On Intel Atom - USB, webcam and console. On the Opteron 285 system
does not boot, can't mount devtmpfs, XFS partitions ...

I can not get to catch the error and find a place neither in debug mode or in
normal. Because everything is frozen completely, and get to the console or logs
is not possible.
I described one situation where had run top and see that the process
ksoftirqd/0 use CPU upto 100%

P.S.
3.12.5-rt7 still work Basic-RT mode.






-- 

 Pavel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] at91: dt for 3.14 #2

[Olof Johansson]

On Fri, Dec 20, 2013 at 12:03:18AM +0100, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> Some more DT material for 3.14 based on top of what I already sent (in
> your at91/dt branch). Nothing really surprising...
> 
> Thanks, best regards,
> 
> The following changes since commit ca594844e4a53f778811c06feef60bdf36bc5fec:
> 
>   ARM: at91/at91rm9200ek.dts: rearrange nodes in address ascending order 
> (2013-12-09 15:08:57 +0100)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-dt2
> 
> for you to fetch changes up to 45e5c2cb6bc1c52c7134f898ea326a422dd75761:
> 
>   ARM: at91/dt: add clk properties to sama5d3 TDES device node (2013-12-19 
> 23:00:06 +0100)

Pulled into next/dt.
Thanks!

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

Re: 3.12.5 CRASH/FREEZE

[Pavel Vasilyev]

20.12.2013 19:05, Sebastian Andrzej Siewior пишет:
> On 12/20/2013 03:57 PM, Pavel Vasilyev wrote:

... The last two years I have worked with 3.2 kernel and patches for it.
Recently, we have a new equipment that partially works with version 3.2.53.
Therefore it was decided to move to version 3.12. What was my surprise that none
of the 15 (or old models, or new )computers does not start with the same
.configs on a new version of the kernel and rt-patches. :)



-- 

 Pavel.



signature.asc
Description: OpenPGP digital signature

Re: GPF in aio_migratepage

[Kristian Nielsen]

Benjamin LaHaise  writes:

> Linus just pushed out 3.13-rc5 that has changes to aio_migratepage() that 
> should make it much more robust, as well as other fixes.  Can you please 
> give it a spin as well and let me know if it works?  Thanks a bunch!

Ok, will do.

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

iio_utils.h bug?

[Zubair Lutfullah :]

Hi,

A guy posted this fix on my blog. I couldn't make sense of it.

Thought I'd post it here. I'll send a proper patch file if 
I knew what commit log I needed to write.
And I can't exactly sign-off :s.

I asked him to post but he couldn't/wouldn't.

Regards
ZubairLK


"Defend against buffer overflow of ci_array:

 code always overwrites one entry beyond end of array, now fixed
--Craig Markwardt"

iio_utils.h

@@ -335,6 +335,7 @@ inline int build_channel_array(const char *device_dir,
   while (ent = readdir(dp), ent != NULL) {
 if (strcmp(ent->d_name + strlen(ent->d_name) - strlen("_en"),
  "_en") == 0) {
+  int current_enabled = 0;
   current = &(*ci_array)[count++];
   ret = asprintf(&filename,
"%s/%s", scan_el_dir, ent->d_name);
   if (ret < 0) {
 ret = -ENOMEM;
 /* decrement count to avoid freeing name */
 count--;
 goto error_cleanup_array;
   }

   sysfsfp = fopen(filename, "r");

   if (sysfsfp == NULL) {
 free(filename);
 ret = -errno;
 goto error_cleanup_array;
   }

-  fscanf(sysfsfp, "%u", ¤t->enabled);
+  fscanf(sysfsfp, "%u", ¤t_enabled);
   fclose(sysfsfp);

-  if (!current->enabled) {
+  if (!current_enabled) {
 free(filename);
 count--;
 continue;
   }
+  current->enabled = current_enabled;
   current->scale = 1.0;
   current->offset = 0;
   current->name = strndup(ent->d_name,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/2] sctp: Consolidate and ratelimit deprecation warnings

[David Miller]

From: Neil Horman 
Date: Tue, 17 Dec 2013 11:19:57 -0500

> The SCTP protocol has several deprecation warnings in its setsockopt path that
> can be triggered by unprivlidged users.  Since these are not ratelimited, we 
> can
> spam the logs quite easily here.  Since these are all deprecation warnings, 
> and
> that type of warning isn't uncommon in the rest of the kernel, lets make a
> common pr_warn_deprecated macro to produce somewhat generalized ratelimited
> deprecation warnings easily
> 
> Signed-off-by: Neil Horman 

Neil, I really wish you would CC: netdev on all of the patches in the
series.  Otherwise only some of them end up in patchwork, and this makes
a lot more work for me if I want to actually apply this, which I do.

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

Re: [PATCH v4 3/4] futex: Document ordering guarantees

[Davidlohr Bueso]

On Thu, 2013-12-19 at 15:19 -0800, Darren Hart wrote:
> On Thu, 2013-12-19 at 15:05 -0800, Randy Dunlap wrote:
> > On 12/19/13 13:07, Darren Hart wrote:
> > > On Thu, 2013-12-19 at 13:00 -0800, Davidlohr Bueso wrote:
> > >> On Thu, 2013-12-19 at 12:51 -0800, Randy Dunlap wrote:
> > >>> On 12/19/13 12:45, Davidlohr Bueso wrote:
> >  From: Thomas Gleixner 
> > 
> >  That's essential, if you want to hack on futexes.
> > 
> >  Cc: Ingo Molnar 
> >  Cc: Darren Hart 
> >  Acked-by: Peter Zijlstra 
> >  Cc: Thomas Gleixner 
> >  Cc: Paul E. McKenney 
> >  Cc: Mike Galbraith 
> >  Cc: Jeff Mahoney 
> >  Cc: Linus Torvalds 
> >  Cc: Scott Norton 
> >  Cc: Tom Vaden 
> >  Cc: Aswin Chandramouleeswaran 
> >  Cc: Waiman Long 
> >  Cc: Jason Low 
> >  Signed-off-by: Thomas Gleixner 
> >  Signed-off-by: Davidlohr Bueso 
> >  ---
> >   kernel/futex.c | 57 
> >  +
> >   1 file changed, 57 insertions(+)
> > 
> >  diff --git a/kernel/futex.c b/kernel/futex.c
> >  index 577481d..af1fc31 100644
> >  --- a/kernel/futex.c
> >  +++ b/kernel/futex.c
> >  @@ -69,6 +69,63 @@
> >   
> >   #include "locking/rtmutex_common.h"
> >   
> >  +/*
> >  + * Basic futex operation and ordering guarantees:
> >  + *
> >  + * The waiter reads the futex value in user space and calls
> >  + * futex_wait(). It computes the hash bucket and acquires the hash
> > >>>
> > >>> doesIt
> > >>> refer to "the waiter" or to futex_wait()?
> > >>> I read it as referring to the waiter, but ISTM that the comments are 
> > >>> using It
> > >>> to refer to futex_wait()... ???
> > >>>
> > >>
> > >> Yes, it refers to futex_wait(), which IMO in a futex context is pretty
> > >> clear.
> > > 
> > > 
> > > Agreed.
> > > 
> > > 
> > 
> > I'll just have to get by with disagreeing with both of you then.
> > I say that the pronoun's antecedent is ambiguous (unclear).
> > 
> 
> You are correct from a purely grammatical perspective, no argument
> there. I just feel that the comment is clear enough from the context -
> although perhaps people that hack on futexes should be excluded from
> having an opinion here as we are biased :-)
> 
> If Davidlohr is going to resubmit for other reasons, then by all means,
> please correct this per Randy's suggestion - I just didn't want to put
> him (Davidlohr ;-) through another round of patches for this alone.
> 
> Thanks for ensuring our docs are as clear as possible Randy!

Absolutely.

I've found that we have the same grammatical error when describing
futex_wake() as well, so I've updated the doc to say "This function"
instead of "It".

Thanks,
Davidlohr

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

Re: [PATCH v6 2/2] PCI: Try best to allocate pref mmio 64bit above 4g

[Bjorn Helgaas]

On Thu, Dec 19, 2013 at 1:44 PM, Yinghai Lu  wrote:

Let me see if I can figure out what you're trying to do here.  Please
correct me if I'm wrong:

> When one of children resources does not support MEM_64, MEM_64 for
> bridge get reset, so pull down whole pref resource on the bridge under 4G.

When we allocate space for a bridge's prefetchable window, we
currently look at the devices behind the bridge and put the window
below 4GB if any of those children has a 32-bit prefetchable BAR.

This maximizes the use of prefetch, at the cost of using more 32-bit
address space.

> If the bridge support pref mem 64, will only allocate that with pref mem64 to
> children that support it.
> For children resources if they only support pref mem 32, will allocate them
> from non pref mem instead.

You are changing this so that we will always try to put a bridge's
64-bit prefetchable window above 4GB, regardless of what devices are
behind the bridge.  If a device behind the bridge has a 32-bit
prefetchable BAR, we will place that BAR in the bridge's 32-bit
non-prefetchable window.

This minimizes the use of the 32-bit address space, at the cost of not
being able to use prefetch as much.

> If the bridge only support 32bit pref mmio, will still have all children pref
> mmio under that.

Obviously, if a bridge has a prefetchable window that's only 32 bits,
64-bit prefetchable BARs behind the bridge will have to be in that
32-bit prefetchable window or the 32-bit non-prefetchable window.  And
if the bridge has no prefetchable window at all, every memory BAR
behind the bridge will have to be in the 32-bit non-prefetchable
window.

I'll look at the actual patch later; I just want to make sure I
understand your intent first.

Bjorn

> -v2: Add release bridge res support with bridge mem res for pref_mem children 
> res.
> -v3: refresh and make it can be applied early before for_each_dev_res 
> patchset.
> -v4: fix non-pref mmio 64bit support found by Guo Chao.
>
> Signed-off-by: Yinghai Lu 
> Tested-by: Guo Chao 
> ---
>  drivers/pci/setup-bus.c | 138 
> 
>  drivers/pci/setup-res.c |  20 ++-
>  2 files changed, 111 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 138bdd6..b29504f 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -713,12 +713,11 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
> bus resource of a given type. Note: we intentionally skip
> the bus resources which have already been assigned (that is,
> have non-NULL parent resource). */
> -static struct resource *find_free_bus_resource(struct pci_bus *bus, unsigned 
> long type)
> +static struct resource *find_free_bus_resource(struct pci_bus *bus,
> +unsigned long type_mask, unsigned long type)
>  {
> int i;
> struct resource *r;
> -   unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
> - IORESOURCE_PREFETCH;
>
> pci_bus_for_each_resource(bus, r, i) {
> if (r == &ioport_resource || r == &iomem_resource)
> @@ -815,7 +814,8 @@ static void pbus_size_io(struct pci_bus *bus, 
> resource_size_t min_size,
> resource_size_t add_size, struct list_head *realloc_head)
>  {
> struct pci_dev *dev;
> -   struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO);
> +   struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO,
> +   IORESOURCE_IO);
> resource_size_t size = 0, size0 = 0, size1 = 0;
> resource_size_t children_add_size = 0;
> resource_size_t min_align, align;
> @@ -915,15 +915,17 @@ static inline resource_size_t 
> calculate_mem_align(resource_size_t *aligns,
>   * guarantees that all child resources fit in this size.
>   */
>  static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
> -unsigned long type, resource_size_t min_size,
> -   resource_size_t add_size,
> -   struct list_head *realloc_head)
> +unsigned long type, unsigned long type2,
> +unsigned long type3,
> +resource_size_t min_size, resource_size_t add_size,
> +struct list_head *realloc_head)
>  {
> struct pci_dev *dev;
> resource_size_t min_align, align, size, size0, size1;
> resource_size_t aligns[12]; /* Alignments from 1Mb to 2Gb */
> int order, max_order;
> -   struct resource *b_res = find_free_bus_resource(bus, type);
> +   struct resource *b_res = find_free_bus_resource(bus,
> +mask | IORESOURCE_PREFETCH, type);
> unsigned int mem64_mask = 0;
> resource_size_t children_add_size = 0;
>
> @@ -944,7 +946,9 @@ static int pbus_size_mem(struct pci_bus 

[PULL] fixes for virtio balloon and non-MMU kallsyms

[Rusty Russell]

The following changes since commit af91706d5ddecb4a9858cca9e90d463037cfd498:

  ima: store address of template_fmt_copy in a pointer before calling strsep 
(2013-11-30 13:09:53 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git 
tags/fixes-for-linus

for you to fetch changes up to 7122c3e9154b5d9a7422f68f02d8acf050fad2b0:

  scripts/link-vmlinux.sh: only filter kernel symbols for arm (2013-12-10 
16:49:19 +1030)


Refactoring broke the balloon driver, and fixing kallsyms on ARM broke
some (non-ARM) MMUless setups, so we're making that fix ARM-only for now.

Unfortunately, the ARM refactoring which broke kallsyms/perf was CC:stable,
so the fix (which broken non-ARM) was also CC:stable, so now the partial
reversion is also CC:stable...

Cheers,
Rusty.


Luiz Capitulino (1):
  virtio_balloon: update_balloon_size(): update correct field

Ming Lei (1):
  scripts/link-vmlinux.sh: only filter kernel symbols for arm

 drivers/virtio/virtio_balloon.c | 2 +-
 scripts/link-vmlinux.sh | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irq-renesas-irqc: simplify irq_set_type() method

[Simon Horman]

On Thu, Dec 19, 2013 at 06:53:32PM +0900, Magnus Damm wrote:
> On Thu, Dec 19, 2013 at 5:24 PM, Simon Horman  wrote:
> > On Sat, Dec 14, 2013 at 03:09:31AM +0300, Sergei Shtylyov wrote:
> >> Value 0 of the sense  selection field of CONFIG_n register means "disable 
> >> event
> >> detection" and serves in irqc_sense[] for marking the invalid values of 
> >> the IRQ
> >> type (by just omitting initializers). There is no need for 
> >> INTC_IRQ_SENSE_VALID
> >> and hence INTC_IRQ_SENSE() as all field values matching to the  valid IRQ 
> >> types
> >> are non-zero anyway.
> >>
> >> Signed-off-by: Sergei Shtylyov 
> >
> > Magnus, could you review this?
> 
> The patch is IMO only cosmetic so I can't say I care that much. But
> since you ask. =)
> 
> Acked-by: Magnus Damm 

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

I want to transfer an abandoned

[mr.sinzoganchabi]

Hi friend I am a banker in IDB BANK. I want to transfer an abandonedUSD5.
5Million to your Bank account. 40/percent will be your share. No risk involved 
but keep it as secret. Contact me for more details.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re : Re: [PATCH] Squashfs: add asynchronous read support

[Minchan Kim]

On Sat, Dec 21, 2013 at 11:05:51AM +0900, Chanho Min wrote:
> 
> > Please don't break thread.
> > You should reply to my mail instead of your original post.
> Sorry, It seems to be my mailer issue. I'm trying to fix it.
> 
> > It's a result which isn't what I want to know.
> > What I wnat to know is why upper layer issues more I/O per second.
> > For example, you read 32K so MM layer will prepare 8 pages to read in but
> > at issuing at a first page, squashfs make 32 pages and fill the page cache
> > if we assume you use 128K compression so MM layer's already prepared 7
> > page
> > would be freed without further I/O and do_generic_file_read will wait for
> > completion by lock_page without further I/O queueing. It's not suprising.
> > One of page freed is a READA marked page so readahead couldn't work.
> > If readahead works, it would be just by luck. Actually, by simulation
> > 64K dd, I found readahead logic would be triggered but it's just by luck
> > and it's not intended, I think.
> MM layer's readahead pages would not be freed immediately.
> Squashfs can use them by grab_cache_page_nowait and READA marked page is 
> available.
> Intentional or not, readahead works pretty well. I checked in experiment.


read_pages
  for(page_idx ...) {
if (!add_to_page_cache_lru)) { <-- 1)
  mapping->a_ops->readpage(filp, page)
squashfs_readpage
  for (i ...) {   2)  Here, 31 pages are inserted into page cache
grab_cahe_page_nowait <--/
  add_to_page_cache_lru 
  }
}
/*
 * 1) will be failed with EEXIST by 2) so every pages other than first page
 * in list would be freed
 */
page_cache_release(page) 
  }
   
If you see ReadAhead works, it is just by luck as I told you.
Please simulate it with 64K dd.

> 
> > If first issued I/O complete, squashfs decompress the I/O with 128K pages
> > so all 4 iteration(128K/32K) would be hit in page cache.
> > If all 128K hit in page cache, mm layer start to issue next I/O and
> > repeat above logic until you ends up reading all file size.
> > So my opition is that upper layer wouldn't issue more I/O logically.
> > If it worked, it's not what we expect but side-effect.
> >
> > That's why I'd like to know what's your thought for increasing IOPS.
> > Please, could you say your thought why IOPS increased, not a result
> > on low level driver?
> It is because readahead can works asynchronously in background.
> Suppose that you read a large file by 128k partially and contiguously
> like "dd bs=128k". Two IOs can be issued per 128k reading,
> First IO is for intended pages, second IO is for readahead.
> If first IO hit in cache thank to previous readahead, no wait for IO 
> completion
> is needed, because intended page is up-to-date already.
> But, current squashfs waits for second IO's completion unnecessarily.
> That is one of reason that we should move page's up-to-date
> to the asynchronous area like my patch.

I understand it but your patch doesn't make it.

> 
> > Anyway, in my opinion, we should take care of MM layer's readahead for
> > enhance sequential I/O. For it, we should use buffer pages passed by MM
> > instead of freeing them and allocating new pages in squashfs.
> > IMHO, it would be better to implement squashfs_readpages but my insight
> > is very weak so I guess Phillip will give more good idea/insight about
> > the issue.
> That's a good point. Also, I think my patch is another way which can be 
> implemented
> without significant impact on current implementation and I wait for Phillip's 
> comment.
> 
> Thanks
> Chanho
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/14] mm, hugetlb: retry if failed to allocate and there is concurrent user

[Joonsoo Kim]

On Fri, Dec 20, 2013 at 10:48:17PM -0800, Davidlohr Bueso wrote:
> On Fri, 2013-12-20 at 14:01 +, Mel Gorman wrote:
> > On Thu, Dec 19, 2013 at 05:02:02PM -0800, Andrew Morton wrote:
> > > On Wed, 18 Dec 2013 15:53:59 +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.
> > > 
> > > So the whole point of the patch is to improve performance, but the
> > > changelog doesn't include any performance measurements!
> > > 
> > 
> > I don't really deal with hugetlbfs any more and I have not examined this
> > series but I remember why I never really cared about this mutex. It wrecks
> > fault scalability but AFAIK fault scalability almost never mattered for
> > workloads using hugetlbfs.  The most common user of hugetlbfs by far is
> > sysv shared memory. The memory is faulted early in the lifetime of the
> > workload and after that it does not matter. At worst, it hurts application
> > startup time but that is still poor motivation for putting a lot of work
> > into removing the mutex.
> 
> Yep, important hugepage workloads initially pound heavily on this lock,
> then it naturally decreases.
> 
> > Microbenchmarks will be able to trigger problems in this area but it'd
> > be important to check if any workload that matters is actually hitting
> > that problem.
> 
> I was thinking of writing one to actually get some numbers for this
> patchset -- I don't know of any benchmark that might stress this lock. 
> 
> However I first measured the amount of cycles it costs to start an
> Oracle DB and things went south with these changes. A simple 'startup
> immediate' calls hugetlb_fault() ~5000 times. For a vanilla kernel, this
> costs ~7.5 billion cycles and with this patchset it goes up to ~27.1
> billion. While there is naturally a fair amount of variation, these
> changes do seem to do more harm than good, at least in real world
> scenarios.

Hello,

I think that number of cycles is not proper to measure this patchset,
because cycles would be wasted by fault handling failure. Instead, it
targeted improved elapsed time. Could you tell me how long it
takes to fault all of it's hugepages?

Anyway, this order of magnitude still seems a problem. :/

I guess that cycles are wasted by zeroing hugepage in fault-path like as
Andrew pointed out.

I will send another patches to fix this problem.

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 03/14] mm, hugetlb: protect region tracking via newly introduced resv_map lock

[Joonsoo Kim]

On Sun, Dec 22, 2013 at 12:58:19AM +1100, David Gibson wrote:
> On Wed, Dec 18, 2013 at 03:53:49PM +0900, Joonsoo Kim wrote:
> > There is a race condition if we map a same file on different processes.
> > Region tracking is protected by mmap_sem and hugetlb_instantiation_mutex.
> > When we do mmap, we don't grab a hugetlb_instantiation_mutex, but,
> > grab a mmap_sem. This doesn't prevent other process to modify region
> > structure, so it can be modified by two processes concurrently.
> > 
> > To solve this, I introduce a lock to resv_map and make region manipulation
> > function grab a lock before they do actual work. This makes region
> > tracking safe.
> 
> It's not clear to me if you're saying there is a list corruption race
> bug in the existing code, or only that there will be if the
> instantiation mutex goes away.

Hello,

The race exists in current code.
Currently, region tracking is protected by either down_write(&mm->mmap_sem) or
down_read(&mm->mmap_sem) + instantiation mutex. But if we map this hugetlbfs
file to two different processes, holding a mmap_sem doesn't have any impact on
the other process and concurrent access to data structure is possible.

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 v6 2/2] PCI: Try best to allocate pref mmio 64bit above 4g

[Yinghai Lu]

On Sun, Dec 22, 2013 at 4:00 PM, Bjorn Helgaas  wrote:
> On Thu, Dec 19, 2013 at 1:44 PM, Yinghai Lu  wrote:
>
> Let me see if I can figure out what you're trying to do here.  Please
> correct me if I'm wrong:
>
>> When one of children resources does not support MEM_64, MEM_64 for
>> bridge get reset, so pull down whole pref resource on the bridge under 4G.
>
> When we allocate space for a bridge's prefetchable window, we
> currently look at the devices behind the bridge and put the window
> below 4GB if any of those children has a 32-bit prefetchable BAR.
>
> This maximizes the use of prefetch, at the cost of using more 32-bit
> address space.

yes. and we have problem when we have 8 sockets or 32 sockets system,
will have limit 32bit space.
but we have enough above 4G 64bit mmio for prefetchable.

>
>> If the bridge support pref mem 64, will only allocate that with pref mem64 to
>> children that support it.
>> For children resources if they only support pref mem 32, will allocate them
>> from non pref mem instead.
>
> You are changing this so that we will always try to put a bridge's
> 64-bit prefetchable window above 4GB, regardless of what devices are
> behind the bridge.  If a device behind the bridge has a 32-bit
> prefetchable BAR, we will place that BAR in the bridge's 32-bit
> non-prefetchable window.

Yes. so we can keep IORESOURCE_MEM64 in the flags for PREF.

>
> This minimizes the use of the 32-bit address space, at the cost of not
> being able to use prefetch as much.
>
>> If the bridge only support 32bit pref mmio, will still have all children pref
>> mmio under that.
>
> Obviously, if a bridge has a prefetchable window that's only 32 bits,
> 64-bit prefetchable BARs behind the bridge will have to be in that
> 32-bit prefetchable window or the 32-bit non-prefetchable window.  And
> if the bridge has no prefetchable window at all, every memory BAR
> behind the bridge will have to be in the 32-bit non-prefetchable
> window.

Yes.

>
> I'll look at the actual patch later; I just want to make sure I
> understand your intent first.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [f2fs-dev] [PATCH 1/3] f2fs: check filename length in recover_dentry

[Jaegeuk Kim]

2013-12-21 (토), 18:01 +0800, Chao Yu:
> In current flow, we will get Null return value of f2fs_find_entry in
> recover_dentry when name.len is bigger than F2FS_NAME_LEN, and then we
> still add this inode into its dir entry.
> To avoid this situation, we must check filename length before we use it.
> 
> Another point is that we could remove the code of checking filename length
> In f2fs_find_entry, because f2fs_lookup will be called previously to ensure of
> validity of filename length.
> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/dir.c  |3 ---
>  fs/f2fs/recovery.c |5 +
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> index 0cc26ba..3f3b661 100644
> --- a/fs/f2fs/dir.c
> +++ b/fs/f2fs/dir.c
> @@ -190,9 +190,6 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode *dir,
>   unsigned int max_depth;
>   unsigned int level;
>  
> - if (unlikely(namelen > F2FS_NAME_LEN))
> - return NULL;
> -
>   if (npages == 0)
>   return NULL;
>  
> diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> index a3f4542..fdd175b 100644
> --- a/fs/f2fs/recovery.c
> +++ b/fs/f2fs/recovery.c
> @@ -62,6 +62,11 @@ static int recover_dentry(struct page *ipage, struct inode 
> *inode)
>  
>   name.len = le32_to_cpu(raw_inode->i_namelen);
>   name.name = raw_inode->i_name;
> +
> + if (unlikely(name.len > F2FS_NAME_LEN)) {
> + err = -ENAMETOOLONG;
> + goto out;
> + }

Have you seen this before?
This is a trivial bug case, so, if you have got this bug, we should fix
the bug first instead of adding any workaround patch.
Let's add WARN_ON() at least.
Thanks,

>  retry:
>   de = f2fs_find_entry(dir, &name, &page);
>   if (de && inode->i_ino == le32_to_cpu(de->ino))

-- 
Jaegeuk Kim
Samsung

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

Re: linux-next: build failure after merge of the mmc tree

[Stephen Rothwell]

On Tue, 17 Dec 2013 13:28:38 +1100 Stephen Rothwell  
wrote:
>
> Hi Chris,
> 
> ping?

ping again - I am still getting this error.

> On Fri, 13 Dec 2013 12:57:16 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the mmc tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > ERROR (phandle_references): Reference to non-existent node or label 
> > "pinctrl_usdhc4_1"
> > 
> > ERROR: Input tree has errors, aborting (use -f to force output)
> > make[2]: *** [arch/arm/boot/dts/imx6dl-sabresd.dtb] Error 2
> > ERROR (phandle_references): Reference to non-existent node or label 
> > "pinctrl_usdhc4_1"
> > 
> > ERROR: Input tree has errors, aborting (use -f to force output)
> > make[2]: *** [arch/arm/boot/dts/imx6q-sabresd.dtb] Error 2
> > 
> > Caused by commit fc4fafac9656 ("ARM: dts: sabresd: add usdhc4 support").
> > 
> > I have used the mmc tree from next-20131212 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpWRHriW47xj.pgp
Description: PGP signature

Re: [PATCH] i2c: fix a potential kmemleak of adapter device

[Gu Zheng]

Hi Wolfram,
On 12/21/2013 01:31 AM, Wolfram Sang wrote:

> On Wed, Dec 18, 2013 at 09:18:08AM +0800, Gu Zheng wrote:
>> When running with the latest kernel, we get the following kmemleak message:
>> unreferenced object 0x8800c2a36100 (size 256):
>>   comm "modprobe", pid 629, jiffies 4294676002 (age 1531.115s)
>>   hex dump (first 32 bytes):
>> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .N..
>> ff ff ff ff ff ff ff ff 78 21 85 82 ff ff ff ff  x!..
>>   backtrace:
>> [] kmemleak_alloc+0x73/0x98
>> [] slab_post_alloc_hook+0x28/0x2a
>> [] __kmalloc+0x12c/0x158
>> [] kzalloc.constprop.6+0xe/0x10
>> [] device_private_init+0x18/0x66
>> [] dev_set_drvdata+0x1e/0x34
>> [] i801_probe+0x5d/0x447 [i2c_i801]
>> [] local_pci_probe+0x41/0x84
>> [] pci_device_probe+0xdf/0x10c
>> [] driver_probe_device+0x12f/0x2ee
>> [] __driver_attach+0x5f/0x83
>> [] bus_for_each_dev+0x64/0x90
>> [] driver_attach+0x1e/0x20
>> [] bus_add_driver+0xf2/0x1f0
>> [] driver_register+0x8c/0xc3
>> [] __pci_register_driver+0x62/0x67
>> According to the backtrace, it seems that we do not release the
>> device_private field of adapter device in the fail path of i801_probe
>> or the flow of i2c_del_adapter, so add the cleanup step to fix it.
>>
>> Signed-off-by: Gu Zheng 
> 
> ? Why should we free something we don't have allocated? The fix must be
> somewhere else probably...

We do allocate the device_private in device_private_init() when calling
dev_set_drvdata() to set adapter data in probe flow, and the calltrace
also shows this. Am I missing something?

Regards,
Gu
 

> 
>> ---
>>  drivers/i2c/busses/i2c-i801.c |1 +
>>  drivers/i2c/i2c-core.c|1 +
>>  2 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
>> index 737e298..4bd4fba 100644
>> --- a/drivers/i2c/busses/i2c-i801.c
>> +++ b/drivers/i2c/busses/i2c-i801.c
>> @@ -1246,6 +1246,7 @@ exit_free_irq:
>>  exit_release:
>>  pci_release_region(dev, SMBBAR);
>>  exit:
>> +kfree(priv->adapter.dev.p);
>>  kfree(priv);
>>  return err;
>>  }
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> index d74c0b3..a7bab9a 100644
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>> @@ -1491,6 +1491,7 @@ void i2c_del_adapter(struct i2c_adapter *adap)
>>  idr_remove(&i2c_adapter_idr, adap->nr);
>>  mutex_unlock(&core_lock);
>>  
>> +kfree(adap->dev.p);
>>  /* Clear the device structure in case this adapter is ever going to be
>> added again */
>>  memset(&adap->dev, 0, sizeof(adap->dev));
>> -- 
>> 1.7.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 1/1] MTD: UBI: try to avoid program data to NOR flash after erasure interrupted

[qiwang]

Hi Artem:
Sorry to interrupt your busy life. 
As you said in previous mail, I send my patch separately without quoting this 
e-mail. And I have send to you, but I never get  your reply. I am very confuse, 
no sure if is there anything wrong at the patch I send to you.
Can you help explain to me?
Thanks

-Original Message-
From: Artem Bityutskiy [mailto:dedeki...@gmail.com] 
Sent: Friday, November 01, 2013 4:58 PM
To: Qi Wang 王起 (qiwang)
Cc: linux-...@lists.infradead.org; Adrian Hunter; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] MTD: UBI: try to avoid program data to NOR flash after 
erasure interrupted

Hi,

could you please re-send your patch separately, without quoting any
parts of this conversation, so that I could use 'git am'.

Your patch also contains trailing white-spaces, please, get rid of them
in the next submission.

Also, could you please clearly state whether you have tested this patch
on a real NOR flash or not. If yes, then could you share the chip
vendor/type information?

On Thu, 2013-10-31 at 04:07 +, Qi Wang 王起 (qiwang) wrote:

> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -499,59 +499,44 @@ static int nor_erase_prepare(struct ubi_device *ubi, 
> int pnum)
>   size_t written;
>   loff_t addr;
>   uint32_t data = 0;
> - /*
> -  * Note, we cannot generally define VID header buffers on stack,
> -  * because of the way we deal with these buffers (see the header
> -  * comment in this file). But we know this is a NOR-specific piece of
> -  * code, so we can do this. But yes, this is error-prone and we should
> -  * (pre-)allocate VID header buffer instead.
> -  */

Please, do not remove this comment.

>   struct ubi_vid_hdr vid_hdr;
> + struct ubi_ec_hdr ec_hdr;

To make it obvious what the above big comment talks about, could you
please define 'struct ubi_ec_hdr ec_hdr' above that big comment.

Otherwise looks good to me, thank you!


> My Comments for above changing:
> 1. 
>   -   /*
>   -* Note, we cannot generally define VID header buffers on stack,
>   -* because of the way we deal with these buffers (see the header
>   -* comment in this file). But we know this is a NOR-specific 
> piece of
>   -* code, so we can do this. But yes, this is error-prone and we 
> should
>   -* (pre-)allocate VID header buffer instead.
>   -*/
>   I remove above comment, because I pre-allocate VID header and EC header 
> together. 
>   So I think no need to emphasize VID header buffers cannot be on stack.
>   (Maybe my understanding about this comment is error, if so, please 
> correct me)

The problem is that some functions in io.c can read or write _beyond_
sizeof(struct ubi_vid_hdr), but this is only relevant to NAND, not for
NOR, and the code you change is NOR-only. This is why that comment is
there, and I'd like to keep it.

> 2.
>   why use
>   "if (err != UBI_IO_BAD_HDR_EBADMSG && err != UBI_IO_BAD_HDR && err != 
> UBI_IO_FF)"
>   but not 
>   "if (!err)" 
>   to judge if need to program '0' to invalid this block.
> 
>   In case err == UBI_IO_FF_BITFLIPS, err == UBI_IO_BITFLIPS or unexpected 
> value return
>   from read function, I think UBI still need to invalid this block for 
> above mentioned 
>   condition. So I use
>   "if (err != UBI_IO_BAD_HDR_EBADMSG && err != UBI_IO_BAD_HDR && err != 
> UBI_IO_FF)"
>   to judge. 

In case of UBI_IO_FF (all FFs) UBI will erase the eraseblock before
using it anyway, so invalidation is not necessary.

Thanks!

-- 
Best Regards,
Artem Bityutskiy

[PATCH 1/1] MTD: UBI: avoid program operation on NOR flash after erasure interrupted

[qiwang]

Hi Artem:
As we talked in mail before, please check my patch as below:

From: Qi Wang 

nor_erase_prepare() will be called before erase a NOR flash, it will program '0'
into a block to mark this block. But program data into a erasure interrupted 
block
can cause program timtout(several minutes at most) error, could impact other 
operation on NOR flash. So UBIFS can read this block first to avoid unneeded 
program operation. 

This patch try to put read operation at head of write operation in 
nor_erase_prepare(), read out the data. 
If the data is already corrupt, then no need to program any data into this 
block, 
just go to erase this block.

Signed-off-by: Qi Wang 
---
diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index bf79def..0a6343d 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -499,6 +499,7 @@ static int nor_erase_prepare(struct ubi_device *ubi, int 
pnum)
size_t written;
loff_t addr;
uint32_t data = 0;
+   struct ubi_ec_hdr ec_hdr;
/*
 * Note, we cannot generally define VID header buffers on stack,
 * because of the way we deal with these buffers (see the header
@@ -509,49 +510,38 @@ static int nor_erase_prepare(struct ubi_device *ubi, int 
pnum)
struct ubi_vid_hdr vid_hdr;
 
/*
+* If VID or EC is valid, need to corrupt it before erase operation.  
 * It is important to first invalidate the EC header, and then the VID
 * header. Otherwise a power cut may lead to valid EC header and
 * invalid VID header, in which case UBI will treat this PEB as
 * corrupted and will try to preserve it, and print scary warnings.
 */
addr = (loff_t)pnum * ubi->peb_size;
-   err = mtd_write(ubi->mtd, addr, 4, &written, (void *)&data);
-   if (!err) {
-   addr += ubi->vid_hdr_aloffset;
-   err = mtd_write(ubi->mtd, addr, 4, &written, (void *)&data);
-   if (!err)
-   return 0;
+   err = ubi_io_read_ec_hdr(ubi, pnum, &ec_hdr, 0);
+   if (err != UBI_IO_BAD_HDR_EBADMSG && err != UBI_IO_BAD_HDR &&
+   err != UBI_IO_FF){
+   err1 = mtd_write(ubi->mtd, addr, 4, &written, (void *)&data);
+   if(err1)
+   goto error;
}
 
-   /*
-* We failed to write to the media. This was observed with Spansion
-* S29GL512N NOR flash. Most probably the previously eraseblock erasure
-* was interrupted at a very inappropriate moment, so it became
-* unwritable. In this case we probably anyway have garbage in this
-* PEB.
-*/
-   err1 = ubi_io_read_vid_hdr(ubi, pnum, &vid_hdr, 0);
-   if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR ||
-   err1 == UBI_IO_FF) {
-   struct ubi_ec_hdr ec_hdr;
-
-   err1 = ubi_io_read_ec_hdr(ubi, pnum, &ec_hdr, 0);
-   if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR ||
-   err1 == UBI_IO_FF)
-   /*
-* Both VID and EC headers are corrupted, so we can
-* safely erase this PEB and not afraid that it will be
-* treated as a valid PEB in case of an unclean reboot.
-*/
-   return 0;
+   err = ubi_io_read_vid_hdr(ubi, pnum, &vid_hdr, 0);
+   if (err != UBI_IO_BAD_HDR_EBADMSG && err != UBI_IO_BAD_HDR &&
+   err != UBI_IO_FF){
+   addr += ubi->vid_hdr_aloffset;
+   err1 = mtd_write(ubi->mtd, addr, 4, &written, (void *)&data);
+   if (err1)
+   goto error; 
}
+   return 0;
 
+error:
/*
-* The PEB contains a valid VID header, but we cannot invalidate it.
+* The PEB contains a valid VID or EC header, but we cannot invalidate 
it.
 * Supposedly the flash media or the driver is screwed up, so return an
 * error.
 */
-   ubi_err("cannot invalidate PEB %d, write returned %d read returned %d",
+   ubi_err("cannot invalidate PEB %d, read returned %d write returned %d",
pnum, err, err1);
ubi_dump_flash(ubi, pnum, 0, ubi->peb_size);
return -EIO;
---

I have tested this patch on Micron NOR flash, part number is：JS28F512M29EWHA.
If have any questions, please let me know. 
Thank you

Best Regards, 
Qi Wang 王起
ESG APAC AE 
Tel: 86-021-38997158
Mobile: 86-15201958202
Email: qiw...@micron.com
Address: No 601 Fasai Rd, Pudong, Shanghai, China, 200131

Re: [PATCH v7 09/12] efi: passing kexec necessary efi data via setup_data

[Dave Young]

> > +   if (data)
> > +   early_memunmap(data, sizeof(*data));
> >  #ifdef CONFIG_X86_32
> > if (tmp >> 32) {
> > pr_err("EFI data located above 4GB, disabling EFI.\n");
> 
> This isn't correct, and means we now won't trigger this pr_err() if
> booting a CONFIG_X86_32 kernel with EFI_64BIT and where the ->fw_vendor,
> ->runtime or ->tables pointer is above 4GB - you've mixed up systab and
> systab64. I've fixed this up like so when applying this patch,

You are right, I missed this 32bit tmp value, thanks for taking care of this.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 09/12] efi: passing kexec necessary efi data via setup_data

[Dave Young]

On 12/21/13 at 04:06pm, Matt Fleming wrote:
> On Fri, 20 Dec, at 06:02:19PM, Dave Young wrote:
> > @@ -133,6 +133,19 @@ extern void efi_sync_low_kernel_mappings(void);
> >  extern void efi_setup_page_tables(void);
> >  extern void __init old_map_region(efi_memory_desc_t *md);
> >  
> > +struct efi_setup_data {
> > +   u64 fw_vendor;
> > +   u64 runtime;
> > +   u64 tables;
> > +   u64 smbios;
> > +   u64 reserved[8];
> > +   efi_memory_desc_t map[0];
> > +};
> 
> [...]
> 
> > +static void get_nr_runtime_map(void)
> > +{
> > +   if (!efi_setup)
> > +   return;
> > +
> > +   nr_efi_runtime_map = (efi_data_len - sizeof(struct efi_setup_data)) /
> > +sizeof(efi_memory_desc_t);
> > +}
> 
> Do we actually need the 'map' entry in efi_setup_data now that you're
> passing it via efi_info (which is much better approach!)? Also, we don't
> need the global nr_efi_runtime_map or efi_runtime_map variables now,
> right?

The map is still necessary because we need store the map somewhere and pass
the physicall address to kexec kernel. Passing them in setup_data is the
only better way currently...

In efi_info there's only an entry for the map physical address, the original
map area is not valid any more.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/14] mm, hugetlb: retry if failed to allocate and there is concurrent user

[Joonsoo Kim]

On Mon, Dec 23, 2013 at 09:44:38AM +0900, Joonsoo Kim wrote:
> On Fri, Dec 20, 2013 at 10:48:17PM -0800, Davidlohr Bueso wrote:
> > On Fri, 2013-12-20 at 14:01 +, Mel Gorman wrote:
> > > On Thu, Dec 19, 2013 at 05:02:02PM -0800, Andrew Morton wrote:
> > > > On Wed, 18 Dec 2013 15:53:59 +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.
> > > > 
> > > > So the whole point of the patch is to improve performance, but the
> > > > changelog doesn't include any performance measurements!
> > > > 
> > > 
> > > I don't really deal with hugetlbfs any more and I have not examined this
> > > series but I remember why I never really cared about this mutex. It wrecks
> > > fault scalability but AFAIK fault scalability almost never mattered for
> > > workloads using hugetlbfs.  The most common user of hugetlbfs by far is
> > > sysv shared memory. The memory is faulted early in the lifetime of the
> > > workload and after that it does not matter. At worst, it hurts application
> > > startup time but that is still poor motivation for putting a lot of work
> > > into removing the mutex.
> > 
> > Yep, important hugepage workloads initially pound heavily on this lock,
> > then it naturally decreases.
> > 
> > > Microbenchmarks will be able to trigger problems in this area but it'd
> > > be important to check if any workload that matters is actually hitting
> > > that problem.
> > 
> > I was thinking of writing one to actually get some numbers for this
> > patchset -- I don't know of any benchmark that might stress this lock. 
> > 
> > However I first measured the amount of cycles it costs to start an
> > Oracle DB and things went south with these changes. A simple 'startup
> > immediate' calls hugetlb_fault() ~5000 times. For a vanilla kernel, this
> > costs ~7.5 billion cycles and with this patchset it goes up to ~27.1
> > billion. While there is naturally a fair amount of variation, these
> > changes do seem to do more harm than good, at least in real world
> > scenarios.
> 
> Hello,
> 
> I think that number of cycles is not proper to measure this patchset,
> because cycles would be wasted by fault handling failure. Instead, it
> targeted improved elapsed time. Could you tell me how long it
> takes to fault all of it's hugepages?
> 
> Anyway, this order of magnitude still seems a problem. :/
> 
> I guess that cycles are wasted by zeroing hugepage in fault-path like as
> Andrew pointed out.
> 
> I will send another patches to fix this problem.

Hello, Davidlohr.

Here goes the fix on top of this series.
Thanks.

-->8---
>From 5f20459d90dfa2f7cd28d62194ce22bd9a0df0f5 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim 
Date: Mon, 23 Dec 2013 10:32:04 +0900
Subject: [PATCH] mm, hugetlb: optimize zeroing hugepage

When parallel faults occur, someone would be failed. In this case,
cpu cycles for zeroing failed hugepage is wasted. To reduce this overhead,
mark the hugepage as zeroed hugepage after zeroing hugepage and unmark
it as non-zeroed hugepage after it is really used. If it isn't used with
any reason, it returns back to the hugepage pool and it will be used
sometime ago. At this time, we would see zeroed page marker and skip to
do zeroing.

Signed-off-by: Joonsoo Kim 

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6edf423..b90b792 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -582,6 +582,7 @@ static void update_and_free_page(struct hstate *h, struct 
page *page)
1 << PG_private | 1 << PG_writeback);
}
VM_BUG_ON(hugetlb_cgroup_from_page(page));
+   ClearPageActive(page);
set_compound_page_dtor(page, NULL);
set_page_refcounted(page);
arch_release_hugepage(page);
@@ -2715,6 +2716,7 @@ retry_avoidcopy:
spin_lock(ptl);
ptep = huge_pte_offset(mm, address & huge_page_mask(h));
if (likely(pte_same(huge_ptep_get(ptep), pte))) {
+   ClearPageActive(new_page);
ClearPagePrivate(new_page);
 
/* Break COW */
@@ -2834,7 +2836,10 @@ retry:
}
goto out;
}
-   clear_huge_page(page, address, pages_per_huge_page(h));
+   if (!PageAc

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

Xmas fixes pull, all small nothing major, intel, radeon, one ttm 
regression, and one build fix.

Dave.

The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c:

  Linux 3.13-rc5 (2013-12-22 13:08:32 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 418cb50bd6f977249b38f359e0adca6fc8ea:

  Merge tag 'drm-intel-fixes-2013-12-18' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-12-23 
10:35:57 +1000)



Alex Deucher (4):
  drm/radeon/dce6: set correct number of audio pins
  drm/radeon/dpm: disable ss on Cayman
  drm/radeon: check for 0 count in speaker allocation and SAD code
  drm/radeon: fix asic gfx values for scrapper asics

Chris Wilson (3):
  drm/i915: Prevent double unref following alloc failure during execbuffer
  drm/i915: Fix erroneous dereference of batch_obj inside reset_status
  drm/i915: Use the correct GMCH_CTRL register for Sandybridge+

Dave Airlie (2):
  Merge branch 'drm-fixes-3.13' of 
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2013-12-18' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Paulo Zanoni (2):
  drm/i915: change CRTC assertion on LCPLL disable
  drm/i915: get a PC8 reference when enabling the power well

Randy Dunlap (1):
  gpu: fix qxl missing crc32_le

Thomas Hellstrom (1):
  drm/ttm: Fix swapin regression

 drivers/gpu/drm/i915/i915_gem.c| 34 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 28 +---
 drivers/gpu/drm/i915/intel_display.c   |  7 +++---
 drivers/gpu/drm/i915/intel_pm.c| 14 ++--
 drivers/gpu/drm/qxl/Kconfig|  1 +
 drivers/gpu/drm/qxl/qxl_display.c  |  2 +-
 drivers/gpu/drm/radeon/dce6_afmt.c |  8 ---
 drivers/gpu/drm/radeon/evergreen_hdmi.c|  4 ++--
 drivers/gpu/drm/radeon/ni.c| 20 ++
 drivers/gpu/drm/radeon/rv770_dpm.c |  6 ++
 drivers/gpu/drm/ttm/ttm_bo_util.c  |  3 ++-
 11 files changed, 93 insertions(+), 34 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH net v5 0/4] r8152 bug fixes

[hayeswang]

Any response? 

> -Original Message-
> From: Hayeswang [mailto:hayesw...@realtek.com] 
> Sent: Wednesday, November 20, 2013 5:31 PM
> To: net...@vger.kernel.org
> Cc: nic_swsd; linux-kernel@vger.kernel.org; 
> linux-...@vger.kernel.org; Hayeswang
> Subject: [PATCH net v5 0/4] r8152 bug fixes
> 
> For the patch #3, I add netif_tx_lock() before checking the
> netif_queue_stopped(). Besides, I add checking the skb queue
> length before waking the tx queue.
> 
> Hayes Wang (4):
>   r8152: fix tx/rx memory overflow
>   r8152: modify the tx flow
>   r8152: support stopping/waking tx queue
>   r8152: fix incorrect type in assignment
> 
>  drivers/net/usb/r8152.c | 114 
> +---
>  1 file changed, 50 insertions(+), 64 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/

RE: [f2fs-dev] [PATCH 1/3] f2fs: check filename length in recover_dentry

[Chao Yu]

Hi Kim,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Monday, December 23, 2013 9:26 AM
> To: Chao Yu
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 1/3] f2fs: check filename length in 
> recover_dentry
> 
> 2013-12-21 (토), 18:01 +0800, Chao Yu:
> > In current flow, we will get Null return value of f2fs_find_entry in
> > recover_dentry when name.len is bigger than F2FS_NAME_LEN, and then we
> > still add this inode into its dir entry.
> > To avoid this situation, we must check filename length before we use it.
> >
> > Another point is that we could remove the code of checking filename length
> > In f2fs_find_entry, because f2fs_lookup will be called previously to ensure 
> > of
> > validity of filename length.
> >
> > Signed-off-by: Chao Yu 
> > ---
> >  fs/f2fs/dir.c  |3 ---
> >  fs/f2fs/recovery.c |5 +
> >  2 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > index 0cc26ba..3f3b661 100644
> > --- a/fs/f2fs/dir.c
> > +++ b/fs/f2fs/dir.c
> > @@ -190,9 +190,6 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode 
> > *dir,
> > unsigned int max_depth;
> > unsigned int level;
> >
> > -   if (unlikely(namelen > F2FS_NAME_LEN))
> > -   return NULL;
> > -
> > if (npages == 0)
> > return NULL;
> >
> > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> > index a3f4542..fdd175b 100644
> > --- a/fs/f2fs/recovery.c
> > +++ b/fs/f2fs/recovery.c
> > @@ -62,6 +62,11 @@ static int recover_dentry(struct page *ipage, struct 
> > inode *inode)
> >
> > name.len = le32_to_cpu(raw_inode->i_namelen);
> > name.name = raw_inode->i_name;
> > +
> > +   if (unlikely(name.len > F2FS_NAME_LEN)) {
> > +   err = -ENAMETOOLONG;
> > +   goto out;
> > +   }
> 
> Have you seen this before?

Not yet.

> This is a trivial bug case, so, if you have got this bug, we should fix
> the bug first instead of adding any workaround patch.

What I worry about is that not only f2fs bug lead to this trivial problem,
but also other program with operation in raw disk could do this.

> Let's add WARN_ON() at least.

Alright.
Thanks.

> Thanks,
> 
> >  retry:
> > de = f2fs_find_entry(dir, &name, &page);
> > if (de && inode->i_ino == le32_to_cpu(de->ino))
> 
> --
> Jaegeuk Kim
> Samsung

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 00/12] kexec kernel efi runtime support

[Dave Young]

On 12/21/13 at 05:35pm, Matt Fleming wrote:
> On Fri, 20 Dec, at 06:02:10PM, Dave Young wrote:
> > Here is the V7 patchset for supporting kexec kernel efi runtime.
> > Per pervious discussion I pass the 1st kernel efi runtime mapping
> > via setup_data to 2nd kernel. Besides of the runtime mapping
> > info I also pass the fw_vendor, runtime, config table, smbios
> > physical address in setup_data. EFI spec mentioned fw_vendor,
> > runtime, config table addresses will be converted to virt address
> > after entering virtual mode, but we will use it as physical address
> > in efi_init. For smbios EFI spec did not mention about the address
> > updating, but during my test on a HP workstation, the bios will
> > convert it to Virt addr, thus pass it in setup_data as well.
> 
> OK Dave, I've pulled patches 3-12 into the 'kexec' branch at,
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
> 
> I plan on sending this branch to the tip folks this week for further
> testing.
> 
> Please have a look and make sure I haven't messed anything up when
> dropping the first two patches (though they were very small and trival).

Matt, I have reviewed them, it looks good to me.
Thanks for removing the global variable in your last one.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mei_me: Ratelimit several error messages

[Ian Munsie]

I'm unsure of the cause, but I found irq/40-mei_me consuming 100% CPU
and my disk full due to kern.log, syslog and messages rapidly growing in
size filled with these messages:

Dec 23 12:29:57 dukhat kernel: [336224.363138] mei_me :00:16.0: reset: 
wrong host start response
Dec 23 12:29:57 dukhat kernel: [336224.363140] mei_me :00:16.0: unexpected 
reset: dev_state = RESETTING
Dec 23 12:29:57 dukhat kernel: [336224.363152] mei_me :00:16.0: reset: 
unexpected enumeration response hbm.
Dec 23 12:29:57 dukhat kernel: [336224.363155] mei_me :00:16.0: unexpected 
reset: dev_state = RESETTING
Dec 23 12:29:57 dukhat kernel: [336224.363185] mei_me :00:16.0: reset: 
wrong host start response
Dec 23 12:29:57 dukhat kernel: [336224.363187] mei_me :00:16.0: unexpected 
reset: dev_state = RESETTING
Dec 23 12:29:57 dukhat kernel: [336224.363199] mei_me :00:16.0: reset: 
unexpected enumeration response hbm.
Dec 23 12:29:57 dukhat kernel: [336224.363201] mei_me :00:16.0: unexpected 
reset: dev_state = RESETTING

This patch rate-limits those specific messages to reduce the impact if
this problem ever recurs.

Signed-off-by: Ian Munsie 
---
 drivers/misc/mei/hbm.c  | 4 ++--
 drivers/misc/mei/init.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 9b3a0fb..2ab8b1d 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -613,7 +613,7 @@ void mei_hbm_dispatch(struct mei_device *dev, struct 
mei_msg_hdr *hdr)
dev->init_clients_timer = 0;
mei_hbm_enum_clients_req(dev);
} else {
-   dev_err(&dev->pdev->dev, "reset: wrong host start 
response\n");
+   dev_err_ratelimited(&dev->pdev->dev, "reset: wrong host 
start response\n");
mei_reset(dev, 1);
return;
}
@@ -690,7 +690,7 @@ void mei_hbm_dispatch(struct mei_device *dev, struct 
mei_msg_hdr *hdr)
/* first property reqeust */
mei_hbm_prop_req(dev);
} else {
-   dev_err(&dev->pdev->dev, "reset: unexpected enumeration 
response hbm.\n");
+   dev_err_ratelimited(&dev->pdev->dev, "reset: unexpected 
enumeration response hbm.\n");
mei_reset(dev, 1);
return;
}
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index f7f3abb..edd3bb6 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -148,7 +148,7 @@ void mei_reset(struct mei_device *dev, int 
interrupts_enabled)
dev->dev_state != MEI_DEV_POWER_UP);
 
if (unexpected)
-   dev_warn(&dev->pdev->dev, "unexpected reset: dev_state = %s\n",
+   dev_warn_ratelimited(&dev->pdev->dev, "unexpected reset: 
dev_state = %s\n",
 mei_dev_state_str(dev->dev_state));
 
ret = mei_hw_reset(dev, interrupts_enabled);
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: Re : Re: [PATCH] Squashfs: add asynchronous read support

[Chanho Min]

> read_pages
>   for(page_idx ...) {
> if (!add_to_page_cache_lru)) { <-- 1)
>   mapping->a_ops->readpage(filp, page)
> squashfs_readpage
>   for (i ...) {   2)  Here, 31 pages are inserted into page cache
> grab_cahe_page_nowait <--/
>   add_to_page_cache_lru
>   }
> }
> /*
>  * 1) will be failed with EEXIST by 2) so every pages other than first 
> page
>  * in list would be freed
>  */
> page_cache_release(page)
>   }
>
> If you see ReadAhead works, it is just by luck as I told you.
> Please simulate it with 64K dd.
You right, This luck happened frequently with 128k dd or my test.

> I understand it but your patch doesn't make it.
>
I think my patch can make it if readahead works normally or luckily.

Thanks a lot!
Chanho,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] tracing: Fixes to event_triggers patches found by Fengguang's test bot

[Tom Zanussi]

Hi Steve,

On Sat, 2013-12-21 at 22:07 -0500, Steven Rostedt wrote:
> Tom,
> 
> This is the changes I made to fix the reports that Fengguang's kbuild test bot
> found. I folded in your change that fixes the bug with -ENODEV used in 
> kernel.h.
> 

These look fine to me, and I didn't see any problems after running
through my normal event trigger testing with them applied.

So you can add my Acked-by and/or Tested-by..

Thanks for writing these improved versions!

Tom

> Paul,
> 
> I've Cc'd you because the second patch is fixing up RCU notation. The filter
> is protect by rcu_sched, and the first hunk of the patch is performed
> within a rcu_read_lock_sched(), and the second hunk is done on the write
> side. The tmp variable holds the old value, the value is updated, and
> then the new value gets updated. I emailed you so that you can verify
> that this all works.
> 
> Thanks!
> 
> -- Steve
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> ftrace/core
> 
> Head SHA1: 05741e383228a79eeec83644181255d2171f9f7c
> 
> 
> Steven Rostedt (Red Hat) (2):
>   tracing: Add generic tracing_lseek() function
>   tracing: Fix rcu handling of event_trigger_data filter field
> 
> 
>  include/linux/ftrace.h  |  2 --
>  kernel/trace/ftrace.c   | 25 ++---
>  kernel/trace/trace.c| 14 +-
>  kernel/trace/trace.h|  4 +++-
>  kernel/trace/trace_events_trigger.c | 10 ++
>  kernel/trace/trace_stack.c  |  2 +-
>  6 files changed, 25 insertions(+), 32 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/

[f2fs-dev] [PATCH 1/3 V2] f2fs: check filename length in recover_dentry

[Chao Yu]

In current flow, we will get Null return value of f2fs_find_entry in
recover_dentry when name.len is bigger than F2FS_NAME_LEN, and then we
still add this inode into its dir entry.
To avoid this situation, we must check filename length before we use it.

Another point is that we could remove the code of checking filename length
In f2fs_find_entry, because f2fs_lookup will be called previously to ensure of
validity of filename length.

V2:
 o add WARN_ON() as Jaegeuk Kim suggested.

Signed-off-by: Chao Yu 
---
 fs/f2fs/dir.c  |3 ---
 fs/f2fs/recovery.c |6 ++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 07ad850..f0b4630 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -190,9 +190,6 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode *dir,
unsigned int max_depth;
unsigned int level;
 
-   if (unlikely(namelen > F2FS_NAME_LEN))
-   return NULL;
-
if (npages == 0)
return NULL;
 
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index a3f4542..4d411a2 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -62,6 +62,12 @@ static int recover_dentry(struct page *ipage, struct inode 
*inode)
 
name.len = le32_to_cpu(raw_inode->i_namelen);
name.name = raw_inode->i_name;
+
+   if (unlikely(name.len > F2FS_NAME_LEN)) {
+   WARN_ON(1);
+   err = -ENAMETOOLONG;
+   goto out;
+   }
 retry:
de = f2fs_find_entry(dir, &name, &page);
if (de && inode->i_ino == le32_to_cpu(de->ino))
-- 
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/

linux-next: manual merge of the target-updates tree with Linus' tree

[Stephen Rothwell]

Hi Nicholas,

Today's linux-next merge of the target-updates tree got a conflict in
drivers/target/target_core_tpg.c between commit de06875f0896 ("target:
Remove extra percpu_ref_init") from Linus' tree and commit d344f8a15637
("target: Rename core_tpg_{pre,post}_addlun for clarity") from the
target-updates tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/target/target_core_tpg.c
index 2a573de19a9f,d1df39a05d88..
--- a/drivers/target/target_core_tpg.c
+++ b/drivers/target/target_core_tpg.c
@@@ -656,9 -658,15 +656,9 @@@ static int core_tpg_setup_virtual_lun0(
spin_lock_init(&lun->lun_sep_lock);
init_completion(&lun->lun_ref_comp);
  
-   ret = core_tpg_post_addlun(se_tpg, lun, lun_access, dev);
 -  ret = percpu_ref_init(&lun->lun_ref, core_tpg_lun_ref_release);
 -  if (ret < 0)
 -  return ret;
 -
+   ret = core_tpg_add_lun(se_tpg, lun, lun_access, dev);
 -  if (ret < 0) {
 -  percpu_ref_cancel_init(&lun->lun_ref);
 +  if (ret < 0)
return ret;
 -  }
  
return 0;
  }


pgpYNbAT59FL0.pgp
Description: PGP signature

linux-next: manual merge of the akpm-current tree with the pci tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
scripts/checkpatch.pl between commit 92e112fdbb3c ("PCI/checkpatch:
Deprecate DEFINE_PCI_DEVICE_TABLE") from the pci tree and commit
369353832de3 ("checkpatch.pl: check for function declarations without
arguments") from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc scripts/checkpatch.pl
index 9fb30b15c9dc,8f3aecd3e27b..
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@@ -2634,13 -2630,19 +2630,22 @@@ sub process 
$herecurr);
 }
  
+ # check for function declarations without arguments like "int foo()"
+   if ($line =~ /(\b$Type\s+$Ident)\s*\(\s*\)/) {
+   if (ERROR("FUNCTION_WITHOUT_ARGS",
+ "Bad function definition - $1() should 
probably be $1(void)\n" . $herecurr) &&
+   $fix) {
+   $fixed[$linenr - 1] =~ 
s/(\b($Type)\s+($Ident))\s*\(\s*\)/$2 $3(void)/;
+   }
+   }
+ 
 -# check for declarations of struct pci_device_id
 -  if ($line =~ 
/\bstruct\s+pci_device_id\s+\w+\s*\[\s*\]\s*\=\s*\{/) {
 -  WARN("DEFINE_PCI_DEVICE_TABLE",
 -   "Use DEFINE_PCI_DEVICE_TABLE for struct 
pci_device_id\n" . $herecurr);
 +# check for uses of DEFINE_PCI_DEVICE_TABLE
 +  if ($line =~ /\bDEFINE_PCI_DEVICE_TABLE\s*\(\s*(\w+)\s*\)\s*=/) 
{
 +  if (WARN("DEFINE_PCI_DEVICE_TABLE",
 +   "Prefer struct pci_device_id over deprecated 
DEFINE_PCI_DEVICE_TABLE\n" . $herecurr) &&
 +  $fix) {
 +  $fixed[$linenr - 1] =~ 
s/\b(?:static\s+|)DEFINE_PCI_DEVICE_TABLE\s*\(\s*(\w+)\s*\)\s*=\s*/static const 
struct pci_device_id $1\[\] = /;
 +  }
}
  
  # check for new typedefs, only function parameters and sparse annotations


pgp3yOxMu463J.pgp
Description: PGP signature

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Dave Chinner]

On Sun, Dec 22, 2013 at 12:33:18AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > > I disagree - given the problem it is resolving leads to silent
> > > > > > filesystem corruption, this patch should be considered somewhat of a
> > > > > > priority to push...
> > > > > 
> > > > > Umm. Ok, I forgot what it does, really.
> > > > 
> > > > It ensures that the filesystem is in an quiescent state both in
> > > > memory and on disk, and it cannot be modified in memory or on disk
> > > > whilst the suspend image is being generated, or by log recovery
> > > > after a resume before the suspended image has been restored.
> > > 
> > > If someone attempts to run log recovery before resume, that's a bug
> > > and yes, it will corrupt filesystems. (Including ext3). Don't do that.
> > 
> > Freezing the filesystem prevents that accidental mount of the
> > filesystem from being an issue. It fixes a bug that:
> 
> Can you elaborate on that?
> 
> If you do read-write mount of that filesystem, surely filesystem
> metadata will differ from what the filesystem expects. You'll still
> get data corruption AFAICT.

Only if you modify stuff. That's not what we are protecting against,
it's avoiding the automatic journal replay that you can't avoid if
you accidentally mount the filesystem.

> Read-only mount... maybe that will get slightly better -- there'll be
> no journal to play back. But what happens to superblock information
> such as "last mount time"? Mount counts?

If metadata is being modified on a read only mount outside of
journal replay, then the filesystem needs fixing.

> 
> > > Documentation/power/swsusp.txt:
> > > 
> > >  * BIG FAT WARNING
> > >*
> > >  *
> > >  * If you touch anything on disk between suspend and resume...
> > >  *  ...kiss your data goodbye.
> > 
> > Makes this a whole lot less dangerous.
> 
> Do you claim that it is now safe to mount (rw) and access filesystem
> between suspend and resume?

No, I didn't claim that. "less dangerous" is still dangerous, just
less so than it was before.

Cheers,

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