Re: [PATCH] arch/x86/realmode: make trampoline code conditional for x86-32
On Wed, Oct 15, 2014 at 08:47:11AM -0700, H. Peter Anvin wrote: > On 10/15/2014 08:38 AM, Jarkko Sakkinen wrote: > > Trampoline code is only needed for SMP and in x86-64 for wakeup > > code. Make it conditional in order to minimize the kernel size. > > > > Signed-off-by: Jarkko Sakkinen > > --- > > arch/x86/realmode/rm/Makefile | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile > > index 7c0d7be..82b7312 100644 > > --- a/arch/x86/realmode/rm/Makefile > > +++ b/arch/x86/realmode/rm/Makefile > > @@ -20,7 +20,11 @@ wakeup-objs += video-vesa.o > > wakeup-objs+= video-bios.o > > > > realmode-y += header.o > > +ifdef CONFIG_X86_64 > > realmode-y += trampoline_$(BITS).o > > +else > > +realmode-$(CONFIG_SMP) += trampoline_$(BITS).o > > +endif > > realmode-y += stack.o > > realmode-y += reboot.o > > realmode-$(CONFIG_ACPI_SLEEP) += $(wakeup-objs) > > > > It is usually preferred to make this a hidden config option (e.g. > CONFIG_X86_TRAMPOLINE) rather than use ifdef, especially since your > ifdef has another conditional inside it. OK, I'll revise the patch, thanks. > -hpa /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 2/4] i2c: add support for Diolan DLN-2 USB-I2C adapter
On Wed, Oct 15, 2014 at 05:48:09PM +0300, Octavian Purdila wrote: > From: Laurentiu Palcu > > This patch adds support for the Diolan DLN-2 I2C master module. Due > to hardware limitations it does not support SMBUS quick commands. > > Information about the USB protocol interface can be found in the > Programmer's Reference Manual [1], see section 6.2.2 for the I2C > master module commands and responses. > > [1] https://www.diolan.com/downloads/dln-api-manual.pdf > > Signed-off-by: Laurentiu Palcu > Signed-off-by: Octavian Purdila For the I2C part: Acked-by: Wolfram Sang I assume this goes together with the other patches. If I should pick it, let me know. signature.asc Description: Digital signature
Re: [PATH v3 0/4] i2c: show and change bus frequency via sysfs
On Wed, Oct 15, 2014 at 11:03:27PM +0300, Octavian Purdila wrote: > This patch series adds support to show and change the bus frequency > via sysfs, by exposing files to show the minimum, maximum and current > frequency as well as allowing the frequency to be changed. This allows > the user to view or change the bus frequency on a per bus level. To give you some early feedback. Patches 1-2 are nice, will review them somewhen, no general issues here. For patch 3, I am not convinced that sysfs is the right mechanism. Maybe configfs, yet I have never dealt with it, so far. So, looking into this might take more time since I have other core changes pending before that. signature.asc Description: Digital signature
Re: [PATCH v6] mmc: dw_mmc: Add IDMAC 64-bit address mode support
Hi, Prabu.
On 10/15/2014 09:05 PM, Vivek Gautam wrote:
> Hi Prabu,
>
>
> On Tue, Oct 14, 2014 at 5:41 PM, Alim Akhtar wrote:
>> Hi Prahu,
>> Thanks for a quick re-spin o the patch.
>> One last comment, this is more of a information seek.
>> On Thu, Oct 9, 2014 at 1:09 PM, Prabu Thangamuthu
>> wrote:
>>> Synopsys DW_MMC IP core supports Internal DMA Controller with 64-bit
>>> address mode from IP version 2.70a onwards.
>>> Updated the driver to support IDMAC 64-bit addressing mode.
>>>
>>> Tested the features in DW_MMC core v2.70a and v2.40a with HAPS-51 setup and
>>> driver is working fine.
>>>
>>> Signed-off-by: Prabu Thangamuthu
>>> ---
>>> Change log v6:
>>> - Updated with review comment.
>>>
>>> Change log v5:
>>> - Recreated the patch against linux-next as this patch is required
>>> for another patch http://www.spinics.net/lists/arm-kernel/msg357985.html
>>>
>>> Change log v4:
>>> - Add the dynamic support for 32-bit and 64-bit address mode based
>>> on hw configuration.
>>> - Removed the CONFIG_MMC_DW_IDMAC_64BIT_ADDRESS macro.
>>>
>>> drivers/mmc/host/dw_mmc.c | 195
>>> +++-
>>> drivers/mmc/host/dw_mmc.h | 11 +++
>>> include/linux/mmc/dw_mmc.h |2 +
>>> 3 files changed, 170 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 69f0cc6..c3b75a5 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -62,6 +62,24 @@
>>> SDMMC_IDMAC_INT_FBE | SDMMC_IDMAC_INT_RI |
>>> \
>>> SDMMC_IDMAC_INT_TI)
>>>
>>> +struct idmac_desc_64addr {
>>> + u32 des0; /* Control Descriptor */
>>> +
>>> + u32 des1; /* Reserved */
>> What is the default value of these _Reserved_ descriptors? As these
>> are pointers, do you thing initializing then to zero make sense?
>
> I think the default reset value of these descriptors will depend on
> how dwmmc is integrated in h/w and how these descriptors are then
> configured.
>
> So it makes sense to initialize these descriptors to zero before use.
> We have seen on our exynos7 system, that we need to initialize the
> descriptors des1 and des2 to zero before we use them further.
I agreed with Vivek and Alim's comment.
And I think you can fix the below compile warning.
drivers/mmc/host/dw_mmc.c: In function ‘dw_mci_idmac_init’:
drivers/mmc/host/dw_mmc.c:542:21: warning: right shift count >= width of type
[enabled by default]
drivers/mmc/host/dw_mmc.c:547:3: warning: right shift count >= width of type
[enabled by default]
drivers/mmc/host/dw_mmc.c:575:3: warning: right shift count >= width of type
[enabled by default]
I will check this patch with 2.70a and other version.
Best Regards,
Jaehoon Chung
>
>>> +
>>> + u32 des2; /*Buffer sizes */
>>> +#define IDMAC_64ADDR_SET_BUFFER1_SIZE(d, s) \
>>> + ((d)->des2 = ((d)->des2 & 0x03ffe000) | ((s) & 0x1fff))
>>> +
>>> + u32 des3; /* Reserved */
>>> +
>>> + u32 des4; /* Lower 32-bits of Buffer Address Pointer
>>> 1*/
>>> + u32 des5; /* Upper 32-bits of Buffer Address Pointer
>>> 1*/
>>> +
>>> + u32 des6; /* Lower 32-bits of Next Descriptor Address
>>> */
>>> + u32 des7; /* Upper 32-bits of Next Descriptor Address
>>> */
>>> +};
>>> +
>>> struct idmac_desc {
>>> u32 des0; /* Control Descriptor */
>>> #define IDMAC_DES0_DIC BIT(1)
>>> @@ -414,30 +432,66 @@ static void dw_mci_translate_sglist(struct dw_mci
>>> *host, struct mmc_data *data,
>>> unsigned int sg_len)
>>> {
>>> int i;
>>> - struct idmac_desc *desc = host->sg_cpu;
>>> + if (host->dma_64bit_address == 1) {
>>> + struct idmac_desc_64addr *desc = host->sg_cpu;
>>>
>>> - for (i = 0; i < sg_len; i++, desc++) {
>>> - unsigned int length = sg_dma_len(&data->sg[i]);
>>> - u32 mem_addr = sg_dma_address(&data->sg[i]);
>>> + for (i = 0; i < sg_len; i++, desc++) {
>>> + unsigned int length = sg_dma_len(&data->sg[i]);
>>> + u64 mem_addr = sg_dma_address(&data->sg[i]);
>>>
>>> - /* Set the OWN bit and disable interrupts for this
>>> descriptor */
>>> - desc->des0 = IDMAC_DES0_OWN | IDMAC_DES0_DIC |
>>> IDMAC_DES0_CH;
>>> + /*
>>> +* Set the OWN bit and disable interrupts for this
>>> +* descriptor
>>> +*/
>>> + desc->des0 = IDMAC_DES0_OWN | IDMAC_DES0_DIC |
>>> + IDMAC_DES0_CH;
>>> + /* Buffer length */
>>> + IDMAC_64ADDR_SET_BUFFER1_SIZE(desc, length);
>>>
[GIT PULL] MTD updates for 3.18
Hi Linus, Sorry for delaying this a bit later than usual. There's one mild regression from 3.16 that was noticed during the 3.17 cycle, and I meant to send a fix for it along with this pull request. I'll probably try to queue it up for a later pull request once I've had a better look at it, hopefully by -rc2 at the latest. The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) are available in the git repository at: git://git.infradead.org/linux-mtd.git tags/for-linus-20141015 for you to fetch changes up to 8b3d58e554453ab858bbb169d93b7321bdc628d4: mtd: nand: omap: Correct CONFIG_MTD_NAND_OMAP_BCH help message (2014-10-06 23:40:09 -0700) MTD updates for 3.18 NAND * Cleanup for Denali driver * Atmel: add support for new page sizes * Atmel: fix up 'raw' mode support * Atmel: miscellaneous cleanups * New timing mode helpers for non-ONFI NAND * OMAP: allow driver to be (properly) built as a module * bcm47xx: RESET support and other cleanups SPI NOR * Miscellaneous cleanups, to prepare framework for wider use (some further work still pending) * Compile-time configuration to select 4K vs. 64K support for flash that support both (necessary for using UBIFS on some SPI NOR) A few scattered code quality fixes, detected by Coverity See the changesets for more. Aaron Sierra (2): mtd: physmap_of: Fix ROM support via OF mtd: physmap_of: Add non-obsolete map_rom probe Aaron Wu (1): mtd: gpio_flash: handle case where offset + len exceeds the window size Boris BREZILLON (3): mtd: nand: atmel_nand: retrieve NFC clock mtd: nand: support ONFI timing mode retrieval for non-ONFI NANDs mtd: nand: add Hynix's H27UCG8T2ATR-BC to nand_ids table Brian Norris (16): mtd: cfi_cmdset_0002: allow retry/timeout loop to exit mtd: correct upper bounds check for mtd_*() APIs mtd: sm_ftl: initialize error code mtd: remove dead non-char logic mtd: mtdswap: fix integer overflow mtd: tests: fix integer overflow issues mtd: use __packed shorthand mtd: nand: denali: set proper error code on timeout mtd: nandsim: fix integer widening mtd: maps: solutionengine: drop excess dependency mtd: nand: fix integer widening problems mtd: terminate user-provided string Merge l2-mtd/next into l2-mtd/master Merge tag 'v3.17-rc5' from upstream mtd: denali: remove another set-but-unused variable MAINTAINERS: add l2-mtd.git, 'next' tree for MTD Dan Carpenter (1): mtd: ndfc: silence an array underflow static checker warning Ezequiel Garcia (1): mtd: nand: Force omap_elm to be built as a module if omap2_nand is a module Ezequiel García (4): nand: omap2: Add support for flash-based bad block table nand: omap2: Remove horrible ifdefs to fix module probe nand: omap2: Replace pr_err with dev_err mtd: nand: Move ELM driver and rename as omap_elm Geert Uytterhoeven (1): mtd: nand: Use ULL-suffix for big u64 constant Martin Kepplinger (1): mtd: use NULL instead of 0 for an address Masahiro Yamada (9): mtd: denali: avoid using a magic number mtd: denali: fix the format of comment blocks mtd: denali: remove unnecessary variable initializations mtd: denali: remove unnecessary casts mtd: denali: change the type of iterators to int mtd: denali: remove a set-but-unused variable mtd: denali: fix include guard and license block of denali.h mtd: denali: remove unnecessary parentheses mtd: denali: fix indents and other trivial things Rafał Miłecki (11): mtd: spi-nor: remove duplicated w25q128 entry mtd: spi-nor: drop jedec_probe /helper/ function mtd: bcm47xxpart: find NVRAM partitions in middle blocks mtd: bcm47xxnflash: fix typo in freq calculation mtd: bcm47xxnflash: add dev_ready and fill chip_delay mtd: bcm47xxnflash: add cmd_ctrl handler mtd: bcm47xxnflash: NAND_CMD_RESET support mtd: bcm47xxnflash: replace some magic numbers mtd: nand: don't break long print messages mtd: spi-nor: add Kconfig option to disable 4K sectors mtd: move support for struct flash_platform_data into m25p80 Randy Dunlap (1): mtd: fix linux/mtd/nand.h kernel-doc warning Raphaël Poggi (1): mtd: atmel_nand: increase chip_delay Roger Quadros (1): mtd: nand: omap: Correct CONFIG_MTD_NAND_OMAP_BCH help message Samarth Parikh (1): mtd: Fixed checkpatch seq_printf warnings Thomas Petazzoni (1): mtd: spi-nor: add support for Micron M25PX80 Wei Yongjun (1): mtd: atmel_nand: remove redundant dev_err call White Ding (1): mtd: nand: fix nand_lock/unlock() function Wu, Josh (4):
Re: How can I check creator of probe point?
I'm going to try them.
Thanks a lot.
2014-10-16 오후 3:00, Masami Hiramatsu 쓴 글:
> Hello Gioh,
>
> If you can use ftrace and perftool, you can also put probes on
> caller site. perf-probe will give you source-code level probes.
> Or, just trace kmalloc event with ftrace stacktrace option, which
> gives you caller information so that you can filter your driver
> by postprocessing.
>
> Thank you,
>
> (2014/10/14 11:16), Gioh Kim wrote:
>>
>> Hi,
>>
>> I am trying to find a way to make statistics for memory allocation of my
>> device driver.
>> I want to know how much memory it allocates and how many times it calls
>> kmalloc().
>>
>> So I am considering to use kprobe but I think it doesn't provide a way to
>> identify who makes the probe point.
>> Can I distinguish kmalloc() calling only from my driver?
>>
>> For example I think it could be like this:
>>
>> diff --git a/samples/kprobes/kretprobe_example.c
>> b/samples/kprobes/kretprobe_example.c
>> index 1041b67..5322e0a 100644
>> --- a/samples/kprobes/kretprobe_example.c
>> +++ b/samples/kprobes/kretprobe_example.c
>> @@ -32,6 +32,7 @@ MODULE_PARM_DESC(func, "Function to kretprobe; this module
>> will report the"
>>
>> /* per-instance private data */
>> struct my_data {
>> + unsigned long signature;
>> ktime_t entry_stamp;
>> };
>>
>> @@ -43,8 +44,10 @@ static int entry_handler(struct kretprobe_instance *ri,
>> struct pt_regs *regs)
>> if (!current->mm)
>> return 1; /* Skip kernel threads */
>>
>> - data = (struct my_data *)ri->data;
>> - data->entry_stamp = ktime_get();
>> + if (signature == 0xabcdabcd) {
>> + data = (struct my_data *)ri->data;
>> + data->entry_stamp = ktime_get();
>> + }
>> return 0;
>> }
>>
>> @@ -60,10 +63,12 @@ static int ret_handler(struct kretprobe_instance *ri,
>> struct pt_regs *regs)
>> s64 delta;
>> ktime_t now;
>>
>> - now = ktime_get();
>> - delta = ktime_to_ns(ktime_sub(now, data->entry_stamp));
>> - printk(KERN_INFO "%s returned %d and took %lld ns to execute\n",
>> - func_name, retval, (long long)delta);
>> + if (signature == 0xabcdabcd) {
>> + now = ktime_get();
>> + delta = ktime_to_ns(ktime_sub(now, data->entry_stamp));
>> + printk(KERN_INFO "%s returned %d and took %lld ns to
>> execute\n",
>> + func_name, retval, (long long)delta);
>> + }
>> return 0;
>> }
>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
lening bieden
Goedenavond Wij bieden nu de zakelijke en persoonlijke leningen: de kosten zijn laag Flexibele aflossingsperiode 1-25 jaar. Voor meer informatie en uitleg Mijn e-mail: i...@pretmv100.com This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/27] Fix common bug in most nand drivers not showing a device in sysfs
Hello, I wonder if anyone else will fix this in a maintainer-approved style which doesn't use these evil leftovers from C666 called functions. Or will the sysfs for most NAND drivers be knowingly broken forever? Regards, Alexander Holler Am 27.05.2014 00:12, schrieb Alexander Holler: A comment in mtdcore.c function add_mtd_device() which is called by mtd_device_parse_register() made me wonder: "Caller should have set dev.parent to match the physical device." In fact this is not done by most nand drivers. What follows is a series which fixes this. Tested: orion and omap2 Compile-Tested: atmel, gpio, fsmc, gpmi, plat, pxa3xx, s3c2410, sh_flctl, sharpsl, tmio, docg4, davinci, lpc32xx_mlc, lpc32xx_slc, mxc Not tested at all (only be view, patches 19-27): bcm47, fsl_elbc, fsl_upm, fsl_ifc, jz4740, mpc5121m, ndfc, txx9ndfmx, socrates The overall stat is 27 files changed, 36 insertions(+), 80 deletions(-) and it fixes 21 of these bugs. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/
[GIT PULL REQUEST] md updates for 3.18
Hi Linus, here are some md updates for 3.18. Thanks, NeilBrown The following changes since commit 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93: md/raid5: disable 'DISCARD' by default due to safety concerns. (2014-10-02 13:45:00 +1000) are available in the git repository at: git://neil.brown.name/md tags/md/3.18 for you to fetch changes up to b395f75eabb3844c99244928293796ff42feaa3d: lib/raid6: Add log level to printks (2014-10-14 13:08:29 +1100) md updates for 3.18 - a few minor bug fixes - quite a lot of code tidy-up and simplification - remove PRINT_RAID_DEBUG ioctl. I'm fairly sure it is unused, and it isn't particularly useful. Anton Blanchard (1): lib/raid6: Add log level to printks Chao Yu (1): md: avoid potential long delay under pers_lock Markus Stockhausen (1): md/raid5: fix init_stripe() inconsistencies NeilBrown (18): md/bitmap: always wait for writes on unplug. md/raid1: minor typos and reformatting. md: use set_bit/clear_bit instead of shift/mask for bi_flags changes. md/raid10: another memory leak due to reshape. md/raid1: process_checks doesn't use its return value. md: be more relaxed about stopping an array which isn't started. md: use wait_event() to simplify md_super_wait() md: discard find_rdev_nr in favour of find_rdev_nr_rcu md: simplify export_array() md: Just use RCU when checking for overlap between arrays. md: don't start resync thread directly from md thread. md: remove unwanted white space from md.c md: don't allow "-sync" to be set for device in an active array. md: remove unnecessary test for MD_MAJOR in md_ioctl() md: clean up 'exit' labels in md_ioctl(). md: remove MD_BUG() md: discard PRINT_RAID_DEBUG ioctl md: move EXPORT_SYMBOL to after function in md.c drivers/md/bitmap.c| 16 +- drivers/md/linear.c| 8 +- drivers/md/md.c| 601 + drivers/md/md.h| 34 ++- drivers/md/multipath.c | 28 +- drivers/md/raid0.c | 9 +- drivers/md/raid1.c | 37 +-- drivers/md/raid1.h | 2 - drivers/md/raid10.c| 18 +- drivers/md/raid5.c | 29 +- drivers/md/raid5.h | 4 +- include/uapi/linux/raid/md_u.h | 1 - lib/raid6/algos.c | 12 +- 13 files changed, 266 insertions(+), 533 deletions(-) pgpix8NFBOkld.pgp Description: OpenPGP digital signature
[git pull] Please pull mpe.git for-linus branch (for powerpc)
Hi Linus, There was a bit of a misunderstanding between us and the ARM guys in the device tree PCI code, which is breaking virtio on powerpc. This is the minimal fix until we can sort it out properly. cheers The following changes since commit 0429fbc0bdc297d64188483ba029a23773ae07b0: Merge branch 'for-3.18-consistent-ops' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu (2014-10-15 07:48:18 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git for-linus for you to fetch changes up to aeba3731b150188685225b510886f1370d8814de: powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change (2014-10-16 14:19:07 +1100) Michael Ellerman (1): powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change arch/powerpc/kernel/pci-common.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) signature.asc Description: This is a digitally signed message part
[PATCH] xen: avoid race in p2m handling
When a new p2m leaf is allocated this leaf is linked into the p2m tree
via cmpxchg. Unfortunately the compare value for checking the success
of the update is read after checking for the need of a new leaf. It is
possible that a new leaf has been linked into the tree concurrently
in between. This could lead to a leaked memory page and to the loss of
some p2m entries.
Avoid the race by using the read compare value for checking the need
of a new p2m leaf.
Signed-off-by: Juergen Gross
---
arch/x86/xen/p2m.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index d1b3da2..8c1a278 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -532,6 +532,7 @@ static bool alloc_p2m(unsigned long pfn)
unsigned topidx, mididx;
unsigned long ***top_p, **mid;
unsigned long *top_mfn_p, *mid_mfn;
+ unsigned long *p2m_orig;
topidx = p2m_top_index(pfn);
mididx = p2m_mid_index(pfn);
@@ -579,11 +580,10 @@ static bool alloc_p2m(unsigned long pfn)
}
}
- if (p2m_top[topidx][mididx] == p2m_identity ||
- p2m_top[topidx][mididx] == p2m_missing) {
+ p2m_orig = p2m_top[topidx][mididx];
+ if (p2m_orig == p2m_identity || p2m_orig == p2m_missing) {
/* p2m leaf page is missing */
unsigned long *p2m;
- unsigned long *p2m_orig = p2m_top[topidx][mididx];
p2m = alloc_p2m_page();
if (!p2m)
--
1.8.4.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/
LED LENSER X21 Flashlight
Dear friend Glad to hear that you're on the market for LED LENSER flashlight products. We do LED LENSER Wholesale all around the world. Our LED LENSER Products are all of high quality and the most competitive price, which are highly spoke of by our cooperant customers. Now we're looking for new big buyers. For more information,please contact us in any time it will be our honor to serve you well and be your supplier It's my great honor to hear from you soon ! Best wishes Hellen JRS Technology Co.,Ltd E-mail : sa...@jrs-tech.net Msn: techj...@msn.cn Skype: techjrsa we would be grateful if you will be our led lenser catalogue reserved for your supervisor.
Re: How can I check creator of probe point?
Hello Gioh,
If you can use ftrace and perftool, you can also put probes on
caller site. perf-probe will give you source-code level probes.
Or, just trace kmalloc event with ftrace stacktrace option, which
gives you caller information so that you can filter your driver
by postprocessing.
Thank you,
(2014/10/14 11:16), Gioh Kim wrote:
>
> Hi,
>
> I am trying to find a way to make statistics for memory allocation of my
> device driver.
> I want to know how much memory it allocates and how many times it calls
> kmalloc().
>
> So I am considering to use kprobe but I think it doesn't provide a way to
> identify who makes the probe point.
> Can I distinguish kmalloc() calling only from my driver?
>
> For example I think it could be like this:
>
> diff --git a/samples/kprobes/kretprobe_example.c
> b/samples/kprobes/kretprobe_example.c
> index 1041b67..5322e0a 100644
> --- a/samples/kprobes/kretprobe_example.c
> +++ b/samples/kprobes/kretprobe_example.c
> @@ -32,6 +32,7 @@ MODULE_PARM_DESC(func, "Function to kretprobe; this module
> will report the"
>
> /* per-instance private data */
> struct my_data {
> + unsigned long signature;
> ktime_t entry_stamp;
> };
>
> @@ -43,8 +44,10 @@ static int entry_handler(struct kretprobe_instance *ri,
> struct pt_regs *regs)
> if (!current->mm)
> return 1; /* Skip kernel threads */
>
> - data = (struct my_data *)ri->data;
> - data->entry_stamp = ktime_get();
> + if (signature == 0xabcdabcd) {
> + data = (struct my_data *)ri->data;
> + data->entry_stamp = ktime_get();
> + }
> return 0;
> }
>
> @@ -60,10 +63,12 @@ static int ret_handler(struct kretprobe_instance *ri,
> struct pt_regs *regs)
> s64 delta;
> ktime_t now;
>
> - now = ktime_get();
> - delta = ktime_to_ns(ktime_sub(now, data->entry_stamp));
> - printk(KERN_INFO "%s returned %d and took %lld ns to execute\n",
> - func_name, retval, (long long)delta);
> + if (signature == 0xabcdabcd) {
> + now = ktime_get();
> + delta = ktime_to_ns(ktime_sub(now, data->entry_stamp));
> + printk(KERN_INFO "%s returned %d and took %lld ns to
> execute\n",
> + func_name, retval, (long long)delta);
> + }
> return 0;
> }
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 10/10] uprobes: Remove "weak" from function declarations
* Bjorn Helgaas [2014-10-15 11:06:50]:
> For the following interfaces:
>
> set_swbp()
> set_orig_insn()
> is_swbp_insn()
> is_trap_insn()
> uprobe_get_swbp_addr()
> arch_uprobe_ignore()
> arch_uprobe_copy_ixol()
>
> kernel/events/uprobes.c provides default definitions explicitly marked
> "weak". Some architectures provide their own definitions intended to
> override the defaults, but the "weak" attribute on the declarations applied
> to the arch definitions as well, so the linker chose one based on link
> order (see 10629d711ed7 ("PCI: Remove __weak annotation from
> pcibios_get_phb_of_node decl")).
>
> Remove the "weak" attribute from the declarations so we always prefer a
> non-weak definition over the weak one, independent of link order.
>
Acked-by: Srikar Dronamraju
> Signed-off-by: Bjorn Helgaas
> CC: Victor Kamensky
> CC: Oleg Nesterov
> CC: David A. Long
> CC: Srikar Dronamraju
> CC: Ananth N Mavinakayanahalli
> ---
> include/linux/uprobes.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> index 4f844c6b03ee..60beb5dc7977 100644
> --- a/include/linux/uprobes.h
> +++ b/include/linux/uprobes.h
> @@ -98,11 +98,11 @@ struct uprobes_state {
> struct xol_area *xol_area;
> };
>
> -extern int __weak set_swbp(struct arch_uprobe *aup, struct mm_struct *mm,
> unsigned long vaddr);
> -extern int __weak set_orig_insn(struct arch_uprobe *aup, struct mm_struct
> *mm, unsigned long vaddr);
> -extern bool __weak is_swbp_insn(uprobe_opcode_t *insn);
> -extern bool __weak is_trap_insn(uprobe_opcode_t *insn);
> -extern unsigned long __weak uprobe_get_swbp_addr(struct pt_regs *regs);
> +extern int set_swbp(struct arch_uprobe *aup, struct mm_struct *mm, unsigned
> long vaddr);
> +extern int set_orig_insn(struct arch_uprobe *aup, struct mm_struct *mm,
> unsigned long vaddr);
> +extern bool is_swbp_insn(uprobe_opcode_t *insn);
> +extern bool is_trap_insn(uprobe_opcode_t *insn);
> +extern unsigned long uprobe_get_swbp_addr(struct pt_regs *regs);
> extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
> extern int uprobe_write_opcode(struct mm_struct *mm, unsigned long vaddr,
> uprobe_opcode_t);
> extern int uprobe_register(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc);
> @@ -128,8 +128,8 @@ extern bool arch_uprobe_xol_was_trapped(struct
> task_struct *tsk);
> extern int arch_uprobe_exception_notify(struct notifier_block *self,
> unsigned long val, void *data);
> extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs
> *regs);
> extern unsigned long arch_uretprobe_hijack_return_addr(unsigned long
> trampoline_vaddr, struct pt_regs *regs);
> -extern bool __weak arch_uprobe_ignore(struct arch_uprobe *aup, struct
> pt_regs *regs);
> -extern void __weak arch_uprobe_copy_ixol(struct page *page, unsigned long
> vaddr,
> +extern bool arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs
> *regs);
> +extern void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
>void *src, unsigned long len);
> #else /* !CONFIG_UPROBES */
> struct uprobes_state {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Thanks and Regards
Srikar Dronamraju
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at fs/ext4/inode.c:2982!
Just hit this on Linus' current tree while running my fuzz-tester. (No logs unfortunatly, so no idea what actually happened). kernel BUG at fs/ext4/inode.c:2982! invalid opcode: [#1] SMP DEBUG_PAGEALLOC Modules linked in: hidp rfcomm af_key llc2 can_bcm sctp libcrc32c can_raw nfc caif_socket caif af_802154 ieee802154 phonet af_rxrpc bluetooth can pppoe pppox ppp_generic slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx p8023 p8022 psnap llc ax25 nouveau cfg80211 rfkill kvm_intel kvm video backlight mxm_wmi wmi i2c_algo_bit drm_kms_helper ttm drm microcode tg3 serio_raw pcspkr ptp pps_core libphy i2c_core lpc_ich mfd_core rtc_cmos shpchp nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc raid0 floppy CPU: 3 PID: 24261 Comm: trinity-c10 Not tainted 3.17.0+ #5 Hardware name: Dell Inc. Precision WorkStation 490/0DT031, BIOS A08 04/25/2008 task: 8802094ccb40 ti: 8800bc168000 task.ti: 8800bc168000 RIP: 0010:[] [] ext4_direct_IO+0x713/0x750 RSP: 0018:8800bc16ba78 EFLAGS: 00010246 RAX: 0002 RBX: 0001 RCX: 000f RDX: 0008 RSI: 880033e368d0 RDI: 8802094cd3b8 RBP: 8800bc16baf8 R08: 0001 R09: R10: 0001 R11: 0001 R12: 8800bc16bd40 R13: 880033e368d0 R14: 8800bc16bb30 R15: 001f FS: 7f8cc4e8f740() GS:88022640() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0001 CR3: b7747000 CR4: 07e0 DR0: 01c16000 DR1: 0160a000 DR2: DR3: DR6: 0ff0 DR7: 0600 Stack: ea000560a600 ea00060dc480 ea000503d880 ea0005cbfc80 ea00056e6500 ea00049b1780 880033e368d0 ea0005da7980 0001 0001 8800bc16baf8 880033e36ae0 Call Trace: [] generic_file_direct_write+0xa9/0x170 [] __generic_file_write_iter+0x2ac/0x350 [] ext4_file_write_iter+0x109/0x3f0 [] ? __kmalloc+0x39c/0x420 [] ? sched_clock_cpu+0xa8/0xd0 [] ? iter_file_splice_write+0x91/0x450 [] ? local_clock+0x16/0x30 [] iter_file_splice_write+0x263/0x450 [] direct_splice_actor+0x36/0x40 [] splice_direct_to_actor+0xc3/0x1f0 [] ? generic_pipe_buf_nosteal+0x10/0x10 [] do_splice_direct+0x82/0xb0 [] do_sendfile+0x1af/0x3a0 [] SyS_sendfile64+0x8a/0xa0 [] ? tracesys_phase2+0x75/0xd9 [] tracesys_phase2+0xd4/0xd9 Code: e8 83 57 e4 ff 85 c0 0f 85 a0 fc ff ff e9 47 ff ff ff 48 c7 c7 e0 f4 c3 9a e8 6a 57 e4 ff 85 c0 0f 85 e7 fc ff ff e9 6c ff ff ff <0f> 0b be fe 0b 00 00 48 c7 c7 f9 4d a2 9a e8 7a 3b df ff e9 c8 RIP [] ext4_direct_IO+0x713/0x750 RSP ---[ end trace d80209ec68bf10b8 ]--- That BUG_ON is.. 2982 BUG_ON(iocb->private == NULL); I'll try and reproduce it in the morning. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] s390 vs. kprobes on ftrace
Hi Heiko, (2014/10/16 0:46), Heiko Carstens wrote: > Hi all, > > we would like to implement an architecture specific variant of "kprobes > on ftrace" without using the current HAVE_KPROBES_ON_FTRACE infrastructure > which is currently only used by x86. > > The rationale for these two patches is: > - we want to patch the first instruction of the mcount code block to > reduce the overhead of the function tracer > - we'd like to keep the ftrace_caller function as simple as possible and > not require it to generate a 100% valid pt_regs structure as required > by the combination of DYNAMIC_FTRACE_WITH_REGS and HAVE_KPROBES_ON_FTRACE. > This allows us to not generate the psw mask field in the pt_regs > structure on each function tracer enabled function, which otherwise would > be very expensive. Besides that program check generated pt_regs contents > are "more" accurate than program generated ones and don't require any > maintenance. > And also we can keep the ftrace and kprobes backends quite separated. I'm not sure about s390 nor have the machine, so it is very helpful if you give us a command line level test and show us the result with this patch :) Fortunately, we already have ftracetest under tools/tesitng/selftest/ftrace/. You can add the testcase for checking co-existence of kprobes and ftrace on an entry of a function. And also, since ftrace is now supporting assembly trampoline code for each handler, performance overhead can be reduced if we save registers only when the kprobes enabled on the function. I'm not sure it can implement on s390, but your requirement looks similar. What would you think about that? Thank you, > > In order to make this work a small common code change is necessary which > removes a check if kprobe is being placed on an ftrace location (see > first patch). > > If possible, I'd like to have an ACK from at least one of the kprobes > maintainers for the first patch and bring it upstream via the s390 tree. > > Thanks, > Heiko > > Heiko Carstens (2): > kprobes: introduce ARCH_HANDLES_KPROBES_ON_FTRACE > s390/ftrace,kprobes: allow to patch first instruction > > arch/Kconfig| 8 +++ > arch/s390/Kconfig | 1 + > arch/s390/include/asm/ftrace.h | 52 ++-- > arch/s390/include/asm/kprobes.h | 1 + > arch/s390/include/asm/lowcore.h | 4 +- > arch/s390/include/asm/pgtable.h | 12 > arch/s390/kernel/asm-offsets.c | 1 - > arch/s390/kernel/early.c| 4 -- > arch/s390/kernel/ftrace.c | 132 > +--- > arch/s390/kernel/kprobes.c | 87 ++ > arch/s390/kernel/mcount.S | 1 + > arch/s390/kernel/setup.c| 2 - > arch/s390/kernel/smp.c | 1 - > kernel/kprobes.c| 3 +- > scripts/recordmcount.c | 2 +- > scripts/recordmcount.pl | 2 +- > 16 files changed, 220 insertions(+), 93 deletions(-) > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/zbud: init user ops only when it is needed
Hello,
On 10/16/2014 05:17 AM, Andrew Morton wrote:
On Wed, 15 Oct 2014 19:00:43 +0900 Heesub Shin wrote:
When zbud is initialized through the zpool wrapper, pool->ops which
points to user-defined operations is always set regardless of whether it
is specified from the upper layer. This causes zbud_reclaim_page() to
iterate its loop for evicting pool pages out without any gain.
This patch sets the user-defined ops only when it is needed, so that
zbud_reclaim_page() can bail out the reclamation loop earlier if there
is no user-defined operations specified.
Which callsite is calling zbud_zpool_create(..., NULL)?
Currently nowhere. zswap is the only user of zbud and always passes a
pointer to user-defined operation on pool creation. In addition, there
may be less possibility that pool shrinking is requested by users who
did not provide the user-defined ops. So, we may not need to worry much
about what I wrote in the changelog. However, it is definitely weird to
pass an argument, zpool_ops, which even will not be referenced by
zbud_zpool_create(). Above all, it would be more useful to avoid the
possibility in the future rather than just ignoring it.
regards,
heesub
...
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -132,7 +132,7 @@ static struct zbud_ops zbud_zpool_ops = {
static void *zbud_zpool_create(gfp_t gfp, struct zpool_ops *zpool_ops)
{
- return zbud_create_pool(gfp, &zbud_zpool_ops);
+ return zbud_create_pool(gfp, zpool_ops ? &zbud_zpool_ops : NULL);
}
static void zbud_zpool_destroy(void *pool)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: Make Atom PMC driver configurable.
On 2014/10/16 13:24, Ingo Molnar wrote: > > * Dave Jones wrote: > >> The Atom PMC driver is always built-in, regardless of whether >> the kernel being built is going to be run on an Atom (or even Intel) CPU. >> >> Signed-off-by: Dave Jones >> Cc: One Thousand Gnomes >> Cc: aubrey...@linux.intel.com >> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >> index f2327e88e07c..b4dfd96aeea8 100644 >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP >> depends on STA2X11 >> >> config PMC_ATOM >> -def_bool y >> +tristate "Intel Atom SOC power management controller driver" >> +default y >> depends on PCI >> > > So what I think should happen is to decouple of the 'must work' > features from the optional debug features in this 'driver': the > Atom SoC power-off quirk should be made unconditional, as long as > the .config is Atom-supported (CPU_SUP_INTEL I guess). > > All the other bits, such as the debugfs interface, should be in a > separately and appropriately named config option, > CONFIG_X86_INTEL_ATOM_PMC_DEBUG=y or so, with 'default n'. > > The file should probably be split up, the quirk moved into one of > the generic quirk files, while pmc_atom.c should have the debugfs > interface. > > That way we don't break anyone and remove the unnecessary code as > well. It's also a nice clean up. Thanks for the suggestion, I'll take a look if I can refine it after I clean up my plate. Please expect a delay here. -Aubrey > > Thanks, > > Ingo > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf callchain: Create an address space per thread
Commit-ID: 66f066d8994bd146304bab72fa09c1e644c4b3ff
Gitweb: http://git.kernel.org/tip/66f066d8994bd146304bab72fa09c1e644c4b3ff
Author: Namhyung Kim
AuthorDate: Mon, 6 Oct 2014 09:46:00 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 17:38:23 -0300
perf callchain: Create an address space per thread
The unw_addr_space_t in libunwind represents an address space to be used
for stack unwinding. It doesn't need to be create/destory everytime to
unwind callchain (as in get_entries) and can have a same lifetime as
thread (unless exec called).
So move the address space construction/destruction logic to the thread
lifetime handling functions. This is a preparation to enable caching in
the unwind library.
Note that it saves unw_addr_space_t object using thread__set_priv(). It
seems currently only used by perf trace and perf kvm stat commands which
don't use callchain.
Signed-off-by: Namhyung Kim
Acked-by: Jean Pihet
Acked-by: Jiri Olsa
Cc: Arun Sharma
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jean Pihet
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1412556363-26229-3-git-send-email-namhy...@kernel.org
[ Fixup unwind-libunwind.c missing CALLCHAIN_DWARF definition, added
missing __maybe_unused on unused parameters in stubs at util/unwind.h ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/thread.c | 6 ++
tools/perf/util/unwind-libunwind.c | 37 -
tools/perf/util/unwind.h | 17 +
3 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index a9df7f2..2b7b2d9 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -7,6 +7,7 @@
#include "util.h"
#include "debug.h"
#include "comm.h"
+#include "unwind.h"
int thread__init_map_groups(struct thread *thread, struct machine *machine)
{
@@ -37,6 +38,9 @@ struct thread *thread__new(pid_t pid, pid_t tid)
thread->cpu = -1;
INIT_LIST_HEAD(&thread->comm_list);
+ if (unwind__prepare_access(thread) < 0)
+ goto err_thread;
+
comm_str = malloc(32);
if (!comm_str)
goto err_thread;
@@ -48,6 +52,7 @@ struct thread *thread__new(pid_t pid, pid_t tid)
goto err_thread;
list_add(&comm->list, &thread->comm_list);
+
}
return thread;
@@ -69,6 +74,7 @@ void thread__delete(struct thread *thread)
list_del(&comm->list);
comm__free(comm);
}
+ unwind__finish_access(thread);
free(thread);
}
diff --git a/tools/perf/util/unwind-libunwind.c
b/tools/perf/util/unwind-libunwind.c
index 92b56db..e060386 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include "callchain.h"
#include "thread.h"
#include "session.h"
#include "perf_regs.h"
@@ -525,12 +526,12 @@ static unw_accessors_t accessors = {
.get_proc_name = get_proc_name,
};
-static int get_entries(struct unwind_info *ui, unwind_entry_cb_t cb,
- void *arg, int max_stack)
+int unwind__prepare_access(struct thread *thread)
{
unw_addr_space_t addr_space;
- unw_cursor_t c;
- int ret;
+
+ if (callchain_param.record_mode != CALLCHAIN_DWARF)
+ return 0;
addr_space = unw_create_addr_space(&accessors, 0);
if (!addr_space) {
@@ -538,6 +539,33 @@ static int get_entries(struct unwind_info *ui,
unwind_entry_cb_t cb,
return -ENOMEM;
}
+ thread__set_priv(thread, addr_space);
+
+ return 0;
+}
+
+void unwind__finish_access(struct thread *thread)
+{
+ unw_addr_space_t addr_space;
+
+ if (callchain_param.record_mode != CALLCHAIN_DWARF)
+ return;
+
+ addr_space = thread__priv(thread);
+ unw_destroy_addr_space(addr_space);
+}
+
+static int get_entries(struct unwind_info *ui, unwind_entry_cb_t cb,
+ void *arg, int max_stack)
+{
+ unw_addr_space_t addr_space;
+ unw_cursor_t c;
+ int ret;
+
+ addr_space = thread__priv(ui->thread);
+ if (addr_space == NULL)
+ return -1;
+
ret = unw_init_remote(&c, addr_space, ui);
if (ret)
display_error(ret);
@@ -549,7 +577,6 @@ static int get_entries(struct unwind_info *ui,
unwind_entry_cb_t cb,
ret = ip ? entry(ip, ui->thread, ui->machine, cb, arg) : 0;
}
- unw_destroy_addr_space(addr_space);
return ret;
}
diff --git a/tools/perf/util/unwind.h b/tools/perf/util/unwind.h
index f030612..c17c485 100644
--- a/tools/perf/util/unwind.h
+++ b/tools/perf/util/unwind.h
@@ -4,6 +4,7 @@
#include
#include "event.h"
[tip:perf/urgent] perf Documentation: Fix typos in perf/ Documentation
Commit-ID: 96355f2cfb61bb057df9bc0712cd7323dba28080 Gitweb: http://git.kernel.org/tip/96355f2cfb61bb057df9bc0712cd7323dba28080 Author: Masanari Iida AuthorDate: Wed, 10 Sep 2014 00:18:50 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 15 Oct 2014 17:39:02 -0300 perf Documentation: Fix typos in perf/Documentation This patch fix spelling typos found in tool/perf/Documentation. Signed-off-by: Masanari Iida Acked-by: Randy Dunlap Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Randy Dunlap Link: http://lkml.kernel.org/r/1410275930-17207-1-git-send-email-standby2...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Documentation/perf-diff.txt | 6 +++--- tools/perf/Documentation/perf-kvm.txt | 4 ++-- tools/perf/Documentation/perf-list.txt | 2 +- tools/perf/Documentation/perf-record.txt| 2 +- tools/perf/Documentation/perf-script-perl.txt | 4 ++-- tools/perf/Documentation/perf-script-python.txt | 6 +++--- tools/perf/Documentation/perf-script.txt| 2 +- tools/perf/Documentation/perf-test.txt | 2 +- tools/perf/Documentation/perf-trace.txt | 2 +- 9 files changed, 15 insertions(+), 15 deletions(-) diff --git a/tools/perf/Documentation/perf-diff.txt b/tools/perf/Documentation/perf-diff.txt index b3b8aba..e463caa 100644 --- a/tools/perf/Documentation/perf-diff.txt +++ b/tools/perf/Documentation/perf-diff.txt @@ -196,10 +196,10 @@ If specified the 'Weighted diff' column is displayed with value 'd' computed as: - period being the hist entry period value - - WEIGHT-A/WEIGHT-B being user suplied weights in the the '-c' option + - WEIGHT-A/WEIGHT-B being user supplied weights in the the '-c' option behind ':' separator like '-c wdiff:1,2'. -- WIEGHT-A being the weight of the data file -- WIEGHT-B being the weight of the baseline data file +- WEIGHT-A being the weight of the data file +- WEIGHT-B being the weight of the baseline data file SEE ALSO diff --git a/tools/perf/Documentation/perf-kvm.txt b/tools/perf/Documentation/perf-kvm.txt index 6e689dc..6252e77 100644 --- a/tools/perf/Documentation/perf-kvm.txt +++ b/tools/perf/Documentation/perf-kvm.txt @@ -100,7 +100,7 @@ OPTIONS STAT REPORT OPTIONS --- --vcpu=:: - analyze events which occures on this vcpu. (default: all vcpus) + analyze events which occur on this vcpu. (default: all vcpus) --event=:: event to be analyzed. Possible values: vmexit, mmio (x86 only), @@ -134,7 +134,7 @@ STAT LIVE OPTIONS Analyze events only for given process ID(s) (comma separated list). --vcpu=:: - analyze events which occures on this vcpu. (default: all vcpus) + analyze events which occur on this vcpu. (default: all vcpus) --event=:: diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt index 6fce6a6..cbb4f74 100644 --- a/tools/perf/Documentation/perf-list.txt +++ b/tools/perf/Documentation/perf-list.txt @@ -19,7 +19,7 @@ various perf commands with the -e option. EVENT MODIFIERS --- -Events can optionally have a modifer by appending a colon and one or +Events can optionally have a modifier by appending a colon and one or more modifiers. Modifiers allow the user to restrict the events to be counted. The following modifiers exist: diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt index d460049..398f8d5 100644 --- a/tools/perf/Documentation/perf-record.txt +++ b/tools/perf/Documentation/perf-record.txt @@ -146,7 +146,7 @@ the thread executes on the designated CPUs. Default is to monitor all CPUs. -N:: --no-buildid-cache:: -Do not update the builid cache. This saves some overhead in situations +Do not update the buildid cache. This saves some overhead in situations where the information in the perf.data file (which includes buildids) is sufficient. diff --git a/tools/perf/Documentation/perf-script-perl.txt b/tools/perf/Documentation/perf-script-perl.txt index d00bef2..dfbb506 100644 --- a/tools/perf/Documentation/perf-script-perl.txt +++ b/tools/perf/Documentation/perf-script-perl.txt @@ -181,8 +181,8 @@ strings for flag and symbolic fields. These correspond to the strings and values parsed from the 'print fmt' fields of the event format files: - flag_str($event_name, $field_name, $field_value) - returns the string represention corresponding to $field_value for the flag field $field_name of event $event_name - symbol_str($event_name, $field_name, $field_value) - returns the string represention corresponding to $field_value for the symbolic field $field_name of event $event_name + flag_str($event_name, $field_name, $field_value) - returns the string representation corresponding to $field_value for the flag field $field_name of event $event_name + symbol_str($event_name, $field_name, $field_value) - returns the string represen
[tip:perf/urgent] perf session: Add option to copy events when queueing
Commit-ID: 54bf53b1cb9150b894213a705c562d52388376ef
Gitweb: http://git.kernel.org/tip/54bf53b1cb9150b894213a705c562d52388376ef
Author: Alexander Yarygin
AuthorDate: Fri, 3 Oct 2014 18:40:11 +0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 17:39:03 -0300
perf session: Add option to copy events when queueing
When processing events the session code has an ordered samples queue
which is used to time-sort events coming in across multiple mmaps. At a
later point in time samples on the queue are flushed up to some
timestamp at which point the event is actually processed.
When analyzing events live (ie., record/analysis path in the same
command) there is a race that leads to corrupted events and parse errors
which cause perf to terminate. The problem is that when the event is
placed in the ordered samples queue it is only a reference to the event
which is really sitting in the mmap buffer. Even though the event is
queued for later processing the mmap tail pointer is updated which
indicates to the kernel that the event has been processed. The race is
flushing the event from the queue before it gets overwritten by some
other event. For commands trying to process events live (versus just
writing to a file) and processing a high rate of events this leads to
parse failures and perf terminates.
Examples hitting this problem are 'perf kvm stat live', especially with
nested VMs which generate 100,000+ traces per second, and a command
processing scheduling events with a high rate of context switching --
e.g., running 'perf bench sched pipe'.
This patch offers live commands an option to copy the event when it is
placed in the ordered samples queue.
Based on a patch from David Ahern
Signed-off-by: Alexander Yarygin
Acked-by: Jiri Olsa
Cc: Christian Borntraeger
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1412347212-28237-2-git-send-email-yary...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/ordered-events.c | 49
tools/perf/util/ordered-events.h | 10 +++-
tools/perf/util/session.c| 5 ++--
3 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 706ce1a..fd4be94 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -1,5 +1,6 @@
#include
#include
+#include
#include "ordered-events.h"
#include "evlist.h"
#include "session.h"
@@ -57,11 +58,45 @@ static void queue_event(struct ordered_events *oe, struct
ordered_event *new)
}
}
+static union perf_event *__dup_event(struct ordered_events *oe,
+union perf_event *event)
+{
+ union perf_event *new_event = NULL;
+
+ if (oe->cur_alloc_size < oe->max_alloc_size) {
+ new_event = memdup(event, event->header.size);
+ if (new_event)
+ oe->cur_alloc_size += event->header.size;
+ }
+
+ return new_event;
+}
+
+static union perf_event *dup_event(struct ordered_events *oe,
+ union perf_event *event)
+{
+ return oe->copy_on_queue ? __dup_event(oe, event) : event;
+}
+
+static void free_dup_event(struct ordered_events *oe, union perf_event *event)
+{
+ if (oe->copy_on_queue) {
+ oe->cur_alloc_size -= event->header.size;
+ free(event);
+ }
+}
+
#define MAX_SAMPLE_BUFFER (64 * 1024 / sizeof(struct ordered_event))
-static struct ordered_event *alloc_event(struct ordered_events *oe)
+static struct ordered_event *alloc_event(struct ordered_events *oe,
+union perf_event *event)
{
struct list_head *cache = &oe->cache;
struct ordered_event *new = NULL;
+ union perf_event *new_event;
+
+ new_event = dup_event(oe, event);
+ if (!new_event)
+ return NULL;
if (!list_empty(cache)) {
new = list_entry(cache->next, struct ordered_event, list);
@@ -74,8 +109,10 @@ static struct ordered_event *alloc_event(struct
ordered_events *oe)
size_t size = MAX_SAMPLE_BUFFER * sizeof(*new);
oe->buffer = malloc(size);
- if (!oe->buffer)
+ if (!oe->buffer) {
+ free_dup_event(oe, new_event);
return NULL;
+ }
pr("alloc size %" PRIu64 "B (+%zu), max %" PRIu64 "B\n",
oe->cur_alloc_size, size, oe->max_alloc_size);
@@ -90,15 +127,17 @@ static struct ordered_event *alloc_event(struct
ordered_events *oe)
pr("allocation limit reached %" PRIu64 "B\n",
oe->max_alloc_size);
}
+ new->event = new_event;
return new;
}
[tip:perf/urgent] perf kvm stat live: Enable events copying
Commit-ID: 673d659f5c5918b7ddbafebf1f129c9eb82973b4 Gitweb: http://git.kernel.org/tip/673d659f5c5918b7ddbafebf1f129c9eb82973b4 Author: Alexander Yarygin AuthorDate: Fri, 3 Oct 2014 18:40:12 +0400 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 15 Oct 2014 17:39:03 -0300 perf kvm stat live: Enable events copying Process of analyzing events caused by 2 functions: mmap_read() and finished_round(). During mmap_read(), perf receives events from shared memory, queues their pointers for further processing in finished_round() and notifies the kernel that the events have been processed. By the time when finished_round() is invoked, queued events can be overwritten by the kernel, so the finished_round() occurs on potentially corrupted memory. Since there is no place where the event can be safely consumed, let's copy events when queueing. Signed-off-by: Alexander Yarygin Cc: Christian Borntraeger Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1412347212-28237-3-git-send-email-yary...@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-kvm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c index ef9fc15..b65eb050 100644 --- a/tools/perf/builtin-kvm.c +++ b/tools/perf/builtin-kvm.c @@ -1358,6 +1358,7 @@ static int kvm_events_live(struct perf_kvm_stat *kvm, } kvm->session->evlist = kvm->evlist; perf_session__set_id_hdr_size(kvm->session); + ordered_events__set_copy_on_queue(&kvm->session->ordered_events, true); machine__synthesize_threads(&kvm->session->machines.host, &kvm->opts.target, kvm->evlist->threads, false); err = kvm_live_open_events(kvm); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf trace: Use thread_{,_set}_priv helpers
Commit-ID: 89dceb22c098bd6afa9f3054aedddb9e1349392b
Gitweb: http://git.kernel.org/tip/89dceb22c098bd6afa9f3054aedddb9e1349392b
Author: Namhyung Kim
AuthorDate: Mon, 6 Oct 2014 09:46:03 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 17:39:02 -0300
perf trace: Use thread_{,_set}_priv helpers
This is mechanical changes only for accounting access to thread->priv
properly in the source level.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1412556363-26229-6-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-trace.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 09bcf23..fb12645 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1189,13 +1189,13 @@ static struct thread_trace *thread__trace(struct thread
*thread, FILE *fp)
if (thread == NULL)
goto fail;
- if (thread->priv == NULL)
- thread->priv = thread_trace__new();
+ if (thread__priv(thread) == NULL)
+ thread__set_priv(thread, thread_trace__new());
- if (thread->priv == NULL)
+ if (thread__priv(thread) == NULL)
goto fail;
- ttrace = thread->priv;
+ ttrace = thread__priv(thread);
++ttrace->nr_events;
return ttrace;
@@ -1248,7 +1248,7 @@ struct trace {
static int trace__set_fd_pathname(struct thread *thread, int fd, const char
*pathname)
{
- struct thread_trace *ttrace = thread->priv;
+ struct thread_trace *ttrace = thread__priv(thread);
if (fd > ttrace->paths.max) {
char **npath = realloc(ttrace->paths.table, (fd + 1) *
sizeof(char *));
@@ -1301,7 +1301,7 @@ static int thread__read_fd_path(struct thread *thread,
int fd)
static const char *thread__fd_path(struct thread *thread, int fd,
struct trace *trace)
{
- struct thread_trace *ttrace = thread->priv;
+ struct thread_trace *ttrace = thread__priv(thread);
if (ttrace == NULL)
return NULL;
@@ -1338,7 +1338,7 @@ static size_t syscall_arg__scnprintf_close_fd(char *bf,
size_t size,
{
int fd = arg->val;
size_t printed = syscall_arg__scnprintf_fd(bf, size, arg);
- struct thread_trace *ttrace = arg->thread->priv;
+ struct thread_trace *ttrace = thread__priv(arg->thread);
if (ttrace && fd >= 0 && fd <= ttrace->paths.max)
zfree(&ttrace->paths.table[fd]);
@@ -2381,7 +2381,7 @@ static int trace__fprintf_one_thread(struct thread
*thread, void *priv)
FILE *fp = data->fp;
size_t printed = data->printed;
struct trace *trace = data->trace;
- struct thread_trace *ttrace = thread->priv;
+ struct thread_trace *ttrace = thread__priv(thread);
double ratio;
if (ttrace == 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/
Re: [Patch v2] x86: Make Atom PMC driver configurable.
* Dave Jones wrote: > The Atom PMC driver is always built-in, regardless of whether > the kernel being built is going to be run on an Atom (or even Intel) CPU. > > Signed-off-by: Dave Jones > Cc: One Thousand Gnomes > Cc: aubrey...@linux.intel.com > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index f2327e88e07c..b4dfd96aeea8 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP > depends on STA2X11 > > config PMC_ATOM > - def_bool y > + tristate "Intel Atom SOC power management controller driver" > + default y > depends on PCI > So what I think should happen is to decouple of the 'must work' features from the optional debug features in this 'driver': the Atom SoC power-off quirk should be made unconditional, as long as the .config is Atom-supported (CPU_SUP_INTEL I guess). All the other bits, such as the debugfs interface, should be in a separately and appropriately named config option, CONFIG_X86_INTEL_ATOM_PMC_DEBUG=y or so, with 'default n'. The file should probably be split up, the quirk moved into one of the generic quirk files, while pmc_atom.c should have the debugfs interface. That way we don't break anyone and remove the unnecessary code as well. It's also a nice clean up. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf kvm: Use thread_{,_set}_priv helpers
Commit-ID: 69e865c353b226dbedf319ae6d1ab8fb3510fa25
Gitweb: http://git.kernel.org/tip/69e865c353b226dbedf319ae6d1ab8fb3510fa25
Author: Namhyung Kim
AuthorDate: Mon, 6 Oct 2014 09:46:02 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 17:39:01 -0300
perf kvm: Use thread_{,_set}_priv helpers
This is mechanical changes only for accounting access to thread->priv
properly in the source level.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1412556363-26229-5-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-kvm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 460a4ce..ef9fc15 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -376,7 +376,7 @@ struct vcpu_event_record *per_vcpu_record(struct thread
*thread,
struct perf_sample *sample)
{
/* Only kvm_entry records vcpu id. */
- if (!thread->priv && kvm_entry_event(evsel)) {
+ if (!thread__priv(thread) && kvm_entry_event(evsel)) {
struct vcpu_event_record *vcpu_record;
vcpu_record = zalloc(sizeof(*vcpu_record));
@@ -386,10 +386,10 @@ struct vcpu_event_record *per_vcpu_record(struct thread
*thread,
}
vcpu_record->vcpu_id = perf_evsel__intval(evsel, sample,
VCPU_ID);
- thread->priv = vcpu_record;
+ thread__set_priv(thread, vcpu_record);
}
- return thread->priv;
+ return thread__priv(thread);
}
static bool handle_kvm_event(struct perf_kvm_stat *kvm,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf report: Set callchain_param.record_mode for future use
Commit-ID: 0cdccac6fe4b1316f04f0dbfcc4efab51932014a
Gitweb: http://git.kernel.org/tip/0cdccac6fe4b1316f04f0dbfcc4efab51932014a
Author: Namhyung Kim
AuthorDate: Mon, 6 Oct 2014 09:45:59 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 16:20:03 -0300
perf report: Set callchain_param.record_mode for future use
Normally the callchain_param.record_mode is used only for record path.
But as it might need to prepare something for dwarf unwinding, setup
this info for perf report too.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jean Pihet
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1412556363-26229-2-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 7 +++
tools/perf/tests/dwarf-unwind.c | 3 +++
2 files changed, 10 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 2cfc4b93..140a6cd 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -257,6 +257,13 @@ static int report__setup_sample_type(struct report *rep)
}
}
+ if (symbol_conf.use_callchain || symbol_conf.cumulate_callchain) {
+ if ((sample_type & PERF_SAMPLE_REGS_USER) &&
+ (sample_type & PERF_SAMPLE_STACK_USER))
+ callchain_param.record_mode = CALLCHAIN_DWARF;
+ else
+ callchain_param.record_mode = CALLCHAIN_FP;
+ }
return 0;
}
diff --git a/tools/perf/tests/dwarf-unwind.c b/tools/perf/tests/dwarf-unwind.c
index 96adb73..fc25e57 100644
--- a/tools/perf/tests/dwarf-unwind.c
+++ b/tools/perf/tests/dwarf-unwind.c
@@ -9,6 +9,7 @@
#include "perf_regs.h"
#include "map.h"
#include "thread.h"
+#include "callchain.h"
static int mmap_handler(struct perf_tool *tool __maybe_unused,
union perf_event *event,
@@ -120,6 +121,8 @@ int test__dwarf_unwind(void)
return -1;
}
+ callchain_param.record_mode = CALLCHAIN_DWARF;
+
if (init_live_machine(machine)) {
pr_err("Could not init machine\n");
goto out;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf Documentation: Remove Ruplicated docs for powerpc cpu specific events
Commit-ID: b56d5beff4825f9f216f1fc4a54a5d07d4b68b71 Gitweb: http://git.kernel.org/tip/b56d5beff4825f9f216f1fc4a54a5d07d4b68b71 Author: Cody P Schafer AuthorDate: Tue, 30 Sep 2014 23:03:20 -0700 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 15 Oct 2014 16:00:37 -0300 perf Documentation: Remove Ruplicated docs for powerpc cpu specific events Listing specific events doesn't actually help us at all here because: - these events actually vary between different ppc processors, they aren't garunteed to be present. - the documentation of the (generic) file contents is now superceded by the docs for arbitrary event file contents. Signed-off-by: Cody P Schafer Signed-off-by: Sukadev Bhattiprolu Cc: Andi Kleen Cc: Anshuman Khandual Cc: Haren Myneni Cc: Jiri Olsa Cc: Michael Ellerman Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: linuxppc-...@lists.ozlabs.org Link: http://lkml.kernel.org/r/1412143402-26061-5-git-send-email-suka...@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo --- .../testing/sysfs-bus-event_source-devices-events | 573 - 1 file changed, 573 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events index a5226f0..20979f8 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events @@ -27,579 +27,6 @@ Description:Generic performance monitoring events "basename". -What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL - /sys/devices/cpu/events/PM_BRU_FIN - /sys/devices/cpu/events/PM_BR_MPRED - /sys/devices/cpu/events/PM_CMPLU_STALL - /sys/devices/cpu/events/PM_CMPLU_STALL_BRU - /sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS - /sys/devices/cpu/events/PM_CMPLU_STALL_DFU - /sys/devices/cpu/events/PM_CMPLU_STALL_DIV - /sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS - /sys/devices/cpu/events/PM_CMPLU_STALL_FXU - /sys/devices/cpu/events/PM_CMPLU_STALL_IFU - /sys/devices/cpu/events/PM_CMPLU_STALL_LSU - /sys/devices/cpu/events/PM_CMPLU_STALL_REJECT - /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR - /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG - /sys/devices/cpu/events/PM_CMPLU_STALL_STORE - /sys/devices/cpu/events/PM_CMPLU_STALL_THRD - /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR - /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG - /sys/devices/cpu/events/PM_CYC - /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED - /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS - /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC - /sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS - /sys/devices/cpu/events/PM_GRP_CMPL - /sys/devices/cpu/events/PM_INST_CMPL - /sys/devices/cpu/events/PM_LD_MISS_L1 - /sys/devices/cpu/events/PM_LD_REF_L1 - /sys/devices/cpu/events/PM_RUN_CYC - /sys/devices/cpu/events/PM_RUN_INST_CMPL - /sys/devices/cpu/events/PM_IC_DEMAND_L2_BR_ALL - /sys/devices/cpu/events/PM_GCT_UTIL_7_TO_10_SLOTS - /sys/devices/cpu/events/PM_PMC2_SAVED - /sys/devices/cpu/events/PM_VSU0_16FLOP - /sys/devices/cpu/events/PM_MRK_LSU_DERAT_MISS - /sys/devices/cpu/events/PM_MRK_ST_CMPL - /sys/devices/cpu/events/PM_NEST_PAIR3_ADD - /sys/devices/cpu/events/PM_L2_ST_DISP - /sys/devices/cpu/events/PM_L2_CASTOUT_MOD - /sys/devices/cpu/events/PM_ISEG - /sys/devices/cpu/events/PM_MRK_INST_TIMEO - /sys/devices/cpu/events/PM_L2_RCST_DISP_FAIL_ADDR - /sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_CONFIRM - /sys/devices/cpu/events/PM_IERAT_WR_64K - /sys/devices/cpu/events/PM_MRK_DTLB_MISS_16M - /sys/devices/cpu/events/PM_IERAT_MISS - /sys/devices/cpu/events/PM_MRK_PTEG_FROM_LMEM - /sys/devices/cpu/events/PM_FLOP - /sys/devices/cpu/events/PM_THRD_PRIO_4_5_CYC - /sys/devices/cpu/events/PM_BR_PRED_TA - /sys/devices/cpu/events/PM_EXT_INT - /sys/devices/cpu/events/PM_VSU_FSQRT_FDIV - /sys/devices/cpu/events/PM_MRK_LD_MISS_EXPOSED_CYC - /sys/devices/cpu/events/PM_LSU1_LDF - /sys/devices/cpu/events/PM_IC_WRITE_ALL - /sys/devices/cpu/events/PM_LSU0_SRQ_STFWD - /sys/devices/cpu/events/PM_PTEG_FROM_RL2L3_MOD - /sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_SHR -
[tip:perf/urgent] perf Documentation: sysfs events/ interfaces
Commit-ID: ed90a4466340e51699139ea83dbe0f4536360e6d Gitweb: http://git.kernel.org/tip/ed90a4466340e51699139ea83dbe0f4536360e6d Author: Cody P Schafer AuthorDate: Tue, 30 Sep 2014 23:03:19 -0700 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 15 Oct 2014 15:54:40 -0300 perf Documentation: sysfs events/ interfaces Add documentation for the , .scale, and .unit files in sysfs. .scale and .unit were undocumented. was previously documented only for specific powerpc pmu events. Signed-off-by: Cody P Schafer Signed-off-by: Sukadev Bhattiprolu Cc: Andi Kleen Cc: Anshuman Khandual Cc: Cody P Schafer Cc: Haren Myneni Cc: Haren Myneni Cc: Jiri Olsa Cc: Michael Ellerman Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: linuxppc-...@lists.ozlabs.org Link: http://lkml.kernel.org/r/1412143402-26061-4-git-send-email-suka...@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo --- .../testing/sysfs-bus-event_source-devices-events | 60 ++ 1 file changed, 60 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events index 7b40a3c..a5226f0 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events @@ -599,3 +599,63 @@ Description: POWER-systems specific performance monitoring events Further, multiple terms like 'event=0x' can be specified and separated with comma. All available terms are defined in the /sys/bus/event_source/devices//format file. + +What: /sys/bus/event_source/devices//events/ +Date: 2014/02/24 +Contact: Linux kernel mailing list +Description: Per-pmu performance monitoring events specific to the running system + + Each file (except for some of those with a '.' in them, '.unit' + and '.scale') in the 'events' directory describes a single + performance monitoring event supported by the . The name + of the file is the name of the event. + + File contents: + + [=][,[=]]... + + Where is one of the terms listed under + /sys/bus/event_source/devices//format/ and is + a number is base-16 format with a '0x' prefix (lowercase only). + If a is specified alone (without an assigned value), it + is implied that 0x1 is assigned to that . + + Examples (each of these lines would be in a seperate file): + + event=0x2abc + event=0x423,inv,cmask=0x3 + domain=0x1,offset=0x8,starting_index=0x + + Each of the assignments indicates a value to be assigned to a + particular set of bits (as defined by the format file + corresponding to the ) in the perf_event structure passed + to the perf_open syscall. + +What: /sys/bus/event_source/devices//events/.unit +Date: 2014/02/24 +Contact: Linux kernel mailing list +Description: Perf event units + + A string specifying the English plural numerical unit that + (once multiplied by .scale) represents. + + Example: + + Joules + +What: /sys/bus/event_source/devices//events/.scale +Date: 2014/02/24 +Contact: Linux kernel mailing list +Description: Perf event scaling factors + + A string representing a floating point value expressed in + scientific notation to be multiplied by the event count + recieved from the kernel to match the unit specified in the + .unit file. + + Example: + + 2.3283064365386962890625e-10 + + This is provided to avoid performing floating point arithmetic + in the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf evlist: Fix for double free in tools/ perf stat
Commit-ID: b2e19a934a36b2b4affcde9c170c0f01afabe50a Gitweb: http://git.kernel.org/tip/b2e19a934a36b2b4affcde9c170c0f01afabe50a Author: Yasser Shalabi AuthorDate: Sat, 4 Oct 2014 11:37:57 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 15 Oct 2014 16:16:53 -0300 perf evlist: Fix for double free in tools/perf stat Fix for double free bug in tools/perf due to dangling thread_map pointer in perf_evlist struct. Code path excercised when perf stat -C switch is used but not set and is followed by another switch. Example: perf stat -C -e. Signed-off-by: Yasser Shalabi Acked-by: Namhyung Kim Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1412437077-13109-1-git-send-email-yassershal...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/evlist.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c index b4b54d8..3c9e77d 100644 --- a/tools/perf/util/evlist.c +++ b/tools/perf/util/evlist.c @@ -1003,6 +1003,7 @@ int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target) out_delete_threads: thread_map__delete(evlist->threads); + evlist->threads = NULL; return -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/
[tip:perf/urgent] perf tools: Parse the pmu event prefix and suffix
Commit-ID: dcb4e1022b40d886027500821a592dd8f8ccde8f
Gitweb: http://git.kernel.org/tip/dcb4e1022b40d886027500821a592dd8f8ccde8f
Author: Kan Liang
AuthorDate: Tue, 7 Oct 2014 11:08:50 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 16:05:01 -0300
perf tools: Parse the pmu event prefix and suffix
There are two types of event formats for PMU events. E.g. el-abort OR
cpu/el-abort/. However, the lexer mistakenly recognizes the simple style
format as two events.
The parse_events_pmu_check function uses bsearch to search the name in
known pmu event list. It can tell the lexer that the name is a PE_NAME
or a PMU event name prefix or a PMU event name suffix. All these
information will be used for accurately parsing kernel PMU events.
The pmu events list will be read from sysfs at runtime.
Note: Currently, the patch only want to handle the PMU event name as
"a-b" and "a". The only exception, "stalled-cycles-frontend" and
"stalled-cycles-fronted", are already hardcoded in lexer.
Signed-off-by: Kan Liang
Acked-by: Jiri Olsa
Cc: Andi Kleen
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1412694532-23391-3-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 117 +
tools/perf/util/parse-events.h | 14 +
tools/perf/util/pmu.c | 10
tools/perf/util/pmu.h | 10
4 files changed, 141 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index c5642e6..c659a3c 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -30,6 +30,15 @@ extern int parse_events_debug;
#endif
int parse_events_parse(void *data, void *scanner);
+static struct perf_pmu_event_symbol *perf_pmu_events_list;
+/*
+ * The variable indicates the number of supported pmu event symbols.
+ * 0 means not initialized and ready to init
+ * -1 means failed to init, don't try anymore
+ * >0 is the number of supported pmu event symbols
+ */
+static int perf_pmu_events_list_num;
+
static struct event_symbol event_symbols_hw[PERF_COUNT_HW_MAX] = {
[PERF_COUNT_HW_CPU_CYCLES] = {
.symbol = "cpu-cycles",
@@ -863,6 +872,113 @@ int parse_events_name(struct list_head *list, char *name)
return 0;
}
+static int
+comp_pmu(const void *p1, const void *p2)
+{
+ struct perf_pmu_event_symbol *pmu1 = (struct perf_pmu_event_symbol *)
p1;
+ struct perf_pmu_event_symbol *pmu2 = (struct perf_pmu_event_symbol *)
p2;
+
+ return strcmp(pmu1->symbol, pmu2->symbol);
+}
+
+static void perf_pmu__parse_cleanup(void)
+{
+ if (perf_pmu_events_list_num > 0) {
+ struct perf_pmu_event_symbol *p;
+ int i;
+
+ for (i = 0; i < perf_pmu_events_list_num; i++) {
+ p = perf_pmu_events_list + i;
+ free(p->symbol);
+ }
+ free(perf_pmu_events_list);
+ perf_pmu_events_list = NULL;
+ perf_pmu_events_list_num = 0;
+ }
+}
+
+#define SET_SYMBOL(str, stype) \
+do { \
+ p->symbol = str;\
+ if (!p->symbol) \
+ goto err; \
+ p->type = stype;\
+} while (0)
+
+/*
+ * Read the pmu events list from sysfs
+ * Save it into perf_pmu_events_list
+ */
+static void perf_pmu__parse_init(void)
+{
+
+ struct perf_pmu *pmu = NULL;
+ struct perf_pmu_alias *alias;
+ int len = 0;
+
+ pmu = perf_pmu__find("cpu");
+ if ((pmu == NULL) || list_empty(&pmu->aliases)) {
+ perf_pmu_events_list_num = -1;
+ return;
+ }
+ list_for_each_entry(alias, &pmu->aliases, list) {
+ if (strchr(alias->name, '-'))
+ len++;
+ len++;
+ }
+ perf_pmu_events_list = malloc(sizeof(struct perf_pmu_event_symbol) *
len);
+ if (!perf_pmu_events_list)
+ return;
+ perf_pmu_events_list_num = len;
+
+ len = 0;
+ list_for_each_entry(alias, &pmu->aliases, list) {
+ struct perf_pmu_event_symbol *p = perf_pmu_events_list + len;
+ char *tmp = strchr(alias->name, '-');
+
+ if (tmp != NULL) {
+ SET_SYMBOL(strndup(alias->name, tmp - alias->name),
+ PMU_EVENT_SYMBOL_PREFIX);
+ p++;
+ SET_SYMBOL(strdup(++tmp), PMU_EVENT_SYMBOL_SUFFIX);
+ len += 2;
+ } else {
+ SET_SYMBOL(strdup(alias->name), PMU_EVENT_SYMBOL);
+ len++;
+ }
+ }
+ qsort(perf_pmu_events_list, len,
+ sizeof(struct perf_pmu_event_symbol), comp_pmu);
+
+ return;
+err:
+ perf_pmu__parse
[tip:perf/urgent] perf test: Add test case for pmu event new style format
Commit-ID: ffe59788e69b548bd62cc9a053253a8af2cdda1d
Gitweb: http://git.kernel.org/tip/ffe59788e69b548bd62cc9a053253a8af2cdda1d
Author: Kan Liang
AuthorDate: Tue, 7 Oct 2014 11:08:52 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 16:10:24 -0300
perf test: Add test case for pmu event new style format
Add test case in automated tests suite. It checks not only the two types
of pmu event stytle formats "pmu_event_name" and "cpu/pmu_event_name/",
but also the different formats mixtures which are more likely to trigger
parse issue.
The patch set including this one has been tested by the perf automated
test:
./perf test parse -v"
On haswell, ivybridge and Romley platform.
The patch set also has been tested on haswell by the following script.
Note: please make sure that your test system support TSX and
L1-dcache-loads events. Otherwise, you may want to change the events to
other pmu events.
[lk@localhost ~]$ cat perf_style_test.sh
# hardware events + kernel pmu event with different style
perf stat -x, -e cycles,mem-stores,tx-start sleep 2
perf stat -x, -e cpu-cycles,cycles-ct,cycles-t sleep 2
perf stat -x, -e cycles,cpu/cycles-ct/,cpu/cycles-t/ sleep 2
perf stat -x, -e instructions,cpu/tx-start/ sleep 2
perf stat -x, -e '{cycles,tx-start}' sleep 2
perf stat -x, -e '{cycles,cpu/tx-start/}' sleep 2
# HW Cache event + kernel pmu event with different style
perf stat -x, -e L1-dcache-loads,cpu/mem-stores/,tx-start sleep 2
perf stat -x, -e L1-dcache-loads,mem-stores,cpu/tx-start/ sleep 2
perf stat -x, -e '{L1-dcache-loads,mem-stores}' sleep 2
perf stat -x, -e '{L1-dcache-loads,cpu/tx-start/}' sleep 2
# Raw event + kernel pmu event with different style:
perf stat -x, -e cpu/event=0xc0,umask=0x00/,mem-loads,cpu/mem-stores/ sleep 2
perf stat -x, -e cpu/event=0xc0,umask=0x00/,tx-start,cpu/el-start/ sleep 2
perf stat -x, -e '{cpu/event=0xc0,umask=0x00/,tx-start}' sleep 2
Signed-off-by: Kan Liang
Acked-by: Jiri Olsa
Cc: Andi Kleen
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1412694532-23391-5-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/parse-events.c | 36
1 file changed, 36 insertions(+)
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index 5941927..7f2f51f 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -457,6 +457,36 @@ static int test__checkevent_pmu_events(struct perf_evlist
*evlist)
return 0;
}
+
+static int test__checkevent_pmu_events_mix(struct perf_evlist *evlist)
+{
+ struct perf_evsel *evsel = perf_evlist__first(evlist);
+
+ /* pmu-event:u */
+ TEST_ASSERT_VAL("wrong number of entries", 2 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong exclude_user",
+ !evsel->attr.exclude_user);
+ TEST_ASSERT_VAL("wrong exclude_kernel",
+ evsel->attr.exclude_kernel);
+ TEST_ASSERT_VAL("wrong exclude_hv", evsel->attr.exclude_hv);
+ TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
+ TEST_ASSERT_VAL("wrong pinned", !evsel->attr.pinned);
+
+ /* cpu/pmu-event/u*/
+ evsel = perf_evsel__next(evsel);
+ TEST_ASSERT_VAL("wrong number of entries", 2 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong type", PERF_TYPE_RAW == evsel->attr.type);
+ TEST_ASSERT_VAL("wrong exclude_user",
+ !evsel->attr.exclude_user);
+ TEST_ASSERT_VAL("wrong exclude_kernel",
+ evsel->attr.exclude_kernel);
+ TEST_ASSERT_VAL("wrong exclude_hv", evsel->attr.exclude_hv);
+ TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
+ TEST_ASSERT_VAL("wrong pinned", !evsel->attr.pinned);
+
+ return 0;
+}
+
static int test__checkterms_simple(struct list_head *terms)
{
struct parse_events_term *term;
@@ -1554,6 +1584,12 @@ static int test_pmu_events(void)
e.check = test__checkevent_pmu_events;
ret = test_event(&e);
+ if (ret)
+ break;
+ snprintf(name, MAX_NAME, "%s:u,cpu/event=%s/u", ent->d_name,
ent->d_name);
+ e.name = name;
+ e.check = test__checkevent_pmu_events_mix;
+ ret = test_event(&e);
#undef MAX_NAME
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf tools: Add support to new style format of kernel PMU event
Commit-ID: ba32a4511c65e41958384d2f7a046a6ec6e151e5
Gitweb: http://git.kernel.org/tip/ba32a4511c65e41958384d2f7a046a6ec6e151e5
Author: Kan Liang
AuthorDate: Tue, 7 Oct 2014 11:08:51 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 16:05:45 -0300
perf tools: Add support to new style format of kernel PMU event
Add new rules for kernel PMU event.
Currently, the patch only want to handle the PMU event name as "a-b" and
"a".
event_pmu:
PE_KERNEL_PMU_EVENT sep_dc
|
PE_PMU_EVENT_PRE '-' PE_PMU_EVENT_SUF sep_dc
PE_KERNEL_PMU_EVENT token is for
cycles-ct/cycles-t/mem-loads/mem-stores.
The prefix cycles is mixed up with cpu-cycles. loads and stores are
mixed up with cache event So they have to be hardcode in lex.
PE_PMU_EVENT_PRE and PE_PMU_EVENT_SUF tokens are for other PMU events.
The lex looks generic identifier up in the table and return the matched
token. If there is no match, generic PE_NAME token will be return.
Using the rules, kernel PMU event could use new style format without //
so you can use:
perf record -e mem-loads ...
instead of:
perf record -e cpu/mem-loads/
Signed-off-by: Kan Liang
Acked-by: Jiri Olsa
Cc: Andi Kleen
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1412694532-23391-4-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.l | 30 +-
tools/perf/util/parse-events.y | 40
2 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 3432995..906630b 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -51,6 +51,24 @@ static int str(yyscan_t scanner, int token)
return token;
}
+static int pmu_str_check(yyscan_t scanner)
+{
+ YYSTYPE *yylval = parse_events_get_lval(scanner);
+ char *text = parse_events_get_text(scanner);
+
+ yylval->str = strdup(text);
+ switch (perf_pmu__parse_check(text)) {
+ case PMU_EVENT_SYMBOL_PREFIX:
+ return PE_PMU_EVENT_PRE;
+ case PMU_EVENT_SYMBOL_SUFFIX:
+ return PE_PMU_EVENT_SUF;
+ case PMU_EVENT_SYMBOL:
+ return PE_KERNEL_PMU_EVENT;
+ default:
+ return PE_NAME;
+ }
+}
+
static int sym(yyscan_t scanner, int type, int config)
{
YYSTYPE *yylval = parse_events_get_lval(scanner);
@@ -178,6 +196,16 @@ alignment-faults { return
sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_AL
emulation-faults { return sym(yyscanner,
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_EMULATION_FAULTS); }
dummy { return sym(yyscanner,
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_DUMMY); }
+ /*
+* We have to handle the kernel PMU event
cycles-ct/cycles-t/mem-loads/mem-stores separately.
+* Because the prefix cycles is mixed up with cpu-cycles.
+* loads and stores are mixed up with cache event
+*/
+cycles-ct { return str(yyscanner,
PE_KERNEL_PMU_EVENT); }
+cycles-t { return str(yyscanner,
PE_KERNEL_PMU_EVENT); }
+mem-loads { return str(yyscanner,
PE_KERNEL_PMU_EVENT); }
+mem-stores { return str(yyscanner,
PE_KERNEL_PMU_EVENT); }
+
L1-dcache|l1-d|l1d|L1-data |
L1-icache|l1-i|l1i|L1-instruction |
LLC|L2 |
@@ -199,7 +227,7 @@ r{num_raw_hex} { return raw(yyscanner); }
{num_hex} { return value(yyscanner, 16); }
{modifier_event} { return str(yyscanner, PE_MODIFIER_EVENT); }
-{name} { return str(yyscanner, PE_NAME); }
+{name} { return pmu_str_check(yyscanner); }
"/"{ BEGIN(config); return '/'; }
- { return '-'; }
, { BEGIN(event); return ','; }
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 55fab6a..93c4c9f 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -47,6 +47,7 @@ static inc_group_count(struct list_head *list,
%token PE_NAME_CACHE_TYPE PE_NAME_CACHE_OP_RESULT
%token PE_PREFIX_MEM PE_PREFIX_RAW PE_PREFIX_GROUP
%token PE_ERROR
+%token PE_PMU_EVENT_PRE PE_PMU_EVENT_SUF PE_KERNEL_PMU_EVENT
%type PE_VALUE
%type PE_VALUE_SYM_HW
%type PE_VALUE_SYM_SW
@@ -58,6 +59,7 @@ static inc_group_count(struct list_head *list,
%type PE_MODIFIER_EVENT
%type PE_MODIFIER_BP
%type PE_EVENT_NAME
+%type PE_PMU_EVENT_PRE PE_PMU_EVENT_SUF PE_KERNEL_PMU_EVENT
%type value_sym
%type event_config
%type event_term
@@ -220,6 +222,44 @@ PE_NAME '/' '/'
ABORT_ON(parse_events_add_pmu(list, &data->idx, $1, NULL));
[tip:perf/urgent] Revert "perf tools: Default to cpu// for events v5"
Commit-ID: 42f60c2d63b0d3f7230d28ac37c1da4885d4ee65
Gitweb: http://git.kernel.org/tip/42f60c2d63b0d3f7230d28ac37c1da4885d4ee65
Author: Kan Liang
AuthorDate: Tue, 7 Oct 2014 11:08:49 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 16:04:33 -0300
Revert "perf tools: Default to cpu// for events v5"
This reverts commit 50e200f07948 ("perf tools: Default to cpu// for
events v5")
The fixup cannot handle the case that
new style format(which without //) mixed with
other different formats.
For example,
group events with new style format: {mem-stores,mem-loads}
some hardware event + new style event: cycles,mem-loads
Cache event + new style event: LLC-loads,mem-loads
Raw event + new style event:
cpu/event=0xc8,umask=0x08/,mem-loads
old style event and new stytle mixture: mem-stores,cpu/mem-loads/
Signed-off-by: Kan Liang
Acked-by: Jiri Olsa
Cc: Andi Kleen
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1412694532-23391-2-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/include/linux/string.h | 1 -
tools/perf/util/parse-events.c | 30 +-
tools/perf/util/string.c | 24
3 files changed, 1 insertion(+), 54 deletions(-)
diff --git a/tools/perf/util/include/linux/string.h
b/tools/perf/util/include/linux/string.h
index 97a8007..6f19c54 100644
--- a/tools/perf/util/include/linux/string.h
+++ b/tools/perf/util/include/linux/string.h
@@ -1,4 +1,3 @@
#include
void *memdup(const void *src, size_t len);
-int str_append(char **s, int *len, const char *a);
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index d76aa30..c5642e6 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -6,7 +6,7 @@
#include "parse-options.h"
#include "parse-events.h"
#include "exec_cmd.h"
-#include "linux/string.h"
+#include "string.h"
#include "symbol.h"
#include "cache.h"
#include "header.h"
@@ -863,32 +863,6 @@ int parse_events_name(struct list_head *list, char *name)
return 0;
}
-static int parse_events__scanner(const char *str, void *data, int start_token);
-
-static int parse_events_fixup(int ret, const char *str, void *data,
- int start_token)
-{
- char *o = strdup(str);
- char *s = NULL;
- char *t = o;
- char *p;
- int len = 0;
-
- if (!o)
- return ret;
- while ((p = strsep(&t, ",")) != NULL) {
- if (s)
- str_append(&s, &len, ",");
- str_append(&s, &len, "cpu/");
- str_append(&s, &len, p);
- str_append(&s, &len, "/");
- }
- free(o);
- if (!s)
- return -ENOMEM;
- return parse_events__scanner(s, data, start_token);
-}
-
static int parse_events__scanner(const char *str, void *data, int start_token)
{
YY_BUFFER_STATE buffer;
@@ -909,8 +883,6 @@ static int parse_events__scanner(const char *str, void
*data, int start_token)
parse_events__flush_buffer(buffer, scanner);
parse_events__delete_buffer(buffer, scanner);
parse_events_lex_destroy(scanner);
- if (ret && !strchr(str, '/'))
- ret = parse_events_fixup(ret, str, data, start_token);
return ret;
}
diff --git a/tools/perf/util/string.c b/tools/perf/util/string.c
index d87767f..6afd610 100644
--- a/tools/perf/util/string.c
+++ b/tools/perf/util/string.c
@@ -357,27 +357,3 @@ void *memdup(const void *src, size_t len)
return p;
}
-
-/**
- * str_append - reallocate string and append another
- * @s: pointer to string pointer
- * @len: pointer to len (initialized)
- * @a: string to append.
- */
-int str_append(char **s, int *len, const char *a)
-{
- int olen = *s ? strlen(*s) : 0;
- int nlen = olen + strlen(a) + 1;
- if (*len < nlen) {
- *len = *len * 2;
- if (*len < nlen)
- *len = nlen;
- *s = realloc(*s, *len);
- if (!*s)
- return -ENOMEM;
- if (olen == 0)
- **s = 0;
- }
- strcat(*s, a);
- return 0;
-}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf top: Add a visual cue for toggle zeroing of samples
Commit-ID: 1e378ebd117d1828b9d5dbe0538887478fcb9d84
Gitweb: http://git.kernel.org/tip/1e378ebd117d1828b9d5dbe0538887478fcb9d84
Author: Taeung Song
AuthorDate: Tue, 7 Oct 2014 16:13:15 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Oct 2014 15:47:48 -0300
perf top: Add a visual cue for toggle zeroing of samples
When 'perf top' is run, one can't easily find a difference
between -z option and normal output.
So I added a visual cue to know whether it is the zeroing or not.
Output is as below.
Before:
$ perf top
Samples: 61K of event 'cycles', Event count (approx.): 3908136933
Overhead Shared Object Symbol
1.42% firefox [.] 0x00011e76
1.32% libpthread-2.17.so [.] pthread_mutex_lock
If you press key 'z' or run with zero option like '$ perf top --zero', it is as
below.
After:
Samples: 61K of event 'cycles', Event count (approx.): 3908136933 [z]
Overhead Shared Object Symbol
1.42% firefox [.] 0x00011e76
1.32% libpthread-2.17.so [.] pthread_mutex_lock
Signed-off-by: Taeung Song
Acked-by: Namhyung Kim
Cc: Namhyung Kim
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1412665995-26359-1-git-send-email-treeze.tae...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 68eab9e..cfb976b 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -35,7 +35,9 @@ struct hist_browser {
extern void hist_browser__init_hpp(void);
-static int hists__browser_title(struct hists *hists, char *bf, size_t size);
+static int hists__browser_title(struct hists *hists,
+ struct hist_browser_timer *hbt,
+ char *bf, size_t size);
static void hist_browser__update_nr_entries(struct hist_browser *hb);
static struct rb_node *hists__filter_entries(struct rb_node *nd,
@@ -390,7 +392,7 @@ static int hist_browser__run(struct hist_browser *browser,
browser->b.entries = &browser->hists->entries;
browser->b.nr_entries = hist_browser__nr_entries(browser);
- hists__browser_title(browser->hists, title, sizeof(title));
+ hists__browser_title(browser->hists, hbt, title, sizeof(title));
if (ui_browser__show(&browser->b, title,
"Press '?' for help on key bindings") < 0)
@@ -417,7 +419,8 @@ static int hist_browser__run(struct hist_browser *browser,
ui_browser__warn_lost_events(&browser->b);
}
- hists__browser_title(browser->hists, title,
sizeof(title));
+ hists__browser_title(browser->hists,
+hbt, title, sizeof(title));
ui_browser__show_title(&browser->b, title);
continue;
}
@@ -1204,7 +1207,15 @@ static struct thread
*hist_browser__selected_thread(struct hist_browser *browser
return browser->he_selection->thread;
}
-static int hists__browser_title(struct hists *hists, char *bf, size_t size)
+/* Check whether the browser is for 'top' or 'report' */
+static inline bool is_report_browser(void *timer)
+{
+ return timer == NULL;
+}
+
+static int hists__browser_title(struct hists *hists,
+ struct hist_browser_timer *hbt,
+ char *bf, size_t size)
{
char unit;
int printed;
@@ -1258,6 +1269,13 @@ static int hists__browser_title(struct hists *hists,
char *bf, size_t size)
if (dso)
printed += scnprintf(bf + printed, size - printed,
", DSO: %s", dso->short_name);
+ if (!is_report_browser(hbt)) {
+ struct perf_top *top = hbt->arg;
+
+ if (top->zero)
+ printed += scnprintf(bf + printed, size - printed, "
[z]");
+ }
+
return printed;
}
@@ -1269,12 +1287,6 @@ static inline void free_popup_options(char **options,
int n)
zfree(&options[i]);
}
-/* Check whether the browser is for 'top' or 'report' */
-static inline bool is_report_browser(void *timer)
-{
- return timer == NULL;
-}
-
/*
* Only runtime switching of perf data file will make "input_name" point
* to a malloced buffer. So add "is_input_name_malloced" flag to decide
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/15] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, I guess the changes are minor of affect just
> some
> non-core feature, so it is you call if you prefer to pull it into perf/urgent
> instead.
>
> Best Regards,
>
> - Arnaldo
>
> The following changes since commit ec4212d88a77eb6caec10777ddd629b702a5ebbd:
>
> Merge tag 'perf-core-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
> (2014-10-15 11:54:14 +0200)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-core-for-mingo
>
> for you to fetch changes up to 673d659f5c5918b7ddbafebf1f129c9eb82973b4:
>
> perf kvm stat live: Enable events copying (2014-10-15 17:39:03 -0300)
>
>
> perf/core improvements and fixes:
>
> User visible:
>
> * Add a visual cue for toggle zeroing of samples in 'perf top' (Taeung Song)
>
> * Fix for double free in 'perf stat' when using some specific invalid
> command line combo (Yasser Shalabi)
>
> Infrastructure:
>
> * Add option to copy events when queuing for sorting across cpu buffers
> and enable it for 'perf kvm stat live', to avoid having events left
> in the queue pointing to the ring buffer be rewritten in high volume
> sessions. (Alexander Yarygin, improving work done by David Ahern):
>
> * Document sysfs events/ interfaces (Cody P Schafer)
>
> * Add support to new style format of kernel PMU event. (Kan Liang)
>
> * Fix typos in perf/Documentation (Masanari Iida)
>
> * Improve callchains when using libunwind (Namhyung Kim)
>
> Signed-off-by: Arnaldo Carvalho de Melo
> Lines starting with '#' will be ignored.
>
>
> Alexander Yarygin (2):
> perf session: Add option to copy events when queueing
> perf kvm stat live: Enable events copying
>
> Cody P Schafer (2):
> perf Documentation: sysfs events/ interfaces
> perf Documentation: Remove Ruplicated docs for powerpc cpu specific
> events
>
> Kan Liang (4):
> Revert "perf tools: Default to cpu// for events v5"
> perf tools: Parse the pmu event prefix and suffix
> perf tools: Add support to new style format of kernel PMU event
> perf test: Add test case for pmu event new style format
>
> Masanari Iida (1):
> perf Documentation: Fix typos in perf/Documentation
>
> Namhyung Kim (4):
> perf report: Set callchain_param.record_mode for future use
> perf callchain: Create an address space per thread
> perf kvm: Use thread_{,_set}_priv helpers
> perf trace: Use thread_{,_set}_priv helpers
>
> Taeung Song (1):
> perf top: Add a visual cue for toggle zeroing of samples
>
> Yasser Shalabi (1):
> perf evlist: Fix for double free in tools/perf stat
>
> .../testing/sysfs-bus-event_source-devices-events | 611
> ++---
> tools/perf/Documentation/perf-diff.txt | 6 +-
> tools/perf/Documentation/perf-kvm.txt | 4 +-
> tools/perf/Documentation/perf-list.txt | 2 +-
> tools/perf/Documentation/perf-record.txt | 2 +-
> tools/perf/Documentation/perf-script-perl.txt | 4 +-
> tools/perf/Documentation/perf-script-python.txt| 6 +-
> tools/perf/Documentation/perf-script.txt | 2 +-
> tools/perf/Documentation/perf-test.txt | 2 +-
> tools/perf/Documentation/perf-trace.txt| 2 +-
> tools/perf/builtin-kvm.c | 7 +-
> tools/perf/builtin-report.c| 7 +
> tools/perf/builtin-trace.c | 16 +-
> tools/perf/tests/dwarf-unwind.c| 3 +
> tools/perf/tests/parse-events.c| 36 ++
> tools/perf/ui/browsers/hists.c | 32 +-
> tools/perf/util/evlist.c | 1 +
> tools/perf/util/include/linux/string.h | 1 -
> tools/perf/util/ordered-events.c | 49 +-
> tools/perf/util/ordered-events.h | 10 +-
> tools/perf/util/parse-events.c | 133 -
> tools/perf/util/parse-events.h | 14 +
> tools/perf/util/parse-events.l | 30 +-
> tools/perf/util/parse-events.y | 40 ++
> tools/perf/util/pmu.c | 10 -
> tools/perf/util/pmu.h | 10 +
> tools/perf/util/session.c | 5 +-
> tools/perf/util/string.c | 24 -
> tools/perf/util/thread.c | 6 +
> tools/perf/util/unwind-libunwind.c | 37 +-
> tools/perf/util/unwind.h | 17 +
> 31 files changed, 460 insertions(+), 669 deletions(-)
Pulled, thanks a lot Arnaldo!
Ingo
--
T
Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation
On Thu, Oct 16, 2014 at 11:35 AM, Hui Zhu wrote: > In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > MIGRATE_MOVABLE. > MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > order that Linux kernel want. > > If a system that has a lot of user space program is running, for > instance, an Android board, most of memory is in MIGRATE_MOVABLE and > allocated. Before function __rmqueue_fallback get memory from > MIGRATE_CMA, the oom_killer will kill a task to release memory when > kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > This status is odd. The MIGRATE_CMA has a lot free memory but Linux > kernel kill some tasks to release memory. I'm not very clear to this description, what issue do you try to solve? Make MIGRATE_CMA be the fallback of desired MIGRATE_UNMOVABLE? > This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > be more aggressive about allocation. > If function CMA_AGGRESSIVE is available, when Linux kernel call function > __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > doesn't have enough pages for allocation, go back to allocate memory from > MIGRATE_MOVABLE. I don't think so. That will cause MIGRATE_CMA depleted prematurely, and when a user(such as camera) wants CMA memory, he will not get the wanted memory. > Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. I don't think this is the root cause of oom. But I am interested in the CMA shrinker idea, I will follow this mail. Thanks for your work, add some test data will be better. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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/
linux-next: Tree for Oct 16
Hi all, Please do not add any material intended for v3.19 to your linux-next included trees until after v3.18-rc1 has been released. Changes since 20141015: The net tree lost its build failure. The thermal tree gained a build failure for which I reverted a commit. The akpm-current tree gained a build failure for which I applied a patch. The akpm tree lost a patch that turned up elsewhere. Non-merge commits (relative to Linus' tree): 1106 1073 files changed, 32703 insertions(+), 16141 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 225 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (0429fbc0bdc2 Merge branch 'for-3.18-consistent-ops' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (ad684dce87fa ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset") Merging m68k-current/for-linus (24cae7934cf1 m68k: Reformat arch/m68k/mm/hwtest.c) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging powerpc-merge-mpe/for-linus (d53ba6b3bba3 cxl: Fix afu_read() not doing finish_wait() on signal or non-blocking) Merging sparc/master (f4da3628dc7c sparc64: Fix FPU register corruption with AES crypto offload.) Merging net/master (f5b720b85944 gianfar: Add FCS to rx buffer size (fix)) Merging ipsec/master (b8c203b2d2fc xfrm: Generate queueing routes only from route lookup functions) Merging sound-current/for-linus (c8b00fd2f4c5 ALSA: hda_intel: Add Device IDs for Intel Sunrise Point PCH) Merging pci-current/for-linus (52265ae92ab9 Merge branch 'remove-weak-function-declarations' into for-linus) Merging wireless/master (f8adaf0ae978 brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()) Merging driver-core.current/driver-core-linus (5e40d331bd72 Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security) Merging tty.current/tty-linus (9e82bf014195 Linux 3.17-rc5) Merging usb.current/usb-linus (0f33be009b89 Linux 3.17-rc6) Merging usb-gadget-fixes/fixes (0b93a4c838fa usb: dwc3: fix TRB completion when multiple TRBs are started) Merging usb-serial-fixes/usb-linus (dee80ad12d2b USB: cp210x: add support for Seluxit USB dongle) Merging staging.current/staging-linus (80213c03c415 Merge tag 'pci-v3.18-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging char-misc.current/char-misc-linus (9e82bf014195 Linux 3.17-rc5) Merging input-current/for-linus (447a8b858e4b Merge branch 'next' into for-linus) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (be34c4ef693f crypto: sha - Handle unaligned input data in generic sha256 and sha512.) Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NUL
Re: [PATCH] arch: arm: mach-shmobile: Remove ARCH_HAS_OPP completely
On Wed, Oct 15, 2014 at 03:29:45PM +0200, Rolf Evers-Fischer wrote:
> The Kconfig symbol ARCH_HAS_OPP became redundant in v3.16: commit
> 049d595a4db3 ("PM / OPP: Make OPP invisible to users in Kconfig")
> removed the only dependency that used it. Setting it had no effect
> anymore.
>
> So commit 78c5e0bb145d ("PM / OPP: Remove ARCH_HAS_OPP") removed it. For
> some reason that commit did not remove all select statements for that
> symbol. These statements are now useless.
>
> Commit adad5621f3e1 ("PM / devfreq: Remove ARCH_HAS_OPP completely")
> removed it for devfreq. Remove one from mach-shmobile too.
>
> Signed-off-by: Rolf Evers-Fischer
Thanks, I have queued this up.
> ---
> arch/arm/mach-shmobile/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 21f457b..f59019d 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -36,7 +36,6 @@ menuconfig ARCH_SHMOBILE_MULTI
> select NO_IOPORT_MAP
> select PINCTRL
> select ARCH_REQUIRE_GPIOLIB
> - select ARCH_HAS_OPP
>
> if ARCH_SHMOBILE_MULTI
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 10/10] uprobes: Remove "weak" from function declarations
* Bjorn Helgaas wrote:
> For the following interfaces:
>
> set_swbp()
> set_orig_insn()
> is_swbp_insn()
> is_trap_insn()
> uprobe_get_swbp_addr()
> arch_uprobe_ignore()
> arch_uprobe_copy_ixol()
>
> kernel/events/uprobes.c provides default definitions explicitly marked
> "weak". Some architectures provide their own definitions intended to
> override the defaults, but the "weak" attribute on the declarations applied
> to the arch definitions as well, so the linker chose one based on link
> order (see 10629d711ed7 ("PCI: Remove __weak annotation from
> pcibios_get_phb_of_node decl")).
>
> Remove the "weak" attribute from the declarations so we always prefer a
> non-weak definition over the weak one, independent of link order.
>
> Signed-off-by: Bjorn Helgaas
> CC: Victor Kamensky
> CC: Oleg Nesterov
> CC: David A. Long
> CC: Srikar Dronamraju
> CC: Ananth N Mavinakayanahalli
> ---
> include/linux/uprobes.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> index 4f844c6b03ee..60beb5dc7977 100644
> --- a/include/linux/uprobes.h
> +++ b/include/linux/uprobes.h
> @@ -98,11 +98,11 @@ struct uprobes_state {
> struct xol_area *xol_area;
> };
>
> -extern int __weak set_swbp(struct arch_uprobe *aup, struct mm_struct *mm,
> unsigned long vaddr);
> -extern int __weak set_orig_insn(struct arch_uprobe *aup, struct mm_struct
> *mm, unsigned long vaddr);
> -extern bool __weak is_swbp_insn(uprobe_opcode_t *insn);
> -extern bool __weak is_trap_insn(uprobe_opcode_t *insn);
> -extern unsigned long __weak uprobe_get_swbp_addr(struct pt_regs *regs);
> +extern int set_swbp(struct arch_uprobe *aup, struct mm_struct *mm, unsigned
> long vaddr);
> +extern int set_orig_insn(struct arch_uprobe *aup, struct mm_struct *mm,
> unsigned long vaddr);
> +extern bool is_swbp_insn(uprobe_opcode_t *insn);
> +extern bool is_trap_insn(uprobe_opcode_t *insn);
> +extern unsigned long uprobe_get_swbp_addr(struct pt_regs *regs);
> extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
> extern int uprobe_write_opcode(struct mm_struct *mm, unsigned long vaddr,
> uprobe_opcode_t);
> extern int uprobe_register(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc);
> @@ -128,8 +128,8 @@ extern bool arch_uprobe_xol_was_trapped(struct
> task_struct *tsk);
> extern int arch_uprobe_exception_notify(struct notifier_block *self,
> unsigned long val, void *data);
> extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs
> *regs);
> extern unsigned long arch_uretprobe_hijack_return_addr(unsigned long
> trampoline_vaddr, struct pt_regs *regs);
> -extern bool __weak arch_uprobe_ignore(struct arch_uprobe *aup, struct
> pt_regs *regs);
> -extern void __weak arch_uprobe_copy_ixol(struct page *page, unsigned long
> vaddr,
> +extern bool arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs
> *regs);
> +extern void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
>void *src, unsigned long len);
> #else /* !CONFIG_UPROBES */
> struct uprobes_state {
Acked-by: Ingo Molnar
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 06/10] clocksource: Remove "weak" from clocksource_default_clock() declaration
* Bjorn Helgaas wrote:
> kernel/time/jiffies.c provides a default clocksource_default_clock()
> definition explicitly marked "weak". arch/s390 provides its own definition
> intended to override the default, but the "weak" attribute on the
> declaration applied to the s390 definition as well, so the linker chose one
> based on link order (see 10629d711ed7 ("PCI: Remove __weak annotation from
> pcibios_get_phb_of_node decl")).
>
> Remove the "weak" attribute from the clocksource_default_clock()
> declaration so we always prefer a non-weak definition over the weak one,
> independent of link order.
>
> Fixes: f1b82746c1e9 ("clocksource: Cleanup clocksource selection")
> Signed-off-by: Bjorn Helgaas
> CC: Daniel Lezcano
> CC: Martin Schwidefsky
> ---
> include/linux/clocksource.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
> index 653f0e2b6ca9..abcafaa20b86 100644
> --- a/include/linux/clocksource.h
> +++ b/include/linux/clocksource.h
> @@ -287,7 +287,7 @@ extern struct clocksource* clocksource_get_next(void);
> extern void clocksource_change_rating(struct clocksource *cs, int rating);
> extern void clocksource_suspend(void);
> extern void clocksource_resume(void);
> -extern struct clocksource * __init __weak clocksource_default_clock(void);
> +extern struct clocksource * __init clocksource_default_clock(void);
> extern void clocksource_mark_unstable(struct clocksource *cs);
Acked-by: Ingo Molnar
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 02/10] x86, intel-mid: Remove "weak" from function declarations
* Bjorn Helgaas wrote: > For the following interfaces: > > get_penwell_ops() > get_cloverview_ops() > get_tangier_ops() > > there is only one implementation, so they do not need to be marked "weak". > > Remove the "weak" attribute from their declarations. > > Signed-off-by: Bjorn Helgaas > CC: David Cohen > CC: Kuppuswamy Sathyanarayanan > CC: x...@kernel.org > --- > arch/x86/platform/intel-mid/intel_mid_weak_decls.h |7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > index 46aa25c8ce06..3c1c3866d82b 100644 > --- a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > +++ b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > @@ -10,10 +10,9 @@ > */ > > > -/* __attribute__((weak)) makes these declarations overridable */ > /* For every CPU addition a new get__ops interface needs > * to be added. > */ > -extern void *get_penwell_ops(void) __attribute__((weak)); > -extern void *get_cloverview_ops(void) __attribute__((weak)); > -extern void *get_tangier_ops(void) __attribute__((weak)); > +extern void *get_penwell_ops(void); > +extern void *get_cloverview_ops(void); > +extern void *get_tangier_ops(void); Acked-by: Ingo Molnar Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [kernel]: process: replace printk with pr_err
This patch replaces printk(KERN_ERR...) with pr_err found.
Signed-off-by: Vishnu Pratap Singh
---
kernel/power/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 7b32322..401f7ee 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -85,7 +85,7 @@ static int try_to_freeze_tasks(bool user_only)
if (todo) {
printk("\n");
- printk(KERN_ERR "Freezing of tasks %s after %d.%03d seconds "
+ pr_err("Freezing of tasks %s after %d.%03d seconds "
"(%d tasks refusing to freeze, wq_busy=%d):\n",
wakeup ? "aborted" : "failed",
elapsed_msecs / 1000, elapsed_msecs % 1000,
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: orion_nand: fix error code path in probe
On 10/14/2014 11:35 PM, Andrew Lunn wrote:
>
>
> if (pdev->dev.of_node) {
> board = devm_kzalloc(&pdev->dev, sizeof(struct orion_nand_data),
> GFP_KERNEL);
> if (!board) {
> - ret = -ENOMEM;
> - goto no_res;
> + return -ENOMEM;
> }
> Doesn't this now break the coding style? No need to have the {} since
> it is a single statement.
Right, I've checked Documentation/CodingStyle, and this is just
recommended, not absolutely required. That could be the reason why
check_patch.pl didn't complain.
My v2 changes this.
Thanks!
Michael.
--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: orion_nand: fix error code path in probe
This replaces kzalloc() and ioremap() calls by devm_ functions
in the probe() routine, which automatically release the corresponding
resources when probe() fails or when the device is removed.
This simplifies simplifies the error management code, and brings
the below improvements or changes:
A. Fixing a bug reported by "make coccicheck":
If "board = devm_kzalloc()" fails, the probe() function jumps
incorrectly to label "no_res" and therefore returns without
running iounmap().
B. Requesting the memory region
Using devm_ioremap_resource() makes the probe() function request
the corresponding memory region before running ioremap(), as
it is supposed to do.
C. Standardizing the error codes:
The use of devm_ioremap_resource() changes the return value:
* -ENOMEM instead of -EIO in case of ioremap() failure,
* -EINVAL instead of -ENODEV in case of platform_get_resource()
failure.
Signed-off-by: Michael Opdenacker
---
drivers/mtd/nand/orion_nand.c | 39 +++
1 file changed, 11 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index 471b4df3a5ac..0b49d5d34c50 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -19,7 +19,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -85,33 +85,24 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
int ret = 0;
u32 val = 0;
- nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info),
GFP_KERNEL);
- if (!nc) {
- ret = -ENOMEM;
- goto no_res;
- }
+ nc = devm_kzalloc(&pdev->dev,
+ sizeof(struct nand_chip) + sizeof(struct mtd_info),
+ GFP_KERNEL);
+ if (!nc)
+ return -ENOMEM;
mtd = (struct mtd_info *)(nc + 1);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- ret = -ENODEV;
- goto no_res;
- }
+ io_base = devm_ioremap_resource(&pdev->dev, res);
- io_base = ioremap(res->start, resource_size(res));
- if (!io_base) {
- dev_err(&pdev->dev, "ioremap failed\n");
- ret = -EIO;
- goto no_res;
- }
+ if (IS_ERR(io_base))
+ return PTR_ERR(io_base);
if (pdev->dev.of_node) {
board = devm_kzalloc(&pdev->dev, sizeof(struct orion_nand_data),
GFP_KERNEL);
- if (!board) {
- ret = -ENOMEM;
- goto no_res;
- }
+ if (!board)
+ return -ENOMEM;
if (!of_property_read_u32(pdev->dev.of_node, "cle", &val))
board->cle = (u8)val;
else
@@ -185,9 +176,6 @@ no_dev:
clk_disable_unprepare(clk);
clk_put(clk);
}
- iounmap(io_base);
-no_res:
- kfree(nc);
return ret;
}
@@ -195,15 +183,10 @@ no_res:
static int orion_nand_remove(struct platform_device *pdev)
{
struct mtd_info *mtd = platform_get_drvdata(pdev);
- struct nand_chip *nc = mtd->priv;
struct clk *clk;
nand_release(mtd);
- iounmap(nc->IO_ADDR_W);
-
- kfree(nc);
-
clk = clk_get(&pdev->dev, NULL);
if (!IS_ERR(clk)) {
clk_disable_unprepare(clk);
--
1.9.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/
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from mm/memcontrol.c:28:0:
include/linux/page_counter.h: In function 'page_counter_init':
include/linux/page_counter.h:19:27: error: 'LONG_MAX' undeclared (first use in
this function)
#define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
^
include/linux/page_counter.h:26:19: note: in expansion of macro
'PAGE_COUNTER_MAX'
counter->limit = PAGE_COUNTER_MAX;
^
include/linux/page_counter.h:19:27: note: each undeclared identifier is
reported only once for each function it appears in
#define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
^
include/linux/page_counter.h:26:19: note: in expansion of macro
'PAGE_COUNTER_MAX'
counter->limit = PAGE_COUNTER_MAX;
^
include/linux/page_counter.h:19:38: error: 'PAGE_SIZE' undeclared (first use in
this function)
#define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
^
include/linux/page_counter.h:26:19: note: in expansion of macro
'PAGE_COUNTER_MAX'
counter->limit = PAGE_COUNTER_MAX;
^
In file included from mm/page_counter.c:7:0:
include/linux/page_counter.h: In function 'page_counter_init':
include/linux/page_counter.h:19:27: error: 'LONG_MAX' undeclared (first use in
this function)
#define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
^
include/linux/page_counter.h:26:19: note: in expansion of macro
'PAGE_COUNTER_MAX'
counter->limit = PAGE_COUNTER_MAX;
^
include/linux/page_counter.h:19:27: note: each undeclared identifier is
reported only once for each function it appears in
#define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
^
include/linux/page_counter.h:26:19: note: in expansion of macro
'PAGE_COUNTER_MAX'
counter->limit = PAGE_COUNTER_MAX;
^
include/linux/page_counter.h:19:38: error: 'PAGE_SIZE' undeclared (first use in
this function)
#define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
^
include/linux/page_counter.h:26:19: note: in expansion of macro
'PAGE_COUNTER_MAX'
counter->limit = PAGE_COUNTER_MAX;
^
Caused by commit 36a1bfb2a772 ("mm: memcontrol: lockless page
counters"). See Rule 1 in Documentation/SubmitChecklist.
I have added the following patch for today:
From: Stephen Rothwell
Date: Thu, 16 Oct 2014 15:49:08 +1100
Subject: [PATCH] mm: memcontrol: add includes for page_counter.h
Signed-off-by: Stephen Rothwell
---
include/linux/page_counter.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h
index a878ef61d073..785640e4efec 100644
--- a/include/linux/page_counter.h
+++ b/include/linux/page_counter.h
@@ -2,6 +2,9 @@
#define _LINUX_PAGE_COUNTER_H
#include
+#include
+
+#include
struct page_counter {
atomic_long_t count;
--
2.1.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH] mtd: orion_nand: fix error code path in probe
Andrew, Ezequiel, Many thanks for your review! On 10/15/2014 11:39 PM, Ezequiel Garcia wrote: > On 14 Oct 11:35 PM, Andrew Lunn wrote: > >> Hi Michael >> >> It is quite a common pattern to use: >> >> res = platform_get_resource(dev, IORESOURCE_MEM, 0); >> c->membase = devm_ioremap_resource(&dev->dev, res); >> if (IS_ERR(c->membase)) >> return PTR_ERR(c->membase) >> >> which is more compact. I like it, thanks for the suggestion! >> > Be careful with this. devm_ioremap and devm_ioremap_resource are not > the same thing, as the former requests the region as well. > > It can break things if the region is shared across several drivers. > I don't think this is the case, so in fact adding the request is correct, > but it's a more intrusive change than just "code cleanup". Right. If I understand correctly, requesting the region should always be done anyway, so this should be a welcome change. What Andrew suggests also changes the return value: -ENOMEM instead of -EIO, though it should be more standard. This could have side effects too! I'll post a V2 right away. Thanks again! Cheers, Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Machine crashes right *after* ~successful resume
On Wed, Oct 15, 2014 at 4:34 PM, Wilmer van der Gaast wrote:
>
> Is there anything I can do now to find out why your change is causing my
> machine to crash?
Can you please try attached patch? that should workaround the problem.
as some driver is using pci_enable_device in .resume instead of
pci_renable_device
We should skip the pci_enable_bridge in those pci_enable_device to avoid
contention between async device_resume.
Thanks
Yinghai
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 625a4ac..6567831 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1266,7 +1266,6 @@ static void pci_enable_bridge(struct pci_dev *dev)
static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
{
- struct pci_dev *bridge;
int err;
int i, bars = 0;
@@ -1285,9 +1284,19 @@ static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
if (atomic_inc_return(&dev->enable_cnt) > 1)
return 0; /* already enabled */
- bridge = pci_upstream_bridge(dev);
- if (bridge)
- pci_enable_bridge(bridge);
+ /*
+ * Do not enable bridge again on resume path, as parent state
+ * get restored before.
+ * Also could avoid delay between different async resume.
+ */
+ if (!(dev->dev.power.is_suspended ||
+ dev->dev.power.is_noirq_suspended ||
+ dev->dev.power.is_late_suspended)) {
+ struct pci_dev *bridge = pci_upstream_bridge(dev);
+
+ if (bridge)
+ pci_enable_bridge(bridge);
+ }
/* only skip sriov related */
for (i = 0; i <= PCI_ROM_RESOURCE; i++)
Re: [PATCHv3 3/3] gpio: sch: Enable IRQ support for Quark X1000
On 10/16/2014 09:21 AM, Chang Rebecca Swee Fun wrote:
Intel Quark X1000 GPIO controller supports interrupt handling for
both core power well and resume power well. This patch is to enable
the IRQ support and provide IRQ handling for Intel Quark X1000
GPIO-SCH device driver.
(...)
static int sch_gpio_probe(struct platform_device *pdev)
{
struct sch_gpio *sch;
- struct resource *res;
+ struct resource *res, *irq;
+ int err;
sch = devm_kzalloc(&pdev->dev, sizeof(*sch), GFP_KERNEL);
if (!sch)
@@ -203,6 +376,17 @@ static int sch_gpio_probe(struct platform_device *pdev)
pdev->name))
return -EBUSY;
+ irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ sch->irq_support = !!irq;
+ if (sch->irq_support) {
+ sch->irq_num = irq->start;
+ if (sch->irq_num < 0) {
+ dev_warn(&pdev->dev,
+"failed to obtain irq number for device\n");
+ sch->irq_support = false;
+ }
+ }
+
spin_lock_init(&sch->lock);
sch->iobase = res->start;
sch->chip = sch_gpio_chip;
@@ -251,15 +435,64 @@ static int sch_gpio_probe(struct platform_device *pdev)
return -ENODEV;
}
+ err = gpiochip_add(&sch->chip);
+ if (err < 0)
+ goto err_sch_gpio;
+
+ if (sch->irq_support) {
+ sch->irq_base = irq_alloc_descs(-1, 0, sch->chip.ngpio,
+ NUMA_NO_NODE);
+ if (sch->irq_base < 0) {
+ dev_err(&pdev->dev,
+ "failed to allocate GPIO IRQ descs\n");
+ goto err_sch_intr_chip;
+ }
+
+ /* disable interrupts */
+ sch_gpio_irq_disable_all(sch, sch->chip.ngpio);
+
+ err = request_irq(sch->irq_num, sch_gpio_irq_handler,
+ IRQF_SHARED, KBUILD_MODNAME, sch);
+ if (err) {
+ dev_err(&pdev->dev,
+ "%s failed to request IRQ\n", __func__);
+ goto err_sch_request_irq;
+ }
+
+ sch_gpio_irqs_init(sch, sch->chip.ngpio);
+ }
+
platform_set_drvdata(pdev, sch);
- return gpiochip_add(&sch->chip);
+ return 0;
+
+err_sch_request_irq:
+ irq_free_descs(sch->irq_base, sch->chip.ngpio);
+
+err_sch_intr_chip:
+ if (gpiochip_remove(&sch->chip))
gpiochip_remove() return 'void' [0].
+ dev_err(&pdev->dev,
+ "%s gpiochip_remove() failed\n", __func__);
+
+err_sch_gpio:
+ release_region(res->start, resource_size(res));
+
+ return err;
}
[0]:https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/tree/drivers/gpio/gpiolib.c#n311
--
Regards,
Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: of/pci: Fix the conversion of IO ranges into IO resources
On Thu, 2014-10-16 at 13:55 +1100, Michael Ellerman wrote: > Yes, we already provide our own version of pci_address_to_pio(). > > The problem is it's too early to call it when we come in from > find_and_init_phbs() -> pci_process_bridge_OF_ranges(), so it returns junk. > > I think you were expecting us to hit the #ifndef PCI_IOBASE case, which looks > like it might have worked. > > For now we're just going to stop using of_pci_range_to_resource(). Right, this is a band-aid to fix things now. For the long run, I think we could exploit Liviu's code with a few changes: - We would want to add a variant of pci_register_io_range() that takes the actual PIO address as an argument so we can use it to "register" our ranges on ppc64 since we decide where in IO space they go using our own algorithm and we don't want to change that. That would make the generic pci_pio_to_address() and pci_address_to_pio() work for us. At least for ppc64. - For ppc32, we might want to consider changing the horrible pointer arithmetic we do today (which keeps breaking) and just switch to the allocator inside pci_register_io_range() and use it like ARM does. - I object to of_pci_range_to_resource() implicitly doing the allocation/registration of the range. It should fail if the range isn't registered. The architecture code should explicitly register the IO ranges before trying to turn them into resources. Now, this will take a bit more time to sort out (and the latter comment will mean, if addressed, some changes to the new ARM code which I don't think I have the bandwidth to do), so I'm happy to settle for whatever band-aid Michael is coming up with for 3.18 but we should consider improving things for .19 Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 0/3] Enable Quark X1000 support in gpio-sch
Hi, This is a revised version for enabling Quark X1000 in gpio-sch. Change log for V3: The patches had been rebased on "devel" branch and it has dependency on Mika Westerberg's commit at: https://lkml.org/lkml/2014/9/16/213 Patch 3: - Change variable type of irq_support to bool. - Update error message and remove redundant code. - Revert gpiochip_remove() to avoid it to return a value. The changes had been verified by passing build test and functional test on Intel Galileo board. Thank you. Regards, Rebecca Change log for V2: Patch 1: - Move sch_gpio_get() and sch_gpio_set() to avoid forward declaration. - Changed sch_gpio_enable()/sch_gpio_disable() to sch_gpio_register_set()/ sch_gpio_register_clear(). Patch 3: - Changed all sch_gpio_enable()/sch_gpio_disable() to sch_gpio_register_set()/ sch_gpio_register_clear(). Version 1: Initial version. Chang Rebecca Swee Fun (3): gpio: sch: Consolidate similar algorithms gpio: sch: Add support for Intel Quark X1000 SoC gpio: sch: Enable IRQ support for Quark X1000 drivers/gpio/Kconfig| 11 +- drivers/gpio/gpio-sch.c | 353 --- 2 files changed, 311 insertions(+), 53 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tiny: reverse logic for DISABLE_DEV_COREDUMP
On Thu, Oct 16, 2014 at 01:14:46AM +0200, Greg Kroah-Hartman wrote: > On Wed, Oct 15, 2014 at 11:25:23AM -0400, Aristeu Rozanski wrote: > > It's desirable for allnconfig and tinyconfig targets to result in the > > least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to > > switch off DEV_COREDUMP regardless if any drivers select > > WANT_DEV_COREDUMP. > > > > This patch renames the option to ENABLE_DEV_COREDUMP and setting it to > > 'n' (as in allnconfig or tinyconfig) will effectively disable device > > coredump. > > > > Cc: Greg Kroah-Hartman > > Cc: Josh Triplett > > Reviewed-by: Josh Triplett > > Signed-off-by: Aristeu Rozanski > > Any reason you didn't cc: the author of this feature / Kconfig option > about this change you are proposing? Likely my fault; I'd suggested using get_maintainer.pl, which does not show that for this patch: ~/src/linux$ scripts/get_maintainer.pl < /tmp/patch Greg Kroah-Hartman (supporter:DRIVER CORE, KOBJ...) linux-kernel@vger.kernel.org (open list) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] gpio: sch: Add support for Intel Quark X1000 SoC
Intel Quark X1000 provides a total of 16 GPIOs. The GPIOs are split between the legacy I/O bridge and the GPIO controller. GPIO-SCH is the GPIO pins on legacy bridge for Intel Quark SoC. Intel Quark X1000 has 2 GPIOs powered by the core power well and 6 from the suspend power well. This piece of work is derived from Dan O'Donovan's initial work for Quark X1000 enabling. Signed-off-by: Chang Rebecca Swee Fun --- drivers/gpio/Kconfig| 11 +-- drivers/gpio/gpio-sch.c |6 ++ 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 0959ca9..0e60f93 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -371,25 +371,32 @@ config GPIO_VR41XX Say yes here to support the NEC VR4100 series General-purpose I/O Uint config GPIO_SCH - tristate "Intel SCH/TunnelCreek/Centerton GPIO" + tristate "Intel SCH/TunnelCreek/Centerton/Quark X1000 GPIO" depends on PCI && X86 select MFD_CORE select LPC_SCH help Say yes here to support GPIO interface on Intel Poulsbo SCH, - Intel Tunnel Creek processor or Intel Centerton processor. + Intel Tunnel Creek processor, Intel Centerton processor or + Intel Quark X1000 SoC. + The Intel SCH contains a total of 14 GPIO pins. Ten GPIOs are powered by the core power rail and are turned off during sleep modes (S3 and higher). The remaining four GPIOs are powered by the Intel SCH suspend power supply. These GPIOs remain active during S3. The suspend powered GPIOs can be used to wake the system from the Suspend-to-RAM state. + The Intel Tunnel Creek processor has 5 GPIOs powered by the core power rail and 9 from suspend power supply. + The Intel Centerton processor has a total of 30 GPIO pins. Twenty-one are powered by the core power rail and 9 from the suspend power supply. + The Intel Quark X1000 SoC has 2 GPIOs powered by the core + power well and 6 from the suspend power well. + config GPIO_ICH tristate "Intel ICH GPIO" depends on PCI && X86 diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c index 6e89be9..952990f 100644 --- a/drivers/gpio/gpio-sch.c +++ b/drivers/gpio/gpio-sch.c @@ -241,6 +241,12 @@ static int sch_gpio_probe(struct platform_device *pdev) sch->chip.ngpio = 30; break; + case PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB: + sch->core_base = 0; + sch->resume_base = 2; + sch->chip.ngpio = 8; + break; + default: return -ENODEV; } -- 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/
[PATCHv3 3/3] gpio: sch: Enable IRQ support for Quark X1000
Intel Quark X1000 GPIO controller supports interrupt handling for
both core power well and resume power well. This patch is to enable
the IRQ support and provide IRQ handling for Intel Quark X1000
GPIO-SCH device driver.
This piece of work is derived from Dan O'Donovan's initial work for
Quark X1000 enabling.
Signed-off-by: Chang Rebecca Swee Fun
---
drivers/gpio/gpio-sch.c | 257 ---
1 file changed, 245 insertions(+), 12 deletions(-)
diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 952990f..dd84b1f 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -28,17 +28,30 @@
#include
#include
+#include
+#include
#define GEN0x00
#define GIO0x04
#define GLV0x08
+#define GTPE 0x0C
+#define GTNE 0x10
+#define GGPE 0x14
+#define GSMI 0x18
+#define GTS0x1C
+#define CGNMIEN0x40
+#define RGNMIEN0x44
struct sch_gpio {
struct gpio_chip chip;
+ struct irq_data data;
spinlock_t lock;
unsigned short iobase;
unsigned short core_base;
unsigned short resume_base;
+ int irq_base;
+ int irq_num;
+ bool irq_support;
};
#define to_sch_gpio(c) container_of(c, struct sch_gpio, chip)
@@ -66,10 +79,11 @@ static unsigned sch_gpio_bit(struct sch_gpio *sch, unsigned
gpio)
static void sch_gpio_register_set(struct sch_gpio *sch, unsigned gpio,
unsigned reg)
{
+ unsigned long flags;
unsigned short offset, bit;
u8 enable;
- spin_lock(&sch->lock);
+ spin_lock_irqsave(&sch->lock, flags);
offset = sch_gpio_offset(sch, gpio, reg);
bit = sch_gpio_bit(sch, gpio);
@@ -78,16 +92,17 @@ static void sch_gpio_register_set(struct sch_gpio *sch,
unsigned gpio,
if (!(enable & BIT(bit)))
outb(enable | BIT(bit), sch->iobase + offset);
- spin_unlock(&sch->lock);
+ spin_unlock_irqrestore(&sch->lock, flags);
}
static void sch_gpio_register_clear(struct sch_gpio *sch, unsigned gpio,
unsigned reg)
{
+ unsigned long flags;
unsigned short offset, bit;
u8 disable;
- spin_lock(&sch->lock);
+ spin_lock_irqsave(&sch->lock, flags);
offset = sch_gpio_offset(sch, gpio, reg);
bit = sch_gpio_bit(sch, gpio);
@@ -96,7 +111,7 @@ static void sch_gpio_register_clear(struct sch_gpio *sch,
unsigned gpio,
if (disable & BIT(bit))
outb(disable & ~BIT(bit), sch->iobase + offset);
- spin_unlock(&sch->lock);
+ spin_unlock_irqrestore(&sch->lock, flags);
}
static int sch_gpio_reg_get(struct gpio_chip *gc, unsigned gpio, unsigned reg)
@@ -134,10 +149,11 @@ static void sch_gpio_reg_set(struct gpio_chip *gc,
unsigned gpio, unsigned reg,
static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned gpio_num)
{
struct sch_gpio *sch = to_sch_gpio(gc);
+ unsigned long flags;
- spin_lock(&sch->lock);
+ spin_lock_irqsave(&sch->lock, flags);
sch_gpio_register_set(sch, gpio_num, GIO);
- spin_unlock(&sch->lock);
+ spin_unlock_irqrestore(&sch->lock, flags);
return 0;
}
@@ -149,20 +165,22 @@ static int sch_gpio_get(struct gpio_chip *gc, unsigned
gpio_num)
static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int val)
{
struct sch_gpio *sch = to_sch_gpio(gc);
+ unsigned long flags;
- spin_lock(&sch->lock);
+ spin_lock_irqsave(&sch->lock, flags);
sch_gpio_reg_set(gc, gpio_num, GLV, val);
- spin_unlock(&sch->lock);
+ spin_unlock_irqrestore(&sch->lock, flags);
}
static int sch_gpio_direction_out(struct gpio_chip *gc, unsigned gpio_num,
int val)
{
struct sch_gpio *sch = to_sch_gpio(gc);
+ unsigned long flags;
- spin_lock(&sch->lock);
+ spin_lock_irqsave(&sch->lock, flags);
sch_gpio_register_clear(sch, gpio_num, GIO);
- spin_unlock(&sch->lock);
+ spin_unlock_irqrestore(&sch->lock, flags);
/*
* according to the datasheet, writing to the level register has no
@@ -177,6 +195,13 @@ static int sch_gpio_direction_out(struct gpio_chip *gc,
unsigned gpio_num,
return 0;
}
+static int sch_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
+{
+ struct sch_gpio *sch = to_sch_gpio(gc);
+
+ return sch->irq_base + offset;
+}
+
static struct gpio_chip sch_gpio_chip = {
.label = "sch_gpio",
.owner = THIS_MODULE,
@@ -184,12 +209,160 @@ static struct gpio_chip sch_gpio_chip = {
.get= sch_gpio_get,
.direction_output = sch_gpio_direction_out,
.set= sch_gpio_set,
+ .to_irq = sch_gpio_to_irq,
};
+static void sch_gpio_irq_enable(struct irq_data *d)
+{
+ struct sc
[PATCHv3 1/3] gpio: sch: Consolidate similar algorithms
Consolidating similar algorithms into common functions to make
GPIO SCH simpler and manageable.
Signed-off-by: Chang Rebecca Swee Fun
---
drivers/gpio/gpio-sch.c | 95 ++-
1 file changed, 53 insertions(+), 42 deletions(-)
diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 99720c8..6e89be9 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -63,94 +63,105 @@ static unsigned sch_gpio_bit(struct sch_gpio *sch,
unsigned gpio)
return gpio % 8;
}
-static void sch_gpio_enable(struct sch_gpio *sch, unsigned gpio)
+static void sch_gpio_register_set(struct sch_gpio *sch, unsigned gpio,
+ unsigned reg)
{
unsigned short offset, bit;
u8 enable;
spin_lock(&sch->lock);
- offset = sch_gpio_offset(sch, gpio, GEN);
+ offset = sch_gpio_offset(sch, gpio, reg);
bit = sch_gpio_bit(sch, gpio);
enable = inb(sch->iobase + offset);
- if (!(enable & (1 << bit)))
- outb(enable | (1 << bit), sch->iobase + offset);
+ if (!(enable & BIT(bit)))
+ outb(enable | BIT(bit), sch->iobase + offset);
spin_unlock(&sch->lock);
}
-static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned gpio_num)
+static void sch_gpio_register_clear(struct sch_gpio *sch, unsigned gpio,
+ unsigned reg)
{
- struct sch_gpio *sch = to_sch_gpio(gc);
- u8 curr_dirs;
unsigned short offset, bit;
+ u8 disable;
spin_lock(&sch->lock);
- offset = sch_gpio_offset(sch, gpio_num, GIO);
- bit = sch_gpio_bit(sch, gpio_num);
-
- curr_dirs = inb(sch->iobase + offset);
+ offset = sch_gpio_offset(sch, gpio, reg);
+ bit = sch_gpio_bit(sch, gpio);
- if (!(curr_dirs & (1 << bit)))
- outb(curr_dirs | (1 << bit), sch->iobase + offset);
+ disable = inb(sch->iobase + offset);
+ if (disable & BIT(bit))
+ outb(disable & ~BIT(bit), sch->iobase + offset);
spin_unlock(&sch->lock);
- return 0;
}
-static int sch_gpio_get(struct gpio_chip *gc, unsigned gpio_num)
+static int sch_gpio_reg_get(struct gpio_chip *gc, unsigned gpio, unsigned reg)
{
struct sch_gpio *sch = to_sch_gpio(gc);
- int res;
unsigned short offset, bit;
+ u8 curr_dirs;
- offset = sch_gpio_offset(sch, gpio_num, GLV);
- bit = sch_gpio_bit(sch, gpio_num);
+ offset = sch_gpio_offset(sch, gpio, reg);
+ bit = sch_gpio_bit(sch, gpio);
- res = !!(inb(sch->iobase + offset) & (1 << bit));
+ curr_dirs = !!(inb(sch->iobase + offset) & BIT(bit));
- return res;
+ return curr_dirs;
}
-static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int val)
+static void sch_gpio_reg_set(struct gpio_chip *gc, unsigned gpio, unsigned reg,
+int val)
{
struct sch_gpio *sch = to_sch_gpio(gc);
- u8 curr_vals;
unsigned short offset, bit;
+ u8 curr_dirs;
- spin_lock(&sch->lock);
-
- offset = sch_gpio_offset(sch, gpio_num, GLV);
- bit = sch_gpio_bit(sch, gpio_num);
+ offset = sch_gpio_offset(sch, gpio, reg);
+ bit = sch_gpio_bit(sch, gpio);
- curr_vals = inb(sch->iobase + offset);
+ curr_dirs = inb(sch->iobase + offset);
if (val)
- outb(curr_vals | (1 << bit), sch->iobase + offset);
+ outb(curr_dirs | BIT(bit), sch->iobase + offset);
else
- outb((curr_vals & ~(1 << bit)), sch->iobase + offset);
+ outb((curr_dirs & ~BIT(bit)), sch->iobase + offset);
+}
+static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned gpio_num)
+{
+ struct sch_gpio *sch = to_sch_gpio(gc);
+
+ spin_lock(&sch->lock);
+ sch_gpio_register_set(sch, gpio_num, GIO);
spin_unlock(&sch->lock);
+ return 0;
}
-static int sch_gpio_direction_out(struct gpio_chip *gc, unsigned gpio_num,
- int val)
+static int sch_gpio_get(struct gpio_chip *gc, unsigned gpio_num)
+{
+ return sch_gpio_reg_get(gc, gpio_num, GLV);
+}
+
+static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int val)
{
struct sch_gpio *sch = to_sch_gpio(gc);
- u8 curr_dirs;
- unsigned short offset, bit;
spin_lock(&sch->lock);
+ sch_gpio_reg_set(gc, gpio_num, GLV, val);
+ spin_unlock(&sch->lock);
+}
- offset = sch_gpio_offset(sch, gpio_num, GIO);
- bit = sch_gpio_bit(sch, gpio_num);
-
- curr_dirs = inb(sch->iobase + offset);
- if (curr_dirs & (1 << bit))
- outb(curr_dirs & ~(1 << bit), sch->iobase + offset);
+static int sch_gpio_direction_out(struct gpio_chip *gc, unsigned gpio_num,
+ int val)
+{
+ struct sch_gpio *sch = to_sch_gpio(gc);
+ spin_lock
Re: PCIe PASID (Process Address Space ID) and iommu code
[+cc Joerg, Suravee, Jay, iommu list, linux-pci] On Wed, Oct 15, 2014 at 5:44 PM, Kallol Biswas wrote: > Resending, as message got bounced for html content. > > Hi, > PCIe has introduced PASID TLP Prefix. There are two ECNs on this. > > It seems that AMD iommu code makes use of PASID. Is there a device that > utilizes this TLP prefix? > > PASID allocation and management within a device is not clear to me. How > does device know which PASID to issue for which virtual address? Who makes > the association? Must be software/OS, but how? There is no table for this > like MSI-X table. > > Any pointer/documentation will be appreciated. > > Regards, > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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 1/4] ARM: rockchip: add suspend and resume for RK3288
Chris,
On Wed, Oct 15, 2014 at 1:47 PM, wrote:
> +static const struct platform_suspend_ops rk3288_suspend_ops = {
> + .enter = rk3288_suspend_enter,
> + .valid = suspend_valid_only_mem,
> +};
As per offline discussion, let's add the regulator calls in prepare / finish.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] ARM: dts: add RK3288 suspend support
Chris, On Wed, Oct 15, 2014 at 1:49 PM, wrote: > From: Chris Zhong > > add pmu_intmem subnode for suspend, add suspend pinctrl Maybe mention that it's expected that board files will reference the suspend pinctrl as part of the PMIC config? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] ARM: rockchip: add pmu-sram sub
Chris, On Wed, Oct 15, 2014 at 1:50 PM, wrote: > From: Chris Zhong > > The pmu-sram is used to store resume code, suspend/resume need get the > address of it. Therefore add a node and documentation for it. This patch just adds bindings, not a node. > > Signed-off-by: Tony Xie > Signed-off-by: Chris Zhong > > --- > > .../devicetree/bindings/arm/rockchip/pmu-sram.txt | 15 +++ > 1 file changed, 15 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt Title of this patch should probably mention bindings somewhere. Also bindings should be patch #3 and the adding to the DTS patch #4. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation
In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of MIGRATE_MOVABLE. MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in order that Linux kernel want. If a system that has a lot of user space program is running, for instance, an Android board, most of memory is in MIGRATE_MOVABLE and allocated. Before function __rmqueue_fallback get memory from MIGRATE_CMA, the oom_killer will kill a task to release memory when kernel want get MIGRATE_UNMOVABLE memory because fallbacks of MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. This status is odd. The MIGRATE_CMA has a lot free memory but Linux kernel kill some tasks to release memory. This patch series adds a new function CMA_AGGRESSIVE to make CMA memory be more aggressive about allocation. If function CMA_AGGRESSIVE is available, when Linux kernel call function __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA doesn't have enough pages for allocation, go back to allocate memory from MIGRATE_MOVABLE. Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory
Function shrink_all_memory try to free `nr_to_reclaim' of memory.
CMA_AGGRESSIVE_SHRINK function will call this functon to free `nr_to_reclaim' of
memory. It need different scan_control with current caller function
hibernate_preallocate_memory.
If hibernation is true, the caller is hibernate_preallocate_memory.
if not, the caller is CMA alloc function.
Signed-off-by: Hui Zhu
---
include/linux/swap.h| 3 ++-
kernel/power/snapshot.c | 2 +-
mm/vmscan.c | 19 +--
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 37a585b..9f2cb43 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -335,7 +335,8 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct
mem_cgroup *mem,
gfp_t gfp_mask, bool noswap,
struct zone *zone,
unsigned long *nr_scanned);
-extern unsigned long shrink_all_memory(unsigned long nr_pages);
+extern unsigned long shrink_all_memory(unsigned long nr_pages,
+ bool hibernation);
extern int vm_swappiness;
extern int remove_mapping(struct address_space *mapping, struct page *page);
extern unsigned long vm_total_pages;
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 791a618..a00fc35 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1657,7 +1657,7 @@ int hibernate_preallocate_memory(void)
* NOTE: If this is not done, performance will be hurt badly in some
* test cases.
*/
- shrink_all_memory(saveable - size);
+ shrink_all_memory(saveable - size, true);
/*
* The number of saveable pages in memory was too high, so apply some
diff --git a/mm/vmscan.c b/mm/vmscan.c
index dcb4707..fdcfa30 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3404,7 +3404,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum
zone_type classzone_idx)
wake_up_interruptible(&pgdat->kswapd_wait);
}
-#ifdef CONFIG_HIBERNATION
+#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE
/*
* Try to free `nr_to_reclaim' of memory, system-wide, and return the number of
* freed pages.
@@ -3413,22 +3413,29 @@ void wakeup_kswapd(struct zone *zone, int order, enum
zone_type classzone_idx)
* LRU order by reclaiming preferentially
* inactive > active > active referenced > active mapped
*/
-unsigned long shrink_all_memory(unsigned long nr_to_reclaim)
+unsigned long shrink_all_memory(unsigned long nr_to_reclaim, bool hibernation)
{
struct reclaim_state reclaim_state;
struct scan_control sc = {
.nr_to_reclaim = nr_to_reclaim,
- .gfp_mask = GFP_HIGHUSER_MOVABLE,
.priority = DEF_PRIORITY,
- .may_writepage = 1,
.may_unmap = 1,
.may_swap = 1,
- .hibernation_mode = 1,
};
struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask);
struct task_struct *p = current;
unsigned long nr_reclaimed;
+ if (hibernation) {
+ sc.hibernation_mode = 1;
+ sc.may_writepage = 1;
+ sc.gfp_mask = GFP_HIGHUSER_MOVABLE;
+ } else {
+ sc.hibernation_mode = 0;
+ sc.may_writepage = !laptop_mode;
+ sc.gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM;
+ }
+
p->flags |= PF_MEMALLOC;
lockdep_set_current_reclaim_state(sc.gfp_mask);
reclaim_state.reclaimed_slab = 0;
@@ -3442,7 +3449,7 @@ unsigned long shrink_all_memory(unsigned long
nr_to_reclaim)
return nr_reclaimed;
}
-#endif /* CONFIG_HIBERNATION */
+#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */
/* It's optimal to keep kswapds on the same CPUs as their memory, but
not required for correctness. So if the last cpu in a node goes
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function
If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and
conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter)
allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first.
Signed-off-by: Hui Zhu
---
mm/page_alloc.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 736d8e1..87bc326 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -65,6 +65,10 @@
#include
#include "internal.h"
+#ifdef CONFIG_CMA_AGGRESSIVE
+#include
+#endif
+
/* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */
static DEFINE_MUTEX(pcp_batch_high_lock);
#define MIN_PERCPU_PAGELIST_FRACTION (8)
@@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone,
unsigned int order,
{
struct page *page;
-retry_reserve:
+#ifdef CONFIG_CMA_AGGRESSIVE
+ if (cma_aggressive_switch
+ && migratetype == MIGRATE_MOVABLE
+ && atomic_read(&cma_alloc_counter) == 0
+ && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min
+ + (1 << order))
+ migratetype = MIGRATE_CMA;
+#endif
+retry:
page = __rmqueue_smallest(zone, order, migratetype);
- if (unlikely(!page) && migratetype != MIGRATE_RESERVE) {
- page = __rmqueue_fallback(zone, order, migratetype);
+ if (unlikely(!page)) {
+#ifdef CONFIG_CMA_AGGRESSIVE
+ if (migratetype == MIGRATE_CMA) {
+ migratetype = MIGRATE_MOVABLE;
+ goto retry;
+ }
+#endif
+ if (migratetype != MIGRATE_RESERVE) {
+ page = __rmqueue_fallback(zone, order, migratetype);
- /*
-* Use MIGRATE_RESERVE rather than fail an allocation. goto
-* is used because __rmqueue_smallest is an inline function
-* and we want just one call site
-*/
- if (!page) {
- migratetype = MIGRATE_RESERVE;
- goto retry_reserve;
+ /*
+ * Use MIGRATE_RESERVE rather than fail an allocation.
+ * goto is used because __rmqueue_smallest is an inline
+ * function and we want just one call site
+ */
+ if (!page) {
+ migratetype = MIGRATE_RESERVE;
+ goto retry;
+ }
}
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] (CMA_AGGRESSIVE) Update reserve custom contiguous area code
Add cma_alloc_counter, cma_aggressive_switch, cma_aggressive_free_min and
cma_aggressive_shrink_switch.
cma_aggressive_switch is the swith for all CMA_AGGRESSIVE function. It can be
controlled by sysctl vm.cma-aggressive-switch.
cma_aggressive_free_min can be controlled by sysctl
"vm.cma-aggressive-free-min". If the number of CMA free pages is small than
this sysctl value, CMA_AGGRESSIVE will not work in page alloc code.
cma_aggressive_shrink_switch can be controlled by sysctl
"vm.cma-aggressive-shrink-switch". If sysctl "vm.cma-aggressive-shrink-switch"
is true and free normal memory's size is smaller than the size that it want to
allocate, do memory shrink with function shrink_all_memory before driver
allocate pages from CMA.
When Linux kernel try to reserve custom contiguous area, increase the value of
cma_alloc_counter. CMA_AGGRESSIVE will not work in page alloc code.
After reserve custom contiguous area function return, decreases the value of
cma_alloc_counter.
Signed-off-by: Hui Zhu
---
include/linux/cma.h | 7 +++
kernel/sysctl.c | 27 +++
mm/cma.c| 54 +
3 files changed, 88 insertions(+)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 0430ed0..df96abf 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -15,6 +15,13 @@
struct cma;
+#ifdef CONFIG_CMA_AGGRESSIVE
+extern atomic_t cma_alloc_counter;
+extern int cma_aggressive_switch;
+extern unsigned long cma_aggressive_free_min;
+extern int cma_aggressive_shrink_switch;
+#endif
+
extern phys_addr_t cma_get_base(struct cma *cma);
extern unsigned long cma_get_size(struct cma *cma);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 4aada6d..646929e2 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -92,6 +92,10 @@
#include
#endif
+#ifdef CONFIG_CMA_AGGRESSIVE
+#include
+#endif
+
#if defined(CONFIG_SYSCTL)
@@ -1485,6 +1489,29 @@ static struct ctl_table vm_table[] = {
.mode = 0644,
.proc_handler = proc_doulongvec_minmax,
},
+#ifdef CONFIG_CMA_AGGRESSIVE
+ {
+ .procname = "cma-aggressive-switch",
+ .data = &cma_aggressive_switch,
+ .maxlen = sizeof(int),
+ .mode = 0600,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "cma-aggressive-free-min",
+ .data = &cma_aggressive_free_min,
+ .maxlen = sizeof(unsigned long),
+ .mode = 0600,
+ .proc_handler = proc_doulongvec_minmax,
+ },
+ {
+ .procname = "cma-aggressive-shrink-switch",
+ .data = &cma_aggressive_shrink_switch,
+ .maxlen = sizeof(int),
+ .mode = 0600,
+ .proc_handler = proc_dointvec,
+ },
+#endif
{ }
};
diff --git a/mm/cma.c b/mm/cma.c
index 963bc4a..566ed5f 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
struct cma {
unsigned long base_pfn;
@@ -127,6 +128,27 @@ err:
return -EINVAL;
}
+#ifdef CONFIG_CMA_AGGRESSIVE
+/* The counter for the dma_alloc_from_contiguous and
+ dma_release_from_contiguous. */
+atomic_t cma_alloc_counter = ATOMIC_INIT(0);
+
+/* Swich of CMA_AGGRESSIVE. */
+int cma_aggressive_switch __read_mostly;
+
+/* If the number of CMA free pages is small than this value, CMA_AGGRESSIVE
will
+ not work. */
+#ifdef CONFIG_CMA_AGGRESSIVE_FREE_MIN
+unsigned long cma_aggressive_free_min __read_mostly =
+ CONFIG_CMA_AGGRESSIVE_FREE_MIN;
+#else
+unsigned long cma_aggressive_free_min __read_mostly = 500;
+#endif
+
+/* Swich of CMA_AGGRESSIVE shink. */
+int cma_aggressive_shrink_switch __read_mostly;
+#endif
+
static int __init cma_init_reserved_areas(void)
{
int i;
@@ -138,6 +160,22 @@ static int __init cma_init_reserved_areas(void)
return ret;
}
+#ifdef CONFIG_CMA_AGGRESSIVE
+ cma_aggressive_switch = 0;
+#ifdef CONFIG_CMA_AGGRESSIVE_PHY_MAX
+ if (memblock_phys_mem_size() <= CONFIG_CMA_AGGRESSIVE_PHY_MAX)
+#else
+ if (memblock_phys_mem_size() <= 0x4000)
+#endif
+ cma_aggressive_switch = 1;
+
+ cma_aggressive_shrink_switch = 0;
+#ifdef CONFIG_CMA_AGGRESSIVE_SHRINK
+ if (cma_aggressive_switch)
+ cma_aggressive_shrink_switch = 1;
+#endif
+#endif
+
return 0;
}
core_initcall(cma_init_reserved_areas);
@@ -312,6 +350,11 @@ struct page *cma_alloc(struct cma *cma, int count,
unsigned int align)
unsigned long bitmap_maxno, bitmap_no, bitmap_count;
struct page *page = NULL;
int ret;
+#ifdef CONFIG_CMA_AGGRESSIVE
+ int free = global_page_state(NR_FREE_PAGES)
+
[PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig
Add CMA_AGGRESSIVE config that depend on CMA to Linux kernel config. Add CMA_AGGRESSIVE_PHY_MAX, CMA_AGGRESSIVE_FREE_MIN and CMA_AGGRESSIVE_SHRINK that depend on CMA_AGGRESSIVE. If physical memory size (not include CMA memory) in byte less than or equal to CMA_AGGRESSIVE_PHY_MAX, CMA aggressive switch (sysctl vm.cma-aggressive-switch) will be opened. When system boot, this value will set to sysctl "vm.cma-aggressive-free-min". If this value is true, sysctl "vm.cma-aggressive-shrink-switch" will be set to true when Linux boot. Signed-off-by: Hui Zhu --- mm/Kconfig | 43 +++ 1 file changed, 43 insertions(+) diff --git a/mm/Kconfig b/mm/Kconfig index 1d1ae6b..940f5f3 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -527,6 +527,49 @@ config CMA_AREAS If unsure, leave the default value "7". +config CMA_AGGRESSIVE + bool "CMA aggressive" + depends on CMA + default n + help + Be more aggressive about taking memory from CMA when allocate MOVABLE + page. + Sysctl "vm.cma-aggressive-switch", "vm.cma-aggressive-alloc-max" + and "vm.cma-aggressive-shrink-switch" can control this function. + If unsure, say "n". + +config CMA_AGGRESSIVE_PHY_MAX + hex "Physical memory size in Bytes that auto turn on the CMA aggressive switch" + depends on CMA_AGGRESSIVE + default 0x4000 + help + If physical memory size (not include CMA memory) in byte less than or + equal to this value, CMA aggressive switch will be opened. + After the Linux boot, sysctl "vm.cma-aggressive-switch" can control + the CMA AGGRESSIVE switch. + +config CMA_AGGRESSIVE_FREE_MIN + int "The minimum free CMA page number that CMA aggressive work" + depends on CMA_AGGRESSIVE + default 500 + help + When system boot, this value will set to sysctl + "vm.cma-aggressive-free-min". + If the number of CMA free pages is small than this sysctl value, + CMA aggressive will not work. + +config CMA_AGGRESSIVE_SHRINK + bool "CMA aggressive shrink" + depends on CMA_AGGRESSIVE + default y + help + If this value is true, sysctl "vm.cma-aggressive-shrink-switch" will + be set to true when Linux boot. + If sysctl "vm.cma-aggressive-shrink-switch" is true and free normal + memory's size is smaller than the size that it want to allocate, + do memory shrink before driver allocate pages from CMA. + If unsure, say "y". + config MEM_SOFT_DIRTY bool "Track memory changes" depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS -- 1.9.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 2/4] clk: rockchip: RK3288: add suspend and resume
Chris,
On Wed, Oct 15, 2014 at 1:48 PM, wrote:
> From: Chris Zhong
>
> save and restore some clks, which might be changed in suspend.
>
> Signed-off-by: Tony Xie
> Signed-off-by: Chris Zhong
> ---
>
> drivers/clk/rockchip/clk-rk3288.c | 61
> +
> 1 file changed, 61 insertions(+)
Put this as patch set #1? It's safe to do this first and the other
patch won't work without it (right?)
> +static int rk3288_clk_suspend(void)
> +{
> + int i, reg_id;
> +
> + for (i = 0; i < ARRAY_SIZE(rk3288_saved_cru_reg_ids); i++) {
> + reg_id = rk3288_saved_cru_reg_ids[i];
> +
> + rk3288_saved_cru_regs[i] =
> + __raw_readl(rk3288_cru_base + reg_id);
As talked about off-list, should probably not be the __raw version
here and elsewhere in this file.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 net-next] openvswitch: kerneldoc warning fix
From: Fabian Frederick Date: Wed, 15 Oct 2014 21:03:18 +0200 > s/sock/gs > > Signed-off-by: Fabian Frederick Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 net-next] openvswitch: use vport instead of p
From: Fabian Frederick Date: Wed, 15 Oct 2014 21:03:41 +0200 > All functions used struct vport *vport except > ovs_vport_find_upcall_portid. > > This fixes 1 kerneldoc warning > > Signed-off-by: Fabian Frederick Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change
Commit 0b0b0893d49b "of/pci: Fix the conversion of IO ranges into IO
resources" changed the behaviour of of_pci_range_to_resource().
Previously it simply populated the resource based on the arguments. Now
it calls pci_register_io_range() and pci_address_to_pio(). These both
have two implementations depending on whether PCI_IOBASE is defined,
which it is not for powerpc.
Further complicating matters, both routines are weak, and powerpc
implements it's own version of one - pci_address_to_pio(). However
powerpc's implementation depends on other initialisations which are done
later in boot.
The end result is incorrectly initialised IO space. Often we can get
away with that, because we don't make much use of IO space. However
virtio requires it, so we see eg:
pci_bus :00: root bus resource [io 0x] (bus address
[0x-0x])
PCI: Cannot allocate resource region 0 of device :00:01.0, will remap
virtio-pci :00:01.0: can't enable device: BAR 0 [io size 0x0020] not
assigned
The simplest fix for now is to just stop using of_pci_range_to_resource(),
and open-code the original implementation, that's all we want it to do.
Fixes: 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO
resources")
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/pci-common.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index bd70a51d5747..e5dad9a9edc0 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -747,7 +747,11 @@ void pci_process_bridge_OF_ranges(struct pci_controller
*hose,
break;
}
if (res != NULL) {
- of_pci_range_to_resource(&range, dev, res);
+ res->name = dev->full_name;
+ res->flags = range.flags;
+ res->start = range.cpu_addr;
+ res->end = range.cpu_addr + range.size - 1;
+ res->parent = res->child = res->sibling = NULL;
}
}
}
--
1.9.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] perf tools: fix incorrect header string
On 2014/10/15 23:13, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 15, 2014 at 11:28:53AM +0800, Wang Nan escreveu: >> Commit fbe96f29 (perf tools: Make perf.data more self-descriptive) >> read '/proc/cpuinfo' to form cpu descriptor. For ARM, it finds >> 'Processor' field. It is correct when the patch merged, but due to >> commit b4b8f770 (ARM: kernel: update cpuinfo to print all online CPUs >> features), the corresponding information becomes 'model name' field. >> >> This patch simply corrects it. > > It doesn't :-) > > It makes it work with kernels >= b4b8f770, and fail with older kernels. > > We need to somehow figure out where the right information is regardless > of the kernel. > > - Arnaldo > However it is a real problem. Look at output on arm platform at the bottom of this mail, especially "cpudesc", "total memory" and "cmdline" field. By further debugging I found that the real problem resides in return value checking when write header error. Please see my other patches: https://lkml.org/lkml/2014/10/15/612 https://lkml.org/lkml/2014/10/15/611 I think at least one of them is required. Thanks. >> Signed-off-by: Wang Nan >> --- >> tools/perf/perf-sys.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h >> index 937e432..4293970 100644 >> --- a/tools/perf/perf-sys.h >> +++ b/tools/perf/perf-sys.h >> @@ -113,7 +113,7 @@ >> #define mb()((void(*)(void))0x0fa0)() >> #define wmb() ((void(*)(void))0x0fa0)() >> #define rmb() ((void(*)(void))0x0fa0)() >> -#define CPUINFO_PROC"Processor" >> +#define CPUINFO_PROC"model name" >> #endif >> >> #ifdef __aarch64__ >> -- >> 1.8.4 bash-4.2# perf record ls ... [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.001 MB perf.data (~36 samples) ] bash-4.2# perf report --stdio --header Error: The perf.data file has no samples! # # captured on: Fri Sep 12 10:09:10 2014 # hostname : arma15el # os release : 3.17.0+ # perf version : 3.10.53 # arch : armv7l # nrcpus online : 4 # nrcpus avail : 1 # cpudesc : (null) # total memory : 0 kB # cmdline : # event : name = cycles, type = 0, config = 0x0, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, excl_host = 0, excl_guest = 1, precise_ip = 0 # pmu mappings: not available # # -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: unaligned accesses in SLAB etc.
From: Meelis Roos Date: Wed, 15 Oct 2014 23:11:34 +0300 (EEST) >> >> The gcc-4.9 case is interesting, are you saying that a gcc-4.9 compiled >> >> kernel works fine on other systems? >> > >> > Yes, all USII based systems work fine with Debian gcc-4.9, as does >> > T2000. Of USIII* systems, V210 and V440 exhibit the boot hang with >> > gcc-4.9 and V480 crashes wit FATAL exception during boot that is >> > probably earlier than the gcc boot hang so I do not know about V480 and >> > gcc-4.9. V240 not tested because of fan failures, V245 is in the queue >> > for setup but not tested so far. >> >> Ok, on the V210/V440 can you boot with "-p" on the kernel boot command >> line and post the log? Let's start by seeing how far it gets, maybe >> we can figure out roughly where it dies. > > http://www.spinics.net/lists/sparclinux/msg12238.html and > http://www.spinics.net/lists/sparclinux/msg12468.html are my relevant > posts about it. Should I get something more? It would be easy because of > ALOM. Less information than I had hoped :-/ I thought it was hanging "during boot" meaning before we try to execute userspace. When in fact it seems to die exactly when we start running the init process. Wrt. disassembly of fault_in_user_windows(), that's not likely the cause because if it were being miscompiled it would equally not work on the other systems. Something in the UltraSPARC-III specific code paths is going wrong (either it is miscompiled, or the code makes an assumption that isn't valid which has happened in the past). Do you happen to have both gcc-4.9 and a previously working compiler on these systems? If you do, we can build a kernel with gcc-4.9 and then selectively compile certain failes with the older working compiler to narrow down what compiles into something non-working with gcc-4.9 I would start with the following files: arch/sparc/mm/init_64.c arch/sparc/mm/tlb.c arch/sparc/mm/tsb.c arch/sparc/mm/fault_64.c And failing that, go for various files under arch/sparc/kernel/ such as: arch/sparc/kernel/process_64.c arch/sparc/kernel/smp_64.c arch/sparc/kernel/sys_sparc_64.c arch/sparc/kernel/sys_sparc32.c arch/sparc/kernel/traps_64.c Hopefully, this should be a simply matter of doing a complete build with gcc-4.9, then removing the object file we want to selectively build with the older compiler and then going: make CC="gcc-4.6" arch/sparc/mm/init_64.o then relinking with plain 'make'. If the build system rebuilds the object file on you when you try to relink the final kernel image, we'll have to do some of this by hand to make the test. 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/
[PATCH] perf tools: ensure return negitive value when write header error
When 'perf record' write headers, it calls write_xxx in
tools/perf/util/header.c, and check return value. It rolls back all
working only when return value is negative.
This patch ensures write_cpudesc() and write_total_mem() return negative number
when error. Without this patch, headers reported by 'perf report' header is
error in some platform. Following output is caputured on ARM, which doesn't
contain "Processor" field in /proc/cpuinfo. See "cpudesc", "total memory" and
"cmdline" field.
bash-4.2# perf record ls
...
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.001 MB perf.data (~36 samples) ]
bash-4.2# perf report --stdio --header
Error:
The perf.data file has no samples!
#
# captured on: Fri Sep 12 10:09:10 2014
# hostname : arma15el
# os release : 3.17.0+
# perf version : 3.10.53
# arch : armv7l
# nrcpus online : 4
# nrcpus avail : 1
# cpudesc : (null)
# total memory : 0 kB
# cmdline :
# event : name = cycles, type = 0, config = 0x0, config1 = 0x0, config2 =
0x0, excl_usr = 0, excl_kern = 0, excl_host = 0, excl_guest = 1, precise_ip = 0
# pmu mappings: not available
#
#
Signed-off-by: Wang Nan
---
tools/perf/util/header.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index ce0de00..39b80ac 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -605,8 +605,10 @@ static int write_cpudesc(int fd, struct perf_header *h
__maybe_unused,
break;
}
- if (ret)
+ if (ret) {
+ ret = -1;
goto done;
+ }
s = buf;
@@ -950,7 +952,8 @@ static int write_total_mem(int fd, struct perf_header *h
__maybe_unused,
n = sscanf(buf, "%*s %"PRIu64, &mem);
if (n == 1)
ret = do_write(fd, &mem, sizeof(mem));
- }
+ } else
+ ret = -1;
free(buf);
fclose(fp);
return ret;
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: makes CPUINFO_PROC to array for different kernel version
After kerne 3.7 (commit b4b8f770eb10a1bccaf8aa0ec1956e2dd7ed1e0a),
/proc/cpuinfo replcae 'Processor' to 'model name'. This patch makes
CPUINFO_PROC to an array and provides two choices for ARM, make it
compatible for different kernel version.
Signed-off-by: Wang Nan
---
tools/perf/perf-sys.h| 30 +++---
tools/perf/util/header.c | 26 --
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h
index 937e432..a3b13d7 100644
--- a/tools/perf/perf-sys.h
+++ b/tools/perf/perf-sys.h
@@ -13,7 +13,7 @@
#define wmb() asm volatile("lock; addl $0,0(%%esp)" ::: "memory")
#define rmb() asm volatile("lock; addl $0,0(%%esp)" ::: "memory")
#define cpu_relax()asm volatile("rep; nop" ::: "memory");
-#define CPUINFO_PROC "model name"
+#define CPUINFO_PROC {"model name"}
#ifndef __NR_perf_event_open
# define __NR_perf_event_open 336
#endif
@@ -30,7 +30,7 @@
#define wmb() asm volatile("sfence" ::: "memory")
#define rmb() asm volatile("lfence" ::: "memory")
#define cpu_relax()asm volatile("rep; nop" ::: "memory");
-#define CPUINFO_PROC "model name"
+#define CPUINFO_PROC {"model name"}
#ifndef __NR_perf_event_open
# define __NR_perf_event_open 298
#endif
@@ -47,14 +47,14 @@
#define mb() asm volatile ("sync" ::: "memory")
#define wmb() asm volatile ("sync" ::: "memory")
#define rmb() asm volatile ("sync" ::: "memory")
-#define CPUINFO_PROC "cpu"
+#define CPUINFO_PROC {"cpu"}
#endif
#ifdef __s390__
#define mb() asm volatile("bcr 15,0" ::: "memory")
#define wmb() asm volatile("bcr 15,0" ::: "memory")
#define rmb() asm volatile("bcr 15,0" ::: "memory")
-#define CPUINFO_PROC "vendor_id"
+#define CPUINFO_PROC {"vendor_id"}
#endif
#ifdef __sh__
@@ -67,14 +67,14 @@
# define wmb() asm volatile("" ::: "memory")
# define rmb() asm volatile("" ::: "memory")
#endif
-#define CPUINFO_PROC "cpu type"
+#define CPUINFO_PROC {"cpu type"}
#endif
#ifdef __hppa__
#define mb() asm volatile("" ::: "memory")
#define wmb() asm volatile("" ::: "memory")
#define rmb() asm volatile("" ::: "memory")
-#define CPUINFO_PROC "cpu"
+#define CPUINFO_PROC {"cpu"}
#endif
#ifdef __sparc__
@@ -87,14 +87,14 @@
#endif
#define wmb() asm volatile("":::"memory")
#define rmb() asm volatile("":::"memory")
-#define CPUINFO_PROC "cpu"
+#define CPUINFO_PROC {"cpu"}
#endif
#ifdef __alpha__
#define mb() asm volatile("mb" ::: "memory")
#define wmb() asm volatile("wmb" ::: "memory")
#define rmb() asm volatile("mb" ::: "memory")
-#define CPUINFO_PROC "cpu model"
+#define CPUINFO_PROC {"cpu model"}
#endif
#ifdef __ia64__
@@ -102,7 +102,7 @@
#define wmb() asm volatile ("mf" ::: "memory")
#define rmb() asm volatile ("mf" ::: "memory")
#define cpu_relax()asm volatile ("hint @pause" ::: "memory")
-#define CPUINFO_PROC "model name"
+#define CPUINFO_PROC {"model name"}
#endif
#ifdef __arm__
@@ -113,7 +113,7 @@
#define mb() ((void(*)(void))0x0fa0)()
#define wmb() ((void(*)(void))0x0fa0)()
#define rmb() ((void(*)(void))0x0fa0)()
-#define CPUINFO_PROC "Processor"
+#define CPUINFO_PROC {"model name", "Processor"}
#endif
#ifdef __aarch64__
@@ -133,28 +133,28 @@
: "memory")
#define wmb() mb()
#define rmb() mb()
-#define CPUINFO_PROC "cpu model"
+#define CPUINFO_PROC {"cpu model"}
#endif
#ifdef __arc__
#define mb() asm volatile("" ::: "memory")
#define wmb() asm volatile("" ::: "memory")
#define rmb() asm volatile("" ::: "memory")
-#define CPUINFO_PROC "Processor"
+#define CPUINFO_PROC {"Processor"}
#endif
#ifdef __metag__
#define mb() asm volatile("" ::: "memory")
#define wmb() asm volatile("" ::: "memory")
#define rmb() asm volatile("" ::: "memory")
-#define CPUINFO_PROC "CPU"
+#define CPUINFO_PROC {"CPU"}
#endif
#ifdef __xtensa__
#define mb() asm volatile("memw" ::: "memory")
#define wmb() asm volatile("memw" ::: "memory")
#define rmb() asm volatile("" ::: "memory")
-#define CPUINFO_PROC "core ID"
+#define CPUINFO_PROC {"core ID"}
#endif
#ifdef __tile__
@@ -162,7 +162,7 @@
#define wmb() asm volatile ("mf" ::: "memory")
#define rmb() asm volatile ("mf" ::: "memory")
#define cpu_relax()asm volatile ("mfspr zero, PASS" ::: "memory")
-#define CPUINFO_PROC"model name"
+#define CPUINFO_PROC{"model name"}
#endif
#define barrier() asm volatile ("" ::: "memory")
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 39b80ac..e23cd45 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -579,16 +579,13 @@ static int
Re: [Patch v2] x86: Make Atom PMC driver configurable.
On Thu, Oct 16, 2014 at 11:00:35AM +0800, Li, Aubrey wrote: > On 2014/10/16 10:18, Dave Jones wrote: > > The Atom PMC driver is always built-in, regardless of whether > > the kernel being built is going to be run on an Atom (or even Intel) CPU. > > > > Signed-off-by: Dave Jones > > Cc: One Thousand Gnomes > > Cc: aubrey...@linux.intel.com > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index f2327e88e07c..b4dfd96aeea8 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP > >depends on STA2X11 > > > > config PMC_ATOM > > - def_bool y > > + tristate "Intel Atom SOC power management controller driver" > > PMC driver provides core function like reboot, better to change to > bool, or did you see a scenario it can be as a module? All the MODULE_* stuff in arch/x86/kernel/pmc_atom.c threw me off. It could also use a help text. I suspect you might be in a better position than me to write one though. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] x86: Make Atom PMC driver configurable.
On 2014/10/16 10:18, Dave Jones wrote: > The Atom PMC driver is always built-in, regardless of whether > the kernel being built is going to be run on an Atom (or even Intel) CPU. > > Signed-off-by: Dave Jones > Cc: One Thousand Gnomes > Cc: aubrey...@linux.intel.com > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index f2327e88e07c..b4dfd96aeea8 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP > depends on STA2X11 > > config PMC_ATOM > - def_bool y > + tristate "Intel Atom SOC power management controller driver" PMC driver provides core function like reboot, better to change to bool, or did you see a scenario it can be as a module? Thanks, -Aubrey > + default y > depends on PCI > > source "net/Kconfig" > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: of/pci: Fix the conversion of IO ranges into IO resources
On Wed, 2014-10-15 at 10:02 +0100, Liviu Dudau wrote: > On Wed, Oct 15, 2014 at 08:35:07AM +0100, Benjamin Herrenschmidt wrote: > > On Thu, 2014-10-09 at 20:02 +, Linux Kernel Mailing List wrote: > > > Gitweb: > > > http://git.kernel.org/linus/;a=commit;h=0b0b0893d49b34201a6c4416b1a707b580b91e3d > > > Commit: 0b0b0893d49b34201a6c4416b1a707b580b91e3d > > > Author: Liviu Dudau > > > Committer: Bjorn Helgaas > > > > > > of/pci: Fix the conversion of IO ranges into IO resources > > > > > > The ranges property for a host bridge controller in DT describes the > > > mapping between the PCI bus address and the CPU physical address. The > > > resources framework however expects that the IO resources start at a > > > pseudo > > > "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT. > > > The > > > conversion from PCI ranges to resources failed to take that into > > > account, > > > returning a CPU physical address instead of a port number. > > > > > > Also fix all the drivers that depend on the old behaviour by fetching > > > the > > > CPU physical address based on the port number where it is being > > > needed. > > > > Michael just signaled me that this completely breaks IO space on powerpc ... > > Hi Benjamin, > > I'm sorry to hear that I've broke powerpc before I've had a chance to actually > change the code there. I would like to get the details of what functionality > get broken. You changed code that arch/powerpc depends on, without updating it, or even CC'ing us on the patches. I'm not sure what you mean by "before I've had a chance to actually change the code there" - it's too late. > The pci_register_io_range() function (the "allocator" for IO space) is a > weak function. It takes the CPU physical address of the range and its size > and makes sure that it can fit that area in the arch's space for PCI IO. > The main purpose of that function is to be a helper to pci_address_to_pio() > in order to help return the correct answer in that function. > pci_address_to_pio() > is also weak and can be overwritten. Yes, we already provide our own version of pci_address_to_pio(). The problem is it's too early to call it when we come in from find_and_init_phbs() -> pci_process_bridge_OF_ranges(), so it returns junk. I think you were expecting us to hit the #ifndef PCI_IOBASE case, which looks like it might have worked. For now we're just going to stop using of_pci_range_to_resource(). cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers: staging: imx-drm Fix checkpatch warning
Fix line over 80 characters in imx-tve.c
Signed-off-by: Gaston Gonzalez
---
drivers/staging/imx-drm/imx-tve.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/imx-tve.c
b/drivers/staging/imx-drm/imx-tve.c
index 3e8b0a1..a46905f 100644
--- a/drivers/staging/imx-drm/imx-tve.c
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -665,7 +665,8 @@ static int imx_tve_bind(struct device *dev, struct device
*master, void *data)
ret = regmap_read(tve->regmap, TVE_COM_CONF_REG, &val);
if (ret < 0) {
- dev_err(dev, "failed to read configuration register: %d\n",
ret);
+ dev_err(dev, "failed to read configuration register: %d\n",
+ ret);
return ret;
}
if (val != 0x0010) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3] ARM: ls1021a: add gating clocks to IP blocks.
Hi Shawn,
[...]
> > + DCFG_CCSR_DEVDISR1,
> > + ls1021a_clk_shift(0));
>
> I think we can ignore the 80 columns warning and put these on one line
> to make the code a bit easier to read.
>
Yes, it looks better, but in the FSL's internal Gerrit it will be a little
Harder to merge this patch in SDK, the Jenkins will check this and then return
failure.
Thanks,
BRs
Xiubo
> > + clks[LS1021A_CLK_ESDHC_EN] = ls1021a_clk_gate("esdhc_en", "dummy",
> > + DCFG_CCSR_DEVDISR1,
> > + ls1021a_clk_shift(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] drivers: rtc: fix s3c-rtc initialization failure without rtc source clock
On 10/15/2014 08:27 PM, Marek Szyprowski wrote:
> This patch fixes unconditional initialization failure on non-exynos3250
> SoCs. Commit df9e26d093d33a097c5558aab017dd2f540ccfe5 ("rtc: s3c: add support
> for RTC of Exynos3250 SoC") introduced rtc source clock support,
> but also added initialization failure on SoCs, which doesn't need such
> clock.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/rtc/rtc-s3c.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index a6b1252c9941..806072238c00 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -535,13 +535,15 @@ static int s3c_rtc_probe(struct platform_device *pdev)
> }
> clk_prepare_enable(info->rtc_clk);
>
> - info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
> - if (IS_ERR(info->rtc_src_clk)) {
> - dev_err(&pdev->dev, "failed to find rtc source clock\n");
> - return PTR_ERR(info->rtc_src_clk);
> + if (info->data->needs_src_clk) {
> + info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
> + if (IS_ERR(info->rtc_src_clk)) {
> + dev_err(&pdev->dev,
> + "failed to find rtc source clock\n");
> + return PTR_ERR(info->rtc_src_clk);
> + }
> + clk_prepare_enable(info->rtc_src_clk);
> }
> - clk_prepare_enable(info->rtc_src_clk);
> -
>
> /* check to see if everything is setup correctly */
> if (info->data->enable)
>
Reviewed-by: Chanwoo Choi
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: dw_mmc: rockchip: Don't recalc the clock when it goes off
Hi, Doug. It looks good to me. Acked-by: Jaehoon Chung On 10/15/2014 01:39 AM, Doug Anderson wrote: > The "set_ios" function is called with a clock of 0 when the clock is > turning off. There's no reason to go through all the extra Rockchip > logic (whose goal is to make sure DIV is 0 or 1) in that case. The > Rockchip logic happened to work because the CCF will pick the lowest > possible rate when you ask it for a clock of 0, but it's silly to go > through all the remuxing and adjusting for no reason. > > Signed-off-by: Doug Anderson > --- > drivers/mmc/host/dw_mmc-rockchip.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/mmc/host/dw_mmc-rockchip.c > b/drivers/mmc/host/dw_mmc-rockchip.c > index f0c2cb1..bbb4ec3 100644 > --- a/drivers/mmc/host/dw_mmc-rockchip.c > +++ b/drivers/mmc/host/dw_mmc-rockchip.c > @@ -37,6 +37,9 @@ static void dw_mci_rk3288_set_ios(struct dw_mci *host, > struct mmc_ios *ios) > unsigned int cclkin; > u32 bus_hz; > > + if (ios->clock == 0) > + return; > + > /* >* cclkin: source clock of mmc controller >* bus_hz: card interface clock generated by CLKGEN > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm/numa balancing: Rearrange Kconfig entry
Add the default enable config option after the NUMA_BALANCING option so that it appears related in the nconfig interface. Signed-off-by: Aneesh Kumar K.V --- NOTE: Resending with linux-mm on cc: init/Kconfig | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 5a5613ed49bc..d73c934f9e77 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -889,14 +889,6 @@ config ARCH_SUPPORTS_INT128 config ARCH_WANT_NUMA_VARIABLE_LOCALITY bool -config NUMA_BALANCING_DEFAULT_ENABLED - bool "Automatically enable NUMA aware memory/task placement" - default y - depends on NUMA_BALANCING - help - If set, automatic NUMA balancing will be enabled if running on a NUMA - machine. - config NUMA_BALANCING bool "Memory placement aware NUMA scheduler" depends on ARCH_SUPPORTS_NUMA_BALANCING @@ -909,6 +901,14 @@ config NUMA_BALANCING This system will be inactive on UMA systems. +config NUMA_BALANCING_DEFAULT_ENABLED + bool "Automatically enable NUMA aware memory/task placement" + default y + depends on NUMA_BALANCING + help + If set, automatic NUMA balancing will be enabled if running on a NUMA + machine. + menuconfig CGROUPS boolean "Control Group support" select KERNFS -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v2] x86: Make Atom PMC driver configurable.
The Atom PMC driver is always built-in, regardless of whether the kernel being built is going to be run on an Atom (or even Intel) CPU. Signed-off-by: Dave Jones Cc: One Thousand Gnomes Cc: aubrey...@linux.intel.com diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f2327e88e07c..b4dfd96aeea8 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP depends on STA2X11 config PMC_ATOM - def_bool y + tristate "Intel Atom SOC power management controller driver" + default y depends on PCI source "net/Kconfig" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Change for codestyle and good read
On Wed, 2014-10-15 at 22:55 -0300, Albino Biasutti Neto wrote: > I'm writing my first kernel patch, sorry. I will be better in the next. Please experiment with files in drivers/staging/ before you work on other files. Even then, verify what you do by using tools like scripts/objdiff and scripts/checkpatch.pl before you send a patch to the mailing list or to a maintainer. Also use scripts/get_maintainer.pl to help figure out who should be a patch email recipient. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Subject: [PATCH] kobject: fix the race between kobject_del and get_device_parent
Hi，
Would you please give me some of your views on this issue? Any suggestion is
appreciative.
Thanks!
Weng Meiling
On 2014/10/15 14:42, Weng Meiling wrote:
> When the last child kobject was deleted, it's parent kobject will be deleted,
> when removing the parent kobject if the parent kobject's sd has been set NULL
> and still not been removed from it's kset's list, at the same time another one
> trigger an device adding event, the function get_parent_device() will get the
> parent object from the kset's list for kobject_add(), but this time parent
> kobject's sd has been NULL. This race will make the sysfs_create_dir() return
> ENOENT, the new kobject will be failed to added into sysfs and trigger BUG()
> when creating attribute group under the new device's directory. So move the
> kobject removal from kset's list before kobj->sd=NULL.
>
> The race situation:
>
> path0(remove parent kobj, e.g:/sys/devices/virtual/block/) path1(register a
> new device)
>
> kobject_del(){
> get_device_parent(){
> ... ...
> sysfs_remove_dir(kobj); //kobj->sd=NULL
> spin_lock(&dev->class->p->glue_dirs.list_lock);
> ... <===
> list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
> kobj_kset_leave(kobj); //remove kobj from kset list...
> } }
>
>
> We had triggered the bug, the detail message link:
> https://lkml.org/lkml/2014/10/13/40
>
> Signed-off-by: Weng Meiling
> ---
> lib/kobject.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/kobject.c b/lib/kobject.c
> index 58751bb..af2b7bb 100644
> --- a/lib/kobject.c
> +++ b/lib/kobject.c
> @@ -560,12 +560,13 @@ void kobject_del(struct kobject *kobj)
> if (!kobj)
> return;
>
> + kobj_kset_leave(kobj);
> +
> sd = kobj->sd;
> sysfs_remove_dir(kobj);
> sysfs_put(sd);
>
> kobj->state_in_sysfs = 0;
> - kobj_kset_leave(kobj);
> kobject_put(kobj->parent);
> kobj->parent = 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/
Re: [PATCH] Change for codestyle and good read
2014-10-15 20:26 GMT-03:00 Joe Perches :
> On Wed, 2014-10-15 at 20:15 -0300, Albino Biasutti Neto wrote:
>> ---
>
> Are you not mentioning the logic changes because you
> didn't notice them?
>> diff --git a/fs/open.c b/fs/open.c
> []
>> @@ -71,10 +71,8 @@ long vfs_truncate(struct path *path, loff_t length)
>> inode = path->dentry->d_inode;
>>
>> /* For directories it's -EISDIR, for other non-regulars - -EINVAL */
>> - if (S_ISDIR(inode->i_mode))
>> + if ((S_ISDIR(inode->i_mode)) && (!S_ISRG(inode->i_mode)))
>> return -EISDIR;
>> - if (!S_ISREG(inode->i_mode))
>> - return -EINVAL;
>
> Don't think so...
>
> Did you read the comment?
No.
>> @@ -137,14 +135,13 @@ retry:
>> return error;
>> }
>>
>> -SYSCALL_DEFINE2(truncate, const char __user *, path, long, length)
>> -{
>> +SYSCALL_DEFINE2(truncate, const char __user *, path, long, length) {
>> return do_sys_truncate(path, length);
>> }
>
> Poorer, non-kernel style
>
> []
>
> diff --git a/kernel/exit.c b/kernel/exit.c
>> index 32c58f7..f429fdd 100644
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -78,8 +78,8 @@ static void __unhash_process(struct task_struct *p, bool
>> group_dead)
>> }
>>
>> /*
>> - * This function expects the tasklist_lock write-locked.
>> - */
>> + * This function expects the tasklist_lock write-locked.
>> +*/
>> static void __exit_signal(struct task_struct *tsk)
>> {
>> struct signal_struct *sig = tsk->signal;
>
> Adding trailing whitespace and misaligning too.
>
I'm writing my first kernel patch, sorry. I will be better in the next.
Albino
binoanb.eti.br
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
>Acked-by: Marek Vasut Hi,brian How about this patch? And can be accepted by linux-mtd? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the thermal tree
Hi Zhang,
After merging the thermal tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/thermal/thermal_core.c:1183:1: error: redefinition of
'thermal_cooling_device_register'
thermal_cooling_device_register(char *type, void *devdata,
^
In file included from drivers/thermal/thermal_core.c:34:0:
include/linux/thermal.h:345:46: note: previous definition of
'thermal_cooling_device_register' was here
static inline struct thermal_cooling_device *thermal_cooling_device_register(
^
drivers/thermal/thermal_core.c:1221:6: error: redefinition of
'thermal_cooling_device_unregister'
void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev)
^
In file included from drivers/thermal/thermal_core.c:34:0:
include/linux/thermal.h:351:20: note: previous definition of
'thermal_cooling_device_unregister' was here
static inline void thermal_cooling_device_unregister(struct
thermal_cooling_device *cdev)
^
Caused by commit 571ed5a8177a ("Thermal: int340x thermal: fix a Kconfig
dependency error").
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
signature.asc
Description: PGP signature
[PATCH] spi/atmel: add support for runtime PM
Drivers should put the device into low power states proactively whenever the
device is not in use. Thus implement support for runtime PM and use the
autosuspend feature to make sure that we can still perform well in case we see
lots of SPI traffic within short period of time.
Signed-off-by: Wenyou Yang
---
drivers/spi/spi-atmel.c | 62 +--
1 file changed, 55 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 649dcb5..aca285e 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
/* SPI register offsets */
#define SPI_CR 0x
@@ -191,6 +192,8 @@
#define SPI_DMA_TIMEOUT(msecs_to_jiffies(1000))
+#define AUTOSUSPEND_TIMEOUT2000
+
struct atmel_spi_dma {
struct dma_chan *chan_rx;
struct dma_chan *chan_tx;
@@ -1313,6 +1316,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
master->setup = atmel_spi_setup;
master->transfer_one_message = atmel_spi_transfer_one_message;
master->cleanup = atmel_spi_cleanup;
+ master->auto_runtime_pm = true;
platform_set_drvdata(pdev, master);
as = spi_master_get_devdata(master);
@@ -1385,6 +1389,11 @@ static int atmel_spi_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Atmel SPI Controller at 0x%08lx (irq %d)\n",
(unsigned long)regs->start, irq);
+ pm_runtime_set_autosuspend_delay(&pdev->dev, AUTOSUSPEND_TIMEOUT);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
ret = devm_spi_register_master(&pdev->dev, master);
if (ret)
goto out_free_dma;
@@ -1392,6 +1401,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
return 0;
out_free_dma:
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+
if (as->use_dma)
atmel_spi_release_dma(as);
@@ -1413,6 +1425,8 @@ static int atmel_spi_remove(struct platform_device *pdev)
struct spi_master *master = platform_get_drvdata(pdev);
struct atmel_spi*as = spi_master_get_devdata(master);
+ pm_runtime_get_sync(&pdev->dev);
+
/* reset the hardware and block queue progress */
spin_lock_irq(&as->lock);
if (as->use_dma) {
@@ -1430,9 +1444,13 @@ static int atmel_spi_remove(struct platform_device *pdev)
clk_disable_unprepare(as->clk);
+ pm_runtime_put_noidle(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+
return 0;
}
+#ifdef CONFIG_PM
#ifdef CONFIG_PM_SLEEP
static int atmel_spi_suspend(struct device *dev)
{
@@ -1447,9 +1465,10 @@ static int atmel_spi_suspend(struct device *dev)
return ret;
}
- clk_disable_unprepare(as->clk);
-
- pinctrl_pm_select_sleep_state(dev);
+ if (!pm_runtime_suspended(dev)) {
+ clk_disable_unprepare(as->clk);
+ pinctrl_pm_select_sleep_state(dev);
+ }
return 0;
}
@@ -1460,9 +1479,10 @@ static int atmel_spi_resume(struct device *dev)
struct atmel_spi*as = spi_master_get_devdata(master);
int ret;
- pinctrl_pm_select_default_state(dev);
-
- clk_prepare_enable(as->clk);
+ if (!pm_runtime_suspended(dev)) {
+ pinctrl_pm_select_default_state(dev);
+ clk_prepare_enable(as->clk);
+ }
/* Start the queue running */
ret = spi_master_resume(master);
@@ -1471,9 +1491,37 @@ static int atmel_spi_resume(struct device *dev)
return ret;
}
+#endif
-static SIMPLE_DEV_PM_OPS(atmel_spi_pm_ops, atmel_spi_suspend,
atmel_spi_resume);
+#ifdef CONFIG_PM_RUNTIME
+static int atmel_spi_runtime_suspend(struct device *dev)
+{
+ struct spi_master *master = dev_get_drvdata(dev);
+ struct atmel_spi *as = spi_master_get_devdata(master);
+ clk_disable_unprepare(as->clk);
+ pinctrl_pm_select_sleep_state(dev);
+
+ return 0;
+}
+
+static int atmel_spi_runtime_resume(struct device *dev)
+{
+ struct spi_master *master = dev_get_drvdata(dev);
+ struct atmel_spi *as = spi_master_get_devdata(master);
+
+ pinctrl_pm_select_default_state(dev);
+ clk_prepare_enable(as->clk);
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops atmel_spi_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(atmel_spi_suspend, atmel_spi_resume)
+ SET_RUNTIME_PM_OPS(atmel_spi_runtime_suspend,
+ atmel_spi_runtime_resume, NULL)
+};
#define ATMEL_SPI_PM_OPS (&atmel_spi_pm_ops)
#else
#define ATMEL_SPI_PM_OPS NULL
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
[PATCH] Input: xen-kbdfront - free grant table entry in xenkbd_disconnect_backend
From: Chang Huaixin xenkbd_disconnect_backend doesn't free grant table entry. This bug affects live migration. xenkbd_disconnect_backend uses gnttab_end_foreign_access_ref to handle grant table entry which doesn't really free an entry. Thus every time we do xenkbd_resume, grant table entry increses by one. As an grant table entry occupies 8 bytes, an grant table page has at most 512 entries. Every 512 times we do xenkdb_resume, grant table pages increses by one. After around 3500 times of live migration, grant table pages will increase by 7, causing too many pages to populate and hitting max_pages limit when assigning pages.Thus assign_pages will fail, so will live migration. Signed-off-by: Chang Huaixin --- drivers/input/misc/xen-kbdfront.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c index fbfdc10..e2ecfc6 100644 --- a/drivers/input/misc/xen-kbdfront.c +++ b/drivers/input/misc/xen-kbdfront.c @@ -285,7 +285,7 @@ static int xenkbd_connect_backend(struct xenbus_device *dev, error_evtchan: xenbus_free_evtchn(dev, evtchn); error_grant: - gnttab_end_foreign_access_ref(info->gref, 0); + gnttab_end_foreign_access(info->gref, 0, 0UL); info->gref = -1; return ret; } @@ -296,7 +296,7 @@ static void xenkbd_disconnect_backend(struct xenkbd_info *info) unbind_from_irqhandler(info->irq, info); info->irq = -1; if (info->gref >= 0) - gnttab_end_foreign_access_ref(info->gref, 0); + gnttab_end_foreign_access(info->gref, 0, 0UL); info->gref = -1; } -- 1.9.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: randconfig build error with next-20141015, in crypto
On Wed, Oct 15, 2014 at 04:24:20PM -0700, Jim Davis wrote: > This looks like a similar problem to one reported in August > (https://lists.01.org/pipermail/kbuild-all/2014-August/006021.html), > but there are significantly more errors this time. Random > configuration file attached: > > crypto/built-in.o: In function `crypto_ctr_free': > ctr.c:(.text+0x41): undefined reference to `crypto_drop_spawn' Something is wrong with your test because your config file is inconsistent with the current Kconfig description. In particular, you've got CRYPTO_CTR=y and CRYPTO_BLKCIPHER=m and yet in our Kconfig CRYPTO_CTR explicitly selects CRYPTO_BLKCIPHER. If you're just doing a simple make then this could be a bug in the kbuild system. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 net-next] openvswitch: use vport instead of p
On Wed, Oct 15, 2014 at 12:03 PM, Fabian Frederick wrote:
> All functions used struct vport *vport except
> ovs_vport_find_upcall_portid.
>
> This fixes 1 kerneldoc warning
>
> Signed-off-by: Fabian Frederick
Acked-by: Pravin B Shelar
Thanks.
> ---
> net/openvswitch/vport.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
> index 53001b0..6015802 100644
> --- a/net/openvswitch/vport.c
> +++ b/net/openvswitch/vport.c
> @@ -408,13 +408,13 @@ int ovs_vport_get_upcall_portids(const struct vport
> *vport,
> *
> * Returns the portid of the target socket. Must be called with
> rcu_read_lock.
> */
> -u32 ovs_vport_find_upcall_portid(const struct vport *p, struct sk_buff *skb)
> +u32 ovs_vport_find_upcall_portid(const struct vport *vport, struct sk_buff
> *skb)
> {
> struct vport_portids *ids;
> u32 ids_index;
> u32 hash;
>
> - ids = rcu_dereference(p->upcall_portids);
> + ids = rcu_dereference(vport->upcall_portids);
>
> if (ids->n_ids == 1 && ids->ids[0] == 0)
> return 0;
> --
> 1.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 net-next] openvswitch: kerneldoc warning fix
On Wed, Oct 15, 2014 at 12:03 PM, Fabian Frederick wrote:
> s/sock/gs
>
> Signed-off-by: Fabian Frederick
Looks good.
Acked-by: Pravin B Shelar
Thanks.
> ---
> net/openvswitch/vport-geneve.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/vport-geneve.c b/net/openvswitch/vport-geneve.c
> index 910b3ef..106a9d8 100644
> --- a/net/openvswitch/vport-geneve.c
> +++ b/net/openvswitch/vport-geneve.c
> @@ -30,7 +30,7 @@
>
> /**
> * struct geneve_port - Keeps track of open UDP ports
> - * @sock: The socket created for this port number.
> + * @gs: The socket created for this port number.
> * @name: vport name.
> */
> struct geneve_port {
> --
> 1.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] media: add media token device resource framework
On 10/15/2014 11:05 AM, Takashi Iwai wrote:
>> +#if defined(CONFIG_MEDIA_SUPPORT)
>> +extern int media_tknres_create(struct device *dev);
>> +extern int media_tknres_destroy(struct device *dev);
>> +
>> +extern int media_get_tuner_tkn(struct device *dev);
>> +extern int media_put_tuner_tkn(struct device *dev);
>> +
>> +extern int media_get_audio_tkn(struct device *dev);
>> +extern int media_put_audio_tkn(struct device *dev);
>
> The words "tknres" and "tkn" (especially latter) look ugly and not
> clear to me. IMO, it should be "token".
No problem. I can change that to media_token_create/destroy()
and expand token in other functions.
>> +struct media_tkn {
>> +spinlock_t lock;
>> +unsigned int owner; /* owner task pid */
>> +unsigned int tgid; /* owner task gid */
>> +struct task_struct *task;
>> +};
>> +
>> +struct media_tknres {
>> +struct media_tkn tuner;
>> +struct media_tkn audio;
>> +};
>
> Why do you need to have both tuner and audio tokens? If I understand
> correctly, no matter whether it's tuner or audio, if it's being used,
> the open must fail, right?
As it evolved during development, it turns out at the moment I don't
have any use-cases that require holding audio and tuner separately.
It probably could be collapsed into just a media token. I have to
think about this some.
>> +
>> +static int __media_get_tkn(struct media_tkn *tkn, char *tkn_str)
>> +{
>> +int rc = 0;
>> +unsigned tpid;
>> +unsigned tgid;
>> +
>> +spin_lock(&tkn->lock);
>
> You should use spin_lock_irqsave() here and in all other places.
> The trigger callback in usb-audio, for example, may be called in irq
> context.
ok. Good point, will change that.
>
>> +
>> +tpid = task_pid_nr(current);
>> +tgid = task_tgid_nr(current);
>> +
>> +/* allow task in the same group id to release */
>
> IMO, it's not "release" but "steal"... But what happens if the stolen
> owner calls put? Then it'll be released although the stealing owner
> still thinks it's being held.
Yeah it could be called a steal. :) Essentially tgid happens to be
the real owner. I am overwriting the pid with current pid when
tgid is same.
media dvb and v4l apps start two or more threads that all share the
tgid and subsequent token gets should be allowed based on the tgid.
Scenario 1:
Please note that there are 3 device files in question and media
token resource is the lock for all. Hence the changes to v4l-core,
dvb-core, and snd-usb-audio to hold the token for exclusive access
when the task or tgid don't match.
program starts:
- first thread opens device file in R/W mode - open gets the token
or thread makes ioctls calls that clearly indicates intent to
change tuner settings
- creates one thread for audio
- creates another for video or continues video function
- video thread does a close and re-opens the device file
In this case when thread tries to close, token put fails unless
tasks with same tgid are allowed to release.
( I ran into this one of the media applications and it is a valid
case to handle, thread can close the file and should be able to
open again without running into token busy case )
- or continue to just use the device file
- audio thread does snd_pcm_capture ops - trigger start
program exits:
- video thread closes the device file
- audio thread does snd_pcm_capture ops - trigger stop
This got me thinking about the scenario when an application
does a fork() as opposed to create a thread. I have to think
about this and see how I can address that.
>
>> +if (tkn->task && ((tkn->task != current) && (tkn->tgid != tgid))) {
>
> Shouldn't the second "&&" be "||" instead?
> And too many parentheses there.
Right - this is my bad. The comment right above this conditional
is a give away that, at some point I did a copy and paste from
_put to _get and only changed the first task null check.
I am yelling at myself at the moment.
>
>> +rc = -EBUSY;
>
> Wrong indentation.
Yes. Will fix that.
>
> I have a feeling that the whole thing can be a bit more simplified in
> the end...
>
Any ideas to simplify are welcome.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
>Won't $info contain an undefined value in case the newly added condition isn't
>met ? The old code initialized $info to a certain value always, the new code
>does not do that.
Hi,Marek Vasut
Thanks.the $info has been defined before as below:
info = (void *)id->driver_data;
Unless id has not been initialized before.If having the following situation,
current linux codes will not properly match platform device data:
For example:
const struct spi_device_id spi_nor_ids[] = {
..
..
..
{ "n25q064", INFO(0x20ba17, 0, 64 * 1024, 128, 0) },
{ "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, 0) },//former right
platform point will be overwrote by this data info.
{ "n25q128a13", INFO(0x20bb18, 0x1234, 64 * 1024, 512, SECT_4K)
},//this is the right platform data,I want to match this data info.
{ "n25q256a",INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
{ "n25q512a",INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
..
..
..
};
EXPORT_SYMBOL_GPL(spi_nor_ids);
Maybe my patch should take into account that ID is NULL,
I want to change my patch following, could you please give me some suggestions:
struct flash_info *tmpinfo;
tmpinfo = (void *)jid->driver_data;
if (id == NULL || tmpinfo->jedec_id != info->jedec_id ||
(info->ext_id != 0 && tmpinfo->ext_id != info->ext_id)) {
dev_warn(dev, "found %s, expected %s\n",
jid->name, id->name);
id = jid;
info = (void *)jid->driver_data;
}
Re: [PATCH RFC v2 0/3] virtio_net: enabling tx interrupts
On 10/15/2014 10:32 PM, Michael S. Tsirkin wrote: > RFC patches to enable tx interrupts. > This is to demonstrate how this can be done without > core virtio changes, and to make sure I understand > the new APIs correctly. > > Testing TBD: I'm going offline for several days, will only be able to > test afterwards (unless someone beats me to this). > So I thought I'd post this early. > > Applies on top of patch: "virtio_net: fix use after free" > that I recently sent. > > Changes: > address comments by Jason Wang, use delayed cb everywhere > rebased Jason's patch on top of mine and include it (with some tweaks) > > Jason, feel free to either use this, try it out, or take ideas out > of this patchset and reuse in any other way you see fit. Sure, will do some tests first. Thanks > > Jason Wang (1): > virtio-net: optimize free_old_xmit_skbs stats > > Michael S. Tsirkin (2): > virtio_net: enable tx interrupt > virtio_net: bql > > drivers/net/virtio_net.c | 153 > ++- > 1 file changed, 111 insertions(+), 42 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/2 v3] SPI: spi-pxa2xx: Add support for Intel Quark X1000 SPI controller
Hi Mark, Any update for these patches? Just want to follow-up. Best regards，Alvin Chen ICFS Platform Engineering Solution Flex Services (CMMI Level 3, IQA2005, IQA2008), Greater Asia Region Intel Information Technology Tel. 010-82171960 inet.8-7581960 Email. alvin.c...@intel.com > -Original Message- > From: Chen, Alvin > Sent: Wednesday, October 8, 2014 11:50 PM > To: Eric Miao; Russell King; Haojian Zhuang; Mark Brown > Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Westerberg, Mika; Kweh, Hock Leong; Ong, Boon > Leong; Tan, Raymond; Chen, Alvin; Andy Shevchenko > Subject: [PATCH 0/2 v3] SPI: spi-pxa2xx: Add support for Intel Quark X1000 SPI > controller > > Hi, > Intel Quark X1000 consists of two SPI controllers which can be PCI enumerated. > SPI-PXA2XX PCI layer doesn't support it. Thus, we add support for Intel Quark > X1000 SPI as well. > > --- > v3: > [PATCH 1/2] > * Improve the commit message. > * A couple of minor fixes. > [PATCH 2/2] > * Set '.num_chipselect' to '1' instead of '4'. > * A couple of minor fixes. > > v2: > Split into two patches: one is for helper functions, > and another is for quark supporting. > > [PATCH 1/2] > * Add helper functions to access registers. > * Use 'switch' instead of 'if-else'. > [PATCH 2/2] > * Use 'switch' instead of 'if-else'. > * Add comments for the 'dds'&'clk_div' caculation. > * A couple of minor fixes. > > Weike Chen (2): > SPI: spi-pxa2xx: Add helpers for regiseters' accessing > SPI: spi-pxa2xx: SPI support for Intel Quark X1000 > > drivers/spi/spi-pxa2xx-pci.c |8 ++ > drivers/spi/spi-pxa2xx.c | 304 > -- > drivers/spi/spi-pxa2xx.h | 16 ++- > include/linux/pxa2xx_ssp.h | 21 +++ > 4 files changed, 304 insertions(+), 45 deletions(-) > > -- > 1.7.9.5
Re: feature suggestion: implement SO_PEERCRED on local AF_INET/AF_INET6 sockets (allow uid-based identification on localhost)
On Wed, Oct 15, 2014 at 5:07 PM, David Madore wrote: > On Wed, Oct 15, 2014 at 03:54:08PM -0700, Andy Lutomirski wrote: >> On Wed, Oct 15, 2014 at 3:30 PM, David Madore wrote: >> > Note that since the possibility of using SO_PEERCRED on AF_INET >> > sockets does not hitherto exist on Linux, we can be sure that nobody >> > uses it, so it's not like it might open vulnerabilities in existing >> > code. If you think it's insecure, it can be documented as such (by >> > comparing it with identd): I still think it's better than having no >> > control at all when binding to localhost, which is the present >> > situation (causing, e.g., CVE-2014-2914). >> >> This doesn't follow. *Everybody* uses connect on AF_INET. >> >> IMO anything that sends a caller's credentials needs to be explicit and >> opt-in. > > I'm confused as to whether you mean "opt-in" on the side of the caller > (=process requesting the endpoint's credentials), or on that of the > endpoint (=authenticated process). On the one hand I don't understand > what it could mean on the caller side, on the other hand you mention > explicit support in OpenSSH, which would be the caller in my scenario. I mean the authenticated process, not the process doing the authentication. > > So, in case I haven't been clear enough, the situation I have in mind > is: on "thishost", I run "ssh -L 14321:remotehost:4321 somehost" to > forward connexions on from the local port 14321 of thishost (where ssh > listens on the loopback) to the port 4321 of remotehost. > Unfortunately, now everyone with an acccount on thishost can connect > to port 14321 and effectively emit a connection from somehost to > remotehost on my behalf. I think everyone agrees that this is a huge > problem. But I don't understand how you propose to remedy this. Unfortunately, I think that you need client changes. These could be semi-transparent (using LD_PRELOAD) or almost completely transparent (using network namespaces). Actually, a network namespace-based proxying tool could be very useful. > > Patching ssh is an option, but I don't see how to do it (ssh needs to > make sure that the connections it receives on 14321 are from the same > uid, and this seems impossible without the feature I'm discussing). > Patching the kernel is an option. Patching clients that connect to > 14321, on the other hand, is not, because there are many different > ones, and their protocol is defined by immutable Internet standards, > so we have no latitude there (for example, we can't ask a Web browser > to connect to Unix domain sockets: there simply isn't a URL scheme to > refer to them). Adding iptables rules is not an option if I'm not the > system administrator on thishost. I misunderstood. I though that you wanted a server-side solution. > > So, how can we solve this problem securely? > >> I believe that there is no secure way to authenticate clients that >> currently don't authenticate themselves without changing the clients. >> That's the whole point: currently-secure are written under the >> assumption that they are not exercising their credentials. You can't >> safely change that without making it opt-in. > > Then what are we to do, given that modifying the clients is > impossible? > > What about my proposal that user credentials would be returned only if > they refer to the same user as the caller user and that the caller is > permitted to ptrace the endpoint? This answers your objection of > leaking credentials: the caller could do anything at all with the > other side since it could ptrace it - we're just permitting a user to > authenticate their own sockets. A further sysctl could enable the use > of the call in more general cases, for those administrators who think > it should be allowed. > Ugh. That's probably safe, but it's quite disgusting IMO. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 08/10] kgdb: Remove "weak" from kgdb_arch_pc() declaration
On Wed, Oct 15, 2014 at 10:06 AM, Bjorn Helgaas wrote:
>
> kernel/debug/debug_core.c provides a default kgdb_arch_pc() definition
> explicitly marked "weak". Several architectures provide their own
> definitions intended to override the default, but the "weak" attribute on
> the declaration applied to the arch definitions as well, so the linker
> chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak
> annotation from pcibios_get_phb_of_node decl")).
>
> Remove the "weak" attribute from the declaration so we always prefer a
> non-weak definition over the weak one, independent of link order.
>
> Fixes: 688b744d8bc8 ("kgdb: fix signedness mixmatches, add statics, add
> declaration to header")
> Signed-off-by: Bjorn Helgaas
> CC: Harvey Harrison
Reviewed-by: Harvey Harrison
This was likely simply an error in my patch, likely just copied the
function definition and didn't even notice the
weak annotation at the time.
Harvey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: feature suggestion: implement SO_PEERCRED on local AF_INET/AF_INET6 sockets (allow uid-based identification on localhost)
On Wed, Oct 15, 2014 at 03:54:08PM -0700, Andy Lutomirski wrote: > On Wed, Oct 15, 2014 at 3:30 PM, David Madore wrote: > > Note that since the possibility of using SO_PEERCRED on AF_INET > > sockets does not hitherto exist on Linux, we can be sure that nobody > > uses it, so it's not like it might open vulnerabilities in existing > > code. If you think it's insecure, it can be documented as such (by > > comparing it with identd): I still think it's better than having no > > control at all when binding to localhost, which is the present > > situation (causing, e.g., CVE-2014-2914). > > This doesn't follow. *Everybody* uses connect on AF_INET. > > IMO anything that sends a caller's credentials needs to be explicit and > opt-in. I'm confused as to whether you mean "opt-in" on the side of the caller (=process requesting the endpoint's credentials), or on that of the endpoint (=authenticated process). On the one hand I don't understand what it could mean on the caller side, on the other hand you mention explicit support in OpenSSH, which would be the caller in my scenario. So, in case I haven't been clear enough, the situation I have in mind is: on "thishost", I run "ssh -L 14321:remotehost:4321 somehost" to forward connexions on from the local port 14321 of thishost (where ssh listens on the loopback) to the port 4321 of remotehost. Unfortunately, now everyone with an acccount on thishost can connect to port 14321 and effectively emit a connection from somehost to remotehost on my behalf. I think everyone agrees that this is a huge problem. But I don't understand how you propose to remedy this. Patching ssh is an option, but I don't see how to do it (ssh needs to make sure that the connections it receives on 14321 are from the same uid, and this seems impossible without the feature I'm discussing). Patching the kernel is an option. Patching clients that connect to 14321, on the other hand, is not, because there are many different ones, and their protocol is defined by immutable Internet standards, so we have no latitude there (for example, we can't ask a Web browser to connect to Unix domain sockets: there simply isn't a URL scheme to refer to them). Adding iptables rules is not an option if I'm not the system administrator on thishost. So, how can we solve this problem securely? > I believe that there is no secure way to authenticate clients that > currently don't authenticate themselves without changing the clients. > That's the whole point: currently-secure are written under the > assumption that they are not exercising their credentials. You can't > safely change that without making it opt-in. Then what are we to do, given that modifying the clients is impossible? What about my proposal that user credentials would be returned only if they refer to the same user as the caller user and that the caller is permitted to ptrace the endpoint? This answers your objection of leaking credentials: the caller could do anything at all with the other side since it could ptrace it - we're just permitting a user to authenticate their own sockets. A further sysctl could enable the use of the call in more general cases, for those administrators who think it should be allowed. -- David A. Madore ( http://www.madore.org/~david/ ) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 net-next] openvswitch: kerneldoc warning fix
Pravin could you please review these two openvswitch kerneldoc fixes from Fabian? 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: [resend Patch v3 1/2] kaslr: check if kernel location is changed
On 10/16/14 at 07:55am, Baoquan He wrote: > On 10/15/14 at 01:32pm, H. Peter Anvin wrote: > > I don't see why we can't randomize anywhere in physical space. We already > > handle the kernel above 4 GB and it wouldn't be hard to do the equivalent > > for the decompress/relocation code, using a #PF handler. Not all CPUs > > support 1 GB pages. > > > > Well, IIUC, in arch/x86/boot/compressed/head_64.S pgtable contains 6 > page frames and is used to build 4G identity mapping. Then this pgtable > is loaded into cr3. Later jump into 64bit mode. decompress/relocation > code should work in this region. Isn't it right? > > Currently kernel surely can be put anywhere, even above 4G. This have > been done very often in kexec/kdump. However in kexec/kdump the identity > mapping is built for all physical memory after jumping to startup_64 ~ should be before > directly from purgatory, that's why kexec/kdump kernel can be put > anywhere. > > So for normal kernel, don't we need to extend the physical memory mappng > to a larger region if we want to randomize anywhere in physical space? > > Thanks > Baoquan > > > > On October 14, 2014 8:37:01 PM PDT, Baoquan He wrote: > > >On 10/14/14 at 08:49am, Vivek Goyal wrote: > > >> On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote: > > >> > On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote: > > >> > > On 10/13/2014 08:19 AM, Vivek Goyal wrote: > > >> > > >>> > > >> > > >>> This really shouldn't have happened this way on x86-64. It > > >has to happen > > >> > > >>> this way on i386, but I worry that this may be a serious > > >misdesign in kaslr > > >> > > >>> on x86-64. I'm also wondering if there is any other fallout > > >of this? > > >> > > >> > > >> > > >> I agree. On x86_64, we should stick to previous design and > > >this new > > >> > > >> logic of performing relocations does not sound very clean and > > >makes > > >> > > >> things very confusing. > > >> > > >> > > >> > > >> I am wondering that why couldn't we simply adjust page tables > > >in case of > > >> > > >> kaslr on x86_64, instead of performing relocations. > > >> > > > > > >> > > > Well, IIUC, if virtual addresses are shifted w.r.t what virtual > > >address > > >> > > > kernel was compiled for, then relocation will have to be done. > > >> > > > > > >> > > > So question will be if physical address shift is enough for > > >kaslr or > > >> > > > virtual address shift is necessary. > > >> > > > > > >> > > > > >> > > I would assume that without a virtual address shift kaslr is > > >pretty darn > > >> > > pointless. Without the physical address shift the 1:1 map can be > > >used, > > >> > > and again, kaslr becomes pointless. However, there is absolutely > > >no > > >> > > reason why they should be coupled. They can, in fact, be > > >independently > > >> > > randomized. > > >> > > > >> > Agreed. On x86_64, we should be able to randomize virtual address > > >space > > >> > and physical address space independently. And in that case whole of > > >> > the physical memory should be available for a possible location for > > >> > kernel. (As opposed to a small limit (I guess 1GB) now) > > > > > >It can be done to randomize virtual address space and physical address > > >space independently. But limited by the 2G of kernel text mapping and > > >module mapping virtual address space, virtual address can be randomized > > >in (0x100, 1G) range. While physical address can be randomized in > > >(0x100, 4G) according to the identity mapping of normal kernel. > > >Then > > >phys_base still stores an relative value, a different offset than > > >before. > > > > > >This can be easily implement. One thing is still there's a limit for > > >physical addr randomization, only below 4G. So I am wondering if we can > > >extend the identify mapping to complete mapping of 48 bit, using 1G > > >page > > >frame. This can make physical addr be randomized to anywhere. > > > > > >So now there may be 3 options: > > > > > >1) Fix this bug in current kaslr. Since when randomize the new kernel > > >location in choose_kernel_location(), cmdline options has been checked > > >strictly, e.g if nokaslr is specified, it's safe to do the kernel > > >location randomization. Then in handle_relocations(), we only need to > > >check if the kernel location is changed, comparing with kernel loaded > > >addr. If changed, kaslr is done, let's do the relocation handling. If > > >not changed, no kaslr id done, just skip the relocation handling like > > >before. > > > > > >2) randomize the virtual addr space and physical addr space > > >independently. But physical addr space must be below 4G. > > > > > >3) extend the identity mapping to 48bit of addr space. Then we can > > >randomized the virtual addr space in (0x100, 1G) and physical addr > > >space in (0x100, real physical memory end). > > > > > >If option 3 is doable, it's the best. If not, I think bug fix should be
mmotm 2014-10-15-16-57 uploaded
The mm-of-the-moment snapshot 2014-10-15-16-57 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.17: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch * cgroup-kmemleak-add-kmemleak_free-for-cgroup-deallocations.patch * mm-compaction-avoid-premature-range-skip-in-isolate_migratepages_range.patch * fsnotify-next_i-is-freed-during-fsnotify_unmount_inodes.patch * gcov-add-arm64-to-gcov_profile_all.patch * mm-free-compound-page-with-correct-order.patch * drivers-of-add-return-value-to-of_reserved_mem_device_init.patch * mm-thp-fix-collapsing-of-hugepages-on-madvise.patch * fs-cifs-remove-obsolete-__constant.patch * fs-cifs-filec-replace-countsize-kzalloc-by-kcalloc.patch * fs-cifs-smb2filec-replace-countsize-kzalloc-by-kcalloc.patch * kernel-posix-timersc-code-clean-up.patch * kernel-posix-timersc-code-clean-up-checkpatch-fixes.patch * input-route-kbd-leds-through-the-generic-leds-layer.patch * input-route-kbd-leds-through-the-generic-leds-layer-fix.patch * input-route-kbd-leds-through-the-generic-leds-layer-fix-2.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * ocfs2-dlm-let-sender-retry-if-dlm_dispatch_assert_master-failed-with-enomem.patch * o2dlm-fix-null-pointer-dereference-in-o2dlm_blocking_ast_wrapper.patch * o2dlm-fix-null-pointer-dereference-in-o2dlm_blocking_ast_wrapper-checkpatch-fixes.patch * ocfs2-free-inode-when-i_count-becomes-zero.patch * ocfs2-call-ocfs2_journal_access_di-before-ocfs2_journal_dirty-in-ocfs2_write_end_nolock.patch * ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages.patch * ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages-v2.patch * ocfs2-dlm-fix-race-between-dispatched_work-and-dlm_lockres_grab_inflight_worker.patch * ocfs2-reflink-fix-slow-unlink-for-refcounted-file.patch * ocfs2-fix-journal-commit-deadlock.patch * ocfs2-eliminate-the-static-flag-of-some-functions.patch * ocfs2-add-two-functions-of-add-and-remove-inode-in-orphan-dir.patch * ocfs2-add-orphan-recovery-types-in-ocfs2_recover_orphans.patch * ocfs2-add-and-remove-inode-in-orphan-dir-in-ocfs2_direct_io.patch * ocfs2-add-and-remove-inode-in-orphan-dir-in-ocfs2_direct_io-fix.patch * ocfs2-allocate-blocks-in-ocfs2_direct_io_get_blocks.patch * ocfs2-do-not-fallback-to-buffer-i-o-write-if-appending.patch * ocfs2-do-not-fallback-to-buffer-i-o-write-if-fill-holes.patch * ocfs2-do-not-fallback-to-buffer-i-o-write-if-fill-holes-checkpatch-fixes.patch * bio-modify-__bio_add_page-to-accept-pages-that-dont-start-a-new-segment.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.pat
