Interesting conversation or usual day without something new? I'd choose the first one. What do you think?:)

[Phylis Hutcherson]

What's new? 
I liked you and that u know how to make women happy. you know, I was studying 
psychology in college and that's why I know tons about physiognomy! So, I saw 
ur photo shots, made an analysis of them and decided that u are really cool. 
That's why I'm writing you this mail. 
Oh, some of my information. Name of mine is Phylis and I'm 23 years. I am here 
almost daily and so I wait for u to write me back! 
Please, don't let me wait!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/7 V6] workqueue: fix idle worker depletion

[Lai Jiangshan]

On Sun, Sep 9, 2012 at 3:02 AM, Tejun Heo  wrote:
> Hello, Lai.
>
> On Sun, Sep 09, 2012 at 02:34:02AM +0800, Lai Jiangshan wrote:
>> in 3.6 busy_worker_rebind() handle WORKER_REBIND bit,
>> not WORKER_UNBOUND bit.
>>
>> busy_worker_rebind() takes struct work_struct *work argument, we have to
>> add new patch to add a helper and restruct it at first.
>
> What's wrong with just treating manager as busy.  Factor out,
> rebind_work scheduling from rebind_workers() and call it for busy
> workers and the manager if it exists.  manage_workers() only need to
> call process_scheduled_works().  Wouldn't that work?
>
>> worker_maybe_bind_and_lock() 's mean is very clear
>> here. busy_worker_rebind() seems for busy workers, manager is not
>> busy workers.
>
> I don't know.  It just seems unnecessarily wordy.  If you don't like
> reusing the busy worker path, how about just calling
> maybe_bind_and_lock() unconditionally after locking manager_mutex?  I
> mean, can't it just do the following?
>
> spin_unlock_irq(>lock);
>
> /*
>  * Explain what's going on.
>  */
> mutex_lock(>manager_mutex);
> if (worker_maybe_bind_and_lock(worker))
> worker_clr_flags(worker, WORKER_UNBOUND);
> ret = true;
>


This code is correct. worker_maybe_bind_and_lock() can be called any time.
but I like to call it only when it is really needed.

Thanks.
Lai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: add support for zsmalloc and zcache

[Nitin Gupta]

On 09/07/2012 07:37 AM, Konrad Rzeszutek Wilk wrote:

significant design challenges exist, many of which are already resolved in
the new codebase ("zcache2").  These design issues include:

.. snip..

Before other key mm maintainers read and comment on zcache, I think
it would be most wise to move to a codebase which resolves the known design
problems or, at least to thoroughly discuss and debunk the design issues
described above.  OR... it may be possible to identify and pursue some
compromise plan.  In any case, I believe the promotion proposal is premature.


Thank you for the feedback!

I took your comments and pasted them in this patch.

Seth, Robert, Minchan, Nitin, can you guys provide some comments pls,
so we can put them as a TODO pls or modify the patch below.

Oh, I think I forgot Andrew's comment which was:

  - Explain which workloads this benefits and provide some benchmark data.
This should help in narrowing down in which case we know zcache works
well and in which it does not.

My TODO's were:

  - Figure out (this could be - and perhaps should be in frontswap) a
determination whether this swap is quite fast and the CPU is slow
(or taxed quite heavily now), so as to not slow the currently executing
workloads.
  - Work out automatic benchmarks in three categories: database (I am going to 
use
swing for that), compile (that one is easy), and firefox tab browsers
overloading.


 From bd85d5fa0cc231f2779f3209ee62b755caf3aa9b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 7 Sep 2012 10:21:01 -0400
Subject: [PATCH] zsmalloc/zcache: TODO list.

Adding in comments by Dan.

Signed-off-by: Konrad Rzeszutek Wilk 
---
  drivers/staging/zcache/TODO   |   21 +
  drivers/staging/zsmalloc/TODO |   17 +
  2 files changed, 38 insertions(+), 0 deletions(-)
  create mode 100644 drivers/staging/zcache/TODO
  create mode 100644 drivers/staging/zsmalloc/TODO

diff --git a/drivers/staging/zcache/TODO b/drivers/staging/zcache/TODO
new file mode 100644
index 000..bf19a01
--- /dev/null
+++ b/drivers/staging/zcache/TODO
@@ -0,0 +1,21 @@
+
+A) Andrea Arcangeli pointed out and, after some deep thinking, I came
+   to agree that zcache _must_ have some "backdoor exit" for frontswap
+   pages [2], else bad things will eventually happen in many workloads.
+   This requires some kind of reaper of frontswap'ed zpages[1] which "evicts"
+   the data to the actual swap disk.  This reaper must ensure it can reclaim
+   _full_ pageframes (not just zpages) or it has little value.  Further the
+   reaper should determine which pageframes to reap based on an LRU-ish
+   (not random) approach.
+
+B) Zcache uses zbud(v1) for cleancache pages and includes a shrinker which
+   reclaims pairs of zpages to release whole pageframes, but there is
+   no attempt to shrink/reclaim cleanache pageframes in LRU order.
+   It would also be nice if single-cleancache-pageframe reclaim could
+   be implemented.
+
+C) Offer a mechanism to select whether zbud or zsmalloc should be used.
+   This should be for either cleancache or frontswap pages. Meaning there
+   are four choices: cleancache and frontswap using zbud; cleancache and
+   frontswap using zsmalloc; cleancache using zsmalloc, frontswap using zbud;
+   cleacache using zbud, and frontswap using zsmalloc.
diff --git a/drivers/staging/zsmalloc/TODO b/drivers/staging/zsmalloc/TODO
new file mode 100644
index 000..b1debad
--- /dev/null
+++ b/drivers/staging/zsmalloc/TODO
@@ -0,0 +1,17 @@
+
+A) Zsmalloc has potentially far superior density vs zbud because zsmalloc can
+   pack more zpages into each pageframe and allows for zpages that cross 
pageframe
+   boundaries.  But, (i) this is very data dependent... the average compression
+   for LZO is about 2x.  The frontswap'ed pages in the kernel compile benchmark
+   compress to about 4x, which is impressive but probably not representative of
+   a wide range of zpages and workloads.  And (ii) there are many historical
+   discussions going back to Knuth and mainframes about tight packing of 
data...
+   high density has some advantages but also brings many disadvantages related 
to
+   fragmentation and compaction.  Zbud is much less aggressive (max two zpages
+   per pageframe) but has a similar density on average data, without the
+   disadvantages of high density.
+
+   So zsmalloc may blow zbud away on a kernel compile benchmark but, if both 
were
+   runners, zsmalloc is a sprinter and zbud is a marathoner.  Perhaps the best
+   solution is to offer both?
+



The problem is that zbud performs well only when a (compressed) page is 
either PAGE_SIZE/2 - e or PAGE_SIZE - e, where e is small. So, even if 
the average compression ratio is 2x (which is hard to believe), a 
majority of sizes can actually end up in PAGE_SIZE/2 + e bucket and zbud 
will still give bad performance.  For instance, consider these histograms:


# Created tar of /usr/lib (2GB) on a 

[PATCH mmotm] slub: zero page to fix boot crashes

[Hugh Dickins]

Latest mmotm rarely boots if SLUB is enabled: earlyprintk=vga shows
it crashing with various backtraces.  The memset has now been removed
from kmem_cache_open(), so kmem_cache_init() needs to zero its page.
This gets SLUB booting reliably again.

Signed-off-by: Hugh Dickins 
---

 mm/slub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- mmotm/mm/slub.c 2012-09-07 12:39:38.136019730 -0700
+++ fixed/mm/slub.c 2012-09-08 19:37:38.608993123 -0700
@@ -3712,7 +3712,7 @@ void __init kmem_cache_init(void)
/* Allocate two kmem_caches from the page allocator */
kmalloc_size = ALIGN(kmem_size, cache_line_size());
order = get_order(2 * kmalloc_size);
-   kmem_cache = (void *)__get_free_pages(GFP_NOWAIT, order);
+   kmem_cache = (void *)__get_free_pages(GFP_NOWAIT | __GFP_ZERO, order);
 
/*
 * Must first have the slab cache available for the allocations of the
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regmap: no need primary handler for nested irq

[Mark Brown]

On Sat, Sep 08, 2012 at 03:53:25AM -0700, Yunfan Zhang wrote:
> The primary handler will NOT be called if the interrupt nests into
> another interrupt thread. Remove it to avoid confusing.

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

Re: [RFC PATCH 0/5] driver core: driver probe asynchronously

[Greg Kroah-Hartman]

On Sun, Sep 09, 2012 at 07:25:15AM +0800, Ming Lei wrote:
> Hi,
> 
> This patchset implements asynchronous driver probe for driver_register,
> and try to address the below problems about driver init during
> kernel boot:
>   - help to solve some dependency problem during kernel boot
>   (such as, request_firmware is called inside probe when driver
>   is built in kernel[1])
> 
> The idea behind the patch is very simple:
> 
>   - seperate driver probe from driver_register and run this part
>   in one standalone kernel thread context
> 
>   - so driver_register will become two parts: register the driver
>   on the bus, and trigger to schedule a kernel thread to do the
>   driver probe if autoprobe is set

You do realize we tried this out about 5+ years ago, it caused major
problems, no real benefit, and so we removed it (or maybe never did the
final commit with it, it might never have hit Linus's tree due to all of
the problems we found.)

> Fortunately, my OMAP4 based Pandaboard boots fine with the patchset, and
> looks it may work well.
> 
> More or less, some problems might be triggered by these patchset, but
> it should be helpful and not a big deal:
>   - the dependency problem may be found, and it either exposes
>   the driver's probelm or help to improve the asynchronous probe
>   approach
> 
>   - can use driver_register_sync to work around it
> 
> In summary, there are at least two advantages about asynchronous driver
> probe:
>   - speedup kernel boot when many drivers are built in kernel

I would be really amazed if this is true in any measurable fashion.
Again, we tried this, and it did seem to be a tiny bit faster, but in
the end, wasn't worth it.

>   - make driver's probe() not need to consider running something
>   asynchronously(such as, scsi scan, request_firmware_no_wait, ...),
>   so easier to write drivers

No, that's a bus issue, not a driver issue.  Busses can do this today,
if they want to, no problem at all.  So, some busses have (maybe, maybe
not, I can't remember, but I think ATA did), and that is the level you
need to do this at, not at the driver core level, sorry.

> It should a very simple way to help to solve the problem[1], without
> any changes on current drivers which call request_firmware() in its
> probe(). BTW, the patchset doesn't solve the problem completely, and
> still some work is needed.

As you state, this doesn't really solve the problem, and will cause a
lot more (think about all the busses that aren't expecting to have their
probe functions called at the same time as other probe functions are
being called.)

So while I applaud the effort, I can't accept this due to the past
history of when it was tried before.

sorry,

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] aoe: cleanup an allocation a bit

[Ed Cashin]

Looks OK to me, thanks.

On Sep 7, 2012, at 11:59 PM, "Dan Carpenter"  wrote:

> We changed this recently so we can just use kzalloc() here instead of
> kcalloc(1, ...).  Kernel style prefers sizeof(*t) over sizeof *t.  The
> kfree(t) is a no-op now as well so that can be removed.
> 
> Signed-off-by: Dan Carpenter 
> ---
> Only applies to linux-next.
> 
> diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
> index 5461faa..c0adbbd 100644
> --- a/drivers/block/aoe/aoecmd.c
> +++ b/drivers/block/aoe/aoecmd.c
> @@ -1255,9 +1255,8 @@ addtgt(struct aoedev *d, char *addr, ulong nframes)
>"aoe: device addtgt failure; too many targets\n");
>return NULL;
>}
> -t = kcalloc(1, sizeof *t, GFP_ATOMIC);
> +t = kzalloc(sizeof(*t), GFP_ATOMIC);
>if (!t) {
> -kfree(t);
>printk(KERN_INFO "aoe: cannot allocate memory to add target\n");
>return NULL;
>}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: gadget: Conform with checkpatch -3 warnings, 1 error

[Ben Minerds]

Removed 3 checkpatch.sh warnings and 1 error in
drivers/usb/gadget/serial.c.
-sizeof brackets x2
-remove initialise to 0
-pr_warning to pr_warn

Signed-off-by: Ben Minerds 
---
 drivers/usb/gadget/serial.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/serial.c b/drivers/usb/gadget/serial.c
index 665c074..af69cd2 100644
--- a/drivers/usb/gadget/serial.c
+++ b/drivers/usb/gadget/serial.c
@@ -101,9 +101,8 @@ static struct usb_device_descriptor device_desc = {
 };
 
 static struct usb_otg_descriptor otg_descriptor = {
-   .bLength =  sizeof otg_descriptor,
+   .bLength =  sizeof(otg_descriptor),
.bDescriptorType =  USB_DT_OTG,
-
/* REVISIT SRP-only hardware is possible, although
 * it would not be called "OTG" ...
 */
@@ -127,7 +126,7 @@ static bool use_acm = true;
 module_param(use_acm, bool, 0);
 MODULE_PARM_DESC(use_acm, "Use CDC ACM, default=yes");
 
-static bool use_obex = false;
+static bool use_obex;
 module_param(use_obex, bool, 0);
 MODULE_PARM_DESC(use_obex, "Use CDC OBEX, default=no");
 
@@ -175,7 +174,7 @@ static int __init gs_bind(struct usb_composite_dev *cdev)
 */
 
/* device description: manufacturer, product */
-   snprintf(manufacturer, sizeof manufacturer, "%s %s with %s",
+   snprintf(manufacturer, sizeof(manufacturer), "%s %s with %s",
init_utsname()->sysname, init_utsname()->release,
gadget->name);
status = usb_string_id(cdev);
@@ -212,7 +211,7 @@ static int __init gs_bind(struct usb_composite_dev *cdev)
 * things like configuration and altsetting numbering
 * can need hardware-specific attention though.
 */
-   pr_warning("gs_bind: controller '%s' not recognized\n",
+   pr_warn("gs_bind: controller '%s' not recognized\n",
gadget->name);
device_desc.bcdDevice =
cpu_to_le16(GS_VERSION_NUM | 0x0099);
-- 
1.7.2.5

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

Linux 3.6-rc5

[Linus Torvalds]

Hey, we're back to the *regular* release schedule, with weekly -rc's and all.

So 3.6-rc5 is out there, and everything is looking fairly calm. Too
calm, in fact, I'm waiting for the other shoe to drop, when Greg
finally crawls his way out from under his mailbox after the kernel
summit and kayaking. I suspect a few other developers may also have
been quiet because of the kernel summit and related travel.

I have some more travel myself coming up, but if it stays this quiet
it will hopefully not even be noticeable.

Anyway, what's new? Not a whole lot, and what is there is really
spread pretty much all over, but we're back to the usual situation
with the bulk of it being drivers: sound, mmc, networking (both wired
and wireless), pci, video.

There's some ARM (and to a lesser degree powerpc) updates too, and
some cifs stuff. And random one-liners scattered pretty much all over.
The shortlog is appended, so scan over it just to get a feel for
things,

Linus

---


Alan Cox (1):
  dj: memory scribble in logi_dj

Alan Stern (1):
  HID: add NOGET quirk for Eaton Ellipse MAX UPS

Aleksander Morgado (1):
  net: qmi_wwan: new device: Foxconn/Novatel E396

Alex Shi (1):
  xen: fix logical error in tlb flushing

Alexey Khoroshilov (1):
  can: softing: Fix potential memory leak in softing_load_fw()

Amerigo Wang (1):
  netpoll: revert 6bdb7fe3104 and fix be_poll() instead

Andres Freund (1):
  HID: tpkbd: work even if the new Lenovo Keyboard driver is not configured

Andrew Lunn (1):
  ARM: Kirkwood: Fix 'SZ_1M' undeclared here for db88f6281-bp-setup.c

Anton Blanchard (4):
  powerpc: Update DSCR on all CPUs when writing sysfs dscr_default
  powerpc: Keep thread.dscr and thread.dscr_inherit in sync
  powerpc: Fix DSCR inheritance in copy_thread()
  powerpc: Restore correct DSCR in context switch

Artem Bityutskiy (1):
  UBI: fix a horrible memory deallocation bug

Axel Lin (3):
  gpio: mc9s08dz60: Fix build error if I2C=m
  gpio: em: Fix checking return value of irq_alloc_descs
  gpio: rdc321x: Prevent removal of modules exporting active GPIOs

Ben Hutchings (1):
  sfc: Fix reporting of IPv4 full filters through ethtool

Benjamin Herrenschmidt (1):
  powerpc: Don't use __put_user() in patch_instruction

Bin Liu (1):
  net: ethernet: fix kernel OOPS when remove davinci_mdio module

Bjorn Helgaas (1):
  PCI: Don't print anything while decoding is disabled

Bjørn Mork (1):
  net: qmi_wwan: add several new Gobi devices

Bo Shen (1):
  ARM: at91/dts: remove partial parameter in at91sam9g25ek.dts

Bruce Allan (1):
  e1000e: DoS while TSO enabled caused by link partner with small MSS

Bruno Prémont (1):
  fbcon: Fix bit_putcs() call to kmalloc(s, GFP_KERNEL)

Claudiu Manoil (1):
  gianfar: fix default tx vlan offload feature flag

Dan Carpenter (2):
  video: mb862xxfb: prevent divide by zero bug
  fddi: 64 bit bug in smt_add_para()

Daniel Mack (4):
  ALSA: snd-usb: Fix URB cancellation at stream start
  ALSA: snd-usb: restore delay information
  ALSA: snd-usb: fix calls to next_packet_size
  ALSA: snd-usb: fix cross-interface streaming devices

Dave Jones (1):
  Remove user-triggerable BUG from mpol_to_str

David Henningsson (1):
  ALSA: hda - Do not set GPIOs for speakers on IDT if there are no speakers

Dmitry Torokhov (1):
  Input: i8042 - add Gigabyte T1005 series netbooks to noloop table

Doug Anderson (1):
  mmc: dw_mmc: Disable low power mode if SDIO interrupts are used

Eric Dumazet (3):
  ipv4: properly update pmtu
  ipv4: take rt_uncached_lock only if needed
  ipv4: must use rcu protection while calling fib_lookup

Fengguang Wu (1):
  af_packet: match_fanout_group() can be static

Francesco Ruggeri (1):
  net: ipv4: ipmr_expire_timer causes crash when removing net namespace

Giuseppe CAVALLARO (2):
  stmmac: fix GMAC syn ID
  stmmac: fix a typo in the macro used to mask the mmc irq

Grazvydas Ignotas (1):
  OMAPFB: fix framebuffer console colors

Guenter Roeck (2):
  Input: edt-ft5x06 - fix build error when compiling wthout CONFIG_DEBUG_FS
  linux/kernel.h: Fix DIV_ROUND_CLOSEST to support negative dividends

Henrik Rydberg (1):
  HID: Only dump input if someone is listening

Hiroshi Doyu (4):
  ARM: dma-mapping: atomic_pool with struct page **pages
  ARM: dma-mapping: Refactor out to introduce __in_atomic_pool
  ARM: dma-mapping: Introduce __atomic_get_pages() for __iommu_get_pages()
  ARM: dma-mapping: IOMMU allocates pages from atomic_pool with GFP_ATOMIC

Huang Ying (4):
  PCI/PM: Enable D3/D3cold by default for most devices
  PCI/PM: Keep parent bridge active when probing device
  PCI/PM: Fix config reg access for D3cold and bridge suspending
  PCI/PM: Add ABI document for sysfs file d3cold_allowed

Ian Campbell (1):
  xen-netfront: use __pskb_pull_tail to ensure linear 

Re: [PATCH v2 0/10] mm: SLxB cleaning and trace accuracy improvement

[Christoph]

Please pull from pekkas tree on github or use next (check if the back and forth 
with patchset in and out has been resolved first).


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

[RFC PATCH 4/5] driver core: remove __must_check on declaration of driver_attach

[Ming Lei]

The check is not necessary since driver_attach should return 0
always.

Signed-off-by: Ming Lei 
---
 include/linux/device.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 7222c0b..dbb5efd 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -858,7 +858,7 @@ static inline void *dev_get_platdata(const struct device 
*dev)
 extern int __must_check device_bind_driver(struct device *dev);
 extern void device_release_driver(struct device *dev);
 extern int  __must_check device_attach(struct device *dev);
-extern int __must_check driver_attach(struct device_driver *drv);
+extern int driver_attach(struct device_driver *drv);
 extern int __must_check device_reprobe(struct device *dev);
 
 /*
-- 
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/

[RFC PATCH 3/5] driver core: platform: apply driver_register_sync for platform_driver_probe

[Ming Lei]

platform_driver_probe supposes that the driver's probe is always called
inside platform_driver_probe, so apply driver_register_sync for it.

Signed-off-by: Ming Lei 
---
 drivers/base/platform.c |   11 +++
 include/linux/platform_device.h |   12 +++-
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 42ca90c..f1d3507 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -500,7 +500,7 @@ static void platform_drv_shutdown(struct device *_dev)
  * platform_driver_register - register a driver for platform-level devices
  * @drv: platform driver structure
  */
-int platform_driver_register(struct platform_driver *drv)
+int __platform_driver_register(struct platform_driver *drv, int sync)
 {
drv->driver.bus = _bus_type;
if (drv->probe)
@@ -510,9 +510,12 @@ int platform_driver_register(struct platform_driver *drv)
if (drv->shutdown)
drv->driver.shutdown = platform_drv_shutdown;
 
-   return driver_register(>driver);
+   if (sync)
+   return driver_register_sync(>driver);
+   else
+   return driver_register(>driver);
 }
-EXPORT_SYMBOL_GPL(platform_driver_register);
+EXPORT_SYMBOL_GPL(__platform_driver_register);
 
 /**
  * platform_driver_unregister - unregister a driver for platform-level devices
@@ -551,7 +554,7 @@ int __init_or_module platform_driver_probe(struct 
platform_driver *drv,
 
/* temporary section violation during probe() */
drv->probe = probe;
-   retval = code = platform_driver_register(drv);
+   retval = code = platform_driver_register_sync(drv);
 
/*
 * Fixup that section violation, being paranoid about code scanning
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 5711e95..f791a59 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -175,9 +175,19 @@ struct platform_driver {
const struct platform_device_id *id_table;
 };
 
-extern int platform_driver_register(struct platform_driver *);
+extern int __platform_driver_register(struct platform_driver *, int sync);
 extern void platform_driver_unregister(struct platform_driver *);
 
+static inline int platform_driver_register(struct platform_driver *drv)
+{
+   return __platform_driver_register(drv, 0);
+}
+
+static inline int platform_driver_register_sync(struct platform_driver *drv)
+{
+   return __platform_driver_register(drv, 1);
+}
+
 /* non-hotpluggable platform devices may use this so that probe() and
  * its support may live in __init sections, conserving runtime memory.
  */
-- 
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/

[RFC PATCH 2/5] driver core: introduce driver_register_sync helper

[Ming Lei]

This patch introduces driver_register_sync helper to make
driver's probe called synchronously inside driver_register
path.

platform_driver_probe should use driver_register_sync.

Signed-off-by: Ming Lei 
---
 drivers/base/driver.c  |5 +++--
 include/linux/device.h |   13 -
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 27f4c85..9365076 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -156,12 +156,13 @@ static void driver_remove_groups(struct device_driver 
*drv,
 /**
  * driver_register - register driver with bus
  * @drv: driver to register
+ * @sync: if the .probe() is called synchronously
  *
  * We pass off most of the work to the bus_add_driver() call,
  * since most of the things we have to do deal with the bus
  * structures.
  */
-int driver_register(struct device_driver *drv)
+int __driver_register(struct device_driver *drv, int sync)
 {
int ret;
struct device_driver *other;
@@ -197,7 +198,7 @@ int driver_register(struct device_driver *drv)
 
return ret;
 }
-EXPORT_SYMBOL_GPL(driver_register);
+EXPORT_SYMBOL_GPL(__driver_register);
 
 /**
  * driver_unregister - remove driver from system.
diff --git a/include/linux/device.h b/include/linux/device.h
index dd0d684..7222c0b 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -237,9 +237,20 @@ struct device_driver {
 };
 
 
-extern int __must_check driver_register(struct device_driver *drv);
+extern int __must_check __driver_register(struct device_driver *drv,
+ int sync);
 extern void driver_unregister(struct device_driver *drv);
 
+static inline int __must_check driver_register(struct device_driver *drv)
+{
+   return __driver_register(drv, 0);
+}
+
+static inline int __must_check driver_register_sync(struct device_driver *drv)
+{
+   return __driver_register(drv, 1);
+}
+
 extern struct device_driver *driver_find(const char *name,
 struct bus_type *bus);
 extern int driver_probe_done(void);
-- 
1.7.9.5

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

[RFC PATCH 1/5] driver core: driver probe at the last minute in driver_register

[Ming Lei]

It should be correct to probe driver at the last minute in
driver_register since it will be so in !auto_probe case and
driver_register on no matched devices case.

Signed-off-by: Ming Lei 
---
 drivers/base/bus.c|5 -
 drivers/base/driver.c |4 
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 181ed26..00d841d 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -714,11 +714,6 @@ int bus_add_driver(struct device_driver *drv)
if (error)
goto out_unregister;
 
-   if (drv->bus->p->drivers_autoprobe) {
-   error = driver_attach(drv);
-   if (error)
-   goto out_unregister;
-   }
klist_add_tail(>knode_bus, >p->klist_drivers);
module_add_driver(drv->owner, drv);
 
diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 974e301..27f4c85 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -191,6 +191,10 @@ int driver_register(struct device_driver *drv)
}
kobject_uevent(>p->kobj, KOBJ_ADD);
 
+   /* driver probe at the last minute */
+   if (drv->bus->p->drivers_autoprobe)
+   ret = driver_attach(drv);
+
return ret;
 }
 EXPORT_SYMBOL_GPL(driver_register);
-- 
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/

[RFC PATCH 5/5] driver core: implement asynchorous probe() inside driver_register

[Ming Lei]

Signed-off-by: Ming Lei 
---
 drivers/base/driver.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 9365076..67fb63c 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "base.h"
 
 static struct device *next_device(struct klist_iter *i)
@@ -153,6 +154,13 @@ static void driver_remove_groups(struct device_driver *drv,
sysfs_remove_group(>p->kobj, groups[i]);
 }
 
+static void async_driver_attach(void *data, async_cookie_t cookie)
+{
+   struct device_driver *drv = data;
+
+   driver_attach(drv);
+}
+
 /**
  * driver_register - register driver with bus
  * @drv: driver to register
@@ -193,8 +201,12 @@ int __driver_register(struct device_driver *drv, int sync)
kobject_uevent(>p->kobj, KOBJ_ADD);
 
/* driver probe at the last minute */
-   if (drv->bus->p->drivers_autoprobe)
-   ret = driver_attach(drv);
+   if (drv->bus->p->drivers_autoprobe) {
+   if (sync)
+   ret = driver_attach(drv);
+   else
+   async_schedule(async_driver_attach, drv);
+   }
 
return ret;
 }
-- 
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/

[RFC PATCH 0/5] driver core: driver probe asynchronously

[Ming Lei]

Hi,

This patchset implements asynchronous driver probe for driver_register,
and try to address the below problems about driver init during
kernel boot:
- help to solve some dependency problem during kernel boot
(such as, request_firmware is called inside probe when driver
is built in kernel[1])

The idea behind the patch is very simple:

- seperate driver probe from driver_register and run this part
in one standalone kernel thread context

- so driver_register will become two parts: register the driver
on the bus, and trigger to schedule a kernel thread to do the
driver probe if autoprobe is set

Fortunately, my OMAP4 based Pandaboard boots fine with the patchset, and
looks it may work well.

More or less, some problems might be triggered by these patchset, but
it should be helpful and not a big deal:
- the dependency problem may be found, and it either exposes
the driver's probelm or help to improve the asynchronous probe
approach

- can use driver_register_sync to work around it

In summary, there are at least two advantages about asynchronous driver
probe:
- speedup kernel boot when many drivers are built in kernel
- make driver's probe() not need to consider running something
asynchronously(such as, scsi scan, request_firmware_no_wait, ...),
so easier to write drivers

It should a very simple way to help to solve the problem[1], without
any changes on current drivers which call request_firmware() in its
probe(). BTW, the patchset doesn't solve the problem completely, and
still some work is needed.


[1], http://marc.info/?t=13467641612=1=2


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

Re: [PATCH v2 0/10] mm: SLxB cleaning and trace accuracy improvement

[Ezequiel Garcia]

Christoph,

On Sat, Sep 8, 2012 at 7:30 PM, Christoph Lameter  wrote:
> On Sat, 8 Sep 2012, Ezequiel Garcia wrote:
>
>> This is the second spin of my patchset to clean SLxB and improve kmem
>> trace events accuracy.
>
> Please redo the patches on top of the patchsets that create
> mm/slab_common.c. You will be able to extract a lot more common code and
> help the goal of having as much common code as possible. PLease move as
> much as possible of the common functions into slab_common.c
>

Ah, I wasn't sure where to base my patches. I can split this patchset in two and
base the SLAB/SLUB commonize part on top of your tree, or perhaps just
based everything on top of your tree.

Is it this one?
http://west.gentwo.org/gitweb/?p=christoph;a=shortlog;h=refs/heads/common

I have to admit I started thinking of this commonization after seeing
your common
code patches.

Thanks!
Ezequiel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/12] perf tools: include wrapper for magic.h

