Re: [RFC PATCH v1 02/31] ARC: irqflags
On Tuesday 13 November 2012 01:20 AM, Thomas Gleixner wrote:
> On Wed, 7 Nov 2012, Vineet Gupta wrote:
>> + **
>> + * Inline ASM macros to read/write AUX Regs
>> + * Essentially invocation of lr/sr insns from "C"
>> + */
>> +
>> +#if 1
>
> Leftover ???
Kind of - the gcc builtins sometimes tend to generate good code and sometimes
they don't. I wanted to retain the inline asm version for experimenting sake.
But
if it's too ugly, I can get rid of one of them.
>
>> +#define read_aux_reg(reg) __builtin_arc_lr(reg)
>> +
>> +/* gcc builtin sr needs reg param to be long immediate */
>> +#define write_aux_reg(reg_immed, val) \
>> +__builtin_arc_sr((unsigned int)val, reg_immed)
>> +
>> +#else
>> +/*
>> + * Conditionally Enable IRQs
>
> Unconditionally methinks
ofcourse - fixed !
> The following two functions are related to irq chips I guess. So why
> would you want them here ?
>
>> +static inline void arch_mask_irq(unsigned int irq)
>> +{
>> +unsigned int ienb;
>> +
>> +ienb = read_aux_reg(AUX_IENABLE);
>> +ienb &= ~(1 << irq);
>> +write_aux_reg(AUX_IENABLE, ienb);
>> +}
>> +
>> +static inline void arch_unmask_irq(unsigned int irq)
>> +{
>> +unsigned int ienb;
>> +
>> +ienb = read_aux_reg(AUX_IENABLE);
>> +ienb |= (1 << irq);
>> +write_aux_reg(AUX_IENABLE, ienb);
>> +}
>
> The only user is the interrupt controller code, right?
These are the platform agnostic routines which handle the in-core interrupt
controller, hence provided as helpers. The simpler plat-arcfpga (PATCH 12/31)
uses
them as it is while a bunch of other platforms (yet to be submitted) might
conditionally use depending upon whether a IRQ is cascaded or not.
>> diff --git a/arch/arc/kernel/irq.c b/arch/arc/kernel/irq.c
>> new file mode 100644
>> index 000..16fcbe8
>> --- /dev/null
>> +++ b/arch/arc/kernel/irq.c
>> @@ -0,0 +1,32 @@
>> +/*
>> + * Copyright (C) 2011-12 Synopsys, Inc. (www.synopsys.com)
>> + *
>> + * 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.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +void arch_local_irq_enable(void)
>> +{
>> +
>> +unsigned long flags;
>> +flags = arch_local_save_flags();
>> +flags |= (STATUS_E1_MASK | STATUS_E2_MASK);
>> +
>> +/*
>> + * If called from hard ISR (between irq_enter and irq_exit)
>> + * don't allow Level 1. In Soft ISR we allow further Level 1s
>> + */
>> +
>> +if (in_irq())
>> +flags &= ~(STATUS_E1_MASK | STATUS_E2_MASK);
>
> Hmm. This looks weird and the comment is not very helpful. So using my
> crystal ball you want to enforce, that nothing enables interrupts
> while a hard interrupt handler is running, right?
Correct. I'll fix the comment.
>
> Is there a chip limitation which you have to enforce here? If yes,
> then please explain it.
Yes and No. This is from our 2.6.26 days and AFAIKR, it was indeed ARC IDE
driver
enabling IRQ from within hard ISR context. The issue however became critical
when
I added support for the ARC700 in-core interrupt controller which provides 2
levels of interrupts per IRQ (kind of ARM FIQ): L2 (High priority) could
interrupt
L1 (low). The priority management (among other - don't allow L1 if L2 active) is
done with 2 pairs of bits in STATUS32 (CPU flags) register
* A1/A2 (Level-n active)
* E1/E2 (Level-n enabled)
However since the OS is allowed to write to E1/E2 bits, independent of A1/A2, it
is possible to re-enable interrupts even from hard-isr context. When IDE driver
re-enabled L1 interrupts in L2 ISR - we had the basic low level irq handling
messed by because of L1-L2-L1 scenarion
The patch which implements the 2 intc priorities support is separate. It
probably
fell of your radar since it was in mini-series #2 of v1 patchset @
https://lkml.org/lkml/2012/11/12/125). Once I respin v2 series for review, would
request you to please take a look at that one as well (currently has a bad hack
of
disabling task preemption in a corner case - which of all people, you, would
certainly loathe seeing)
> Btw, all hard interrupt handlers in Linux run with interrupts disabled and
> they are not supposed to reenable interrupts, which is true for almost
> all drivers except for a few archaic IDE drivers. In fact you might
> even WARN about it at least once, so the offending code gets fixed.
Sure - did that in next version.
> Also the code flow is backwards. What about:
>
> unsigned long flags;
>
> if (in_irq())
> return;
>
> flags =
>
>
>> +arch_local_irq_restore(flags);
>> +}
>
Indeed fixed in v2. Actually the prev version would *disable* the IRQs if
in_irq(), now we leave status quo and return - but given that we return - they
will not be e
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Fri, 2012-12-28 at 02:32 +0100, Petr Holasek wrote:
> Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_across_nodes
> which control merging pages across different numa nodes.
> When it is set to zero only pages from the same node are merged,
> otherwise pages from all nodes can be merged together (default behavior).
>
> Typical use-case could be a lot of KVM guests on NUMA machine
> and cpus from more distant nodes would have significant increase
> of access latency to the merged ksm page. Sysfs knob was choosen
> for higher variability when some users still prefers higher amount
> of saved physical memory regardless of access latency.
>
> Every numa node has its own stable & unstable trees because of faster
> searching and inserting. Changing of merge_across_nodes value is possible
> only when there are not any ksm shared pages in system.
>
> I've tested this patch on numa machines with 2, 4 and 8 nodes and
> measured speed of memory access inside of KVM guests with memory pinned
> to one of nodes with this benchmark:
>
> http://pholasek.fedorapeople.org/alloc_pg.c
>
> Population standard deviations of access times in percentage of average
> were following:
>
> merge_across_nodes=1
> 2 nodes 1.4%
> 4 nodes 1.6%
> 8 nodes 1.7%
>
> merge_across_nodes=0
> 2 nodes 1%
> 4 nodes 0.32%
> 8 nodes 0.018%
>
> RFC: https://lkml.org/lkml/2011/11/30/91
> v1: https://lkml.org/lkml/2012/1/23/46
> v2: https://lkml.org/lkml/2012/6/29/105
> v3: https://lkml.org/lkml/2012/9/14/550
> v4: https://lkml.org/lkml/2012/9/23/137
> v5: https://lkml.org/lkml/2012/12/10/540
> v6: https://lkml.org/lkml/2012/12/23/154
>
> Changelog:
>
> v2: Andrew's objections were reflected:
> - value of merge_nodes can't be changed while there are some ksm
> pages in system
> - merge_nodes sysfs entry appearance depends on CONFIG_NUMA
> - more verbose documentation
> - added some performance testing results
>
> v3: - more verbose documentation
> - fixed race in merge_nodes store function
> - introduced share_all debugging knob proposed by Andrew
> - minor cleanups
>
> v4: - merge_nodes was renamed to merge_across_nodes
> - share_all debug knob was dropped
> - get_kpfn_nid helper
> - fixed page migration behaviour
>
> v5: - unstable node's nid presence depends on CONFIG_NUMA
> - fixed oops appearing when stable nodes were removed from tree
> - roots of stable trees are initialized properly
> - fixed unstable page migration issue
>
> v6: - fixed oops caused by stable_nodes appended to wrong tree
> - KSM_RUN_MERGE test removed
>
> v7: - added sysfs ABI documentation for KSM
Hi Petr,
How you handle "memory corruption because the ksm page still points to
the stable_node that has been freed" mentioned by Andrea this time?
>
> Signed-off-by: Petr Holasek
> Signed-off-by: Hugh Dickins
> Acked-by: Rik van Riel
> ---
> Documentation/vm/ksm.txt | 7 +++
> mm/ksm.c | 151
> +--
> 2 files changed, 139 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
> index b392e49..25cc89b 100644
> --- a/Documentation/vm/ksm.txt
> +++ b/Documentation/vm/ksm.txt
> @@ -58,6 +58,13 @@ sleep_millisecs - how many milliseconds ksmd should sleep
> before next scan
> e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
> Default: 20 (chosen for demonstration purposes)
>
> +merge_across_nodes - specifies if pages from different numa nodes can be
> merged.
> + When set to 0, ksm merges only pages which physically
> + reside in the memory area of same NUMA node. It brings
> + lower latency to access to shared page. Value can be
> + changed only when there is no ksm shared pages in system.
> + Default: 1
> +
> run - set 0 to stop ksmd from running but keep merged pages,
> set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
> set 2 to stop ksmd and unmerge all pages currently merged,
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 5157385..d1e1041 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include "internal.h"
> @@ -139,6 +140,9 @@ struct rmap_item {
> struct mm_struct *mm;
> unsigned long address; /* + low bits used for flags below */
> unsigned int oldchecksum; /* when unstable */
> +#ifdef CONFIG_NUMA
> + unsigned int nid;
> +#endif
> union {
> struct rb_node node;/* when node of unstable tree */
> struct {/* when listed from stable tree */
> @@ -153,8 +157,8 @@ struct rmap_item {
> #define STABLE_FLAG 0x200 /* is listed from the stable tree */
>
>
Re: mm: lockup on mmap_sem
On Tue, Jan 1, 2013 at 1:55 AM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest, running latest -next
> kernel,
> I've stumbled on the following hang:
>
> [ 7204.030178] INFO: task khugepaged:3257 blocked for more than 120 seconds.
> [ 7204.031043] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 7204.032056] khugepaged D 001d6dc0 5144 3257 2
> 0x
> [ 7204.032969] 8800be8bdc00 0002 880007dd6e78
> 880007dd6e78
> [ 7204.033959] 8800bf9cb000 8800be8b3000 8800be8bdc00
> 001d6dc0
> [ 7204.034994] 8800be8b3000 8800be8bdfd8 001d6dc0
> 001d6dc0
> [ 7204.036057] Call Trace:
> [ 7204.036388] [] __schedule+0x2e9/0x3b0
> [ 7204.037090] [] schedule+0x55/0x60
> [ 7204.037711] [] rwsem_down_failed_common+0xf5/0x130
> [ 7204.038511] [] rwsem_down_read_failed+0x15/0x17
> [ 7204.039292] [] call_rwsem_down_read_failed+0x14/0x30
> [ 7204.040207] [] ? down_read+0x79/0x8e
> [ 7204.040895] [] ? khugepaged_scan_mm_slot+0xa7/0x2b0
> [ 7204.041689] [] ? _raw_spin_unlock+0x30/0x60
> [ 7204.042482] [] khugepaged_scan_mm_slot+0xa7/0x2b0
> [ 7204.043299] [] khugepaged_do_scan+0xfd/0x1a0
> [ 7204.044105] [] ? khugepaged_do_scan+0x1a0/0x1a0
> [ 7204.044874] [] khugepaged+0x25/0x70
> [ 7204.045527] [] kthread+0xe3/0xf0
> [ 7204.046129] [] ? flush_kthread_worker+0x190/0x190
> [ 7204.046905] [] ret_from_fork+0x7c/0xb0
> [ 7204.047609] [] ? flush_kthread_worker+0x190/0x190
> [ 7204.048524] 1 lock held by khugepaged/3257:
> [ 7204.049046] #0: (&mm->mmap_sem){++}, at: []
> khugepaged_scan_mm_slot+0xa7/0x2b0
> [ 7204.050449] INFO: task trinity-child22:15461 blocked for more than 120
> seconds.
> [ 7204.051355] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 7204.052390] trinity-child22 D 88000c00e4c0 4920 15461 6883
> 0x0004
> [ 7204.053347] 88002fba9bc0 0002 88000b6c2000
> 88000b6c2000
> [ 7204.054387] 880008003000 880007898000 88002fba9bc0
> 001d6dc0
> [ 7204.055373] 880007898000 88002fba9fd8 001d6dc0
> 001d6dc0
> [ 7204.056396] Call Trace:
> [ 7204.056703] [] __schedule+0x2e9/0x3b0
> [ 7204.057402] [] schedule+0x55/0x60
> [ 7204.058036] [] rwsem_down_failed_common+0xf5/0x130
> [ 7204.058826] [] rwsem_down_read_failed+0x15/0x17
> [ 7204.059588] [] call_rwsem_down_read_failed+0x14/0x30
> [ 7204.060502] [] ? down_read+0x79/0x8e
> [ 7204.061188] [] ? do_migrate_pages+0x56/0x2b0
> [ 7204.061906] [] ? lru_add_drain_all+0x10/0x20
> [ 7204.062648] [] do_migrate_pages+0x56/0x2b0
> [ 7204.063418] [] ? do_raw_spin_unlock+0xc8/0xe0
> [ 7204.064240] [] ? security_capable+0x13/0x20
> [ 7204.064865] [] ? ns_capable+0x50/0x80
> [ 7204.065443] [] sys_migrate_pages+0x4e2/0x550
> [ 7204.065964] [] ? sys_migrate_pages+0xb8/0x550
> [ 7204.066513] [] tracesys+0xe1/0xe6
> [ 7204.067011] 1 lock held by trinity-child22/15461:
> [ 7204.067452] #0: (&mm->mmap_sem){++}, at: []
> do_migrate_pages+0x56/0x2b0
> [ 7204.068489] INFO: task trinity-child16:15829 blocked for more than 120
> seconds.
> [ 7204.069224] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 7204.070057] trinity-child16 D 880008ba74c0 5128 15829 6883
> 0x0004
> [ 7204.070732] 88000c791bc0 0002 880012dd6000
> 880012dd6000
> [ 7204.071550] 88000c083000 88000d808000 88000c791bc0
> 001d6dc0
> [ 7204.072380] 88000d808000 88000c791fd8 001d6dc0
> 001d6dc0
> [ 7204.073323] Call Trace:
> [ 7204.073614] [] __schedule+0x2e9/0x3b0
> [ 7204.074179] [] schedule+0x55/0x60
> [ 7204.074619] [] rwsem_down_failed_common+0xf5/0x130
> [ 7204.075285] [] rwsem_down_read_failed+0x15/0x17
> [ 7204.075839] [] call_rwsem_down_read_failed+0x14/0x30
> [ 7204.076435] [] ? down_read+0x79/0x8e
> [ 7204.076900] [] ? do_migrate_pages+0x56/0x2b0
> [ 7204.077623] [] ? lru_add_drain_all+0x10/0x20
> [ 7204.078360] [] do_migrate_pages+0x56/0x2b0
> [ 7204.079063] [] ? do_raw_spin_unlock+0xc8/0xe0
> [ 7204.079622] [] ? security_capable+0x13/0x20
> [ 7204.080329] [] ? ns_capable+0x50/0x80
> [ 7204.080938] [] sys_migrate_pages+0x4e2/0x550
> [ 7204.081692] [] ? sys_migrate_pages+0xb8/0x550
> [ 7204.082241] [] tracesys+0xe1/0xe6
> [ 7204.082735] 1 lock held by trinity-child16/15829:
> [ 7204.083401] #0: (&mm->mmap_sem){++}, at: []
> do_migrate_pages+0x56/0x2b0
>
> I'm not quite sure how it happened, but I've attached a full sysrq-t which
> could possibly
> help with figuring it out.
>
Hey Sasha
Can you please try with the following commits reverted?
Hillf
[1] commit: 5a505085f
mm/rmap: Convert the struct anon_vma::mutex to an rwsem
[2] commit: 4fc3f1d66
mm/rmap, migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable
--
To unsubscribe from this list: send t
[PATCH 2] Re: New Defect(s) reported by Coverity Scan
From 68e866b8eac534405ae16b79b7ffd9de05c11c67 Mon Sep 17 00:00:00 2001
From: Nigel Cunningham
Date: Tue, 1 Jan 2013 13:50:22 +1100
Subject: [PATCH] Fix uninitialised variable in rbd_dev_probe_update_spec.
The local variable ret can be used uninitialised in the error path
if the kstrdup at line 2631 fails. Set ret to -ENOMEM in that case.
This patch addresses Coverity #753111.
Signed-off-by: Nigel Cunningham
---
drivers/block/rbd.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index dfb7ef8..ba4dd66 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2629,8 +2629,10 @@ static int rbd_dev_probe_update_spec(struct
rbd_device *rbd_dev)
goto out_err;
}
rbd_dev->spec->snap_name = kstrdup(name, GFP_KERNEL);
-if(!rbd_dev->spec->snap_name)
+if(!rbd_dev->spec->snap_name) {
+ret = -ENOMEM;
goto out_err;
+}
return 0;
out_err:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3] Re: New Defect(s) reported by Coverity Scan
From b4a7ab768df17e1cda7d0ae8744e986215a644c3 Mon Sep 17 00:00:00 2001
From: Nigel Cunningham
Date: Tue, 1 Jan 2013 13:53:51 +1100
Subject: [PATCH] Remove unused variable in rbd_dev_probe_update_spec.
As an aside to the previous patch, remove the unused local
variable reply_buf in that function.
Signed-off-by: Nigel Cunningham
---
drivers/block/rbd.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index ba4dd66..dccb6e4 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2592,7 +2592,6 @@ static int rbd_dev_probe_update_spec(struct
rbd_device *rbd_dev)
{
struct ceph_osd_client *osdc;
const char *name;
-void *reply_buf = NULL;
int ret;
if (rbd_dev->spec->pool_name)
@@ -2636,7 +2635,6 @@ static int rbd_dev_probe_update_spec(struct
rbd_device *rbd_dev)
return 0;
out_err:
-kfree(reply_buf);
kfree(rbd_dev->spec->pool_name);
rbd_dev->spec->pool_name = NULL;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: New Defect(s) reported by Coverity Scan
From b41864867464bfe0e2d114528bc9b39e2d9f546e Mon Sep 17 00:00:00 2001 From: Nigel Cunningham Date: Tue, 1 Jan 2013 13:03:50 +1100 Subject: [PATCH] Fix rbd use after free. This patch addresses Coverity #753114. The use of ceph_opts in rbd_add is currently confusing - there are three possible outcomes of the call to rbd_get_client: 1) An existing, matching and usable rdb client is found and returned by rbd_client_find. ceph_opts is freed by rbd_get_client and should not be freed by rbd_add. This the code path triggering the Coverity warning. 2) An existing, matching and usable rdb client is NOT found and returned by rbd_client_find. rbd_client_create successfully executes, passing responsibility for ceph_opts to the newly created client. It should not be freed by rbd_add. 3) An existing, matching and usable rdb client is NOT found and returned by rbd_client_find. rbd_client_create fails to create a new client, freeing ceph_opts in its error path. It should not be freed by rbd_add. So then, regardless of the outcome of rbd_get_client, if it is called, we should not attempt to free ceph_opts. The solution is then simple: there is no need to seek to free ceph_opts in rbd_add (or do anything with it) because rbd_get_client is called immediately after the structure is allocated by rbd_add_parse_args. Signed-off-by: Nigel Cunningham --- drivers/block/rbd.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c index 89576a0..dfb7ef8 100644 --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -3629,7 +3629,6 @@ static ssize_t rbd_add(struct bus_type *bus, rc = PTR_ERR(rbdc); goto err_out_args; } -ceph_opts = NULL;/* rbd_dev client now owns this */ /* pick the pool */ osdc = &rbdc->client->osdc; @@ -3658,8 +3657,6 @@ err_out_rbd_dev: err_out_client: rbd_put_client(rbdc); err_out_args: -if (ceph_opts) -ceph_destroy_options(ceph_opts); kfree(rbd_opts); rbd_spec_put(spec); err_out_module: -- 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: [RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth
On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote:
> Check that the AGP aperture can be mapped. This follows a similar change
> done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
> the aperture can be mapped by the CPU.).
>
> The patch fixes the following error seen on G5 iMac:
>
> nouveau E[ DRM] failed to create kernel channel, -12
>
> Reviewed-by: Michel Dänzer
> Signed-off-by: Aaro Koskinen
> ---
This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=58806.
For some (weird) reason Nouveau worked on this configuration on 3.6 kernel,
so cc'ing stable@vger seems to be appropriate.
> drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 5614c89..69d7b1d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1276,7 +1276,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> if (drm->agp.stat == ENABLED) {
> mem->bus.offset = mem->start << PAGE_SHIFT;
> mem->bus.base = drm->agp.base;
> - mem->bus.is_iomem = true;
> + mem->bus.is_iomem = !dev->agp->cant_use_aperture;
> }
> #endif
> break;
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Git v1.8.1
The latest feature release Git v1.8.1 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: ac8dced9c3232c0ec6a88d04600a4d0eaf2ba4e3 git-1.8.1.tar.gz a256fc56c89dc3c8d58b81a2c02dc89299f1f29b git-htmldocs-1.8.1.tar.gz a9ab9de3fa1781bb5009f5a215374dfc694feb30 git-manpages-1.8.1.tar.gz Also the following public repositories all have a copy of the v1.8.1 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.1 Release Notes Backward compatibility notes In the next major release (not *this* one), we will change the behavior of the "git push" command. When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). We will use the "simple" semantics that pushes the current branch to the branch with the same name, only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable "push.default" to change this, and "git push" will warn about the upcoming change until you set this variable in this release. "git branch --set-upstream" is deprecated and may be removed in a relatively distant future. "git branch [-u|--set-upstream-to]" has been introduced with a saner order of arguments to replace it. Updates since v1.8.0 UI, Workflows & Features * Command-line completion scripts for tcsh and zsh have been added. * "git-prompt" scriptlet (in contrib/completion) can be told to paint pieces of the hints in the prompt string in colors. * Some documentation pages that used to ship only in the plain text format are now formatted in HTML as well. * We used to have a workaround for a bug in ancient "less" that causes it to exit without any output when the terminal is resized. The bug has been fixed in "less" version 406 (June 2007), and the workaround has been removed in this release. * When "git checkout" checks out a branch, it tells the user how far behind (or ahead) the new branch is relative to the remote tracking branch it builds upon. The message now also advises how to sync them up by pushing or pulling. This can be disabled with the advice.statusHints configuration variable. * "git config --get" used to diagnose presence of multiple definitions of the same variable in the same configuration file as an error, but it now applies the "last one wins" rule used by the internal configuration logic. Strictly speaking, this may be an API regression but it is expected that nobody will notice it in practice. * A new configuration variable "diff.context" can be used to give the default number of context lines in the patch output, to override the hardcoded default of 3 lines. * "git format-patch" learned the "--notes=" option to give notes for the commit after the three-dash lines in its output. * "git log -p -S" now looks for the after applying the textconv filter (if defined); earlier it inspected the contents of the blobs without filtering. * "git log --grep=" learned to honor the "grep.patterntype" configuration set to "perl". * "git replace -d " now interprets as an extended SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex object name. * "git rm $submodule" used to punt on removing a submodule working tree to avoid losing the repository embedded in it. Because recent git uses a mechanism to separate the submodule repository from the submodule working tree, "git rm" learned to detect this case and removes the submodule working tree when it is safe to do so. * "git send-email" used to prompt for the sender address, even when the committer identity is well specified (e.g. via user.name and user.email configuration variables). The command no longer gives this prompt when not necessary. * "git send-email" did not allow non-address garbage strings to appear after addresses on Cc: lines in the patch files (and when told to pick them up to find more recipients), e.g. Cc: Stable Kernel # for v3.2 and up The command now strips " # for v3.2 and up" part before adding the remainder of this line to the list of recipients. * "git submodule add" learned to add a new submodule at the same path as the path where an unrelated submodule was bound to in an existing revision via the "--name" option. * "git submodule sync" learned the "--recursive" option. * "diff.submodule" configuration variable can be used to give custom
New Defect(s) reported by Coverity Scan
Hi,
Please find the latest report on new defect(s) that have been introduced to the
Linux Kernel found with Coverity SCAN.
Defect(s) Reported-by: Coverity Scan:
___
** CID 753114: Use after free (USE_AFTER_FREE)
/drivers/block/rbd.c: 3662
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753114
** CID 753112: Uninitialized scalar variable (UNINIT)
/fs/f2fs/node.c: 713
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753112
** CID 753111: Uninitialized scalar variable (UNINIT)
/drivers/block/rbd.c: 2641
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753111
** CID 753110: Use of untrusted scalar value (TAINTED_SCALAR)
/fs/nfsd/fault_inject.c: 138
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753110
** CID 753109: Dereference null return value (NULL_RETURNS)
/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: 1109
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753109
** CID 753108: Dereference null return value (NULL_RETURNS)
/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: 1207
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753108
** CID 753107: Dereference null return value (NULL_RETURNS)
/drivers/infiniband/hw/cxgb4/cm.c: 2910
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753107
** CID 753106: Dereference null return value (NULL_RETURNS)
/drivers/infiniband/hw/cxgb4/cm.c: 1463
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753106
** CID 753105: Data race condition (MISSING_LOCK)
/fs/f2fs/node.h: 68
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753105
** CID 753104: Data race condition (MISSING_LOCK)
/fs/f2fs/node.h: 67
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753104
** CID 753103: Explicit null dereferenced (FORWARD_NULL)
/fs/f2fs/acl.c: 200
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753103
** CID 753102: Unchecked return value (CHECKED_RETURN)
/fs/f2fs/recovery.c: 70
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753102
** CID 753101: Unchecked return value (CHECKED_RETURN)
/drivers/vfio/pci/vfio_pci.c: 59
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753101
###
Defect Details:
___
CID 753114: Use after free (USE_AFTER_FREE)
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753114
/drivers/block/rbd.c: 3627 ( freed_arg)
3624 if (rc < 0)
3625 goto err_out_module;
3626
>>> "rbd_get_client(struct ceph_options *)" frees "ceph_opts".
3627 rbdc = rbd_get_client(ceph_opts);
3628 if (IS_ERR(rbdc)) {
3629 rc = PTR_ERR(rbdc);
3630 goto err_out_args;
3631 }
/drivers/block/rbd.c: 3662 ( deref_arg)
3659 rbd_put_client(rbdc);
3660err_out_args:
3661 if (ceph_opts)
>>> CID 753114: Use after free (USE_AFTER_FREE) Calling
>>> "ceph_destroy_options(struct ceph_options *)" dereferences freed pointer
>>> "ceph_opts".
3662 ceph_destroy_options(ceph_opts);
3663 kfree(rbd_opts);
3664 rbd_spec_put(spec);
3665err_out_module:
3666 module_put(THIS_MODULE);
CID 753112: Uninitialized scalar variable (UNINIT)
http://scan5.coverity.com:8080/sourcebrowser.htm?projectId=10063#mergedDefectId=753112
/fs/f2fs/node.c: 663 ( var_decl)
660 int level, offset[4], noffset[4];
661 unsigned int nofs;
662 struct f2fs_node *rn;
>>> Declaring variable "dn" without initializer.
663 struct dnode_of_data dn;
664 struct page *page;
665
666 level = get_node_path(from, offset, noffset);
667
/fs/f2fs/node.c: 713 ( uninit_use_in_call)
710
711 case NODE_IND1_BLOCK:
712 case NODE_IND2_BLOCK:
>>> CID 753112: Uninitialized scalar variable (UNINIT) Using
>>> uninitialized value "dn": field "dn"."data_blkaddr" is uninitialized when
>>> calling "truncate_nodes(struct dnode_of_data *, unsigned int, int, int)".
713 err = truncate_nodes(&dn, nofs, offset[1], 2);
714 break;
715
716 case NODE_DIND_BLOCK:
717 err = truncate_nodes(&dn, nofs, offset[1], 3);
CID 753111: Uninitiali
Re: [PATCH] poll: prevent missed events if _qproc is NULL
Eric Wong wrote: > This patch seems to fix my issue with ppoll() being stuck on my > SMP machine: http://article.gmane.org/gmane.linux.file-systems/70414 OK, it doesn't fix my issue, but it seems to make it harder-to-hit... > The change to sock_poll_wait() in > commit 626cf236608505d376e4799adb4f7eb00a8594af > (poll: add poll_requested_events() and poll_does_not_wait() functions) > seems to have allowed additional cases where the SMP memory barrier > is not issued before checking for readiness. > > In my case, this affects the select()-family of functions > which register descriptors once and set _qproc to NULL before > checking events again (after poll_schedule_timeout() returns). > The set_mb() barrier in poll_schedule_timeout() appears to be > insufficient on my SMP x86-64 machine (as it's only an xchg()). > > This may also be related to the epoll issue described by > Andreas Voellmy in http://thread.gmane.org/gmane.linux.kernel/1408782/ However, I believe my patch will still fix Andreas' issue with epoll due to how ep_modify() uses a NULL qproc when calling ->poll(). (I've never been able to reproduce Andreas' issue on my 4-core system, but he's been hitting it since 3.4 (at least)) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 7/8] zswap: add to mm/
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > Subject: [PATCH 7/8] zswap: add to mm/ > > zswap is a thin compression backend for frontswap. It receives > pages from frontswap and attempts to store them in a compressed > memory pool, resulting in an effective partial memory reclaim and > dramatically reduced swap device I/O. Hi Seth -- Happy (almost) New Year! I am eagerly studying one of the details of your zswap "flush" code in this patch to see how you solved a problem or two that I was struggling with for the similar mechanism RFC'ed for zcache (see https://lkml.org/lkml/2012/10/3/558). I like the way that you force the newly-uncompressed to-be-flushed page immediately into a swap bio in zswap_flush_entry via the call to swap_writepage, though I'm not entirely convinced that there aren't some race conditions there. However, won't swap_writepage simply call frontswap_store instead and re-compress the page back into zswap? The (very ugly) solution I used for this was to flag the page in a frontswap_denial_map (see https://lkml.org/lkml/2012/10/3/560). Don't you require something like that also, or am I missing some magic in your code? I'm also a bit concerned about the consequent recursion: frontswap_store-> zswap_fs_store-> zswap_flush_entries-> zswap_flush_entry-> __swap_writepage-> swap_writepage-> frontswap_store-> zswap_fs_store-> etc It's not obvious to me how deeply this might recurse and/or how the recursion is terminated. The RFC'ed zcache code calls its equivalence of your "flush" code only from the shrinker thread to avoid this, though there may be a third, better, way. A second related issue that concerns me is that, although you are now, like zcache2, using an LRU queue for compressed pages (aka "zpages"), there is no relationship between that queue and physical pageframes. In other words, you may free up 100 zpages out of zswap via zswap_flush_entries, but not free up a single pageframe. This seems like a significant design issue. Or am I misunderstanding the code? A third concern is about scalability... the locking seems very coarse-grained. In zcache, you personally observed and fixed hashbucket contention (see https://lkml.org/lkml/2011/9/29/215). Doesn't zswap's tree_lock essentially use a single tree (per swaptype), i.e. no scalability? Thanks, Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] input: vt8500: Add power button keypad driver
This patch adds support for the Power Button keypad found on
Wondermedia netbooks/tablets.
A keymap property is exposed to allowing defining the key
event to be generated when the power button is pressed.
Signed-off-by: Tony Prisk
---
CC: linux-kernel@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: vt8500-wm8505-linux-ker...@googlegroups.com
CC: linux-in...@vger.kernel.org
v2:
Remove devicetree binding for keycode
Add dependency on OF in Kconfig
Move static variables in a struct
Remove redundant inline modifier from kpad_power_timeout()
Remove unneccessary checks against power_button_pressed. Drop variable.
Cleanup the fail path code and add a .remove function.
Change the button behaviour so that a key-released event is only generated once
the key is released, not after timeout.
*Changes tested on WM8650 tablet.
v3:
Remove dependency on PMC node, and change binding document accordingly.
Remove mod_timer call in kpad_power_timeout()
Unmap io memory in fail path and .remove
Update name & phys fields to be more meaningful
Use del_timer_sync rather than del_timer
Fix usage of input_unregister_device/input_free_device
.../bindings/input/vt8500-power-keypad.txt | 17 ++
drivers/input/keyboard/Kconfig | 10 ++
drivers/input/keyboard/Makefile|1 +
drivers/input/keyboard/wmt_power_keypad.c | 182
4 files changed, 210 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
create mode 100644 drivers/input/keyboard/wmt_power_keypad.c
diff --git a/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
new file mode 100644
index 000..f6996d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
@@ -0,0 +1,17 @@
+* Wondermedia Power Keypad device tree bindings
+
+Wondermedia SoCs have a single irq-driven power button attached to
+the power management controller.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - "wm,power-keypad": For all Wondermedia 8xxx-series SoCs.
+- reg : Should contain the register range of the Power Mgmt controller
+- interrupts: should be the power management controller wakeup interrupt.
+
+Example:
+ powerkey: pwrkey@0 {
+ compatible = "wm,power-keypad";
+ reg = <0xd813 0x1000>;
+ interrupts = <22>;
+ };
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 5a240c6..bb1e04f 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -595,6 +595,16 @@ config KEYBOARD_TWL4030
To compile this driver as a module, choose M here: the
module will be called twl4030_keypad.
+config KEYBOARD_WMT_POWER_KEYPAD
+ tristate "Wondermedia Power keypad support"
+ depends on (OF && ARCH_VT8500)
+ help
+ Say Y here to enable support for the power button keypad
+ on Wondermedia 8xxx-series SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called wmt_power_keypad.
+
config KEYBOARD_XTKBD
tristate "XT keyboard"
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 44e7600..eea31af 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)+=
tc3589x-keypad.o
obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
+obj-$(CONFIG_KEYBOARD_WMT_POWER_KEYPAD)+= wmt_power_keypad.o
obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/wmt_power_keypad.c
b/drivers/input/keyboard/wmt_power_keypad.c
new file mode 100644
index 000..383b73e
--- /dev/null
+++ b/drivers/input/keyboard/wmt_power_keypad.c
@@ -0,0 +1,182 @@
+/* Wondermedia Power Keypad
+ *
+ * Copyright (C) 2012 Tony Prisk
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct kpad_pwr_data {
+ struct input_dev*kpad_power;
+ void __iomem*pmc_base;
+ int irq;
+ struct timer_list ti
Re: [PATCH] prctl: fix validation of an address
Quoting Cyrill Gorcunov (gorcu...@openvz.org): > > The kernel makes the decision on what is valid via security_mmap_addr(). > > Assuming there are no security fears of an untrusted application > > tricking some priviledged application to set up these maps the answer is > > just calling security_mmap_addr() instead of doing if(addr < > > mmap_min_addr) return -EINVAL; > > If only I've not missed something obvious, the check for security_mmap_addr() > here > instead of poking the mmap_min_addr looks more correct for me. Andrew? That sounds right to me as well. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] input: vt8500: Add power button keypad driver
On Mon, 2012-12-31 at 12:37 -0800, Dmitry Torokhov wrote:
> Hi Tony,
>
> On Mon, Dec 31, 2012 at 03:04:59PM +1300, Tony Prisk wrote:
> > This patch adds support for the Power Button keypad found on
> > Wondermedia netbooks/tablets.
> >
> > Signed-off-by: Tony Prisk
> > ---
> > v2:
> > Remove devicetree binding for keycode
> > Add dependency on OF in Kconfig
> > Move static variables in a struct
> > Remove redundant inline modifier from kpad_power_timeout()
> > Remove unneccessary checks against power_button_pressed. Drop variable.
> > Cleanup the fail path code and add a .remove function.
> > Change the button behaviour so that a key-released event is only generated
> > once
> > the key is released, not after timeout.
> > *Changes tested on WM8650 tablet.
>
>
> Thank you for making the requested changes, unfortunately there is some
> more...
It's never unfortunate to get it right :)
>
> >
> > + status = readl(data->pmc_base + 0x14);
> > + if (status & BIT(14)) {
> > + /* Button isn't release so check again in 50ms */
> > + mod_timer(&data->timer, jiffies + msecs_to_jiffies(50));
>
> I do not think you need to do this: your ISR does "mod_timer" which
> means that the timer expiration gets extended every time there is
> interrupt, so as long as the button is pressed the timer will not run.
> So I'd just report the button as released here and be done with it.
Will fix.
> > +
> > + np = of_find_compatible_node(NULL, NULL, "via,vt8500-pmc");
> > + if (!np) {
> > + dev_err(&pdev->dev, "pmc node not found\n");
> > + return -EINVAL;
> > + }
>
> Hmm, why are we looking up another device? What is it is not there yet?
> Can we have all resources contained in this device DT description?
This driver uses registers in the power management controller. It didn't
seem right to declare the memory space for this device as well as the PM
controller, but I don't think there is any reason why it couldn't - just
seemed a bit backward to me.
> > + data->pmc_base = of_iomap(np, 0);
> > + if (!data->pmc_base) {
> > + dev_err(&pdev->dev, "unable to map pmc memory\n");
> > + return -ENOMEM;
> > + }
> > +
> > + np = pdev->dev.of_node;
> > + if (!np) {
> > + dev_err(&pdev->dev, "devicenode not found\n");
>
> Your error handling is still incomplete, you need to unmap the memory
> you just mapped above.
Will do.
>
> I happened to peek at other vt8500 drivers and the lack of proper error
> handling and absence of remove() methods is a common theme among them.
Will put this on my list of things to look into. Thanks for pointing it
out.
>
> > +
> > + data->kpad_power->evbit[0] = BIT_MASK(EV_KEY);
> > + set_bit(data->keycode, data->kpad_power->keybit);
>
> Make it:
>
> input_set_capability(data->kpad_power, EV_KEY, data->keycode);
OK.
>
> > +
> > + data->kpad_power->name = "wmt_power_keypad";
> > + data->kpad_power->phys = "wmt_power_keypad";
>
> You can have more "human" name in name field, you do not have to have
> underscores. Also if you want to use phys it is common to have it in
> form of "/input0" so something like "vt8500-pmic/input0".
Thanks.
>
> > + data->kpad_power->keycode = &data->keycode;
> > + data->kpad_power->keycodesize = sizeof(unsigned int);
> > + data->kpad_power->keycodemax = 1;
> > +
> > + err = input_register_device(data->kpad_power);
> > + if (err < 0) {
> > + dev_err(&pdev->dev, "failed to register input device\n");
> > + goto cleanup_input;
> > + }
> > +
>
> I'd recommend registering input device after you request irq as it
> simplifies error path (it is OK for ISR to use allocated but not
> registered input device).
Sounds good.
>
> > +
> > +static int vt8500_pwr_kpad_remove(struct platform_device *pdev)
> > +
> > +{
> > + struct kpad_pwr_data *data = platform_get_drvdata(pdev);
> > +
> > + free_irq(data->irq, data);
> > + del_timer(&data->timer);
>
> This should be del_timer_sync().
OK.
>
> > + input_unregister_device(data->kpad_power);
> > + input_free_device(data->kpad_power);
>
> input_free_device() after input_unregister_device() will result in
> double-free. The rule is use input_free_device() if device has not been
> registered, otherwise use input_unregister_device().
That seems a little unintuitive given the functions seemed to be paired.
Will fix. Thanks.
>
> You also need to unmap the mapped region.
Will do.
Regards
Tony P
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Access control in Xen privcmd_ioctl_mmap
In the privcmd Linux driver two checks in the functions
privcmd_ioctl_mmap and privcmd_ioctl_mmap_batch are not needed as they
are trying to enforce hypervisor-level access control. They should be
removed as they break secondary control domains when performing dom0
disaggregation. Xen itself provides adequate security controls around
these hypercalls and these checks prevent those controls from
functioning as intended.
The patch applies to the stable Linux 3.7.1 kernel.
Signed-off-by: Tamas K Lengyel
Cc: Daniel De Graaf
Cc: xen-de...@lists.xensource.com
Cc: linux-kernel@vger.kernel.org
---
drivers/xen/privcmd.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 71f5c45..adaa260 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -196,9 +196,6 @@ static long privcmd_ioctl_mmap(void __user *udata)
LIST_HEAD(pagelist);
struct mmap_mfn_state state;
- if (!xen_initial_domain())
- return -EPERM;
-
if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
return -EFAULT;
@@ -316,9 +313,6 @@ static long privcmd_ioctl_mmap_batch(void __user
*udata, int version)
int *err_array = NULL;
struct mmap_batch_state state;
- if (!xen_initial_domain())
- return -EPERM;
-
switch (version) {
case 1:
if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] input: vt8500: Add power button keypad driver
Hi Tony,
On Mon, Dec 31, 2012 at 03:04:59PM +1300, Tony Prisk wrote:
> This patch adds support for the Power Button keypad found on
> Wondermedia netbooks/tablets.
>
> Signed-off-by: Tony Prisk
> ---
> v2:
> Remove devicetree binding for keycode
> Add dependency on OF in Kconfig
> Move static variables in a struct
> Remove redundant inline modifier from kpad_power_timeout()
> Remove unneccessary checks against power_button_pressed. Drop variable.
> Cleanup the fail path code and add a .remove function.
> Change the button behaviour so that a key-released event is only generated
> once
> the key is released, not after timeout.
> *Changes tested on WM8650 tablet.
Thank you for making the requested changes, unfortunately there is some
more...
>
> .../bindings/input/vt8500-power-keypad.txt | 15 ++
> drivers/input/keyboard/Kconfig | 10 +
> drivers/input/keyboard/Makefile|1 +
> drivers/input/keyboard/wmt_power_keypad.c | 198
>
> 4 files changed, 224 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
> create mode 100644 drivers/input/keyboard/wmt_power_keypad.c
>
> diff --git a/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
> b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
> new file mode 100644
> index 000..63f170b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
> @@ -0,0 +1,15 @@
> +* Wondermedia Power Keypad device tree bindings
> +
> +Wondermedia SoCs have a single irq-driven power button attached to
> +the power management controller.
> +
> +Required SoC Specific Properties:
> +- compatible: should be one of the following
> + - "wm,power-keypad": For all Wondermedia 8xxx-series SoCs.
> +- interrupts: should be the power management controller wakeup interrupt.
> +
> +Example:
> + powerkey: pwrkey@0 {
> + compatible = "wm,power-keypad";
> + interrupts = <22>;
> + };
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 5a240c6..bb1e04f 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -595,6 +595,16 @@ config KEYBOARD_TWL4030
> To compile this driver as a module, choose M here: the
> module will be called twl4030_keypad.
>
> +config KEYBOARD_WMT_POWER_KEYPAD
> + tristate "Wondermedia Power keypad support"
> + depends on (OF && ARCH_VT8500)
> + help
> + Say Y here to enable support for the power button keypad
> + on Wondermedia 8xxx-series SoCs.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called wmt_power_keypad.
> +
> config KEYBOARD_XTKBD
> tristate "XT keyboard"
> select SERIO
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 44e7600..eea31af 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X) +=
> tc3589x-keypad.o
> obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
> obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
> obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
> +obj-$(CONFIG_KEYBOARD_WMT_POWER_KEYPAD) += wmt_power_keypad.o
> obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
> obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
> diff --git a/drivers/input/keyboard/wmt_power_keypad.c
> b/drivers/input/keyboard/wmt_power_keypad.c
> new file mode 100644
> index 000..f3b24d8
> --- /dev/null
> +++ b/drivers/input/keyboard/wmt_power_keypad.c
> @@ -0,0 +1,198 @@
> +/* Wondermedia Power Keypad
> + *
> + * Copyright (C) 2012 Tony Prisk
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct kpad_pwr_data {
> + struct input_dev*kpad_power;
> + void __iomem*pmc_base;
> + int irq;
> + struct timer_list timer;
> + spinlock_t lock;
> + unsigned intkeycode;
> +};
> +
> +static void kpad_power_timeout(unsigned long fcontext)
> +{
> + struct kpad_pwr_data *data = (struct kpad_pwr_data *)fcontext;
> + u32 status;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&data->lock, flags);
> +
>
Re: [PATCH v6 05/12] iommu/exynos: support for device tree
On 12/26/2012 02:53 AM, Cho KyongHo wrote:
> This commit adds device tree support for System MMU.
>
> Signed-off-by: KyongHo Cho
Cc: devicetree-disc...@lists.ozlabs.org
Please note any patches adding new device tree bindings should be sent
to this mailing list. I have few comments, please see below.
> ---
> drivers/iommu/Kconfig| 2 +-
> drivers/iommu/exynos-iommu.c | 282
> ++-
> 2 files changed, 174 insertions(+), 110 deletions(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index e39f9db..64586f1 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -168,7 +168,7 @@ config TEGRA_IOMMU_SMMU
>
> config EXYNOS_IOMMU
> bool "Exynos IOMMU Support"
> - depends on ARCH_EXYNOS&& EXYNOS_DEV_SYSMMU
> + depends on ARCH_EXYNOS
> select IOMMU_API
> help
> Support for the IOMMU(System MMU) of Samsung Exynos application
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 5847508..5b35820 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1,6 +1,6 @@
> -/* linux/drivers/iommu/exynos_iommu.c
> +/* linux/drivers/iommu/exynos-iommu.c
>*
> - * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
>* http://www.samsung.com
>*
>* This program is free software; you can redistribute it and/or modify
> @@ -12,6 +12,7 @@
> #define DEBUG
> #endif
>
> +#include
> #include
> #include
> #include
> @@ -25,11 +26,10 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> -#include
> -
> -#include
>
> /* We does not consider super section mapping (16MB) */
> #define SECT_ORDER 20
> @@ -161,14 +161,13 @@ struct sysmmu_drvdata {
> struct list_head node; /* entry of exynos_iommu_domain.clients */
> struct device *sysmmu; /* System MMU's device descriptor */
> struct device *dev; /* Owner of system MMU */
> - char *dbgname;
> int nsfrs;
> - void __iomem **sfrbases;
> - struct clk *clk[2];
> + struct clk *clk;
> int activations;
> spinlock_t lock;
> struct iommu_domain *domain;
> unsigned long pgtable;
> + void __iomem *sfrbases[0];
> };
>
> static bool set_sysmmu_active(struct sysmmu_drvdata *data)
> @@ -373,10 +372,8 @@ static bool __exynos_sysmmu_disable(struct
> sysmmu_drvdata *data)
> for (i = 0; i< data->nsfrs; i++)
> __raw_writel(CTRL_DISABLE, data->sfrbases[i] + REG_MMU_CTRL);
>
> - if (data->clk[1])
> - clk_disable(data->clk[1]);
> - if (data->clk[0])
> - clk_disable(data->clk[0]);
> + if (data->clk)
> + clk_disable(data->clk);
>
> disabled = true;
> data->pgtable = 0;
> @@ -385,10 +382,10 @@ finish:
> spin_unlock_irqrestore(&data->lock, flags);
>
> if (disabled)
> - dev_dbg(data->sysmmu, "(%s) Disabled\n", data->dbgname);
> + dev_dbg(data->sysmmu, "Disabled\n");
> else
> - dev_dbg(data->sysmmu, "(%s) %d times left to be disabled\n",
> - data->dbgname, data->activations);
> + dev_dbg(data->sysmmu, "%d times left to be disabled\n",
> + data->activations);
>
> return disabled;
> }
> @@ -415,14 +412,12 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata
> *data,
> ret = 1;
> }
>
> - dev_dbg(data->sysmmu, "(%s) Already enabled\n", data->dbgname);
> + dev_dbg(data->sysmmu, "Already enabled\n");
> goto finish;
> }
>
> - if (data->clk[0])
> - clk_enable(data->clk[0]);
> - if (data->clk[1])
> - clk_enable(data->clk[1]);
> + if (data->clk)
> + clk_enable(data->clk);
>
> data->pgtable = pgtable;
>
> @@ -442,7 +437,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata
> *data,
>
> data->domain = domain;
>
> - dev_dbg(data->sysmmu, "(%s) Enabled\n", data->dbgname);
> + dev_dbg(data->sysmmu, "Enabled\n");
> finish:
> spin_unlock_irqrestore(&data->lock, flags);
>
> @@ -458,7 +453,7 @@ int exynos_sysmmu_enable(struct device *dev, unsigned
> long pgtable)
>
> ret = pm_runtime_get_sync(data->sysmmu);
> if (ret< 0) {
> - dev_dbg(data->sysmmu, "(%s) Failed to enable\n", data->dbgname);
> + dev_dbg(data->sysmmu, "Failed to enable\n");
> return ret;
> }
>
> @@ -466,8 +461,8 @@ int exynos_sysmmu_enable(struct device *dev, unsigned
> long pgtable)
> if (WARN_ON(ret< 0)) {
> pm_runtime_put(data->sysmmu);
> dev_err(data->sysmmu,
> - "(%s) Already enabled with page table %#lx\n",
> - data->dbgname, data->pgtable);
> +
Re: [RFC] ktap: Another dynamic tracing tool for Linux
bookjovi wrote: > [...] This mail is RFC for discuss on a new dynamic tracing tool, I > name it ktap. (only experimental project now) Welcome to the problem domain! > [...] > what ktap differentiates with Systemtap is: > [...] > 2). ktap have good portability, because it compile source file to > bytecode, like python and Java. (From this PoV, systemtap is just as portable as the kernel, as it generates the same sort of C code the kernel is built from.) > [...] > 5). ktap will be open source completely, with GPL license, it might be > merge into mainline in someday, that's very convince for tracing user. (systemtap has always been GPLv2, ever since its beginning in 2005.) > [...] > ktap use lua language syntax and bytecode as initial implementation, Interesting approach. I recall we considered it way back when, but rejected it for a couple of reasons, including the at-the-time perceived unwelcomeness of a serious bytecode interpreter within the kernel. > it could support kprobe, uprobe, userspace probe, etc. Great. > I wish you can give me some technical architecture pre-review for > ktap, before ktap release 1.0. > Any comments is welcome, thanks very much. Have you made any source code available yet? - FChE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] uio: sercos3: use devm_kzalloc
use devm_kzalloc and no need of free's at error path and unload
Signed-off-by: Devendra Naga
---
Please apply this after
changeid: 1fb4ec94e7e955a1e26bf81f2634e5be2fa5f1d5
[PATCH] uio: uio_sercos3: use module_pci_driver macro
sorry for sending as patch should be patch 2/2.
drivers/uio/uio_sercos3.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/uio/uio_sercos3.c b/drivers/uio/uio_sercos3.c
index 5419832..c0d758a 100644
--- a/drivers/uio/uio_sercos3.c
+++ b/drivers/uio/uio_sercos3.c
@@ -123,16 +123,16 @@ static int sercos3_pci_probe(struct pci_dev *dev,
struct sercos3_priv *priv;
int i;
- info = kzalloc(sizeof(struct uio_info), GFP_KERNEL);
+ info = devm_kzalloc(&dev->dev, sizeof(struct uio_info), GFP_KERNEL);
if (!info)
return -ENOMEM;
- priv = kzalloc(sizeof(struct sercos3_priv), GFP_KERNEL);
+ priv = devm_kzalloc(&dev->dev, sizeof(struct sercos3_priv), GFP_KERNEL);
if (!priv)
- goto out_free;
+ return -ENOMEM;
if (pci_enable_device(dev))
- goto out_free_priv;
+ goto out;
if (pci_request_regions(dev, "sercos3"))
goto out_disable;
@@ -173,10 +173,7 @@ out_unmap:
pci_release_regions(dev);
out_disable:
pci_disable_device(dev);
-out_free_priv:
- kfree(priv);
-out_free:
- kfree(info);
+out:
return -ENODEV;
}
@@ -193,8 +190,6 @@ static void sercos3_pci_remove(struct pci_dev *dev)
if (info->mem[i].internal_addr)
iounmap(info->mem[i].internal_addr);
}
- kfree(info->priv);
- kfree(info);
}
static struct pci_device_id sercos3_pci_ids[] = {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PATCH: Error Checking for pagemap.h.
This patch is for the pagemap.h. This checks to see if the
page_size_int is 2, if not, set the value to 2, and return 1.
The code is under the double-dashed lines. It is for Kernel Version 3.8-rc1.
This is a rewrite.
--
Signed-off-by: Christopher P. Sacchi chris.sac...@gmail.com
--- pagemap.h 2012-12-21 20:19:00.0 -0500
+++ pagemap.h 2012-12-31 13:07:51.566631871 -0500
@@ -14,11 +14,15 @@
#include
#include /* for in_interrupt() */
#include
-
/*
* Bits in mapping->flags. The lower __GFP_BITS_SHIFT bits are the page
* allocation mode flags.
*/
+/*
+* Here we declare the number that
+* the PAGE_SIZE should have.
+* We need it an integer for checking
+* and writing. This value should be two.
+* If not, later we'll check.
+*/
+int page_size_integer = 2;
enum mapping_flags {
AS_EIO = __GFP_BITS_SHIFT + 0, /* IO error on async write */
AS_ENOSPC = __GFP_BITS_SHIFT + 1, /* ENOSPC on async write */
@@ -426,6 +430,18 @@ extern void add_page_wait_queue(struct p
* This assumes that two userspace pages are always sufficient. That's
* not true if PAGE_CACHE_SIZE > PAGE_SIZE.
*/
+
+/*
+* Here we'll check for if the two userspace pages are not sufficient,
+* and if PAGE_CACHE_SIZE > PAGE_SIZE.
+* This will return 1 if true,
+* and will set the value back to 2 in case of a fault.
+*/
+static inline int fault_userspace_assumption_sufficient_not_true()
+{
+ if (PAGE_CACHE_SIZE > PAGE_SIZE) {
+ page_size_int = 2;
+ return 1;
+ }
+}
static inline int fault_in_pages_writeable(char __user *uaddr, int size)
{
int ret;
--
Regards,
Christopher
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Error checking page_size to see if userspace page_size_int = 2.
This patch is for the pagemap.h. This checks to see if the
page_size_int is 2, if not, set the value to 2, and return 1.
The code is under the double-dashed lines.
--
Signed-off-by: Christopher P. Sacchi chris.sac...@gmail.com
--- pagemap.h 2012-12-21 20:19:00.0 -0500
+++ pagemap.h 2012-12-31 13:07:51.566631871 -0500
@@ -14,11 +14,15 @@
#include
#include /* for in_interrupt() */
#include
-
/*
* Bits in mapping->flags. The lower __GFP_BITS_SHIFT bits are the page
* allocation mode flags.
*/
+/*
+* Here we declare the number that
+* the PAGE_SIZE should have.
+* We need it an integer for checking
+* and writing. This value should be two.
+* If not, later we'll check.
+*/
+int page_size_integer = 2;
enum mapping_flags {
AS_EIO = __GFP_BITS_SHIFT + 0, /* IO error on async write */
AS_ENOSPC = __GFP_BITS_SHIFT + 1, /* ENOSPC on async write */
@@ -426,6 +430,18 @@ extern void add_page_wait_queue(struct p
* This assumes that two userspace pages are always sufficient. That's
* not true if PAGE_CACHE_SIZE > PAGE_SIZE.
*/
+
+/*
+* Here we'll check for if the two userspace pages are not sufficient,
+* and if PAGE_CACHE_SIZE > PAGE_SIZE.
+* This will return 1 if true,
+* and will set the value back to 2 in case of a fault.
+*/
+static inline int fault_userspace_assumption_sufficient_not_true()
+{
+ if (PAGE_CACHE_SIZE > PAGE_SIZE) {
+ page_size_int = 2;
+ return 1;
+ }
+}
static inline int fault_in_pages_writeable(char __user *uaddr, int size)
{
int ret;
--
Regards,
Christopher
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] uio: uio_sercos3: use module_pci_driver macro
use module_pci_driver macro and simplify the module init and exit code
Signed-off-by: Devendra Naga
---
drivers/uio/uio_sercos3.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/uio/uio_sercos3.c b/drivers/uio/uio_sercos3.c
index 81a10a5..5419832 100644
--- a/drivers/uio/uio_sercos3.c
+++ b/drivers/uio/uio_sercos3.c
@@ -226,19 +226,7 @@ static struct pci_driver sercos3_pci_driver = {
.remove = sercos3_pci_remove,
};
-static int __init sercos3_init_module(void)
-{
- return pci_register_driver(&sercos3_pci_driver);
-}
-
-static void __exit sercos3_exit_module(void)
-{
- pci_unregister_driver(&sercos3_pci_driver);
-}
-
-module_init(sercos3_init_module);
-module_exit(sercos3_exit_module);
-
+module_pci_driver(sercos3_pci_driver);
MODULE_DESCRIPTION("UIO driver for the Automata Sercos III PCI card");
MODULE_AUTHOR("John Ogness ");
MODULE_LICENSE("GPL v2");
--
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 v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
Cho KyongHo wrote: > > notice: v6 patch-set is rebased on next/iommu-exynos branch of > linux-samsung.git. This patch-set does not include 2 patches (05 and 06 > patches in v5 patch-se) because they alread exist already in the branch. > > The current exynos-iommu(System MMU) driver does not work > autonomously > since it is lack of support for power management of peripheral blocks. > For example, MFC device driver must ensure that its System MMU is > disabled > before MFC block is power-down not to invalidate IOTLB in the System MMU > when I/O memory mapping is changed. Because A System MMU is resides in > the > same H/W block, access to control registers of System MMU while the H/W > block is turned off must be prohibited. > > This set of changes solves the above problem with setting each System > MMUs > as the parent of the device which owns the System MMU to recieve the > information when the device is turned off or turned on. > > Another big change to the driver is the support for devicetree. > The bindings for System MMU is described in > Documentation/devicetree/bindings/arm/samsung/system-mmu.txt > > In addition, this patchset also includes several bug fixes and enhancements > of the current driver. > > Change log: > v6: > - Rebased on the branch, next/iommu-exynos of > git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > > v5: > - new bugfix: patch 01 > - Reordered patches > * patch 01 ~ 05: Bugfix and enhancements of the existing driver > * patch 06 ~ 10: Device Tree support and callbacks for power management > * patch 11 : System MMU 3.2 and 3.3 support > * patch 12 ~ 14: Debugging features > - Additional code compaction > > v4: > - Remove Change-Id from v3 patches > - Change the order of the third and the first patch > Thanks to Kukjin Kim. > - Fix memory leak when allocating and assigning exynos_iommu_owner to > client > device if the client device has multiple System MMUs. > Thanks to Rahul Sharma. > > v3: > - Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12) > - Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12) > Thanks to Prathyush. > > v2: > - Split the patch to iommu/exynos into 9 patches > - Support for System MMU 3.3 > - Some code compaction > > Patch summary: > [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed > pagetable entries > [PATCH v6 02/12] iommu/exynos: always use iommu fault handler > [PATCH v6 03/12] iommu/exynos: allocate lv2 page table from own slab > [PATCH v6 04/12] iommu/exynos: change rwlock to spinlock > [PATCH v6 05/12] iommu/exynos: support for device tree > [PATCH v6 06/12] iommu/exynos: set System MMU as the parent of client > device > [PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from > exynos tree > [PATCH v6 08/12] iommu/exynos: add support for runtime pm and > suspend/resume > [PATCH v6 09/12] iommu/exynos: add support for System MMU 3.2 and 3.3 > [PATCH v6 10/12] iommu/exynos: pass version information from DT > [PATCH v6 11/12] iommu/exynos: add literal name of System MMU for > debugging > [PATCH v6 12/12] iommu/exynos: add debugfs entries for System MMU > > Diffstats: > arch/arm/boot/dts/exynos5250-smdk5250.dts |2 +- > arch/arm/boot/dts/exynos5250.dtsi | 27 +- > arch/arm/mach-exynos/Kconfig |5 - > arch/arm/mach-exynos/Makefile |1 - > arch/arm/mach-exynos/clock-exynos4.c | 41 +- > arch/arm/mach-exynos/clock-exynos4210.c|9 +- > arch/arm/mach-exynos/clock-exynos4212.c| 23 +- > arch/arm/mach-exynos/clock-exynos5.c | 87 +- > arch/arm/mach-exynos/dev-sysmmu.c | 274 -- > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 -- > arch/arm/mach-exynos/mach-exynos4-dt.c | 34 + > arch/arm/mach-exynos/mach-exynos5-dt.c | 30 + > drivers/iommu/Kconfig |2 +- > drivers/iommu/Makefile |2 +- > drivers/iommu/exynos-iommu.c | 1477 +-- > - > 15 files changed, 1284 insertions(+), 796 deletions(-) Looks OK to me, and some guys tested this series on board. Joerg, it's time to merge this. If you don't mind, let me pick up this whole series into Samsung tree because this touches many Samsung stuff. Any problems/comments on this, let me know. Happy new year, thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] uprobes: Move alloc_page() from xol_add_vma() to xol_alloc_area()
Move alloc_page() from xol_add_vma() to xol_alloc_area() to cleanup
the code. This separates the memory allocations and consolidates the
-EALREADY cleanups and the error handling.
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 32 +---
1 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index f883813..1456f7d 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1041,22 +1041,14 @@ void uprobe_munmap(struct vm_area_struct *vma, unsigned
long start, unsigned lon
/* Slot allocation for XOL */
static int xol_add_vma(struct xol_area *area)
{
- struct mm_struct *mm;
- int ret;
-
- area->page = alloc_page(GFP_HIGHUSER);
- if (!area->page)
- return -ENOMEM;
-
- ret = -EALREADY;
- mm = current->mm;
+ struct mm_struct *mm = current->mm;
+ int ret = -EALREADY;
down_write(&mm->mmap_sem);
if (mm->uprobes_state.xol_area)
goto fail;
ret = -ENOMEM;
-
/* Try to map as high as possible, this is only a hint. */
area->vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE,
0, 0);
if (area->vaddr & ~PAGE_MASK) {
@@ -1072,11 +1064,8 @@ static int xol_add_vma(struct xol_area *area)
smp_wmb(); /* pairs with get_xol_area() */
mm->uprobes_state.xol_area = area;
ret = 0;
-
-fail:
+ fail:
up_write(&mm->mmap_sem);
- if (ret)
- __free_page(area->page);
return ret;
}
@@ -1104,21 +1093,26 @@ static struct xol_area *xol_alloc_area(void)
area = kzalloc(sizeof(*area), GFP_KERNEL);
if (unlikely(!area))
- return NULL;
+ goto out;
area->bitmap = kzalloc(BITS_TO_LONGS(UINSNS_PER_PAGE) * sizeof(long),
GFP_KERNEL);
-
if (!area->bitmap)
- goto fail;
+ goto free_area;
+
+ area->page = area->page = alloc_page(GFP_HIGHUSER);
+ if (!area->page)
+ goto free_bitmap;
init_waitqueue_head(&area->wq);
if (!xol_add_vma(area))
return area;
-fail:
+ __free_page(area->page);
+ free_bitmap:
kfree(area->bitmap);
+ free_area:
kfree(area);
-
+ out:
return get_xol_area(current->mm);
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] uprobes: Kill the bogus IS_ERR_VALUE(xol_vaddr) check
utask->xol_vaddr is either zero or valid, remove the bogus IS_ERR_VALUE() check in xol_free_insn_slot(). Signed-off-by: Oleg Nesterov --- kernel/events/uprobes.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index ad1245d..ed4fcbe 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -1223,8 +1223,7 @@ static void xol_free_insn_slot(struct task_struct *tsk) return; slot_addr = tsk->utask->xol_vaddr; - - if (unlikely(!slot_addr || IS_ERR_VALUE(slot_addr))) + if (unlikely(!slot_addr)) return; area = tsk->mm->uprobes_state.xol_area; -- 1.5.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] uprobes: Do not allocate current->utask unnecessary
handle_swbp() does get_utask() before can_skip_sstep() for no reason,
we do not need ->utask if can_skip_sstep() succeeds.
Move get_utask() to pre_ssout() who actually starts to use it. Move
the initialization of utask->active_uprobe/state as well. This way
the whole initialization is consolidated in pre_ssout().
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index bd94d2c..ad1245d 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1308,7 +1308,9 @@ pre_ssout(struct uprobe *uprobe, struct pt_regs *regs,
unsigned long bp_vaddr)
unsigned long xol_vaddr;
int err;
- utask = current->utask;
+ utask = get_utask();
+ if (!utask)
+ return -ENOMEM;
xol_vaddr = xol_get_insn_slot(uprobe);
if (!xol_vaddr)
@@ -1323,6 +1325,8 @@ pre_ssout(struct uprobe *uprobe, struct pt_regs *regs,
unsigned long bp_vaddr)
return err;
}
+ utask->active_uprobe = uprobe;
+ utask->state = UTASK_SSTEP;
return 0;
}
@@ -1474,7 +1478,6 @@ static void handler_chain(struct uprobe *uprobe, struct
pt_regs *regs)
*/
static void handle_swbp(struct pt_regs *regs)
{
- struct uprobe_task *utask;
struct uprobe *uprobe;
unsigned long bp_vaddr;
int uninitialized_var(is_swbp);
@@ -1512,19 +1515,12 @@ static void handle_swbp(struct pt_regs *regs)
if (unlikely(!test_bit(UPROBE_COPY_INSN, &uprobe->flags)))
goto out;
- utask = get_utask();
- if (!utask)
- goto out; /* re-execute the instruction. */
-
handler_chain(uprobe, regs);
if (can_skip_sstep(uprobe, regs))
goto out;
- if (!pre_ssout(uprobe, regs, bp_vaddr)) {
- utask->active_uprobe = uprobe;
- utask->state = UTASK_SSTEP;
+ if (!pre_ssout(uprobe, regs, bp_vaddr))
return;
- }
/* can_skip_sstep() succeeded, or restart if can't singlestep */
out:
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] uprobes: Do not play with utask in xol_get_insn_slot()
pre_ssout()->xol_get_insn_slot() path is confusing and buggy. This patch
cleanups the code, the next one fixes the bug.
Change xol_get_insn_slot() to only allocate the slot and do nothing more,
move the initialization of utask->xol_vaddr/vaddr into pre_ssout().
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 37 +
1 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index b09b3ba..2ed6239 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1176,30 +1176,26 @@ static unsigned long xol_take_insn_slot(struct xol_area
*area)
}
/*
- * xol_get_insn_slot - If was not allocated a slot, then
- * allocate a slot.
+ * xol_get_insn_slot - allocate a slot for xol.
* Returns the allocated slot address or 0.
*/
-static unsigned long xol_get_insn_slot(struct uprobe *uprobe, unsigned long
slot_addr)
+static unsigned long xol_get_insn_slot(struct uprobe *uprobe)
{
struct xol_area *area;
unsigned long offset;
+ unsigned long xol_vaddr;
void *vaddr;
area = get_xol_area();
if (!area)
return 0;
- current->utask->xol_vaddr = xol_take_insn_slot(area);
- /*
-* Initialize the slot if xol_vaddr points to valid
-* instruction slot.
-*/
- if (unlikely(!current->utask->xol_vaddr))
+ xol_vaddr = xol_take_insn_slot(area);
+ if (unlikely(!xol_vaddr))
return 0;
- current->utask->vaddr = slot_addr;
- offset = current->utask->xol_vaddr & ~PAGE_MASK;
+ /* Initialize the slot */
+ offset = xol_vaddr & ~PAGE_MASK;
vaddr = kmap_atomic(area->page);
memcpy(vaddr + offset, uprobe->arch.insn, MAX_UINSN_BYTES);
kunmap_atomic(vaddr);
@@ -1209,7 +1205,7 @@ static unsigned long xol_get_insn_slot(struct uprobe
*uprobe, unsigned long slot
*/
flush_dcache_page(area->page);
- return current->utask->xol_vaddr;
+ return xol_vaddr;
}
/*
@@ -1306,12 +1302,21 @@ static struct uprobe_task *get_utask(void)
/* Prepare to single-step probed instruction out of line. */
static int
-pre_ssout(struct uprobe *uprobe, struct pt_regs *regs, unsigned long vaddr)
+pre_ssout(struct uprobe *uprobe, struct pt_regs *regs, unsigned long bp_vaddr)
{
- if (xol_get_insn_slot(uprobe, vaddr) &&
!arch_uprobe_pre_xol(&uprobe->arch, regs))
- return 0;
+ struct uprobe_task *utask;
+ unsigned long xol_vaddr;
+
+ utask = current->utask;
+
+ xol_vaddr = xol_get_insn_slot(uprobe);
+ if (!xol_vaddr)
+ return -ENOMEM;
+
+ utask->xol_vaddr = xol_vaddr;
+ utask->vaddr = bp_vaddr;
- return -EFAULT;
+ return arch_uprobe_pre_xol(&uprobe->arch, regs);
}
/*
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] uprobes: Fix utask->xol_vaddr leak in pre_ssout()
pre_ssout() should do xol_free_insn_slot() if arch_uprobe_pre_xol()
fails, otherwise nobody will free the allocated slot.
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 2ed6239..bd94d2c 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1306,6 +1306,7 @@ pre_ssout(struct uprobe *uprobe, struct pt_regs *regs,
unsigned long bp_vaddr)
{
struct uprobe_task *utask;
unsigned long xol_vaddr;
+ int err;
utask = current->utask;
@@ -1316,7 +1317,13 @@ pre_ssout(struct uprobe *uprobe, struct pt_regs *regs,
unsigned long bp_vaddr)
utask->xol_vaddr = xol_vaddr;
utask->vaddr = bp_vaddr;
- return arch_uprobe_pre_xol(&uprobe->arch, regs);
+ err = arch_uprobe_pre_xol(&uprobe->arch, regs);
+ if (unlikely(err)) {
+ xol_free_insn_slot(current);
+ return err;
+ }
+
+ return 0;
}
/*
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] uprobes: Turn add_utask() into get_utask()
Rename add_utask() into get_utask() and change it to allocate on
demand to simplify the caller. Like get_xol_area() it will have
more users.
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 27 +--
1 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index ef81162..b09b3ba 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1290,23 +1290,18 @@ void uprobe_copy_process(struct task_struct *t)
}
/*
- * Allocate a uprobe_task object for the task.
- * Called when the thread hits a breakpoint for the first time.
+ * Allocate a uprobe_task object for the task if if necessary.
+ * Called when the thread hits a breakpoint.
*
* Returns:
* - pointer to new uprobe_task on success
* - NULL otherwise
*/
-static struct uprobe_task *add_utask(void)
+static struct uprobe_task *get_utask(void)
{
- struct uprobe_task *utask;
-
- utask = kzalloc(sizeof *utask, GFP_KERNEL);
- if (unlikely(!utask))
- return NULL;
-
- current->utask = utask;
- return utask;
+ if (!current->utask)
+ current->utask = kzalloc(sizeof(struct uprobe_task),
GFP_KERNEL);
+ return current->utask;
}
/* Prepare to single-step probed instruction out of line. */
@@ -1505,13 +1500,9 @@ static void handle_swbp(struct pt_regs *regs)
if (unlikely(!test_bit(UPROBE_COPY_INSN, &uprobe->flags)))
goto out;
- utask = current->utask;
- if (!utask) {
- utask = add_utask();
- /* Cannot allocate; re-execute the instruction. */
- if (!utask)
- goto out;
- }
+ utask = get_utask();
+ if (!utask)
+ goto out; /* re-execute the instruction. */
handler_chain(uprobe, regs);
if (can_skip_sstep(uprobe, regs))
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] uprobes: alloc utask/xol_area cleanups and minor fix
Hello. This series fixes the minor bug and cleanups the usage of add_utask() and xol_alloc_area(). Plus it cleanups the initializaion of ->utask in handle_swbp() paths. Anton, this conflicts with your uretprobe patches, but I think we should do this to avoid the code duplication. IOW, I consider this series as a minor preparations for uretprobes as well. Oleg. kernel/events/uprobes.c | 150 +-- 1 files changed, 68 insertions(+), 82 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] uprobes: Fold xol_alloc_area() into get_xol_area()
Currently only xol_get_insn_slot() does get_xol_area() + xol_alloc_area(),
but this will have more users and we do not want to copy-and-paste this
code. This patch simply moves xol_alloc_area() into get_xol_area() to
simplify the current and future code.
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 38 --
1 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 1456f7d..ef81162 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1070,27 +1070,21 @@ static int xol_add_vma(struct xol_area *area)
return ret;
}
-static struct xol_area *get_xol_area(struct mm_struct *mm)
-{
- struct xol_area *area;
-
- area = mm->uprobes_state.xol_area;
- smp_read_barrier_depends(); /* pairs with wmb in xol_add_vma() */
-
- return area;
-}
-
/*
- * xol_alloc_area - Allocate process's xol_area.
- * This area will be used for storing instructions for execution out of
- * line.
+ * get_alloc_area - Allocate process's xol_area if necessary.
+ * This area will be used for storing instructions for execution out of line.
*
* Returns the allocated area or NULL.
*/
-static struct xol_area *xol_alloc_area(void)
+static struct xol_area *get_xol_area(void)
{
+ struct mm_struct *mm = current->mm;
struct xol_area *area;
+ area = mm->uprobes_state.xol_area;
+ if (area)
+ goto ret;
+
area = kzalloc(sizeof(*area), GFP_KERNEL);
if (unlikely(!area))
goto out;
@@ -1113,7 +1107,10 @@ static struct xol_area *xol_alloc_area(void)
free_area:
kfree(area);
out:
- return get_xol_area(current->mm);
+ area = mm->uprobes_state.xol_area;
+ ret:
+ smp_read_barrier_depends(); /* pairs with wmb in xol_add_vma() */
+ return area;
}
/*
@@ -1189,14 +1186,11 @@ static unsigned long xol_get_insn_slot(struct uprobe
*uprobe, unsigned long slot
unsigned long offset;
void *vaddr;
- area = get_xol_area(current->mm);
- if (!area) {
- area = xol_alloc_area();
- if (!area)
- return 0;
- }
- current->utask->xol_vaddr = xol_take_insn_slot(area);
+ area = get_xol_area();
+ if (!area)
+ return 0;
+ current->utask->xol_vaddr = xol_take_insn_slot(area);
/*
* Initialize the slot if xol_vaddr points to valid
* instruction slot.
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: prevent *.dtb from always being rebuilt
On 12/31/2012 10:39 AM, Stephen Warren wrote: > On 12/29/2012 10:32 PM, Olof Johansson wrote: >> On Fri, Dec 28, 2012 at 05:42:46PM -0700, Stephen Warren wrote: >>> From: Stephen Warren >>> >>> if_changed (used by the *.dts->*.dtc rule) rebuilds files if they aren't >>> contained in $(targets). (make V=2 indicates this). Add $(dtb-y) to >>> $(targets) to prevent *.dtb from always being rebuilt. >>> >>> This fixes a regression introduced by the .dtb rule rework in 499cd82 >>> "ARM: dt: change .dtb build rules to build in dts directory". >>> >>> Reported-by: Shawn Guo >>> Signed-off-by: Stephen Warren >> >> Not sure who you have in mind to apply this, but if it's not through arm-soc: >> >> Acked-by: Olof Johansson > > I was assuming through the device tree tree, since that's where the dtc > rule rework went through, but I think it's mostly just about whoever > picks it up:-) > I'll pick up both. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: prevent *.dtb from always being rebuilt
On 12/29/2012 10:32 PM, Olof Johansson wrote: > On Fri, Dec 28, 2012 at 05:42:46PM -0700, Stephen Warren wrote: >> From: Stephen Warren >> >> if_changed (used by the *.dts->*.dtc rule) rebuilds files if they aren't >> contained in $(targets). (make V=2 indicates this). Add $(dtb-y) to >> $(targets) to prevent *.dtb from always being rebuilt. >> >> This fixes a regression introduced by the .dtb rule rework in 499cd82 >> "ARM: dt: change .dtb build rules to build in dts directory". >> >> Reported-by: Shawn Guo >> Signed-off-by: Stephen Warren > > Not sure who you have in mind to apply this, but if it's not through arm-soc: > > Acked-by: Olof Johansson I was assuming through the device tree tree, since that's where the dtc rule rework went through, but I think it's mostly just about whoever picks it 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/
Re: [PATCH v2 2/3] mm: Update file times when inodes are written after mmaped writes
On Sat 22-12-12 00:43:30, Andy Lutomirski wrote: > On Sat, Dec 22, 2012 at 12:29 AM, Christoph Hellwig > wrote: > > NAK, we went through great trouble to get rid of the nasty layering > > violation where the VM called file_update_time directly just a short > > while ago, reintroducing that is a massive step back. > > > > Make sure whatever "solution" for your problem you come up with keeps > > the file update in the filesystem or generic helpers. > > > There's an inode operation ->update_time that is called (if it exists) > in these patches to update the time. Is that insufficient? Filesystems need more choice in when they modify time stamps because that can mean complex work like starting a transaction which has various locking implications. Just making a separate callback for this doesn't really solve the problem. Although I don't see particular problem with the call sites you chose Christoph is right we probably don't want to reintroduce updates of time stamps from generic code because eventually someone will have problem with that. > I could add a new inode operation ->modified_by_mmap that would be > called in mapping_flush_cmtime if that would be better. Not really. That's only uglier ;) > The original version of this patch did the update in ->writepage and > ->writepages, but that may have had lock ordering issues. (I wasn't > able to confirm that there was any actual problem.) Well, your call of mapping_flush_cmtime() from do_writepages() is easy to move to generic_writepages(). Thus filesystem can easily implement it's own ->writepages() callback if time update doesn't suit it. With the call from remove_vma() it is more problematic (and the calling context there is harder as well because we hold mmap_sem). We could maybe leave the call upto filesystem's ->release callback (and provide generic ->release handler which just calls mapping_flush_cmtime()). It won't be perfect because that gets called only after the last file descriptor for that struct file is closed (i.e., if a process forks and child inherits mappings, ->release gets called only after both parent and the child unmap the file) but it should catch 99% of the real world cases. Christoph, would the be OK with you? Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] prctl: fix validation of an address
On Mon, Dec 31, 2012 at 10:20:47AM -0500, Eric Paris wrote: > > Is there anything which prevents an unpriv application from changing > mm.mm_start_code and mm.mm_end_code in the image, thus taking advantage > of the privileged restore code to bypass the mmap_min_addr > restrictions? Well, you can assign some values in image directly (note the crtools is running with root priveleges and image files have appropriate owner:group) because image format is opened and well known from crtools source code or from protobufer files we use to descibe the entries in image. Thus it's assumed that administrator/root guarantee that images are not modified after checkpoint (image signing, checksumming and such). Also note the members being assigned in this prctl call are not critical but rather used for statistics output in procfs as far as I remember. Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] prctl: fix validation of an address
On Mon, 2012-12-31 at 19:13 +0400, Cyrill Gorcunov wrote: > On Mon, Dec 31, 2012 at 09:27:14AM -0500, Eric Paris wrote: > > On Mon, 2012-12-31 at 14:14 +0400, Andrew Vagin wrote: > > > On Sun, Dec 30, 2012 at 05:03:07PM -0500, Eric Paris wrote: > > > > On Sat, 2012-12-29 at 15:00 +0400, Andrey Vagin wrote: > > > > > The address should be bigger than dac_mmap_min_addr, because > > > > > a process with CAP_RAWIO can map a vma bellow mmap_min_addr. > > > > > > > > NAK > > > > > > Currently prctl(PR_SET_MM_*, addr, ) returns EINVAL for valid addresses. > > > I think it's a bug. Are you agree? > > > > Can you help me understand how prctl(PR_SET_MM_*, relates to > > checkpoint/restore? My worry here is that somehow this interface could > > Here how we use it (from userspace code) > > ret |= sys_prctl_safe(PR_SET_MM, PR_SET_MM_START_CODE, > (long)args->mm.mm_start_code, 0); > ret |= sys_prctl_safe(PR_SET_MM, PR_SET_MM_END_CODE, > (long)args->mm.mm_end_code, 0); > ... > > the values of mm.mm_start_code and such are saved in image file and obtained > during checkpoint stage. Note the prctl_set_mm requires the caller to have > CAP_SYS_RESOURCE privilege granted. Is there anything which prevents an unpriv application from changing mm.mm_start_code and mm.mm_end_code in the image, thus taking advantage of the privileged restore code to bypass the mmap_min_addr restrictions? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/14] atm: Removed redundant check on unsigned variable
Acked-by: chas williams - CONTRACTOR
On Fri, 28 Dec 2012 10:46:36 +0530
Tushar Behera wrote:
> Ping.
>
> On 11/16/2012 12:20 PM, Tushar Behera wrote:
> > No need to check whether unsigned variable is less than 0.
> >
> > CC: Chas Williams
> > CC: linux-atm-gene...@lists.sourceforge.net
> > CC: net...@vger.kernel.org
> > Signed-off-by: Tushar Behera
> > ---
> > drivers/atm/fore200e.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
> > index 361f5ae..fdd3fe7 100644
> > --- a/drivers/atm/fore200e.c
> > +++ b/drivers/atm/fore200e.c
> > @@ -972,7 +972,7 @@ int bsq_audit(int where, struct host_bsq* bsq, int
> > scheme, int magn)
> >where, scheme, magn, buffer->index, buffer->scheme);
> > }
> >
> > - if ((buffer->index < 0) || (buffer->index >= fore200e_rx_buf_nbr[
> > scheme ][ magn ])) {
> > + if (buffer->index >= fore200e_rx_buf_nbr[ scheme ][ magn ]) {
> > printk(FORE200E "bsq_audit(%d): queue %d.%d, out of range buffer
> > index = %ld !\n",
> >where, scheme, magn, buffer->index);
> > }
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] prctl: fix validation of an address
On Mon, Dec 31, 2012 at 09:27:14AM -0500, Eric Paris wrote: > On Mon, 2012-12-31 at 14:14 +0400, Andrew Vagin wrote: > > On Sun, Dec 30, 2012 at 05:03:07PM -0500, Eric Paris wrote: > > > On Sat, 2012-12-29 at 15:00 +0400, Andrey Vagin wrote: > > > > The address should be bigger than dac_mmap_min_addr, because > > > > a process with CAP_RAWIO can map a vma bellow mmap_min_addr. > > > > > > NAK > > > > Currently prctl(PR_SET_MM_*, addr, ) returns EINVAL for valid addresses. > > I think it's a bug. Are you agree? > > Can you help me understand how prctl(PR_SET_MM_*, relates to > checkpoint/restore? My worry here is that somehow this interface could Here how we use it (from userspace code) ret |= sys_prctl_safe(PR_SET_MM, PR_SET_MM_START_CODE, (long)args->mm.mm_start_code, 0); ret |= sys_prctl_safe(PR_SET_MM, PR_SET_MM_END_CODE, (long)args->mm.mm_end_code, 0); ... the values of mm.mm_start_code and such are saved in image file and obtained during checkpoint stage. Note the prctl_set_mm requires the caller to have CAP_SYS_RESOURCE privilege granted. > be used to bypass the security properties of mmap_min_addr.I have no > idea how the interface is used, so I don't know if my fears are founded. > When I hear 'restore' I think of a privileged application setting up > some unprivileged application based on untrusted data. My fear is that > some unpriv application, that doesn't have permission to map below > mmap_min_addr, may be able to trick the privileged application, which > would have this permission, into doing it on its behalf. Does that make > sense? Is that a realistic scenario with how this interface is used? > > > CONFIG_LSM_MMAP_MIN_ADDR could not be got from user space. > > > > This application can use a real value of mmap_min_addr, but it is not > > provided into userspace. > > Unrelated to this patch issue, but I guess either could be exposed if > there is a need. > > > Currently a task can have user memory area bellow dac_mmap_min_addr, > > but prctl returns -EINVAL for such addresses. > > How can I understand the reason, if I know that the address is valid? > > Talking about dac_mmap_min_addr is wrong. The capabilities security > module uses dac_mmap_min_addr but other LSMs can (and obviously do) use > other things. mmap_min_addr is just the shorthand to make sure you > clear all hurdles. Breaking those hurdles up outside of the security > subsystem is wrong. > > The kernel makes the decision on what is valid via security_mmap_addr(). > Assuming there are no security fears of an untrusted application > tricking some priviledged application to set up these maps the answer is > just calling security_mmap_addr() instead of doing if(addr < > mmap_min_addr) return -EINVAL; If only I've not missed something obvious, the check for security_mmap_addr() here instead of poking the mmap_min_addr looks more correct for me. Andrew? > I don't know if it is a good idea to allow this interface to ever go > below mmap_min_addr, but I do know that using (or even thinking about) > dac_mmap_min_addr is wrong and you should be looking at > security_mmap_addr() if you look at anything... Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpuidle - fix lock contention in the idle path
On Sat, Dec 29, 2012 at 11:03:03AM +0100, Daniel Lezcano wrote:
>
> Hi Russ,
>
> Is it possible you try this patch on your 2048 cpus ?
Yes, I will try it later today.
Thanks
> Thanks
>
> -- Daniel
>
> On 12/26/2012 11:01 AM, Daniel Lezcano wrote:
> > The commit bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92 introduces
> > a lock in the cpuidle_get_cpu_driver function. This function
> > is used in the idle_call function.
> >
> > The problem is the contention with a large number of cpus because
> > they try to access the idle routine at the same time.
> >
> > The lock could be safely removed because of how is used the
> > cpuidle api. The cpuidle_register_driver is called first but
> > until the cpuidle_register_device is not called we don't
> > enter in the cpuidle idle call function because the device
> > is not enabled.
> >
> > The cpuidle_unregister_driver function, leading the a NULL driver,
> > is not called before the cpuidle_unregister_device.
> >
> > This is how is used the cpuidle api from the different drivers.
> >
> > However, a cleanup around the lock and a proper refcounting
> > mechanism should be used to ensure the consistency in the api,
> > like cpuidle_unregister_driver should failed if its refcounting
> > is not 0.
> >
> > These modifications will need some code reorganization and rewrite
> > which does not fit with a fix.
> >
> > The following patch is a hot fix by returning to the initial behavior
> > by removing the lock when getting the driver.
> >
> > Signed-off-by: Daniel Lezcano
> > ---
> > drivers/cpuidle/driver.c |8 +---
> > 1 file changed, 1 insertion(+), 7 deletions(-)
> >
> > diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> > index 3af841f..c2b281a 100644
> > --- a/drivers/cpuidle/driver.c
> > +++ b/drivers/cpuidle/driver.c
> > @@ -235,16 +235,10 @@ EXPORT_SYMBOL_GPL(cpuidle_get_driver);
> > */
> > struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
> > {
> > - struct cpuidle_driver *drv;
> > -
> > if (!dev)
> > return NULL;
> >
> > - spin_lock(&cpuidle_driver_lock);
> > - drv = __cpuidle_get_cpu_driver(dev->cpu);
> > - spin_unlock(&cpuidle_driver_lock);
> > -
> > - return drv;
> > + return __cpuidle_get_cpu_driver(dev->cpu);
> > }
> > EXPORT_SYMBOL_GPL(cpuidle_get_cpu_driver);
> >
> >
>
>
> --
> Facebook |
> Twitter |
>
Regression: Bacula jobs fail with kernel 3.8-rc1
With kernel 3.8-rc1, my nightly Bacula backup job reproducibly aborts 20 minutes into spooling with a "broken pipe" error on the network socket connecting the file and storage daemons: 31-Dec 00:45 xenon-sd JobId 859: Spooling data ... 31-Dec 01:04 xenon-fd JobId 859: Error: bsock.c:429 Write error sending 65536 bytes to Storage daemon:xenon:9103: ERR=Broken pipe 31-Dec 01:04 xenon-fd JobId 859: Fatal error: backup.c:1200 Network send error to SD. ERR=Broken pipe 31-Dec 01:04 xenon-dir JobId 859: Error: Director's comm line to SD dropped. Returning to kernel 3.7.1 makes it work again. (Provided the crash I reported in http://marc.info/?l=linux-kernel&m=135337052232021&w=2 doesn't hit, of course.) Configuration: Intel Pentium D, Intel DQ965GF mainboard, 6 GB RAM onboard S-ATA controller driving two 500 GB S-ATA disks and a Pioneer DVR-216D DVD-RW drive Adaptec 29160B Ultra160 SCSI adapter driving a Tandberg TS400 LTO-2 tape drive openSUSE 11.4 userspace Bacula 5.2.12, all daemons on the same machine, spooling to local disk Regards, Tilman -- Tilman SchmidtE-Mail: til...@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [PATCH] printk: Fix incorrect length from print_time() when seconds > 99999
Hi, >> Sylvan Munaut did something similar >> https://lkml.org/lkml/2012/12/5/168 > > Missed that and duplicated the debugging :( > Sorry Sylvain. I should have followed up on the patch sooner, but I basically finished testing it fixed all the issues and posted it just before leaving for vacation and I just got back (and didn't check my work email there). > I guess my patch may be preferable, since I happened to use the snprintf() > method that you suggest -- all the open-coded digit-counting seems a bit > verbose and perhaps hard to read and see the equivalence to the sprintf. Yes, I just did it that way to match the way if was done in other parts of that file in ... the snprintf method is clearly more readable. Cheers, Sylvain -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] prctl: fix validation of an address
On Mon, 2012-12-31 at 14:14 +0400, Andrew Vagin wrote: > On Sun, Dec 30, 2012 at 05:03:07PM -0500, Eric Paris wrote: > > On Sat, 2012-12-29 at 15:00 +0400, Andrey Vagin wrote: > > > The address should be bigger than dac_mmap_min_addr, because > > > a process with CAP_RAWIO can map a vma bellow mmap_min_addr. > > > > NAK > > Currently prctl(PR_SET_MM_*, addr, ) returns EINVAL for valid addresses. > I think it's a bug. Are you agree? Can you help me understand how prctl(PR_SET_MM_*, relates to checkpoint/restore? My worry here is that somehow this interface could be used to bypass the security properties of mmap_min_addr.I have no idea how the interface is used, so I don't know if my fears are founded. When I hear 'restore' I think of a privileged application setting up some unprivileged application based on untrusted data. My fear is that some unpriv application, that doesn't have permission to map below mmap_min_addr, may be able to trick the privileged application, which would have this permission, into doing it on its behalf. Does that make sense? Is that a realistic scenario with how this interface is used? > CONFIG_LSM_MMAP_MIN_ADDR could not be got from user space. > > This application can use a real value of mmap_min_addr, but it is not > provided into userspace. Unrelated to this patch issue, but I guess either could be exposed if there is a need. > Currently a task can have user memory area bellow dac_mmap_min_addr, > but prctl returns -EINVAL for such addresses. > How can I understand the reason, if I know that the address is valid? Talking about dac_mmap_min_addr is wrong. The capabilities security module uses dac_mmap_min_addr but other LSMs can (and obviously do) use other things. mmap_min_addr is just the shorthand to make sure you clear all hurdles. Breaking those hurdles up outside of the security subsystem is wrong. The kernel makes the decision on what is valid via security_mmap_addr(). Assuming there are no security fears of an untrusted application tricking some priviledged application to set up these maps the answer is just calling security_mmap_addr() instead of doing if(addr < mmap_min_addr) return -EINVAL; I don't know if it is a good idea to allow this interface to ever go below mmap_min_addr, but I do know that using (or even thinking about) dac_mmap_min_addr is wrong and you should be looking at security_mmap_addr() if you look at anything... -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pm-suspend not waking up properly
Hey, I used uswusp till now and it worked for my old HW configuration. Now I updated to a new I'm running Ubuntu 12.04 with a self-compiled Linux 3.7.0 kernel (uname -a): Linux linux 3.7.0-custom #2 SMP Sat Dec 22 15:07:12 CET 2012 x86_64 x86_64 x86_64 GNU/Linux Mainboard is (dmesg | grep Gigabyte): [0.00] DMI: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A85X-D3H, BIOS F1 10/09/2012 Processor is an AMD A4-5300 with a microcode update (cat /proc/cpuinfo): processor : 1 vendor_id : AuthenticAMD cpu family : 21 model : 16 model name : AMD A4-5300 APU with Radeon(tm) HD Graphics stepping: 1 microcode : 0x6001119 "s2ram" would not work with this mainboard anymore. I then used "s2ram -f -a 1" and that worked. Now s2ram is deprecated so I used "pm-suspend" but the PC doesnt wake up properly. Monitor is black, network is down but keyboard lights up when i press the CAPSLOCK button etc. So i took a log to see what happens when PC enters suspend mode: - Mon Dec 24 23:10:02 CET 2012: Running hooks for suspend. Running hook /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend: /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend: success. Running hook /usr/lib/pm-utils/sleep.d/00logging suspend suspend: Linux linux 3.7.0-custom #2 SMP Sat Dec 22 15:07:12 CET 2012 x86_64 x86_64 x86_64 GNU/Linux Module Size Used by xfs 885075 1 libcrc32c 12644 1 xfs ext2 72820 2 kvm_amd59833 0 kvm 443029 1 kvm_amd snd_hda_codec_hdmi 36804 1 snd_hda_intel 43738 0 snd_hda_codec 140017 2 snd_hda_codec_hdmi,snd_hda_intel snd_hwdep 13563 1 snd_hda_codec snd_pcm97486 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec snd_timer 29532 1 snd_pcm snd78958 6 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer soundcore 15047 1 snd snd_page_alloc 18710 2 snd_hda_intel,snd_pcm microcode 22893 0 i2c_piix4 13266 0 serio_raw 13215 0 k10temp13126 0 mac_hid13205 0 lp 17759 0 parport46354 1 lp dm_crypt 22800 7 pata_jmicron 12758 0 ghash_clmulni_intel13259 0 aesni_intel55399 15 ablk_helper13597 1 aesni_intel cryptd 20360 10 ghash_clmulni_intel,aesni_intel,ablk_helper lrw13286 1 aesni_intel aes_x86_64 17255 1 aesni_intel xts12914 1 aesni_intel gf128mul 14951 2 lrw,xts radeon929563 1 r8169 67571 0 ttm83223 1 radeon drm_kms_helper 49196 1 radeon drm 280816 3 radeon,ttm,drm_kms_helper i2c_algo_bit 13413 1 radeon total used free sharedbuffers cached Mem: 34141163302128 111988 0 131442664148 -/+ buffers/cache: 6248362789280 Swap: 1953788 01953788 /usr/lib/pm-utils/sleep.d/00logging suspend suspend: success. Running hook /usr/lib/pm-utils/sleep.d/00powersave suspend suspend: /usr/lib/pm-utils/sleep.d/00powersave suspend suspend: success. Running hook /etc/pm/sleep.d/10_grub-common suspend suspend: /etc/pm/sleep.d/10_grub-common suspend suspend: success. Running hook /etc/pm/sleep.d/10_unattended-upgrades-hibernate suspend suspend: /etc/pm/sleep.d/10_unattended-upgrades-hibernate suspend suspend: success. Running hook /usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: Having NetworkManager put all interaces to sleep...Failed. /usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: success. Running hook /usr/lib/pm-utils/sleep.d/75modules suspend suspend: /usr/lib/pm-utils/sleep.d/75modules suspend suspend: not applicable. Running hook /usr/lib/pm-utils/sleep.d/90clock suspend suspend: /usr/lib/pm-utils/sleep.d/90clock suspend suspend: not applicable. Running hook /usr/lib/pm-utils/sleep.d/94cpufreq suspend suspend: /usr/lib/pm-utils/sleep.d/94cpufreq suspend suspend: success. Running hook /usr/lib/pm-utils/sleep.d/95hdparm-apm suspend suspend: /usr/lib/pm-utils/sleep.d/95hdparm-apm suspend suspend: not applicable. Running hook /usr/lib/pm-utils/sleep.d/95led suspend suspend: /usr/lib/pm-utils/sleep.d/95led suspend suspend: not applicable. Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend: Kernel modesetting video driver detected, not using quirks. /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend: success. Running hook /usr/lib/pm-utils/sleep.d/99video suspend suspend: kernel.acpi_video_flags = 0 /usr/lib/pm-utils/sleep.d/99video suspend suspend: success. Mon Dec 24 23:10:03 CET 2012: performing suspend Can someon
[PATCH] poll: prevent missed events if _qproc is NULL
This patch seems to fix my issue with ppoll() being stuck on my
SMP machine: http://article.gmane.org/gmane.linux.file-systems/70414
The change to sock_poll_wait() in
commit 626cf236608505d376e4799adb4f7eb00a8594af
(poll: add poll_requested_events() and poll_does_not_wait() functions)
seems to have allowed additional cases where the SMP memory barrier
is not issued before checking for readiness.
In my case, this affects the select()-family of functions
which register descriptors once and set _qproc to NULL before
checking events again (after poll_schedule_timeout() returns).
The set_mb() barrier in poll_schedule_timeout() appears to be
insufficient on my SMP x86-64 machine (as it's only an xchg()).
This may also be related to the epoll issue described by
Andreas Voellmy in http://thread.gmane.org/gmane.linux.kernel/1408782/
Signed-off-by: Eric Wong
Cc: Hans Verkuil
Cc: Jiri Olsa
Cc: Jonathan Corbet
Cc: Al Viro
Cc: Davide Libenzi
Cc: Hans de Goede
Cc: Mauro Carvalho Chehab
Cc: David Miller
Cc: Eric Dumazet
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Andreas Voellmy
Cc: "Junchang(Jason) Wang"
Cc: net...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
---
If this patch is correct, I think we can just drop the
poll_does_not_wait() function entirely since poll_wait()
does the same check anyways...
include/net/sock.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index c945fba..1923e48 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1925,8 +1925,9 @@ static inline bool wq_has_sleeper(struct socket_wq *wq)
static inline void sock_poll_wait(struct file *filp,
wait_queue_head_t *wait_address, poll_table *p)
{
- if (!poll_does_not_wait(p) && wait_address) {
- poll_wait(filp, wait_address, p);
+ if (wait_address) {
+ if (!poll_does_not_wait(p))
+ poll_wait(filp, wait_address, p);
/* We need to be sure we are in sync with the
* socket flags modification.
*
--
Eric Wong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] leds: leds-gpio: set devm_gpio_request_one() flags correctly
On 12/21/2012 06:06 PM, Ezequiel Garcia wrote:
> On Fri, Dec 21, 2012 at 12:07 PM, Javier Martinez Canillas
> wrote:
>> commit a99d76f leds: leds-gpio: use gpio_request_one
>>
>> changed the leds-gpio driver to use gpio_request_one() instead
>> of gpio_request() + gpio_direction_output()
>>
>> Unfortunately, it also made a semantic change that breaks the
>> leds-gpio driver.
>>
>> The gpio_request_one() flags parameter was set to:
>>
>> GPIOF_DIR_OUT | (led_dat->active_low ^ state)
>>
>> Since GPIOF_DIR_OUT is 0, the final flags value will just be the
>> XOR'ed value of led_dat->active_low and state.
>>
>> This value were used to distinguish between HIGH/LOW output initial
>> level and call gpio_direction_output() accordingly.
>>
>> With this new semantic gpio_request_one() will take the flags value
>> of 1 as a configuration of input direction (GPIOF_DIR_IN) and will
>> call gpio_direction_input() instead of gpio_direction_output().
>>
>> int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
>> {
>> ..
>> if (flags & GPIOF_DIR_IN)
>> err = gpio_direction_input(gpio);
>> else
>> err = gpio_direction_output(gpio,
>> (flags & GPIOF_INIT_HIGH) ? 1 : 0);
>> ..
>> }
>>
>> The right semantic is to evaluate led_dat->active_low ^ state and
>> set the output initial level explicitly.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>>
>> This makes LEDs to work again on my IGEPv2 board (TI OMAP3 based SoC).
>>
>> I sent this patch before but then realized that I only cc'ed to linux-leds.
>> So, I'm resending the patch cc'ing linux-omap,linux-arm-kernel and LKML to
>> reach a broader audience and have more people review/test the patch.
>>
>> Sorry for the noise if someone got it twice.
>>
>> drivers/leds/leds-gpio.c |5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
>> index 1885a26..a0d931b 100644
>> --- a/drivers/leds/leds-gpio.c
>> +++ b/drivers/leds/leds-gpio.c
>> @@ -127,8 +127,9 @@ static int create_gpio_led(const struct gpio_led
>> *template,
>> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>>
>> ret = devm_gpio_request_one(parent, template->gpio,
>> - GPIOF_DIR_OUT | (led_dat->active_low ^ state),
>> - template->name);
>> + (led_dat->active_low ^ state) ?
>> + GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
>> + template->name);
>> if (ret < 0)
>> return ret;
>>
>> --
>> 1.7.7.6
>>
>
> Without this patch my IGEP v2 LEDs were dead,
> and this patch brings them back.
>
> Tested-by: Ezequiel Garcia
>
> Thanks,
>
> Ezequiel
>
Hello,
Any news on this?
GPIO LEDs support is still not working on latest mainline kernel and other
people report that this patch solves the issue for them.
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] writeback: fix writeback cache thrashing
On Sun 30-12-12 14:59:50, Namjae Jeon wrote: > From: Namjae Jeon > > Consider Process A: huge I/O on sda > doing heavy write operation - dirty memory becomes more > than dirty_background_ratio > on HDD - flusher thread flush-8:0 > > Consider Process B: small I/O on sdb > doing while [1]; read 1024K + rewrite 1024K + sleep 2sec > on Flash device - flusher thread flush-8:16 > > As Process A is a heavy dirtier, dirty memory becomes more > than dirty_background_thresh. Due to this, below check becomes > true(checking global_page_state in over_bground_thresh) > for all bdi devices(even for very small dirtied bdi - sdb): > > In this case, even small cached data on 'sdb' is forced to flush > and writeback cache thrashing happens. > > When we added debug prints inside above 'if' condition and ran > above Process A(heavy dirtier on bdi with flush-8:0) and > Process B(1024K frequent read/rewrite on bdi with flush-8:16) > we got below prints: > > [Test setup: ARM dual core CPU, 512 MB RAM] > > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56064 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56704 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84720 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94720 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 384 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 960 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =64 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92160 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 256 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 768 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =64 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 256 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 320 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 0 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92032 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91968 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 192 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 1024 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =64 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 192 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 576 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 0 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84352 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 192 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 512 KB > [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 0 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92608 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92544 KB > > As mentioned in above log, when global dirty memory > global background_thresh > small cached data is also forced to flush by flush-8:16. > > If removing global background_thresh checking code, we can reduce cache > thrashing of frequently used small data. It's not completely clear to me: Why is this a problem? Wearing of the flash? Power consumption? I'd like to understand this before changing the code... > And It will be great if we can reserve a portion of writeback cache using > min_ratio. > > After applying patch: > $ echo 5 > /sys/block/sdb/bdi/min_ratio > $ cat /sys/block/sdb/bdi/min_ratio > 5 > > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56064 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56704 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84160 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 96960 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94080 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93120 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93120 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91520 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 89600 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93696 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93696 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 72960 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 90624 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 90624 KB > [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 90688 KB > > As mentioned in the above logs, once cache is reserved for Process B, > and patch is applied there is less writeback cache thrashing on sdb > by frequent forced writeback by flush-8:16 in over_bground_thresh. > > After all, small cached d
what's the return-value of regulator_get?
I repeat my question: the driver for lsm303dlh in the 3.5 kernel calls regulator_get(&client->dev, "vdd"); from that it got the return-value fdfb triggering IS_ERR(). but I cannot find any errorcode for -0x205. does anyone know the meaning of this error-code? P -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/10] mfd: twl-core: Clean up module id lookup and definitions
Use enums for all module definitions:
twl_module_ids for common functionality among twl4030/twl6030
twl4030_module_ids for twl4030 specific ids
twl6030_module_ids for twl6030 specific ids
In this way the list can be managed easier when new functionality going to
be implemented.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 105 +++-
include/linux/i2c/twl.h | 66 --
2 files changed, 86 insertions(+), 85 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 4f3baad..b781cdd 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -74,8 +74,6 @@
#define SUB_CHIP_ID3 3
#define SUB_CHIP_ID_INVAL 0xff
-#define TWL_MODULE_LAST TWL4030_MODULE_LAST
-
/* Base Address defns for twl4030_map[] */
/* subchip/slave 0 - USB ID */
@@ -94,10 +92,7 @@
#define TWL4030_BASEADD_MADC 0x
#define TWL4030_BASEADD_MAIN_CHARGE0x0074
#define TWL4030_BASEADD_PRECHARGE 0x00AA
-#define TWL4030_BASEADD_PWM0 0x00F8
-#define TWL4030_BASEADD_PWM1 0x00FB
-#define TWL4030_BASEADD_PWMA 0x00EF
-#define TWL4030_BASEADD_PWMB 0x00F1
+#define TWL4030_BASEADD_PWM0x00F8
#define TWL4030_BASEADD_KEYPAD 0x00D2
#define TWL5031_BASEADD_ACCESSORY 0x0074 /* Replaces Main Charge */
@@ -117,7 +112,7 @@
/* subchip/slave 0 0x48 - POWER */
#define TWL6030_BASEADD_RTC0x
-#define TWL6030_BASEADD_MEM0x0017
+#define TWL6030_BASEADD_SECURED_REG0x0017
#define TWL6030_BASEADD_PM_MASTER 0x001F
#define TWL6030_BASEADD_PM_SLAVE_MISC 0x0030 /* PM_RECEIVER */
#define TWL6030_BASEADD_PM_MISC0x00E2
@@ -132,6 +127,7 @@
#define TWL6030_BASEADD_PIH0x00D0
#define TWL6030_BASEADD_CHARGER0x00E0
#define TWL6025_BASEADD_CHARGER0x00DA
+#define TWL6030_BASEADD_LED0x00F4
/* subchip/slave 2 0x4A - DFT */
#define TWL6030_BASEADD_DIEID 0x00C0
@@ -188,34 +184,33 @@ static struct twl_mapping twl4030_map[] = {
* so they continue to match the order in this table.
*/
+ /* Common IPs */
{ 0, TWL4030_BASEADD_USB },
+ { 1, TWL4030_BASEADD_PIH },
+ { 2, TWL4030_BASEADD_MAIN_CHARGE },
+ { 3, TWL4030_BASEADD_PM_MASTER },
+ { 3, TWL4030_BASEADD_PM_RECEIVER },
+
+ { 3, TWL4030_BASEADD_RTC },
+ { 2, TWL4030_BASEADD_PWM },
+ { 2, TWL4030_BASEADD_LED },
+ { 3, TWL4030_BASEADD_SECURED_REG },
+
+ /* TWL4030 specific IPs */
{ 1, TWL4030_BASEADD_AUDIO_VOICE },
{ 1, TWL4030_BASEADD_GPIO },
{ 1, TWL4030_BASEADD_INTBR },
- { 1, TWL4030_BASEADD_PIH },
-
{ 1, TWL4030_BASEADD_TEST },
{ 2, TWL4030_BASEADD_KEYPAD },
+
{ 2, TWL4030_BASEADD_MADC },
{ 2, TWL4030_BASEADD_INTERRUPTS },
- { 2, TWL4030_BASEADD_LED },
-
- { 2, TWL4030_BASEADD_MAIN_CHARGE },
{ 2, TWL4030_BASEADD_PRECHARGE },
- { 2, TWL4030_BASEADD_PWM0 },
- { 2, TWL4030_BASEADD_PWM1 },
- { 2, TWL4030_BASEADD_PWMA },
-
- { 2, TWL4030_BASEADD_PWMB },
- { 2, TWL5031_BASEADD_ACCESSORY },
- { 2, TWL5031_BASEADD_INTERRUPTS },
{ 3, TWL4030_BASEADD_BACKUP },
{ 3, TWL4030_BASEADD_INT },
- { 3, TWL4030_BASEADD_PM_MASTER },
- { 3, TWL4030_BASEADD_PM_RECEIVER },
- { 3, TWL4030_BASEADD_RTC },
- { 3, TWL4030_BASEADD_SECURED_REG },
+ { 2, TWL5031_BASEADD_ACCESSORY },
+ { 2, TWL5031_BASEADD_INTERRUPTS },
};
static struct regmap_config twl4030_regmap_config[4] = {
@@ -251,35 +246,25 @@ static struct twl_mapping twl6030_map[] = {
* defines for TWL4030_MODULE_*
* so they continue to match the order in this table.
*/
- { SUB_CHIP_ID1, TWL6030_BASEADD_USB },
- { SUB_CHIP_ID_INVAL, TWL6030_BASEADD_AUDIO },
- { SUB_CHIP_ID2, TWL6030_BASEADD_DIEID },
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
- { SUB_CHIP_ID1, TWL6030_BASEADD_PIH },
-
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
- { SUB_CHIP_ID1, TWL6030_BASEADD_GPADC_CTRL },
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
-
- { SUB_CHIP_ID1, TWL6030_BASEADD_CHARGER },
- { SUB_CHIP_ID1, TWL6030_BASEADD_GASGAUGE },
- { SUB_CHIP_ID1, TWL6030_BASEADD_PWM },
- { SUB_CHIP_ID0, TWL6030_BASEADD_ZERO },
- { SUB_CHIP_ID1, TWL6030_BASEADD_ZERO },
-
- { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
- { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
- { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
-
- { SUB_CHIP_ID0, TWL6030_BASEADD_PM_MASTER },
- { SUB_CHIP_ID0, TWL6030_BASEADD_PM_SLAVE_MISC },
- { SUB_CHIP_ID0, TWL6030_BASEADD_RTC },
-
[PATCH 06/10] mfd: twl-core: Do not create dummy pdata when booted with DT
When booted with DT we can manage without the dummy pdata.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 31 +++
1 file changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 86cca9e..547fed5 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -1165,6 +1165,11 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
int status;
unsignedi, num_slaves;
+ if (!node && !pdata) {
+ dev_err(&client->dev, "no platform data\n");
+ return -EINVAL;
+ }
+
pdev = platform_device_alloc(DRIVER_NAME, -1);
if (!pdev) {
dev_err(&client->dev, "can't alloc pdev\n");
@@ -1177,28 +1182,6 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
return status;
}
- if (node && !pdata) {
- /*
-* XXX: Temporary pdata until the information is correctly
-* retrieved by every TWL modules from DT.
-*/
- pdata = devm_kzalloc(&client->dev,
-sizeof(struct twl4030_platform_data),
-GFP_KERNEL);
- if (!pdata) {
- status = -ENOMEM;
- goto free;
- }
- }
-
- if (!pdata) {
- dev_dbg(&client->dev, "no platform data?\n");
- status = -EINVAL;
- goto free;
- }
-
- platform_set_drvdata(pdev, pdata);
-
if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
dev_dbg(&client->dev, "can't talk I2C?\n");
status = -EIO;
@@ -1264,7 +1247,7 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
inuse = true;
/* setup clock framework */
- clocks_init(&pdev->dev, pdata->clock);
+ clocks_init(&pdev->dev, pdata ? pdata->clock : NULL);
/* read TWL IDCODE Register */
if (twl_id == TWL4030_CLASS_ID) {
@@ -1273,7 +1256,7 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
}
/* load power event scripts */
- if (IS_ENABLED(CONFIG_TWL4030_POWER) && pdata->power)
+ if (IS_ENABLED(CONFIG_TWL4030_POWER) && pdata && pdata->power)
twl4030_power_init(pdata->power);
/* Maybe init the T2 Interrupt subsystem */
--
1.8.0.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 07/10] mfd: twl-core: Move 'inuse' check early at probe time
We can fail earlier in case multiple instance of the twl-core is tried to
be loaded.
The twl-core by design only supports one instance.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 547fed5..1827088 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -1170,6 +1170,12 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
return -EINVAL;
}
+ if (inuse) {
+ dev_dbg(&client->dev, "only one instance of %s allowed\n",
+ DRIVER_NAME);
+ return -EBUSY;
+ }
+
pdev = platform_device_alloc(DRIVER_NAME, -1);
if (!pdev) {
dev_err(&client->dev, "can't alloc pdev\n");
@@ -1188,12 +1194,6 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
goto free;
}
- if (inuse) {
- dev_dbg(&client->dev, "driver is already in use\n");
- status = -EBUSY;
- goto free;
- }
-
if ((id->driver_data) & TWL6030_CLASS) {
twl_id = TWL6030_CLASS_ID;
twl_map = &twl6030_map[0];
--
1.8.0.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 08/10] mfd: twl-core: Collect global variables behind one private structure (global)
Gather the global variables under a single structure and allocate it with
devm_kzalloc(). It is easier to see them and if in the future we try to add
support for multiple instance of twl in the system it is going to be much
simpler.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 104 +++--
1 file changed, 57 insertions(+), 47 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 1827088..e2895a4 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -141,33 +141,28 @@
/*--*/
-/* is driver active, bound to a chip? */
-static bool inuse;
-
-/* TWL IDCODE Register value */
-static u32 twl_idcode;
-
-static unsigned int twl_id;
-unsigned int twl_rev(void)
-{
- return twl_id;
-}
-EXPORT_SYMBOL(twl_rev);
-
/* Structure for each TWL4030/TWL6030 Slave */
struct twl_client {
struct i2c_client *client;
struct regmap *regmap;
};
-static struct twl_client *twl_modules;
-
/* mapping the module id to slave id and base address */
struct twl_mapping {
unsigned char sid; /* Slave ID */
unsigned char base; /* base address */
};
-static struct twl_mapping *twl_map;
+
+struct twl_private {
+ bool ready; /* The core driver is ready to be used */
+ u32 twl_idcode; /* TWL IDCODE Register value */
+ unsigned int twl_id;
+
+ struct twl_mapping *twl_map;
+ struct twl_client *twl_modules;
+};
+
+static struct twl_private *twl_priv;
static struct twl_mapping twl4030_map[] = {
/*
@@ -300,6 +295,12 @@ static inline int twl_get_last_module(void)
/* Exported Functions */
+unsigned int twl_rev(void)
+{
+ return twl_priv ? twl_priv->twl_id : 0;
+}
+EXPORT_SYMBOL(twl_rev);
+
/**
* twl_i2c_write - Writes a n bit register in TWL4030/TWL5030/TWL60X0
* @mod_no: module number
@@ -322,16 +323,17 @@ int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes)
pr_err("%s: invalid module number %d\n", DRIVER_NAME, mod_no);
return -EPERM;
}
- if (unlikely(!inuse)) {
+ if (unlikely(!twl_priv->ready)) {
pr_err("%s: not initialized\n", DRIVER_NAME);
return -EPERM;
}
- sid = twl_map[mod_no].sid;
- twl = &twl_modules[sid];
+ sid = twl_priv->twl_map[mod_no].sid;
+ twl = &twl_priv->twl_modules[sid];
- ret = regmap_bulk_write(twl->regmap, twl_map[mod_no].base + reg,
- value, num_bytes);
+ ret = regmap_bulk_write(twl->regmap,
+ twl_priv->twl_map[mod_no].base + reg, value,
+ num_bytes);
if (ret)
pr_err("%s: Write failed (mod %d, reg 0x%02x count %d)\n",
@@ -360,16 +362,17 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes)
pr_err("%s: invalid module number %d\n", DRIVER_NAME, mod_no);
return -EPERM;
}
- if (unlikely(!inuse)) {
+ if (unlikely(!twl_priv->ready)) {
pr_err("%s: not initialized\n", DRIVER_NAME);
return -EPERM;
}
- sid = twl_map[mod_no].sid;
- twl = &twl_modules[sid];
+ sid = twl_priv->twl_map[mod_no].sid;
+ twl = &twl_priv->twl_modules[sid];
- ret = regmap_bulk_read(twl->regmap, twl_map[mod_no].base + reg,
- value, num_bytes);
+ ret = regmap_bulk_read(twl->regmap,
+ twl_priv->twl_map[mod_no].base + reg, value,
+ num_bytes);
if (ret)
pr_err("%s: Read failed (mod %d, reg 0x%02x count %d)\n",
@@ -425,7 +428,7 @@ static int twl_read_idcode_register(void)
goto fail;
}
- err = twl_i2c_read(TWL4030_MODULE_INTBR, (u8 *)(&twl_idcode),
+ err = twl_i2c_read(TWL4030_MODULE_INTBR, (u8 *)(&twl_priv->twl_idcode),
REG_IDCODE_7_0, 4);
if (err) {
pr_err("TWL4030: unable to read IDCODE -%d\n", err);
@@ -446,7 +449,7 @@ fail:
*/
int twl_get_type(void)
{
- return TWL_SIL_TYPE(twl_idcode);
+ return TWL_SIL_TYPE(twl_priv->twl_idcode);
}
EXPORT_SYMBOL_GPL(twl_get_type);
@@ -457,7 +460,7 @@ EXPORT_SYMBOL_GPL(twl_get_type);
*/
int twl_get_version(void)
{
- return TWL_SIL_REV(twl_idcode);
+ return TWL_SIL_REV(twl_priv->twl_idcode);
}
EXPORT_SYMBOL_GPL(twl_get_version);
@@ -506,8 +509,8 @@ add_numbered_child(unsigned mod_no, const char *name, int
num,
pr_err("%s: invalid module number %d\n", DRIVER_NAME, mod_no);
return ERR_PTR(-EPERM);
}
- sid = twl_map[mod_no].sid;
- twl = &twl_modules[sid];
+ sid = twl_priv->twl_map[mod_no].sid;
+ twl = &twl_priv->twl_modules[sid];
[PATCH 02/10] mfd: twl-core: No need to check for invalid subchip ID
The module id table no longer can have invalid/unused entries.
No need for checking the ID for validity.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index b781cdd..fa1a5a0 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -72,7 +72,6 @@
#define SUB_CHIP_ID1 1
#define SUB_CHIP_ID2 2
#define SUB_CHIP_ID3 3
-#define SUB_CHIP_ID_INVAL 0xff
/* Base Address defns for twl4030_map[] */
@@ -326,12 +325,8 @@ int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes)
pr_err("%s: not initialized\n", DRIVER_NAME);
return -EPERM;
}
+
sid = twl_map[mod_no].sid;
- if (unlikely(sid == SUB_CHIP_ID_INVAL)) {
- pr_err("%s: module %d is not part of the pmic\n",
- DRIVER_NAME, mod_no);
- return -EINVAL;
- }
twl = &twl_modules[sid];
ret = regmap_bulk_write(twl->regmap, twl_map[mod_no].base + reg,
@@ -368,12 +363,8 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes)
pr_err("%s: not initialized\n", DRIVER_NAME);
return -EPERM;
}
+
sid = twl_map[mod_no].sid;
- if (unlikely(sid == SUB_CHIP_ID_INVAL)) {
- pr_err("%s: module %d is not part of the pmic\n",
- DRIVER_NAME, mod_no);
- return -EINVAL;
- }
twl = &twl_modules[sid];
ret = regmap_bulk_read(twl->regmap, twl_map[mod_no].base + reg,
--
1.8.0.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 09/10] mfd: twl-core: Remove no longer valid comment regarding to write buffer size
With the regmap conversion there is no longeer a need to allocate bigger buffer for writes Signed-off-by: Peter Ujfalusi --- drivers/mfd/twl-core.c | 3 --- include/linux/i2c/twl.h | 3 --- 2 files changed, 6 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index e2895a4..9661204 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -308,9 +308,6 @@ EXPORT_SYMBOL(twl_rev); * @reg: register address (just offset will do) * @num_bytes: number of bytes to transfer * - * IMPORTANT: for 'value' parameter: Allocate value num_bytes+1 and - * valid data starts at Offset 1. - * * Returns the result of operation - 0 is success */ int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes) diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h index 72adc88..e441fd8 100644 --- a/include/linux/i2c/twl.h +++ b/include/linux/i2c/twl.h @@ -182,9 +182,6 @@ int twl_i2c_read_u8(u8 mod_no, u8 *val, u8 reg); /* * Read and write several 8-bit registers at once. - * - * IMPORTANT: For twl_i2c_write(), allocate num_bytes + 1 - * for the value, and populate your data starting at offset 1. */ int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes); int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes); -- 1.8.0.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 10/10] mfd: twl-core: Move twl_i2c_read/write_u8 to header as inline function
twl_i2c_read/write_u8 become as a simple wrapper over the twl_i2c_read/write.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 28
include/linux/i2c/twl.h | 17 +++--
2 files changed, 11 insertions(+), 34 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 9661204..557f9ee 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -379,34 +379,6 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes)
}
EXPORT_SYMBOL(twl_i2c_read);
-/**
- * twl_i2c_write_u8 - Writes a 8 bit register in TWL4030/TWL5030/TWL60X0
- * @mod_no: module number
- * @value: the value to be written 8 bit
- * @reg: register address (just offset will do)
- *
- * Returns result of operation - 0 is success
- */
-int twl_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
-{
- return twl_i2c_write(mod_no, &value, reg, 1);
-}
-EXPORT_SYMBOL(twl_i2c_write_u8);
-
-/**
- * twl_i2c_read_u8 - Reads a 8 bit register from TWL4030/TWL5030/TWL60X0
- * @mod_no: module number
- * @value: the value read 8 bit
- * @reg: register address (just offset will do)
- *
- * Returns result of operation - 0 is success
- */
-int twl_i2c_read_u8(u8 mod_no, u8 *value, u8 reg)
-{
- return twl_i2c_read(mod_no, value, reg, 1);
-}
-EXPORT_SYMBOL(twl_i2c_read_u8);
-
/*--*/
/**
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index e441fd8..488debb 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -175,17 +175,22 @@ TWL_CLASS_IS(4030, TWL4030_CLASS_ID)
TWL_CLASS_IS(6030, TWL6030_CLASS_ID)
/*
- * Read and write single 8-bit registers
- */
-int twl_i2c_write_u8(u8 mod_no, u8 val, u8 reg);
-int twl_i2c_read_u8(u8 mod_no, u8 *val, u8 reg);
-
-/*
* Read and write several 8-bit registers at once.
*/
int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes);
int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes);
+/*
+ * Read and write single 8-bit registers
+ */
+static inline int twl_i2c_write_u8(u8 mod_no, u8 val, u8 reg) {
+ return twl_i2c_write(mod_no, &val, reg, 1);
+}
+
+static inline int twl_i2c_read_u8(u8 mod_no, u8 *val, u8 reg) {
+ return twl_i2c_read(mod_no, val, reg, 1);
+}
+
int twl_get_type(void);
int twl_get_version(void);
int twl_get_hfclk_rate(void);
--
1.8.0.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 04/10] mfd: twl-core: Allocate twl_modules dynamically
At boot time we can allocate the twl_modules array dynamically based on the
twl class we are using with devm_kzalloc() instead of the static
twl_modules[] array.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index f07317b..fbff830 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -66,8 +66,6 @@
/* Triton Core internal information (BEGIN) */
-#define TWL_NUM_SLAVES 4
-
/* Base Address defns for twl4030_map[] */
/* subchip/slave 0 - USB ID */
@@ -162,7 +160,7 @@ struct twl_client {
struct regmap *regmap;
};
-static struct twl_client twl_modules[TWL_NUM_SLAVES];
+static struct twl_client *twl_modules;
/* mapping the module id to slave id and base address */
struct twl_mapping {
@@ -284,6 +282,14 @@ static struct regmap_config twl6030_regmap_config[3] = {
/*--*/
+static inline int twl_get_num_slaves(void)
+{
+ if (twl_class_is_4030())
+ return 4; /* TWL4030 class have four slave address */
+ else
+ return 3; /* TWL6030 class have three slave address */
+}
+
static inline int twl_get_last_module(void)
{
if (twl_class_is_4030())
@@ -1127,17 +1133,15 @@ static int twl_remove(struct i2c_client *client)
unsigned i, num_slaves;
int status;
- if (twl_class_is_4030()) {
+ if (twl_class_is_4030())
status = twl4030_exit_irq();
- num_slaves = TWL_NUM_SLAVES;
- } else {
+ else
status = twl6030_exit_irq();
- num_slaves = TWL_NUM_SLAVES - 1;
- }
if (status < 0)
return status;
+ num_slaves = twl_get_num_slaves();
for (i = 0; i < num_slaves; i++) {
struct twl_client *twl = &twl_modules[i];
@@ -1215,12 +1219,19 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
twl_map[TWL_MODULE_MAIN_CHARGE].base =
TWL6025_BASEADD_CHARGER;
twl_regmap_config = twl6030_regmap_config;
- num_slaves = TWL_NUM_SLAVES - 1;
} else {
twl_id = TWL4030_CLASS_ID;
twl_map = &twl4030_map[0];
twl_regmap_config = twl4030_regmap_config;
- num_slaves = TWL_NUM_SLAVES;
+ }
+
+ num_slaves = twl_get_num_slaves();
+ twl_modules = devm_kzalloc(&client->dev,
+ sizeof(struct twl_client) * num_slaves,
+ GFP_KERNEL);
+ if (!twl_modules) {
+ status = -ENOMEM;
+ goto free;
}
for (i = 0; i < num_slaves; i++) {
--
1.8.0.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 05/10] mfd: twl-core: Do not try to call legacy mfd add_children() when booted with DT
There is really no point to retry to add children devices in case the of_platform_populate() fails. We do not have any information provided via pdata in this case anyways. Depending on the boot type (legacy or DT) only execute either one. Signed-off-by: Peter Ujfalusi --- drivers/mfd/twl-core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index fbff830..86cca9e 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -1305,10 +1305,9 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id) twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1); } - status = -ENODEV; if (node) status = of_platform_populate(node, NULL, NULL, &client->dev); - if (status) + else status = add_children(pdata, irq_base, id->driver_data); fail: -- 1.8.0.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 03/10] mfd: twl-core: Use the lookup table to find the correct subchip for the modules
Instead of using SUB_CHIP_ID* or magic numbers use the twl_mapping table to
look for the subchip ID.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl-core.c | 56 --
1 file changed, 27 insertions(+), 29 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index fa1a5a0..f07317b 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -68,11 +68,6 @@
#define TWL_NUM_SLAVES 4
-#define SUB_CHIP_ID0 0
-#define SUB_CHIP_ID1 1
-#define SUB_CHIP_ID2 2
-#define SUB_CHIP_ID3 3
-
/* Base Address defns for twl4030_map[] */
/* subchip/slave 0 - USB ID */
@@ -493,13 +488,20 @@ int twl_get_hfclk_rate(void)
EXPORT_SYMBOL_GPL(twl_get_hfclk_rate);
static struct device *
-add_numbered_child(unsigned chip, const char *name, int num,
+add_numbered_child(unsigned mod_no, const char *name, int num,
void *pdata, unsigned pdata_len,
bool can_wakeup, int irq0, int irq1)
{
struct platform_device *pdev;
- struct twl_client *twl = &twl_modules[chip];
- int status;
+ struct twl_client *twl;
+ int status, sid;
+
+ if (unlikely(mod_no >= twl_get_last_module())) {
+ pr_err("%s: invalid module number %d\n", DRIVER_NAME, mod_no);
+ return ERR_PTR(-EPERM);
+ }
+ sid = twl_map[mod_no].sid;
+ twl = &twl_modules[sid];
pdev = platform_device_alloc(name, num);
if (!pdev) {
@@ -544,11 +546,11 @@ err:
return &pdev->dev;
}
-static inline struct device *add_child(unsigned chip, const char *name,
+static inline struct device *add_child(unsigned mod_no, const char *name,
void *pdata, unsigned pdata_len,
bool can_wakeup, int irq0, int irq1)
{
- return add_numbered_child(chip, name, -1, pdata, pdata_len,
+ return add_numbered_child(mod_no, name, -1, pdata, pdata_len,
can_wakeup, irq0, irq1);
}
@@ -557,7 +559,6 @@ add_regulator_linked(int num, struct regulator_init_data
*pdata,
struct regulator_consumer_supply *consumers,
unsigned num_consumers, unsigned long features)
{
- unsigned sub_chip_id;
struct twl_regulator_driver_data drv_data;
/* regulator framework demands init_data ... */
@@ -584,8 +585,7 @@ add_regulator_linked(int num, struct regulator_init_data
*pdata,
}
/* NOTE: we currently ignore regulator IRQs, e.g. for short circuits */
- sub_chip_id = twl_map[TWL_MODULE_PM_MASTER].sid;
- return add_numbered_child(sub_chip_id, "twl_reg", num,
+ return add_numbered_child(TWL_MODULE_PM_MASTER, "twl_reg", num,
pdata, sizeof(*pdata), false, 0, 0);
}
@@ -607,10 +607,9 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
unsigned long features)
{
struct device *child;
- unsigned sub_chip_id;
if (IS_ENABLED(CONFIG_GPIO_TWL4030) && pdata->gpio) {
- child = add_child(SUB_CHIP_ID1, "twl4030_gpio",
+ child = add_child(TWL4030_MODULE_GPIO, "twl4030_gpio",
pdata->gpio, sizeof(*pdata->gpio),
false, irq_base + GPIO_INTR_OFFSET, 0);
if (IS_ERR(child))
@@ -618,7 +617,7 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
}
if (IS_ENABLED(CONFIG_KEYBOARD_TWL4030) && pdata->keypad) {
- child = add_child(SUB_CHIP_ID2, "twl4030_keypad",
+ child = add_child(TWL4030_MODULE_KEYPAD, "twl4030_keypad",
pdata->keypad, sizeof(*pdata->keypad),
true, irq_base + KEYPAD_INTR_OFFSET, 0);
if (IS_ERR(child))
@@ -627,7 +626,7 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
if (IS_ENABLED(CONFIG_TWL4030_MADC) && pdata->madc &&
twl_class_is_4030()) {
- child = add_child(SUB_CHIP_ID2, "twl4030_madc",
+ child = add_child(TWL4030_MODULE_MADC, "twl4030_madc",
pdata->madc, sizeof(*pdata->madc),
true, irq_base + MADC_INTR_OFFSET, 0);
if (IS_ERR(child))
@@ -642,22 +641,21 @@ add_children(struct twl4030_platform_data *pdata,
unsigned irq_base,
* Eventually, Linux might become more aware of such
* HW security concerns, and "least privilege".
*/
- sub_chip_id = twl_map[TWL_MODULE_RTC].sid;
- child = add_child(sub_chip_id, "twl_rtc", NULL, 0,
+ child = add_child(TWL_MODULE_RTC, "twl_rtc", NULL, 0,
true, irq_base + RTC_INTR_OFFSET, 0);
if (IS_ERR(child))
return PTR_ERR(child);
}
if (
[PATCH 00/10] MFD: twl-core: Cleanup part 2 for 3.9
Hello, Second part of the cleanup of twl-core which aims to make the code a bit more readable. It has been tested on: OMAP4 PandaBoard, OMAP4 Blaze, OMAP3 BeagleBoard, OMAP3 Zoom2. Regards, Peter --- Peter Ujfalusi (10): mfd: twl-core: Clean up module id lookup and definitions mfd: twl-core: No need to check for invalid subchip ID mfd: twl-core: Use the lookup table to find the correct subchip for the modules mfd: twl-core: Allocate twl_modules dynamically mfd: twl-core: Do not try to call legacy mfd add_children() when booted with DT mfd: twl-core: Do not create dummy pdata when booted with DT mfd: twl-core: Move 'inuse' check early at probe time mfd: twl-core: Collect global variables behind one private structure (global) mfd: twl-core: Remove no longer valid comment regarding to write buffer size mfd: twl-core: Move twl_i2c_read/write_u8 to header as inline function drivers/mfd/twl-core.c | 362 +--- include/linux/i2c/twl.h | 84 +-- 2 files changed, 205 insertions(+), 241 deletions(-) -- 1.8.0.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: Fwd: PROBLEM: Random kernel panic & system freeze when watching video
On Mon, Dec 31, 2012 at 02:42:07AM +0800, Du Jiulun wrote: > CPU 2: Machine Check Exception: 4 Bank 2: b205 > TSC 6568f53a1cee > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 2 BANK 2 TSC 6568f53a1cee > TIME 1356717945 Sat Dec 29 02:05:45 2012 > STATUS b205 MCGSTATUS 4 > PROCESSOR 0:20652 TIME 1356717945 SOCKET 0 APIC 1 microcode c > Run the above through 'mcelog --ascii' > CPU 0: Machine Check Exception: 4 Bank 2: b205 > TSC 6568f53a1cfc > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 0 BANK 2 TSC 6568f53a1cfc > TIME 1356717945 Sat Dec 29 02:05:45 2012 > STATUS b205 MCGSTATUS 4 > PROCESSOR 0:20652 TIME 1356717945 SOCKET 0 APIC 0 microcode c > Run the above through 'mcelog --ascii' > Machine check: Processor context corrupt > > It seems that nothing much has come up except those already there. I had to build the latest mcelog from kernel.org and it tells you a little bit more: it is an internal parity error. I don't know, though, what errors reported in bank 2 pertain to on this cpu model - Intel should know :). CPU 2 BANK 2 TSC 6568f53a1cee TIME 1356717945 Fri Dec 28 19:05:45 2012 MCG status:MCIP MCi status: Uncorrected error Error enabled Processor context corrupt MCA: Internal parity error STATUS b205 MCGSTATUS 4 CPUID Vendor Intel Family 6 Model 37 SOCKET 0 APIC 1 microcode c Run the above through 'mcelog --ascii' CPU 0 BANK 2 TSC 6568f53a1cfc TIME 1356717945 Fri Dec 28 19:05:45 2012 MCG status:MCIP MCi status: Uncorrected error Error enabled Processor context corrupt MCA: Internal parity error STATUS b205 MCGSTATUS 4 CPUID Vendor Intel Family 6 Model 37 SOCKET 0 APIC 0 microcode c Run the above through 'mcelog --ascii' Machine check: Processor context corrupt Question: is this easily reproducible or only sporadic and has happened only twice up 'til now? > Since there's something about hardware error, I've got these message > in *bold* in my booting log: (from "sudo journalctl --line=5000", > don't know if relevant, sorry if not) Nah, those are your ACPI tables. > ACPI: RSDP 000f0410 00024 (v02 _ASUS_) > ACPI: XSDT aada5e18 0006C (v01 _ASUS_ Notebook 06222004 MSFT 00010013) > ACPI: FACP aad81c18 000F4 (v04 _ASUS_ Notebook 06222004 MSFT 00010013) > ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS tables! > (20120711/tbfadt-394) > ACPI BIOS Bug: Warning: 32/64X FACS address mismatch in FADT - > 0xAADB7F40/0xAADD1D40, using 32 (20120711/tbfadt-521) Yet another BIOS f*ckup. Oh well, it should be unrelated. > ACPI: DSDT aad44018 13C72 (v01 _ASUS_ Notebook INTL 20051117) > ACPI: FACS aadb7f40 00040 > ACPI: APIC aada4f18 0008C (v02 _ASUS_ Notebook 06222004 MSFT 00010013) > ACPI: DBGP aada6f18 00034 (v01 _ASUS_ Notebook 06222004 MSFT 00010013) > ACPI: ECDT aadd1b18 000C1 (v01 _ASUS_ Notebook 06222004 AMI. 0003) > ACPI: SLIC aadb2c18 00176 (v01 _ASUS_ Notebook 06222004 ASUS 0001) > ACPI: MCFG aadd0d18 0003C (v01 _ASUS_ Notebook 06222004 MSFT 0097) > ACPI: HPET aadd0c98 00038 (v01 _ASUS_ Notebook 06222004 AMI. 0003) > ACPI: SSDT aad9f018 009F1 (v01 PmRefCpuPm 3000 INTL 20051117) > ACPI: DMAR aad81f18 000B8 (v01 INTEL CP_DALE 0001 INTL 0001) > > perf_event_intel: CPUID marked event: 'bus cycles' unavailable > > mtrr: your CPUs had inconsistent variable MTRR settings Yep, more BIOS f*ckup. By the look of it, I wouldn't wonder if BIOS is misprogramming something and causing those MCEs. By the way, can you boot vanilla 3.7 and send the _whole_ dmesg? Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] prctl: fix validation of an address
On Sun, Dec 30, 2012 at 05:03:07PM -0500, Eric Paris wrote: > On Sat, 2012-12-29 at 15:00 +0400, Andrey Vagin wrote: > > The address should be bigger than dac_mmap_min_addr, because > > a process with CAP_RAWIO can map a vma bellow mmap_min_addr. > > NAK Currently prctl(PR_SET_MM_*, addr, ) returns EINVAL for valid addresses. I think it's a bug. Are you agree? > > This doesn't make any sense. dac_mmap_min_addr should ONLY be used in > security/min_addr.c and security/commoncap.c. Period. You should not We can add a function to security/commoncap.c... > be allowed to circumvent LSM protections. Maybe you are missing that > mmap_min_addr = max(dac_mmap_min_addr, CONFIG_LSM_MMAP_MIN_ADDR) ? Or maybe you are missing ;) that /* * cap_mmap_addr - check if able to map given addr * @addr: address attempting to be mapped * * If the process is attempting to map memory below dac_mmap_min_addr * they need CAP_SYS_RAWIO. It was a real case. I have an application, which is failed due to prlctl. This application uses vm.mmap_min_addr to calculate an adress for a new vma. $ sysctl -a | grep min_add vm.mmap_min_addr = 4096 CONFIG_LSM_MMAP_MIN_ADDR could not be got from user space. This application can use a real value of mmap_min_addr, but it is not provided into userspace. > > But this patch is absolutely unacceptable. Maybe you can help me > understand what problem you had and what you were hoping for? Currently a task can have user memory area bellow dac_mmap_min_addr, but prctl returns -EINVAL for such addresses. How can I understand the reason, if I know that the address is valid? I like Linux, because I always can predict its behavior, but this dac_mmap_min_addr vs mmap_min_addr looks stange for me. > > -Eric > > > > Cc: Andrew Morton > > Cc: Kees Cook > > Cc: Cyrill Gorcunov > > Cc: Serge Hallyn > > Cc: "Eric W. Biederman" > > Cc: Eric Paris > > Cc: James Morris > > Signed-off-by: Andrey Vagin > > --- > > kernel/sys.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/sys.c b/kernel/sys.c > > index 265b376..e0e1bbd 100644 > > --- a/kernel/sys.c > > +++ b/kernel/sys.c > > @@ -1868,7 +1868,7 @@ static int prctl_set_mm(int opt, unsigned long addr, > > if (opt == PR_SET_MM_EXE_FILE) > > return prctl_set_mm_exe_file(mm, (unsigned int)addr); > > > > - if (addr >= TASK_SIZE || addr < mmap_min_addr) > > + if (addr >= TASK_SIZE || addr < dac_mmap_min_addr) > > return -EINVAL; > > > > error = -EINVAL; > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd, TWL4030: TWL4030 need select REGMAP_I2C
On 12/24/2012 03:19 PM, Chuansheng Liu wrote: > This patch fix the below build error: > drivers/built-in.o: In function `twl_probe': > drivers/mfd/twl-core.c:1256: undefined reference to `devm_regmap_init_i2c' > make: *** [vmlinux] Error 1 Thanks Liu, I have missed this one. Acked-by: Peter Ujfalusi > > Signed-off-by: liu chuansheng > --- > drivers/mfd/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 1c0abd4..47ad4e2 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -292,6 +292,7 @@ config TWL4030_CORE > bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support" > depends on I2C=y && GENERIC_HARDIRQS > select IRQ_DOMAIN > + select REGMAP_I2C > help > Say yes here if you have TWL4030 / TWL6030 family chip on your board. > This core driver provides register access and IRQ handling > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Request-queue not getting process even after calling unplug
Kindly let me know if I am posting query in wrong Forum. If yes, then could anyone point me to the appropriate forum ? Thanks in advance, Vivek Satpute On Sun, Dec 30, 2012 at 5:02 PM, Vivek Satpute wrote: > Hi All, > > I am working on RHEL5.8 (kernel-2.6.18-308) and facing weird behavior > with the IO subsystem. > > My testcase requires to form the SCSI request manually and send it > down to the underlying HBA > for further IO processing. To achieve this I have formed the SCSI > request, packed it inside the > new request. Later on I am queuing the request to device's > request-queue using function - elv_add_request( ). > Request is getting queued correctly in a queue. Further I called > unplug on a queue, still it is not getting > processed further by IO scheduler. Request remains stuck in queue itself ! > > Strange part is, same code is working successfully on other kernel versions, > but I am facing the issue only on kernel-2.6.18-308. > > Can anyone help me to understand why request is being stuck in a queue > ? How can I debug this further ? > > > Thanks in advance! > Vivek Satpute -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] uprobes: Change handle_swbp() to expose bp_vaddr to handler_chain()
On Sun, Dec 30, 2012 at 04:47:22PM +0100, Oleg Nesterov wrote: > Change handle_swbp() to set regs->ip = bp_vaddr in advance, this is > what consumer->handler() needs but uprobe_get_swbp_addr() is not > exported. > > This also simplifies the code and makes it more consistent across > the supported architectures. handle_swbp() becomes the only caller > of uprobe_get_swbp_addr(). The arch agnostic bits look fine to me. > Signed-off-by: Oleg Nesterov Acked-by: Ananth N Mavinakayanahalli -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hwmon: (vexpress) Fix build error seen if CONFIG_OF_DEVICE is not set
Fix: vexpress.c: In function ‘vexpress_hwmon_name_show’: vexpress.c:34:2: error: implicit declaration of function ‘of_get_property’ [-Werror=implicit-function-declaration] vexpress.c:34:27: warning: initialization makes pointer from integer without a cast [enabled by default] vexpress.c: In function ‘vexpress_hwmon_label_show’: vexpress.c:43:22: warning: initialization makes pointer from integer without a cast [enabled by default] Seen if CONFIG_OF_DEVICE is not defined. of_get_property is declared in of.h which is only included by of_device.h if CONFIG_OF_DEVICE is defined. of.h needs to be included directly. Signed-off-by: Guenter Roeck --- drivers/hwmon/vexpress.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hwmon/vexpress.c b/drivers/hwmon/vexpress.c index 86d7f6d..d867e6b 100644 --- a/drivers/hwmon/vexpress.c +++ b/drivers/hwmon/vexpress.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include -- 1.7.9.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/
[PATCH 1/2] hwmon: (vexpress) Remove __devexit and __devexit_p
Signed-off-by: Guenter Roeck
---
drivers/hwmon/vexpress.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/vexpress.c b/drivers/hwmon/vexpress.c
index 59fd126..86d7f6d 100644
--- a/drivers/hwmon/vexpress.c
+++ b/drivers/hwmon/vexpress.c
@@ -196,7 +196,7 @@ error:
return err;
}
-static int __devexit vexpress_hwmon_remove(struct platform_device *pdev)
+static int vexpress_hwmon_remove(struct platform_device *pdev)
{
struct vexpress_hwmon_data *data = platform_get_drvdata(pdev);
const struct of_device_id *match;
@@ -213,7 +213,7 @@ static int __devexit vexpress_hwmon_remove(struct
platform_device *pdev)
static struct platform_driver vexpress_hwmon_driver = {
.probe = vexpress_hwmon_probe,
- .remove = __devexit_p(vexpress_hwmon_remove),
+ .remove = vexpress_hwmon_remove,
.driver = {
.name = DRVNAME,
.owner = THIS_MODULE,
--
1.7.9.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/
