Re: [PATCH 0/4] perf tools: New comm infrastructure
Hi Ingo, On Sat, 14 Sep 2013 08:11:49 +0200, Ingo Molnar wrote: > * Frederic Weisbecker wrote: >> My patches and Namhyung's should improve the comm situation a lot but we >> can't do much miracle. The only way would be perhaps to be able to limit >> the deepness of the callchain branches. >> >> Now may be we can find other big contention point in perf. It's possible >> we also have some endless loop somewhere. > > Well, it was the 100,000+ step linear list walk that was causing 90% of > the slowness here. Namhyung's patch should dramatically improve that. I > guess time for someone to post a combined tree so that it can be tested > all together? I pushed combined tree to 'perf/callchain-v2' branch in my tree git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Please note that I also pushed other versions (v[1-3]). The v1 is my previous rbtree conversion patch, v2 adds Frederic's new comm infrastructure series on top and v3 adds my revised patch to refer current comm [1] on top of v2. I did my own test again among them. Test data is 400MB perf.data file created by parallel kernel build. $ ls -lh perf.data.big -rw---. 1 namhyung namhyung 400M Sep 9 10:21 perf.data.big For more precise result, I changed cpufreq governor to 'performance' # echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor and run perf report on the cpu. $ taskset -c 3 time -p perf --no-pager report --stdio -i perf.data.big > /dev/null I ran it multiple times for each case and the results did not vary much. baselinev1v2 v3 -- real380.17 12.63 10.029.03 user378.86 11.95 9.668.69 sys 0.70 0.65 0.330.34 I also tried to cache latest result and reuse it when adding a callchain (in callchain_append() function) but it only hits ~5% and did not help the performance. Thanks, Namhyung [1] https://lkml.org/lkml/2013/9/16/565 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] uncore_pmu_event_init: using smp_processor_id() in preemptible core
On Tue, Sep 17, 2013 at 12:58:34PM +0800, Yan, Zheng wrote: > --- > diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c > b/arch/x86/kernel/cpu/perf_event_intel_uncore.c > index fd8011e..a12a22f 100644 > --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c > +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c > @@ -2713,7 +2713,10 @@ struct intel_uncore_box *uncore_alloc_box(struct > intel_uncore_type *type, int cp > > size = sizeof(*box) + type->num_shared_regs * sizeof(struct > intel_uncore_extra_reg); > > - box = kzalloc_node(size, GFP_KERNEL, cpu_to_node(cpu)); > + if (cpu < 0) > + box = kzalloc(size, GFP_KERNEL); > + else > + box = kzalloc_node(size, GFP_KERNEL, cpu_to_node(cpu)); > if (!box) > return NULL; I believe -1 is a valid node number for all allocators, in which case they fall back to the current node. > > @@ -3031,7 +3034,7 @@ static int uncore_validate_group(struct > intel_uncore_pmu *pmu, > struct intel_uncore_box *fake_box; > int ret = -EINVAL, n; > > - fake_box = uncore_alloc_box(pmu->type, smp_processor_id()); > + fake_box = uncore_alloc_box(pmu->type, -1); > if (!fake_box) > return -ENOMEM; > Yes, much better indeed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 stats (Was: Linux 3.12-rc1)
On Mon, 16 Sep 2013 18:08:11 -0400 Linus Torvalds wrote: > > So it's been two weeks, and the merge window for 3.12 is now closed. As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20130903 was the linux-next based on v3.11) Commits in v3.12-rc1 (relative to v3.11): 9474 (v3.11-rc11:9494) Commits in next-20130903: 8891 (next-20130701: 8929) Commits with the same SHA1: 7991 ( 7670) Commits with the same patch_id:472 (1) (759) Commits with the same subject line: 70 (1) ( 55) (1) not counting those in the lines above. So commits in -rc1 that were "in" next-20130903:853390.1% (8484 89.4%) Commits in -rc1 that were not in next-20120722: 941 9.9% (1010 10.6% So better than last time, but it would be still nice to figure out where the last lot came from. I have the "git log --oneline --no-walk" list if someone wants them. Some breakdown of that list: Top ten first word of commit summary: 57 net 53 mips 49 drm 47 [scsi] 23 perf 23 nfs 20 cifs 19 nvme 18 vfs 17 arm Top ten authors: 33 Al Viro 21 Sachin Kamat 20 Linus Torvalds 18 James Smart 17 Jon Mason 17 Chuck Lever 16 Tomasz Figa 16 Jingoo Han 15 Daniel Borkmann 14 Trond Myklebust Top ten commiters: 162 David S. Miller 64 Linus Torvalds 53 Ralf Baechle 53 Al Viro 52 Trond Myklebust 47 James Bottomley 22 Steve French 21 Inki Dae 21 Arnaldo Carvalho de Melo 19 Rafael J. Wysocki Quite a few of these could be bug fixes (especially DaveM's). There are also 358 commits in next-20130701 that didn't make it into v3.11-rc1. Top ten first word of commit summary: 56 arm 34 drm 23 selinux 15 drivers 13 ocfs2 9 iov_iter 9 bluetooth 7 kdb 6 pci 5 watchdog Top ten authors: 31 Andrew Morton 22 Dave Kleikamp 15 Jani Nikula 13 Sebastian Hesselbarth 12 Eric Paris 10 Joern Engel 9 Zach Brown 9 Paul Moore 9 Marcel Holtmann 8 Guenter Roeck Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Top ten commiters: 116 Stephen Rothwell 33 Dave Kleikamp 31 Daniel Vetter 28 Benoit Cousson 26 Eric Paris 22 Jason Cooper 14 Joern Engel 11 Shawn Guo 10 Jason Wessel 9 Gustavo Padovan Well, that's embarrassing again :-) Those commits by me are from the quilt series (mainly Andrew's mmotm tree). Some of the above will have been merged into other patches or replaced, I guess. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpmdFe8nfk_8.pgp Description: PGP signature
Re: [PATCH 1/1] dma: tegra20-apb-dma: Staticize tegra_dma_prep_dma_cyclic
On Fri, Sep 06, 2013 at 05:16:22PM +0530, Sachin Kamat wrote: > tegra_dma_prep_dma_cyclic is referenced only in this file. > Make it static. Applied, thanks ~Vinod > > Signed-off-by: Sachin Kamat > Cc: Laxman Dewangan > --- > drivers/dma/tegra20-apb-dma.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c > index 5d4986e..67a6752 100644 > --- a/drivers/dma/tegra20-apb-dma.c > +++ b/drivers/dma/tegra20-apb-dma.c > @@ -1018,7 +1018,7 @@ static struct dma_async_tx_descriptor > *tegra_dma_prep_slave_sg( > return _desc->txd; > } > > -struct dma_async_tx_descriptor *tegra_dma_prep_dma_cyclic( > +static struct dma_async_tx_descriptor *tegra_dma_prep_dma_cyclic( > struct dma_chan *dc, dma_addr_t buf_addr, size_t buf_len, > size_t period_len, enum dma_transfer_direction direction, > unsigned long flags, void *context) > -- > 1.7.9.5 > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/28] of: Introduce common early_init_dt_scan
On 09/17/2013 04:39 AM, Rob Herring wrote:
> From: Rob Herring
>
> Most architectures scan the all the same items early in the FDT and none
> are really architecture specific. Create a common early_init_dt_scan to
> unify the early scan of root, memory, and chosen nodes in the flattened
> DT.
>
> Signed-off-by: Rob Herring
> Cc: Grant Likely
> ---
> drivers/of/fdt.c | 18 ++
> include/linux/of_fdt.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index eca1810..0714dd4 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -785,6 +785,24 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64
> size, u64 align)
> }
> #endif
>
> +bool __init early_init_dt_scan(void *params)
> +{
> + /* Setup flat device-tree pointer */
> + initial_boot_params = params;
> +
> + /* check device tree validity */
> + if (be32_to_cpu(initial_boot_params->magic) != OF_DT_HEADER)
> + return false;
> +
> + /* Retrieve various information from the /chosen node */
> + of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
> + /* Initialize {size,address}-cells info */
> + of_scan_flat_dt(early_init_dt_scan_root, NULL);
> + /* Setup memory, calling early_init_dt_add_memory_arch */
> + of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> + return true;
> +}
You probably need empty lines here.
-Vineet
> +
> /**
> * unflatten_device_tree - create tree of device_nodes from flat blob
> *
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index 58c28a8..73e1651 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -116,6 +116,8 @@ extern void early_init_dt_setup_initrd_arch(u64 start,
> u64 end);
> extern int early_init_dt_scan_root(unsigned long node, const char *uname,
> int depth, void *data);
>
> +extern bool early_init_dt_scan(void *params);
> +
> /* Other Prototypes */
> extern void unflatten_device_tree(void);
> extern void unflatten_and_copy_device_tree(void);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma/Kconfig: Make TI_EDMA select TI_PRIV_EDMA
On Wed, Sep 04, 2013 at 12:10:45PM -0400, Josh Boyer wrote: > On Wed, Sep 04, 2013 at 09:32:03AM -0400, Josh Boyer wrote: > > The TI_EDMA driver unconditionally calls functions provided by the > > TI_PRIV_EDMA code, but it doesn't force that to be built-in. If that isn't > > otherwise enabled somewhere, you can get build errors like: > > > > linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:593: undefined > > reference to `edma_free_slot' > > drivers/built-in.o: In function `edma_terminate_all': > > linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:169: undefined > > reference to `edma_stop' > > drivers/built-in.o: In function `edma_execute': > > linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:122: undefined > > reference to `edma_write_slot' > > linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:149: undefined > > reference to `edma_link' > > linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:152: undefined > > reference to `edma_start' > > > > Make TI_EDMA select TI_PRIV_EDMA to avoid this. > > > > Signed-off-by: Josh Boyer Applied, thanks ~Vinod > > Just replying to Matt's new email address as the TI one bounced when I > originally sent this. > > > --- > > drivers/dma/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig > > index daa4da2..825374b 100644 > > --- a/drivers/dma/Kconfig > > +++ b/drivers/dma/Kconfig > > @@ -198,6 +198,7 @@ config TI_EDMA > > depends on ARCH_DAVINCI || ARCH_OMAP > > select DMA_ENGINE > > select DMA_VIRTUAL_CHANNELS > > + select TI_PRIV_EDMA > > default n > > help > > Enable support for the TI EDMA controller. This DMA > > -- > > 1.8.3.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: [RESEND PATCH v5 3/4] mm/vmalloc: revert "mm/vmalloc.c: check VM_UNINITIALIZED flag in s_show instead of show_numa_info"
On Mon, Sep 16, 2013 at 8:18 PM, Wanpeng Li wrote: > Hi KOSAKI, > On Mon, Sep 16, 2013 at 05:23:32PM -0400, KOSAKI Motohiro wrote: >>On 9/14/2013 7:45 PM, Wanpeng Li wrote: >>> Changelog: >>> *v2 -> v3: revert commit d157a558 directly >>> >>> The VM_UNINITIALIZED/VM_UNLIST flag introduced by commit f5252e00(mm: avoid >>> null pointer access in vm_struct via /proc/vmallocinfo) is used to avoid >>> accessing the pages field with unallocated page when show_numa_info() is >>> called. This patch move the check just before show_numa_info in order that >>> some messages still can be dumped via /proc/vmallocinfo. This patch revert >>> commit d157a558 (mm/vmalloc.c: check VM_UNINITIALIZED flag in s_show instead >>> of show_numa_info); >> >>Both d157a558 and your patch don't explain why your one is better. Yes, some >>messages _can_ be dumped. But why should we do so? > > More messages can be dumped and original commit f5252e00(mm: avoid null > pointer > access in vm_struct via /proc/vmallocinfo) do that. > >>And No. __get_vm_area_node() doesn't use __GFP_ZERO for allocating >>vm_area_struct. >>dumped partial dump is not only partial, but also may be garbage. > > vm_struct is allocated by kzalloc_node. Oops, you are right. Then, your code _intentionally_ show amazing zero. Heh, nice. More message is pointless. zero is just zero. It doesn't have any information. >>I wonder why we need to call setup_vmalloc_vm() _after_ insert_vmap_area. > > I think it's another topic. Why? > Fill vm_struct and set VM_VM_AREA flag. If I misunderstand your > question? VM_VM_AREA doesn't help. we have race between insert_vmap_area and setup_vmalloc_vm. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] dma: Add Freescale eDMA engine driver support
On Thu, Sep 05, 2013 at 05:53:19PM +0800, Jingchang Lu wrote:
> Add Freescale enhanced direct memory(eDMA) controller support.
> The eDMA controller deploys DMAMUXs routing DMA request sources(slot)
> to eDMA channels.
> This module can be found on Vybrid and LS-1 SoCs.
>
> Signed-off-by: Alison Wang
> Signed-off-by: Jingchang Lu
> ---
> changes in v5:
> config slave_id when dmaengine_slave_config intead of channel request.
> adding residue calculation and dma pause/resume device control.
>
> changes in v4:
> using exact compatible string in binding document.
>
> changes in v3:
> handle all pending interrupt one time.
> add protect lock on dma transfer complete handling.
> change desc and tcd alloc flag to GFP_NOWAIT.
> add sanity check and error messages.
>
> changes in v2:
> using generic dma-channels property instead of fsl,dma-channel.
> rename the binding document to fsl-edma.txt.
>
> Documentation/devicetree/bindings/dma/fsl-edma.txt | 84 ++
> drivers/dma/Kconfig| 10 +
> drivers/dma/Makefile | 1 +
> drivers/dma/fsl-edma.c | 925
> +
> 4 files changed, 1020 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/fsl-edma.txt
> create mode 100644 drivers/dma/fsl-edma.c
>
> diff --git a/Documentation/devicetree/bindings/dma/fsl-edma.txt
> b/Documentation/devicetree/bindings/dma/fsl-edma.txt
> new file mode 100644
> index 000..60a8cb2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/fsl-edma.txt
> @@ -0,0 +1,84 @@
> +* Freescale enhanced Direct Memory Access(eDMA) Controller
> +
> +The eDMA engine deploys DMAMUXs routing request sources(slot) to
> +eDMA controller channels.
> +
> +* eDMA Controller
> +Required properties:
> +- compatible :
> + - "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC
> +- reg : Should contain eDMA registers location and length
> +- interrupts : Should contain eDMA interrupt
> +- interrupt-names : Should be "edma-tx" for tx interrupt and
> + "edma-err" for err interrupt
> +- #dma-cells : Must be <2>.
> + The first cell specifies the DMAMUX ID. Specific request source
> + can only be routed by specific DMAMUXs.
> + the second cell specifies the request source(slot) ID.
> + See include/dt-bindings/dma/-edma.h for all the supported
> + request source IDs.
> +- dma-channels : Number of channels supported by the controller
> +- fsl,dma-mux : Phandle of the DMAMUXs deployed by the controller
> +
> +
> +* DMAMUX
> +Required properties:
> +- reg : Should contain DMAMUX registers location and length
> +- fsl,dmamux-id : DMAMUX ID. DMAMUX IDs are unique in each eDMA controller.
> + inside one eDMA controller, specific request source can only be routed by
> + one of its DMAMUXs.
> + However Specific request source may be routed to different eDMA controller,
> + thus all the DMAMUXs sharing a the same request sources have the same ID.
> +- clocks : Phandle of the clock used by the DMAMUX
> +- clock-names : The clock names
> +
> +Below is the eDMA controller and DMAMUX association, and DMAMUX IDs
> assignment
> +On Vybrid vf610 SoC, DMAMUX0 and DMAMU3 share the same request source group,
> +and DMAMUX1 and DMAMU2 share the same request source group.
> +
> +eDMA controller DMAMUXs DMAMUX ID
> +-
> +eDMA0DMAMUX0 0
> + DMAMUX1 1
> +
> +eDMA1DMAMUX2 1
> + DMAMUX3 0
> +
> +Examples:
> +
> +edma0: dma-controller@40018000 {
> + #dma-cells = <2>;
> + compatible = "fsl,vf610-edma";
> + reg = <0x40018000 0x2000>;
> + interrupts = <0 8 0x04>, <0 9 0x04>;
> + interrupt-names = "edma-tx", "edma-err";
> + dma-channels = <32>;
> + fsl,edma-mux = <>, <>;
> +};
> +
> +dmamux0: dmamux@40024000 {
> + reg = <0x40024000 0x1000>;
> + fsl,dmamux-id = <0>;
> + clocks = < VF610_CLK_DMAMUX0>;
> + clock-names = "dmamux";
> +};
> +
> +
> +* DMA clients
> +DMA client drivers that uses the DMA function must use the format described
> +in the dma.txt file, using a three-cell specifier for each channel: a phandle
> +plus two integer cells as described above.
> +
> +Examples:
> +
> +sai2: sai@40031000 {
> + compatible = "fsl,vf610-sai";
> + reg = <0x40031000 0x1000>;
> + interrupts = <0 86 0x04>;
> + clocks = < VF610_CLK_SAI2>;
> + clock-names = "sai";
> + dma-names = "tx", "rx";
> + dmas = < 0 VF610_EDMA_MUXID0_SAI2_TX>,
> + < 0 VF610_EDMA_MUXID0_SAI2_RX>;
> + status = "disabled";
> +};
I need ACK from DT maintainers on the above parts
> +static int fsl_edma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> + unsigned long arg)
> +{
> + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> + struct
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On 09/17/2013 12:08 AM, Sekhar Nori wrote: [..] >>> I still cannot find any users of edma in the device tree sources either >>> in linux-next or linus/master. Why cannot this wait until v3.13? >> >> I understand this affects only DT users of EDMA. But I get so many private >> reports of breakage due to this patch not being there that I think it will >> save >> everyone a lot of pain, specially folks creating integration trees to have >> this >> patch available by default. > > Well, I do agree that the current DT support for EDMA is incomplete > without this patch even if there are no in-kernel users of it. I will > try sending this for the next -rc if we get to the final version in time > and after that its upto the upstreams to take it. Ok, except for the one minor nit below my last scissor patch is good to go. + + ctlr = EDMA_CTLR(dma_spec.args[0]); + clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]), +edma_cc[ctlr]->edma_unused); >>> >>> We don't support the second controller when using DT and the controller >>> number is not really encoded in the argument to edma phandle. So just >>> simplify this to: >>> >>> clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]), >>> edma_cc[0]->edma_unused); >> >> I think let's not make that assumption just incase in the future we support >> more >> than one EDMA controller for DT-based boot. Is that ok? > > We don't write future proof code in that _hope_ that it will get used > someday. In fact this will confuse the reader into wondering if support > for second channel controller is present or not as the code will send Nope I don't agree with this at all.. EDMA CC ctrl will not be hardcoded. We need to write future-proof code to make sure sudden regressions don't pop up when say a second EDMA CC is introduced.. further edma_cc[ctrl] pattern is used all through out the code so what you're asking to do doesn't make much sense in this context. There's no reason to break out of this pattern. It actually will confuse the reader more. Second controller can be present in future. I don't want to come back to change the code when we introduce more than 1 CC which is possible in the future. > mixed messages. In short, we aim for consistency with situation today, > not tomorrow. What you're asking to do infact breaks consistency with the rest of the code. > > Besides, I can bet that when second CC support does get added, it is > very unlikely that the CC number is get encoded into channel number when > using DT. Even if it is not encoded, the data structure for edma_cc is an array and what you're asking is to hardcode the controller number to 0 always. No way I'm going to hard code controller number to a single value. Different topic but anyway why wouldn't ctrl number be encoded in the channel? That's clean, and saves variables and extra structures. Better use of the integer bitmap making up the Ctrl and channel number of small ranges. Regards, -Joel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v5 2/4] mm/vmalloc: revert "mm/vmalloc.c: emit the failure message before return"
On Mon, Sep 16, 2013 at 7:41 PM, Wanpeng Li wrote: > Hi KOSAKI, > On Mon, Sep 16, 2013 at 04:15:29PM -0400, KOSAKI Motohiro wrote: >>On 9/14/2013 7:45 PM, Wanpeng Li wrote: >>> Changelog: >>> *v2 -> v3: revert commit 46c001a2 directly >>> >>> Don't warning twice in __vmalloc_area_node and __vmalloc_node_range if >>> __vmalloc_area_node allocation failure. This patch revert commit 46c001a2 >>> (mm/vmalloc.c: emit the failure message before return). >>> >>> Reviewed-by: Zhang Yanfei >>> Signed-off-by: Wanpeng Li >>> --- >>> mm/vmalloc.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >>> index d78d117..e3ec8b4 100644 >>> --- a/mm/vmalloc.c >>> +++ b/mm/vmalloc.c >>> @@ -1635,7 +1635,7 @@ void *__vmalloc_node_range(unsigned long size, >>> unsigned long align, >>> >>> addr = __vmalloc_area_node(area, gfp_mask, prot, node, caller); >>> if (!addr) >>> -goto fail; >>> +return NULL; > > The goto fail is introduced by commit (mm/vmalloc.c: emit the failure message > before return), and the commit author ignore there has already have warning in > __vmalloc_area_node. > > http://marc.info/?l=linux-mm=137818671125209=2 But, module_alloc() directly calls __vmalloc_node_range(). Your fix makes another regression. >>This is not right fix. Now we have following call stack. >> >> __vmalloc_node >> __vmalloc_node_range >> __vmalloc_node >> >>Even if we remove a warning of __vmalloc_node_range, we still be able to see >>double warning >>because we call __vmalloc_node recursively. > > Different size allocation failure in your example actually. But, when we can not allocate small size memory, almost always we can't allocate large size too. You need some refactoring and make right fix. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/28] arc: use unflatten_and_copy_device_tree
On 09/17/2013 04:39 AM, Rob Herring wrote: > From: Rob Herring > > Use the common unflatten_and_copy_device_tree to copy the built-in FDT > out of init section. > > Signed-off-by: Rob Herring > Cc: Vineet Gupta I tested the series - works great ! Acked by: Vineet Gupta Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 03/28] of: create unflatten_and_copy_device_tree
On 09/17/2013 04:38 AM, Rob Herring wrote:
> From: Rob Herring
>
> Several architectures using DT support built-in dtb's in the init
> section. These platforms need to copy the dtb from init since the
> strings are referenced after unflattening. Every arch has their own
> copying routine which do the same thing. Create a common function,
> unflatten_and_copy_device_tree, to copy the dtb when unflattening the
> dtb.
>
> Signed-off-by: Rob Herring
>
> Cc: Grant Likely
> ---
> drivers/of/fdt.c | 13 +
> include/linux/of_fdt.h | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 229dd9d..eca1810 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -802,6 +802,19 @@ void __init unflatten_device_tree(void)
> of_alias_scan(early_init_dt_alloc_memory_arch);
> }
>
> +void __init unflatten_and_copy_device_tree(void)
> +{
Can we add a comment here why exactly is the copy needed (unflattening doesn't
copy strings which are referenced to by the DT APIs). Will help first time
readers.
> + int size = __be32_to_cpu(initial_boot_params->totalsize);
> + void *dt = early_init_dt_alloc_memory_arch(size,
> + __alignof__(struct boot_param_header));
> +
> + if (dt) {
> + memcpy(dt, initial_boot_params, size);
> + initial_boot_params = dt;
> + }
> + unflatten_device_tree();
> +}
> +
> #endif /* CONFIG_OF_EARLY_FLATTREE */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Please add PTR_RET tree.
Hi Rusty, On Tue, 17 Sep 2013 10:20:55 +0930 Rusty Russell wrote: > > Please remove PTR_RET tree, it's merged. OK, thanks for letting me know. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpVBmDb4Fm5L.pgp Description: PGP signature
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On Monday 16 September 2013 09:56 PM, Joel Fernandes wrote:
> On 09/16/2013 06:48 AM, Sekhar Nori wrote:
>> Hi Joel,
>>
>> On Saturday 14 September 2013 06:27 AM, Joel Fernandes wrote:
>>> From: Joel Fernandes
>>> Subject: [PATCH v4] 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.
>>
>> I still cannot find any users of edma in the device tree sources either
>> in linux-next or linus/master. Why cannot this wait until v3.13?
>
> I understand this affects only DT users of EDMA. But I get so many private
> reports of breakage due to this patch not being there that I think it will
> save
> everyone a lot of pain, specially folks creating integration trees to have
> this
> patch available by default.
Well, I do agree that the current DT support for EDMA is incomplete
without this patch even if there are no in-kernel users of it. I will
try sending this for the next -rc if we get to the final version in time
and after that its upto the upstreams to take it.
>>> 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;
>>
>> This will break for the case where devices on platform bus use non-EDMA
>> dma controllers like SDMA or CPPI (DRA7x has both EDMA and SDMA on the
>> same chip). You need to do an additional check to make sure the dma
>> controller is indeed EDMA. Something like.
>
> Ok, edma is probed earlier so I could never see any problem.
This has got nothing to do with edma probe order.
> Thanks for pointing this out,
>
> Using the below method is more future-proof than using compatible literal
> strings directly. The only problem is the matches table has to be defined
> earlier in the sources. What do you think?
>
> if (!of_match_node(edma_of_ids, dma_spec.np) {
> of_node_put(dma_spec.np);
> continue;
> }
Looks fine to me.
>> if(!of_device_is_compatible(dma_spec.np, "ti,edma3"))
>> continue;
>>
>> Don forget to call of_node_put() on dma_spec.np (something that needs to
>> be done even with your current code).
>
> Ok, will do.
>
>
>>> +
>>> + ctlr = EDMA_CTLR(dma_spec.args[0]);
>>> + clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]),
>>> + edma_cc[ctlr]->edma_unused);
>>
>> We don't support the second controller when using DT and the controller
>> number is not really encoded in the argument to edma phandle. So just
>> simplify this to:
>>
>> clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]),
>>edma_cc[0]->edma_unused);
>
> I think let's not make that assumption just incase in the future we support
> more
> than one EDMA controller for DT-based boot. Is that ok?
We don't write future proof code in that _hope_ that it will get used
someday. In fact this will confuse the reader into wondering if support
for second channel controller is present or not as the code will send
mixed messages. In short, we aim for consistency with situation today,
not tomorrow.
Besides, I can bet that when second CC support does get added, it is
very unlikely that the CC number is get encoded into channel number when
using DT.
Re: [PATCH v2] modpost: Fix secondary errors seen if a single module build fails
Guenter Roeck writes: > Commit ea4054a23 (modpost: handle huge numbers of modules) added > support for building a large number of modules. > > Unfortunately, the commit changed the semantics of the makefile: Instead of > passing only existing object files to modpost, make now passes all expected > object files. If make was started with option -i, this results in a modpost > error if a single file failed to build. > > Example with the current btrfs build falure on m68k: > > fs/btrfs/btrfs.o: No such file or directory > make[1]: [__modpost] Error 1 (ignored) > > This error is followed by lots of errors such as: > > m68k-linux-gcc: error: arch/m68k/emu/nfcon.mod.c: No such file or directory > m68k-linux-gcc: fatal error: no input files > compilation terminated. > make[1]: [arch/m68k/emu/nfcon.mod.o] Error 1 (ignored) > > This doesn't matter much for normal builds, but it is annoying for builds > started with "make -i" due to the large number of secondary errors. > Those errors unnececessarily clog any error log and make it difficult > to find the real errors in the build. > > Fix the problem by only passing existing object files to modpost. Acked-by: Rusty Russell Thanks! Rusty. > > Cc: Rusty Russell > Signed-off-by: Guenter Roeck > --- > v2: Use "xargs -r ls 2>/dev/null" instead of a shell while loop > to filter for existing files. > Not sure if this is much better, but it is an alternative. > If anyone has a better solution, please let me know. > [Another option would be to use 'find' (no parameters) instead > of 'ls', but that would still require the error redirect.] > > scripts/Makefile.modpost |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost > index 8dcdca2..edc4394 100644 > --- a/scripts/Makefile.modpost > +++ b/scripts/Makefile.modpost > @@ -81,7 +81,8 @@ modpost = scripts/mod/modpost\ > > # We can go over command line length here, so be careful. > quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) modules > - cmd_modpost = $(MODLISTCMD) | sed 's/\.ko$$/.o/' | $(modpost) -s -T - > + cmd_modpost = $(MODLISTCMD) | sed 's/\.ko$$/.o/' | \ > + xargs -r ls 2>/dev/null | $(modpost) -s -T - > > PHONY += __modpost > __modpost: $(modules:.ko=.o) FORCE > -- > 1.7.9.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: Please add PTR_RET tree.
Stephen Rothwell writes: > Hi Rusty, > > On Mon, 15 Jul 2013 14:07:03 +0930 Rusty Russell > wrote: >> >> Temporary branch for PTR_RET -> PTR_ERR_OR_ZERO and associated cleanups. >> >> git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git PTR_RET >> >> Log appended. Contributors and people who didn't already ack CC'd. > > Added from tomorrow. Please remove PTR_RET tree, it's merged. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] ashmem: Fix ashmem_shrink deadlock.
2013/5/17 Robert Love : > On Thu, May 16, 2013 at 1:19 PM, Andrew Morton > wrote: >> On Thu, 16 May 2013 13:08:17 -0400 Robert Love wrote: >>> This problem seems a rare proper use of mutex_trylock. >> >> Not really. The need for a trylock is often an indication that a >> subsystem has a locking misdesign. That is indeed the case here. > > It is exactly the same as PF_MEMALLOC. We've got an effectively > asynchronous event (shrinking) that can occur while you are holding > locks requisite to that shrinking. Given that the shrinkage is best > effort, a trylock actually communicates the intent pretty well: "If > possible, grab this lock and shrink." > > I think the idiomatic fix is to introduce a GFP_SHMEM but that seems > overkill. Lots of the GFP flags are really just preventing recursing > into the shrinkage code and it seems ill-designed that we require > developers to know where they might end up. But we can disagree. :) > >> Well, it's not exactly a ton of work, but adding a per-ashmem_area lock >> to protect ->file would rather be putting lipstick on a pig. I suppose >> we can put the trylock in there and run away, but it wouldn't hurt to >> drop in a big fat comment somewhere explaining that the driver should be >> migrated to a per-object locking scheme. > > Unfortunately I think ashmem_shrink would need to grab the per-object > lock too; it needs to update the ranges. I'm sure we could re-design > this but I don't think it is as easy as simply pushing the locking > into the objects. > >Robert Hi all, I am wondering if this is fixed in latest kernel? We are continuously seeing this deadlock issue. Best Regards, Raul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Potential use-after-free in SyS_remap_file_pages
Hi, I am working on AddressSanitizer -- a tool that detects use-after-free and out-of-bounds bugs (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel). Here is one of the use-after-free reports: [ 296.869705] ERROR: AddressSanitizer: heap-use-after-free on address 88005b47a670 [ 296.870787] 88005b47a670 is located 80 bytes inside of 184-byte region [88005b47a620, 88005b47a6d8) [ 296.872146] Accessed by thread T12219: [ 296.872673] #0 inlined describe_heap_address ./arch/x86/mm/asan/report.c:170 [ 296.872673] #0 810dd2a6 (asan_report_error+0x306/0x410) ./arch/x86/mm/asan/report.c:284 [ 296.873509] #1 810dc6a0 (asan_check_region+0x30/0x40) ./arch/x86/mm/asan/asan.c:37 [ 296.874328] #2 810dd453 (__tsan_read8+0x13/0x20) ??:0 [ 296.875295] #3 8124d1b6 (SyS_remap_file_pages+0x486/0x4f0) ??:0 [ 296.876243] #4 81928582 (system_call_fastpath+0x16/0x1b) ./arch/x86/kernel/entry_64.S:645 [ 296.877098] [ 296.877319] Freed by thread T12219: [ 296.877797] #0 810dc849 (asan_slab_free+0x69/0xb0) ./arch/x86/mm/asan/asan.c:134 [ 296.878590] #1 inlined __cache_free ./mm/slab.c:3591 [ 296.878590] #1 81280c55 (kmem_cache_free+0x55/0x2e0) ./mm/slab.c:3800 [ 296.879403] #2 81258bfd (remove_vma+0xad/0xc0) ./mm/mmap.c:256 [ 296.880161] #3 inlined remove_vma_list ./mm/mmap.c:2321 [ 296.880161] #3 8125c817 (do_munmap+0x4d7/0x5f0) ./mm/mmap.c:2542 [ 296.880888] #4 8125d3f0 (mmap_region+0x280/0x960) ./mm/mmap.c:1506 [ 296.881666] #5 8124d18e (SyS_remap_file_pages+0x45e/0x4f0) ??:0 [ 296.882547] #6 81928582 (system_call_fastpath+0x16/0x1b) ./arch/x86/kernel/entry_64.S:645 [ 296.883408] [ 296.883627] Allocated by thread T12219: [ 296.884182] #0 810dc768 (asan_slab_alloc+0x48/0xc0) ./arch/x86/mm/asan/asan.c:91 [ 296.884954] #1 inlined slab_alloc ./mm/slab.c:3475 [ 296.884954] #1 81282eca (kmem_cache_alloc+0x9a/0x4c0) ./mm/slab.c:3630 [ 296.885773] #2 8125d660 (mmap_region+0x4f0/0x960) ./mm/mmap.c:1534 [ 296.886550] #3 8125df0a (do_mmap_pgoff+0x43a/0x510) ./mm/mmap.c:1345 [ 296.887349] #4 81240482 (vm_mmap_pgoff+0xb2/0xf0) ./mm/util.c:370 [ 296.888129] #5 inlined SYSC_mmap_pgoff ./mm/mmap.c:1394 [ 296.888129] #5 8125b552 (SyS_mmap_pgoff+0x282/0x2f0) ./mm/mmap.c:1352 [ 296.888912] #6 8108441d (SyS_mmap+0x5d/0x80) ./arch/x86/kernel/sys_x86_64.c:79 [ 296.889650] #7 81928582 (system_call_fastpath+0x16/0x1b) ./arch/x86/kernel/entry_64.S:645 [ 296.890505] [ 296.890705] Shadow bytes around the buggy address: [ 296.891415] 88005b47a380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa [ 296.892644] 88005b47a400: fa fa fa fa fa fa 00 00 00 00 00 00 00 00 00 00 [ 296.893706] 88005b47a480: 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa [ 296.894753] 88005b47a500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa [ 296.895798] 88005b47a580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa [ 296.896844] =>88005b47a600: fa fa fa fa fd fd fd fd fd fd fd fd fd fd[fd]fd [ 296.897893] 88005b47a680: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa [ 296.899037] 88005b47a700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa [ 296.900101] 88005b47a780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa [ 296.901149] 88005b47a800: fa fa 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 296.902190] 88005b47a880: 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa [ 296.903180] Shadow byte legend (one shadow byte represents 8 application bytes): [ 296.904185] Addressable: 00 [ 296.904714] Partially addressable: 01 02 03 04 05 06 07 [ 296.905515] Heap redzone: fa [ 296.906096] Heap kmalloc redzone: fb [ 296.906613] Freed heap region: fd [ 296.907177] Shadow gap:fe SyS_remap_file_pages() calls mmap_region(), which calls remove_vma_list(), which calls remove_vma(), which frees the vma. Later (after out label) SyS_remap_file_pages() accesses the freed vma in vm_flags = vma->vm_flags. The report is obtained on revision 6a7492a4b2e05051a44458d7187023e22d580666. Please help to confirm/triage the report. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] uncore_pmu_event_init: using smp_processor_id() in preemptible core
On 09/16/2013 05:21 PM, Peter Zijlstra wrote: > Hi, > > Trinity just triggered this: > > [ 595.847438] BUG: using smp_processor_id() in preemptible [] code: > trinity-child28/2674 > [ 595.857378] caller is uncore_pmu_event_init+0x114/0x270 > [ 595.863262] CPU: 11 PID: 2674 Comm: trinity-child28 Tainted: GW > 3.11.0+ #365 > [ 595.872146] Hardware name: Supermicro X8DTN/X8DTN, BIOS 4.6.3 01/08/2010 > [ 595.879656] 000b 880433e09d98 81642eb8 > 880433e09fd8 > [ 595.888430] 880433e09dc0 81367d1e 880373621000 > 880435bacc00 > [ 595.897330] 880433e09df8 81068394 > 81068285 > [ 595.906252] Call Trace: > [ 595.909127] [] dump_stack+0x4e/0x82 > [ 595.914925] [] debug_smp_processor_id+0xde/0x100 > [ 595.921903] [] uncore_pmu_event_init+0x114/0x270 > [ 595.928907] [] ? uncore_pmu_event_init+0x5/0x270 > [ 595.935806] [] perf_init_event+0xcc/0x190 > > That's in uncore_validate_group() where we allocate the fake_box(). > > I'm thinking we might as well use raw_smp_processor_id() since it really > doesn't matter where the fake box lives. > > --- > arch/x86/kernel/cpu/perf_event_intel_uncore.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c > b/arch/x86/kernel/cpu/perf_event_intel_uncore.c > index 8ed4458..63c8913 100644 > --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c > +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c > @@ -3031,7 +3031,7 @@ static int uncore_validate_group(struct > intel_uncore_pmu *pmu, > struct intel_uncore_box *fake_box; > int ret = -EINVAL, n; > > - fake_box = uncore_alloc_box(pmu->type, smp_processor_id()); > + fake_box = uncore_alloc_box(pmu->type, raw_smp_processor_id()); > if (!fake_box) > return -ENOMEM; > > how about using kzalloc() in this case. --- diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c index fd8011e..a12a22f 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c @@ -2713,7 +2713,10 @@ struct intel_uncore_box *uncore_alloc_box(struct intel_uncore_type *type, int cp size = sizeof(*box) + type->num_shared_regs * sizeof(struct intel_uncore_extra_reg); - box = kzalloc_node(size, GFP_KERNEL, cpu_to_node(cpu)); + if (cpu < 0) + box = kzalloc(size, GFP_KERNEL); + else + box = kzalloc_node(size, GFP_KERNEL, cpu_to_node(cpu)); if (!box) return NULL; @@ -3031,7 +3034,7 @@ static int uncore_validate_group(struct intel_uncore_pmu *pmu, struct intel_uncore_box *fake_box; int ret = -EINVAL, n; - fake_box = uncore_alloc_box(pmu->type, smp_processor_id()); + fake_box = uncore_alloc_box(pmu->type, -1); if (!fake_box) return -ENOMEM; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/2] cpufreq: unlock correct rwsem while updating policy->cpu
Current code looks like this:
WARN_ON(lock_policy_rwsem_write(cpu));
update_policy_cpu(policy, new_cpu);
unlock_policy_rwsem_write(cpu);
{lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's rwsem.
Because cpu is changing with the call to update_policy_cpu(), the
unlock_policy_rwsem_write() will release the incorrect lock.
The right solution would be to release the same lock as was taken earlier. Also
update_policy_cpu() was also called from cpufreq_add_dev() without any locks and
so its better if we move this locking to inside update_policy_cpu().
Reported-and-Tested-by: Jon Medhurst
Signed-off-by: Viresh Kumar
---
Hi Rafael,
Only one patch is sent now as other one is unchanged.
drivers/cpufreq/cpufreq.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 43c24aa..1479522 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -952,9 +952,20 @@ static void update_policy_cpu(struct cpufreq_policy
*policy, unsigned int cpu)
if (cpu == policy->cpu)
return;
+ /*
+* Take direct locks as lock_policy_rwsem_write wouldn't work here.
+* Also lock for last cpu is enough here as contention will happen only
+* after policy->cpu is changed and after it is changed, other threads
+* will try to acquire lock for new cpu. And policy is already updated
+* by then.
+*/
+ down_write(_cpu(cpu_policy_rwsem, policy->cpu));
+
policy->last_cpu = policy->cpu;
policy->cpu = cpu;
+ up_write(_cpu(cpu_policy_rwsem, policy->last_cpu));
+
#ifdef CONFIG_CPU_FREQ_TABLE
cpufreq_frequency_table_update_policy_cpu(policy);
#endif
@@ -1203,9 +1214,7 @@ static int __cpufreq_remove_dev_prepare(struct device
*dev,
new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen);
if (new_cpu >= 0) {
- WARN_ON(lock_policy_rwsem_write(cpu));
update_policy_cpu(policy, new_cpu);
- unlock_policy_rwsem_write(cpu);
if (!frozen) {
pr_debug("%s: policy Kobject moved to cpu: %d "
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] cpufreq: unlock correct rwsem while updating policy->cpu
On 17 September 2013 00:12, Jon Medhurst (Tixy) wrote: > The commit log to that patch still mentions taking both locks. Yeah, it was sent in hurry to just give you a working solution and I forgot to see the log if it is still valid. > The code itself fixes the lockdep errors I had, so > > Tested-by: Jon Medhurst Great!! > however, I still have concerns about the locking (below)... :( > But what about reads, like in cpufreq_frequency_table_update_policy_cpu > which is called immediately after the unlocking writes? Should that not > be covered by a reader lock? > > And after that call, policy is passed into blocking_notifier_call_chain, > do those callbacks not want to look at policy fields? Or are they going > to do there own locking? policy->cpu is used at multiple places outside of cpufreq.c and cpufreq core can't really put read locks for those accesses. Things will turn bad only if cpufreq core has got these races where we are trying to access a struct or pointer that belonged to the last policy->cpu, which is updated now.. For example the case of lock you reported.. And so lock is required only for those places.. > Or is update_policy_cpu itself meant to be called with a read lock held? No. > This is the first time I've looked at this code, so feel free just to > say 'it's complicated, just trust me, I'm the expert, I know what I'm > doing'... We aren't that rude :) Now, that you have tested this patch let me resent it... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extending splice for copy offloading
On 09/11/2013 04:17:23 PM, Eric Wong wrote: Zach Brown wrote: > Towards the end of that thread Eric Wong asked why we didn't just > extend splice. I immediately replied with some dumb dismissive > answer. Once I sat down and looked at it, though, it does make a > lot of sense. So good job, Eric. +10 Dummie points for me. Thanks for revisiting that :> > Some things to talk about: > - I really don't care about the naming here. If you do, holler. Exposing "DIRECT" to userspace now might confuse users into expecting O_DIRECT behavior. I say this as an easily-confused user. In the future, perhaps O_DIRECT behavior can become per-splice (instead of just per-open) and can save SPLICE_F_DIRECT for that. > - We might want different flags for file-to-file splicing and acceleration > - We might want flags to require or forbid acceleration > - We might want to provide all these flags to sendfile, too Another syscall? I prefer not. Better to just maintain the sendfile API as-is for compatibility reasons and nudge users towards splice. > Thoughts? Objections? I'll try to test/comment more in a week or two (not much time for computing until then). Just a vague note that I've wanted to use splice implementing cp and patch and cat and so on in toybox, but couldn't because it needs a pipe. So I'm quite interested in moves to lift this restriction... Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] cpufreq: unlock correct rwsem while updating policy->cpu
On 17 September 2013 00:04, Rafael J. Wysocki wrote: > Care to resend with a subject indicating that that's a patch update? > > Like [PATCH v2] etc. or similar? Yeah.. I was waiting for Tixy to test it once.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 15/28] mips: use early_init_dt_scan
On 17/09/13 01:09, Rob Herring wrote:
From: Rob Herring
Convert mips to use new early_init_dt_scan function.
Remove early_init_dt_scan_memory_arch
Signed-off-by: Rob Herring
Cc: Ralf Baechle
Cc: linux-m...@linux-mips.org
---
Acked-by: John Crispin
Thanks for this series ...
arch/mips/include/asm/prom.h | 3 ---
arch/mips/kernel/prom.c | 39 +++
2 files changed, 3 insertions(+), 39 deletions(-)
diff --git a/arch/mips/include/asm/prom.h b/arch/mips/include/asm/prom.h
index 1e7e096..e3dbd0e 100644
--- a/arch/mips/include/asm/prom.h
+++ b/arch/mips/include/asm/prom.h
@@ -17,9 +17,6 @@
#include
#include
-extern int early_init_dt_scan_memory_arch(unsigned long node,
- const char *uname, int depth, void *data);
-
extern void device_tree_init(void);
static inline unsigned long pci_address_to_pio(phys_addr_t address)
diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 0fa0b69..67a4c53 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -17,8 +17,6 @@
#include
#include
#include
-#include
-#include
#include
#include
@@ -40,13 +38,6 @@ char *mips_get_machine_name(void)
}
#ifdef CONFIG_OF
-int __init early_init_dt_scan_memory_arch(unsigned long node,
- const char *uname, int depth,
- void *data)
-{
- return early_init_dt_scan_memory(node, uname, depth, data);
-}
-
void __init early_init_dt_add_memory_arch(u64 base, u64 size)
{
return add_memory_region(base, size, BOOT_MEM_RAM);
@@ -78,36 +69,12 @@ int __init early_init_dt_scan_model(unsigned long node,
const char *uname,
return 0;
}
-void __init early_init_devtree(void *params)
-{
- /* Setup flat device-tree pointer */
- initial_boot_params = params;
-
- /* Retrieve various informations from the /chosen node of the
-* device-tree, including the platform type, initrd location and
-* size, and more ...
-*/
- of_scan_flat_dt(early_init_dt_scan_chosen, arcs_cmdline);
-
-
- /* Scan memory nodes */
- of_scan_flat_dt(early_init_dt_scan_root, NULL);
- of_scan_flat_dt(early_init_dt_scan_memory_arch, NULL);
-
- /* try to load the mips machine name */
- of_scan_flat_dt(early_init_dt_scan_model, NULL);
-}
-
void __init __dt_setup_arch(struct boot_param_header *bph)
{
- if (be32_to_cpu(bph->magic) != OF_DT_HEADER) {
- pr_err("DTB has bad magic, ignoring builtin OF DTB\n");
-
+ if (!early_init_dt_scan(bph))
return;
- }
-
- initial_boot_params = bph;
- early_init_devtree(initial_boot_params);
+ /* try to load the mips machine name */
+ of_scan_flat_dt(early_init_dt_scan_model, NULL);
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 28/28] mips: use common of_flat_dt_get_machine_name
On 17/09/13 01:09, Rob Herring wrote:
From: Rob Herring
Convert mips to use the common of_flat_dt_get_machine_name function.
Signed-off-by: Rob Herring
Cc: Ralf Baechle
Cc: linux-m...@linux-mips.org
---
Acked-by: John Crispin
Thanks for this series ...
arch/mips/kernel/prom.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 0b2485f..3c3b0df 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -47,24 +47,11 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64
align)
return __alloc_bootmem(size, align, __pa(MAX_DMA_ADDRESS));
}
-int __init early_init_dt_scan_model(unsigned long node,const char
*uname,
- int depth, void *data)
-{
- if (!depth) {
- char *model = of_get_flat_dt_prop(node, "model", NULL);
-
- if (model)
- mips_set_machine_name(model);
- }
- return 0;
-}
-
void __init __dt_setup_arch(struct boot_param_header *bph)
{
if (!early_init_dt_scan(bph))
return;
- /* try to load the mips machine name */
- of_scan_flat_dt(early_init_dt_scan_model, NULL);
+ mips_set_machine_name(of_flat_dt_get_machine_name());
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ethernet/arc/arc_emac: Fix huge delays in large file copies
From: Vineet Gupta Date: Tue, 17 Sep 2013 04:07:23 + > Can you please do the needful for stable 3.11 backport of this patch. Queued up for -stable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/17] Add system table pointer argument to shared functions.
Add system table pointer argument to shared EFI stub related functions
so they no longer use a global system table pointer as they did when part
of eboot.c. For the ARM EFI stub this allows us to avoid global
variables completely and thereby not have to deal with GOT fixups.
Not having the EFI stub fixup its GOT, which is shared with the
decompressor, simplifies the relocating of the zImage to a
bootable address.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 38 +++--
drivers/firmware/efi/efi-stub-helper.c | 96 +---
2 files changed, 72 insertions(+), 62 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ab0eefc..65b6a34 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -453,13 +453,13 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
status = efi_call_phys3(sys_table->boottime->handle_protocol,
handle, , (void *));
if (status != EFI_SUCCESS) {
- efi_printk("Failed to get handle for LOADED_IMAGE_PROTOCOL\n");
+ efi_printk(sys_table, "Failed to get handle for
LOADED_IMAGE_PROTOCOL\n");
return NULL;
}
- status = low_alloc(0x4000, 1, (unsigned long *)_params);
+ status = low_alloc(sys_table, 0x4000, 1, (unsigned long *)_params);
if (status != EFI_SUCCESS) {
- efi_printk("Failed to alloc lowmem for boot params\n");
+ efi_printk(sys_table, "Failed to alloc lowmem for boot
params\n");
return NULL;
}
@@ -503,9 +503,10 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
options_size++; /* NUL termination */
- status = low_alloc(options_size, 1, );
+ status = low_alloc(sys_table, options_size, 1,
+ );
if (status != EFI_SUCCESS) {
- efi_printk("Failed to alloc mem for cmdline\n");
+ efi_printk(sys_table, "Failed to alloc mem for
cmdline\n");
goto fail;
}
@@ -529,16 +530,16 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
memset(sdt, 0, sizeof(*sdt));
- status = handle_ramdisks(image, hdr);
+ status = handle_ramdisks(sys_table, image, hdr);
if (status != EFI_SUCCESS)
goto fail2;
return boot_params;
fail2:
if (options_size)
- low_free(options_size, hdr->cmd_line_ptr);
+ low_free(sys_table, options_size, hdr->cmd_line_ptr);
fail:
- low_free(0x4000, (unsigned long)boot_params);
+ low_free(sys_table, 0x4000, (unsigned long)boot_params);
return NULL;
}
@@ -561,7 +562,7 @@ static efi_status_t exit_boot(struct boot_params
*boot_params,
again:
size += sizeof(*mem_map) * 2;
_size = size;
- status = low_alloc(size, 1, (unsigned long *)_map);
+ status = low_alloc(sys_table, size, 1, (unsigned long *)_map);
if (status != EFI_SUCCESS)
return status;
@@ -569,7 +570,7 @@ get_map:
status = efi_call_phys5(sys_table->boottime->get_memory_map, ,
mem_map, , _size, _version);
if (status == EFI_BUFFER_TOO_SMALL) {
- low_free(_size, (unsigned long)mem_map);
+ low_free(sys_table, _size, (unsigned long)mem_map);
goto again;
}
@@ -671,7 +672,7 @@ get_map:
return EFI_SUCCESS;
free_mem_map:
- low_free(_size, (unsigned long)mem_map);
+ low_free(sys_table, _size, (unsigned long)mem_map);
return status;
}
@@ -694,10 +695,10 @@ static efi_status_t relocate_kernel(struct setup_header
*hdr)
EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
nr_pages, );
if (status != EFI_SUCCESS) {
- status = low_alloc(hdr->init_size, hdr->kernel_alignment,
- );
+ status = low_alloc(sys_table, hdr->init_size,
+ hdr->kernel_alignment, );
if (status != EFI_SUCCESS)
- efi_printk("Failed to alloc mem for kernel\n");
+ efi_printk(sys_table, "Failed to alloc mem for
kernel\n");
}
if (status == EFI_SUCCESS)
@@ -737,14 +738,15 @@ struct boot_params *efi_main(void *handle,
efi_system_table_t *_table,
EFI_LOADER_DATA, sizeof(*gdt),
(void **));
if (status != EFI_SUCCESS) {
- efi_printk("Failed to alloc mem for gdt structure\n");
+ efi_printk(sys_table, "Failed to
[PATCH 03/17] Move common EFI stub code from x86 arch code to common location
No code changes made, just moving functions and #define from x86 arch
directory to common location. Code is shared using #include, similar
to how decompression code is shared among architectures.
Signed-off-by: Roy Franz
Acked-by: Mark Salter
Reviewed-by: Grant Likely
---
arch/x86/boot/compressed/eboot.c | 442 +-
arch/x86/boot/compressed/eboot.h |1 -
drivers/firmware/efi/efi-stub-helper.c | 463
3 files changed, 464 insertions(+), 442 deletions(-)
create mode 100644 drivers/firmware/efi/efi-stub-helper.c
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b7388a4..ab0eefc 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -19,214 +19,10 @@
static efi_system_table_t *sys_table;
-static void efi_char16_printk(efi_char16_t *str)
-{
- struct efi_simple_text_output_protocol *out;
-
- out = (struct efi_simple_text_output_protocol *)sys_table->con_out;
- efi_call_phys2(out->output_string, out, str);
-}
-
-static void efi_printk(char *str)
-{
- char *s8;
-
- for (s8 = str; *s8; s8++) {
- efi_char16_t ch[2] = { 0 };
-
- ch[0] = *s8;
- if (*s8 == '\n') {
- efi_char16_t nl[2] = { '\r', 0 };
- efi_char16_printk(nl);
- }
-
- efi_char16_printk(ch);
- }
-}
-
-static efi_status_t __get_map(efi_memory_desc_t **map, unsigned long *map_size,
- unsigned long *desc_size)
-{
- efi_memory_desc_t *m = NULL;
- efi_status_t status;
- unsigned long key;
- u32 desc_version;
-
- *map_size = sizeof(*m) * 32;
-again:
- /*
-* Add an additional efi_memory_desc_t because we're doing an
-* allocation which may be in a new descriptor region.
-*/
- *map_size += sizeof(*m);
- status = efi_call_phys3(sys_table->boottime->allocate_pool,
- EFI_LOADER_DATA, *map_size, (void **));
- if (status != EFI_SUCCESS)
- goto fail;
-
- status = efi_call_phys5(sys_table->boottime->get_memory_map, map_size,
- m, , desc_size, _version);
- if (status == EFI_BUFFER_TOO_SMALL) {
- efi_call_phys1(sys_table->boottime->free_pool, m);
- goto again;
- }
-
- if (status != EFI_SUCCESS)
- efi_call_phys1(sys_table->boottime->free_pool, m);
-
-fail:
- *map = m;
- return status;
-}
-
-/*
- * Allocate at the highest possible address that is not above 'max'.
- */
-static efi_status_t high_alloc(unsigned long size, unsigned long align,
- unsigned long *addr, unsigned long max)
-{
- unsigned long map_size, desc_size;
- efi_memory_desc_t *map;
- efi_status_t status;
- unsigned long nr_pages;
- u64 max_addr = 0;
- int i;
-
- status = __get_map(, _size, _size);
- if (status != EFI_SUCCESS)
- goto fail;
-
- nr_pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
-again:
- for (i = 0; i < map_size / desc_size; i++) {
- efi_memory_desc_t *desc;
- unsigned long m = (unsigned long)map;
- u64 start, end;
-
- desc = (efi_memory_desc_t *)(m + (i * desc_size));
- if (desc->type != EFI_CONVENTIONAL_MEMORY)
- continue;
-
- if (desc->num_pages < nr_pages)
- continue;
- start = desc->phys_addr;
- end = start + desc->num_pages * (1UL << EFI_PAGE_SHIFT);
+#include "../../../../drivers/firmware/efi/efi-stub-helper.c"
- if ((start + size) > end || (start + size) > max)
- continue;
-
- if (end - size > max)
- end = max;
-
- if (round_down(end - size, align) < start)
- continue;
-
- start = round_down(end - size, align);
-
- /*
-* Don't allocate at 0x0. It will confuse code that
-* checks pointers against NULL.
-*/
- if (start == 0x0)
- continue;
-
- if (start > max_addr)
- max_addr = start;
- }
-
- if (!max_addr)
- status = EFI_NOT_FOUND;
- else {
- status = efi_call_phys4(sys_table->boottime->allocate_pages,
- EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
- nr_pages, _addr);
- if (status != EFI_SUCCESS) {
- max = max_addr;
- max_addr = 0;
- goto again;
- }
-
- *addr = max_addr;
- }
-
-free_pool:
-
[PATCH 01/17] EFI stub documentation updates
Move efi-stub.txt out of x86 directory and into common directory in preparation for adding ARM EFI stub support. Signed-off-by: Roy Franz --- Documentation/efi-stub.txt | 65 Documentation/x86/efi-stub.txt | 65 arch/x86/Kconfig |2 +- 3 files changed, 66 insertions(+), 66 deletions(-) create mode 100644 Documentation/efi-stub.txt delete mode 100644 Documentation/x86/efi-stub.txt diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt new file mode 100644 index 000..44e6bb6 --- /dev/null +++ b/Documentation/efi-stub.txt @@ -0,0 +1,65 @@ + The EFI Boot Stub +--- + +On the x86 platform, a bzImage can masquerade as a PE/COFF image, +thereby convincing EFI firmware loaders to load it as an EFI +executable. The code that modifies the bzImage header, along with the +EFI-specific entry point that the firmware loader jumps to are +collectively known as the "EFI boot stub", and live in +arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c, +respectively. + +By using the EFI boot stub it's possible to boot a Linux kernel +without the use of a conventional EFI boot loader, such as grub or +elilo. Since the EFI boot stub performs the jobs of a boot loader, in +a certain sense it *IS* the boot loader. + +The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option. + + + How to install bzImage.efi + +The bzImage located in arch/x86/boot/bzImage must be copied to the EFI +System Partiion (ESP) and renamed with the extension ".efi". Without +the extension the EFI firmware loader will refuse to execute it. It's +not possible to execute bzImage.efi from the usual Linux file systems +because EFI firmware doesn't have support for them. + + + Passing kernel parameters from the EFI shell + +Arguments to the kernel can be passed after bzImage.efi, e.g. + + fs0:> bzImage.efi console=ttyS0 root=/dev/sda4 + + + The "initrd=" option + +Like most boot loaders, the EFI stub allows the user to specify +multiple initrd files using the "initrd=" option. This is the only EFI +stub-specific command line parameter, everything else is passed to the +kernel when it boots. + +The path to the initrd file must be an absolute path from the +beginning of the ESP, relative path names do not work. Also, the path +is an EFI-style path and directory elements must be separated with +backslashes (\). For example, given the following directory layout, + +fs0:> + Kernels\ + bzImage.efi + initrd-large.img + + Ramdisks\ + initrd-small.img + initrd-medium.img + +to boot with the initrd-large.img file if the current working +directory is fs0:\Kernels, the following command must be used, + + fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img + +Notice how bzImage.efi can be specified with a relative path. That's +because the image we're executing is interpreted by the EFI shell, +which understands relative paths, whereas the rest of the command line +is passed to bzImage.efi. diff --git a/Documentation/x86/efi-stub.txt b/Documentation/x86/efi-stub.txt deleted file mode 100644 index 44e6bb6..000 --- a/Documentation/x86/efi-stub.txt +++ /dev/null @@ -1,65 +0,0 @@ - The EFI Boot Stub ---- - -On the x86 platform, a bzImage can masquerade as a PE/COFF image, -thereby convincing EFI firmware loaders to load it as an EFI -executable. The code that modifies the bzImage header, along with the -EFI-specific entry point that the firmware loader jumps to are -collectively known as the "EFI boot stub", and live in -arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c, -respectively. - -By using the EFI boot stub it's possible to boot a Linux kernel -without the use of a conventional EFI boot loader, such as grub or -elilo. Since the EFI boot stub performs the jobs of a boot loader, in -a certain sense it *IS* the boot loader. - -The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option. - - - How to install bzImage.efi - -The bzImage located in arch/x86/boot/bzImage must be copied to the EFI -System Partiion (ESP) and renamed with the extension ".efi". Without -the extension the EFI firmware loader will refuse to execute it. It's -not possible to execute bzImage.efi from the usual Linux file systems -because EFI firmware doesn't have support for them. - - - Passing kernel parameters from the EFI shell - -Arguments to the kernel can be passed after bzImage.efi, e.g. - - fs0:> bzImage.efi console=ttyS0 root=/dev/sda4 - - - The "initrd=" option - -Like most boot loaders, the EFI stub allows the user to specify -multiple initrd files using the "initrd=" option. This is the only EFI -stub-specific command line parameter, everything
[PATCH 09/17] Move unicode to ASCII conversion to shared function.
Move the open-coded conversion to a shared function for
use by all architectures. Change the allocation to prefer
a high address for ARM, as this is required to avoid conflicts
with reserved regions in low memory. We don't know the specifics
of these regions until after we process the command line and
device tree.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 43 ---
drivers/firmware/efi/efi-stub-helper.c | 58
2 files changed, 64 insertions(+), 37 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 7fe2754..a0e8a2c 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -435,11 +435,10 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
struct efi_info *efi;
efi_loaded_image_t *image;
void *options;
- u32 load_options_size;
efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
int options_size = 0;
efi_status_t status;
- unsigned long cmdline;
+ char *cmdline_ptr;
u16 *s2;
u8 *s1;
int i;
@@ -487,41 +486,11 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
hdr->type_of_loader = 0x21;
/* Convert unicode cmdline to ascii */
- options = image->load_options;
- load_options_size = image->load_options_size / 2; /* ASCII */
- cmdline = 0;
- s2 = (u16 *)options;
-
- if (s2) {
- while (*s2 && *s2 != '\n' && options_size < load_options_size) {
- s2++;
- options_size++;
- }
-
- if (options_size) {
- if (options_size > hdr->cmdline_size)
- options_size = hdr->cmdline_size;
-
- options_size++; /* NUL termination */
-
- status = efi_low_alloc(sys_table, options_size, 1,
- );
- if (status != EFI_SUCCESS) {
- efi_printk(sys_table, "Failed to alloc mem for
cmdline\n");
- goto fail;
- }
-
- s1 = (u8 *)(unsigned long)cmdline;
- s2 = (u16 *)options;
-
- for (i = 0; i < options_size - 1; i++)
- *s1++ = *s2++;
-
- *s1 = '\0';
- }
- }
-
- hdr->cmd_line_ptr = cmdline;
+ cmdline_ptr = efi_convert_cmdline_to_ascii(sys_table, image,
+ _size);
+ if (!cmdline_ptr)
+ goto fail;
+ hdr->cmd_line_ptr = (unsigned long)cmdline_ptr;
hdr->ramdisk_image = 0;
hdr->ramdisk_size = 0;
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index e34040e..4f88e38 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -546,3 +546,61 @@ static efi_status_t efi_relocate_kernel(efi_system_table_t
*sys_table_arg,
return status;
}
+/* Convert the unicode UEFI command line to ASCII to pass to kernel.
+ * Size of memory allocated return in *cmd_line_len.
+ * Returns NULL on error.
+ */
+static char *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
+ efi_loaded_image_t *image,
+ int *cmd_line_len)
+{
+ u16 *s2;
+ u8 *s1 = NULL;
+ unsigned long cmdline_addr = 0;
+ int load_options_size = image->load_options_size / 2; /* ASCII */
+ void *options = image->load_options;
+ int options_size = 0;
+ efi_status_t status;
+ int i;
+ u16 zero = 0;
+
+ if (options) {
+ s2 = options;
+ while (*s2 && *s2 != '\n' && options_size < load_options_size) {
+ s2++;
+ options_size++;
+ }
+ }
+
+ if (options_size == 0) {
+ /* No command line options, so return empty string*/
+ options_size = 1;
+ options =
+ }
+
+ options_size++; /* NUL termination */
+#ifdef CONFIG_ARM
+ /* For ARM, allocate at a high address to avoid reserved
+* regions at low addresses that we don't know the specfics of
+* at the time we are processing the command line.
+*/
+ status = efi_high_alloc(sys_table_arg, options_size, 0,
+ _addr, 0xf000);
+#else
+ status = efi_low_alloc(sys_table_arg, options_size, 0,
+ _addr);
+#endif
+ if (status != EFI_SUCCESS)
+ return NULL;
+
+ s1 = (u8 *)cmdline_addr;
+ s2 = (u16 *)options;
+
+ for (i = 0; i < options_size - 1; i++)
+
[PATCH 05/17] Rename memory allocation/free functions
Rename them to be more similar, as low_free() could be used to free
memory allocated by both high_alloc() and low_alloc().
high_alloc() -> efi_high_alloc()
low_alloc() -> efi_low_alloc()
low_free() -> efi_free()
Signed-off-by: Roy Franz
Acked-by: Mark Salter
Reviewed-by: Grant Likely
---
arch/x86/boot/compressed/eboot.c | 19 ++-
drivers/firmware/efi/efi-stub-helper.c | 14 +++---
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 65b6a34..2a4430a 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -457,7 +457,8 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
return NULL;
}
- status = low_alloc(sys_table, 0x4000, 1, (unsigned long *)_params);
+ status = efi_low_alloc(sys_table, 0x4000, 1,
+ (unsigned long *)_params);
if (status != EFI_SUCCESS) {
efi_printk(sys_table, "Failed to alloc lowmem for boot
params\n");
return NULL;
@@ -503,7 +504,7 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
options_size++; /* NUL termination */
- status = low_alloc(sys_table, options_size, 1,
+ status = efi_low_alloc(sys_table, options_size, 1,
);
if (status != EFI_SUCCESS) {
efi_printk(sys_table, "Failed to alloc mem for
cmdline\n");
@@ -537,9 +538,9 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
return boot_params;
fail2:
if (options_size)
- low_free(sys_table, options_size, hdr->cmd_line_ptr);
+ efi_free(sys_table, options_size, hdr->cmd_line_ptr);
fail:
- low_free(sys_table, 0x4000, (unsigned long)boot_params);
+ efi_free(sys_table, 0x4000, (unsigned long)boot_params);
return NULL;
}
@@ -562,7 +563,7 @@ static efi_status_t exit_boot(struct boot_params
*boot_params,
again:
size += sizeof(*mem_map) * 2;
_size = size;
- status = low_alloc(sys_table, size, 1, (unsigned long *)_map);
+ status = efi_low_alloc(sys_table, size, 1, (unsigned long *)_map);
if (status != EFI_SUCCESS)
return status;
@@ -570,7 +571,7 @@ get_map:
status = efi_call_phys5(sys_table->boottime->get_memory_map, ,
mem_map, , _size, _version);
if (status == EFI_BUFFER_TOO_SMALL) {
- low_free(sys_table, _size, (unsigned long)mem_map);
+ efi_free(sys_table, _size, (unsigned long)mem_map);
goto again;
}
@@ -672,7 +673,7 @@ get_map:
return EFI_SUCCESS;
free_mem_map:
- low_free(sys_table, _size, (unsigned long)mem_map);
+ efi_free(sys_table, _size, (unsigned long)mem_map);
return status;
}
@@ -695,7 +696,7 @@ static efi_status_t relocate_kernel(struct setup_header
*hdr)
EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
nr_pages, );
if (status != EFI_SUCCESS) {
- status = low_alloc(sys_table, hdr->init_size,
+ status = efi_low_alloc(sys_table, hdr->init_size,
hdr->kernel_alignment, );
if (status != EFI_SUCCESS)
efi_printk(sys_table, "Failed to alloc mem for
kernel\n");
@@ -743,7 +744,7 @@ struct boot_params *efi_main(void *handle,
efi_system_table_t *_table,
}
gdt->size = 0x800;
- status = low_alloc(sys_table, gdt->size, 8,
+ status = efi_low_alloc(sys_table, gdt->size, 8,
(unsigned long *)>address);
if (status != EFI_SUCCESS) {
efi_printk(sys_table, "Failed to alloc mem for gdt\n");
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 05c539e..2f528fb 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -86,7 +86,7 @@ fail:
/*
* Allocate at the highest possible address that is not above 'max'.
*/
-static efi_status_t high_alloc(efi_system_table_t *sys_table_arg,
+static efi_status_t efi_high_alloc(efi_system_table_t *sys_table_arg,
unsigned long size, unsigned long align,
unsigned long *addr, unsigned long max)
{
@@ -165,8 +165,8 @@ fail:
/*
* Allocate at the lowest possible address.
*/
-static efi_status_t low_alloc(efi_system_table_t *sys_table_arg,
- unsigned long size, unsigned long align,
+static efi_status_t efi_low_alloc(efi_system_table_t *sys_table_arg,
+ unsigned long size, unsigned long align,
[PATCH 11/17] generalize efi_get_memory_map()
Add arguments for returning the descriptor version and also
the memory map key. The key is required for calling
exit_boot_services().
Signed-off-by: Roy Franz
---
drivers/firmware/efi/efi-stub-helper.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 7c158cb..ca1592b 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -49,7 +49,9 @@ static void efi_printk(efi_system_table_t *sys_table_arg,
char *str)
static efi_status_t efi_get_memory_map(efi_system_table_t *sys_table_arg,
efi_memory_desc_t **map,
unsigned long *map_size,
- unsigned long *desc_size)
+ unsigned long *desc_size,
+ u32 *desc_ver,
+ unsigned long *key_ptr)
{
efi_memory_desc_t *m = NULL;
efi_status_t status;
@@ -77,6 +79,10 @@ again:
if (status != EFI_SUCCESS)
efi_call_phys1(sys_table_arg->boottime->free_pool, m);
+ if (key_ptr && status == EFI_SUCCESS)
+ *key_ptr = key;
+ if (desc_ver && status == EFI_SUCCESS)
+ *desc_ver = desc_version;
fail:
*map = m;
@@ -97,7 +103,8 @@ static efi_status_t efi_high_alloc(efi_system_table_t
*sys_table_arg,
u64 max_addr = 0;
int i;
- status = efi_get_memory_map(sys_table_arg, , _size, _size);
+ status = efi_get_memory_map(sys_table_arg, , _size, _size,
+ NULL, NULL);
if (status != EFI_SUCCESS)
goto fail;
@@ -182,7 +189,8 @@ static efi_status_t efi_low_alloc(efi_system_table_t
*sys_table_arg,
unsigned long nr_pages;
int i;
- status = efi_get_memory_map(sys_table_arg, , _size, _size);
+ status = efi_get_memory_map(sys_table_arg, , _size, _size,
+ NULL, NULL);
if (status != EFI_SUCCESS)
goto fail;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/17] Move relocate_kernel() to shared file.
The relocate_kernel() function will be generalized and used
by all architectures, as they all have similar requirements.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 34 ---
drivers/firmware/efi/efi-stub-helper.c | 35
2 files changed, 35 insertions(+), 34 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 2a4430a..5bbba86 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -677,40 +677,6 @@ free_mem_map:
return status;
}
-static efi_status_t relocate_kernel(struct setup_header *hdr)
-{
- unsigned long start, nr_pages;
- efi_status_t status;
-
- /*
-* The EFI firmware loader could have placed the kernel image
-* anywhere in memory, but the kernel has various restrictions
-* on the max physical address it can run at. Attempt to move
-* the kernel to boot_params.pref_address, or as low as
-* possible.
-*/
- start = hdr->pref_address;
- nr_pages = round_up(hdr->init_size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
-
- status = efi_call_phys4(sys_table->boottime->allocate_pages,
- EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
- nr_pages, );
- if (status != EFI_SUCCESS) {
- status = efi_low_alloc(sys_table, hdr->init_size,
- hdr->kernel_alignment, );
- if (status != EFI_SUCCESS)
- efi_printk(sys_table, "Failed to alloc mem for
kernel\n");
- }
-
- if (status == EFI_SUCCESS)
- memcpy((void *)start, (void *)(unsigned long)hdr->code32_start,
- hdr->init_size);
-
- hdr->pref_address = hdr->code32_start;
- hdr->code32_start = (__u32)start;
-
- return status;
-}
/*
* On success we return a pointer to a boot_params structure, and NULL
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 9e451c6..1d5f219 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -483,3 +483,38 @@ fail:
return status;
}
+
+static efi_status_t relocate_kernel(struct setup_header *hdr)
+{
+ unsigned long start, nr_pages;
+ efi_status_t status;
+
+ /*
+* The EFI firmware loader could have placed the kernel image
+* anywhere in memory, but the kernel has various restrictions
+* on the max physical address it can run at. Attempt to move
+* the kernel to boot_params.pref_address, or as low as
+* possible.
+*/
+ start = hdr->pref_address;
+ nr_pages = round_up(hdr->init_size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
+
+ status = efi_call_phys4(sys_table->boottime->allocate_pages,
+ EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
+ nr_pages, );
+ if (status != EFI_SUCCESS) {
+ status = efi_low_alloc(sys_table, hdr->init_size,
+ hdr->kernel_alignment, );
+ if (status != EFI_SUCCESS)
+ efi_printk(sys_table, "Failed to alloc mem for
kernel\n");
+ }
+
+ if (status == EFI_SUCCESS)
+ memcpy((void *)start, (void *)(unsigned long)hdr->code32_start,
+ hdr->init_size);
+
+ hdr->pref_address = hdr->code32_start;
+ hdr->code32_start = (__u32)start;
+
+ return status;
+}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf session: Add option to copy events when queueing
On 9/16/13 10:40 AM, Frederic Weisbecker wrote: Yes. I could make it the default behavior; just overhead in doing that (malloc/copy for each event). Are there any tool that don't suffer from this bug somehow? If not then it must be applied unconditionally. I believe only 'live' commands would be affected: top, kvm stat live, my local scheduling daemon. perf-trace bypasses session and time ordering (though I question that decision). ---8<--- size of event is determined by mmap_event (mmap2_event in latest code) which is > 4096 because of the filename argument. Including the event directly in sample_queue would balloon memory usage (learned this the hard way!). Ah then perhaps we can allocate with the dynamic size of the event? Yes, that's how I have it my patch -- allocate memory based on header size and copy in the queue_event function. I think we agree on this part now. ---8<--- Although the mirrored os->sample_buffer condition check is a bit ugly and should move to a function. But the idea is there. Ok. That should be a separate patch. Are you going to submit that one? Yeah, unless you beat me at it :) That's not going to happen on my end due to a recent time constraint (jury duty - minimum 1 week trial). At best I can do a patch in early October. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/17] Enforce minimum alignment of 1 page on allocations.
The efi_high_alloc() and efi_low_alloc() functions
use the EFI_ALLOCATE_ADDRESS option to the EFI
function allocate_pages(), which requires a minimum
of page alignment, and rejects all other requests.
The existing code could fail to allocate depending
on allocation size, as although repeated allocation
attempts were made, none were guaranteed to be page
aligned.
Signed-off-by: Roy Franz
Acked-by: Mark Salter
Reviewed-by: Grant Likely
---
drivers/firmware/efi/efi-stub-helper.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 2f528fb..9e451c6 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -101,6 +101,13 @@ static efi_status_t efi_high_alloc(efi_system_table_t
*sys_table_arg,
if (status != EFI_SUCCESS)
goto fail;
+ /* Enforce minimum alignment that EFI requires when requesting
+* a specific address. We are doing page-based allocations,
+* so we must be aligned to a page.
+*/
+ if (align < EFI_PAGE_SIZE)
+ align = EFI_PAGE_SIZE;
+
nr_pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
again:
for (i = 0; i < map_size / desc_size; i++) {
@@ -179,6 +186,13 @@ static efi_status_t efi_low_alloc(efi_system_table_t
*sys_table_arg,
if (status != EFI_SUCCESS)
goto fail;
+ /* Enforce minimum alignment that EFI requires when requesting
+* a specific address. We are doing page-based allocations,
+* so we must be aligned to a page.
+*/
+ if (align < EFI_PAGE_SIZE)
+ align = EFI_PAGE_SIZE;
+
nr_pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
for (i = 0; i < map_size / desc_size; i++) {
efi_memory_desc_t *desc;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/17] Renames in handle_cmdline_files() to complete generalization.
Rename variables to be not initrd specific, as now the function
loads arbitrary files. This change is exclusively renames
and comment changes to reflect the generalization.
Signed-off-by: Roy Franz
Acked-by: Mark Salter
Reviewed-by: Grant Likely
---
drivers/firmware/efi/efi-stub-helper.c | 92
1 file changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index d56ce3f..9437edd 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -11,7 +11,7 @@
*/
#define EFI_READ_CHUNK_SIZE(1024 * 1024)
-struct initrd {
+struct file_info {
efi_file_handle_t *handle;
u64 size;
};
@@ -262,10 +262,10 @@ static void efi_free(efi_system_table_t *sys_table_arg,
unsigned long size,
/*
- * Check the cmdline for a LILO-style initrd= arguments.
+ * Check the cmdline for a LILO-style file= arguments.
*
- * We only support loading an initrd from the same filesystem as the
- * kernel image.
+ * We only support loading a file from the same filesystem as
+ * the kernel image.
*/
static efi_status_t handle_cmdline_files(efi_system_table_t *sys_table_arg,
efi_loaded_image_t *image,
@@ -274,19 +274,19 @@ static efi_status_t
handle_cmdline_files(efi_system_table_t *sys_table_arg,
unsigned long *load_addr,
unsigned long *load_size)
{
- struct initrd *initrds;
- unsigned long initrd_addr;
+ struct file_info *files;
+ unsigned long file_addr;
efi_guid_t fs_proto = EFI_FILE_SYSTEM_GUID;
- u64 initrd_total;
+ u64 file_size_total;
efi_file_io_interface_t *io;
efi_file_handle_t *fh;
efi_status_t status;
- int nr_initrds;
+ int nr_files;
char *str;
int i, j, k;
- initrd_addr = 0;
- initrd_total = 0;
+ file_addr = 0;
+ file_size_total = 0;
str = cmd_line;
@@ -301,7 +301,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t
*sys_table_arg,
if (!str || !*str)
return EFI_SUCCESS;
- for (nr_initrds = 0; *str; nr_initrds++) {
+ for (nr_files = 0; *str; nr_files++) {
str = strstr(str, option_string);
if (!str)
break;
@@ -316,21 +316,21 @@ static efi_status_t
handle_cmdline_files(efi_system_table_t *sys_table_arg,
str++;
}
- if (!nr_initrds)
+ if (!nr_files)
return EFI_SUCCESS;
status = efi_call_phys3(sys_table_arg->boottime->allocate_pool,
EFI_LOADER_DATA,
- nr_initrds * sizeof(*initrds),
- );
+ nr_files * sizeof(*files),
+ );
if (status != EFI_SUCCESS) {
- efi_printk(sys_table_arg, "Failed to alloc mem for file
load\n");
+ efi_printk(sys_table_arg, "Failed to alloc mem for file handle
list\n");
goto fail;
}
str = cmd_line;
- for (i = 0; i < nr_initrds; i++) {
- struct initrd *initrd;
+ for (i = 0; i < nr_files; i++) {
+ struct file_info *file;
efi_file_handle_t *h;
efi_file_info_t *info;
efi_char16_t filename_16[256];
@@ -345,7 +345,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t
*sys_table_arg,
str += strlen(option_string);
- initrd = [i];
+ file = [i];
p = filename_16;
/* Skip any leading slashes */
@@ -376,13 +376,13 @@ static efi_status_t
handle_cmdline_files(efi_system_table_t *sys_table_arg,
image->device_handle, _proto, );
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to handle
fs_proto\n");
- goto free_initrds;
+ goto free_files;
}
status = efi_call_phys2(io->open_volume, io, );
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to open
volume\n");
- goto free_initrds;
+ goto free_files;
}
}
@@ -395,7 +395,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t
*sys_table_arg,
goto close_handles;
}
- initrd->handle = h;
+ file->handle = h;
info_sz = 0;
status = efi_call_phys4(h->get_info, h, _guid,
@@ -429,37
[PATCH 14/17] Generalize handle_ramdisks() and rename to handle_cmdline_files().
The handle_cmdline_files now takes the option to handle as a string,
and returns the loaded data through parameters, rather than taking
an x86 specific setup_header structure. For ARM, this will be used
to load a device tree blob in addition to initrd images.
Signed-off-by: Roy Franz
Acked-by: Mark Salter
Reviewed-by: Grant Likely
---
arch/x86/boot/compressed/eboot.c |9 +-
drivers/firmware/efi/efi-stub-helper.c | 51 +++-
2 files changed, 38 insertions(+), 22 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 2bf1f83..bf56206 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -442,6 +442,8 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
u16 *s2;
u8 *s1;
int i;
+ unsigned long ramdisk_addr;
+ unsigned long ramdisk_size;
sys_table = _table;
@@ -500,9 +502,14 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
memset(sdt, 0, sizeof(*sdt));
- status = handle_ramdisks(sys_table, image, hdr);
+ status = handle_cmdline_files(sys_table, image,
+ (char *)(unsigned long)hdr->cmd_line_ptr,
+ "initrd=", hdr->initrd_addr_max,
+ _addr, _size);
if (status != EFI_SUCCESS)
goto fail2;
+ hdr->ramdisk_image = ramdisk_addr;
+ hdr->ramdisk_size = ramdisk_size;
return boot_params;
fail2:
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 06ef01c..d56ce3f 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -267,9 +267,12 @@ static void efi_free(efi_system_table_t *sys_table_arg,
unsigned long size,
* We only support loading an initrd from the same filesystem as the
* kernel image.
*/
-static efi_status_t handle_ramdisks(efi_system_table_t *sys_table_arg,
- efi_loaded_image_t *image,
- struct setup_header *hdr)
+static efi_status_t handle_cmdline_files(efi_system_table_t *sys_table_arg,
+efi_loaded_image_t *image,
+char *cmd_line, char *option_string,
+unsigned long max_addr,
+unsigned long *load_addr,
+unsigned long *load_size)
{
struct initrd *initrds;
unsigned long initrd_addr;
@@ -285,19 +288,25 @@ static efi_status_t handle_ramdisks(efi_system_table_t
*sys_table_arg,
initrd_addr = 0;
initrd_total = 0;
- str = (char *)(unsigned long)hdr->cmd_line_ptr;
+ str = cmd_line;
j = 0; /* See close_handles */
+ if (!load_addr || !load_size)
+ return EFI_INVALID_PARAMETER;
+
+ *load_addr = 0;
+ *load_size = 0;
+
if (!str || !*str)
return EFI_SUCCESS;
for (nr_initrds = 0; *str; nr_initrds++) {
- str = strstr(str, "initrd=");
+ str = strstr(str, option_string);
if (!str)
break;
- str += 7;
+ str += strlen(option_string);
/* Skip any leading slashes */
while (*str == '/' || *str == '\\')
@@ -315,11 +324,11 @@ static efi_status_t handle_ramdisks(efi_system_table_t
*sys_table_arg,
nr_initrds * sizeof(*initrds),
);
if (status != EFI_SUCCESS) {
- efi_printk(sys_table_arg, "Failed to alloc mem for initrds\n");
+ efi_printk(sys_table_arg, "Failed to alloc mem for file
load\n");
goto fail;
}
- str = (char *)(unsigned long)hdr->cmd_line_ptr;
+ str = cmd_line;
for (i = 0; i < nr_initrds; i++) {
struct initrd *initrd;
efi_file_handle_t *h;
@@ -330,11 +339,11 @@ static efi_status_t handle_ramdisks(efi_system_table_t
*sys_table_arg,
efi_char16_t *p;
u64 file_sz;
- str = strstr(str, "initrd=");
+ str = strstr(str, option_string);
if (!str)
break;
- str += 7;
+ str += strlen(option_string);
initrd = [i];
p = filename_16;
@@ -380,7 +389,7 @@ static efi_status_t handle_ramdisks(efi_system_table_t
*sys_table_arg,
status = efi_call_phys5(fh->open, fh, , filename_16,
EFI_FILE_MODE_READ, (u64)0);
if (status != EFI_SUCCESS) {
- efi_printk(sys_table_arg, "Failed to open
[PATCH 17/17] resolve warnings found on ARM compile
warnings from gcc:
warning: label 'free_pool' defined but not used [-Wunused-label]
warning: value computed is not used [-Wunused-value]
Signed-off-by: Roy Franz
---
drivers/firmware/efi/efi-stub-helper.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 6b28845..c91e757 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -169,7 +169,6 @@ again:
*addr = max_addr;
}
-free_pool:
efi_call_phys1(sys_table_arg->boottime->free_pool, map);
fail:
@@ -242,7 +241,6 @@ static efi_status_t efi_low_alloc(efi_system_table_t
*sys_table_arg,
if (i == map_size / desc_size)
status = EFI_NOT_FOUND;
-free_pool:
efi_call_phys1(sys_table_arg->boottime->free_pool, map);
fail:
return status;
@@ -358,7 +356,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t
*sys_table_arg,
if (*str == '/') {
*p++ = '\\';
- *str++;
+ str++;
} else {
*p++ = *str++;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/17] Fix types in EFI calls to match EFI function definitions.
EFI calls can made directly on ARM, so the function pointers
are directly invoked. This allows types to be checked at
compile time, so here we ensure that the parameters match
the function signature. The wrappers used by x86 prevent
any type checking.
Correct the type of chunksize to be based on native
width as specified by the EFI_FILE_PROTOCOL read()
function.
Signed-off-by: Roy Franz
---
drivers/firmware/efi/efi-stub-helper.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 9437edd..6b28845 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -322,7 +322,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t
*sys_table_arg,
status = efi_call_phys3(sys_table_arg->boottime->allocate_pool,
EFI_LOADER_DATA,
nr_files * sizeof(*files),
- );
+ (void **));
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to alloc mem for file handle
list\n");
goto fail;
@@ -373,7 +373,8 @@ static efi_status_t handle_cmdline_files(efi_system_table_t
*sys_table_arg,
boottime = sys_table_arg->boottime;
status = efi_call_phys3(boottime->handle_protocol,
- image->device_handle, _proto, );
+ image->device_handle, _proto,
+ (void **));
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to handle
fs_proto\n");
goto free_files;
@@ -407,7 +408,8 @@ static efi_status_t handle_cmdline_files(efi_system_table_t
*sys_table_arg,
grow:
status = efi_call_phys3(sys_table_arg->boottime->allocate_pool,
- EFI_LOADER_DATA, info_sz, );
+ EFI_LOADER_DATA, info_sz,
+ (void **));
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to alloc mem for file
info\n");
goto close_handles;
@@ -457,18 +459,19 @@ grow:
addr = file_addr;
for (j = 0; j < nr_files; j++) {
- u64 size;
+ unsigned long size;
size = files[j].size;
while (size) {
- u64 chunksize;
+ unsigned long chunksize;
if (size > EFI_READ_CHUNK_SIZE)
chunksize = EFI_READ_CHUNK_SIZE;
else
chunksize = size;
status = efi_call_phys3(fh->read,
files[j].handle,
- , addr);
+ ,
+ (void *)addr);
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to
read file\n");
goto free_file_total;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/17] Generalize relocate_kernel() for use by other architectures.
Rename relocate_kernel() to efi_relocate_kernel(), and take
parameters rather than x86 specific structure. Add max_addr
argument as for ARM we have some address constraints that we
need to enforce when relocating the kernel. Add alloc_size
parameter for use by ARM64 which uses an uncompressed kernel,
and needs to allocate space for BSS.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 12 --
drivers/firmware/efi/efi-stub-helper.c | 74 ++--
2 files changed, 60 insertions(+), 26 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 5bbba86..7fe2754 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -730,13 +730,19 @@ struct boot_params *efi_main(void *handle,
efi_system_table_t *_table,
/*
* If the kernel isn't already loaded at the preferred load
-* address, relocate it.
+* address, relocate it. Enforce allocation in 32 bit
+* addressable space.
*/
if (hdr->pref_address != hdr->code32_start) {
- status = relocate_kernel(hdr);
-
+ unsigned long bzimage_addr = hdr->code32_start;
+ status = efi_relocate_kernel(sys_table, _addr,
+hdr->init_size, hdr->init_size,
+hdr->pref_address);
if (status != EFI_SUCCESS)
goto fail;
+
+ hdr->pref_address = hdr->code32_start;
+ hdr->code32_start = bzimage_addr;
}
status = exit_boot(boot_params, handle);
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 1d5f219..e34040e 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -483,38 +483,66 @@ fail:
return status;
}
-
-static efi_status_t relocate_kernel(struct setup_header *hdr)
+/* Relocate a kernel image, either compressed or uncompressed.
+ * In the ARM64 case, all kernel images are currently
+ * uncompressed, and as such when we relocate it we need to
+ * allocate additional space for the BSS segment. Any low
+ * memory that this function should avoid needs to be
+ * unavailable in the EFI memory map, as if the preferred
+ * address is not available the lowest available address will
+ * be used.
+ */
+static efi_status_t efi_relocate_kernel(efi_system_table_t *sys_table_arg,
+ unsigned long *image_addr,
+ unsigned long image_size,
+ unsigned long alloc_size,
+ unsigned long preferred_addr)
{
- unsigned long start, nr_pages;
+ unsigned long cur_image_addr;
+ unsigned long new_addr = 0;
efi_status_t status;
+ unsigned long nr_pages;
+ efi_physical_addr_t efi_addr = preferred_addr;
- /*
-* The EFI firmware loader could have placed the kernel image
-* anywhere in memory, but the kernel has various restrictions
-* on the max physical address it can run at. Attempt to move
-* the kernel to boot_params.pref_address, or as low as
-* possible.
-*/
- start = hdr->pref_address;
- nr_pages = round_up(hdr->init_size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
+ if (!image_addr || !image_size || !alloc_size)
+ return EFI_INVALID_PARAMETER;
+ if (alloc_size < image_size)
+ return EFI_INVALID_PARAMETER;
- status = efi_call_phys4(sys_table->boottime->allocate_pages,
+ cur_image_addr = *image_addr;
+
+ /* The EFI firmware loader could have placed the kernel image
+* anywhere in memory, but the kernel has restrictions on the
+* anywhere in memory, but the kernel has restrictions on the
+* max physical address it can run at. Some architectures
+* also have a prefered address, so first try to relocate
+* to the preferred address.
+*/
+ nr_pages = round_up(alloc_size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
+ status = efi_call_phys4(sys_table_arg->boottime->allocate_pages,
EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
- nr_pages, );
+ nr_pages, _addr);
+ new_addr = efi_addr;
+ /* If preferred address allocation failed allocate as low as
+* possible. */
if (status != EFI_SUCCESS) {
- status = efi_low_alloc(sys_table, hdr->init_size,
- hdr->kernel_alignment, );
- if (status != EFI_SUCCESS)
- efi_printk(sys_table, "Failed to alloc mem for
kernel\n");
+ status = efi_low_alloc(sys_table_arg, alloc_size, 0,
+ _addr);
+ }
+
[PATCH 12/17] use efi_get_memory_map() to get final map for x86
Replace the open-coded memory map getting with the
efi_get_memory_map() that is now general enough to use.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index a0e8a2c..e1fbb2e 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -527,25 +527,12 @@ static efi_status_t exit_boot(struct boot_params
*boot_params,
u8 nr_entries;
int i;
- size = sizeof(*mem_map) * 32;
-
-again:
- size += sizeof(*mem_map) * 2;
- _size = size;
- status = efi_low_alloc(sys_table, size, 1, (unsigned long *)_map);
- if (status != EFI_SUCCESS)
- return status;
-
get_map:
- status = efi_call_phys5(sys_table->boottime->get_memory_map, ,
- mem_map, , _size, _version);
- if (status == EFI_BUFFER_TOO_SMALL) {
- efi_free(sys_table, _size, (unsigned long)mem_map);
- goto again;
- }
+ status = efi_get_memory_map(sys_table, _map, , _size,
+ _version, );
if (status != EFI_SUCCESS)
- goto free_mem_map;
+ return status;
memcpy(>efi_loader_signature, EFI_LOADER_SIGNATURE, sizeof(__u32));
efi->efi_systab = (unsigned long)sys_table;
@@ -574,6 +561,7 @@ get_map:
goto free_mem_map;
called_exit = true;
+ efi_call_phys1(sys_table->boottime->free_pool, mem_map);
goto get_map;
}
@@ -642,7 +630,7 @@ get_map:
return EFI_SUCCESS;
free_mem_map:
- efi_free(sys_table, _size, (unsigned long)mem_map);
+ efi_call_phys1(sys_table->boottime->free_pool, mem_map);
return status;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/17] Rename __get_map() to efi_get_memory_map()
Rename function in preparation for making it more flexible
and sharing it.
Signed-off-by: Roy Franz
---
drivers/firmware/efi/efi-stub-helper.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index 4f88e38..7c158cb 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -46,10 +46,10 @@ static void efi_printk(efi_system_table_t *sys_table_arg,
char *str)
}
-static efi_status_t __get_map(efi_system_table_t *sys_table_arg,
- efi_memory_desc_t **map,
- unsigned long *map_size,
- unsigned long *desc_size)
+static efi_status_t efi_get_memory_map(efi_system_table_t *sys_table_arg,
+ efi_memory_desc_t **map,
+ unsigned long *map_size,
+ unsigned long *desc_size)
{
efi_memory_desc_t *m = NULL;
efi_status_t status;
@@ -97,7 +97,7 @@ static efi_status_t efi_high_alloc(efi_system_table_t
*sys_table_arg,
u64 max_addr = 0;
int i;
- status = __get_map(sys_table_arg, , _size, _size);
+ status = efi_get_memory_map(sys_table_arg, , _size, _size);
if (status != EFI_SUCCESS)
goto fail;
@@ -182,7 +182,7 @@ static efi_status_t efi_low_alloc(efi_system_table_t
*sys_table_arg,
unsigned long nr_pages;
int i;
- status = __get_map(sys_table_arg, , _size, _size);
+ status = efi_get_memory_map(sys_table_arg, , _size, _size);
if (status != EFI_SUCCESS)
goto fail;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/17] Allow efi_free() to be called with size of 0, and do nothing in that case.
Make efi_free() safely callable with size of 0, similar to free() being
callable with NULL pointers.
Remove size checks that this makes redundant. This also avoids some
size checks in the ARM EFI stub code that will be added as well.
Signed-off-by: Roy Franz
---
arch/x86/boot/compressed/eboot.c |3 +--
drivers/firmware/efi/efi-stub-helper.c |3 +++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index e1fbb2e..2bf1f83 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -506,8 +506,7 @@ struct boot_params *make_boot_params(void *handle,
efi_system_table_t *_table)
return boot_params;
fail2:
- if (options_size)
- efi_free(sys_table, options_size, hdr->cmd_line_ptr);
+ efi_free(sys_table, options_size, hdr->cmd_line_ptr);
fail:
efi_free(sys_table, 0x4000, (unsigned long)boot_params);
return NULL;
diff --git a/drivers/firmware/efi/efi-stub-helper.c
b/drivers/firmware/efi/efi-stub-helper.c
index ca1592b..06ef01c 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -253,6 +253,9 @@ static void efi_free(efi_system_table_t *sys_table_arg,
unsigned long size,
{
unsigned long nr_pages;
+ if (!size)
+ return;
+
nr_pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
efi_call_phys2(sys_table_arg->boottime->free_pages, addr, nr_pages);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/17] Add proper definitions for some EFI function pointers.
The x86/AMD64 EFI stubs must use a call wrapper to convert between
the Linux and EFI ABIs, so void pointers are sufficient. For ARM,
the ABIs are compatible, so we can directly invoke the function
pointers. The functions that are used by the ARM stub are updated
to match the EFI definitions.
Also add some EFI types used by EFI functions.
Signed-off-by: Roy Franz
Acked-by: Mark Salter
Reviewed-by: Grant Likely
---
arch/x86/boot/compressed/eboot.h |8 --
include/linux/efi.h | 50 ++
2 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.h b/arch/x86/boot/compressed/eboot.h
index e5b0a8f..0226510 100644
--- a/arch/x86/boot/compressed/eboot.h
+++ b/arch/x86/boot/compressed/eboot.h
@@ -10,8 +10,6 @@
#define SEG_GRANULARITY_4KB(1 << 0)
#define DESC_TYPE_CODE_DATA(1 << 0)
-
-#define EFI_PAGE_SIZE (1UL << EFI_PAGE_SHIFT)
#define EFI_READ_CHUNK_SIZE(1024 * 1024)
#define EFI_CONSOLE_OUT_DEVICE_GUID\
@@ -62,10 +60,4 @@ struct efi_uga_draw_protocol {
void *blt;
};
-struct efi_simple_text_output_protocol {
- void *reset;
- void *output_string;
- void *test_string;
-};
-
#endif /* BOOT_COMPRESSED_EBOOT_H */
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 5f8f176..840ab28 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -39,6 +39,8 @@
typedef unsigned long efi_status_t;
typedef u8 efi_bool_t;
typedef u16 efi_char16_t; /* UNICODE character */
+typedef u64 efi_physical_addr_t;
+typedef void *efi_handle_t;
typedef struct {
@@ -96,6 +98,7 @@ typedef struct {
#define EFI_MEMORY_DESCRIPTOR_VERSION 1
#define EFI_PAGE_SHIFT 12
+#define EFI_PAGE_SIZE (1UL << EFI_PAGE_SHIFT)
typedef struct {
u32 type;
@@ -157,11 +160,13 @@ typedef struct {
efi_table_hdr_t hdr;
void *raise_tpl;
void *restore_tpl;
- void *allocate_pages;
- void *free_pages;
- void *get_memory_map;
- void *allocate_pool;
- void *free_pool;
+ efi_status_t (*allocate_pages)(int, int, unsigned long,
+ efi_physical_addr_t *);
+ efi_status_t (*free_pages)(efi_physical_addr_t, unsigned long);
+ efi_status_t (*get_memory_map)(unsigned long *, void *, unsigned long *,
+ unsigned long *, u32 *);
+ efi_status_t (*allocate_pool)(int, unsigned long, void **);
+ efi_status_t (*free_pool)(void *);
void *create_event;
void *set_timer;
void *wait_for_event;
@@ -171,7 +176,7 @@ typedef struct {
void *install_protocol_interface;
void *reinstall_protocol_interface;
void *uninstall_protocol_interface;
- void *handle_protocol;
+ efi_status_t (*handle_protocol)(efi_handle_t, efi_guid_t *, void **);
void *__reserved;
void *register_protocol_notify;
void *locate_handle;
@@ -181,7 +186,7 @@ typedef struct {
void *start_image;
void *exit;
void *unload_image;
- void *exit_boot_services;
+ efi_status_t (*exit_boot_services)(efi_handle_t, unsigned long);
void *get_next_monotonic_count;
void *stall;
void *set_watchdog_timer;
@@ -488,10 +493,6 @@ typedef struct {
unsigned long unload;
} efi_loaded_image_t;
-typedef struct {
- u64 revision;
- void *open_volume;
-} efi_file_io_interface_t;
typedef struct {
u64 size;
@@ -504,20 +505,30 @@ typedef struct {
efi_char16_t filename[1];
} efi_file_info_t;
-typedef struct {
+typedef struct _efi_file_handle {
u64 revision;
- void *open;
- void *close;
+ efi_status_t (*open)(struct _efi_file_handle *,
+struct _efi_file_handle **,
+efi_char16_t *, u64, u64);
+ efi_status_t (*close)(struct _efi_file_handle *);
void *delete;
- void *read;
+ efi_status_t (*read)(struct _efi_file_handle *, unsigned long *,
+void *);
void *write;
void *get_position;
void *set_position;
- void *get_info;
+ efi_status_t (*get_info)(struct _efi_file_handle *, efi_guid_t *,
+ unsigned long *, void *);
void *set_info;
void *flush;
} efi_file_handle_t;
+typedef struct _efi_file_io_interface {
+ u64 revision;
+ int (*open_volume)(struct _efi_file_io_interface *,
+ efi_file_handle_t **);
+} efi_file_io_interface_t;
+
#define EFI_FILE_MODE_READ 0x0001
#define EFI_FILE_MODE_WRITE0x0002
#define EFI_FILE_MODE_CREATE 0x8000
@@ -784,6 +795,13 @@ struct efivar_entry {
struct kobject kobj;
};
+
+struct efi_simple_text_output_protocol {
+ void *reset;
+ efi_status_t (*output_string)(void *,
[PATCH V4 00/17] ARM EFI stub common code
This patch is the common/x86 portion of the ARM EFI stub patchset broken out. These changes support the addition of EFI stub support for the ARM and ARM64 architectures. The common code that is now shared in efi-stub-helper.c is based on code in the x86 stub that has been generalized to support other architectures. (Previously these changes were submitted as part of the "EFI stub for ARM" patch series that included the common/x86 changes as well as the ARM changes.) Changes since V3: * Made relocate_kernel() a shared function. * Made command line unicode to ASCII conversion ASCII a shared function * Updated efi_get_memory_map() to return descriptor version, and updated x86 stub to use it to retrieve final memory map. * removed min_address argument of efi_low_alloc(), as it is no longer used. * Squashed very tiny patch moving EFI_READ_CHUNK_SIZE into related patch. Changes since v2: * EFI bugfix "correct call to free_pages" that patch series depends on now in mainline * remove unnecessary zimage_size variable from relocate_kernel() * correct return types on EFI functions - should be efi_status_t, not int. Changes since V1: * Broke up changes to x86 and common code into more patches. 10 more patches in this series. Roy Franz (17): EFI stub documentation updates Add proper definitions for some EFI function pointers. Move common EFI stub code from x86 arch code to common location Add system table pointer argument to shared functions. Rename memory allocation/free functions Enforce minimum alignment of 1 page on allocations. Move relocate_kernel() to shared file. Generalize relocate_kernel() for use by other architectures. Move unicode to ASCII conversion to shared function. Rename __get_map() to efi_get_memory_map() generalize efi_get_memory_map() use efi_get_memory_map() to get final map for x86 Allow efi_free() to be called with size of 0, and do nothing in that case. Generalize handle_ramdisks() and rename to handle_cmdline_files(). Renames in handle_cmdline_files() to complete generalization. Fix types in EFI calls to match EFI function definitions. resolve warnings found on ARM compile Documentation/efi-stub.txt | 65 Documentation/x86/efi-stub.txt | 65 arch/x86/Kconfig |2 +- arch/x86/boot/compressed/eboot.c | 582 ++--- arch/x86/boot/compressed/eboot.h |9 - drivers/firmware/efi/efi-stub-helper.c | 627 include/linux/efi.h| 50 ++- 7 files changed, 767 insertions(+), 633 deletions(-) create mode 100644 Documentation/efi-stub.txt delete mode 100644 Documentation/x86/efi-stub.txt create mode 100644 drivers/firmware/efi/efi-stub-helper.c -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ethernet/arc/arc_emac: Fix huge delays in large file copies
On 09/17/2013 01:10 AM, greg Kroah-Hartman wrote: > On Mon, Sep 16, 2013 at 11:13:48AM +0530, Vineet Gupta wrote: >> On 09/10/2013 11:57 AM, Vineet Gupta wrote: >>> On 09/05/2013 11:55 PM, David Miller wrote: From: Vineet Gupta Date: Wed, 4 Sep 2013 17:17:15 +0530 > copying large files to a NFS mounted host was taking absurdly large > time. > > Turns out that TX BD reclaim had a sublte bug. > > Loop starts off from @txbd_dirty cursor and stops when it hits a BD > still in use by controller. However when it stops it needs to keep the > cursor at that very BD to resume scanning in next iteration. However it > was erroneously incrementing the cursor, causing the next scan(s) to > fail too, unless the BD chain was completely drained out. > > [ARCLinux]$ ls -l -sh /disk/log.txt > 17976 -rw-r--r--1 root root 17.5M Sep /disk/log.txt > > == Before = > [ARCLinux]$ time cp /disk/log.txt /mnt/. > real31m 7.95s > user0m 0.00s > sys 0m 0.10s > > == After = > [ARCLinux]$ time cp /disk/log.txt /mnt/. > real0m 24.33s > user0m 0.00s > sys 0m 0.19s > > Signed-off-by: Vineet Gupta Applied. >>> Hi Greg, >>> >>> This needs a stable backport (3.11). >>> Mainline commit 27082ee1b92f4d41e78b85 >>> >>> Thx, >>> -Vineet >> Hi Greg, >> >> I didn't spot this one in your stable-queue for 3.11. >> Please apply. > Network patches for the stable tree needs to go through the networking > maintainer. Please let them know about this and they will forward it on > to me if needed. > > thanks, > > greg k-h Hi David, Can you please do the needful for stable 3.11 backport of this patch. Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v6 1/5] ARM: add basic support for Trusted Foundations
On Tue, Sep 17, 2013 at 1:50 AM, Stephen Warren wrote:
> On 09/15/2013 03:40 AM, Alexandre Courbot wrote:
>> Trusted Foundations is a TrustZone-based secure monitor for ARM that
>> can be invoked using the same SMC-based API on all supported
>> platforms. This patch adds initial basic support for Trusted
>> Foundations using the ARM firmware API. Current features are limited
>> to the ability to boot secondary processors.
>>
>> Note: The API followed by Trusted Foundations does *not* follow the SMC
>> calling conventions. It has nothing to do with PSCI neither and is only
>> relevant to devices that use Trusted Foundations (like most Tegra-based
>> retail devices).
>
>> diff --git a/arch/arm/firmware/trusted_foundations.c
>> b/arch/arm/firmware/trusted_foundations.c
>
>> +#if IS_ENABLED(CONFIG_OF)
>> +void of_register_trusted_foundations(void)
>> +{
>> + struct device_node *node;
>> + struct trusted_foundations_platform_data pdata;
>> + int err;
>> +
>> + node = of_find_compatible_node(NULL, NULL, "tl,trusted-foundations");
>> + if (!node)
>> + return;
> ...
>
>> diff --git a/arch/arm/include/asm/trusted_foundations.h
>> b/arch/arm/include/asm/trusted_foundations.h
>
>> +#if IS_ENABLED(CONFIG_TRUSTED_FOUNDATIONS)
>> +void register_trusted_foundations(struct trusted_foundations_platform_data
>> *pd);
>> +#if IS_ENABLED(CONFIG_OF)
>> +void of_register_trusted_foundations(void);
>> +#endif
>
> I still don't think that's correct.
>
> If TF support is enabled, yet DT support is not enabled, then there is
> no prototype, implementation, or dummy implementation for
> of_register_trusted_foundations(). I think there should be a dummy
> implementation in this case, shouldn't there?
>
>> +
>> +#else /* CONFIG_TRUSTED_FOUNDATIONS */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +static inline void register_trusted_foundations(
>> +struct trusted_foundations_platform_data
>> *pd)
>> +{
>> + panic("No support for Trusted Foundations, stopping...\n");
>> +}
>> +
>> +#if IS_ENABLED(CONFIG_OF)
>> +static inline void of_register_trusted_foundations(void)
>> +{
>> + /* If we find the target should enable TF but does not support it,
>> + * fail as the system won't be able to do much anyway */
>> + if (of_find_compatible_node(NULL, NULL, "tl,trusted-foundations"))
>> + register_trusted_foundations(NULL);
>> +}
>> +#else
>> +static inline void of_register_trusted_foundations(void)
>> +{
>> +}
>> +#endif /* CONFIG_OF */
>
> That's more complex than it needs to be; there is a dummy
> of_find_compatible_node() in the !OF case, so you don't need to ifdef
> the implementation of of_register_trusted_foundations(); you just need
> the first implementation here.
>
>> +#endif /* CONFIG_TRUSTED_FOUNDATIONS */
>
> In summary, I think you need:
>
> If TF is enabled, always implement of_register_trusted_foundations() in
> the C file, and rely on of_find_compatible_node() to return NULL if
> !CONFIG_OF.
>
> If TF is not enabled, implement the inline version in the header file,
> and again rely on of_find_compatible_node() to return NULL if !CONFIG_OF.
Indeed, all your points are correct, and I've clearly been negligent
here. Sorry about that.
Will have to submit a v7, but hopefully we can get the acks that we
need (Russel?) on this version.
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] On x86_32 system, handle block-device which size is larger than 16TB.
Hi all,
This patch has a long long time.How about this patch?
Thanks!
Jianpeng Ma
>Hi all,
>Some time ago, I mentioned there are some problems on x86-32 system about
> handling md-block-device which size is larger than 16TB.
>And i send a patch.But there are no concern with it.
>The website of is: http://www.spinics.net/lists/linux-fsdevel/msg55672.html.
>
>Except the wrapping problem, recently i found another problem.It will cause
>infinite loop.At lease i watched one hour, the programs don't end.
>
>On x86-32 system, the version of kernel is 3.9-rc8. Disk is raid0 which size
>is about 17TB.
>The test program is:
> int main()
>{
>long long max_size = (4096LL << 32);
>int fd = open("/dev/md0", O_RDWR);
>off64_t off;
>int ret;
>char *buff = memalign(512, 4096);
>
>if (buff == NULL) {
>printf("memalign error %s\n", strerror(errno));
>exit(-1);
>}
>if (fd < 0) {
>printf("open error %s\n", strerror(errno));
>return -errno;
>}
>
>if ((off = lseek64(fd, max_size - 2000, SEEK_SET)) < 0)
>printf("lseek64 error %s\n", strerror(errno));
>else
>printf("off 0x%llx\n", off);
>if ((ret = write(fd, buff, 4096)) < 0)
>printf("write error %s\n", strerror(errno));
>else
>printf("write return %d\n", ret);
>close(fd);
>return 0;
>}
>
>If run this problem, it will not be end up.Because the close(fd) operation.
>The reason is:
>close(fd)>blkdev_close-->sync_blockdev--->filemap_write_and_wait--->__filemap_fdatawrite_range--->do_writepages-->write_cache_pages.
>In function write_cache_pages:
> > nr_pages = pagevec_lookup_tag(, mapping, , tag,
> > min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1);
> > if (nr_pages == 0)
> > break;
>Because there is only on dirty page which index is 0x.
>>for (i = 0; i < nr_pages; i++) {
>..
>>ret = (*writepage)(page, wbc, data);
>So the function blkdev_writepage will be called.
>blkdev_writepage>block_write_full_page>block_write_full_page_endio.
>In function block_write_full_page_endio:
>> struct inode * const inode = page->mapping->host;
>>loff_t i_size = i_size_read(inode);
>>const pgoff_t end_index = i_size >> PAGE_CACHE_SHIFT;
>>unsigned offset;
>
>>/* Is the page fully inside i_size? */
>>if (page->index < end_index)
>return __block_write_full_page(inode, page, get_block, wbc,
> handler);
>Because page->index is 0xfff,but the end_index is very litter because the
>wrapping.
>On x86-32os, pgoff_t is unsigned long .So 17TB >> PAGE_CACHE_SHIFT will be
>overflow.
>>/* Is the page fully outside i_size? (truncate in progress) */
>>offset = i_size & (PAGE_CACHE_SIZE-1);
>>if (page->index >= end_index+1 || !offset) {
>Because end_index is less than page->index.So it will be return there.So the
>PAGECACHE_TAG_TOWRITE will not be clear.
>So it will continue to do.
>>/*
>> * The page may have dirty, unmapped buffers. For example,
>> * they may have been added in ext3_writepage(). Make them
>> * freeable here, so the page does not leak.
>> */
>>do_invalidatepage(page, 0);
>>unlock_page(page);
>>return 0; /* don't care */
>>}
>
>The infinite loop will cause hung-task because the mutex_lock don't release.
>
>My previous patch is try to resolve this problem by add some judgement on
>lseek/read/write operation on block-device.
>I think there are some place to deal with.
>So i think we can using LFS rule on this.
>The following is my new patch which adding LFS rule on block device.Because at
>present MAX_LFS_FILESIZE is equal 8GB -1.
>But at present the pgoff_t is the type of unsigned long.So i update the
>definition of MAX_LFS_FILESIZE.
>
>diff --git a/fs/block_dev.c b/fs/block_dev.c
>index aae187a..f5ecd64 100644
>--- a/fs/block_dev.c
>+++ b/fs/block_dev.c
>@@ -960,6 +960,8 @@ void check_disk_size_change(struct gendisk *disk, struct
>block_device *bdev)
>
> disk_size = (loff_t)get_capacity(disk) << 9;
> bdev_size = i_size_read(bdev->bd_inode);
>+if (bdev_size > bdev->bd_inode->i_sb->s_maxbytes)
>+bdev_size = bdev->bd_inode->i_sb->s_maxbytes;
> if (disk_size != bdev_size) {
> char name[BDEVNAME_SIZE];
>
>@@ -1034,6 +1036,8 @@ void bd_set_size(struct block_device *bdev, loff_t size)
> {
> unsigned bsize = bdev_logical_block_size(bdev);
>
>+if (size > bdev->bd_inode->i_sb->s_maxbytes)
>+size = bdev->bd_inode->i_sb->s_maxbytes;
>
[PATCH V2 2/2] block_dev: Add size check before doing async write on block device.
For async-write on block device,when disk removed,the vfs don't know.
It will continue do async-write.Add this check it will stop async-write
when disk removed.
Signed-off-by: Jianpeng Ma
---
fs/block_dev.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 1173a4e..e308b52 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1514,6 +1514,10 @@ ssize_t blkdev_aio_write(struct kiocb *iocb, const
struct iovec *iov,
struct file *file = iocb->ki_filp;
struct blk_plug plug;
ssize_t ret;
+ loff_t size = i_size_read(file->f_mapping->host);
+
+ if (pos >= size)
+ return 0;
BUG_ON(iocb->ki_pos != pos);
--
1.8.4-rc0N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±êçzX§¶¡Ü¨}©²Æ
zÚ:+v¨¾«êçzZ+Ê+zf£¢·h§~Ûiÿûàz¹ ®w¥¢¸?¨èÚ&¢)ߢfù^jÇ«y§m
á@A«a¶Úÿ
0¶ìh®åi
[PATCH][RESEND] c6x: remove unused parameter in Kconfig
This patch proposes to remove the TMS320C6X_CACHES_ON kernel configuration parameter defined in arch/c6x/Kconfig, but used nowhere in the makefiles and source code. Signed-off-by: Michael Opdenacker Acked by: Mark Salter --- arch/c6x/Kconfig | 4 1 file changed, 4 deletions(-) diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig index 957dd00..b4f7725 100644 --- a/arch/c6x/Kconfig +++ b/arch/c6x/Kconfig @@ -105,10 +105,6 @@ menu "Processor type and features" source "arch/c6x/platforms/Kconfig" -config TMS320C6X_CACHES_ON - bool "L2 cache support" - default y - config KERNEL_RAM_BASE_ADDRESS hex "Virtual address of memory base" default 0xe000 if SOC_TMS320C6455 -- 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/2] block: Set inode of block_device size to zero when delete gendisk.
When remove gendisk, set the size of inode of block_device to zero.
This is mainly let the vfs know disk removed.
Signed-off-by: Jianpeng Ma
---
block/genhd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/block/genhd.c b/block/genhd.c
index dadf42b..9a4c245 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1369,6 +1369,12 @@ int invalidate_partition(struct gendisk *disk, int
partno)
if (bdev) {
fsync_bdev(bdev);
res = __invalidate_device(bdev, true);
+ /*
+* When used buffer-mode on raw blockdevice,the disk removed.
+* But the vfs don't know.So tell the vfs size of disk
+* became zero, the buffer write can return
+*/
+ i_size_write(bdev->bd_inode, 0);
bdput(bdev);
}
return res;
--
1.8.4-rc0
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±êçzX§¶¡Ü¨}©²Æ
zÚ:+v¨¾«êçzZ+Ê+zf£¢·h§~Ûiÿûàz¹ ®w¥¢¸?¨èÚ&¢)ߢfù^jÇ«y§m
á@A«a¶Úÿ
0¶ìh®åi
[PATCH V2 0/2] Auto stop async-write on block device when device removed.
For async-write on block device,if device removed,but the vfs don't know it.
It will continue to do.
Patch1 set size of inode of block device to zero when removed disk.By this,vfs
know
disk changed.
Path2 add size-check on blk_aio_write.If pos of write larger than size of
inode,it will
return zero.So the user can check disk state.
V2:
patch1:
-consider the case which disk has partitions
-move i_size_write into func invalidate_partition
patch2: No change
Jianpeng Ma (2):
block: Set inode of block_device size to zero when delete gendisk.
block_dev: Add size check before doing async write on block device.
block/genhd.c | 6 ++
fs/block_dev.c | 4
2 files changed, 10 insertions(+)
--
1.8.4-rc0N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±êçzX§¶¡Ü¨}©²Æ
zÚ:+v¨¾«êçzZ+Ê+zf£¢·h§~Ûiÿûàz¹ ®w¥¢¸?¨èÚ&¢)ߢfù^jÇ«y§m
á@A«a¶Úÿ
0¶ìh®åi
[PATCH V2] Input: atmel_mxt_ts - update to devm_* API
Update the code to use devm_* API so that driver core will manage
resources.
Signed-off-by: Manish Badarkhe
---
Changes since V1:
As per Dmitry's comment, avoid "devm_" operation on irq as it may cause
kernel crash while device is getting unbound and CCing Nick dryer.
:100644 100644 59aa240... d04dbed... M drivers/input/touchscreen/atmel_mxt_ts.c
drivers/input/touchscreen/atmel_mxt_ts.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 59aa240..d04dbed 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1139,12 +1139,12 @@ static int mxt_probe(struct i2c_client *client,
if (!pdata)
return -EINVAL;
- data = kzalloc(sizeof(struct mxt_data), GFP_KERNEL);
- input_dev = input_allocate_device();
+ data = devm_kzalloc(>dev, sizeof(struct mxt_data), GFP_KERNEL);
+ input_dev = devm_input_allocate_device(>dev);
if (!data || !input_dev) {
dev_err(>dev, "Failed to allocate memory\n");
error = -ENOMEM;
- goto err_free_mem;
+ goto err_out;
}
data->is_tp = pdata && pdata->is_tp;
@@ -1170,7 +1170,7 @@ static int mxt_probe(struct i2c_client *client,
error = mxt_initialize(data);
if (error)
- goto err_free_mem;
+ goto err_out;
__set_bit(EV_ABS, input_dev->evbit);
__set_bit(EV_KEY, input_dev->evbit);
@@ -1253,9 +1253,7 @@ err_free_irq:
free_irq(client->irq, data);
err_free_object:
kfree(data->object_table);
-err_free_mem:
- input_free_device(input_dev);
- kfree(data);
+err_out:
return error;
}
@@ -1267,7 +1265,6 @@ static int mxt_remove(struct i2c_client *client)
free_irq(data->irq, data);
input_unregister_device(data->input_dev);
kfree(data->object_table);
- kfree(data);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev][PATCH RESEND] f2fs: avoid allocating failure in bio_alloc
Hi Gu
> -Original Message-
> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
> Sent: Monday, September 16, 2013 12:40 PM
> To: Chao Yu
> Cc: 'Kim Jaegeuk'; linux-f2fs-de...@lists.sourceforge.net;
> linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; '谭姝'
> Subject: Re: [f2fs-dev][PATCH RESEND] f2fs: avoid allocating failure in
bio_alloc
>
> Hi Chao,
>
> On 09/16/2013 11:26 AM, Chao Yu wrote:
>
> > Hi Gu
> >
> >> -Original Message-
> >> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
> >> Sent: Monday, September 16, 2013 10:09 AM
> >> To: Chao Yu
> >> Cc: Kim Jaegeuk; linux-f2fs-de...@lists.sourceforge.net;
> >> linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; 谭姝
> >> Subject: Re: [f2fs-dev][PATCH RESEND] f2fs: avoid allocating failure
> >> in
> > bio_alloc
> >>
> >> Hi Chao,
> >>
> >> On 09/13/2013 09:27 PM, Chao Yu wrote:
> >>
> >>> This patch add macro MAX_BIO_BLOCKS to limit value of npages in
> >>> f2fs_bio_alloc, it can avoid allocating failure in bio_alloc caused
> >>> by npages is larger than UIO_MAXIOV.
> >>
> >> As I know bio_alloc is based of *fs_bio_set* pool, without the
> >> limitation
> > of
> >> UIO_MAXIOV, am I missing something?
> >
> > Here is the code in bio.c, fs_bio_set is as the actual parameter pass
> > to bs without being inited.
>
> fs_bio_set was initiated early in the bio subsystem init.
>
> > So it may have opportunity to return NULL in this function.
>
> It may be, but may not be the thread you mentioned below.
>
> > ---
> > Bio.c
> > struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct
> > bio_set
> > *bs)
> > {
> > ..
> > if (!bs) {
> > if (nr_iovecs > UIO_MAXIOV)
> > return NULL;
> > ---
> > I did the abnormal test: modify the max_sectors_kb in
> > /sys/block/sdx/queue to 32767 for a disk with f2fs format, and I got a
> > segfualt in f2fs_bio_alloc after the img mounted.
> > Is there anyting I missed?
>
> Hmm, this change will also trigger bvec_alloc failed, did you add some
traces to
> debug this?
I reviewed the code in bio_alloc, and then trace the process of bio_alloc
for verification.
It indicate that bvec_alloc() will fail on the condition that nr_iovecs is
greater than BIO_MAX_PAGES.
The patch should be updated for that.
I am sorry about the mistake in this patch, and thanks for the reviewing and
reminding.
>
> Regards,
> Gu
>
> >
> >>
> >> Thanks,
> >> Gu
> >>
> >>>
> >>> Signed-off-by: Yu Chao
> >>> ---
> >>> fs/f2fs/segment.c |4 +++-
> >>> fs/f2fs/segment.h |3 +++
> >>> 2 files changed, 6 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index
> >>> 09af9c7..bd79bbe 100644
> >>> --- a/fs/f2fs/segment.c
> >>> +++ b/fs/f2fs/segment.c
> >>> @@ -657,6 +657,7 @@ static void submit_write_page(struct
> >>> f2fs_sb_info *sbi, struct page *page,
> >>> block_t blk_addr, enum page_type
> >> type)
> >>> {
> >>> struct block_device *bdev = sbi->sb->s_bdev;
> >>> + int bio_blocks;
> >>>
> >>> verify_block_addr(sbi, blk_addr);
> >>>
> >>> @@ -676,7 +677,8 @@ retry:
> >>> goto retry;
> >>> }
> >>>
> >>> - sbi->bio[type] = f2fs_bio_alloc(bdev,
> > max_hw_blocks(sbi));
> >>> + bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
> >>> + sbi->bio[type] = f2fs_bio_alloc(bdev, bio_blocks);
> >>> sbi->bio[type]->bi_sector =
> SECTOR_FROM_BLOCK(sbi,
> >>> blk_addr);
> >>> sbi->bio[type]->bi_private = priv;
> >>> /*
> >>> diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index
> >>> bdd10ea..6352af1 100644
> >>> --- a/fs/f2fs/segment.h
> >>> +++ b/fs/f2fs/segment.h
> >>> @@ -9,6 +9,7 @@
> >>> * published by the Free Software Foundation.
> >>> */
> >>> #include
> >>> +#include
> >>>
> >>> /* constant macro */
> >>> #define NULL_SEGNO ((unsigned int)(~0))
> >>> @@ -90,6 +91,8 @@
> >>> (blk_addr << ((sbi)->log_blocksize - F2FS_LOG_SECTOR_SIZE))
> >>> #define SECTOR_TO_BLOCK(sbi, sectors)
> >> \
> >>> (sectors >> ((sbi)->log_blocksize - F2FS_LOG_SECTOR_SIZE))
> >>> +#define MAX_BIO_BLOCKS(max_hw_blocks)
> >> \
> >>> + (min((int)max_hw_blocks, UIO_MAXIOV))
> >>>
> >>> /* during checkpoint, bio_private is used to synchronize the last
> >>> bio */ struct bio_private {
> >>> ---
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe
> >>> linux-kernel" in the body of a message to majord...@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>> Please read the FAQ at http://www.tux.org/lkml/
> >>>
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at
linux-next: Tree for Sep 17
Hi all, Changes since 20130916: *crickets* I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 222 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (272b98c Linux 3.12-rc1) Merging fixes/master (fa8218d Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1) Merging arc-current/for-curr (07b9b65 ARC: fix new Section mismatches in build (post __cpuinit cleanup)) Merging arm-current/fixes (171b3f0 ARM: sort arch/arm/Kconfig) Merging m68k-current/for-linus (21e884b m68k/m68knommu: Implement __get_user_unaligned/__put_user_unaligned()) Merging metag-fixes/fixes (3b2f64d Linux 3.11-rc2) Merging powerpc-merge/merge (363edbe powerpc: Default arch idle could cede processor on pseries) Merging sparc/master (4de9ad9 Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile) Merging net/master (73a695f cxgb4: remove workqueue when driver registration fails) Merging ipsec/master (73a695f cxgb4: remove workqueue when driver registration fails) Merging sound-current/for-linus (3d0049e Merge tag 'asoc-v3.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (a923874 Merge tag 'pci-v3.12-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging wireless/master (f4e1a4d rt2800: change initialization sequence to fix system freeze) Merging driver-core.current/driver-core-linus (272b98c Linux 3.12-rc1) Merging tty.current/tty-linus (272b98c Linux 3.12-rc1) Merging usb.current/usb-linus (272b98c Linux 3.12-rc1) Merging staging.current/staging-linus (272b98c Linux 3.12-rc1) Merging char-misc.current/char-misc-linus (272b98c Linux 3.12-rc1) Merging input-current/for-linus (c7dc657 Input: evdev - add EVIOCREVOKE ioctl) Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' and 'recovery'.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (26052f9 crypto: crct10dif - Add fallback for broken initrds) Merging ide/master (64110c1 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct resource to 0 in of_irq_to_resource()) Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32) Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work without pdata) Merging vfio-fixes/for-linus (d24cdbf vfio-pci: Avoid deadlock on remove) Merging drm-intel-fixes/for-linux-next-fixes (6e46645 Linux 3.11) Merging asm-generic/master (fb9de7e xtensa: Use generic asm/mmu.h for nommu) Merging arc/for-next (d8dfad3 Linux 3.11-rc7) Merging arm/for-next (4f57a10 Merge branch 'mw-fixes' into for-next) Merging arm-perf/for-next/perf (ad81f05 Linux 3.11-rc1) Merging davinci/davinci-next (fe0d422 Linux 3.
Re: [PATCH] m68k: remove unused Kconfig parameters
Hi Greg,
On 09/17/2013 01:48 AM, Greg Ungerer wrote:
> Hi Michael,
>
> On 06/09/13 21:59, Michael Opdenacker wrote:
>> This patch proposes to remove the UC5282 and UC5272 kernel configuration
>> parameters defined in arch/m68k/Kconfig.machine,
>> but used nowhere in the makefiles and source code.
>>
>> Signed-off-by: Michael Opdenacker
> This change is a subset of c065edde ("remove 16 unused boards in
> Kconfig.machine") by Pauk Bolle. And that is in 3.12-rc1.
Awesome! Thank you very much for the good news, and for not applying the
same change twice. Pfooh, this would have created anti-kconfig
parameters. Scary. ;)
Cheers,
Michael.
--
Michael Opdenacker, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kernel panic
2.6.32-279.el6.x86_64 #1 SMP Thu Sep 12 12:59:17 CST 2013 x86_64 x86_64 x86_64 GNU/Linux == PID: 2621 TASK: 881fe10d2aa0 CPU: 14 COMMAND: "qemu-kvm" #0 [880028307b00] machine_kexec at 8103281b #1 [880028307b60] crash_kexec at 810ba322 #2 [880028307c30] panic at 814fce74 #3 [880028307cb0] watchdog_overflow_callback at 810daf7d #4 [880028307cd0] __perf_event_overflow at 8110dbbd #5 [880028307d70] perf_event_overflow at 8110e174 #6 [880028307d80] intel_pmu_handle_irq at 8101e976 #7 [880028307e90] perf_event_nmi_handler at 81501519 #8 [880028307ea0] notifier_call_chain at 81503065 #9 [880028307ee0] atomic_notifier_call_chain at 815030ca #10 [880028307ef0] notify_die at 81097d6e #11 [880028307f20] do_nmi at 81500ce3 #12 [880028307f50] nmi at 815005f0 [exception RIP: _spin_lock+33] RIP: 814ffe61 RSP: 8800283033d0 RFLAGS: 0097 RAX: 8dbb RBX: 00016680 RCX: 00c1 RDX: 8db4 RSI: 880028303438 RDI: 880028336680 RBP: 8800283033d0 R8: 00c1 R9: 0005 R10: R11: 0001 R12: 880bf2fd0080 R13: 880028303438 R14: 880028336680 R15: 0001 ORIG_RAX: CS: 0010 SS: 0018 --- --- #13 [8800283033d0] _spin_lock at 814ffe61 #14 [8800283033d8] task_rq_lock at 8105350d #15 [880028303408] try_to_wake_up at 8105bfbc #16 [880028303478] default_wake_function at 8105c372 #17 [880028303488] pollwake at 8118fbd6 #18 [8800283034c8] __wake_up_common at 8104e189 #19 [880028303518] __wake_up at 81053268 #20 [880028303558] tun_net_xmit at a0156495 [tun] #21 [880028303588] dev_hard_start_xmit at 8143ad9c #22 [8800283035e8] sch_direct_xmit at 814588ea #23 [880028303638] __qdisc_run at 814589bb #24 [880028303668] dev_queue_xmit at 8143f4c3 #25 [8800283036b8] br_dev_queue_push_xmit at a03796bc [bridge] #26 [8800283036d8] br_nf_dev_queue_xmit at a037f378 [bridge] #27 [8800283036e8] br_nf_post_routing at a037fe10 [bridge] #28 [880028303738] nf_iterate at 814662b9 #29 [880028303788] nf_hook_slow at 81466474 #30 [880028303808] br_forward_finish at a0379733 [bridge] #31 [880028303838] br_nf_forward_finish at a037f9b8 [bridge] #32 [880028303878] br_nf_forward_ip at a0380ea8 [bridge] #33 [8800283038d8] nf_iterate at 814662b9 #34 [880028303928] nf_hook_slow at 81466474 #35 [8800283039a8] __br_forward at a03797c2 [bridge] #36 [8800283039d8] deliver_clone at a037939e [bridge] #37 [880028303a08] br_flood at a03795b9 [bridge] #38 [880028303a48] br_flood_forward at a0379625 [bridge] #39 [880028303a58] br_handle_frame_finish at a037a7ae [bridge] #40 [880028303aa8] br_nf_pre_routing_finish at a0380318 [bridge] #41 [880028303b48] br_nf_pre_routing at a038088f [bridge] #42 [880028303b98] nf_iterate at 814662b9 #43 [880028303be8] nf_hook_slow at 81466474 #44 [880028303c68] br_handle_frame at a037a95c [bridge] #45 [880028303ca8] __netif_receive_skb at 8143a509 #46 [880028303d08] netif_receive_skb at 8143c708 #47 [880028303d48] napi_skb_finish at 8143c810 #48 [880028303d68] napi_gro_receive at 8143ed49 #49 [880028303d88] ixgbe_receive_skb at a00df9df [ixgbe] #50 [880028303d98] ixgbe_poll at a00e0dda [ixgbe] #51 [880028303e68] net_rx_action at 8143ee63 #52 [880028303ec8] __do_softirq at 81073b81 #53 [880028303f38] call_softirq at 8100c24c #54 [880028303f50] do_softirq at 8100de85 #55 [880028303f70] irq_exit at 81073965 #56 [880028303f80] do_IRQ at 81505835 --- --- #57 [881e47ce3a48] ret_from_intr at 8100ba53 [exception RIP: x86_emulate_insn+9030] RIP: a01c69f6 RSP: 881e47ce3af8 RFLAGS: 0202 RAX: RBX: 881e47ce3b88 RCX: 0010 RDX: 881c26cbc5c0 RSI: 0003 RDI: 881c26cbc5c0 RBP: 8100ba4e R8: 0001 R9: a01b3bf0 R10: R11: R12: a01ae2c6 R13: 881e47ce3a98 R14: R15: 881c26cbc5c0 ORIG_RAX: ff86 CS: 0010 SS: 0018 #58 [881e47ce3b90] x86_emulate_instruction at a01b47ab [kvm] #59 [881e47ce3bf0] kvm_mmu_page_fault at a01be6d2 [kvm] #60 [881e47ce3c30] handle_ept_violation at a020548a [kvm_intel] #61
Re: increased vmap_area_lock contentions on "n_tty: Move buffers into n_tty_data"
On Mon, Sep 16, 2013 at 10:42:11PM -0400, Peter Hurley wrote: > On 09/12/2013 11:38 PM, Fengguang Wu wrote: > >On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote: > >>On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote: > >>>Hi Peter, > >>> > >>>FYI, we noticed much increased vmap_area_lock contentions since this > >>>commit: > >> > >>What does that mean? What is happening, are we allocating/removing more > >>memory now? > > > >// leave this question to Peter and Tejun. :) > > > >>What type of load were you running that showed this problem? > > > >The increased contentions and lock hold/wait time showed up in a > >number of test cases. > > How is the raw data acquired? > > For example, is the test apparatus reading from /proc/vmallocinfo > (which claims the vmap_area_lock) during the test execution? We didn't read /proc/vmallocinfo and read /proc/lock_stat once when the test ends. > I'm wondering if a Heisenberg effect is happening here. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: increased vmap_area_lock contentions on "n_tty: Move buffers into n_tty_data"
On 09/12/2013 11:38 PM, Fengguang Wu wrote: On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote: On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote: Hi Peter, FYI, we noticed much increased vmap_area_lock contentions since this commit: What does that mean? What is happening, are we allocating/removing more memory now? // leave this question to Peter and Tejun. :) What type of load were you running that showed this problem? The increased contentions and lock hold/wait time showed up in a number of test cases. How is the raw data acquired? For example, is the test apparatus reading from /proc/vmallocinfo (which claims the vmap_area_lock) during the test execution? I'm wondering if a Heisenberg effect is happening here. Regards, Peter Hurley The second email has the details, and this section of data is most illustrating. 8cb06c983822103da1cf 20bafb3d23d108bc0a89 3470.31 +1631.0% 60070.49 fat/micro/dd-write/1HDD-cfq-ext4-10dd 3339.57 +1676.9% 59340.71 fat/micro/dd-write/1HDD-cfq-ext4-1dd 2848.79 +1489.1% 45269.54 lkp-a04/micro/netperf/120s-200%-TCP_CRR 3563.01 +1515.2% 57548.50 lkp-a04/micro/netperf/120s-200%-TCP_MAERTS 2678.64 +1346.0% 38733.80 lkp-a04/micro/netperf/120s-200%-TCP_RR 2839.84 +1450.2% 44022.08 lkp-a04/micro/netperf/120s-200%-TCP_SENDFILE 3417.37 +1571.4% 57116.34 lkp-a04/micro/netperf/120s-200%-TCP_STREAM 2558.59 +1450.8% 39677.58 lkp-a04/micro/netperf/120s-200%-UDP_RR 3737.24 +1558.0% 61963.62 lkp-a04/micro/netperf/120s-200%-UDP_STREAM 20219.50 +1488.7%321218.02 lkp-a06/crypto/tcrypt/2s-200-204 21017.17 +1457.1%327257.41 lkp-a06/crypto/tcrypt/2s-205-210 22109.84 +1240.3%296346.33 lkp-a06/crypto/tcrypt/2s-401-417 17909.60 +1467.3%280693.71 lkp-a06/micro/dbench/100% 489739.50 +978.5% 5281916.05 lkp-ne04/micro/aim7/shell_rtns_1 1601675.63 +906.7% 16123642.52 lkp-snb01/micro/aim7/exec_test 12105.00 +2453.6%309110.42 nhm-white/micro/aim7/dbase 822461.02 +1585.0% 13858430.62 nhm-white/micro/aim7/exec_test 9858.11 +2715.9%277595.41 nhm-white/micro/aim7/fork_test 3452.91 +1685.5% 61650.74 nhm-white/micro/aim7/fserver 300.14 +2621.5% 8168.53 nhm-white/micro/aim7/misc_rtns_1 345479.21 +1624.5% 5957828.25 nhm-white/micro/aim7/shell_rtns_1 2694.48 +1974.4% 55894.19 nhm-white/sysbench/oltp/100%-600-100 4415.67 +1202.2% 57501.52 nhm8/micro/dbench/100% 2284.65 +1505.2% 36672.75 snb-drag/crypto/tcrypt/2s-200-204 2446.02 +1537.1% 40042.87 snb-drag/crypto/tcrypt/2s-205-210 2484.11 +1599.6% 42219.71 snb-drag/crypto/tcrypt/2s-500-504 2118.55 +1155.8% 26604.99 vpx/crypto/tcrypt/2s-200-204 2713.48 +1198.5% 35234.77 vpx/crypto/tcrypt/2s-205-210 2711.31 +973.8% 29114.07 vpx/crypto/tcrypt/2s-301-319 2369.23 +940.3% 24648.12 vpx/crypto/tcrypt/2s-401-417 2620.64 +1428.7% 40060.71 vpx/crypto/tcrypt/2s-500-504 1713.98 +1624.3% 29553.72 vpx/crypto/tcrypt/2s-505-509 3423353.12 +1184.9% 43985148.08 TOTAL lock_stat.vmap_area_lock.holdtime-total The format of report is parent commitcommit number %change number testbox/testcase/test-params ... ... ... total number %changetotal number TOTAL perf-metric-name being compared Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vfs: avoid sb->s_umount lock while changing bind-mount flags
On Mon, Sep 16, 2013 at 10:42:30AM -0700, Aditya Kali wrote: > During remount of a bind mount (mount -o remount,bind,ro,... /mnt/mntpt), > we currently take down_write(>s_umount). This causes the remount > operation to get blocked behind writes occuring on device (possibly > mounted somewhere else). We have observed that simply trying to change > the bind-mount from read-write to read-only can take several seconds > becuase writeback is in progress. Looking at the code it seems to me that > we need s_umount lock only around the do_remount_sb() call. > vfsmount_lock seems enough to protect the flag change on the mount. > So this patch fixes the locking so that changing of flags can happen > outside the down_write(>s_umount). What's to prevent mount -o remount,ro /mnt and mount -o remount,rw,nodev /mnt racing and ending up with that sucker rw and without nodev? As for lock_mount... nope - we carefully do *not* hold namespace_sem over any kind of fs operations. Anything getting stuck while holding it will have really nasty consequences. So ->s_umount here is inelegant, but alternatives sucks worse... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: onenand: omap: remove two unused functions
On Wed, Aug 07, 2013 at 08:16:49PM +0200, Paul Bolle wrote: > Nothing calls omap2_onenand_rephase(). And __adjust_timing() is only > called by omap2_onenand_rephase(). Remove these two unused functions. > > Signed-off-by: Paul Bolle > --- > Completely untested. Compile-tested successfully here. And it gets rid of a few sparse warnings: drivers/mtd/onenand/omap2.c:592:5: warning: no previous prototype for 'omap2_onenand_rephase' [-Wmissing-prototypes] drivers/mtd/onenand/omap2.c:592:5: warning: symbol 'omap2_onenand_rephase' was not declared. Should it be static? [sparse] Applied to l2-mtd.git. Thanks! Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scsi: delete decade+ obsolete aic7xxx_old driver
Yes, this driver is well past ready to be removed. Acked-by: Doug Ledford Sent from my ASUS Pad Paul Gortmaker wrote: >After getting warnings in an allyesconfig build[1] from this >driver, I decided to remind myself just how old it was, and >whether it warranted fixing. In the Kconfig help text, I found: > > "This driver will eventually be phased out entirely" > >Going back to the history archive, I see the line was added[2] >in Feb 2002, when we moved from v2.4.2.1 ---> v2.4.2.2 > >So, with over a decade of notification, and multiple major releases >since then, I think we can justify removing this. Currently we have >people wasting time building it during routine testing, and then >wasting more time re-researching the known reported warnings, only to >find that nobody really is willing to integrate the fixes[3] for it. > >A quick search didn't seem to indicate any active user base for it. >If someone happens to have a quirky _old_ card that the eleven year >old "new" driver doesn't work with, then it is entirely reasonable >that they stick with a kernel version that predates this removal. > >[1] drivers/scsi/aic7xxx_old.c: In function ‘aic7xxx_register’: >drivers/scsi/aic7xxx_old.c:7901:5: warning: case value ‘257’ not in > enumerated type ‘ahc_chip’ [-Wswitch] >drivers/scsi/aic7xxx_old.c:7898:5: warning: case value ‘513’ not in > enumerated type ‘ahc_chip’ [-Wswitch] >drivers/scsi/aic7xxx_old.c: In function ‘aic7xxx_load_seeprom’: >drivers/scsi/aic7xxx_old.c:8517:5: warning: case value ‘257’ not in > enumerated type ‘ahc_chip’ [-Wswitch] >drivers/scsi/aic7xxx_old.c:8510:5: warning: case value ‘513’ not in > enumerated type ‘ahc_chip’ [-Wswitch] > >[2] http://git.kernel.org/cgit/linux/kernel/git/tglx/history.git commit >44e8778c > >[3] https://lkml.org/lkml/2012/10/29/215 > >Cc: Hannes Reinecke >Cc: Doug Ledford >Cc: "James E.J. Bottomley" >Signed-off-by: Paul Gortmaker >--- > >[This is an "--irreversible-delete" pseudo-patch which doesn't show all >the file content that was deleted wholesale. The full commit is at: >git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git aic7xxx-delete ] > > Documentation/scsi/00-INDEX | 2 - > Documentation/scsi/aic7xxx_old.txt | 511 -- > MAINTAINERS | 1 - > drivers/scsi/Kconfig|41 - > drivers/scsi/Makefile | 1 - > drivers/scsi/aic7xxx_old.c | 11149 -- > drivers/scsi/aic7xxx_old/aic7xxx.h |28 - > drivers/scsi/aic7xxx_old/aic7xxx.reg| 1401 > drivers/scsi/aic7xxx_old/aic7xxx.seq| 1539 - > drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 270 - > drivers/scsi/aic7xxx_old/aic7xxx_reg.h | 629 -- > drivers/scsi/aic7xxx_old/aic7xxx_seq.c | 817 --- > drivers/scsi/aic7xxx_old/scsi_message.h |49 - > drivers/scsi/aic7xxx_old/sequencer.h| 135 - > 14 files changed, 16573 deletions(-) > delete mode 100644 Documentation/scsi/aic7xxx_old.txt > delete mode 100644 drivers/scsi/aic7xxx_old.c > delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx.h > delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx.reg > delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx.seq > delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx_proc.c > delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx_reg.h > delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx_seq.c > delete mode 100644 drivers/scsi/aic7xxx_old/scsi_message.h > delete mode 100644 drivers/scsi/aic7xxx_old/sequencer.h > >diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX >index 9b0787f..2044be5 100644 >--- a/Documentation/scsi/00-INDEX >+++ b/Documentation/scsi/00-INDEX >@@ -42,8 +42,6 @@ aic79xx.txt > - Adaptec Ultra320 SCSI host adapters > aic7xxx.txt > - info on driver for Adaptec controllers >-aic7xxx_old.txt >- - info on driver for Adaptec controllers, old generation > arcmsr_spec.txt > - ARECA FIRMWARE SPEC (for IOP331 adapter) > dc395x.txt >diff --git a/Documentation/scsi/aic7xxx_old.txt >b/Documentation/scsi/aic7xxx_old.txt >deleted file mode 100644 >index ecfc474..000 >diff --git a/MAINTAINERS b/MAINTAINERS >index e61c2e8..c79be42 100644 >--- a/MAINTAINERS >+++ b/MAINTAINERS >@@ -470,7 +470,6 @@ M: Hannes Reinecke > L:linux-s...@vger.kernel.org > S:Maintained > F:drivers/scsi/aic7xxx/ >-F:drivers/scsi/aic7xxx_old/ > > AIMSLAB FM RADIO RECEIVER DRIVER > M:Hans Verkuil >diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig >index fe25677..1f02003 100644 >--- a/drivers/scsi/Kconfig >+++ b/drivers/scsi/Kconfig >@@ -499,47 +499,6 @@ config SCSI_AACRAID > > > source "drivers/scsi/aic7xxx/Kconfig.aic7xxx" >- >-config SCSI_AIC7XXX_OLD >- tristate "Adaptec AIC7xxx support (old driver)" >- depends on (ISA || EISA || PCI ) && SCSI >- help >-WARNING This driver is an older aic7xxx driver and is no longer >-under active
Re: [PATCH] mtd: nand: fix memory leak in ONFI extended parameter page
于 2013年09月17日 09:31, Brian Norris 写道:
> This fixes a memory leak in the ONFI support code for detecting the
> required ECC levels from this commit:
>
> commit 6dcbe0cdd83fb5f77be4f44c9e06c535281c375a
> Author: Huang Shijie
> Date: Wed May 22 10:28:27 2013 +0800
>
> mtd: get the ECC info from the Extended Parameter Page
>
> In the success case, we never freed the 'ep' buffer.
>
> Also, this fixes an oversight in the same commit where we (harmlessly)
> freed the NULL pointer.
>
> Signed-off-by: Brian Norris
> Cc: Huang Shijie
> ---
> David, if there are no objections, can you send this to Linus for 3.12?
>
> If this doesn't make it into 3.12, then it will be -stable material.
>
> drivers/mtd/nand/nand_base.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index d4578a1..00022b4 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -2869,10 +2869,8 @@ static int nand_flash_detect_ext_param_page(struct
> mtd_info *mtd,
>
> len = le16_to_cpu(p->ext_param_page_length) * 16;
> ep = kmalloc(len, GFP_KERNEL);
> - if (!ep) {
> - ret = -ENOMEM;
> - goto ext_out;
> - }
> + if (!ep)
> + return -ENOMEM;
>
> /* Send our own NAND_CMD_PARAM. */
> chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
> @@ -2920,7 +2918,7 @@ static int nand_flash_detect_ext_param_page(struct
> mtd_info *mtd,
> }
>
> pr_info("ONFI extended param page detected.\n");
> - return 0;
> + ret = 0;
>
> ext_out:
> kfree(ep);
good catch!
Acked-by: Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 5/5] squashfs: support readpages
And I found regression from iozone random read test.
This patch fixes it.
>From 546a541c6e29b321e4908ebe0f8aac506eb5b3af Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Tue, 17 Sep 2013 10:20:56 +0900
Subject: [PATCH] squahsfs: read synchronously when readahead window is small
Normally, MM does readahead with small window size so in that case,
our plugging logic can hurt performance.
If readahead window is smaller than compress block size, let's do
old synchronous read.
Signed-off-by: Minchan Kim
---
fs/squashfs/file.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c
index b98965c..2537eeb 100644
--- a/fs/squashfs/file.c
+++ b/fs/squashfs/file.c
@@ -1007,6 +1007,24 @@ static int squashfs_readpages(struct file *file, struct
address_space *mapping,
start_bindex = hpage->index >> (msblk->block_log - PAGE_CACHE_SHIFT);
last_bindex = tpage->index >> (msblk->block_log - PAGE_CACHE_SHIFT);
+ /*
+* Normally, MM readahread window is smaller than our compressed
+* block size. In that case, plugging could hurt performance so
+* let's do synchronous read in that case.
+*/
+ if (start_bindex == last_bindex) {
+ list_del(>lru);
+ if (add_to_page_cache_lru(hpage, mapping, hpage->index,
+ GFP_KERNEL)) {
+ page_cache_release(hpage);
+ return 0;
+ }
+
+ ret = squashfs_readpage(file, hpage);
+ page_cache_release(hpage);
+ return ret;
+ }
+
if (last_bindex >= (i_size_read(inode) >> msblk->block_log))
return 0;
--
1.7.9.5
On Tue, Sep 17, 2013 at 10:52:14AM +0900, Minchan Kim wrote:
> This patch had a bug so I send fixed below patchset.
> Thanks.
>
> >From ccbf1322b6322bc34bb3e6f75a27f4fecf84ed02 Mon Sep 17 00:00:00 2001
> From: Minchan Kim
> Date: Mon, 16 Sep 2013 14:28:49 +0900
> Subject: [RFC 5/5] squashfs: support readpages
>
> This patch supports squashfs_readpages so it can do readahead pages
> without unplugging I/O scheduler. With blktrace, I confirmed following test.
>
> 2 compression ratio 1G file(ie, 500M consumed by real storage) sequential read
> with fadvise(SEQUENTIAL) hint and tune some knobs for block device and
> read_ahead_kb.
>
> Old :
> Reads Queued: 524289, 524289KiB Writes Queued: 0,
> 0KiB
> Read Dispatches: 4096, 524289KiB Write Dispatches:0,
> 0KiB
> Reads Requeued: 0 Writes Requeued: 0
> Reads Completed: 4096, 524289KiB Writes Completed:0,
> 0KiB
> Read Merges: 520193, 520193KiB Write Merges:0,
> 0KiB
> PC Reads Queued:0,0KiB PC Writes Queued:0,
> 0KiB
> PC Read Disp.: 10,0KiB PC Write Disp.: 0,
> 0KiB
> PC Reads Req.: 0 PC Writes Req.: 0
> PC Reads Compl.:0 PC Writes Compl.:0
> IO unplugs: 4096 Timer unplugs: 0
>
> New :
> Reads Queued: 524289, 524289KiB Writes Queued: 0,
> 0KiB
> Read Dispatches: 633, 524289KiB Write Dispatches:0,
> 0KiB
> Reads Requeued: 0 Writes Requeued: 0
> Reads Completed: 633, 524289KiB Writes Completed:0,
> 0KiB
> Read Merges: 523656, 523656KiB Write Merges:0,
> 0KiB
> PC Reads Queued:0,0KiB PC Writes Queued:0,
> 0KiB
> PC Read Disp.: 7,0KiB PC Write Disp.: 0,
> 0KiB
> PC Reads Req.: 0 PC Writes Req.: 0
> PC Reads Compl.:0 PC Writes Compl.:0
> IO unplugs:31 Timer unplugs: 0
>
> IOW, lots of I/O were merged before issuing. Of course, I can confirm that
> with
> blktrace.
>
> old:
>
> 8,34 0 1933 0.014381550 4957 Q R 4197628 + 2 [seqread]
> 8,34 0 1934 0.014381629 4957 M R 4197628 + 2 [seqread]
> 8,32 0 1935 0.014381821 4957 A R 4197630 + 2 <- (8,34) 1278
> 8,34 0 1936 0.014381919 4957 Q R 4197630 + 2 [seqread]
> 8,34 0 1937 0.014381998 4957 M R 4197630 + 2 [seqread]
> 8,32 0 1938 0.014382131 4957 A R 4197632 + 2 <- (8,34) 1280
> 8,34 0 1939 0.014382203 4957 Q R 4197632 + 2 [seqread]
> 8,34 0 1940 0.014382281 4957 M R 4197632 + 2 [seqread]
> 8,34 0 1941 0.014382873 4957 I R 4197378 + 256 [seqread]
> 8,34 00 0.014383649 0 m N cfq4957S / insert_request
> 8,34 00 0.014384609 0 m N cfq4957S / dispatch_insert
> 8,34 00 0.014385132 0 m N
Re: [RFC 5/5] squashfs: support readpages
This patch had a bug so I send fixed below patchset. Thanks. >From ccbf1322b6322bc34bb3e6f75a27f4fecf84ed02 Mon Sep 17 00:00:00 2001 From: Minchan Kim Date: Mon, 16 Sep 2013 14:28:49 +0900 Subject: [RFC 5/5] squashfs: support readpages This patch supports squashfs_readpages so it can do readahead pages without unplugging I/O scheduler. With blktrace, I confirmed following test. 2 compression ratio 1G file(ie, 500M consumed by real storage) sequential read with fadvise(SEQUENTIAL) hint and tune some knobs for block device and read_ahead_kb. Old : Reads Queued: 524289, 524289KiB Writes Queued: 0,0KiB Read Dispatches: 4096, 524289KiB Write Dispatches:0,0KiB Reads Requeued: 0 Writes Requeued: 0 Reads Completed: 4096, 524289KiB Writes Completed:0,0KiB Read Merges: 520193, 520193KiB Write Merges:0,0KiB PC Reads Queued:0,0KiB PC Writes Queued:0,0KiB PC Read Disp.: 10,0KiB PC Write Disp.: 0,0KiB PC Reads Req.: 0 PC Writes Req.: 0 PC Reads Compl.:0 PC Writes Compl.:0 IO unplugs: 4096 Timer unplugs: 0 New : Reads Queued: 524289, 524289KiB Writes Queued: 0,0KiB Read Dispatches: 633, 524289KiB Write Dispatches:0,0KiB Reads Requeued: 0 Writes Requeued: 0 Reads Completed: 633, 524289KiB Writes Completed:0,0KiB Read Merges: 523656, 523656KiB Write Merges:0,0KiB PC Reads Queued:0,0KiB PC Writes Queued:0,0KiB PC Read Disp.: 7,0KiB PC Write Disp.: 0,0KiB PC Reads Req.: 0 PC Writes Req.: 0 PC Reads Compl.:0 PC Writes Compl.:0 IO unplugs:31 Timer unplugs: 0 IOW, lots of I/O were merged before issuing. Of course, I can confirm that with blktrace. old: 8,34 0 1933 0.014381550 4957 Q R 4197628 + 2 [seqread] 8,34 0 1934 0.014381629 4957 M R 4197628 + 2 [seqread] 8,32 0 1935 0.014381821 4957 A R 4197630 + 2 <- (8,34) 1278 8,34 0 1936 0.014381919 4957 Q R 4197630 + 2 [seqread] 8,34 0 1937 0.014381998 4957 M R 4197630 + 2 [seqread] 8,32 0 1938 0.014382131 4957 A R 4197632 + 2 <- (8,34) 1280 8,34 0 1939 0.014382203 4957 Q R 4197632 + 2 [seqread] 8,34 0 1940 0.014382281 4957 M R 4197632 + 2 [seqread] 8,34 0 1941 0.014382873 4957 I R 4197378 + 256 [seqread] 8,34 00 0.014383649 0 m N cfq4957S / insert_request 8,34 00 0.014384609 0 m N cfq4957S / dispatch_insert 8,34 00 0.014385132 0 m N cfq4957S / dispatched a request 8,34 00 0.014385460 0 m N cfq4957S / activate rq, drv=1 8,34 0 1942 0.014385581 4957 D R 4197378 + 256 [seqread] new: 8,34 098321 0.352583517 5101 M R 4261888 + 2 [seqread] 8,34 098322 0.353008833 5101 I R 4230404 + 4096 [seqread] 8,34 00 0.353012357 0 m N cfq5101SN / insert_request 8,34 098323 0.353013872 5101 I R 4234500 + 4096 [seqread] 8,34 00 0.353014218 0 m N cfq5101SN / insert_request 8,34 098324 0.353014553 5101 I R 4238596 + 4096 [seqread] 8,34 00 0.353014802 0 m N cfq5101SN / insert_request 8,34 098325 0.353014992 5101 I R 4242692 + 4096 [seqread] 8,34 00 0.353015315 0 m N cfq5101SN / insert_request Voila, it's a result by that. elapsed time, old : 17.5 sec new : 11.5 sec A drawback from my mind is magic value 3ms for waiting more I/O so that it can make delay at least 3ms although the I/O was done earlier. The reason I selected that value is that it was a vaule kblockd had used for a long time to plug/unplug for scheduler until we introduced explicit blk_[start|finish]_plug. If it's really problem, we can add a hook into plug and flush the I/O if someone is waiting the I/O. Signed-off-by: Minchan Kim --- fs/squashfs/block.c | 2 - fs/squashfs/file.c | 447 ++- fs/squashfs/squashfs.h | 3 + fs/squashfs/squashfs_fs_sb.h | 4 + fs/squashfs/super.c | 4 +- 5 files changed, 450 insertions(+), 10 deletions(-) diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c index d41bac8..e8bf200 100644 --- a/fs/squashfs/block.c +++ b/fs/squashfs/block.c @@ -76,8 +76,6 @@ static struct buffer_head *get_block_length(struct super_block *sb, return bh; } - - int squashfs_decompress_block(struct
[PATCH] scsi: delete decade+ obsolete aic7xxx_old driver
After getting warnings in an allyesconfig build[1] from this driver, I decided to remind myself just how old it was, and whether it warranted fixing. In the Kconfig help text, I found: "This driver will eventually be phased out entirely" Going back to the history archive, I see the line was added[2] in Feb 2002, when we moved from v2.4.2.1 ---> v2.4.2.2 So, with over a decade of notification, and multiple major releases since then, I think we can justify removing this. Currently we have people wasting time building it during routine testing, and then wasting more time re-researching the known reported warnings, only to find that nobody really is willing to integrate the fixes[3] for it. A quick search didn't seem to indicate any active user base for it. If someone happens to have a quirky _old_ card that the eleven year old "new" driver doesn't work with, then it is entirely reasonable that they stick with a kernel version that predates this removal. [1] drivers/scsi/aic7xxx_old.c: In function ‘aic7xxx_register’: drivers/scsi/aic7xxx_old.c:7901:5: warning: case value ‘257’ not in enumerated type ‘ahc_chip’ [-Wswitch] drivers/scsi/aic7xxx_old.c:7898:5: warning: case value ‘513’ not in enumerated type ‘ahc_chip’ [-Wswitch] drivers/scsi/aic7xxx_old.c: In function ‘aic7xxx_load_seeprom’: drivers/scsi/aic7xxx_old.c:8517:5: warning: case value ‘257’ not in enumerated type ‘ahc_chip’ [-Wswitch] drivers/scsi/aic7xxx_old.c:8510:5: warning: case value ‘513’ not in enumerated type ‘ahc_chip’ [-Wswitch] [2] http://git.kernel.org/cgit/linux/kernel/git/tglx/history.git commit 44e8778c [3] https://lkml.org/lkml/2012/10/29/215 Cc: Hannes Reinecke Cc: Doug Ledford Cc: "James E.J. Bottomley" Signed-off-by: Paul Gortmaker --- [This is an "--irreversible-delete" pseudo-patch which doesn't show all the file content that was deleted wholesale. The full commit is at: git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git aic7xxx-delete ] Documentation/scsi/00-INDEX | 2 - Documentation/scsi/aic7xxx_old.txt | 511 -- MAINTAINERS | 1 - drivers/scsi/Kconfig|41 - drivers/scsi/Makefile | 1 - drivers/scsi/aic7xxx_old.c | 11149 -- drivers/scsi/aic7xxx_old/aic7xxx.h |28 - drivers/scsi/aic7xxx_old/aic7xxx.reg| 1401 drivers/scsi/aic7xxx_old/aic7xxx.seq| 1539 - drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 270 - drivers/scsi/aic7xxx_old/aic7xxx_reg.h | 629 -- drivers/scsi/aic7xxx_old/aic7xxx_seq.c | 817 --- drivers/scsi/aic7xxx_old/scsi_message.h |49 - drivers/scsi/aic7xxx_old/sequencer.h| 135 - 14 files changed, 16573 deletions(-) delete mode 100644 Documentation/scsi/aic7xxx_old.txt delete mode 100644 drivers/scsi/aic7xxx_old.c delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx.h delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx.reg delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx.seq delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx_proc.c delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx_reg.h delete mode 100644 drivers/scsi/aic7xxx_old/aic7xxx_seq.c delete mode 100644 drivers/scsi/aic7xxx_old/scsi_message.h delete mode 100644 drivers/scsi/aic7xxx_old/sequencer.h diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX index 9b0787f..2044be5 100644 --- a/Documentation/scsi/00-INDEX +++ b/Documentation/scsi/00-INDEX @@ -42,8 +42,6 @@ aic79xx.txt - Adaptec Ultra320 SCSI host adapters aic7xxx.txt - info on driver for Adaptec controllers -aic7xxx_old.txt - - info on driver for Adaptec controllers, old generation arcmsr_spec.txt - ARECA FIRMWARE SPEC (for IOP331 adapter) dc395x.txt diff --git a/Documentation/scsi/aic7xxx_old.txt b/Documentation/scsi/aic7xxx_old.txt deleted file mode 100644 index ecfc474..000 diff --git a/MAINTAINERS b/MAINTAINERS index e61c2e8..c79be42 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -470,7 +470,6 @@ M: Hannes Reinecke L: linux-s...@vger.kernel.org S: Maintained F: drivers/scsi/aic7xxx/ -F: drivers/scsi/aic7xxx_old/ AIMSLAB FM RADIO RECEIVER DRIVER M: Hans Verkuil diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index fe25677..1f02003 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -499,47 +499,6 @@ config SCSI_AACRAID source "drivers/scsi/aic7xxx/Kconfig.aic7xxx" - -config SCSI_AIC7XXX_OLD - tristate "Adaptec AIC7xxx support (old driver)" - depends on (ISA || EISA || PCI ) && SCSI - help - WARNING This driver is an older aic7xxx driver and is no longer - under active development. Adaptec, Inc. is writing a new driver to - take the place of this one, and it is recommended that whenever - possible, people should use the new Adaptec written driver instead - of this one. This
[PATCH 1/3] msi: add forgotten pci_dev_put(pdev) to populate_msi_sysfs()
Before trying to kobject_init_and_add(), we add a reference to pdev via
pci_dev_get(pdev). However, if it fails to init and/or add the kobject, we
don't return it back - even on out_unroll.
Fix this by adding pci_dev_put(pdev) before going to unrolling section.
CC: Bjorn Helgaas
CC: linux-...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Veaceslav Falico
---
drivers/pci/msi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d5f90d6..14bf578 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -534,8 +534,10 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
pci_dev_get(pdev);
ret = kobject_init_and_add(kobj, _irq_ktype, NULL,
"%u", entry->irq);
- if (ret)
+ if (ret) {
+ pci_dev_put(pdev);
goto out_unroll;
+ }
count++;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] msi: free msi_desc entry only after we've released the kobject
Currently, we first do kobject_put(>kobj) and the kfree(entry),
however kobject_put() doesn't guarantee us that it was the last reference
and that the kobj isn't used currently by someone else, so after we
kfree(entry) with the struct kobject - other users will begin using the
freed memory, instead of the actual kobject.
Fix this by using the kobject->release callback, which is called last when
the kobject is indeed not used and is cleaned up - it's msi_kobj_release(),
which can do the kfree(entry) safely (kobject_put/cleanup doesn't use the
kobj itself after ->release() was called, so we're safe).
In case we've failed to create the sysfs directories - just kfree()
it - cause we don't have the kobjects attached.
Also, remove the same functionality from populate_msi_sysfs(), cause on
failure we anyway call free_msi_irqs(), which will take care of all the
kobjects properly.
CC: Bjorn Helgaas
CC: linux-...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Veaceslav Falico
---
drivers/pci/msi.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 68da921..c9236e4 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -374,19 +374,22 @@ static void free_msi_irqs(struct pci_dev *dev)
iounmap(entry->mask_base);
}
+ list_del(>list);
+
/*
* Its possible that we get into this path
* When populate_msi_sysfs fails, which means the entries
* were not registered with sysfs. In that case don't
-* unregister them.
+* unregister them, and just free. Otherwise the
+* kobject->release will take care of freeing the entry via
+* msi_kobj_release().
*/
if (entry->kobj.parent) {
kobject_del(>kobj);
kobject_put(>kobj);
+ } else {
+ kfree(entry);
}
-
- list_del(>list);
- kfree(entry);
}
kset_unregister(dev->msi_kset);
@@ -512,6 +515,7 @@ static void msi_kobj_release(struct kobject *kobj)
struct msi_desc *entry = to_msi_desc(kobj);
pci_dev_put(entry->dev);
+ kfree(entry);
}
static struct kobj_type msi_irq_ktype = {
@@ -525,7 +529,6 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
struct msi_desc *entry;
struct kobject *kobj;
int ret;
- int count = 0;
pdev->msi_kset = kset_create_and_add("msi_irqs", NULL, >dev.kobj);
if (!pdev->msi_kset)
@@ -539,23 +542,11 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
"%u", entry->irq);
if (ret) {
pci_dev_put(pdev);
- goto out_unroll;
+ return ret;
}
-
- count++;
}
return 0;
-
-out_unroll:
- list_for_each_entry(entry, >msi_list, list) {
- if (!count)
- break;
- kobject_del(>kobj);
- kobject_put(>kobj);
- count--;
- }
- return ret;
}
/**
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] msi: always unregister ->msi_kset within free_msi_irqs()
Currently we create and populate ->msi_kset while allocating irqs in populate_msi_sysfs(), however if it fails and/or we want to free the entries - we don't always remove it, and we might have problems if we've failed to allocate irqs and try it again. To fix that, move the unregister part to free_msi_irqs() and remove already existing ones. CC: Bjorn Helgaas CC: linux-...@vger.kernel.org CC: linux-kernel@vger.kernel.org Signed-off-by: Veaceslav Falico --- drivers/pci/msi.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 14bf578..68da921 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -388,6 +388,9 @@ static void free_msi_irqs(struct pci_dev *dev) list_del(>list); kfree(entry); } + + kset_unregister(dev->msi_kset); + dev->msi_kset = NULL; } static struct msi_desc *alloc_msi_entry(struct pci_dev *dev) @@ -917,8 +920,6 @@ void pci_disable_msi(struct pci_dev *dev) pci_msi_shutdown(dev); free_msi_irqs(dev); - kset_unregister(dev->msi_kset); - dev->msi_kset = NULL; } EXPORT_SYMBOL(pci_disable_msi); @@ -1015,8 +1016,6 @@ void pci_disable_msix(struct pci_dev *dev) pci_msix_shutdown(dev); free_msi_irqs(dev); - kset_unregister(dev->msi_kset); - dev->msi_kset = NULL; } EXPORT_SYMBOL(pci_disable_msix); -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] msi: fix kobject/sysfs removal from msi_list
Currently, while removing msi_list's ->kobj, we just do kobject_put() on it and after that free the entry itself. However, kobject_put() doesn't guarantee that the kobject itself is freed - it can be used by someone else and thus, when we'll free the entry, we'll free the kobject too - leading to bugs in the other users (or when we'll finally release it). Also, in some cases we might fail to register the kobjects, but we forget to remove pdev->msi_kset, and this can lead to errors if we try to re-register it - cause we already have that kset initialized. Fix both issues by moving msi_kset/kobject deinitialization code completely to free_msi_irqs(), which is called every time we fail and need to roll back (and on the proper device irqs deinit). Also, move kfree-ing of the msi_list entry to kobject->release (msi_kobj_release()), so that the entry containing kobject will only be delisted in free_msi_irqs(), and free only when there are no other users of its kobject. CC: Bjorn Helgaas CC: linux-...@vger.kernel.org CC: linux-kernel@vger.kernel.org Signed-off-by: Veaceslav Falico --- drivers/pci/msi.c | 38 +++--- 1 file changed, 15 insertions(+), 23 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] perf tools: Compare hists comm by addresses
Hi Frederic,
On Fri, 13 Sep 2013 15:59:49 +0200, Frederic Weisbecker wrote:
> On Fri, Sep 13, 2013 at 05:07:06PM +0900, Namhyung Kim wrote:
[SNIP]
>> --- a/tools/perf/util/sort.c
>> +++ b/tools/perf/util/sort.c
>> @@ -1,5 +1,6 @@
>> #include "sort.h"
>> #include "hist.h"
>> +#include "comm.h"
>> #include "symbol.h"
>>
>> regex_t parent_regex;
>> @@ -80,14 +81,14 @@ static int64_t
>> sort__comm_cmp(struct hist_entry *left, struct hist_entry *right)
>> {
>> /* Compare the addr that should be unique among comm */
>> -return thread__comm_curr(right->thread) -
>> thread__comm_curr(left->thread);
>> +return comm__str(right->comm) - comm__str(left->comm);
>
>
> If comm and fork events don't have a timestamp, or they aren't time ordered,
> we should
> override the comm entry of a thread and forget the previous one.
>
> So perhaps what we should do instead is to compare "struct comm" addresses
> directly.
> But it means that on thread__set_comm(), if we override the old entry due to
> missing or
> unordered timestamps (in which case we need to force them to be 0), we
> shouldn't reallocate
> a new struct comm, nor should we keep the old one and queue a new. Instead we
> need to override
> list_first_entry(thread->comm)->comm_str pointer only to make it point to a
> new struct comm_str.
Okay. Here's a revised patch:
>From 599221323f8fc0fd3327190900fece6c2aaa7309 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Fri, 13 Sep 2013 16:28:57 +0900
Subject: [PATCH] perf tools: Get current comm instead of last one
At insert time, a hist entry should reference comm at the time
otherwise it'll get the last comm anyway.
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/comm.c | 15 +++
tools/perf/util/comm.h | 1 +
tools/perf/util/hist.c | 3 +++
tools/perf/util/sort.c | 14 +-
tools/perf/util/sort.h | 1 +
tools/perf/util/thread.c | 6 +++---
tools/perf/util/thread.h | 2 ++
7 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/tools/perf/util/comm.c b/tools/perf/util/comm.c
index 87f4a10e4a23..2d0f94f6593e 100644
--- a/tools/perf/util/comm.c
+++ b/tools/perf/util/comm.c
@@ -95,6 +95,21 @@ struct comm *comm__new(const char *str, u64 timestamp)
return self;
}
+void comm__override(struct comm *comm, const char *str, u64 timestamp)
+{
+ struct comm_str *old = comm->comm_str;
+
+ comm->comm_str = comm_str_findnew(str, _str_root);
+ if (!comm->comm_str) {
+ comm->comm_str = old;
+ return;
+ }
+
+ comm->start = timestamp;
+ comm_str_get(comm->comm_str);
+ comm_str_put(old);
+}
+
void comm__free(struct comm *self)
{
comm_str_put(self->comm_str);
diff --git a/tools/perf/util/comm.h b/tools/perf/util/comm.h
index 2e47fb7e27de..d37c2898e665 100644
--- a/tools/perf/util/comm.h
+++ b/tools/perf/util/comm.h
@@ -16,5 +16,6 @@ struct comm {
void comm__free(struct comm *self);
struct comm *comm__new(const char *str, u64 timestamp);
const char *comm__str(struct comm *self);
+void comm__override(struct comm *self, const char *str, u64 timestamp);
#endif /* __PERF_COMM_H */
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 1f5767f97dce..1fe90bd9dcb7 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -412,6 +412,7 @@ struct hist_entry *__hists__add_mem_entry(struct hists
*self,
{
struct hist_entry entry = {
.thread = al->thread,
+ .comm = curr_comm(al->thread),
.ms = {
.map= al->map,
.sym= al->sym,
@@ -442,6 +443,7 @@ struct hist_entry *__hists__add_branch_entry(struct hists
*self,
{
struct hist_entry entry = {
.thread = al->thread,
+ .comm = curr_comm(al->thread),
.ms = {
.map= bi->to.map,
.sym= bi->to.sym,
@@ -471,6 +473,7 @@ struct hist_entry *__hists__add_entry(struct hists *self,
{
struct hist_entry entry = {
.thread = al->thread,
+ .comm = curr_comm(al->thread),
.ms = {
.map= al->map,
.sym= al->sym,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 3b307e740d6e..65f10784d2dc 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1,5 +1,6 @@
#include "sort.h"
#include "hist.h"
+#include "comm.h"
#include "symbol.h"
regex_tparent_regex;
@@ -80,25 +81,20 @@ static int64_t
sort__comm_cmp(struct hist_entry *left, struct hist_entry *right)
{
/* Compare the addr that should be unique among comm */
- return thread__comm_curr(right->thread) -
thread__comm_curr(left->thread);
+ return comm__str(right->comm) - comm__str(left->comm);
}
static int64_t
sort__comm_collapse(struct hist_entry
Re: [PATCH] m68k: remove unused Kconfig parameters
Hi Michael,
On 06/09/13 21:59, Michael Opdenacker wrote:
> This patch proposes to remove the UC5282 and UC5272 kernel configuration
> parameters defined in arch/m68k/Kconfig.machine,
> but used nowhere in the makefiles and source code.
>
> Signed-off-by: Michael Opdenacker
This change is a subset of c065edde ("remove 16 unused boards in
Kconfig.machine") by Pauk Bolle. And that is in 3.12-rc1.
Thanks
Greg
> ---
> arch/m68k/Kconfig.machine | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
> index b9ab0a6..a10516b 100644
> --- a/arch/m68k/Kconfig.machine
> +++ b/arch/m68k/Kconfig.machine
> @@ -150,18 +150,6 @@ config XCOPILOT_BUGS
> help
> Support the bugs of Xcopilot.
>
> -config UC5272
> - bool "Arcturus Networks uC5272 dimm board support"
> - depends on M5272
> - help
> - Support for the Arcturus Networks uC5272 dimm board.
> -
> -config UC5282
> - bool "Arcturus Networks uC5282 board support"
> - depends on M528x
> - help
> - Support for the Arcturus Networks uC5282 dimm board.
> -
> config UCSIMM
> bool "uCsimm module support"
> depends on M68EZ328
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: "memory" binding issues
On Mon, 2013-09-16 at 16:48 -0700, Olof Johansson wrote: > On Mon, Sep 16, 2013 at 4:47 PM, Benjamin Herrenschmidt > wrote: > > On Mon, 2013-09-16 at 15:48 -0700, Olof Johansson wrote: > >> > A node that has a "reg" property should have the corresponding unit > >> > address. > >> > >> No, absolutely _NOT_ a requirement. Unit address is only required if > >> needed to disambiguate two properties with the same name. > >> > >> If there are no ambiguities, then leaving off the unit address is much > >> preferred. > > > > I disagree :-) > > Well, good thing you've got your own arch to litter the device trees > with unit specifiers in then. :) Right :-) We tend to have multiple memory nodes on server anyway so it's not a big deal. > > Also this would be only true of our find_node_by_path was capable of > > handling it, which it isn't. Thus you end up with generic code looking > > for /memory and finding nothing ... > > Yes, this should be fixed. Right, the whole thing becomes mostly a non-issue once that's fixed. My main objection isn't that ARM doesn't use unit address specifiers. My objection is that the binding documents no unit address :-) It should instead document the unit address with a note indicating that it can be omitted if there is no ambiguity. But first, do we have a volunteer to fix the path parsing code ? Also do we *really* need to keep the path parsing code for fdt ? IE. It would be annoying to have to duplicate that code for before and after expansion... Cheers, Ben. > -Olof > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtd: nand: fix memory leak in ONFI extended parameter page
This fixes a memory leak in the ONFI support code for detecting the
required ECC levels from this commit:
commit 6dcbe0cdd83fb5f77be4f44c9e06c535281c375a
Author: Huang Shijie
Date: Wed May 22 10:28:27 2013 +0800
mtd: get the ECC info from the Extended Parameter Page
In the success case, we never freed the 'ep' buffer.
Also, this fixes an oversight in the same commit where we (harmlessly)
freed the NULL pointer.
Signed-off-by: Brian Norris
Cc: Huang Shijie
---
David, if there are no objections, can you send this to Linus for 3.12?
If this doesn't make it into 3.12, then it will be -stable material.
drivers/mtd/nand/nand_base.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index d4578a1..00022b4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2869,10 +2869,8 @@ static int nand_flash_detect_ext_param_page(struct
mtd_info *mtd,
len = le16_to_cpu(p->ext_param_page_length) * 16;
ep = kmalloc(len, GFP_KERNEL);
- if (!ep) {
- ret = -ENOMEM;
- goto ext_out;
- }
+ if (!ep)
+ return -ENOMEM;
/* Send our own NAND_CMD_PARAM. */
chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
@@ -2920,7 +2918,7 @@ static int nand_flash_detect_ext_param_page(struct
mtd_info *mtd,
}
pr_info("ONFI extended param page detected.\n");
- return 0;
+ ret = 0;
ext_out:
kfree(ep);
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: lustre: remove assignment in if conditions
This is a patch to lvfs_linux.c that removes the use of variable assignment
within an if condition found by checkpatch.pl.
Signed-off-by: Jon Bernard
---
drivers/staging/lustre/lustre/lvfs/lvfs_linux.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lvfs/lvfs_linux.c
b/drivers/staging/lustre/lustre/lvfs/lvfs_linux.c
index 18e1b47..7b03f4d 100644
--- a/drivers/staging/lustre/lustre/lvfs/lvfs_linux.c
+++ b/drivers/staging/lustre/lustre/lvfs/lvfs_linux.c
@@ -80,7 +80,8 @@ static void push_group_info(struct lvfs_run_ctxt *save,
struct cred *cred;
task_lock(current);
save->group_info = current_cred()->group_info;
- if ((cred = prepare_creds())) {
+ cred = prepare_creds();
+ if (cred) {
cred->group_info = ginfo;
commit_creds(cred);
}
@@ -96,7 +97,8 @@ static void pop_group_info(struct lvfs_run_ctxt *save,
} else {
struct cred *cred;
task_lock(current);
- if ((cred = prepare_creds())) {
+ cred = prepare_creds();
+ if (cred) {
cred->group_info = save->group_info;
commit_creds(cred);
}
@@ -137,7 +139,8 @@ void push_ctxt(struct lvfs_run_ctxt *save, struct
lvfs_run_ctxt *new_ctx,
save->luc.luc_fsgid = current_fsgid();
save->luc.luc_cap = current_cap();
- if ((cred = prepare_creds())) {
+ cred = prepare_creds();
+ if (cred) {
cred->uid = uc->luc_uid;
cred->gid = uc->luc_gid;
cred->fsuid = uc->luc_fsuid;
@@ -180,7 +183,8 @@ void pop_ctxt(struct lvfs_run_ctxt *saved, struct
lvfs_run_ctxt *new_ctx,
current->fs->umask = saved->luc.luc_umask;
if (uc) {
struct cred *cred;
- if ((cred = prepare_creds())) {
+ cred = prepare_creds();
+ if (cred) {
cred->uid = saved->luc.luc_uid;
cred->gid = saved->luc.luc_gid;
cred->fsuid = saved->luc.luc_fsuid;
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rwsem: add rwsem_is_contended
On 09/16/2013 09:11 PM, Josef Bacik wrote: On Mon, Sep 16, 2013 at 06:08:42PM -0700, David Daney wrote: On 09/16/2013 05:37 PM, Peter Hurley wrote: On 09/16/2013 08:29 PM, David Daney wrote: On 09/16/2013 05:05 PM, Josef Bacik wrote: On Mon, Sep 16, 2013 at 04:05:47PM -0700, Andrew Morton wrote: On Fri, 30 Aug 2013 10:14:01 -0400 Josef Bacik wrote: Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they will drop the lock and schedule. The transaction commit needs to take a write lock for this rwsem for a very short period to switch out the commit roots. If there are a lot of threads doing this caching operation we can starve out the committers which slows everybody out. To address this we want to add this functionality to see if our rwsem has anybody waiting to take a write lock so we can drop it and schedule for a bit to allow the commit to continue. Thanks, This sounds rather nasty and hacky. Rather then working around a locking shortcoming in a caller it would be better to fix/enhance the core locking code. What would such a change need to do? Presently rwsem waiters are fifo-queued, are they not? So the commit thread will eventually get that lock. Apparently that's not working adequately for you but I don't fully understand what it is about these dynamics which is causing observable problems. So the problem is not that its normal lock starvation, it's more our particular use case that is causing the starvation. We can have lots of people holding readers and simply never give them up for long periods of time, which is why we need this is_contended helper so we know to drop things and let the committer through. Thanks, You could easily achieve the same thing by putting an "is_contending" flag in parallel with the rwsem and testing that: Which adds a bunch more bus-locked operations to contended over Would that be a problem in this particular case? Has it been measured? , when a unlocked if (list_empty()) is sufficient. I don't object to adding rwsem_is_contended() *if* it is required. I was just pointing out that there may be other options. The patch adds a bunch of new semantics to rwsem. There is a trade off between increased complexity of core code, and generalizing subsystem specific optimizations that may not be globally useful. Is it worth it in this case? I do not know. So what you suggested is actually what we did in order to prove that this was what the problem was. I'm ok with continuing to do that, I just figured adding something like rwsem_is_contended() would be nice in case anybody else runs into the issue in the future, plus it would save me an atomic_t in an already large structure. I saw the original patch you linked to earlier in the discussion, and I agree that for your use case adding a contention test is cleaner and clearer than other options. That said, I think this extension is only useful for readers: writers should be getting their business done and releasing the sem. Also, I think the comment above the function should be clearer that the lock must already be held by the caller; IOW, this is not a trylock replacement. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rwsem: add rwsem_is_contended
On 09/16/2013 05:37 PM, Peter Hurley wrote: On 09/16/2013 08:29 PM, David Daney wrote: On 09/16/2013 05:05 PM, Josef Bacik wrote: On Mon, Sep 16, 2013 at 04:05:47PM -0700, Andrew Morton wrote: On Fri, 30 Aug 2013 10:14:01 -0400 Josef Bacik wrote: Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they will drop the lock and schedule. The transaction commit needs to take a write lock for this rwsem for a very short period to switch out the commit roots. If there are a lot of threads doing this caching operation we can starve out the committers which slows everybody out. To address this we want to add this functionality to see if our rwsem has anybody waiting to take a write lock so we can drop it and schedule for a bit to allow the commit to continue. Thanks, This sounds rather nasty and hacky. Rather then working around a locking shortcoming in a caller it would be better to fix/enhance the core locking code. What would such a change need to do? Presently rwsem waiters are fifo-queued, are they not? So the commit thread will eventually get that lock. Apparently that's not working adequately for you but I don't fully understand what it is about these dynamics which is causing observable problems. So the problem is not that its normal lock starvation, it's more our particular use case that is causing the starvation. We can have lots of people holding readers and simply never give them up for long periods of time, which is why we need this is_contended helper so we know to drop things and let the committer through. Thanks, You could easily achieve the same thing by putting an "is_contending" flag in parallel with the rwsem and testing that: Which adds a bunch more bus-locked operations to contended over Would that be a problem in this particular case? Has it been measured? , when a unlocked if (list_empty()) is sufficient. I don't object to adding rwsem_is_contended() *if* it is required. I was just pointing out that there may be other options. The patch adds a bunch of new semantics to rwsem. There is a trade off between increased complexity of core code, and generalizing subsystem specific optimizations that may not be globally useful. Is it worth it in this case? I do not know. David Daney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/9] i2c: prepare runtime PM support for I2C client devices
On Tuesday, September 17, 2013 12:31:11 AM Mark Brown wrote: > On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote: > > > That may be left to the client driver altogether. I mean, if the client > > wants > > the controller to be powered up, it should just call > > pm_runtime_get_sync(controller device) at a suitable place (and then do the > > corresponding _put when the controller is not necessary anu more) from its > > ->probe() callback. > > It shouldn't even need to do that, it should just be able to rely on the > controller to power itself up when asked to do work. This is how the > existing implementations are done - the controller power management is > totally transparent to the slave. If both the I2C client and I2C controller have corresponding objects in the ACPI namespace and the client's object is a child of the controller's object, then in order to power up the client we need to power up the controller even if no transactions are going to be carried out. That's what the spec simply requires us to do in that case. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rwsem: add rwsem_is_contended
On Mon, Sep 16, 2013 at 06:08:42PM -0700, David Daney wrote: > On 09/16/2013 05:37 PM, Peter Hurley wrote: > >On 09/16/2013 08:29 PM, David Daney wrote: > >>On 09/16/2013 05:05 PM, Josef Bacik wrote: > >>>On Mon, Sep 16, 2013 at 04:05:47PM -0700, Andrew Morton wrote: > On Fri, 30 Aug 2013 10:14:01 -0400 Josef Bacik > wrote: > > >Btrfs uses an rwsem to control access to its extent tree. Threads > >will hold a > >read lock on this rwsem while they scan the extent tree, and if > >need_resched() > >they will drop the lock and schedule. The transaction commit needs > >to take a > >write lock for this rwsem for a very short period to switch out the > >commit > >roots. If there are a lot of threads doing this caching operation > >we can starve > >out the committers which slows everybody out. To address this we > >want to add > >this functionality to see if our rwsem has anybody waiting to take > >a write lock > >so we can drop it and schedule for a bit to allow the commit to > >continue. > >Thanks, > > > > This sounds rather nasty and hacky. Rather then working around a > locking shortcoming in a caller it would be better to fix/enhance the > core locking code. What would such a change need to do? > > Presently rwsem waiters are fifo-queued, are they not? So the commit > thread will eventually get that lock. Apparently that's not working > adequately for you but I don't fully understand what it is about these > dynamics which is causing observable problems. > > >>> > >>>So the problem is not that its normal lock starvation, it's more our > >>>particular > >>>use case that is causing the starvation. We can have lots of people > >>>holding > >>>readers and simply never give them up for long periods of time, which > >>>is why we > >>>need this is_contended helper so we know to drop things and let the > >>>committer > >>>through. Thanks, > >> > >>You could easily achieve the same thing by putting an "is_contending" > >>flag in parallel with the rwsem and testing that: > > > >Which adds a bunch more bus-locked operations to contended over > > Would that be a problem in this particular case? Has it been measured? > > >, when > >a unlocked if (list_empty()) is sufficient. > > I don't object to adding rwsem_is_contended() *if* it is required. I was > just pointing out that there may be other options. > > The patch adds a bunch of new semantics to rwsem. There is a trade off > between increased complexity of core code, and generalizing subsystem > specific optimizations that may not be globally useful. > > Is it worth it in this case? I do not know. > So what you suggested is actually what we did in order to prove that this was what the problem was. I'm ok with continuing to do that, I just figured adding something like rwsem_is_contended() would be nice in case anybody else runs into the issue in the future, plus it would save me an atomic_t in an already large structure. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] mm/mempolicy: use NUMA_NO_NODE
Use more appropriate NUMA_NO_NODE instead of -1
Signed-off-by: Jianguo Wu
Acked-by: KOSAKI Motohiro
---
mm/mempolicy.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 4baf12e..4f0cd20 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1083,7 +1083,7 @@ int do_migrate_pages(struct mm_struct *mm, const
nodemask_t *from,
tmp = *from;
while (!nodes_empty(tmp)) {
int s,d;
- int source = -1;
+ int source = NUMA_NO_NODE;
int dest = 0;
for_each_node_mask(s, tmp) {
@@ -1118,7 +1118,7 @@ int do_migrate_pages(struct mm_struct *mm, const
nodemask_t *from,
if (!node_isset(dest, tmp))
break;
}
- if (source == -1)
+ if (source == NUMA_NO_NODE)
break;
node_clear(source, tmp);
@@ -1765,7 +1765,7 @@ static unsigned offset_il_node(struct mempolicy *pol,
unsigned nnodes = nodes_weight(pol->v.nodes);
unsigned target;
int c;
- int nid = -1;
+ int nid = NUMA_NO_NODE;
if (!nnodes)
return numa_node_id();
@@ -1802,11 +1802,11 @@ static inline unsigned interleave_nid(struct mempolicy
*pol,
/*
* Return the bit number of a random bit set in the nodemask.
- * (returns -1 if nodemask is empty)
+ * (returns NUMA_NO_NODE if nodemask is empty)
*/
int node_random(const nodemask_t *maskp)
{
- int w, bit = -1;
+ int w, bit = NUMA_NO_NODE;
w = nodes_weight(*maskp);
if (w)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: fix fatal kernel-doc error
From: Randy Dunlap
Fix fatal kernel-doc error in :
Error(include/linux/regulator/driver.h:52): cannot understand prototype:
'struct regulator_linear_range '
Signed-off-by: Randy Dunlap
Cc: Liam Girdwood
Cc: Mark Brown
---
include/linux/regulator/driver.h |2 ++
1 file changed, 2 insertions(+)
--- lnx-312-rc1.orig/include/linux/regulator/driver.h
+++ lnx-312-rc1/include/linux/regulator/driver.h
@@ -40,6 +40,8 @@ enum regulator_status {
};
/**
+ * struct regulator_linear_range - specify voltage ranges
+ *
* Specify a range of voltages for regulator_map_linar_range() and
* regulator_list_linear_range().
*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mempolicy: use NUMA_NO_NODE
On 2013/9/17 4:26, Cody P Schafer wrote:
>
>> @@ -1802,11 +1802,11 @@ static inline unsigned interleave_nid(struct
>> mempolicy *pol,
>>
>> /*
>>* Return the bit number of a random bit set in the nodemask.
>> - * (returns -1 if nodemask is empty)
>> + * (returns NUMA_NO_NOD if nodemask is empty)
>
> s/NUMA_NO_NOD/NUMA_NO_NODE/
>
Thanks, I will resent this.
>>*/
>> int node_random(const nodemask_t *maskp)
>> {
>> -int w, bit = -1;
>> +int w, bit = NUMA_NO_NODE;
>>
>> w = nodes_weight(*maskp);
>> if (w)
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mempolicy: use NUMA_NO_NODE
On 2013/9/17 0:19, KOSAKI Motohiro wrote: > (9/16/13 8:53 AM), Jianguo Wu wrote: >> Use more appropriate NUMA_NO_NODE instead of -1 >> >> Signed-off-by: Jianguo Wu >> --- >> mm/mempolicy.c | 10 +- >> 1 files changed, 5 insertions(+), 5 deletions(-) > > I think this patch don't make any functional change, right? > Yes. > Acked-by: KOSAKI Motohiro Thanks for your ack. > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup
On 09/16/2013 05:05 PM, Dan Carpenter wrote: > On Mon, Sep 16, 2013 at 04:49:29PM -0400, Joseph Salisbury wrote: >> On 09/16/2013 04:38 PM, Dan Carpenter wrote: >>> On Mon, Sep 16, 2013 at 01:42:35PM -0400, Joseph Salisbury wrote: Reverting the patch changes the driver back to useing kzalloc() and memcpy() instead of kmemdup. Doing so has uncovered another bug, which causes an oops on memcpy()[1]. We are in the process of bisecting that one now and will provide the results. >>> The two bugs are the same it's that the code has shifted a little. Mark >>> the commit as buggy and continue with the git bisect. >>> >>> regards, >>> dan carpenter >> Can you explain a little further? Mark commit a4a23f6 as bad? An >> initial bisect already reported that was the first bad commit, so it >> can't be marked bad. The oops on memcpy() happens after commit a4a23f6 >> is reverted. The oops on memcpy() did not happen before a4a23f6 was >> committed, so I assume this new oops was introduced by a change later. >> >> Right now I'm bisecting down the oops on memcpy() by updating the bisect >> with good or bad, depending if the test kernel hit the oops. I then >> revert a4a23f6, so that revert is the HEAD of the tree each time before >> building the kernel again(As long as the commit spit out by bisect is >> after when a4a23f6 was introduced). > Yep. Please continue bisecting the memcpy() oops. > > kmemdup() is just a kzalloc() followed by a memcpy(). When we split it > apart by reverting the patch then we would expect the oops to move to > the memcpy() part. Somehow "desc" is a bogus pointer, but I don't > immediately see how that is possible. > > regards, > dan carpenter Thanks for the details. We'll continue the bisect and let you know how it goes. Thanks again, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rwsem: add rwsem_is_contended
On 09/16/2013 08:29 PM, David Daney wrote: On 09/16/2013 05:05 PM, Josef Bacik wrote: On Mon, Sep 16, 2013 at 04:05:47PM -0700, Andrew Morton wrote: On Fri, 30 Aug 2013 10:14:01 -0400 Josef Bacik wrote: Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they will drop the lock and schedule. The transaction commit needs to take a write lock for this rwsem for a very short period to switch out the commit roots. If there are a lot of threads doing this caching operation we can starve out the committers which slows everybody out. To address this we want to add this functionality to see if our rwsem has anybody waiting to take a write lock so we can drop it and schedule for a bit to allow the commit to continue. Thanks, This sounds rather nasty and hacky. Rather then working around a locking shortcoming in a caller it would be better to fix/enhance the core locking code. What would such a change need to do? Presently rwsem waiters are fifo-queued, are they not? So the commit thread will eventually get that lock. Apparently that's not working adequately for you but I don't fully understand what it is about these dynamics which is causing observable problems. So the problem is not that its normal lock starvation, it's more our particular use case that is causing the starvation. We can have lots of people holding readers and simply never give them up for long periods of time, which is why we need this is_contended helper so we know to drop things and let the committer through. Thanks, You could easily achieve the same thing by putting an "is_contending" flag in parallel with the rwsem and testing that: Which adds a bunch more bus-locked operations to contended over, when a unlocked if (list_empty()) is sufficient. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rwsem: add rwsem_is_contended
On 09/16/2013 05:05 PM, Josef Bacik wrote: On Mon, Sep 16, 2013 at 04:05:47PM -0700, Andrew Morton wrote: On Fri, 30 Aug 2013 10:14:01 -0400 Josef Bacik wrote: Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they will drop the lock and schedule. The transaction commit needs to take a write lock for this rwsem for a very short period to switch out the commit roots. If there are a lot of threads doing this caching operation we can starve out the committers which slows everybody out. To address this we want to add this functionality to see if our rwsem has anybody waiting to take a write lock so we can drop it and schedule for a bit to allow the commit to continue. Thanks, This sounds rather nasty and hacky. Rather then working around a locking shortcoming in a caller it would be better to fix/enhance the core locking code. What would such a change need to do? Presently rwsem waiters are fifo-queued, are they not? So the commit thread will eventually get that lock. Apparently that's not working adequately for you but I don't fully understand what it is about these dynamics which is causing observable problems. So the problem is not that its normal lock starvation, it's more our particular use case that is causing the starvation. We can have lots of people holding readers and simply never give them up for long periods of time, which is why we need this is_contended helper so we know to drop things and let the committer through. Thanks, You could easily achieve the same thing by putting an "is_contending" flag in parallel with the rwsem and testing that: DECLARE_RWSEM(foo); atomic_t is_contended = ATOMIC_INIT(0); . . . /* writing context */ atomic_inc(_contended); down_write(); do_writing_action(); up_write(); atomic_dec(_contended); /* reading context */ down_read(); while (!atomic_read(_contended)) do_reading_actions(); up_read(); David Daney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [RFC v2] seqcount: Add lockdep functionality to seqcount/seqlock structures
On 09/13/2013 05:19 PM, John Stultz wrote: > Currently seqlocks and seqcounts don't support lockdep. > > After running across a seqcount related deadlock in the timekeeping > code, I used a less-refined and more focused varient of this patch > to narrow down the cause of the issue. > > This is a first-pass attempt to properly enable lockdep functionality > on seqlocks and seqcounts. > > Since seqcounts are used in the vdso gettimeofday code, I've provided > lockdep accessors. > > I've also handled one cases where there were nested seqlock writers > and there may be more edge cases. Oof. So I just noticed there's a bunch of places in the network code that use fairly deeply embedded seqcounter: u64_stats_sync. There's almost never an explicit initialization, as they assume they're zeroed when allocated, but this causes trouble with the lockdep key initialization. I'll have to go through each of these (about 25 cases) and make them call seqcount_init(), but since I'm heading to plumbers tomorrow I might not get to it until next week. Anyway, let me know if you have any other thoughts on the patches. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpu: host1x: use %pa to print dma_addr_t
On 09/16/13 17:06, Olof Johansson wrote:
> On Mon, Sep 16, 2013 at 8:54 AM, Joe Perches wrote:
>> On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote:
>>> On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
>>> wrote:
On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote:
> This removes two warnings where dma_addr_t variables were printed using
> %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t:
>
> drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects
> argument of type 'unsigned int', but argument 5 has type 'dma_addr_t'
> drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects
> argument of type 'unsigned int', but argument 3 has type 'dma_addr_t'
Hi Olof,
I can't reproduce this. Does this perhaps depend on some other patch?
When I enable LPAE I do see similar warnings in drivers/iommu/tegra-*.c
and those can indeed be fixed using an equivalent patch.
>>>
>>> You need to enable LPAE on a platform that also selects
>>> ARCH_DMA_ADDR_T_64BIT, I don't think tegra does. If you do it with
>>> multi_v7_defconfig you'll see them.
>>>
>>> However, see discussion on another of the emails in the series; I'll
>>> have to introduce a new format specifier instead.
>>
>> Or not.
>>
>> I don't know whether or not the dma_addr_t really needs a
>> fixed 18 byte output length for 64 bit uses.
>>
>> I think always using a cast for dma_addr_t addresses like:
>>
>> printk("dma_addr_t: %#llx\n", (u64)addr);
>>
>> would probably work just fine.
>
> Sigh. Any color would do. I just want to get rid of the mostly-bogus
> warnings that makes it harder to spot real problems, I really don't
> care how they're resolved.
>
> None of the affected platforms today use 64-bit DMA anyway, so casting
> down to u32 is equally acceptable. I'll repost with that instead.
Casting to u64 and using %llx is preferred for this throughout the kernel,
not u32.
That way you would never have to 'fix' those when those platforms use
64-bit DMA (this is where you say that they never will :).
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpu: host1x: use %pa to print dma_addr_t
On Mon, Sep 16, 2013 at 8:54 AM, Joe Perches wrote:
> On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote:
>> On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
>> wrote:
>> > On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote:
>> >> This removes two warnings where dma_addr_t variables were printed using
>> >> %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t:
>> >>
>> >> drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects
>> >> argument of type 'unsigned int', but argument 5 has type 'dma_addr_t'
>> >> drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects
>> >> argument of type 'unsigned int', but argument 3 has type 'dma_addr_t'
>> >
>> > Hi Olof,
>> >
>> > I can't reproduce this. Does this perhaps depend on some other patch?
>> > When I enable LPAE I do see similar warnings in drivers/iommu/tegra-*.c
>> > and those can indeed be fixed using an equivalent patch.
>>
>> You need to enable LPAE on a platform that also selects
>> ARCH_DMA_ADDR_T_64BIT, I don't think tegra does. If you do it with
>> multi_v7_defconfig you'll see them.
>>
>> However, see discussion on another of the emails in the series; I'll
>> have to introduce a new format specifier instead.
>
> Or not.
>
> I don't know whether or not the dma_addr_t really needs a
> fixed 18 byte output length for 64 bit uses.
>
> I think always using a cast for dma_addr_t addresses like:
>
> printk("dma_addr_t: %#llx\n", (u64)addr);
>
> would probably work just fine.
Sigh. Any color would do. I just want to get rid of the mostly-bogus
warnings that makes it harder to spot real problems, I really don't
care how they're resolved.
None of the affected platforms today use 64-bit DMA anyway, so casting
down to u32 is equally acceptable. I'll repost with that instead.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rwsem: add rwsem_is_contended
On Mon, Sep 16, 2013 at 04:05:47PM -0700, Andrew Morton wrote: > On Fri, 30 Aug 2013 10:14:01 -0400 Josef Bacik wrote: > > > Btrfs uses an rwsem to control access to its extent tree. Threads will > > hold a > > read lock on this rwsem while they scan the extent tree, and if > > need_resched() > > they will drop the lock and schedule. The transaction commit needs to take > > a > > write lock for this rwsem for a very short period to switch out the commit > > roots. If there are a lot of threads doing this caching operation we can > > starve > > out the committers which slows everybody out. To address this we want to > > add > > this functionality to see if our rwsem has anybody waiting to take a write > > lock > > so we can drop it and schedule for a bit to allow the commit to continue. > > Thanks, > > > > This sounds rather nasty and hacky. Rather then working around a > locking shortcoming in a caller it would be better to fix/enhance the > core locking code. What would such a change need to do? > > Presently rwsem waiters are fifo-queued, are they not? So the commit > thread will eventually get that lock. Apparently that's not working > adequately for you but I don't fully understand what it is about these > dynamics which is causing observable problems. > So the problem is not that its normal lock starvation, it's more our particular use case that is causing the starvation. We can have lots of people holding readers and simply never give them up for long periods of time, which is why we need this is_contended helper so we know to drop things and let the committer through. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/7] improve memcg oom killer robustness v2
On Mon, Sep 16, 2013 at 10:52:46PM +0200, azurIt wrote: > > CC: "Johannes Weiner" , "Andrew Morton" > > , "David Rientjes" , > > "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro" > > , linux...@kvack.org, > > cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, > > linux-kernel@vger.kernel.org > >On Mon 16-09-13 17:05:43, azurIt wrote: > >> > CC: "Johannes Weiner" , "Andrew Morton" > >> > , "David Rientjes" , > >> > "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro" > >> > , linux...@kvack.org, > >> > cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, > >> > linux-kernel@vger.kernel.org > >> >On Mon 16-09-13 16:13:16, azurIt wrote: > >> >[...] > >> >> >You can use sysrq+l via serial console to see tasks hogging the CPU or > >> >> >sysrq+t to see all the existing tasks. > >> >> > >> >> > >> >> Doesn't work here, it just prints 'l' resp. 't'. > >> > > >> >I am using telnet for accessing my serial consoles exported by > >> >the multiplicator or KVM and it can send sysrq via ctrl+t (Send > >> >Break). Check your serial console setup. > >> > >> > >> > >> I'm using Raritan KVM and i created keyboard macro 'sysrq + l' resp. > >> 'sysrq + t'. I'm also unable to use it on my local PC. Maybe it needs > >> to be enabled somehow? > > > >Probably yes. echo 1 > /proc/sys/kernel/sysrq should enable all sysrq > >commands. You can select also some of them (have a look at > >Documentation/sysrq.txt for more information) > > > Now it happens again and i was just looking on the server's > htop. I'm sure that this time it was only one process (apache) > running under user account (not root). It was taking about 100% CPU > (about 100% of one core). I was able to kill it by hand inside htop > but everything was very slow, server load was immediately on > 500. I'm sure it must be related to that Johannes kernel patches > because i'm also using i/o throttling in cgroups via Block IO > controller so users are unable to create such a huge I/O. I will try > to take stacks of processes but i'm not able to identify the > problematic process so i will have to take them from *all* apache > processes while killing them. It would be fantastic if you could capture those stacks. sysrq+t captures ALL of them in one go and drops them into your syslog. /proc//stack for individual tasks works too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: palmas: Remove wrong comment for the equation calculating num_voltages
On Thu, Sep 12, 2013 at 09:38:12AM +0800, Axel Lin wrote: > Current equation on the comment is wrong. > For linear mapping starting from 0, the equation is (maxV-minV)/stepV + 1. > Since the linear mapping for PALMAS is not all starting from 0, the equation > on the comment is not useful and misleading. Thus remove it. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] dvb: fix potential format string leak
On Mon, 2013-09-16 at 16:37 -0700, Kees Cook wrote:
> Make sure that a format string cannot accidentally leak into the printk
> buffer.
[]
> diff --git a/drivers/media/dvb-frontends/dib9000.c
> b/drivers/media/dvb-frontends/dib9000.c
[]
> @@ -649,7 +649,7 @@ static int dib9000_risc_debug_buf(struct dib9000_state
> *state, u16 * data, u8 si
> b[2 * (size - 2) - 1] = '\0'; /* Bullet proof the buffer */
> if (*b == '~') {
> b++;
> - dprintk(b);
> + dprintk("%s", b);
> } else
> dprintk("RISC%d: %d.%04d %s", state->fe_id, ts / 1, ts %
> 1, *b ? b : "");
> return 1;
This looks odd.
Perhaps this should be:
if (*b == '~')
b++;
dprintk("etc...);
It'd be nice to fix the typo too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: blackfin: Add missing break statement to bf6xx
On Sat, Sep 14, 2013 at 02:20:37AM +0300, Valentin Ilie wrote: > SNDRV_PCM_FORMAT_S8 isn't supposed to fall through to SNDRV_PCM_FORMAT_S16_LE > > Signed-off-by: Valentin Ilie Applied, thanks. signature.asc Description: Digital signature
Re: "memory" binding issues
On Mon, Sep 16, 2013 at 4:47 PM, Benjamin Herrenschmidt wrote: > On Mon, 2013-09-16 at 15:48 -0700, Olof Johansson wrote: >> > A node that has a "reg" property should have the corresponding unit >> > address. >> >> No, absolutely _NOT_ a requirement. Unit address is only required if >> needed to disambiguate two properties with the same name. >> >> If there are no ambiguities, then leaving off the unit address is much >> preferred. > > I disagree :-) Well, good thing you've got your own arch to litter the device trees with unit specifiers in then. :) > Also this would be only true of our find_node_by_path was capable of > handling it, which it isn't. Thus you end up with generic code looking > for /memory and finding nothing ... Yes, this should be fixed. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: "memory" binding issues
On Mon, 2013-09-16 at 15:48 -0700, Olof Johansson wrote: > > A node that has a "reg" property should have the corresponding unit > > address. > > No, absolutely _NOT_ a requirement. Unit address is only required if > needed to disambiguate two properties with the same name. > > If there are no ambiguities, then leaving off the unit address is much > preferred. I disagree :-) Also this would be only true of our find_node_by_path was capable of handling it, which it isn't. Thus you end up with generic code looking for /memory and finding nothing ... 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: [PATCH 2/4 v2] regulator: add STw481x VMMC driver
On Fri, Sep 13, 2013 at 09:01:15PM +0200, Linus Walleij wrote: > The ST Microelectronics STw481x PMIC used for the Nomadik > has one single software-controlled regulator for VMMC. > This driver registers directly to the compatible string > as there is just one regulator. Applied, thanks. signature.asc Description: Digital signature
RE: [RESEND PATCH v2 1/4] mm/hwpoison: fix traverse hugetlbfs page to avoid printk flood
>>Sorry, I have no meaningful progress on this. Splitting hugepages is not >>a trivial operation, and introduce more complexity on hugetlbfs code. >>I don't hit on any usecase of it rather than memory failure, so I'm not >>sure that it's worth doing now. > > Agreed. ;-) Agreed that huge pages should be split - or that it is not worth splitting them? Actually I wonder how useful huge pages still are - transparent huge pages may give most of the benefits without having to modify applications to use them. Plus the kernel does know how to split them when an error occurs (which I care about more than most people). -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dvb: fix potential format string leak
Make sure that a format string cannot accidentally leak into the printk
buffer.
Signed-off-by: Kees Cook
---
drivers/media/dvb-frontends/dib9000.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/dib9000.c
b/drivers/media/dvb-frontends/dib9000.c
index 6201c59..61b2cfe 100644
--- a/drivers/media/dvb-frontends/dib9000.c
+++ b/drivers/media/dvb-frontends/dib9000.c
@@ -649,7 +649,7 @@ static int dib9000_risc_debug_buf(struct dib9000_state
*state, u16 * data, u8 si
b[2 * (size - 2) - 1] = '\0'; /* Bullet proof the buffer */
if (*b == '~') {
b++;
- dprintk(b);
+ dprintk("%s", b);
} else
dprintk("RISC%d: %d.%04d %s", state->fe_id, ts / 1, ts %
1, *b ? b : "");
return 1;
--
1.7.9.5
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] gpio / ACPI: add support for GPIO operation regions
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Monday, September 16, 2013 4:11 PM
>
> On Mon, Sep 16, 2013 at 01:21:53AM +, Zheng, Lv wrote:
> > > A pseudo device may be created to access the GPIO operation region fields
> > > provided by one GPIO device.
> > > The pseudo device may have other functions to access other GPIO operation
> > > region fields provided by other GPIO devices, or even worse
> to
> > > access other ACPI provided value-adds.
> > > So hierarchically the pseudo device only requires CPU, thus should not be
> > > under the GPIO device, which means the GPIO operation
> regions
> > > have nothing to do with the GPIO devices' ACPI handle.
> >
> > Sorry for the wording.
> > It's better to say the GPIO operation region users haven't strict
> > relationship to the GPIO operation region providers.
> > As the installation is to provide GPIO operation regions to the users, it
> > shouldn't relate to the providers' ACPI handle.
>
> If I understand you correctly you mean that there might be multiple users
> (different devices) for the same GPIO operation region, right?
No, this is not what I meant.
Can one vendor device uses two or more GPIO pins from different GPIO ports?
> That shouldn't be a problem as far as I can tell.
>
> What comes to the hierarchy you refer, I'm not sure if that is a problem
> either (unless I'm missing something). The GPIO can be used anywhere in the
> ASL, it doesn't have to be descendant of the GPIO device. You only need to
> do something like this:
>
> // Assert the GPIO
> Store(1, \_SB.PCI0.SHD3)
>
> In other words, use the fully qualified name.
Yes, which means this line of code can be everywhere in the namespace.
It is not required to be under one particular GPIO device as long as there is
an operation region defined in that scope.
The problem is the installation, the first parameter for
acpi_install_address_space_handler() is a namespace node, the function will
call _REG for all OperationRegions below the scope whose top most node is the
specified node.
The nodes out of this scope are not affected. So if an OperationRegion is
defined out of this scope, problem happens.
> Typically when the GPIO device _REG() is called it sets some variable like
> AVBL to true which is then checked in the code that uses the GPIO:
>
> If (LEqual (\_SB.PCI0.GPO0.AVBL, One))
> {
> Store (Zero, \_SB.PCI0..SHD3)
> }
>
> So if there is no driver, this part of the code is never called.
This can trigger exceptions, which can be used to load the GPIO driver.
This seems to be another topic.
Thanks and best regards
-Lv
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