[Irina Tirdea]

On Sat, Sep 8, 2012 at 12:13 PM, Pekka Enberg  wrote:
> Hi Irina,
>

Hi Pekka,

> I commented on some of the patches but overall, I think the series makes 
> sense:
>
> Acked-by: Pekka Enberg 

Thanks for reviewing it!

Irina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio-balloon spec: provide a version of the "silent deflate" feature that works

[Michael S. Tsirkin]

On Sat, Sep 08, 2012 at 02:36:00PM +0930, Rusty Russell wrote:
> "Michael S. Tsirkin"  writes:
> > On Fri, Sep 07, 2012 at 04:09:50PM +0930, Rusty Russell wrote:
> >> > So it looks like a bug: we should teach driver to tell host first on 
> >> > leak?
> >> > Yan, Vadim, can you comment please?
> >> >
> >> > Also if true, looks like this bit will be useful to detect a fixed 
> >> > driver on
> >> > the hypervisor side - to avoid unmapping such pages? Rusty what do you
> >> > think?
> >> 
> >> So, feature is unimplemented in qemu, and broken in drivers.  I starting
> >> to share Paolo's dislike of it.
> >
> > What is broken in drivers?
> 
> Because supporting the feature is *not* optional for a driver.
> 
> If the device said MUST_TELL_HOST, it meant that the driver *had* to
> tell the host before it touched the page, otherwise Bad Things might
> happen.  It was in the original spec precisely to allow devices to
> actually *remove* pages.
> 
> Noone ever noticed the windows driver didn't support it, because qemu
> never requires MUST_TELL_HOST.
> 
> So in practice, it's now an optional feature.  Since no device used it
> anyway, we're better off discarding it than trying to fix it.

I trust you this was not the intent. But it seems to be
the intent in spec, because almost all features are optional.

And so windows driver authors interpreted it
this way. And it is *useful* like this.  See below.

> If someone wants an *optional* "tell me first" feature later, that's
> easy to add, but I don't see why they'd want to.

Suggested use is for device assignment which needs all guest memory
locked.  hypervisor can unlock pages in balloon but guest must wait for
hypervisor to lock them back before use.

when a hypervisor implements this,
this will work with linux guests but not windows
guests and the existing bit fits exactly the purpose.


> > Do we really know there are no hypervisors implementing it?
> 
> As much as can be known.  Qemu doesn't, lkvm doesn't.

But we can add it in qemu and it will be a useful feature.

> > As I said above drivers do have support.
> 
> Not the windows drivers.  So it's optional, thus removing it will likely
> harm noone.
> 
> Cheers,
> Rusty.

I think the issue is that kvm always locked all guest memory
for assignment. This restriction is removed
with vfio which has separate page tables.
Now that vfio is upstream and work on qemu integration
is being worked on, we might finally see people using this bit
to allow memory overcommit with device assignment.

So let's not remove yet, there is no rush.
Let's document it that this feature is optional,
maybe renaming as Paolo suggests.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/10] mm: SLxB cleaning and trace accuracy improvement

[Christoph Lameter]

On Sat, 8 Sep 2012, Ezequiel Garcia wrote:

> This is the second spin of my patchset to clean SLxB and improve kmem
> trace events accuracy.

Please redo the patches on top of the patchsets that create
mm/slab_common.c. You will be able to extract a lot more common code and
help the goal of having as much common code as possible. PLease move as
much as possible of the common functions into slab_common.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 the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] perf tool: basename cleanups

[Irina Tirdea]

> Irina: Would you verify perf still compiles cleanly for Android. Thanks.
>

With these 3 patches perf still compiles cleanly for Android.
Thanks for making the changes.

Irina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG][3.4.10] Conflicts between initializing my USB devices and my IDE devices

[David Miller]

The IDE layer does not handle shared interrupts properly at all,
and it never will be rearchitected to do so.

This is a well known issue.

Please disable IDE in your configuration and use the PATA drivers
instead, which are able to handle shared interrupts properly.

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

[BUG][3.4.10] Conflicts between initializing my USB devices and my IDE devices

[Steven Rostedt]

I upgraded my workstation to 3.4.10 from something like 3.2 or so, thus
I don't know when this started causing issues. But after I did, my 2TB
WD external USB hard drive stopped showing up.

I looked at my dmesg and saw this:

[1.372997] 
/home/rostedt/work/git/nobackup/linux-build.git/drivers/usb/core/inode.c: 
creating file '002'
[1.373024] hub 3-0:1.0: state 7 ports 3 chg 000c evt 000c
[1.373032] ohci_hcd :07:01.0: GetStatus roothub.portstatus [1] = 
0x00010100 CSC PPS
[1.373045] hub 3-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
[1.465871] [ cut here ]
[1.466177] WARNING: at 
/home/rostedt/work/git/nobackup/linux-build.git/kernel/irq/manage.c:433 
__enable_irq+0x60/0x120()
[1.466782] Hardware name: System Product Name
[1.467056] Unbalanced enable for IRQ 16
[1.467304] Modules linked in: ata_generic(+) ohci_hcd xhci_hcd ata_piix 
r8169 mii libata via82cxxx(+) ehci_hcd scsi_mod ide_pci_generic ide_core 
usbcore usb_common
[1.468790] Pid: 146, comm: modprobe Not tainted 3.4.10-custom+ #25
[1.469153] Call Trace:
[1.469332]  [] warn_slowpath_common+0x7f/0xc0
[1.469684]  [] warn_slowpath_fmt+0x46/0x50
[1.470042]  [] __enable_irq+0x60/0x120
[1.470375]  [] enable_irq+0x5d/0xa0
[1.470670] usb 1-1: link qh256-0001/88022f9798c0 start 1 [1/0 us]
[1.470706]  [] ide_probe_port+0x1a9/0x6d0 [ide_core]
[1.471090]  [] ? dmi_check_system+0x2b/0x60
[1.471433]  [] ide_host_register+0x2d9/0x730 [ide_core]
[1.471828]  [] ide_pci_init_two+0x4ba/0x7c0 [ide_core]
[1.472220]  [] ? _raw_spin_unlock_irqrestore+0x18/0x40
[1.472610]  [] ? console_unlock+0x1f5/0x270
[1.472955]  [] ide_pci_init_one+0x16/0x20 [ide_core]
[1.473337]  [] via_init_one+0x237/0x25c [via82cxxx]
[1.473715]  [] ? get_parent_ip+0x11/0x50
[1.474044]  [] ? via82cxxx_cable_detect+0xa0/0xa0 
[via82cxxx]
[1.474475]  [] local_pci_probe+0x5c/0xd0
[1.474806]  [] pci_device_probe+0x101/0x120
[1.475150]  [] driver_probe_device+0x7e/0x220
[1.475501]  [] __driver_attach+0xab/0xb0
[1.475832]  [] ? driver_probe_device+0x220/0x220
[1.476195]  [] bus_for_each_dev+0x56/0x90
[1.476529]  [] driver_attach+0x1e/0x20
[1.476850]  [] bus_add_driver+0x1a0/0x260
[1.477184]  [] ? 0xa0035fff
[1.477492]  [] driver_register+0x76/0x130
[1.477826]  [] ? notifier_call_chain.isra.0+0x4d/0x70
[1.478210]  [] ? 0xa0035fff
[1.478518]  [] __pci_register_driver+0x55/0xd0
[1.478873]  [] ? set_memory_nx+0x43/0x50
[1.479203]  [] via_ide_init+0x1e/0x1000 [via82cxxx]
[1.479580]  [] do_one_initcall+0x3f/0x170
[1.479914]  [] sys_init_module+0xbe/0x230
[1.480249]  [] system_call_fastpath+0x16/0x1b
[1.480599] ---[ end trace 99f8fad80eedfdb7 ]---
[1.480909] Probing IDE interface ide1...

Thinking, OK this is probably related. I than started debugging and
added a bunch of trace_printks around the enable/disable_irq() routines,
and monitoring the desc->depth. This is what I found:

[edited for just the relevant content]

   <...>-146   [002]  0.898096: ide_probe_port:  disable irq 16
   <...>-146   [002] d..1 0.898097: __disable_irq_nosync: 
disable_irq 16 desc=8802349bb880
   <...>-146   [002] d..1 0.898098: __disable_irq: inc desc 16 
8802349bb880 (1)
   <...>-198   [001]  0.920680: __setup_irq: setup irq 16 decs 
8802349bb880
   <...>-198   [001] d..1 0.920680: irq_startup: reset desc 
8802349bb880
   <...>-198   [001] d..1 0.920686: 
 => irq_startup
 => __setup_irq
 => request_threaded_irq
 => usb_add_hcd
 => usb_hcd_pci_probe
 => local_pci_probe
 => pci_device_probe
 => driver_probe_device
 => __driver_attach
 => bus_for_each_dev
 => driver_attach
 => bus_add_driver
 => driver_register
 => __pci_register_driver
 => acpi_lid_send_state
 => do_one_initcall
 => sys_init_module
 => system_call_fastpath
   <...>-146   [002]  1.465868: ide_probe_port: enable irq 16
   <...>-146   [002] d..1 1.465869: enable_irq: enable_irq 16 
desc=8802349bb880
   <...>-146   [002] d..1 1.465870: __enable_irq: desc depth 16 
8802349bb880 (0)


Seems there's a nasty race/conflict between threads 146 and 198. Thread
146 is probing the ide devices and has code that looks like this:

irqd = hwif->irq;
if (irqd)
disable_irq(hwif->irq);

if (ide_port_wait_ready(hwif) == -EBUSY)
printk(KERN_DEBUG "%s: Wait for ready failed before probe !\n", 
hwif->name);

/*
 * Second drive should only exist if first drive was found,
 * but a lot of cdrom drives are configured as single slaves.
 */
ide_port_for_each_dev(i, drive, hwif) {
(void) probe_for_drive(drive);
if (drive->dev_flags & IDE_DFLAG_PRESENT)
rc = 0;
}

   

Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works

[Michael S. Tsirkin]

On Fri, Sep 07, 2012 at 04:44:40PM +0200, Paolo Bonzini wrote:
> Il 07/09/2012 16:25, Michael S. Tsirkin ha scritto:
> >> > Silent deflate is deflating just by using the page, without using the
> >> > deflateq at all.  So it can be done even from GFP_ATOMIC context.
> > BTW I don't see a need to avoid deflateq.
> > Without MUST_TELL_HOST you can just deflate and then
> > bounce telling the host out to a thread.
> 
> Yes, that's fine too.

OK so it's preferable: will work on existing hypervisors.

> >> > But knowing that the guest will _not_ deflate silently also benefits the
> >> > host. This is the cause of unpinning ballooned pages and pinning them
> >> > again upon deflation. This allows cooperative memory overcommit even if
> >> > the guests' memory is pinned, similar to what Xen did before it
> >> > supported overcommit.  This is the second feature bit.
> > This is the MUST_TELL_HOST.
> 
> Almost.  One is "the guest, if really needed, can tell the host of
> pages".  If not negotiated, and the host does not support it, the host
> must break the guest (e.g. fail to offer any virtqueues).

There is no way in spec to break the guest.
You can not fail to offer virtqueues.
Besides, there is no guarantee that virtqueue setup
happens after feature negotiation.

> The other is "the guest, though, would prefer not to do so".  It is
> different because the guest can proceed in a fallback mode even if the
> host doesn't offer it.

I think I get what your proposed SILENT means what I do not get
is the motivation. It looks like a premature optimization to me.

> You're interpreting features as something that dictates behavior, but
> they're really just advisory.

The spec is pretty clear that if guest acks feature it
is a contract that dictates behaviour.
If it doesn't it is either ignored or just informative
depending on feature.

>  You could negotiate VIRTIO_BLK_F_TOPOLOGY
> and end up never reading the fields; you could negotiate
> VIRTIO_NET_F_GUEST_ANNOUNCE and never send a guest announcement.


Block example is just informative. It does not need to be
negotiated even to be used.
But last example is wrong.
If you ack GUEST_ANNOUNCE hypervisor assumes guest will
announce self, if guest does not do it this break migration.


> >> > * guest will always do silent deflation: current Windows driver.
> > Not exactly. It is not silent. It tells host
> > just after use.
> 
> Yeah, but no difference from the POV of the driver.
> 
> Delaying or avoiding is the same in the end.  The spec says it well: "In
> this case, deflation advice is merely a courtesy".

So it looks like we don't need a new bit to leak in atomic ctx.
Just do not ack MUST_TELL_HOST and delay telling host to a wq.
IMO we should not add random stuff to spec like this just because it
seems like a good idea.

> >> > Negotiates nothing, or if it cares it can negotiate
> >> > VIRTIO_BALLOON_F_SILENT_DEFLATE.  Host mustn't do munlock/mlock dance.
> >> >
> >> > * guest may do silent deflation if available: combo of Linux driver +
> >> > Frank's driver.  Negotiates both features, looks at
> >> > VIRTIO_BALLOON_F_SILENT_DEFLATE host feature to decide how to behave:
> >> > 
> >> >   ** If PCI passthrough, the host will not negotiate
> >> >  VIRTIO_BALLOON_F_SILENT_DEFLATE.  The driver will behave as the
> >> >  current Linux driver, the host can do the munlock/mlock dance.
> > So this case is just existing interface. OK.
> > 
> >> >   ** If no PCI passthrough, the host will negotiate
> >> >  VIRTIO_BALLOON_F_SILENT_DEFLATE, and the driver can balloon more
> >> >  aggressively and not use the deflateq.
> >> > 
> > This last trickery confuses me.  It just does not make sense to set both
> > SILENT and TELL: either you are silent or you tell.
> 
> "I can be chatty if you ask me, but I'd rather be silent if you let me".
> 
> TELL is a request of the host to the guest; the guest can agree or not.
> 
> SILENT is a request of the guest to the host; the host can agree or not.

OK so TELL says *when* to notify host, SILENT if set allows guest
to skip leak notifications? In this case TELL should just be ignored
when SILENT is set. Otherwise it's a reasonable extension.
But I am still not sure *why* do we need SILENT - any data showing
that avoiding these notifications is a win?
Let's not add new features until we see an actual use.


> > It seems cleaner for the host to know the state.
> 
> Yeah, if you want to do it you can.
> 
> Paolo

IMHO, renaming is fine since there is confusion.
But WILL_TELL is also not all that clear imho.

I think the confusion is that TELL_HOST seems to
imply we can avoid telling host at all.
How about being explicit?

VIRTIO_BALLOON_F_HOST_ACK_BEFORE_DEFLATE

Hmm?


"MUST" "WILL" are not really informative.

Also some confusion I think is from spec text saying "feature is set"
in many cases where it really almost always means "feature is negotiated".

Let's address?

-- 
MSt
--
To unsubscribe from this list: send the line 

Re: [PATCH v2 03/12] perf tools: include __WORDSIZE definition

[Irina Tirdea]

>> +#ifndef __WORDSIZE
>> +#if defined(__x86_64__)
>> +# define __WORDSIZE 64
>> +#endif
>> +#if defined(__i386__) || defined(__arm__)
>> +# define __WORDSIZE 32
>> +#endif
>> +#endif
>
> Why not use "sizeof(unsigned long) * 8" ?

I tried to do it this, but the compilation crashes because this value
is tested in an #if:

target  C: libperf <= tools/perf/util/annotate.c
In file included from tools/perf/util/include/linux/bitmap.h:5:0,
 from tools/perf/util/header.h:10,
 from tools/perf/util/session.h:6,
 from tools/perf/util/build-id.h:4,
 from tools/perf/util/annotate.c:11:
tools/perf/util/include/linux/bitops.h: In function '__ffs':
tools/perf/util/include/linux/bitops.h:62:5: warning: "sizeof" is not
defined [-Wundef]
tools/perf/util/include/linux/bitops.h:62:5: error: missing binary
operator before token "("

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

Re: [PATCH v3 1/2] PM / devfreq: add global PM QoS support

[Rafael J. Wysocki]

