headers
Stephen Boyd | 22 Feb 2013 08:27

[PATCH 0/8] Remove ARM local timer API

In light of Mark Rutland's recent work on divorcing the ARM architected
timers from the ARM local timer API and introducing a generic arch hook for
broadcast it seems that we should remove the local timer API entirely.
Doing so will reduce the architecture dependencies of our timer drivers,
reduce code in ARM core, and simplify timer drivers because they no longer
go through an architecture layer that is essentially a hotplug notifier.

Previous attempts have been made[1] unsuccessfully. I'm hoping this can
be accepted now so that we can clean up the timer drivers that are
used in both UP and SMP situations. Right now these drivers have to ignore
the timer setup callback on the boot CPU to avoid registering clockevents
twice. This is not very symmetric and causes convuluted code that does
the same thing in two places.

Patches based on linux-next-20130221. Mostly compile tested as I don't
have access to the hardware.

[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/145705

Note: A hotplug notifier is used by both x86 for the apb_timer (see 
apbt_cpuhp_notify) and by metag (see arch_timer_cpu_notify in
metag_generic.c) so this is not new.

Stephen Boyd (8):
  ARM: smp: Lower rating of dummy broadcast device
  ARM: smp_twd: Divorce smp_twd from local timer API
  ARM: EXYNOS4: Divorce mct from local timer API
  ARM: PRIMA2: Divorce timer-marco from local timer API
  ARM: MSM: Divorce msm_timer from local timer API
  clocksource: time-armada-370-xp: Fix sparse warning
(Continue reading)

Permalink | Reply | 18 comments |
headers
Bill Gatliff | 20 Feb 2013 18:50

Missing copy_from_user() in APQ8060A's msm_vfe_subdev_ioctl()

Guys:

I'm getting the following OOPS:

[    2.952388] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
[    2.952388] pgd = dfca4000
[    2.952418] [00000000] *pgd=a70cb831, *pte=00000000, *ppte=00000000
[    2.952418] Internal error: Oops: 17 [#1] PREEMPT SMP
[    2.952418] Modules linked in:
[    2.952418] CPU: 0    Not tainted  (3.0.21-perf+ #1)
[    2.952449] PC is at msm_vfe_subdev_ioctl+0x14/0x4614
[    2.952449] LR is at subdev_do_ioctl+0x43c/0x49c

Referring to commit d358ecdb, I see a lot of code that looks like this
in msm_vfe_subdev_ioctl():

static long msm_vfe_subdev_ioctl(struct v4l2_subdev *sd,
                        unsigned int subdev_cmd, void *arg)
{
...
        struct msm_camvfe_params *vfe_params =
                (struct msm_camvfe_params *)arg;
        struct msm_vfe_cfg_cmd *cmd = vfe_params->vfe_cfg;
        void *data = vfe_params->data;
...
                struct axidata *axid;
                axid = data;
...
                regptr = axid->region;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yaniv Gardi | 19 Feb 2013 17:22

[PATCH v9 0/2] *** adding and exposing SANITIZE capability to the user space via a unique IOCTL ***

*** adding and exposing SANITIZE capability to the user space via a unique IOCTL ***

Yaniv Gardi (2):
  block: ioctl support for sanitize in eMMC 4.5
  mmc: card: Adding support for sanitize in eMMC 4.5

 block/blk-core.c          |    8 +++++
 block/blk-lib.c           |   51 ++++++++++++++++++++++++++++++
 block/blk-merge.c         |    4 ++
 block/elevator.c          |    6 +++-
 block/ioctl.c             |    9 +++++
 drivers/mmc/card/block.c  |   75 +++++++++++++++++++++++++++++++-------------
 drivers/mmc/card/queue.c  |   10 +++++-
 include/linux/blk_types.h |    7 +++-
 include/linux/blkdev.h    |    6 +++
 include/linux/mmc/host.h  |    1 +
 include/uapi/linux/fs.h   |    1 +
 kernel/trace/blktrace.c   |    2 +
 12 files changed, 154 insertions(+), 26 deletions(-)

-- 
1.7.6
--

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum
Permalink | Reply | 3 comments |
headers
Steve Muckle | 2 Feb 2013 03:08

invalid socket structure with ip_early_demux

Recently I've struggled with crashes in the xt_qtaguid netfilter module.
This module is written by Google and used with Android. The match
function in xt_qtaguid eventually tries to access

  skb->sk->sk_socket->file

What I find is that the sk->sk_socket pointer is sometimes 0xAAAAAAAA,
or PAGE_POISON. In fact everything after the first 16 bytes of the
struct sock sk is PAGE_POISON. I've confirmed that if I change
PAGE_POISON, the values I see in the sk structure change as well.

I was curious how this structure was being allocated/initialized and
instrumented the sk_alloc, sk_free, and sk_clone_lock functions. When
xt_qtaguid encounters a bad struct sock, that sock does not show up as
ever having been allocated (or freed).

The struct sock is being assigned to the skb in tcb_v4_early_demux(). I
modified that function immediately after the sk is assigned from
__inet_lookup_established() to panic if the sk has a sk_socket pointer
of PAGE_POISON. I can reproduce that condition on my target by simply
attempting to mount an NFS volume. Initiating *and* aborting wget
operations also reproduces the issue - simply initiating a bunch of
wgets is not enough to trigger it.

I have not yet been able to reproduce the bad condition when disabling
ip_early_demux via the sysctl. Any possibility this is an actual issue
with that feature? My target is an MSM using the ks8851 ethernet module.

thanks,
Steve
(Continue reading)

Permalink | Reply | 4 comments |
headers
Chen Gang | 30 Jan 2013 06:01

[PATCH] ARM:mach-msm: seting tail NUL after strncpy


  temp need NUL terminated, or next ptr may cause issue.

Signed-off-by: Chen Gang <gang.chen <at> asianux.com>
---
 arch/arm/mach-msm/clock-debug.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-msm/clock-debug.c
b/arch/arm/mach-msm/clock-debug.c
index 4886404..bdca900 100644
--- a/arch/arm/mach-msm/clock-debug.c
+++ b/arch/arm/mach-msm/clock-debug.c
 <at>  <at>  -105,6 +105,8  <at>  <at>  int __init clock_debug_add(struct clk *clock)
 		return -ENOMEM;

 	strncpy(temp, clock->dbg_name, ARRAY_SIZE(temp)-1);
+	temp[ARRAY_SIZE(temp)-1] = '\0';
+
 	for (ptr = temp; *ptr; ptr++)
 		*ptr = tolower(*ptr);

--

-- 
1.7.10.4
Permalink | Reply | 6 comments |
headers
Stepan Moskovchenko | 22 Jan 2013 06:47

[PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

Add the %pa format specifier for printing a phys_addr_t
type, since the physical address size on some platforms
can vary based on build options, regardless of the native
integer type.

Signed-off-by: Stepan Moskovchenko <stepanm <at> codeaurora.org>
---
 Documentation/printk-formats.txt |   13 ++++++++++---
 lib/vsprintf.c                   |    7 +++++++
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 8ffb274..dbc977b 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
 <at>  <at>  -53,6 +53,13  <at>  <at>  Struct Resources:
 	For printing struct resources. The 'R' and 'r' specifiers result in a
 	printed resource with ('R') or without ('r') a decoded flags member.

+Physical addresses:
+
+	%pa	0x01234567 or 0x0123456789abcdef
+
+	For printing a phys_addr_t type, which can vary based on build options,
+	regardless of the width of the CPU data path. Passed by reference.
+
 Raw buffer as a hex string:
 	%*ph	00 01 02  ...  3f
 	%*phC	00:01:02: ... :3f
 <at>  <at>  -150,9 +157,9  <at>  <at>  s64 SHOULD be printed with %lld/%llx, (long long):
(Continue reading)

Permalink | Reply | 10 comments |
headers
Maya Erez | 20 Jan 2013 12:29

[PATCH v1] mmc: core: move the cache disabling operation to mmc_suspend

Cache control is an eMMC feature and in therefore should be
part of MMC's bus resume operations, performed in mmc_suspend,
rather than in the generic mmc_suspend_host().

Signed-off-by: Maya Erez <merez <at> codeaurora.org>

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index aaed768..b438bb2 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
 <at>  <at>  -2388,6 +2388,7  <at>  <at>  EXPORT_SYMBOL(mmc_flush_cache);
  * Turn the cache ON/OFF.
  * Turning the cache OFF shall trigger flushing of the data
  * to the non-volatile storage.
+ * This function should be called with host claimed
  */
 int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
 {
 <at>  <at>  -2399,7 +2400,6  <at>  <at>  int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
 			mmc_card_is_removable(host))
 		return err;

-	mmc_claim_host(host);
 	if (card && mmc_card_mmc(card) &&
 			(card->ext_csd.cache_size > 0)) {
 		enable = !!enable;
 <at>  <at>  -2417,7 +2417,6  <at>  <at>  int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
 				card->ext_csd.cache_ctrl = enable;
 		}
 	}
(Continue reading)

Permalink | Reply | 2 comments |
headers
Maya Erez | 10 Jan 2013 21:15

[PATCH v5 1/3] mmc: core: Add support for idle time BKOPS

Devices have various maintenance operations need to perform internally.
In order to reduce latencies during time critical operations like read
and write, it is better to execute maintenance operations in other
times - when the host is not being serviced. Such operations are called
Background operations (BKOPS).
The device notifies the status of the BKOPS need by updating BKOPS_STATUS
(EXT_CSD byte [246]).

According to the standard a host that supports BKOPS shall check the
status periodically and start background operations as needed, so that
the device has enough time for its maintenance operations.

This patch adds support for this periodic check of the BKOPS status.
Since foreground operations are of higher priority than background
operations the host will check the need for BKOPS when it is idle,
and in case of an incoming request the BKOPS operation will be
interrupted.

When the mmcqd thread is idle, a delayed work is created to check the
need for BKOPS. The time to start the delayed work can be set by the host
controller. If this time is not set, a default time is used.
If the card raised an exception with need for urgent BKOPS (level 2/3)
a flag will be set to indicate MMC to start the BKOPS activity when it
becomes idle.

Since running the BKOPS too often can impact the eMMC endurance, the card
need for BKOPS is not checked every time MMC is idle (despite of cases of
exception raised). In order to estimate when is the best time to check
for BKOPS need the host will take into account the card capacity and
percentages of changed sectors in the card. A future enhancement can be to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maya Erez | 10 Jan 2013 21:15

[PATCH v5 0/3] Add support for periodic BKOPS

Devices have various maintenance operations need to perform internally.
In order to reduce latencies during time critical operations like read
and write, it is better to execute maintenance operations in other
times - when the host is not being serviced. Such operations are called
Background operations (BKOPS).
The device notifies the status of the BKOPS need by updating BKOPS_STATUS
(EXT_CSD byte [246]).

According to the standard a host that supports BKOPS shall check the
status periodically and start background operations as needed, so that
the device has enough time for its maintenance operations.

This patch adds support for this periodic check of the BKOPS status.
Since foreground operations are of higher priority than background
operations the host will check the need for BKOPS when it is idle,
and in case of an incoming request the BKOPS operation will be
interrupted.

When the mmcqd thread is idle, a delayed work is created to check the
need for BKOPS. The time to start the delayed work can be set by the host
controller. If this time is not set, a default time is used.
If the card raised an exception with need for urgent BKOPS (level 2/3)
a flag will be set to indicate MMC to start the BKOPS activity when it
becomes idle.

Since running the BKOPS too often can impact the eMMC endurance, the card
need for BKOPS is not checked every time MMC is idle (despite of cases of
exception raised). In order to estimate when is the best time to check
for BKOPS need the host will take into account the card capacity and
percentages of changed sectors in the card. A future enhancement can be to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Srivatsa Vaddagiri | 4 Jan 2013 03:58

[PATCH 1/2] cpuhotplug/nohz: Remove offline cpus from nohz-idle state

Modify idle loop of arm, mips, s390, sh and x86 architectures to exit from nohz
state before dying upon hot-remove. This change is needed to avoid userspace
tools like top command from seeing a rollback in total idle time over some
sampling periods.

Additionaly, modify idle loop on all architectures supporting cpu hotplug to
have idle thread of a dying cpu die immediately after scheduler returns control
to it. There is no point in wasting time via calls to *_enter()/*_exit() before
noticing the need to die and dying.

Additional ARM specific change:
	Revert commit ff081e05 ("ARM: 7457/1: smp: Fix suspicious
RCU originating from cpu_die()"), which added a RCU_NONIDLE() wrapper
around call to complete(). That wrapper is no longer needed as cpu_die() is
now called outside of a rcu_idle_enter()/exit() section. I also think that the
wait_for_completion() based wait in ARM's __cpu_die() can be replaced with a
busy-loop based one, as the wait there in general should be terminated within
few cycles.

Cc: Russell King <linux <at> arm.linux.org.uk>
Cc: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>
Cc: Stephen Boyd <sboyd <at> codeaurora.org>
Cc: linux-arm-kernel <at> lists.infradead.org
Cc: Mike Frysinger <vapier <at> gentoo.org>
Cc: uclinux-dist-devel <at> blackfin.uclinux.org
Cc: Ralf Baechle <ralf <at> linux-mips.org>
Cc: linux-mips <at> linux-mips.org
Cc: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
Cc: linuxppc-dev <at> lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky <at> de.ibm.com>
(Continue reading)

Permalink | Reply | 6 comments |

Gmane