Re: [PATCH] net: sun4i-emac: remove erroneous assignment
On 06/03/2013 11:36 PM, Arnd Bergmann wrote: > The newly added sun4i-emac driver causes a build error when > CONFIG_NET_POLL_CONTROLLER is set, because it attempts to > assign a pointer to netdev->poll_controller, which has > been replaced with ops->ndo_poll_controller in 2.6.31! > > The correct assignment is present as well, so we just need > to remove the wrong one. > > Signed-off-by: Arnd Bergmann > Cc: Stefan Roese > Cc: Maxime Ripard > Cc: Richard Genoud Thanks for fixing this: Acked-by: Stefan Roese Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [net-next rfc V2 7/8] macvtap: add TUNSETQUEUE ioctl
On 06/03/2013 07:09 PM, Michael S. Tsirkin wrote:
> On Mon, Jun 03, 2013 at 01:20:58PM +0800, Jason Wang wrote:
>> On 06/02/2013 07:22 PM, Michael S. Tsirkin wrote:
>>> On Fri, May 31, 2013 at 05:53:24PM +0800, Jason Wang wrote:
This patch adds TUNSETQUEUE ioctl to let userspace can temporarily disable
or
enable a queue of macvtap. This is used to be compatible at API layer of
tuntap
to simplify the userspace to manage the queues.
This is done by split the taps array into three different areas:
- [0, numvtaps) : enabled taps
- [numvtaps, numvtaps + numdisabled) : disabled taps
- [numvtaps + numdisabled, MAX_MAXVTAP_QUEUES) : unused slots
When a tap were enabled and disabled, it was moved to another area.
Signed-off-by: Jason Wang
>>> This seems a bit tricky. Can we just move the tap out of the
>>> array?
>> Certainly yes.
>>> the only reason we have the array is for fast
>>> lookup on xmit.
>>> What's the reason to keep disabled queues there?
>> It saves us some space and make code simpler.
>>> To be able to track all queues for cleanups, all we need is
>>> a linked list of all queues (enabled and disabled).
>> Yes, but you need iterate both arrays and linked list which won't be
>> simpler than keeping them in place.
> No, my idea is to keep all taps in the list.
>
> If you need all taps, walks the list.
> If you need active taps, look them up in the array.
>
> Reasonable?
Looks so, will change in next version.
>
---
drivers/net/macvtap.c | 167
include/linux/if_macvlan.h |7 ++
2 files changed, 159 insertions(+), 15 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index eac49cb..03b781c 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -85,32 +85,126 @@ static const struct proto_ops macvtap_socket_ops;
*/
static DEFINE_SPINLOCK(macvtap_lock);
-static int macvtap_set_queue(struct net_device *dev, struct file *file,
+static void macvtap_swap_slot(struct macvlan_dev *vlan, int a, int b)
+{
+ struct macvtap_queue *q1, *q2;
+
+ if (a == b)
+ return;
+
+ q1 = rcu_dereference_protected(vlan->taps[a],
+ lockdep_is_held(_lock));
+ q2 = rcu_dereference_protected(vlan->taps[b],
+ lockdep_is_held(_lock));
+
+ BUG_ON(q1 == NULL || q2 == NULL);
+
+ rcu_assign_pointer(vlan->taps[a], q2);
+ rcu_assign_pointer(vlan->taps[b], q1);
+
+ q1->queue_index = b;
+ q2->queue_index = a;
+}
+
+static int macvtap_enable_queue(struct net_device *dev, struct file *file,
struct macvtap_queue *q)
{
struct macvlan_dev *vlan = netdev_priv(dev);
+ int err = -EINVAL;
+ int total;
+
+ spin_lock(_lock);
+ total = vlan->numvtaps + vlan->numdisabled;
+
+ if (q->queue_index < vlan->numvtaps)
+ goto out;
+
+ err = 0;
+
+ BUG_ON(q->queue_index >= total);
+ macvtap_swap_slot(vlan, q->queue_index, vlan->numvtaps);
+
+ /* Make sure the pointers were seen before indices. */
+ wmb();
>>> Which indices? We only care about numvtaps right?
>>> So let's just say so.
>> ok
>>> Why is this wmb and not smp_wmb()?
>> will correct it.
+
+ vlan->numdisabled--;
+ vlan->numvtaps++;
+out:
+ spin_unlock(_lock);
+ return err;
+}
+
+static int macvtap_set_queue(struct net_device *dev, struct file *file,
+ struct macvtap_queue *q)
+{
+ struct macvlan_dev *vlan = netdev_priv(dev);
int err = -EBUSY;
+ int total;
spin_lock(_lock);
- if (vlan->numvtaps == MAX_MACVTAP_QUEUES)
+
+ total = vlan->numvtaps + vlan->numdisabled;
+ if (total == MAX_MACVTAP_QUEUES)
goto out;
err = 0;
+
rcu_assign_pointer(q->vlan, vlan);
- rcu_assign_pointer(vlan->taps[vlan->numvtaps], q);
+ rcu_assign_pointer(vlan->taps[total], q);
sock_hold(>sk);
q->file = file;
- q->queue_index = vlan->numvtaps;
+ q->queue_index = total;
file->private_data = q;
+ if (vlan->numdisabled)
+ macvtap_swap_slot(vlan, vlan->numvtaps, total);
- vlan->numvtaps++;
+ /* Make sure the pointers were seen before indices. */
+ wmb();
+ vlan->numvtaps++;
out:
spin_unlock(_lock);
return err;
}
+static int macvtap_disable_queue(struct macvtap_queue *q)
+{
+ struct macvlan_dev *vlan;
+ int err = -EINVAL;
+
+ spin_lock(_lock);
+ vlan = rcu_dereference_protected(q->vlan,
+
[PATCH v2 2/2] staging: gdm72xx: fix typos in Kconfig
Signed-off-by: Ben Chan Cc: Sage Ahn --- drivers/staging/gdm72xx/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/gdm72xx/Kconfig b/drivers/staging/gdm72xx/Kconfig index dd47bd1..dd8a391 100644 --- a/drivers/staging/gdm72xx/Kconfig +++ b/drivers/staging/gdm72xx/Kconfig @@ -19,7 +19,7 @@ config WIMAX_GDM72XX_K_MODE default n config WIMAX_GDM72XX_WIMAX2 - bool "Enable WIMAX2 support" + bool "Enable WiMAX2 support" default n choice @@ -38,7 +38,7 @@ endchoice if WIMAX_GDM72XX_USB config WIMAX_GDM72XX_USB_PM - bool "Enable power managerment support" + bool "Enable power management support" depends on PM_RUNTIME endif # WIMAX_GDM72XX_USB -- 1.8.2.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 v2 1/2] staging: gdm72xx: WIMAX_GDM72XX should depend on either USB or MMC
The gdm72xx driver needs to have either the USB or SDIO implementation enabled to provide useful functionalities, so the driver should depend on either USB or MMC. This patch makes WIMAX_GDM72XX depend on either USB or MMC. Also, WIMAX_GDM72XX needs to be built as a module if its dependent interface, either USB or MMC, is built as a module. This patch enforces that in the WIMAX_GDM72XX_USB and WIMAX_GDM72XX_SDIO dependency. Reported-by: Alan Stern Signed-off-by: Ben Chan Cc: Sage Ahn --- drivers/staging/gdm72xx/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/gdm72xx/Kconfig b/drivers/staging/gdm72xx/Kconfig index 6905913..dd47bd1 100644 --- a/drivers/staging/gdm72xx/Kconfig +++ b/drivers/staging/gdm72xx/Kconfig @@ -4,7 +4,7 @@ menuconfig WIMAX_GDM72XX tristate "GCT GDM72xx WiMAX support" - depends on NET + depends on NET && (USB || MMC) help Support for the GCT GDM72xx WiMAX chip @@ -27,11 +27,11 @@ choice config WIMAX_GDM72XX_USB bool "USB interface" - depends on USB + depends on (USB = y || USB = WIMAX_GDM72XX) config WIMAX_GDM72XX_SDIO bool "SDIO interface" - depends on MMC + depends on (MMC = y || MMC = WIMAX_GDM72XX) endchoice -- 1.8.2.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 RESEND] perf sched: Move struct perf_sched definition out of cmd_sched()
From: Namhyung Kim
For some reason it consumed quite amount of compile time when declared
as local variable, and it disappeared when moved out of the function.
Moving other variables/tables didn't help.
On my system this single-file-change build time reduced from 11s to 3s.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-sched.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 2da2a6ca22bf..2eddd71baa94 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1663,28 +1663,29 @@ static int __cmd_record(int argc, const char **argv)
return cmd_record(i, rec_argv, NULL);
}
+static const char default_sort_order[] = "avg, max, switch, runtime";
+static struct perf_sched sched = {
+ .tool = {
+ .sample = perf_sched__process_tracepoint_sample,
+ .comm= perf_event__process_comm,
+ .lost= perf_event__process_lost,
+ .fork= perf_event__process_fork,
+ .ordered_samples = true,
+ },
+ .cmp_pid = LIST_HEAD_INIT(sched.cmp_pid),
+ .sort_list= LIST_HEAD_INIT(sched.sort_list),
+ .start_work_mutex = PTHREAD_MUTEX_INITIALIZER,
+ .work_done_wait_mutex = PTHREAD_MUTEX_INITIALIZER,
+ .curr_pid = { [0 ... MAX_CPUS - 1] = -1 },
+ .sort_order = default_sort_order,
+ .replay_repeat= 10,
+ .profile_cpu = -1,
+ .next_shortname1 = 'A',
+ .next_shortname2 = '0',
+};
+
int cmd_sched(int argc, const char **argv, const char *prefix __maybe_unused)
{
- const char default_sort_order[] = "avg, max, switch, runtime";
- struct perf_sched sched = {
- .tool = {
- .sample =
perf_sched__process_tracepoint_sample,
- .comm= perf_event__process_comm,
- .lost= perf_event__process_lost,
- .fork= perf_event__process_fork,
- .ordered_samples = true,
- },
- .cmp_pid = LIST_HEAD_INIT(sched.cmp_pid),
- .sort_list= LIST_HEAD_INIT(sched.sort_list),
- .start_work_mutex = PTHREAD_MUTEX_INITIALIZER,
- .work_done_wait_mutex = PTHREAD_MUTEX_INITIALIZER,
- .curr_pid = { [0 ... MAX_CPUS - 1] = -1 },
- .sort_order = default_sort_order,
- .replay_repeat= 10,
- .profile_cpu = -1,
- .next_shortname1 = 'A',
- .next_shortname2 = '0',
- };
const struct option latency_options[] = {
OPT_STRING('s', "sort", _order, "key[,key2...]",
"sort by key(s): runtime, switch, avg, max"),
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the percpu tree
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in
include/linux/percpu-refcount.h and lib/percpu-refcount.c between commit
215e262f2aeb ("percpu: implement generic percpu refcounting") from the
percpu tree and commit "generic dynamic per cpu refcounting" from the
akpm tree.
I just dropped the patch from the akpm tree. The percpu tree patch looks
like it may be a later version.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpid7YYe0ZOJ.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the staging tree
On Tue, Jun 04, 2013 at 02:57:00PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from
> drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:44:0,
> from
> drivers/staging/lustre/lustre/fid/../include/linux/lvfs.h:48,
> from drivers/staging/lustre/lustre/fid/../include/lvfs.h:45,
> from
> drivers/staging/lustre/lustre/fid/../include/obd_support.h:41,
> from
> drivers/staging/lustre/lustre/fid/../include/linux/obd.h:44,
> from drivers/staging/lustre/lustre/fid/../include/obd.h:40,
> from drivers/staging/lustre/lustre/fid/fid_store.c:48:
> drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h:
> In function 'truncate_complete_page':
> drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h:56:3:
> error: too few arguments to function 'page->mapping->a_ops->invalidatepage'
>page->mapping->a_ops->invalidatepage(page, 0);
>^
>
> Lots of times.
>
> Caused by the Lustre client patches interacting with commit d47992f86b30
> ("mm: change invalidatepage prototype to accept length") from the ext4
> tree.
>
> I added this merge fix patch:
>
> From 3873636f50eb89ba5e4f8e4e0523fd62f681edc8 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell
> Date: Tue, 4 Jun 2013 14:41:00 +1000
> Subject: [PATCH] staging/lustre: fix for invalidatepage() API change
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
> b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
> index f050808..67c4644 100644
> --- a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
> +++ b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
> @@ -53,7 +53,7 @@ truncate_complete_page(struct address_space *mapping,
> struct page *page)
> return;
>
> if (PagePrivate(page))
> - page->mapping->a_ops->invalidatepage(page, 0);
> + page->mapping->a_ops->invalidatepage(page, 0, PAGE_CACHE_SIZE);
>
> cancel_dirty_page(page, PAGE_SIZE);
> ClearPageMappedToDisk(page);
> --
> 1.8.1
>
> diff --git a/drivers/staging/lustre/lustre/llite/rw26.c
> b/drivers/staging/lustre/lustre/llite/rw26.c
> index 27e4e64..f1a1c5f 100644
> --- a/drivers/staging/lustre/lustre/llite/rw26.c
> +++ b/drivers/staging/lustre/lustre/llite/rw26.c
> @@ -72,7 +72,8 @@
> * aligned truncate). Lustre leaves partially truncated page in the cache,
> * relying on struct inode::i_size to limit further accesses.
> */
> -static void ll_invalidatepage(struct page *vmpage, unsigned long offset)
> +static void ll_invalidatepage(struct page *vmpage, unsigned int offset,
> + unsigned int length)
> {
> struct inode *inode;
> struct lu_env*env;
> @@ -89,7 +90,7 @@ static void ll_invalidatepage(struct page *vmpage, unsigned
> long offset)
>* below because they are run with page locked and all our io is
>* happening with locked page too
>*/
> - if (offset == 0) {
> + if (offset == 0 && length == PAGE_CACHE_SIZE) {
> env = cl_env_get();
> if (!IS_ERR(env)) {
> inode = vmpage->mapping->host;
That patch makes sense.
But then:
> But then got these errors:
>
> drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c: In function
> 'cfs_cpt_bind':
> drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c:630:3: error: implicit
> declaration of function 'set_cpus_allowed'
> [-Werror=implicit-function-declaration]
>rc = set_cpus_allowed(current, *cpumask);
>^
> cc1: some warnings being treated as errors
> drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 'key_fini':
> drivers/staging/lustre/lustre/obdclass/lu_object.c:1354:4: error: implicit
> declaration of function 'module_refcount'
> [-Werror=implicit-function-declaration]
> LINVRNT(module_refcount(key->lct_owner) > 0);
> ^
> In file included from
> drivers/staging/lustre/include/linux/libcfs/libcfs.h:203:0,
> from drivers/staging/lustre/lustre/obdclass/lu_object.c:47:
> drivers/staging/lustre/lustre/obdclass/lu_object.c: In function
> 'lu_context_keys_dump':
> drivers/staging/lustre/lustre/obdclass/lu_object.c:1936:42: error:
> dereferencing pointer to incomplete type
>key->lct_owner ? key->lct_owner->name : "",
> ^
> drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:221:41: note: in
> definition of macro '__CDEBUG'
>libcfs_debug_msg(, format, ## __VA_ARGS__); \
>
RE: A bug about system call on ARM
Hi Will, Could I know what's your git branch is mainly used for ? https://git.kernel.org/cgit/linux/kernel/git/will/linux.git I mean if the branch is used for ARM arch maintenance ? If yes, I think I can send future bugs about ARM to you directly, And do not need ping-pang in the mail list . Thanks for your help . -Original Message- From: Wang, Yalin Sent: Monday, June 03, 2013 5:58 PM To: 'Will Deacon' Cc: 'richard -rw- weinberger'; 'linux-a...@vger.kernel.org'; 'linux-kernel@vger.kernel.org'; 'linux-arm-ker...@lists.infradead.org' Subject: RE: A bug about system call on ARM Hi Will Oh I see, Thanks for your reply Yes , we are testing for it , But need some time to wait for the result , Because The stability test need some time to reproduce this issue , And this issue doesn't reproduce 100% . -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Monday, June 03, 2013 5:54 PM To: Wang, Yalin Cc: 'richard -rw- weinberger'; 'linux-a...@vger.kernel.org'; 'linux-kernel@vger.kernel.org'; 'linux-arm-ker...@lists.infradead.org' Subject: Re: A bug about system call on ARM On Mon, Jun 03, 2013 at 06:25:26AM +0100, Wang, Yalin wrote: > Hi Will, > > I have a question about this patch . > > If the user space is thumb mode, > The PC should be rewind by 2 bytes, > So the fix_up code should be > > Sub lr, lr, #2 . > > > Am I right ? No, because we don't have OABI-compat support for Thumb applications and force everything down the EABI path instead. Did you manage to test the patch? Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Modify UEFI anti-bricking code
On 06/02/2013 04:06 AM, Matthew Garrett wrote: This patch reworks the UEFI anti-bricking code, including an effective reversion of cc5a080c and 31ff2f20. It turns out that calling QueryVariableInfo() from boot services results in some firmware implementations jumping to physical addresses even after entering virtual mode, so until we have 1:1 mappings for UEFI runtime space this isn't going to work so well. Reverting these gets us back to the situation where we'd refuse to create variables on some systems because they classify deleted variables as "used" until the firmware triggers a garbage collection run, which they won't do until they reach a lower threshold. This results in it being impossible to install a bootloader, which is unhelpful. Feedback from Samsung indicates that the firmware doesn't need more than 5KB of storage space for its own purposes, so that seems like a reasonable threshold. However, there's still no guarantee that a platform will attempt garbage collection merely because it drops below this threshold. It seems that this is often only triggered if an attempt to write generates a genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to create a variable larger than the remaining space. This should fail, but if it somehow succeeds we can then immediately delete it. I've tested this on the UEFI machines I have available, but I don't have a Samsung and so can't verify that it avoids the bricking problem. This patch works well on my Dell Windows 8 logo machine. This Dell machine will use up ~2K nvram space on each reboot and do garbage collection at boot time when full. With the new 5K threshold, it is only a few reboots away from boot time garbage collection anyway. Run time garbage collection also works. But the write takes 5 seconds. Lingzhu Xiang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: DT bindings for the palmas family MFD
Hello Lee Jones,
Thanks for the quick review.
> -Original Message-
> From: Lee Jones [mailto:lee.jo...@linaro.org]
> Sent: Monday, June 03, 2013 7:49 PM
> To: J, KEERTHY
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> devicetree-disc...@lists.ozlabs.org; swar...@wwwdotorg.org;
> broo...@opensource.wolfsonmicro.com; rob.herr...@calxeda.com;
> r...@landley.net; mturque...@linaro.org; sa...@linux.intel.com;
> w...@iguana.be; lgirdw...@gmail.com; g...@slimlogic.co.uk; Kristo, Tero;
> Ian Lartey
> Subject: Re: [PATCH] mfd: DT bindings for the palmas family MFD
>
> On Mon, 03 Jun 2013, J Keerthy wrote:
>
> > From: Graeme Gregory
> >
> > Add the various binding files for the palmas family of chips. There
> is
> > a top level MFD binding then a seperate binding for regulators IP
> blocks on chips.
> >
> > Signed-off-by: Graeme Gregory
> > Signed-off-by: J Keerthy
> > Signed-off-by: Ian Lartey
> > ---
> > Documentation/devicetree/bindings/mfd/palmas.txt | 49 ++
> > .../devicetree/bindings/regulator/palmas-pmic.txt | 165
> >
> > 2 files changed, 214 insertions(+), 0 deletions(-) create mode
> > 100644 Documentation/devicetree/bindings/mfd/palmas.txt
> > create mode 100644
> > Documentation/devicetree/bindings/regulator/palmas-pmic.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
> > b/Documentation/devicetree/bindings/mfd/palmas.txt
> > new file mode 100644
> > index 000..c6c5e78
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/palmas.txt
> > @@ -0,0 +1,49 @@
> > +* palmas device tree bindings
> > +
> > +The TI palmas family current members :-
> > +twl6035 (palmas)
> > +twl6037 (palmas)
> > +tps65913 (palmas)
> > +tps65914 (palmas)
> > +
> > +Required properties:
> > +- compatible : Should be from the list
> > + ti,twl6035
> > + ti,twl6036
> > + ti,twl6037
> > + ti,tps65913
> > + ti,tps65914
> > + ti,tps80036
> > +and also the generic series names
> > + ti,palmas
> > +- interrupt-controller : palmas has its own internal IRQs
> > +- #interrupt-cells : should be set to 2 for IRQ number and flags
> > + The first cell is the IRQ number.
> > + The second cell is the flags, encoded as the trigger masks from
> > + Documentation/devicetree/bindings/interrupts.txt
> > +- interrupt-parent : The parent interrupt controller.
> > +
> > +Optional properties:
> > + ti,mux_padX : set the pad register X (1-2) to the correct muxing
> for the
> > + hardware, if not set will use muxing in OTP.
> > +
> > +Example:
> > +
> > +palmas {
>
> Should this be 'palmas@48 {', as it has an address?
>
> > + compatible = "ti,twl6035", "ti,palmas";
> > + reg = <0x48>
> > + interrupt-parent = <>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > +
> > + ti,mux-pad1 = <0>;
> > + ti,mux-pad2 = <0>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + pmic {
> > + compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
> > +
> > + };
> > +}
> > diff --git
> > a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
> > b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
> > new file mode 100644
> > index 000..f7bbc3e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
> > @@ -0,0 +1,165 @@
> > +* palmas regulator IP block devicetree bindings
> > +
> > +Required properties:
> > +- compatible : Should be from the list
> > + ti,twl6035-pmic
> > + ti,twl6036-pmic
> > + ti,twl6037-pmic
> > + ti,tps65913-pmic
> > + ti,tps65914-pmic
> > +and also the generic series names
> > + ti,palmas-pmic
> > +
> > +Optional properties:
> > +- ti,ldo6-vibrator : ldo6 is in vibrator mode
> > +
> > +Optional nodes:
> > +- regulators : should contain the constrains and init information
> for the
> > + regulators. It should contain a subnode per regulator from
> the
> > + list.
> > + For ti,palmas-pmic - smps12, smps123, smps3 depending on
> OTP,
> > + smps45, smps457, smps7 depending on varient, smps6,
> smps[8-10],
> > + ldo[1-9], ldoln, ldousb
> > +
> > + optional chip specific regulator fields :-
> > + ti,warm-reset - maintain voltage during warm
> reset(boolean)
>
> Pushing the boat out a bit here, but is it possible to reuse
> 'regulator-always-on' for this?
It is getting used below.
>
> > + ti,roof-floor - control voltage selection by pin(boolean)
>
> Is this the same as a GPIO regulator?
This is not a GPIO Regulator.
>
> If so, you might not need to add superfluous vendor specific
> properties.
>
> See: Documentation/devicetree/bindings/regulator/gpio-regulator.txt
>
> > + ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 -
> auto,
> > + 2 - eco, 3 - forced pwm
>
> I've seen lots of sleep-mode properties, can't we define a generic one?
HW specific modes.
>
> > + ti,tstep - slope control 0
Re: [PATCH 0/3] iommu/amd: IOMMU Error Reporting/Handling/Filtering
Ping On 5/22/2013 2:15 PM, suravee.suthikulpa...@amd.com wrote: From: Suravee Suthikulpanit This patch set implements framework for handling errors reported via IOMMU event log. It also implements mechanism to filter/suppress error messages when IOMMU hardware generates large amount event logs, which is often caused by devices performing invalid operations or from misconfiguring IOMMU hardware (e.g. IO_PAGE_FAULT and INVALID_DEVICE_QEQUEST"). DEVICE vs IOMMU ERRORS: === Event types in AMD IOMMU event log can be categorized as: - IOMMU error : An error which is specific to IOMMU hardware - Device error: An error which is specific to a device - Non-error : Miscelleneous events which are not classified as errors. This patch set implements frameworks for handling "IOMMU error" and "device error". For IOMMU error, the driver will log the event in dmesg and panic since the IOMMU hardware is no longer functioning. For device error, the driver will decode and log the error in dmesg based on the error logging level specified at boot time. ERROR LOGGING LEVEL: The filtering framework introduce 3 levels of event logging, "AMD_IOMMU_LOG_[DEFAULT|VERBOSE|DEBUG]". Users can specify the level via a new boot option "amd_iommu_log=[default|verbose|debug]". - default: Each error message is truncated. Filtering is enabled. - verbose: Output detail error message. Filtering is enabled. - debug : Output detail error message. Filtering is disabled. ERROR THRESHOLD LEVEL: == Error threshold is used by the log filtering logic to determine when to suppress the errors from a particular device. The threshold is defined as "the number of errors (X) over a specified period (Y sec)". When the threshold is reached, IOMMU driver will suppress subsequent error messages from the device for a predefined period (Z sec). X, Y, and Z is currently hard-coded to 10 errors, 5 sec, and 30 sec. DATA STRUCTURE: === A new structure "struct dte_err_info" is added. It contains error information specific to each device table entry (DTE). The structure is allocated dynamically per DTE when IOMMU driver handle device error for the first time. ERROR STATES and LOG FILTERING: The filtering framework define 3 device error states "NONE", "PROBATION" and "SUPPRESS". 1. From IOMMU driver intialization, all devices are in DEV_ERR_NONE state. 2. During interupt handling, IOMMU driver processes each entry in the event log. 3. If an entry is device error, the driver tags DTE with DEV_ERR_PROBATION and report error via via dmesg. 4. For non-debug mode, if the device threshold is reached, the device is moved into DEV_ERR_SUPPRESS state in which all error messages are suppressed. 5. After the suppress period has passed, the driver put the device in probation state, and errors are reported once again. If the device continues to generate errors, it will be re-suppress once the next threshold is reached. EXAMPLE OUTPUT: === AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x97040 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x97070 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x97060 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x4970 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x98840 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x98870 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x98860 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x4980 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x99040 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Event=IO_PAGE_FAULT dev=3:0.0 dom=0x1b addr=0x99060 flg=N Ex Sup M P W Pm Ill Ta AMD-Vi: Warning: IOMMU error threshold (10) reached for device=3:0.0. Suppress for 30 secs.!!! Suravee Suthikulpanit (3): iommu/amd: Adding amd_iommu_log cmdline option iommu/amd: Add error handling/reporting/filtering logic iommu/amd: Remove old event printing logic Documentation/kernel-parameters.txt | 10 + drivers/iommu/Makefile |2 +- drivers/iommu/amd_iommu.c | 85 +--- drivers/iommu/amd_iommu_fault.c | 368 +++ drivers/iommu/amd_iommu_init.c | 19 ++ drivers/iommu/amd_iommu_proto.h |6 + drivers/iommu/amd_iommu_types.h | 16 ++ 7 files changed, 426 insertions(+), 80 deletions(-) create mode 100644 drivers/iommu/amd_iommu_fault.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read
Re: [PATCH] ARM: avoid mis-detecting some V7 cores in the decompressor
On Mon, 3 Jun 2013, Stephen Boyd wrote:
> On 06/03/13 15:45, Russell King - ARM Linux wrote:
> > On Mon, Jun 03, 2013 at 03:37:39PM -0700, Stephen Boyd wrote:
> >> In my case I'm booting a kernel with textoffset = 0x208000 but RAM
> >> starts at 0x0. Does "minimum of RAM start" mean 0x0 or 0x20?
> > The basic requirement for zImage's is no less than the start of RAM
> > plus 32K. Or let me put it another way - start of writable memory
> > plus 32K.
> >
> > Whether you need an offset of 0x20 or not is not for the
> > decompressor to know. If you're having to avoid the first 0x20
> > bytes of memory for some reason (eg, secure firmware or DSP needs
> > it left free) then there's no way for the decompressor to know that,
> > so it's irrelevant.
> >
> > So, lets say that your platform has a DSP which needs the first 0x20
> > bytes left free. So the boot loader _already_ needs to know to load
> > the image not at zero, but above 0x20. The additional 32K
> > requirement is really nothing new and so should be treated in just the
> > same way.
> >
> > Leave at least 32K of usable memory below the zImage at all times.
>
> Understood. On my device writeable RAM actually starts at 0x0 but I have
> compiled in support for devices which don't have writeable memory at
> 0x0, instead they have writeable memory starting at 0x20. Because I
> have a kernel supporting more than one device with differing memory
> layouts I run into this problem. The same problem will occur to any
> devices in the multi-platform kernel when a device with unwriteable
> memory near the bottom (such as MSM8960) joins the multi-platform defconfig.
>
> Let me try to word it in your example. I have compiled in support for a
> platform that has a DSP which needs the first 0x20 bytes left free.
> I have also compiled in support for a platform that doesn't have this
> requirement. I plan to run the zImage on the second platform (the one
> without the DSP requirement). The bootloader I'm running this zImage on
> has no idea that I've compiled in support for the other platform with
> the DSP requirement so it assumes it can load the zImage at the start of
> RAM (0x0) plus 32K. This is bad because then the page tables get written
> into my compressed data and it fails to decompress.
I've looked at the code and I think that #1 in your initial options is
probably best here. I agree with Russell about #2 being way too complex
for only this case.
So, right before calling into cache_on, you could test if r4 - 16K >= pc
and r4 < pc + (_end - .) then skip cache_on.
Something like this untested patch:
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 9a94f344df..9e0dbbccdd 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -182,7 +182,16 @@ not_angel:
ldr r4, =zreladdr
#endif
- bl cache_on
+ /* Set up a page table only if we don't overwrite ourself */
+ ldr r0, 1f
+ add r0, r0, pc
+ cmp r4, r0
+ mov r0, pc
+ cmpcc r0, r4
+ blcscache_on
+ b restart
+ .align 2
+1: .word _end - . + 0x4000
restart: adr r0, LC0
ldmia r0, {r1, r2, r3, r6, r10, r11, r12}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/16] tools lib traceevent: Get rid of unused gui target
From: Namhyung Kim It's came from trace-cmd's kernelshark which is not a part of libtraceevent. Acked-by: Steven Rostedt Cc: Frederic Weisbecker Signed-off-by: Namhyung Kim --- tools/lib/traceevent/Makefile | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/tools/lib/traceevent/Makefile b/tools/lib/traceevent/Makefile index fd7510d99583..4505de874929 100644 --- a/tools/lib/traceevent/Makefile +++ b/tools/lib/traceevent/Makefile @@ -71,10 +71,7 @@ $(if $(BUILD_OUTPUT),, \ all: sub-make -gui: force - $(call build_output, all_cmd) - -$(filter-out gui,$(MAKECMDGOALS)): sub-make +$(MAKECMDGOALS): sub-make sub-make: force $(call build_output, $(MAKECMDGOALS)) @@ -253,9 +250,6 @@ define check_deps $(RM) $@. endef -$(gui_deps): ks_version.h -$(non_gui_deps): tc_version.h - $(all_deps): .%.d: $(src)/%.c $(Q)$(call check_deps) -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/16] perf util: Make file/host_bigendian variable local
From: Namhyung Kim They're not used anywhere, just make them local variables. Signed-off-by: Namhyung Kim --- tools/perf/util/trace-event-read.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/trace-event-read.c b/tools/perf/util/trace-event-read.c index 6166294d7f22..0dd9fbda88eb 100644 --- a/tools/perf/util/trace-event-read.c +++ b/tools/perf/util/trace-event-read.c @@ -39,9 +39,6 @@ static int input_fd; -int file_bigendian; -int host_bigendian; - static ssize_t trace_data_size; static bool repipe; @@ -342,6 +339,8 @@ ssize_t trace_report(int fd, struct pevent **ppevent, bool __repipe) int show_funcs = 0; int show_printk = 0; ssize_t size = -1; + int file_bigendian; + int host_bigendian; int file_long_size; int file_page_size; struct pevent *pevent; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/16] perf util: Save page size in a trace file to pevent
From: Namhyung Kim We now have page_size field in struct pevent, save the actual size of the system. Signed-off-by: Namhyung Kim --- tools/perf/util/trace-event-read.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/trace-event-read.c b/tools/perf/util/trace-event-read.c index af215c0d2379..c6b491bcb8cd 100644 --- a/tools/perf/util/trace-event-read.c +++ b/tools/perf/util/trace-event-read.c @@ -349,6 +349,7 @@ ssize_t trace_report(int fd, struct pevent **ppevent, bool __repipe) int show_funcs = 0; int show_printk = 0; ssize_t size = -1; + int file_page_size; struct pevent *pevent; int err; @@ -393,10 +394,12 @@ ssize_t trace_report(int fd, struct pevent **ppevent, bool __repipe) goto out; long_size = buf[0]; - page_size = read4(pevent); - if (!page_size) + file_page_size = read4(pevent); + if (!file_page_size) goto out; + pevent_set_page_size(pevent, file_page_size); + err = read_header_files(pevent); if (err) goto out; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/16] tools lib traceevent: Add page_size field to pevent
From: Namhyung Kim
The page size of traced system can be different than current system's
because the recorded data file might be analyzed in a different machine.
In this case we should use original page size of traced system when
accessing the data file, so this information needs to be saved.
Cc: Steven Rostedt
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/event-parse.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index 39f0c1dca915..c37b2026d04a 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -400,6 +400,7 @@ struct pevent {
int cpus;
int long_size;
+ int page_size;
struct cmdline *cmdlines;
struct cmdline_list *cmdlist;
@@ -621,6 +622,16 @@ static inline void pevent_set_long_size(struct pevent
*pevent, int long_size)
pevent->long_size = long_size;
}
+static inline int pevent_get_page_size(struct pevent *pevent)
+{
+ return pevent->page_size;
+}
+
+static inline void pevent_set_page_size(struct pevent *pevent, int _page_size)
+{
+ pevent->page_size = _page_size;
+}
+
static inline int pevent_is_file_bigendian(struct pevent *pevent)
{
return pevent->file_bigendian;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/16] perf util: Save long size of traced system
From: Namhyung Kim Save size of long type of system to struct pevent. Since original static variable was not used anywhere, just get rid of it. Signed-off-by: Namhyung Kim --- tools/perf/util/trace-event-read.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/tools/perf/util/trace-event-read.c b/tools/perf/util/trace-event-read.c index c6b491bcb8cd..6166294d7f22 100644 --- a/tools/perf/util/trace-event-read.c +++ b/tools/perf/util/trace-event-read.c @@ -41,7 +41,6 @@ static int input_fd; int file_bigendian; int host_bigendian; -static int long_size; static ssize_t trace_data_size; static bool repipe; @@ -231,12 +230,6 @@ static int read_header_files(struct pevent *pevent) size = read8(pevent); skip(size); - /* -* The size field in the page is of type long, -* use that instead, since it represents the kernel. -*/ - long_size = header_page_size_size; - if (do_read(buf, 13) < 0) return -1; @@ -349,6 +342,7 @@ ssize_t trace_report(int fd, struct pevent **ppevent, bool __repipe) int show_funcs = 0; int show_printk = 0; ssize_t size = -1; + int file_long_size; int file_page_size; struct pevent *pevent; int err; @@ -392,12 +386,13 @@ ssize_t trace_report(int fd, struct pevent **ppevent, bool __repipe) if (do_read(buf, 1) < 0) goto out; - long_size = buf[0]; + file_long_size = buf[0]; file_page_size = read4(pevent); if (!file_page_size) goto out; + pevent_set_long_size(pevent, file_long_size); pevent_set_page_size(pevent, file_page_size); err = read_header_files(pevent); -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/16] tools lib traceevent: Port kbuffer parser routines
From: Namhyung Kim
kbuffer code is for parsing ftrace ring-buffer binary data and used
for trace-cmd. Move the code here in order to be used more widely.
Original-patch-by: Steven Rostedt
Acked-by: Steven Rostedt
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/Makefile| 1 +
tools/lib/traceevent/kbuffer-parse.c | 732 +++
tools/lib/traceevent/kbuffer.h | 67
3 files changed, 800 insertions(+)
create mode 100644 tools/lib/traceevent/kbuffer-parse.c
create mode 100644 tools/lib/traceevent/kbuffer.h
diff --git a/tools/lib/traceevent/Makefile b/tools/lib/traceevent/Makefile
index 4505de874929..0794acca46a3 100644
--- a/tools/lib/traceevent/Makefile
+++ b/tools/lib/traceevent/Makefile
@@ -181,6 +181,7 @@ $(obj)/%.o: $(src)/%.c
$(Q)$(call do_compile)
PEVENT_LIB_OBJS = event-parse.o trace-seq.o parse-filter.o parse-utils.o
+PEVENT_LIB_OBJS += kbuffer-parse.o
ALL_OBJS = $(PEVENT_LIB_OBJS)
diff --git a/tools/lib/traceevent/kbuffer-parse.c
b/tools/lib/traceevent/kbuffer-parse.c
new file mode 100644
index ..dcc665228c71
--- /dev/null
+++ b/tools/lib/traceevent/kbuffer-parse.c
@@ -0,0 +1,732 @@
+/*
+ * Copyright (C) 2009, 2010 Red Hat Inc, Steven Rostedt
+ *
+ * ~~
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License (not later!)
+ *
+ * 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 Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA.
+ *
+ * ~~
+ */
+#include
+#include
+#include
+
+#include "kbuffer.h"
+
+#define MISSING_EVENTS (1 << 31)
+#define MISSING_STORED (1 << 30)
+
+#define COMMIT_MASK ((1 << 27) - 1)
+
+enum {
+ KBUFFER_FL_HOST_BIG_ENDIAN = (1<<0),
+ KBUFFER_FL_BIG_ENDIAN = (1<<1),
+ KBUFFER_FL_LONG_8 = (1<<2),
+ KBUFFER_FL_OLD_FORMAT = (1<<3),
+};
+
+#define ENDIAN_MASK (KBUFFER_FL_HOST_BIG_ENDIAN | KBUFFER_FL_BIG_ENDIAN)
+
+/** kbuffer
+ * @timestamp - timestamp of current event
+ * @lost_events- # of lost events between this subbuffer and
previous
+ * @flags - special flags of the kbuffer
+ * @subbuffer - pointer to the sub-buffer page
+ * @data - pointer to the start of data on the sub-buffer page
+ * @index - index from @data to the @curr event data
+ * @curr - offset from @data to the start of current event
+ *(includes metadata)
+ * @next - offset from @data to the start of next event
+ * @size - The size of data on @data
+ * @start - The offset from @subbuffer where @data lives
+ *
+ * @read_4 - Function to read 4 raw bytes (may swap)
+ * @read_8 - Function to read 8 raw bytes (may swap)
+ * @read_long - Function to read a long word (4 or 8 bytes with
needed swap)
+ */
+struct kbuffer {
+ unsigned long long timestamp;
+ long long lost_events;
+ unsigned long flags;
+ void*subbuffer;
+ void*data;
+ unsigned intindex;
+ unsigned intcurr;
+ unsigned intnext;
+ unsigned intsize;
+ unsigned intstart;
+
+ unsigned int (*read_4)(void *ptr);
+ unsigned long long (*read_8)(void *ptr);
+ unsigned long long (*read_long)(struct kbuffer *kbuf, void *ptr);
+ int (*next_event)(struct kbuffer *kbuf);
+};
+
+static void *zmalloc(size_t size)
+{
+ return calloc(1, size);
+}
+
+static int host_is_bigendian(void)
+{
+ unsigned char str[] = { 0x1, 0x2, 0x3, 0x4 };
+ unsigned int *ptr;
+
+ ptr = (unsigned int *)str;
+ return *ptr == 0x01020304;
+}
+
+static int do_swap(struct kbuffer *kbuf)
+{
+ return ((kbuf->flags & KBUFFER_FL_HOST_BIG_ENDIAN) + kbuf->flags) &
+ ENDIAN_MASK;
+}
+
+static unsigned long long __read_8(void *ptr)
+{
+ unsigned long long data = *(unsigned long long *)ptr;
+
+ return data;
+}
+
+static unsigned long long __read_8_sw(void *ptr)
+{
+ unsigned long long data = *(unsigned long long *)ptr;
+ unsigned long long swap;
+
+ swap = ((data & 0xffULL) << 56) |
+
[PATCH] jfs: Convert jfs_error to jfs_sb_err
Use a more current logging style.
Rename function jfs_error to jfs_sb_err.
Add __printf format and argument verification.
Remove embedded function names from formats.
Add %pf, __builtin_return_address(0) to jfs_sb_err.
Add newlines to formats for kernel style consistency.
(One format already had an erroneous newline)
Coalesce formats and align arguments.
Object size reduced ~1KiB.
$ size fs/jfs/built-in.o*
textdata bss dec hex filename
201891 35488 63936 301315 49903 fs/jfs/built-in.o.new
202821 35488 64192 302501 49da5 fs/jfs/built-in.o.old
Signed-off-by: Joe Perches
---
fs/jfs/jfs_dmap.c | 94 -
fs/jfs/jfs_dtree.c | 45 ---
fs/jfs/jfs_extent.c | 2 +-
fs/jfs/jfs_imap.c | 89 +-
fs/jfs/jfs_metapage.c | 9 +++--
fs/jfs/jfs_superblock.h | 3 +-
fs/jfs/jfs_txnmgr.c | 2 +-
fs/jfs/jfs_xtree.c | 64 -
fs/jfs/namei.c | 4 +--
fs/jfs/resize.c | 2 +-
fs/jfs/super.c | 22 +++-
fs/jfs/xattr.c | 4 +--
12 files changed, 158 insertions(+), 182 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index 9a55f53..7eafc30 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -346,8 +346,7 @@ int dbFree(struct inode *ip, s64 blkno, s64 nblocks)
printk(KERN_ERR "blkno = %Lx, nblocks = %Lx\n",
(unsigned long long) blkno,
(unsigned long long) nblocks);
- jfs_error(ip->i_sb,
- "dbFree: block to be freed is outside the map");
+ jfs_sb_err(ip->i_sb, "block to be freed is outside the map\n");
return -EIO;
}
@@ -384,7 +383,7 @@ int dbFree(struct inode *ip, s64 blkno, s64 nblocks)
/* free the blocks. */
if ((rc = dbFreeDmap(bmp, dp, blkno, nb))) {
- jfs_error(ip->i_sb, "dbFree: error in block map\n");
+ jfs_sb_err(ip->i_sb, "error in block map\n");
release_metapage(mp);
IREAD_UNLOCK(ipbmap);
return (rc);
@@ -441,8 +440,7 @@ dbUpdatePMap(struct inode *ipbmap,
printk(KERN_ERR "blkno = %Lx, nblocks = %Lx\n",
(unsigned long long) blkno,
(unsigned long long) nblocks);
- jfs_error(ipbmap->i_sb,
- "dbUpdatePMap: blocks are outside the map");
+ jfs_sb_err(ipbmap->i_sb, "blocks are outside the map\n");
return -EIO;
}
@@ -726,7 +724,7 @@ int dbAlloc(struct inode *ip, s64 hint, s64 nblocks, s64 *
results)
/* the hint should be within the map */
if (hint >= mapSize) {
- jfs_error(ip->i_sb, "dbAlloc: the hint is outside the map");
+ jfs_sb_err(ip->i_sb, "the hint is outside the map\n");
return -EIO;
}
@@ -1057,8 +1055,7 @@ static int dbExtend(struct inode *ip, s64 blkno, s64
nblocks, s64 addnblocks)
bmp = sbi->bmap;
if (lastblkno < 0 || lastblkno >= bmp->db_mapsize) {
IREAD_UNLOCK(ipbmap);
- jfs_error(ip->i_sb,
- "dbExtend: the block is outside the filesystem");
+ jfs_sb_err(ip->i_sb, "the block is outside the filesystem\n");
return -EIO;
}
@@ -1134,8 +1131,7 @@ static int dbAllocNext(struct bmap * bmp, struct dmap *
dp, s64 blkno,
u32 mask;
if (dp->tree.leafidx != cpu_to_le32(LEAFIND)) {
- jfs_error(bmp->db_ipbmap->i_sb,
- "dbAllocNext: Corrupt dmap page");
+ jfs_sb_err(bmp->db_ipbmap->i_sb, "Corrupt dmap page\n");
return -EIO;
}
@@ -1265,8 +1261,7 @@ dbAllocNear(struct bmap * bmp,
s8 *leaf;
if (dp->tree.leafidx != cpu_to_le32(LEAFIND)) {
- jfs_error(bmp->db_ipbmap->i_sb,
- "dbAllocNear: Corrupt dmap page");
+ jfs_sb_err(bmp->db_ipbmap->i_sb, "Corrupt dmap page\n");
return -EIO;
}
@@ -1380,9 +1375,8 @@ dbAllocAG(struct bmap * bmp, int agno, s64 nblocks, int
l2nb, s64 * results)
* allocation group size.
*/
if (l2nb > bmp->db_agl2size) {
- jfs_error(bmp->db_ipbmap->i_sb,
- "dbAllocAG: allocation request is larger than the "
- "allocation group size");
+ jfs_sb_err(bmp->db_ipbmap->i_sb,
+ "allocation request is larger than the allocation
group size\n");
return -EIO;
}
@@ -1416,8 +1410,8 @@ dbAllocAG(struct bmap * bmp, int agno, s64 nblocks, int
l2nb, s64 * results)
printk(KERN_ERR "blkno = %Lx,
[PATCH 10/16] perf util: Skip reading header_event file
From: Namhyung Kim
It seems perf does not parse header_event file so we can skip it as we
do for header_page file.
Signed-off-by: Namhyung Kim
---
tools/perf/util/trace-event-read.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/tools/perf/util/trace-event-read.c
b/tools/perf/util/trace-event-read.c
index 0dd9fbda88eb..fa45fca2a2d3 100644
--- a/tools/perf/util/trace-event-read.c
+++ b/tools/perf/util/trace-event-read.c
@@ -212,7 +212,6 @@ static int read_ftrace_printk(struct pevent *pevent)
static int read_header_files(struct pevent *pevent)
{
unsigned long long size;
- char *header_event;
char buf[BUFSIZ];
int ret = 0;
@@ -236,14 +235,8 @@ static int read_header_files(struct pevent *pevent)
}
size = read8(pevent);
- header_event = malloc(size);
- if (header_event == NULL)
- return -1;
-
- if (do_read(header_event, size) < 0)
- ret = -1;
+ skip(size);
- free(header_event);
return ret;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/16] perf util: Move latency_format variable to builtin-script.c
From: Namhyung Kim
It's the only user of the variable, so move it.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-script.c | 1 +
tools/perf/util/trace-event-parse.c | 2 --
tools/perf/util/trace-event.h | 1 -
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 92d4658f56fb..3de8979fe87d 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -24,6 +24,7 @@ static u64last_timestamp;
static u64 nr_unordered;
extern const struct option record_options[];
static boolno_callchain;
+static boollatency_format;
static boolsystem_wide;
static const char *cpu_list;
static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
diff --git a/tools/perf/util/trace-event-parse.c
b/tools/perf/util/trace-event-parse.c
index 0deae885c7ba..fe7a27d67d2b 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -28,8 +28,6 @@
#include "util.h"
#include "trace-event.h"
-bool latency_format;
-
struct pevent *read_trace_init(int file_bigendian, int host_bigendian)
{
struct pevent *pevent = pevent_alloc();
diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
index 10d6e7b202c5..96ad22f98726 100644
--- a/tools/perf/util/trace-event.h
+++ b/tools/perf/util/trace-event.h
@@ -10,7 +10,6 @@ struct perf_sample;
union perf_event;
struct perf_tool;
-extern bool latency_format;
extern struct pevent *perf_pevent;
enum {
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/16] perf util: Rename read_*() functions in trace-event-info.c
From: Namhyung Kim
It's confusing to have same name for two difference functions which
does something opposite way. Since what they do in this file is read
*AND* writing some of tracing metadata files, rename them to
record_*() looks better to me.
Signed-off-by: Namhyung Kim
---
tools/perf/util/trace-event-info.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/trace-event-info.c
b/tools/perf/util/trace-event-info.c
index 3917eb9a8479..9648175e2a1c 100644
--- a/tools/perf/util/trace-event-info.c
+++ b/tools/perf/util/trace-event-info.c
@@ -160,7 +160,7 @@ out:
return err;
}
-static int read_header_files(void)
+static int record_header_files(void)
{
char *path;
struct stat st;
@@ -299,7 +299,7 @@ out:
return err;
}
-static int read_ftrace_files(struct tracepoint_path *tps)
+static int record_ftrace_files(struct tracepoint_path *tps)
{
char *path;
int ret;
@@ -328,7 +328,7 @@ static bool system_in_tp_list(char *sys, struct
tracepoint_path *tps)
return false;
}
-static int read_event_files(struct tracepoint_path *tps)
+static int record_event_files(struct tracepoint_path *tps)
{
struct dirent *dent;
struct stat st;
@@ -403,7 +403,7 @@ out:
return err;
}
-static int read_proc_kallsyms(void)
+static int record_proc_kallsyms(void)
{
unsigned int size;
const char *path = "/proc/kallsyms";
@@ -421,7 +421,7 @@ static int read_proc_kallsyms(void)
return record_file(path, 4);
}
-static int read_ftrace_printk(void)
+static int record_ftrace_printk(void)
{
unsigned int size;
char *path;
@@ -583,19 +583,19 @@ struct tracing_data *tracing_data_get(struct list_head
*pattrs,
err = tracing_data_header();
if (err)
goto out;
- err = read_header_files();
+ err = record_header_files();
if (err)
goto out;
- err = read_ftrace_files(tps);
+ err = record_ftrace_files(tps);
if (err)
goto out;
- err = read_event_files(tps);
+ err = record_event_files(tps);
if (err)
goto out;
- err = read_proc_kallsyms();
+ err = record_proc_kallsyms();
if (err)
goto out;
- err = read_ftrace_printk();
+ err = record_ftrace_printk();
out:
/*
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET 00/16] perf tools: Cleanups on tracepoint handling
Hello, This patchset is a resend version of previous work and basis of upcoming perf ftrace patchset. Although I saw no issue on this series when I posted earlier, it'd be great if Steve or others take a look at it again and give comments. I also updated 'perf/cleanup' branch on my tree at: git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Namhyung Kim (16): tools lib traceevent: Remove unused install targets tools lib traceevent: Get rid of unused gui target tools lib traceevent: Add const qualifier to string arguments tools lib traceevent: Add trace_seq_reset() tools lib traceevent: Add page_size field to pevent tools lib traceevent: Port kbuffer parser routines perf util: Save page size in a trace file to pevent perf util: Save long size of traced system perf util: Make file/host_bigendian variable local perf util: Skip reading header_event file perf util: Parse header_page to get proper long size perf util: Get rid of unused header_page_* variables perf util: Move latency_format variable to builtin-script.c perf util: Rename read_*() functions in trace-event-info.c perf util: No need to call read_trace_init() in tracing_data_header() perf util: Remove unused enum and macro in trace-event.h tools/lib/traceevent/Makefile| 18 +- tools/lib/traceevent/event-parse.c | 7 +- tools/lib/traceevent/event-parse.h | 15 +- tools/lib/traceevent/kbuffer-parse.c | 732 +++ tools/lib/traceevent/kbuffer.h | 67 tools/lib/traceevent/trace-seq.c | 13 + tools/perf/builtin-script.c | 1 + tools/perf/util/trace-event-info.c | 22 +- tools/perf/util/trace-event-parse.c | 6 - tools/perf/util/trace-event-read.c | 52 ++- tools/perf/util/trace-event.h| 15 - 11 files changed, 875 insertions(+), 73 deletions(-) create mode 100644 tools/lib/traceevent/kbuffer-parse.c create mode 100644 tools/lib/traceevent/kbuffer.h -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/16] tools lib traceevent: Add const qualifier to string arguments
From: Namhyung Kim
If pevent_register_event_handler() received a string literal as
@sys_name or @event_name parameter, it emitted a warning about const
qualifier removal. Since they're not modified in the function we can
make it have const qualifier.
Acked-by: Steven Rostedt
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/event-parse.c | 7 +++
tools/lib/traceevent/event-parse.h | 3 ++-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 82b0606dcb8a..d1c2a6a4cd32 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -5450,10 +5450,9 @@ int pevent_register_print_function(struct pevent *pevent,
* If @id is >= 0, then it is used to find the event.
* else @sys_name and @event_name are used.
*/
-int pevent_register_event_handler(struct pevent *pevent,
- int id, char *sys_name, char *event_name,
- pevent_event_handler_func func,
- void *context)
+int pevent_register_event_handler(struct pevent *pevent, int id,
+ const char *sys_name, const char *event_name,
+ pevent_event_handler_func func, void *context)
{
struct event_format *event;
struct event_handler *handle;
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index 7be7e89533e4..bfceab948f22 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -561,7 +561,8 @@ int pevent_print_num_field(struct trace_seq *s, const char
*fmt,
struct event_format *event, const char *name,
struct pevent_record *record, int err);
-int pevent_register_event_handler(struct pevent *pevent, int id, char
*sys_name, char *event_name,
+int pevent_register_event_handler(struct pevent *pevent, int id,
+ const char *sys_name, const char *event_name,
pevent_event_handler_func func, void
*context);
int pevent_register_print_function(struct pevent *pevent,
pevent_func_handler func,
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/16] tools lib traceevent: Remove unused install targets
From: Namhyung Kim The html_install, img_install, install_plugin and install_python are unused in the Makefile. Get rid of them. Acked-by: Steven Rostedt Cc: Frederic Weisbecker Signed-off-by: Namhyung Kim --- tools/lib/traceevent/Makefile | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/tools/lib/traceevent/Makefile b/tools/lib/traceevent/Makefile index 0b0a90787db6..fd7510d99583 100644 --- a/tools/lib/traceevent/Makefile +++ b/tools/lib/traceevent/Makefile @@ -39,13 +39,8 @@ bindir_relative = bin bindir = $(prefix)/$(bindir_relative) man_dir = $(prefix)/share/man man_dir_SQ = '$(subst ','\'',$(man_dir))' -html_install = $(prefix)/share/kernelshark/html -html_install_SQ = '$(subst ','\'',$(html_install))' -img_install = $(prefix)/share/kernelshark/html/images -img_install_SQ = '$(subst ','\'',$(img_install))' -export man_dir man_dir_SQ html_install html_install_SQ INSTALL -export img_install img_install_SQ +export man_dir man_dir_SQ INSTALL export DESTDIR DESTDIR_SQ # copy a bit from Linux kbuild @@ -300,7 +295,7 @@ define do_install $(INSTALL) $1 '$(DESTDIR_SQ)$2' endef -install_lib: all_cmd install_plugins install_python +install_lib: all_cmd $(Q)$(call do_install,$(LIB_FILE),$(bindir_SQ)) install: install_lib -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/16] perf util: Get rid of unused header_page_* variables
From: Namhyung Kim They're not used anywhere and same information is kept in a pevent already. So let's get rid of them. Signed-off-by: Namhyung Kim --- tools/perf/util/trace-event-parse.c | 4 tools/perf/util/trace-event.h | 4 2 files changed, 8 deletions(-) diff --git a/tools/perf/util/trace-event-parse.c b/tools/perf/util/trace-event-parse.c index 4454835a9ebc..0deae885c7ba 100644 --- a/tools/perf/util/trace-event-parse.c +++ b/tools/perf/util/trace-event-parse.c @@ -28,10 +28,6 @@ #include "util.h" #include "trace-event.h" -int header_page_size_size; -int header_page_ts_size; -int header_page_data_offset; - bool latency_format; struct pevent *read_trace_init(int file_bigendian, int host_bigendian) diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h index 1978c398ad87..10d6e7b202c5 100644 --- a/tools/perf/util/trace-event.h +++ b/tools/perf/util/trace-event.h @@ -10,10 +10,6 @@ struct perf_sample; union perf_event; struct perf_tool; -extern int header_page_size_size; -extern int header_page_ts_size; -extern int header_page_data_offset; - extern bool latency_format; extern struct pevent *perf_pevent; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/16] perf util: No need to call read_trace_init() in tracing_data_header()
From: Namhyung Kim It's useless to call the read_trace_init() function at this time as we don't need a returned pevent and it makes me confusing. :) Signed-off-by: Namhyung Kim --- tools/perf/util/trace-event-info.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/perf/util/trace-event-info.c b/tools/perf/util/trace-event-info.c index 9648175e2a1c..e85cbcf298f3 100644 --- a/tools/perf/util/trace-event-info.c +++ b/tools/perf/util/trace-event-info.c @@ -520,8 +520,6 @@ static int tracing_data_header(void) else buf[0] = 0; - read_trace_init(buf[0], buf[0]); - if (write(output_fd, buf, 1) != 1) return -1; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/16] perf util: Parse header_page to get proper long size
From: Namhyung Kim
The header_page file describes the format of the ring buffer page
which is used by ftrace (not perf). And size of "commit" field (I
guess it's older name was 'size') represents the real size of long
type used for kernel. So update the pevent's long size.
Signed-off-by: Namhyung Kim
---
tools/perf/util/trace-event-read.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/trace-event-read.c
b/tools/perf/util/trace-event-read.c
index fa45fca2a2d3..f2112270c663 100644
--- a/tools/perf/util/trace-event-read.c
+++ b/tools/perf/util/trace-event-read.c
@@ -212,6 +212,7 @@ static int read_ftrace_printk(struct pevent *pevent)
static int read_header_files(struct pevent *pevent)
{
unsigned long long size;
+ char *header_page;
char buf[BUFSIZ];
int ret = 0;
@@ -224,7 +225,26 @@ static int read_header_files(struct pevent *pevent)
}
size = read8(pevent);
- skip(size);
+
+ header_page = malloc(size);
+ if (header_page == NULL)
+ return -1;
+
+ if (do_read(header_page, size) < 0) {
+ pr_debug("did not read header page");
+ free(header_page);
+ return -1;
+ }
+
+ if (!pevent_parse_header_page(pevent, header_page, size,
+ pevent_get_long_size(pevent))) {
+ /*
+* The commit field in the page is of type long,
+* use that instead, since it represents the kernel.
+*/
+ pevent_set_long_size(pevent, pevent->header_page_size_size);
+ }
+ free(header_page);
if (do_read(buf, 13) < 0)
return -1;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/16] perf util: Remove unused enum and macro in trace-event.h
From: Namhyung Kim
They're internals of ftrace ring-buffer and not used in perf code
directly. As it now resides on libtraceevent/kbuffer.h, just get
rid of them.
Signed-off-by: Namhyung Kim
---
tools/perf/util/trace-event.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
index 96ad22f98726..929baae82f71 100644
--- a/tools/perf/util/trace-event.h
+++ b/tools/perf/util/trace-event.h
@@ -12,16 +12,6 @@ struct perf_tool;
extern struct pevent *perf_pevent;
-enum {
- RINGBUF_TYPE_PADDING= 29,
- RINGBUF_TYPE_TIME_EXTEND= 30,
- RINGBUF_TYPE_TIME_STAMP = 31,
-};
-
-#ifndef TS_SHIFT
-#define TS_SHIFT 27
-#endif
-
int bigendian(void);
struct pevent *read_trace_init(int file_bigendian, int host_bigendian);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/16] tools lib traceevent: Add trace_seq_reset()
From: Namhyung Kim
Sometimes it'd be useful if existing trace_seq can be reused. But
currently it's impossible since there's no API to reset the trace_seq.
Let's add trace_seq_reset() for this case.
Acked-by: Steven Rostedt
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/event-parse.h | 1 +
tools/lib/traceevent/trace-seq.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index bfceab948f22..39f0c1dca915 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -69,6 +69,7 @@ struct trace_seq {
};
void trace_seq_init(struct trace_seq *s);
+void trace_seq_reset(struct trace_seq *s);
void trace_seq_destroy(struct trace_seq *s);
extern int trace_seq_printf(struct trace_seq *s, const char *fmt, ...)
diff --git a/tools/lib/traceevent/trace-seq.c b/tools/lib/traceevent/trace-seq.c
index a57db805136a..d7f2e68bc5b9 100644
--- a/tools/lib/traceevent/trace-seq.c
+++ b/tools/lib/traceevent/trace-seq.c
@@ -49,6 +49,19 @@ void trace_seq_init(struct trace_seq *s)
}
/**
+ * trace_seq_reset - re-initialize the trace_seq structure
+ * @s: a pointer to the trace_seq structure to reset
+ */
+void trace_seq_reset(struct trace_seq *s)
+{
+ if (!s)
+ return;
+ TRACE_SEQ_CHECK(s);
+ s->len = 0;
+ s->readpos = 0;
+}
+
+/**
* trace_seq_destroy - free up memory of a trace_seq
* @s: a pointer to the trace_seq to free the buffer
*
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET 00/16] perf tools: Cleanups on tracepoint handling
Hello, This patchset is a resend version of previous work and basis of upcoming perf ftrace patchset. Although I saw no issue on this series when I posted earlier, it'd be great if Steve or others take a look at it again and give comments. I also updated 'perf/cleanup' branch on my tree at: git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Namhyung Kim (16): tools lib traceevent: Remove unused install targets tools lib traceevent: Get rid of unused gui target tools lib traceevent: Add const qualifier to string arguments tools lib traceevent: Add trace_seq_reset() tools lib traceevent: Add page_size field to pevent tools lib traceevent: Port kbuffer parser routines perf util: Save page size in a trace file to pevent perf util: Save long size of traced system perf util: Make file/host_bigendian variable local perf util: Skip reading header_event file perf util: Parse header_page to get proper long size perf util: Get rid of unused header_page_* variables perf util: Move latency_format variable to builtin-script.c perf util: Rename read_*() functions in trace-event-info.c perf util: No need to call read_trace_init() in tracing_data_header() perf util: Remove unused enum and macro in trace-event.h tools/lib/traceevent/Makefile| 18 +- tools/lib/traceevent/event-parse.c | 7 +- tools/lib/traceevent/event-parse.h | 15 +- tools/lib/traceevent/kbuffer-parse.c | 732 +++ tools/lib/traceevent/kbuffer.h | 67 tools/lib/traceevent/trace-seq.c | 13 + tools/perf/builtin-script.c | 1 + tools/perf/util/trace-event-info.c | 22 +- tools/perf/util/trace-event-parse.c | 6 - tools/perf/util/trace-event-read.c | 52 ++- tools/perf/util/trace-event.h| 15 - 11 files changed, 875 insertions(+), 73 deletions(-) create mode 100644 tools/lib/traceevent/kbuffer-parse.c create mode 100644 tools/lib/traceevent/kbuffer.h -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] cpufreq: Remove unused function __cpufreq_driver_getavg
On 4 June 2013 01:18, Stratos Karafotis wrote: > Calculation of frequency target in ondemand governor changed and it is s/frequency target/target frequency > independent from measured average frequency. > > Remove unused__cpufreq_driver_getavg function and getavg member from > cpufreq_driver struct. Also, remove the callback getavg in > acpi_cpufreq_driver. > > Signed-off-by: Stratos Karafotis > --- > drivers/cpufreq/Makefile | 2 +- > drivers/cpufreq/acpi-cpufreq.c | 5 - > drivers/cpufreq/cpufreq.c | 12 > include/linux/cpufreq.h| 6 -- > 4 files changed, 1 insertion(+), 24 deletions(-) > > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > index 6ad0b91..aebd4ef 100644 > --- a/drivers/cpufreq/Makefile > +++ b/drivers/cpufreq/Makefile > @@ -23,7 +23,7 @@ obj-$(CONFIG_GENERIC_CPUFREQ_CPU0)+= cpufreq-cpu0.o > # powernow-k8 can load then. ACPI is preferred to all other > hardware-specific drivers. > # speedstep-* is preferred over p4-clockmod. > > -obj-$(CONFIG_X86_ACPI_CPUFREQ) += acpi-cpufreq.o mperf.o Should this be done in 3/3 ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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, v2] PM / Runtime: Rework the "runtime idle" helper routine
On 06/03/2013 05:52 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The "runtime idle" helper routine, rpm_idle(), currently ignores
> return values from .runtime_idle() callbacks executed by it.
> However, it turns out that many subsystems use
> pm_generic_runtime_idle() which checks the return value of the
> driver's callback and executes pm_runtime_suspend() for the device
> unless that value is not 0. If that logic is moved to rpm_idle()
> instead, pm_generic_runtime_idle() can be dropped and its users
> will not need any .runtime_idle() callbacks any more.
>
> Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
> routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
> ata_port_runtime_idle(), respectively, as well as a few drivers'
> ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
> been returned by the .runtime_idle() callback executed by it.
For ATA and SCSI part:
Reviewed-by: Aaron Lu
Thanks,
Aaron
>
> To reduce overall code bloat, make the changes described above.
>
> Tested-by: Mika Westerberg
> Tested-by: Kevin Hilman
> Signed-off-by: Rafael J. Wysocki
> Acked-by: Kevin Hilman
> Reviewed-by: Ulf Hansson
> ---
> Documentation/power/runtime_pm.txt |5 -
> arch/arm/mach-omap2/omap_device.c |7 +--
> drivers/acpi/device_pm.c |1 -
> drivers/amba/bus.c |2 +-
> drivers/ata/libata-core.c |2 +-
> drivers/base/platform.c|1 -
> drivers/base/power/domain.c|1 -
> drivers/base/power/generic_ops.c | 23 ---
> drivers/base/power/runtime.c | 12 +---
> drivers/dma/intel_mid_dma.c|2 +-
> drivers/gpio/gpio-langwell.c |6 +-
> drivers/i2c/i2c-core.c |2 +-
> drivers/mfd/ab8500-gpadc.c |8 +---
> drivers/mmc/core/bus.c |2 +-
> drivers/mmc/core/sdio_bus.c|2 +-
> drivers/pci/pci-driver.c | 14 +-
> drivers/scsi/scsi_pm.c | 11 +++
> drivers/sh/pm_runtime.c|2 +-
> drivers/spi/spi.c |2 +-
> drivers/tty/serial/mfd.c |9 ++---
> drivers/usb/core/driver.c |3 ++-
> drivers/usb/core/port.c|1 -
> include/linux/pm_runtime.h |2 --
> 23 files changed, 28 insertions(+), 92 deletions(-)
>
> Index: linux-pm/drivers/base/power/runtime.c
> ===
> --- linux-pm.orig/drivers/base/power/runtime.c
> +++ linux-pm/drivers/base/power/runtime.c
> @@ -293,11 +293,8 @@ static int rpm_idle(struct device *dev,
> /* Pending requests need to be canceled. */
> dev->power.request = RPM_REQ_NONE;
>
> - if (dev->power.no_callbacks) {
> - /* Assume ->runtime_idle() callback would have suspended. */
> - retval = rpm_suspend(dev, rpmflags);
> + if (dev->power.no_callbacks)
> goto out;
> - }
>
> /* Carry out an asynchronous or a synchronous idle notification. */
> if (rpmflags & RPM_ASYNC) {
> @@ -306,7 +303,8 @@ static int rpm_idle(struct device *dev,
> dev->power.request_pending = true;
> queue_work(pm_wq, >power.work);
> }
> - goto out;
> + trace_rpm_return_int(dev, _THIS_IP_, 0);
> + return 0;
> }
>
> dev->power.idle_notification = true;
> @@ -326,14 +324,14 @@ static int rpm_idle(struct device *dev,
> callback = dev->driver->pm->runtime_idle;
>
> if (callback)
> - __rpm_callback(callback, dev);
> + retval = __rpm_callback(callback, dev);
>
> dev->power.idle_notification = false;
> wake_up_all(>power.wait_queue);
>
> out:
> trace_rpm_return_int(dev, _THIS_IP_, retval);
> - return retval;
> + return retval ? retval : rpm_suspend(dev, rpmflags);
> }
>
> /**
> Index: linux-pm/drivers/base/power/generic_ops.c
> ===
> --- linux-pm.orig/drivers/base/power/generic_ops.c
> +++ linux-pm/drivers/base/power/generic_ops.c
> @@ -12,29 +12,6 @@
>
> #ifdef CONFIG_PM_RUNTIME
> /**
> - * pm_generic_runtime_idle - Generic runtime idle callback for subsystems.
> - * @dev: Device to handle.
> - *
> - * If PM operations are defined for the @dev's driver and they include
> - * ->runtime_idle(), execute it and return its error code, if nonzero.
> - * Otherwise, execute pm_runtime_suspend() for the device and return 0.
> - */
> -int pm_generic_runtime_idle(struct device *dev)
> -{
> - const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> -
> - if (pm && pm->runtime_idle) {
> - int ret = pm->runtime_idle(dev);
> - if (ret)
> - return ret;
> - }
> -
> - pm_runtime_suspend(dev);
> -
Re: [v5][PATCH 5/6] mm: vmscan: batch shrink_page_list() locking operations
On Tue, Jun 04, 2013 at 09:17:26AM +0800, Hillf Danton wrote:
> On Tue, Jun 4, 2013 at 4:02 AM, Dave Hansen wrote:
> > +/*
> > + * pages come in here (via remove_list) locked and leave unlocked
> > + * (on either ret_pages or free_pages)
> > + *
> > + * We do this batching so that we free batches of pages with a
> > + * single mapping->tree_lock acquisition/release. This optimization
> > + * only makes sense when the pages on remove_list all share a
> > + * page_mapping(). If this is violated you will BUG_ON().
> > + */
> > +static int __remove_mapping_batch(struct list_head *remove_list,
> > + struct list_head *ret_pages,
> > + struct list_head *free_pages)
> > +{
> > + int nr_reclaimed = 0;
> > + struct address_space *mapping;
> > + struct page *page;
> > + LIST_HEAD(need_free_mapping);
> > +
> > + if (list_empty(remove_list))
> > + return 0;
> > +
> > + mapping = page_mapping(lru_to_page(remove_list));
> > + spin_lock_irq(>tree_lock);
> > + while (!list_empty(remove_list)) {
> > + page = lru_to_page(remove_list);
> > + BUG_ON(!PageLocked(page));
> > + BUG_ON(page_mapping(page) != mapping);
> > + list_del(>lru);
> > +
> > + if (!__remove_mapping(mapping, page)) {
> > + unlock_page(page);
> > + list_add(>lru, ret_pages);
> > + continue;
> > + }
> > + list_add(>lru, _free_mapping);
> > + }
> > + spin_unlock_irq(>tree_lock);
> > +
> While reclaiming pages, can we open ears upon IRQ controller,
> if the page list length is over 10, or even 20?
At the moment, it implicitly could be bounded by SWAP_CLUSTER_MAX and
it's the value used by isolate_migratepages_ranges to enable IRQ.
I have no idea it's proper value to give a chace to IRQ but at least,
Dave's code doesn't break the rule.
If we need a tune for that, it could be a another patch to investigate
all of places on vmscan.c in near future.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v5][PATCH 5/6] mm: vmscan: batch shrink_page_list() locking operations
On Mon, Jun 03, 2013 at 01:02:08PM -0700, Dave Hansen wrote:
>
> From: Dave Hansen
> changes for v2:
> * remove batch_has_same_mapping() helper. A local varible makes
>the check cheaper and cleaner
> * Move batch draining later to where we already know
>page_mapping(). This probably fixes a truncation race anyway
> * rename batch_for_mapping_removal -> batch_for_mapping_rm. It
>caused a line over 80 chars and needed shortening anyway.
> * Note: we only set 'batch_mapping' when there are pages in the
>batch_for_mapping_rm list
>
> --
>
> We batch like this so that several pages can be freed with a
> single mapping->tree_lock acquisition/release pair. This reduces
> the number of atomic operations and ensures that we do not bounce
> cachelines around.
>
> Tim Chen's earlier version of these patches just unconditionally
> created large batches of pages, even if they did not share a
> page_mapping(). This is a bit suboptimal for a few reasons:
> 1. if we can not consolidate lock acquisitions, it makes little
>sense to batch
> 2. The page locks are held for long periods of time, so we only
>want to do this when we are sure that we will gain a
>substantial throughput improvement because we pay a latency
>cost by holding the locks.
>
> This patch makes sure to only batch when all the pages on
> 'batch_for_mapping_rm' continue to share a page_mapping().
> This only happens in practice in cases where pages in the same
> file are close to each other on the LRU. That seems like a
> reasonable assumption.
>
> In a 128MB virtual machine doing kernel compiles, the average
> batch size when calling __remove_mapping_batch() is around 5,
> so this does seem to do some good in practice.
>
> On a 160-cpu system doing kernel compiles, I still saw an
> average batch length of about 2.8. One promising feature:
> as the memory pressure went up, the average batches seem to
> have gotten larger.
>
> It has shown some substantial performance benefits on
> microbenchmarks.
>
> Signed-off-by: Dave Hansen
> Acked-by: Mel Gorman
Look at below comment, otherwise, looks good to me.
Reviewed-by: Minchan Kim
> ---
>
> linux.git-davehans/mm/vmscan.c | 95
> +
> 1 file changed, 86 insertions(+), 9 deletions(-)
>
> diff -puN mm/vmscan.c~create-remove_mapping_batch mm/vmscan.c
> --- linux.git/mm/vmscan.c~create-remove_mapping_batch 2013-06-03
> 12:41:31.408751324 -0700
> +++ linux.git-davehans/mm/vmscan.c2013-06-03 12:41:31.412751500 -0700
> @@ -550,6 +550,61 @@ int remove_mapping(struct address_space
> return 0;
> }
>
> +/*
> + * pages come in here (via remove_list) locked and leave unlocked
> + * (on either ret_pages or free_pages)
> + *
> + * We do this batching so that we free batches of pages with a
> + * single mapping->tree_lock acquisition/release. This optimization
> + * only makes sense when the pages on remove_list all share a
> + * page_mapping(). If this is violated you will BUG_ON().
> + */
> +static int __remove_mapping_batch(struct list_head *remove_list,
> + struct list_head *ret_pages,
> + struct list_head *free_pages)
> +{
> + int nr_reclaimed = 0;
> + struct address_space *mapping;
> + struct page *page;
> + LIST_HEAD(need_free_mapping);
> +
> + if (list_empty(remove_list))
> + return 0;
> +
> + mapping = page_mapping(lru_to_page(remove_list));
> + spin_lock_irq(>tree_lock);
> + while (!list_empty(remove_list)) {
> + page = lru_to_page(remove_list);
> + BUG_ON(!PageLocked(page));
> + BUG_ON(page_mapping(page) != mapping);
> + list_del(>lru);
> +
> + if (!__remove_mapping(mapping, page)) {
> + unlock_page(page);
> + list_add(>lru, ret_pages);
> + continue;
> + }
> + list_add(>lru, _free_mapping);
Why do we need new lru list instead of using @free_pages?
> + }
> + spin_unlock_irq(>tree_lock);
> +
> + while (!list_empty(_free_mapping)) {
> + page = lru_to_page(_free_mapping);
> + list_move(>list, free_pages);
> + mapping_release_page(mapping, page);
> + /*
> + * At this point, we have no other references and there is
> + * no way to pick any more up (removed from LRU, removed
> + * from pagecache). Can use non-atomic bitops now (and
> + * we obviously don't have to worry about waking up a process
> + * waiting on the page lock, because there are no references.
> + */
> + __clear_page_locked(page);
> + nr_reclaimed++;
> + }
> + return nr_reclaimed;
> +}
> +
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
linux-next: build failure after merge of the staging tree
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from
drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:44:0,
from
drivers/staging/lustre/lustre/fid/../include/linux/lvfs.h:48,
from drivers/staging/lustre/lustre/fid/../include/lvfs.h:45,
from
drivers/staging/lustre/lustre/fid/../include/obd_support.h:41,
from
drivers/staging/lustre/lustre/fid/../include/linux/obd.h:44,
from drivers/staging/lustre/lustre/fid/../include/obd.h:40,
from drivers/staging/lustre/lustre/fid/fid_store.c:48:
drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h:
In function 'truncate_complete_page':
drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h:56:3:
error: too few arguments to function 'page->mapping->a_ops->invalidatepage'
page->mapping->a_ops->invalidatepage(page, 0);
^
Lots of times.
Caused by the Lustre client patches interacting with commit d47992f86b30
("mm: change invalidatepage prototype to accept length") from the ext4
tree.
I added this merge fix patch:
From 3873636f50eb89ba5e4f8e4e0523fd62f681edc8 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell
Date: Tue, 4 Jun 2013 14:41:00 +1000
Subject: [PATCH] staging/lustre: fix for invalidatepage() API change
Signed-off-by: Stephen Rothwell
---
drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
index f050808..67c4644 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
@@ -53,7 +53,7 @@ truncate_complete_page(struct address_space *mapping, struct
page *page)
return;
if (PagePrivate(page))
- page->mapping->a_ops->invalidatepage(page, 0);
+ page->mapping->a_ops->invalidatepage(page, 0, PAGE_CACHE_SIZE);
cancel_dirty_page(page, PAGE_SIZE);
ClearPageMappedToDisk(page);
--
1.8.1
diff --git a/drivers/staging/lustre/lustre/llite/rw26.c
b/drivers/staging/lustre/lustre/llite/rw26.c
index 27e4e64..f1a1c5f 100644
--- a/drivers/staging/lustre/lustre/llite/rw26.c
+++ b/drivers/staging/lustre/lustre/llite/rw26.c
@@ -72,7 +72,8 @@
* aligned truncate). Lustre leaves partially truncated page in the cache,
* relying on struct inode::i_size to limit further accesses.
*/
-static void ll_invalidatepage(struct page *vmpage, unsigned long offset)
+static void ll_invalidatepage(struct page *vmpage, unsigned int offset,
+ unsigned int length)
{
struct inode *inode;
struct lu_env*env;
@@ -89,7 +90,7 @@ static void ll_invalidatepage(struct page *vmpage, unsigned
long offset)
* below because they are run with page locked and all our io is
* happening with locked page too
*/
- if (offset == 0) {
+ if (offset == 0 && length == PAGE_CACHE_SIZE) {
env = cl_env_get();
if (!IS_ERR(env)) {
inode = vmpage->mapping->host;
But then got these errors:
drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c: In function
'cfs_cpt_bind':
drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c:630:3: error: implicit
declaration of function 'set_cpus_allowed'
[-Werror=implicit-function-declaration]
rc = set_cpus_allowed(current, *cpumask);
^
cc1: some warnings being treated as errors
drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 'key_fini':
drivers/staging/lustre/lustre/obdclass/lu_object.c:1354:4: error: implicit
declaration of function 'module_refcount'
[-Werror=implicit-function-declaration]
LINVRNT(module_refcount(key->lct_owner) > 0);
^
In file included from
drivers/staging/lustre/include/linux/libcfs/libcfs.h:203:0,
from drivers/staging/lustre/lustre/obdclass/lu_object.c:47:
drivers/staging/lustre/lustre/obdclass/lu_object.c: In function
'lu_context_keys_dump':
drivers/staging/lustre/lustre/obdclass/lu_object.c:1936:42: error:
dereferencing pointer to incomplete type
key->lct_owner ? key->lct_owner->name : "",
^
drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:221:41: note: in
definition of macro '__CDEBUG'
libcfs_debug_msg(, format, ## __VA_ARGS__); \
^
drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:238:30: note: in
expansion of macro 'CDEBUG_LIMIT'
#define CERROR(format, ...) CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__)
^
drivers/staging/lustre/lustre/obdclass/lu_object.c:1932:4:
Re: 3.9.4 Oops running xfstests (WAS Re: 3.9.3: Oops running xfstests)
> Cai, I did ask you for the information that would have answered this > question: > > > > 3. if you can't reproduce it like that, does it reproduce on > > > an xfstest run on a pristine system? If so, what command > > > line are you running, and what are the filesystem > > > configurations? > > So, I need xfstests command line and the xfs_info output from the > filesystems in use at the time this problem occurs.. Here you are. [root@hp-z210-01 xfstests-dev]# a=`grep ' swap' /etc/fstab | cut -f 1 -d ' '` [root@hp-z210-01 xfstests-dev]# b=`grep ' /home' /etc/fstab | cut -f 1 -d ' '` [root@hp-z210-01 xfstests-dev]# swapoff -a [root@hp-z210-01 xfstests-dev]# umount /home [root@hp-z210-01 xfstests-dev]# echo "swap = $a" swap = /dev/mapper/rhel_hp--z210--01-swap [root@hp-z210-01 xfstests-dev]# echo "home = $b" home = /dev/mapper/rhel_hp--z210--01-home [root@hp-z210-01 xfstests-dev]# export TEST_DEV=$a [root@hp-z210-01 xfstests-dev]# export TEST_DIR=/mnt/testarea/test [root@hp-z210-01 xfstests-dev]# export SCRATCH_DEV=$b [root@hp-z210-01 xfstests-dev]# export SCRATCH_MNT=/mnt/testarea/scratch [root@hp-z210-01 xfstests-dev]# mkdir -p /mnt/testarea/test [root@hp-z210-01 xfstests-dev]# mkdir -p /mnt/testarea/scratch [root@hp-z210-01 xfstests-dev]# [root@hp-z210-01 xfstests-dev]# mkfs.xfs -f $a meta-data=/dev/mapper/rhel_hp--z210--01-swap isize=256agcount=4, agsize=251904 blks = sectsz=512 attr=2, projid32bit=0 data = bsize=4096 blocks=1007616, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 [root@hp-z210-01 xfstests-dev]# mkfs.xfs -f $b meta-data=/dev/mapper/rhel_hp--z210--01-home isize=256agcount=4, agsize=11701504 blks = sectsz=512 attr=2, projid32bit=0 data = bsize=4096 blocks=46806016, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=22854, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 [root@hp-z210-01 xfstests-dev]# [root@hp-z210-01 xfstests-dev]# mount /dev/mapper/rhel_hp--z210--01-home /mnt/testarea/scratch [root@hp-z210-01 xfstests-dev]# [root@hp-z210-01 xfstests-dev]# mount /dev/mapper/rhel_hp--z210--01-swap /mnt/testarea/test [root@hp-z210-01 xfstests-dev]# xfs_info $a meta-data=/dev/mapper/rhel_hp--z210--01-swap isize=256agcount=4, agsize=251904 blks = sectsz=512 attr=2 data = bsize=4096 blocks=1007616, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 [root@hp-z210-01 xfstests-dev]# xfs_info $b meta-data=/dev/mapper/rhel_hp--z210--01-home isize=256agcount=4, agsize=11701504 blks = sectsz=512 attr=2 data = bsize=4096 blocks=46806016, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=22854, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 [root@hp-z210-01 xfstests-dev]# ./check 20 FSTYP -- xfs (non-debug) PLATFORM -- Linux/x86_64 hp-z210-01 3.9.4 MKFS_OPTIONS -- -f -bsize=4096 /dev/mapper/rhel_hp--z210--01-home MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/mapper/rhel_hp--z210--01-home /mnt/testarea/scratch 020 CAI Qian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [DISCUSSION] removing variety rq->cpu_load ?
>>> >> Forgive me but I'm a little lost on this thread... >>> >> >>> >> So we are planing to rely on instant 'cpu_load[0]' and decayed >>> >> 'runnable_load_avg' only, do we? >> > >> > cpu_load is a kind of time decay for cpu load, but after runnable load >> > introduced, >> > the decay functionality is a kind duplicate with it. >> > So, remove them will make code simple. The idea were mentioned by Paul, >> > Peter and I. > Nice, what about make a patch 9 and clean up all those stuff? > > I suppose we will get more benefit :) I'd like to. But since Peter doesn't response this thread for long time, I even don't know what's he opinions of patch 1~8. :( -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 00/30] thermal: exynos: Add thermal driver for exynos5440
Hi Eduardo, On Wed, May 15, 2013 at 8:14 PM, Eduardo Valentin wrote: > On 14-05-2013 05:58, Amit Daniel Kachhap wrote: >> Changes in V4: >> Almost all the changes in this version is as per suggestion from Eduardo.The >> major ones are listed below, >> * Added kconfig symbol ARCH_HAS_TMU which needs to be enabled by platform. >> With >> this change existing symbol EXYNOS_TMU_DATA is not needed. > > I was more thinking if we could have a single flag that we could use in > thermal drivers. Besides, my proposal for ARCH_HAS_BANDGAP is still not > merged yet. yes a single flag might be useful such as ARCH_HAS_THERMAL but this patch can work as an intermediate solution. Thanks, Amit Daniel > >> * Movement of freq_clip_table from exynos_tmu.h to exynos_thermal_common.h is >> explained in the commit logs. >> * Wrote all register description documentation. >> * Split 5440 TMU support patch into controller change, configuration data and >> feature addition patches. >> * Remove all *LINUX_* in the header files. >> * Still regulator enable is kept optional but a TODO: comment is added to fix >> it later. >> >> Changes in V3: >> * Added proper dependency of different exynos thermal Kconfig symbols. >> Basically 3 >> Kconfig can be enabled now and corresponds to tmu driver. exynos common part >> and exynos configuration data. This issue was raised by Rui Zhang. >> >> Changes in V2: >> * Separated SOC data from TMU driver. This is as per suggestion from Eduardo. >> * Merged the new file created for exynos5440 TMU controller with the existing >> TMU controller code. >> * Removed the DT parsing code as now the SOC specific data are cleanly put >> inside the data specific file. >> * Even the register definations/bitfields are treated as data as there is >> some variation across SOC's. >> >> This patchset adds TMU(Thermal management Unit) driver support for >> exynos5440 platform. There are 3 instances of the TMU controllers so >> necessary cleanup/re-structure is done to handle multiple thermal zone. >> >> Patch (exynos4: Add documentation for Exynos SoC thermal bindings) from >> Lukasz Majewski is already posted to mainline. Adding it here for >> completeness. >> (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17817.html) >> >> Patch (thermal: exynos: Support thermal tripping ) from Jonghwan Choi is >> added here with some changes. >> (https://patchwork.kernel.org/patch/1668371/) >> >> Patch (thermal: exynos: Support for TMU regulator defined at device tree) >> is a repost of my earlier >> patch(https://patchwork-mail1.kernel.org/patch/2510771/) >> and adds regulator support. >> >> Patch (ARM: dts: Add device tree node for exynos5440 TMU controller) and >> patch (arm: exynos: enable ARCH_HAS_TMU) can be merged through exynos >> platform >> maintainer as this can cause merge conflict. >> >> All these patches are based on thermal maintainers git tree, >> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next. >> >> Amit Daniel Kachhap (29): >> thermal: exynos: Moving exynos thermal files into samsung directory >> thermal: exynos: Add ARCH_HAS_TMU config to know the supported soc's >> thermal: exynos: Remove CPU_THERMAL dependency for using TMU driver >> thermal: exynos: Bifurcate exynos thermal common and tmu controller >> code >> thermal: exynos: Rename exynos_thermal.c to exynos_tmu.c >> thermal: exynos: Move exynos_thermal.h from include/* to driver/* >> folder >> thermal: exynos: Bifurcate exynos tmu driver and configuration data >> thermal: exynos: Add missing definations and code cleanup >> thermal: exynos: Add extra entries in the tmu platform data >> thermal: exynos: Support thermal tripping >> thermal: exynos: Move register definitions from driver file to data >> file >> thermal: exynos: Fix to clear only the generated interrupts >> thermal: exynos: Add support for instance based register/unregister >> thermal: exynos: Modify private_data to appropriate name driver_data >> thermal: exynos: Return success even if no cooling data supplied >> thermal: exynos: Make the zone handling dependent on trip count >> thermal: exynos: Add support to handle many instances of TMU >> thermal: exynos: Add TMU features to check instead of using SOC type >> thermal: exynos: use device resource management infrastructure >> thermal: exynos: Add support to access common register for >> multistance >> thermal: exynos: Add support for exynos5440 TMU sensor. >> thermal: exynos: Fix to set the second point correction value >> properly >> thermal: exynos: Add thermal configuration data for exynos5440 TMU >> sensor >> thermal: exynos: Add a compensation logic on swapped e-fuse values >> thermal: exynos: Add hardware mode thermal calibration support >> Documentation: thermal: Explain the exynos thermal driver model >> thermal: exynos: Support for TMU regulator defined at device tree >> ARM: dts: Add device tree
Re: [PATCH] staging: gdm72xx: WIMAX_GDM72XX should depend on either USB or MMC
No worries. I've attached a revised patch to the original email thread, which includes Alan. Thanks again, Ben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 10/30] thermal: exynos: Support thermal tripping
Hi .
On Fri, May 17, 2013 at 5:26 PM, wrote:
> Hi, Amit
> On 2013년 05월 14일 18:58, Amit Daniel Kachhap wrote:
>
>> TMU urgently sends active-high signal (thermal trip) to PMU, and thermal
>> tripping by hardware logic. Thermal tripping means that PMU cuts off the
>> whole power of SoC by controlling external voltage regulator.
>>
>> Acked-by: Kukjin Kim
>> Signed-off-by: Jonghwan Choi
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> drivers/thermal/samsung/exynos_tmu.c |8 +++-
>> drivers/thermal/samsung/exynos_tmu_data.c |2 ++
>> 2 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index 5f8f189..479d61e 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -84,6 +84,7 @@
>> #define EXYNOS_TMU_CLEAR_FALL_INT(0x111 << 12)
>> #define EXYNOS_TMU_TRIP_MODE_SHIFT 13
>> #define EXYNOS_TMU_TRIP_MODE_MASK0x7
>> +#define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12
>>
>> #define EXYNOS_TMU_INTEN_RISE0_SHIFT 0
>> #define EXYNOS_TMU_INTEN_RISE1_SHIFT 4
>> @@ -186,7 +187,7 @@ static int exynos_tmu_initialize(struct platform_device
>> *pdev)
>> {
>> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>> struct exynos_tmu_platform_data *pdata = data->pdata;
>> - unsigned int status, trim_info;
>> + unsigned int status, trim_info, con;
>> unsigned int rising_threshold = 0, falling_threshold = 0;
>> int ret = 0, threshold_code, i, trigger_levs = 0;
>>
>> @@ -251,6 +252,11 @@ static int exynos_tmu_initialize(struct platform_device
>> *pdev)
>> falling_threshold |=
>> threshold_code << 8 * i;
>> }
>> + if (pdata->trigger_type[i] != HW_TRIP)
>> + continue;
>
>
> As you know, HW trip can be used when only the most last level of threshold
> temperature is set. (exynos4412 : 4th, exynos 5440 : 5th threshold level). So
> it
> wouldn't work properly, even if we enable HW trip according to pre-defined
> trigger type not to HW trip threshold temperature. To enable HW trip, we just
> need to check whether if HW trip threshold temperature level is defined.
>
> if (trigger_level[HW_TRIP_LEVEL])
> enable HW trip
Yes you are right. I will include this change in the next version.
Thanks,
Amit Daniel
>
> Thanks,
> Jonghwa
>
>> + con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
>> + con |= (1 << EXYNOS_TMU_THERM_TRIP_EN_SHIFT);
>> + writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
>> }
>>
>> writel(rising_threshold,
>> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
>> b/drivers/thermal/samsung/exynos_tmu_data.c
>> index ee6a3c9..6b937f5 100644
>> --- a/drivers/thermal/samsung/exynos_tmu_data.c
>> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
>> @@ -64,6 +64,7 @@ struct exynos_tmu_platform_data const
>> exynos5250_default_tmu_data = {
>> .trigger_levels[0] = 85,
>> .trigger_levels[1] = 103,
>> .trigger_levels[2] = 110,
>> + .trigger_levels[3] = 120,
>> .trigger_enable[0] = 1,
>> .trigger_enable[1] = 1,
>> .trigger_enable[2] = 1,
>> @@ -71,6 +72,7 @@ struct exynos_tmu_platform_data const
>> exynos5250_default_tmu_data = {
>> .trigger_type[0] = 0,
>> .trigger_type[1] = 0,
>> .trigger_type[2] = 1,
>> + .trigger_type[3] = 2,
>> .gain = 8,
>> .reference_voltage = 16,
>> .noise_cancel_mode = 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 V4 22/30] thermal: exynos: Add support for exynos5440 TMU sensor.
Hi Jonghwa,
Sorry for the late reply as I was on leave.
On Sat, May 18, 2013 at 10:53 AM, wrote:
> On 2013년 05월 14일 18:58, Amit Daniel Kachhap wrote:
>
>> This patch modifies TMU controller to add changes needed to work with
>> exynos5440 platform. This sensor registers 3 instance of the tmu controller
>> with the thermal zone and hence reports 3 temperature output. This controller
>> supports upto five trip points. For critical threshold the driver uses the
>> core driver thermal framework for shutdown.
>>
>> Acked-by: Kukjin Kim
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> .../devicetree/bindings/thermal/exynos-thermal.txt | 28 -
>> drivers/thermal/samsung/exynos_tmu.c | 43
>> +--
>> drivers/thermal/samsung/exynos_tmu.h |6 +++
>> drivers/thermal/samsung/exynos_tmu_data.h |2 +
>> 4 files changed, 72 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index 535fd0e..970eeba 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -6,13 +6,16 @@
>> "samsung,exynos4412-tmu"
>> "samsung,exynos4210-tmu"
>> "samsung,exynos5250-tmu"
>> +"samsung,exynos5440-tmu"
>> - interrupt-parent : The phandle for the interrupt controller
>> -- reg : Address range of the thermal registers
>> +- reg : Address range of the thermal registers. For exynos5440-tmu which
>> has 3
>> + instances of TMU, 2 set of register has to supplied. First set belongs
>> + to each instance of TMU and second set belongs to common TMU registers.
>> - interrupts : Should contain interrupt for thermal system
>> - clocks : The main clock for TMU device
>> - clock-names : Thermal system clock name
>>
>> -Example:
>> +Example 1):
>>
>> tmu@100C {
>> compatible = "samsung,exynos4412-tmu";
>> @@ -23,3 +26,24 @@ Example:
>> clock-names = "tmu_apbif";
>> status = "disabled";
>> };
>> +
>> +Example 2):
>> +
>> + tmuctrl_0: tmuctrl@160118 {
>> + compatible = "samsung,exynos5440-tmu";
>> + reg = <0x160118 0x230>, <0x160368 0x10>;
>> + interrupts = <0 58 0>;
>> + clocks = < 21>;
>> + clock-names = "tmu_apbif";
>> + };
>> +
>> +Note: For multi-instance tmu each instance should have an alias correctly
>> +numbered in "aliases" node.
>> +
>> +Example:
>> +
>> +aliases {
>> + tmuctrl0 = _0;
>> + tmuctrl1 = _1;
>> + tmuctrl2 = _2;
>> +};
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index 7f7b1cf..7ca9c4d 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -185,9 +185,11 @@ static int exynos_tmu_initialize(struct platform_device
>> *pdev)
>> reg->threshold_th0 + i * sizeof(reg->threshold_th0));
>>
>> writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
>> - } else if (data->soc == SOC_ARCH_EXYNOS) {
>> + } else if (data->soc == SOC_ARCH_EXYNOS ||
>> + data->soc == SOC_ARCH_EXYNOS5440) {
>> /* Write temperature code for rising and falling threshold */
>> - for (i = 0; i < trigger_levs; i++) {
>> + for (i = 0;
>> + i < trigger_levs && i < EXYNOS_MAX_TRIGGER_PER_REG; i++) {
>> threshold_code = temp_to_code(data,
>> pdata->trigger_levels[i]);
>> if (threshold_code < 0) {
>> @@ -218,7 +220,30 @@ static int exynos_tmu_initialize(struct platform_device
>> *pdev)
>> writel((reg->inten_rise_mask << reg->inten_rise_shift) |
>> (reg->inten_fall_mask << reg->inten_fall_shift),
>> data->base + reg->tmu_intclear);
>> +
>> + /* if 5th threshold limit is also present, use TH2 register */
>> + i = EXYNOS_MAX_TRIGGER_PER_REG;
>> + if (pdata->trigger_levels[i]) {
>> + threshold_code = temp_to_code(data,
>> + pdata->trigger_levels[i]);
>> + if (threshold_code < 0) {
>> + ret = threshold_code;
>> + goto out;
>> + }
>> + rising_threshold =
>> + threshold_code << reg->threshold_th3_l0_shift;
>> + writel(rising_threshold,
>> + data->base + reg->threshold_th2);
>> + if (pdata->trigger_type[i] == HW_TRIP) {
>> + con = readl(data->base + reg->tmu_ctrl);
>> +
Re: [v4][PATCH 1/6] mm: swap: defer clearing of page_private() for swap cache pages
On Mon, Jun 03, 2013 at 07:53:01AM -0700, Dave Hansen wrote: > On 06/02/2013 10:40 PM, Minchan Kim wrote: > >> > diff -puN mm/vmscan.c~__delete_from_swap_cache-dont-clear-page-private > >> > mm/vmscan.c > >> > --- > >> > linux.git/mm/vmscan.c~__delete_from_swap_cache-dont-clear-page-private > >> > 2013-05-30 16:07:50.632079492 -0700 > >> > +++ linux.git-davehans/mm/vmscan.c 2013-05-30 16:07:50.637079712 > >> > -0700 > >> > @@ -494,6 +494,8 @@ static int __remove_mapping(struct addre > >> > __delete_from_swap_cache(page); > >> > spin_unlock_irq(>tree_lock); > >> > swapcache_free(swap, page); > >> > +set_page_private(page, 0); > >> > +ClearPageSwapCache(page); > > It it worth to support non-atomic version of ClearPageSwapCache? > > Just for this, probably not. > > It does look like a site where it would be theoretically safe to use > non-atomic flag operations since the page is on a one-way trip to the > allocator at this point and the __clear_page_locked() now happens _just_ > after this code. True. > > But, personally, I'm happy to leave it as-is. The atomic vs. non-atomic > flags look to me like a micro-optimization that we should use when we > _know_ there will be some tangible benefit. Otherwise, they're just > something extra for developers to trip over and cause very subtle bugs. I just asked it because when I read the description of patchset, I felt you were very sensitive to the atomic operation on many CPU system with several sockets. Anyway, if you don't want it, I don't mind it, either. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] clocksource: dw_apb_timer_of: use clocksource_of_init
Hi Heiko,
On Mon, Jun 03, 2013 at 09:59:55PM +0200, Heiko Stübner wrote:
> dw_apb_timer_init used to search the devicetree for matching timer
> devices, making calls to it from board files necessary.
>
> Change the dw_apb_timer_init to work with CLOCKSOURCE_OF_DECLARE.
> With this change the function gets called once for each timer node
> and tracks these number of calls to attach clockevent and clocksource
> devices to the nodes.
>
> Also remove the calls to dw_apb_timer_init from all previous users, as
> clocksource_of_init is the default for init_time now.
>
> Tested on the upcoming rk3066 code.
>
> Signed-off-by: Heiko Stuebner
> Acked-by: Rob Herring
> Acked-by: Arnd Bergmann
> ---
> arch/arm/mach-picoxcell/Kconfig |1 +
> arch/arm/mach-picoxcell/common.c |2 -
> arch/arm/mach-socfpga/Kconfig |1 +
> arch/arm/mach-socfpga/socfpga.c |2 -
> drivers/clocksource/dw_apb_timer_of.c | 41
> -
> include/linux/dw_apb_timer.h |1 -
> 6 files changed, 22 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm/mach-picoxcell/Kconfig b/arch/arm/mach-picoxcell/Kconfig
> index 13bae78..3ef6bbe 100644
> --- a/arch/arm/mach-picoxcell/Kconfig
> +++ b/arch/arm/mach-picoxcell/Kconfig
> @@ -6,6 +6,7 @@ config ARCH_PICOXCELL
> select CPU_V6K
> select DW_APB_TIMER
> select DW_APB_TIMER_OF
> + select CLKSRC_OF
Shouldn't DW_APB_TIMER 'select CLKSRC_OF if OF' instead of selecting is for
each and every platform? While at it we can do the same to DW_APB_TIMER_OF.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] ARM: SAMSUNG: Consolidate uncompress subroutine
For mach-exynos, uart_base is a pointer and the value is calculated
in the machine folder. For other machines, uart_base is defined as
a macro in platform directory. For symmetry, the uart_base macro
definition is removed and the uart_base calculation is moved to
specific machine folders.
This would help us consolidating uncompress subroutine for s5p64x0.
Signed-off-by: Tushar Behera
---
Changes for v2:
* Remove ifdef's while calculating uart_base value.
arch/arm/mach-exynos/include/mach/uncompress.h |3 ---
arch/arm/mach-s3c24xx/include/mach/uncompress.h |3 +++
arch/arm/mach-s3c64xx/include/mach/uncompress.h |3 +++
arch/arm/mach-s5pc100/include/mach/uncompress.h |2 ++
arch/arm/mach-s5pv210/include/mach/uncompress.h |2 ++
arch/arm/plat-samsung/include/plat/uncompress.h |6 ++
6 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/uncompress.h
b/arch/arm/mach-exynos/include/mach/uncompress.h
index 2979995..d405762 100644
--- a/arch/arm/mach-exynos/include/mach/uncompress.h
+++ b/arch/arm/mach-exynos/include/mach/uncompress.h
@@ -15,9 +15,6 @@
#include
#include
-
-volatile u8 *uart_base;
-
#include
static unsigned int __raw_readl(unsigned int ptr)
diff --git a/arch/arm/mach-s3c24xx/include/mach/uncompress.h
b/arch/arm/mach-s3c24xx/include/mach/uncompress.h
index 8b283f8..7d2ce20 100644
--- a/arch/arm/mach-s3c24xx/include/mach/uncompress.h
+++ b/arch/arm/mach-s3c24xx/include/mach/uncompress.h
@@ -49,6 +49,9 @@ static void arch_detect_cpu(void)
fifo_mask = S3C2410_UFSTAT_TXMASK;
fifo_max = 15 << S3C2410_UFSTAT_TXSHIFT;
}
+
+ uart_base = (volatile u8 *) S3C_PA_UART +
+ (S3C_UART_OFFSET * CONFIG_S3C_LOWLEVEL_UART_PORT);
}
#endif /* __ASM_ARCH_UNCOMPRESS_H */
diff --git a/arch/arm/mach-s3c64xx/include/mach/uncompress.h
b/arch/arm/mach-s3c64xx/include/mach/uncompress.h
index c6a82a2..1c95673 100644
--- a/arch/arm/mach-s3c64xx/include/mach/uncompress.h
+++ b/arch/arm/mach-s3c64xx/include/mach/uncompress.h
@@ -23,6 +23,9 @@ static void arch_detect_cpu(void)
/* we do not need to do any cpu detection here at the moment. */
fifo_mask = S3C2440_UFSTAT_TXMASK;
fifo_max = 63 << S3C2440_UFSTAT_TXSHIFT;
+
+ uart_base = (volatile u8 *)S3C_PA_UART +
+ (S3C_UART_OFFSET * CONFIG_S3C_LOWLEVEL_UART_PORT);
}
#endif /* __ASM_ARCH_UNCOMPRESS_H */
diff --git a/arch/arm/mach-s5pc100/include/mach/uncompress.h
b/arch/arm/mach-s5pc100/include/mach/uncompress.h
index 01ccf53..720e133 100644
--- a/arch/arm/mach-s5pc100/include/mach/uncompress.h
+++ b/arch/arm/mach-s5pc100/include/mach/uncompress.h
@@ -23,6 +23,8 @@ static void arch_detect_cpu(void)
/* we do not need to do any cpu detection here at the moment. */
fifo_mask = S3C2440_UFSTAT_TXMASK;
fifo_max = 63 << S3C2440_UFSTAT_TXSHIFT;
+
+ uart_base = (volatile u8 *)S5P_PA_UART(CONFIG_S3C_LOWLEVEL_UART_PORT);
}
#endif /* __ASM_ARCH_UNCOMPRESS_H */
diff --git a/arch/arm/mach-s5pv210/include/mach/uncompress.h
b/arch/arm/mach-s5pv210/include/mach/uncompress.h
index ef977ea..231cb07 100644
--- a/arch/arm/mach-s5pv210/include/mach/uncompress.h
+++ b/arch/arm/mach-s5pv210/include/mach/uncompress.h
@@ -21,6 +21,8 @@ static void arch_detect_cpu(void)
/* we do not need to do any cpu detection here at the moment. */
fifo_mask = S5PV210_UFSTAT_TXMASK;
fifo_max = 63 << S5PV210_UFSTAT_TXSHIFT;
+
+ uart_base = (volatile u8 *)S5P_PA_UART(CONFIG_S3C_LOWLEVEL_UART_PORT);
}
#endif /* __ASM_ARCH_UNCOMPRESS_H */
diff --git a/arch/arm/plat-samsung/include/plat/uncompress.h
b/arch/arm/plat-samsung/include/plat/uncompress.h
index 02b66d7..2ace0d5 100644
--- a/arch/arm/plat-samsung/include/plat/uncompress.h
+++ b/arch/arm/plat-samsung/include/plat/uncompress.h
@@ -21,6 +21,8 @@ typedef unsigned int upf_t; /* cannot include
linux/serial_core.h */
unsigned int fifo_mask;
unsigned int fifo_max;
+volatile u8 *uart_base;
+
/* forward declerations */
static void arch_detect_cpu(void);
@@ -37,10 +39,6 @@ static void arch_detect_cpu(void);
/* how many bytes we allow into the FIFO at a time in FIFO mode */
#define FIFO_MAX(14)
-#ifdef S3C_PA_UART
-#define uart_base S3C_PA_UART + (S3C_UART_OFFSET *
CONFIG_S3C_LOWLEVEL_UART_PORT)
-#endif
-
static __inline__ void
uart_wr(unsigned int reg, unsigned int val)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] ARM: s5p64x0: Use common uncompress.h part for plat-samsung
From: Tomasz Figa
Since uart_base can be set dynamically in arch_detect_cpu(), there is no
need to have a copy of all code locally, just to override UART base
address.
This patch removes any duplicate code in uncompress.h variant of s5p64x0
and implements proper arch_detect_cpu() function to initialize UART with
SoC-specific parameters.
While at it, replace hard-coded register address with macro.
Signed-off-by: Tomasz Figa
Signed-off-by: Tushar Behera
---
(This patch replaces the original patch in this patchset as it was an
earlier-posted near-identical patch.)
Changes for v2:
* Remove the declaration of uart_base (taken care in plat/uncompress.h)
arch/arm/mach-s5p64x0/include/mach/uncompress.h | 162 +--
1 file changed, 6 insertions(+), 156 deletions(-)
diff --git a/arch/arm/mach-s5p64x0/include/mach/uncompress.h
b/arch/arm/mach-s5p64x0/include/mach/uncompress.h
index 19e0d64..bc04bd5 100644
--- a/arch/arm/mach-s5p64x0/include/mach/uncompress.h
+++ b/arch/arm/mach-s5p64x0/include/mach/uncompress.h
@@ -14,171 +14,21 @@
#define __ASM_ARCH_UNCOMPRESS_H
#include
+#include
-/*
- * cannot use commonly
- * because uart base of S5P6440 and S5P6450 is different
- */
-
-typedef unsigned int upf_t;/* cannot include linux/serial_core.h */
-
-/* uart setup */
-
-unsigned int fifo_mask;
-unsigned int fifo_max;
-
-/* forward declerations */
-
-static void arch_detect_cpu(void);
-
-/* defines for UART registers */
-
-#include
-#include
-
-/* working in physical space... */
-#undef S3C2410_WDOGREG
-#define S3C2410_WDOGREG(x) ((S3C24XX_PA_WATCHDOG + (x)))
-
-/* how many bytes we allow into the FIFO at a time in FIFO mode */
-#define FIFO_MAX(14)
-
-unsigned long uart_base;
-
-static __inline__ void get_uart_base(void)
+static void arch_detect_cpu(void)
{
unsigned int chipid;
chipid = *(const volatile unsigned int __force *) 0xE0100118;
- uart_base = S3C_UART_OFFSET * CONFIG_S3C_LOWLEVEL_UART_PORT;
-
if ((chipid & 0xff000) == 0x5)
- uart_base += 0xEC80;
+ uart_base = S5P6450_PA_UART(CONFIG_S3C_LOWLEVEL_UART_PORT);
else
- uart_base += 0xEC00;
-}
-
-static __inline__ void uart_wr(unsigned int reg, unsigned int val)
-{
- volatile unsigned int *ptr;
-
- get_uart_base();
- ptr = (volatile unsigned int *)(reg + uart_base);
- *ptr = val;
-}
-
-static __inline__ unsigned int uart_rd(unsigned int reg)
-{
- volatile unsigned int *ptr;
-
- get_uart_base();
- ptr = (volatile unsigned int *)(reg + uart_base);
- return *ptr;
-}
-
-/*
- * we can deal with the case the UARTs are being run
- * in FIFO mode, so that we don't hold up our execution
- * waiting for tx to happen...
- */
-
-static void putc(int ch)
-{
- if (uart_rd(S3C2410_UFCON) & S3C2410_UFCON_FIFOMODE) {
- int level;
-
- while (1) {
- level = uart_rd(S3C2410_UFSTAT);
- level &= fifo_mask;
-
- if (level < fifo_max)
- break;
- }
-
- } else {
- /* not using fifos */
-
- while ((uart_rd(S3C2410_UTRSTAT) & S3C2410_UTRSTAT_TXE) !=
S3C2410_UTRSTAT_TXE)
- barrier();
- }
+ uart_base = S5P6440_PA_UART(CONFIG_S3C_LOWLEVEL_UART_PORT);
- /* write byte to transmission register */
- uart_wr(S3C2410_UTXH, ch);
-}
-
-static inline void flush(void)
-{
-}
-
-#define __raw_writel(d, ad)\
- do {\
- *((volatile unsigned int __force *)(ad)) = (d); \
- } while (0)
-
-
-#ifdef CONFIG_S3C_BOOT_ERROR_RESET
-
-static void arch_decomp_error(const char *x)
-{
- putstr("\n\n");
- putstr(x);
- putstr("\n\n -- System resetting\n");
-
- __raw_writel(0x4000, S3C2410_WTDAT);
- __raw_writel(0x4000, S3C2410_WTCNT);
- __raw_writel(S3C2410_WTCON_ENABLE | S3C2410_WTCON_DIV128 |
S3C2410_WTCON_RSTEN | S3C2410_WTCON_PRESCALE(0x40), S3C2410_WTCON);
-
- while(1);
-}
-
-#define arch_error arch_decomp_error
-#endif
-
-#ifdef CONFIG_S3C_BOOT_UART_FORCE_FIFO
-static inline void arch_enable_uart_fifo(void)
-{
- u32 fifocon = uart_rd(S3C2410_UFCON);
-
- if (!(fifocon & S3C2410_UFCON_FIFOMODE)) {
- fifocon |= S3C2410_UFCON_RESETBOTH;
- uart_wr(S3C2410_UFCON, fifocon);
-
- /* wait for fifo reset to complete */
- while (1) {
- fifocon = uart_rd(S3C2410_UFCON);
- if (!(fifocon & S3C2410_UFCON_RESETBOTH))
- break;
- }
- }
-}
-#else
-#define arch_enable_uart_fifo() do { } while(0)
-#endif
-
-static void arch_decomp_setup(void)
-{
- /*
-* we may need to setup the uart(s) here if we are not
[PATCH v2 0/3] Consolidate uncompress code for Samsung platform
The patches are based on v3.10-rc4. They are build tested for s3c2410_defconfig, s3c6400_defconfig, s5p64x0_defconfig, s5pc100_defconfig, s5pv210_defconfig, exynos4_defconfig and exynos_defconfig. Since they affect all the Samsung boards, testing them on different machines would be essential. Unfortunately I can only test on Exynos here. Tested on Exynos5250 based Arndale board. Changes for v2: * Instead of checking for uart_base, we are now checking whether DEBUG_LL is enabled. This removes the ifdefs used in mach/uncompress.h * 3rd patch has been updated by Tomasz Figa's patch that almost does the same thing. Tomasz Figa (1): ARM: s5p64x0: Use common uncompress.h part for plat-samsung Tushar Behera (2): ARM: EXYNOS: uncompress - print debug messages if DEBUG_LL is defined ARM: SAMSUNG: Consolidate uncompress subroutine arch/arm/mach-exynos/include/mach/uncompress.h |3 - arch/arm/mach-s3c24xx/include/mach/uncompress.h |3 + arch/arm/mach-s3c64xx/include/mach/uncompress.h |3 + arch/arm/mach-s5p64x0/include/mach/uncompress.h | 162 +-- arch/arm/mach-s5pc100/include/mach/uncompress.h |2 + arch/arm/mach-s5pv210/include/mach/uncompress.h |2 + arch/arm/plat-samsung/include/plat/uncompress.h | 16 ++- 7 files changed, 27 insertions(+), 164 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] ARM: EXYNOS: uncompress - print debug messages if DEBUG_LL is defined
Printing low-level debug messages make an assumption that the specified
UART port has been preconfigured by the bootloader. Incorrectly
specified UART port results in system getting stalled while printing the
message "Uncompressing Linux... done, booting the kernel"
This UART port number is specified through S3C_LOWLEVEL_UART_PORT. Since
the UART port might different for different board, it is not possible to
specify it correctly for every board that use a common defconfig file.
Calling this print subroutine only when DEBUG_LL fixes the problem. By
disabling DEBUG_LL in default config file, we would be able to boot
multiple boards with different default UART ports.
With this current approach, we miss the print "Uncompressing Linux...
done, booting the kernel." when DEBUG_LL is not defined.
Signed-off-by: Tushar Behera
---
Change for v2:
* Instead of checking value of uart_base, now check if DEBUG_LL
is enabled. This removes the ifdef's from mach/uncompress.h
arch/arm/plat-samsung/include/plat/uncompress.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-samsung/include/plat/uncompress.h
b/arch/arm/plat-samsung/include/plat/uncompress.h
index 438b248..02b66d7 100644
--- a/arch/arm/plat-samsung/include/plat/uncompress.h
+++ b/arch/arm/plat-samsung/include/plat/uncompress.h
@@ -66,6 +66,9 @@ uart_rd(unsigned int reg)
static void putc(int ch)
{
+ if (!config_enabled(CONFIG_DEBUG_LL))
+ return;
+
if (uart_rd(S3C2410_UFCON) & S3C2410_UFCON_FIFOMODE) {
int level;
@@ -118,7 +121,12 @@ static void arch_decomp_error(const char *x)
#ifdef CONFIG_S3C_BOOT_UART_FORCE_FIFO
static inline void arch_enable_uart_fifo(void)
{
- u32 fifocon = uart_rd(S3C2410_UFCON);
+ u32 fifocon;
+
+ if (!config_enabled(CONFIG_DEBUG_LL))
+ return;
+
+ fifocon = uart_rd(S3C2410_UFCON);
if (!(fifocon & S3C2410_UFCON_FIFOMODE)) {
fifocon |= S3C2410_UFCON_RESETBOTH;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.4 Oops running xfstests (WAS Re: 3.9.3: Oops running xfstests)
On Tue, Jun 04, 2013 at 02:16:18PM +1000, Dave Chinner wrote: > On Mon, Jun 03, 2013 at 11:14:56PM -0400, CAI Qian wrote: > > [ 102.312909] > > = > > [ 102.312910] RSP: 0018:88007d083e08 EFLAGS: 00010003 > > [ 102.312912] BUG kmalloc-1024 (Tainted: G D ): Padding > > overwritten. 0x88005b4e7ec0-0x88005b4e7fff > > [ 102.312913] RAX: 88005b656288 RBX: 880079b43c80 RCX: > > 00a7 > > [ 102.312914] > > - > > And a memory overwrite. > > > [ 102.313009] Padding 88005b4e7ec0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 > > [ 102.313010] Padding 88005b4e7ed0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 > > [ 102.313011] Padding 88005b4e7ee0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 > > [ 102.313013] Padding 88005b4e7ef0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 29 01 00 .).. > > [ 102.313014] Padding 88005b4e7f00: 07 1b 04 73 65 6c 69 6e 75 78 73 > > 79 73 74 65 6d ...selinuxsystem > > [ 102.313015] Padding 88005b4e7f10: 5f 75 3a 6f 62 6a 65 63 74 5f 72 > > 3a 75 73 72 5f _u:object_r:usr_ > > [ 102.313032] Padding 88005b4e7f20: 74 3a 73 30 00 00 00 00 49 4e 81 > > a4 02 02 00 00 t:s0IN.. > > [ 102.313033] Padding 88005b4e7f30: 00 00 00 00 00 00 00 00 00 00 00 > > 01 00 00 00 00 > > [ 102.313033] Padding 88005b4e7f40: 00 00 00 00 00 00 00 02 51 47 09 > > 00 00 00 00 00 QG.. > > [ 102.313043] Padding 88005b4e7f50: 51 47 09 00 00 00 00 00 51 ac 1e > > 27 21 f1 4e ad QG..Q..'!.N. > > [ 102.313043] Padding 88005b4e7f60: 00 00 00 00 00 00 00 f2 00 00 00 > > 00 00 00 00 01 > > [ 102.313044] Padding 88005b4e7f70: 00 00 00 00 00 00 00 01 00 00 0e > > 01 00 00 00 00 > > [ 102.313053] Padding 88005b4e7f80: 00 00 00 00 c1 6d 78 44 ff ff ff > > ff 00 00 00 00 .mxD > > [ 102.313054] Padding 88005b4e7f90: 00 00 00 00 00 00 08 10 36 a0 00 > > 01 00 00 00 00 6... > > [ 102.313062] Padding 88005b4e7fa0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 > > [ 102.313063] Padding 88005b4e7fb0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 > > [ 102.313072] Padding 88005b4e7fc0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 > > [ 102.313073] Padding 88005b4e7fd0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 > > [ 102.313074] Padding 88005b4e7fe0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 > > [ 102.313082] Padding 88005b4e7ff0: 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 29 01 00 .).. > > Oh, look, that contains attributes, and being at the top of a page, > that tallies with the attribute code copying data from the top of > the block down On second thoughts, I'm not so sure of this now. That actually has an inode core in it (the bit starting from "IN"), so it can't be a piece of code from the attribute compaction. So this piece of memory has been used several times by different things before the overwrite has triggered by the look of it. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/5] Enable f2fs support inline data
Hi. Huajun. I agree jaegeuk's opinion. Additionally, It is better that you describe the effect in change-log when this feature is added to f2fs. e.g. 1. how much space is saved when storing kernel-tree(small files) ? 2. small files creation performance test. 3. file look-up performance test. 4. other performance tools 's result. Thanks. 2013/6/4 Jaegeuk Kim : > Hi, > > This feature is one of my todo items. ;) > Thank you for the contribution. > > Before reviewing the below code intensively, we need to check the > following issues. > > - deadlock conditions > - FS consistency > - recovery routine > > Could you check one more time? > Thanks again, > > 2013-06-03 (월), 18:04 +0800, Huajun Li: >> f2fs inode is so large, small files can be stored directly in the inode, >> rather than just storing a single block address and storing the data >> elsewhere. >> >> This RFC patch set is just to enable f2fs support inline data: files less >> than >> about 3.6K can be stored directly in inode block. >> >> TODO: make small dirs inline too. >> >> >> Haicheng Li (3): >> f2fs: Add helper functions and flag to support inline data >> f2fs: Add interface for inline data support >> f2fs: add tracepoints to debug inline data operations >> >> Huajun Li (2): >> f2fs: Handle inline data read and write >> f2fs: Key functions to handle inline data >> >> fs/f2fs/Kconfig | 10 +++ >> fs/f2fs/Makefile|1 + >> fs/f2fs/data.c | 78 +- >> fs/f2fs/f2fs.h | 70 +++ >> fs/f2fs/file.c |9 ++- >> fs/f2fs/inline.c| 156 >> +++ >> fs/f2fs/inode.c |8 +++ >> include/linux/f2fs_fs.h |5 ++ >> include/trace/events/f2fs.h | 69 +++ >> 9 files changed, 402 insertions(+), 4 deletions(-) >> create mode 100644 fs/f2fs/inline.c >> > > -- > Jaegeuk Kim > Samsung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] f2fs: add remount_fs callback support
On 06/01/2013 03:20 PM, Namjae Jeon wrote:
> From: Namjae Jeon
>
> Add the f2fs_remount function call which will be used
> during the filesystem remounting. This function
> will help us to change the mount options specific to
> f2fs.
>
> Also modify the f2fs background_gc mount option, which
> will allow the user to dynamically trun on/off the
> garbage collection in f2fs based on the background_gc
> value. If background_gc=0, Garbage collection will
> be turned off & if background_gc=1, Garbage collection
> will be truned on.
Hi Namjae,
I think splitting these two changes into single ones seems better.
Refer to the inline comments.
Thanks,
Gu
>
> By default the garbage collection is on in f2fs.
>
> Signed-off-by: Namjae Jeon
> Signed-off-by: Pankaj Kumar
> ---
> Documentation/filesystems/f2fs.txt |8 +-
> fs/f2fs/super.c| 223
> +++-
> 2 files changed, 148 insertions(+), 83 deletions(-)
>
> diff --git a/Documentation/filesystems/f2fs.txt
> b/Documentation/filesystems/f2fs.txt
> index bd3c56c..6a036ce 100644
> --- a/Documentation/filesystems/f2fs.txt
> +++ b/Documentation/filesystems/f2fs.txt
> @@ -98,8 +98,12 @@ Cleaning Overhead
> MOUNT OPTIONS
>
>
>
> -background_gc_off Turn off cleaning operations, namely garbage
> collection,
> -triggered in background when I/O subsystem is idle.
> +background_gc=%u Turn on/off cleaning operations, namely garbage
> collection,
> + triggered in background when I/O subsystem is idle. If
> + background_gc=1, it will turn on the garbage
> collection &
> + if background_gc=0, garbage collection will be truned
> off.
> + Default value for this option is 1. So garbage
> collection
> + is on by default.
> disable_roll_forward Disable the roll-forward recovery routine
> discardIssue discard/TRIM commands when a segment is cleaned.
> no_heapDisable heap-style segment allocation which finds free
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 3ac305d..bcd68aa 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -34,7 +34,7 @@
> static struct kmem_cache *f2fs_inode_cachep;
>
> enum {
> - Opt_gc_background_off,
> + Opt_gc_background,
> Opt_disable_roll_forward,
> Opt_discard,
> Opt_noheap,
> @@ -46,7 +46,7 @@ enum {
> };
>
> static match_table_t f2fs_tokens = {
> - {Opt_gc_background_off, "background_gc_off"},
> + {Opt_gc_background, "background_gc=%u"},
> {Opt_disable_roll_forward, "disable_roll_forward"},
> {Opt_discard, "discard"},
> {Opt_noheap, "no_heap"},
> @@ -76,6 +76,86 @@ static void init_once(void *foo)
> inode_init_once(>vfs_inode);
> }
>
> +static int parse_options(struct super_block *sb, struct f2fs_sb_info *sbi,
> + char *options)
> +{
> + substring_t args[MAX_OPT_ARGS];
> + char *p;
> + int arg = 0;
> +
> + if (!options)
> + return 0;
> +
> + while ((p = strsep(, ",")) != NULL) {
> + int token;
> + if (!*p)
> + continue;
> + /*
> + * Initialize args struct so we know whether arg was
> + * found; some options take optional arguments.
> + */
> + args[0].to = args[0].from = NULL;
> + token = match_token(p, f2fs_tokens, args);
> +
> + switch (token) {
> + case Opt_gc_background:
> + if (args->from && match_int(args, ))
> + return -EINVAL;
> + if (arg != 0 && arg != 1)
> + return -EINVAL;
> + if (arg == 0)
> + clear_opt(sbi, BG_GC);
> + else
> + set_opt(sbi, BG_GC);
> + break;
> + case Opt_disable_roll_forward:
> + set_opt(sbi, DISABLE_ROLL_FORWARD);
> + break;
> + case Opt_discard:
> + set_opt(sbi, DISCARD);
> + break;
> + case Opt_noheap:
> + set_opt(sbi, NOHEAP);
> + break;
> +#ifdef CONFIG_F2FS_FS_XATTR
> + case Opt_nouser_xattr:
> + clear_opt(sbi, XATTR_USER);
> + break;
> +#else
> + case Opt_nouser_xattr:
> + f2fs_msg(sb, KERN_INFO,
> + "nouser_xattr options not supported");
> + break;
> +#endif
> +#ifdef CONFIG_F2FS_FS_POSIX_ACL
> + case Opt_noacl:
> + clear_opt(sbi, POSIX_ACL);
> + break;
> +#else
>
Re: 3.9.4 Oops running xfstests (WAS Re: 3.9.3: Oops running xfstests)
On Mon, Jun 03, 2013 at 11:14:56PM -0400, CAI Qian wrote: > > > - Original Message - > > From: "Dave Chinner" > > To: "CAI Qian" > > Cc: x...@oss.sgi.com, sta...@vger.kernel.org, "LKML" > > , "linux-mm" > > Sent: Monday, June 3, 2013 12:00:38 PM > > Subject: Re: 3.9.4 Oops running xfstests (WAS Re: 3.9.3: Oops running > > xfstests) > > > > On Sun, Jun 02, 2013 at 11:04:11PM -0400, CAI Qian wrote: > > > > > > > There's memory corruption all over the place. It is most likely > > > > that trinity is causing this - it's purpose is to trigger corruption > > > > issues, but they aren't always immediately seen. If you can trigger > > > > this xfs trace without trinity having been run and without all the > > > > RCU/idle/scheduler/cgroup issues occuring at the same time, then > > > > it's likely to be caused by XFS. But right now, I'd say XFS is just > > > > an innocent bystander caught in the crossfire. There's nothing I can > > > > do from an XFS persepctive to track this down... > > > OK, this can be reproduced by just running LTP and then xfstests without > > > trinity at all... > > > > Cai, can you be more precise about what is triggering it? LTP and > > xfstests do a large amount of stuff, and stack traces do not do not > > help narrow down the cause at all. Can you provide the follwoing > > information and perform the follwoing steps: > > > > 1. What xfstest is tripping over it? > Test #20. > > 2. Can you reproduce it just by running that one specific test > > on a pristine system (i.e. freshly mkfs'd filesystems, > > immediately after boot) > Yes, it was reproduced without LTP at all. > [ 98.534402] XFS (dm-0): Mounting Filesystem > [ 98.586673] XFS (dm-0): Ending clean mount > [ 99.741704] XFS (dm-2): Mounting Filesystem > [ 100.117248] XFS (dm-2): Ending clean mount > [ 100.723228] XFS (dm-0): Mounting Filesystem > [ 100.775965] XFS (dm-0): Ending clean mount > [ 101.980250] BUG: unable to handle kernel NULL pointer dereference at > 0098 > [ 101.988136] IP: [] tg_load_down+0x4c/0x80 first bug, in scheduler > [ 102.312714] BUG: unable to handle kernel NULL pointer dereference at > 0098 > [ 102.312719] IP: [] tg_load_down+0x4c/0x80 second bug, in scheduler > [ 102.312842] ---[ end trace ba964230a74993ff ]--- > [ 102.312866] general protection fault: [#3] SMP Third bug > [ 102.312903] Pid: 1999, comm: attr Tainted: G D 3.9.4 #1 > Hewlett-Packard HP Z210 Workstation/1587h > [ 102.312908] RIP: 0010:[] [] > irqtime_account_process_tick.isra.2+0x239/0x3c0 In the timer tick code. > [ 102.312909] > = > [ 102.312910] RSP: 0018:88007d083e08 EFLAGS: 00010003 > [ 102.312912] BUG kmalloc-1024 (Tainted: G D ): Padding > overwritten. 0x88005b4e7ec0-0x88005b4e7fff > [ 102.312913] RAX: 88005b656288 RBX: 880079b43c80 RCX: > 00a7 > [ 102.312914] > - And a memory overwrite. > [ 102.313009] Padding 88005b4e7ec0: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 102.313010] Padding 88005b4e7ed0: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 102.313011] Padding 88005b4e7ee0: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 102.313013] Padding 88005b4e7ef0: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 29 01 00 .).. > [ 102.313014] Padding 88005b4e7f00: 07 1b 04 73 65 6c 69 6e 75 78 73 79 > 73 74 65 6d ...selinuxsystem > [ 102.313015] Padding 88005b4e7f10: 5f 75 3a 6f 62 6a 65 63 74 5f 72 3a > 75 73 72 5f _u:object_r:usr_ > [ 102.313032] Padding 88005b4e7f20: 74 3a 73 30 00 00 00 00 49 4e 81 a4 > 02 02 00 00 t:s0IN.. > [ 102.313033] Padding 88005b4e7f30: 00 00 00 00 00 00 00 00 00 00 00 01 > 00 00 00 00 > [ 102.313033] Padding 88005b4e7f40: 00 00 00 00 00 00 00 02 51 47 09 00 > 00 00 00 00 QG.. > [ 102.313043] Padding 88005b4e7f50: 51 47 09 00 00 00 00 00 51 ac 1e 27 > 21 f1 4e ad QG..Q..'!.N. > [ 102.313043] Padding 88005b4e7f60: 00 00 00 00 00 00 00 f2 00 00 00 00 > 00 00 00 01 > [ 102.313044] Padding 88005b4e7f70: 00 00 00 00 00 00 00 01 00 00 0e 01 > 00 00 00 00 > [ 102.313053] Padding 88005b4e7f80: 00 00 00 00 c1 6d 78 44 ff ff ff ff > 00 00 00 00 .mxD > [ 102.313054] Padding 88005b4e7f90: 00 00 00 00 00 00 08 10 36 a0 00 01 > 00 00 00 00 6... > [ 102.313062] Padding 88005b4e7fa0: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 102.313063] Padding 88005b4e7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 102.313072] Padding 88005b4e7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 >
[PATCH V3] misc: replace strict_strtoul() with kstrtoul()
The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.
Signed-off-by: Jingoo Han
Reviewed-by: Andy Shevchenko
---
Changes since v1:
- Split to two sequential checks.
- Replaced kstrtoul() & copy_from_user() with kstrtoul_from_user().
- Added Andy Shevchenko's Reviewed-by.
Changes since v1:
- Used return code from kstrtoul().
drivers/misc/ad525x_dpot.c |2 +-
drivers/misc/apds9802als.c |5 +--
drivers/misc/apds990x.c | 37 ---
drivers/misc/bh1770glc.c| 59 ---
drivers/misc/bh1780gli.c|2 +-
drivers/misc/carma/carma-fpga-program.c | 10 +++---
drivers/misc/carma/carma-fpga.c |4 +--
drivers/misc/hmc6352.c |5 +--
drivers/misc/isl29003.c | 24 ++---
drivers/misc/isl29020.c |6 ++--
drivers/misc/lis3lv02d/lis3lv02d.c |6 ++--
drivers/misc/sgi-gru/gruprocfs.c| 14 +++-
drivers/misc/spear13xx_pcie_gadget.c| 57 +++--
drivers/misc/ti_dac7512.c |6 ++--
14 files changed, 154 insertions(+), 83 deletions(-)
diff --git a/drivers/misc/ad525x_dpot.c b/drivers/misc/ad525x_dpot.c
index 8f99e8e..0daadcf 100644
--- a/drivers/misc/ad525x_dpot.c
+++ b/drivers/misc/ad525x_dpot.c
@@ -470,7 +470,7 @@ static ssize_t sysfs_set_reg(struct device *dev,
!test_bit(DPOT_RDAC_MASK & reg, data->otp_en_mask))
return -EPERM;
- err = strict_strtoul(buf, 10, );
+ err = kstrtoul(buf, 10, );
if (err)
return err;
diff --git a/drivers/misc/apds9802als.c b/drivers/misc/apds9802als.c
index 5b5fd84..0c6e037 100644
--- a/drivers/misc/apds9802als.c
+++ b/drivers/misc/apds9802als.c
@@ -126,8 +126,9 @@ static ssize_t als_sensing_range_store(struct device *dev,
int ret_val;
unsigned long val;
- if (strict_strtoul(buf, 10, ))
- return -EINVAL;
+ ret_val = kstrtoul(buf, 10, );
+ if (ret_val)
+ return ret_val;
if (val < 4096)
val = 1;
diff --git a/drivers/misc/apds990x.c b/drivers/misc/apds990x.c
index 98f9bb2..868a30a 100644
--- a/drivers/misc/apds990x.c
+++ b/drivers/misc/apds990x.c
@@ -696,9 +696,11 @@ static ssize_t apds990x_lux_calib_store(struct device *dev,
{
struct apds990x_chip *chip = dev_get_drvdata(dev);
unsigned long value;
+ int ret;
- if (strict_strtoul(buf, 0, ))
- return -EINVAL;
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
chip->lux_calib = value;
@@ -759,8 +761,9 @@ static ssize_t apds990x_rate_store(struct device *dev,
unsigned long value;
int ret;
- if (strict_strtoul(buf, 0, ))
- return -EINVAL;
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
mutex_lock(>mutex);
ret = apds990x_set_arate(chip, value);
@@ -813,9 +816,11 @@ static ssize_t apds990x_prox_enable_store(struct device
*dev,
{
struct apds990x_chip *chip = dev_get_drvdata(dev);
unsigned long value;
+ int ret;
- if (strict_strtoul(buf, 0, ))
- return -EINVAL;
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
mutex_lock(>mutex);
@@ -892,11 +897,12 @@ static ssize_t apds990x_lux_thresh_below_show(struct
device *dev,
static ssize_t apds990x_set_lux_thresh(struct apds990x_chip *chip, u32 *target,
const char *buf)
{
- int ret = 0;
unsigned long thresh;
+ int ret;
- if (strict_strtoul(buf, 0, ))
- return -EINVAL;
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
if (thresh > APDS_RANGE)
return -EINVAL;
@@ -957,9 +963,11 @@ static ssize_t apds990x_prox_threshold_store(struct device
*dev,
{
struct apds990x_chip *chip = dev_get_drvdata(dev);
unsigned long value;
+ int ret;
- if (strict_strtoul(buf, 0, ))
- return -EINVAL;
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
if ((value > APDS_RANGE) || (value == 0) ||
(value < APDS_PROX_HYSTERESIS))
@@ -990,9 +998,12 @@ static ssize_t apds990x_power_state_store(struct device
*dev,
{
struct apds990x_chip *chip = dev_get_drvdata(dev);
unsigned long value;
+ int ret;
+
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
- if (strict_strtoul(buf, 0, ))
- return -EINVAL;
if (value) {
pm_runtime_get_sync(dev);
mutex_lock(>mutex);
diff --git a/drivers/misc/bh1770glc.c b/drivers/misc/bh1770glc.c
index f4975f7..99a0468 100644
---
[PATCH V3] rtc: rtc-pcf2123: replace strict_strtoul() with kstrtoul()
The usage of strict_strtoul() is not preferred, because strict_strtoul() is obsolete. Thus, kstrtoul() should be used. Signed-off-by: Jingoo Han Reviewed-by: Andy Shevchenko --- Changes since v1: - Splitted to two sequential checks. - Added Andy Shevchenko's Reviewed-by. Changes since v1: - Used return code from kstrtoul(). drivers/rtc/rtc-pcf2123.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-pcf2123.c b/drivers/rtc/rtc-pcf2123.c index b2a78a0..1725b50 100644 --- a/drivers/rtc/rtc-pcf2123.c +++ b/drivers/rtc/rtc-pcf2123.c @@ -94,8 +94,9 @@ static ssize_t pcf2123_show(struct device *dev, struct device_attribute *attr, r = container_of(attr, struct pcf2123_sysfs_reg, attr); - if (strict_strtoul(r->name, 16, )) - return -EINVAL; + ret = kstrtoul(r->name, 16, ); + if (ret) + return ret; txbuf[0] = PCF2123_READ | reg; ret = spi_write_then_read(spi, txbuf, 1, rxbuf, 1); @@ -117,9 +118,13 @@ static ssize_t pcf2123_store(struct device *dev, struct device_attribute *attr, r = container_of(attr, struct pcf2123_sysfs_reg, attr); - if (strict_strtoul(r->name, 16, ) - || strict_strtoul(buffer, 10, )) - return -EINVAL; + ret = kstrtoul(r->name, 16, ); + if (ret) + return ret; + + ret = kstrtoul(buffer, 10, ); + if (ret) + return ret; txbuf[0] = PCF2123_WRITE | reg; txbuf[1] = val; -- 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 V3] mfd: replace strict_strtoul() with kstrtoul()
The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.
Signed-off-by: Jingoo Han
Reviewed-by: Andy Shevchenko
---
Changes since v1:
- Removed redundant variables 'u8 reg'.
- Changed the type of 'user_value' from 'unsigned long' to 'u8'.
- Replaced kstrtoul() with kstrtou8() to handle u8 variable.
- Added Andy Shevchenko's Reviewed-by.
Changes since v1:
- Used return code from kstrtoul().
- Changed the type of 'user_reg' from 'unsigned long' to 'u8'.
- Replaced kstrtoul() with kstrtou8() to handle u8 variable.
drivers/mfd/aat2870-core.c |5 +++--
drivers/mfd/ab3100-core.c| 28 ++--
drivers/mfd/ab8500-debugfs.c |2 +-
3 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/mfd/aat2870-core.c b/drivers/mfd/aat2870-core.c
index dfdb0a2..d4f5945 100644
--- a/drivers/mfd/aat2870-core.c
+++ b/drivers/mfd/aat2870-core.c
@@ -312,8 +312,9 @@ static ssize_t aat2870_reg_write_file(struct file *file,
while (*start == ' ')
start++;
- if (strict_strtoul(start, 16, ))
- return -EINVAL;
+ ret = kstrtoul(start, 16, );
+ if (ret)
+ return ret;
ret = aat2870->write(aat2870, (u8)addr, (u8)val);
if (ret)
diff --git a/drivers/mfd/ab3100-core.c b/drivers/mfd/ab3100-core.c
index a9bb140..ddc669d 100644
--- a/drivers/mfd/ab3100-core.c
+++ b/drivers/mfd/ab3100-core.c
@@ -491,7 +491,7 @@ static ssize_t ab3100_get_set_reg(struct file *file,
char buf[32];
ssize_t buf_size;
int regp;
- unsigned long user_reg;
+ u8 user_reg;
int err;
int i = 0;
@@ -514,34 +514,29 @@ static ssize_t ab3100_get_set_reg(struct file *file,
/*
* Advance pointer to end of string then terminate
* the register string. This is needed to satisfy
-* the strict_strtoul() function.
+* the kstrtou8() function.
*/
while ((i < buf_size) && (buf[i] != ' '))
i++;
buf[i] = '\0';
- err = strict_strtoul([regp], 16, _reg);
+ err = kstrtou8([regp], 16, _reg);
if (err)
return err;
- if (user_reg > 0xff)
- return -EINVAL;
/* Either we read or we write a register here */
if (!priv->mode) {
/* Reading */
- u8 reg = (u8) user_reg;
u8 regvalue;
- ab3100_get_register_interruptible(ab3100, reg, );
+ ab3100_get_register_interruptible(ab3100, user_reg, );
dev_info(ab3100->dev,
"debug read AB3100 reg[0x%02x]: 0x%02x\n",
-reg, regvalue);
+user_reg, regvalue);
} else {
int valp;
- unsigned long user_value;
- u8 reg = (u8) user_reg;
- u8 value;
+ u8 user_value;
u8 regvalue;
/*
@@ -557,20 +552,17 @@ static ssize_t ab3100_get_set_reg(struct file *file,
i++;
buf[i] = '\0';
- err = strict_strtoul([valp], 16, _value);
+ err = kstrtou8([valp], 16, _value);
if (err)
return err;
- if (user_reg > 0xff)
- return -EINVAL;
- value = (u8) user_value;
- ab3100_set_register_interruptible(ab3100, reg, value);
- ab3100_get_register_interruptible(ab3100, reg, );
+ ab3100_set_register_interruptible(ab3100, user_reg, user_value);
+ ab3100_get_register_interruptible(ab3100, user_reg, );
dev_info(ab3100->dev,
"debug write reg[0x%02x] with 0x%02x, "
"after readback: 0x%02x\n",
-reg, value, regvalue);
+user_reg, user_value, regvalue);
}
return buf_size;
}
diff --git a/drivers/mfd/ab8500-debugfs.c b/drivers/mfd/ab8500-debugfs.c
index 37b7ce4..11656c2 100644
--- a/drivers/mfd/ab8500-debugfs.c
+++ b/drivers/mfd/ab8500-debugfs.c
@@ -2757,7 +2757,7 @@ static ssize_t show_irq(struct device *dev,
unsigned int irq_index;
int err;
- err = strict_strtoul(attr->attr.name, 0, );
+ err = kstrtoul(attr->attr.name, 0, );
if (err)
return 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/
Re: [PATCH 06/10] mmc: dw_mmc-pltfm: add Rockchip variant
On 06/03/2013 07:59 AM, Heiko Stübner wrote:
> Cortex-A9 SoCs from Rockchip use a slightly modified variant of dw_mmc
> controllers that seems to require the SDMMC_CMD_USE_HOLD_REG bit to
> always be set.
>
> There also seem to be no other modifications (additional register etc)
> present, so to keep the footprint low, add this small variant to the
> pltfm driver.
>
> Signed-off-by: Heiko Stuebner
> ---
> drivers/mmc/host/dw_mmc-pltfm.c | 48 +++---
> 1 files changed, 34 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index 0048da8..7d041b5 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -24,6 +24,16 @@
>
> #include "dw_mmc.h"
>
> +
> +static void dw_mci_rockchip_prepare_command(struct dw_mci *host, u32 *cmdr)
How about using "dw_mci_pltfm_prepare_command()"?
Maybe HOLD_REG could be used at other SoC.
> +{
> + *cmdr |= SDMMC_CMD_USE_HOLD_REG;
> +}
> +
> +static const struct dw_mci_drv_data rockchip_drv_data = {
> + .prepare_command= dw_mci_rockchip_prepare_command,
> +};
> +
> int dw_mci_pltfm_register(struct platform_device *pdev,
> const struct dw_mci_drv_data *drv_data)
> {
> @@ -63,20 +73,6 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
> }
> EXPORT_SYMBOL_GPL(dw_mci_pltfm_register);
>
> -static int dw_mci_pltfm_probe(struct platform_device *pdev)
> -{
> - return dw_mci_pltfm_register(pdev, NULL);
> -}
> -
> -int dw_mci_pltfm_remove(struct platform_device *pdev)
> -{
> - struct dw_mci *host = platform_get_drvdata(pdev);
> -
> - dw_mci_remove(host);
> - return 0;
> -}
> -EXPORT_SYMBOL_GPL(dw_mci_pltfm_remove);
> -
> #ifdef CONFIG_PM_SLEEP
> /*
> * TODO: we should probably disable the clock to the card in the suspend
> path.
> @@ -114,10 +110,34 @@ EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
>
> static const struct of_device_id dw_mci_pltfm_match[] = {
> { .compatible = "snps,dw-mshc", },
> + { .compatible = "rockchip,cortex-a9-dw-mshc",
> + .data = _drv_data },
> {},
> };
> MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
>
> +static int dw_mci_pltfm_probe(struct platform_device *pdev)
> +{
> + const struct dw_mci_drv_data *drv_data = NULL;
> + const struct of_device_id *match;
> +
> + if (pdev->dev.of_node) {
> + match = of_match_node(dw_mci_pltfm_match, pdev->dev.of_node);
> + drv_data = match->data;
> + }
> +
> + return dw_mci_pltfm_register(pdev, drv_data);
> +}
> +
> +int dw_mci_pltfm_remove(struct platform_device *pdev)
> +{
> + struct dw_mci *host = platform_get_drvdata(pdev);
> +
> + dw_mci_remove(host);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(dw_mci_pltfm_remove);
> +
> static struct platform_driver dw_mci_pltfm_driver = {
> .probe = dw_mci_pltfm_probe,
> .remove = dw_mci_pltfm_remove,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/10] mmc: dw_mmc-pltfm: remove static from dw_mci_pltfm_remove
Acked-by: Jaehoon Chung
On 06/03/2013 07:58 AM, Heiko Stübner wrote:
> dw_mci_pltfm_remove gets exported and used by dw_mmc-exynos, so should
> not be static.
>
> Signed-off-by: Heiko Stuebner
> ---
> drivers/mmc/host/dw_mmc-pltfm.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index 37873f1..0048da8 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -68,7 +68,7 @@ static int dw_mci_pltfm_probe(struct platform_device *pdev)
> return dw_mci_pltfm_register(pdev, NULL);
> }
>
> -static int dw_mci_pltfm_remove(struct platform_device *pdev)
> +int dw_mci_pltfm_remove(struct platform_device *pdev)
> {
> struct dw_mci *host = platform_get_drvdata(pdev);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Modify UEFI anti-bricking code
於 一，2013-06-03 於 16:31 +，Matthew Garrett 提到：
> On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote:
>
> > Oliver raised a question for if power fails between that succesful
> > attempt and the deletion?
>
> It's a pretty tiny window, but sure. Making sure we delete it seems
> sensible. In that case we should make the GUID a #define rather than
> write it out twice.
>
Base on your patch, the following diff moved DUMMY GUID to #define, and
add a static efi name string:
Thanks a lot!
Joey Lee
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 63e167a..cc3cfe8 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -53,6 +53,11 @@
#define EFI_DEBUG 1
+#define EFI_DUMMY_GUID \
+ EFI_GUID(0x4424ac57, 0xbe4b, 0x47dd, 0x9e, 0x97, 0xed, 0x50, 0xf0,
0x9f, 0x92, 0xa9)
+
+static efi_char16_t efi_dummy_name[6] = { 'D', 'U', 'M', 'M', 'Y', 0 };
+
struct efi __read_mostly efi = {
.mps= EFI_INVALID_TABLE_ADDR,
.acpi = EFI_INVALID_TABLE_ADDR,
@@ -981,6 +986,9 @@ void __init efi_enter_virtual_mode(void)
runtime_code_page_mkexec();
kfree(new_memmap);
+
+ /* clean DUMMY object */
+ efi.set_variable(efi_dummy_name, _DUMMY_GUID, 0, 0, NULL);
}
/*
@@ -1051,21 +1059,17 @@ efi_status_t efi_query_variable_store(u32 attributes,
unsigned long size)
*/
unsigned long dummy_size = remaining_size + 1024;
void *dummy = kmalloc(dummy_size, GFP_ATOMIC);
- efi_char16_t efi_name[6] = { 'D', 'U', 'M', 'M', 'Y', 0 };
- efi_guid_t guid = EFI_GUID(0x4424ac57, 0xbe4b, 0x47dd, 0x9e,
- 0x97, 0xed, 0x50, 0xf0, 0x9f, 0x92,
- 0xa9);
- status = efi.set_variable(efi_name, , attributes,
- dummy_size, dummy);
+ status = efi.set_variable(efi_dummy_name, _DUMMY_GUID,
+ attributes, dummy_size, dummy);
if (status == EFI_SUCCESS) {
/*
* This should have failed, so if it didn't make sure
* that we delete it...
*/
- efi.set_variable(efi_name, , attributes, 0,
-dummy);
+ efi.set_variable(efi_dummy_name, _DUMMY_GUID,
+attributes, 0, dummy);
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.4 Oops running xfstests (WAS Re: 3.9.3: Oops running xfstests)
- Original Message - > From: "Dave Chinner" > To: "CAI Qian" > Cc: x...@oss.sgi.com, sta...@vger.kernel.org, "LKML" > , "linux-mm" > Sent: Monday, June 3, 2013 12:00:38 PM > Subject: Re: 3.9.4 Oops running xfstests (WAS Re: 3.9.3: Oops running > xfstests) > > On Sun, Jun 02, 2013 at 11:04:11PM -0400, CAI Qian wrote: > > > > > There's memory corruption all over the place. It is most likely > > > that trinity is causing this - it's purpose is to trigger corruption > > > issues, but they aren't always immediately seen. If you can trigger > > > this xfs trace without trinity having been run and without all the > > > RCU/idle/scheduler/cgroup issues occuring at the same time, then > > > it's likely to be caused by XFS. But right now, I'd say XFS is just > > > an innocent bystander caught in the crossfire. There's nothing I can > > > do from an XFS persepctive to track this down... > > OK, this can be reproduced by just running LTP and then xfstests without > > trinity at all... > > Cai, can you be more precise about what is triggering it? LTP and > xfstests do a large amount of stuff, and stack traces do not do not > help narrow down the cause at all. Can you provide the follwoing > information and perform the follwoing steps: > > 1. What xfstest is tripping over it? Test #20. > 2. Can you reproduce it just by running that one specific test > on a pristine system (i.e. freshly mkfs'd filesystems, > immediately after boot) Yes, it was reproduced without LTP at all. [ 98.534402] XFS (dm-0): Mounting Filesystem [ 98.586673] XFS (dm-0): Ending clean mount [ 99.741704] XFS (dm-2): Mounting Filesystem [ 100.117248] XFS (dm-2): Ending clean mount [ 100.723228] XFS (dm-0): Mounting Filesystem [ 100.775965] XFS (dm-0): Ending clean mount [ 101.980250] BUG: unable to handle kernel NULL pointer dereference at 0098 [ 101.988136] IP: [] tg_load_down+0x4c/0x80 [ 101.993737] PGD 0 [ 101.995769] Oops: 0002 [#1] SMP [ 101.999038] Modules linked in: lockd sunrpc nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_nat nf_nat_ipv6 ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables sg snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm hp_wmi sparse_keymap rfkill iTCO_wdt e1000e pcspkr snd_page_alloc iTCO_vendor_support mei ptp pps_core lpc_ich i2c_i801 snd_timer mfd_core microcode(+) snd soundcore xfs libcrc32c sr_mod sd_mod cdrom crc_t10dif nouveau video mxm_wmi i2c_algo_bit drm_kms_helper ahci ata_generic ttm libahci pata_acpi drm i2c_core libata wmi dm_mirror dm_region_hash dm_log dm_mod [ 102.075355] CPU 2 [ 102.077197] Pid: 356, comm: kworker/2:2 Not tainted 3.9.4 #1 Hewlett-Packard HP Z210 Workstation/1587h [ 102.086691] RIP: 0010:[] [] tg_load_down+0x4c/0x80 [ 102.094705] RSP: 0018:880078307c78 EFLAGS: 00010002 [ 102.100020] RAX: 0001f2b5a618ed0f RBX: 0001 RCX: 068a [ 102.107157] RDX: RSI: 0001 RDI: 8800772ceee8 [ 102.114293] RBP: 880078307c78 R08: 0008 R09: 88007d094400 [ 102.121422] R10: 0344 R11: 0001 R12: 81c78560 [ 102.128552] R13: 8108c460 R14: R15: 8800772ceee8 [ 102.135682] FS: () GS:88007d10() knlGS: [ 102.143776] CS: 0010 DS: ES: CR0: 80050033 [ 102.149524] CR2: 0098 CR3: 018fa000 CR4: 000407e0 [ 102.156654] DR0: DR1: DR2: [ 102.163785] DR3: DR6: 0ff0 DR7: 0400 [ 102.170915] Process kworker/2:2 (pid: 356, threadinfo 880078306000, task 88007736b580) [ 102.179527] Stack: [ 102.181545] 880078307cc0 810926b2 81098c60 8800772cf008 [ 102.189005] 880079b96f00 069c 880079b96ee8 00014400 [ 102.196464] 88007d094400 880078307db0 8109f773 88007cc10480 [ 102.203920] Call Trace: [ 102.206372] [] walk_tg_tree_from+0x32/0xe0 [ 102.212118] [] ? task_waking_fair+0x20/0x20 [ 102.217955] [] load_balance+0x2a3/0x7d0 [ 102.223444] [] ? update_rq_clock.part.67+0x1c/0x170 [ 102.229977] [] idle_balance+0x182/0x2f0 [ 102.235468] [] __schedule+0x7bc/0x7d0 [ 102.240786] [] schedule+0x29/0x70 [ 102.245756] [] worker_thread+0x1b4/0x3d0 [ 102.251332] [] ? __alloc_workqueue_key+0x500/0x500 [ 102.25] [] kthread+0xc0/0xd0 [ 102.262662] [] ? insert_kthread_work+0x40/0x40 [ 102.268761] [] ret_from_fork+0x7c/0xb0 [ 102.274164] [] ? insert_kthread_work+0x40/0x40 [ 102.280262] Code: 00 00 00 00 48 8b 14 f0 48 8b 0c f1 48 8b
Re: [PATCH] [RFC]Watchdog:core: constant pinging until userspace timesout when delay very less
On Tue, Jun 4, 2013 at 3:55 AM, Guenter Roeck wrote: > On Mon, Jun 03, 2013 at 10:23:04PM +0530, anish singh wrote: >> On Mon, Jun 3, 2013 at 8:57 PM, Guenter Roeck wrote: >> > On Sun, Jun 02, 2013 at 03:43:07PM +0530, anish kumar wrote: >> >> Certain watchdog drivers use a timer to keep kicking the watchdog at >> >> a rate of 0.5s (HZ/2) untill userspace times out.They do this as >> >> we can't guarantee that watchdog will be pinged fast enough >> >> for all system loads, especially if timeout is configured for >> >> less than or equal to 1 second(basically small values). >> >> >> >> As suggested by Wim Van Sebroeck & Guenter Roeck we should >> >> add this functionality of individual watchdog drivers in the core >> >> watchdog core. >> >> >> >> Signed-off-by: anish kumar >> > >> > Not exactly what I had in mind. My idea was to enable the softdog only if >> > the hardware watchdog's maximum timeout was low (say, less than a couple >> > of minutes), and if a timeout larger than its maximum value was configured. >> >> watchdog_timeout_invalid wouldn't this check will fail if the user space >> tries >> to set maximum timeout more that what driver can support?It would work >> for pika_wdt.c as it is old watchdog driver and doesn't register with >> watchdog >> framwork but new drivers has to pass this api. >> >> OR >> >> Do you want to remove this check and go as explained by you?I would >> favour this approach though. >> > One would still have a check, but the enforced limits would no longer be > the driver limits, but larger limits implemented in the watchdog core. How much larger would be the big question here?Should it be configurable property(sysfs?) or some hardcoding based on existing drivers? Before going for next patch, it would be better for me to wait for some more comments. > >> > In that case, I would have set the hardware watchdog to its maximum value >> > and use the softdog to ping it at a rate of, say, 50% of this maximum. >> > >> > If userspace would not ping the watchdog within its configured value, >> > I would stop pinging the hardware watchdog and let it time out. >> >> One more question.Why is the return value of watchdog_ping int? Anyway >> we discard it. > > I can not answer that question. > > Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DISCUSSION] removing variety rq->cpu_load ?
On 06/04/2013 10:44 AM, Alex Shi wrote:
> On 06/04/2013 10:33 AM, Michael Wang wrote:
>> Hi, Alex
>>
>> On 06/04/2013 09:51 AM, Alex Shi wrote:
>>> resend with a new subject.
>>
>> Forgive me but I'm a little lost on this thread...
>>
>> So we are planing to rely on instant 'cpu_load[0]' and decayed
>> 'runnable_load_avg' only, do we?
>
> cpu_load is a kind of time decay for cpu load, but after runnable load
> introduced,
> the decay functionality is a kind duplicate with it.
> So, remove them will make code simple. The idea were mentioned by Paul, Peter
> and I.
Nice, what about make a patch 9 and clean up all those stuff?
I suppose we will get more benefit :)
Regards,
Michael Wang
>
> the following is Peter's word of this affair.
>
>> Agreed, esp. the plethora of weird idx things we currently have. If we need
>> to
>> re-introduce something it would likely only be the busy case and for that we
>> can immediately link to the balance interval or so.
>
>
>>
>>
>> Regards,
>> Michael Wang
>>
>>>
Peter,
I just tried to remove the variety rq.cpu_load, by the following patch.
Because forkexec_idx and busy_idx are all zero, after the patch system
just keep cpu_load[0]
and remove other values.
I tried the patch base 3.10-rc3 and latest tip/sched/core with benchmark
dbench,tbench,
aim7,hackbench. and oltp of sysbench. Seems performance doesn't change
clear.
So, for my tested machines, core2, NHM, SNB, with 2 or 4 CPU sockets, and
above tested
benchmark. We are fine to remove the variety cpu_load.
Don't know if there some other concerns on other scenarios.
---
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 590d535..f0ca983 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4626,7 +4626,7 @@ static inline void update_sd_lb_stats(struct lb_env
*env,
if (child && child->flags & SD_PREFER_SIBLING)
prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle);
+ load_idx = 0; //get_sd_load_idx(env->sd, env->idle);
do {
int local_group;
>>>
>>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] raise the maximum number of usb-serial devices to 512
On Mon, Jun 03, 2013 at 07:49:59PM -0700, Greg Kroah-Hartman wrote:
> On Mon, May 27, 2013 at 02:28:51PM +0200, Bjørn Mork wrote:
> > But, IMHO, a nicer approach would be to make the allocation completely
> > dynamic, using e.g. the idr subsystem. Static tables are always feel
> > like straight jackets to me, no matter how big they are :)
>
> You are right, I didn't change the code to use idr (it predates idr by
> about a decade or so), because I thought we needed the "rage" logic that
> the usb-serial minor reservation does.
Rage logic sounds like my kinda code.
> +static int get_free_port(struct usb_serial_port *port)
> {
> -unsigned int i, j;
> -int good_spot;
> -
> -dev_dbg(>interface->dev, "%s %d\n", __func__, num_ports);
> +int i;
>
> -*minor = 0;
> mutex_lock(_lock);
> -for (i = 0; i < SERIAL_TTY_MINORS; ++i) {
> -if (serial_table[i])
> -continue;
> +i = idr_alloc(_minors, port, 0, 0, GFP_KERNEL);
> +if (i < 0)
> +return -EEXIST;
> +port->number = i;
> +mutex_unlock(_lock);
> +return i;
> +}
-EEXIST case misses the mutex unlock.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] SELinux: cache inode checks inside struct inode
On 6/3/2013 4:18 PM, Eric Paris wrote: > On Tue, 2013-06-04 at 06:31 +0900, Linus Torvalds wrote: >> >> On Mon, 3 Jun 2013, Eric Paris wrote: >>> >>> #ifdef CONFIG_SECURITY >>> + seqcount_t i_security_seqcount; >>> + u32 i_last_task_sid; >>> + u32 i_last_granting; >>> + u32 i_last_perms; >>> + u32 i_audit_allow; >>> void*i_security; >>> #endif >> This is much too big. I was really hoping for "another word that the >> security layer can use" or similar. > Not sure how that can work :-( > >> Something this big would be acceptable if it would be a *generic* security >> cache, and others could use it too, and would avoid ever actually calling >> into any security layer at all (ie we could do the checks entirely at the >> VFS layer). Then it would be fine. But for just the fact that SELinux is >> too slow? No. > There is nothing about it that can't be VFS-erized. The fields are: > > readlockless way to get the data > which task was allowed > which perms were allowed > what generation of security policy allowed it > what perms should be forced to call security hook anyway You've defined all of these things as u32 (that is, secids). Secids are an SELinux artifact and do not belong in general purpose interfaces. > defining "perms" from a VFS PoV is hard. Yes, it is. But I think that for this to work we can't be looking at the perms, we have to be looking at a previous determination that can be used to accurately predict what the outcome would be if we did look at the perms. If, for example, we saved the pid (in a reuse safe way) of the last process to successfully access the inode you wouldn't need to look at any perms (unless the configuration changed) for that pid again. Yeah, yeah, I know that is an oversimplification that would likely gain precious little advantage.I seriously doubt it would be worth doing. > doing any of this with 'stacking' is hard. Then again, I'm only so so > on the value of stacking. I've waffled a few times... That's another reason why cashing certain attributes isn't a good idea, but that caching a result might have value. > I can do it entirely inside selinux, but we are still going to have the > cache hit you were originally seeing as we dereference isec to get the > info > > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] raise the maximum number of usb-serial devices to 512
On Mon, May 27, 2013 at 02:28:51PM +0200, Bjørn Mork wrote:
> But, IMHO, a nicer approach would be to make the allocation completely
> dynamic, using e.g. the idr subsystem. Static tables are always feel
> like straight jackets to me, no matter how big they are :)
You are right, I didn't change the code to use idr (it predates idr by
about a decade or so), because I thought we needed the "rage" logic that
the usb-serial minor reservation does.
But I'm not so sure anymore, so here's a patch to change to use the idr
code, and should remove all minor number limitations (well 65k is the
limit the tty core should be setting I think.)
Tobias, can you test this patch out? Note, I only compiled it, did not
get the chance to actually run it, so it might not work at all.
thanks,
greg k-h
Subject: [PATCH] usb: serial: remove minor number limitation of 255
Signed-off-by: Greg Kroah-Hartman
drivers/usb/serial/usb-serial.c | 86 +---
1 file changed, 38 insertions(+), 48 deletions(-)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 4753c00..74b6f08 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "pl2303.h"
#define DRIVER_AUTHOR "Greg Kroah-Hartman "
@@ -49,7 +50,7 @@
drivers depend on it.
*/
-static struct usb_serial *serial_table[SERIAL_TTY_MINORS];
+static DEFINE_IDR(serial_minors);
static DEFINE_MUTEX(table_lock);
static LIST_HEAD(usb_serial_driver_list);
@@ -61,59 +62,52 @@ static LIST_HEAD(usb_serial_driver_list);
struct usb_serial *usb_serial_get_by_index(unsigned index)
{
struct usb_serial *serial;
+ struct usb_serial_port *port;
mutex_lock(_lock);
- serial = serial_table[index];
-
- if (serial) {
- mutex_lock(>disc_mutex);
- if (serial->disconnected) {
- mutex_unlock(>disc_mutex);
- serial = NULL;
- } else {
- kref_get(>kref);
- }
- }
+ port = idr_find(_minors, index);
mutex_unlock(_lock);
+ if (!port)
+ return NULL;
+
+ serial = port->serial;
+ kref_get(>kref);
return serial;
}
-static struct usb_serial *get_free_serial(struct usb_serial *serial,
- int num_ports, unsigned int *minor)
+static int get_free_port(struct usb_serial_port *port)
{
- unsigned int i, j;
- int good_spot;
-
- dev_dbg(>interface->dev, "%s %d\n", __func__, num_ports);
+ int i;
- *minor = 0;
mutex_lock(_lock);
- for (i = 0; i < SERIAL_TTY_MINORS; ++i) {
- if (serial_table[i])
- continue;
+ i = idr_alloc(_minors, port, 0, 0, GFP_KERNEL);
+ if (i < 0)
+ return -EEXIST;
+ port->number = i;
+ mutex_unlock(_lock);
+ return i;
+}
- good_spot = 1;
- for (j = 1; j <= num_ports-1; ++j)
- if ((i+j >= SERIAL_TTY_MINORS) || (serial_table[i+j])) {
- good_spot = 0;
- i += j;
- break;
- }
- if (good_spot == 0)
- continue;
+static int get_free_serial(struct usb_serial *serial, int num_ports,
+ unsigned int *minor)
+{
+ unsigned int i;
+ unsigned int x;
- *minor = i;
- j = 0;
- dev_dbg(>interface->dev, "%s - minor base = %d\n",
__func__, *minor);
- for (i = *minor; (i < (*minor + num_ports)) && (i <
SERIAL_TTY_MINORS); ++i) {
- serial_table[i] = serial;
- serial->port[j++]->number = i;
- }
- mutex_unlock(_lock);
- return serial;
+ dev_dbg(>interface->dev, "%s %d\n", __func__, num_ports);
+
+ *minor = 0x;
+ for (i = 0; i < num_ports; ++i) {
+ x = get_free_port(serial->port[i]);
+ if (x < 0)
+ goto error;
+ if (*minor == 0x)
+ *minor = x;
}
- mutex_unlock(_lock);
- return NULL;
+ return 0;
+error:
+ // FIXME unwind the already allocated minors
+ return -ENODEV;
}
static void return_serial(struct usb_serial *serial)
@@ -122,7 +116,7 @@ static void return_serial(struct usb_serial *serial)
mutex_lock(_lock);
for (i = 0; i < serial->num_ports; ++i)
- serial_table[serial->minor + i] = NULL;
+ idr_remove(_minors, serial->port[i]->number);
mutex_unlock(_lock);
}
@@ -1041,7 +1035,7 @@ static int usb_serial_probe(struct usb_interface
*interface,
*/
serial->disconnected = 1;
Re: [PATCH 1/2] spi: atmel: convert to dma_request_slave_channel_compat()
Richard Genoud wrote:
Use generic DMA DT helper.
Platforms booting with or without DT populated are both supported.
Based on Ludovic Desroches patchset
"ARM: at91: move to generic DMA device tree binding"
Signed-off-by: Richard Genoud
---
drivers/spi/spi-atmel.c | 42 +++---
1 file changed, 27 insertions(+), 15 deletions(-)
rebased on linux-next next-20130531
Tested on at91sam9g25ek,
Based on linux-next, next-20130603
plus Ludovic Desroches' patch "ARM: at91: dt: add header to define
at_hdmac configuration"
Tested-by: Wenyou Yang
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 31cfc87..ea1ec00 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -424,10 +424,15 @@ static int atmel_spi_dma_slave_config(struct atmel_spi
*as,
return err;
}
-static bool filter(struct dma_chan *chan, void *slave)
+static bool filter(struct dma_chan *chan, void *pdata)
{
- struct at_dma_slave *sl = slave;
+ struct atmel_spi_dma *sl_pdata = pdata;
+ struct at_dma_slave *sl;
+ if (!sl_pdata)
+ return false;
+
+ sl = _pdata->dma_slave;
if (sl->dma_dev == chan->device->dev) {
chan->private = sl;
return true;
@@ -438,24 +443,31 @@ static bool filter(struct dma_chan *chan, void *slave)
static int atmel_spi_configure_dma(struct atmel_spi *as)
{
- struct at_dma_slave *sdata = >dma.dma_slave;
struct dma_slave_config slave_config;
+ struct device *dev = >pdev->dev;
int err;
- if (sdata && sdata->dma_dev) {
- dma_cap_mask_t mask;
+ dma_cap_mask_t mask;
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
- /* Try to grab two DMA channels */
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
- as->dma.chan_tx = dma_request_channel(mask, filter, sdata);
- if (as->dma.chan_tx)
- as->dma.chan_rx =
- dma_request_channel(mask, filter, sdata);
+ as->dma.chan_tx = dma_request_slave_channel_compat(mask, filter,
+ >dma,
+ dev, "tx");
+ if (!as->dma.chan_tx) {
+ dev_err(dev,
+ "DMA TX channel not available, SPI unable to use
DMA\n");
+ err = -EBUSY;
+ goto error;
}
- if (!as->dma.chan_rx || !as->dma.chan_tx) {
- dev_err(>pdev->dev,
- "DMA channel not available, SPI unable to use DMA\n");
+
+ as->dma.chan_rx = dma_request_slave_channel_compat(mask, filter,
+ >dma,
+ dev, "rx");
+
+ if (!as->dma.chan_rx) {
+ dev_err(dev,
+ "DMA RX channel not available, SPI unable to use
DMA\n");
err = -EBUSY;
goto error;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [DISCUSSION] removing variety rq->cpu_load ?
On 06/04/2013 10:33 AM, Michael Wang wrote:
> Hi, Alex
>
> On 06/04/2013 09:51 AM, Alex Shi wrote:
>> resend with a new subject.
>
> Forgive me but I'm a little lost on this thread...
>
> So we are planing to rely on instant 'cpu_load[0]' and decayed
> 'runnable_load_avg' only, do we?
cpu_load is a kind of time decay for cpu load, but after runnable load
introduced,
the decay functionality is a kind duplicate with it.
So, remove them will make code simple. The idea were mentioned by Paul, Peter
and I.
the following is Peter's word of this affair.
> Agreed, esp. the plethora of weird idx things we currently have. If we need to
> re-introduce something it would likely only be the busy case and for that we
> can immediately link to the balance interval or so.
>
>
> Regards,
> Michael Wang
>
>>
>>> Peter,
>>>
>>> I just tried to remove the variety rq.cpu_load, by the following patch.
>>> Because forkexec_idx and busy_idx are all zero, after the patch system just
>>> keep cpu_load[0]
>>> and remove other values.
>>> I tried the patch base 3.10-rc3 and latest tip/sched/core with benchmark
>>> dbench,tbench,
>>> aim7,hackbench. and oltp of sysbench. Seems performance doesn't change
>>> clear.
>>> So, for my tested machines, core2, NHM, SNB, with 2 or 4 CPU sockets, and
>>> above tested
>>> benchmark. We are fine to remove the variety cpu_load.
>>> Don't know if there some other concerns on other scenarios.
>>>
>>> ---
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index 590d535..f0ca983 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -4626,7 +4626,7 @@ static inline void update_sd_lb_stats(struct lb_env
>>> *env,
>>> if (child && child->flags & SD_PREFER_SIBLING)
>>> prefer_sibling = 1;
>>>
>>> - load_idx = get_sd_load_idx(env->sd, env->idle);
>>> + load_idx = 0; //get_sd_load_idx(env->sd, env->idle);
>>>
>>> do {
>>> int local_group;
>>>
>>>
>>
>>
>
--
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the net tree
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
net/mac80211/iface.c between commit ac20976dcaee ("mac80211: Allow single
vif mac address change with addr_mask") from the net tree and commit
31eba5bc56a9 ("mac80211: support active monitor interfaces") from the
wireless-next tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/mac80211/iface.c
index 7c3ba86,7cabaf2..000
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@@ -159,10 -159,10 +159,11 @@@ static int ieee80211_change_mtu(struct
return 0;
}
- static int ieee80211_verify_mac(struct ieee80211_sub_if_data *sdata, u8 *addr)
-static int ieee80211_verify_mac(struct ieee80211_local *local, u8 *addr,
++static int ieee80211_verify_mac(struct ieee80211_sub_if_data *sdata, u8 *addr,
+ bool check_dup)
{
- struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_sub_if_data *iter;
u64 new, mask, tmp;
u8 *m;
int ret = 0;
@@@ -180,16 -180,16 +181,19 @@@
((u64)m[2] << 3*8) | ((u64)m[3] << 2*8) |
((u64)m[4] << 1*8) | ((u64)m[5] << 0*8);
+ if (!check_dup)
+ return ret;
mutex_lock(>iflist_mtx);
- list_for_each_entry(sdata, >interfaces, list) {
- if (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
- !(sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE))
+ list_for_each_entry(iter, >interfaces, list) {
+ if (iter == sdata)
continue;
- if (iter->vif.type == NL80211_IFTYPE_MONITOR)
- m = sdata->vif.addr;
++ if (iter->vif.type == NL80211_IFTYPE_MONITOR &&
++ !(iter->u.mntr_flags & MONITOR_FLAG_ACTIVE))
+ continue;
+
+ m = iter->vif.addr;
tmp = ((u64)m[0] << 5*8) | ((u64)m[1] << 4*8) |
((u64)m[2] << 3*8) | ((u64)m[3] << 2*8) |
((u64)m[4] << 1*8) | ((u64)m[5] << 0*8);
@@@ -213,7 -214,11 +218,11 @@@ static int ieee80211_change_mac(struct
if (ieee80211_sdata_running(sdata))
return -EBUSY;
- ret = ieee80211_verify_mac(sdata, sa->sa_data);
+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
+ !(sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE))
+ check_dup = false;
+
- ret = ieee80211_verify_mac(sdata->local, sa->sa_data, check_dup);
++ ret = ieee80211_verify_mac(sdata, sa->sa_data, check_dup);
if (ret)
return ret;
pgpwMkN4Nm93s.pgp
Description: PGP signature
linux-next: manual merge of the wireless-next tree with the net-next tree
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/ath/ath9k/debug.c between commit 27d7f47756f4 ("net:
wireless: replace strict_strtoul() with kstrtoul()") from the net-next
tree and commit 6e4d291eec82 ("ath9k: Print ANI statistics in debugfs")
from the wireless-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/wireless/ath/ath9k/debug.c
index 51cc0fa,7852f6e..000
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@@ -200,12 -244,15 +244,15 @@@ static ssize_t write_file_ani(struct fi
return -EFAULT;
buf[len] = '\0';
- if (kstrtoul(buf, 0, _ani))
- if (strict_strtoul(buf, 0, ))
++ if (kstrtoul(buf, 0, ))
return -EINVAL;
- common->disable_ani = !!disable_ani;
+ if (ani < 0 || ani > 1)
+ return -EINVAL;
+
+ common->disable_ani = !ani;
- if (disable_ani) {
+ if (common->disable_ani) {
clear_bit(SC_OP_ANI_RUN, >sc_flags);
ath_stop_ani(sc);
} else {
pgpvHHWRlhGdN.pgp
Description: PGP signature
Re: [DISCUSSION] removing variety rq->cpu_load ?
Hi, Alex
On 06/04/2013 09:51 AM, Alex Shi wrote:
> resend with a new subject.
Forgive me but I'm a little lost on this thread...
So we are planing to rely on instant 'cpu_load[0]' and decayed
'runnable_load_avg' only, do we?
Regards,
Michael Wang
>
>> Peter,
>>
>> I just tried to remove the variety rq.cpu_load, by the following patch.
>> Because forkexec_idx and busy_idx are all zero, after the patch system just
>> keep cpu_load[0]
>> and remove other values.
>> I tried the patch base 3.10-rc3 and latest tip/sched/core with benchmark
>> dbench,tbench,
>> aim7,hackbench. and oltp of sysbench. Seems performance doesn't change clear.
>> So, for my tested machines, core2, NHM, SNB, with 2 or 4 CPU sockets, and
>> above tested
>> benchmark. We are fine to remove the variety cpu_load.
>> Don't know if there some other concerns on other scenarios.
>>
>> ---
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 590d535..f0ca983 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -4626,7 +4626,7 @@ static inline void update_sd_lb_stats(struct lb_env
>> *env,
>> if (child && child->flags & SD_PREFER_SIBLING)
>> prefer_sibling = 1;
>>
>> - load_idx = get_sd_load_idx(env->sd, env->idle);
>> + load_idx = 0; //get_sd_load_idx(env->sd, env->idle);
>>
>> do {
>> int local_group;
>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/5] Enable f2fs support inline data
Hi, This feature is one of my todo items. ;) Thank you for the contribution. Before reviewing the below code intensively, we need to check the following issues. - deadlock conditions - FS consistency - recovery routine Could you check one more time? Thanks again, 2013-06-03 (월), 18:04 +0800, Huajun Li: > f2fs inode is so large, small files can be stored directly in the inode, > rather than just storing a single block address and storing the data > elsewhere. > > This RFC patch set is just to enable f2fs support inline data: files less than > about 3.6K can be stored directly in inode block. > > TODO: make small dirs inline too. > > > Haicheng Li (3): > f2fs: Add helper functions and flag to support inline data > f2fs: Add interface for inline data support > f2fs: add tracepoints to debug inline data operations > > Huajun Li (2): > f2fs: Handle inline data read and write > f2fs: Key functions to handle inline data > > fs/f2fs/Kconfig | 10 +++ > fs/f2fs/Makefile|1 + > fs/f2fs/data.c | 78 +- > fs/f2fs/f2fs.h | 70 +++ > fs/f2fs/file.c |9 ++- > fs/f2fs/inline.c| 156 > +++ > fs/f2fs/inode.c |8 +++ > include/linux/f2fs_fs.h |5 ++ > include/trace/events/f2fs.h | 69 +++ > 9 files changed, 402 insertions(+), 4 deletions(-) > create mode 100644 fs/f2fs/inline.c > -- Jaegeuk Kim Samsung signature.asc Description: This is a digitally signed message part
[PATCH 3.9-stable] jfs: Several bugs in jfs_freeze() and jfs_unfreeze()
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Vahram Martirosyan "
commit e9b376671910d105c5e61103111b96209c729529 upstream
The mentioned functions do not pay attention to the error codes returned
by the functions updateSuper(), lmLogInit() and lmLogShutdown(). It brings
to system crash later when writing to log.
The patch adds corresponding code to check and return the error codes
and to print correct error messages in case of errors.
Found by Linux File System Verification project (linuxtesting.org).
Signed-off-by: Vahram Martirosyan
Reviewed-by: Gu Zheng
Signed-off-by: Dave Kleikamp
Signed-off-by: Jonghwan Choi
---
fs/jfs/super.c | 38 ++
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index 1a543be..2502d39 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
@@ -611,11 +611,28 @@ static int jfs_freeze(struct super_block *sb)
{
struct jfs_sb_info *sbi = JFS_SBI(sb);
struct jfs_log *log = sbi->log;
+ int rc = 0;
if (!(sb->s_flags & MS_RDONLY)) {
txQuiesce(sb);
- lmLogShutdown(log);
- updateSuper(sb, FM_CLEAN);
+ rc = lmLogShutdown(log);
+ if (rc) {
+ jfs_error(sb, "jfs_freeze: lmLogShutdown failed");
+
+ /* let operations fail rather than hang */
+ txResume(sb);
+
+ return rc;
+ }
+ rc = updateSuper(sb, FM_CLEAN);
+ if (rc) {
+ jfs_err("jfs_freeze: updateSuper failed\n");
+ /*
+* Don't fail here. Everything succeeded except
+* marking the superblock clean, so there's really
+* no harm in leaving it frozen for now.
+*/
+ }
}
return 0;
}
@@ -627,13 +644,18 @@ static int jfs_unfreeze(struct super_block *sb)
int rc = 0;
if (!(sb->s_flags & MS_RDONLY)) {
- updateSuper(sb, FM_MOUNT);
- if ((rc = lmLogInit(log)))
- jfs_err("jfs_unlock failed with return code %d",
rc);
- else
- txResume(sb);
+ rc = updateSuper(sb, FM_MOUNT);
+ if (rc) {
+ jfs_error(sb, "jfs_unfreeze: updateSuper failed");
+ goto out;
+ }
+ rc = lmLogInit(log);
+ if (rc)
+ jfs_error(sb, "jfs_unfreeze: lmLogInit failed");
+out:
+ txResume(sb);
}
- return 0;
+ return rc;
}
static struct dentry *jfs_do_mount(struct file_system_type *fs_type,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the pci tree with Linus' tree
On Mon, Jun 3, 2013 at 7:49 PM, Stephen Rothwell wrote:
> Hi Bjorn,
>
> Today's linux-next merge of the pci tree got a conflict in
> drivers/acpi/pci_root.c between commit 3f327e39b4b8 ("PCI: acpiphp:
> Re-enumerate devices when host bridge receives Bus Check") from Linus'
> tree and commit 6dc7d22c6738 ("PCI/ACPI: Use dev_printk(),
> acpi_handle_print(), pr_xxx() when possible") from the pci tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks perfect, thanks!
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/acpi/pci_root.c
> index e427dc5,122b4dc..000
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@@ -639,11 -620,9 +620,11 @@@ static void _handle_hotplug_event_root(
> switch (type) {
> case ACPI_NOTIFY_BUS_CHECK:
> /* bus enumerate */
> - printk(KERN_DEBUG "%s: Bus check notify on %s\n", __func__,
> -(char *)buffer.pointer);
> + acpi_handle_printk(KERN_DEBUG, handle,
> + "Bus check notify on %s\n", __func__);
> - if (!root)
> + if (root)
> + acpiphp_check_host_bridge(handle);
> + else
> handle_root_bridge_insertion(handle);
>
> 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/
Re: [RFC] perf record: Remove -A option
2013-06-04 오전 3:06, Jiri Olsa 쓴 글: hi, the -A option (append data to the output file) for record command is broken, probably for some time now. Anyone interested in this functionality? As we discussed this with Arnaldo he and I would vote for removal. +1 for removal. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firmware loader: fix build failure with !CONFIG_FW_LOADER_USER_HELPER
This patch fixes one build failure which is introduced by the patch
below:
driver core: firmware loader: kill FW_ACTION_NOHOTPLUG requests
before suspend
When CONFIG_FW_LOADER_USER_HELPER is unset, kill_requests_without_uevent()
should be nop because no userspace loading is involved.
Reported-by: kbuild test robot
Signed-off-by: Ming Lei
---
drivers/base/firmware_class.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index c415043..c31fc29 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -916,6 +916,21 @@ static int fw_load_from_user_helper(struct firmware
*firmware,
fw_priv->buf = firmware->priv;
return _request_firmware_load(fw_priv, uevent, timeout);
}
+
+/* kill pending requests without uevent to avoid blocking suspend */
+static void kill_requests_without_uevent(void)
+{
+ struct firmware_buf *buf;
+ struct firmware_buf *next;
+
+ mutex_lock(_lock);
+ list_for_each_entry_safe(buf, next, _fw_head, pending_list) {
+ if (!buf->need_uevent)
+fw_load_abort(buf);
+ }
+ mutex_unlock(_lock);
+}
+
#else /* CONFIG_FW_LOADER_USER_HELPER */
static inline int
fw_load_from_user_helper(struct firmware *firmware, const char *name,
@@ -928,6 +943,8 @@ fw_load_from_user_helper(struct firmware *firmware, const
char *name,
/* No abort during direct loading */
#define is_fw_load_aborted(buf) false
+static inline void kill_requests_without_uevent(void) { }
+
#endif /* CONFIG_FW_LOADER_USER_HELPER */
@@ -1414,20 +1431,6 @@ static void __device_uncache_fw_images(void)
spin_unlock(>name_lock);
}
-/* kill pending requests without uevent to avoid blocking suspend */
-static void kill_requests_without_uevent(void)
-{
- struct firmware_buf *buf;
- struct firmware_buf *next;
-
- mutex_lock(_lock);
- list_for_each_entry_safe(buf, next, _fw_head, pending_list) {
- if (!buf->need_uevent)
-fw_load_abort(buf);
- }
- mutex_unlock(_lock);
-}
-
/**
* device_cache_fw_images - cache devices' firmware
*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DISCUSSION] removing variety rq->cpu_load ?
resend with a new subject.
> Peter,
>
> I just tried to remove the variety rq.cpu_load, by the following patch.
> Because forkexec_idx and busy_idx are all zero, after the patch system just
> keep cpu_load[0]
> and remove other values.
> I tried the patch base 3.10-rc3 and latest tip/sched/core with benchmark
> dbench,tbench,
> aim7,hackbench. and oltp of sysbench. Seems performance doesn't change clear.
> So, for my tested machines, core2, NHM, SNB, with 2 or 4 CPU sockets, and
> above tested
> benchmark. We are fine to remove the variety cpu_load.
> Don't know if there some other concerns on other scenarios.
>
> ---
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 590d535..f0ca983 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4626,7 +4626,7 @@ static inline void update_sd_lb_stats(struct lb_env
> *env,
> if (child && child->flags & SD_PREFER_SIBLING)
> prefer_sibling = 1;
>
> - load_idx = get_sd_load_idx(env->sd, env->idle);
> + load_idx = 0; //get_sd_load_idx(env->sd, env->idle);
>
> do {
> int local_group;
>
>
--
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2 4/6] sched_clock: Add support for >32 bit sched_clock
On 06/03/13 15:12, Russell King - ARM Linux wrote:
> On Mon, Jun 03, 2013 at 02:11:59PM -0700, Stephen Boyd wrote:
>> On 06/03/13 02:39, Russell King - ARM Linux wrote:
>>> On Sat, Jun 01, 2013 at 11:39:41PM -0700, Stephen Boyd wrote:
+}
+
+void __init
+setup_sched_clock_64(u64 (*read)(void), int bits, unsigned long rate)
+{
+ if (cd.rate > rate)
+ return;
+
+ BUG_ON(bits <= 32);
+ WARN_ON(!irqs_disabled());
+ read_sched_clock_64 = read;
+ sched_clock_func = sched_clock_64;
+ cd.rate = rate;
+ cd.mult = NSEC_PER_SEC / rate;
>>> Here, you don't check that the (2^bits) * mult results in a wrap of the
>>> resulting 64-bit number, which is a _basic_ requirement for sched_clock
>>> (hence all the code for <=32bit clocks, otherwise we wouldn't need this
>>> complexity in the first place.)
>> Ok I will use clocks_calc_mult_shift() here.
> No, that's not the problem.
>
> If you have a 56-bit clock which ticks at a period of 1ns, then
> cd.rate = 1, and your sched_clock() values will be truncated to 56-bits.
> The scheduler always _requires_ 64-bits from sched_clock. That's why we
> have the complicated code to extend the 32-bits-or-less to a _full_
> 64-bit value.
>
> Let me make this clearer: sched_clock() return values _must_ without
> exception monotonically increment from zero to 2^64-1 and then wrap
> back to zero. No other behaviour is acceptable for sched_clock().
Ok so you're saying if we have less than 64 bits of useable information
we _must_ do something to find where the wraparound will occur and
adjust for it so that epoch_ns is always incrementing until 2^64-1. Fair
enough. I was trying to avoid more work because on arm architected timer
platforms it takes many years for that to happen.
I'll see what I can do.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] perf util: Add parse_nsec_time() function
From: Namhyung Kim
The parse_nsec_time() function is for parsing a string of time into
64-bit nsec value. It's a preparation of time filtering in some of
perf commands.
Cc: David Ahern
Signed-off-by: Namhyung Kim
---
tools/perf/util/util.c | 33 +
tools/perf/util/util.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 59d868add275..205972f6addb 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -269,3 +269,36 @@ void perf_debugfs_set_path(const char *mntpt)
snprintf(debugfs_mountpoint, strlen(debugfs_mountpoint), "%s", mntpt);
set_tracing_events_path(mntpt);
}
+
+int parse_nsec_time(const char *str, u64 *ptime)
+{
+ u64 time_sec, time_nsec;
+ char *end;
+
+ time_sec = strtoul(str, , 10);
+ if (*end != '.' && *end != '\0')
+ return -1;
+
+ if (*end == '.') {
+ int i;
+ char nsec_buf[10];
+
+ if (strlen(++end) > 9)
+ return -1;
+
+ strncpy(nsec_buf, end, 9);
+ nsec_buf[9] = '\0';
+
+ /* make it nsec precision */
+ for (i = strlen(nsec_buf); i < 9; i++)
+ nsec_buf[i] = '0';
+
+ time_nsec = strtoul(nsec_buf, , 10);
+ if (*end != '\0')
+ return -1;
+ } else
+ time_nsec = 0;
+
+ *ptime = time_sec * NSEC_PER_SEC + time_nsec;
+ return 0;
+}
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 7a484c97e500..6c8baf312c8a 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -204,6 +204,8 @@ static inline int has_extension(const char *filename, const
char *ext)
#define NSEC_PER_MSEC 100L
#endif
+int parse_nsec_time(const char *str, u64 *ptime);
+
extern unsigned char sane_ctype[256];
#define GIT_SPACE 0x01
#define GIT_DIGIT 0x02
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the pci tree with Linus' tree
Hi Bjorn,
Today's linux-next merge of the pci tree got a conflict in
drivers/acpi/pci_root.c between commit 3f327e39b4b8 ("PCI: acpiphp:
Re-enumerate devices when host bridge receives Bus Check") from Linus'
tree and commit 6dc7d22c6738 ("PCI/ACPI: Use dev_printk(),
acpi_handle_print(), pr_xxx() when possible") from the pci tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/acpi/pci_root.c
index e427dc5,122b4dc..000
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@@ -639,11 -620,9 +620,11 @@@ static void _handle_hotplug_event_root(
switch (type) {
case ACPI_NOTIFY_BUS_CHECK:
/* bus enumerate */
- printk(KERN_DEBUG "%s: Bus check notify on %s\n", __func__,
-(char *)buffer.pointer);
+ acpi_handle_printk(KERN_DEBUG, handle,
+ "Bus check notify on %s\n", __func__);
- if (!root)
+ if (root)
+ acpiphp_check_host_bridge(handle);
+ else
handle_root_bridge_insertion(handle);
break;
pgpnP20XurlBq.pgp
Description: PGP signature
Re: [PATCH] sctp: set association state to established in dupcook_a handler
On 06/03/2013 10:28 PM, Greg KH wrote: On Mon, Jun 03, 2013 at 03:52:58PM +0800, Xufeng Zhang wrote: 3.4-stable review patch. If anyone has any objections, please let me know. Really? What are you going to do with it if no one objects? Sorry, I don't have any experience with stable patch and I consult stable_kernel_rules.txt, there are not much special rules and here I just want to specify the kernel version I wish it to be applied to. I know I'm sure not going to do anything with it... (hint, this isn't how you ask for networking stable patches to be applied.) Ok, thanks for your hint, I'll resend the patch. Thanks, Xufeng greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/7] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task
On 05/07/2013 02:17 PM, Alex Shi wrote:
> On 05/06/2013 07:10 PM, Peter Zijlstra wrote:
The runnable_avgs themselves actually have a fair bit of history in
them already (50% is last 32ms); but given that they don't need to be
cut-off to respond to load being migrated I'm guessing we could
actually potentially get by with just "instaneous" and "use averages"
where appropriate?
>> Sure,. worth a try. If things fall over we can always look at it again.
>>
We always end up having to re-pick/tune them based on a variety of
workloads; if we can eliminate them I think it would be a win.
>> Agreed, esp. the plethora of weird idx things we currently have. If we need
>> to
>> re-introduce something it would likely only be the busy case and for that we
>> can immediately link to the balance interval or so.
>>
>>
>>
>
> I like to have try bases on this patchset. :)
>
> First, we can remove the idx, to check if the removing is fine for our
> benchmarks, kbuild, dbench, tbench, hackbench, aim7, specjbb etc.
>
> If there are some regression. we can think more.
>
Peter,
I just tried to remove the variety rq.cpu_load, by the following patch.
Because forkexec_idx and busy_idx are all zero, after the patch system just
keep cpu_load[0]
and remove other values.
I tried the patch base 3.10-rc3 and latest tip/sched/core with benchmark
dbench,tbench,
aim7,hackbench. and oltp of sysbench. Seems performance doesn't change clear.
So, for my tested machines, core2, NHM, SNB, with 2 or 4 CPU sockets, and above
tested
benchmark. We are fine to remove the variety cpu_load.
Don't know if there some other concerns on other scenarios.
---
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 590d535..f0ca983 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4626,7 +4626,7 @@ static inline void update_sd_lb_stats(struct lb_env *env,
if (child && child->flags & SD_PREFER_SIBLING)
prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle);
+ load_idx = 0; //get_sd_load_idx(env->sd, env->idle);
do {
int local_group;
--
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86/xen: sync the wallclock when the system time changes
On Wed, May 29, 2013 at 10:42:04AM +0100, David Vrabel wrote: > On 28/05/13 19:53, John Stultz wrote: > > On 05/28/2013 11:22 AM, David Vrabel wrote: > >> From: David Vrabel > >> > >> Currently the Xen wallclock is only updated every 11 minutes if NTP is > >> synchronized to its clock source. If a guest is started before NTP is > >> synchronized it may see an incorrect wallclock time. > >> > >> Use the pvclock_gtod notifier chain to receive a notification when the > >> system time has changed and update the wallclock to match. > >> > >> This chain is called on every timer tick and we want to avoid an extra > >> (expensive) hypercall on every tick. Because dom0 has historically > >> never provided a very accurate wallclock and guests do not expect one, > >> we can do this simply. The wallclock is only updated if the > >> difference between now and the last update is more than 0.5 s. > [...] > >> index 4656165..81027b5 100644 > >> --- a/arch/x86/xen/time.c > >> +++ b/arch/x86/xen/time.c > [...] > >> +struct xen_platform_op op; > >> +int ret; > >> + > >> +/* > >> + * Set the Xen wallclock from Linux system time. > >> + * > >> + * dom0 hasn't historically maintained a very accurate > >> + * wallclock so guests don't expect it. We can therefore > >> + * reduce the number of expensive hypercalls by only updating > >> + * the wallclock every 0.5 s. > >> + */ > >> + > >> +now.tv_sec = tk->xtime_sec; > >> +now.tv_nsec = tk->xtime_nsec >> tk->shift; > > > > You probably want current_kernel_time() here. > > Ah. I was looking for something like this but since the notifier chain > is called with various locks held stuff kept deadlocking. It looks like > I can use __current_kernel_time() though. > > >> + > >> +if (timespec_compare(, ) > 0 > >> +&& timespec_compare(, ) < 0) > >> +return 0; > >> + > >> op.cmd = XENPF_settime; > >> -op.u.settime.secs = now->tv_sec; > >> -op.u.settime.nsecs = now->tv_nsec; > >> +op.u.settime.secs = now.tv_sec; > >> +op.u.settime.nsecs = now.tv_nsec; > >> op.u.settime.system_time = xen_clocksource_read(); > >> ret = HYPERVISOR_dom0_op(); > >> if (ret) > >> -return ret; > >> +return 0; > >> -/* Set the hardware RTC. */ > >> -return mach_set_rtc_mmss(now); > >> +last = now; > >> +next = timespec_add(now, ns_to_timespec(NSEC_PER_SEC / 2)); > >> > > > > Am I missing the xen_set_wallclock hook here? Your previous patch wanted > > to call the dom0 op and then set the hardware RTC. > > As Jan says, this is deliberate. We now update the hardware CMOS RTC in > the same way as bare metal and then use this notifier to only maintain > the Xen wallclock for guests. > > > And this notifier get called every timer tick? This seems out there... > > This notifier was added to support similar functionality for KVM and I'm > just reusing what's there. > > See e0b306fef (time: export time information for KVM pvclock) [1] and > 16e8d74d2 (KVM: x86: notifier for clocksource changes) [2]. > > Perhaps Marcelo can comment on why it was necessary for this to be > called on every timer tick. Just so to maintain similarity with the vsyscall notifier (as in updates all fields the vsyscall notifier uses). KVM only actually makes use of the clocksource change case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [v5][PATCH 5/6] mm: vmscan: batch shrink_page_list() locking operations
On Tue, Jun 4, 2013 at 4:02 AM, Dave Hansen wrote:
> +/*
> + * pages come in here (via remove_list) locked and leave unlocked
> + * (on either ret_pages or free_pages)
> + *
> + * We do this batching so that we free batches of pages with a
> + * single mapping->tree_lock acquisition/release. This optimization
> + * only makes sense when the pages on remove_list all share a
> + * page_mapping(). If this is violated you will BUG_ON().
> + */
> +static int __remove_mapping_batch(struct list_head *remove_list,
> + struct list_head *ret_pages,
> + struct list_head *free_pages)
> +{
> + int nr_reclaimed = 0;
> + struct address_space *mapping;
> + struct page *page;
> + LIST_HEAD(need_free_mapping);
> +
> + if (list_empty(remove_list))
> + return 0;
> +
> + mapping = page_mapping(lru_to_page(remove_list));
> + spin_lock_irq(>tree_lock);
> + while (!list_empty(remove_list)) {
> + page = lru_to_page(remove_list);
> + BUG_ON(!PageLocked(page));
> + BUG_ON(page_mapping(page) != mapping);
> + list_del(>lru);
> +
> + if (!__remove_mapping(mapping, page)) {
> + unlock_page(page);
> + list_add(>lru, ret_pages);
> + continue;
> + }
> + list_add(>lru, _free_mapping);
> + }
> + spin_unlock_irq(>tree_lock);
> +
While reclaiming pages, can we open ears upon IRQ controller,
if the page list length is over 10, or even 20?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch -v4 4/8] memcg: enhance memcg iterator to support predicates
On Mon, Jun 03, 2013 at 12:18:51PM +0200, Michal Hocko wrote: > The caller of the iterator might know that some nodes or even subtrees > should be skipped but there is no way to tell iterators about that so > the only choice left is to let iterators to visit each node and do the > selection outside of the iterating code. This, however, doesn't scale > well with hierarchies with many groups where only few groups are > interesting. > > This patch adds mem_cgroup_iter_cond variant of the iterator with a > callback which gets called for every visited node. There are three > possible ways how the callback can influence the walk. Either the node > is visited, it is skipped but the tree walk continues down the tree or > the whole subtree of the current group is skipped. > > TODO is it correct to reclaim + cond together? What if the cache simply > skips interesting nodes which another predicate would find interesting? I don't know. Maybe it's just taste but it looks pretty ugly to me. Why does everything have to be folded into the iteration function? The iteration only depends on the current position. Can't you factor out skipping part outside the function rather than rolling into this monstery thing with predicate callback? Just test the condition outside and call a function to skip whatever is necessary? Also, cgroup_rightmost_descendant() can be pretty expensive depending on how your tree looks like. It travels to the rightmost child at each level until it can't. In extreme cases, you can travel the whole subtree. This usually isn't a problem for its usecases but yours may be different, I'm not sure. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] SELinux: cache inode checks inside struct inode
On 6/3/2013 1:26 PM, Casey Schaufler wrote:
> On 6/3/2013 11:59 AM, Eric Paris wrote:
>> This patch adds a cache of selinux security checks into struct inode.
> This violates the security blob architecture of the LSM.
>
> Security module specific optimizations in the VFS layer are
> probably going to be pointless if (when) we go to stackable
> security modules. I have based all of the work I've been
> doing on stacking modules on the blob pointer architecture.
> Building special case code into the stacking infrastructure
> to accommodate this optimization, which will apply only if
> SELinux is being used and no other inode blob using LSM is
> in use, will be possible, but heinous.
After further review it turns out that this patch set won't
affect the stacking after all, because the work is still getting
done in the SELinux code. So put me down as having philosophical
objections, but not substantive ones.
>
> We (the LSM community) agreed to the blob pointer architecture
> for a number of reasons, one of which was that it keeps all of
> the details of the implementation hidden from the VFS. Pulling
> SELinux specific code into the VFS violates that dramatically.
>
> I understand that Linus has chimed in on this issue and has
> spoken well of the potential performance improvement. I suggest
> that if we have a module independent "cache" we (for values of
> "we" that include modules other than SELinux) will be better off.
> *I understand that today only SELinux and Smack use i_security.*
> I do not expect that to continue into the future.
>
>
>> It is protected by the seq counter against updates by other nodes. This
>> has a measurable impact on one benchmark Linus mentioned. The cpu
>> time using make to check a huge project for changes. It is going to
>> have a negative impact on cases where tasks with different labels are
>> accessing the same object. In these cases each one will grab the i_lock
>> to reset the in inode cache. The only place I imagine this would be
>> common would be with shared libraries. But as those are typically
>> openned and mmapped, they don't have continuous checks...
>>
>> Stock Kernel:
>> 8.23% make [k] __d_lookup_rcu
>> 6.27% make [k] link_path_walk
>> 3.91% make [k] selinux_inode_permission <
>> 3.37% make [k] avc_has_perm_noaudit <
>> 2.26% make [k] lookup_fast
>> 2.12% make [k] system_call
>> 1.86% make [k] path_lookupat
>> 1.82% make [k] inode_has_perm.isra.32.constprop.61 <
>> 1.57% make [k] copy_user_enhanced_fast_string
>> 1.48% make [k] generic_permission
>> 1.34% make [k] __audit_syscall_exit
>> 1.31% make [k] kmem_cache_free
>> 1.24% make [k] kmem_cache_alloc
>> 1.20% make [k] generic_fillattr
>> 1.12% make [k] __inode_permission
>> 1.06% make [k] dput
>> 1.04% make [k] strncpy_from_user
>> 1.04% make [k] _raw_spin_lock
>> Total: 3.91 + 3.37 + 1.82 = 9.1%
>>
>> My Changes:
>> 8.54% make [k] __d_lookup_rcu
>> 6.52% make [k] link_path_walk
>> 3.93% make [k] inode_has_perm <
>> 2.31% make [k] lookup_fast
>> 2.05% make [k] system_call
>> 1.79% make [k] path_lookupat
>> 1.72% make [k] generic_permission
>> 1.50% make [k] __audit_syscall_exit
>> 1.49% make [k] selinux_inode_permission <
>> 1.47% make [k] copy_user_enhanced_fast_string
>> 1.28% make [k] __inode_permission
>> 1.23% make [k] kmem_cache_alloc
>> 1.19% make [k] _raw_spin_lock
>> 1.15% make [k] lg_local_lock
>> 1.10% make [k] strncpy_from_user
>> 1.10% make [k] dput
>> 1.08% make [k] kmem_cache_free
>> 1.08% make [k] generic_fillattr
>> Total: 3.93 + 1.49 = 5.42
>>
>> In inode_has_perm the big time takers are loading cred->sid and the
>> raw_seqcount_begin(inode->i_security_seccount). I'm not certain how to
>> make either of those much faster.
>>
>> In selinux_inode_permission() we spend time in getting current->cred and
>> in calling inode_has_perm().
>>
>> Signed-off-by: Eric Paris
>> ---
>> include/linux/fs.h | 5 +++
>> security/selinux/hooks.c| 62
>> ++---
>> security/selinux/include/security.h | 1 +
>> security/selinux/ss/services.c | 5 +++
>> 4 files changed, 69 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 43db02e..5268cf3 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -535,6 +535,11 @@ struct inode {
>> struct address_space*i_mapping;
>>
>> #ifdef CONFIG_SECURITY
> Shouldn't these be under #ifdef SELINUX?
> They're pointless without SELinux.
>
>> +seqcount_t i_security_seqcount;
>> +u32 i_last_task_sid;
>> +u32 i_last_granting;
>> +u32 i_last_perms;
>> +u32 i_audit_allow;
>> void
Re: [PATCH v2 4/4] proc: avoid ->f_pos overflows in proc_task_readdir() paths
On Mon, Jun 03, 2013 at 09:07:05PM +0200, Oleg Nesterov wrote: > 1. proc_task_readdir() truncates f_pos to long, this can lead >to wrong result on 32bit. > > 2. first_tid() truncates f_pos to int, this is wrong even on >64bit. > >We could check that f_pos < PID_MAX or even INT_MAX in >proc_task_readdir(), but this patch simply checks the >potential overflow in first_tid(), this check is nop on >64bit. We do not care if it was negative and the new >unsigned value is huge, all we need to ensure is that we >never wrongly return !NULL. > > 3. Remove the 2nd "nr != 0" check before get_nr_threads(), >nr_threads == 0 is not distinguishable from !pid_task() >above. Oleg, please take a look at the series in vfs.git#experimental; at the very least, we don't want to access file->f_pos in any foo_readdir() - it's too messy and race-prone. It's pretty much independent from the issues you are dealing with, but let's avoid creating pointless conflicts... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PVH: vcpu info placement, load selectors, and remove debug printk.
This patch addresses 3 things:
- Resolve vcpu info placement fixme.
- Load DS/SS/CS selectors for PVH after switching to new gdt.
- Remove printk in case of failure to map pnfs in p2m. This because qemu
has lot of benign failures when mapping HVM pages.
Signed-off-by: Mukesh Rathor
---
arch/x86/xen/enlighten.c | 22 ++
arch/x86/xen/mmu.c |3 ---
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index a7ee39f..6ff30d8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1083,14 +1083,12 @@ void xen_setup_shared_info(void)
HYPERVISOR_shared_info =
(struct shared_info *)__va(xen_start_info->shared_info);
- /* PVH TBD/FIXME: vcpu info placement in phase 2 */
- if (xen_pvh_domain())
- return;
-
#ifndef CONFIG_SMP
/* In UP this is as good a place as any to set up shared info */
xen_setup_vcpu_info_placement();
#endif
+ if (xen_pvh_domain())
+ return;
xen_setup_mfn_list_list();
}
@@ -1103,6 +1101,10 @@ void xen_setup_vcpu_info_placement(void)
for_each_possible_cpu(cpu)
xen_vcpu_setup(cpu);
+ /* PVH always uses native IRQ ops */
+ if (xen_pvh_domain())
+ return;
+
/* xen_vcpu_setup managed to place the vcpu_info within the
percpu area for all cpus, so make use of it */
if (have_vcpu_info_placement) {
@@ -1327,6 +1329,18 @@ static void __init xen_setup_stackprotector(void)
/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
if (xen_feature(XENFEAT_auto_translated_physmap)) {
switch_to_new_gdt(0);
+
+ /* xen started us with null selectors. load them now */
+ __asm__ __volatile__ (
+ "movl %0,%%ds\n"
+ "movl %0,%%ss\n"
+ "pushq %%rax\n"
+ "leaq 1f(%%rip),%%rax\n"
+ "pushq %%rax\n"
+ "retfq\n"
+ "1:\n"
+ : : "r" (__KERNEL_DS), "a" (__KERNEL_CS) : "memory");
+
return;
}
pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 31cc1ef..c104895 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2527,9 +2527,6 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn,
unsigned long fgmfn,
set_xen_guest_handle(xatp.errs, );
rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
- if (rc || err)
- pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx)
rc:%d:%d\n",
- lpfn, fgmfn, rc, err);
return rc;
}
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/5] Drivers: scsi: storvsc: Make the scsi timeout a module parameter
> -Original Message- > From: James Bottomley [mailto:jbottom...@parallels.com] > Sent: Monday, June 03, 2013 7:47 PM > To: KY Srinivasan > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; oher...@suse.com; h...@infradead.org; linux- > s...@vger.kernel.org > Subject: Re: [PATCH 1/5] Drivers: scsi: storvsc: Make the scsi timeout a > module > parameter > > On Mon, 2013-06-03 at 23:25 +, KY Srinivasan wrote: > > > > > -Original Message- > > > From: James Bottomley [mailto:jbottom...@parallels.com] > > > Sent: Monday, June 03, 2013 7:03 PM > > > To: KY Srinivasan > > > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > > de...@linuxdriverproject.org; oher...@suse.com; h...@infradead.org; linux- > > > s...@vger.kernel.org > > > Subject: Re: [PATCH 1/5] Drivers: scsi: storvsc: Make the scsi timeout a > module > > > parameter > > > > > > On Mon, 2013-06-03 at 16:21 -0700, K. Y. Srinivasan wrote: > > > > The standard scsi timeout is not appropriate in some of the environments > > > where > > > > Hyper-V is deployed. Set this timeout appropriately for all devices > > > > managed > > > > by this driver. Further make this a module parameter. > > > > > > > > Signed-off-by: K. Y. Srinivasan > > > > Reviewed-by: Haiyang Zhang > > > > --- > > > > drivers/scsi/storvsc_drv.c |9 + > > > > 1 files changed, 9 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c > > > > index 16a3a0c..8d29a95 100644 > > > > --- a/drivers/scsi/storvsc_drv.c > > > > +++ b/drivers/scsi/storvsc_drv.c > > > > @@ -221,6 +221,13 @@ static int storvsc_ringbuffer_size = (20 * > PAGE_SIZE); > > > > module_param(storvsc_ringbuffer_size, int, S_IRUGO); > > > > MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)"); > > > > > > > > +/* > > > > + * Timeout in seconds for all devices managed by this driver. > > > > + */ > > > > +static int storvsc_timeout = 180; > > > > +module_param(storvsc_timeout, uint, (S_IRUGO | S_IWUSR)); > > > > +MODULE_PARM_DESC(storvsc_timeout, "Device timeout (seconds)"); > > > > + > > > > #define STORVSC_MAX_IO_REQUESTS128 > > > > > > > > /* > > > > @@ -1204,6 +1211,8 @@ static int storvsc_device_configure(struct > scsi_device > > > *sdevice) > > > > > > > > blk_queue_bounce_limit(sdevice->request_queue, BLK_BOUNCE_ANY); > > > > > > > > + blk_queue_rq_timeout(sdevice->request_queue, (storvsc_timeout * > > > HZ)); > > > > > > Why does this need to be a module parameter? It's already a sysfs one > > > in the scsi_device class? Three minutes is also a bit large. The > > > default is 30s with huge cache arrays recommending upping this to > > > 60s ... you're three times this. > > > > James, > > This number was arrived at based on some testing that was done on the > > cloud. On our cloud, we have a 120 second > > timeouts that trigger broader VM level recovery and in cases where > > there is storage access issues > > (which is when we would hit this timeout), it will be better to defer > > to the fabric level recovery than attempt > > Scsi level recovery/retry. The default value chosen for devices > > managed by storvsc should be just fine, > > So are you sure you want to set the command timeout to 3 minutes? ... > it's an incredibly high value. The actual complete timeout is this > value multiplied by the number of retries, which is 5 for disk devices, > so you'll be waiting up to 15 minutes before we signal a failure in some > circumstances. It sounds like you want the actual path length of error > recovery to be on average 3 minutes. > > The value of the timeout should be a compromise between the longest time > you want the user to wait for a failure and the longest time a device > should take to respond. This should be fine. Note that all error recovery/retry is happening on the host side and beyond a certain delay, we will do a VM level recovery at the fabric level. On a slightly different note, we have the same issue with the SCSI FLUSH timeout. Would you consider changing this. > > > I made it a module parameter to have more flexibility. > > It's *already* a sysfs parameter ... why do you want an additional > module parameter? Multiple parameters for the same quantity, especially > ones which can't be altered at runtime like module parameters, end up > confusing users. Agreed. I can send you a patch that would remove this parameter. Or, if you prefer I could resend this set with the change to this patch (removing the module parameter). Regards, K. Y > > James > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] Add SMP support for MSM8660 and MSM8960
This series re-organizes the platsmp.c and adds SMP support for MSM8660 and MSM8960. We convert to using the cpus property in device tree and add a "enable-method" property for arm32. Rohit Vaswani (3): msm: platsmp: Consolidate write to pen_release ARM: msm: Re-organize platsmp to make it extensible ARM: msm: Add SMP support for 8960 Documentation/devicetree/bindings/arm/cpus.txt |8 + Documentation/devicetree/bindings/arm/msm/kpss.txt | 16 ++ Documentation/devicetree/bindings/arm/msm/scss.txt | 15 ++ arch/arm/boot/dts/msm8660-surf.dts | 21 +++ arch/arm/boot/dts/msm8960-cdp.dts | 22 +++ arch/arm/mach-msm/platsmp.c| 165 --- arch/arm/mach-msm/scm-boot.h |8 +- 7 files changed, 226 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/msm/kpss.txt create mode 100644 Documentation/devicetree/bindings/arm/msm/scss.txt -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] ARM: msm: Add SMP support for 8960
Add the cpus bindings and the Krait release sequence
to make SMP work for MSM8960
Signed-off-by: Rohit Vaswani
---
Documentation/devicetree/bindings/arm/cpus.txt |2 +
Documentation/devicetree/bindings/arm/msm/kpss.txt | 16 ++
arch/arm/boot/dts/msm8960-cdp.dts | 22
arch/arm/mach-msm/platsmp.c| 57
arch/arm/mach-msm/scm-boot.h |8 ++-
5 files changed, 102 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/msm/kpss.txt
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 327aad2..1132eac 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -45,11 +45,13 @@ For the ARM architecture every CPU node must contain the
following properties:
"marvell,xsc3"
"marvell,xscale"
"qcom,scorpion"
+ "qcom,krait"
- enable-method: Specifies the method used to enable or take the secondary
cores
out of reset. This allows different reset sequence for
different types of cpus.
This should be one of:
"qcom,scss"
+"qcom,kpssv1"
Example:
diff --git a/Documentation/devicetree/bindings/arm/msm/kpss.txt
b/Documentation/devicetree/bindings/arm/msm/kpss.txt
new file mode 100644
index 000..7272340
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/kpss.txt
@@ -0,0 +1,16 @@
+* KPSS - Krait Processor Sub-system
+
+Properties
+
+- compatible : Should contain "qcom,kpss".
+
+- reg: Specifies the base address for the KPSS registers used for
+ booting up secondary cores.
+
+Example:
+
+ kpss@2088000 {
+ compatible = "qcom,kpss";
+ reg = <0x02088000 0x1000
+ 0x02098000 0x2000>;
+ };
diff --git a/arch/arm/boot/dts/msm8960-cdp.dts
b/arch/arm/boot/dts/msm8960-cdp.dts
index 2e4d87a..fd2f3ec 100644
--- a/arch/arm/boot/dts/msm8960-cdp.dts
+++ b/arch/arm/boot/dts/msm8960-cdp.dts
@@ -7,6 +7,22 @@
compatible = "qcom,msm8960-cdp", "qcom,msm8960";
interrupt-parent = <>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "qcom,krait";
+ device_type = "cpu";
+ enable-method = "qcom,kpssv1";
+
+ cpu@0 {
+ reg = <0>;
+ };
+
+ cpu@1 {
+ reg = <1>;
+ };
+ };
+
intc: interrupt-controller@200 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
@@ -26,6 +42,12 @@
cpu-offset = <0x8>;
};
+ kpss@2088000 {
+ compatible = "qcom,kpss";
+ reg = <0x02088000 0x1000
+ 0x02098000 0x2000>;
+ };
+
serial@19c40 {
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
reg = <0x1644 0x1000>,
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index ccf4168..2e9e0a1 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -88,6 +88,56 @@ static int __cpuinit scorpion_release_secondary(void)
return 0;
}
+static int __cpuinit msm8960_release_secondary(unsigned int cpu)
+{
+ void __iomem *reg;
+ struct device_node *dn = NULL;
+
+ if (cpu == 0 || cpu >= num_possible_cpus())
+ return -EINVAL;
+
+ dn = of_find_compatible_node(dn, NULL, "qcom,kpss");
+ if (!dn) {
+ pr_err("%s : Missing kpss node from device tree\n", __func__);
+ return -ENXIO;
+ }
+
+ reg = of_iomap(dn, cpu);
+ if (!reg)
+ return -ENOMEM;
+
+ pr_debug("Starting secondary CPU %d\n", cpu);
+
+ /* Turn on CPU Rail */
+ writel_relaxed(0xA4, reg+0x1014);
+ mb();
+ udelay(512);
+
+ /* Krait bring-up sequence */
+ writel_relaxed(0x109, reg+0x04);
+ writel_relaxed(0x101, reg+0x04);
+ mb();
+ ndelay(300);
+
+ writel_relaxed(0x121, reg+0x04);
+ mb();
+ udelay(2);
+
+ writel_relaxed(0x120, reg+0x04);
+ mb();
+ udelay(2);
+
+ writel_relaxed(0x100, reg+0x04);
+ mb();
+ udelay(100);
+
+ writel_relaxed(0x180, reg+0x04);
+ mb();
+
+ iounmap(reg);
+ return 0;
+}
+
static DEFINE_PER_CPU(int, cold_boot_done);
static __cpuinit void boot_cold_cpu(unsigned int cpu)
@@ -110,6 +160,11 @@ static __cpuinit void boot_cold_cpu(unsigned int cpu)
scorpion_release_secondary();
per_cpu(cold_boot_done, cpu) = true;
}
+ } else if (!strcmp(enable_method, "qcom,kpssv1")) {
+ if
[PATCH 2/3] ARM: msm: Re-organize platsmp to make it extensible
This makes it easy to add SMP support for new targets.
This patch adds the 8660 cpus bindings to make SMP work.
Signed-off-by: Rohit Vaswani
---
Documentation/devicetree/bindings/arm/cpus.txt |6 ++
Documentation/devicetree/bindings/arm/msm/scss.txt | 15 +++
arch/arm/boot/dts/msm8660-surf.dts | 21 +
arch/arm/mach-msm/platsmp.c| 93 +++-
4 files changed, 114 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/msm/scss.txt
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494d..327aad2 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -44,6 +44,12 @@ For the ARM architecture every CPU node must contain the
following properties:
"marvell,mohawk"
"marvell,xsc3"
"marvell,xscale"
+ "qcom,scorpion"
+- enable-method: Specifies the method used to enable or take the secondary
cores
+out of reset. This allows different reset sequence for
+different types of cpus.
+This should be one of:
+"qcom,scss"
Example:
diff --git a/Documentation/devicetree/bindings/arm/msm/scss.txt
b/Documentation/devicetree/bindings/arm/msm/scss.txt
new file mode 100644
index 000..21c3e26
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/scss.txt
@@ -0,0 +1,15 @@
+* SCSS - Scorpion Sub-system
+
+Properties
+
+- compatible : Should contain "qcom,scss".
+
+- reg: Specifies the base address for the SCSS registers used for
+ booting up secondary cores.
+
+Example:
+
+ scss@902000 {
+ compatible = "qcom,scss";
+ reg = <0x00902000 0x2000>;
+ };
diff --git a/arch/arm/boot/dts/msm8660-surf.dts
b/arch/arm/boot/dts/msm8660-surf.dts
index 9bf49b3..0ede522 100644
--- a/arch/arm/boot/dts/msm8660-surf.dts
+++ b/arch/arm/boot/dts/msm8660-surf.dts
@@ -7,6 +7,22 @@
compatible = "qcom,msm8660-surf", "qcom,msm8660";
interrupt-parent = <>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "qcom,scorpion";
+ device_type = "cpu";
+ enable-method = "qcom,scss";
+
+ cpu@0 {
+ reg = <0>;
+ };
+
+ cpu@1 {
+ reg = <1>;
+ };
+ };
+
intc: interrupt-controller@208 {
compatible = "qcom,msm-8660-qgic";
interrupt-controller;
@@ -26,6 +42,11 @@
cpu-offset = <0x4>;
};
+ scss@902000 {
+ compatible = "qcom,scss";
+ reg = <0x00902000 0x2000>;
+ };
+
serial@19c40 {
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
reg = <0x19c4 0x1000>,
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 2028f3f..ccf4168 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -61,35 +63,64 @@ static void __cpuinit msm_secondary_init(unsigned int cpu)
spin_unlock(_lock);
}
-static __cpuinit void prepare_cold_cpu(unsigned int cpu)
+static int __cpuinit scorpion_release_secondary(void)
{
- int ret;
- ret = scm_set_boot_addr(virt_to_phys(msm_secondary_startup),
- SCM_FLAG_COLDBOOT_CPU1);
- if (ret == 0) {
- void __iomem *sc1_base_ptr;
- sc1_base_ptr = ioremap_nocache(0x00902000, SZ_4K*2);
- if (sc1_base_ptr) {
- writel(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
- writel(0, sc1_base_ptr + SCSS_CPU1CORE_RESET);
- writel(3, sc1_base_ptr + SCSS_DBG_STATUS_CORE_PWRDUP);
- iounmap(sc1_base_ptr);
+ void __iomem *sc1_base_ptr;
+ struct device_node *dn = NULL;
+
+ dn = of_find_compatible_node(dn, NULL, "qcom,scss");
+ if (!dn) {
+ pr_err("%s: Missing scss node in device tree\n", __func__);
+ return -ENXIO;
+ }
+
+ sc1_base_ptr = of_iomap(dn, 0);
+ if (sc1_base_ptr) {
+ writel_relaxed(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
+ writel_relaxed(0, sc1_base_ptr + SCSS_CPU1CORE_RESET);
+ writel_relaxed(3, sc1_base_ptr + SCSS_DBG_STATUS_CORE_PWRDUP);
+ mb();
+ iounmap(sc1_base_ptr);
+ } else {
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static DEFINE_PER_CPU(int, cold_boot_done);
+
+static __cpuinit void boot_cold_cpu(unsigned int cpu)
+{
+ const char *enable_method;
+ struct
Re: [PATCHv2 0/6] Make ARM's sched_clock generic + 64 bit friendly
On 06/01/2013 11:39 PM, Stephen Boyd wrote: This is mostly a resend of a patch series I sent a little over a month ago. I've reordered the patches so that John can pick up the first three and get a generic sched_clock layer without having to take the 64 bit patches. The last three patches add 64 bit support and move the architected timers on ARM64 and ARM to use it. Yea, so from the initial look over it, I think I'm happy with queuing the first three patches, although I'd like to get some acks from arm folks on at least the first two, just so no one is surprised with it going through the -tip tree. It looks like the arm64 bit stuff needs a few more iterations w/ Russell, so I'll not touch those. We still have a ways to go to consolidate x86 into this (need to handle pv hooks), but it should provide a base to get some of the simpler arches sharing the same infrastructure. Also I suspect we can maybe further combine this with the kernel/sched/clock.c code, but I think this is a good start for now. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] msm: platsmp: Consolidate write to pen_release
Change the pen variable in one place.
Signed-off-by: Rohit Vaswani
---
arch/arm/mach-msm/platsmp.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 00cdb0a..2028f3f 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -32,6 +32,14 @@ extern void msm_secondary_startup(void);
static DEFINE_SPINLOCK(boot_lock);
+static void __cpuinit write_pen_release(int val)
+{
+ pen_release = val;
+ smp_wmb();
+ __cpuc_flush_dcache_area((void *)_release, sizeof(pen_release));
+ outer_clean_range(__pa(_release), __pa(_release + 1));
+}
+
static inline int get_core_count(void)
{
/* 1 + the PART[1:0] field of MIDR */
@@ -44,8 +52,7 @@ static void __cpuinit msm_secondary_init(unsigned int cpu)
* let the primary processor know we're out of the
* pen, then head off into the C entry point
*/
- pen_release = -1;
- smp_wmb();
+ write_pen_release(-1);
/*
* Synchronise with the boot thread.
@@ -98,9 +105,7 @@ static int __cpuinit msm_boot_secondary(unsigned int cpu,
struct task_struct *id
* Note that "pen_release" is the hardware CPU ID, whereas
* "cpu" is Linux's internal ID.
*/
- pen_release = cpu_logical_map(cpu);
- __cpuc_flush_dcache_area((void *)_release, sizeof(pen_release));
- outer_clean_range(__pa(_release), __pa(_release + 1));
+ write_pen_release(cpu_logical_map(cpu));
/*
* Send the secondary CPU a soft interrupt, thereby causing
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v13 3/3] trace,x86: Add irq vector tracepoints
On Mon, 2013-06-03 at 15:29 -0400, Seiji Aguchi wrote:
Yeah, I believe this does work. But you probably should add a comment
like the following:
/*
* The current_idt_descr_ptr can only be set out of interrupt context
* to avoid races. Once set, the load_current_idt() is called by
interrupt
* context either by NMI, debug, or via a smp_call_function(). That way
* the IDT will always be set back to the expected descriptor.
*/
>
> +extern atomic_long_t current_idt_descr_ptr;
> +static inline void load_current_idt(void)
> +{
> + if (atomic_long_read(_idt_descr_ptr))
Also, we should probably add here:
unsigned long new_idt =
atomic_long_read(_idt_descr_ptr);
if (WARN_ON_ONCE(!validate_idt(new_idt))
return;
load_idt((const struct desc_ptr *)new_idt);
> + load_idt((const struct desc_ptr *)
> + atomic_long_read(_idt_descr_ptr));
> + else
> + load_idt((const struct desc_ptr *)_descr);
> +}
> +
Then have
bool validate_idt(unsigned long idt)
{
switch(idt) {
case (unsigned long)_idt_descr:
case (unsigned long)_descr:
return 0;
}
return -1;
}
This way we wont be opening up any easy root holes where if a process
finds a way to modify some arbitrary kernel memory, we can prevent it
from modifying the current_idt_descr_ptr and have a nice way to exploit
the IDT. Sure, one can argue that if they can modify arbitrary kernel
memory, we may already be lost, but lets not make it easier for them
than need be.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] Drivers: scsi: storvsc: Make the scsi timeout a module parameter
On Mon, 2013-06-03 at 23:25 +, KY Srinivasan wrote: > > > -Original Message- > > From: James Bottomley [mailto:jbottom...@parallels.com] > > Sent: Monday, June 03, 2013 7:03 PM > > To: KY Srinivasan > > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > de...@linuxdriverproject.org; oher...@suse.com; h...@infradead.org; linux- > > s...@vger.kernel.org > > Subject: Re: [PATCH 1/5] Drivers: scsi: storvsc: Make the scsi timeout a > > module > > parameter > > > > On Mon, 2013-06-03 at 16:21 -0700, K. Y. Srinivasan wrote: > > > The standard scsi timeout is not appropriate in some of the environments > > where > > > Hyper-V is deployed. Set this timeout appropriately for all devices > > > managed > > > by this driver. Further make this a module parameter. > > > > > > Signed-off-by: K. Y. Srinivasan > > > Reviewed-by: Haiyang Zhang > > > --- > > > drivers/scsi/storvsc_drv.c |9 + > > > 1 files changed, 9 insertions(+), 0 deletions(-) > > > > > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c > > > index 16a3a0c..8d29a95 100644 > > > --- a/drivers/scsi/storvsc_drv.c > > > +++ b/drivers/scsi/storvsc_drv.c > > > @@ -221,6 +221,13 @@ static int storvsc_ringbuffer_size = (20 * > > > PAGE_SIZE); > > > module_param(storvsc_ringbuffer_size, int, S_IRUGO); > > > MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)"); > > > > > > +/* > > > + * Timeout in seconds for all devices managed by this driver. > > > + */ > > > +static int storvsc_timeout = 180; > > > +module_param(storvsc_timeout, uint, (S_IRUGO | S_IWUSR)); > > > +MODULE_PARM_DESC(storvsc_timeout, "Device timeout (seconds)"); > > > + > > > #define STORVSC_MAX_IO_REQUESTS 128 > > > > > > /* > > > @@ -1204,6 +1211,8 @@ static int storvsc_device_configure(struct > > > scsi_device > > *sdevice) > > > > > > blk_queue_bounce_limit(sdevice->request_queue, BLK_BOUNCE_ANY); > > > > > > + blk_queue_rq_timeout(sdevice->request_queue, (storvsc_timeout * > > HZ)); > > > > Why does this need to be a module parameter? It's already a sysfs one > > in the scsi_device class? Three minutes is also a bit large. The > > default is 30s with huge cache arrays recommending upping this to > > 60s ... you're three times this. > > James, > This number was arrived at based on some testing that was done on the > cloud. On our cloud, we have a 120 second > timeouts that trigger broader VM level recovery and in cases where > there is storage access issues > (which is when we would hit this timeout), it will be better to defer > to the fabric level recovery than attempt > Scsi level recovery/retry. The default value chosen for devices > managed by storvsc should be just fine, So are you sure you want to set the command timeout to 3 minutes? ... it's an incredibly high value. The actual complete timeout is this value multiplied by the number of retries, which is 5 for disk devices, so you'll be waiting up to 15 minutes before we signal a failure in some circumstances. It sounds like you want the actual path length of error recovery to be on average 3 minutes. The value of the timeout should be a compromise between the longest time you want the user to wait for a failure and the longest time a device should take to respond. > I made it a module parameter to have more flexibility. It's *already* a sysfs parameter ... why do you want an additional module parameter? Multiple parameters for the same quantity, especially ones which can't be altered at runtime like module parameters, end up confusing users. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 5/5] f2fs: add tracepoints to debug inline data operations
On Mon, Jun 03, 2013 at 09:50:00AM -0400, Steven Rostedt wrote: > Can you convert the above to use DECLARE_EVENT_CLASS() and > DEFINE_EVENT(), as the above three are basically the same. You'll save a > few K in text by doing so. sure, thank you for the review. > > > + > > #endif /* _TRACE_F2FS_H */ > > > > /* This part must be outside protection */ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dmatest: add ability to disable pq and xor
On Fri, May 31, 2013 at 11:22:10AM +0300, Andy Shevchenko wrote: > On Fri, May 17, 2013 at 8:54 PM, Jon Mason wrote: > > dmatest would create a thread to stress XOR and PQ, if the capability is > > present in the hardware. Add the ability to disable XOR and PQ by > > disabling it if *_sources are set to zero. > > Sorry, didn't comment this earlier. > > Those threads are independent including MEMCPY stuff. > I think it's better to have one additional parameter let's say > type_of_test where you can set > 1 for MEMCPY > 2 for XOR > 4 for PQ > > Share this parameter via debugfs and use 0x07 as default value. > I doubt we need this as a module parameter. This is using the existing module parameter, so there is nothing new added. Since the testing is started immediately upon module insertion, there needs to be a way to prevent it from ever starting. Thanks, Jon > > -- > With Best Regards, > Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/5] Drivers: scsi: storvsc: Make the scsi timeout a module parameter
> -Original Message- > From: James Bottomley [mailto:jbottom...@parallels.com] > Sent: Monday, June 03, 2013 7:03 PM > To: KY Srinivasan > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; oher...@suse.com; h...@infradead.org; linux- > s...@vger.kernel.org > Subject: Re: [PATCH 1/5] Drivers: scsi: storvsc: Make the scsi timeout a > module > parameter > > On Mon, 2013-06-03 at 16:21 -0700, K. Y. Srinivasan wrote: > > The standard scsi timeout is not appropriate in some of the environments > where > > Hyper-V is deployed. Set this timeout appropriately for all devices managed > > by this driver. Further make this a module parameter. > > > > Signed-off-by: K. Y. Srinivasan > > Reviewed-by: Haiyang Zhang > > --- > > drivers/scsi/storvsc_drv.c |9 + > > 1 files changed, 9 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c > > index 16a3a0c..8d29a95 100644 > > --- a/drivers/scsi/storvsc_drv.c > > +++ b/drivers/scsi/storvsc_drv.c > > @@ -221,6 +221,13 @@ static int storvsc_ringbuffer_size = (20 * PAGE_SIZE); > > module_param(storvsc_ringbuffer_size, int, S_IRUGO); > > MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)"); > > > > +/* > > + * Timeout in seconds for all devices managed by this driver. > > + */ > > +static int storvsc_timeout = 180; > > +module_param(storvsc_timeout, uint, (S_IRUGO | S_IWUSR)); > > +MODULE_PARM_DESC(storvsc_timeout, "Device timeout (seconds)"); > > + > > #define STORVSC_MAX_IO_REQUESTS128 > > > > /* > > @@ -1204,6 +1211,8 @@ static int storvsc_device_configure(struct scsi_device > *sdevice) > > > > blk_queue_bounce_limit(sdevice->request_queue, BLK_BOUNCE_ANY); > > > > + blk_queue_rq_timeout(sdevice->request_queue, (storvsc_timeout * > HZ)); > > Why does this need to be a module parameter? It's already a sysfs one > in the scsi_device class? Three minutes is also a bit large. The > default is 30s with huge cache arrays recommending upping this to > 60s ... you're three times this. James, This number was arrived at based on some testing that was done on the cloud. On our cloud, we have a 120 second timeouts that trigger broader VM level recovery and in cases where there is storage access issues (which is when we would hit this timeout), it will be better to defer to the fabric level recovery than attempt Scsi level recovery/retry. The default value chosen for devices managed by storvsc should be just fine, I made it a module parameter to have more flexibility. Regards, K. Y > > James > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] SELinux: cache inode checks inside struct inode
On Tue, 2013-06-04 at 06:31 +0900, Linus Torvalds wrote: > > > On Mon, 3 Jun 2013, Eric Paris wrote: > > > > #ifdef CONFIG_SECURITY > > + seqcount_t i_security_seqcount; > > + u32 i_last_task_sid; > > + u32 i_last_granting; > > + u32 i_last_perms; > > + u32 i_audit_allow; > > void*i_security; > > #endif > > This is much too big. I was really hoping for "another word that the > security layer can use" or similar. Not sure how that can work :-( > Something this big would be acceptable if it would be a *generic* security > cache, and others could use it too, and would avoid ever actually calling > into any security layer at all (ie we could do the checks entirely at the > VFS layer). Then it would be fine. But for just the fact that SELinux is > too slow? No. There is nothing about it that can't be VFS-erized. The fields are: readlockless way to get the data which task was allowed which perms were allowed what generation of security policy allowed it what perms should be forced to call security hook anyway defining "perms" from a VFS PoV is hard. doing any of this with 'stacking' is hard. Then again, I'm only so so on the value of stacking. I've waffled a few times... I can do it entirely inside selinux, but we are still going to have the cache hit you were originally seeing as we dereference isec to get the info -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rtc: rtc-twl: ensure IRQ is wakeup enabled
On Fri, 31 May 2013 15:37:07 -0700 Kevin Hilman wrote:
> Currently, the RTC IRQ is never wakeup-enabled so is not capable of
> bringing the system out of suspend.
>
> On OMAP platforms, we have gotten by without this because the TWL RTC
> is on an I2C-connected chip which is capable of waking up the OMAP via
> the IO ring when the OMAP is in low-power states.
>
> However, if the OMAP suspends without hitting the low-power states
> (and the IO ring is not enabled), RTC wakeups will not work because
> the IRQ is not wakeup enabled.
>
> To fix, ensure the RTC IRQ is wakeup enabled whenever the RTC alarm is
> set.
>
> --- a/drivers/rtc/rtc-twl.c
> +++ b/drivers/rtc/rtc-twl.c
> @@ -213,12 +213,24 @@ static int mask_rtc_irq_bit(unsigned char bit)
>
> static int twl_rtc_alarm_irq_enable(struct device *dev, unsigned enabled)
> {
> + struct platform_device *pdev = to_platform_device(dev);
> + int irq = platform_get_irq(pdev, 0);
> + static bool twl_rtc_wake_enabled;
> int ret;
>
> - if (enabled)
> + if (enabled) {
> ret = set_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
> - else
> + if (device_can_wakeup(dev) && !twl_rtc_wake_enabled) {
> + enable_irq_wake(irq);
> + twl_rtc_wake_enabled = true;
> + }
> + } else {
> ret = mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
> + if (twl_rtc_wake_enabled) {
> + disable_irq_wake(irq);
> + twl_rtc_wake_enabled = false;
> + }
> + }
Why do we need this (slightly racy) logic with twl_rtc_wake_enabled?
Other drivers don't do this.
Should we test device_may_wakeup() befre running disable_irq_wake()?
Most drivers seem to do this, but it's all a bit foggy.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] percpu-refcount: Don't use silly cmpxchg()
On Mon, Jun 03, 2013 at 04:02:29PM -0700, Kent Overstreet wrote: > The cmpxcgh() was just to ensure the debug check didn't race, which was > a bit excessive. The caller is supposed to do the appropriate > synchronization, which means percpu_ref_kill() can just do a simple > store. > > Signed-off-by: Kent Overstreet Applied to percpu/for-3.11. The only concern I have left now is that we now have bitwise-and and test instead of just test in the hot path (get/put) to test whether the percpu part is alive. As x86 has single and-and-test instruction which doesn't require an output register, this only adds a single instruction but this may lead to more overhead on other architectures. The and-and-test was added because RCU free needs to have access to the percpu pointer after the pointer is killed and can be removed by adding another field to struct percpu_ref which remembers the pointer separately from the original percpu pointer, which I think is a better trade-off given that it makes the hot path lighter and adding another pointer field to struct percpu_ref isn't really gonna affect anything. Plus, it'd also make the code simpler. Anyways, it's not a big concern at this point and we can address it later. Thanks a lot, everyone! -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