On Thursday, August 30, 2012, MyungJoo Ham wrote:
> Even if the performance of a device is controlled properly with devfreq,
> sometimes, we still need to get PM-QoS inputs in order to meet the
> required performance.
> 
> In our testbed of Exynos4412, which has on-chip various DMA devices, the
> memory interface and system bus are controlled according to their
> utilization by devfreq. However, in some multimedia applications
> including video-playing with MFC (multi-function codec) H/W and
> photo/video-capturing with FIMC H/W, we have observed issues due to
> insufficient DMA throughput or latency.
> 
> In such applications, there are deadlines: less than 16.6ms with 60Hz.
> With shorter polling intervals (5 ~ 15ms), the frequencies fluctuate
> within a frame and we get missing frames and distorted pictures.
> With longer polling intervals (20 ~ 100ms), the response time is not
> sufficient and we get distorted or broken images. In other words,
> regardless of polling interval, we get poor results with hard-deadline
> H/Ws. They, in fact, have a preset requirement on DMA throughput.
> 
> Thus, we need PM-QoS capabilities in devfreq. (Note that for general
> user applications, devfreq for bus/memory works fine. They are not so
> sensitive to tens of ms in performance increasing responses in general.
> 
> In order to express how to handle QoS requests in devfreq devices,
> the devfreq device drivers only need to express the mappings of
> QoS value and frequency pairs with QoS class along with
> devfreq_add_device() call.
> 
> As a side effect of the implementation, which happens to be positive,
> min/max freq is now enforced regardless of governor implementation.

Can you please explain in a few words how this is supposed to work in
practice?

> Tested on Exynos4412 machines with memory/bus frequencies and multimedia
> H/W blocks. (camera, video decoding, and video encoding)
> 
> Signed-off-by: MyungJoo Ham 
> Signed-off-by: Kyungmin Park 

I'm not entirely convinced yet, but a few comments follow.

> ---
> Changed from V2-resend
> - Removed dependencies on global pm-qos class definitions
> - Revised data structure handling pm-qos (being ready for dev-pm-qos)
> 
> Changes from V2
> - Rebased
> 
> Changes from V1
> - Error handling at devfreq_add_device()
> - Handling pm_qos_max information
> - Styly update
> ---
>  drivers/devfreq/devfreq.c |  127 
> +++--
>  include/linux/devfreq.h   |   41 ++
>  2 files changed, 164 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 00e326c..d74b382 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "governor.h"
>  
>  static struct class *devfreq_class;
> @@ -136,8 +137,13 @@ int update_devfreq(struct devfreq *devfreq)
>* List from the highest proiority
>* max_freq (probably called by thermal when it's too hot)
>* min_freq
> +  * qos_min_freq
>*/
>  
> + if (devfreq->qos_min_freq && freq < devfreq->qos_min_freq) {
> + freq = devfreq->qos_min_freq;
> + flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */

What exactly is the purpose of this last line?

> + }
>   if (devfreq->min_freq && freq < devfreq->min_freq) {
>   freq = devfreq->min_freq;
>   flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */
> @@ -164,12 +170,12 @@ int update_devfreq(struct devfreq *devfreq)
>   * devfreq_notifier_call() - Notify that the device frequency requirements
>   *  has been changed out of devfreq framework.
>   * @nb   the notifier_block (supposed to be devfreq->nb)
> - * @type not used
> + * @val  not used.
>   * @devp not used
>   *
>   * Called by a notifier that uses devfreq->nb.
>   */
> -static int devfreq_notifier_call(struct notifier_block *nb, unsigned long 
> type,
> +static int devfreq_notifier_call(struct notifier_block *nb, unsigned long 
> val,
>void *devp)
>  {
>   struct devfreq *devfreq = container_of(nb, struct devfreq, nb);

The above change is only a cleanup unrelated to the rest of modifications.
Please push it separately (if you _really_ think it's necessary).

> @@ -183,6 +189,49 @@ static int devfreq_notifier_call(struct notifier_block 
> *nb, unsigned long type,
>  }
>  
>  /**
> + * devfreq_qos_notifier_call() -

This looks like a missing kerneldoc comment?

> + */
> +static int devfreq_qos_notifier_call(struct notifier_block *nb,
> +  unsigned long value, void *devp)
> +{
> + struct devfreq *devfreq = container_of(nb, struct devfreq, qos_nb);
> + int ret;
> + int i;
> + s32 default_value = PM_QOS_DEFAULT_VALUE;
> + struct devfreq_pm_qos_table *qos_list = devfreq->profile->qos_list;
> + bool qos_use_max 

[PATCHv3 4/4] efi: Fix the ACPI BGRT driver for images located in EFI boot services memory

[Josh Triplett]

The ACPI BGRT driver accesses the BIOS logo image when it initializes.
However, ACPI 5.0 (which introduces the BGRT) recommends putting the
logo image in EFI boot services memory, so that the OS can reclaim that
memory.  Production systems follow this recommendation, breaking the
ACPI BGRT driver.

Move the bulk of the BGRT code to run during a new EFI late
initialization phase, which occurs after switching EFI to virtual mode,
and after initializing ACPI, but before freeing boot services memory.
Copy the BIOS logo image to kernel memory at that point, and make it
accessible to the BGRT driver.  Rework the existing ACPI BGRT driver to
act as a simple wrapper exposing that image (and the properties from the
BGRT) via sysfs.

Signed-off-by: Josh Triplett 
---
 arch/x86/platform/efi/Makefile   |1 +
 arch/x86/platform/efi/efi-bgrt.c |   76 ++
 arch/x86/platform/efi/efi.c  |6 +++
 drivers/acpi/Kconfig |4 +-
 drivers/acpi/bgrt.c  |   76 +-
 include/linux/efi-bgrt.h |   21 +++
 include/linux/efi.h  |2 +
 init/main.c  |4 +-
 8 files changed, 120 insertions(+), 70 deletions(-)
 create mode 100644 arch/x86/platform/efi/efi-bgrt.c
 create mode 100644 include/linux/efi-bgrt.h

diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile
index 73b8be0..6db1cc4 100644
--- a/arch/x86/platform/efi/Makefile
+++ b/arch/x86/platform/efi/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_EFI)  += efi.o efi_$(BITS).o efi_stub_$(BITS).o
+obj-$(CONFIG_ACPI_BGRT) += efi-bgrt.o
diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
new file mode 100644
index 000..f6a0c1b
--- /dev/null
+++ b/arch/x86/platform/efi/efi-bgrt.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright 2012 Intel Corporation
+ * Author: Josh Triplett 
+ *
+ * Based on the bgrt driver:
+ * Copyright 2012 Red Hat, Inc 
+ * Author: Matthew Garrett
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+
+struct acpi_table_bgrt *bgrt_tab;
+void *bgrt_image;
+size_t bgrt_image_size;
+
+struct bmp_header {
+   u16 id;
+   u32 size;
+} __packed;
+
+void efi_bgrt_init(void)
+{
+   acpi_status status;
+   void __iomem *image;
+   bool ioremapped = false;
+   struct bmp_header bmp_header;
+
+   if (acpi_disabled)
+   return;
+
+   status = acpi_get_table("BGRT", 0,
+   (struct acpi_table_header **)_tab);
+   if (ACPI_FAILURE(status))
+   return;
+
+   if (bgrt_tab->version != 1)
+   return;
+   if (bgrt_tab->image_type != 0 || !bgrt_tab->image_address)
+   return;
+
+   image = efi_lookup_mapped_addr(bgrt_tab->image_address);
+   if (!image) {
+   image = ioremap(bgrt_tab->image_address, sizeof(bmp_header));
+   ioremapped = true;
+   if (!image)
+   return;
+   }
+
+   memcpy_fromio(_header, image, sizeof(bmp_header));
+   if (ioremapped)
+   iounmap(image);
+   bgrt_image_size = bmp_header.size;
+
+   bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL);
+   if (!bgrt_image)
+   return;
+
+   if (ioremapped) {
+   image = ioremap(bgrt_tab->image_address, bmp_header.size);
+   if (!image) {
+   kfree(bgrt_image);
+   bgrt_image = NULL;
+   return;
+   }
+   }
+
+   memcpy_fromio(bgrt_image, image, bgrt_image_size);
+   if (ioremapped)
+   iounmap(image);
+}
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 90023d1..faa04f7 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -745,6 +746,11 @@ void __init efi_init(void)
 #endif
 }
 
+void __init efi_late_init(void)
+{
+   efi_bgrt_init();
+}
+
 void __init efi_set_executable(efi_memory_desc_t *md, bool executable)
 {
u64 addr, npages;
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 8099895..119d58d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -385,8 +385,8 @@ config ACPI_CUSTOM_METHOD
  to override that restriction).
 
 config ACPI_BGRT
-tristate "Boottime Graphics Resource Table support"
-default n
+   bool "Boottime Graphics Resource Table support"
+   depends on EFI
 help
  This driver adds support for exposing the ACPI Boottime Graphics
  Resource Table, which allows the operating system to obtain
diff --git a/drivers/acpi/bgrt.c 

[PATCHv3 3/4] efi: Add a function to look up existing IO memory mappings

[Josh Triplett]

The EFI initialization creates virtual mappings for EFI boot services
memory, so if a driver wants to access EFI boot services memory, it
cannot call ioremap itself; doing so will trip the WARN about mapping
RAM twice.  Thus, a driver accessing EFI boot services memory must do so
via the existing mapping already created during EFI intiialization.
Since the EFI code already maintains a memory map for that memory, add a
function efi_lookup_mapped_addr to look up mappings in that memory map.

Signed-off-by: Josh Triplett 
---
 arch/x86/platform/efi/efi.c |   28 
 include/linux/efi.h |1 +
 2 files changed, 29 insertions(+)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ab2cfe8..90023d1 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -777,6 +777,34 @@ static void __init runtime_code_page_mkexec(void)
 }
 
 /*
+ * We can't ioremap data in EFI boot services RAM, because we've already mapped
+ * it as RAM.  So, look it up in the existing EFI memory map instead.  Only
+ * callable after efi_enter_virtual_mode and before efi_free_boot_services.
+ */
+void __iomem *efi_lookup_mapped_addr(u64 phys_addr)
+{
+   void *p;
+   if (WARN_ON(!memmap.map))
+   return NULL;
+   for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+   efi_memory_desc_t *md = p;
+   u64 size = md->num_pages << EFI_PAGE_SHIFT;
+   u64 end = md->phys_addr + size;
+   if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
+   md->type != EFI_BOOT_SERVICES_CODE &&
+   md->type != EFI_BOOT_SERVICES_DATA)
+   continue;
+   if (!md->virt_addr)
+   continue;
+   if (phys_addr >= md->phys_addr && phys_addr < end) {
+   phys_addr += md->virt_addr - md->phys_addr;
+   return (__force void __iomem *)phys_addr;
+   }
+   }
+   return NULL;
+}
+
+/*
  * This function will switch the EFI runtime services to virtual mode.
  * Essentially, look through the EFI memmap and map every region that
  * has the runtime attribute bit set in its memory descriptor and update
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 3c72c27..00aa5de 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -502,6 +502,7 @@ extern void efi_free_boot_services(void);
 static void efi_enter_virtual_mode(void) {}
 static void efi_free_boot_services(void) {}
 #endif
+extern void __iomem *efi_lookup_mapped_addr(u64 phys_addr);
 extern u64 efi_get_iobase (void);
 extern u32 efi_mem_type (unsigned long phys_addr);
 extern u64 efi_mem_attributes (unsigned long phys_addr);
-- 
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/

[PATCHv3 2/4] efi: Defer freeing boot services memory until after ACPI init

[Josh Triplett]

Some new ACPI 5.0 tables reference resources stored in boot services
memory, so keep that memory around until we have ACPI and can extract
data from it.

Signed-off-by: Josh Triplett 
---
 arch/x86/platform/efi/efi.c |   31 ++-
 include/linux/efi.h |2 ++
 init/main.c |3 +++
 3 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 92660eda..ab2cfe8 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -419,10 +419,21 @@ void __init efi_reserve_boot_services(void)
}
 }
 
-static void __init efi_free_boot_services(void)
+static void __init efi_unmap_memmap(void)
+{
+   if (memmap.map) {
+   early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
+   memmap.map = NULL;
+   }
+}
+
+void __init efi_free_boot_services(void)
 {
void *p;
 
+   if (!efi_native)
+   return;
+
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
efi_memory_desc_t *md = p;
unsigned long long start = md->phys_addr;
@@ -438,6 +449,8 @@ static void __init efi_free_boot_services(void)
 
free_bootmem_late(start, size);
}
+
+   efi_unmap_memmap();
 }
 
 static int __init efi_systab_init(void *phys)
@@ -787,8 +800,10 @@ void __init efi_enter_virtual_mode(void)
 * non-native EFI
 */
 
-   if (!efi_native)
-   goto out;
+   if (!efi_native) {
+   efi_unmap_memmap();
+   return;
+   }
 
/* Merge contiguous regions of the same type and attribute */
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
@@ -878,13 +893,6 @@ void __init efi_enter_virtual_mode(void)
}
 
/*
-* Thankfully, it does seem that no runtime services other than
-* SetVirtualAddressMap() will touch boot services code, so we can
-* get rid of it all at this point
-*/
-   efi_free_boot_services();
-
-   /*
 * Now that EFI is in virtual mode, update the function
 * pointers in the runtime service table to the new virtual addresses.
 *
@@ -906,9 +914,6 @@ void __init efi_enter_virtual_mode(void)
if (__supported_pte_mask & _PAGE_NX)
runtime_code_page_mkexec();
 
-out:
-   early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
-   memmap.map = NULL;
kfree(new_memmap);
 }
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 52fbedf..3c72c27 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -497,8 +497,10 @@ extern void efi_memmap_walk (efi_freemem_callback_t 
callback, void *arg);
 extern void efi_gettimeofday (struct timespec *ts);
 #ifdef CONFIG_X86
 extern void efi_enter_virtual_mode (void); /* switch EFI to virtual mode, 
if possible */
+extern void efi_free_boot_services(void);
 #else
 static void efi_enter_virtual_mode(void) {}
+static void efi_free_boot_services(void) {}
 #endif
 extern u64 efi_get_iobase (void);
 extern u32 efi_mem_type (unsigned long phys_addr);
diff --git a/init/main.c b/init/main.c
index ebb1ba5..78e5491 100644
--- a/init/main.c
+++ b/init/main.c
@@ -629,6 +629,9 @@ asmlinkage void __init start_kernel(void)
acpi_early_init(); /* before LAPIC and SMP init */
sfi_init_late();
 
+   if (efi_enabled)
+   efi_free_boot_services();
+
ftrace_init();
 
/* Do the rest non-__init'ed, we're now alive */
-- 
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/

[PATCHv3 1/4] efi: Add a stub for efi_enter_virtual_mode on non-x86

[Josh Triplett]

This eliminates an ifdef in init/main.c.

Signed-off-by: Josh Triplett 
---
 include/linux/efi.h |4 
 init/main.c |2 --
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index ec45ccd..52fbedf 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -495,7 +495,11 @@ extern void *efi_get_pal_addr (void);
 extern void efi_map_pal_code (void);
 extern void efi_memmap_walk (efi_freemem_callback_t callback, void *arg);
 extern void efi_gettimeofday (struct timespec *ts);
+#ifdef CONFIG_X86
 extern void efi_enter_virtual_mode (void); /* switch EFI to virtual mode, 
if possible */
+#else
+static void efi_enter_virtual_mode(void) {}
+#endif
 extern u64 efi_get_iobase (void);
 extern u32 efi_mem_type (unsigned long phys_addr);
 extern u64 efi_mem_attributes (unsigned long phys_addr);
diff --git a/init/main.c b/init/main.c
index b286730..ebb1ba5 100644
--- a/init/main.c
+++ b/init/main.c
@@ -602,10 +602,8 @@ asmlinkage void __init start_kernel(void)
calibrate_delay();
pidmap_init();
anon_vma_init();
-#ifdef CONFIG_X86
if (efi_enabled)
efi_enter_virtual_mode();
-#endif
thread_info_cache_init();
cred_init();
fork_init(totalram_pages);
-- 
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/

[PATCHv3 0/4] Fix ACPI BGRT support for images located in EFI boot services memory

[Josh Triplett]

The ACPI BGRT lets the OS access the BIOS logo image and its position on the
screen at boot time, allowing it to maintain that image on the screen until
ready to display something else, making boot more seamless.  This series fixes
support for accessing the boot logo image via the BGRT when the BIOS stores it
in EFI boot services memory, as recommended by the ACPI 5.0 spec.  Linux needs
to copy the image out of boot services memory before reclaiming boot services
memory.

The first patch cleans up the existing x86-specific efi_enter_virtual_mode
function to have a stub version on non-x86 platforms, to eliminate an ifdef in
init/main.c.   The second patch refactors EFI initialization to defer freeing
boot services memory until much later in the boot process, and in particular
until after we have ACPI available.  The third patch adds a helper function to
look up existing EFI boot services mappings, to avoid re-mapping them.  The
fourth patch moves BGRT initialization to before the reclamation of boot
services memory, copies the logo at that point, and reworks the existing BGRT
driver to use that existing copy.

v2: Made the new internal function efi_unmap_memmap static.  Incorporated
feedback from H. Peter Anvin and Matt Fleming: added stubs for
x86-specific EFI functions called from init/main.c to eliminate the
corresponding ifdefs in start_kernel; deferred
efi_free_boot_services even later, to just before free_initmem.

v3: Moved efi_free_boot_services back to right after EFI initialization, to
avoid a WARN from check_early_ioremap_leak about not calling
early_iounmap soon enough.

Josh Triplett (4):
  efi: Add a stub for efi_enter_virtual_mode on non-x86
  efi: Defer freeing boot services memory until after ACPI init
  efi: Add a function to look up existing IO memory mappings
  efi: Fix the ACPI BGRT driver for images located in EFI boot services
memory

 arch/x86/platform/efi/Makefile   |1 +
 arch/x86/platform/efi/efi-bgrt.c |   76 ++
 arch/x86/platform/efi/efi.c  |   65 +---
 drivers/acpi/Kconfig |4 +-
 drivers/acpi/bgrt.c  |   76 +-
 include/linux/efi-bgrt.h |   21 +++
 include/linux/efi.h  |9 +
 init/main.c  |7 +++-
 8 files changed, 175 insertions(+), 84 deletions(-)
 create mode 100644 arch/x86/platform/efi/efi-bgrt.c
 create mode 100644 include/linux/efi-bgrt.h

-- 
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: Question about failure in PCI power-state change

[Larry Finger]

On 09/08/2012 04:50 PM, Alan Stern wrote:

On Sat, 8 Sep 2012, Rafael J. Wysocki wrote:


On Saturday, September 08, 2012, Bjorn Helgaas wrote:

+cc Rafael, Huang, linux-pm

On Fri, Sep 7, 2012 at 3:44 PM, Larry Finger  wrote:

Hi,

On occasion when I unload and reload driver rtl8192ce, I get the message

"Refused to change power state, currently in D3"

I added additional info to the printk and discovered that it was trying to
change to state D0. The problem seems to occur when I have made a
connection, unloaded the driver, and reloaded it. If I do not make a
connection before unloading, then the problem is a lot less likely.

This is with kernel 3.6-rc4 from wireless-testing. A Google search shows
that the problem is usually due to suspend/resume difficulties, but this
machine has not been suspended.

I would appreciate any help that you might give in solving this issue.


I think writing "on" to the /sys/devices/.../power/control attribute of the 
device
in question would help.


Are you suggesting that this particular wireless adapter is unable to
return to D0 from D3?

Larry, what happens if you try the suspend & resume your system while
there's a connection?  Does a similar error occur during the resume?


After I sent this request, I found an error in the removal process for this 
particular adapter, which I suspect is the real source of the problem. That 
difficulty is only found on the new variant of the card - the older one is OK. I 
think the problem is that the adapter is left in some ill-defined state that can 
only be cleared by doing a power reset. In that state, it is unable to return to D0.


This box has never been able to suspend/resume, thus I cannot answer the other 
question.


Thanks to all that responded. Once I clean up the other error, I will recontact 
the list if the D3 => D0 problem persists.


Larry


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

pull request: bluetooth 2012-09-08

[Gustavo Padovan]

Hi John,

A few more fixes to 3.6, here we have four important fix to the MGMT interface,
two from Johan Hedberg and Andrzej Kaczmarek. Andrei fixed a free on
uninitialized memory and I added support for Broadcom/Foxconn devices.

Please pull, or let me know of any problems. Thanks.

Gustavo

The following changes since commit f10723841e624c0726c70356b31d91befed01dd6:

  libertas sdio: fix suspend when interface is down (2012-09-05 14:53:36 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master

for you to fetch changes up to b6f04c364ef853d8baa8949be20ef708000bcb97:

  Bluetooth: Fix freeing uninitialized delayed works (2012-09-08 17:27:52 -0300)


Andrei Emeltchenko (1):
  Bluetooth: Fix freeing uninitialized delayed works

Andrzej Kaczmarek (2):
  Bluetooth: mgmt: Fix enabling SSP while powered off
  Bluetooth: mgmt: Fix enabling LE while powered off

Gustavo Padovan (1):
  Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn

Johan Hedberg (2):
  Bluetooth: mgmt: Implement support for passkey notification
  Bluetooth: Update management interface revision

 drivers/bluetooth/btusb.c|  2 +-
 include/net/bluetooth/hci.h  | 18 
 include/net/bluetooth/hci_core.h |  5 
 include/net/bluetooth/mgmt.h |  7 +
 net/bluetooth/hci_event.c| 67 
++
 net/bluetooth/l2cap_core.c   |  2 +-
 net/bluetooth/mgmt.c | 35 +-
 7 files changed, 133 insertions(+), 3 deletions(-)



pgpEC98AyGy0C.pgp
Description: PGP signature

Re: Question about failure in PCI power-state change

[Alan Stern]

On Sat, 8 Sep 2012, Rafael J. Wysocki wrote:

> On Saturday, September 08, 2012, Bjorn Helgaas wrote:
> > +cc Rafael, Huang, linux-pm
> > 
> > On Fri, Sep 7, 2012 at 3:44 PM, Larry Finger  
> > wrote:
> > > Hi,
> > >
> > > On occasion when I unload and reload driver rtl8192ce, I get the message
> > >
> > > "Refused to change power state, currently in D3"
> > >
> > > I added additional info to the printk and discovered that it was trying to
> > > change to state D0. The problem seems to occur when I have made a
> > > connection, unloaded the driver, and reloaded it. If I do not make a
> > > connection before unloading, then the problem is a lot less likely.
> > >
> > > This is with kernel 3.6-rc4 from wireless-testing. A Google search shows
> > > that the problem is usually due to suspend/resume difficulties, but this
> > > machine has not been suspended.
> > >
> > > I would appreciate any help that you might give in solving this issue.
> 
> I think writing "on" to the /sys/devices/.../power/control attribute of the 
> device
> in question would help.

Are you suggesting that this particular wireless adapter is unable to 
return to D0 from D3?

Larry, what happens if you try the suspend & resume your system while 
there's a connection?  Does a similar error occur during the resume?

Alan Stern

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

Re: [PATCH 01/10] Makefile: Add option CONFIG_DISABLE_GCC_AUTOMATIC_INLINING

[Sam Ravnborg]

On Sat, Sep 08, 2012 at 05:47:50PM -0300, Ezequiel Garcia wrote:
> As its name suggest this option prevents gcc from auto inlining
> small functions. This is very important if one wants to obtain
> traces with accurate call sites.
> 
> Without this option, gcc will collapse some small functions,
> even when not marked as 'inline' thus making impossible to
> correlate the trace caller address to the real function it belongs.
> 
> Of course, the resultant kernel is slower and slightly smaller,
> but that's not an issue if the focus is on tracing accuracy.
> 
> Cc: Michal Marek 
> Signed-off-by: Ezequiel Garcia 
> ---
>  Makefile  |4 
>  lib/Kconfig.debug |   11 +++
>  2 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index ddf5be9..df6045a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -561,6 +561,10 @@ else
>  KBUILD_CFLAGS+= -O2
>  endif
>  
> +ifdef CONFIG_DISABLE_GCC_AUTOMATIC_INLINING
> +KBUILD_CFLAGS+= -fno-inline-small-functions
> +endif
> +
>  include $(srctree)/arch/$(SRCARCH)/Makefile
>  
>  ifdef CONFIG_READABLE_ASM
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 2403a63..c8fd50f 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1265,6 +1265,17 @@ config LATENCYTOP
>  source mm/Kconfig.debug
>  source kernel/trace/Kconfig
>  
> +config DISABLE_GCC_AUTOMATIC_INLINING
> + bool "Disable gcc automatic inlining"

Could we please call this option for:
config CC_DISABLE_AUTOMATIC_INLINING

We have at least a few other options following that naming scheme.
And today we have no options named *GCC_*

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

Re: [PATCH 10/10] drivers/bluetooth/btuart_cs.c: removes unnecessary semicolon

[Gustavo Padovan]

Hi Peter,

* Peter Senna Tschudin  [2012-09-07 17:24:48 +0200]:

> From: Peter Senna Tschudin 
> 
> removes unnecessary semicolon
> 
> Found by Coccinelle: http://coccinelle.lip6.fr/
> 
> Signed-off-by: Peter Senna Tschudin 
> 
> ---
>  drivers/bluetooth/btuart_cs.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, Thanks.

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

Re: [PATCH 5/10] drivers/bluetooth/hci_vhci.c: removes unnecessary semicolon

[Gustavo Padovan]

Hi Peter,

* Peter Senna Tschudin  [2012-09-07 17:24:47 +0200]:

> From: Peter Senna Tschudin 
> 
> removes unnecessary semicolon
> 
> Found by Coccinelle: http://coccinelle.lip6.fr/
> 
> Signed-off-by: Peter Senna Tschudin 
> 
> ---
>  drivers/bluetooth/hci_vhci.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

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

Re: [PATCH 4/10] drivers/bluetooth/hci_ll.c: removes unnecessary semicolon

[Gustavo Padovan]

Hi Peter,

* Peter Senna Tschudin  [2012-09-07 17:24:42 +0200]:

> From: Peter Senna Tschudin 
> 
> removes unnecessary semicolon
> 
> Found by Coccinelle: http://coccinelle.lip6.fr/
> 
> Signed-off-by: Peter Senna Tschudin 
> 
> ---
>  drivers/bluetooth/hci_ll.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/10] drivers/bluetooth/hci_ldisc.c: removes unnecessary semicolon

[Gustavo Padovan]

Hi Peter,

* Peter Senna Tschudin  [2012-09-07 17:24:39 +0200]:

> From: Peter Senna Tschudin 
> 
> removes unnecessary semicolon
> 
> Found by Coccinelle: http://coccinelle.lip6.fr/
> 
> Signed-off-by: Peter Senna Tschudin 

Patch has been applied to the bluetooth-next tree. Thanks.

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/10] drivers/bluetooth/bluecard_cs.c: removes unnecessary semicolon

[Gustavo Padovan]

Hi Peter,

* Peter Senna Tschudin  [2012-09-07 17:24:40 +0200]:

> From: Peter Senna Tschudin 
> 
> removes unnecessary semicolon
> 
> Found by Coccinelle: http://coccinelle.lip6.fr/
> 
> Signed-off-by: Peter Senna Tschudin 
> 
> ---
>  drivers/bluetooth/bluecard_cs.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

patch has been applied to the bluetooth-next tree. Thanks.

Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: Use local parameter pci_device_id for pci_get_subsys/class()

[Bjorn Helgaas]

On Sat, Sep 08, 2012 at 11:40:52AM -0700, Yinghai Lu wrote:
> On Sat, Sep 8, 2012 at 8:34 AM, Feng Tang  wrote:
> >> This makes lspci work again on my side. The caveat is, kzalloc() will
> >> zero out all data while the new local variable leaves some data
> >> uninitialized.
> >
> > Yes, thanks for the quick root cause and fix to the bug in my code.
> 
> Can you resubmit your patch with two extra "memset" line?

I updated the patch as follows and rebased my "next" branch to include it:

commit e664f5bd55247bba3a6ebd61f83d6c9cd87ce0de
Author: Feng Tang 
Date:   Thu Aug 23 15:45:03 2012 +0800

PCI: Use pci_device_id on stack for pci_get_subsys/class() to avoid kmalloc

This fixes a kernel warning https://lkml.org/lkml/2012/7/31/682

pci_get_subsys() may get called in late system reboot stage, using
a sleepable kmalloc() sounds fragile and will cause a kernel warning
with my recent commmit 55c844a "x86/reboot: Fix a warning message
triggered by stop_other_cpus()" which disable local interrupt in
late system shutdown/reboot phase. Using a local parameter instead
will fix it and make it eligible for calling forom atomic context.

Do the same change for the pci_get_class() as suggested by Bjorn Helgaas

[bhelgaas: changelog, clear pci_device_id on stack with memset()]
Bisected-by: Fengguang Wu 
Signed-off-by: Feng Tang 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Fengguang Wu 

diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 993d4a0..e0a0310 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -245,8 +245,7 @@ struct pci_dev *pci_get_subsys(unsigned int vendor, 
unsigned int device,
   unsigned int ss_vendor, unsigned int ss_device,
   struct pci_dev *from)
 {
-   struct pci_dev *pdev;
-   struct pci_device_id *id;
+   struct pci_device_id id;
 
/*
 * pci_find_subsys() can be called on the ide_setup() path,
@@ -257,18 +256,13 @@ struct pci_dev *pci_get_subsys(unsigned int vendor, 
unsigned int device,
if (unlikely(no_pci_devices()))
return NULL;
 
-   id = kzalloc(sizeof(*id), GFP_KERNEL);
-   if (!id)
-   return NULL;
-   id->vendor = vendor;
-   id->device = device;
-   id->subvendor = ss_vendor;
-   id->subdevice = ss_device;
-
-   pdev = pci_get_dev_by_id(id, from);
-   kfree(id);
+   memset(, 0, sizeof(id));
+   id.vendor = vendor;
+   id.device = device;
+   id.subvendor = ss_vendor;
+   id.subdevice = ss_device;
 
-   return pdev;
+   return pci_get_dev_by_id(, from);
 }
 
 /**
@@ -307,19 +301,14 @@ pci_get_device(unsigned int vendor, unsigned int device, 
struct pci_dev *from)
  */
 struct pci_dev *pci_get_class(unsigned int class, struct pci_dev *from)
 {
-   struct pci_dev *dev;
-   struct pci_device_id *id;
+   struct pci_device_id id;
 
-   id = kzalloc(sizeof(*id), GFP_KERNEL);
-   if (!id)
-   return NULL;
-   id->vendor = id->device = id->subvendor = id->subdevice = PCI_ANY_ID;
-   id->class_mask = PCI_ANY_ID;
-   id->class = class;
+   memset(, 0, sizeof(id));
+   id.vendor = id.device = id.subvendor = id.subdevice = PCI_ANY_ID;
+   id.class_mask = PCI_ANY_ID;
+   id.class = class;
 
-   dev = pci_get_dev_by_id(id, from);
-   kfree(id);
-   return dev;
+   return pci_get_dev_by_id(, from);
 }
 
 /**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/10] mm, slub: Rename slab_alloc() -> slab_alloc_node() to match SLAB

[Ezequiel Garcia]

This patch does not fix anything, and its only goal is to enable us
to obtain some common code between SLAB and SLUB.
Neither behavior nor produced code is affected.

Cc: Christoph Lameter 
Signed-off-by: Ezequiel Garcia 
---
 mm/slub.c |   24 +++-
 1 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index c67bd0a..786a181 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2311,7 +2311,7 @@ new_slab:
  *
  * Otherwise we can simply pick the next object from the lockless free list.
  */
-static __always_inline void *slab_alloc(struct kmem_cache *s,
+static __always_inline void *slab_alloc_node(struct kmem_cache *s,
gfp_t gfpflags, int node, unsigned long addr)
 {
void **object;
@@ -2381,9 +2381,15 @@ redo:
return object;
 }
 
+static __always_inline void *slab_alloc(struct kmem_cache *s,
+   gfp_t gfpflags, unsigned long addr)
+{
+   return slab_alloc_node(s, gfpflags, NUMA_NO_NODE, addr);
+}
+
 void *kmem_cache_alloc(struct kmem_cache *s, gfp_t gfpflags)
 {
-   void *ret = slab_alloc(s, gfpflags, NUMA_NO_NODE, _RET_IP_);
+   void *ret = slab_alloc(s, gfpflags, _RET_IP_);
 
trace_kmem_cache_alloc(_RET_IP_, ret, s->object_size, s->size, 
gfpflags);
 
@@ -2394,7 +2400,7 @@ EXPORT_SYMBOL(kmem_cache_alloc);
 #ifdef CONFIG_TRACING
 void *kmem_cache_alloc_trace(struct kmem_cache *s, gfp_t gfpflags, size_t size)
 {
-   void *ret = slab_alloc(s, gfpflags, NUMA_NO_NODE, _RET_IP_);
+   void *ret = slab_alloc(s, gfpflags, _RET_IP_);
trace_kmalloc(_RET_IP_, ret, size, s->size, gfpflags);
return ret;
 }
@@ -2412,7 +2418,7 @@ EXPORT_SYMBOL(kmalloc_order_trace);
 #ifdef CONFIG_NUMA
 void *kmem_cache_alloc_node(struct kmem_cache *s, gfp_t gfpflags, int node)
 {
-   void *ret = slab_alloc(s, gfpflags, node, _RET_IP_);
+   void *ret = slab_alloc_node(s, gfpflags, node, _RET_IP_);
 
trace_kmem_cache_alloc_node(_RET_IP_, ret,
s->object_size, s->size, gfpflags, node);
@@ -2426,7 +2432,7 @@ void *kmem_cache_alloc_node_trace(struct kmem_cache *s,
gfp_t gfpflags,
int node, size_t size)
 {
-   void *ret = slab_alloc(s, gfpflags, node, _RET_IP_);
+   void *ret = slab_alloc_node(s, gfpflags, node, _RET_IP_);
 
trace_kmalloc_node(_RET_IP_, ret,
   size, s->size, gfpflags, node);
@@ -3364,7 +3370,7 @@ void *__kmalloc(size_t size, gfp_t flags)
if (unlikely(ZERO_OR_NULL_PTR(s)))
return s;
 
-   ret = slab_alloc(s, flags, NUMA_NO_NODE, _RET_IP_);
+   ret = slab_alloc(s, flags, _RET_IP_);
 
trace_kmalloc(_RET_IP_, ret, size, s->size, flags);
 
@@ -3407,7 +3413,7 @@ void *__kmalloc_node(size_t size, gfp_t flags, int node)
if (unlikely(ZERO_OR_NULL_PTR(s)))
return s;
 
-   ret = slab_alloc(s, flags, node, _RET_IP_);
+   ret = slab_alloc_node(s, flags, node, _RET_IP_);
 
trace_kmalloc_node(_RET_IP_, ret, size, s->size, flags, node);
 
@@ -4035,7 +4041,7 @@ void *__kmalloc_track_caller(size_t size, gfp_t gfpflags, 
unsigned long caller)
if (unlikely(ZERO_OR_NULL_PTR(s)))
return s;
 
-   ret = slab_alloc(s, gfpflags, NUMA_NO_NODE, caller);
+   ret = slab_alloc(s, gfpflags, caller);
 
/* Honor the call site pointer we received. */
trace_kmalloc(caller, ret, size, s->size, gfpflags);
@@ -4065,7 +4071,7 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t 
gfpflags,
if (unlikely(ZERO_OR_NULL_PTR(s)))
return s;
 
-   ret = slab_alloc(s, gfpflags, node, caller);
+   ret = slab_alloc_node(s, gfpflags, node, caller);
 
/* Honor the call site pointer we received. */
trace_kmalloc_node(caller, ret, size, s->size, gfpflags, node);
-- 
1.7.8.6

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

[PATCH 01/10] Makefile: Add option CONFIG_DISABLE_GCC_AUTOMATIC_INLINING

[Ezequiel Garcia]

As its name suggest this option prevents gcc from auto inlining
small functions. This is very important if one wants to obtain
traces with accurate call sites.

Without this option, gcc will collapse some small functions,
even when not marked as 'inline' thus making impossible to
correlate the trace caller address to the real function it belongs.

Of course, the resultant kernel is slower and slightly smaller,
but that's not an issue if the focus is on tracing accuracy.

Cc: Michal Marek 
Signed-off-by: Ezequiel Garcia 
---
 Makefile  |4 
 lib/Kconfig.debug |   11 +++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index ddf5be9..df6045a 100644
--- a/Makefile
+++ b/Makefile
@@ -561,6 +561,10 @@ else
 KBUILD_CFLAGS  += -O2
 endif
 
+ifdef CONFIG_DISABLE_GCC_AUTOMATIC_INLINING
+KBUILD_CFLAGS  += -fno-inline-small-functions
+endif
+
 include $(srctree)/arch/$(SRCARCH)/Makefile
 
 ifdef CONFIG_READABLE_ASM
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2403a63..c8fd50f 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1265,6 +1265,17 @@ config LATENCYTOP
 source mm/Kconfig.debug
 source kernel/trace/Kconfig
 
+config DISABLE_GCC_AUTOMATIC_INLINING
+   bool "Disable gcc automatic inlining"
+   depends on TRACING
+   help
+ This option tells gcc he's not allowed to inline functions 
automatically,
+ when they are not marked as 'inline'.
+ In turn, this enables to trace an event with an accurate call site.
+ Of course, the resultant kernel is slower and slightly smaller.
+
+ Select this option only if you want to trace call sites accurately.
+
 config PROVIDE_OHCI1394_DMA_INIT
bool "Remote debugging over FireWire early on boot"
depends on PCI && X86
-- 
1.7.8.6

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

[PATCH 04/10] mm, slob: Add support for kmalloc_track_caller()

[Ezequiel Garcia]

Currently slob falls back to regular kmalloc for this case.
With this patch kmalloc_track_caller() is correctly implemented,
thus tracing the specified caller.

This is important to trace accurately allocations performed by
krealloc, kstrdup, kmemdup, etc.

Cc: Pekka Enberg 
Signed-off-by: Ezequiel Garcia 
---
 include/linux/slab.h |6 --
 mm/slob.c|   27 ---
 2 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/include/linux/slab.h b/include/linux/slab.h
index 0dd2dfa..83d1a14 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -321,7 +321,8 @@ static inline void *kmem_cache_alloc_node(struct kmem_cache 
*cachep,
  * request comes from.
  */
 #if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB) || \
-   (defined(CONFIG_SLAB) && defined(CONFIG_TRACING))
+   (defined(CONFIG_SLAB) && defined(CONFIG_TRACING)) || \
+   (defined(CONFIG_SLOB) && defined(CONFIG_TRACING))
 extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long);
 #define kmalloc_track_caller(size, flags) \
__kmalloc_track_caller(size, flags, _RET_IP_)
@@ -340,7 +341,8 @@ extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned 
long);
  * allocation request comes from.
  */
 #if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB) || \
-   (defined(CONFIG_SLAB) && defined(CONFIG_TRACING))
+   (defined(CONFIG_SLAB) && defined(CONFIG_TRACING)) || \
+   (defined(CONFIG_SLOB) && defined(CONFIG_TRACING))
 extern void *__kmalloc_node_track_caller(size_t, gfp_t, int, unsigned long);
 #define kmalloc_node_track_caller(size, flags, node) \
__kmalloc_node_track_caller(size, flags, node, \
diff --git a/mm/slob.c b/mm/slob.c
index c0c1a93..984c42a 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -424,7 +424,8 @@ out:
  * End of slob allocator proper. Begin kmem_cache_alloc and kmalloc frontend.
  */
 
-void *__kmalloc_node(size_t size, gfp_t gfp, int node)
+static __always_inline void *
+__do_kmalloc_node(size_t size, gfp_t gfp, int node, unsigned long caller)
 {
unsigned int *m;
int align = max(ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
@@ -445,7 +446,7 @@ void *__kmalloc_node(size_t size, gfp_t gfp, int node)
*m = size;
ret = (void *)m + align;
 
-   trace_kmalloc_node(_RET_IP_, ret,
+   trace_kmalloc_node(caller, ret,
   size, size + align, gfp, node);
} else {
unsigned int order = get_order(size);
@@ -454,15 +455,35 @@ void *__kmalloc_node(size_t size, gfp_t gfp, int node)
gfp |= __GFP_COMP;
ret = slob_new_pages(gfp, order, node);
 
-   trace_kmalloc_node(_RET_IP_, ret,
+   trace_kmalloc_node(caller, ret,
   size, PAGE_SIZE << order, gfp, node);
}
 
kmemleak_alloc(ret, size, 1, gfp);
return ret;
 }
+
+void *__kmalloc_node(size_t size, gfp_t gfp, int node)
+{
+   return __do_kmalloc_node(size, gfp, node, _RET_IP_);
+}
 EXPORT_SYMBOL(__kmalloc_node);
 
+#ifdef CONFIG_TRACING
+void *__kmalloc_track_caller(size_t size, gfp_t gfp, unsigned long caller)
+{
+   return __do_kmalloc_node(size, gfp, NUMA_NO_NODE, caller);
+}
+
+#ifdef CONFIG_NUMA
+void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags,
+   int node, unsigned long caller)
+{
+   return __do_kmalloc_node(size, gfp, node, caller);
+}
+#endif
+#endif
+
 void kfree(const void *block)
 {
struct page *sp;
-- 
1.7.8.6

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

[PATCH 07/10] mm, slab: Match SLAB and SLUB kmem_cache_alloc_xxx_trace() prototype

[Ezequiel Garcia]

This long (seemingly unnecessary) patch does not fix anything and
its only goal is to produce common code between SLAB and SLUB.

Cc: Pekka Enberg 
Cc: Christoph Lameter 
Signed-off-by: Ezequiel Garcia 
---
 include/linux/slab_def.h |7 +++
 mm/slab.c|   10 +-
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
index 604ebc8..e98caeb 100644
--- a/include/linux/slab_def.h
+++ b/include/linux/slab_def.h
@@ -111,11 +111,10 @@ void *kmem_cache_alloc(struct kmem_cache *, gfp_t);
 void *__kmalloc(size_t size, gfp_t flags);
 
 #ifdef CONFIG_TRACING
-extern void *kmem_cache_alloc_trace(size_t size,
-   struct kmem_cache *cachep, gfp_t flags);
+extern void *kmem_cache_alloc_trace(struct kmem_cache *, gfp_t, size_t);
 #else
 static __always_inline void *
-kmem_cache_alloc_trace(size_t size, struct kmem_cache *cachep, gfp_t flags)
+kmem_cache_alloc_trace(struct kmem_cache *cachep, gfp_t flags, size_t size)
 {
return kmem_cache_alloc(cachep, flags);
 }
@@ -148,7 +147,7 @@ found:
 #endif
cachep = malloc_sizes[i].cs_cachep;
 
-   ret = kmem_cache_alloc_trace(size, cachep, flags);
+   ret = kmem_cache_alloc_trace(cachep, flags, size);
 
return ret;
}
diff --git a/mm/slab.c b/mm/slab.c
index bc342d1..47cb03c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3834,7 +3834,7 @@ EXPORT_SYMBOL(kmem_cache_alloc);
 
 #ifdef CONFIG_TRACING
 void *
-kmem_cache_alloc_trace(size_t size, struct kmem_cache *cachep, gfp_t flags)
+kmem_cache_alloc_trace(struct kmem_cache *cachep, gfp_t flags, size_t size)
 {
void *ret;
 
@@ -3861,10 +3861,10 @@ void *kmem_cache_alloc_node(struct kmem_cache *cachep, 
gfp_t flags, int nodeid)
 EXPORT_SYMBOL(kmem_cache_alloc_node);
 
 #ifdef CONFIG_TRACING
-void *kmem_cache_alloc_node_trace(size_t size,
- struct kmem_cache *cachep,
+void *kmem_cache_alloc_node_trace(struct kmem_cache *cachep,
  gfp_t flags,
- int nodeid)
+ int nodeid,
+ size_t size)
 {
void *ret;
 
@@ -3886,7 +3886,7 @@ __do_kmalloc_node(size_t size, gfp_t flags, int node, 
unsigned long caller)
cachep = kmem_find_general_cachep(size, flags);
if (unlikely(ZERO_OR_NULL_PTR(cachep)))
return cachep;
-   return kmem_cache_alloc_node_trace(size, cachep, flags, node);
+   return kmem_cache_alloc_node_trace(cachep, flags, node, size);
 }
 
 #if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_TRACING)
-- 
1.7.8.6

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

[PATCH 10/10] mm: Factor SLAB and SLUB common code

[Ezequiel Garcia]

Several interfaces are now exactly the same in both SLAB and SLUB,
and it's very easy to factor them out.
To make this work slab_alloc() and slab_alloc_node() are made non-static.

This has the benefit of putting most of the tracing code in mm/slab_common.c,
making it harder to produce inconsistent trace behavior.

Cc: Pekka Enberg 
Cc: Christoph Lameter 
Signed-off-by: Ezequiel Garcia 
---
 include/linux/slab_def.h |2 +
 include/linux/slub_def.h |2 +
 mm/slab.c|   68 +
 mm/slab_common.c |   57 ++
 mm/slub.c|   49 +---
 5 files changed, 65 insertions(+), 113 deletions(-)

diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
index e98caeb..021c162 100644
--- a/include/linux/slab_def.h
+++ b/include/linux/slab_def.h
@@ -107,6 +107,8 @@ struct cache_sizes {
 };
 extern struct cache_sizes malloc_sizes[];
 
+void *slab_alloc(struct kmem_cache *, gfp_t, unsigned long);
+void *slab_alloc_node(struct kmem_cache *, gfp_t, int, unsigned long);
 void *kmem_cache_alloc(struct kmem_cache *, gfp_t);
 void *__kmalloc(size_t size, gfp_t flags);
 
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index df448ad..d94f457 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -216,6 +216,8 @@ static __always_inline struct kmem_cache 
*kmalloc_slab(size_t size)
return kmalloc_caches[index];
 }
 
+void *slab_alloc(struct kmem_cache *, gfp_t, unsigned long);
+void *slab_alloc_node(struct kmem_cache *, gfp_t, int, unsigned long);
 void *kmem_cache_alloc(struct kmem_cache *, gfp_t);
 void *__kmalloc(size_t size, gfp_t flags);
 
diff --git a/mm/slab.c b/mm/slab.c
index 57094ee..d7f8466 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3559,7 +3559,7 @@ done:
  *
  * Fallback to other node is possible if __GFP_THISNODE is not set.
  */
-static __always_inline void *
+__always_inline void *
 slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid,
   unsigned long caller)
 {
@@ -3646,7 +3646,7 @@ __do_cache_alloc(struct kmem_cache *cachep, gfp_t flags)
 
 #endif /* CONFIG_NUMA */
 
-static __always_inline void *
+__always_inline void *
 slab_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long caller)
 {
unsigned long save_flags;
@@ -3813,71 +3813,7 @@ static inline void __cache_free(struct kmem_cache 
*cachep, void *objp,
ac_put_obj(cachep, ac, objp);
 }
 
-/**
- * kmem_cache_alloc - Allocate an object
- * @cachep: The cache to allocate from.
- * @flags: See kmalloc().
- *
- * Allocate an object from this cache.  The flags are only relevant
- * if the cache has no available objects.
- */
-void *kmem_cache_alloc(struct kmem_cache *cachep, gfp_t flags)
-{
-   void *ret = slab_alloc(cachep, flags, _RET_IP_);
-
-   trace_kmem_cache_alloc(_RET_IP_, ret,
-  cachep->object_size, cachep->size, flags);
-
-   return ret;
-}
-EXPORT_SYMBOL(kmem_cache_alloc);
-
-#ifdef CONFIG_TRACING
-void *
-kmem_cache_alloc_trace(struct kmem_cache *cachep, gfp_t flags, size_t size)
-{
-   void *ret;
-
-   ret = slab_alloc(cachep, flags, _RET_IP_);
-
-   trace_kmalloc(_RET_IP_, ret,
- size, cachep->size, flags);
-   return ret;
-}
-EXPORT_SYMBOL(kmem_cache_alloc_trace);
-#endif
-
 #ifdef CONFIG_NUMA
-void *kmem_cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid)
-{
-   void *ret = slab_alloc_node(cachep, flags, nodeid, _RET_IP_);
-
-   trace_kmem_cache_alloc_node(_RET_IP_, ret,
-   cachep->object_size, cachep->size,
-   flags, nodeid);
-
-   return ret;
-}
-EXPORT_SYMBOL(kmem_cache_alloc_node);
-
-#ifdef CONFIG_TRACING
-void *kmem_cache_alloc_node_trace(struct kmem_cache *cachep,
- gfp_t flags,
- int nodeid,
- size_t size)
-{
-   void *ret;
-
-   ret = slab_alloc_node(cachep, flags, nodeid, _RET_IP);
-
-   trace_kmalloc_node(_RET_IP_, ret,
-  size, cachep->size,
-  flags, nodeid);
-   return ret;
-}
-EXPORT_SYMBOL(kmem_cache_alloc_node_trace);
-#endif
-
 static __always_inline void *
 __do_kmalloc_node(size_t size, gfp_t flags, int node, unsigned long caller)
 {
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 8cf8b49..5fc0da0 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 
+#include 
 #include "slab.h"
 
 enum slab_state slab_state;
@@ -113,6 +114,62 @@ struct kmem_cache *kmem_cache_create(const char *name, 
size_t size, size_t align
 }
 EXPORT_SYMBOL(kmem_cache_create);
 
+#if defined(CONFIG_SLAB) || defined(CONFIG_SLUB)
+/**
+ * kmem_cache_alloc - Allocate an object
+ * @cachep: The cache to allocate from.
+ * @flags: See kmalloc().
+ 

[PATCH 08/10] mm, slab: Rename __cache_alloc() -> slab_alloc()

[Ezequiel Garcia]

This patch does not fix anything and its only goal is to
produce common code between SLAB and SLUB.

Cc: Pekka Enberg 
Cc: Christoph Lameter 
Signed-off-by: Ezequiel Garcia 
---
 mm/slab.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 47cb03c..57094ee 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3560,7 +3560,7 @@ done:
  * Fallback to other node is possible if __GFP_THISNODE is not set.
  */
 static __always_inline void *
-__cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid,
+slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid,
   unsigned long caller)
 {
unsigned long save_flags;
@@ -3647,7 +3647,7 @@ __do_cache_alloc(struct kmem_cache *cachep, gfp_t flags)
 #endif /* CONFIG_NUMA */
 
 static __always_inline void *
-__cache_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long caller)
+slab_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long caller)
 {
unsigned long save_flags;
void *objp;
@@ -3823,7 +3823,7 @@ static inline void __cache_free(struct kmem_cache 
*cachep, void *objp,
  */
 void *kmem_cache_alloc(struct kmem_cache *cachep, gfp_t flags)
 {
-   void *ret = __cache_alloc(cachep, flags, _RET_IP_);
+   void *ret = slab_alloc(cachep, flags, _RET_IP_);
 
trace_kmem_cache_alloc(_RET_IP_, ret,
   cachep->object_size, cachep->size, flags);
@@ -3838,7 +3838,7 @@ kmem_cache_alloc_trace(struct kmem_cache *cachep, gfp_t 
flags, size_t size)
 {
void *ret;
 
-   ret = __cache_alloc(cachep, flags, _RET_IP_);
+   ret = slab_alloc(cachep, flags, _RET_IP_);
 
trace_kmalloc(_RET_IP_, ret,
  size, cachep->size, flags);
@@ -3850,7 +3850,7 @@ EXPORT_SYMBOL(kmem_cache_alloc_trace);
 #ifdef CONFIG_NUMA
 void *kmem_cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid)
 {
-   void *ret = __cache_alloc_node(cachep, flags, nodeid, _RET_IP_);
+   void *ret = slab_alloc_node(cachep, flags, nodeid, _RET_IP_);
 
trace_kmem_cache_alloc_node(_RET_IP_, ret,
cachep->object_size, cachep->size,
@@ -3868,7 +3868,7 @@ void *kmem_cache_alloc_node_trace(struct kmem_cache 
*cachep,
 {
void *ret;
 
-   ret = __cache_alloc_node(cachep, flags, nodeid, _RET_IP);
+   ret = slab_alloc_node(cachep, flags, nodeid, _RET_IP);
 
trace_kmalloc_node(_RET_IP_, ret,
   size, cachep->size,
@@ -3931,7 +3931,7 @@ static __always_inline void *__do_kmalloc(size_t size, 
gfp_t flags,
cachep = __find_general_cachep(size, flags);
if (unlikely(ZERO_OR_NULL_PTR(cachep)))
return cachep;
-   ret = __cache_alloc(cachep, flags, caller);
+   ret = slab_alloc(cachep, flags, caller);
 
trace_kmalloc(caller, ret,
  size, cachep->size, flags);
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/10] mm, slab: Replace 'caller' type, void* -> unsigned long

[Ezequiel Garcia]

This allows to use _RET_IP_ instead of builtin_address(0), thus
achiveing implementation consistency in all three allocators.
Though maybe a nitpick, the real goal behind this patch is
to be able to obtain common code between SLAB and SLUB.

Cc: Pekka Enberg 
Signed-off-by: Ezequiel Garcia 
---
 mm/slab.c |   50 --
 1 files changed, 24 insertions(+), 26 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 53e41de..bc342d1 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3083,7 +3083,7 @@ static inline void verify_redzone_free(struct kmem_cache 
*cache, void *obj)
 }
 
 static void *cache_free_debugcheck(struct kmem_cache *cachep, void *objp,
-  void *caller)
+  unsigned long caller)
 {
struct page *page;
unsigned int objnr;
@@ -3103,7 +3103,7 @@ static void *cache_free_debugcheck(struct kmem_cache 
*cachep, void *objp,
*dbg_redzone2(cachep, objp) = RED_INACTIVE;
}
if (cachep->flags & SLAB_STORE_USER)
-   *dbg_userword(cachep, objp) = caller;
+   *dbg_userword(cachep, objp) = (void *)caller;
 
objnr = obj_to_index(cachep, slabp, objp);
 
@@ -3116,7 +3116,7 @@ static void *cache_free_debugcheck(struct kmem_cache 
*cachep, void *objp,
if (cachep->flags & SLAB_POISON) {
 #ifdef CONFIG_DEBUG_PAGEALLOC
if ((cachep->size % PAGE_SIZE)==0 && OFF_SLAB(cachep)) {
-   store_stackinfo(cachep, objp, (unsigned long)caller);
+   store_stackinfo(cachep, objp, caller);
kernel_map_pages(virt_to_page(objp),
 cachep->size / PAGE_SIZE, 0);
} else {
@@ -3269,7 +3269,7 @@ static inline void cache_alloc_debugcheck_before(struct 
kmem_cache *cachep,
 
 #if DEBUG
 static void *cache_alloc_debugcheck_after(struct kmem_cache *cachep,
-   gfp_t flags, void *objp, void *caller)
+   gfp_t flags, void *objp, unsigned long caller)
 {
if (!objp)
return objp;
@@ -3286,7 +3286,7 @@ static void *cache_alloc_debugcheck_after(struct 
kmem_cache *cachep,
poison_obj(cachep, objp, POISON_INUSE);
}
if (cachep->flags & SLAB_STORE_USER)
-   *dbg_userword(cachep, objp) = caller;
+   *dbg_userword(cachep, objp) = (void *)caller;
 
if (cachep->flags & SLAB_RED_ZONE) {
if (*dbg_redzone1(cachep, objp) != RED_INACTIVE ||
@@ -3561,7 +3561,7 @@ done:
  */
 static __always_inline void *
 __cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid,
-  void *caller)
+  unsigned long caller)
 {
unsigned long save_flags;
void *ptr;
@@ -3647,7 +3647,7 @@ __do_cache_alloc(struct kmem_cache *cachep, gfp_t flags)
 #endif /* CONFIG_NUMA */
 
 static __always_inline void *
-__cache_alloc(struct kmem_cache *cachep, gfp_t flags, void *caller)
+__cache_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long caller)
 {
unsigned long save_flags;
void *objp;
@@ -3783,7 +3783,7 @@ free_done:
  * be in this state _before_ it is released.  Called with disabled ints.
  */
 static inline void __cache_free(struct kmem_cache *cachep, void *objp,
-void *caller)
+   unsigned long caller)
 {
struct array_cache *ac = cpu_cache_get(cachep);
 
@@ -3823,7 +3823,7 @@ static inline void __cache_free(struct kmem_cache 
*cachep, void *objp,
  */
 void *kmem_cache_alloc(struct kmem_cache *cachep, gfp_t flags)
 {
-   void *ret = __cache_alloc(cachep, flags, __builtin_return_address(0));
+   void *ret = __cache_alloc(cachep, flags, _RET_IP_);
 
trace_kmem_cache_alloc(_RET_IP_, ret,
   cachep->object_size, cachep->size, flags);
@@ -3838,7 +3838,7 @@ kmem_cache_alloc_trace(size_t size, struct kmem_cache 
*cachep, gfp_t flags)
 {
void *ret;
 
-   ret = __cache_alloc(cachep, flags, __builtin_return_address(0));
+   ret = __cache_alloc(cachep, flags, _RET_IP_);
 
trace_kmalloc(_RET_IP_, ret,
  size, cachep->size, flags);
@@ -3850,8 +3850,7 @@ EXPORT_SYMBOL(kmem_cache_alloc_trace);
 #ifdef CONFIG_NUMA
 void *kmem_cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid)
 {
-   void *ret = __cache_alloc_node(cachep, flags, nodeid,
-  __builtin_return_address(0));
+   void *ret = __cache_alloc_node(cachep, flags, nodeid, _RET_IP_);
 
trace_kmem_cache_alloc_node(_RET_IP_, ret,
cachep->object_size, cachep->size,
@@ -3869,8 +3868,8 @@ void *kmem_cache_alloc_node_trace(size_t size,
 {
void *ret;
 
-   ret = __cache_alloc_node(cachep, flags, nodeid,
- __builtin_return_address(0));
+  

[PATCH 03/10] mm, slab: Remove silly function slab_buffer_size()

[Ezequiel Garcia]

This function is seldom used, and can be simply replaced with cachep->size.

Cc: Pekka Enberg 
Signed-off-by: Ezequiel Garcia 
---
 include/linux/slab_def.h |5 -
 mm/slab.c|   12 ++--
 2 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
index 36d7031..604ebc8 100644
--- a/include/linux/slab_def.h
+++ b/include/linux/slab_def.h
@@ -113,17 +113,12 @@ void *__kmalloc(size_t size, gfp_t flags);
 #ifdef CONFIG_TRACING
 extern void *kmem_cache_alloc_trace(size_t size,
struct kmem_cache *cachep, gfp_t flags);
-extern size_t slab_buffer_size(struct kmem_cache *cachep);
 #else
 static __always_inline void *
 kmem_cache_alloc_trace(size_t size, struct kmem_cache *cachep, gfp_t flags)
 {
return kmem_cache_alloc(cachep, flags);
 }
-static inline size_t slab_buffer_size(struct kmem_cache *cachep)
-{
-   return 0;
-}
 #endif
 
 static __always_inline void *kmalloc(size_t size, gfp_t flags)
diff --git a/mm/slab.c b/mm/slab.c
index 3b4587b..53e41de 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -498,14 +498,6 @@ static void **dbg_userword(struct kmem_cache *cachep, void 
*objp)
 
 #endif
 
-#ifdef CONFIG_TRACING
-size_t slab_buffer_size(struct kmem_cache *cachep)
-{
-   return cachep->size;
-}
-EXPORT_SYMBOL(slab_buffer_size);
-#endif
-
 /*
  * Do not go above this order unless 0 objects fit into the slab or
  * overridden on the command line.
@@ -3849,7 +3841,7 @@ kmem_cache_alloc_trace(size_t size, struct kmem_cache 
*cachep, gfp_t flags)
ret = __cache_alloc(cachep, flags, __builtin_return_address(0));
 
trace_kmalloc(_RET_IP_, ret,
- size, slab_buffer_size(cachep), flags);
+ size, cachep->size, flags);
return ret;
 }
 EXPORT_SYMBOL(kmem_cache_alloc_trace);
@@ -3880,7 +3872,7 @@ void *kmem_cache_alloc_node_trace(size_t size,
ret = __cache_alloc_node(cachep, flags, nodeid,
  __builtin_return_address(0));
trace_kmalloc_node(_RET_IP_, ret,
-  size, slab_buffer_size(cachep),
+  size, cachep->size,
   flags, nodeid);
return ret;
 }
-- 
1.7.8.6

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

[PATCH 05/10] mm, util: Use dup_user to duplicate user memory

[Ezequiel Garcia]

Previously the strndup_user allocation was being done through memdup_user,
and the caller was wrongly traced as being strndup_user
(the correct trace must report the caller of strndup_user).

This is a common problem: in order to get accurate callsite tracing,
a utils function can't allocate through another utils function,
but instead do the allocation himself (or inlined).

Here we fix this by creating an always inlined dup_user() function to
performed the real allocation and to be used by memdup_user and strndup_user.

Cc: Pekka Enberg 
Signed-off-by: Ezequiel Garcia 
---
 mm/util.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/mm/util.c b/mm/util.c
index dc3036c..48d3ff8b 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -76,14 +76,14 @@ void *kmemdup(const void *src, size_t len, gfp_t gfp)
 EXPORT_SYMBOL(kmemdup);
 
 /**
- * memdup_user - duplicate memory region from user space
+ * dup_user - duplicate memory region from user space
  *
  * @src: source address in user space
  * @len: number of bytes to copy
  *
  * Returns an ERR_PTR() on failure.
  */
-void *memdup_user(const void __user *src, size_t len)
+static __always_inline void *dup_user(const void __user *src, size_t len)
 {
void *p;
 
@@ -103,6 +103,11 @@ void *memdup_user(const void __user *src, size_t len)
 
return p;
 }
+
+void *memdup_user(const void __user *src, size_t len)
+{
+   return dup_user(src, len);
+}
 EXPORT_SYMBOL(memdup_user);
 
 static __always_inline void *__do_krealloc(const void *p, size_t new_size,
@@ -214,7 +219,7 @@ char *strndup_user(const char __user *s, long n)
if (length > n)
return ERR_PTR(-EINVAL);
 
-   p = memdup_user(s, length);
+   p = dup_user(s, length);
 
if (IS_ERR(p))
return p;
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/10] mm, slob: Use NUMA_NO_NODE instead of -1

[Ezequiel Garcia]

Cc: Pekka Enberg 
Signed-off-by: Ezequiel Garcia 
---
 include/linux/slob_def.h |6 --
 mm/slob.c|6 +++---
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/linux/slob_def.h b/include/linux/slob_def.h
index 0ec00b3..f28e14a 100644
--- a/include/linux/slob_def.h
+++ b/include/linux/slob_def.h
@@ -1,12 +1,14 @@
 #ifndef __LINUX_SLOB_DEF_H
 #define __LINUX_SLOB_DEF_H
 
+#include 
+
 void *kmem_cache_alloc_node(struct kmem_cache *, gfp_t flags, int node);
 
 static __always_inline void *kmem_cache_alloc(struct kmem_cache *cachep,
  gfp_t flags)
 {
-   return kmem_cache_alloc_node(cachep, flags, -1);
+   return kmem_cache_alloc_node(cachep, flags, NUMA_NO_NODE);
 }
 
 void *__kmalloc_node(size_t size, gfp_t flags, int node);
@@ -26,7 +28,7 @@ static __always_inline void *kmalloc_node(size_t size, gfp_t 
flags, int node)
  */
 static __always_inline void *kmalloc(size_t size, gfp_t flags)
 {
-   return __kmalloc_node(size, flags, -1);
+   return __kmalloc_node(size, flags, NUMA_NO_NODE);
 }
 
 static __always_inline void *__kmalloc(size_t size, gfp_t flags)
diff --git a/mm/slob.c b/mm/slob.c
index ae46edc..c0c1a93 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -193,7 +193,7 @@ static void *slob_new_pages(gfp_t gfp, int order, int node)
void *page;
 
 #ifdef CONFIG_NUMA
-   if (node != -1)
+   if (node != NUMA_NO_NODE)
page = alloc_pages_exact_node(node, gfp, order);
else
 #endif
@@ -289,7 +289,7 @@ static void *slob_alloc(size_t size, gfp_t gfp, int align, 
int node)
 * If there's a node specification, search for a partial
 * page with a matching node id in the freelist.
 */
-   if (node != -1 && page_to_nid(sp) != node)
+   if (node != NUMA_NO_NODE && page_to_nid(sp) != node)
continue;
 #endif
/* Enough room on this page? */
@@ -510,7 +510,7 @@ struct kmem_cache *__kmem_cache_create(const char *name, 
size_t size,
struct kmem_cache *c;
 
c = slob_alloc(sizeof(struct kmem_cache),
-   GFP_KERNEL, ARCH_KMALLOC_MINALIGN, -1);
+   GFP_KERNEL, ARCH_KMALLOC_MINALIGN, NUMA_NO_NODE);
 
if (c) {
c->name = name;
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/10] mm: SLxB cleaning and trace accuracy improvement

[Ezequiel Garcia]

Hi everyone,

This is the second spin of my patchset to clean SLxB and improve kmem
trace events accuracy.

For this v2, the most relevant stuff is:

I've dropped two patches that were not very well received:
Namely this two are now gone:
  mm, slob: Use only 'ret' variable for both slob object and returned pointer
  mm, slob: Trace allocation failures consistently
I believe consistency is important but perhaps this is just me being paranoid.

There's a lot of dumb movement and renaming. This might seem stupid
(and maybe it is) but it's necessary to create some common code between SLAB
and SLUB, and then factor it out.

Also, there's a patch to add a new option to disable gcc auto-inlining.
I know we hate to add new options, but this is necessary to get
accurate call site
traces. Plus, the option is in "Kernel Hacking", so it's for kernel
developers only.

This work is part of CELF Workgroup Project:
"Kernel_dynamic_memory_allocation_tracking_and_reduction" [1]

Feedback, comments, suggestions are very welcome.

Ezequiel Garcia (10):
 mm: Factor SLAB and SLUB common code
 mm, slub: Rename slab_alloc() -> slab_alloc_node() to match SLAB
 mm, slab: Rename __cache_alloc() -> slab_alloc()
 mm, slab: Match SLAB and SLUB kmem_cache_alloc_xxx_trace() prototype
 mm, slab: Replace 'caller' type, void* -> unsigned long
 mm, util: Use dup_user to duplicate user memory
 mm, slob: Add support for kmalloc_track_caller()
 mm, slab: Remove silly function slab_buffer_size()
 mm, slob: Use NUMA_NO_NODE instead of -1
 Makefile: Add option CONFIG_DISABLE_GCC_AUTOMATIC_INLINING

 Makefile |4 ++
 include/linux/slab.h |6 ++-
 include/linux/slab_def.h |   14 ++---
 include/linux/slob_def.h |6 ++-
 include/linux/slub_def.h |2 +
 lib/Kconfig.debug|   11 
 mm/slab.c|  122 +-
 mm/slab_common.c |   57 +
 mm/slob.c|   33 ++--
 mm/slub.c|   55 +++--
 mm/util.c|   11 +++-
 11 files changed, 154 insertions(+), 167 deletions(-)

Thanks!
Ezequiel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM QoS: Add a metric : Bus Throughput.

[Rafael J. Wysocki]

On Friday, August 10, 2012, 함명주 wrote:
> > + Myungjoo Ham,
> > 
> > It used at devfreq. Mr. Ham can you explain it in detail?
> > 
> > Thank you,
> > Kyungmin Park
> > ,
> > On 8/9/12, Rafael J. Wysocki  wrote:
> > > On Wednesday, August 08, 2012, Jonghwa Lee wrote:
> > >> Bus throughput metric is added to PM QoS in order to control the
> > >> frequency of memory interfaces and busses with PM QoS.
> > >>
> > >> Signed-off-by: Jonghwa Lee 
> > >> Signed-off-by: Kyungmin Park 
> > >
> > > I said some time ago I didn't want any new global PM QoS classes to be
> > > added this way.
> > >
> > > Can you please post a driver patch using this new thing?
> > >
> > > Rafael
> 
> It'd be too early for V4L2 device driver QoS patches as they are undergoing
> major updates and the previous QoS patches over they are now obsolete.
> 
> However, I've found that one QoS patch is still intact with the current one.
> Here goes the example driver that uses Bus-Throughput for its operation.
> (Fortunately, it is not V4L2, but DRM driver)
> 
> It is a G2D (2D graphics acceleration) device driver that gets command lists
> from userspace and then process them via DMA. Many command lists finish even
> before any DVFS mechanism may react while the response time of a command list
> is still important for the user processes.
> 
> Here we go:

Well, so my questions are:

> ---
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index d2d88f2..969b2c5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -135,6 +136,7 @@ struct g2d_data {
>   struct workqueue_struct *g2d_workq;
>   struct work_struct  runqueue_work;
>   struct exynos_drm_subdrvsubdrv;
> + struct pm_qos_request_list  pm_qos;
>   boolsuspended;
>  
>   /* cmdlist */
> @@ -314,6 +316,9 @@ static void g2d_dma_start(struct g2d_data *g2d,
>   pm_runtime_get_sync(g2d->dev);
>   clk_enable(g2d->gate_clk);
>  
> + /* 416MHz w/ 64b 30% saturating bus */
> + pm_qos_update_request(>pm_qos, 100);
> +

(1) What's the unit of that number and (2) why is it global?

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

[PATCH 1/9] perf bench: fix assert when NDEBUG is defined

[Arnaldo Carvalho de Melo]

From: Irina Tirdea 

When NDEBUG is defined, the assert macro will be expanded to nothing.
Some assert calls used in perf are also including some functionality
(e.g. system calls), not only validity checks. Therefore, if NDEBUG is
defined, this functionality will be removed along with the assert.  Perf
also defines BUG_ON based on assert, so it has the same problem.

Define BUG_ON so that the condition will be executed when NDEBUG is
defined.  Replace the assert statements that have these side effects
with BUG_ON.

For defining BUG_ON, use "if (cond) {}" insted of "if (cond) ;" because
in the latter case build fails with "error: suggest braces around empty
body in an ‘if’ statement [-Werror=empty-body]"

Suggested-by: Peter Zijlstra 
Signed-off-by: Irina Tirdea 
Reviewed-by: Namhyung Kim 
Reviewed-by: Pekka Enberg 
Cc: David Ahern 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Link: 
http://lkml.kernel.org/r/1347082551-2394-1-git-send-email-irina.tir...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/bench/sched-pipe.c  |6 +++---
 tools/perf/util/include/linux/kernel.h |4 
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
index 0c7454f..15911e9 100644
--- a/tools/perf/bench/sched-pipe.c
+++ b/tools/perf/bench/sched-pipe.c
@@ -56,13 +56,13 @@ int bench_sched_pipe(int argc, const char **argv,
 * causes error in building environment for perf
 */
int __used ret, wait_stat;
-   pid_t pid, retpid;
+   pid_t pid, retpid __used;
 
argc = parse_options(argc, argv, options,
 bench_sched_pipe_usage, 0);
 
-   assert(!pipe(pipe_1));
-   assert(!pipe(pipe_2));
+   BUG_ON(pipe(pipe_1));
+   BUG_ON(pipe(pipe_2));
 
pid = fork();
assert(pid >= 0);
diff --git a/tools/perf/util/include/linux/kernel.h 
b/tools/perf/util/include/linux/kernel.h
index b6842c1..4af9a10 100644
--- a/tools/perf/util/include/linux/kernel.h
+++ b/tools/perf/util/include/linux/kernel.h
@@ -47,8 +47,12 @@
 #endif
 
 #ifndef BUG_ON
+#ifdef NDEBUG
+#define BUG_ON(cond) do { if (cond) {} } while (0)
+#else
 #define BUG_ON(cond) assert(!(cond))
 #endif
+#endif
 
 /*
  * Both need more care to handle endianness
-- 
1.7.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/

[GIT PULL 0/9] perf/core improvements and fixes

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Hi Ingo,

Please consider pulling,

Thanks,

- Arnaldo

The following changes since commit ef34eb4da3eb62a1511592adf7c76d74faca0b14:

  Merge tag 'perf-core-for-mingo' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
(2012-09-08 13:26:02 +0200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux 
tags/perf-core-for-mingo

for you to fetch changes up to 6c7f631261064762a8ba1ee34fc2b76d117ef3fa:

  perf symbols: Remove BIONIC wrapper around libgen.h (2012-09-08 17:15:16 
-0300)


perf/core improvements and fixes

. Don't pass const char pointers to basename, so that we can unconditionally
  use libgen.h and thus avoid ifdef BIONIC lines, from David Ahern

. Fix assert/BUG_ON when NDEBUG is defined, from Irina Tirdea.

. Refactor hist formatting so that it can be reused with the GTK browser,
  From Namhyung Kim

Signed-off-by: Arnaldo Carvalho de Melo 


David Ahern (3):
  perf annotate: Make a copy of filename for passing to basename
  perf probe: Make a copy of exec path for passing to basename
  perf symbols: Remove BIONIC wrapper around libgen.h

Irina Tirdea (1):
  perf bench: fix assert when NDEBUG is defined

Namhyung Kim (5):
  perf hists: Introduce perf_hpp for hist period printing
  perf hists: Handle field separator properly
  perf hists: Use perf_hpp__format->width to calculate the column widths
  perf hists browser: Use perf_hpp__format functions
  perf gtk/browser: Use perf_hpp__format functions

 tools/perf/Makefile|2 +
 tools/perf/bench/sched-pipe.c  |6 +-
 tools/perf/builtin-diff.c  |1 +
 tools/perf/ui/browsers/hists.c |   96 ++--
 tools/perf/ui/gtk/browser.c|  101 +++--
 tools/perf/ui/gtk/gtk.h|1 +
 tools/perf/ui/gtk/setup.c  |1 +
 tools/perf/ui/hist.c   |  389 
 tools/perf/ui/setup.c  |8 +-
 tools/perf/ui/stdio/hist.c |  239 
 tools/perf/ui/tui/setup.c  |4 +
 tools/perf/util/annotate.c |9 +-
 tools/perf/util/hist.c |   33 ---
 tools/perf/util/hist.h |   37 +++
 tools/perf/util/include/linux/kernel.h |4 +
 tools/perf/util/probe-event.c  |   12 +-
 tools/perf/util/symbol.h   |2 -
 17 files changed, 665 insertions(+), 280 deletions(-)
 create mode 100644 tools/perf/ui/hist.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 the FAQ at  http://www.tux.org/lkml/

[PATCH 2/9] perf hists: Introduce perf_hpp for hist period printing

[Arnaldo Carvalho de Melo]

From: Namhyung Kim 

Current hist print functions are messy because it has to consider many
of command line options and the code doing that is scattered around to
places. So when someone wants to add an option to manipulate the hist
output it'd very easy to miss to update all of them in sync. And things
getting worse as more options/features are added continuously.

So I'd like to refactor them using hpp formats and move common code to
ui/hist.c in order to make it easy to maintain and to add new features.

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1346640790-17197-2-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile|2 +
 tools/perf/builtin-diff.c  |1 +
 tools/perf/ui/hist.c   |  340 
 tools/perf/ui/setup.c  |8 +-
 tools/perf/ui/stdio/hist.c |  238 ++-
 tools/perf/util/hist.h |   37 +
 6 files changed, 426 insertions(+), 200 deletions(-)
 create mode 100644 tools/perf/ui/hist.c

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 3eda492..e4b2e8f 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -403,7 +403,9 @@ LIB_OBJS += $(OUTPUT)util/cgroup.o
 LIB_OBJS += $(OUTPUT)util/target.o
 LIB_OBJS += $(OUTPUT)util/rblist.o
 LIB_OBJS += $(OUTPUT)util/intlist.o
+
 LIB_OBJS += $(OUTPUT)ui/helpline.o
+LIB_OBJS += $(OUTPUT)ui/hist.o
 LIB_OBJS += $(OUTPUT)ui/stdio/hist.o
 
 BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index e9933fd..c4c6d76 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -264,6 +264,7 @@ int cmd_diff(int argc, const char **argv, const char 
*prefix __used)
if (symbol__init() < 0)
return -1;
 
+   perf_hpp__init(true, show_displacement);
setup_sorting(diff_usage, options);
setup_pager();
 
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
new file mode 100644
index 000..8ccd1f2
--- /dev/null
+++ b/tools/perf/ui/hist.c
@@ -0,0 +1,340 @@
+#include 
+
+#include "../util/hist.h"
+#include "../util/util.h"
+#include "../util/sort.h"
+
+
+/* hist period print (hpp) functions */
+static int hpp__header_overhead(struct perf_hpp *hpp)
+{
+   if (hpp->ptr)
+   return scnprintf(hpp->buf, hpp->size, "Baseline");
+   else
+   return scnprintf(hpp->buf, hpp->size, "Overhead");
+}
+
+static int hpp__width_overhead(struct perf_hpp *hpp __used)
+{
+   return 8;
+}
+
+static int hpp__color_overhead(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period / hpp->total_period;
+
+   if (hpp->ptr) {
+   struct hists *old_hists = hpp->ptr;
+   u64 total_period = old_hists->stats.total_period;
+   u64 base_period = he->pair ? he->pair->period : 0;
+
+   if (total_period)
+   percent = 100.0 * base_period / total_period;
+   else
+   percent = 0.0;
+   }
+
+   return percent_color_snprintf(hpp->buf, hpp->size, "  %5.2f%%", 
percent);
+}
+
+static int hpp__entry_overhead(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period / hpp->total_period;
+
+   if (hpp->ptr) {
+   struct hists *old_hists = hpp->ptr;
+   u64 total_period = old_hists->stats.total_period;
+   u64 base_period = he->pair ? he->pair->period : 0;
+
+   if (total_period)
+   percent = 100.0 * base_period / total_period;
+   else
+   percent = 0.0;
+   }
+
+   return scnprintf(hpp->buf, hpp->size, "  %5.2f%%", percent);
+}
+
+static int hpp__header_overhead_sys(struct perf_hpp *hpp)
+{
+   return scnprintf(hpp->buf, hpp->size, " sys  ");
+}
+
+static int hpp__width_overhead_sys(struct perf_hpp *hpp __used)
+{
+   return 6;
+}
+
+static int hpp__color_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period_sys / hpp->total_period;
+   return percent_color_snprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__entry_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period_sys / hpp->total_period;
+   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__header_overhead_us(struct perf_hpp *hpp)
+{
+   return scnprintf(hpp->buf, hpp->size, " user ");
+}
+
+static int hpp__width_overhead_us(struct perf_hpp *hpp __used)
+{
+   return 6;
+}
+
+static int hpp__color_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
+{
+   double percent = 100.0 * he->period_us / hpp->total_period;
+   return percent_color_snprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int 

[PATCH 6/9] perf gtk/browser: Use perf_hpp__format functions

[Arnaldo Carvalho de Melo]

From: Namhyung Kim 

Now we can support color using pango markup with this change.

Signed-off-by: Namhyung Kim 
Acked-by: Pekka Enberg 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1346640790-17197-6-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/gtk/browser.c |  101 ---
 tools/perf/ui/gtk/gtk.h |1 +
 tools/perf/ui/gtk/setup.c   |1 +
 3 files changed, 87 insertions(+), 16 deletions(-)

diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 26b5b65..3c16ab5 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -36,6 +36,57 @@ static void perf_gtk__resize_window(GtkWidget *window)
gtk_window_resize(GTK_WINDOW(window), width, height);
 }
 
+static const char *perf_gtk__get_percent_color(double percent)
+{
+   if (percent >= MIN_RED)
+   return "";
+   if (percent >= MIN_GREEN)
+   return "";
+   return NULL;
+}
+
+#define HPP__COLOR_FN(_name, _field)   
\
+static int perf_gtk__hpp_color_ ## _name(struct perf_hpp *hpp, 
\
+struct hist_entry *he) 
\
+{  
\
+   double percent = 100.0 * he->_field / hpp->total_period;
\
+   const char *markup; 
\
+   int ret = 0;
\
+   
\
+   markup = perf_gtk__get_percent_color(percent);  
\
+   if (markup) 
\
+   ret += scnprintf(hpp->buf, hpp->size, "%s", markup);
\
+   ret += scnprintf(hpp->buf + ret, hpp->size - ret, "%5.2f%%", percent);  
\
+   if (markup) 
\
+   ret += scnprintf(hpp->buf + ret, hpp->size - ret, "");   
\
+   
\
+   return ret; 
\
+}
+
+HPP__COLOR_FN(overhead, period)
+HPP__COLOR_FN(overhead_sys, period_sys)
+HPP__COLOR_FN(overhead_us, period_us)
+HPP__COLOR_FN(overhead_guest_sys, period_guest_sys)
+HPP__COLOR_FN(overhead_guest_us, period_guest_us)
+
+#undef HPP__COLOR_FN
+
+void perf_gtk__init_hpp(void)
+{
+   perf_hpp__init(false, false);
+
+   perf_hpp__format[PERF_HPP__OVERHEAD].color =
+   perf_gtk__hpp_color_overhead;
+   perf_hpp__format[PERF_HPP__OVERHEAD_SYS].color =
+   perf_gtk__hpp_color_overhead_sys;
+   perf_hpp__format[PERF_HPP__OVERHEAD_US].color =
+   perf_gtk__hpp_color_overhead_us;
+   perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_SYS].color =
+   perf_gtk__hpp_color_overhead_guest_sys;
+   perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_US].color =
+   perf_gtk__hpp_color_overhead_guest_us;
+}
+
 static void perf_gtk__show_hists(GtkWidget *window, struct hists *hists)
 {
GType col_types[MAX_COLUMNS];
@@ -43,15 +94,25 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists)
struct sort_entry *se;
GtkListStore *store;
struct rb_node *nd;
-   u64 total_period;
GtkWidget *view;
-   int col_idx;
+   int i, col_idx;
int nr_cols;
+   char s[512];
+
+   struct perf_hpp hpp = {
+   .buf= s,
+   .size   = sizeof(s),
+   .total_period   = hists->stats.total_period,
+   };
 
nr_cols = 0;
 
-   /* The percentage column */
-   col_types[nr_cols++] = G_TYPE_STRING;
+   for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+   if (!perf_hpp__format[i].cond)
+   continue;
+
+   col_types[nr_cols++] = G_TYPE_STRING;
+   }
 
list_for_each_entry(se, _entry__sort_list, list) {
if (se->elide)
@@ -68,11 +129,17 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists)
 
col_idx = 0;
 
-   /* The percentage column */
-   gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
-   -1, "Overhead (%)",
-   renderer, "text",
-   col_idx++, NULL);
+   for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+   if (!perf_hpp__format[i].cond)
+   continue;
+
+   perf_hpp__format[i].header();
+
+   

[PATCH 4/9] perf hists: Use perf_hpp__format->width to calculate the column widths

[Arnaldo Carvalho de Melo]

From: Namhyung Kim 

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1346640790-17197-4-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/hist.c   |   27 +++
 tools/perf/util/hist.c |   33 -
 2 files changed, 27 insertions(+), 33 deletions(-)

diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 009adf2..031b349 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -360,3 +360,30 @@ int hist_entry__sort_snprintf(struct hist_entry *he, char 
*s, size_t size,
 
return ret;
 }
+
+/*
+ * See hists__fprintf to match the column widths
+ */
+unsigned int hists__sort_list_width(struct hists *hists)
+{
+   struct sort_entry *se;
+   int i, ret = 0;
+
+   for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+   if (!perf_hpp__format[i].cond)
+   continue;
+   if (i)
+   ret += 2;
+
+   ret += perf_hpp__format[i].width(NULL);
+   }
+
+   list_for_each_entry(se, _entry__sort_list, list)
+   if (!se->elide)
+   ret += 2 + hists__col_len(hists, se->se_width_idx);
+
+   if (verbose) /* Addr + origin */
+   ret += 3 + BITS_PER_LONG / 4;
+
+   return ret;
+}
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index b1817f1..0ba65ad 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -563,39 +563,6 @@ void hists__output_resort_threaded(struct hists *hists)
return __hists__output_resort(hists, true);
 }
 
-/*
- * See hists__fprintf to match the column widths
- */
-unsigned int hists__sort_list_width(struct hists *hists)
-{
-   struct sort_entry *se;
-   int ret = 9; /* total % */
-
-   if (symbol_conf.show_cpu_utilization) {
-   ret += 7; /* count_sys % */
-   ret += 6; /* count_us % */
-   if (perf_guest) {
-   ret += 13; /* count_guest_sys % */
-   ret += 12; /* count_guest_us % */
-   }
-   }
-
-   if (symbol_conf.show_nr_samples)
-   ret += 11;
-
-   if (symbol_conf.show_total_period)
-   ret += 13;
-
-   list_for_each_entry(se, _entry__sort_list, list)
-   if (!se->elide)
-   ret += 2 + hists__col_len(hists, se->se_width_idx);
-
-   if (verbose) /* Addr + origin */
-   ret += 3 + BITS_PER_LONG / 4;
-
-   return ret;
-}
-
 static void hists__remove_entry_filter(struct hists *hists, struct hist_entry 
*h,
   enum hist_filter filter)
 {
-- 
1.7.1

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

[PATCH 7/9] perf annotate: Make a copy of filename for passing to basename

[Arnaldo Carvalho de Melo]

From: David Ahern 

The basename function may modify the string passed to it, so the string
should not be marked const.

Signed-off-by: David Ahern 
Acked-by: Pekka Enberg 
Cc: Irina Tirdea 
Cc: Pekka Enberg 
Link: 
http://lkml.kernel.org/r/1347116812-93646-2-git-send-email-dsah...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 51ef69c..04eafd3 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -984,7 +984,8 @@ int symbol__annotate_printf(struct symbol *sym, struct map 
*map, int evidx,
int context)
 {
struct dso *dso = map->dso;
-   const char *filename = dso->long_name, *d_filename;
+   char *filename;
+   const char *d_filename;
struct annotation *notes = symbol__annotation(sym);
struct disasm_line *pos, *queue = NULL;
u64 start = map__rip_2objdump(map, sym->start);
@@ -992,6 +993,10 @@ int symbol__annotate_printf(struct symbol *sym, struct map 
*map, int evidx,
int more = 0;
u64 len;
 
+   filename = strdup(dso->long_name);
+   if (!filename)
+   return -ENOMEM;
+
if (full_paths)
d_filename = filename;
else
@@ -1042,6 +1047,8 @@ int symbol__annotate_printf(struct symbol *sym, struct 
map *map, int evidx,
}
}
 
+   free(filename);
+
return more;
 }
 
-- 
1.7.1

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

[PATCH 5/9] perf hists browser: Use perf_hpp__format functions

[Arnaldo Carvalho de Melo]

From: Namhyung Kim 

Override hpp->color functions for TUI. Because line coloring is done
outside of the function, it just sets the percent value and pass it.

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1346640790-17197-5-git-send-email-namhy...@kernel.org
[ committer note: Keep previous layout by showing the overhead at column 1 ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/hists.c |   96 ++--
 tools/perf/ui/tui/setup.c  |4 ++
 2 files changed, 77 insertions(+), 23 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 81bd8c2..5a5739b 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -28,6 +28,8 @@ struct hist_browser {
bool has_symbols;
 };
 
+extern void hist_browser__init_hpp(void);
+
 static int hists__browser_title(struct hists *hists, char *bf, size_t size,
const char *ev_name);
 
@@ -563,14 +565,47 @@ static int hist_browser__show_callchain(struct 
hist_browser *browser,
return row - first_row;
 }
 
+#define HPP__COLOR_FN(_name, _field)   \
+static int hist_browser__hpp_color_ ## _name(struct perf_hpp *hpp, \
+struct hist_entry *he) \
+{  \
+   double percent = 100.0 * he->_field / hpp->total_period;\
+   *(double *)hpp->ptr = percent;  \
+   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);  \
+}
+
+HPP__COLOR_FN(overhead, period)
+HPP__COLOR_FN(overhead_sys, period_sys)
+HPP__COLOR_FN(overhead_us, period_us)
+HPP__COLOR_FN(overhead_guest_sys, period_guest_sys)
+HPP__COLOR_FN(overhead_guest_us, period_guest_us)
+
+#undef HPP__COLOR_FN
+
+void hist_browser__init_hpp(void)
+{
+   perf_hpp__init(false, false);
+
+   perf_hpp__format[PERF_HPP__OVERHEAD].color =
+   hist_browser__hpp_color_overhead;
+   perf_hpp__format[PERF_HPP__OVERHEAD_SYS].color =
+   hist_browser__hpp_color_overhead_sys;
+   perf_hpp__format[PERF_HPP__OVERHEAD_US].color =
+   hist_browser__hpp_color_overhead_us;
+   perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_SYS].color =
+   hist_browser__hpp_color_overhead_guest_sys;
+   perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_US].color =
+   hist_browser__hpp_color_overhead_guest_us;
+}
+
 static int hist_browser__show_entry(struct hist_browser *browser,
struct hist_entry *entry,
unsigned short row)
 {
char s[256];
double percent;
-   int printed = 0;
-   int width = browser->b.width - 6; /* The percentage */
+   int i, printed = 0;
+   int width = browser->b.width - 1;
char folded_sign = ' ';
bool current_entry = ui_browser__is_current_entry(>b, row);
off_t row_offset = entry->row_offset;
@@ -586,35 +621,50 @@ static int hist_browser__show_entry(struct hist_browser 
*browser,
}
 
if (row_offset == 0) {
-   hist_entry__sort_snprintf(entry, s, sizeof(s), browser->hists);
-   percent = (entry->period * 100.0) / 
browser->hists->stats.total_period;
+   struct perf_hpp hpp = {
+   .buf= s,
+   .size   = sizeof(s),
+   .total_period   = browser->hists->stats.total_period,
+   };
 
-   ui_browser__set_percent_color(>b, percent, 
current_entry);
-   ui_browser__gotorc(>b, row, 0);
-   if (symbol_conf.use_callchain) {
-   slsmg_printf("%c ", folded_sign);
-   width -= 2;
-   }
+   ui_browser__gotorc(>b, row, 1);
 
-   slsmg_printf(" %5.2f%%", percent);
+   for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+   if (!perf_hpp__format[i].cond)
+   continue;
 
-   /* The scroll bar isn't being used */
-   if (!browser->b.navkeypressed)
-   width += 1;
+   if (i) {
+   slsmg_printf("  ");
+   width -= 2;
+   }
 
-   if (!current_entry || !browser->b.navkeypressed)
-   ui_browser__set_color(>b, HE_COLORSET_NORMAL);
+   if (perf_hpp__format[i].color) {
+   hpp.ptr = 
+   /* It will set percent for us. See 
HPP__COLOR_FN above. */
+   width -= 

[PATCH 3/9] perf hists: Handle field separator properly

[Arnaldo Carvalho de Melo]

From: Namhyung Kim 

When a field separator is given, the output format doesn't need to be
fancy like aligning to column length, coloring the percent value and so
on.  And since there's a slight difference to normal format, fix it not
to break backward compatibility.

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1346640790-17197-3-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/hist.c   |   74 ---
 tools/perf/ui/stdio/hist.c |3 +-
 2 files changed, 50 insertions(+), 27 deletions(-)

diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 8ccd1f2..009adf2 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -8,10 +8,9 @@
 /* hist period print (hpp) functions */
 static int hpp__header_overhead(struct perf_hpp *hpp)
 {
-   if (hpp->ptr)
-   return scnprintf(hpp->buf, hpp->size, "Baseline");
-   else
-   return scnprintf(hpp->buf, hpp->size, "Overhead");
+   const char *fmt = hpp->ptr ? "Baseline" : "Overhead";
+
+   return scnprintf(hpp->buf, hpp->size, fmt);
 }
 
 static int hpp__width_overhead(struct perf_hpp *hpp __used)
@@ -40,6 +39,7 @@ static int hpp__color_overhead(struct perf_hpp *hpp, struct 
hist_entry *he)
 static int hpp__entry_overhead(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period / hpp->total_period;
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "  %5.2f%%";
 
if (hpp->ptr) {
struct hists *old_hists = hpp->ptr;
@@ -52,12 +52,14 @@ static int hpp__entry_overhead(struct perf_hpp *hpp, struct 
hist_entry *he)
percent = 0.0;
}
 
-   return scnprintf(hpp->buf, hpp->size, "  %5.2f%%", percent);
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_overhead_sys(struct perf_hpp *hpp)
 {
-   return scnprintf(hpp->buf, hpp->size, " sys  ");
+   const char *fmt = symbol_conf.field_sep ? "%s" : "%6s";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, "sys");
 }
 
 static int hpp__width_overhead_sys(struct perf_hpp *hpp __used)
@@ -74,12 +76,16 @@ static int hpp__color_overhead_sys(struct perf_hpp *hpp, 
struct hist_entry *he)
 static int hpp__entry_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period_sys / hpp->total_period;
-   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "%5.2f%%";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_overhead_us(struct perf_hpp *hpp)
 {
-   return scnprintf(hpp->buf, hpp->size, " user ");
+   const char *fmt = symbol_conf.field_sep ? "%s" : "%6s";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, "user");
 }
 
 static int hpp__width_overhead_us(struct perf_hpp *hpp __used)
@@ -96,7 +102,9 @@ static int hpp__color_overhead_us(struct perf_hpp *hpp, 
struct hist_entry *he)
 static int hpp__entry_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period_us / hpp->total_period;
-   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "%5.2f%%";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_overhead_guest_sys(struct perf_hpp *hpp)
@@ -120,7 +128,9 @@ static int hpp__entry_overhead_guest_sys(struct perf_hpp 
*hpp,
 struct hist_entry *he)
 {
double percent = 100.0 * he->period_guest_sys / hpp->total_period;
-   return scnprintf(hpp->buf, hpp->size, "  %5.2f%% ", percent);
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "  %5.2f%% ";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_overhead_guest_us(struct perf_hpp *hpp)
@@ -144,12 +154,16 @@ static int hpp__entry_overhead_guest_us(struct perf_hpp 
*hpp,
struct hist_entry *he)
 {
double percent = 100.0 * he->period_guest_us / hpp->total_period;
-   return scnprintf(hpp->buf, hpp->size, "  %5.2f%% ", percent);
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "  %5.2f%% ";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_samples(struct perf_hpp *hpp)
 {
-   return scnprintf(hpp->buf, hpp->size, "  Samples  ");
+   const char *fmt = symbol_conf.field_sep ? "%s" : "%11s";
+
+   return scnprintf(hpp->buf, hpp->size, fmt, "Samples");
 }
 
 static int hpp__width_samples(struct perf_hpp *hpp __used)
@@ -159,12 +173,16 @@ static int hpp__width_samples(struct perf_hpp *hpp __used)
 
 static int hpp__entry_samples(struct perf_hpp *hpp, struct hist_entry *he)
 {
-   return scnprintf(hpp->buf, 

[PATCH 8/9] perf probe: Make a copy of exec path for passing to basename

[Arnaldo Carvalho de Melo]

From: David Ahern 

The basename function may modify the string passed to it, so the string
should not be marked const.

Signed-off-by: David Ahern 
Acked-by: Pekka Enberg 
Cc: Irina Tirdea 
Cc: Pekka Enberg 
Cc: Srikar Dronamraju 
Link: 
http://lkml.kernel.org/r/1347116812-93646-3-git-send-email-dsah...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 0dda25d..e8c72de 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2307,10 +2307,17 @@ static int convert_name_to_addr(struct perf_probe_event 
*pev, const char *exec)
function = NULL;
}
if (!pev->group) {
-   char *ptr1, *ptr2;
+   char *ptr1, *ptr2, *exec_copy;
 
pev->group = zalloc(sizeof(char *) * 64);
-   ptr1 = strdup(basename(exec));
+   exec_copy = strdup(exec);
+   if (!exec_copy) {
+   ret = -ENOMEM;
+   pr_warning("Failed to copy exec string.\n");
+   goto out;
+   }
+
+   ptr1 = strdup(basename(exec_copy));
if (ptr1) {
ptr2 = strpbrk(ptr1, "-._");
if (ptr2)
@@ -2319,6 +2326,7 @@ static int convert_name_to_addr(struct perf_probe_event 
*pev, const char *exec)
ptr1);
free(ptr1);
}
+   free(exec_copy);
}
free(pp->function);
pp->function = zalloc(sizeof(char *) * MAX_PROBE_ARGS);
-- 
1.7.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 9/9] perf symbols: Remove BIONIC wrapper around libgen.h

[Arnaldo Carvalho de Melo]

From: David Ahern 

Now that the 2 offenders are fixed, the BIONIC conditional around
libgen.h can be removed.

Signed-off-by: David Ahern 
Acked-by: Pekka Enberg 
Cc: Irina Tirdea 
Cc: Pekka Enberg 
Link: 
http://lkml.kernel.org/r/1347116812-93646-4-git-send-email-dsah...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol.h |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index d3b330c..41a15da 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -10,9 +10,7 @@
 #include 
 #include 
 #include 
-#if defined(__BIONIC__)
 #include 
-#endif
 
 #ifndef NO_LIBELF_SUPPORT
 #include 
-- 
1.7.1

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

Re: Question about failure in PCI power-state change

[Rafael J. Wysocki]

On Saturday, September 08, 2012, Bjorn Helgaas wrote:
> +cc Rafael, Huang, linux-pm
> 
> On Fri, Sep 7, 2012 at 3:44 PM, Larry Finger  
> wrote:
> > Hi,
> >
> > On occasion when I unload and reload driver rtl8192ce, I get the message
> >
> > "Refused to change power state, currently in D3"
> >
> > I added additional info to the printk and discovered that it was trying to
> > change to state D0. The problem seems to occur when I have made a
> > connection, unloaded the driver, and reloaded it. If I do not make a
> > connection before unloading, then the problem is a lot less likely.
> >
> > This is with kernel 3.6-rc4 from wireless-testing. A Google search shows
> > that the problem is usually due to suspend/resume difficulties, but this
> > machine has not been suspended.
> >
> > I would appreciate any help that you might give in solving this issue.

I think writing "on" to the /sys/devices/.../power/control attribute of the 
device
in question would help.

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

[PATCH v3] trace: Move trace event enable from fs_initcall to core_initcall

[Ezequiel Garcia]

This patch splits trace event initialization in two stages:
 * ftrace enable
 * sysfs event entry creation

This allows to capture trace events from an earlier point
by using 'trace_event' kernel parameter and is important
to trace boot-up allocations.

Note that, in order to enable events at core_initcall,
it's necessary to move init_ftrace_syscalls() from
core_initcall to early_initcall.

Cc: Steven Rostedt 
Signed-off-by: Ezequiel Garcia 
---
Changes from v1:
  * Rework code as requested by Steven.

Changes from v2:
  * Move init_ftrace_syscalls() to early_initcall, 
so syscalls self-test pass.

 kernel/trace/trace_events.c   |  104 +++-
 kernel/trace/trace_syscalls.c |2 +-
 2 files changed, 71 insertions(+), 35 deletions(-)

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 29111da..4eaf86e 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1199,6 +1199,31 @@ event_create_dir(struct ftrace_event_call *call, struct 
dentry *d_events,
return 0;
 }
 
+static void event_remove(struct ftrace_event_call *call)
+{
+   ftrace_event_enable_disable(call, 0);
+   if (call->event.funcs)
+   __unregister_ftrace_event(>event);
+   list_del(>list);
+}
+
+static int event_init(struct ftrace_event_call *call)
+{
+   int ret = 0;
+
+   if (WARN_ON(!call->name))
+   return -EINVAL;
+
+   if (call->class->raw_init) {
+   ret = call->class->raw_init(call);
+   if (ret < 0 && ret != -ENOSYS)
+   pr_warn("Could not initialize trace events/%s\n",
+   call->name);
+   }
+
+   return ret;
+}
+
 static int
 __trace_add_event_call(struct ftrace_event_call *call, struct module *mod,
   const struct file_operations *id,
@@ -1209,19 +1234,9 @@ __trace_add_event_call(struct ftrace_event_call *call, 
struct module *mod,
struct dentry *d_events;
int ret;
 
-   /* The linker may leave blanks */
-   if (!call->name)
-   return -EINVAL;
-
-   if (call->class->raw_init) {
-   ret = call->class->raw_init(call);
-   if (ret < 0) {
-   if (ret != -ENOSYS)
-   pr_warning("Could not initialize trace 
events/%s\n",
-  call->name);
-   return ret;
-   }
-   }
+   ret = event_init(call);
+   if (ret < 0)
+   return ret;
 
d_events = event_trace_events_dir();
if (!d_events)
@@ -1272,13 +1287,10 @@ static void remove_subsystem_dir(const char *name)
  */
 static void __trace_remove_event_call(struct ftrace_event_call *call)
 {
-   ftrace_event_enable_disable(call, 0);
-   if (call->event.funcs)
-   __unregister_ftrace_event(>event);
-   debugfs_remove_recursive(call->dir);
-   list_del(>list);
+   event_remove(call);
trace_destroy_fields(call);
destroy_preds(call);
+   debugfs_remove_recursive(call->dir);
remove_subsystem_dir(call->class->system);
 }
 
@@ -1450,6 +1462,36 @@ static __init int setup_trace_event(char *str)
 }
 __setup("trace_event=", setup_trace_event);
 
+static __init int event_trace_enable(void)
+{
+   struct ftrace_event_call **iter, *call;
+   char *buf = bootup_event_buf;
+   char *token;
+   int ret;
+
+   for_each_event(iter, __start_ftrace_events, __stop_ftrace_events) {
+
+   call = *iter;
+   ret = event_init(call);
+   if (!ret)
+   list_add(>list, _events);
+   }
+
+   while (true) {
+   token = strsep(, ",");
+
+   if (!token)
+   break;
+   if (!*token)
+   continue;
+
+   ret = ftrace_set_clr_event(token, 1);
+   if (ret)
+   pr_warn("Failed to enable trace event: %s\n", token);
+   }
+   return 0;
+}
+
 static __init int event_trace_init(void)
 {
struct ftrace_event_call **call;
@@ -1457,8 +1499,6 @@ static __init int event_trace_init(void)
struct dentry *entry;
struct dentry *d_events;
int ret;
-   char *buf = bootup_event_buf;
-   char *token;
 
d_tracer = tracing_init_dentry();
if (!d_tracer)
@@ -1497,24 +1537,19 @@ static __init int event_trace_init(void)
if (trace_define_common_fields())
pr_warning("tracing: Failed to allocate common fields");
 
+   /*
+* Early initialization already enabled ftrace event.
+* Now it's only necessary to create the event directory.
+*/
for_each_event(call, __start_ftrace_events, __stop_ftrace_events) {
-   __trace_add_event_call(*call, NULL, _event_id_fops,
+
+   ret = event_create_dir(*call, d_events,
+  

Re: mtd: kernel BUG at arch/x86/mm/pat.c:279!

[Linus Torvalds]

On Fri, Sep 7, 2012 at 4:54 PM, Suresh Siddha  wrote:
>
> Essentially the user is trying to mmap at a very large offset (from the
> oops it appears "vma->vm_pgoff << PAGE_SHIFT + start" ends up to
> "0xf000").

Ok, Sasha confirmed that.

> So it appears that the condition "(vma->vm_end - vma->vm_start + off) >
> len" might be false because of the wraparound? and doesn't return
> -EINVAL.

Ack.

Anyway, that means that the BUG_ON() is likely bogus, but so is the
whole calling convention.

The 4kB range starting at 0xf000 sounds like a *valid*
range, but that requires that we fix the calling convention to not
have that "end" (exclusive) thing. It should either be "end"
(inclusive), or just "len".

So it should either be start=0xf000 end=0x
or it should be start=0xf000 len=0x1000.

Or we need to say that we must never accept things at the end of the
64-bit range.

Whatever. Something like this (TOTALLY UNTESTED) attached patch should
get the mtdchar overflows to go away, but it does *not* fix the fact
that the MTRR start/end model is broken. It really is technically
valid to have a resource_size_t range of 0xf000+0x1000,
and right now it causes a BUG_ON() in pat.c.

Suresh?

Linus


patch.diff
Description: Binary data

Re: [PATCH fixes/for-3.6 0/3] few more IB fixes for 3.6

[Or Gerlitz]

On Wed, Aug 29, 2012 at 6:14 PM, Or Gerlitz  wrote:

> Hi Roland,
>
> This short series include two more fixes from Shlomo to the newly
> introduced IPoIB neighbour table, and a fix for Yishai that completes
> the support for memory registration of up to 8TB.

Roland,

AFAIK 3.6-rc5 should be out by tonight, these are fixes to known bugs
in there which I sent you eleven days ago and didn't get any comment,
could you get them in and/or react in some way?

thanks,

Or.

>
> Shlomo Pongratz (2):
>   IB/ipoib: Fix memory leak in the neigh table deletion flow
>   IB/ipoib: Fix AB-BA deadlock when deleting neighbours
>
> Yishai Hadas (1):
>   net/mlx4_core: Enable 8TB memory registration
>
>  drivers/infiniband/ulp/ipoib/ipoib.h   |4 +-
>  drivers/infiniband/ulp/ipoib/ipoib_main.c  |  101 +++
>  drivers/infiniband/ulp/ipoib/ipoib_multicast.c |2 -
>  drivers/net/ethernet/mellanox/mlx4/icm.c   |   30 ---
>  drivers/net/ethernet/mellanox/mlx4/icm.h   |   10 +-
>  5 files changed, 74 insertions(+), 73 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Kbuild: use normal compression settings for tar*-pkg

[Andi Kleen]

From: Andi Kleen 

For large kernel configurations (like a distribution kernel)
targz-pkg takes a quite long time to just do the compression.
I clocked it at 15+mins for a SUSE kernel like config on a fast
system.  And tarxz and bzip2 are even slower.

The main reason is that the script that is doing the taring sets
the highest compression level (-9).  When I change it to just
use the defaults the gzip time for the same kernel goes down
to ~3 mins. I haven't tested xz and bzip, but I expect those
to be much faster too.

I'm not willing to wait that long for a small compression
gain. So just change the script to use the defaults.

Signed-off-by: Andi Kleen 
---
 scripts/package/buildtar |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/package/buildtar b/scripts/package/buildtar
index 8a7b155..632377f 100644
--- a/scripts/package/buildtar
+++ b/scripts/package/buildtar
@@ -28,15 +28,15 @@ case "${1}" in
file_ext=""
;;
targz-pkg)
-   compress="gzip -c9"
+   compress="gzip"
file_ext=".gz"
;;
tarbz2-pkg)
-   compress="bzip2 -c9"
+   compress="bzip2"
file_ext=".bz2"
;;
tarxz-pkg)
-   compress="xz -c9"
+   compress="xz"
file_ext=".xz"
;;
*)
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: Documentation change for inkern interface.

[anish kumar]

From: anish kumar 

This commit- 314be14bb renamed the _st_ functions to loose the bit
that was meant for staging version but forgot to change
the documentation which still have _st_ sprinkled in some of the
places.

Signed-off-by: anish kumar 
---
 drivers/staging/iio/Documentation/inkernel.txt |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/iio/Documentation/inkernel.txt 
b/drivers/staging/iio/Documentation/inkernel.txt
index a05823e..ab52840 100644
--- a/drivers/staging/iio/Documentation/inkernel.txt
+++ b/drivers/staging/iio/Documentation/inkernel.txt
@@ -48,11 +48,11 @@ There are then a number of functions that can be used to 
get information
 about this channel such as it's current reading.
 
 e.g.
-iio_st_read_channel_raw() - get a reading
-iio_st_read_channel_type() - get the type of channel
+iio_read_channel_raw() - get a reading
+iio_get_channel_type() - get the type of channel
 
 There is also provision for retrieving all of the channels associated
 with a given consumer.  This is useful for generic drivers such as
 iio_hwmon where the number and naming of channels is not known by the
-consumer driver.  To do this, use iio_st_channel_get_all.
+consumer driver.  To do this, use iio_channel_get_all.
 
-- 
1.7.1

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

Re: [PATCH 0/9] Prep work for immutable bio vecs

[Tejun Heo]

Hello, Kent.

On Fri, Sep 07, 2012 at 03:59:11PM -0700, Kent Overstreet wrote:
> Random assortment of refactoring and trivial cleanups.
> 
> Immutable bio vecs and efficient bio splitting require auditing and removing
> pretty much all bi_idx uses, among other things.
> 
> The reason is that with immutable bio vecs we can't use the bvec array
> directly; if we have a partially completed bvec, that'll be indicated with a
> field in struct bvec_iter (which gets embedded in struct bio) - bi_bvec_done.
> 
> bio_for_each_segments() will handle this transparently, so code needs to be
> converted to use it or some other generic accessor.
> 
> Also, bio splitting means that when a driver gets a bio, bi_idx and
> bi_bvec_done may both be nonzero. Again, just need to use generic accessors.

There are three pending patchsets and I don't know how they're
supposed to come together.  Please explain on which tree the patches
are based and how they stack and preferably provide a git branch.

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: [PATCH 2/2] block: Avoid deadlocks with bio allocation by stacking drivers

[Tejun Heo]

(Restoring cc list from the previous discussion.  Please retain the cc
list of the people who discussed in the previous postings.)

On Fri, Sep 07, 2012 at 03:12:53PM -0700, Kent Overstreet wrote:
> But this is tricky and not a generic solution. This patch solves it for
> all users by inverting the previously described technique. We allocate a
> rescuer workqueue for each bio_set, and then in the allocation code if
> there are bios on current->bio_list we would be blocking, we punt them
> to the rescuer workqueue to be submitted.

It would be great if this explanation can be expanded a bit.  Why does
it make the deadlock condition go away?  What are the restrictions -
e.g. using other mempools for additional per-bio data structure
wouldn't work, right?

> +static void punt_bios_to_rescuer(struct bio_set *bs)
> +{
> + struct bio_list punt, nopunt;
> + struct bio *bio;
> +
> + bio_list_init();
> + bio_list_init();
> +
> + while ((bio = bio_list_pop(current->bio_list)))
> + bio_list_add(bio->bi_pool == bs ?  : , bio);
> +
> + *current->bio_list = nopunt;

Why this is necessary needs explanation and it's done in rather
unusual way.  I suppose the weirdness is from bio_list API
restriction?

> + spin_lock(>rescue_lock);
> + bio_list_merge(>rescue_list, );
> + spin_unlock(>rescue_lock);
> +
> + queue_work(bs->rescue_workqueue, >rescue_work);
> +}
> +
>  /**
>   * bio_alloc_bioset - allocate a bio for I/O
>   * @gfp_mask:   the GFP_ mask given to the slab allocator
> @@ -317,6 +354,7 @@ EXPORT_SYMBOL(bio_reset);
>   */
>  struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set 
> *bs)
>  {
> + gfp_t saved_gfp = gfp_mask;
>   unsigned front_pad;
>   unsigned inline_vecs;
>   unsigned long idx = BIO_POOL_NONE;
> @@ -334,13 +372,37 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int 
> nr_iovecs, struct bio_set *bs)
>   front_pad = 0;
>   inline_vecs = nr_iovecs;
>   } else {
> + /*
> +  * generic_make_request() converts recursion to iteration; this
> +  * means if we're running beneath it, any bios we allocate and
> +  * submit will not be submitted (and thus freed) until after we
> +  * return.
> +  *
> +  * This exposes us to a potential deadlock if we allocate
> +  * multiple bios from the same bio_set() while running
> +  * underneath generic_make_request(). If we were to allocate
> +  * multiple bios (say a stacking block driver that was splitting
> +  * bios), we would deadlock if we exhausted the mempool's
> +  * reserve.
> +  *
> +  * We solve this, and guarantee forward progress, with a rescuer
> +  * workqueue per bio_set. If we go to allocate and there are
> +  * bios on current->bio_list, we first try the allocation
> +  * without __GFP_WAIT; if that fails, we punt those bios we
> +  * would be blocking to the rescuer workqueue before we retry
> +  * with the original gfp_flags.
> +  */
> +
> + if (current->bio_list && !bio_list_empty(current->bio_list))
> + gfp_mask &= ~__GFP_WAIT;
> +retry:
>   p = mempool_alloc(bs->bio_pool, gfp_mask);
>   front_pad = bs->front_pad;
>   inline_vecs = BIO_INLINE_VECS;
>   }

Wouldn't the following be better?

p = mempool_alloc(bs->bi_pool, gfp_mask);
if (unlikely(!p) && gfp_mask != saved_gfp) {
punt_bios_to_rescuer(bs);
p = mempool_alloc(bs->bi_pool, saved_gfp);
}

I really hope the usage restriction (don't mix with mempool) for
bioset is clearly documented somewhere appropriate.

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: [PATCH v4 00/21] OMAP UART Patches

[Felipe Balbi]

Hi,

On Fri, Sep 07, 2012 at 01:53:11PM -0700, Kevin Hilman wrote:
> Felipe Balbi  writes:
> 
> > Hi,
> >
> > On Thu, Sep 06, 2012 at 03:44:13PM -0700, Kevin Hilman wrote:
> >> Felipe Balbi  writes:
> >> 
> >> > Hi guys,
> >> >
> >> > here's v4 of the omap uart patchset. No changes other than a rebase on 
> >> > top of
> >> > Greg's tty-next branch and Tony's Acked-by being added to a couple 
> >> > patches
> >> >
> >> > Note: I'm resending the series with Vikram's Software Flow Control fix 
> >> > anyway
> >> > as it can just be ignored if it's decided it needs to go into this merge
> >> > window.
> >> 
> >> Sorry to be late to the party... just getting back from some time off.
> >> 
> >> I'm assuming that this was not tested with PM, so decided I better do it
> >
> > you assumed wrong. See the previous versions of the series and you'll
> > see I mention all the basic pm testing I did.
> 
> My apologies for not reading the previous versions.  I don't think it's
> unusual that a reviewer should expect everything he to know about a
> series (including how it was tested) is in the cover letter or in the
> changelogs of the latest series.  I don't expect to have to look through

you've got a point there. My bad, should've kept series history on all
revisions.

> all the previous versions for this kind of info.  Since I wasn't around
> to review/test the earlier versions, I just looked at the latest (v4)
> and didn't see any mention of testing of any sort in the cover letter.

Well, fair enough. Maybe I wasn't too verbose, but here's what I did on
panda:

. check that console still works
. check that IRQs increase as I type on console
. check that pm_runtime suspend callback is called after 1 second of
inactivity (with printk)
. check that device resumes properly when I type on console again
. enable UART wakeup (through sysfs) and 'echo mem > /sys/power/state'
then check that I can wakeup from suspend and check that all
powerdomains actually reached low power state

> Looking back at the previous cover letters, I don't see any description
> of the PM testing either.  I only see it was tested on pandaboard.

Yeah, initially I wasn't testing PM because UART wakeup was known to be
broken, but then I decided to test and sent it as a reply to cover
letter v2, then I forgot to keep the history on v3 and v4. My bad.

> Since mainline doesn't have full PM support for OMAP4, testing on panda
> doesn't really test UART PM at all.

Fair enough. What's missing for omap4 panda ? I could reach suspend2ram
with echo mem > /sys/power/state and wakeup from it.

> Could you please point me to the descriptions in earlier mails of how
> you did PM testing, and on what platforms?

Though not on a cover letter, this is how I was testing from v2 and
onwards:

http://marc.info/?l=linux-omap=134555434407362=2

> In addition, IMO, if this was only tested on Panda (as suggested by
> earlier cover letters), it really should not have been merged until it
> got some broader testing.

Shubhro's got his Tested-by tag. I believe he tested on beagleboard and
omap4sdp. Shubhro, can you confirm which platforms you tested the UART
patches ? cheers

> >> myself seeing that Greg is has already merge it.  To test, I merged
> >> Greg's tty-next branch with v3.6-rc4 and did some PM testing.
> >> 
> >> The bad news is that it doesn't even compile (see reply to [PATCH v4
> >> 20/21]).  
> >
> > yeah, that was an automerge issue when rebasing on greg's tty-next
> > branch, plus me assuming omap serial was already enabled on my .config
> > and not checking the compile output. Sent a patch now.
> 
> As I reported in my reply to [PATCH v4 20/21], that patch also had
> another problem where it introduced a new (but unused) field.  Maybe
> another rebase problem?  I see the same problem in v3 and v4.

I'll check it out and make sure to delete any such unused fields. Thanks

> >> Also, there is a big WARNING on boot[1], which seems to be triggered by
> >> a new check added for v3.6-rc3[2].  This appears to be introduced by
> >> $SUBJECT series, because I don't see it on vanilla v3.6-rc4.
> 
> [...]
> 
> > This doesn't seem to be caused by $SUBJECT at all. See that we are
> > calling uart_add_one_port() which will call tty_port_register_device()
> > which, in turn, will call tty_port_link_device() and that will set
> > driver->ports[index] correctly.
> >
> > Have you checked if this doesn't happen without my series before waving
> > your blame hammer ? FWIW, that part of the code wasn't change by
> > $SUBJECT at all.
> 
> Whoa.  This was only test report.  No need to get personal.  All I said
> is that it "seemed" to introduced by $SUBJECT series.  Hardly waiving
> "blame hammer."

fair enough.

> And yes, I did check without your series.  As I reported above, the

What about v3.6-rc4 + the patch which added the warning ? :-)

> warning didn't exist with v3.6-rc4, and it did with yesterday's tty-next
> branch.  The WARNING pointed a 

Re: [PATCH 4/7 V6] workqueue: fix idle worker depletion

[Tejun Heo]

Hello, Lai.

On Sun, Sep 09, 2012 at 02:34:02AM +0800, Lai Jiangshan wrote:
> in 3.6 busy_worker_rebind() handle WORKER_REBIND bit,
> not WORKER_UNBOUND bit.
>
> busy_worker_rebind() takes struct work_struct *work argument, we have to
> add new patch to add a helper and restruct it at first.

What's wrong with just treating manager as busy.  Factor out,
rebind_work scheduling from rebind_workers() and call it for busy
workers and the manager if it exists.  manage_workers() only need to
call process_scheduled_works().  Wouldn't that work?

> worker_maybe_bind_and_lock() 's mean is very clear
> here. busy_worker_rebind() seems for busy workers, manager is not
> busy workers.

I don't know.  It just seems unnecessarily wordy.  If you don't like
reusing the busy worker path, how about just calling
maybe_bind_and_lock() unconditionally after locking manager_mutex?  I
mean, can't it just do the following?

spin_unlock_irq(>lock);

/*
 * Explain what's going on.
 */
mutex_lock(>manager_mutex);
if (worker_maybe_bind_and_lock(worker))
worker_clr_flags(worker, WORKER_UNBOUND);
ret = true;

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/

Announce: Sysprof 1.2.0; system-level profiler for Linux

[Soren Sandmann]

A new stable release 1.2.0 of the Sysprof system-level sampling profiler
for Linux is now available. News since 1.0:

- User interface improvements
- Improved tracking of time spent in kernel
- Command line version
- Performance improvements
- Now based on perf_event_open system call

Where to get it:

   Download:   http://sysprof.com/sysprof-1.2.0.tar.gz
   Sysprof web site:   http://sysprof.com/
   Anonymous git:  git://git.gnome.org/sysprof  (tag: 1.2.0)
   Sysprof mailing list:
   http://mail.gnome.org/mailman/listinfo/sysprof-list

Please send patches and bug reports to

sysprof-l...@gnome.org


Søren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c: fix error return code

[Ezequiel Garcia]

Peter,

On Sat, Sep 8, 2012 at 11:01 AM, Peter Senna Tschudin
 wrote:
> From: Peter Senna Tschudin 
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != 
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
>
> // 
>
> Signed-off-by: Peter Senna Tschudin 
>
> ---
> walter harms , thanks for the tip. Please take a look 
> carefully to check if I got your suggestion correctly. It was tested by 
> compilation only.
>
>  drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c |   30 
> ++---
>  1 file changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c 
> b/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
> index c8c94fb..b663dac 100644
> --- a/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
> +++ b/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
> @@ -704,11 +704,9 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev 
> *dev, int channel_select,
>  {
> struct sram_channel *sram_ch;
> u32 tmp;
> -   int retval = 0;
> int err = 0;
> int data_frame_size = 0;
> int risc_buffer_size = 0;
> -   int str_length = 0;
>
> if (dev->_is_running_ch2) {
> pr_info("Video Channel is still running so return!\n");
> @@ -744,20 +742,16 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev 
> *dev, int channel_select,
> risc_buffer_size = dev->_isNTSC_ch2 ?
> NTSC_RISC_BUF_SIZE : PAL_RISC_BUF_SIZE;
>
> -   if (dev->input_filename_ch2) {
> -   str_length = strlen(dev->input_filename_ch2);
> -   dev->_filename_ch2 = kmemdup(dev->input_filename_ch2,
> -str_length + 1, GFP_KERNEL);
> -
> -   if (!dev->_filename_ch2)
> -   goto error;
> -   } else {
> -   str_length = strlen(dev->_defaultname_ch2);
> -   dev->_filename_ch2 = kmemdup(dev->_defaultname_ch2,
> -str_length + 1, GFP_KERNEL);
> +   if (dev->input_filename_ch2)
> +   dev->_filename_ch2 = kstrdup(dev->input_filename_ch2,
> +   GFP_KERNEL);
> +   else
> +   dev->_filename_ch2 = kstrdup(dev->_defaultname_ch2,
> +   GFP_KERNEL);
>

You're replacing kmemdup for kstrdup, which is great,
but that's not anywhere in the commit message.

I'm not sure if you should re-send, but you should definitely
try to have better commit messages in the future!

Not to mention you're doing two things in one patch, and that makes
very difficult to bisect.

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

Re: [PATCH 0/3] Fix edac_mc crash in e7xxx_edac error path.

[Shaun Ruffell]

Just a friendly reminder that I'm still seeing this NULL pointer
dereference on boot with 3.6-rc4.

On Sat, Aug 18, 2012 at 11:11:21PM -0500, Shaun Ruffell wrote:
> With kernel version 3.6-rc2 on a Dell Poweredge 2600 I experienced a NULL
> pointer dereference that did not occur with on 3.5. I believe the error is
> related to commit de3910eb79a "edac: change the mem allocation scheme to make
> Documentation/kobject.txt happy" [1] and the fact that my system is going
> through an error path in the e7xxx_edac driver.
> 
> [1] 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=de3910eb79ac8c0f29a11224661c0ebaaf813039
> 
> This is the OOPS:
> 
>  [  36.703479] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
>  [  36.703479] IP: [] __wake_up_common+0x1a/0x6a
>  [  36.703479] *pde = 7f0c6067 
>  [  36.703479] Oops:  [#1] SMP 
>  [  36.703479] Modules linked in: parport_pc parport floppy e7xxx_edac(+) 
> ide_cd_mod edac_core intel_rng cdrom microcode(+) dm_snapshot dm_zero 
> dm_mirror dm_region_hash d
>  [  36.703479] Pid: 933, comm: modprobe Tainted: GW
> 3.6.0-rc2-00111-gc1999ee #12 Dell Computer Corporation PowerEdge 2600 
> /0F0364
>  [  36.703479] EIP: 0060:[] EFLAGS: 00010093 CPU: 3
>  [  36.703479] EIP is at __wake_up_common+0x1a/0x6a
>  [  36.703479] EAX: f47b0984 EBX: fff4 ECX:  EDX: 0003
>  [  36.703479] ESI: f47b0984 EDI: 0282 EBP: f3dc7d38 ESP: f3dc7d1c
>  [  36.703479]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>  [  36.703479] CR0: 8005003b CR2:  CR3: 347d4000 CR4: 07d0
>  [  36.703479] DR0:  DR1:  DR2:  DR3: 
>  [  36.703479] DR6: 0ff0 DR7: 0400
>  [  36.703479] Process modprobe (pid: 933, ti=f3dc6000 task=f3db9520 
> task.ti=f3dc6000)
>  [  36.703479] Stack:
>  [  36.703479]    0003 c046701a f47b0980 f47b0984 
> 0282 f3dc7d54
>  [  36.703479]  c046703f   f47b08b0 f47b08b0  
> f3dc7d74 c06961ce
>  [  36.703479]  f3dc7d74 f3dc7d80 c05e2837 c094c4cc f47b08b0 f47b08b0 
> f3dc7d88 c068d56d
>  [  36.703479] Call Trace:
>  [  36.703479]  [] ? complete_all+0x1a/0x50
>  [  36.703479]  [] complete_all+0x3f/0x50
>  [  36.703479]  [] device_pm_remove+0x23/0xa2
>  [  36.703479]  [] ? kobject_put+0x5b/0x5d
>  [  36.703479]  [] device_del+0x34/0x142
>  [  36.703479]  [] edac_unregister_sysfs+0x3b/0x5c [edac_core]
>  [  36.703479]  [] edac_mc_free+0x29/0x2f [edac_core]
>  [  36.703479]  [] e7xxx_probe1+0x268/0x311 [e7xxx_edac]
>  [  36.703479]  [] ? __pci_enable_device_flags+0x8f/0xd3
>  [  36.703479]  [] e7xxx_init_one+0x56/0x61 [e7xxx_edac]
>  [  36.703479]  [] local_pci_probe+0x13/0x15
>  [  36.703479]  [] pci_call_probe+0x1c/0x1e
>  [  36.703479]  [] __pci_device_probe+0x41/0x4e
>  [  36.703479]  [] pci_device_probe+0x26/0x39
>  [  36.703479]  [] really_probe+0x101/0x2a1
>  [  36.703479]  [] ? __driver_attach+0x3d/0x6e
>  [  36.703479]  [] ? __driver_attach+0x3d/0x6e
>  [  36.703479]  [] ? quirk_usb_disable_ehci+0xa3/0x141
>  [  36.703479]  [] driver_probe_device+0x35/0x79
>  [  36.703479]  [] __driver_attach+0x6c/0x6e
>  [  36.703479]  [] bus_for_each_dev+0x44/0x62
>  [  36.703479]  [] driver_attach+0x1e/0x20
>  [  36.703479]  [] ? device_attach+0x98/0x98
>  [  36.703479]  [] bus_add_driver+0xc5/0x1c8
>  [  36.703479]  [] ? store_new_id+0xfa/0xfa
>  [  36.703479]  [] driver_register+0x52/0xd6
>  [  36.703479]  [] ? 0xf8603fff
>  [  36.703479]  [] __pci_register_driver+0x4b/0x73
>  [  36.703479]  [] ? 0xf8603fff
>  [  36.703479]  [] e7xxx_init+0x55/0x57 [e7xxx_edac]
>  [  36.703479]  [] do_one_initcall+0xa3/0xe0
>  [  36.703479]  [] sys_init_module+0x70/0x1af
>  [  36.703479]  [] ? trace_hardirqs_on_caller+0x56/0xf9
>  [  36.703479]  [] ? trace_hardirqs_on_thunk+0xc/0x10
>  [  36.703479]  [] sysenter_do_call+0x12/0x32
>  [  36.703479] Code: 5d c3 55 89 e5 3e 8d 74 26 00 e8 8f ff ff ff 5d c3 55 89 
> e5 57 56 53 83 ec 10 3e 8d 74 26 00 89 55 ec 89 4d e8 8b 58 28 83 eb 0c <8b> 
> 53 0c 83 c0 28
>  [  36.703479] EIP: [] __wake_up_common+0x1a/0x6a SS:ESP 
> 0068:f3dc7d1c
>  [  36.703479] CR2: 
>  [  36.703479] ---[ end trace 6fcfddc0eef7bbd8 ]---
> 
> When I enabled edac debugging I saw the following printed to the kernel log
> prior to the above BUG:
> 
>   EDAC MC: Ver: 3.0.0
>   EDAC DEBUG: edac_mc_sysfs_init: device mc created
>   EDAC DEBUG: e7xxx_init_one:
>   EDAC DEBUG: e7xxx_probe1: mci
>   EDAC DEBUG: edac_mc_alloc: errcount layer 0 size 8
>   EDAC DEBUG: edac_mc_alloc: errcount layer 1 size 16
>   EDAC DEBUG: edac_mc_alloc: allocating 48 error counters
>   EDAC DEBUG: edac_mc_alloc: allocating 1068 bytes for mci data (16 ranks, 16 
> csrows/channels)
>   EDAC DEBUG: e7xxx_probe1: init mci
>   EDAC DEBUG: e7xxx_probe1: init pvt
>   EDAC e7xxx: error reporting device not found:vendor 8086 device 0x2541 
> (broken BIOS?)
>   EDAC DEBUG: edac_mc_free:
>   Floppy drive(s): fd0 is 1.44M
>   EDAC 

Re: [PATCH 1/2] PCI: Use local parameter pci_device_id for pci_get_subsys/class()

[Yinghai Lu]

On Sat, Sep 8, 2012 at 8:34 AM, Feng Tang  wrote:
>> This makes lspci work again on my side. The caveat is, kzalloc() will
>> zero out all data while the new local variable leaves some data
>> uninitialized.
>
> Yes, thanks for the quick root cause and fix to the bug in my code.

Can you resubmit your patch with two extra "memset" line?

Thanks

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

Re: [PATCH 4/7 V6] workqueue: fix idle worker depletion

[Lai Jiangshan]

On Sun, Sep 9, 2012 at 2:11 AM, Tejun Heo  wrote:
> On Sun, Sep 09, 2012 at 02:07:50AM +0800, Lai Jiangshan wrote:
>> when we release gcwq->lock and then grab it, we leave a hole that things
>> can be changed.
>>
>> I don't want to open a hole. if the hole has bug we have to fix it.
>> if the hole has no bug, we have to add lot of comments to explain it.
>>
>> When I write this reply. I am thinking: is the hole  has bug if
>> I release gcwq->lock here? result: no. But I don't want to add all things
>> what I have thought as comments to explain there is no bug even when we
>> open a hole. don't leave reviewers too much burden.
>
> We're already releasing gcwq->lock in maybe_create_worker().  That's
> the reason why @ret is set to true.  In addition, we already released
> the lock to grab manager_mutex.  So, you're not adding any burden.
> Please reuse the busy rebinding mechanism.
>

in 3.6 busy_worker_rebind() handle WORKER_REBIND bit,
not WORKER_UNBOUND bit.

busy_worker_rebind() takes struct work_struct *work argument, we have to
add new patch to add a helper and restruct it at first.

worker_maybe_bind_and_lock() 's mean is very clear here. busy_worker_rebind()
seems for busy workers, manager is not busy workers.

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

fscache scheduling while atomic bugs under 3.4.10-rt18

[Tvrtko Ursulin]

Hi,

I get a lot of those and was wondering if it is a generic fscache issues 
or in some way related to the RT patchset. Perhaps that the two do not 
play well together?


Traces typically look like this:

 BUG: scheduling while atomic: kworker/u:2/4151/0x0002
 Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib fuse 
ip6table_filter ip6_tables ebtable_nat ebtables cachefiles 
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 
xt_state nf_conntrack ipt_REJECT iptable_mangle xt_tcpudp iptable_filter 
ip_tables x_tables bridge stp llc kvm_amd kvm autofs4 dm_crypt joydev 
usbhid hid snd_ice1712 nfsd snd_ice17xx_ak4xxx bnep snd_ak4xxx_adda 
snd_cs8427 snd_ac97_codec nfs bluetooth snd_pcm lockd fscache 
auth_rpcgss snd_page_alloc nfs_acl ac97_bus binfmt_misc sunrpc snd_i2c 
snd_mpu401_uart snd_seq_midi microcode snd_rawmidi snd_seq_midi_event 
snd_seq snd_timer snd_seq_device snd psmouse soundcore ext4 
firewire_ohci mbcache r8169 firewire_core jbd2 mii crc_itu_t pata_atiixp 
fglrx(PO) i2c_piix4 it87 hwmon_vid raid10 raid456 async_pq async_xor xor 
async_memcpy async_raid6_recov raid6_pq async_tx raid1 linear xfs raid0 
ahci libahci

 Pid: 4151, comm: kworker/u:2 Tainted: P   O 3.4.10-rt18 #1
 Call Trace:
  [] __schedule_bug+0x43/0x45
  [] __schedule+0x64a/0x680
  [] schedule+0x29/0x80
  [] rt_spin_lock_slowlock+0x14b/0x1e4
  [] rt_spin_lock+0x21/0x30
  [] __queue_work+0x180/0x330
  [] ? ttwu_do_activate.constprop.76+0x4a/0x60
  [] queue_work_on+0x1d/0x30
  [] queue_work+0x2e/0x50
  [] ? migrate_enable+0xcb/0x1b0
  [] fscache_enqueue_object+0x65/0xd0 [fscache]
  [] fscache_object_work_func+0x342/0xa20 [fscache]
  [] ? migrate_enable+0xcb/0x1b0
  [] ? fscache_drop_object+0x170/0x170 [fscache]
  [] process_one_work+0x117/0x3a0
  [] process_scheduled_works+0x24/0x40
  [] worker_thread+0x271/0x340
  [] ? manage_workers.isra.30+0x230/0x230
  [] kthread+0x8e/0xa0
  [] ? finish_task_switch+0x49/0xf0
  [] kernel_thread_helper+0x4/0x10
  [] ? __init_kthread_worker+0x50/0x50
  [] ? gs_change+0xb/0xb

Thanks,

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

Re: [PATCH 0/7 V6] workqueue: fix hoplug things

[Lai Jiangshan]

>
> Hmmm... so, I'm having some difficulty communicating with you.  We
> need two separate patch series.  One for for-3.6-fixes and the other
> for restructuring on top of for-3.7 after the fixes are merged into
> it.
>
> As you currently posted, the patches are based on for-3.7 and fixes
> and restructuring are intermixed, so I'm asking you to separate out
> two patches to fix the idle depletion bug and base them on top of
> for-3.6-fixes.  Am I misunderstanding something?
>


Patch 3,4 are ready for 3.6 and they can be applied to 3.6 directly.
don't need to revise nor resend.
you just pick them up to for-3.6-fixes.

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

Re: [PATCH 4/7 V6] workqueue: fix idle worker depletion

[Tejun Heo]

On Sun, Sep 09, 2012 at 02:07:50AM +0800, Lai Jiangshan wrote:
> when we release gcwq->lock and then grab it, we leave a hole that things
> can be changed.
> 
> I don't want to open a hole. if the hole has bug we have to fix it.
> if the hole has no bug, we have to add lot of comments to explain it.
> 
> When I write this reply. I am thinking: is the hole  has bug if
> I release gcwq->lock here? result: no. But I don't want to add all things
> what I have thought as comments to explain there is no bug even when we
> open a hole. don't leave reviewers too much burden.

We're already releasing gcwq->lock in maybe_create_worker().  That's
the reason why @ret is set to true.  In addition, we already released
the lock to grab manager_mutex.  So, you're not adding any burden.
Please reuse the busy rebinding mechanism.

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: [PATCH 4/7 V6] workqueue: fix idle worker depletion

[Lai Jiangshan]

On Sun, Sep 9, 2012 at 1:53 AM, Tejun Heo  wrote:
> Hello,
>
> On Sun, Sep 09, 2012 at 01:50:41AM +0800, Lai Jiangshan wrote:
>> >> + if (worker_maybe_bind_and_lock(manager))
>> >> + worker_clr_flags(manager, WORKER_UNBOUND);
>> >> + }
>> >> +}
>> >
>> > We can reuse busy_worker_rebind_fn(), right?
>>
>> busy_worker_rebind_fn() releases the gcwq->lock. we can't release
>> the lock here.
>
> Why so?  Can you please elaborate?
>

when we release gcwq->lock and then grab it, we leave a hole that things
can be changed.

I don't want to open a hole. if the hole has bug we have to fix it.
if the hole has no bug, we have to add lot of comments to explain it.

When I write this reply. I am thinking: is the hole  has bug if
I release gcwq->lock here? result: no. But I don't want to add all things
what I have thought as comments to explain there is no bug even when we
open a hole. don't leave reviewers too much burden.

Thanks.
Lai.

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

[PATCH v2] watchdog: omap_wdt: convert to new watchdog core

[Aaro Koskinen]

Convert omap_wdt to new watchdog core. On OMAP boards, there are usually
multiple watchdogs. Since the new watchdog core supports multiple
watchdogs, all watchdog drivers used on OMAP should be converted.

The legacy watchdog device node is still created, so this should not
break existing users.

Signed-off-by: Aaro Koskinen 
---

v2: Fix a bug in the first version of the patch: __omap_wdt_disable()
in probe was mistakenly moved outside PM runtime calls. This caused a
crash as device was probably accessed with some clocks off. Thanks to
Jarkko Nikula  for reporting this.

 drivers/watchdog/Kconfig|1 +
 drivers/watchdog/omap_wdt.c |  266 ++-
 2 files changed, 114 insertions(+), 153 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 0526c7a..212b566 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -232,6 +232,7 @@ config EP93XX_WATCHDOG
 config OMAP_WATCHDOG
tristate "OMAP Watchdog"
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
+   select WATCHDOG_CORE
help
  Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog. 
 Say 'Y'
  here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 
watchdog timer.
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index fceec4f..1636f2c 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -31,18 +31,14 @@
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -50,24 +46,20 @@
 
 #include "omap_wdt.h"
 
-static struct platform_device *omap_wdt_dev;
-
 static unsigned timer_margin;
 module_param(timer_margin, uint, 0);
 MODULE_PARM_DESC(timer_margin, "initial watchdog timeout (in seconds)");
 
-static unsigned int wdt_trgr_pattern = 0x1234;
-static DEFINE_SPINLOCK(wdt_lock);
-
 struct omap_wdt_dev {
void __iomem*base;  /* physical */
struct device   *dev;
-   int omap_wdt_users;
+   boolomap_wdt_users;
struct resource *mem;
-   struct miscdevice omap_wdt_miscdev;
+   int wdt_trgr_pattern;
+   struct mutexlock;   /* to avoid races with PM */
 };
 
-static void omap_wdt_ping(struct omap_wdt_dev *wdev)
+static void __omap_wdt_ping(struct omap_wdt_dev *wdev)
 {
void __iomem*base = wdev->base;
 
@@ -75,8 +67,8 @@ static void omap_wdt_ping(struct omap_wdt_dev *wdev)
while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
cpu_relax();
 
-   wdt_trgr_pattern = ~wdt_trgr_pattern;
-   __raw_writel(wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
+   wdev->wdt_trgr_pattern = ~wdev->wdt_trgr_pattern;
+   __raw_writel(wdev->wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
 
/* wait for posted write to complete */
while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
@@ -84,7 +76,7 @@ static void omap_wdt_ping(struct omap_wdt_dev *wdev)
/* reloaded WCRR from WLDR */
 }
 
-static void omap_wdt_enable(struct omap_wdt_dev *wdev)
+static void __omap_wdt_enable(struct omap_wdt_dev *wdev)
 {
void __iomem *base = wdev->base;
 
@@ -98,7 +90,7 @@ static void omap_wdt_enable(struct omap_wdt_dev *wdev)
cpu_relax();
 }
 
-static void omap_wdt_disable(struct omap_wdt_dev *wdev)
+static void __omap_wdt_disable(struct omap_wdt_dev *wdev)
 {
void __iomem *base = wdev->base;
 
@@ -112,18 +104,10 @@ static void omap_wdt_disable(struct omap_wdt_dev *wdev)
cpu_relax();
 }
 
-static void omap_wdt_adjust_timeout(unsigned new_timeout)
-{
-   if (new_timeout < TIMER_MARGIN_MIN)
-   new_timeout = TIMER_MARGIN_DEFAULT;
-   if (new_timeout > TIMER_MARGIN_MAX)
-   new_timeout = TIMER_MARGIN_MAX;
-   timer_margin = new_timeout;
-}
-
-static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
+static void __omap_wdt_set_timeout(struct omap_wdt_dev *wdev,
+  unsigned int timeout)
 {
-   u32 pre_margin = GET_WLDR_VAL(timer_margin);
+   u32 pre_margin = GET_WLDR_VAL(timeout);
void __iomem *base = wdev->base;
 
/* just count up at 32 KHz */
@@ -135,16 +119,14 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev 
*wdev)
cpu_relax();
 }
 
-/*
- * Allow only one task to hold it open
- */
-static int omap_wdt_open(struct inode *inode, struct file *file)
+static int omap_wdt_start(struct watchdog_device *wdog)
 {
-   struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
+   struct omap_wdt_dev *wdev = watchdog_get_drvdata(wdog);
void __iomem *base = wdev->base;
 
-   if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
-   return -EBUSY;
+   mutex_lock(>lock);
+
+   

[PATCH 2/2 v2] Add copyright header.

[Jon Stanley]

Adding a missing copyright header to parse-utils.c. Assuminng that the
license is LGPL like the rest of the trace-cmd library code.

Signed-off-by: Jon Stanley 
Cc: Arnaldo Carvalho de Melo 
Cc: Steven Rostedt 
---
* Changes for v2 -

I seem to have forgotten to add the Signed-off-by abnd CC lines. Now included.

 tools/lib/traceevent/parse-utils.c |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/tools/lib/traceevent/parse-utils.c 
b/tools/lib/traceevent/parse-utils.c
index f023a13..bba701c 100644
--- a/tools/lib/traceevent/parse-utils.c
+++ b/tools/lib/traceevent/parse-utils.c
@@ -1,3 +1,22 @@
+/*
+ * Copyright (C) 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,  see 
+ *
+ * ~~
+ */
 #include 
 #include 
 #include 
-- 
1.7.1

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

Re: [PATCH 0/7 V6] workqueue: fix hoplug things

[Tejun Heo]

On Sun, Sep 09, 2012 at 01:56:47AM +0800, Lai Jiangshan wrote:
> > So, your worry was incorrect and the above is what we're gonna do, no?
> 
> NO BUG found for PATCH4 even idle rebinding is synchronous.

Hmmm... so, I'm having some difficulty communicating with you.  We
need two separate patch series.  One for for-3.6-fixes and the other
for restructuring on top of for-3.7 after the fixes are merged into
it.

As you currently posted, the patches are based on for-3.7 and fixes
and restructuring are intermixed, so I'm asking you to separate out
two patches to fix the idle depletion bug and base them on top of
for-3.6-fixes.  Am I misunderstanding something?

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: [PATCH 0/7 V6] workqueue: fix hoplug things

[Lai Jiangshan]

On Sun, Sep 9, 2012 at 1:50 AM, Tejun Heo  wrote:
> Hello, Lai.
>
> On Sun, Sep 09, 2012 at 01:46:59AM +0800, Lai Jiangshan wrote:
>> > * Instead of MANAGING, add pool->manager.
>> >
>> > * Fix the idle depletion bug by using pool->manager for exclusion and
>> >   always grabbing pool->manager_mutex.  Hotplug can use pool->manager
>> >   to schedule rebind work (or UNBIND) to the manager.
>> >
>> > Thoughts?
>>
>> Don't need.  my worry is wrong.
>
> So, your worry was incorrect and the above is what we're gonna do, no?

NO BUG found for PATCH4 even idle rebinding is synchronous.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/7 V6] workqueue: fix idle worker depletion

[Tejun Heo]

Hello,

On Sun, Sep 09, 2012 at 01:50:41AM +0800, Lai Jiangshan wrote:
> >> + if (worker_maybe_bind_and_lock(manager))
> >> + worker_clr_flags(manager, WORKER_UNBOUND);
> >> + }
> >> +}
> >
> > We can reuse busy_worker_rebind_fn(), right?
> 
> busy_worker_rebind_fn() releases the gcwq->lock. we can't release
> the lock here.

Why so?  Can you please elaborate?

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: [PATCH 0/7 V6] workqueue: fix hoplug things

[Tejun Heo]

On Sat, Sep 08, 2012 at 10:50:07AM -0700, Tejun Heo wrote:
> Please create two patches, first introducing pool->manager_mutex and

   ^ pool->manager

-- 
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: [PATCH 4/7 V6] workqueue: fix idle worker depletion

[Lai Jiangshan]

On Sun, Sep 9, 2012 at 1:40 AM, Tejun Heo  wrote:
> Hello, Lai.
>
> On Sun, Sep 09, 2012 at 01:12:53AM +0800, Lai Jiangshan wrote:
>> +/* does the manager need to be rebind after we just release gcwq->lock */
>> +static void maybe_rebind_manager(struct worker *manager)
>> +{
>> + struct global_cwq *gcwq = manager->pool->gcwq;
>> + bool assoc = !(gcwq->flags & GCWQ_DISASSOCIATED);
>> +
>> + if (assoc && (manager->flags & WORKER_UNBOUND)) {
>> + spin_unlock_irq(>lock);
>> +
>> + if (worker_maybe_bind_and_lock(manager))
>> + worker_clr_flags(manager, WORKER_UNBOUND);
>> + }
>> +}
>
> We can reuse busy_worker_rebind_fn(), right?

busy_worker_rebind_fn() releases the gcwq->lock. we can't release the lock here.

>
>>   pool->manager = worker;
>> + if (unlikely(!mutex_trylock(>manager_mutex))) {
>> + /*
>> +  * Ouch! rebind_workers() or gcwq_unbind_fn() beats we.
>> +  * it can't return false here, otherwise it will lead to
>> +  * worker depletion. So we release gcwq->lock and then
>> +  * grab manager_mutex again.
>> +  */
>> + spin_unlock_irq(>lock);
>> + mutex_lock(>manager_mutex);
>> + spin_lock_irq(>lock);
>> +
>> + /* rebind_workers() can happen when we release gcwq->lock */
>> + maybe_rebind_manager(worker);
>
> And we can call process_scheduled_works() here and make the CPU
> hotplug check pool->manager and schedule rebind_work there.
>

sorry again. don't need.

Thanks.
Lai

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

Re: [PATCH 0/7 V6] workqueue: fix hoplug things

[Tejun Heo]

Hello, Lai.

On Sun, Sep 09, 2012 at 01:46:59AM +0800, Lai Jiangshan wrote:
> > * Instead of MANAGING, add pool->manager.
> >
> > * Fix the idle depletion bug by using pool->manager for exclusion and
> >   always grabbing pool->manager_mutex.  Hotplug can use pool->manager
> >   to schedule rebind work (or UNBIND) to the manager.
> >
> > Thoughts?
> 
> Don't need.  my worry is wrong.

So, your worry was incorrect and the above is what we're gonna do, no?

> > Also, can you please base the fix patches on top of wq/for-3.6-fixes?
> > It's getting quite confusing.
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.6-fixes
> 
> I base on wq/for-3.7 of several days ago.
> 
> I can change the base, but which blanch should patch5,6,7 base on?

Please create two patches, first introducing pool->manager_mutex and
second fixing the depletion bug by making manager always grab
manager_mutex on top of wq/for-3.6-fixes.  For the rest of the series,
please wait for me to merge the for-3.6-fixes into for-3.7 and base on
top of them and *please* stop sending restructuring patches before the
fixes are settled.  It's wasting time for both of us.

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: [PATCH 0/7 V6] workqueue: fix hoplug things

[Lai Jiangshan]

On Sun, Sep 9, 2012 at 1:37 AM, Tejun Heo  wrote:
> Hello, Lai.
>
> On Sun, Sep 09, 2012 at 01:27:37AM +0800, Lai Jiangshan wrote:
>> On Sun, Sep 9, 2012 at 1:12 AM, Lai Jiangshan  wrote:
>> > The patch set is based on 3b07e9ca26866697616097044f25fbe53dbab693 of 
>> > wq.git
>> >
>> > Patch 1,2 are accepted. Patch 1 goes to 3.6. tj has a replacement goes
>> > to 3.6 instead of Patch 2. so Patch2 will go to 3.7. Patch2 will need
>> > to be rebased if the replacement is still in 3.7.
>> > (tj, could you help me do the rebase if I don't need to respin the patchset
>> > as V7 ?)
>> >
>> > Patch3,4 fix depletion problem, it is simple enough. it goes to 3.6.
>>
>> sorry.
>> 3.6 is synchronous idles when we use tj's replacement for patch2.
>> and maybe_rebind_manager() don't wait for idles rebind. so it can't go to 
>> 3.6.
>
> Let's get the fix down first.  I *think* we can do it for 3.6-fixes.
> Can't we do the following?
>
> * Instead of MANAGING, add pool->manager.
>
> * Fix the idle depletion bug by using pool->manager for exclusion and
>   always grabbing pool->manager_mutex.  Hotplug can use pool->manager
>   to schedule rebind work (or UNBIND) to the manager.
>
> Thoughts?

Don't need.  my worry is wrong.

>
> Also, can you please base the fix patches on top of wq/for-3.6-fixes?
> It's getting quite confusing.
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.6-fixes

I base on wq/for-3.7 of several days ago.

I can change the base, but which blanch should patch5,6,7 base on?


Thanks.
Lai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 wq/for-3.6-fixes 3/3] workqueue: fix possible idle worker depletion during CPU_ONLINE

[Tejun Heo]

On Sun, Sep 09, 2012 at 01:40:19AM +0800, Lai Jiangshan wrote:
> On Sun, Sep 9, 2012 at 1:32 AM, Tejun Heo  wrote:
> > On Sat, Sep 08, 2012 at 10:29:50AM -0700, Tejun Heo wrote:
> >> > hotplug code can't iterate manager.  not rebind_work() nor UNBOUND for 
> >> > manager.
> >>
> >> Ah, right.  It isn't either on idle or busy list.  Maybe have
> >> pool->manager pointer?
> >
> > Ooh, this is what you did with the new patchset, right?
> 
> I already did it in V5 patchset. not in new patchset. I just change it
> as you like in V6.
> I change the strategy of calling may_rebind_manager().

Yeah, you did that and a lot else too.  Let's please isolate the fixes
and think about restructuring later.

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: [PATCH 4/7 V6] workqueue: fix idle worker depletion

[Tejun Heo]

Hello, Lai.

On Sun, Sep 09, 2012 at 01:12:53AM +0800, Lai Jiangshan wrote:
> +/* does the manager need to be rebind after we just release gcwq->lock */
> +static void maybe_rebind_manager(struct worker *manager)
> +{
> + struct global_cwq *gcwq = manager->pool->gcwq;
> + bool assoc = !(gcwq->flags & GCWQ_DISASSOCIATED);
> +
> + if (assoc && (manager->flags & WORKER_UNBOUND)) {
> + spin_unlock_irq(>lock);
> +
> + if (worker_maybe_bind_and_lock(manager))
> + worker_clr_flags(manager, WORKER_UNBOUND);
> + }
> +}

We can reuse busy_worker_rebind_fn(), right?

>   pool->manager = worker;
> + if (unlikely(!mutex_trylock(>manager_mutex))) {
> + /*
> +  * Ouch! rebind_workers() or gcwq_unbind_fn() beats we.
> +  * it can't return false here, otherwise it will lead to
> +  * worker depletion. So we release gcwq->lock and then
> +  * grab manager_mutex again.
> +  */
> + spin_unlock_irq(>lock);
> + mutex_lock(>manager_mutex);
> + spin_lock_irq(>lock);
> +
> + /* rebind_workers() can happen when we release gcwq->lock */
> + maybe_rebind_manager(worker);

And we can call process_scheduled_works() here and make the CPU
hotplug check pool->manager and schedule rebind_work there.

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: [PATCH wq/for-3.6-fixes 3/3] workqueue: fix possible idle worker depletion during CPU_ONLINE

[Lai Jiangshan]

On Sun, Sep 9, 2012 at 1:32 AM, Tejun Heo  wrote:
> On Sat, Sep 08, 2012 at 10:29:50AM -0700, Tejun Heo wrote:
>> > hotplug code can't iterate manager.  not rebind_work() nor UNBOUND for 
>> > manager.
>>
>> Ah, right.  It isn't either on idle or busy list.  Maybe have
>> pool->manager pointer?
>
> Ooh, this is what you did with the new patchset, right?

I already did it in V5 patchset. not in new patchset. I just change it
as you like in V6.
I change the strategy of calling may_rebind_manager().

Thanks.
Lai

>
> --
> 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: [PATCH 0/7 V6] workqueue: fix hoplug things

[Tejun Heo]

Hello, Lai.

On Sun, Sep 09, 2012 at 01:27:37AM +0800, Lai Jiangshan wrote:
> On Sun, Sep 9, 2012 at 1:12 AM, Lai Jiangshan  wrote:
> > The patch set is based on 3b07e9ca26866697616097044f25fbe53dbab693 of wq.git
> >
> > Patch 1,2 are accepted. Patch 1 goes to 3.6. tj has a replacement goes
> > to 3.6 instead of Patch 2. so Patch2 will go to 3.7. Patch2 will need
> > to be rebased if the replacement is still in 3.7.
> > (tj, could you help me do the rebase if I don't need to respin the patchset
> > as V7 ?)
> >
> > Patch3,4 fix depletion problem, it is simple enough. it goes to 3.6.
> 
> sorry.
> 3.6 is synchronous idles when we use tj's replacement for patch2.
> and maybe_rebind_manager() don't wait for idles rebind. so it can't go to 3.6.

Let's get the fix down first.  I *think* we can do it for 3.6-fixes.
Can't we do the following?

* Instead of MANAGING, add pool->manager.

* Fix the idle depletion bug by using pool->manager for exclusion and
  always grabbing pool->manager_mutex.  Hotplug can use pool->manager
  to schedule rebind work (or UNBIND) to the manager.

Thoughts?

Also, can you please base the fix patches on top of wq/for-3.6-fixes?
It's getting quite confusing.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.6-fixes

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: [PATCH 0/7 V6] workqueue: fix hoplug things

[Lai Jiangshan]

On Sun, Sep 9, 2012 at 1:12 AM, Lai Jiangshan  wrote:
> The patch set is based on 3b07e9ca26866697616097044f25fbe53dbab693 of wq.git
>
> Patch 1,2 are accepted. Patch 1 goes to 3.6. tj has a replacement goes
> to 3.6 instead of Patch 2. so Patch2 will go to 3.7. Patch2 will need
> to be rebased if the replacement is still in 3.7.
> (tj, could you help me do the rebase if I don't need to respin the patchset
> as V7 ?)
>
> Patch3,4 fix depletion problem, it is simple enough. it goes to 3.6.

sorry.
3.6 is synchronous idles when we use tj's replacement for patch2.
and maybe_rebind_manager() don't wait for idles rebind. so it can't go to 3.6.

Choice1: also push Patch 2(async idle rebinding) to 3.6? thus patch 4
can goto 3.6 too.
Choice2: add workaroud and make patch4 and make it go to 3.6. (add some code.)

Thanks.
Lai

>
> Patch 5,6,7 are clean up. -> 3.7
>
>
> Lai Jiangshan (7):
>   workqueue: ensure the wq_worker_sleeping() see the right flags
>   workqueue: async idle rebinding
>   workqueue:  add manager pointer for worker_pool
>   workqueue: fix idle worker depletion
>   workqueue: rename manager_mutex to assoc_mutex
>   workqueue: new day don't need WORKER_REBIND for busy rebinding
>   workqueue: remove WORKER_REBIND
>
>  kernel/workqueue.c |  195 
> +++-
>  1 files changed, 85 insertions(+), 110 deletions(-)
>
> --
> 1.7.4.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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7 V6] workqueue: fix hoplug things

[Lai Jiangshan]

On Sun, Sep 9, 2012 at 1:27 AM, Lai Jiangshan  wrote:
> On Sun, Sep 9, 2012 at 1:12 AM, Lai Jiangshan  wrote:
>> The patch set is based on 3b07e9ca26866697616097044f25fbe53dbab693 of wq.git
>>
>> Patch 1,2 are accepted. Patch 1 goes to 3.6. tj has a replacement goes
>> to 3.6 instead of Patch 2. so Patch2 will go to 3.7. Patch2 will need
>> to be rebased if the replacement is still in 3.7.
>> (tj, could you help me do the rebase if I don't need to respin the patchset
>> as V7 ?)
>>
>> Patch3,4 fix depletion problem, it is simple enough. it goes to 3.6.
>
> sorry.
> 3.6 is synchronous idles when we use tj's replacement for patch2.
> and maybe_rebind_manager() don't wait for idles rebind. so it can't go to 3.6.
>
> Choice1: also push Patch 2(async idle rebinding) to 3.6? thus patch 4
> can goto 3.6 too.
> Choice2: add workaroud and make patch4 and make it go to 3.6. (add some code.)
>

Sorry again. the above worry is incorrect.
maybe_rebind_manager() **DO** wait for idles rebind via
mutex_lock(manager_lock).
so it is safe to 3.6.

sorry. don't worry anything. I just think it without code.

Thanks
Lai

>
>>
>> Patch 5,6,7 are clean up. -> 3.7
>>
>>
>> Lai Jiangshan (7):
>>   workqueue: ensure the wq_worker_sleeping() see the right flags
>>   workqueue: async idle rebinding
>>   workqueue:  add manager pointer for worker_pool
>>   workqueue: fix idle worker depletion
>>   workqueue: rename manager_mutex to assoc_mutex
>>   workqueue: new day don't need WORKER_REBIND for busy rebinding
>>   workqueue: remove WORKER_REBIND
>>
>>  kernel/workqueue.c |  195 
>> +++-
>>  1 files changed, 85 insertions(+), 110 deletions(-)
>>
>> --
>> 1.7.4.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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 wq/for-3.6-fixes 3/3] workqueue: fix possible idle worker depletion during CPU_ONLINE

[Tejun Heo]

On Sat, Sep 08, 2012 at 10:29:50AM -0700, Tejun Heo wrote:
> > hotplug code can't iterate manager.  not rebind_work() nor UNBOUND for 
> > manager.
> 
> Ah, right.  It isn't either on idle or busy list.  Maybe have
> pool->manager pointer?

Ooh, this is what you did with the new patchset, right?

-- 
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: [PATCH wq/for-3.6-fixes 3/3] workqueue: fix possible idle worker depletion during CPU_ONLINE

[Tejun Heo]

Hello, Lai.

On Sun, Sep 09, 2012 at 01:18:25AM +0800, Lai Jiangshan wrote:
> > +   /*
> > +* CPU hotplug could have scheduled rebind_work while we're
> > +* waiting for manager_mutex.  Rebind before doing anything
> > +* else.  This has to be handled here.  worker_thread()
> > +* will be confused by the unexpected work item.
> > +*/
> > +   process_scheduled_works(worker);
> 
> hotplug code can't iterate manager.  not rebind_work() nor UNBOUND for 
> manager.

Ah, right.  It isn't either on idle or busy list.  Maybe have
pool->manager pointer?

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: HDD problem, software bug, bios bug, or hardware ?

[Adko Branil]

>Please try the patch below, which implements the fix I described a

>week ago. It's for 3.6-rc4 but should work in any recent kernel.
>Without this patch one of my test machines always throws a lockdep
>warning involving pdc_sata_hardreset and pdc_interrupt during bootup,
>but with the patch the warning is gone, as expected.

>If it works for you I'll add your Tested-by: and submit it properly.

>/Mikael


I will be able to try it no sooner than next week.


Thanks !

Regards
Adko.

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