Re: [PATCH] cpufreq: governors: Remove duplicate check of target freq in supported range
On 27 August 2013 00:07, Stratos Karafotis wrote: > drivers/cpufreq/cpufreq_conservative.c | 4 Get rid of few more checks.. /* if we are already at full speed then break out early */ if (dbs_info->requested_freq == policy->max) return; /* * if we cannot reduce the frequency anymore, break out early */ if (policy->cur == policy->min) return; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the libata tree
On 08/27/2013 10:50 AM, Stephen Rothwell wrote:
> Hi Tejun,
>
> After merging the libata tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from drivers/ata/libata-pmp.c:14:0:
> drivers/ata/libata.h:136:1: error: unknown type name 'acpi_handle'
> static inline acpi_handle ata_dev_acpi_handle(struct ata_device *dev) {
> return NULL; }
> ^
>
> And several others.
>
> Caused by commit f1bc1e4c44b1 ("ata: acpi: rework the ata acpi bind
> support"). All the world does not have the ACPI include files
> included via some other path ... nor wants them, I suspect.
Sorry for the trouble, my bad.
Does the below patch fix the problem?
From: Aaron Lu
Subject: [PATCH] ata: acpi: Remove ata_dev_acpi_handle stub in libata.h
The ata_dev_acpi_handle is defined in libata-acpi.c and the only
external user is libata-zpodd.c, which is built when CONFIG_ATA_ACPI
is set, so there is no need to make an empty stub function for
!CONFIG_ATA_ACPI case in libata.h. It also causes compile errors due to
acpi_handle is not defined when !CONFIG_ACPI. This patch fixes this
problem by removing the empty stub.
Reported-by: Stephen Rothwell
Signed-off-by: Aaron Lu
---
drivers/ata/libata.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index 3e9cc95..eeeb778 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -133,7 +133,6 @@ static inline void ata_acpi_set_state(struct ata_port *ap,
pm_message_t state) { }
static inline void ata_acpi_bind_port(struct ata_port *ap) {}
static inline void ata_acpi_bind_dev(struct ata_device *dev) {}
-static inline acpi_handle ata_dev_acpi_handle(struct ata_device *dev) { return
NULL; }
static inline void ata_scsi_acpi_bind(struct ata_device *dev) {}
static inline void ata_scsi_acpi_unbind(struct ata_device *dev) {}
#endif
--
1.8.3.2.10.g43d11f4
Thanks,
Aaron
>
> I have used the libata tree from next-20130822 for today.
>
> P.S. drivers/ata/libata.h seems to assume that a lot of other stuff is
> included that it does not include explicitly ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel: Assembly: need add prefix for h8300 architecture.
Chen Gang writes: > If this implementation is correct, the implementation still can be > improved (at least, it is not quite well to hard code the architecture > related code in "kernel/" and "usr/" sub-directory). > > But it seems, I have no right to add or move files, so welcome any > members help do it. > > And welcome any additional suggestions or completions. Hmm, how about something like: #ifdef CONFIG_ARCH_ASM_INCBIN_NEEDS_PREFIX #include ASM_INCBIN_PREFIX #endif /* ARCH_ASM_INCBIN_NEEDS_PREFIX */ Then h8300 can define ARCH_ASM_INCBIN_NEEDS_PREFIX in Kconfig and define ASM_INCBIN_PREFIX in arch/h8300/include/asm/incbin_prefix.h? Cheers, Rusty. > On 08/26/2013 06:42 PM, Chen Gang wrote: >> Need add related prefix for h8300, or can not pass compiling by the >> latest linker. >> >> The related error (allmodconfig for h8300): >> >> /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file >> `usr/initramfs_data.o' is incompatible with h8300h output >> /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file >> `kernel/modsign_certificate.o' is incompatible with h8300h output >> >> The cross-compiler's information: >> >> [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-ld -v >> GNU ld (GNU Binutils) 2.22 >> [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-as -v >> GNU assembler version 2.22 (h8300-gchen-elf) using BFD version (GNU >> Binutils) 2.22 >> >> [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v >> Using built-in specs. >> COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc >> >> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.8.0/lto-wrapper >> Target: h8300-gchen-elf >> Configured with: ../gcc-4.8.0/configure --target=h8300-gchen-elf >> --without-header --disable-nls --enable-language=c --disable-threads >> --disable-shared --enable-werror=no >> Thread model: single >> gcc version 4.8.0 (GCC) >> >> >> Signed-off-by: Chen Gang >> --- >> kernel/modsign_certificate.S |7 +++ >> usr/initramfs_data.S |7 +++ >> 2 files changed, 14 insertions(+), 0 deletions(-) >> >> diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S >> index 4a9a86d..d24acac 100644 >> --- a/kernel/modsign_certificate.S >> +++ b/kernel/modsign_certificate.S >> @@ -1,5 +1,12 @@ >> #include >> >> +#if defined(CONFIG_CPU_H8300H) >> +.h8300h >> +#endif >> +#if defined(CONFIG_CPU_H8S) >> +.h8300s >> +#endif >> + >> #define GLOBAL(name)\ >> .globl VMLINUX_SYMBOL(name);\ >> VMLINUX_SYMBOL(name): >> diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S >> index c14322d..6a6c106 100644 >> --- a/usr/initramfs_data.S >> +++ b/usr/initramfs_data.S >> @@ -24,6 +24,13 @@ >> #include >> #include >> >> +#if defined(CONFIG_CPU_H8300H) >> +.h8300h >> +#endif >> +#if defined(CONFIG_CPU_H8S) >> +.h8300s >> +#endif >> + >> .section .init.ramfs,"a" >> __irf_start: >> .incbin __stringify(INITRAMFS_IMAGE) >> > > > -- > Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 next]module: Fix mod->mkobj.kobj potentially freed too early
Greg KH writes:
> On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote:
>> DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
> People are starting to hit these types of issues, and I'd like to take
> this one out of the picture.
>
> Rusty, any objection to me taking this through my driver-core tree,
> where this new config option shows up?
The original fix was better.
Moving the module_kobject out and giving it its own lifetime solves this
immediate issue, but it still means there's an accessible module_kobject
around referring to a module which doesn't exist any more.
Original copied below, feel free to take it.
Cheers,
Rusty.
From: Li Zhong
Subject: module: Fix mod->mkobj.kobj potentially freed too early
DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
After some investigation, it seems the reason is:
The mod->mkobj.kobj(a01600d0 below) is freed together with mod
itself in free_module(). However, its children still hold references to
it, as the delay caused by DEBUG_KOBJECT_RELEASE. So when the
child(holders below) tries to decrease the reference count to its parent
in kobject_del(), BUG happens as it tries to access already freed memory.
This patch tries to fix it by waiting for the mod->mkobj.kobj to be
really released in the module removing process (and some error code
paths).
[ 1844.175287] kobject: 'holders' (88007c1f1600): kobject_release, parent
a01600d0 (delayed)
[ 1844.178991] kobject: 'notes' (8800370b2a00): kobject_release, parent
a01600d0 (delayed)
[ 1845.180118] kobject: 'holders' (88007c1f1600): kobject_cleanup, parent
a01600d0
[ 1845.182130] kobject: 'holders' (88007c1f1600): auto cleanup kobject_del
[ 1845.184120] BUG: unable to handle kernel paging request at a01601d0
[ 1845.185026] IP: [] kobject_put+0x11/0x60
[ 1845.185026] PGD 1a13067 PUD 1a14063 PMD 7bd30067 PTE 0
[ 1845.185026] Oops: [#1] PREEMPT
[ 1845.185026] Modules linked in: xfs libcrc32c [last unloaded: kprobe_example]
[ 1845.185026] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G O
3.11.0-rc6-next-20130819+ #1
[ 1845.185026] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 1845.185026] Workqueue: events kobject_delayed_cleanup
[ 1845.185026] task: 88007ca51f00 ti: 88007ca5c000 task.ti:
88007ca5c000
[ 1845.185026] RIP: 0010:[] []
kobject_put+0x11/0x60
[ 1845.185026] RSP: 0018:88007ca5dd08 EFLAGS: 00010282
[ 1845.185026] RAX: 2000 RBX: a01600d0 RCX: 8177d638
[ 1845.185026] RDX: 88007ca5dc18 RSI: RDI: a01600d0
[ 1845.185026] RBP: 88007ca5dd18 R08: 824e9810 R09:
[ 1845.185026] R10: 8800 R11: dead4ead0001 R12: 81a95040
[ 1845.185026] R13: 88007b27a960 R14: 88007c1f1600 R15:
[ 1845.185026] FS: () GS:81a23000()
knlGS:
[ 1845.185026] CS: 0010 DS: ES: CR0: 8005003b
[ 1845.185026] CR2: a01601d0 CR3: 37207000 CR4: 06b0
[ 1845.185026] Stack:
[ 1845.185026] 88007c1f1600 88007c1f1600 88007ca5dd38
812cdb7e
[ 1845.185026] 88007c1f1640 88007ca5dd68
812cdbfe
[ 1845.185026] 88007c974800 88007c1f1640 88007ff61a00
[ 1845.185026] Call Trace:
[ 1845.185026] [] kobject_del+0x2e/0x40
[ 1845.185026] [] kobject_delayed_cleanup+0x6e/0x1d0
[ 1845.185026] [] process_one_work+0x1e5/0x670
[ 1845.185026] [] ? process_one_work+0x183/0x670
[ 1845.185026] [] worker_thread+0x113/0x370
[ 1845.185026] [] ? rescuer_thread+0x290/0x290
[ 1845.185026] [] kthread+0xda/0xe0
[ 1845.185026] [] ? _raw_spin_unlock_irq+0x30/0x60
[ 1845.185026] [] ? kthread_create_on_node+0x130/0x130
[ 1845.185026] [] ret_from_fork+0x7a/0xb0
[ 1845.185026] [] ? kthread_create_on_node+0x130/0x130
[ 1845.185026] Code: 81 48 c7 c7 28 95 ad 81 31 c0 e8 9b da 01 00 e9 4f ff ff
ff 66 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 85 ff 74 1d 87
00 01 00 00 01 74 1e 48 8d 7b 38 83 6b 38 01 0f 94 c0 84
[ 1845.185026] RIP [] kobject_put+0x11/0x60
[ 1845.185026] RSP
[ 1845.185026] CR2: a01601d0
[ 1845.185026] ---[ end trace 49a70afd109f5653 ]---
Signed-off-by: Li Zhong
Signed-off-by: Rusty Russell
---
include/linux/module.h | 1 +
kernel/module.c| 14 +++---
kernel/params.c| 7 +++
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 504035f..05f2447 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -42,6 +42,7 @@ struct module_kobject {
struct module *mod;
struct kobject *drivers_dir;
struct module_param_attrs *mp;
+ struct completion *kobj_completion;
};
struct module_attribute {
diff --git a/kernel/module.c b/kernel/module.c
index 40ee1dc..9f5ddae 100644
---
[PATCH net-next] drivers:net: Convert dma_alloc_coherent(...__GFP_ZERO) to dma_zalloc_coherent
__GFP_ZERO is an uncommon flag and perhaps is better
not used. static inline dma_zalloc_coherent exists
so convert the uses of dma_alloc_coherent with __GFP_ZERO
to the more common kernel style with zalloc.
Remove memset from the static inline dma_zalloc_coherent
and add just one use of __GFP_ZERO instead.
Trivially reduces the size of the existing uses of
dma_zalloc_coherent.
Realign arguments as appropriate.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/aeroflex/greth.c | 12 -
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 6 ++---
drivers/net/ethernet/broadcom/bnx2.c | 5 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h| 5 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h| 3 +--
drivers/net/ethernet/broadcom/tg3.c| 23 -
drivers/net/ethernet/emulex/benet/be_main.c| 18 +++---
drivers/net/ethernet/faraday/ftgmac100.c | 7 +++---
drivers/net/ethernet/faraday/ftmac100.c| 8 +++---
drivers/net/ethernet/ibm/emac/mal.c| 4 +--
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 8 +++---
drivers/net/ethernet/intel/ixgb/ixgb_main.c| 4 +--
drivers/net/ethernet/marvell/pxa168_eth.c | 19 +++---
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 6 ++---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 16 ++--
drivers/net/ethernet/pasemi/pasemi_mac.c | 7 +++---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c| 29 +++---
drivers/net/ethernet/sfc/nic.c | 5 ++--
drivers/net/ethernet/sgi/meth.c| 5 ++--
drivers/net/ethernet/tundra/tsi108_eth.c | 8 +++---
drivers/net/ethernet/xilinx/ll_temac_main.c| 12 -
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 14 +--
drivers/net/fddi/defxx.c | 6 ++---
drivers/net/irda/ali-ircc.c| 8 +++---
drivers/net/irda/nsc-ircc.c| 8 +++---
drivers/net/irda/smsc-ircc2.c | 8 +++---
drivers/net/irda/via-ircc.c| 8 +++---
drivers/net/irda/w83977af_ir.c | 8 +++---
drivers/net/wireless/b43/dma.c | 6 ++---
drivers/net/wireless/b43legacy/dma.c | 7 +++---
include/linux/dma-mapping.h| 5 ++--
31 files changed, 135 insertions(+), 153 deletions(-)
diff --git a/drivers/net/ethernet/aeroflex/greth.c
b/drivers/net/ethernet/aeroflex/greth.c
index 7ff4b30..e066945 100644
--- a/drivers/net/ethernet/aeroflex/greth.c
+++ b/drivers/net/ethernet/aeroflex/greth.c
@@ -1464,18 +1464,18 @@ static int greth_of_probe(struct platform_device *ofdev)
}
/* Allocate TX descriptor ring in coherent memory */
- greth->tx_bd_base = dma_alloc_coherent(greth->dev, 1024,
- >tx_bd_base_phys,
- GFP_KERNEL | __GFP_ZERO);
+ greth->tx_bd_base = dma_zalloc_coherent(greth->dev, 1024,
+ >tx_bd_base_phys,
+ GFP_KERNEL);
if (!greth->tx_bd_base) {
err = -ENOMEM;
goto error3;
}
/* Allocate RX descriptor ring in coherent memory */
- greth->rx_bd_base = dma_alloc_coherent(greth->dev, 1024,
- >rx_bd_base_phys,
- GFP_KERNEL | __GFP_ZERO);
+ greth->rx_bd_base = dma_zalloc_coherent(greth->dev, 1024,
+ >rx_bd_base_phys,
+ GFP_KERNEL);
if (!greth->rx_bd_base) {
err = -ENOMEM;
goto error4;
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 190219e..98b6870 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -948,8 +948,7 @@ static int bcm_enet_open(struct net_device *dev)
/* allocate rx dma ring */
size = priv->rx_ring_size * sizeof(struct bcm_enet_desc);
- p = dma_alloc_coherent(kdev, size, >rx_desc_dma,
- GFP_KERNEL | __GFP_ZERO);
+ p = dma_zalloc_coherent(kdev, size, >rx_desc_dma, GFP_KERNEL);
if (!p) {
ret = -ENOMEM;
goto out_freeirq_tx;
@@ -960,8 +959,7 @@ static int bcm_enet_open(struct net_device *dev)
/* allocate tx dma ring */
size = priv->tx_ring_size * sizeof(struct bcm_enet_desc);
- p = dma_alloc_coherent(kdev, size, >tx_desc_dma,
- GFP_KERNEL | __GFP_ZERO);
+ p = dma_zalloc_coherent(kdev, size, >tx_desc_dma, GFP_KERNEL);
if (!p)
Re: unused swap offset / bad page map.
On Mon, Aug 26, 2013 at 04:15:00PM -0700, Linus Torvalds wrote: > On Mon, Aug 26, 2013 at 3:08 PM, Hugh Dickins wrote: > > > > I just did a quick diff of 3.11-rc7/mm against 3.10, and here's > > a line in mremap which worries me. That set_pte_at() is operating > > on anything that isn't pte_none(), so the pte_mksoft_dirty() looks > > prone to corrupt a swap entry. > > Uhhuh. I think you hit the nail on the head here. > > I checked all the pte_swp_*soft_dirty() users (they should be used on > swp entries), because that came up in another thread. But you're > right, the non-swp ones only work on present pte entries (or on > file-offset entries, I guess), and at least that mremap() case seems > bogus. Oh my :( Indeed it sets _PAGE_SOFT_DIRTY unconditionally, sigh. This nit comes from former soft-dirty commit. Let me check all other places we set soft dirty bit (Pavel CC'ed). > I'm not seeing the point of marking the thing soft-dirty at all, > although I guess it's "dirty" in the sense that it changed the > contents at that virtual address. But for that code to work, it would > have to have the same bit for swap entries as for present pages (and > for file mapping entries), and that's not true. They are two different > bits (_PAGE_SOFT_DIRTY is bit #11 vs _PAGE_SWP_SOFT_DIRTY is bit #7). > > Ugh. Cyrill, this is a mess. Linus, I simply had no place in pte entry to carry soft-dirty status when pte incoded in swap format, so it was unpleasant but necessary decision. That's why bits access are wrapped in own macros with 'swp' prefix thus reader would easily grep for them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/7] cpufreq:boost: CPU Boost mode support
On 26 August 2013 21:20, Lukasz Majewski wrote: > This patch series introduces support for CPU overclocking technique > called Boost. > > It is a follow up of a LAB governor proposal. Boost is a LAB component: > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > software oriented one (like the one done at Exynos). > For this reason cpufreq/freq_table code has been reorganized to include > common code. > > Important design decisions: > - Boost related code is compiled-in unconditionally to cpufreq core and > disabled by default. The cpufreq_driver is responsibile for setting > boost_supported flag and providing set_boost callback(if HW support > is needed). For software managed boost, special Kconfig flag - > CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only > when a target platform has thermal framework properly configured. > > - struct cpufreq_driver has been extended with boost related fields: > -- boost_supported - when driver supports boosting > -- boost_enabled - boost state > -- set_boost - callback to function, which is necessary to >enable/disable boost > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is visible > _only_ when cpufreq driver supports Boost. > > - No special spin_lock for Boost was created. The one from cpufreq core > was reused. > > - The Boost code doesn't rely on any policy. When boost state is changed, > then the policy list is iterated and proper adjustements are done. > > - To improve safety level, the thermal framework is also extended to disable > software boosting, when thermal trip point is reached. Then it starts > monitoring target temperature to evaluate if boost can be enabled > again. This emulates behaviour similar to HW managed boost (like x86) > > Tested at HW: >Exynos 4412 3.11-rc6 Linux >Intel Core i7-3770 3.11-rc6 Linux > > Above patches were posted on top of linux_pm/linux-next > (SHA1: 68327ee544d74f20bb6179637971912e5e78811c) > > Lukasz Majewski (7): > cpufreq: Add boost frequency support in core > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common > boost solution > thermal:boost: Automatic enable/disable of BOOST feature > cpufreq:boost:Kconfig: Provide support for software managed BOOST > cpufreq:exynos:Extend Exynos cpufreq driver to support boost > framework > Documentation:cpufreq:boost: Update BOOST documentation > cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ > > Documentation/cpu-freq/boost.txt | 26 > drivers/cpufreq/Kconfig |4 ++ > drivers/cpufreq/Kconfig.arm | 15 + > drivers/cpufreq/acpi-cpufreq.c | 86 + > drivers/cpufreq/cpufreq.c| 118 > +- > drivers/cpufreq/exynos-cpufreq.c |6 ++ > drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > drivers/cpufreq/freq_table.c | 53 +-- > drivers/thermal/thermal_core.c | 55 > include/linux/cpufreq.h | 25 +++ > include/linux/thermal.h |2 + > 11 files changed, 313 insertions(+), 79 deletions(-) Sorry for the long delays in getting this patchset in :) Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [trivial PATCH] treewide: Fix printks with 0x%#
On Thursday 25 July 2013 14:53:25 Joe Perches wrote: > Using 0x%# emits 0x0x. Only one is necessary. sounds like a job for checkpatch.pl :) -mike signature.asc Description: This is a digitally signed message part.
linux-next: manual merge of the regulator tree with the pm tree
Hi all,
Today's linux-next merge of the regulator tree got a conflict in
drivers/cpufreq/cpufreq-cpu0.c between commit f837a9b5ab05 ("cpufreq:
cpufreq-cpu0: remove device tree parsing for cpu nodes") from the tree
and commit 7d748971c0c0 ("cpufreq: cpufreq-cpu0: Use
devm_regulator_get_optional()") from the regulator tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/cpufreq/cpufreq-cpu0.c
index bad620e,e9dedb2..000
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@@ -174,18 -174,30 +174,18 @@@ static struct cpufreq_driver cpu0_cpufr
static int cpu0_cpufreq_probe(struct platform_device *pdev)
{
- struct device_node *np, *parent;
+ struct device_node *np;
int ret;
- parent = of_find_node_by_path("/cpus");
- if (!parent) {
- pr_err("failed to find OF /cpus\n");
- return -ENOENT;
- }
-
- for_each_child_of_node(parent, np) {
- if (of_get_property(np, "operating-points", NULL))
- break;
- }
+ cpu_dev = >dev;
+ np = of_node_get(cpu_dev->of_node);
if (!np) {
pr_err("failed to find cpu0 node\n");
- ret = -ENOENT;
- goto out_put_parent;
+ return -ENOENT;
}
- cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
- cpu_dev = >dev;
- cpu_dev->of_node = np;
-
+ cpu_reg = devm_regulator_get_optional(cpu_dev, "cpu0");
if (IS_ERR(cpu_reg)) {
/*
* If cpu0 regulator supply node is present, but regulator is
pgpDrHUWgJtZ3.pgp
Description: PGP signature
[PATCH v2] h8300: Makefile: add "-no-warn-mismatch" to linker to avoid linking error.
Need add "-no-warn-mismatch" to avoid the linking error, or assembly files which are outside of the "arch/h8300" can not pass compiling. The related error (allmodconfig for h8300): /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file `usr/initramfs_data.o' is incompatible with h8300h output /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file `kernel/modsign_certificate.o' is incompatible with h8300h output The cross-compiler's information: [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-ld -v GNU ld (GNU Binutils) 2.22 [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-as -v GNU assembler version 2.22 (h8300-gchen-elf) using BFD version (GNU Binutils) 2.22 [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.8.0/lto-wrapper Target: h8300-gchen-elf Configured with: ../gcc-4.8.0/configure --target=h8300-gchen-elf --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no Thread model: single gcc version 4.8.0 (GCC) Signed-off-by: Chen Gang --- arch/h8300/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/h8300/Makefile b/arch/h8300/Makefile index a556447..3ad1369 100644 --- a/arch/h8300/Makefile +++ b/arch/h8300/Makefile @@ -26,7 +26,7 @@ model-$(CONFIG_ROMKERNEL) := rom MODEL := $(model-y) cflags-$(CONFIG_CPU_H8300H):= -mh -ldflags-$(CONFIG_CPU_H8300H) := -mh8300helf +ldflags-$(CONFIG_CPU_H8300H) := -mh8300helf -no-warn-mismatch cflags-$(CONFIG_CPU_H8S) := -ms ldflags-$(CONFIG_CPU_H8S) := -mh8300self -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: Assembly: need add prefix for h8300 architecture.
After check binutils-2.22 source code, can pass "-no-warn-mismatch" to
'ld' to avoid this error.
I will send patch v2 for it.
:-)
On 08/27/2013 10:14 AM, Chen Gang wrote:
> On 08/26/2013 06:46 PM, Chen Gang wrote:
>>
>> If this implementation is correct, the implementation still can be
>> improved (at least, it is not quite well to hard code the architecture
>> related code in "kernel/" and "usr/" sub-directory).
>>
>> But it seems, I have no right to add or move files, so welcome any
>> members help do it.
>>
>
> Sorry, what I said above ("...have no right...") is not quite precise:
>
> it is only my current feelings, maybe misunderstand something.
> also maybe can find better fixing ways more than "add or move files".
>
>
> Thanks.
>
>> And welcome any additional suggestions or completions.
>>
>> Thanks.
>>
>> On 08/26/2013 06:42 PM, Chen Gang wrote:
>>> Need add related prefix for h8300, or can not pass compiling by the
>>> latest linker.
>>>
>>> The related error (allmodconfig for h8300):
>>>
>>> /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file
>>> `usr/initramfs_data.o' is incompatible with h8300h output
>>> /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file
>>> `kernel/modsign_certificate.o' is incompatible with h8300h output
>>>
>>> The cross-compiler's information:
>>>
>>> [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-ld -v
>>> GNU ld (GNU Binutils) 2.22
>>> [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-as -v
>>> GNU assembler version 2.22 (h8300-gchen-elf) using BFD version (GNU
>>> Binutils) 2.22
>>>
>>> [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc
>>>
>>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.8.0/lto-wrapper
>>> Target: h8300-gchen-elf
>>> Configured with: ../gcc-4.8.0/configure --target=h8300-gchen-elf
>>> --without-header --disable-nls --enable-language=c --disable-threads
>>> --disable-shared --enable-werror=no
>>> Thread model: single
>>> gcc version 4.8.0 (GCC)
>>>
>>>
>>> Signed-off-by: Chen Gang
>>> ---
>>> kernel/modsign_certificate.S |7 +++
>>> usr/initramfs_data.S |7 +++
>>> 2 files changed, 14 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S
>>> index 4a9a86d..d24acac 100644
>>> --- a/kernel/modsign_certificate.S
>>> +++ b/kernel/modsign_certificate.S
>>> @@ -1,5 +1,12 @@
>>> #include
>>>
>>> +#if defined(CONFIG_CPU_H8300H)
>>> + .h8300h
>>> +#endif
>>> +#if defined(CONFIG_CPU_H8S)
>>> + .h8300s
>>> +#endif
>>> +
>>> #define GLOBAL(name) \
>>> .globl VMLINUX_SYMBOL(name);\
>>> VMLINUX_SYMBOL(name):
>>> diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S
>>> index c14322d..6a6c106 100644
>>> --- a/usr/initramfs_data.S
>>> +++ b/usr/initramfs_data.S
>>> @@ -24,6 +24,13 @@
>>> #include
>>> #include
>>>
>>> +#if defined(CONFIG_CPU_H8300H)
>>> + .h8300h
>>> +#endif
>>> +#if defined(CONFIG_CPU_H8S)
>>> + .h8300s
>>> +#endif
>>> +
>>> .section .init.ramfs,"a"
>>> __irf_start:
>>> .incbin __stringify(INITRAMFS_IMAGE)
>>>
>>
>>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
On Friday 23 August 2013 04:47 AM, Luck, Tony wrote: <1>[ 383.209057] RIP [] sysrq_handle_crash+0x16/0x20 <4>[ 383.209057] RSP <4>[ 383.209057] CR2: <4>[ 383.209057] ---[ end trace 04a1cddad37b4b33 ]--- <3>[ 383.209057] pstore: compression failed for Part 2 returned -5 <3>[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 2 <3>[ 383.209057] pstore: compression failed for Part 5 returned -5 Interesting. With ERST backend I didn't see these messages. Traces in pstore recovered files go as far as the line before the "---[ end trace 04a1cddad37b4b33 ]---" Why the difference depending on which back end is in use? But I agree that we shouldn't have these messages. They use up space in the persistent store that could be better used saving some more lines from earlier in the console log. Yeah. We can remove these messages as it will add to the space consumed. But it would be good to know why the compression failed with efivars case. Seiji, Could you let us know the efivars buffer size with which the pstore is registered when the failure occurred. Regards, Aruna -Tony ___ Linuxppc-dev mailing list linuxppc-...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [guv 00/16] [RFC] percpu: Replace __get_cpu_var uses throughout the kernel
Hi Christoph, On Fri, 23 Aug 2013 19:01:56 + Christoph Lameter wrote: > > At the end of the patchset all uses of __get_cpu_var have been removed so the > macro is removed too. However you get these to Linus, please do not do this last step until the following merge window. I can pretty much guarantee that new usages will be added between the generation of the patch set and their integration. Its also helpful (to me, at least) if these can be routed via various subsystem trees to lower the number of conflicts ... -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpgS29Sr0T1q.pgp Description: PGP signature
Re: [PATCH] f2fs: fix omitting to update inode page
On 08/26/2013 08:28 PM, Jaegeuk Kim wrote:
> The f2fs_set_link updates its parent inode number, so we should sync this to
> the inode block.
> Otherwise, the data can be lost after sudden-power-off.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/namei.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index 4e47518..9e90d31 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -447,6 +447,7 @@ static int f2fs_rename(struct inode *old_dir, struct
> dentry *old_dentry,
> else
> release_orphan_inode(sbi);
>
> + update_inode_page(old_inode):
':' --> ';'
> update_inode_page(new_inode);
> } else {
> err = f2fs_add_link(new_dentry, old_inode);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 1/3] arm: mvebu: add missing of_node_put() to fix reference leak
Add of_node_put to properly decrement the refcount when we are
done using a given node.
Signed-off-by: Jisheng Zhang
Reviewed-by: Ezequiel Garcia
---
arch/arm/mach-mvebu/armada-370-xp.c | 1 +
arch/arm/mach-mvebu/coherency.c | 8 +++-
arch/arm/mach-mvebu/platsmp.c | 1 +
arch/arm/mach-mvebu/pmsu.c | 1 +
arch/arm/mach-mvebu/system-controller.c | 1 +
5 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..8a1ae83 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -64,6 +64,7 @@ static void __init armada_370_xp_mbus_init(void)
ARMADA_370_XP_MBUS_WINS_SIZE,
of_translate_address(dn, _wins_offs),
ARMADA_370_XP_SDRAM_WINS_SIZE);
+ of_node_put(dn);
}
static void __init armada_370_xp_timer_and_clk_init(void)
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 4c24303..58adf2f 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -140,6 +140,7 @@ int __init coherency_init(void)
coherency_base = of_iomap(np, 0);
coherency_cpu_base = of_iomap(np, 1);
set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
+ of_node_put(np);
}
return 0;
@@ -147,9 +148,14 @@ int __init coherency_init(void)
static int __init coherency_late_init(void)
{
- if (of_find_matching_node(NULL, of_coherency_table))
+ struct device_node *np;
+
+ np = of_find_matching_node(NULL, of_coherency_table);
+ if (np) {
bus_register_notifier(_bus_type,
_hwcc_platform_nb);
+ of_node_put(np);
+ }
return 0;
}
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..e7edb82 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -95,6 +95,7 @@ static void __init armada_xp_smp_init_cpus(void)
panic("No 'cpus' node found\n");
ncores = of_get_child_count(np);
+ of_node_put(np);
if (ncores == 0 || ncores > ARMADA_XP_MAX_CPUS)
panic("Invalid number of CPUs in DT\n");
diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
index 3cc4bef..27fc4f0 100644
--- a/arch/arm/mach-mvebu/pmsu.c
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -67,6 +67,7 @@ int __init armada_370_xp_pmsu_init(void)
pr_info("Initializing Power Management Service Unit\n");
pmsu_mp_base = of_iomap(np, 0);
pmsu_reset_base = of_iomap(np, 1);
+ of_node_put(np);
}
return 0;
diff --git a/arch/arm/mach-mvebu/system-controller.c
b/arch/arm/mach-mvebu/system-controller.c
index f875124..5175083c 100644
--- a/arch/arm/mach-mvebu/system-controller.c
+++ b/arch/arm/mach-mvebu/system-controller.c
@@ -98,6 +98,7 @@ static int __init mvebu_system_controller_init(void)
BUG_ON(!match);
system_controller_base = of_iomap(np, 0);
mvebu_sc = (struct mvebu_system_controller *)match->data;
+ of_node_put(np);
}
return 0;
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 0/3] arm: mvebu: fix resource leak
These patches try to fix resource leak by adding missing of_node_put(), iounmap or using devm_ioremap_resource() if available. v5: - rebase against mvebu/fixes-non-critical v4: - re-generate since Ezequiel's patches add DT support to the mvebu-mbus driver v3: - remove the clk patch since it's already taken by Mike - Add more commit log as suggested by Ezequiel Garcia v2: - use devm_ioremap_resource() as suggested by Ezequiel Garcia - use gates_out instead of bail_out as suggested by Mike Turquette Jisheng Zhang (3): arm: mvebu: add missing of_node_put() to fix reference leak bus: mvebu: add missing of_node_put() to fix reference leak pinctrl: mvebu: Convert to use devm_ioremap_resource arch/arm/mach-mvebu/armada-370-xp.c | 1 + arch/arm/mach-mvebu/coherency.c | 8 +++- arch/arm/mach-mvebu/platsmp.c | 1 + arch/arm/mach-mvebu/pmsu.c | 1 + arch/arm/mach-mvebu/system-controller.c | 1 + drivers/bus/mvebu-mbus.c| 6 +- drivers/pinctrl/mvebu/pinctrl-mvebu.c | 11 +-- 7 files changed, 21 insertions(+), 8 deletions(-) -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5 3/3] pinctrl: mvebu: Convert to use devm_ioremap_resource
The resource mapped by of_iomap() isn't unmapped in error path. This
patch fix the resource leakage by using devm_ioremap_resource() instead
of of_iomap().
Signed-off-by: Jisheng Zhang
Reviewed-by: Ezequiel Garcia
Acked-by: Jason Cooper
---
drivers/pinctrl/mvebu/pinctrl-mvebu.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index bb7ddb1..1caa45f 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -579,7 +579,7 @@ static int mvebu_pinctrl_build_functions(struct
platform_device *pdev,
int mvebu_pinctrl_probe(struct platform_device *pdev)
{
struct mvebu_pinctrl_soc_info *soc = dev_get_platdata(>dev);
- struct device_node *np = pdev->dev.of_node;
+ struct resource *res;
struct mvebu_pinctrl *pctl;
void __iomem *base;
struct pinctrl_pin_desc *pdesc;
@@ -591,11 +591,10 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
return -EINVAL;
}
- base = of_iomap(np, 0);
- if (!base) {
- dev_err(>dev, "unable to get base address\n");
- return -ENODEV;
- }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
pctl = devm_kzalloc(>dev, sizeof(struct mvebu_pinctrl),
GFP_KERNEL);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 2/3] bus: mvebu: add missing of_node_put() to fix reference leak
Add of_node_put to properly decrement the refcount when we are
done using a given node.
Signed-off-by: Jisheng Zhang
Reviewed-by: Ezequiel Garcia
---
drivers/bus/mvebu-mbus.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..20da90f 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -837,6 +837,7 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
{
struct mvebu_mbus_state *mbus = _state;
const struct of_device_id *of_id;
+ struct device_node *np;
int win;
for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
@@ -860,8 +861,11 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
return -ENOMEM;
}
- if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric"))
+ np = of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric");
+ if (np) {
mbus->hw_io_coherency = 1;
+ of_node_put(np);
+ }
for (win = 0; win < mbus->soc->num_wins; win++)
mvebu_mbus_disable_window(mbus, win);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the tree
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
net/mac80211/ibss.c between commit 75a423f493ff ("mac80211: ibss: fix
ignored channel parameter") from the wireless tree and commit
d51b70ff5122 ("mac80211: move ibss presp generation in own function")
from the wireless-next tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/mac80211/ibss.c
index cb73baf,74de0f1..000
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@@ -246,6 -191,90 +191,93 @@@ ieee80211_ibss_build_presp(struct ieee8
presp->head_len = pos - presp->head;
if (WARN_ON(presp->head_len > frame_len))
+ goto error;
+
+ return presp;
+ error:
+ kfree(presp);
+ return NULL;
+ }
+
+ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
+ const u8 *bssid, const int beacon_int,
-struct ieee80211_channel *chan,
++struct cfg80211_chan_def *req_chandef,
+ const u32 basic_rates,
+ const u16 capability, u64 tsf,
+ bool creator)
+ {
+ struct ieee80211_if_ibss *ifibss = >u.ibss;
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_supported_band *sband;
+ struct ieee80211_mgmt *mgmt;
+ struct cfg80211_bss *bss;
+ u32 bss_change;
+ struct cfg80211_chan_def chandef;
++ struct ieee80211_channel *chan;
+ struct beacon_data *presp;
+ enum nl80211_bss_scan_width scan_width;
+ bool have_higher_than_11mbit;
+
+ sdata_assert_lock(sdata);
+
+ /* Reset own TSF to allow time synchronization work. */
+ drv_reset_tsf(local, sdata);
+
+ if (!ether_addr_equal(ifibss->bssid, bssid))
+ sta_info_flush(sdata);
+
+ /* if merging, indicate to driver that we leave the old IBSS */
+ if (sdata->vif.bss_conf.ibss_joined) {
+ sdata->vif.bss_conf.ibss_joined = false;
+ sdata->vif.bss_conf.ibss_creator = false;
+ sdata->vif.bss_conf.enable_beacon = false;
+ netif_carrier_off(sdata->dev);
+ ieee80211_bss_info_change_notify(sdata,
+BSS_CHANGED_IBSS |
+BSS_CHANGED_BEACON_ENABLED);
+ }
+
+ presp = rcu_dereference_protected(ifibss->presp,
+ lockdep_is_held(>wdev.mtx));
+ rcu_assign_pointer(ifibss->presp, NULL);
+ if (presp)
+ kfree_rcu(presp, rcu_head);
+
+ sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
+
- chandef = ifibss->chandef;
++ /* make a copy of the chandef, it could be modified below. */
++ chandef = *req_chandef;
++ chan = chandef.chan;
+ if (!cfg80211_reg_can_beacon(local->hw.wiphy, )) {
+ if (chandef.width == NL80211_CHAN_WIDTH_5 ||
+ chandef.width == NL80211_CHAN_WIDTH_10 ||
+ chandef.width == NL80211_CHAN_WIDTH_20_NOHT ||
+ chandef.width == NL80211_CHAN_WIDTH_20) {
+ sdata_info(sdata,
+ "Failed to join IBSS, beacons forbidden\n");
+ return;
+ }
+ chandef.width = NL80211_CHAN_WIDTH_20;
+ chandef.center_freq1 = chan->center_freq;
+ }
+
+ ieee80211_vif_release_channel(sdata);
+ if (ieee80211_vif_use_channel(sdata, ,
+ ifibss->fixed_channel ?
+ IEEE80211_CHANCTX_SHARED :
+ IEEE80211_CHANCTX_EXCLUSIVE)) {
+ sdata_info(sdata, "Failed to join IBSS, no channel context\n");
+ return;
+ }
+
+ memcpy(ifibss->bssid, bssid, ETH_ALEN);
+
+ sband = local->hw.wiphy->bands[chan->band];
+
+ presp = ieee80211_ibss_build_presp(sdata, beacon_int, basic_rates,
+ capability, tsf, ,
+ _higher_than_11mbit);
+ if (!presp)
return;
rcu_assign_pointer(ifibss->presp, presp);
pgpsQyonlX3C7.pgp
Description: PGP signature
Re: [ 00/74] 3.10.10-stable review
On 08/26/2013 06:07 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.10 release. There are 74 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Aug 29 01:03:56 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.10-rc1.gz and the diffstat can be found below. Cross build results: total: 85 pass: 85 fail: 0 Compared to 3.10.8: total: 76 pass: 76 fail: 0 qemu tests: arm, microblaze, mips, mips64, ppc, x86, x86_64: pass (boot to login prompt) Note that the arm qemu test now passes because I found a workaround for the bug causing the failure observed with the previous release, not because the bug was fixed. More builds, more platforms tested, still no failures. Results look good. Details: http://server.roeck-us.net:8010/builders Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
On Tue, 2013-08-27 at 14:19 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote: > > > Gleb, any chance you can put this (and the next one) into a tree to > > > "lock in" the numbers ? > > > > > Applied it. Sorry for slow response, was on vocation and still go > > through the email backlog. > > Thanks. Since it's not in a topic branch that I can pull, I'm going to > just cherry-pick them. However, they are in your "queue" branch, not > "next" branch. Should I still assume this is a stable branch and that > the numbers aren't going to change ? Oh and Alexey mentions that there are two capabilities and you only applied one :-) 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/
Re: [ 00/13] 3.4.60-stable review
On 08/26/2013 06:08 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.60 release. There are 13 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Aug 29 01:03:03 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.60-rc1.gz and the diffstat can be found below. Cross build results: total: 75 pass: 73 fail: 2 Compared to 3.4.59: total: 69 pass: 67 fail: 2 qemu tests: mips, mips64, ppc, x86, x86_64: pass (boot to login prompt) arm: skipped More builds, more platforms tested, still only two failures. Results look good. Details: http://server.roeck-us.net:8010/builders Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote: > > Gleb, any chance you can put this (and the next one) into a tree to > > "lock in" the numbers ? > > > Applied it. Sorry for slow response, was on vocation and still go > through the email backlog. Thanks. Since it's not in a topic branch that I can pull, I'm going to just cherry-pick them. However, they are in your "queue" branch, not "next" branch. Should I still assume this is a stable branch and that the numbers aren't going to change ? 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/
Re: [ 0/9] 3.0.94-stable review
On 08/26/2013 06:04 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.0.94 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Aug 29 01:02:44 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.94-rc1.gz and the diffstat can be found below. Cross build results: total: 70 pass: 61 fail: 9 Compared to 3.0.92: total: 65 pass: 57 fail: 8 qemu tests: ppc, x86, x86_64: pass (boot to login prompt) arm, mips, mips64: skipped Additional build failure is due to added build. Results look good. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] h8300: include: asm: Kbuild: add gpio.h for pass compiling
On 08/26/2013 06:59 PM, Chen Gang wrote:
> On 08/26/2013 06:21 PM, Geert Uytterhoeven wrote:
>> On Mon, Aug 26, 2013 at 12:16 PM, Chen Gang wrote:
>>> Need add default "gpio.h" for h8300, or can not pass compiling.
>>>
>>> The related error (allmodconfig for h8300):
>>>
>>> arch/h8300/kernel/h8300_ksyms.c:17:22: fatal error: asm/gpio.h: No such
>>> file or directory
>>>#include
>>> ^
>>
>> I this include needed at all? Perhaps it can just be removed?
>>
>
> Pardon ? Do you mean, only removing it will be OK ?
>
>>> Signed-off-by: Chen Gang
>>> ---
>>> arch/h8300/include/asm/Kbuild |1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/h8300/include/asm/Kbuild b/arch/h8300/include/asm/Kbuild
>>> index 8ada3cf..4c627aa 100644
>>> --- a/arch/h8300/include/asm/Kbuild
>>> +++ b/arch/h8300/include/asm/Kbuild
>>> @@ -1,6 +1,7 @@
>>>
>>> generic-y += clkdev.h
>>> generic-y += exec.h
>>> +generic-y += gpio.h
>>> generic-y += linkage.h
>>> generic-y += mmu.h
>>> generic-y += module.h
>>
>> The only gpio-related exports in arch/h8300/kernel/h8300_ksyms.c are:
>>
>> EXPORT_SYMBOL(h8300_reserved_gpio);
>> EXPORT_SYMBOL(h8300_free_gpio);
>> EXPORT_SYMBOL(h8300_set_gpio_dir);
>>
>> and these are definitely not provided by asm-generic/gpio.h.
>>
>
> Yeah, I will try to remove "#include " to see whether can
> pass compiling, tomorrow. :-)
>
> And now, I feel (just guess), it will not, for h8300 really need gpio
> (it has "gpio-internal.h"), commonly it will need "asm/gpio.h" too.
>
> Tomorrow, I will try to prove whether my guess is correct or not. ;-).
>
After reading the related code (search "gpio.h" in root source tree),
it seems what you said is correct, my guess is incorrect. :-(
Hmm... but better to get final conclusion after finish allmodconfig
compiling.
Now, I am compiling, and excuse me, I can not finish today because of
some issues (mainly for 'gcc 4.8.0', part for 'ld 2.22', and part for
kernel), I will 'process' them, hope can finish before 2013-08-31.
Welcome additional suggestions or completions.
Thanks.
>
> Thanks.
>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>> ge...@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like
>> that.
>> -- Linus Torvalds
>>
>>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the wireless tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/mac80211/ibss.c between commit 75a423f493ff ("mac80211: ibss: fix
ignored channel parameter") from the wireless tree and commit
7ca15a0ae865 ("mac80211: allow scanning for 5/10 MHz channels in IBSS")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/mac80211/ibss.c
index 2d45643,e08387c..000
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@@ -48,12 -49,13 +49,14 @@@ static void __ieee80211_sta_join_ibss(s
u8 *pos;
struct ieee80211_supported_band *sband;
struct cfg80211_bss *bss;
- u32 bss_change;
- u8 supp_rates[IEEE80211_MAX_SUPP_RATES];
+ u32 bss_change, rate_flags, rates = 0, rates_added = 0;
struct cfg80211_chan_def chandef;
+ struct ieee80211_channel *chan;
+ enum nl80211_bss_scan_width scan_width;
+ bool have_higher_than_11mbit = false;
struct beacon_data *presp;
int frame_len;
+ int shift;
sdata_assert_lock(sdata);
@@@ -82,10 -84,16 +85,18 @@@
sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
- chandef = ifibss->chandef;
+ /* make a copy of the chandef, it could be modified below. */
+ chandef = *req_chandef;
+ chan = chandef.chan;
if (!cfg80211_reg_can_beacon(local->hw.wiphy, )) {
+ if (chandef.width == NL80211_CHAN_WIDTH_5 ||
+ chandef.width == NL80211_CHAN_WIDTH_10 ||
+ chandef.width == NL80211_CHAN_WIDTH_20_NOHT ||
+ chandef.width == NL80211_CHAN_WIDTH_20) {
+ sdata_info(sdata,
+ "Failed to join IBSS, beacons forbidden\n");
+ return;
+ }
chandef.width = NL80211_CHAN_WIDTH_20;
chandef.center_freq1 = chan->center_freq;
}
@@@ -267,35 -310,18 +314,39 @@@ static void ieee80211_sta_join_ibss(str
int i, j;
u16 beacon_int = cbss->beacon_interval;
const struct cfg80211_bss_ies *ies;
+ enum nl80211_channel_type chan_type;
u64 tsf;
+ u32 rate_flags;
+ int shift;
sdata_assert_lock(sdata);
if (beacon_int < 10)
beacon_int = 10;
+ switch (sdata->u.ibss.chandef.width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_20:
+ case NL80211_CHAN_WIDTH_40:
+ chan_type = cfg80211_get_chandef_type(>u.ibss.chandef);
+ cfg80211_chandef_create(, cbss->channel, chan_type);
+ break;
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
+ cfg80211_chandef_create(, cbss->channel,
+ NL80211_CHAN_WIDTH_20_NOHT);
+ chandef.width = sdata->u.ibss.chandef.width;
+ break;
+ default:
+ /* fall back to 20 MHz for unsupported modes */
+ cfg80211_chandef_create(, cbss->channel,
+ NL80211_CHAN_WIDTH_20_NOHT);
+ break;
+ }
+
sband = sdata->local->hw.wiphy->bands[cbss->channel->band];
+ rate_flags = ieee80211_chandef_rate_flags(>u.ibss.chandef);
+ shift = ieee80211_vif_get_shift(>vif);
basic_rates = 0;
pgpvvNP1cm1CV.pgp
Description: PGP signature
Re: [PATCH 4/4] Documentation: Add device tree bindings for Freescale FTM PWM
On 08/26/2013 09:48 PM, Xiubo Li-B47053 wrote: > Hi Stephen, > > >> Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for >> Freescale FTM PWM >> >> On 08/25/2013 11:35 PM, Xiubo Li-B47053 wrote: Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for >> ... > Why do you need to manipulate the pinctrl to en/disable a channel? This is because in Vybrid VF610 TOWER board, there are 4 leds, and each led's one point(diode's positive pole) is connected to 3.3V, and the other point is connected to pwm's one channel. When the 4 pinctrls are configured as enable at the same time, the 4 pinctrls is low valtage, and the 4 leds will be lighted up as default, then when you enable/disable one led will effects others. These pinctrls are belong to pwm, and I don't think led or other customer could control them directly. So, here I authorize the 4 pinctrls to each channel controls. >>> " >>> For the reason above, I have to control the pinctrls separately. >>> >>> If all the pinctrls set as default state, the 8 pinctrls must be >> controlled together. >>> And the 4 leds will all be lighted up as default and will influence >> each other. >> >> Sorry, that still doesn't make much sense. ... What may help here is to show the exact content you expect the various en/dis states to have, so that we can see exactly which pinctrl options get set when and why. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v7 00/10] tracing: trace event triggers
Hi, This is v7 of the trace event triggers patchset. This version mainly moves some code between patches to fix some bisectibity problems, but also adds a couple minor cleanups and variable naming changes mentioned by Masami Hiramatsu. v7: - moved find_event_file() extern declartion to patch 06. - moved helper functions from patch 02 to 03, where they're first used. - removed copies of cmd_ops fields from trigger_data and changed to use cmd_ops diretly instead. - renamed trigger_mode to trigger_type to avoid confusion with the FTRACE_EVENT_FL_TRIGGER_MODE_BIT bitflag, and fixed up usage/documentation, etc. v6: - fixed up the conflicts in trace_events.c related to the actual creation of the per-event 'trigger' files. v5: - got rid of the trigger_iterator, a vestige of the first patchset, which attempted to abstract the ftrace_iterator for triggers, and cleaned up related code simplified as a result. - replaced the void *cmd_data everywhere with ftrace_event_file *, another vestige of the initial patchset. - updated the patchset to use event_file_data() to grab the i_private ftrace_event_files where appropriate (this was a separate patch in the previous patchset, but was merged into the basic framework patch as suggested by Masami. The only interesting part about this is that it moved event_file_data() from kernel/trace/trace_events.c to kernel/trace/trace.h so it can be used in e.g. trace_events_trigger.c as well.) - add missing grab of event_mutex in event_trigger_regex_write(). - realized when making the above changes that the trigger filters weren't being freed when the trigger was freed, so added a trigger_data_free() to do that. It also ensures that trigger_data won't be freed until nothing is using it. - added clear_event_triggers(), which clears all triggers in a trace array (and soft-disable associated with event_enable/disable events). - added a comment to ftrace_syscall_enter/exit to document the use of rcu_dereference_raw() there. v4: - made some changes to the soft-disable for syscall patch, according to Masami's suggestions. Actually, since there's now an array of ftrace_files for syscalls that can serve the same purpose, the enabled_enter/exit_syscalls bit arrays became redundant and were removed. - moved all the remaining common functions out of the traceon/traceoff patch and into the basic trigger framework patch and added comments to all the common functions. - extensively commented the event_trigger_ops and event_command ops. - made the register/unregister_command functions __init. Since that code was originally inspired by similar ftrace code, a new patch was added to do the same thing for the register/unregister of the ftrace commands (patch 10/11). - fixed the event_trigger_regex_open i_private problem noted by Masami that's currently being addressed by Oleg Nesterov's fixes for this. Note that that patchset also affects patch 8/11 (update filters for multi-buffer, since it touches event filters as well). Patch 11/11 depends on that patchset and also moves event_file_data() to trace.h.b v3: - added a new patch to the series (patch 8/9 - update event filters for multibuffer) to bring the event filters up-to-date wrt the multibuffer changes - without this patch, the same filter is applied to all buffers regardless of which instance sets it; this patch allows you to set per-instance filters as you'd expect. The one exception to this is the 'ftrace subsystem' events, which are special and retain their current behavior. - changed the syscall soft enabling to keep a per-trace-array array of trace_event_files alongside the 'enabled' bitmaps there. This keeps them in a place where they're only allocated for tracing and which I think addresses all the previous comments for that patch. v2: - removed all changes to __ftrace_event_enable_disable() (except for patch 04/11 which clears the soft_disabled bit as discussed) and created a separate trace_event_trigger_enable_disable() that calls it after setting/clearing the TRIGGER_MODE_BIT. - added a trigger_mode enum for future patches that break up the trigger calls for filtering, but that's also now used as a command id for registering/unregistering commands. - removed the enter_file/exit_file members that were added to syscall_metadata after realizing that they were unnecessary if ftrace_syscall_enter/exit() were modified to receive a pointer to the ftrace_file instead of the pointer to the trace_array in the ftrace_file. - broke up the trigger invocation into two parts so that triggers like 'stacktrace' that themselves log into the trace buffer can defer the actual trigger invocation until after the current record is closed, which is needed for the filter check that in turn determines whether the trigger gets invoked. - other minor cleanup
[PATCH v7 02/10] tracing: add basic event trigger framework
Add a 'trigger' file for each trace event, enabling 'trace event triggers' to be set for trace events. 'trace event triggers' are patterned after the existing 'ftrace function triggers' implementation except that triggers are written to per-event 'trigger' files instead of to a single file such as the 'set_ftrace_filter' used for ftrace function triggers. The implementation is meant to be entirely separate from ftrace function triggers, in order to keep the respective implementations relatively simple and to allow them to diverge. The event trigger functionality is built on top of SOFT_DISABLE functionality. It adds a TRIGGER_MODE bit to the ftrace_event_file flags which is checked when any trace event fires. Triggers set for a particular event need to be checked regardless of whether that event is actually enabled or not - getting an event to fire even if it's not enabled is what's already implemented by SOFT_DISABLE mode, so trigger mode directly reuses that. Event trigger essentially inherit the soft disable logic in __ftrace_event_enable_disable() while adding a bit of logic and trigger reference counting via tm_ref on top of that in a new trace_event_trigger_enable_disable() function. Because the base __ftrace_event_enable_disable() code now needs to be invoked from outside trace_events.c, a wrapper is also added for those usages. The triggers for an event are actually invoked via a new function, event_triggers_call(), and code is also added to invoke them for ftrace_raw_event calls as well as syscall events. The main part of the patch creates a new trace_events_trigger.c file to contain the trace event triggers implementation. The standard open, read, and release file operations are implemented here. The open() implementation sets up for the various open modes of the 'trigger' file. It creates and attaches the trigger iterator and sets up the command parser. If opened for reading set up the trigger seq_ops. The read() implementation parses the event trigger written to the 'trigger' file, looks up the trigger command, and passes it along to that event_command's func() implementation for command-specific processing. The release() implementation does whatever cleanup is needed to release the 'trigger' file, like releasing the parser and trigger iterator, etc. A couple of functions for event command registration and unregistration are added, along with a list to add them to and a mutex to protect them, as well as an (initially empty) registration function to add the set of commands that will be added by future commits, and call to it from the trace event initialization code. also added are a couple trigger-specific data structures needed for these implementations such as a trigger iterator and a struct for trigger-specific data. A couple structs consisting mostly of function meant to be implemented in command-specific ways, event_command and event_trigger_ops, are used by the generic event trigger command implementations. They're being put into trace.h alongside the other trace_event data structures and functions, in the expectation that they'll be needed in several trace_event-related files such as trace_events_trigger.c and trace_events.c. The event_command.func() function is meant to be called by the trigger parsing code in order to add a trigger instance to the corresponding event. It essentially coordinates adding a live trigger instance to the event, and arming the triggering the event. Every event_command func() implementation essentially does the same thing for any command: - choose ops - use the value of param to choose either a number or count version of event_trigger_ops specific to the command - do the register or unregister of those ops - associate a filter, if specified, with the triggering event The reg() and unreg() ops allow command-specific implementations for event_trigger_op registration and unregistration, and the get_trigger_ops() op allows command-specific event_trigger_ops selection to be parameterized. When a trigger instance is added, the reg() op essentially adds that trigger to the triggering event and arms it, while unreg() does the opposite. The set_filter() function is used to associate a filter with the trigger - if the command doesn't specify a set_filter() implementation, the command will ignore filters. Each command has an associated trigger_mode, which serves double duty, both as a unique identifier for the command as well as a value that can be used for setting a trigger mode bit during trigger invocation. The signature of func() adds a pointer to the event_command struct, used to invoke those functions, along with a command_data param that can be passed to the reg/unreg functions. This allows func() implementations to use command-specific blobs and supports code re-use. The event_trigger_ops.func() command corrsponds to the trigger 'probe' function that gets called when the triggering event is actually invoked. The other
[PATCH v7 03/10] tracing: add 'traceon' and 'traceoff' event trigger commands
Add 'traceon' and 'traceoff' ftrace_func_command commands. traceon
and traceoff event triggers are added by the user via these commands
in a similar way and using practically the same syntax as the
analagous 'traceon' and 'traceoff' ftrace function commands, but
instead of writing to the set_ftrace_filter file, the traceon and
traceoff triggers are written to the per-event 'trigger' files:
echo 'traceon' > .../tracing/events/somesys/someevent/trigger
echo 'traceoff' > .../tracing/events/somesys/someevent/trigger
The above command will turn tracing on or off whenever someevent is
hit.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'traceon:N' > .../tracing/events/somesys/someevent/trigger
echo 'traceoff:N' > .../tracing/events/somesys/someevent/trigger
Where N is the number of times the command will be invoked.
The above commands will will turn tracing on or off whenever someevent
is hit, but only N times.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 1 +
kernel/trace/trace_events_trigger.c | 182
2 files changed, 183 insertions(+)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 0765d3d..4c8f7c1 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -318,6 +318,7 @@ struct ftrace_event_file {
enum trigger_mode {
TM_NONE = (0),
+ TM_TRACE_ONOFF = (1 << 0),
};
extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index 7a52109..d5a10ed 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -564,7 +564,189 @@ event_trigger_callback(struct event_command *cmd_ops,
goto out;
}
+static void
+traceon_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (tracing_is_on())
+ return;
+
+ tracing_on();
+}
+
+static void
+traceon_count_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (!data->count)
+ return;
+
+ if (data->count != -1)
+ (data->count)--;
+
+ traceon_trigger(_data);
+}
+
+static void
+traceoff_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (!tracing_is_on())
+ return;
+
+ tracing_off();
+}
+
+static void
+traceoff_count_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (!data->count)
+ return;
+
+ if (data->count != -1)
+ (data->count)--;
+
+ traceoff_trigger(_data);
+}
+
+static int
+traceon_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+ void *_data)
+{
+ struct event_trigger_data *data = _data;
+
+ return event_trigger_print("traceon", m, (void *)data->count,
+ data->filter_str);
+}
+
+static int
+traceoff_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+ void *_data)
+{
+ struct event_trigger_data *data = _data;
+
+ return event_trigger_print("traceoff", m, (void *)data->count,
+ data->filter_str);
+}
+
+static struct event_trigger_ops traceon_trigger_ops = {
+ .func = traceon_trigger,
+ .print = traceon_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops traceon_count_trigger_ops = {
+ .func = traceon_count_trigger,
+ .print = traceon_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops traceoff_trigger_ops = {
+ .func = traceoff_trigger,
+ .print = traceoff_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops traceoff_count_trigger_ops = {
+ .func = traceoff_count_trigger,
+ .print = traceoff_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
Re: [RFC PATCH 2/3] pinctrl: at91: add support for generic pinconf
On 08/26/2013 11:17 AM, boris brezillon wrote: > On 26/08/2013 18:53, Stephen Warren wrote: >> On 08/24/2013 03:37 PM, Boris BREZILLON wrote: >>> Add support for generic pin configuration to pinctrl-at91 driver. >>> diff --git >>> a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt >>> b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt >>> Required properties for iomux controller: >>> -- compatible: "atmel,at91rm9200-pinctrl" >>> +- compatible: "atmel,at91rm9200-pinctrl" or "atmel,at91sam9x5-pinctrl". >> You seem to also be adding a second chip name to the list here, which is >> more than the patch subject/description imply you're doing... > > This is an update of the documentation: > "atmel,at91sam9x5-pinctrl" compatible is already used in the pinctrl > driver but the documention > was not updated. > > But I agree, this should not be part of this series. > >>> + Add "generic-pinconf" to the compatible string list to use the >>> generic pin >>> + configuration syntax. >> "generic-pinconf" is too generic of a compatible value for this binding >> to define. >> >> Instead, I think you want to either: >> >> a) >> >> Use compatible="atmel,at91rm9200-pinctrl" for the old binding, >> use compatible="atmel,at91rm9200-pinctrl-generic" for the new binding >> >> or: >> >> b) >> >> Define Boolean property atmel,generic-pinconf (perhaps a better name >> could be chosen?). If it's not present, parse the node assuming the old >> binding. If it is present, parse the node assuming the new binding. >> > Okay. > > I thought this property string could be generic as it may concern other > drivers too > (in order to keep compatibility with old dt ABI and add support the > generic pinconf binding). > > Anyway, I prefer the first proposition. > > pinctrl single driver is already using these names: > > |compatible = "pinctrl-single" for non generic pinconf binding > ||compatible = "pinconf-single" ||for generic pinconf binding| > > So I think we should use something similar: > > |compatible = "atmel,at91xx-pinctrl" for non generic pinconf binding > ||compatible = "|||atmel,at91xx-|pinconf" ||for generic pinconf binding| > > What do you think ? Hmmm. It is a little odd to switch out the compatible value and invent a new binding for the same HW. Isn't it possible to define both sets of properties in the binding, and have drivers look for either? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v7 07/10] tracing: add and use generic set_trigger_filter() implementation
Add a generic event_command.set_trigger_filter() op implementation and
have the current set of trigger commands use it - this essentially
gives them all support for filters.
Syntactically, filters are supported by adding 'if ' just
after the command, in which case only events matching the filter will
invoke the trigger. For example, to add a filter to an
enable/disable_event command:
echo 'enable_event:system:event if common_pid == 999' > \
.../othersys/otherevent/trigger
The above command will only enable the system:event event if the
common_pid field in the othersys:otherevent event is 999.
As another example, to add a filter to a stacktrace command:
echo 'stacktrace if common_pid == 999' > \
.../somesys/someevent/trigger
The above command will only trigger a stacktrace if the common_pid
field in the event is 999.
The filter syntax is the same as that described in the 'Event
filtering' section of Documentation/trace/events.txt.
Because triggers can now use filters, the trigger-invoking logic needs
to be moved - for ftrace_raw_event_calls, trigger invocation now needs
to happen after the { assign; } part of the call.
Also, because triggers need to be invoked even for soft-disabled
events, the SOFT_DISABLED check and return needs to be moved from the
top of the call to a point following the trigger check, which means
that soft-disabled events actually get discarded instead of simply
skipped. There's still a SOFT_DISABLED-only check at the top of the
function, so when an event is soft disabled but not because of the
presence of a trigger, the original SOFT_DISABLED behavior remains
unchanged.
There's also a bit of trickiness in that some triggers need to avoid
being invoked while an event is currently in the process of being
logged, since the trigger may itself log data into the trace buffer.
Thus we make sure the current event is committed before invoking those
triggers. To do that, we split the trigger invocation in two - the
first part (event_triggers_call()) checks the filter using the current
trace record; if a command has the post_trigger flag set, it sets a
bit for itself in the return value, otherwise it directly invoks the
trigger. Once all commands have been either invoked or set their
return flag, event_triggers_call() returns. The current record is
then either committed or discarded; if any commands have deferred
their triggers, those commands are finally invoked following the close
of the current event by event_triggers_post_call().
The syscall event invocation code is also changed in analogous ways.
Because event triggers need to be able to create and free filters,
this also adds a couple external wrappers for the existing
create_filter and free_filter functions, which are too generic to be
made extern functions themselves.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 6 ++-
include/trace/ftrace.h | 45 +++-
kernel/trace/trace.h| 4 ++
kernel/trace/trace_events_filter.c | 13 +
kernel/trace/trace_events_trigger.c | 103 ++--
kernel/trace/trace_syscalls.c | 36 +
6 files changed, 180 insertions(+), 27 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 4ace984..5f14544 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -330,7 +330,11 @@ extern int filter_current_check_discard(struct ring_buffer
*buffer,
struct ftrace_event_call *call,
void *rec,
struct ring_buffer_event *event);
-extern void event_triggers_call(struct ftrace_event_file *file);
+extern enum trigger_mode event_triggers_call(struct ftrace_event_file *file,
+void *rec);
+extern void event_triggers_post_call(struct ftrace_event_file *file,
+enum trigger_mode tm);
+
enum {
FILTER_OTHER = 0,
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 326ba32..be913f1 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -412,13 +412,15 @@ static inline notrace int ftrace_get_offsets_##call(
\
* struct ftrace_data_offsets_ __maybe_unused __data_offsets;
* struct ring_buffer_event *event;
* struct ftrace_raw_ *entry; <-- defined in stage 1
+ * enum trigger_mode __tm = TM_NONE;
* struct ring_buffer *buffer;
* unsigned long irq_flags;
* int __data_size;
* int pc;
*
- * if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
- * _file->flags))
+ * if ((ftrace_file->flags & (FTRACE_EVENT_FL_SOFT_DISABLED |
+ * FTRACE_EVENT_FL_TRIGGER_MODE)) ==
+ * FTRACE_EVENT_FL_SOFT_DISABLED)
* return;
*
* local_save_flags(irq_flags);
@@ -437,9
[PATCH v7 05/10] tracing: add 'stacktrace' event trigger command
Add 'stacktrace' ftrace_func_command. stacktrace event triggers are
added by the user via this command in a similar way and using
practically the same syntax as the analogous 'stacktrace' ftrace
function command, but instead of writing to the set_ftrace_filter
file, the stacktrace event trigger is written to the per-event
'trigger' files:
echo 'stacktrace' > .../tracing/events/somesys/someevent/trigger
The above command will turn on stacktraces for someevent i.e. whenever
someevent is hit, a stacktrace will be logged.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'stacktrace:N' > .../tracing/events/somesys/someevent/trigger
Where N is the number of times the command will be invoked.
The above command will log N stacktraces for someevent i.e. whenever
someevent is hit N times, a stacktrace will be logged.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 1 +
kernel/trace/trace_events_trigger.c | 102
2 files changed, 103 insertions(+)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 5c223e3..850f201 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -320,6 +320,7 @@ enum trigger_mode {
TM_NONE = (0),
TM_TRACE_ONOFF = (1 << 0),
TM_SNAPSHOT = (1 << 1),
+ TM_STACKTRACE = (1 << 2),
};
extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index 342a6dc..42c96de 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -793,6 +793,97 @@ static struct event_command trigger_snapshot_cmd = {
.get_trigger_ops= snapshot_get_trigger_ops,
};
+/*
+ * Skip 4:
+ * ftrace_stacktrace()
+ * function_trace_probe_call()
+ * ftrace_ops_list_func()
+ * ftrace_call()
+ */
+#define STACK_SKIP 4
+
+static void
+stacktrace_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ trace_dump_stack(STACK_SKIP);
+}
+
+static void
+stacktrace_count_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (!data->count)
+ return;
+
+ if (data->count != -1)
+ (data->count)--;
+
+ stacktrace_trigger(_data);
+}
+
+static int
+stacktrace_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+void *_data)
+{
+ struct event_trigger_data *data = _data;
+
+ return event_trigger_print("stacktrace", m, (void *)data->count,
+ data->filter_str);
+}
+
+static int stacktrace_register_trigger(char *glob,
+ struct event_trigger_ops *ops,
+ void *trigger_data,
+ struct ftrace_event_file *file)
+{
+ struct event_trigger_data *data = trigger_data;
+
+ data->post_trigger = true;
+
+ return register_trigger(glob, ops, trigger_data, file);
+}
+
+static struct event_trigger_ops stacktrace_trigger_ops = {
+ .func = stacktrace_trigger,
+ .print = stacktrace_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops stacktrace_count_trigger_ops = {
+ .func = stacktrace_count_trigger,
+ .print = stacktrace_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops *
+stacktrace_get_trigger_ops(char *cmd, char *param)
+{
+ return param ? _count_trigger_ops : _trigger_ops;
+}
+
+static struct event_command trigger_stacktrace_cmd = {
+ .name = "stacktrace",
+ .trigger_mode = TM_STACKTRACE,
+ .post_trigger = true,
+ .func = event_trigger_callback,
+ .reg= register_trigger,
+ .unreg = unregister_trigger,
+ .get_trigger_ops= stacktrace_get_trigger_ops,
+};
+
static __init void unregister_trigger_traceon_traceoff_cmds(void)
{
unregister_event_command(_traceon_cmd,
@@ -837,5 +928,16 @@ __init int register_trigger_cmds(void)
return ret;
}
+ ret = register_event_command(_stacktrace_cmd,
+ _commands,
+ _cmd_mutex);
+ if (WARN_ON(ret < 0)) {
+
[PATCH v7 06/10] tracing: add 'enable_event' and 'disable_event' event trigger commands
Add 'enable_event' and 'disable_event' event_command commands.
enable_event and disable_event event triggers are added by the user
via these commands in a similar way and using practically the same
syntax as the analagous 'enable_event' and 'disable_event' ftrace
function commands, but instead of writing to the set_ftrace_filter
file, the enable_event and disable_event triggers are written to the
per-event 'trigger' files:
echo 'enable_event:system:event' > .../othersys/otherevent/trigger
echo 'disable_event:system:event' > .../othersys/otherevent/trigger
The above commands will enable or disable the 'system:event' trace
events whenever the othersys:otherevent events are hit.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'enable_event:system:event:N' > .../othersys/otherevent/trigger
echo 'disable_event:system:event:N' > .../othersys/otherevent/trigger
Where N is the number of times the command will be invoked.
The above commands will will enable or disable the 'system:event'
trace events whenever the othersys:otherevent events are hit, but only
N times.
This also makes the find_event_file() helper function extern, since
it's useful to use from other places, such as the event triggers code,
so make it accessible.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 1 +
kernel/trace/trace_events.c | 2 +-
kernel/trace/trace_events_trigger.c | 364
3 files changed, 366 insertions(+), 1 deletion(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 850f201..4ace984 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -321,6 +321,7 @@ enum trigger_mode {
TM_TRACE_ONOFF = (1 << 0),
TM_SNAPSHOT = (1 << 1),
TM_STACKTRACE = (1 << 2),
+ TM_EVENT_ENABLE = (1 << 3),
};
extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 7d8eb8a..25b2c86 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1860,7 +1860,7 @@ struct event_probe_data {
boolenable;
};
-static struct ftrace_event_file *
+struct ftrace_event_file *
find_event_file(struct trace_array *tr, const char *system, const char *event)
{
struct ftrace_event_file *file;
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index 42c96de..94074d8 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -894,6 +894,358 @@ static __init void
unregister_trigger_traceon_traceoff_cmds(void)
_cmd_mutex);
}
+/* Avoid typos */
+#define ENABLE_EVENT_STR "enable_event"
+#define DISABLE_EVENT_STR "disable_event"
+
+static void
+event_enable_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (data->enable)
+ clear_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
>file->flags);
+ else
+ set_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, >file->flags);
+}
+
+static void
+event_enable_count_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (!data->count)
+ return;
+
+ /* Skip if the event is in a state we want to switch to */
+ if (data->enable == !(data->file->flags &
FTRACE_EVENT_FL_SOFT_DISABLED))
+ return;
+
+ if (data->count != -1)
+ (data->count)--;
+
+ event_enable_trigger(_data);
+}
+
+static int
+event_enable_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+ void *_data)
+{
+ struct event_trigger_data *data = _data;
+
+ seq_printf(m, "%s:%s:%s",
+ data->enable ? ENABLE_EVENT_STR : DISABLE_EVENT_STR,
+ data->file->event_call->class->system,
+ data->file->event_call->name);
+
+ if (data->count == -1)
+ seq_puts(m, ":unlimited");
+ else
+ seq_printf(m, ":count=%ld", data->count);
+
+ if (data->filter_str)
+ seq_printf(m, " if %s\n", data->filter_str);
+ else
+ seq_puts(m, "\n");
+
+ return 0;
+}
+
+static void
+event_enable_trigger_free(struct event_trigger_ops *ops, void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (WARN_ON_ONCE(data->ref <= 0))
+ return;
+
+ data->ref--;
+ if (!data->ref) {
+ /* Remove the SOFT_MODE
[PATCH v7 09/10] tracing: add documentation for trace event triggers
Provide a basic overview of trace event triggers and document the
available trigger commands, along with a few simple examples.
Signed-off-by: Tom Zanussi
---
Documentation/trace/events.txt | 207 +
1 file changed, 207 insertions(+)
diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index 37732a2..c94435d 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -287,3 +287,210 @@ their old filters):
prev_pid == 0
# cat sched_wakeup/filter
common_pid == 0
+
+6. Event triggers
+=
+
+Trace events can be made to conditionally invoke trigger 'commands'
+which can take various forms and are described in detail below;
+examples would be enabling or disabling other trace events or invoking
+a stack trace whenever the trace event is hit. Whenever a trace event
+with attached triggers is invoked, the set of trigger commands
+associated with that event is invoked. Any given trigger can
+additionally have an event filter of the same form as described in
+section 5 (Event filtering) associated with it - the command will only
+be invoked if the event being invoked passes the associated filter.
+If no filter is associated with the trigger, it always passes.
+
+Triggers are added to and removed from a particular event by writing
+trigger expressions to the 'trigger' file for the given event.
+
+A given event can have any number of triggers associated with it,
+subject to any restrictions that individual commands may have in that
+regard.
+
+Event triggers are implemented on top of "soft" mode, which means that
+whenever a trace event has one or more triggers associated with it,
+the event is activated even if it isn't actually enabled, but is
+disabled in a "soft" mode. That is, the tracepoint will be called,
+but just will not be traced, unless of course it's actually enabled.
+This scheme allows triggers to be invoked even for events that aren't
+enabled, and also allows the current event filter implementation to be
+used for conditionally invoking triggers.
+
+The syntax for event triggers is roughly based on the syntax for
+set_ftrace_filter 'ftrace filter commands' (see the 'Filter commands'
+section of Documentation/trace/ftrace.txt), but there are major
+differences and the implementation isn't currently tied to it in any
+way, so beware about making generalizations between the two.
+
+6.1 Expression syntax
+-
+
+Triggers are added by echoing the command to the 'trigger' file:
+
+ # echo 'command[:count] [if filter]' > trigger
+
+Triggers are removed by echoing the same command but starting with '!'
+to the 'trigger' file:
+
+ # echo '!command[:count] [if filter]' > trigger
+
+The [if filter] part isn't used in matching commands when removing, so
+leaving that off in a '!' command will accomplish the same thing as
+having it in.
+
+The filter syntax is the same as that described in the 'Event
+filtering' section above.
+
+For ease of use, writing to the trigger file using '>' currently just
+adds or removes a single trigger and there's no explicit '>>' support
+('>' actually behaves like '>>') or truncation support to remove all
+triggers (you have to use '!' for each one added.)
+
+6.2 Supported trigger commands
+--
+
+The following commands are supported:
+
+- enable_event/disable_event
+
+ These commands can enable or disable another trace event whenever
+ the triggering event is hit. When these commands are registered,
+ the other trace event is activated, but disabled in a "soft" mode.
+ That is, the tracepoint will be called, but just will not be traced.
+ The event tracepoint stays in this mode as long as there's a trigger
+ in effect that can trigger it.
+
+ For example, the following trigger causes kmalloc events to be
+ traced when a read system call is entered, and the :1 at the end
+ specifies that this enablement happens only once:
+
+ # echo 'enable_event:kmem:kmalloc:1' > \
+ /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
+
+ The following trigger causes kmalloc events to stop being traced
+ when a read system call exits. This disablement happens on every
+ read system call exit:
+
+ # echo 'disable_event:kmem:kmalloc' > \
+ /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger
+
+ The format is:
+
+ enable_event::[:count]
+ disable_event::[:count]
+
+ To remove the above commands:
+
+ # echo '!enable_event:kmem:kmalloc:1' > \
+ /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
+
+ # echo '!disable_event:kmem:kmalloc' > \
+ /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger
+
+ Note that there can be any number of enable/disable_event triggers
+ per triggering event, but there can only be one trigger per
+ triggered event. e.g. sys_enter_read can have triggers enabling both
+ kmem:kmalloc and sched:sched_switch, but can't
[PATCH v7 10/10] tracing: make register/unregister_ftrace_command __init
register/unregister_ftrace_command() are only ever called from __init
functions, so can themselves be made __init.
Also make register_snapshot_cmd() __init for the same reason.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace.h | 4 ++--
kernel/trace/ftrace.c | 12 ++--
kernel/trace/trace.c | 4 ++--
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 9f15c00..6062491 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -533,11 +533,11 @@ static inline int ftrace_force_update(void) { return 0; }
static inline void ftrace_disable_daemon(void) { }
static inline void ftrace_enable_daemon(void) { }
static inline void ftrace_release_mod(struct module *mod) {}
-static inline int register_ftrace_command(struct ftrace_func_command *cmd)
+static inline __init int register_ftrace_command(struct ftrace_func_command
*cmd)
{
return -EINVAL;
}
-static inline int unregister_ftrace_command(char *cmd_name)
+static inline __init int unregister_ftrace_command(char *cmd_name)
{
return -EINVAL;
}
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index a6d098c..64f7f39 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3292,7 +3292,11 @@ void unregister_ftrace_function_probe_all(char *glob)
static LIST_HEAD(ftrace_commands);
static DEFINE_MUTEX(ftrace_cmd_mutex);
-int register_ftrace_command(struct ftrace_func_command *cmd)
+/*
+ * Currently we only register ftrace commands from __init, so mark this
+ * __init too.
+ */
+__init int register_ftrace_command(struct ftrace_func_command *cmd)
{
struct ftrace_func_command *p;
int ret = 0;
@@ -3311,7 +3315,11 @@ int register_ftrace_command(struct ftrace_func_command
*cmd)
return ret;
}
-int unregister_ftrace_command(struct ftrace_func_command *cmd)
+/*
+ * Currently we only unregister ftrace commands from __init, so mark
+ * this __init too.
+ */
+__init int unregister_ftrace_command(struct ftrace_func_command *cmd)
{
struct ftrace_func_command *p, *n;
int ret = -ENODEV;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2aabd34..4222c6a 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5458,12 +5458,12 @@ static struct ftrace_func_command ftrace_snapshot_cmd =
{
.func = ftrace_trace_snapshot_callback,
};
-static int register_snapshot_cmd(void)
+static __init int register_snapshot_cmd(void)
{
return register_ftrace_command(_snapshot_cmd);
}
#else
-static inline int register_snapshot_cmd(void) { return 0; }
+static inline __init int register_snapshot_cmd(void) { return 0; }
#endif /* defined(CONFIG_TRACER_SNAPSHOT) && defined(CONFIG_DYNAMIC_FTRACE) */
struct dentry *tracing_init_dentry_tr(struct trace_array *tr)
--
1.7.11.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 v7 08/10] tracing: update event filters for multibuffer
The trace event filters are still tied to event calls rather than
event files, which means you don't get what you'd expect when using
filters in the multibuffer case:
Before:
# echo 'count > 65536' >
/sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
# cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
count > 65536
# mkdir /sys/kernel/debug/tracing/instances/test1
# echo 'count > 4096' >
/sys/kernel/debug/tracing/instances/test1/events/syscalls/sys_enter_read/filter
# cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
count > 4096
Setting the filter in tracing/instances/test1/events shouldn't affect
the same event in tracing/events as it does above.
After:
# echo 'count > 65536' >
/sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
# cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
count > 65536
# mkdir /sys/kernel/debug/tracing/instances/test1
# echo 'count > 4096' >
/sys/kernel/debug/tracing/instances/test1/events/syscalls/sys_enter_read/filter
# cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
count > 65536
We'd like to just move the filter directly from ftrace_event_call to
ftrace_event_file, but there are a couple cases that don't yet have
multibuffer support and therefore have to continue using the current
event_call-based filters. For those cases, a new USE_CALL_FILTER bit
is added to the event_call flags, whose main purpose is to keep the
old behavioir for those cases until they can be updated with
multibuffer support; at that point, the USE_CALL_FILTER flag (and the
new associated call_filter_check_discard() function) can go away.
The multibuffer support also made filter_current_check_discard()
redundant, so this change removes that function as well and replaces
it with filter_check_discard() (or call_filter_check_discard() as
appropriate).
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h | 37 ++--
include/trace/ftrace.h | 6 +-
kernel/trace/trace.c | 18 ++--
kernel/trace/trace.h | 10 +--
kernel/trace/trace_branch.c | 2 +-
kernel/trace/trace_events.c | 26 +++---
kernel/trace/trace_events_filter.c | 168 +++
kernel/trace/trace_export.c | 2 +-
kernel/trace/trace_functions_graph.c | 4 +-
kernel/trace/trace_kprobe.c | 4 +-
kernel/trace/trace_mmiotrace.c | 4 +-
kernel/trace/trace_sched_switch.c| 4 +-
kernel/trace/trace_syscalls.c| 8 +-
kernel/trace/trace_uprobe.c | 3 +-
14 files changed, 200 insertions(+), 96 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 5f14544..908d293 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -202,6 +202,7 @@ enum {
TRACE_EVENT_FL_NO_SET_FILTER_BIT,
TRACE_EVENT_FL_IGNORE_ENABLE_BIT,
TRACE_EVENT_FL_WAS_ENABLED_BIT,
+ TRACE_EVENT_FL_USE_CALL_FILTER_BIT,
};
/*
@@ -213,6 +214,7 @@ enum {
* WAS_ENABLED - Set and stays set when an event was ever enabled
*(used for module unloading, if a module event is enabled,
* it is best to clear the buffers that used it).
+ * USE_CALL_FILTER - For ftrace internal events, don't use file filter
*/
enum {
TRACE_EVENT_FL_FILTERED = (1 << TRACE_EVENT_FL_FILTERED_BIT),
@@ -220,6 +222,7 @@ enum {
TRACE_EVENT_FL_NO_SET_FILTER= (1 <<
TRACE_EVENT_FL_NO_SET_FILTER_BIT),
TRACE_EVENT_FL_IGNORE_ENABLE= (1 <<
TRACE_EVENT_FL_IGNORE_ENABLE_BIT),
TRACE_EVENT_FL_WAS_ENABLED = (1 << TRACE_EVENT_FL_WAS_ENABLED_BIT),
+ TRACE_EVENT_FL_USE_CALL_FILTER = (1 <<
TRACE_EVENT_FL_USE_CALL_FILTER_BIT),
};
struct ftrace_event_call {
@@ -238,6 +241,7 @@ struct ftrace_event_call {
* bit 2: failed to apply filter
* bit 3: ftrace internal event (do not enable)
* bit 4: Event was enabled by module
+* bit 5: use call filter rather than file filter
*/
int flags; /* static flags of different events */
@@ -253,6 +257,8 @@ struct ftrace_subsystem_dir;
enum {
FTRACE_EVENT_FL_ENABLED_BIT,
FTRACE_EVENT_FL_RECORDED_CMD_BIT,
+ FTRACE_EVENT_FL_FILTERED_BIT,
+ FTRACE_EVENT_FL_NO_SET_FILTER_BIT,
FTRACE_EVENT_FL_SOFT_MODE_BIT,
FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
FTRACE_EVENT_FL_TRIGGER_MODE_BIT,
@@ -262,6 +268,8 @@ enum {
* Ftrace event file flags:
* ENABLED - The event is enabled
* RECORDED_CMD - The comms should be recorded at sched_switch
+ * FILTERED - The event has a filter attached
+ * NO_SET_FILTER - Set when filter has error and is to be ignored
* SOFT_MODE - The event is enabled/disabled by SOFT_DISABLED
*
[PATCH v7 04/10] tracing: add 'snapshot' event trigger command
Add 'snapshot' ftrace_func_command. snapshot event triggers are added
by the user via this command in a similar way and using practically
the same syntax as the analogous 'snapshot' ftrace function command,
but instead of writing to the set_ftrace_filter file, the snapshot
event trigger is written to the per-event 'trigger' files:
echo 'snapshot' > .../somesys/someevent/trigger
The above command will turn on snapshots for someevent i.e. whenever
someevent is hit, a snapshot will be done.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'snapshot:N' > .../somesys/someevent/trigger
Where N is the number of times the command will be invoked.
The above command will snapshot N times for someevent i.e. whenever
someevent is hit N times, a snapshot will be done.
Also adds a new ftrace_alloc_snapshot() function - the ftrace snapshot
command defines code that allocates a snapshot, which would be nice to
be able to reuse, which this does.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 1 +
kernel/trace/trace.c| 9
kernel/trace/trace.h| 1 +
kernel/trace/trace_events_trigger.c | 89 +
4 files changed, 100 insertions(+)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 4c8f7c1..5c223e3 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -319,6 +319,7 @@ struct ftrace_event_file {
enum trigger_mode {
TM_NONE = (0),
TM_TRACE_ONOFF = (1 << 0),
+ TM_SNAPSHOT = (1 << 1),
};
extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 496f94d..5a61dbe 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5358,6 +5358,15 @@ static const struct file_operations
tracing_dyn_info_fops = {
};
#endif /* CONFIG_DYNAMIC_FTRACE */
+#if defined(CONFIG_TRACER_SNAPSHOT)
+int ftrace_alloc_snapshot(void)
+{
+ return alloc_snapshot(_trace);
+}
+#else
+int ftrace_alloc_snapshot(void) { return -ENOSYS; }
+#endif
+
#if defined(CONFIG_TRACER_SNAPSHOT) && defined(CONFIG_DYNAMIC_FTRACE)
static void
ftrace_snapshot(unsigned long ip, unsigned long parent_ip, void **data)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 1733ac9..5aea9e1 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1193,6 +1193,7 @@ struct event_command {
extern int trace_event_enable_disable(struct ftrace_event_file *file,
int enable, int soft_disable);
+extern int ftrace_alloc_snapshot(void);
extern const char *__start___trace_bprintk_fmt[];
extern const char *__stop___trace_bprintk_fmt[];
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index d5a10ed..342a6dc 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -712,6 +712,87 @@ static struct event_command trigger_traceoff_cmd = {
.get_trigger_ops= onoff_get_trigger_ops,
};
+static void
+snapshot_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ tracing_snapshot();
+}
+
+static void
+snapshot_count_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (!data->count)
+ return;
+
+ if (data->count != -1)
+ (data->count)--;
+
+ snapshot_trigger(_data);
+}
+
+static int
+register_snapshot_trigger(char *glob, struct event_trigger_ops *ops,
+ void *data, struct ftrace_event_file *file)
+{
+ int ret = register_trigger(glob, ops, data, file);
+
+ if (ret > 0)
+ ftrace_alloc_snapshot();
+
+ return ret;
+}
+
+static int
+snapshot_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+ void *_data)
+{
+ struct event_trigger_data *data = _data;
+
+ return event_trigger_print("snapshot", m, (void *)data->count,
+ data->filter_str);
+}
+
+static struct event_trigger_ops snapshot_trigger_ops = {
+ .func = snapshot_trigger,
+ .print = snapshot_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops snapshot_count_trigger_ops = {
+ .func = snapshot_count_trigger,
+ .print = snapshot_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct
[PATCH v7 01/10] tracing: Add support for SOFT_DISABLE to syscall events
The original SOFT_DISABLE patches didn't add support for soft disable
of syscall events; this adds it and paves the way for future patches
allowing triggers to be added to syscall events, since triggers are
built on top of SOFT_DISABLE.
Add an array of ftrace_event_file pointers indexed by syscall number
to the trace array and remove the existing enabled bitmaps, which as a
result are now redundant. The ftrace_event_file structs in turn
contain the soft disable flags we need for per-syscall soft disable
accounting; later patches add additional 'trigger' flags and
per-syscall triggers and filters.
Signed-off-by: Tom Zanussi
---
kernel/trace/trace.h | 4 ++--
kernel/trace/trace_syscalls.c | 36 ++--
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index fe39acd..b1227b9 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -192,8 +192,8 @@ struct trace_array {
#ifdef CONFIG_FTRACE_SYSCALLS
int sys_refcount_enter;
int sys_refcount_exit;
- DECLARE_BITMAP(enabled_enter_syscalls, NR_syscalls);
- DECLARE_BITMAP(enabled_exit_syscalls, NR_syscalls);
+ struct ftrace_event_file *enter_syscall_files[NR_syscalls];
+ struct ftrace_event_file *exit_syscall_files[NR_syscalls];
#endif
int stop_count;
int clock_id;
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 559329d..230cdb6 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -302,6 +302,7 @@ static int __init syscall_exit_define_fields(struct
ftrace_event_call *call)
static void ftrace_syscall_enter(void *data, struct pt_regs *regs, long id)
{
struct trace_array *tr = data;
+ struct ftrace_event_file *ftrace_file;
struct syscall_trace_enter *entry;
struct syscall_metadata *sys_data;
struct ring_buffer_event *event;
@@ -314,7 +315,13 @@ static void ftrace_syscall_enter(void *data, struct
pt_regs *regs, long id)
syscall_nr = trace_get_syscall_nr(current, regs);
if (syscall_nr < 0)
return;
- if (!test_bit(syscall_nr, tr->enabled_enter_syscalls))
+
+ /* Here we're inside the tp handler's rcu_read_lock (__DO_TRACE()) */
+ ftrace_file = rcu_dereference_raw(tr->enter_syscall_files[syscall_nr]);
+ if (!ftrace_file)
+ return;
+
+ if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, _file->flags))
return;
sys_data = syscall_nr_to_meta(syscall_nr);
@@ -345,6 +352,7 @@ static void ftrace_syscall_enter(void *data, struct pt_regs
*regs, long id)
static void ftrace_syscall_exit(void *data, struct pt_regs *regs, long ret)
{
struct trace_array *tr = data;
+ struct ftrace_event_file *ftrace_file;
struct syscall_trace_exit *entry;
struct syscall_metadata *sys_data;
struct ring_buffer_event *event;
@@ -356,7 +364,13 @@ static void ftrace_syscall_exit(void *data, struct pt_regs
*regs, long ret)
syscall_nr = trace_get_syscall_nr(current, regs);
if (syscall_nr < 0)
return;
- if (!test_bit(syscall_nr, tr->enabled_exit_syscalls))
+
+ /* Here we're inside the tp handler's rcu_read_lock (__DO_TRACE()) */
+ ftrace_file = rcu_dereference_raw(tr->exit_syscall_files[syscall_nr]);
+ if (!ftrace_file)
+ return;
+
+ if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, _file->flags))
return;
sys_data = syscall_nr_to_meta(syscall_nr);
@@ -397,7 +411,7 @@ static int reg_event_syscall_enter(struct ftrace_event_file
*file,
if (!tr->sys_refcount_enter)
ret = register_trace_sys_enter(ftrace_syscall_enter, tr);
if (!ret) {
- set_bit(num, tr->enabled_enter_syscalls);
+ rcu_assign_pointer(tr->enter_syscall_files[num], file);
tr->sys_refcount_enter++;
}
mutex_unlock(_trace_lock);
@@ -415,9 +429,14 @@ static void unreg_event_syscall_enter(struct
ftrace_event_file *file,
return;
mutex_lock(_trace_lock);
tr->sys_refcount_enter--;
- clear_bit(num, tr->enabled_enter_syscalls);
+ rcu_assign_pointer(tr->enter_syscall_files[num], NULL);
if (!tr->sys_refcount_enter)
unregister_trace_sys_enter(ftrace_syscall_enter, tr);
+ /*
+* Callers expect the event to be completely disabled on
+* return, so wait for current handlers to finish.
+*/
+ synchronize_sched();
mutex_unlock(_trace_lock);
}
@@ -435,7 +454,7 @@ static int reg_event_syscall_exit(struct ftrace_event_file
*file,
if (!tr->sys_refcount_exit)
ret = register_trace_sys_exit(ftrace_syscall_exit, tr);
if (!ret) {
- set_bit(num,
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 08/26/2013 11:01 AM, boris brezillon wrote: > Hello Stephen, > > On 26/08/2013 18:50, Stephen Warren wrote: >> On 08/24/2013 03:35 PM, Boris BREZILLON wrote: >>> Add a new parameter to support deglitch filter configuration. >>> A deglitch filter works like a debounce filter but with a smaller >>> delay (nanoseconds). >> Why not use the existing debounce property, just with a small delay >> specified. It seems like that's exactly what the property is for? > That's one of the question I asked in my cover letter :-) > > Indeed the at91 deglitch filter delay is not configurable and is statically > assigned to half a master clk cycle (if master clk = 133MHz -> 8 ns). > The debounce property argument is currently expressed in usecs. > > This will result in always selecting the debounce filter (which is also > available on at91 SoCs) over the deglitch filter. > > Could we add a flag in the deglitch argument to specify the delay unit > (nsecs or usecs) ? If the value is hard-coded in HW, why not use non-zero (or 1) to enable and zero to disable? (this kind of thing is why I'm not convinced that generic pinconf works so well... What if we need psecs in the future?) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/3] pinctrl: at91: add support for generic pinconf
On 08/26/2013 12:45 PM, boris brezillon wrote:
> Hello Jean-Christophe,
>
> Le 26/08/2013 19:53, Jean-Christophe PLAGNIOL-VILLARD a écrit :
>> On 23:37 Sat 24 Aug , Boris BREZILLON wrote:
>>> Add support for generic pin configuration to pinctrl-at91 driver.
...
>>> a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
...
>>> configures various pad settings
>>> such as pull-up, multi drive, etc.
>>> Required properties for iomux controller:
>>> -- compatible: "atmel,at91rm9200-pinctrl"
>>> +- compatible: "atmel,at91rm9200-pinctrl" or "atmel,at91sam9x5-pinctrl".
>>> + Add "generic-pinconf" to the compatible string list to use the
>>> generic pin
...
>>> +pinctrl@f400 {
>>> +#address-cells = <1>;
>>> +#size-cells = <1>;
>>> +ranges;
>>> +compatible = "atmel,at91rm9200-pinctrl", "generic-pinconf",
>>> "simple-bus";
>> nack your break the backword compatibility
>>
>> if we use a old kernel with this new dt nothing will work
>> as the old kernel will never known the the "generic-pinconf" means
>> anything
>
> Your're right, I didn't think of this case (old kernel with new dt).
Well, just to be clear: If a new DT uses a new compatible value of any
kind, be it adding "generic-pinconf" or switching to "foo-yyy" rather
than "foo-yyy", it won't be compatible... That somewhat implies that you
can't ever replace an old binding with something new.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] perf trace enhancements
Arnaldo: A couple of enhancements to perf-trace: ability to analyze events from a file and when processing a file limit the analysis to a given set of pid and tids. David Ahern (3): perf evlist: Add tracepoint lookup by name perf trace: Add option to analyze events in a file versus live perf trace: Honor target pid / tid options when analyzing a file tools/perf/Documentation/perf-trace.txt |4 + tools/perf/builtin-trace.c | 135 ++- tools/perf/util/evlist.c| 15 tools/perf/util/evlist.h|4 + 4 files changed, 157 insertions(+), 1 deletion(-) -- 1.7.10.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 2/3] perf trace: Add option to analyze events in a file versus live
Allows capture of raw_syscall:* events and analyzed at a later
time.
Signed-off-by: David Ahern
Cc: Adrian Hunter
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
---
tools/perf/Documentation/perf-trace.txt |4 ++
tools/perf/builtin-trace.c | 92 ++-
2 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-trace.txt
b/tools/perf/Documentation/perf-trace.txt
index fe19811..34c459b 100644
--- a/tools/perf/Documentation/perf-trace.txt
+++ b/tools/perf/Documentation/perf-trace.txt
@@ -74,6 +74,10 @@ the thread executes on the designated CPUs. Default is to
monitor all CPUs.
--sched:
Accrue thread runtime and provide a summary at the end of the session.
+-r
+--replay
+ Process events from a given perf data file.
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-script[1]
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index b72afc7..a0a1540 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -4,6 +4,7 @@
#include "util/debug.h"
#include "util/evlist.h"
#include "util/machine.h"
+#include "util/session.h"
#include "util/thread.h"
#include "util/parse-options.h"
#include "util/strlist.h"
@@ -648,6 +649,36 @@ out_dump:
return 0;
}
+static int trace__process_sample(struct perf_tool *tool,
+union perf_event *event __maybe_unused,
+struct perf_sample *sample,
+struct perf_evsel *evsel,
+struct machine *machine __maybe_unused)
+{
+ struct trace *trace = container_of(tool, struct trace, tool);
+ int err = 0;
+
+ tracepoint_handler handler = evsel->handler.func;
+
+ if (trace->base_time == 0)
+ trace->base_time = sample->time;
+
+ if (handler)
+ handler(trace, evsel, sample);
+
+ return err;
+}
+
+static bool
+perf_session__has_tp(struct perf_session *session, const char *name)
+{
+ struct perf_evsel *evsel;
+
+ evsel = perf_evlist__find_tracepoint_by_name(session->evlist, name);
+
+ return evsel != NULL;
+}
+
static int trace__run(struct trace *trace, int argc, const char **argv)
{
struct perf_evlist *evlist = perf_evlist__new();
@@ -787,6 +818,61 @@ out:
return err;
}
+static int trace__replay(struct trace *trace)
+{
+ const struct perf_evsel_str_handler handlers[] = {
+ { "raw_syscalls:sys_enter", trace__sys_enter, },
+ { "raw_syscalls:sys_exit", trace__sys_exit, },
+ };
+
+ struct perf_session *session;
+ int err = -1;
+
+ trace->tool.sample= trace__process_sample;
+ trace->tool.mmap = perf_event__process_mmap;
+ trace->tool.comm = perf_event__process_comm;
+ trace->tool.exit = perf_event__process_exit;
+ trace->tool.fork = perf_event__process_fork;
+ trace->tool.attr = perf_event__process_attr;
+ trace->tool.tracing_data = perf_event__process_tracing_data;
+ trace->tool.build_id = perf_event__process_build_id;
+
+ trace->tool.ordered_samples = true;
+ trace->tool.ordering_requires_timestamps = true;
+
+ if (symbol__init() < 0)
+ return -1;
+
+ session = perf_session__new(input_name, O_RDONLY, 0, false,
>tool);
+ if (session == NULL)
+ return -ENOMEM;
+
+ err = perf_session__set_tracepoints_handlers(session, handlers);
+ if (err)
+ goto out;
+
+ if (!perf_session__has_tp(session, "raw_syscalls:sys_enter")) {
+ pr_err("Data file does not have raw_syscalls:sys_enter
events\n");
+ goto out;
+ }
+
+ if (!perf_session__has_tp(session, "raw_syscalls:sys_exit")) {
+ pr_err("Data file does not have raw_syscalls:sys_exit
events\n");
+ goto out;
+ }
+
+ setup_pager();
+
+ err = perf_session__process_events(session, >tool);
+ if (err)
+ pr_err("Failed to process events, error %d", err);
+
+out:
+ perf_session__delete(session);
+
+ return err;
+}
+
static size_t trace__fprintf_threads_header(FILE *fp)
{
size_t printed;
@@ -888,6 +974,7 @@ int cmd_trace(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_STRING('e', "expr", _qualifier_str, "expr",
"list of events to trace"),
OPT_STRING('o', "output", _name, "file", "output file name"),
+ OPT_STRING('r', "replay", _name, "file", "Analyze events in
file"),
OPT_STRING('p', "pid", , "pid",
"trace events on existing process id"),
OPT_STRING('t', "tid", , "tid",
@@ -954,7 +1041,10 @@ int cmd_trace(int argc, const char **argv, const char
*prefix
[PATCH 1/3] perf evlist: Add tracepoint lookup by name
Will be used by upcoming perf-trace replay option.
Signed-off-by: David Ahern
Cc: Adrian Hunter
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
---
tools/perf/util/evlist.c | 15 +++
tools/perf/util/evlist.h |4
2 files changed, 19 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 1f5105a..c0e43ee 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -210,6 +210,21 @@ perf_evlist__find_tracepoint_by_id(struct perf_evlist
*evlist, int id)
return NULL;
}
+struct perf_evsel *
+perf_evlist__find_tracepoint_by_name(struct perf_evlist *evlist,
+const char *name)
+{
+ struct perf_evsel *evsel;
+
+ list_for_each_entry(evsel, >entries, node) {
+ if ((evsel->attr.type == PERF_TYPE_TRACEPOINT) &&
+ (strcmp(evsel->name, name) == 0))
+ return evsel;
+ }
+
+ return NULL;
+}
+
int perf_evlist__add_newtp(struct perf_evlist *evlist,
const char *sys, const char *name, void *handler)
{
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 327abab..8a509e2 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -71,6 +71,10 @@ int perf_evlist__set_filter(struct perf_evlist *evlist,
const char *filter);
struct perf_evsel *
perf_evlist__find_tracepoint_by_id(struct perf_evlist *evlist, int id);
+struct perf_evsel *
+perf_evlist__find_tracepoint_by_name(struct perf_evlist *evlist,
+const char *name);
+
void perf_evlist__id_add(struct perf_evlist *evlist, struct perf_evsel *evsel,
int cpu, int thread, u64 id);
--
1.7.10.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/3] perf trace: Honor target pid / tid options when analyzing a file
Allows capture of raw_syscall events for all processes or threads in a task
and then analyzing specific ones.
Signed-off-by: David Ahern
Cc: Adrian Hunter
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
---
tools/perf/builtin-trace.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index a0a1540..ef957a1 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -8,6 +8,7 @@
#include "util/thread.h"
#include "util/parse-options.h"
#include "util/strlist.h"
+#include "util/intlist.h"
#include "util/thread_map.h"
#include
@@ -259,6 +260,8 @@ struct trace {
unsigned long nr_events;
struct strlist *ev_qualifier;
boolnot_ev_qualifier;
+ struct intlist *tid_list;
+ struct intlist *pid_list;
boolsched;
boolmultiple_threads;
double duration_filter;
@@ -649,6 +652,18 @@ out_dump:
return 0;
}
+static bool skip_sample(struct trace *trace, struct perf_sample *sample)
+{
+ if ((trace->pid_list && intlist__find(trace->pid_list, sample->pid)) ||
+ (trace->tid_list && intlist__find(trace->tid_list, sample->tid)))
+ return false;
+
+ if (trace->pid_list || trace->tid_list)
+ return true;
+
+ return false;
+}
+
static int trace__process_sample(struct perf_tool *tool,
union perf_event *event __maybe_unused,
struct perf_sample *sample,
@@ -660,6 +675,9 @@ static int trace__process_sample(struct perf_tool *tool,
tracepoint_handler handler = evsel->handler.func;
+ if (skip_sample(trace, sample))
+ return 0;
+
if (trace->base_time == 0)
trace->base_time = sample->time;
@@ -679,6 +697,27 @@ perf_session__has_tp(struct perf_session *session, const
char *name)
return evsel != NULL;
}
+static int parse_target_str(struct trace *trace)
+{
+ if (trace->opts.target.pid) {
+ trace->pid_list = intlist__new(trace->opts.target.pid);
+ if (trace->pid_list == NULL) {
+ pr_err("Error parsing process id string\n");
+ return -EINVAL;
+ }
+ }
+
+ if (trace->opts.target.tid) {
+ trace->tid_list = intlist__new(trace->opts.target.tid);
+ if (trace->tid_list == NULL) {
+ pr_err("Error parsing thread id string\n");
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
static int trace__run(struct trace *trace, int argc, const char **argv)
{
struct perf_evlist *evlist = perf_evlist__new();
@@ -861,6 +900,10 @@ static int trace__replay(struct trace *trace)
goto out;
}
+ err = parse_target_str(trace);
+ if (err != 0)
+ goto out;
+
setup_pager();
err = perf_session__process_events(session, >tool);
--
1.7.10.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: [BUG] 3.7-rc regression bisected: s2disk fails to resume image: Processes could not be frozen, cannot continue resuming
Hello,
On Mon, 12 Aug 2013 23:44:15 +0400 Andrew Savchenko wrote:
> after a kernel update from 3.5.7 to the latest stable I found that
> user-space resume (from suspend-1.0 aka uswsusp) no longer works.
> Kernel-space suspend and resume work fine (e.g. echo disk
> > /sys/power/state), problem is with user-space support. (I need
> user-space version because it supports image encryption.)
>
> After resume (essentially linuxrc) application loads image it fails
> to apply it:
>
>
> Processes could not be frozen, cannot continue resuming.
> Error 11: Resource temporarily unavailable
>
> You can now boot the system and lose the saved state
> or reboot and try again.
>
> [Notice that if you decide to reboot, you MUST NOT mount
> any filesystems before a successful resume.
> Resuming after some filesystems have been mounted
> will badly damage these filesystems.]
>
> Do you want to continue booting (Y/n)?
>
>
> Error code wasn't originally showed, I added it to suspend tool to
> aid debugging. Essentially freeze ioctl on /dev/snapshot fails with
> this error.
>
> I bisected a commit which introduces this bug:
>
>
> commit ba4df2808a86f8b103c4db0b8807649383e9bd13
> Author: Al Viro
> Date: Tue Oct 2 15:29:10 2012 -0400
>
> don't bother with kernel_thread/kernel_execve for launching
> linuxrc
> exec_usermodehelper_fns() will do just fine...
>
> Signed-off-by: Al Viro
>
>
> In fact this commit induced/triggered at least two bugs: the first one
> I'm facing now and the second one was fixed in commit
> f0de17c0babe7f29381892def6b37e9181a53410:
> make sure that /linuxrc has std{in,out,err}.
>
> As a temporarily workaround for this issue I reverted all changes for
> init/do_mounts_initrd.c up to the latest working commit
> cb450766bcafc7bd7d40e9a5a0050745e8c68b3e considering the kernel API
> changes (kernel_execve -> sys_execve). See linuxrc-workaround.patch.
> I understand this isn't a proper solution, I just want to show what
> code works for me.
>
> I also found an interesting LKML discussion about s2disk and freezer
> issue: http://www.spinics.net/lists/linux-nfs/msg38160.html
> Maybe it is related to this bug, but patch proposed there doesn't in
> my case.
>
> Kernel config which fails with
> ba4df2808a86f8b103c4db0b8807649383e9bd13 and works with
> f0de17c0babe7f29381892def6b37e9181a53410 is also attached.
>
> As this issue maybe hardware related, the system is 32-bit EEE PC
> 1000H with Atom N270, 2GB RAM, 750 GB SATA drive.
>
> Additional (but probably useless) information on this bug may be found
> here: https://forums.gentoo.org/viewtopic-p-7371120.html
This bug is still here with 3.11-rc7 and 3.10.9.
I opened a kernel bug 60802 for this issue:
https://bugzilla.kernel.org/show_bug.cgi?id=60802
Any ideas?
Best regards,
Andrew Savchenko
pgpeKAmZr6TKe.pgp
Description: PGP signature
RE: [PATCH 4/4] Documentation: Add device tree bindings for Freescale FTM PWM
Hi Stephen, > Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for > Freescale FTM PWM > > On 08/25/2013 11:35 PM, Xiubo Li-B47053 wrote: > >> Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for > ... > >>> Why do you need to manipulate the pinctrl to en/disable a channel? > >> > >> This is because in Vybrid VF610 TOWER board, there are 4 leds, and > >> each led's one point(diode's positive pole) is connected to 3.3V, and > >> the other point is connected to pwm's one channel. When the 4 > >> pinctrls are configured as enable at the same time, the 4 pinctrls is > >> low valtage, and the 4 leds will be lighted up as default, then when > >> you enable/disable one led will effects others. > >> > >> These pinctrls are belong to pwm, and I don't think led or other > >> customer could control them directly. > >> So, here I authorize the 4 pinctrls to each channel controls. > >> > > " > > For the reason above, I have to control the pinctrls separately. > > > > If all the pinctrls set as default state, the 8 pinctrls must be > controlled together. > > And the 4 leds will all be lighted up as default and will influence > each other. > > Sorry, that still doesn't make much sense. Either way though, having > separate pinctrl setup for a single device isn't going to work. You'll > either need to have all combinations of 4 (8?) PWMs represented as > pinctrl states(!), or register separate PWM devices so that they get > independant pinctrl states. > Well, I have ever thought about registering separate PWM device for each channel. But, if so, how should I control the pinctrl of each PWM(actually one channel of FTM PWM) ? I must select "default" state(the "default" state here, the pinctrl must be setup as "dsN" or "chN-idle" state we discussed before) when probing, and when customers .request-->.config-->.enable the PWM I also must select an "active" state to config the pinctrl... Thus, this is still not static. I think this isn't much different from the current. Also if having all combinations of 8 PWMs represented as pinctrl states, how could I deal with the problem about LEDs ? Thanks very much, -- Best Regards, Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] h8300: include: asm: add marco VM_DATA_DEFAULT_FLAGS in page.h
Need add VM_DATA_DEFAULT_FLAGS definition just like another platforms has done (e.g. xtensa), or can not pass compiling. The related error (allmodconfig for h8300): CC security/selinux/hooks.o security/selinux/hooks.c: In function 'selinux_init': security/selinux/hooks.c:5866:21: error: 'VM_DATA_DEFAULT_FLAGS' undeclared (first use in this function) default_noexec = !(VM_DATA_DEFAULT_FLAGS & VM_EXEC); ^ Signed-off-by: Chen Gang --- arch/h8300/include/asm/page.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/h8300/include/asm/page.h b/arch/h8300/include/asm/page.h index 837381a..6af8b0d 100644 --- a/arch/h8300/include/asm/page.h +++ b/arch/h8300/include/asm/page.h @@ -72,6 +72,9 @@ extern unsigned long memory_end; #endif /* __ASSEMBLY__ */ +#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | \ +VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) + #include #include -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock
Hi Don, Sorry for the late reply. (2013/08/22 22:11), Don Zickus wrote: On Thu, Aug 22, 2013 at 05:38:07PM +0900, Yoshihiro YUNOMAE wrote: So, I agree with Eric, let's remove the disable_IO_APIC() stuff and keep the code simpler. Thank you for commenting about my patch. I didn't know you already have submitted the patches for this deadlock problem. I can't answer definitively right now that no problems are induced by removing disable_IO_APIC(). However, my patch should be work well (and has already been merged to -tip tree). So how about taking my patch at first, and then discussing the removal of disabled_IO_APIC()? It doesn't matter to me. My orignal patch last year was similar to yours until it was suggested that we were working around a problem which was we shouldn't touch the IO_APIC code on panic. Then I wrote the removal of disable_IO_APIC patch and did lots of testing on it. I don't think I have seen any issues with it (just the removal of disabling the lapic stuff). Yes, you really did a lot of testing about this problem according to your patch(https://lkml.org/lkml/2012/1/31/391). Although you said jiffies calibration code does not need the PIT in http://lists.infradead.org/pipermail/kexec/2012-February/006017.html, I don't understand yet why we can remove disable_IO_APIC. Would you please explain about the calibration codes? By the way, can we remove disable_IO_APIC even if an old dump capture kernel is used? Thanks, Yoshihiro YUNOMAE Regardless, your patch fixes a similar problem we saw on RHEL, so I am happy either way. The removal of the disable_IO_APIC() just makes the code look cleaner. Cheers, Don -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@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 v2 3/3] mm/hwpoison: fix return value of madvise_hwpoison
On Tue, Aug 27, 2013 at 11:38:27AM +0800, Wanpeng Li wrote:
> Hi Naoya,
> On Mon, Aug 26, 2013 at 11:28:16PM -0400, Naoya Horiguchi wrote:
> >On Tue, Aug 27, 2013 at 10:39:31AM +0800, Wanpeng Li wrote:
> >> The return value outside for loop is always zero which means
> >> madvise_hwpoison
> >> return success, however, this is not truth for soft_offline_page w/ failure
> >> return value.
> >
> >I don't understand what you want to do for what reason. Could you clarify
> >those?
>
> int ret is defined in two place in madvise_hwpoison. One is out of for
> loop and its value is always zero(zero means success for madvise), the
> other one is in for loop. The soft_offline_page function maybe return
> -EBUSY and break, however, the ret out of for loop is return which means
> madvise_hwpoison success.
Oh, I see. Thanks.
Reviewed-by: Naoya Horiguchi
> Regards,
> Wanpeng Li
>
> >
> >>
> >> Signed-off-by: Wanpeng Li
> >> ---
> >> mm/madvise.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/mm/madvise.c b/mm/madvise.c
> >> index a20764c..19b71e4 100644
> >> --- a/mm/madvise.c
> >> +++ b/mm/madvise.c
> >> @@ -359,7 +359,7 @@ static int madvise_hwpoison(int bhv, unsigned long
> >> start, unsigned long end)
> >>page_to_pfn(p), start);
> >>ret = soft_offline_page(p, MF_COUNT_INCREASED);
> >>if (ret)
> >> - break;
> >> + return ret;
> >>continue;
> >>}
> >>pr_info("Injecting memory failure for page %#lx at %#lx\n",
> >
> >This seems to introduce no behavioral change.
> >
> >Thanks,
> >Naoya Horiguchi
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 tip/core/rcu 8/9] nohz_full: Add full-system-idle state machine
On 08/27/2013 12:24 AM, Paul E. McKenney wrote:
> On Mon, Aug 26, 2013 at 01:45:32PM +0800, Lai Jiangshan wrote:
>> On 08/20/2013 10:47 AM, Paul E. McKenney wrote:
>>> From: "Paul E. McKenney"
>>>
>>> This commit adds the state machine that takes the per-CPU idle data
>>> as input and produces a full-system-idle indication as output. This
>>> state machine is driven out of RCU's quiescent-state-forcing
>>> mechanism, which invokes rcu_sysidle_check_cpu() to collect per-CPU
>>> idle state and then rcu_sysidle_report() to drive the state machine.
>>>
>>> The full-system-idle state is sampled using rcu_sys_is_idle(), which
>>> also drives the state machine if RCU is idle (and does so by forcing
>>> RCU to become non-idle). This function returns true if all but the
>>> timekeeping CPU (tick_do_timer_cpu) are idle and have been idle long
>>> enough to avoid memory contention on the full_sysidle_state state
>>> variable. The rcu_sysidle_force_exit() may be called externally
>>> to reset the state machine back into non-idle state.
>>>
>>> For large systems the state machine is driven out of RCU's
>>> force-quiescent-state logic, which provides good scalability at the price
>>> of millisecond-scale latencies on the transition to full-system-idle
>>> state. This is not so good for battery-powered systems, which are usually
>>> small enough that they don't need to care about scalability, but which
>>> do care deeply about energy efficiency. Small systems therefore drive
>>> the state machine directly out of the idle-entry code. The number of
>>> CPUs in a "small" system is defined by a new NO_HZ_FULL_SYSIDLE_SMALL
>>> Kconfig parameter, which defaults to 8. Note that this is a build-time
>>> definition.
>>>
>>> Signed-off-by: Paul E. McKenney
>>> Cc: Frederic Weisbecker
>>> Cc: Steven Rostedt
>>> Cc: Lai Jiangshan
>>> [ paulmck: Use true and false for boolean constants per Lai Jiangshan. ]
>>> Reviewed-by: Josh Triplett
>>> ---
>>> include/linux/rcupdate.h | 18 +++
>>> kernel/rcutree.c | 16 ++-
>>> kernel/rcutree.h | 5 +
>>> kernel/rcutree_plugin.h | 284
>>> ++-
>>> kernel/time/Kconfig | 27 +
>>> 5 files changed, 343 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
>>> index 30bea9c..f1f1bc3 100644
>>> --- a/include/linux/rcupdate.h
>>> +++ b/include/linux/rcupdate.h
>>> @@ -1011,4 +1011,22 @@ static inline bool rcu_is_nocb_cpu(int cpu) { return
>>> false; }
>>> #endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */
>>>
>>>
>>> +/* Only for use by adaptive-ticks code. */
>>> +#ifdef CONFIG_NO_HZ_FULL_SYSIDLE
>>> +extern bool rcu_sys_is_idle(void);
>>> +extern void rcu_sysidle_force_exit(void);
>>> +#else /* #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
>>> +
>>> +static inline bool rcu_sys_is_idle(void)
>>> +{
>>> + return false;
>>> +}
>>> +
>>> +static inline void rcu_sysidle_force_exit(void)
>>> +{
>>> +}
>>> +
>>> +#endif /* #else #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
>>> +
>>> +
>>> #endif /* __LINUX_RCUPDATE_H */
>>> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
>>> index 7b5be56..eca70f44 100644
>>> --- a/kernel/rcutree.c
>>> +++ b/kernel/rcutree.c
>>> @@ -734,6 +734,7 @@ static int dyntick_save_progress_counter(struct
>>> rcu_data *rdp,
>>> bool *isidle, unsigned long *maxj)
>>> {
>>> rdp->dynticks_snap = atomic_add_return(0, >dynticks->dynticks);
>>> + rcu_sysidle_check_cpu(rdp, isidle, maxj);
>>> return (rdp->dynticks_snap & 0x1) == 0;
>>> }
>>>
>>> @@ -1373,11 +1374,17 @@ int rcu_gp_fqs(struct rcu_state *rsp, int
>>> fqs_state_in)
>>> rsp->n_force_qs++;
>>> if (fqs_state == RCU_SAVE_DYNTICK) {
>>> /* Collect dyntick-idle snapshots. */
>>> + if (is_sysidle_rcu_state(rsp)) {
>>> + isidle = 1;
>>> + maxj = jiffies - ULONG_MAX / 4;
>>> + }
>>> force_qs_rnp(rsp, dyntick_save_progress_counter,
>>> , );
>>> + rcu_sysidle_report_gp(rsp, isidle, maxj);
>>> fqs_state = RCU_FORCE_QS;
>>> } else {
>>> /* Handle dyntick-idle and offline CPUs. */
>>> + isidle = 0;
>>> force_qs_rnp(rsp, rcu_implicit_dynticks_qs, , );
>>> }
>>> /* Clear flag to prevent immediate re-entry. */
>>> @@ -2103,9 +2110,12 @@ static void force_qs_rnp(struct rcu_state *rsp,
>>> cpu = rnp->grplo;
>>> bit = 1;
>>> for (; cpu <= rnp->grphi; cpu++, bit <<= 1) {
>>> - if ((rnp->qsmask & bit) != 0 &&
>>> - f(per_cpu_ptr(rsp->rda, cpu), isidle, maxj))
>>> - mask |= bit;
>>> + if ((rnp->qsmask & bit) != 0) {
>>> + if ((rnp->qsmaskinit & bit) != 0)
>>> + *isidle = 0;
>>> + if
Re: [PATCH] driver core / ACPI: Avoid device removal locking problems
Hi Rafael,
On 08/26/2013 11:02 PM, Rafael J. Wysocki wrote:
> On Monday, August 26, 2013 04:43:26 PM Rafael J. Wysocki wrote:
>> On Monday, August 26, 2013 02:42:09 PM Rafael J. Wysocki wrote:
>>> On Monday, August 26, 2013 11:13:13 AM Gu Zheng wrote:
Hi Rafael,
>
> [...]
>
>>
>> OK, so the patch below is quick and dirty and overkill, but it should make
>> the
>> splat go away at least.
>
> And if this patch does make the splat go away for you, please also test the
> appended one (Tejun, thanks for the hint!).
Yes, this one works too, and as expected, the ACPI part is still there.
Thanks,
Gu
==
[ INFO: possible circular locking dependency detected ]
3.11.0-rc6-fix-refeal-fix-01+ #171 Tainted: GF
---
kworker/0:1/96 is trying to acquire lock:
(s_active#245){.+}, at: [] sysfs_addrm_finish+0x3b/0x70
but task is already holding lock:
(device_hotplug_lock){+.+.+.}, at: []
lock_device_hotplug+0x17/0x20
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (device_hotplug_lock){+.+.+.}:
[] validate_chain+0x70c/0x870
[] __lock_acquire+0x36f/0x5f0
[] lock_acquire+0xa0/0x130
[] mutex_lock_nested+0x7b/0x3b0
[] lock_device_hotplug+0x17/0x20
[] acpi_scan_bus_device_check+0x33/0x10f
[] acpi_scan_device_check+0x13/0x15
[] acpi_os_execute_deferred+0x27/0x34
[] process_one_work+0x1e8/0x560
[] worker_thread+0x120/0x3a0
[] kthread+0xee/0x100
[] ret_from_fork+0x7c/0xb0
-> #1 (acpi_scan_lock){+.+.+.}:
[] validate_chain+0x70c/0x870
[] __lock_acquire+0x36f/0x5f0
[] lock_acquire+0xa0/0x130
[] mutex_lock_nested+0x7b/0x3b0
[] acpi_eject_store+0x88/0x170
[] dev_attr_store+0x20/0x30
[] sysfs_write_file+0xe6/0x170
[] vfs_write+0xc8/0x170
[] SyS_write+0x62/0xb0
[] system_call_fastpath+0x16/0x1b
Re: [PATCH v4 0/3] arm: mvebu: fix resource leak
Dear Jason, On Mon, 26 Aug 2013 20:22:37 -0700 Jason Cooper wrote: > On Tue, Aug 27, 2013 at 11:01:20AM +0800, Jisheng Zhang wrote: > > Dear Jason, > > > > On Mon, 26 Aug 2013 13:45:23 -0700 > > Jason Cooper wrote: > > > > > On Mon, Aug 26, 2013 at 07:36:55PM +0800, Jisheng Zhang wrote: > > > > These patches try to fix resource leak by adding missing > > > > of_node_put(), iounmap or using devm_ioremap_resource() if available. > > > > > > > > v4: > > > > - re-generate since Ezequiel's patches add DT support to the > > > > mvebu-mbus driver > > > > > > grrr. I hate to ask this, but can you please rebase patches 1 and 2 > > > against mvebu/fixes-non-critical? No need to add back in the mvebu-mbus > > > hunk. > > > > patch 1 also fixes one similar trivial issue introduced since > > 994c8c94b419e "ARM: mvebu: Remove the harcoded BootROM window allocation" > > in linux-next tree > > > > patch 2 is updated to fix similar trivial issue introduce since > > 6839cfa82f99 "bus: mvebu-mbus: Introduce device tree binding" > > > > These two commits aren't included in mvebu/fixes-non-criticial yet. Could > > you please give suggestion? > > Yes, that's correct. We prefer to have patch submitters base off of a > mainline tag (eg v3.11-rc7). conflicts between patchsets are then > caught and resolved when branches are merged. If done correctly, the > merge resolution should be obvious in most cases. > > The upstream maintainers _prefer_ to see those conflicts because it > gives them a better sense of who is tinkering in the same code-paths. > > Trying to base patches off of disparate branches in order to > 'pre-resolve' those conflicts creates unnecessary dependencies and > non-obvious merge-resolutions. > > In this case I asked you base off of mvebu/fixes-non-critical because > that is where I will be applying them for queueing to arm-soc. You > could also base off of v3.11-rc7, there's nothing in > mvebu/fixes-non-critical that should conflict with your changes. > Got it. Thanks very much for your excellent explanation. Will do and send out patches latter. Best Regards, Jisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] mm/hwpoison: fix bug triggered by unpoison empty zero page
On Tue, Aug 27, 2013 at 10:39:29AM +0800, Wanpeng Li wrote:
> v1 -> v2:
> * ignore empty zero page for madvise_hwpoison directly
>
> [ 57.579580] Injecting memory failure for page 0x19d0 at 0xb77d2000
> [ 57.579824] MCE 0x19d0: non LRU page recovery: Ignored
> [ 91.290453] MCE: Software-unpoisoned page 0x19d0
> [ 91.290456] BUG: Bad page state in process bash pfn:019d0
> [ 91.290466] page:f3461a00 count:0 mapcount:0 mapping: (null) index:0x0
> [ 91.290467] page flags: 0x4404(referenced|reserved)
> [ 91.290469] Modules linked in: nfsd auth_rpcgss i915 nfs_acl nfs lockd
> video drm_kms_helper drm bnep rfcomm sunrpc bluetooth psmouse parport_pc
> ppdev lp serio_raw fscache parport gpio_ich lpc_ich mac_hid i2c_algo_bit
> tpm_tis wmi usb_storage hid_generic usbhid hid e1000e firewire_ohci
> firewire_core ahci ptp libahci pps_core crc_itu_t
> [ 91.290486] CPU: 3 PID: 2123 Comm: bash Not tainted 3.11.0-rc6+ #12
> [ 91.290487] Hardware name: LENOVO 7034DD7/, BIOS 9HKT47AUS 01//2012
> [ 91.290488] e9625ea0 c15ec49b f3461a00 e9625eb8
> c15ea119 c17cbf18
> [ 91.290491] ef084314 19d0 f3461a00 e9625ed8 c110dc8a f3461a00
> 0001
> [ 91.290494] f3461a00 4404 e9625ef8 c110dcc1 f3461a00
> f3461a00 19d0
> [ 91.290497] Call Trace:
> [ 91.290501] [] dump_stack+0x41/0x52
> [ 91.290504] [] bad_page+0xcf/0xeb
> [ 91.290515] [] free_pages_prepare+0x12a/0x140
> [ 91.290517] [] free_hot_cold_page+0x21/0x110
> [ 91.290519] [] __put_single_page+0x21/0x30
> [ 91.290521] [] put_page+0x25/0x40
> [ 91.290524] [] unpoison_memory+0x107/0x200
> [ 91.290526] [] ? ns_capable+0x27/0x60
> [ 91.290528] [] hwpoison_unpoison+0x20/0x30
> [ 91.290530] [] simple_attr_write+0xb6/0xd0
> [ 91.290532] [] ? generic_fh_to_dentry+0x50/0x50
> [ 91.290535] [] vfs_write+0xa0/0x1b0
> [ 91.290537] [] ? generic_fh_to_dentry+0x50/0x50
> [ 91.290539] [] SyS_write+0x4f/0x90
> [ 91.290549] [] sysenter_do_call+0x12/0x22
> [ 91.290550] Disabling lock debugging due to kernel taint
>
> Testcase:
>
> #define _GNU_SOURCE
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define PAGES_TO_TEST 1
> #define PAGE_SIZE 4096
>
> int main(void)
> {
> char *mem;
>
> mem = mmap(NULL, PAGES_TO_TEST * PAGE_SIZE,
> PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0,
> 0);
>
> if (madvise(mem, PAGES_TO_TEST * PAGE_SIZE, MADV_HWPOISON) == -1)
> return -1;
>
> munmap(mem, PAGES_TO_TEST * PAGE_SIZE);
>
> return 0;
> }
>
> There is one page reference count for default empty zero page,
> madvise_hwpoison
> add another one by get_user_pages_fast. memory_hwpoison reduce one page
> reference
> count since it's a non LRU page. unpoison_memory release the last page
> reference
> count and free empty zero page to buddy system which is not correct since
> empty
> zero page has PG_reserved flag. This patch fix it by ignore empty zero page
> for
> madvise_hwpoison directly.
>
> Suggested-by: Naoya Horiguchi
> Signed-off-by: Wanpeng Li
Thank you.
Reviewed-by: Naoya Horiguchi
> ---
> mm/madvise.c| 2 ++
> mm/memory-failure.c | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 212f5f1..a20764c 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -352,6 +352,8 @@ static int madvise_hwpoison(int bhv, unsigned long start,
> unsigned long end)
> int ret = get_user_pages_fast(start, 1, 0, );
> if (ret != 1)
> return ret;
> + if (page_to_pfn(p) == my_zero_pfn(0))
> + continue;
> if (bhv == MADV_SOFT_OFFLINE) {
> pr_info("Soft offlining page %#lx at %#lx\n",
> page_to_pfn(p), start);
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 7cdabc0..68cbca0 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1331,6 +1331,9 @@ int unpoison_memory(unsigned long pfn)
> if (!pfn_valid(pfn))
> return -ENXIO;
>
> + if (pfn == my_zero_pfn(0))
> + return 0;
> +
> p = pfn_to_page(pfn);
> page = compound_head(p);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] mm/hwpoison: fix return value of madvise_hwpoison
On Tue, Aug 27, 2013 at 10:39:31AM +0800, Wanpeng Li wrote:
> The return value outside for loop is always zero which means madvise_hwpoison
> return success, however, this is not truth for soft_offline_page w/ failure
> return value.
I don't understand what you want to do for what reason. Could you clarify
those?
>
> Signed-off-by: Wanpeng Li
> ---
> mm/madvise.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/madvise.c b/mm/madvise.c
> index a20764c..19b71e4 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -359,7 +359,7 @@ static int madvise_hwpoison(int bhv, unsigned long start,
> unsigned long end)
> page_to_pfn(p), start);
> ret = soft_offline_page(p, MF_COUNT_INCREASED);
> if (ret)
> - break;
> + return ret;
> continue;
> }
> pr_info("Injecting memory failure for page %#lx at %#lx\n",
This seems to introduce no behavioral change.
Thanks,
Naoya Horiguchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: TPM: STMicroelectronics st33 driver SPI
Please see my comments below. Did you get a chance to run the trousers
testsuite?
git://trousers.git.sourceforge.net/gitroot/trousers/testsuite
+static u8 spi_read8_reg(struct tpm_chip *tpm, u8 tpm_register,
+ u8 *tpm_data, u16 tpm_size)
+{
+ ...
+
+ /* header + status byte + size of the data + status byte */
+ value = spi_sync_transfer(dev, , 1);
+
+ if (tpm_size > 0 && value == 0) {
+ nbr_dummy_bytes = 2;
Why use 2 for the dummy bytes? Some comments here would be
helpful. Should we use a #define for 2?
...
+static unsigned long wait_for_serirq_timeout(struct tpm_chip *chip,
+bool condition, unsigned long timeout)
+{
+ long status = 0;
+ struct spi_device *client;
+ struct st33zp24_platform_data *pin_infos;
+
+ client = (struct spi_device __force *)chip->vendor.iobase;
+ pin_infos = client->dev.platform_data;
+
+ status = wait_for_completion_interruptible_timeout(
+ _infos->irq_detection, timeout);
+ if (status > 0)
+ enable_irq(gpio_to_irq(pin_infos->io_serirq));
+ gpio_direction_input(pin_infos->io_serirq);
+
+ if (!status)
+ return -EBUSY;
This function returns -EBUSY but the return function type is unsigned.
...
+static int recv_data(struct tpm_chip *chip, u8 *buf, size_t count)
+{
+ u32 size = 0, burstcnt, len;
+ long status = 0;
+
+ while (size < count &&
+ wait_for_stat(chip,
+TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+chip->vendor.timeout_c,
+>vendor.read_queue)
+ == 0) {
+ burstcnt = get_burstcount(chip);
+ len = min_t(int, burstcnt, count - size);
What if get_burstcount returns -EBUSY? Should burstcnt be checked
and handled here in case of error?
+ status = spi_read8_reg(chip, TPM_DATA_FIFO, buf + size,
len);
+ if (status < 0)
+ return status;
+
+
Extra empty line here.
+ size += len;
See above comment. If len is -EBUSY, there might be an issue here.
+ }
+return size;
...
+static int tpm_stm_spi_send(struct tpm_chip *chip, unsigned char *buf,
+ size_t len)
+{
...
+ for (i = 0; i < len - 1;) {
+ burstcnt = get_burstcount(chip);
Again burstcnt needs to be checked to make sure it is > 0.
+ size = min_t(int, len - i - 1, burstcnt);
+ ret = spi_write8_reg(chip, TPM_DATA_FIFO, buf, size);
+ if (ret < 0)
+ goto out_err;
+ i += size;
+ }
...
+ /* write last byte */
+ spi_write8_reg(chip, TPM_DATA_FIFO, buf + len - 1, 1);
Should we check for the return code here? A few lines below it checks
for the return value.
...
+
+
+ /* go and do it */
+ data = TPM_STS_GO;
+ ret = spi_write8_reg(chip, TPM_STS, , 1);
Regards,
--Ashley Lai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/18] Hibernate: generate and verify signature of snapshot
Hi Pavel,
Thanks for your time to review my patches.
於 日，2013-08-25 於 18:36 +0200，Pavel Machek 提到：
> On Thu 2013-08-22 19:01:51, Lee, Chun-Yi wrote:
> > This patch add the code for generate/verify signature of snapshot, it
> > put the signature to snapshot header. This approach can support both
> > on userspace hibernate and in-kernel hibernate.
> >
> > v2:
> > - Due to loaded S4 sign key before ExitBootServices, we need forward key
> > from
> > boot kernel to resume target kernel. So this patch add a empty page in
> > snapshot image, then we keep the pfn of this empty page in snapshot
> > header.
> > When system resume from hibernate, we fill new sign key to this empty page
> > space after snapshot image checked pass. This mechanism let boot kernel
> > can
> > forward new sign key to resume target kernel but don't need write new
> > private
> > key to any other storage, e.g. swap.
> >
> > Cc: Matthew Garrett
> > Reviewed-by: Jiri Kosina
> > Signed-off-by: Lee, Chun-Yi
> > ---
> > kernel/power/power.h|6 +
> > kernel/power/snapshot.c | 280
> > +-
> > kernel/power/swap.c | 14 +++
> > kernel/power/user.c |9 ++
> > 4 files changed, 302 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > index 69a81d8..84e0b06 100644
> > --- a/kernel/power/power.h
> > +++ b/kernel/power/power.h
> > @@ -3,6 +3,9 @@
> > #include
> > #include
> >
> > +/* The maximum length of snapshot signature */
> > +#define SIG_LENG 512
> > +
> > struct swsusp_info {
> > struct new_utsname uts;
> > u32 version_code;
> > @@ -11,6 +14,8 @@ struct swsusp_info {
> > unsigned long image_pages;
> > unsigned long pages;
> > unsigned long size;
> > + unsigned long skey_data_buf_pfn;
> > + u8 signature[SIG_LENG];
> > } __attribute__((aligned(PAGE_SIZE)));
>
> SIG_LEN or SIG_LENGTH. Select one.
>
I will use SIG_LEN at next version, thanks!
>
> > +static int
> > copy_data_pages(struct memory_bitmap *copy_bm, struct memory_bitmap
> > *orig_bm)
> > {
> > struct zone *zone;
> > - unsigned long pfn;
> > + unsigned long pfn, dst_pfn;
> ...
> > + tfm = crypto_alloc_shash(SNAPSHOT_HASH, 0, 0);
> > + if (IS_ERR(tfm)) {
> > + pr_err("IS_ERR(tfm): %ld", PTR_ERR(tfm));
> > + return PTR_ERR(tfm);
> > + }
> > +
> > + desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
> > + digest_size = crypto_shash_digestsize(tfm);
> > + digest = kzalloc(digest_size + desc_size, GFP_KERNEL);
>
> Are you sure GFP_KERNEL allocation is okay at this phase of
> hibernation?
>
> Could the hashing be done at later phase, when writing the image to
> disk?
>
Thanks for you point out!
Yes, call memory allocate here is not a good design due to it causes
garbage in snapshot that will not released by resumed kernel.
I just finished another implementation, the respin patch extracts the
signature generation code to another function then call the function in
swsusp_save() after copy_data_pages() finished. We can write to memory
at that stage.
> >
> > +void **h_buf;
>
> helpfully named.
>
I will change the name to handle_buffers;
> > + ret = verify_signature(s4_wake_key, pks);
> > + if (ret) {
> > + pr_err("snapshot S4 signature verification fail: %d\n", ret);
> > + goto error_verify;
> > + } else
> > + pr_info("snapshot S4 signature verification pass!\n");
> > +
> > + if (pks->rsa.s)
> > + mpi_free(pks->rsa.s);
> > + kfree(pks);
>
> ret = 0 and fall through?
>
When verification success, verify_signature() will return 0.
Yes, here have duplicate code, I will clear up it.
> > + return 0;
> > +
> > +error_verify:
> > + if (pks->rsa.s)
> > + mpi_free(pks->rsa.s);
> > +error_mpi:
> > + kfree(pks);
> > + return ret;
> > +}
>
>
> > + ret = crypto_shash_final(desc, digest);
> > + if (ret)
> > + goto error_shash;
> > +
> > + ret = snapshot_verify_signature(digest, digest_size);
> > + if (ret)
> > + goto error_verify;
> > +
> > + kfree(h_buf);
> > + kfree(digest);
> > + crypto_free_shash(tfm);
> > + return 0;
>
> These four lines can be deleted.
>
Yes, here also duplicate, I will remove.
> > +
> > +error_verify:
> > +error_shash:
> > + kfree(h_buf);
> > + kfree(digest);
> > +error_digest:
> > + crypto_free_shash(tfm);
> > + return ret;
> > +}
> > +
> Pavel
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] arm: mvebu: fix resource leak
On Tue, Aug 27, 2013 at 11:01:20AM +0800, Jisheng Zhang wrote: > Dear Jason, > > On Mon, 26 Aug 2013 13:45:23 -0700 > Jason Cooper wrote: > > > On Mon, Aug 26, 2013 at 07:36:55PM +0800, Jisheng Zhang wrote: > > > These patches try to fix resource leak by adding missing of_node_put(), > > > iounmap or using devm_ioremap_resource() if available. > > > > > > v4: > > > - re-generate since Ezequiel's patches add DT support to the > > > mvebu-mbus driver > > > > grrr. I hate to ask this, but can you please rebase patches 1 and 2 > > against mvebu/fixes-non-critical? No need to add back in the mvebu-mbus > > hunk. > > patch 1 also fixes one similar trivial issue introduced since 994c8c94b419e > "ARM: mvebu: Remove the harcoded BootROM window allocation" in linux-next tree > > patch 2 is updated to fix similar trivial issue introduce since 6839cfa82f99 > "bus: mvebu-mbus: Introduce device tree binding" > > These two commits aren't included in mvebu/fixes-non-criticial yet. Could you > please give suggestion? Yes, that's correct. We prefer to have patch submitters base off of a mainline tag (eg v3.11-rc7). conflicts between patchsets are then caught and resolved when branches are merged. If done correctly, the merge resolution should be obvious in most cases. The upstream maintainers _prefer_ to see those conflicts because it gives them a better sense of who is tinkering in the same code-paths. Trying to base patches off of disparate branches in order to 'pre-resolve' those conflicts creates unnecessary dependencies and non-obvious merge-resolutions. In this case I asked you base off of mvebu/fixes-non-critical because that is where I will be applying them for queueing to arm-soc. You could also base off of v3.11-rc7, there's nothing in mvebu/fixes-non-critical that should conflict with your changes. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: ohci-at91: remove unnecessary dev_set_drvdata()
Unnecessary dev_set_drvdata() is removed, because the driver core clears the driver data to NULL after device_release or on probe failure. Signed-off-by: Libo Chen --- drivers/usb/host/ohci-at91.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c index 9677f68..b49a6c8 100644 --- a/drivers/usb/host/ohci-at91.c +++ b/drivers/usb/host/ohci-at91.c @@ -216,8 +216,6 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd, clk_put(fclk); clk_put(iclk); fclk = iclk = hclk = NULL; - - dev_set_drvdata(>dev, NULL); } /*-*/ -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 3/5] ARM: samsung: add clock setup for FIMC and FIMD
On Tuesday, August 27, 2013 3:38 AM, Sylwester Nawrocki wrote: > On 08/26/2013 06:19 PM, Bartlomiej Zolnierkiewicz wrote: > > On Monday, August 26, 2013 01:38:32 PM Mateusz Krawczuk wrote: > >> This patch adds code that sets correct parents and rates for clocks > >> used by FIMC and FIMD on Goni board. > > This patch is supposed to be a workaround to make the display and camera > subsystem working even without properly configured parent clocks in the > boot-loader, right ? And as such it doesn't really belong to this series > and has been written primarily for the clocks testing purposes ? > I think it can be dropped in the next iteration of this series. > Agreed. :-) This patch can be dropped next. Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] arm: mvebu: fix resource leak
Dear Jason, On Mon, 26 Aug 2013 13:45:23 -0700 Jason Cooper wrote: > On Mon, Aug 26, 2013 at 07:36:55PM +0800, Jisheng Zhang wrote: > > These patches try to fix resource leak by adding missing of_node_put(), > > iounmap or using devm_ioremap_resource() if available. > > > > v4: > > - re-generate since Ezequiel's patches add DT support to the > > mvebu-mbus driver > > grrr. I hate to ask this, but can you please rebase patches 1 and 2 > against mvebu/fixes-non-critical? No need to add back in the mvebu-mbus > hunk. patch 1 also fixes one similar trivial issue introduced since 994c8c94b419e "ARM: mvebu: Remove the harcoded BootROM window allocation" in linux-next tree patch 2 is updated to fix similar trivial issue introduce since 6839cfa82f99 "bus: mvebu-mbus: Introduce device tree binding" These two commits aren't included in mvebu/fixes-non-criticial yet. Could you please give suggestion? Thanks in advance, Jisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 11/12] pid: rewrite task helper functions avoiding task->pid and task->tgid
On Fri, Aug 23, 2013 at 09:28:07PM +0200, Oleg Nesterov wrote: > On 08/22, Richard Guy Briggs wrote: > > > > On Thu, Aug 22, 2013 at 10:05:55PM +0200, Peter Zijlstra wrote: > > > > > > Why would you ever want to do this? It just makes these tests more > > > expensive for no gain what so ff'ing ever. > > > > Backups are generally considered a good idea, but in this case, I'd > > quote: > > And perhaps you are right. At least we can probably kill task->tgid. > And I agree, it would be nice to kill task->pid. > > But: I also agree with Peter, we should try to not make the current > code more expensive. I don't disagree. I was given some hope by Eric Biederman that it might not cause cache-line misses... > Anyway. Imho, you should not mix the different things in one series. > If you want to fix audit, do not add the patches like 10/12 or 11/12 > into this series. They were included to gain reassurance that PIDs reported in audit logs were accurate. If those assurances can be made, then I can limit my work to audit itself. > Or 3/12. That is a cleanup to make clear what parts are actually pid-related and what isn't. > OK, I agree sys_getppid() in audit_log_task_info() looks > strange at least. Just fix it using the helpers we already have and > add the new helpers later. Or send the patch(es) which adds the new > helpers first. Patch 04/12 is that helper. It is used in only two places in audit (and once in apparmor), so I could have duplicated the code, but since it needs rcu locking, an inline funciton in the audit namespace seemed somewhat pointless when it could just as easily be shared with other subsystems. > Or task_pid_nr_init_ns()... For what? We already have task_pid_nr(). > Use the helper we already have, or introduce the new one first and > change the current users of task_pid_nr(). If task_struct::pid is definitely not going away, then that whole part is moot and we'll just use task_pid_nr() as is. > In short. Fortunately you do not need to convince me, I do not > maintain audit or namespaces ;) But imho this series looks a bit > confusing. It is incomplete. The last step(s) were intended to purge task_struct::pid (or abstract it using task_pid_nr()), which haven't been submitted yet. The whole point of the patchset was to give confidence in the PIDs reported in any audit logs. > Oleg. - RGB -- Richard Guy Briggs Senior Software Engineer Kernel Security AMER ENG Base Operating Systems Remote, Ottawa, Canada Voice: +1.647.777.2635 Internal: (81) 32635 Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the pm tree with the powerpc tree
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in
arch/powerpc/kernel/prom.c between commit dc0e643afc50 ("powerpc: Make
prom.c device tree accesses endian safe") from the powerpc tree and
commits 819d596568d8 ("powerpc: refactor of_get_cpu_node to support other
architectures") and 183912d352a2 ("of: move of_get_cpu_node
implementation to DT core library") from the pm tree.
I think that the latter superceded the conflicting fixes in the former,
so I just used the latter and can carry the fix as necessary (no action
is required).
P.S. Rafael, I used both your addresses because I have had a bounce from
the sisk.pl one in the past ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpgfGTPaP0mK.pgp
Description: PGP signature
linux-next: build failure after merge of the libata tree
Hi Tejun,
After merging the libata tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from drivers/ata/libata-pmp.c:14:0:
drivers/ata/libata.h:136:1: error: unknown type name 'acpi_handle'
static inline acpi_handle ata_dev_acpi_handle(struct ata_device *dev) { return
NULL; }
^
And several others.
Caused by commit f1bc1e4c44b1 ("ata: acpi: rework the ata acpi bind
support"). All the world does not have the ACPI include files
included via some other path ... nor wants them, I suspect.
I have used the libata tree from next-20130822 for today.
P.S. drivers/ata/libata.h seems to assume that a lot of other stuff is
included that it does not include explicitly ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp6L9rhwHiZ7.pgp
Description: PGP signature
Re: [PATCH] driver core / ACPI: Avoid device removal locking problems
Hi Rafael,
On 08/26/2013 10:43 PM, Rafael J. Wysocki wrote:
> On Monday, August 26, 2013 02:42:09 PM Rafael J. Wysocki wrote:
>> On Monday, August 26, 2013 11:13:13 AM Gu Zheng wrote:
>>> Hi Rafael,
>>
>> Hi,
>>
>>> On 08/26/2013 04:09 AM, Rafael J. Wysocki wrote:
>>>
From: Rafael J. Wysocki
There are two mutexes, device_hotplug_lock and acpi_scan_lock, held
around the acpi_bus_trim() call in acpi_scan_hot_remove() which
generally removes devices (it removes ACPI device objects at least,
but it may also remove "physical" device objects through .detach()
callbacks of ACPI scan handlers). Thus, potentially, device sysfs
attributes are removed under these locks and to remove those
attributes it is necessary to hold the s_active references of their
directory entries for writing.
On the other hand, the execution of a .show() or .store() callback
from a sysfs attribute is carried out with that attribute's s_active
reference held for reading. Consequently, if any device sysfs
attribute that may be removed from within acpi_scan_hot_remove()
through acpi_bus_trim() has a .store() or .show() callback which
acquires either acpi_scan_lock or device_hotplug_lock, the execution
of that callback may deadlock with the removal of the attribute.
[Unfortunately, the "online" device attribute of CPUs and memory
blocks and the "eject" attribute of ACPI device objects are affected
by this issue.]
To avoid those deadlocks introduce a new protection mechanism that
can be used by the device sysfs attributes in question. Namely,
if a device sysfs attribute's .store() or .show() callback routine
is about to acquire device_hotplug_lock or acpi_scan_lock, it can
first execute read_lock_device_remove() and return an error code if
that function returns false. If true is returned, the lock in
question may be acquired and read_unlock_device_remove() must be
called. [This mechanism is implemented by means of an additional
rwsem in drivers/base/core.c.]
Make the affected sysfs attributes in the driver core and ACPI core
use read_lock_device_remove() and read_unlock_device_remove() as
described above.
Signed-off-by: Rafael J. Wysocki
Reported-by: Gu Zheng
>>>
>>> I'm sorry to forget to mention that the original reporter is
>>> Yasuaki Ishimatsu . I continued
>>> the investigation and found more issues.
>>>
>>> We tested this patch on kernel 3.11-rc6, but it seems that the
>>> issue is still there. Detail info as following.
>>
>> Well, taking pm_mutex under acpi_scan_lock (trace #2) is a bad idea anyway,
>> because we'll need to take acpi_scan_lock during system suspend for PCI hot
>> remove to work and that's under pm_mutex. So I wonder if we can simply
>> drop the system sleep locking from lock/unlock_memory_hotplug(). But that's
>> a side note, because dropping it won't help here.
>>
>> Now ->
>>
>>> ==
>>>
>>>
>>> [ INFO: possible circular locking dependency detected ]
>>>
>>>
>>> 3.11.0-rc6-lockdebug-refea+ #162 Tainted: GF
>>>
>>>
>>> ---
>>>
>>>
>>> kworker/0:2/754 is trying to acquire lock:
>>>
>>>
>>> (s_active#73){.+}, at: []
>>> sysfs_addrm_finish+0x3b/0x70
>>>
>>>
>>>
>>>
>>> but task is already holding lock:
>>>
>>>
>>> (mem_sysfs_mutex){+.+.+.}, at: []
>>> remove_memory_block+0x1d/0xa0
>>>
>>>
>>>
>>>
>>> which lock already depends on the new lock.
>>>
[PATCH/RFC v2] perf list: Skip unsupported events
From: Namhyung Kim
Some hardware events might not be supported on a system. Listing
those events seems meaningless and confusing to users. Let's skip
them.
Before:
$ perf list cache | wc -l
33
After:
$ perf list cache | wc -l
27
Signed-off-by: Namhyung Kim
---
* fixed a build error
tools/perf/util/parse-events.c | 41 +++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 9cba92386a82..69ea4c0cf0aa 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -15,6 +15,7 @@
#define YY_EXTRA_TYPE int
#include "parse-events-flex.h"
#include "pmu.h"
+#include "thread_map.h"
#define MAX_NAME_LEN 100
@@ -1072,6 +1073,33 @@ int is_valid_tracepoint(const char *event_string)
return 0;
}
+static bool is_event_supported(u8 type, unsigned config)
+{
+ bool ret = true;
+ struct perf_evsel *evsel;
+ struct perf_event_attr attr = {
+ .type = type,
+ .config = config,
+ .disabled = 1,
+ .exclude_kernel = 1,
+ };
+ struct {
+ struct thread_map map;
+ int threads[1];
+ } tmap = {
+ .map.nr = 1,
+ .threads = { 0 },
+ };
+
+ evsel = perf_evsel__new(, 0);
+ if (evsel) {
+ ret = perf_evsel__open(evsel, NULL, ) >= 0;
+ perf_evsel__delete(evsel);
+ }
+
+ return ret;
+}
+
static void __print_events_type(u8 type, struct event_symbol *syms,
unsigned max)
{
@@ -1079,14 +1107,16 @@ static void __print_events_type(u8 type, struct
event_symbol *syms,
unsigned i;
for (i = 0; i < max ; i++, syms++) {
+ if (!is_event_supported(type, i))
+ continue;
+
if (strlen(syms->alias))
snprintf(name, sizeof(name), "%s OR %s",
syms->symbol, syms->alias);
else
snprintf(name, sizeof(name), "%s", syms->symbol);
- printf(" %-50s [%s]\n", name,
- event_type_descriptors[type]);
+ printf(" %-50s [%s]\n", name, event_type_descriptors[type]);
}
}
@@ -1115,6 +1145,10 @@ int print_hwcache_events(const char *event_glob, bool
name_only)
if (event_glob != NULL && !strglobmatch(name,
event_glob))
continue;
+ if (!is_event_supported(PERF_TYPE_HW_CACHE,
+ type | (op << 8) | (i
<< 16)))
+ continue;
+
if (name_only)
printf("%s ", name);
else
@@ -1144,6 +1178,9 @@ static void print_symbol_events(const char *event_glob,
unsigned type,
(syms->alias && strglobmatch(syms->alias, event_glob
continue;
+ if (!is_event_supported(type, i))
+ continue;
+
if (name_only) {
printf("%s ", syms->symbol);
continue;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] mm/hwpoison: change permission of corrupt-pfn/unpoison-pfn to 0200
Hwpoison inject doesn't implement read method for corrupt-pfn/unpoison-pfn
attributes:
# cat /sys/kernel/debug/hwpoison/corrupt-pfn
cat: /sys/kernel/debug/hwpoison/corrupt-pfn: Permission denied
# cat /sys/kernel/debug/hwpoison/unpoison-pfn
cat: /sys/kernel/debug/hwpoison/unpoison-pfn: Permission denied
This patch change the permission of corrupt-pfn/unpoison-pfn to 0200.
Reviewed-by: Naoya Horiguchi
Signed-off-by: Wanpeng Li
---
mm/hwpoison-inject.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/hwpoison-inject.c b/mm/hwpoison-inject.c
index 3a61efc..afc2daa 100644
--- a/mm/hwpoison-inject.c
+++ b/mm/hwpoison-inject.c
@@ -88,12 +88,12 @@ static int pfn_inject_init(void)
* hardware status change, hence do not require hardware support.
* They are mainly for testing hwpoison in software level.
*/
- dentry = debugfs_create_file("corrupt-pfn", 0600, hwpoison_dir,
+ dentry = debugfs_create_file("corrupt-pfn", 0200, hwpoison_dir,
NULL, _fops);
if (!dentry)
goto fail;
- dentry = debugfs_create_file("unpoison-pfn", 0600, hwpoison_dir,
+ dentry = debugfs_create_file("unpoison-pfn", 0200, hwpoison_dir,
NULL, _fops);
if (!dentry)
goto fail;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] mm/hwpoison: fix return value of madvise_hwpoison
The return value outside for loop is always zero which means madvise_hwpoison
return success, however, this is not truth for soft_offline_page w/ failure
return value.
Signed-off-by: Wanpeng Li
---
mm/madvise.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index a20764c..19b71e4 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -359,7 +359,7 @@ static int madvise_hwpoison(int bhv, unsigned long start,
unsigned long end)
page_to_pfn(p), start);
ret = soft_offline_page(p, MF_COUNT_INCREASED);
if (ret)
- break;
+ return ret;
continue;
}
pr_info("Injecting memory failure for page %#lx at %#lx\n",
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] mm/hwpoison: fix bug triggered by unpoison empty zero page
v1 -> v2:
* ignore empty zero page for madvise_hwpoison directly
[ 57.579580] Injecting memory failure for page 0x19d0 at 0xb77d2000
[ 57.579824] MCE 0x19d0: non LRU page recovery: Ignored
[ 91.290453] MCE: Software-unpoisoned page 0x19d0
[ 91.290456] BUG: Bad page state in process bash pfn:019d0
[ 91.290466] page:f3461a00 count:0 mapcount:0 mapping: (null) index:0x0
[ 91.290467] page flags: 0x4404(referenced|reserved)
[ 91.290469] Modules linked in: nfsd auth_rpcgss i915 nfs_acl nfs lockd video
drm_kms_helper drm bnep rfcomm sunrpc bluetooth psmouse parport_pc ppdev lp
serio_raw fscache parport gpio_ich lpc_ich mac_hid i2c_algo_bit tpm_tis wmi
usb_storage hid_generic usbhid hid e1000e firewire_ohci firewire_core ahci ptp
libahci pps_core crc_itu_t
[ 91.290486] CPU: 3 PID: 2123 Comm: bash Not tainted 3.11.0-rc6+ #12
[ 91.290487] Hardware name: LENOVO 7034DD7/, BIOS 9HKT47AUS 01//2012
[ 91.290488] e9625ea0 c15ec49b f3461a00 e9625eb8 c15ea119
c17cbf18
[ 91.290491] ef084314 19d0 f3461a00 e9625ed8 c110dc8a f3461a00 0001
[ 91.290494] f3461a00 4404 e9625ef8 c110dcc1 f3461a00 f3461a00
19d0
[ 91.290497] Call Trace:
[ 91.290501] [] dump_stack+0x41/0x52
[ 91.290504] [] bad_page+0xcf/0xeb
[ 91.290515] [] free_pages_prepare+0x12a/0x140
[ 91.290517] [] free_hot_cold_page+0x21/0x110
[ 91.290519] [] __put_single_page+0x21/0x30
[ 91.290521] [] put_page+0x25/0x40
[ 91.290524] [] unpoison_memory+0x107/0x200
[ 91.290526] [] ? ns_capable+0x27/0x60
[ 91.290528] [] hwpoison_unpoison+0x20/0x30
[ 91.290530] [] simple_attr_write+0xb6/0xd0
[ 91.290532] [] ? generic_fh_to_dentry+0x50/0x50
[ 91.290535] [] vfs_write+0xa0/0x1b0
[ 91.290537] [] ? generic_fh_to_dentry+0x50/0x50
[ 91.290539] [] SyS_write+0x4f/0x90
[ 91.290549] [] sysenter_do_call+0x12/0x22
[ 91.290550] Disabling lock debugging due to kernel taint
Testcase:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#define PAGES_TO_TEST 1
#define PAGE_SIZE 4096
int main(void)
{
char *mem;
mem = mmap(NULL, PAGES_TO_TEST * PAGE_SIZE,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0,
0);
if (madvise(mem, PAGES_TO_TEST * PAGE_SIZE, MADV_HWPOISON) == -1)
return -1;
munmap(mem, PAGES_TO_TEST * PAGE_SIZE);
return 0;
}
There is one page reference count for default empty zero page, madvise_hwpoison
add another one by get_user_pages_fast. memory_hwpoison reduce one page
reference
count since it's a non LRU page. unpoison_memory release the last page reference
count and free empty zero page to buddy system which is not correct since empty
zero page has PG_reserved flag. This patch fix it by ignore empty zero page for
madvise_hwpoison directly.
Suggested-by: Naoya Horiguchi
Signed-off-by: Wanpeng Li
---
mm/madvise.c| 2 ++
mm/memory-failure.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/mm/madvise.c b/mm/madvise.c
index 212f5f1..a20764c 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -352,6 +352,8 @@ static int madvise_hwpoison(int bhv, unsigned long start,
unsigned long end)
int ret = get_user_pages_fast(start, 1, 0, );
if (ret != 1)
return ret;
+ if (page_to_pfn(p) == my_zero_pfn(0))
+ continue;
if (bhv == MADV_SOFT_OFFLINE) {
pr_info("Soft offlining page %#lx at %#lx\n",
page_to_pfn(p), start);
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 7cdabc0..68cbca0 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1331,6 +1331,9 @@ int unpoison_memory(unsigned long pfn)
if (!pfn_valid(pfn))
return -ENXIO;
+ if (pfn == my_zero_pfn(0))
+ return 0;
+
p = pfn_to_page(pfn);
page = compound_head(p);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/4] add support for gcov format introduced in gcc 4.7
Hi Peter I can get the gcda for the kernel loadable module now. Yes, the virtual file is with size 0 and I saw the file is empty with 'vi' command. But, it has data with 'cat' or 'hexdump' command. Thanks. On Mon, Aug 26, 2013 at 10:19 PM, Peter Oberparleiter wrote: > On 26.08.2013 13:39, LF.Tan wrote: >> Hi all >> >> I am interested to enable Gcov on my platform (on a target board). I >> have tried to apply the 4 patches submitted by Frantisek Hrbata. But, >> the *.gcda is always empty. Note, I am using GCC 4.7.3. >> >> I have followed the steps in Documentation/gcov.txt. I've mounted the >> NFS filesystem and it has access to the kernel build directory on host >> machine.The path for the kernel source in host and target are same. >> >> Let said my kernel module is under drivers/misc, >> drivers/misc/module.ko. Turn on Gcov in drivers/misc/Makefile. >> >> 1. mount -t debugfs none /sys/kernel/debug/ >> 2. insmod /module.ko >> 3. Perform some actions to excute code in module.ko >> 4. rmmod /module.ko >> 5. Check /sys/kernel/debug/gcov//drivers/misc/. There is a soft >> link of module.gcno (I check the soft link is working), but >> module.gcda is empty. > > Are you sure they are empty? .gcda files report a file size of 0 as many > virtual files do, but you can read data from them nevertheless. You could > try running "cat" on them to copy their contents for example. > >> Any step is incorrect or missing? Or anyone know how to enable GCOV on >> target board? Please advice. >> I would like to enable GCOV in arch/ code as well. >> Thank you very much. > > -- > Peter Oberparleiter > Linux on System z Development - IBM Germany > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 11/12] pid: rewrite task helper functions avoiding task->pid and task->tgid
On Fri, Aug 23, 2013 at 08:36:21AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 22, 2013 at 05:43:47PM -0400, Richard Guy Briggs wrote:
> > On Thu, Aug 22, 2013 at 10:05:55PM +0200, Peter Zijlstra wrote:
> > > On Tue, Aug 20, 2013 at 05:32:03PM -0400, Richard Guy Briggs wrote:
> > > > This stops these four task helper functions from using the deprecated
> > > > and
> > > > error-prone task->pid and task->tgid.
> > > >
> > > > (informed by ebiederman's ea5a4d01)
> > > > Cc: "Eric W. Biederman"
> > > > Signed-off-by: Richard Guy Briggs
> > > > ---
> > > > include/linux/sched.h |8
> > > > 1 files changed, 4 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > > index 8e69807..46e739d 100644
> > > > --- a/include/linux/sched.h
> > > > +++ b/include/linux/sched.h
> > > > @@ -1579,7 +1579,7 @@ static inline int pid_alive(struct task_struct *p)
> > > > */
> > > > static inline int is_global_init(struct task_struct *tsk)
> > > > {
> > > > - return tsk->pid == 1;
> > > > + return task_pid_nr(tsk) == 1;
> > > > }
> > > >
> > > > extern struct pid *cad_pid;
> > > > @@ -1930,7 +1930,7 @@ extern struct task_struct *idle_task(int cpu);
> > > > */
> > > > static inline bool is_idle_task(const struct task_struct *p)
> > > > {
> > > > - return p->pid == 0;
> > > > + return task_pid(p) == _struct_pid;
> > > > }
> > > > extern struct task_struct *curr_task(int cpu);
> > > > extern void set_curr_task(int cpu, struct task_struct *p);
> > >
> > > Why would you ever want to do this? It just makes these tests more
> > > expensive for no gain what so ff'ing ever.
> >
> > Backups are generally considered a good idea, but in this case, I'd
> > quote:
> > "A man with one watch knows what time it is. A man with two is
> > never certain."
>
> Except that's not the case, with namespaces there's a clear hierarchy
> and the task_struct::pid is the one true value aka. root namespace.
Peter, I agonized over the access efficiency of dropping this one or the
duplicate in task_struct::pids and this one was far easier to drop in
terms of somehow always forcing
task->pids[PIDTYPE_PID].pid->numbers[0].nr to point to task->pid.
It should be possible to audit the kernel to make certain task->pid is
only ever written at the time of task creation and copied to its own
task->pids[PIDTYPE_PID].pid->numbers[0].nr at the time of task creation
so that the two values are consistent. Continuously auditing the kernel
so this is the case would be a bit more of a challenge.
Would it be reasonable to suggest task_struct::pid only be accessed by
the existing inlined task_pid_nr() converted to const?
The goal is to gain assurance that any PIDs referred to in audit logs
are indisputable.
Would you be alright with doing away with task_struct::tgid?
> Furthermore idle threads really are special and it doesn't make sense to
> address them in any but the root namespace, doubly so because only
> kernel space does this.
If that is the case, and the above holds true, then we don't need the
second hunk, I agree.
> As for the init thread, that function is called is_global_init() for
> crying out loud, what numb nut doesn't get that that's supposed to be
> using the root namespace?
A process in another pid namespace? If that's never going to happen,
then drop it.
> Seriously, you namespace guys should stop messing things up and
> confusing yourselves and others.
"you namespace guys"? I'm not a namespace guy. I'm a rusty kernel
network security guy taking on audit, trying to prepare it for moving
into a more and more namespace-enabled place of
containerization/light-virtualization.
We aren't ready for it yet, but there is demand to run additional auditd
daemons in other pid namespaces and some of this work is trying to move
in that direction.
This patchset certainly wasn't intended to be ready for adoption just
yet. It was this sort of discussion I was hoping to have.
- RGB
--
Richard Guy Briggs
Senior Software Engineer
Kernel Security
AMER ENG Base Operating Systems
Remote, Ottawa, Canada
Voice: +1.647.777.2635
Internal: (81) 32635
Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/RFC] perf list: Skip unsupported events
From: Namhyung Kim
Some hardware events might not be supported on a system. Listing
those events seems meaningless and confusing to users. Let's skip
them.
Before:
$ perf list cache | wc -l
33
After:
$ perf list cache | wc -l
27
Signed-off-by: Namhyung Kim
---
tools/perf/util/parse-events.c | 41 +++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 9cba92386a82..b5e5860c5484 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -15,6 +15,7 @@
#define YY_EXTRA_TYPE int
#include "parse-events-flex.h"
#include "pmu.h"
+#include "thread_map.h"
#define MAX_NAME_LEN 100
@@ -1072,6 +1073,33 @@ int is_valid_tracepoint(const char *event_string)
return 0;
}
+bool is_event_supported(u8 type, unsigned config)
+{
+ bool ret = true;
+ struct perf_evsel *evsel;
+ struct perf_event_attr attr = {
+ .type = type,
+ .config = config,
+ .disabled = 1,
+ .exclude_kernel = 1,
+ };
+ struct {
+ struct thread_map map;
+ int threads[1];
+ } tmap = {
+ .map.nr = 1,
+ .threads = { 0 },
+ };
+
+ evsel = perf_evsel__new(, 0);
+ if (evsel) {
+ ret = perf_evsel__open(evsel, NULL, ) >= 0;
+ perf_evsel__delete(evsel);
+ }
+
+ return ret;
+}
+
static void __print_events_type(u8 type, struct event_symbol *syms,
unsigned max)
{
@@ -1079,14 +1107,16 @@ static void __print_events_type(u8 type, struct
event_symbol *syms,
unsigned i;
for (i = 0; i < max ; i++, syms++) {
+ if (!is_event_supported(type, i))
+ continue;
+
if (strlen(syms->alias))
snprintf(name, sizeof(name), "%s OR %s",
syms->symbol, syms->alias);
else
snprintf(name, sizeof(name), "%s", syms->symbol);
- printf(" %-50s [%s]\n", name,
- event_type_descriptors[type]);
+ printf(" %-50s [%s]\n", name, event_type_descriptors[type]);
}
}
@@ -1115,6 +1145,10 @@ int print_hwcache_events(const char *event_glob, bool
name_only)
if (event_glob != NULL && !strglobmatch(name,
event_glob))
continue;
+ if (!is_event_supported(PERF_TYPE_HW_CACHE,
+ type | (op << 8) | (i
<< 16)))
+ continue;
+
if (name_only)
printf("%s ", name);
else
@@ -1144,6 +1178,9 @@ static void print_symbol_events(const char *event_glob,
unsigned type,
(syms->alias && strglobmatch(syms->alias, event_glob
continue;
+ if (!is_event_supported(type, i))
+ continue;
+
if (name_only) {
printf("%s ", syms->symbol);
continue;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v14 0/6] LSM: Multiple concurrent LSMs
On 8/6/2013 3:36 PM, Kees Cook wrote:
> On Tue, Aug 6, 2013 at 3:25 PM, Casey Schaufler
> wrote:
>> On 8/5/2013 11:30 PM, Kees Cook wrote:
>>> On Thu, Jul 25, 2013 at 11:52 PM, Casey Schaufler
>>> wrote:
The /proc/*/attr interfaces are given to one LSM. This can be
done by setting CONFIG_SECURITY_PRESENT. Additional interfaces
have been created in /proc/*/attr so that each LSM has its own
named interfaces. The name of the presenting LSM can be read from
>>> For me, this is one problem that was bothering me, but it was a cosmetic
>>> one that I'd mentioned before: I really disliked the /proc/$pid/attr
>>> interface being named "$lsm.$file". I feel it's important to build
>>> directories in attr/ for each LSM. So, I spent time to figure out a way to
>>> do this. This patch changes the interface to /proc/$pid/attr/$lsm/$file
>>> instead, which I feel has a much more appealing organizational structure.
>> I will confess that the reason I went with .current instead of
>> /current was that the former was easier to implement.
> Yeah, that's totally fine. It wasn't very obvious (to me) how to
> implement this initially, so no problem at all. I'm glad there was
> something more than bug fixes I could contribute to this series. :)
Oh dear. I'm rebasing for 3.12 and the macros don't generate compiling
code any longer. It seems that, among other things, readdir is no longer
a member of file_operations.
>
>>> -Kees
>>>
>>> ---
>>> Subject: [PATCH] LSM: use subdirectories for LSM attr files
>>>
>>> Instead of filling the /proc/$pid/attr/ directory with every LSM's needed
>>> attr files, insert a directory entry for each LSM which contains the
>>> needed files.
>>>
>>> Signed-off-by: Kees Cook
>>> ---
>>> fs/proc/base.c | 95
>>> --
>>> fs/proc/internal.h |1 +
>>> include/linux/security.h | 11 +++---
>>> security/security.c | 67 ++--
>>> 4 files changed, 112 insertions(+), 62 deletions(-)
>>>
>>> diff --git a/fs/proc/base.c b/fs/proc/base.c
>>> index 941fe83..4c80ffd 100644
>>> --- a/fs/proc/base.c
>>> +++ b/fs/proc/base.c
>>> @@ -138,6 +138,10 @@ struct pid_entry {
>>> NOD(NAME, (S_IFREG|(MODE)), \
>>> NULL, _single_file_operations, \
>>> { .proc_show = show } )
>>> +#define ATTR(LSM, NAME, MODE)\
>>> + NOD(NAME, (S_IFREG|(MODE)), \
>>> + NULL, _pid_attr_operations,\
>>> + { .lsm = LSM } )
>>>
>>> /*
>>> * Count the number of hardlinks for the pid_entry table, excluding the .
>>> @@ -2292,7 +2296,7 @@ static ssize_t proc_pid_attr_read(struct file * file,
>>> char __user * buf,
>>> if (!task)
>>> return -ESRCH;
>>>
>>> - length = security_getprocattr(task,
>>> + length = security_getprocattr(task, PROC_I(inode)->op.lsm,
>>> (char*)file->f_path.dentry->d_name.name,
>>> );
>>> put_task_struct(task);
>>> @@ -2335,7 +2339,7 @@ static ssize_t proc_pid_attr_write(struct file *
>>> file, const char __user * buf,
>>> if (length < 0)
>>> goto out_free;
>>>
>>> - length = security_setprocattr(task,
>>> + length = security_setprocattr(task, PROC_I(inode)->op.lsm,
>>> (char*)file->f_path.dentry->d_name.name,
>>> (void*)page, count);
>>> mutex_unlock(>signal->cred_guard_mutex);
>>> @@ -2353,29 +2357,82 @@ static const struct file_operations
>>> proc_pid_attr_operations = {
>>> .llseek = generic_file_llseek,
>>> };
>>>
>>> +#define LSM_DIR_OPS(LSM) \
>>> +static int proc_##LSM##_attr_dir_readdir(struct file * filp, \
>>> + void * dirent, filldir_t filldir) \
>>> +{ \
>>> + return proc_pident_readdir(filp, dirent, filldir, \
>>> +LSM##_attr_dir_stuff, \
>>> +ARRAY_SIZE(LSM##_attr_dir_stuff)); \
>>> +} \
>>> +\
>>> +static const struct file_operations proc_##LSM##_attr_dir_ops = { \
>>> + .read = generic_read_dir, \
>>> + .readdir= proc_##LSM##_attr_dir_readdir, \
>>> + .llseek = default_llseek, \
>>> +}; \
>>> +\
>>> +static struct dentry *proc_##LSM##_attr_dir_lookup(struct inode *dir, \
>>> + struct dentry *dentry, unsigned int flags) \
>>> +{ \
>>> + return proc_pident_lookup(dir, dentry, \
>>> + LSM##_attr_dir_stuff, \
>>> + ARRAY_SIZE(LSM##_attr_dir_stuff)); \
>>> +} \
>>> +\
>>> +static const struct inode_operations proc_##LSM##_attr_dir_inode_ops = { \
>>> + .lookup = proc_##LSM##_attr_dir_lookup, \
>>> + .getattr= pid_getattr, \
>>> + .setattr= proc_setattr, \
>>> +};
[PATCH] ARM: EDMA: Fix clearing of unused list for DT DMA resources
HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear.
This patch fixes the issue, by reading the "dmas" property from the DT node if
it exists and clearing the bits in the unused channel list. For this purpose
we use the of_* helpers to parse the arguments in the dmas phandle list.
Reviewed-by: Sekhar Nori
Reported-by: Balaji T K
Cc: Pantel Antoniou
Signed-off-by: Joel Fernandes
---
Changes since v1, in v2 and v3:
- Reduced indentation of non-of case by returning from of-case
- Using of_* helpers for parsing
Note:
This patch should go into the merge window as it is a critical bug fix.
arch/arm/common/edma.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 39ad030..43c7b22 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -560,14 +560,33 @@ static int reserve_contiguous_slots(int ctlr, unsigned
int id,
static int prepare_unused_channel_list(struct device *dev, void *data)
{
struct platform_device *pdev = to_platform_device(dev);
- int i, ctlr;
+ int i, count, ctlr;
+ struct of_phandle_args dma_spec;
+ if (dev->of_node) {
+ count = of_property_count_strings(dev->of_node, "dma-names");
+ if (count < 0)
+ return 0;
+ for (i = 0; i < count; i++) {
+ if (of_parse_phandle_with_args(dev->of_node, "dmas",
+ "#dma-cells", i,
+ _spec))
+ continue;
+
+ ctlr = EDMA_CTLR(dma_spec.args[0]);
+ clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]),
+ edma_cc[ctlr]->edma_unused);
+ }
+ return 0;
+ }
+
+ /* For non-OF case */
for (i = 0; i < pdev->num_resources; i++) {
if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
(int)pdev->resource[i].start >= 0) {
ctlr = EDMA_CTLR(pdev->resource[i].start);
clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
- edma_cc[ctlr]->edma_unused);
+ edma_cc[ctlr]->edma_unused);
}
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] USB fixe for 3.11-rc8
The following changes since commit d8dfad3876e438b759da3c833d62fb8b2267: Linux 3.11-rc7 (2013-08-25 17:43:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.11-rc8 for you to fetch changes up to d3474049ab6cfcf14274f5ab9f20c8f50b083eab: USB: OHCI: fix build error related to ohci_suspend/resume (2013-08-26 15:22:15 -0700) USB bugfix for 3.11-rc8 Here is a single bugfix that resolves the "can not build the OHCI driver with CONFIG_PM disabled" problem that lots of people have been reporting with 3.11-rc7. Sorry about that one, it missed my build tests, and it seems, a number of others as well. Thank goodness for Guenter :) Signed-off-by: Greg Kroah-Hartman Alan Stern (1): USB: OHCI: fix build error related to ohci_suspend/resume drivers/usb/host/ohci-pci.c | 2 ++ 1 file changed, 2 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kernel: Assembly: need add prefix for h8300 architecture.
On 08/26/2013 06:46 PM, Chen Gang wrote:
>
> If this implementation is correct, the implementation still can be
> improved (at least, it is not quite well to hard code the architecture
> related code in "kernel/" and "usr/" sub-directory).
>
> But it seems, I have no right to add or move files, so welcome any
> members help do it.
>
Sorry, what I said above ("...have no right...") is not quite precise:
it is only my current feelings, maybe misunderstand something.
also maybe can find better fixing ways more than "add or move files".
Thanks.
> And welcome any additional suggestions or completions.
>
> Thanks.
>
> On 08/26/2013 06:42 PM, Chen Gang wrote:
>> Need add related prefix for h8300, or can not pass compiling by the
>> latest linker.
>>
>> The related error (allmodconfig for h8300):
>>
>> /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file
>> `usr/initramfs_data.o' is incompatible with h8300h output
>> /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file
>> `kernel/modsign_certificate.o' is incompatible with h8300h output
>>
>> The cross-compiler's information:
>>
>> [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-ld -v
>> GNU ld (GNU Binutils) 2.22
>> [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-as -v
>> GNU assembler version 2.22 (h8300-gchen-elf) using BFD version (GNU
>> Binutils) 2.22
>>
>> [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc
>>
>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.8.0/lto-wrapper
>> Target: h8300-gchen-elf
>> Configured with: ../gcc-4.8.0/configure --target=h8300-gchen-elf
>> --without-header --disable-nls --enable-language=c --disable-threads
>> --disable-shared --enable-werror=no
>> Thread model: single
>> gcc version 4.8.0 (GCC)
>>
>>
>> Signed-off-by: Chen Gang
>> ---
>> kernel/modsign_certificate.S |7 +++
>> usr/initramfs_data.S |7 +++
>> 2 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S
>> index 4a9a86d..d24acac 100644
>> --- a/kernel/modsign_certificate.S
>> +++ b/kernel/modsign_certificate.S
>> @@ -1,5 +1,12 @@
>> #include
>>
>> +#if defined(CONFIG_CPU_H8300H)
>> +.h8300h
>> +#endif
>> +#if defined(CONFIG_CPU_H8S)
>> +.h8300s
>> +#endif
>> +
>> #define GLOBAL(name)\
>> .globl VMLINUX_SYMBOL(name);\
>> VMLINUX_SYMBOL(name):
>> diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S
>> index c14322d..6a6c106 100644
>> --- a/usr/initramfs_data.S
>> +++ b/usr/initramfs_data.S
>> @@ -24,6 +24,13 @@
>> #include
>> #include
>>
>> +#if defined(CONFIG_CPU_H8300H)
>> +.h8300h
>> +#endif
>> +#if defined(CONFIG_CPU_H8S)
>> +.h8300s
>> +#endif
>> +
>> .section .init.ramfs,"a"
>> __irf_start:
>> .incbin __stringify(INITRAMFS_IMAGE)
>>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ARM ATTEND] catching up on exploit mitigations
On 8/26/2013 12:56 PM, Mark Brown wrote: On Mon, Aug 12, 2013 at 09:51:59PM -0700, Laura Abbott wrote: On 7/30/2013 12:05 PM, Kees Cook wrote: - RO and W^X kernel page table protections (similar to x86's DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much LPAE and PXN is already handling this, if at all) We've had support for RO/NX on our tree for a while. I'm interested in attending the summit to share what we've done and to see how much of it could be mainlined. Is that related to the code that Google have in their tree? It's 'related' in that it covers some of the same use cases but the two were developed independently as far as I know. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core / ACPI: Avoid device removal locking problems
Hi Rafael,
On 08/26/2013 10:43 PM, Rafael J. Wysocki wrote:
> On Monday, August 26, 2013 02:42:09 PM Rafael J. Wysocki wrote:
>> On Monday, August 26, 2013 11:13:13 AM Gu Zheng wrote:
>>> Hi Rafael,
>>
>> Hi,
>>
>>> On 08/26/2013 04:09 AM, Rafael J. Wysocki wrote:
>>>
From: Rafael J. Wysocki
There are two mutexes, device_hotplug_lock and acpi_scan_lock, held
around the acpi_bus_trim() call in acpi_scan_hot_remove() which
generally removes devices (it removes ACPI device objects at least,
but it may also remove "physical" device objects through .detach()
callbacks of ACPI scan handlers). Thus, potentially, device sysfs
attributes are removed under these locks and to remove those
attributes it is necessary to hold the s_active references of their
directory entries for writing.
On the other hand, the execution of a .show() or .store() callback
from a sysfs attribute is carried out with that attribute's s_active
reference held for reading. Consequently, if any device sysfs
attribute that may be removed from within acpi_scan_hot_remove()
through acpi_bus_trim() has a .store() or .show() callback which
acquires either acpi_scan_lock or device_hotplug_lock, the execution
of that callback may deadlock with the removal of the attribute.
[Unfortunately, the "online" device attribute of CPUs and memory
blocks and the "eject" attribute of ACPI device objects are affected
by this issue.]
To avoid those deadlocks introduce a new protection mechanism that
can be used by the device sysfs attributes in question. Namely,
if a device sysfs attribute's .store() or .show() callback routine
is about to acquire device_hotplug_lock or acpi_scan_lock, it can
first execute read_lock_device_remove() and return an error code if
that function returns false. If true is returned, the lock in
question may be acquired and read_unlock_device_remove() must be
called. [This mechanism is implemented by means of an additional
rwsem in drivers/base/core.c.]
Make the affected sysfs attributes in the driver core and ACPI core
use read_lock_device_remove() and read_unlock_device_remove() as
described above.
Signed-off-by: Rafael J. Wysocki
Reported-by: Gu Zheng
>>>
>>> I'm sorry to forget to mention that the original reporter is
>>> Yasuaki Ishimatsu . I continued
>>> the investigation and found more issues.
>>>
>>> We tested this patch on kernel 3.11-rc6, but it seems that the
>>> issue is still there. Detail info as following.
>>
>> Well, taking pm_mutex under acpi_scan_lock (trace #2) is a bad idea anyway,
>> because we'll need to take acpi_scan_lock during system suspend for PCI hot
>> remove to work and that's under pm_mutex. So I wonder if we can simply
>> drop the system sleep locking from lock/unlock_memory_hotplug(). But that's
>> a side note, because dropping it won't help here.
>>
>> Now ->
>>
>>> ==
>>>
>>>
>>> [ INFO: possible circular locking dependency detected ]
>>>
>>>
>>> 3.11.0-rc6-lockdebug-refea+ #162 Tainted: GF
>>>
>>>
>>> ---
>>>
>>>
>>> kworker/0:2/754 is trying to acquire lock:
>>>
>>>
>>> (s_active#73){.+}, at: []
>>> sysfs_addrm_finish+0x3b/0x70
>>>
>>>
>>>
>>>
>>> but task is already holding lock:
>>>
>>>
>>> (mem_sysfs_mutex){+.+.+.}, at: []
>>> remove_memory_block+0x1d/0xa0
>>>
>>>
>>>
>>>
>>> which lock already depends on the new lock.
>>>
Re: [PATCH] h8300/kernel/setup.c: add "linux/initrd.h" to pass compiling
On 08/27/2013 06:12 AM, Guenter Roeck wrote:
> On Mon, Aug 26, 2013 at 07:19:38PM +0800, Chen Gang wrote:
>> On 08/26/2013 07:08 PM, Geert Uytterhoeven wrote:
>>> On Mon, Aug 26, 2013 at 1:06 PM, Chen Gang wrote:
On 08/26/2013 07:00 PM, Geert Uytterhoeven wrote:
> On Mon, Aug 26, 2013 at 12:31 PM, Chen Gang wrote:
>> --- a/arch/h8300/kernel/setup.c
>> +++ b/arch/h8300/kernel/setup.c
>> @@ -47,6 +47,9 @@
>> #include
>> #endif
>>
>> +#if defined(CONFIG_BLK_DEV_INITRD)
>
> Why have you added the #ifdef?
>
The related code is below (maybe we need add additional related
comments in the patch for it ?).
in arch/h8300/kernel/setup.c
94 void __init setup_arch(char **cmdline_p)
95 {
96 int bootmap_size;
97
98 memory_start = (unsigned long) &_ramstart;
99
100 /* allow for ROMFS on the end of the kernel */
101 if (memcmp((void *)memory_start, "-rom1fs-", 8) == 0) {
102 #if defined(CONFIG_BLK_DEV_INITRD)
103 initrd_start = memory_start;
104 initrd_end = memory_start += be32_to_cpu(((unsigned
long *) (memory_start))[2]);
105 #else
106 memory_start += be32_to_cpu(((unsigned long *)
memory_start)[2]);
107 #endif
108 }
>>>
>>> Sure, it's used conditionally. But it doesn't harm to always include it.
>>> That means less #ifdefs in the code.
>>>
>>
>> Hmm... I feel, add "#ifdefs" can make the code more clearer (consistent
>> with the "#ifdefs" 'for initrd_start' and 'end').
>>
> The goal in the Linux kernel is to reduce the amount of ifdefs in the code
> by moving conditional code as much as possible into header files. That
> actually
> has a practical advantage - it ensures that all code is compiled.
>
Yeah, it should be.
> You may agree or disagree with this approach, but you should follow it and not
> add new ifdefs when you write kernel code, much less unnecessary ones.
> If anything, you might try to remove existing ifdefs while you are at it.
>
Of cause, I agree.
And do you guess: "I do not agree with it" ?
>> For C code readers, more code doesn't mean more complex, if it can make
>> things clearer after add some more lines (and be sure of no negative
>> effect with performance), normally I prefer to add some more lines.
>>
> The Linux kernel community tends to think otherwise. For my part I don't
> see how ifdefs, and much more so unecessary ones, make anything clearer.
> I would argue you'll end up not seeing the forest because of all the trees.
>
Hmm... it seems the 'clearer' depends on personal feelings (and 'clear'
does not mean 'code style').
For my feeling, when the code is more match the 'real world' and more
consistent with each other, it will be more clearer (maybe it is in
'bad code style').
In fact, 'forest' is not conflict with "all the trees", when we feel we
need discuss about it, it means both of them need improving.
for satisfy "all the trees": need fix the issue.
for satisfy "forest": need beautify code.
>> And this file has already had an area for all "#ifdefs include", I just
>> add it in this area, so at least, it can mach this file well, is it ?
>>
> Your argument is along the line of "the code is bad anyway, so it is ok
> to make it worse". Not really a good argument if you want to get your code
> accepted.
>
So we need divide our current discussion contents into 2 patches.
1st patch is for issue fix. it should follow the original 'coding styles' no
matter whether it is good or bad.
(it is just current patch).
2nd patch is for 'beautify code', it should use 'correct' coding styles.
(if possible I will send 2nd patch for it, it is not a bad idea to me if it
can be applied). ;-)
> I would suggest to read Documentation/SubmittingPatches, section 2.2,
> before you continue with your line of argument.
>
Yeah, I have already read it 6 months ago.
Hmm... but it is not bad idea for every members to read it once more
(including you and me).
> Guenter
>
>
Thanks.
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 f2fs tree
Hi Jaegeuk,
After merging the f2fs tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/f2fs/namei.c: In function 'f2fs_rename':
fs/f2fs/namei.c:450:31: error: expected ';' before ':' token
update_inode_page(old_inode):
^
Caused by commit 2e569fefc95a ("f2fs: fix omitting to update inode page").
Not even build tested :-(
I have used the f2fs tree from next-20130822 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpKSqyNCSDhD.pgp
Description: PGP signature
Re: [PATCH v4 8/10] mm/hwpoison: fix memory failure still hold reference count after unpoison empty zero page
On Tue, Aug 27, 2013 at 09:17:29AM +0800, Wanpeng Li wrote: > On Mon, Aug 26, 2013 at 08:46:54PM -0400, Naoya Horiguchi wrote: > >On Tue, Aug 27, 2013 at 08:21:05AM +0800, Wanpeng Li wrote: > >> Hi Naoya, > >> On Mon, Aug 26, 2013 at 08:12:29PM -0400, Naoya Horiguchi wrote: > >> >Hi Wanpeng, > >> > > >> >On Tue, Aug 27, 2013 at 07:26:04AM +0800, Wanpeng Li wrote: > >> >> Hi Naoya, > >> >> On Mon, Aug 26, 2013 at 11:45:37AM -0400, Naoya Horiguchi wrote: > >> >> >On Mon, Aug 26, 2013 at 04:46:12PM +0800, Wanpeng Li wrote: > >> >> >> madvise hwpoison inject will poison the read-only empty zero page if > >> >> >> there is > >> >> >> no write access before poison. Empty zero page reference count will > >> >> >> be increased > >> >> >> for hwpoison, subsequent poison zero page will return directly since > >> >> >> page has > >> >> >> already been set PG_hwpoison, however, page reference count is still > >> >> >> increased > >> >> >> by get_user_pages_fast. The unpoison process will unpoison the empty > >> >> >> zero page > >> >> >> and decrease the reference count successfully for the fist time, > >> >> >> however, > >> >> >> subsequent unpoison empty zero page will return directly since page > >> >> >> has already > >> >> >> been unpoisoned and without decrease the page reference count of > >> >> >> empty zero page. > >> >> >> This patch fix it by decrease page reference count for empty zero > >> >> >> page which has > >> >> >> already been unpoisoned and page count > 1. > >> >> > > >> >> >I guess that fixing on the madvise side looks reasonable to me, > >> >> >because this > >> >> >refcount mismatch happens only when we poison with madvise(). The root > >> >> >cause > >> >> >is that we can get refcount multiple times on a page, even if > >> >> >memory_failure() > >> >> >or soft_offline_page() can do its work only once. > >> >> > > >> >> > >> >> I think this just happen in read-only before poison case against empty > >> >> zero page. > >> > > >> >OK. I agree. > >> > > >> >> Hi Andrew, > >> >> > >> >> I see you have already merged the patch, which method you prefer? > >> >> > >> >> >How about making madvise_hwpoison() put a page and return immediately > >> >> >(without calling memory_failure() or soft_offline_page()) when the page > >> >> >is already hwpoisoned? > >> >> >I hope it also helps us avoid meaningless printk flood. > >> >> > > >> >> > >> >> Btw, Naoya, how about patch 10/10, any input are welcome! ;-) > >> > > >> >No objection if you (and Andrew) decide to go with current approach. > >> > >> Andrew prefer your method, I will resend the patch w/ your suggested-by. > >> ;-) > > > >Thanks you :) > > > >> >But I think that if we shift to fix this problem in madvise(), > >> >we don't need 10/10 any more. So it looks simpler to me. > >> > >> I don't think it's same issue. There is just one page in my test case. > >> #define PAGES_TO_TEST 1 > >> If I miss something? > > > >Ah, OK. > > I complete do it in madvise codes, however, the bug mentioned in patch > 10/10 is still there. ;-) > > > > >BTW, in my understanding, zero pages are not exist physically (I mean that > >no real page is allocated to store 4096 bytes of 0.) So there can't happen > >any real MCE SRAO on zero page. So one possible solution might be that we > >completely ignore all of madvise(MADV_HWPOISON) over zero pages. > > What's the userland visible difference against mmap w/o write access before > poison > you expect? In this case the userland is a test program like mce-test, so my expectation is that the test program shouldn't detect false test failures when it accidentally calls madvise(MADV_HWPOISON) on zero pages, because there's no real test target associated with such testcases. So I think just returning with success return code without doing anything looks good. Thanks, Naoya Horiguchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] mm/hwpoison: change permission of corrupt-pfn/unpoison-pfn to 0200
Hwpoison inject doesn't implement read method for corrupt-pfn/unpoison-pfn
attributes:
# cat /sys/kernel/debug/hwpoison/corrupt-pfn
cat: /sys/kernel/debug/hwpoison/corrupt-pfn: Permission denied
# cat /sys/kernel/debug/hwpoison/unpoison-pfn
cat: /sys/kernel/debug/hwpoison/unpoison-pfn: Permission denied
This patch change the permission of corrupt-pfn/unpoison-pfn to 0200.
Reviewed-by: Naoya Horiguchi
Signed-off-by: Wanpeng Li
---
mm/hwpoison-inject.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/hwpoison-inject.c b/mm/hwpoison-inject.c
index 3a61efc..afc2daa 100644
--- a/mm/hwpoison-inject.c
+++ b/mm/hwpoison-inject.c
@@ -88,12 +88,12 @@ static int pfn_inject_init(void)
* hardware status change, hence do not require hardware support.
* They are mainly for testing hwpoison in software level.
*/
- dentry = debugfs_create_file("corrupt-pfn", 0600, hwpoison_dir,
+ dentry = debugfs_create_file("corrupt-pfn", 0200, hwpoison_dir,
NULL, _fops);
if (!dentry)
goto fail;
- dentry = debugfs_create_file("unpoison-pfn", 0600, hwpoison_dir,
+ dentry = debugfs_create_file("unpoison-pfn", 0200, hwpoison_dir,
NULL, _fops);
if (!dentry)
goto fail;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] mm/hwpoison: fix memory failure still hold reference count after unpoison empty zero page
madvise hwpoison inject will poison the read-only empty zero page if there is
no write access before poison. Empty zero page reference count will be
increased
for hwpoison, subsequent poison zero page will return directly since page has
already been set PG_hwpoison, however, page reference count is still increased
by get_user_pages_fast. The unpoison process will unpoison the empty zero page
and decrease the reference count successfully for the fist time, however,
subsequent unpoison empty zero page will return directly since page has already
been unpoisoned and without decrease the page reference count of empty zero
page.
This patch fix it by make madvise_hwpoison() put a page and return immediately
(without calling memory_failure() or soft_offline_page()) when the page is
already
hwpoisoned.
Testcase:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#define PAGES_TO_TEST 3
#define PAGE_SIZE 4096
int main(void)
{
char *mem;
int i;
mem = mmap(NULL, PAGES_TO_TEST * PAGE_SIZE,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0,
0);
if (madvise(mem, PAGES_TO_TEST * PAGE_SIZE, MADV_HWPOISON) == -1)
return -1;
munmap(mem, PAGES_TO_TEST * PAGE_SIZE);
return 0;
}
Add printk to dump page reference count:
[ 93.075959] Injecting memory failure for page 0x19d0 at 0xb77d8000
[ 93.076207] MCE 0x19d0: non LRU page recovery: Ignored
[ 93.076209] pfn 0x19d0, page count = 1 after memory failure
[ 93.076220] Injecting memory failure for page 0x19d0 at 0xb77d9000
[ 93.076221] MCE 0x19d0: already hardware poisoned
[ 93.076222] pfn 0x19d0, page count = 2 after memory failure
[ 93.076224] Injecting memory failure for page 0x19d0 at 0xb77da000
[ 93.076224] MCE 0x19d0: already hardware poisoned
[ 93.076225] pfn 0x19d0, page count = 3 after memory failure
Suggested-by: Naoya Horiguchi
Signed-off-by: Wanpeng Li
---
mm/madvise.c | 4
1 file changed, 4 insertions(+)
diff --git a/mm/madvise.c b/mm/madvise.c
index 212f5f1..0956ae9 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -352,6 +352,10 @@ static int madvise_hwpoison(int bhv, unsigned long start,
unsigned long end)
int ret = get_user_pages_fast(start, 1, 0, );
if (ret != 1)
return ret;
+ if (PageHWPoison(p)) {
+ put_page(p);
+ continue;
+ }
if (bhv == MADV_SOFT_OFFLINE) {
pr_info("Soft offlining page %#lx at %#lx\n",
page_to_pfn(p), start);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] mm/hwpoison: fix bug triggered by unpoison empty zero page
[ 57.579580] Injecting memory failure for page 0x19d0 at 0xb77d2000
[ 57.579824] MCE 0x19d0: non LRU page recovery: Ignored
[ 91.290453] MCE: Software-unpoisoned page 0x19d0
[ 91.290456] BUG: Bad page state in process bash pfn:019d0
[ 91.290466] page:f3461a00 count:0 mapcount:0 mapping: (null) index:0x0
[ 91.290467] page flags: 0x4404(referenced|reserved)
[ 91.290469] Modules linked in: nfsd auth_rpcgss i915 nfs_acl nfs lockd video
drm_kms_helper drm bnep rfcomm sunrpc bluetooth psmouse parport_pc ppdev lp
serio_raw fscache parport gpio_ich lpc_ich mac_hid i2c_algo_bit tpm_tis wmi
usb_storage hid_generic usbhid hid e1000e firewire_ohci firewire_core ahci ptp
libahci pps_core crc_itu_t
[ 91.290486] CPU: 3 PID: 2123 Comm: bash Not tainted 3.11.0-rc6+ #12
[ 91.290487] Hardware name: LENOVO 7034DD7/, BIOS 9HKT47AUS 01//2012
[ 91.290488] e9625ea0 c15ec49b f3461a00 e9625eb8 c15ea119
c17cbf18
[ 91.290491] ef084314 19d0 f3461a00 e9625ed8 c110dc8a f3461a00 0001
[ 91.290494] f3461a00 4404 e9625ef8 c110dcc1 f3461a00 f3461a00
19d0
[ 91.290497] Call Trace:
[ 91.290501] [] dump_stack+0x41/0x52
[ 91.290504] [] bad_page+0xcf/0xeb
[ 91.290515] [] free_pages_prepare+0x12a/0x140
[ 91.290517] [] free_hot_cold_page+0x21/0x110
[ 91.290519] [] __put_single_page+0x21/0x30
[ 91.290521] [] put_page+0x25/0x40
[ 91.290524] [] unpoison_memory+0x107/0x200
[ 91.290526] [] ? ns_capable+0x27/0x60
[ 91.290528] [] hwpoison_unpoison+0x20/0x30
[ 91.290530] [] simple_attr_write+0xb6/0xd0
[ 91.290532] [] ? generic_fh_to_dentry+0x50/0x50
[ 91.290535] [] vfs_write+0xa0/0x1b0
[ 91.290537] [] ? generic_fh_to_dentry+0x50/0x50
[ 91.290539] [] SyS_write+0x4f/0x90
[ 91.290549] [] sysenter_do_call+0x12/0x22
[ 91.290550] Disabling lock debugging due to kernel taint
Testcase:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#define PAGES_TO_TEST 1
#define PAGE_SIZE 4096
int main(void)
{
char *mem;
mem = mmap(NULL, PAGES_TO_TEST * PAGE_SIZE,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0,
0);
if (madvise(mem, PAGES_TO_TEST * PAGE_SIZE, MADV_HWPOISON) == -1)
return -1;
munmap(mem, PAGES_TO_TEST * PAGE_SIZE);
return 0;
}
There is one page reference count for default empty zero page, madvise_hwpoison
add another one by get_user_pages_fast. memory_hwpoison reduce one page
reference
count since it's a non LRU page. unpoison_memory release the last page reference
count and free empty zero page to buddy system which is not correct since empty
zero page has PG_reserved flag. This patch fix it by don't reduce the page
reference count under 1 against empty zero page.
Signed-off-by: Wanpeng Li
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 7cdabc0..657c0c1 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1385,7 +1385,7 @@ int unpoison_memory(unsigned long pfn)
unlock_page(page);
put_page(page);
- if (freeit)
+ if (freeit && !(pfn == my_zero_pfn(0) && page_count(p) == 1))
put_page(page);
return 0;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 01/13] workqueue: fix possible stall on try_to_grab_pending() of a delayed work item
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Lai Jiangshan
commit 3aa62497594430ea522050b75c033f71f2c60ee6 upstream.
Currently, when try_to_grab_pending() grabs a delayed work item, it
leaves its linked work items alone on the delayed_works. The linked
work items are always NO_COLOR and will cause future
cwq_activate_first_delayed() increase cwq->nr_active incorrectly, and
may cause the whole cwq to stall. For example,
state: cwq->max_active = 1, cwq->nr_active = 1
one work in cwq->pool, many in cwq->delayed_works.
step1: try_to_grab_pending() removes a work item from delayed_works
but leaves its NO_COLOR linked work items on it.
step2: Later on, cwq_activate_first_delayed() activates the linked
work item increasing ->nr_active.
step3: cwq->nr_active = 1, but all activated work items of the cwq are
NO_COLOR. When they finish, cwq->nr_active will not be
decreased due to NO_COLOR, and no further work items will be
activated from cwq->delayed_works. the cwq stalls.
Fix it by ensuring the target work item is activated before stealing
PENDING in try_to_grab_pending(). This ensures that all the linked
work items are activated without incorrectly bumping cwq->nr_active.
tj: Updated comment and description.
Signed-off-by: Lai Jiangshan
Signed-off-by: Tejun Heo
[lizf: backported to 3.4: adjust context]
Signed-off-by: Li Zefan
Signed-off-by: Greg Kroah-Hartman
---
kernel/workqueue.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1721,10 +1721,9 @@ static void move_linked_works(struct wor
*nextp = n;
}
-static void cwq_activate_first_delayed(struct cpu_workqueue_struct *cwq)
+static void cwq_activate_delayed_work(struct work_struct *work)
{
- struct work_struct *work = list_first_entry(>delayed_works,
- struct work_struct, entry);
+ struct cpu_workqueue_struct *cwq = get_work_cwq(work);
struct list_head *pos = gcwq_determine_ins_pos(cwq->gcwq, cwq);
trace_workqueue_activate_work(work);
@@ -1733,6 +1732,14 @@ static void cwq_activate_first_delayed(s
cwq->nr_active++;
}
+static void cwq_activate_first_delayed(struct cpu_workqueue_struct *cwq)
+{
+ struct work_struct *work = list_first_entry(>delayed_works,
+ struct work_struct, entry);
+
+ cwq_activate_delayed_work(work);
+}
+
/**
* cwq_dec_nr_in_flight - decrement cwq's nr_in_flight
* @cwq: cwq of interest
@@ -2625,6 +2632,18 @@ static int try_to_grab_pending(struct wo
smp_rmb();
if (gcwq == get_work_gcwq(work)) {
debug_work_deactivate(work);
+
+ /*
+* A delayed work item cannot be grabbed directly
+* because it might have linked NO_COLOR work items
+* which, if left on the delayed_list, will confuse
+* cwq->nr_active management later on and cause
+* stall. Make sure the work item is activated
+* before grabbing.
+*/
+ if (*work_data_bits(work) & WORK_STRUCT_DELAYED)
+ cwq_activate_delayed_work(work);
+
list_del_init(>entry);
cwq_dec_nr_in_flight(get_work_cwq(work),
get_work_color(work),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 04/13] xen/events: initialize local per-cpu mask for all possible events
3.4-stable review patch. If anyone has any objections, please let me know. -- From: David Vrabel commit 84ca7a8e45dafb49cd5ca90a343ba033e2885c17 upstream. The sizeof() argument in init_evtchn_cpu_bindings() is incorrect resulting in only the first 64 (or 32 in 32-bit guests) ports having their bindings being initialized to VCPU 0. In most cases this does not cause a problem as request_irq() will set the irq affinity which will set the correct local per-cpu mask. However, if the request_irq() is called on a VCPU other than 0, there is a window between the unmasking of the event and the affinity being set were an event may be lost because it is not locally unmasked on any VCPU. If request_irq() is called on VCPU 0 then local irqs are disabled during the window and the race does not occur. Fix this by initializing all NR_EVENT_CHANNEL bits in the local per-cpu masks. Signed-off-by: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman --- drivers/xen/events.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -324,7 +324,7 @@ static void init_evtchn_cpu_bindings(voi for_each_possible_cpu(i) memset(per_cpu(cpu_evtchn_mask, i), - (i == 0) ? ~0 : 0, sizeof(*per_cpu(cpu_evtchn_mask, i))); + (i == 0) ? ~0 : 0, NR_EVENT_CHANNELS/8); } static inline void clear_evtchn(int port) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 02/13] workqueue: consider work function when searching for busy work items
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Tejun Heo
commit a2c1c57be8d9fd5b716113c8991d3d702eeacf77 upstream.
To avoid executing the same work item concurrenlty, workqueue hashes
currently busy workers according to their current work items and looks
up the the table when it wants to execute a new work item. If there
already is a worker which is executing the new work item, the new item
is queued to the found worker so that it gets executed only after the
current execution finishes.
Unfortunately, a work item may be freed while being executed and thus
recycled for different purposes. If it gets recycled for a different
work item and queued while the previous execution is still in
progress, workqueue may make the new work item wait for the old one
although the two aren't really related in any way.
In extreme cases, this false dependency may lead to deadlock although
it's extremely unlikely given that there aren't too many self-freeing
work item users and they usually don't wait for other work items.
To alleviate the problem, record the current work function in each
busy worker and match it together with the work item address in
find_worker_executing_work(). While this isn't complete, it ensures
that unrelated work items don't interact with each other and in the
very unlikely case where a twisted wq user triggers it, it's always
onto itself making the culprit easy to spot.
Signed-off-by: Tejun Heo
Reported-by: Andrey Isakov
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51701
[lizf: Backported to 3.4:
- Adjust context
- Incorporate earlier logging cleanup in process_one_work() from
044c782ce3a9 ('workqueue: fix checkpatch issues')]
Signed-off-by: Li Zefan
Signed-off-by: Greg Kroah-Hartman
---
kernel/workqueue.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -128,6 +128,7 @@ struct worker {
};
struct work_struct *current_work; /* L: work being processed */
+ work_func_t current_func; /* L: current_work's fn */
struct cpu_workqueue_struct *current_cwq; /* L: current_work's cwq */
struct list_headscheduled; /* L: scheduled works */
struct task_struct *task; /* I: worker task */
@@ -838,7 +839,8 @@ static struct worker *__find_worker_exec
struct hlist_node *tmp;
hlist_for_each_entry(worker, tmp, bwh, hentry)
- if (worker->current_work == work)
+ if (worker->current_work == work &&
+ worker->current_func == work->func)
return worker;
return NULL;
}
@@ -848,9 +850,27 @@ static struct worker *__find_worker_exec
* @gcwq: gcwq of interest
* @work: work to find worker for
*
- * Find a worker which is executing @work on @gcwq. This function is
- * identical to __find_worker_executing_work() except that this
- * function calculates @bwh itself.
+ * Find a worker which is executing @work on @gcwq by searching
+ * @gcwq->busy_hash which is keyed by the address of @work. For a worker
+ * to match, its current execution should match the address of @work and
+ * its work function. This is to avoid unwanted dependency between
+ * unrelated work executions through a work item being recycled while still
+ * being executed.
+ *
+ * This is a bit tricky. A work item may be freed once its execution
+ * starts and nothing prevents the freed area from being recycled for
+ * another work item. If the same work item address ends up being reused
+ * before the original execution finishes, workqueue will identify the
+ * recycled work item as currently executing and make it wait until the
+ * current execution finishes, introducing an unwanted dependency.
+ *
+ * This function checks the work item address, work function and workqueue
+ * to avoid false positives. Note that this isn't complete as one may
+ * construct a work function which can introduce dependency onto itself
+ * through a recycled work item. Well, if somebody wants to shoot oneself
+ * in the foot that badly, there's only so much we can do, and if such
+ * deadlock actually occurs, it should be easy to locate the culprit work
+ * function.
*
* CONTEXT:
* spin_lock_irq(gcwq->lock).
@@ -1811,7 +1831,6 @@ __acquires(>lock)
struct global_cwq *gcwq = cwq->gcwq;
struct hlist_head *bwh = busy_worker_head(gcwq, work);
bool cpu_intensive = cwq->wq->flags & WQ_CPU_INTENSIVE;
- work_func_t f = work->func;
int work_color;
struct worker *collision;
#ifdef CONFIG_LOCKDEP
@@ -1840,6 +1859,7 @@ __acquires(>lock)
debug_work_deactivate(work);
hlist_add_head(>hentry, bwh);
worker->current_work = work;
+ worker->current_func = work->func;
worker->current_cwq = cwq;
work_color = get_work_color(work);
[ 03/13] zd1201: do not use stack as URB transfer_buffer
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jussi Kivilinna
commit 1206ff4ff9d2ef7468a355328bc58ac6ebf5be44 upstream.
Patch fixes zd1201 not to use stack as URB transfer_buffer. URB buffers need
to be DMA-able, which stack is not.
Patch is only compile tested.
Signed-off-by: Jussi Kivilinna
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/zd1201.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/zd1201.c
+++ b/drivers/net/wireless/zd1201.c
@@ -98,10 +98,12 @@ static int zd1201_fw_upload(struct usb_d
goto exit;
err = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), 0x4,
- USB_DIR_IN | 0x40, 0,0, , sizeof(ret), ZD1201_FW_TIMEOUT);
+ USB_DIR_IN | 0x40, 0, 0, buf, sizeof(ret), ZD1201_FW_TIMEOUT);
if (err < 0)
goto exit;
+ memcpy(, buf, sizeof(ret));
+
if (ret & 0x80) {
err = -EIO;
goto exit;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 13/13] x86/xen: do not identity map UNUSABLE regions in the machine E820
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: David Vrabel
commit 3bc38cbceb85881a8eb789ee1aa56678038b1909 upstream.
If there are UNUSABLE regions in the machine memory map, dom0 will
attempt to map them 1:1 which is not permitted by Xen and the kernel
will crash.
There isn't anything interesting in the UNUSABLE region that the dom0
kernel needs access to so we can avoid making the 1:1 mapping and
treat it as RAM.
We only do this for dom0, as that is where tboot case shows up.
A PV domU could have an UNUSABLE region in its pseudo-physical map
and would need to be handled in another patch.
This fixes a boot failure on hosts with tboot.
tboot marks a region in the e820 map as unusable and the dom0 kernel
would attempt to map this region and Xen does not permit unusable
regions to be mapped by guests.
(XEN) - 0006 (usable)
(XEN) 0006 - 00068000 (reserved)
(XEN) 00068000 - 0009e000 (usable)
(XEN) 0010 - 0080 (usable)
(XEN) 0080 - 00972000 (unusable)
tboot marked this region as unusable.
(XEN) 00972000 - cf20 (usable)
(XEN) cf20 - cf38f000 (reserved)
(XEN) cf38f000 - cf3ce000 (ACPI data)
(XEN) cf3ce000 - d000 (reserved)
(XEN) e000 - f000 (reserved)
(XEN) fe00 - 0001 (reserved)
(XEN) 0001 - 00063000 (usable)
Signed-off-by: David Vrabel
[v1: Altered the patch and description with domU's with UNUSABLE regions]
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/setup.c | 22 ++
1 file changed, 22 insertions(+)
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -213,6 +213,17 @@ static void xen_align_and_add_e820_regio
e820_add_region(start, end - start, type);
}
+void xen_ignore_unusable(struct e820entry *list, size_t map_size)
+{
+ struct e820entry *entry;
+ unsigned int i;
+
+ for (i = 0, entry = list; i < map_size; i++, entry++) {
+ if (entry->type == E820_UNUSABLE)
+ entry->type = E820_RAM;
+ }
+}
+
/**
* machine_specific_memory_setup - Hook for machine specific memory setup.
**/
@@ -251,6 +262,17 @@ char * __init xen_memory_setup(void)
}
BUG_ON(rc);
+ /*
+* Xen won't allow a 1:1 mapping to be created to UNUSABLE
+* regions, so if we're using the machine memory map leave the
+* region as RAM as it is in the pseudo-physical map.
+*
+* UNUSABLE regions in domUs are not handled and will need
+* a patch in the future.
+*/
+ if (xen_initial_domain())
+ xen_ignore_unusable(map, memmap.nr_entries);
+
/* Make sure the Xen-supplied memory map is well-ordered. */
sanitize_e820_map(map, memmap.nr_entries, _entries);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 06/13] of: fdt: fix memory initialization for expanded DT
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Wladislav Wiebe
commit 9e40127526e857fa3f29d51e83277204fbdfc6ba upstream.
Already existing property flags are filled wrong for properties created from
initial FDT. This could cause problems if this DYNAMIC device-tree functions
are used later, i.e. properties are attached/detached/replaced. Simply dumping
flags from the running system show, that some initial static (not allocated via
kzmalloc()) nodes are marked as dynamic.
I putted some debug extensions to property_proc_show(..) :
..
+ if (OF_IS_DYNAMIC(pp))
+ pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n");
+ if (OF_IS_DETACHED(pp))
+ pr_err("DEBUG: xxx : OF_IS_DETACHED\n");
when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you
will see that those flags are filled wrong, basically in most cases it will dump
a DYNAMIC or DETACHED status, which is in not true.
(BTW. this OF_IS_DETACHED is a own define for debug purposes which which just
make a test_bit(OF_DETACHED, >_flags)
If nodes are dynamic kernel is allowed to kfree() them. But it will crash
attempting to do so on the nodes from FDT -- they are not allocated via
kzmalloc().
Signed-off-by: Wladislav Wiebe
Acked-by: Alexander Sverdlin
Signed-off-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman
---
drivers/of/fdt.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -390,6 +390,8 @@ static void __unflatten_device_tree(stru
mem = (unsigned long)
dt_alloc(size + 4, __alignof__(struct device_node));
+ memset((void *)mem, 0, size);
+
((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeef);
pr_debug(" unflattening %lx...\n", mem);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 05/13] drm/i915: Invalidate TLBs for the rings after a reset
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit 884020bf3d2a3787a1cc6df902e98e0eec60330b upstream.
After any "soft gfx reset" we must manually invalidate the TLBs
associated with each ring. Empirically, it seems that a
suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is
that the hardware would fail to note the new address for its status
page, and so it would continue to write the shadow registers and
breadcrumbs into the old physical address (now used by something
completely different, scary). Whereas the driver would read the new
status page and never see any progress, it would appear that the GPU
hung immediately upon resume.
Based on a patch by naresh kumar kachhi
Reported-by: Thiago Macieira
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725
Signed-off-by: Chris Wilson
Tested-by: Thiago Macieira
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 12
2 files changed, 14 insertions(+)
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -502,6 +502,8 @@
will not assert AGPBUSY# and will only
be delivered when out of C3. */
#define INSTPM_FORCE_ORDERING(1<<7) /* GEN6+
*/
+#define INSTPM_TLB_INVALIDATE(1<<9)
+#define INSTPM_SYNC_FLUSH(1<<5)
#define ACTHD 0x020c8
#define FW_BLC 0x020d8
#define FW_BLC20x020dc
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -767,6 +767,18 @@ void intel_ring_setup_status_page(struct
I915_WRITE(mmio, (u32)ring->status_page.gfx_addr);
POSTING_READ(mmio);
+
+ /* Flush the TLB for this page */
+ if (INTEL_INFO(dev)->gen >= 6) {
+ u32 reg = RING_INSTPM(ring->mmio_base);
+ I915_WRITE(reg,
+ _MASKED_BIT_ENABLE(INSTPM_TLB_INVALIDATE |
+ INSTPM_SYNC_FLUSH));
+ if (wait_for((I915_READ(reg) & INSTPM_SYNC_FLUSH) == 0,
+1000))
+ DRM_ERROR("%s: wait for SyncFlush to complete for TLB
invalidation timed out\n",
+ ring->name);
+ }
}
static int
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 11/13] SCSI: zfcp: fix lock imbalance by reworking request queue locking
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Martin Peschke
commit d79ff142624e1be080ad8d09101f7004d79c36e1 upstream.
This patch adds wait_event_interruptible_lock_irq_timeout(), which is a
straight-forward descendant of wait_event_interruptible_timeout() and
wait_event_interruptible_lock_irq().
The zfcp driver used to call wait_event_interruptible_timeout()
in combination with some intricate and error-prone locking. Using
wait_event_interruptible_lock_irq_timeout() as a replacement
nicely cleans up that locking.
This rework removes a situation that resulted in a locking imbalance
in zfcp_qdio_sbal_get():
BUG: workqueue leaked lock or atomic: events/1/0xff00/10
last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp]
It was introduced by commit c2af7545aaff3495d9bf9a7608c52f0af86fb194
"[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new
code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit
without a required lock being held. The problem occured when a
special, non-SCSI I/O request was being submitted in process context,
when the adapter's queues had been torn down. In this case the bug
surfaced when the Fibre Channel port connection for a well-known address
was closed during a concurrent adapter shut-down procedure, which is a
rare constellation.
This patch also fixes these warnings from the sparse tool (make C=1):
drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in
'zfcp_qdio_sbal_check' - wrong count at exit
drivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in
'zfcp_qdio_sbal_get' - unexpected unlock
Last but not least, we get rid of that crappy lock-unlock-lock
sequence at the beginning of the critical section.
It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held.
Reported-by: Mikulas Patocka
Reported-by: Heiko Carstens
Signed-off-by: Martin Peschke
Signed-off-by: Steffen Maier
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman
---
drivers/s390/scsi/zfcp_qdio.c |8 +
include/linux/wait.h | 57 ++
2 files changed, 59 insertions(+), 6 deletions(-)
--- a/drivers/s390/scsi/zfcp_qdio.c
+++ b/drivers/s390/scsi/zfcp_qdio.c
@@ -224,11 +224,9 @@ int zfcp_qdio_sbals_from_sg(struct zfcp_
static int zfcp_qdio_sbal_check(struct zfcp_qdio *qdio)
{
- spin_lock_irq(>req_q_lock);
if (atomic_read(>req_q_free) ||
!(atomic_read(>adapter->status) & ZFCP_STATUS_ADAPTER_QDIOUP))
return 1;
- spin_unlock_irq(>req_q_lock);
return 0;
}
@@ -246,9 +244,8 @@ int zfcp_qdio_sbal_get(struct zfcp_qdio
{
long ret;
- spin_unlock_irq(>req_q_lock);
- ret = wait_event_interruptible_timeout(qdio->req_q_wq,
- zfcp_qdio_sbal_check(qdio), 5 * HZ);
+ ret = wait_event_interruptible_lock_irq_timeout(qdio->req_q_wq,
+ zfcp_qdio_sbal_check(qdio), qdio->req_q_lock, 5 * HZ);
if (!(atomic_read(>adapter->status) & ZFCP_STATUS_ADAPTER_QDIOUP))
return -EIO;
@@ -262,7 +259,6 @@ int zfcp_qdio_sbal_get(struct zfcp_qdio
zfcp_erp_adapter_reopen(qdio->adapter, 0, "qdsbg_1");
}
- spin_lock_irq(>req_q_lock);
return -EIO;
}
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -530,6 +530,63 @@ do {
\
? 0 : __wait_event_interruptible_locked(wq, condition, 1, 1))
+#define __wait_event_interruptible_lock_irq_timeout(wq, condition, \
+ lock, ret) \
+do { \
+ DEFINE_WAIT(__wait);\
+ \
+ for (;;) { \
+ prepare_to_wait(, &__wait, TASK_INTERRUPTIBLE); \
+ if (condition) \
+ break; \
+ if (signal_pending(current)) { \
+ ret = -ERESTARTSYS; \
+ break; \
+ } \
+ spin_unlock_irq(); \
+ ret = schedule_timeout(ret);\
+ spin_lock_irq(); \
+ if (!ret) \
+ break; \
+ } \
+
[ 12/13] SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Martin Peschke
commit 924dd584b198a58aa7cb3efefd8a03326550ce8f upstream.
BUG: sleeping function called from invalid context at kernel/workqueue.c:2752
in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700
CPU: 1 Not tainted 3.9.3+ #69
Process zfcperp0.0.1700 (pid: 360, task: 75b7e080, ksp:
7476bc30)
Call Trace:
([<001165de>] show_trace+0x106/0x154)
[<001166a0>] show_stack+0x74/0xf4
[<006ff646>] dump_stack+0xc6/0xd4
[<0017f3a0>] __might_sleep+0x128/0x148
[<0015ece8>] flush_work+0x54/0x1f8
[<001630de>] __cancel_work_timer+0xc6/0x128
[<005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c
[<00161816>] execute_in_process_context+0x96/0xa8
[<004d33d8>] device_release+0x60/0xc0
[<0048af48>] kobject_release+0xa8/0x1c4
[<004f4bf2>] __scsi_iterate_devices+0xfa/0x130
[<03ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp]
[<03ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp]
[<0016b75a>] kthread+0xf2/0xfc
[<0070c9de>] kernel_thread_starter+0x6/0xc
[<0070c9d8>] kernel_thread_starter+0x0/0xc
Apparently, the ref_count for some scsi_device drops down to zero,
triggering device removal through execute_in_process_context(), while
the lldd error recovery thread iterates through a scsi device list.
Unfortunately, execute_in_process_context() decides to immediately
execute that device removal function, instead of scheduling asynchronous
execution, since it detects process context and thinks it is safe to do
so. But almost all calls to shost_for_each_device() in our lldd are
inside spin_lock_irq, even in thread context. Obviously, schedule()
inside spin_lock_irq sections is a bad idea.
Change the lldd to use the proper iterator function,
__shost_for_each_device(), in combination with required locking.
Occurences that need to be changed include all calls in zfcp_erp.c,
since those might be executed in zfcp error recovery thread context
with a lock held.
Other occurences of shost_for_each_device() in zfcp_fsf.c do not
need to be changed (no process context, no surrounding locking).
The problem was introduced in Linux 2.6.37 by commit
b62a8d9b45b971a67a0f8413338c230e3117dff5
"[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit".
Reported-by: Christian Borntraeger
Signed-off-by: Martin Peschke
Signed-off-by: Steffen Maier
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman
---
drivers/s390/scsi/zfcp_erp.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -102,10 +102,13 @@ static void zfcp_erp_action_dismiss_port
if (atomic_read(>status) & ZFCP_STATUS_COMMON_ERP_INUSE)
zfcp_erp_action_dismiss(>erp_action);
- else
- shost_for_each_device(sdev, port->adapter->scsi_host)
+ else {
+ spin_lock(port->adapter->scsi_host->host_lock);
+ __shost_for_each_device(sdev, port->adapter->scsi_host)
if (sdev_to_zfcp(sdev)->port == port)
zfcp_erp_action_dismiss_lun(sdev);
+ spin_unlock(port->adapter->scsi_host->host_lock);
+ }
}
static void zfcp_erp_action_dismiss_adapter(struct zfcp_adapter *adapter)
@@ -592,9 +595,11 @@ static void _zfcp_erp_lun_reopen_all(str
{
struct scsi_device *sdev;
- shost_for_each_device(sdev, port->adapter->scsi_host)
+ spin_lock(port->adapter->scsi_host->host_lock);
+ __shost_for_each_device(sdev, port->adapter->scsi_host)
if (sdev_to_zfcp(sdev)->port == port)
_zfcp_erp_lun_reopen(sdev, clear, id, 0);
+ spin_unlock(port->adapter->scsi_host->host_lock);
}
static void zfcp_erp_strategy_followup_failed(struct zfcp_erp_action *act)
@@ -1435,8 +1440,10 @@ void zfcp_erp_set_adapter_status(struct
atomic_set_mask(common_mask, >status);
read_unlock_irqrestore(>port_list_lock, flags);
- shost_for_each_device(sdev, adapter->scsi_host)
+ spin_lock_irqsave(adapter->scsi_host->host_lock, flags);
+ __shost_for_each_device(sdev, adapter->scsi_host)
atomic_set_mask(common_mask, _to_zfcp(sdev)->status);
+ spin_unlock_irqrestore(adapter->scsi_host->host_lock, flags);
}
/**
@@ -1470,11 +1477,13 @@ void zfcp_erp_clear_adapter_status(struc
}
read_unlock_irqrestore(>port_list_lock, flags);
- shost_for_each_device(sdev, adapter->scsi_host) {
+ spin_lock_irqsave(adapter->scsi_host->host_lock, flags);
+ __shost_for_each_device(sdev, adapter->scsi_host) {
atomic_clear_mask(common_mask, _to_zfcp(sdev)->status);
if (clear_counter)
[ 07/13] nilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vyacheslav Dubeyko
commit 2df37a19c686c2d7c4e9b4ce1505b5141e3e5552 upstream.
Remove double call of bio_put() in nilfs_end_bio_write() for the case of
BIO_EOPNOTSUPP error detection. The issue was found by Dan Carpenter
and he suggests first version of the fix too.
Signed-off-by: Vyacheslav Dubeyko
Reported-by: Dan Carpenter
Acked-by: Ryusuke Konishi
Tested-by: Ryusuke Konishi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/nilfs2/segbuf.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/fs/nilfs2/segbuf.c
+++ b/fs/nilfs2/segbuf.c
@@ -345,8 +345,7 @@ static void nilfs_end_bio_write(struct b
if (err == -EOPNOTSUPP) {
set_bit(BIO_EOPNOTSUPP, >bi_flags);
- bio_put(bio);
- /* to be detected by submit_seg_bio() */
+ /* to be detected by nilfs_segbuf_submit_bio() */
}
if (!uptodate)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 08/13] nilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vyacheslav Dubeyko
commit 4bf93b50fd04118ac7f33a3c2b8a0a1f9fa80bc9 upstream.
Fix the issue with improper counting number of flying bio requests for
BIO_EOPNOTSUPP error detection case.
The sb_nbio must be incremented exactly the same number of times as
complete() function was called (or will be called) because
nilfs_segbuf_wait() will call wail_for_completion() for the number of
times set to sb_nbio:
do {
wait_for_completion(>sb_bio_event);
} while (--segbuf->sb_nbio > 0);
Two functions complete() and wait_for_completion() must be called the
same number of times for the same sb_bio_event. Otherwise,
wait_for_completion() will hang or leak.
Signed-off-by: Vyacheslav Dubeyko
Cc: Dan Carpenter
Acked-by: Ryusuke Konishi
Tested-by: Ryusuke Konishi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/nilfs2/segbuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nilfs2/segbuf.c
+++ b/fs/nilfs2/segbuf.c
@@ -376,12 +376,12 @@ static int nilfs_segbuf_submit_bio(struc
bio->bi_private = segbuf;
bio_get(bio);
submit_bio(mode, bio);
+ segbuf->sb_nbio++;
if (bio_flagged(bio, BIO_EOPNOTSUPP)) {
bio_put(bio);
err = -EOPNOTSUPP;
goto failed;
}
- segbuf->sb_nbio++;
bio_put(bio);
wi->bio = 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/
[ 13/74] iwlwifi: mvm: take the seqno from packet if transmit failed
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Emmanuel Grumbach
commit ebea2f32e814445f94f9e087b646f1cf4d55fa5a upstream.
The fw is unreliable in all the cases in which the packet
wasn't sent.
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/iwlwifi/mvm/tx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/mvm/tx.c
@@ -610,8 +610,8 @@ static void iwl_mvm_rx_tx_cmd_single(str
!(info->flags & IEEE80211_TX_STAT_ACK))
info->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK;
- /* W/A FW bug: seq_ctl is wrong when the queue is flushed */
- if (status == TX_STATUS_FAIL_FIFO_FLUSHED) {
+ /* W/A FW bug: seq_ctl is wrong when the status isn't success */
+ if (status != TX_STATUS_SUCCESS) {
struct ieee80211_hdr *hdr = (void *)skb->data;
seq_ctl = le16_to_cpu(hdr->seq_ctrl);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 12/74] iwlwifi: mvm: dont set the MCAST queue in STAs queue list
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Emmanuel Grumbach
commit 837fb69f10588caafc883c4473a864660e1403ce upstream.
The MCAST queue should be enabled after DTIM only.
According to fw API, the MCAST must not be attached to any
station, but should appear in the mcast_qid of the AP's
mac context only.
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c |5 +
drivers/net/wireless/iwlwifi/mvm/sta.c |3 ---
2 files changed, 1 insertion(+), 7 deletions(-)
--- a/drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c
@@ -193,14 +193,11 @@ static void iwl_mvm_mac_iface_iterator(v
u32 iwl_mvm_mac_get_queues_mask(struct iwl_mvm *mvm,
struct ieee80211_vif *vif)
{
- u32 qmask, ac;
+ u32 qmask = 0, ac;
if (vif->type == NL80211_IFTYPE_P2P_DEVICE)
return BIT(IWL_MVM_OFFCHANNEL_QUEUE);
- qmask = (vif->cab_queue != IEEE80211_INVAL_HW_QUEUE) ?
- BIT(vif->cab_queue) : 0;
-
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
if (vif->hw_queue[ac] != IEEE80211_INVAL_HW_QUEUE)
qmask |= BIT(vif->hw_queue[ac]);
--- a/drivers/net/wireless/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.c
@@ -226,9 +226,6 @@ int iwl_mvm_add_sta(struct iwl_mvm *mvm,
if (vif->hw_queue[i] != IEEE80211_INVAL_HW_QUEUE)
mvm_sta->tfd_queue_msk |= BIT(vif->hw_queue[i]);
- if (vif->cab_queue != IEEE80211_INVAL_HW_QUEUE)
- mvm_sta->tfd_queue_msk |= BIT(vif->cab_queue);
-
/* for HW restart - need to reset the seq_number etc... */
memset(mvm_sta->tid_data, 0, sizeof(mvm_sta->tid_data));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 14/74] iwlwifi: mvm: unregister leds when registration failed
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Emmanuel Grumbach commit b7327d89ae694a89f9934d428bde520b77b3131c upstream. This was missing and prevented any further attempts to load the module. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/iwlwifi/mvm/mac80211.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c @@ -243,7 +243,11 @@ int iwl_mvm_mac_setup_register(struct iw if (ret) return ret; - return ieee80211_register_hw(mvm->hw); + ret = ieee80211_register_hw(mvm->hw); + if (ret) + iwl_mvm_leds_exit(mvm); + + return ret; } static void iwl_mvm_mac_tx(struct ieee80211_hw *hw, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 15/74] iwlwifi: bump required firmware API version for 3160/7260
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Johannes Berg commit a2d0909a687b4d250cc2b7481072e361678745ba upstream. As the firmware API has changed significantly and we don't have support code for the old APIs, bump the version to be able to release the version 7 API firmware. Unfortunately this means that the driver in 3.9 and 3.10 can't work, but that's still better than crashing the device/driver there. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/iwlwifi/iwl-7000.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) --- a/drivers/net/wireless/iwlwifi/iwl-7000.c +++ b/drivers/net/wireless/iwlwifi/iwl-7000.c @@ -67,16 +67,16 @@ #include "iwl-agn-hw.h" /* Highest firmware API version supported */ -#define IWL7260_UCODE_API_MAX 6 -#define IWL3160_UCODE_API_MAX 6 +#define IWL7260_UCODE_API_MAX 7 +#define IWL3160_UCODE_API_MAX 7 /* Oldest version we won't warn about */ -#define IWL7260_UCODE_API_OK 6 -#define IWL3160_UCODE_API_OK 6 +#define IWL7260_UCODE_API_OK 7 +#define IWL3160_UCODE_API_OK 7 /* Lowest firmware API version supported */ -#define IWL7260_UCODE_API_MIN 6 -#define IWL3160_UCODE_API_MIN 6 +#define IWL7260_UCODE_API_MIN 7 +#define IWL3160_UCODE_API_MIN 7 /* NVM versions */ #define IWL7260_NVM_VERSION0x0a1d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 16/74] iwlwifi: mvm: adjust firmware D3 configuration API
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Johannes Berg
commit dfcb4c3aacedee6838e436fb575b31e138505203 upstream.
The D3 firmware API changed to include a new field, adjust
the driver to it to avoid getting an NMI when configuring.
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/iwlwifi/mvm/fw-api-d3.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/iwlwifi/mvm/fw-api-d3.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api-d3.h
@@ -75,13 +75,15 @@ enum iwl_d3_wakeup_flags {
* struct iwl_d3_manager_config - D3 manager configuration command
* @min_sleep_time: minimum sleep time (in usec)
* @wakeup_flags: wakeup flags, see iwl_d3_wakeup_flags
+ * @wakeup_host_timer: force wakeup after this many seconds
*
* The structure is used for the D3_CONFIG_CMD command.
*/
struct iwl_d3_manager_config {
__le32 min_sleep_time;
__le32 wakeup_flags;
-} __packed; /* D3_MANAGER_CONFIG_CMD_S_VER_3 */
+ __le32 wakeup_host_timer;
+} __packed; /* D3_MANAGER_CONFIG_CMD_S_VER_4 */
/* TODO: OFFLOADS_QUERY_API_S_VER_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/
