Re: [PATCH v8 5/5] dt-bindings: display: imx: add bindings for DCSS
On Wed, Jul 29, 2020 at 03:27:30PM +0200, Guido Günther wrote:
> Hi,
> On Fri, Jul 24, 2020 at 12:07:34PM +0300, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu
> >
> > Add bindings for iMX8MQ Display Controller Subsystem.
> >
> > Signed-off-by: Laurentiu Palcu
> > Reviewed-by: Rob Herring
> > ---
> > .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
> > 1 file changed, 104 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> > b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> > new file mode 100644
> > index ..68e4635e4874
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> > @@ -0,0 +1,104 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright 2019 NXP
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#";
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> > +
> > +title: iMX8MQ Display Controller Subsystem (DCSS)
> > +
> > +maintainers:
> > + - Laurentiu Palcu
> > +
> > +description:
> > +
> > + The DCSS (display controller sub system) is used to source up to three
> > + display buffers, compose them, and drive a display using HDMI 2.0a(with
> > HDCP
> > + 2.2) or MIPI-DSI. The DCSS is intended to support up to 4kp60 displays.
> > HDR10
> > + image processing capabilities are included to provide a solution capable
> > of
> > + driving next generation high dynamic range displays.
> > +
> > +properties:
> > + compatible:
> > +const: nxp,imx8mq-dcss
> > +
> > + reg:
> > +items:
> > + - description: DCSS base address and size, up to IRQ steer start
> > + - description: DCSS BLKCTL base address and size
> > +
> > + interrupts:
> > +items:
> > + - description: Context loader completion and error interrupt
> > + - description: DTG interrupt used to signal context loader trigger
> > time
> > + - description: DTG interrupt for Vblank
> > +
> > + interrupt-names:
> > +items:
> > + - const: ctxld
> > + - const: ctxld_kick
> > + - const: vblank
> > +
> > + clocks:
> > +items:
> > + - description: Display APB clock for all peripheral PIO access
> > interfaces
> > + - description: Display AXI clock needed by DPR, Scaler, RTRAM_CTRL
> > + - description: RTRAM clock
> > + - description: Pixel clock, can be driven either by HDMI phy clock
> > or MIPI
> > + - description: DTRC clock, needed by video decompressor
> > +
> > + clock-names:
> > +items:
> > + - const: apb
> > + - const: axi
> > + - const: rtrm
> > + - const: pix
> > + - const: dtrc
> > +
> > + assigned-clocks:
> > +items:
> > + - description: Phandle and clock specifier of
> > IMX8MQ_CLK_DISP_AXI_ROOT
> > + - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_RTRM
> > + - description: Phandle and clock specifier of either
> > IMX8MQ_VIDEO2_PLL1_REF_SEL or
> > + IMX8MQ_VIDEO_PLL1_REF_SEL
> > +
> > + assigned-clock-parents:
> > +items:
> > + - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
> > + - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
> > + - description: Phandle and clock specifier of IMX8MQ_CLK_27M
> > +
> > + assigned-clock-rates:
> > +items:
> > + - description: Must be 800 MHz
> > + - description: Must be 400 MHz
> > +
> > + port:
> > +type: object
> > +description:
> > + A port node pointing to the input port of a HDMI/DP or MIPI display
> > bridge.
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
>
> it would be nice to
>
> #include
>
> here...
>
> > +dcss: display-controller@32e0 {
> > +compatible = "nxp,imx8mq-dcss";
> > +reg = <0x32e0 0x2d000>, <0x32e2f000 0x1000>;
> > +interrupts = <6>, <8>, <9>;
> > +interrupt-names = "ctxld", "ctxld_kick", "vblank";
> > +interrupt-parent = <&irqsteer>;
> > +clocks = <&clk 248>, <&clk 247>, <&clk 249>,
> > + <&clk 254>,<&clk 122>;
> > +clock-names = "apb", "axi", "rtrm", "pix", "dtrc";
> > +assigned-clocks = <&clk 107>, <&clk 109>, <&clk 266>;
> > +assigned-clock-parents = <&clk 78>, <&clk 78>, <&clk 3>;
>
> so that clock names like IMX8MQ_CLK_DISP_AXI could be used to make this
> even more useful.
That's a good idea. I'll add it in.
Thanks,
laurentiu
>
> Cheers,
> -- Guido
>
> > +assigned-clock-rates = <8>,
> > + <4>;
> > +port {
> > +dcss_out: endpoint {
> > +remote-endpoint = <&hdmi_in>;
> > +};
> > +};
> > +};
> > +
> > --
> > 2.23.0
> >
Re: mmotm 2020-07-27-18-18 uploaded (mm/page_alloc.c)
On Tue, Jul 28, 2020 at 03:31:43PM -0700, Andrew Morton wrote: > On Wed, 29 Jul 2020 08:20:53 +1000 Stephen Rothwell > wrote: > > > Hi Andrew, > > > > On Tue, 28 Jul 2020 14:55:53 -0700 Andrew Morton > > wrote: > > > config CONTIG_ALLOC > > > def_bool (MEMORY_ISOLATION && COMPACTION) || CMA > > > > > > says this is an improper combination. And `make oldconfig' fixes it up. > > > > > > What's happening here? > > > > CONFIG_VIRTIO_MEM selects CONFIG_CONTIG_ALLOC ... > > Argh, select strikes again. > > So I guess VIRTIO_MEM should also select COMPACTION? +Cc the maintainer. -- MST
RE: [PATCH V2 1/2] watchdog: imx7ulp: Strictly follow the sequence for wdog operations
Hi, Guenter
> Subject: Re: [PATCH V2 1/2] watchdog: imx7ulp: Strictly follow the sequence
> for wdog operations
>
> On 7/28/20 9:50 PM, Anson Huang wrote:
> > Hi, Guenter
> >
> >
> >> Subject: Re: [PATCH V2 1/2] watchdog: imx7ulp: Strictly follow the
> >> sequence for wdog operations
> >>
> >> On 7/28/20 7:20 PM, Anson Huang wrote:
> >>> According to reference manual, the i.MX7ULP WDOG's operations should
> >>> follow below sequence:
> >>>
> >>> 1. disable global interrupts;
> >>> 2. unlock the wdog and wait unlock bit set; 3. reconfigure the wdog
> >>> and wait for reconfiguration bit set; 4. enabel global interrupts.
> >>>
> >>> Strictly follow the recommended sequence can make it more robust.
> >>>
> >>> Signed-off-by: Anson Huang
> >>> ---
> >>> Changes since V1:
> >>> - use readl_poll_timeout_atomic() instead of usleep_ranges() since
> >>> IRQ is
> >> disabled.
> >>> ---
> >>> drivers/watchdog/imx7ulp_wdt.c | 29 +
> >>> 1 file changed, 29 insertions(+)
> >>>
> >>> diff --git a/drivers/watchdog/imx7ulp_wdt.c
> >>> b/drivers/watchdog/imx7ulp_wdt.c index 7993c8c..7d2b12e 100644
> >>> --- a/drivers/watchdog/imx7ulp_wdt.c
> >>> +++ b/drivers/watchdog/imx7ulp_wdt.c
> >>> @@ -5,6 +5,7 @@
> >>>
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>> #include
> >>> @@ -36,6 +37,7 @@
> >>> #define DEFAULT_TIMEOUT 60
> >>> #define MAX_TIMEOUT 128
> >>> #define WDOG_CLOCK_RATE 1000
> >>> +#define WDOG_WAIT_TIMEOUT1
> >>>
> >>> static bool nowayout = WATCHDOG_NOWAYOUT;
> >> module_param(nowayout,
> >>> bool, ); @@ -48,17 +50,31 @@ struct imx7ulp_wdt_device {
> >>> struct clk *clk;
> >>> };
> >>>
> >>> +static inline void imx7ulp_wdt_wait(void __iomem *base, u32 mask) {
> >>> + u32 val = readl(base + WDOG_CS);
> >>> +
> >>> + if (!(val & mask))
> >>> + WARN_ON(readl_poll_timeout_atomic(base + WDOG_CS, val,
> >>> + val & mask, 0,
> >>> + WDOG_WAIT_TIMEOUT));
> >>
> >> I am not a friend of WARN_ON, especially in situations like this.
> >> Please explain why this is needed, and why a return of -ETIMEDOUT is
> >> not feasible.
> >
> > OK, I will use return value of -ETIMEOUT and handle it in the caller.
> >
> >>
> >> Also, I do not believe that a 10 milli-second timeout is warranted.
> >> This will need to be backed up by the datasheet.
> >>
> >
> > There is no such info provided in reference manual or datasheet, but I
> > just did an experiment, the unlock window is open in less than 1us
> > after sending unlock command, and ONLY last for ONLY 2~3 us then
> > close, the reconfiguration status bit will be set in less than 1us after
> > register
> write. So what do you recommend for this timeout value? 100mS for safe?
> >
>
> That would be even worse. You say yourself that the window is only open for a
> few microseconds. Now you are suggesting to hold the entire system hostage
> for up to
> 100 mS if the code misses that window for some reason. Based on what you
> said,
> 100 uS might be barely acceptable. 10-20 uS would be reasonable. But not
> 100 mS.
OK, I will use 20us.
Thanks,
Anson
Re: [PATCH 2/3] ARM: l2c: update prefetch bits in L2X0_AUX_CTRL using DT value
On Wed, Jul 29, 2020 at 02:47:32PM +0100, Guillaume Tucker wrote:
> The L310_PREFETCH_CTRL register bits 28 and 29 to enable data and
> instruction prefetch respectively can also be accessed via the
> L2X0_AUX_CTRL register. They appear to be actually wired together in
> hardware between the registers. Changing them in the prefetch
> register only will get undone when restoring the aux control register
> later on. For this reason, set these bits in both registers during
> initialisation according to the DT attributes.
How will that happen?
We write the auxiliary control register before the prefetch control
register, so the prefetch control register will take precedence. See
l2c310_configure() - l2c_configure() writes the auxiliary control
register, and the function writes the prefetch control register later.
I think the real issue is that Exynos has been modifying the prefetch
settings via its machine .aux_mask / .aux_val configuration, and the
opposite is actually true: the prefetch control register values will
overwrite the attempt to modify the auxiliary control values set through
the machine .aux_mask/.aux_val.
>
> Fixes: ec3bd0e68a67 ("ARM: 8391/1: l2c: add options to overwrite prefetching
> behavior")
> Signed-off-by: Guillaume Tucker
> ---
> arch/arm/mm/cache-l2x0.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 12c26eb88afb..43d91bfd2360 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -1249,20 +1249,28 @@ static void __init l2c310_of_parse(const struct
> device_node *np,
>
> ret = of_property_read_u32(np, "prefetch-data", &val);
> if (ret == 0) {
> - if (val)
> + if (val) {
> prefetch |= L310_PREFETCH_CTRL_DATA_PREFETCH;
> - else
> + *aux_val |= L310_PREFETCH_CTRL_DATA_PREFETCH;
> + } else {
> prefetch &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
> + *aux_val &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
> + }
> + *aux_mask &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
> } else if (ret != -EINVAL) {
> pr_err("L2C-310 OF prefetch-data property value is missing\n");
> }
>
> ret = of_property_read_u32(np, "prefetch-instr", &val);
> if (ret == 0) {
> - if (val)
> + if (val) {
> prefetch |= L310_PREFETCH_CTRL_INSTR_PREFETCH;
> - else
> + *aux_val |= L310_PREFETCH_CTRL_INSTR_PREFETCH;
> + } else {
> prefetch &= ~L310_PREFETCH_CTRL_INSTR_PREFETCH;
> + *aux_val &= ~L310_PREFETCH_CTRL_INSTR_PREFETCH;
> + }
> + *aux_mask &= ~L310_PREFETCH_CTRL_INSTR_PREFETCH;
> } else if (ret != -EINVAL) {
> pr_err("L2C-310 OF prefetch-instr property value is missing\n");
> }
> --
> 2.20.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH v2 1/9] dt-bindings: arm: mstar: Add binding details for mstar,pmsleep
On Wed, Jul 29, 2020 at 2:34 PM Daniel Palmer wrote: > > On Wed, 29 Jul 2020 at 21:14, Arnd Bergmann wrote: > > > Does calling it "mstar,pmsleepv7" make more sense? I'm not sure what > > > to call it really. > > > > Use the name of the oldest chip you know that supports it in there, > > such as "mstar,msc313-pmsleep" if this one is specific to msc313. > > That makes sense. I think the original patch got merged to soc/arm/newsoc. > Should I recreate the series or create a new patch to do the corrections? Please send an incremental patch. > Slightly off topic but I'm working on the series for the interrupt controller > and I've just renamed it from mstar,msc313e-intc to mstar,v7intc. > I originally called it msc313e because I only knew of that chip but the > same controller is present at the same place in all of the chips so far. > I guess I should probably rename it to mstar,msc313-intc to keep with > the first chip it appeared in pattern? Yes, correct. If you have multiple chips using this controller, use the name of the oldest chip as the generic identifier and then add a more specific one for each the later chips that also use it, so the driver is able to tell the difference if it ever needs to, something like: (on msc313) compatible = "mstar,msc313-intc"; (on msc314) compatible = "mstar,msc314-intc", "mstar,msc313-intc"; (on msc315) compatible = "mstar,msc315-intc", "mstar,msc313-intc"; Arnd
Re: [PATCH v8 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi Guido, On Wed, Jul 29, 2020 at 03:59:48PM +0200, Guido Günther wrote: > Hi, > On Fri, Jul 24, 2020 at 12:07:29PM +0300, Laurentiu Palcu wrote: > > From: Laurentiu Palcu > > > > Hi, > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > > includes only graphics plane support (no video planes), no HDR10 > > capabilities, > > no graphics decompression (only linear, tiled and super-tiled buffers > > allowed). > > > > Support for the rest of the features will be added incrementally, in > > subsequent > > patches. > > > > The patchset was tested with both HDP driver (in the downstream tree) and > > the upstream > > MIPI-DSI driver (with a couple of patches on top, to make it work > > correctly with DCSS). > > While i could run earlier versions of this series with NWL I'm seeing > only a brief image that then turns black (backlight still on) with this > current version and > the board hangs soon after.(for reference using mxsfb works nicely with > the very same DT on next-20200727). If I do a drm.debug=0x3f i can see > that display output stops around: > > [ 15.394473] imx-dcss 32e0.display-controller: > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=22, > diff=1, hw=0 hw_last=0 > [ 15.397575] device: 'input1': device_add > [ 15.444658] imx-dcss 32e0.display-controller: > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=23, > diff=1, hw=0 hw_last=0 > [ 15.465946] PM: Adding info for No Bus:input1 > [ 15.494842] imx-dcss 32e0.display-controller: > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=24, > diff=1, hw=0 hw_last=0 > [ 15.511694] input: gpio-keys as /devices/platform/gpio-keys/input/input1 > [ 15.545025] imx-dcss 32e0.display-controller: > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=25, > diff=1, hw=0 hw_last=0 > [ 15.557869] device: 'event1': device_add > [ 15.595209] imx-dcss 32e0.display-controller: > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=26, > diff=1, hw=0 hw_last=0 > [ 15.605363] PM: Adding info for No Bus:event1 > [ 15.645394] imx-dcss 32e0.display-controller: > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=27, > diff=1, hw=0 hw_last=0 > [ 19.427039] imx-dcss 32e0.display-controller: [drm:vblank_disable_fn] > disabling vblank on crtc 0 > [ 19.436135] device: 'wakeup6': device_add > [ 19.448202] imx-dcss 32e0.display-controller: > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=28, > diff=0, hw=0 hw_last=0 > > (and there's no further logging from drm from there on). > > Would any the above mentioned patches do anything in that area? The NWL driver is missing at least one fix that is needed for DCSS to work nicely with it. One thing that needs fixed is the polarity. I added a patch for that in our tree... :/ Currently, in NWL upstream, we have adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC); adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC); However DCSS works with: adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC); adjusted->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC); I CCed Robert. He'll work on upstreaming these NWL changes in the following period of time. Thanks, laurentiu > > Cheers, > -- Guido > > > > > Thanks, > > Laurentiu > > > > Changes in v8: > > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed > >out. SRC is not used in DCSS driver; > > * Nothing else changed; > > > > Changes in v7: > > * Added a patch to initialize the connector using the drm_bridge_connector > >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with > >Guido's patch [1] applied and one fix for ADV [2]. Also, some extra > >patches for ADV and NWL were needed, from our downstream tree, which > >will be upstreamed soon by their author; > > * Rest of the patches are untouched; > > > > [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html > > [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html > > > > Changes in v6: > > * Addressed Rob's comment and added "additionalProperties: false" at > >the end of the bindings' properties. However, this change surfaced > >an issue with the assigned-clock* properties not being documented in > >the properties section. Added the descriptions and the bindings patch > >will need another review; > > * Added an entry for DCSS driver in the MAINTAINERS file; > > * Removed the component framework patch altogether; > > > > Changes in v5: > > * Rebased to latest; > > * Took out component framework support and made it a separate patch so > >that people can still test with HDP driver, which makes use of it. > >But the idea is to get rid of it once HDP driver's next versions > >will remove component
Re: (resend) [PATCH [linux-4.14.y]] dm cache: submit writethrough writes in parallel to origin and cache
On Wed, Jul 29 2020 at 7:55am -0400, Greg KH wrote: > On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote: > > On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote: > > > This mail needs to be saent to sta...@vger.kernel.org (now cc'd). > > > > > > Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9 > > > > Now backported, thanks. > > Nope, it broke the build, I need something that actually works :) > OK, I'll defer to John Donnelly to get back with you (and rest of stable@). He is more invested due to SUSE also having this issue. I can put focus to it if John cannot sort this out. Mike
Re: [PATCH v10 4/5] arm64: kdump: fix kdump broken with ZONE_DMA reintroduced
Hi Catalin, On 2020/7/29 19:58, Catalin Marinas wrote: > Hi Chen, > > On Wed, Jul 29, 2020 at 11:52:39AM +0800, chenzhou wrote: >> On 2020/7/28 1:30, Catalin Marinas wrote: >>> Anyway, there are two series solving slightly different issues with >>> kdump reservations: >>> >>> 1. This series which relaxes the crashkernel= allocation to go anywhere >>>in the accessible space while having a dedicated crashkernel=X,low >>>option for ZONE_DMA. >>> >>> 2. Bhupesh's series [1] forcing crashkernel=X allocations only from >>>ZONE_DMA. >>> >>> For RPi4 support, we limited ZONE_DMA allocations to the 1st GB. >>> Existing crashkernel= uses may no longer work, depending on where the >>> allocation falls. Option (2) above is a quick fix assuming that the >>> crashkernel reservation is small enough. What's a typical crashkernel >>> option here? That series is probably more prone to reservation failures. >>> >>> Option (1), i.e. this series, doesn't solve the problem raised by >>> Bhupesh unless one uses the crashkernel=X,low argument. It can actually >>> make it worse even for ZONE_DMA32 since the allocation can go above 4G >>> (assuming that we change the ZONE_DMA configuration to only limit it to >>> 1GB on RPi4). >>> >>> I'm more inclined to keep the crashkernel= behaviour to ZONE_DMA >>> allocations. If this is too small for typical kdump, we can look into >>> expanding ZONE_DMA to 4G on non-RPi4 hardware (we had patches on the >>> list). In addition, if Chen thinks allocations above 4G are still needed >>> or if RPi4 needs a sufficiently large crashkernel=, I'd rather have a >>> ",high" option to explicitly require such access. >> Thanks for your reply and exhaustive explanation. >> >> In our ARM servers, we need to to reserve a large chunk for kdump(512M >> or 1G), there is no enough low memory. So we proposed this patch >> series "support reserving crashkernel above 4G on arm64 kdump" In >> April 2019. > Trying to go through the discussions last year, hopefully things get > clearer. > > So prior to the ZONE_DMA change, you still couldn't reserve 1G in the > first 4GB? It shouldn't be sparsely populated during early boot. Yes, we prior to the ZONE_DMA change, you still couldn't reserve 1G/512M in the first 4GB. The memory reported by the bios may be splitted by some "reserved" entries. Like this: ... 2f126000-2fbf : reserved 2fc0-396a : System RAM 30de8000-30de9fff : reserved 30dec000-30decfff : reserved 30df2000-30df2fff : reserved 30e2-30e4 : reserved 3962-3968 : reserved 396b-3974 : reserved 3975-397a : System RAM 397b-398f : reserved 3990-3990 : System RAM 3990-3990 : reserved ... > >> I introduce parameters "crashkernel=X,[high,low]" as x86_64 does in earlier >> versions. >> Suggested by James, to simplify, we call reserve_crashkernel_low() at the >> beginning of >> reserve_crashkernel() and then relax the arm64_dma32_phys_limit if >> reserve_crashkernel_low() >> allocated something. >> That is, just the parameter "crashkernel=X,low" is ok and i deleted >> "crashkernel=X,high". > The problem I see is that with your patches we diverge from x86 > behaviour (and the arm64 behaviour prior to the ZONE_DMA reduction) as > we now require that crashkernel=X,low is always passed if you want > something in ZONE_DMA (and you do want, otherwise the crashdump kernel > fails to boot). > > My main requirement is that crashkernel=X, without any suffix, still > works which I don't think is guaranteed with your patches (well, > ignoring RPi4 ZONE_DMA). Bhupesh's series is a quick fix but doesn't > solve your large allocation requirements (that may have worked prior to > the ZONE_DMA change). The main purpose of this series is to solve the large allocation requirements. Before the DMA_ZONE, both the original crashkernel=X and large allocation with my patches work well. With the DMA_ZONE, both the original crashkernel=X and large allocation with my patches may fail to boot. Both need to think about the DMA_ZONE. > >> After the ZONE_DMA introduced in December 2019, the issue occurred as >> you said above. In fact, we didn't have RPi4 machine. > You don't even need to have a RPi4 machine, ZONE_DMA has been set to 1GB > unconditionally. And while we could move it back to 4GB on non-RPi4 > hardware, I'd rather have a solution that fixes kdump for RPi4 as well. > >> Originally, i suggested to fix this based on this patch series and >> used the dedicated option. >> >> According to your clarify, for typical kdump, there are other >> solutions. In this case, "keep the crashkernel= behaviour to ZONE_DMA >> allocations" looks much better. >> >> How about like this: >> 1. For ZONE_DMA issue, use Bhupesh's solution, keep the crashkernel= >>behaviour to ZONE_DMA allocations. >> 2. For this patch series, make the reserve_crashkernel_low() to >>ZONE_DMA allocations. > So you mean rebasing your series on top of Bhupesh's? I guess you c
Re: [RFC PATCH 0/6] decrease unnecessary gap due to pmem kmem alignment
On Wed, Jul 29, 2020 at 03:03:04PM +0200, David Hildenbrand wrote: > On 29.07.20 15:00, Mike Rapoport wrote: > > On Wed, Jul 29, 2020 at 11:35:20AM +0200, David Hildenbrand wrote: > >>> > >>> There is still large gap with ARM64_64K_PAGES, though. > >>> > >>> As for SPARSEMEM without VMEMMAP, are there actual benefits to use it? > >> > >> I was asking myself the same question a while ago and didn't really find > >> a compelling one. > > > > Memory overhead for VMEMMAP is larger, especially for arm64 that knows > > how to free empty parts of the memory map with "classic" SPARSEMEM. > > You mean the hole punching within section memmap? (which is why their > pfn_valid() implementation is special) Yes, arm (both 32 and 64) do this. And for smaller systems with a few memory banks this is very reasonable to trade slight (if any) slowdown in pfn_valid() for several megs of memory. > (I do wonder why that shouldn't work with VMEMMAP, or is it simply not > implemented?) It's not implemented. There was a patch [1] recently to implement this. [1] https://lore.kernel.org/lkml/20200721073203.107862-1-liwei...@huawei.com/ > -- > Thanks, > > David / dhildenb > -- Sincerely yours, Mike.
Re: [PATCH V2 1/2] watchdog: imx7ulp: Strictly follow the sequence for wdog operations
On 7/28/20 9:50 PM, Anson Huang wrote:
> Hi, Guenter
>
>
>> Subject: Re: [PATCH V2 1/2] watchdog: imx7ulp: Strictly follow the sequence
>> for wdog operations
>>
>> On 7/28/20 7:20 PM, Anson Huang wrote:
>>> According to reference manual, the i.MX7ULP WDOG's operations should
>>> follow below sequence:
>>>
>>> 1. disable global interrupts;
>>> 2. unlock the wdog and wait unlock bit set; 3. reconfigure the wdog
>>> and wait for reconfiguration bit set; 4. enabel global interrupts.
>>>
>>> Strictly follow the recommended sequence can make it more robust.
>>>
>>> Signed-off-by: Anson Huang
>>> ---
>>> Changes since V1:
>>> - use readl_poll_timeout_atomic() instead of usleep_ranges() since IRQ
>>> is
>> disabled.
>>> ---
>>> drivers/watchdog/imx7ulp_wdt.c | 29 +
>>> 1 file changed, 29 insertions(+)
>>>
>>> diff --git a/drivers/watchdog/imx7ulp_wdt.c
>>> b/drivers/watchdog/imx7ulp_wdt.c index 7993c8c..7d2b12e 100644
>>> --- a/drivers/watchdog/imx7ulp_wdt.c
>>> +++ b/drivers/watchdog/imx7ulp_wdt.c
>>> @@ -5,6 +5,7 @@
>>>
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -36,6 +37,7 @@
>>> #define DEFAULT_TIMEOUT60
>>> #define MAX_TIMEOUT128
>>> #define WDOG_CLOCK_RATE1000
>>> +#define WDOG_WAIT_TIMEOUT 1
>>>
>>> static bool nowayout = WATCHDOG_NOWAYOUT;
>> module_param(nowayout,
>>> bool, ); @@ -48,17 +50,31 @@ struct imx7ulp_wdt_device {
>>> struct clk *clk;
>>> };
>>>
>>> +static inline void imx7ulp_wdt_wait(void __iomem *base, u32 mask) {
>>> + u32 val = readl(base + WDOG_CS);
>>> +
>>> + if (!(val & mask))
>>> + WARN_ON(readl_poll_timeout_atomic(base + WDOG_CS, val,
>>> + val & mask, 0,
>>> + WDOG_WAIT_TIMEOUT));
>>
>> I am not a friend of WARN_ON, especially in situations like this.
>> Please explain why this is needed, and why a return of -ETIMEDOUT is not
>> feasible.
>
> OK, I will use return value of -ETIMEOUT and handle it in the caller.
>
>>
>> Also, I do not believe that a 10 milli-second timeout is warranted.
>> This will need to be backed up by the datasheet.
>>
>
> There is no such info provided in reference manual or datasheet, but I just
> did
> an experiment, the unlock window is open in less than 1us after sending
> unlock command,
> and ONLY last for ONLY 2~3 us then close, the reconfiguration status bit will
> be set in less than
> 1us after register write. So what do you recommend for this timeout value?
> 100mS for safe?
>
That would be even worse. You say yourself that the window is only open for a
few
microseconds. Now you are suggesting to hold the entire system hostage for up to
100 mS if the code misses that window for some reason. Based on what you said,
100 uS might be barely acceptable. 10-20 uS would be reasonable. But not 100 mS.
Guenter
Re: [PATCH] scsi: sd: add runtime pm to open / release
On 28.07.20 22:02, Alan Stern wrote: > On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger wrote: >> Hi Alan, >> >> Any API cleanup is of course welcome. I just wanted to remind you that >> the underlying problem: broken block device runtime pm. Your initial >> proposed fix "almost" did it and mounting works but during file access, >> it still just looks like a runtime_resume is missing somewhere. > > Well, I have tested that proposed fix several times, and on my system > it's working perfectly. When I stop accessing a drive it autosuspends, > and when I access it again it gets resumed and works -- as you would > expect. that's weird. when I mount, everything looks good, "sda1". But as soon as I cd to the mountpoint and do "ls" (on another SD card "ls" works but actual file reading leads to the exact same errors), I get: [ 77.474632] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s [ 77.474647] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current] [ 77.474655] sd 0:0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0 [ 77.474667] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 60 40 00 00 01 00 [ 77.474678] blk_update_request: I/O error, dev sda, sector 24640 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 77.485836] sd 0:0:0:0: [sda] tag#0 device offline or changed [ 77.491628] blk_update_request: I/O error, dev sda, sector 24641 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 77.502275] sd 0:0:0:0: [sda] tag#0 device offline or changed [ 77.508051] blk_update_request: I/O error, dev sda, sector 24642 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 77.518651] sd 0:0:0:0: [sda] tag#0 device offline or changed (...) [ 77.947653] sd 0:0:0:0: [sda] tag#0 device offline or changed [ 77.953434] FAT-fs (sda1): Directory bread(block 16448) failed [ 77.959333] sd 0:0:0:0: [sda] tag#0 device offline or changed [ 77.965118] FAT-fs (sda1): Directory bread(block 16449) failed [ 77.971014] sd 0:0:0:0: [sda] tag#0 device offline or changed [ 77.976802] FAT-fs (sda1): Directory bread(block 16450) failed [ 77.982698] sd 0:0:0:0: [sda] tag#0 device offline or changed (...) [ 78.384929] FAT-fs (sda1): Filesystem has been set read-only [ 103.070973] sd 0:0:0:0: [sda] tag#0 device offline or changed [ 103.076751] print_req_error: 118 callbacks suppressed [ 103.076760] blk_update_request: I/O error, dev sda, sector 9748 op 0x1:(WRITE) flags 0x10 phys_seg 1 prio class 0 [ 103.087428] Buffer I/O error on dev sda1, logical block 1556, lost async page write [ 103.095309] sd 0:0:0:0: [sda] tag#0 device offline or changed [ 103.101123] blk_update_request: I/O error, dev sda, sector 17162 op 0x1:(WRITE) flags 0x10 phys_seg 1 prio class 0 [ 103.111883] Buffer I/O error on dev sda1, logical block 8970, lost async page write > >> As we need to have that working at some point, I might look into it, but >> someone who has experience in the block layer can surely do it more >> efficiently. > > I suspect that any problems you still face are caused by something else. > I then formatted sda1 to ext2 (on the runtime suspend system testing your patch) and that seems to have worked! Again accessing the mountpoint then yield the very same "device offline or changed" errors. What kind of device are you testing? You should be easily able to reproduce this using an "sd" device. The problems must lie in the different other drivers we use I guess. martin > Alan Stern >
make oldconfig (Re: mmotm 2020-07-27-18-18 uploaded (mm/page_alloc.c))
On Tue, Jul 28, 2020 at 06:44:19PM -0700, Andrew Morton wrote: > On Tue, 28 Jul 2020 15:39:21 -0700 Randy Dunlap wrote: > > > On 7/28/20 2:55 PM, Andrew Morton wrote: > > > On Tue, 28 Jul 2020 05:33:58 -0700 Randy Dunlap > > > wrote: > > > > > >> On 7/27/20 6:19 PM, Andrew Morton wrote: > > >>> The mm-of-the-moment snapshot 2020-07-27-18-18 has been uploaded to > > >>> > > >>>http://www.ozlabs.org/~akpm/mmotm/ > > > > > > >> on x86_64: > > >> > > >> ../mm/page_alloc.c:8355:48: warning: ‘struct compact_control’ declared > > >> inside parameter list will not be visible outside of this definition or > > >> declaration > > >> static int __alloc_contig_migrate_range(struct compact_control *cc, > > >> ^~~ > > > > > > As is usually the case with your reports, I can't figure out how to > > > reproduce it. I copy then .config, run `make oldconfig' (need to hit > > > enter a zillion times because the .config is whacky) If it helps with Enter: yes '' | make oldconfig Works 99.99% of the time except when there is numeric/string option without default value.
RE: [PATCH v18 3/3] Input: new da7280 haptic driver
Hello Dmitry and Uwe,
Wednesday, July 29, 2020 3:37 PM, Dmitry Torokhov wrote:
> On Wed, Jul 29, 2020 at 11:59:40AM +0900, Roy Im wrote:
> > Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple
> > mode and integrated waveform memory and wideband support.
> > It communicates via an I2C bus to the device.
>
> A few questions/suggestions...
>
> >
> > Reviewed-by: Jes Sorensen .
> >
> > Signed-off-by: Roy Im
> >
> > ---
> > v18:
> > - Corrected comments in Kconfig
> > - Updated to preferred style for multi line comments in c file.
> > v17:
> > - fixed an issue.
> > v16:
> > - Corrected some code and updated description in Kconfig.
> > v15:
> > - Removed some defines and updated some comments.
> > v14:
> > - Updated pwm related code, alignments and comments.
> > v13:
> > - Updated some conditions in pwm function and alignments.
> > v12: No changes.
> > v11:
> > - Updated the pwm related code, comments and typo.
> > v10:
> > - Updated the pwm related function and added some comments.
> > v9:
> > - Removed the header file and put the definitions into the c file.
> > - Updated the pwm code and error logs with %pE
>
> I believe the %pE is to format an escaped buffer, you probably want to %pe
> (lowercase) to print errors. I am also not quite sure
> if we want to use it in cases when we have non-pointer error, or we should
> stick with %d as most of the kernel does.
Right, it should be %pe as you and Uwe said, Uwe suggested %pe to understand
easier.. do you still prefer to stick with %d?
>
> ...
> > +
> > +/* DA7280_ACTUATOR3 (Address 0x0e) */
> > +#define DA7280_IMAX_MASK (31 << 0)
>
> We have GENMASK(h,l) macro in include/linux/bits.h that could be used here
> and in other mask definitions.
I will do.
>
> > +
> > + bool legacy;
> > + struct delayed_work work_duration;
> > + struct work_struct work_playback;
> > + struct work_struct work_setgain;
>
> How do we ensure that all these works do not clash with each other?
> As far as I can see we could have the "duration" work executing
> simultaneously with playback...
You are right, I will use use cancel_delayed_work_sync()/duration and
cancel_work_sync()/playback before scheduling playback work. And same as for
the work_setgain. For setgain, there is no problem to run this regardless the
playback.
>
> > +static int da7280_haptics_playback(struct input_dev *dev,
> > + int effect_id, int val)
> > +{
> > + struct da7280_haptic *haptics = input_get_drvdata(dev);
> > +
> > + if (!haptics->op_mode) {
> > + dev_warn(haptics->dev,
> > +"Any effects are not uploaded yet\n");
>
> "No effects have been uploaded"?
Ok, let me update so.
>
> > + return -EPERM;
>
> I'd say EINVAL.
OK
>
> > +static DEVICE_ATTR_RW(ps_seq_id);
> > +static DEVICE_ATTR_RW(ps_seq_loop);
> > +static DEVICE_ATTR_RW(gpi_seq_id0);
> > +static DEVICE_ATTR_RW(gpi_seq_id1);
> > +static DEVICE_ATTR_RW(gpi_seq_id2);
> > +static DEVICE_ATTR_WO(patterns);
>
> Should this be a binary attribute instead of having string parsing in the
> kernel?
I have carefully reviewed my driver again with your comments, now the upload
effect covers this attributes, so I would like to remove them and add some code
more for gpi_seq_idx update.
Thanks for your comments.
Kinds regards,
Roy
Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output
Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to avoid pixels getting stuck in the (unflushable) FIFO between > the HVS and the PV, we need to add some delay after disabling the PV output > and before disabling the HDMI controller. 20ms seems to be good enough so > let's use that. > > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c > index d0b326e1df0a..7b178d67187f 100644 > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc, > ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1); > WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); > > + mdelay(20); mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we not msleep instead? Dave > + > if (vc4_encoder->post_crtc_disable) > vc4_encoder->post_crtc_disable(encoder); > > -- > git-series 0.9.1
Re: [PATCH v1 1/2] kernel: time: export sched_clock_register function
Hi Freddy,
On 28/07/2020 12:16, Freddy Hsin wrote:
> export sched_clock_register function, because the Mediatek timer
> loadable module depends on this function
That is not a sufficient reason to ask for exporting a symbol from the
core framework.
It is the second patch asking for exporting the symbols because of GKI.
If we want to do this move, it is important to understand what that will
imply by doing the changes as a whole:
- Identify the routines which will need EXPORT_SYMBOL_GPL
- Show it is safe to use them with what that implies as module. eg.
What about cpuidle drivers using the broadcast timers?
- As pointed by Thomas, TIMER_OF_DECLARE must be adapted to handle the
module cases
The conversion to all modules is not as straightforward as just
exporting a symbol and the changes must be provided with the proof the
impact has been studied and anticipated.
> Signed-off-by: Freddy Hsin
> ---
> kernel/time/sched_clock.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> index fa3f800..e1d5afe 100644
> --- a/kernel/time/sched_clock.c
> +++ b/kernel/time/sched_clock.c
> @@ -239,6 +239,7 @@ static enum hrtimer_restart sched_clock_poll(struct
> hrtimer *hrt)
>
> pr_debug("Registered %pS as sched_clock source\n", read);
> }
> +EXPORT_SYMBOL(sched_clock_register);
--
Facebook |
Twitter |
Re: linux-next: build failure after merge of the vhost tree
On Tue, Jul 28, 2020 at 06:11:32PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vhost tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/virtio/virtio_vdpa.c:17:
> include/linux/vdpa.h:43:21: error: expected ':', ',', ';', '}' or
> '__attribute__' before '.' token
>43 | bool features_valid.
> | ^
>
> Caused by commit
>
> fee8fe6bd8cc ("vdpa: make sure set_features in invoked for legacy")
>
> I have used the vhost tree from next-20200727 for today.
Sorry by bad, pushed to a wrong tag.
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH v1 4/6] mm/page_isolation: cleanup set_migratetype_isolate()
On 06/30/20 at 04:26pm, David Hildenbrand wrote:
> Let's clean it up a bit, simplifying error handling and getting rid of
> the label.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Michael S. Tsirkin
> Signed-off-by: David Hildenbrand
> ---
> mm/page_isolation.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index 02a01bff6b219..5f869bef23fa4 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -17,12 +17,9 @@
>
> static int set_migratetype_isolate(struct page *page, int migratetype, int
> isol_flags)
> {
> - struct page *unmovable = NULL;
> - struct zone *zone;
> + struct zone *zone = page_zone(page);
> + struct page *unmovable;
> unsigned long flags;
> - int ret = -EBUSY;
> -
> - zone = page_zone(page);
>
> spin_lock_irqsave(&zone->lock, flags);
>
> @@ -51,21 +48,20 @@ static int set_migratetype_isolate(struct page *page, int
> migratetype, int isol_
> NULL);
>
> __mod_zone_freepage_state(zone, -nr_pages, mt);
> - ret = 0;
> + spin_unlock_irqrestore(&zone->lock, flags);
> + drain_all_pages(zone);
> + return 0;
> }
>
> -out:
> spin_unlock_irqrestore(&zone->lock, flags);
> - if (!ret) {
> - drain_all_pages(zone);
> - } else if ((isol_flags & REPORT_FAILURE) && unmovable)
> + if (isol_flags & REPORT_FAILURE)
> /*
>* printk() with zone->lock held will likely trigger a
>* lockdep splat, so defer it here.
>*/
> dump_page(unmovable, "unmovable page");
>
> - return ret;
> + return -EBUSY;
Reviewed-by: Baoquan He
[PATCH 3/3] docs: cgroup: No special handling of unpopulated memcgs
The current kernel doesn't handle unpopulated cgroups any special
regarding reclaim protection. Furthermore, this wasn't a case even when
this was introduced in
bf8d5d52ffe89 ("memcg: introduce memory.min")
Drop the incorrect documentation. (Implementation taking into account
the inner-node constraint may be added later.)
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v2.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index 47f9f056e66f..3d62922c4499 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1123,9 +1123,6 @@ PAGE_SIZE multiple when read back.
Putting more memory than generally available under this
protection is discouraged and may lead to constant OOMs.
- If a memory cgroup is not populated with processes,
- its memory.min is ignored.
-
memory.low
A read-write single value file which exists on non-root
cgroups. The default is "0".
--
2.27.0
Re: [PATCH v1 3/6] mm/page_isolation: drop WARN_ON_ONCE() in set_migratetype_isolate()
On 07/29/20 at 03:37pm, David Hildenbrand wrote:
> On 29.07.20 15:24, Baoquan He wrote:
> > On 06/30/20 at 04:26pm, David Hildenbrand wrote:
> >> Inside has_unmovable_pages(), we have a comment describing how unmovable
> >> data could end up in ZONE_MOVABLE - via "movable_core". Also, besides
> > ~~~ 'movablecore'
> >> checking if the first page in the pageblock is reserved, we don't
> >> perform any further checks in case of ZONE_MOVABLE.
> >>
> >> In case of memory offlining, we set REPORT_FAILURE, properly
> >> dump_page() the page and handle the error gracefully.
> >> alloc_contig_pages() users currently never allocate from ZONE_MOVABLE.
> >> E.g., hugetlb uses alloc_contig_pages() for the allocation of gigantic
> >> pages only, which will never end up on the MOVABLE zone
> >> (see htlb_alloc_mask()).
> >>
> >> Cc: Andrew Morton
> >> Cc: Michal Hocko
> >> Cc: Michael S. Tsirkin
> >> Signed-off-by: David Hildenbrand
> >> ---
> >> mm/page_isolation.c | 16 ++--
> >> 1 file changed, 6 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> >> index 553b49a34cf71..02a01bff6b219 100644
> >> --- a/mm/page_isolation.c
> >> +++ b/mm/page_isolation.c
> >> @@ -58,16 +58,12 @@ static int set_migratetype_isolate(struct page *page,
> >> int migratetype, int isol_
> >>spin_unlock_irqrestore(&zone->lock, flags);
> >>if (!ret) {
> >>drain_all_pages(zone);
> >> - } else {
> >> - WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
> >> -
> >> - if ((isol_flags & REPORT_FAILURE) && unmovable)
> >> - /*
> >> - * printk() with zone->lock held will likely trigger a
> >> - * lockdep splat, so defer it here.
> >> - */
> >> - dump_page(unmovable, "unmovable page");
> >> - }
> >> + } else if ((isol_flags & REPORT_FAILURE) && unmovable)
> >
> > This else if branch should be enclosed in brace?
> >
>
> Not necessarily. And it will be gone in the next patch in this series :)
OK, that's fine. Thanks.
[PATCH 0/3] Memory reclaim documentation fixes
Hi, I think the reclaim target is a concept that is not just an implementation detail and hence it should be documented how it applies to protection configuration (the first patch). Second patch is a "best practice" bit of information, it may be squashed with the first one. The last patch just makes docs indefinite until the idea is implemented. Michal Koutný (3): docs: cgroup: Explain reclaim protection target docs: cgroup: Note about sibling relative reclaim protection docs: cgroup: No special handling of unpopulated memcgs Documentation/admin-guide/cgroup-v2.rst | 31 - 1 file changed, 25 insertions(+), 6 deletions(-) -- 2.27.0
[PATCH 1/3] docs: cgroup: Explain reclaim protection target
Signed-off-by: Michal Koutný --- Documentation/admin-guide/cgroup-v2.rst | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index d09471aa7443..94bdff4f9e09 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -47,7 +47,8 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst
[PATCH 2/3] docs: cgroup: Note about sibling relative reclaim protection
Signed-off-by: Michal Koutný --- Documentation/admin-guide/cgroup-v2.rst | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 94bdff4f9e09..47f9f056e66f 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1467,6 +1467,10 @@ targets ancestors of A, the effective protection of B is capped by the protection value configured for A (and any other intermediate ancestors between A and the target). +To express indifference about relative sibling protection, it is suggested to +use memory_recursiveprot. Configuring all descendants of a parent with finite +protection to "max" works but it may unnecessarily skew memory.events:low +field. Memory Ownership -- 2.27.0
[PATCH 5/5] seqcount: More consistent seqprop names
Attempt uniformity and brevity.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/seqlock.h | 52
1 file changed, 26 insertions(+), 26 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -247,9 +247,9 @@ SEQCOUNT_LOCKTYPE(struct ww_mutex, ww_mu
__seqprop_case((s), mutex, prop), \
__seqprop_case((s), ww_mutex, prop))
-#define __to_seqcount_t(s) __seqprop(s, ptr)
-#define __associated_lock_exists_and_is_preemptible(s) __seqprop(s,
preemptible)
-#define __assert_write_section_is_protected(s) __seqprop(s, assert)
+#define __seqcount_ptr(s) __seqprop(s, ptr)
+#define __seqcount_lock_preemptible(s) __seqprop(s, preemptible)
+#define __seqcount_assert_lock_held(s) __seqprop(s, assert)
/**
* __read_seqcount_begin() - begin a seqcount_t read section w/o barrier
@@ -266,7 +266,7 @@ SEQCOUNT_LOCKTYPE(struct ww_mutex, ww_mu
* Return: count to be passed to read_seqcount_retry()
*/
#define __read_seqcount_begin(s) \
- __read_seqcount_t_begin(__to_seqcount_t(s))
+ __read_seqcount_t_begin(__seqcount_ptr(s))
static inline unsigned __read_seqcount_t_begin(const seqcount_t *s)
{
@@ -289,7 +289,7 @@ static inline unsigned __read_seqcount_t
* Return: count to be passed to read_seqcount_retry()
*/
#define raw_read_seqcount_begin(s) \
- raw_read_seqcount_t_begin(__to_seqcount_t(s))
+ raw_read_seqcount_t_begin(__seqcount_ptr(s))
static inline unsigned raw_read_seqcount_t_begin(const seqcount_t *s)
{
@@ -305,7 +305,7 @@ static inline unsigned raw_read_seqcount
* Return: count to be passed to read_seqcount_retry()
*/
#define read_seqcount_begin(s) \
- read_seqcount_t_begin(__to_seqcount_t(s))
+ read_seqcount_t_begin(__seqcount_ptr(s))
static inline unsigned read_seqcount_t_begin(const seqcount_t *s)
{
@@ -325,7 +325,7 @@ static inline unsigned read_seqcount_t_b
* Return: count to be passed to read_seqcount_retry()
*/
#define raw_read_seqcount(s) \
- raw_read_seqcount_t(__to_seqcount_t(s))
+ raw_read_seqcount_t(__seqcount_ptr(s))
static inline unsigned raw_read_seqcount_t(const seqcount_t *s)
{
@@ -353,7 +353,7 @@ static inline unsigned raw_read_seqcount
* Return: count to be passed to read_seqcount_retry()
*/
#define raw_seqcount_begin(s) \
- raw_seqcount_t_begin(__to_seqcount_t(s))
+ raw_seqcount_t_begin(__seqcount_ptr(s))
static inline unsigned raw_seqcount_t_begin(const seqcount_t *s)
{
@@ -380,7 +380,7 @@ static inline unsigned raw_seqcount_t_be
* Return: true if a read section retry is required, else false
*/
#define __read_seqcount_retry(s, start)
\
- __read_seqcount_t_retry(__to_seqcount_t(s), start)
+ __read_seqcount_t_retry(__seqcount_ptr(s), start)
static inline int __read_seqcount_t_retry(const seqcount_t *s, unsigned start)
{
@@ -400,7 +400,7 @@ static inline int __read_seqcount_t_retr
* Return: true if a read section retry is required, else false
*/
#define read_seqcount_retry(s, start) \
- read_seqcount_t_retry(__to_seqcount_t(s), start)
+ read_seqcount_t_retry(__seqcount_ptr(s), start)
static inline int read_seqcount_t_retry(const seqcount_t *s, unsigned start)
{
@@ -414,10 +414,10 @@ static inline int read_seqcount_t_retry(
*/
#define raw_write_seqcount_begin(s)\
do { \
- if (__associated_lock_exists_and_is_preemptible(s)) \
+ if (__seqcount_lock_preemptible(s)) \
preempt_disable(); \
\
- raw_write_seqcount_t_begin(__to_seqcount_t(s)); \
+ raw_write_seqcount_t_begin(__seqcount_ptr(s)); \
} while (0)
static inline void raw_write_seqcount_t_begin(seqcount_t *s)
@@ -433,9 +433,9 @@ static inline void raw_write_seqcount_t_
*/
#define raw_write_seqcount_end(s) \
do { \
- raw_write_seqcount_t_end(__to_seqcount_t(s)); \
+ raw_write_seqcount_t_end(__seqcount_ptr(s));\
\
- if (__associated_lock_exists_and_is_preemptible(s)) \
+ if (__seqcount_lock_preemptible(s)) \
preempt_enable();
[PATCH 4/5] seqcount: Compress SEQCNT_LOCKNAME_ZERO()
Less is more.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/seqlock.h | 63 +---
1 file changed, 18 insertions(+), 45 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -138,51 +138,6 @@ static inline void seqcount_lockdep_read
#define __SEQ_LOCK(expr)
#endif
-#define SEQCOUNT_LOCKTYPE_ZERO(seq_name, assoc_lock) { \
- .seqcount = SEQCNT_ZERO(seq_name.seqcount), \
- __SEQ_LOCK(.lock= (assoc_lock)) \
-}
-
-/**
- * SEQCNT_SPINLOCK_ZERO - static initializer for seqcount_spinlock_t
- * @name: Name of the seqcount_spinlock_t instance
- * @lock: Pointer to the associated spinlock
- */
-#define SEQCNT_SPINLOCK_ZERO(name, lock) \
- SEQCOUNT_LOCKTYPE_ZERO(name, lock)
-
-/**
- * SEQCNT_RAW_SPINLOCK_ZERO - static initializer for seqcount_raw_spinlock_t
- * @name: Name of the seqcount_raw_spinlock_t instance
- * @lock: Pointer to the associated raw_spinlock
- */
-#define SEQCNT_RAW_SPINLOCK_ZERO(name, lock) \
- SEQCOUNT_LOCKTYPE_ZERO(name, lock)
-
-/**
- * SEQCNT_RWLOCK_ZERO - static initializer for seqcount_rwlock_t
- * @name: Name of the seqcount_rwlock_t instance
- * @lock: Pointer to the associated rwlock
- */
-#define SEQCNT_RWLOCK_ZERO(name, lock) \
- SEQCOUNT_LOCKTYPE_ZERO(name, lock)
-
-/**
- * SEQCNT_MUTEX_ZERO - static initializer for seqcount_mutex_t
- * @name: Name of the seqcount_mutex_t instance
- * @lock: Pointer to the associated mutex
- */
-#define SEQCNT_MUTEX_ZERO(name, lock) \
- SEQCOUNT_LOCKTYPE_ZERO(name, lock)
-
-/**
- * SEQCNT_WW_MUTEX_ZERO - static initializer for seqcount_ww_mutex_t
- * @name: Name of the seqcount_ww_mutex_t instance
- * @lock: Pointer to the associated ww_mutex
- */
-#define SEQCNT_WW_MUTEX_ZERO(name, lock) \
- SEQCOUNT_LOCKTYPE_ZERO(name, lock)
-
/**
* typedef seqcount_LOCKNAME_t - sequence counter with LOCKTYPR associated
* @seqcount: The real sequence counter
@@ -263,6 +218,24 @@ SEQCOUNT_LOCKTYPE(rwlock_t,rwlock,
fa
SEQCOUNT_LOCKTYPE(struct mutex,mutex, true, s->lock)
SEQCOUNT_LOCKTYPE(struct ww_mutex, ww_mutex, true, &s->lock->base)
+/**
+ * SEQCNT_LOCKNAME_ZERO - static initializer for seqcount_LOCKNAME_t
+ * @name: Name of the seqcount_LOCKNAME_t instance
+ * @lock: Pointer to the associated LOCKTYPE
+ */
+
+#define SEQCOUNT_LOCKTYPE_ZERO(seq_name, assoc_lock) { \
+ .seqcount = SEQCNT_ZERO(seq_name.seqcount), \
+ __SEQ_LOCK(.lock= (assoc_lock)) \
+}
+
+#define SEQCNT_SPINLOCK_ZERO(name, lock) SEQCOUNT_LOCKTYPE_ZERO(name,
lock)
+#define SEQCNT_RAW_SPINLOCK_ZERO(name, lock) SEQCOUNT_LOCKTYPE_ZERO(name,
lock)
+#define SEQCNT_RWLOCK_ZERO(name, lock) SEQCOUNT_LOCKTYPE_ZERO(name,
lock)
+#define SEQCNT_MUTEX_ZERO(name, lock) SEQCOUNT_LOCKTYPE_ZERO(name,
lock)
+#define SEQCNT_WW_MUTEX_ZERO(name, lock) SEQCOUNT_LOCKTYPE_ZERO(name,
lock)
+
+
#define __seqprop_case(s, lockname, prop) \
seqcount_##lockname##_t: __seqcount_##lockname##_##prop((void *)(s))
[PATCH 0/5] seqlock: Cleanups
Hi, These are some minor cleanups that go on top of darwi's seqlock patches: https://lkml.kernel.org/r/20200720155530.1173732-1-a.darw...@linutronix.de It's mostly trimming excessive manual repetition and a few naming niggles. The series has been exposed to 0-day for a while now, so I'm going to push the lot out to tip/locking/core. [ 0day found a Sparse bug in it's _Generic() implementation that has since been fixed by Luc ] --- seqlock.h | 292 +- 1 file changed, 84 insertions(+), 208 deletions(-)
[PATCH 3/5] seqlock: Fold seqcount_LOCKNAME_init() definition
Manual repetition is boring and error prone.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/seqlock.h | 61 +++-
1 file changed, 14 insertions(+), 47 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -143,12 +143,6 @@ static inline void seqcount_lockdep_read
__SEQ_LOCK(.lock= (assoc_lock)) \
}
-#define seqcount_locktype_init(s, assoc_lock) \
-do { \
- seqcount_init(&(s)->seqcount); \
- __SEQ_LOCK((s)->lock = (assoc_lock)); \
-} while (0)
-
/**
* SEQCNT_SPINLOCK_ZERO - static initializer for seqcount_spinlock_t
* @name: Name of the seqcount_spinlock_t instance
@@ -158,14 +152,6 @@ do {
\
SEQCOUNT_LOCKTYPE_ZERO(name, lock)
/**
- * seqcount_spinlock_init - runtime initializer for seqcount_spinlock_t
- * @s: Pointer to the seqcount_spinlock_t instance
- * @lock: Pointer to the associated spinlock
- */
-#define seqcount_spinlock_init(s, lock)
\
- seqcount_locktype_init(s, lock)
-
-/**
* SEQCNT_RAW_SPINLOCK_ZERO - static initializer for seqcount_raw_spinlock_t
* @name: Name of the seqcount_raw_spinlock_t instance
* @lock: Pointer to the associated raw_spinlock
@@ -174,14 +160,6 @@ do {
\
SEQCOUNT_LOCKTYPE_ZERO(name, lock)
/**
- * seqcount_raw_spinlock_init - runtime initializer for seqcount_raw_spinlock_t
- * @s: Pointer to the seqcount_raw_spinlock_t instance
- * @lock: Pointer to the associated raw_spinlock
- */
-#define seqcount_raw_spinlock_init(s, lock)\
- seqcount_locktype_init(s, lock)
-
-/**
* SEQCNT_RWLOCK_ZERO - static initializer for seqcount_rwlock_t
* @name: Name of the seqcount_rwlock_t instance
* @lock: Pointer to the associated rwlock
@@ -190,14 +168,6 @@ do {
\
SEQCOUNT_LOCKTYPE_ZERO(name, lock)
/**
- * seqcount_rwlock_init - runtime initializer for seqcount_rwlock_t
- * @s: Pointer to the seqcount_rwlock_t instance
- * @lock: Pointer to the associated rwlock
- */
-#define seqcount_rwlock_init(s, lock) \
- seqcount_locktype_init(s, lock)
-
-/**
* SEQCNT_MUTEX_ZERO - static initializer for seqcount_mutex_t
* @name: Name of the seqcount_mutex_t instance
* @lock: Pointer to the associated mutex
@@ -206,14 +176,6 @@ do {
\
SEQCOUNT_LOCKTYPE_ZERO(name, lock)
/**
- * seqcount_mutex_init - runtime initializer for seqcount_mutex_t
- * @s: Pointer to the seqcount_mutex_t instance
- * @lock: Pointer to the associated mutex
- */
-#define seqcount_mutex_init(s, lock) \
- seqcount_locktype_init(s, lock)
-
-/**
* SEQCNT_WW_MUTEX_ZERO - static initializer for seqcount_ww_mutex_t
* @name: Name of the seqcount_ww_mutex_t instance
* @lock: Pointer to the associated ww_mutex
@@ -222,15 +184,7 @@ do {
\
SEQCOUNT_LOCKTYPE_ZERO(name, lock)
/**
- * seqcount_ww_mutex_init - runtime initializer for seqcount_ww_mutex_t
- * @s: Pointer to the seqcount_ww_mutex_t instance
- * @lock: Pointer to the associated ww_mutex
- */
-#define seqcount_ww_mutex_init(s, lock)
\
- seqcount_locktype_init(s, lock)
-
-/**
- * typedef seqcount_LOCKNAME_t - sequence counter with spinlock associated
+ * typedef seqcount_LOCKNAME_t - sequence counter with LOCKTYPR associated
* @seqcount: The real sequence counter
* @lock: Pointer to the associated spinlock
*
@@ -240,6 +194,12 @@ do {
\
* that the write side critical section is properly serialized.
*/
+/**
+ * seqcount_LOCKNAME_init() - runtime initializer for seqcount_LOCKNAME_t
+ * @s: Pointer to the seqcount_LOCKNAME_t instance
+ * @lock: Pointer to the associated LOCKTYPE
+ */
+
/*
* SEQCOUNT_LOCKTYPE() - Instantiate seqcount_LOCKNAME_t and helpers
* @locktype: actual typename
@@ -253,6 +213,13 @@ typedef struct seqcount_##lockname {
__SEQ_LOCK(locktype *lock); \
} seqcount_##lockname##_t; \
\
+static __always_inline void\
+seqcount_##lockname##_init(se
[PATCH 1/5] seqlock: s/__SEQ_LOCKDEP/__SEQ_LOCK/g
__SEQ_LOCKDEP() is an expression gate for the
seqcount_LOCKNAME_t::lock member. Rename it to be about the member,
not the gate condition.
Later (PREEMPT_RT) patches will make the member available for !LOCKDEP
configs.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/seqlock.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -133,20 +133,20 @@ static inline void seqcount_lockdep_read
*/
#ifdef CONFIG_LOCKDEP
-#define __SEQ_LOCKDEP(expr)expr
+#define __SEQ_LOCK(expr) expr
#else
-#define __SEQ_LOCKDEP(expr)
+#define __SEQ_LOCK(expr)
#endif
#define SEQCOUNT_LOCKTYPE_ZERO(seq_name, assoc_lock) { \
.seqcount = SEQCNT_ZERO(seq_name.seqcount), \
- __SEQ_LOCKDEP(.lock = (assoc_lock)) \
+ __SEQ_LOCK(.lock= (assoc_lock)) \
}
#define seqcount_locktype_init(s, assoc_lock) \
do { \
seqcount_init(&(s)->seqcount); \
- __SEQ_LOCKDEP((s)->lock = (assoc_lock));\
+ __SEQ_LOCK((s)->lock = (assoc_lock)); \
} while (0)
/**
@@ -161,7 +161,7 @@ do {
\
*/
typedef struct seqcount_spinlock {
seqcount_t seqcount;
- __SEQ_LOCKDEP(spinlock_t*lock);
+ __SEQ_LOCK(spinlock_t *lock);
} seqcount_spinlock_t;
/**
@@ -192,7 +192,7 @@ typedef struct seqcount_spinlock {
*/
typedef struct seqcount_raw_spinlock {
seqcount_t seqcount;
- __SEQ_LOCKDEP(raw_spinlock_t*lock);
+ __SEQ_LOCK(raw_spinlock_t *lock);
} seqcount_raw_spinlock_t;
/**
@@ -223,7 +223,7 @@ typedef struct seqcount_raw_spinlock {
*/
typedef struct seqcount_rwlock {
seqcount_t seqcount;
- __SEQ_LOCKDEP(rwlock_t *lock);
+ __SEQ_LOCK(rwlock_t *lock);
} seqcount_rwlock_t;
/**
@@ -257,7 +257,7 @@ typedef struct seqcount_rwlock {
*/
typedef struct seqcount_mutex {
seqcount_t seqcount;
- __SEQ_LOCKDEP(struct mutex *lock);
+ __SEQ_LOCK(struct mutex *lock);
} seqcount_mutex_t;
/**
@@ -291,7 +291,7 @@ typedef struct seqcount_mutex {
*/
typedef struct seqcount_ww_mutex {
seqcount_t seqcount;
- __SEQ_LOCKDEP(struct ww_mutex *lock);
+ __SEQ_LOCK(struct ww_mutex *lock);
} seqcount_ww_mutex_t;
/**
@@ -329,7 +329,7 @@ __seqcount_##locktype##_preemptible(seqc
static inline void \
__seqcount_##locktype##_assert(seqcount_##locktype##_t *s) \
{ \
- __SEQ_LOCKDEP(lockdep_assert_held(lockmember)); \
+ __SEQ_LOCK(lockdep_assert_held(lockmember));\
}
/*
[PATCH 2/5] seqlock: Fold seqcount_LOCKNAME_t definition
Manual repetition is boring and error prone.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/seqlock.h | 140 +---
1 file changed, 38 insertions(+), 102 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -150,21 +150,6 @@ do {
\
} while (0)
/**
- * typedef seqcount_spinlock_t - sequence counter with spinlock associated
- * @seqcount: The real sequence counter
- * @lock: Pointer to the associated spinlock
- *
- * A plain sequence counter with external writer synchronization by a
- * spinlock. The spinlock is associated to the sequence count in the
- * static initializer or init function. This enables lockdep to validate
- * that the write side critical section is properly serialized.
- */
-typedef struct seqcount_spinlock {
- seqcount_t seqcount;
- __SEQ_LOCK(spinlock_t *lock);
-} seqcount_spinlock_t;
-
-/**
* SEQCNT_SPINLOCK_ZERO - static initializer for seqcount_spinlock_t
* @name: Name of the seqcount_spinlock_t instance
* @lock: Pointer to the associated spinlock
@@ -181,21 +166,6 @@ typedef struct seqcount_spinlock {
seqcount_locktype_init(s, lock)
/**
- * typedef seqcount_raw_spinlock_t - sequence count with raw spinlock
associated
- * @seqcount: The real sequence counter
- * @lock: Pointer to the associated raw spinlock
- *
- * A plain sequence counter with external writer synchronization by a
- * raw spinlock. The raw spinlock is associated to the sequence count in
- * the static initializer or init function. This enables lockdep to
- * validate that the write side critical section is properly serialized.
- */
-typedef struct seqcount_raw_spinlock {
- seqcount_t seqcount;
- __SEQ_LOCK(raw_spinlock_t *lock);
-} seqcount_raw_spinlock_t;
-
-/**
* SEQCNT_RAW_SPINLOCK_ZERO - static initializer for seqcount_raw_spinlock_t
* @name: Name of the seqcount_raw_spinlock_t instance
* @lock: Pointer to the associated raw_spinlock
@@ -212,21 +182,6 @@ typedef struct seqcount_raw_spinlock {
seqcount_locktype_init(s, lock)
/**
- * typedef seqcount_rwlock_t - sequence count with rwlock associated
- * @seqcount: The real sequence counter
- * @lock: Pointer to the associated rwlock
- *
- * A plain sequence counter with external writer synchronization by a
- * rwlock. The rwlock is associated to the sequence count in the static
- * initializer or init function. This enables lockdep to validate that
- * the write side critical section is properly serialized.
- */
-typedef struct seqcount_rwlock {
- seqcount_t seqcount;
- __SEQ_LOCK(rwlock_t *lock);
-} seqcount_rwlock_t;
-
-/**
* SEQCNT_RWLOCK_ZERO - static initializer for seqcount_rwlock_t
* @name: Name of the seqcount_rwlock_t instance
* @lock: Pointer to the associated rwlock
@@ -243,24 +198,6 @@ typedef struct seqcount_rwlock {
seqcount_locktype_init(s, lock)
/**
- * typedef seqcount_mutex_t - sequence count with mutex associated
- * @seqcount: The real sequence counter
- * @lock: Pointer to the associated mutex
- *
- * A plain sequence counter with external writer synchronization by a
- * mutex. The mutex is associated to the sequence counter in the static
- * initializer or init function. This enables lockdep to validate that
- * the write side critical section is properly serialized.
- *
- * The write side API functions write_seqcount_begin()/end() automatically
- * disable and enable preemption when used with seqcount_mutex_t.
- */
-typedef struct seqcount_mutex {
- seqcount_t seqcount;
- __SEQ_LOCK(struct mutex *lock);
-} seqcount_mutex_t;
-
-/**
* SEQCNT_MUTEX_ZERO - static initializer for seqcount_mutex_t
* @name: Name of the seqcount_mutex_t instance
* @lock: Pointer to the associated mutex
@@ -277,24 +214,6 @@ typedef struct seqcount_mutex {
seqcount_locktype_init(s, lock)
/**
- * typedef seqcount_ww_mutex_t - sequence count with ww_mutex associated
- * @seqcount: The real sequence counter
- * @lock: Pointer to the associated ww_mutex
- *
- * A plain sequence counter with external writer synchronization by a
- * ww_mutex. The ww_mutex is associated to the sequence counter in the static
- * initializer or init function. This enables lockdep to validate that
- * the write side critical section is properly serialized.
- *
- * The write side API functions write_seqcount_begin()/end() automatically
- * disable and enable preemption when used with seqcount_ww_mutex_t.
- */
-typedef struct seqcount_ww_mutex {
- seqcount_t seqcount;
- __SEQ_LOCK(struct ww_mutex *lock);
-} seqcount_ww_mutex_t;
-
-/**
* SEQCNT_WW_MUTEX_ZERO - static initializer for seqcount_ww_mutex_t
* @name: Name of the seqcount_ww_mutex_t instance
* @lock: Pointer to the associated ww_
Re: [SchedulerWakeupLatency] Skip energy aware task placement
On Thursday 23 Jul 2020 at 11:31:39 (+0200), Dietmar Eggemann wrote: > The search for the most energy-efficient CPU over the Performance > Domains (PDs) by consulting the Energy Model (EM), i.e. the estimation > on how much energy a PD consumes if the task migrates to one of its > CPUs, adds a certain amount of latency to task placement. > > For some tasks this extra latency could be too high. A good example here > are the Android display pipeline tasks, UIThread and RenderThread. They > have to be placed on idle CPUs with a faster wakeup mechanism than the > energy aware wakeup path (A) to guarantee the smallest amount of dropped > or delayed frames (a.k.a. jank). > > In Linux kernel mainline there is currently no mechanism for latency > sensitive tasks to allow that the energy aware wakeup path (A) is > skipped and the fast path (B) taken instead. FWIW, Android has indeed been using a similar concept for many years (the 'prefer-idle' flag you mentioned below) and that proved to be critical to meet UI requirements on a number of devices. So +1 to have this use case covered as part of the latency-nice work. <...> > > K) Task-Group tuning: which knobs are required > > Currently Android uses the 'prefer idle' mechanism only on task-groups > and not on individual tasks. To add a little bit of context here, Android uses cgroups extensively for task classification. The tasks of any currently used application are placed in a cgroup based on their 'role'. For instance, all tasks that belong to the currently visible application are classified as 'top-app', and are grouped in a cgroup with 'prefer-idle' set (+ other attributes, e.g. uclamp). The other tasks in the system are usually placed in other cgroups (e.g. 'background'), with 'prefer-idle' cleared. When the user switches from one app to the other, their roles are swapped. At this point userspace needs to move all tasks of an app from one cgroup to another, to reflect the change in role. But interestingly, all tasks of the app belong to the same process, so userspace only needs to write the PID of the parent task to the new cgroup to move all of them at once. (Note: we're also experimenting having cgroups per-app rather than per-role, and to change the cgroup parameters instead of migrating between groups, but that doesn't change the conclusion below). So, having 'only' a per-task API for latency-nice may not be sufficient to cover the Android use-case, as that would force userspace to iterate over all the tasks in an app when switching between roles, and that will come at a certain cost (currently unknown). However, that will need to be confirmed experimentally, and starting 'simple' with a per-task API would definitely be a step in the right direction. Thanks, Quentin
Re: [PATCH v8 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi, On Fri, Jul 24, 2020 at 12:07:29PM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > Hi, > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > includes only graphics plane support (no video planes), no HDR10 capabilities, > no graphics decompression (only linear, tiled and super-tiled buffers > allowed). > > Support for the rest of the features will be added incrementally, in > subsequent > patches. > > The patchset was tested with both HDP driver (in the downstream tree) and the > upstream > MIPI-DSI driver (with a couple of patches on top, to make it work > correctly with DCSS). While i could run earlier versions of this series with NWL I'm seeing only a brief image that then turns black (backlight still on) with this current version and the board hangs soon after.(for reference using mxsfb works nicely with the very same DT on next-20200727). If I do a drm.debug=0x3f i can see that display output stops around: [ 15.394473] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=22, diff=1, hw=0 hw_last=0 [ 15.397575] device: 'input1': device_add [ 15.444658] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=23, diff=1, hw=0 hw_last=0 [ 15.465946] PM: Adding info for No Bus:input1 [ 15.494842] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=24, diff=1, hw=0 hw_last=0 [ 15.511694] input: gpio-keys as /devices/platform/gpio-keys/input/input1 [ 15.545025] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=25, diff=1, hw=0 hw_last=0 [ 15.557869] device: 'event1': device_add [ 15.595209] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=26, diff=1, hw=0 hw_last=0 [ 15.605363] PM: Adding info for No Bus:event1 [ 15.645394] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=27, diff=1, hw=0 hw_last=0 [ 19.427039] imx-dcss 32e0.display-controller: [drm:vblank_disable_fn] disabling vblank on crtc 0 [ 19.436135] device: 'wakeup6': device_add [ 19.448202] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=28, diff=0, hw=0 hw_last=0 (and there's no further logging from drm from there on). Would any the above mentioned patches do anything in that area? Cheers, -- Guido > > Thanks, > Laurentiu > > Changes in v8: > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed >out. SRC is not used in DCSS driver; > * Nothing else changed; > > Changes in v7: > * Added a patch to initialize the connector using the drm_bridge_connector >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with >Guido's patch [1] applied and one fix for ADV [2]. Also, some extra >patches for ADV and NWL were needed, from our downstream tree, which >will be upstreamed soon by their author; > * Rest of the patches are untouched; > > [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html > [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html > > Changes in v6: > * Addressed Rob's comment and added "additionalProperties: false" at >the end of the bindings' properties. However, this change surfaced >an issue with the assigned-clock* properties not being documented in >the properties section. Added the descriptions and the bindings patch >will need another review; > * Added an entry for DCSS driver in the MAINTAINERS file; > * Removed the component framework patch altogether; > > Changes in v5: > * Rebased to latest; > * Took out component framework support and made it a separate patch so >that people can still test with HDP driver, which makes use of it. >But the idea is to get rid of it once HDP driver's next versions >will remove component framework as well; > * Slight improvement to modesetting: avoid cutting off the pixel clock >if the new mode and the old one are equal. Also, in this case, is >not necessary to wait for DTG to shut off. This would allow to switch >from 8b RGB to 12b YUV422, for example, with no interruptions (at least >from DCSS point of view); > * Do not fire off CTXLD when going to suspend, unless it still has >entries that need to be committed to DCSS; > * Addressed Rob's comments on bindings; > > Changes in v4: > * Addressed Lucas and Philipp's comments: >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; >* Removed usage of devm_ functions since I'm already doing all the > clean-up in the submodules_deinit(); >* Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); >* Removed en_completion variable from dcss_crtc since this was > introduced mainl
[PATCH] arm, arm64: Fix selection of CONFIG_SCHED_THERMAL_PRESSURE
Qian reported that the current setup forgoes the Kconfig dependencies and
results in warnings such as:
WARNING: unmet direct dependencies detected for SCHED_THERMAL_PRESSURE
Depends on [n]: SMP [=y] && CPU_FREQ_THERMAL [=n]
Selected by [y]:
- ARM64 [=y]
Revert commit
e17ae7fea871 ("arm, arm64: Select CONFIG_SCHED_THERMAL_PRESSURE")
and re-implement it by making the option default to 'y' for arm64 and arm,
which respects Kconfig dependencies (i.e. will remain 'n' if
CPU_FREQ_THERMAL=n).
Fixes: e17ae7fea871 ("arm, arm64: Select CONFIG_SCHED_THERMAL_PRESSURE")
Reported-by: Qian Cai
Signed-off-by: Valentin Schneider
---
arch/arm/Kconfig | 1 -
arch/arm64/Kconfig | 1 -
init/Kconfig | 2 ++
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6cd0f9f086f6..809e8047d669 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -47,7 +47,6 @@ config ARM
select EDAC_ATOMIC_SCRUB
select GENERIC_ALLOCATOR
select GENERIC_ARCH_TOPOLOGY if ARM_CPU_TOPOLOGY
- select SCHED_THERMAL_PRESSURE if ARM_CPU_TOPOLOGY
select GENERIC_ATOMIC64 if CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_CPU_AUTOPROBE
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 2d4abbc9f8d0..baffe8b66da2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -192,7 +192,6 @@ config ARM64
select PCI_SYSCALL if PCI
select POWER_RESET
select POWER_SUPPLY
- select SCHED_THERMAL_PRESSURE
select SPARSE_IRQ
select SWIOTLB
select SYSCTL_EXCEPTION_TRACE
diff --git a/init/Kconfig b/init/Kconfig
index 37b089f87804..f2244892d7a8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -493,6 +493,8 @@ config HAVE_SCHED_AVG_IRQ
config SCHED_THERMAL_PRESSURE
bool
+ default y if ARM && ARM_CPU_TOPOLOGY
+ default y if ARM64
depends on SMP
depends on CPU_FREQ_THERMAL
help
--
2.27.0
[PATCH] staging: atomisp: move null check to earlier point
`find_gmin_subdev` function that returns a pointer to `struct
gmin_subdev` can return NULL.
In `gmin_v2p8_ctrl` there's a call to this function but the possibility
of a NULL was not checked before its being dereferenced. ie:
```
/* Acquired here v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
int value;
/* v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
ret = gpio_request(gs->v2p8_gpio, "camera_v2p8");
if (!ret)
ret = gpio_direction_output(gs->v2p8_gpio, 0);
if (ret)
pr_err("V2P8 GPIO initialization failed\n");
}
```
I have moved the NULL check before deref point.
Caught-by: Coverity Static Analyzer CID 1465536
Signed-off-by: Cengiz Can
---
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..8e9c5016f299 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,11 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
int ret;
int value;
+ if (!gs) {
+ pr_err("Unable to find gmin subdevice\n");
+ return -EINVAL;
+ }
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +886,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
pr_err("V2P8 GPIO initialization failed\n");
}
- if (!gs || gs->v2p8_on == on)
+ if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
--
2.27.0
[PATCH] perf tests: Fix test 68 zstd compression for s390
Commit 5aa98879efe7 ("s390/cpum_sf: prohibit callchain data collection")
prohibits call graph sampling for hardware events on s390. The
information recorded is out of context and does not match.
On s390 this commit now breaks test case 68
Zstd perf.data compression/decompression.
Therefore omit call graph sampling on s390 in this test.
Output before:
[root@t35lp46 perf]# ./perf test -Fv 68
68: Zstd perf.data compression/decompression :
--- start ---
Collecting compressed record file:
Error:
cycles: PMU Hardware doesn't support sampling/overflow-interrupts.
Try 'perf stat'
end
Zstd perf.data compression/decompression: FAILED!
[root@t35lp46 perf]#
Output after:
[root@t35lp46 perf]# ./perf test -Fv 68
68: Zstd perf.data compression/decompression :
--- start ---
Collecting compressed record file:
500+0 records in
500+0 records out
256000 bytes (256 kB, 250 KiB) copied, 0.00615638 s, 41.6 MB/s
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.004 MB /tmp/perf.data.X3M,
compressed (original 0.002 MB, ratio is 3.609) ]
Checking compressed events stats:
# compressed : Zstd, level = 1, ratio = 4
COMPRESSED events: 1
2ELIFREPh end
Zstd perf.data compression/decompression: Ok
[root@t35lp46 perf]#
Signed-off-by: Thomas Richter
Reviewed-by: Sumanth Korikkar
---
tools/perf/tests/shell/record+zstd_comp_decomp.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/shell/record+zstd_comp_decomp.sh
b/tools/perf/tests/shell/record+zstd_comp_decomp.sh
index 63a91ec473bb..045723b3d992 100755
--- a/tools/perf/tests/shell/record+zstd_comp_decomp.sh
+++ b/tools/perf/tests/shell/record+zstd_comp_decomp.sh
@@ -12,7 +12,8 @@ skip_if_no_z_record() {
collect_z_record() {
echo "Collecting compressed record file:"
- $perf_tool record -o $trace_file -g -z -F 5000 -- \
+ [[ "$(uname -m)" != s390x ]] && gflag='-g'
+ $perf_tool record -o $trace_file $gflag -z -F 5000 -- \
dd count=500 if=/dev/urandom of=/dev/null
}
--
2.26.2
Re: [PATCH 1/2] dt-bindings: tlv320adcx140: Add GPO config and drive config
On Tue, 28 Jul 2020 11:08:32 -0500, Dan Murphy wrote: > Add properties for configuring the General Purpose Outputs (GPO). The > GPOs. There are 2 settings for each GPO, configuration and the output drive > type. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] dt-bindings: tlv320adcx140: Add GPO config and drive config commit: 63b0383f3c1c32d7ff958bf3a58c58a84cbd7450 [2/2] ASoC: tlv320adcx140: Add GPO configuration and drive output config commit: 6617cff6a05e7e7a679499cb1d5cd2d3bc6390c3 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: tlv320adcx140: Fix various style errors and warnings
On Tue, 28 Jul 2020 11:43:39 -0500, Dan Murphy wrote: > Fix white space issues and remove else case where it was not needed. > Convert "static const char *" to "static const char * const" Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: tlv320adcx140: Fix various style errors and warnings commit: e5448d7ec656e6c5ed59f4adfc979742fd1f9b07 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [RFC PATCH 3/5] mm: introduce VM_EXEC_KEEP
On Mon, Jul 27, 2020 at 10:11:25AM -0700, Anthony Yznaga wrote:
> A vma with the VM_EXEC_KEEP flag is preserved across exec. For anonymous
> vmas only. For safety, overlap with fixed address VMAs created in the new
> mm during exec (e.g. the stack and elf load segments) is not permitted and
> will cause the exec to fail.
> (We are studying how to guarantee there are no conflicts. Comments welcome.)
>
> Signed-off-by: Steve Sistare
> Signed-off-by: Anthony Yznaga
> ---
> arch/x86/Kconfig | 1 +
> fs/exec.c | 20
> include/linux/mm.h | 5 +
> kernel/fork.c | 2 +-
> mm/mmap.c | 47 +++
> 5 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 883da0abf779..fc36eb2f45c0 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -30,6 +30,7 @@ config X86_64
> select MODULES_USE_ELF_RELA
> select NEED_DMA_MAP_STATE
> select SWIOTLB
> + select ARCH_USES_HIGH_VMA_FLAGS
>
> config FORCE_DYNAMIC_FTRACE
> def_bool y
> diff --git a/fs/exec.c b/fs/exec.c
> index 262112e5f9f8..1de09c4eef00 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1069,6 +1069,20 @@ ssize_t read_code(struct file *file, unsigned long
> addr, loff_t pos, size_t len)
> EXPORT_SYMBOL(read_code);
> #endif
>
> +static int vma_dup_some(struct mm_struct *old_mm, struct mm_struct *new_mm)
> +{
> + struct vm_area_struct *vma;
> + int ret;
> +
> + for (vma = old_mm->mmap; vma; vma = vma->vm_next)
> + if (vma->vm_flags & VM_EXEC_KEEP) {
> + ret = vma_dup(vma, new_mm);
> + if (ret)
> + return ret;
> + }
> + return 0;
> +}
> +
> /*
> * Maps the mm_struct mm into the current task struct.
> * On success, this function returns with the mutex
> @@ -1104,6 +1118,12 @@ static int exec_mmap(struct mm_struct *mm)
> mutex_unlock(&tsk->signal->exec_update_mutex);
> return -EINTR;
> }
> + ret = vma_dup_some(old_mm, mm);
> + if (ret) {
> + mmap_read_unlock(old_mm);
> + mutex_unlock(&tsk->signal->exec_update_mutex);
> + return ret;
> + }
> }
>
> task_lock(tsk);
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index dc7b87310c10..1c538ba77f33 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -295,11 +295,15 @@ int overcommit_kbytes_handler(struct ctl_table *, int,
> void *, size_t *,
> #define VM_HIGH_ARCH_BIT_2 34 /* bit only usable on 64-bit
> architectures */
> #define VM_HIGH_ARCH_BIT_3 35 /* bit only usable on 64-bit
> architectures */
> #define VM_HIGH_ARCH_BIT_4 36 /* bit only usable on 64-bit
> architectures */
> +#define VM_HIGH_ARCH_BIT_5 37 /* bit only usable on 64-bit
> architectures */
> #define VM_HIGH_ARCH_0 BIT(VM_HIGH_ARCH_BIT_0)
> #define VM_HIGH_ARCH_1 BIT(VM_HIGH_ARCH_BIT_1)
> #define VM_HIGH_ARCH_2 BIT(VM_HIGH_ARCH_BIT_2)
> #define VM_HIGH_ARCH_3 BIT(VM_HIGH_ARCH_BIT_3)
> #define VM_HIGH_ARCH_4 BIT(VM_HIGH_ARCH_BIT_4)
> +#define VM_EXEC_KEEP BIT(VM_HIGH_ARCH_BIT_5) /* preserve VMA across exec */
> +#else
> +#define VM_EXEC_KEEP VM_NONE
> #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */
>
> #ifdef CONFIG_ARCH_HAS_PKEYS
> @@ -2534,6 +2538,7 @@ extern struct vm_area_struct *copy_vma(struct
> vm_area_struct **,
> unsigned long addr, unsigned long len, pgoff_t pgoff,
> bool *need_rmap_locks);
> extern void exit_mmap(struct mm_struct *);
> +extern int vma_dup(struct vm_area_struct *vma, struct mm_struct *mm);
>
> static inline int check_data_rlimit(unsigned long rlim,
> unsigned long new,
> diff --git a/kernel/fork.c b/kernel/fork.c
> index efc5493203ae..15ead613714f 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -564,7 +564,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> tmp->anon_vma = NULL;
> } else if (anon_vma_fork(tmp, mpnt))
> goto fail_nomem_anon_vma_fork;
> - tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT);
> + tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT | VM_EXEC_KEEP);
> file = tmp->vm_file;
> if (file) {
> struct inode *inode = file_inode(file);
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 59a4682ebf3f..be2ff53743c3 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3279,6 +3279,53 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
> **vmap,
> return NULL;
> }
>
> +int vma_dup(struct vm_area_struct *old_vma, struct mm_struct *mm)
> +{
> + unsigned long npages;
> + struct mm_struct *old_mm = old_vma->vm_mm;
> + struct vm_area_struct *vma;
> + int re
Re: linux plumbers + clang + s390 virtualized testing
On Thu, Jul 16, 2020 at 01:28:40PM +0200, Heiko Carstens wrote: > Hi Nick, > > > We were very excited to see your patches going by for enabling Clang > > support for s390. Since then, we've added s390 builds to our > > continuous integration setup. > > > > We've been running into a few issues with doing virtualized boot tests > > of our kernels on s390. > > > > I was curious if you'll both be attending Linux plumbers conf? If we > > carve out time for an s390+clang talk, would this be of interest to > > you to attend? > > I will not attend, however cannot speak for Vasily. He will have to > answer as soon as he returns - besides that enabling Clang support for > s390 was done by Vasily anyway :) I will attend and it would surely be interesting to me and other s390 folks. Your efforts are greatly appreciated! BTW I believe basic Clang support for s390 came earlier in 5.2 with a lot of efforts from Arnd Bergmann. My part was fixing recent breakages and bugging our s390 clang team (which did all the great work) to get kernel specific features support in clang 10 and 11 to reach features parity with gcc. And eventually doing few adjustments so that features which came with clang 10 and 11 are working smoothly. That is s390 "asm goto" support and specific compiler flags for ftrace support and stack packing.
Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
On Wed, Jul 29, 2020 at 4:11 AM Christian König
wrote:
>
> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> > Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> > amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
> > when `size` is greater than 356.
> >
> > In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
> > unfortunately does not initialize that 4-byte hole. Fix it by using
> > memset() instead.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
> > Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> > Suggested-by: Dan Carpenter
> > Signed-off-by: Peilin Ye
>
> Reviewed-by: Christian König
>
> I can't count how many of those we have fixed over the years.
>
> At some point we should probably document that using "= {}" or "= { 0 }"
> in the kernel is a really bad idea and should be avoided.
Moreover, it seems like different compilers seem to behave relatively
differently with these and we often get reports of warnings with these
on clang. When in doubt, memset.
Alex
>
> Thanks,
> Christian.
>
> > ---
> > $ pahole -C "drm_amdgpu_info_device" drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o
> > struct drm_amdgpu_info_device {
> > __u32 device_id;/* 0 4 */
> > __u32 chip_rev; /* 4 4 */
> > __u32 external_rev; /* 8 4 */
> > __u32 pci_rev; /*12 4 */
> > __u32 family; /*16 4 */
> > __u32 num_shader_engines; /*20 4 */
> > __u32 num_shader_arrays_per_engine; /*24
> > 4 */
> > __u32 gpu_counter_freq; /*28 4 */
> > __u64 max_engine_clock; /*32 8 */
> > __u64 max_memory_clock; /*40 8 */
> > __u32 cu_active_number; /*48 4 */
> > __u32 cu_ao_mask; /*52 4 */
> > __u32 cu_bitmap[4][4]; /*5664 */
> > /* --- cacheline 1 boundary (64 bytes) was 56 bytes ago --- */
> > __u32 enabled_rb_pipes_mask; /* 120 4 */
> > __u32 num_rb_pipes; /* 124 4 */
> > /* --- cacheline 2 boundary (128 bytes) --- */
> > __u32 num_hw_gfx_contexts; /* 128 4 */
> > __u32 _pad; /* 132 4 */
> > __u64 ids_flags;/* 136 8 */
> > __u64 virtual_address_offset; /* 144 8 */
> > __u64 virtual_address_max; /* 152 8 */
> > __u32 virtual_address_alignment; /* 160 4
> > */
> > __u32 pte_fragment_size;/* 164 4 */
> > __u32 gart_page_size; /* 168 4 */
> > __u32 ce_ram_size; /* 172 4 */
> > __u32 vram_type;/* 176 4 */
> > __u32 vram_bit_width; /* 180 4 */
> > __u32 vce_harvest_config; /* 184 4 */
> > __u32 gc_double_offchip_lds_buf; /* 188 4
> > */
> > /* --- cacheline 3 boundary (192 bytes) --- */
> > __u64 prim_buf_gpu_addr;/* 192 8 */
> > __u64 pos_buf_gpu_addr; /* 200 8 */
> > __u64 cntl_sb_buf_gpu_addr; /* 208 8 */
> > __u64 param_buf_gpu_addr; /* 216 8 */
> > __u32 prim_buf_size;/* 224 4 */
> > __u32 pos_buf_size; /* 228 4 */
> > __u32 cntl_sb_buf_size; /* 232 4 */
> > __u32 param_buf_size; /* 236 4 */
> > __u32 wave_front_size; /* 240 4 */
> > __u32 num_shader_visible_vgprs; /* 244 4 */
> > __u32 num_cu_per_sh;/* 248 4 */
> > __u32 num_tcc_blocks; /* 252 4 */
> > /* --- cacheline 4 boundary (256 bytes) --- */
> > __u32 gs_vgt_table_depth; /* 256 4 */
> > __u32 gs_prim_buffer_depth; /* 260 4 */
> > __u32 max_gs_waves_per_vgt; /* 264 4 */
> > __u32 _pad1;/* 268 4 */
> > __u32 cu_ao_bitmap[4][4]
[PATCH 1/3] ARM: exynos: clear L220_AUX_CTRL_NS_LOCKDOWN in default l2c_aux_val
The L220_AUX_CTRL_NS_LOCKDOWN flag is set during the L2C enable sequence. There is no need to set it in the default register value, this was done before support for it was implemented in the code. It is not set in the hardware initial value either. Clean this up by removing this flag from the default l2c_aux_val, and add it to the l2c_aux_mask to print an alert message if it was already set before the kernel initialisation. Signed-off-by: Guillaume Tucker --- arch/arm/mach-exynos/exynos.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index 36c3785a..a96f3353a0c1 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -193,8 +193,8 @@ static void __init exynos_dt_fixup(void) } DT_MACHINE_START(EXYNOS_DT, "Samsung Exynos (Flattened Device Tree)") - .l2c_aux_val= 0x3c40, - .l2c_aux_mask = 0xc20f, + .l2c_aux_val= 0x3840, + .l2c_aux_mask = 0xc60f, .smp= smp_ops(exynos_smp_ops), .map_io = exynos_init_io, .init_early = exynos_firmware_init, -- 2.20.1
[PATCH 2/3] ARM: l2c: update prefetch bits in L2X0_AUX_CTRL using DT value
The L310_PREFETCH_CTRL register bits 28 and 29 to enable data and
instruction prefetch respectively can also be accessed via the
L2X0_AUX_CTRL register. They appear to be actually wired together in
hardware between the registers. Changing them in the prefetch
register only will get undone when restoring the aux control register
later on. For this reason, set these bits in both registers during
initialisation according to the DT attributes.
Fixes: ec3bd0e68a67 ("ARM: 8391/1: l2c: add options to overwrite prefetching
behavior")
Signed-off-by: Guillaume Tucker
---
arch/arm/mm/cache-l2x0.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 12c26eb88afb..43d91bfd2360 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1249,20 +1249,28 @@ static void __init l2c310_of_parse(const struct
device_node *np,
ret = of_property_read_u32(np, "prefetch-data", &val);
if (ret == 0) {
- if (val)
+ if (val) {
prefetch |= L310_PREFETCH_CTRL_DATA_PREFETCH;
- else
+ *aux_val |= L310_PREFETCH_CTRL_DATA_PREFETCH;
+ } else {
prefetch &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
+ *aux_val &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
+ }
+ *aux_mask &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
} else if (ret != -EINVAL) {
pr_err("L2C-310 OF prefetch-data property value is missing\n");
}
ret = of_property_read_u32(np, "prefetch-instr", &val);
if (ret == 0) {
- if (val)
+ if (val) {
prefetch |= L310_PREFETCH_CTRL_INSTR_PREFETCH;
- else
+ *aux_val |= L310_PREFETCH_CTRL_INSTR_PREFETCH;
+ } else {
prefetch &= ~L310_PREFETCH_CTRL_INSTR_PREFETCH;
+ *aux_val &= ~L310_PREFETCH_CTRL_INSTR_PREFETCH;
+ }
+ *aux_mask &= ~L310_PREFETCH_CTRL_INSTR_PREFETCH;
} else if (ret != -EINVAL) {
pr_err("L2C-310 OF prefetch-instr property value is missing\n");
}
--
2.20.1
[PATCH 3/3] ARM: exynos: use DT prefetch attributes rather than l2c_aux_val
Use the standard l2c2x0 device tree bindings to enable data and instruction prefetch on exynos4210 and exynos4412 and clear the respective bits in the default l2c_aux_val. No other Exynos platform relying on this default register value appears to be using the l2x0 cache. Signed-off-by: Guillaume Tucker --- arch/arm/boot/dts/exynos4210.dtsi | 2 ++ arch/arm/boot/dts/exynos4412.dtsi | 2 ++ arch/arm/mach-exynos/exynos.c | 4 ++-- 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi index b4466232f0c1..7e0d253b26ef 100644 --- a/arch/arm/boot/dts/exynos4210.dtsi +++ b/arch/arm/boot/dts/exynos4210.dtsi @@ -102,6 +102,8 @@ reg = <0x10502000 0x1000>; cache-unified; cache-level = <2>; + prefetch-data = <1>; + prefetch-instr = <1>; arm,tag-latency = <2 2 1>; arm,data-latency = <2 2 1>; }; diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi index 48868947373e..37efa247bf4d 100644 --- a/arch/arm/boot/dts/exynos4412.dtsi +++ b/arch/arm/boot/dts/exynos4412.dtsi @@ -218,6 +218,8 @@ reg = <0x10502000 0x1000>; cache-unified; cache-level = <2>; + prefetch-data = <1>; + prefetch-instr = <1>; arm,tag-latency = <2 2 1>; arm,data-latency = <3 2 1>; arm,double-linefill = <1>; diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index a96f3353a0c1..0e906cc3a48e 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -193,8 +193,8 @@ static void __init exynos_dt_fixup(void) } DT_MACHINE_START(EXYNOS_DT, "Samsung Exynos (Flattened Device Tree)") - .l2c_aux_val= 0x3840, - .l2c_aux_mask = 0xc60f, + .l2c_aux_val= 0x0840, + .l2c_aux_mask = 0xf60f, .smp= smp_ops(exynos_smp_ops), .map_io = exynos_init_io, .init_early = exynos_firmware_init, -- 2.20.1
Re: [PATCH v8 2/5] drm/imx: Add initial support for DCSS on iMX8MQ
Hi Guido, On Wed, Jul 29, 2020 at 03:11:21PM +0200, Guido Günther wrote: > Hi Laurentiu, > On Fri, Jul 24, 2020 at 12:07:31PM +0300, Laurentiu Palcu wrote: > > From: Laurentiu Palcu > > > > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS). > > Some of its capabilities include: > > * 4K@60fps; > > * HDR10; > > * one graphics and 2 video pipelines; > > * on-the-fly decompression of compressed video and graphics; > > > > The reference manual can be found here: > > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM > > > > The current patch adds only basic functionality: one primary plane for > > graphics, linear, tiled and super-tiled buffers support (no graphics > > decompression yet), no HDR10 and no video planes. > > > > Video planes support and HDR10 will be added in subsequent patches once > > per-plane de-gamma/CSC/gamma support is in. > > > > Signed-off-by: Laurentiu Palcu > > Reviewed-by: Lucas Stach > > --- > > drivers/gpu/drm/imx/Kconfig| 2 + > > drivers/gpu/drm/imx/Makefile | 1 + > > drivers/gpu/drm/imx/dcss/Kconfig | 8 + > > drivers/gpu/drm/imx/dcss/Makefile | 6 + > > drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 70 +++ > > drivers/gpu/drm/imx/dcss/dcss-crtc.c | 219 +++ > > drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 + > > drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++ > > drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++ > > drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 + > > drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 + > > drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 > > drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++ > > drivers/gpu/drm/imx/dcss/dcss-kms.h| 43 ++ > > drivers/gpu/drm/imx/dcss/dcss-plane.c | 405 > > drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 + > > drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++ > > 17 files changed, 3961 insertions(+) > > create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig > > create mode 100644 drivers/gpu/drm/imx/dcss/Makefile > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c > > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c > > > > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig > > index 207bf7409dfb..6231048aa5aa 100644 > > --- a/drivers/gpu/drm/imx/Kconfig > > +++ b/drivers/gpu/drm/imx/Kconfig > > @@ -39,3 +39,5 @@ config DRM_IMX_HDMI > > depends on DRM_IMX > > help > > Choose this if you want to use HDMI on i.MX6. > > + > > +source "drivers/gpu/drm/imx/dcss/Kconfig" > > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile > > index 21cdcc2faabc..b644deffe948 100644 > > --- a/drivers/gpu/drm/imx/Makefile > > +++ b/drivers/gpu/drm/imx/Makefile > > @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o > > obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o > > > > obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o > > +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/ > > diff --git a/drivers/gpu/drm/imx/dcss/Kconfig > > b/drivers/gpu/drm/imx/dcss/Kconfig > > new file mode 100644 > > index ..a76435924b6a > > --- /dev/null > > +++ b/drivers/gpu/drm/imx/dcss/Kconfig > > @@ -0,0 +1,8 @@ > > +config DRM_IMX_DCSS > > + tristate "i.MX8MQ DCSS" > > + select IMX_IRQSTEER > > + select DRM_KMS_CMA_HELPER > > + depends on DRM && ARCH_MXC > > I need a > > select VIDEOMODE_HELPERS > > here otherwise the build fails like > > LD .tmp_vmlinux.kallsyms1 > aarch64-linux-gnu-ld: warning: -z norelro ignored > aarch64-linux-gnu-ld: drivers/gpu/drm/imx/dcss/dcss-crtc.o: in function > `dcss_crtc_atomic_enable': > dcss-crtc.c:(.text+0x2a8): undefined reference to > `drm_display_mode_to_videomode' > make: *** [Makefile:1157: vmlinux] Error 1 > > on next-20200727. Thanks for taking this for a spin. :) Sadly, I've never hit the issue, probably because VIDEOMDODE_HELPERS got selected by other modules in my configuration... :/ I'll add it and send another version. Thanks, laurentiu > Cheers, > -- Guido > > > + help > > + Choose this if you have a NXP i.MX8MQ based system and want to use the > > + Display Controller Subsystem. This option enables DCSS support. > > diff --git a/drivers/gpu/drm/imx/dcss/Makefile
Re: [Linux-kernel-mentees] [PATCH v2] block/floppy: Prevent kernel-infoleak in raw_cmd_copyout()
On Wed, Jul 29, 2020 at 04:22:41PM +0300, Denis Efremov wrote: > > On 7/29/20 3:58 PM, Dan Carpenter wrote: > > Argh... This isn't right still. The "ptr" comes from raw_cmd_copyin() > > > > ptr = kmalloc(sizeof(struct floppy_raw_cmd), GFP_KERNEL); > > > > copy_from_user overwrites the padding bytes: > ptr = kmalloc(sizeof(struct floppy_raw_cmd), GFP_KERNEL); > if (!ptr) > return -ENOMEM; > *rcmd = ptr; > ret = copy_from_user(ptr, param, sizeof(*ptr)); > > I think memcpy should be safe in this patch. Oh yeah. You're right. My bad. I just saw the: ptr->next = NULL; ptr->buffer_length = 0; ptr->kernel_data = NULL; Assignments and I missed the copy_from_user. regards, dan carpenter
Re: [patch V5 00/15] entry, x86, kvm: Generic entry/exit functionality for host and guest
On 24/07/2020 21:51, Thomas Gleixner wrote: Thomas Gleixner writes: This is the 5th version of generic entry/exit functionality for host and guest. I've merged the pile in two steps. Patch 1-5, i.e. the generic code is here: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/entry and merged this branch and patch 6-15 into git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry core/entry is immutable and any updates, changes go on top. It's meant as a base for other architecture developers who want to fiddle with that without having to get the x86 mess as well. Hi Thomas, Just FYI: I'm going to take a look at arm64 support for this. I know Mark previously posted[1] a series moving much of the code to C, so hopefully I can build on that and make use of the generic code. Thanks, Steve [1] https://lore.kernel.org/r/20200108185634.1163-1-mark.rutl...@arm.com
[PATCH] powerpc: fix function annotations to avoid section mismatch warnings with gcc-10
Certain warnings are emitted for powerpc code when building with a gcc-10
toolset:
WARNING: modpost: vmlinux.o(.text.unlikely+0x377c): Section mismatch in
reference from the function remove_pmd_table() to the function
.meminit.text:split_kernel_mapping()
The function remove_pmd_table() references
the function __meminit split_kernel_mapping().
This is often because remove_pmd_table lacks a __meminit
annotation or the annotation of split_kernel_mapping is wrong.
Add the appropriate __init and __meminit annotations to make modpost not
complain. In all the cases there are just a single callsite from another
__init or __meminit function:
__meminit remove_pagetable() -> remove_pud_table() -> remove_pmd_table()
__init prom_init() -> setup_secure_guest()
__init xive_spapr_init() -> xive_spapr_disabled()
Signed-off-by: Vladis Dronov
---
arch/powerpc/kernel/prom_init.c | 4 ++--
arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++--
arch/powerpc/sysdev/xive/spapr.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 90c604d00b7d..f6ca7f450361 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -3262,7 +3262,7 @@ static int enter_secure_mode(unsigned long kbase,
unsigned long fdt)
/*
* Call the Ultravisor to transfer us to secure memory if we have an ESM blob.
*/
-static void setup_secure_guest(unsigned long kbase, unsigned long fdt)
+static void __init setup_secure_guest(unsigned long kbase, unsigned long fdt)
{
int ret;
@@ -3292,7 +3292,7 @@ static void setup_secure_guest(unsigned long kbase,
unsigned long fdt)
}
}
#else
-static void setup_secure_guest(unsigned long kbase, unsigned long fdt)
+static void __init setup_secure_guest(unsigned long kbase, unsigned long fdt)
{
}
#endif /* CONFIG_PPC_SVM */
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index bb00e0cba119..b868c07110e3 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -800,7 +800,7 @@ static void __meminit split_kernel_mapping(unsigned long
addr, unsigned long end
pte_clear(&init_mm, addr, pte);
}
-static void remove_pmd_table(pmd_t *pmd_start, unsigned long addr,
+static void __meminit remove_pmd_table(pmd_t *pmd_start, unsigned long addr,
unsigned long end)
{
unsigned long next;
@@ -825,7 +825,7 @@ static void remove_pmd_table(pmd_t *pmd_start, unsigned
long addr,
}
}
-static void remove_pud_table(pud_t *pud_start, unsigned long addr,
+static void __meminit remove_pud_table(pud_t *pud_start, unsigned long addr,
unsigned long end)
{
unsigned long next;
diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c
index f0551a2be9df..1e3674d7ea7b 100644
--- a/arch/powerpc/sysdev/xive/spapr.c
+++ b/arch/powerpc/sysdev/xive/spapr.c
@@ -768,7 +768,7 @@ static const u8 *get_vec5_feature(unsigned int index)
return vec5 + index;
}
-static bool xive_spapr_disabled(void)
+static bool __init xive_spapr_disabled(void)
{
const u8 *vec5_xive;
--
2.26.2
Re: [PATCH] vgacon: fix out of bounds write to the scrollback buffer
Hi Jiri,
On 7/29/20 9:02 AM, Jiri Slaby wrote:
> The current vgacon's scroll up implementation uses a circural buffer
> in vgacon_scrollback_cur. It always advances tail to prepare it for the
> next write and caps it to zero if the next ->vc_size_row bytes won't fit.
>
> But when we change the VT size (e.g. by VT_RESIZE) in the meantime, the new
> line might not fit to the end of the scrollback buffer in the next
> attempt to scroll. This leads to various crashes as
> vgacon_scrollback_update writes out of the buffer:
> BUG: unable to handle page fault for address: c91752a0
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> RIP: 0010:mutex_unlock+0x13/0x30
> ...
> Call Trace:
> n_tty_write+0x1a0/0x4d0
> tty_write+0x1a0/0x2e0
>
> Or to KASAN reports:
> BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed
>
> So check whether the line fits in the buffer and wrap if needed. Do it
> before the loop as console_sem is held and ->vc_size_row cannot change
> during the execution of vgacon_scrollback_cur. If it does change, we
> need to ensure it does not change elsewhere, not here.
>
> Also, we do not split the write of a line into chunks as that would
> break the consumers of the buffer. They expect ->cnt, ->tail and ->size
> to be in harmony and advanced by ->vc_size_row.
>
> I found few reports of this in the past, some with patches included,
> some even 2 years old:
> https://lore.kernel.org/lkml/CAEAjamsJnG-=TSOwgRbbb3B9Z-PA63oWmNPoKYWQ=Z=+x49...@mail.gmail.com/
Sorry but I don't work on fixing fbdev/console KASAN/syzbot/etc.
reports (-ENORESOURCES). This has been made official in the past.
I'm happy to review/apply patches though.
> https://lore.kernel.org/lkml/1589336932-35508-1-git-send-email-yangyingli...@huawei.com/
This was the first time the patch for issue was submitted.
I tried to apply it to drm-misc but then I have noticed that
it has not been posted to linux-fbdev / dri-devel MLs (so it
was not possible to merge it using dim tool) and thus I've
requested the author to resend it:
https://lore.kernel.org/lkml/62544bd9-e47d-e7f9-92f2-49b8dbb13...@samsung.com/
which he did:
https://lore.kernel.org/lkml/20200713105730.550334-1-yangyingli...@huawei.com/
and the patch is currently under review period (to give people
chance to comment on it) and in my "to apply if no objections"
folder.
I see that your/Yunhai patch addresses the root source of
the issue so I'll be happy to apply/ACK it instead of Yang's
patch once the final version is posted.
Thank you for working on this.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> This fixes CVE-2020-14331.
>
> Big thanks to guys mentioned in the Reported-and-debugged-by lines below
> who actually found the root cause.
>
> Signed-off-by: Jiri Slaby
> Reported-and-debugged-by: 张云海
> Reported-and-debugged-by: Yang Yingliang
> Reported-by: Kyungtae Kim
> Fixes: 15bdab959c9b ([PATCH] vgacon: Add support for soft scrollback)
> Cc: Linus Torvalds
> Cc: Greg KH
> Cc: Solar Designer
> Cc: "Srivatsa S. Bhat"
> Cc: Anthony Liguori
> Cc: Security Officers
> Cc: linux-dist...@vs.openwall.org
> Cc: Yang Yingliang
> Cc: Bartlomiej Zolnierkiewicz
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> ---
> drivers/video/console/vgacon.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index f0f3d573f848..13194bb246f8 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -250,6 +250,11 @@ static void vgacon_scrollback_update(struct vc_data *c,
> int t, int count)
>
> p = (void *) (c->vc_origin + t * c->vc_size_row);
>
> + /* vc_size_row might have changed by VT_RESIZE in the meantime */
> + if ((vgacon_scrollback_cur->tail + c->vc_size_row) >=
> + vgacon_scrollback_cur->size)
> + vgacon_scrollback_cur->tail = 0;
> +
> while (count--) {
> scr_memcpyw(vgacon_scrollback_cur->data +
> vgacon_scrollback_cur->tail,
>
Re: [PATCH v1 3/6] mm/page_isolation: drop WARN_ON_ONCE() in set_migratetype_isolate()
On 29.07.20 15:24, Baoquan He wrote:
> On 06/30/20 at 04:26pm, David Hildenbrand wrote:
>> Inside has_unmovable_pages(), we have a comment describing how unmovable
>> data could end up in ZONE_MOVABLE - via "movable_core". Also, besides
> ~~~ 'movablecore'
>> checking if the first page in the pageblock is reserved, we don't
>> perform any further checks in case of ZONE_MOVABLE.
>>
>> In case of memory offlining, we set REPORT_FAILURE, properly
>> dump_page() the page and handle the error gracefully.
>> alloc_contig_pages() users currently never allocate from ZONE_MOVABLE.
>> E.g., hugetlb uses alloc_contig_pages() for the allocation of gigantic
>> pages only, which will never end up on the MOVABLE zone
>> (see htlb_alloc_mask()).
>>
>> Cc: Andrew Morton
>> Cc: Michal Hocko
>> Cc: Michael S. Tsirkin
>> Signed-off-by: David Hildenbrand
>> ---
>> mm/page_isolation.c | 16 ++--
>> 1 file changed, 6 insertions(+), 10 deletions(-)
>>
>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
>> index 553b49a34cf71..02a01bff6b219 100644
>> --- a/mm/page_isolation.c
>> +++ b/mm/page_isolation.c
>> @@ -58,16 +58,12 @@ static int set_migratetype_isolate(struct page *page,
>> int migratetype, int isol_
>> spin_unlock_irqrestore(&zone->lock, flags);
>> if (!ret) {
>> drain_all_pages(zone);
>> -} else {
>> -WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
>> -
>> -if ((isol_flags & REPORT_FAILURE) && unmovable)
>> -/*
>> - * printk() with zone->lock held will likely trigger a
>> - * lockdep splat, so defer it here.
>> - */
>> -dump_page(unmovable, "unmovable page");
>> -}
>> +} else if ((isol_flags & REPORT_FAILURE) && unmovable)
>
> This else if branch should be enclosed in brace?
>
Not necessarily. And it will be gone in the next patch in this series :)
Thanks!
--
Thanks,
David / dhildenb
Re: [PATCH 0/2] locking/qspinlock: Break qspinlock_types.h header loop
On 7/29/20 8:28 AM, Herbert Xu wrote: This miniseries breaks a header loop involving qspinlock_types.h. The issue is that qspinlock_types.h includes atomic.h, which then eventually includes kernel.h which could lead back to the original file via spinlock_types.h. The first patch moves ATOMIC_INIT into linux/types.h while the second patch actuallys breaks the loop by no longer including atomic.h in qspinlock_types.h. Cheers, This patch series looks good to me. I just wonder if we should also move ATOMIC64_INIT() to types.h for symmetry purpose. Anyway, Acked-by: Waiman Long
Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor
* Andy Lutomirski: > This is quite clever, but now I’m wondering just how much kernel help > is really needed. In your series, the trampoline is an non-executable > page. I can think of at least two alternative approaches, and I'd > like to know the pros and cons. > > 1. Entirely userspace: a return trampoline would be something like: > > 1: > pushq %rax > pushq %rbc > pushq %rcx > ... > pushq %r15 > movq %rsp, %rdi # pointer to saved regs > leaq 1b(%rip), %rsi # pointer to the trampoline itself > callq trampoline_handler # see below > > You would fill a page with a bunch of these, possibly compacted to get > more per page, and then you would remap as many copies as needed. libffi does something like this for iOS, I believe. The only thing you really need is a PC-relative indirect call, with the target address loaded from a different page. The trampoline handler can do all the rest because it can identify the trampoline from the stack. Having a closure parameter loaded into a register will speed things up, of course. I still hope to transition libffi to this model for most Linux targets. It really simplifies things because you don't have to deal with cache flushes (on both the data and code aliases for SELinux support). But the key observation is that efficient trampolines do not need run-time code generation at all because their code is so regular. Thanks, Florian
Re: [PATCH v2 2/3] sched: Cleanup SCHED_THERMAL_PRESSURE kconfig entry
On 29/07/20 14:09, Quentin Perret wrote: > On Tuesday 28 Jul 2020 at 17:16:57 (+0100), Valentin Schneider wrote: >> We could change the arch Kconfig into >> >> select SCHED_THERMAL_PRESSURE if CPU_FREQ_THERMAL >> >> but that seems redundant; this dependency is already expressed in >> SCHED_THERMAL_PRESSURE's definition. Is there a proper pattern to select >> some Kconfig option only if all of its dependencies are met? > > How about something like this (totally untested): > > ---8<--- > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 939c4d6bbc2e..2ac74904a3ce 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -46,7 +46,6 @@ config ARM > select EDAC_ATOMIC_SCRUB > select GENERIC_ALLOCATOR > select GENERIC_ARCH_TOPOLOGY if ARM_CPU_TOPOLOGY > - select SCHED_THERMAL_PRESSURE if ARM_CPU_TOPOLOGY > select GENERIC_ATOMIC64 if CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI > select GENERIC_CLOCKEVENTS_BROADCAST if SMP > select GENERIC_CPU_AUTOPROBE > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index c403e6f5db86..66dc41fd49f2 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -192,7 +192,6 @@ config ARM64 > select PCI_SYSCALL if PCI > select POWER_RESET > select POWER_SUPPLY > - select SCHED_THERMAL_PRESSURE > select SPARSE_IRQ > select SWIOTLB > select SYSCTL_EXCEPTION_TRACE > diff --git a/init/Kconfig b/init/Kconfig > index 0a97d85568b2..c2e1f3ac527e 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -493,6 +493,7 @@ config HAVE_SCHED_AVG_IRQ > > config SCHED_THERMAL_PRESSURE > bool > + default y if ARM64 || ARM_CPU_TOPOLOGY > depends on SMP > depends on CPU_FREQ_THERMAL > help > --->8--- > That does seem to do just what I was looking for, thanks! > Thanks, > Quentin
Re: [PATCH 0/2] locking/qspinlock: Break qspinlock_types.h header loop
On (20/07/29 15:00), pet...@infradead.org wrote: > On Wed, Jul 29, 2020 at 10:51:44PM +1000, Herbert Xu wrote: > > On Wed, Jul 29, 2020 at 02:47:44PM +0200, pet...@infradead.org wrote: > > > [..] > > > Anyway, the patches look sane enough, I'll go stick them in > > > tip/locking/core or somesuch. > > > > Perhaps add them on top of the other two patches in locking/header? > > Can do, locking/header would be better -ss
Re: [PATCH v2 0/3] media: vimc: Allow multiple capture devices to use the same sensor
Hi Dafna, Kaaira, On 29/07/2020 14:16, Dafna Hirschfeld wrote: > > > On 29.07.20 15:05, Kieran Bingham wrote: >> Hi Dafna, >> >> On 28/07/2020 15:00, Dafna Hirschfeld wrote: >>> >>> >>> On 28.07.20 14:07, Dafna Hirschfeld wrote: Hi On 28.07.20 13:39, Kaaira Gupta wrote: > On Mon, Jul 27, 2020 at 02:54:30PM -0300, Helen Koike wrote: >> Hi, >> >> On 7/27/20 11:31 AM, Kieran Bingham wrote: >>> Hi all, >>> >>> +Dafna for the thread discussion, as she's missed from the to/cc >>> list. >>> >>> >>> On 24/07/2020 13:21, Kaaira Gupta wrote: On Fri, Jul 24, 2020 at 02:15:21PM +0200, Niklas Söderlund wrote: Hi, > Hi Kaaira, > > Thanks for your work. Thanks for yours :D > > On 2020-07-24 17:32:10 +0530, Kaaira Gupta wrote: >> This is version 2 of the patch series posted by Niklas for >> allowing >> multiple streams in VIMC. >> The original series can be found here: >> https://patchwork.kernel.org/cover/10948831/ >> >> This series adds support for two (or more) capture devices to be >> connected to the same sensors and run simultaneously. Each >> capture device >> can be started and stopped independent of each other. >> >> Patch 1/3 and 2/3 deals with solving the issues that arises once >> two >> capture devices can be part of the same pipeline. While 3/3 >> allows for >> two capture devices to be part of the same pipeline and thus >> allows for >> simultaneously use. I wonder if these two patches are enough, since each vimc entity also have a 'process_frame' callback, but only one allocated frame. That means that the 'process_frame' can be called concurrently by two different streams on the same frame and cause corruption. >>> >>> I think we should somehow change the vimc-stream.c code so that we have >>> only >>> one stream process per pipe. So if one capture is already streaming, >>> then the new >>> capture that wants to stream uses the same thread so we don't have two >>> threads >>> both calling 'process_frame'. >> >> >> Yes, I think it looks and sounds like there are two threads running when >> there are two streams. >> >> so in effect, although they 'share a pipe', aren't they in effect just >> sending two separate buffers through their stream-path? >> >> If that's the case, then I don't think there's any frame corruption, >> because they would both have grabbed their own frame separately. > > But each entity allocates just one buffer. So the same buffer is used for > both stream. Aha, ok, I hadn't realised there was only a single buffer available in the pipeline for each entity. Indeed there is a risk of corruption in that case. > What for example can happen is that the debayer of one stream can read the > sensor's buffer while the sensor itself writes to the buffer for the other > stream. So, In that case, we have currently got a scenario where each 'stream' really is operating it's own pipe (even though all components are reused). Two questions: Is this acceptable, and we should just use a mutex to ensure the buffers are not corrupted, but essentially each stream is a separate temporal capture? Or B: Should we refactor to make sure that there is a single thread, and the code which calls process_frame on each entity should become aware of the potential for multiple paths at the point of the sensor. I suspect option B is really the 'right' path to take, but it is more complicated of course. -- Kieran > Thanks, > Dafna > >> >> >> I don't think that's a good example of the hardware though, as that >> doesn't reflect what 'should' happen where the TPG runs once to generate >> a frame at the sensor, which is then read by both the debayer entity and >> the RAW capture device when there are two streams... >> >> >> So I suspect trying to move to a single thread is desirable, but that >> might be a fair bit of work also. >> >> -- >> Kieran >> >> >> >>> The second capture that wants to stream should iterate the topology >>> downwards until >>> reaching an entity that already belong to the stream path of the other >>> streaming capture >>> and tell the streamer it wants to read the frames this entity >>> produces. >>> >>> Thanks, >>> Dafna >>> Thanks, Dafna > > I'm just curious if you are aware of this series? It would > replace the > need for 1/3 and 2/3 of this series right? v3 of this series replaces the need for 1/3, but not the current version (ie v4). v4 of patch 2/5 removes the stream_counter that is needed to keep count of the calls to s_stream. Hence 1/3 becomes relevant again. >>> >>> So the question really is, how do we best make use of the
Re: [PATCH v8 5/5] dt-bindings: display: imx: add bindings for DCSS
Hi,
On Fri, Jul 24, 2020 at 12:07:34PM +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> Add bindings for iMX8MQ Display Controller Subsystem.
>
> Signed-off-by: Laurentiu Palcu
> Reviewed-by: Rob Herring
> ---
> .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
> 1 file changed, 104 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> new file mode 100644
> index ..68e4635e4874
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> @@ -0,0 +1,104 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 NXP
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: iMX8MQ Display Controller Subsystem (DCSS)
> +
> +maintainers:
> + - Laurentiu Palcu
> +
> +description:
> +
> + The DCSS (display controller sub system) is used to source up to three
> + display buffers, compose them, and drive a display using HDMI 2.0a(with
> HDCP
> + 2.2) or MIPI-DSI. The DCSS is intended to support up to 4kp60 displays.
> HDR10
> + image processing capabilities are included to provide a solution capable of
> + driving next generation high dynamic range displays.
> +
> +properties:
> + compatible:
> +const: nxp,imx8mq-dcss
> +
> + reg:
> +items:
> + - description: DCSS base address and size, up to IRQ steer start
> + - description: DCSS BLKCTL base address and size
> +
> + interrupts:
> +items:
> + - description: Context loader completion and error interrupt
> + - description: DTG interrupt used to signal context loader trigger time
> + - description: DTG interrupt for Vblank
> +
> + interrupt-names:
> +items:
> + - const: ctxld
> + - const: ctxld_kick
> + - const: vblank
> +
> + clocks:
> +items:
> + - description: Display APB clock for all peripheral PIO access
> interfaces
> + - description: Display AXI clock needed by DPR, Scaler, RTRAM_CTRL
> + - description: RTRAM clock
> + - description: Pixel clock, can be driven either by HDMI phy clock or
> MIPI
> + - description: DTRC clock, needed by video decompressor
> +
> + clock-names:
> +items:
> + - const: apb
> + - const: axi
> + - const: rtrm
> + - const: pix
> + - const: dtrc
> +
> + assigned-clocks:
> +items:
> + - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_AXI_ROOT
> + - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_RTRM
> + - description: Phandle and clock specifier of either
> IMX8MQ_VIDEO2_PLL1_REF_SEL or
> + IMX8MQ_VIDEO_PLL1_REF_SEL
> +
> + assigned-clock-parents:
> +items:
> + - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
> + - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
> + - description: Phandle and clock specifier of IMX8MQ_CLK_27M
> +
> + assigned-clock-rates:
> +items:
> + - description: Must be 800 MHz
> + - description: Must be 400 MHz
> +
> + port:
> +type: object
> +description:
> + A port node pointing to the input port of a HDMI/DP or MIPI display
> bridge.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
it would be nice to
#include
here...
> +dcss: display-controller@32e0 {
> +compatible = "nxp,imx8mq-dcss";
> +reg = <0x32e0 0x2d000>, <0x32e2f000 0x1000>;
> +interrupts = <6>, <8>, <9>;
> +interrupt-names = "ctxld", "ctxld_kick", "vblank";
> +interrupt-parent = <&irqsteer>;
> +clocks = <&clk 248>, <&clk 247>, <&clk 249>,
> + <&clk 254>,<&clk 122>;
> +clock-names = "apb", "axi", "rtrm", "pix", "dtrc";
> +assigned-clocks = <&clk 107>, <&clk 109>, <&clk 266>;
> +assigned-clock-parents = <&clk 78>, <&clk 78>, <&clk 3>;
so that clock names like IMX8MQ_CLK_DISP_AXI could be used to make this
even more useful.
Cheers,
-- Guido
> +assigned-clock-rates = <8>,
> + <4>;
> +port {
> +dcss_out: endpoint {
> +remote-endpoint = <&hdmi_in>;
> +};
> +};
> +};
> +
> --
> 2.23.0
>
Re: [PATCH v1 3/6] mm/page_isolation: drop WARN_ON_ONCE() in set_migratetype_isolate()
On 06/30/20 at 04:26pm, David Hildenbrand wrote:
> Inside has_unmovable_pages(), we have a comment describing how unmovable
> data could end up in ZONE_MOVABLE - via "movable_core". Also, besides
~~~ 'movablecore'
> checking if the first page in the pageblock is reserved, we don't
> perform any further checks in case of ZONE_MOVABLE.
>
> In case of memory offlining, we set REPORT_FAILURE, properly
> dump_page() the page and handle the error gracefully.
> alloc_contig_pages() users currently never allocate from ZONE_MOVABLE.
> E.g., hugetlb uses alloc_contig_pages() for the allocation of gigantic
> pages only, which will never end up on the MOVABLE zone
> (see htlb_alloc_mask()).
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Michael S. Tsirkin
> Signed-off-by: David Hildenbrand
> ---
> mm/page_isolation.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index 553b49a34cf71..02a01bff6b219 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -58,16 +58,12 @@ static int set_migratetype_isolate(struct page *page, int
> migratetype, int isol_
> spin_unlock_irqrestore(&zone->lock, flags);
> if (!ret) {
> drain_all_pages(zone);
> - } else {
> - WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
> -
> - if ((isol_flags & REPORT_FAILURE) && unmovable)
> - /*
> - * printk() with zone->lock held will likely trigger a
> - * lockdep splat, so defer it here.
> - */
> - dump_page(unmovable, "unmovable page");
> - }
> + } else if ((isol_flags & REPORT_FAILURE) && unmovable)
This else if branch should be enclosed in brace?
> + /*
> + * printk() with zone->lock held will likely trigger a
> + * lockdep splat, so defer it here.
> + */
> + dump_page(unmovable, "unmovable page");
>
> return ret;
> }
Otherwise, the patch looks good to me.
Reviewed-by: Baoquan He
[PATCH 2/4] KVM: SVM: Add GHCB definitions
From: Tom Lendacky
Extend the vmcb_safe_area with SEV-ES fields and add a new
'struct ghcb' which will be used for guest-hypervisor communication.
Signed-off-by: Tom Lendacky
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/svm.h | 45 +-
arch/x86/kvm/svm/svm.c | 2 ++
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 8a1f5382a4ea..9a3e0b802716 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -200,13 +200,56 @@ struct __attribute__ ((__packed__)) vmcb_save_area {
u64 br_to;
u64 last_excp_from;
u64 last_excp_to;
+
+ /*
+* The following part of the save area is valid only for
+* SEV-ES guests when referenced through the GHCB.
+*/
+ u8 reserved_7[104];
+ u64 reserved_8; /* rax already available at 0x01f8 */
+ u64 rcx;
+ u64 rdx;
+ u64 rbx;
+ u64 reserved_9; /* rsp already available at 0x01d8 */
+ u64 rbp;
+ u64 rsi;
+ u64 rdi;
+ u64 r8;
+ u64 r9;
+ u64 r10;
+ u64 r11;
+ u64 r12;
+ u64 r13;
+ u64 r14;
+ u64 r15;
+ u8 reserved_10[16];
+ u64 sw_exit_code;
+ u64 sw_exit_info_1;
+ u64 sw_exit_info_2;
+ u64 sw_scratch;
+ u8 reserved_11[56];
+ u64 xcr0;
+ u8 valid_bitmap[16];
+ u64 x87_state_gpa;
+};
+
+struct __attribute__ ((__packed__)) ghcb {
+ struct vmcb_save_area save;
+ u8 reserved_save[2048 - sizeof(struct vmcb_save_area)];
+
+ u8 shared_buffer[2032];
+
+ u8 reserved_1[10];
+ u16 protocol_version; /* negotiated SEV-ES/GHCB protocol version */
+ u32 ghcb_usage;
};
static inline void __unused_size_checks(void)
{
- BUILD_BUG_ON(sizeof(struct vmcb_save_area) != 0x298);
+ BUILD_BUG_ON(sizeof(struct vmcb_save_area) != 1032);
BUILD_BUG_ON(sizeof(struct vmcb_control_area) != 256);
+ BUILD_BUG_ON(sizeof(struct ghcb) != 4096);
}
struct __attribute__ ((__packed__)) vmcb {
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 783330d0e7b8..953cf947f022 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4161,6 +4161,8 @@ static struct kvm_x86_init_ops svm_init_ops __initdata = {
static int __init svm_init(void)
{
+ __unused_size_checks();
+
return kvm_init(&svm_init_ops, sizeof(struct vcpu_svm),
__alignof__(struct vcpu_svm), THIS_MODULE);
}
--
2.17.1
[PATCH 1/2] f2fs: compress: add sanity check during compressed cluster read
From: Chao Yu
In f2fs_read_multi_pages(), we don't have to check cluster's type
again, since overwrite or partial truncation need page lock in
cluster which has already been held by reader, so cluster's type
is stable, let's change check condition to sanity check.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index bc89bc987513..c1b676be67b9 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2170,9 +2170,7 @@ int f2fs_read_multi_pages(struct compress_ctx *cc, struct
bio **bio_ret,
if (ret)
goto out;
- /* cluster was overwritten as normal cluster */
- if (dn.data_blkaddr != COMPRESS_ADDR)
- goto out;
+ f2fs_bug_on(sbi, dn.data_blkaddr != COMPRESS_ADDR);
for (i = 1; i < cc->cluster_size; i++) {
block_t blkaddr;
--
2.22.0
Re: [PATCH v1] farsync: use generic power management
On Wed, Jul 29, 2020 at 07:29:54AM -0500, Bjorn Helgaas wrote: > On Wed, Jul 29, 2020 at 03:47:30PM +0530, Vaibhav Gupta wrote: > > > > Agreed. Actually, as their presence only causes PCI core to call > > pci_legacy_suspend/resume() for them, I thought that after removing > > the binding from "struct pci_driver", this driver qualifies to be > > grouped under genric framework, so used "use generic power > > management" for the heading. > > > > I should have written "remove legacy bindning". > > This removed the *mention* of fst_driver.suspend and fst_driver.resume, > which is important because we want to eventually remove those members > completely from struct pci_driver. > > But fst_driver.suspend and fst_driver.resume *exist* before and after > this patch, and they're initialized to zero before and after this > patch. > > Since they were zero before, and they're still zero after this patch, > the PCI core doesn't call pci_legacy_suspend/resume(). This patch > doesn't change that at all. > Got it. Thanks :) > > But David has applied the patch, should I send a v2 or fix to update > > message? > > No, I don't think David updates patches after he's applied them. But > if the situation comes up again, you'll know how to describe it :) > Thanks a lot. :D Vaibhav Gupta > Bjorn
[PATCH 1/4] KVM: SVM: nested: Don't allocate VMCB structures on stack
From: Joerg Roedel
Do not allocate a vmcb_control_area and a vmcb_save_area on the stack,
as these structures will become larger with future extenstions of
SVM and thus the svm_set_nested_state() function will become a too large
stack frame.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm/nested.c | 44 ++-
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index 61378a3c2ce4..f3c3c4e1ca7f 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -1061,8 +1061,9 @@ static int svm_set_nested_state(struct kvm_vcpu *vcpu,
struct vmcb *hsave = svm->nested.hsave;
struct vmcb __user *user_vmcb = (struct vmcb __user *)
&user_kvm_nested_state->data.svm[0];
- struct vmcb_control_area ctl;
- struct vmcb_save_area save;
+ struct vmcb_control_area *ctl;
+ struct vmcb_save_area *save;
+ int ret;
u32 cr0;
if (kvm_state->format != KVM_STATE_NESTED_FORMAT_SVM)
@@ -1096,13 +1097,22 @@ static int svm_set_nested_state(struct kvm_vcpu *vcpu,
return -EINVAL;
if (kvm_state->size < sizeof(*kvm_state) +
KVM_STATE_NESTED_SVM_VMCB_SIZE)
return -EINVAL;
- if (copy_from_user(&ctl, &user_vmcb->control, sizeof(ctl)))
- return -EFAULT;
- if (copy_from_user(&save, &user_vmcb->save, sizeof(save)))
- return -EFAULT;
- if (!nested_vmcb_check_controls(&ctl))
- return -EINVAL;
+ ret = -ENOMEM;
+ ctl = kzalloc(sizeof(*ctl), GFP_KERNEL);
+ save = kzalloc(sizeof(*save), GFP_KERNEL);
+ if (!ctl || !save)
+ goto out_free;
+
+ ret = -EFAULT;
+ if (copy_from_user(ctl, &user_vmcb->control, sizeof(ctl)))
+ goto out_free;
+ if (copy_from_user(save, &user_vmcb->save, sizeof(save)))
+ goto out_free;
+
+ ret = -EINVAL;
+ if (!nested_vmcb_check_controls(ctl))
+ goto out_free;
/*
* Processor state contains L2 state. Check that it is
@@ -1110,15 +1120,15 @@ static int svm_set_nested_state(struct kvm_vcpu *vcpu,
*/
cr0 = kvm_read_cr0(vcpu);
if (((cr0 & X86_CR0_CD) == 0) && (cr0 & X86_CR0_NW))
-return -EINVAL;
+goto out_free;
/*
* Validate host state saved from before VMRUN (see
* nested_svm_check_permissions).
* TODO: validate reserved bits for all saved state.
*/
- if (!(save.cr0 & X86_CR0_PG))
- return -EINVAL;
+ if (!(save->cr0 & X86_CR0_PG))
+ goto out_free;
/*
* All checks done, we can enter guest mode. L1 control fields
@@ -1127,15 +1137,21 @@ static int svm_set_nested_state(struct kvm_vcpu *vcpu,
* contains saved L1 state.
*/
copy_vmcb_control_area(&hsave->control, &svm->vmcb->control);
- hsave->save = save;
+ hsave->save = *save;
svm->nested.vmcb = kvm_state->hdr.svm.vmcb_pa;
- load_nested_vmcb_control(svm, &ctl);
+ load_nested_vmcb_control(svm, ctl);
nested_prepare_vmcb_control(svm);
out_set_gif:
svm_set_gif(svm, !!(kvm_state->flags & KVM_STATE_NESTED_GIF_SET));
- return 0;
+
+ ret = 0;
+out_free:
+ kfree(save);
+ kfree(ctl);
+
+ return ret;
}
struct kvm_x86_nested_ops svm_nested_ops = {
--
2.17.1
[PATCH 2/2] f2fs: compress: disable compression mount option if compression is off
From: Chao Yu
If CONFIG_F2FS_FS_COMPRESSION is off, don't allow to configure or
show compression related mount option.
Signed-off-by: Chao Yu
---
fs/f2fs/super.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 5e0a3eeb8ca4..cdca2087dba0 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -460,9 +460,12 @@ static int parse_options(struct super_block *sb, char
*options, bool is_remount)
{
struct f2fs_sb_info *sbi = F2FS_SB(sb);
substring_t args[MAX_OPT_ARGS];
+#ifdef CONFIG_F2FS_FS_COMPRESSION
unsigned char (*ext)[F2FS_EXTENSION_LEN];
+ int ext_cnt;
+#endif
char *p, *name;
- int arg = 0, ext_cnt;
+ int arg = 0;
kuid_t uid;
kgid_t gid;
int ret;
@@ -853,6 +856,7 @@ static int parse_options(struct super_block *sb, char
*options, bool is_remount)
case Opt_checkpoint_enable:
clear_opt(sbi, DISABLE_CHECKPOINT);
break;
+#ifdef CONFIG_F2FS_FS_COMPRESSION
case Opt_compress_algorithm:
if (!f2fs_sb_has_compression(sbi)) {
f2fs_err(sbi, "Compression feature if off");
@@ -918,6 +922,13 @@ static int parse_options(struct super_block *sb, char
*options, bool is_remount)
F2FS_OPTION(sbi).compress_ext_cnt++;
kfree(name);
break;
+#else
+ case Opt_compress_algorithm:
+ case Opt_compress_log_size:
+ case Opt_compress_extension:
+ f2fs_info(sbi, "compression options not supported");
+ break;
+#endif
default:
f2fs_err(sbi, "Unrecognized mount option \"%s\" or
missing value",
p);
@@ -1608,7 +1619,9 @@ static int f2fs_show_options(struct seq_file *seq, struct
dentry *root)
else if (F2FS_OPTION(sbi).fsync_mode == FSYNC_MODE_NOBARRIER)
seq_printf(seq, ",fsync_mode=%s", "nobarrier");
+#ifdef CONFIG_F2FS_FS_COMPRESSION
f2fs_show_compress_options(seq, sbi->sb);
+#endif
return 0;
}
--
2.22.0
[PATCH 3/4] KVM: SVM: Add GHCB Accessor functions
From: Joerg Roedel
Building a correct GHCB for the hypervisor requires setting valid bits
in the GHCB. Simplify that process by providing accessor functions to
set values and to update the valid bitmap.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/svm.h | 61 ++
1 file changed, 61 insertions(+)
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 9a3e0b802716..0420250b008b 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -341,4 +341,65 @@ struct __attribute__ ((__packed__)) vmcb {
#define SVM_CR0_SELECTIVE_MASK (X86_CR0_TS | X86_CR0_MP)
+/* GHCB Accessor functions */
+
+#define DEFINE_GHCB_INDICES(field) \
+ u16 idx = offsetof(struct vmcb_save_area, field) / 8; \
+ u16 byte_idx = idx / 8;\
+ u16 bit_idx = idx % 8;\
+ BUILD_BUG_ON(byte_idx > ARRAY_SIZE(ghcb->save.valid_bitmap));
+
+#define GHCB_SET_VALID(ghcb, field)\
+ { \
+ DEFINE_GHCB_INDICES(field) \
+ (ghcb)->save.valid_bitmap[byte_idx] |= BIT(bit_idx);\
+ }
+
+#define DEFINE_GHCB_SETTER(field) \
+ static inline void \
+ ghcb_set_##field(struct ghcb *ghcb, u64 value) \
+ { \
+ GHCB_SET_VALID(ghcb, field) \
+ (ghcb)->save.field = value; \
+ }
+
+#define DEFINE_GHCB_ACCESSORS(field) \
+ static inline bool ghcb_is_valid_##field(const struct ghcb *ghcb)
\
+ { \
+ DEFINE_GHCB_INDICES(field) \
+ return !!((ghcb)->save.valid_bitmap[byte_idx] \
+ & BIT(bit_idx));\
+ } \
+ \
+ static inline void \
+ ghcb_set_##field(struct ghcb *ghcb, u64 value) \
+ { \
+ GHCB_SET_VALID(ghcb, field) \
+ (ghcb)->save.field = value; \
+ }
+
+DEFINE_GHCB_ACCESSORS(cpl)
+DEFINE_GHCB_ACCESSORS(rip)
+DEFINE_GHCB_ACCESSORS(rsp)
+DEFINE_GHCB_ACCESSORS(rax)
+DEFINE_GHCB_ACCESSORS(rcx)
+DEFINE_GHCB_ACCESSORS(rdx)
+DEFINE_GHCB_ACCESSORS(rbx)
+DEFINE_GHCB_ACCESSORS(rbp)
+DEFINE_GHCB_ACCESSORS(rsi)
+DEFINE_GHCB_ACCESSORS(rdi)
+DEFINE_GHCB_ACCESSORS(r8)
+DEFINE_GHCB_ACCESSORS(r9)
+DEFINE_GHCB_ACCESSORS(r10)
+DEFINE_GHCB_ACCESSORS(r11)
+DEFINE_GHCB_ACCESSORS(r12)
+DEFINE_GHCB_ACCESSORS(r13)
+DEFINE_GHCB_ACCESSORS(r14)
+DEFINE_GHCB_ACCESSORS(r15)
+DEFINE_GHCB_ACCESSORS(sw_exit_code)
+DEFINE_GHCB_ACCESSORS(sw_exit_info_1)
+DEFINE_GHCB_ACCESSORS(sw_exit_info_2)
+DEFINE_GHCB_ACCESSORS(sw_scratch)
+DEFINE_GHCB_ACCESSORS(xcr0)
+
#endif
--
2.17.1
[PATCH 0/4] KVM: SVM: SEV-ES groundwork
Hi Paolo, here are some groundwork patches for the upcoming SEV-ES support in the Linux kernel. They are part of both the client patch-set and of the KVM hypervisor patches (under development). Patch 1 necesary to fix a compile warning about a stack-frame getting too large. The other 3 patches are currently posted as part of the SEV-ES client patch-set. It would be great if you could consider them for v5.9, so that the client and the hypervisor patch-sets can be developed more independently of each other. Please let me know what you think. Regards, Joerg Borislav Petkov (1): KVM: SVM: Use __packed shorthand Joerg Roedel (2): KVM: SVM: nested: Don't allocate VMCB structures on stack KVM: SVM: Add GHCB Accessor functions Tom Lendacky (1): KVM: SVM: Add GHCB definitions arch/x86/include/asm/svm.h | 118 ++--- arch/x86/kvm/svm/nested.c | 44 +- arch/x86/kvm/svm/svm.c | 2 + 3 files changed, 143 insertions(+), 21 deletions(-) -- 2.17.1
Re: [Linux-kernel-mentees] [PATCH v2] block/floppy: Prevent kernel-infoleak in raw_cmd_copyout()
On 7/29/20 3:58 PM, Dan Carpenter wrote:
> Argh... This isn't right still. The "ptr" comes from raw_cmd_copyin()
>
> ptr = kmalloc(sizeof(struct floppy_raw_cmd), GFP_KERNEL);
>
copy_from_user overwrites the padding bytes:
ptr = kmalloc(sizeof(struct floppy_raw_cmd), GFP_KERNEL);
if (!ptr)
return -ENOMEM;
*rcmd = ptr;
ret = copy_from_user(ptr, param, sizeof(*ptr));
I think memcpy should be safe in this patch.
I've decided to dig a bit into the issue and to run some tests.
Here are my observations:
$ cat test.c
#include
#include
#define __user
struct floppy_raw_cmd {
unsigned int flags;
void __user *data;
char *kernel_data; /* location of data buffer in the kernel */
struct floppy_raw_cmd *next; /* used for chaining of raw cmd's
* within the kernel */
long length; /* in: length of dma transfer. out: remaining bytes */
long phys_length; /* physical length, if different from dma length */
int buffer_length; /* length of allocated buffer */
unsigned char rate;
#define FD_RAW_CMD_SIZE 16
#define FD_RAW_REPLY_SIZE 16
#define FD_RAW_CMD_FULLSIZE (FD_RAW_CMD_SIZE + 1 + FD_RAW_REPLY_SIZE)
unsigned char cmd_count;
union {
struct {
unsigned char cmd[FD_RAW_CMD_SIZE];
unsigned char reply_count;
unsigned char reply[FD_RAW_REPLY_SIZE];
};
unsigned char fullcmd[FD_RAW_CMD_FULLSIZE];
};
int track;
int resultcode;
int reserved1;
int reserved2;
};
void __attribute__((noinline)) stack_alloc()
{
struct floppy_raw_cmd stack;
memset(&stack, 0xff, sizeof(struct floppy_raw_cmd));
asm volatile ("" ::: "memory");
}
int __attribute__((noinline)) test(struct floppy_raw_cmd *ptr)
{
struct floppy_raw_cmd cmd = *ptr;
int i;
for (i = 0; i < sizeof(struct floppy_raw_cmd); ++i) {
if (((char *)&cmd)[i]) {
printf("leak[%d]\n", i);
return i;
}
}
return 0;
}
int main(int argc, char *argv[])
{
struct floppy_raw_cmd zero;
memset(&zero, 0, sizeof(struct floppy_raw_cmd));
// For selfcheck uncomment:
// zero.resultcode = 1;
stack_alloc();
return test(&zero);
}
Next, I've prepared containers with gcc 4.8 5 6 7 8 9 10 versions with this
tool (https://github.com/a13xp0p0v/kernel-build-containers).
And checked for leaks on x86_64 with the script test.sh
$ cat test.sh
#!/bin/bash
for i in 4.8 5 6 7 8 9 10
do
./run_container.sh gcc-$i $(pwd)/src $(pwd)/out bash -c 'gcc test.c; ./a.out'
./run_container.sh gcc-$i $(pwd)/src $(pwd)/out bash -c 'gcc -O2 test.c;
./a.out'
./run_container.sh gcc-$i $(pwd)/src $(pwd)/out bash -c 'gcc -O3 test.c;
./a.out'
done
No leaks reported. Is it really possible this this kind of init, i.e. cmd =
*ptr?
https://lwn.net/Articles/417989/ (December 1, 2010).
GCC 4.9.4 released [2016-08-03]
Maybe this behavior changed.
https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2019/october/padding-the-struct-how-a-compiler-optimization-can-disclose-stack-memory/
Reports for >= 4.7, < 8.0 version. But I can't find a word about this
kind of inits: cmd = *ptr.
Thanks,
Denis
[PATCH 4/4] KVM: SVM: Use __packed shorthand
From: Borislav Petkov
Use the shorthand to make it more readable.
No functional changes.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/svm.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 0420250b008b..af91ced0f370 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -150,14 +150,14 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
#define SVM_NESTED_CTL_NP_ENABLE BIT(0)
#define SVM_NESTED_CTL_SEV_ENABLE BIT(1)
-struct __attribute__ ((__packed__)) vmcb_seg {
+struct vmcb_seg {
u16 selector;
u16 attrib;
u32 limit;
u64 base;
-};
+} __packed;
-struct __attribute__ ((__packed__)) vmcb_save_area {
+struct vmcb_save_area {
struct vmcb_seg es;
struct vmcb_seg cs;
struct vmcb_seg ss;
@@ -231,9 +231,9 @@ struct __attribute__ ((__packed__)) vmcb_save_area {
u64 xcr0;
u8 valid_bitmap[16];
u64 x87_state_gpa;
-};
+} __packed;
-struct __attribute__ ((__packed__)) ghcb {
+struct ghcb {
struct vmcb_save_area save;
u8 reserved_save[2048 - sizeof(struct vmcb_save_area)];
@@ -242,7 +242,7 @@ struct __attribute__ ((__packed__)) ghcb {
u8 reserved_1[10];
u16 protocol_version; /* negotiated SEV-ES/GHCB protocol version */
u32 ghcb_usage;
-};
+} __packed;
static inline void __unused_size_checks(void)
@@ -252,11 +252,11 @@ static inline void __unused_size_checks(void)
BUILD_BUG_ON(sizeof(struct ghcb) != 4096);
}
-struct __attribute__ ((__packed__)) vmcb {
+struct vmcb {
struct vmcb_control_area control;
u8 reserved_control[1024 - sizeof(struct vmcb_control_area)];
struct vmcb_save_area save;
-};
+} __packed;
#define SVM_CPUID_FUNC 0x800a
--
2.17.1
Re: [PATCH v2 0/3] media: vimc: Allow multiple capture devices to use the same sensor
On 29.07.20 15:05, Kieran Bingham wrote: Hi Dafna, On 28/07/2020 15:00, Dafna Hirschfeld wrote: On 28.07.20 14:07, Dafna Hirschfeld wrote: Hi On 28.07.20 13:39, Kaaira Gupta wrote: On Mon, Jul 27, 2020 at 02:54:30PM -0300, Helen Koike wrote: Hi, On 7/27/20 11:31 AM, Kieran Bingham wrote: Hi all, +Dafna for the thread discussion, as she's missed from the to/cc list. On 24/07/2020 13:21, Kaaira Gupta wrote: On Fri, Jul 24, 2020 at 02:15:21PM +0200, Niklas Söderlund wrote: Hi, Hi Kaaira, Thanks for your work. Thanks for yours :D On 2020-07-24 17:32:10 +0530, Kaaira Gupta wrote: This is version 2 of the patch series posted by Niklas for allowing multiple streams in VIMC. The original series can be found here: https://patchwork.kernel.org/cover/10948831/ This series adds support for two (or more) capture devices to be connected to the same sensors and run simultaneously. Each capture device can be started and stopped independent of each other. Patch 1/3 and 2/3 deals with solving the issues that arises once two capture devices can be part of the same pipeline. While 3/3 allows for two capture devices to be part of the same pipeline and thus allows for simultaneously use. I wonder if these two patches are enough, since each vimc entity also have a 'process_frame' callback, but only one allocated frame. That means that the 'process_frame' can be called concurrently by two different streams on the same frame and cause corruption. I think we should somehow change the vimc-stream.c code so that we have only one stream process per pipe. So if one capture is already streaming, then the new capture that wants to stream uses the same thread so we don't have two threads both calling 'process_frame'. Yes, I think it looks and sounds like there are two threads running when there are two streams. so in effect, although they 'share a pipe', aren't they in effect just sending two separate buffers through their stream-path? If that's the case, then I don't think there's any frame corruption, because they would both have grabbed their own frame separately. But each entity allocates just one buffer. So the same buffer is used for both stream. What for example can happen is that the debayer of one stream can read the sensor's buffer while the sensor itself writes to the buffer for the other stream. Thanks, Dafna I don't think that's a good example of the hardware though, as that doesn't reflect what 'should' happen where the TPG runs once to generate a frame at the sensor, which is then read by both the debayer entity and the RAW capture device when there are two streams... So I suspect trying to move to a single thread is desirable, but that might be a fair bit of work also. -- Kieran The second capture that wants to stream should iterate the topology downwards until reaching an entity that already belong to the stream path of the other streaming capture and tell the streamer it wants to read the frames this entity produces. Thanks, Dafna Thanks, Dafna I'm just curious if you are aware of this series? It would replace the need for 1/3 and 2/3 of this series right? v3 of this series replaces the need for 1/3, but not the current version (ie v4). v4 of patch 2/5 removes the stream_counter that is needed to keep count of the calls to s_stream. Hence 1/3 becomes relevant again. So the question really is, how do we best make use of the two current series, to achieve our goal of supporting multiple streams. Having not parsed Dafna's series yet, do we need to combine elements of both ? Or should we work towards starting with this series and get dafna's patches built on top ? Or should patch 1/3 and 3/3 of this series be on top of Dafna's v4 ? (It might be noteworthy to say that Kaaira has reported successful multiple stream operation from /this/ series and her development branch on libcamera). Dafna's patch seems still under discussion, but I don't want to block progress in Vimc either. So I was wondering if we can move forward with Vimc support for multistreaming, without considering Dafna's patchset, and we can do the clean up later once we solve that. What do you think? I agree with supporting multiple streams with VIMC with this patchset, and then we can refactor the counters for s_stream in VIMC later (over this series) if dafna includes them in subsequent version of her patchset. I also think that adding support in the code will take much longer and should not stop us from supporting vimc independently. Thanks, Dafna Regards, Helen 1. https://lore.kernel.org/linux-media/20200522075522.6190-1-dafna.hirschf...@collabora.com/ Changes since v1: - All three patches rebased on latest media-tree. Patch 3: - Search for an entity with a non-NULL pipe instead of searching for sensor. This terminates the search at output itself. Kaaira Gupta (3): media: vimc: Add usage count to subdevices media: vimc: Serialize vimc_stream
[PATCH bpf-next v2] Documentation/bpf: Use valid and new links in index.rst
There exists an error "404 Not Found" when I click the html link of
"Documentation/networking/filter.rst" in the BPF documentation [1],
fix it.
Additionally, use the new links about "BPF and XDP Reference Guide"
and "bpf(2)" to avoid redirects.
[1] https://www.kernel.org/doc/html/latest/bpf/
Fixes: d9b9170a2653 ("docs: bpf: Rename README.rst to index.rst")
Fixes: cb3f0d56e153 ("docs: networking: convert filter.txt to ReST")
Signed-off-by: Tiezhu Yang
---
v2:
- Fix a typo "clik" to "click" in the commit message, sorry for that
Documentation/bpf/index.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst
index 26f4bb3..1b901b4 100644
--- a/Documentation/bpf/index.rst
+++ b/Documentation/bpf/index.rst
@@ -68,7 +68,7 @@ Testing and debugging BPF
.. Links:
-.. _Documentation/networking/filter.rst: ../networking/filter.txt
+.. _Documentation/networking/filter.rst: ../networking/filter.html
.. _man-pages: https://www.kernel.org/doc/man-pages/
-.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
-.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/
+.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
+.. _BPF and XDP Reference Guide: https://docs.cilium.io/en/latest/bpf/
--
2.1.0
Re: [PATCH v2 4/5] prctl: Hook L1D flushing in via prctl
On 7/28/20 7:11 PM, Balbir Singh wrote:
> Use the existing PR_GET/SET_SPECULATION_CTRL API to expose the L1D
> flush capability. For L1D flushing PR_SPEC_FORCE_DISABLE and
> PR_SPEC_DISABLE_NOEXEC are not supported.
>
> There is also no seccomp integration for the feature.
>
> Signed-off-by: Balbir Singh
> ---
> arch/x86/kernel/cpu/bugs.c | 54 ++
> arch/x86/mm/tlb.c | 25 +-
> include/uapi/linux/prctl.h | 1 +
> 3 files changed, 79 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 0b71970d2d3d..935ea88313ab 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -295,6 +295,13 @@ enum taa_mitigations {
> TAA_MITIGATION_TSX_DISABLED,
> };
>
> +enum l1d_flush_out_mitigations {
> + L1D_FLUSH_OUT_OFF,
> + L1D_FLUSH_OUT_ON,
> +};
> +
> +static enum l1d_flush_out_mitigations l1d_flush_out_mitigation
> __ro_after_init = L1D_FLUSH_OUT_ON;
> +
> /* Default mitigation for TAA-affected CPUs */
> static enum taa_mitigations taa_mitigation __ro_after_init =
> TAA_MITIGATION_VERW;
> static bool taa_nosmt __ro_after_init;
> @@ -378,6 +385,18 @@ static void __init taa_select_mitigation(void)
> pr_info("%s\n", taa_strings[taa_mitigation]);
> }
>
> +static int __init l1d_flush_out_parse_cmdline(char *str)
> +{
> + if (!boot_cpu_has_bug(X86_BUG_L1TF))
> + return 0;
Shouldn't this set the l1d_flush_out_mitigation to L1D_FLUSH_OUT_OFF since
it is set to L1D_FLUSH_OUT_ON by default? Or does it not matter because
the enable_l1d_flush_for_task() will return -EINVAL if the cpu doesn't
have the L1TF bug?
I guess it depends on what you want l1d_flush_out_prctl_set() and
l1d_flush_out_prctl_get() to return in this case.
Thanks,
Tom
> +
> + if (!strcmp(str, "off"))
> + l1d_flush_out_mitigation = L1D_FLUSH_OUT_OFF;
> +
> + return 0;
> +}
> +early_param("l1d_flush_out", l1d_flush_out_parse_cmdline);
> +
> static int __init tsx_async_abort_parse_cmdline(char *str)
> {
> if (!boot_cpu_has_bug(X86_BUG_TAA))
> @@ -1220,6 +1239,23 @@ static void task_update_spec_tif(struct task_struct
> *tsk)
> speculation_ctrl_update_current();
> }
>
> +static int l1d_flush_out_prctl_set(struct task_struct *task, unsigned long
> ctrl)
> +{
> +
> + if (l1d_flush_out_mitigation == L1D_FLUSH_OUT_OFF)
> + return -EPERM;
> +
> + switch (ctrl) {
> + case PR_SPEC_ENABLE:
> + return enable_l1d_flush_for_task(task);
> + case PR_SPEC_DISABLE:
> + return disable_l1d_flush_for_task(task);
> + default:
> + return -ERANGE;
> + }
> + return 0;
> +}
> +
> static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> {
> if (ssb_mode != SPEC_STORE_BYPASS_PRCTL &&
> @@ -1312,6 +1348,8 @@ int arch_prctl_spec_ctrl_set(struct task_struct *task,
> unsigned long which,
> return ssb_prctl_set(task, ctrl);
> case PR_SPEC_INDIRECT_BRANCH:
> return ib_prctl_set(task, ctrl);
> + case PR_SPEC_L1D_FLUSH_OUT:
> + return l1d_flush_out_prctl_set(task, ctrl);
> default:
> return -ENODEV;
> }
> @@ -1328,6 +1366,20 @@ void arch_seccomp_spec_mitigate(struct task_struct
> *task)
> }
> #endif
>
> +static int l1d_flush_out_prctl_get(struct task_struct *task)
> +{
> + int ret;
> +
> + if (l1d_flush_out_mitigation == L1D_FLUSH_OUT_OFF)
> + return PR_SPEC_FORCE_DISABLE;
> +
> + ret = test_ti_thread_flag(&task->thread_info, TIF_SPEC_L1D_FLUSH);
> + if (ret)
> + return PR_SPEC_PRCTL | PR_SPEC_ENABLE;
> + else
> + return PR_SPEC_PRCTL | PR_SPEC_DISABLE;
> +}
> +
> static int ssb_prctl_get(struct task_struct *task)
> {
> switch (ssb_mode) {
> @@ -1381,6 +1433,8 @@ int arch_prctl_spec_ctrl_get(struct task_struct *task,
> unsigned long which)
> return ssb_prctl_get(task);
> case PR_SPEC_INDIRECT_BRANCH:
> return ib_prctl_get(task);
> + case PR_SPEC_L1D_FLUSH_OUT:
> + return l1d_flush_out_prctl_get(task);
> default:
> return -ENODEV;
> }
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 48ccc3dd1492..77b739929ad2 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -316,8 +316,31 @@ EXPORT_SYMBOL_GPL(leave_mm);
>
> int enable_l1d_flush_for_task(struct task_struct *tsk)
> {
> + int cpu, ret = 0, i;
> +
> + /*
> + * Do not enable L1D_FLUSH_OUT if
> + * b. The CPU is not affected by the L1TF bug
> + * c. The CPU does not have L1D FLUSH feature support
> + * c. The task's affinity is on cores with SMT on.
> + */
> +
> + if (!boot_cpu_has_bug(X86_BUG_L1TF) ||
> + !static_cpu_has(X86_FEATURE_FLUSH_L1D))
> + return -EINVAL;
> +
> + cpu = get_cpu();
> +
> +
Re: [PATCH] platform/x86:dell-laptop:Add battery charging thresholds and charging mode switch.
> The values here seem very Dell specific, but this is going into a > generic sysfs path. Really stuff here should be as vendor independent as > possible. If these values don't correspond to a wider industry > specification it probably makes sense to make this something Dell > specific. Worth pointing out that for wilco-ec they use this path: Documentation/ABI/testing/sysfs-class-power-wilco So that could be something good to model off for v2.
Re: [PATCH v8 2/5] drm/imx: Add initial support for DCSS on iMX8MQ
Hi Laurentiu, On Fri, Jul 24, 2020 at 12:07:31PM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS). > Some of its capabilities include: > * 4K@60fps; > * HDR10; > * one graphics and 2 video pipelines; > * on-the-fly decompression of compressed video and graphics; > > The reference manual can be found here: > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM > > The current patch adds only basic functionality: one primary plane for > graphics, linear, tiled and super-tiled buffers support (no graphics > decompression yet), no HDR10 and no video planes. > > Video planes support and HDR10 will be added in subsequent patches once > per-plane de-gamma/CSC/gamma support is in. > > Signed-off-by: Laurentiu Palcu > Reviewed-by: Lucas Stach > --- > drivers/gpu/drm/imx/Kconfig| 2 + > drivers/gpu/drm/imx/Makefile | 1 + > drivers/gpu/drm/imx/dcss/Kconfig | 8 + > drivers/gpu/drm/imx/dcss/Makefile | 6 + > drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 70 +++ > drivers/gpu/drm/imx/dcss/dcss-crtc.c | 219 +++ > drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 + > drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++ > drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++ > drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 + > drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 + > drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 > drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++ > drivers/gpu/drm/imx/dcss/dcss-kms.h| 43 ++ > drivers/gpu/drm/imx/dcss/dcss-plane.c | 405 > drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 + > drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++ > 17 files changed, 3961 insertions(+) > create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig > create mode 100644 drivers/gpu/drm/imx/dcss/Makefile > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c > > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig > index 207bf7409dfb..6231048aa5aa 100644 > --- a/drivers/gpu/drm/imx/Kconfig > +++ b/drivers/gpu/drm/imx/Kconfig > @@ -39,3 +39,5 @@ config DRM_IMX_HDMI > depends on DRM_IMX > help > Choose this if you want to use HDMI on i.MX6. > + > +source "drivers/gpu/drm/imx/dcss/Kconfig" > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile > index 21cdcc2faabc..b644deffe948 100644 > --- a/drivers/gpu/drm/imx/Makefile > +++ b/drivers/gpu/drm/imx/Makefile > @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o > obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o > > obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o > +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/ > diff --git a/drivers/gpu/drm/imx/dcss/Kconfig > b/drivers/gpu/drm/imx/dcss/Kconfig > new file mode 100644 > index ..a76435924b6a > --- /dev/null > +++ b/drivers/gpu/drm/imx/dcss/Kconfig > @@ -0,0 +1,8 @@ > +config DRM_IMX_DCSS > + tristate "i.MX8MQ DCSS" > + select IMX_IRQSTEER > + select DRM_KMS_CMA_HELPER > + depends on DRM && ARCH_MXC I need a select VIDEOMODE_HELPERS here otherwise the build fails like LD .tmp_vmlinux.kallsyms1 aarch64-linux-gnu-ld: warning: -z norelro ignored aarch64-linux-gnu-ld: drivers/gpu/drm/imx/dcss/dcss-crtc.o: in function `dcss_crtc_atomic_enable': dcss-crtc.c:(.text+0x2a8): undefined reference to `drm_display_mode_to_videomode' make: *** [Makefile:1157: vmlinux] Error 1 on next-20200727. Cheers, -- Guido > + help > + Choose this if you have a NXP i.MX8MQ based system and want to use the > + Display Controller Subsystem. This option enables DCSS support. > diff --git a/drivers/gpu/drm/imx/dcss/Makefile > b/drivers/gpu/drm/imx/dcss/Makefile > new file mode 100644 > index ..8c7c8da42792 > --- /dev/null > +++ b/drivers/gpu/drm/imx/dcss/Makefile > @@ -0,0 +1,6 @@ > +imx-dcss-objs := dcss-drv.o dcss-dev.o dcss-blkctl.o dcss-ctxld.o dcss-dtg.o > \ > + dcss-ss.o dcss-dpr.o dcss-scaler.o dcss-kms.o > dcss-crtc.o \ > + dcss-plane.o > + > +obj-$(CONFIG_DRM_IMX_DCSS) += imx-dcss.o > + > diff --git a/drivers/gpu/drm/imx/dcss/dcss-blkctl
[PATCH bpf-next] Documentation/bpf: Use valid and new links in index.rst
There exists an error "404 Not Found" when I clik the html link of
"Documentation/networking/filter.rst" in the BPF documentation [1],
fix it.
Additionally, use the new links about "BPF and XDP Reference Guide"
and "bpf(2)" to avoid redirects.
[1] https://www.kernel.org/doc/html/latest/bpf/
Fixes: d9b9170a2653 ("docs: bpf: Rename README.rst to index.rst")
Fixes: cb3f0d56e153 ("docs: networking: convert filter.txt to ReST")
Signed-off-by: Tiezhu Yang
---
Documentation/bpf/index.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst
index 26f4bb3..1b901b4 100644
--- a/Documentation/bpf/index.rst
+++ b/Documentation/bpf/index.rst
@@ -68,7 +68,7 @@ Testing and debugging BPF
.. Links:
-.. _Documentation/networking/filter.rst: ../networking/filter.txt
+.. _Documentation/networking/filter.rst: ../networking/filter.html
.. _man-pages: https://www.kernel.org/doc/man-pages/
-.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
-.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/
+.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
+.. _BPF and XDP Reference Guide: https://docs.cilium.io/en/latest/bpf/
--
2.1.0
Re: [PATCH v2 2/3] sched: Cleanup SCHED_THERMAL_PRESSURE kconfig entry
On Tuesday 28 Jul 2020 at 17:16:57 (+0100), Valentin Schneider wrote: > We could change the arch Kconfig into > > select SCHED_THERMAL_PRESSURE if CPU_FREQ_THERMAL > > but that seems redundant; this dependency is already expressed in > SCHED_THERMAL_PRESSURE's definition. Is there a proper pattern to select > some Kconfig option only if all of its dependencies are met? How about something like this (totally untested): ---8<--- diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 939c4d6bbc2e..2ac74904a3ce 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -46,7 +46,6 @@ config ARM select EDAC_ATOMIC_SCRUB select GENERIC_ALLOCATOR select GENERIC_ARCH_TOPOLOGY if ARM_CPU_TOPOLOGY - select SCHED_THERMAL_PRESSURE if ARM_CPU_TOPOLOGY select GENERIC_ATOMIC64 if CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI select GENERIC_CLOCKEVENTS_BROADCAST if SMP select GENERIC_CPU_AUTOPROBE diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index c403e6f5db86..66dc41fd49f2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -192,7 +192,6 @@ config ARM64 select PCI_SYSCALL if PCI select POWER_RESET select POWER_SUPPLY - select SCHED_THERMAL_PRESSURE select SPARSE_IRQ select SWIOTLB select SYSCTL_EXCEPTION_TRACE diff --git a/init/Kconfig b/init/Kconfig index 0a97d85568b2..c2e1f3ac527e 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -493,6 +493,7 @@ config HAVE_SCHED_AVG_IRQ config SCHED_THERMAL_PRESSURE bool + default y if ARM64 || ARM_CPU_TOPOLOGY depends on SMP depends on CPU_FREQ_THERMAL help --->8--- Thanks, Quentin
[PATCH] atm: fix atm_dev refcnt leaks in atmtcp_remove_persistent
atmtcp_remove_persistent() invokes atm_dev_lookup(), which returns a
reference of atm_dev with increased refcount or NULL if fails.
The refcount leaks issues occur in two error handling paths. If
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL, the function
returns 0 without decreasing the refcount kept by a local variable,
resulting in refcount leaks.
Fix the issue by adding atm_dev_put() before returning 0 both when
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL.
Signed-off-by: Xin Xiong
Signed-off-by: Xiyu Yang
Signed-off-by: Xin Tan
---
drivers/atm/atmtcp.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/atmtcp.c b/drivers/atm/atmtcp.c
index d9fd70280482..7f814da3c2d0 100644
--- a/drivers/atm/atmtcp.c
+++ b/drivers/atm/atmtcp.c
@@ -433,9 +433,15 @@ static int atmtcp_remove_persistent(int itf)
return -EMEDIUMTYPE;
}
dev_data = PRIV(dev);
- if (!dev_data->persist) return 0;
+ if (!dev_data->persist) {
+ atm_dev_put(dev);
+ return 0;
+ }
dev_data->persist = 0;
- if (PRIV(dev)->vcc) return 0;
+ if (PRIV(dev)->vcc) {
+ atm_dev_put(dev);
+ return 0;
+ }
kfree(dev_data);
atm_dev_put(dev);
atm_dev_deregister(dev);
--
2.25.1
Re: [PATCH 1/3] dt-bindings: gpio: sunxi：create a DT header for Allwinner pin controller
Hi, On Sat, Jul 25, 2020 at 02:18:39PM -0500, Samuel Holland wrote: > On 7/17/20 11:07 AM, Maxime Ripard wrote: > > Hi! > > > > On Wed, Jul 15, 2020 at 07:54:12PM +0800, Frank Lee wrote: > >> From: Yangtao Li > >> > >> The sunxi gpio binding defines a few custom cells for its gpio specifier. > >> Provide bank name for those. > >> > >> Signed-off-by: Yangtao Li > > > > Thanks for working on this, I wanted to do it at some point but it kept > > getting pushed further into my todo list. > > > >> --- > >> include/dt-bindings/gpio/sunxi-gpio.h | 29 +++ > >> 1 file changed, 29 insertions(+) > >> create mode 100644 include/dt-bindings/gpio/sunxi-gpio.h > >> > >> diff --git a/include/dt-bindings/gpio/sunxi-gpio.h > >> b/include/dt-bindings/gpio/sunxi-gpio.h > >> new file mode 100644 > >> index ..c692b4360da6 > >> --- /dev/null > >> +++ b/include/dt-bindings/gpio/sunxi-gpio.h > > > > So generally we've been using the compatible name as the file name. You > > should follow that convention too, and since it was added with the A10, > > using the A10 compatible. > > > >> @@ -0,0 +1,29 @@ > >> +/* SPDX-License-Identifier: GPL-2.0 */ > >> +/* > >> + * GPIO definitions for Allwinner SoCs > >> + * > >> + * Copyright (C) 2020 Yangtao Li > >> + */ > >> + > >> +#ifndef _DT_BINDINGS_SUNXI_GPIO_H > >> +#define _DT_BINDINGS_SUNXI_GPIO_H > >> + > >> +#include > >> + > >> +/* pio */ > >> +#define PA0 > >> +#define PB1 > >> +#define PC2 > >> +#define PD3 > >> +#define PE4 > >> +#define PF5 > >> +#define PG6 > >> +#define PH7 > >> +#define PI8 > >> + > >> +/* r-pio */ > >> +#define PL0 > >> +#define PM1 > >> +#define PN2 > >> + > >> +#endif /* _DT_BINDINGS_SUNXI_GPIO_H */ > > > > Maybe we can go one step further and use a macro to have something like > > PIN(A, 12) ? > > Since we have separate cells for the bank and pin, I don't think it would be > appropriate to have a single macro generating both. Yeah, but it's "just" an encoding issue though, it's not a major concern if it makes our life easier. > And I'm not sure what the benefit of the macro would be, if all it > does is forward its arguments. Are you concerned that P[A-M] could > conflict with something else in the device tree? There's indeed a bunch of names that are fairly generic and could be conflicting with others (PD for power domain is the first one that comes to my mind). Using a prefix would make the GPIO descriptors pretty long, so it wasn't ideal either. A macro makes it readable without increasing too much the risks of conflicts Maxime signature.asc Description: PGP signature
Re: [PATCH v2 0/3] media: vimc: Allow multiple capture devices to use the same sensor
Hi Dafna, On 28/07/2020 15:00, Dafna Hirschfeld wrote: > > > On 28.07.20 14:07, Dafna Hirschfeld wrote: >> Hi >> >> On 28.07.20 13:39, Kaaira Gupta wrote: >>> On Mon, Jul 27, 2020 at 02:54:30PM -0300, Helen Koike wrote: Hi, On 7/27/20 11:31 AM, Kieran Bingham wrote: > Hi all, > > +Dafna for the thread discussion, as she's missed from the to/cc list. > > > On 24/07/2020 13:21, Kaaira Gupta wrote: >> On Fri, Jul 24, 2020 at 02:15:21PM +0200, Niklas Söderlund wrote: >> Hi, >> >>> Hi Kaaira, >>> >>> Thanks for your work. >> >> Thanks for yours :D >> >>> >>> On 2020-07-24 17:32:10 +0530, Kaaira Gupta wrote: This is version 2 of the patch series posted by Niklas for allowing multiple streams in VIMC. The original series can be found here: https://patchwork.kernel.org/cover/10948831/ This series adds support for two (or more) capture devices to be connected to the same sensors and run simultaneously. Each capture device can be started and stopped independent of each other. Patch 1/3 and 2/3 deals with solving the issues that arises once two capture devices can be part of the same pipeline. While 3/3 allows for two capture devices to be part of the same pipeline and thus allows for simultaneously use. >> >> I wonder if these two patches are enough, since each vimc entity also >> have >> a 'process_frame' callback, but only one allocated frame. That means >> that the 'process_frame' can be called concurrently by two different >> streams >> on the same frame and cause corruption. >> > > I think we should somehow change the vimc-stream.c code so that we have > only > one stream process per pipe. So if one capture is already streaming, > then the new > capture that wants to stream uses the same thread so we don't have two > threads > both calling 'process_frame'. Yes, I think it looks and sounds like there are two threads running when there are two streams. so in effect, although they 'share a pipe', aren't they in effect just sending two separate buffers through their stream-path? If that's the case, then I don't think there's any frame corruption, because they would both have grabbed their own frame separately. I don't think that's a good example of the hardware though, as that doesn't reflect what 'should' happen where the TPG runs once to generate a frame at the sensor, which is then read by both the debayer entity and the RAW capture device when there are two streams... So I suspect trying to move to a single thread is desirable, but that might be a fair bit of work also. -- Kieran > The second capture that wants to stream should iterate the topology > downwards until > reaching an entity that already belong to the stream path of the other > streaming capture > and tell the streamer it wants to read the frames this entity > produces. > > Thanks, > Dafna > >> Thanks, >> Dafna >> >>> >>> I'm just curious if you are aware of this series? It would >>> replace the >>> need for 1/3 and 2/3 of this series right? >> >> v3 of this series replaces the need for 1/3, but not the current >> version >> (ie v4). v4 of patch 2/5 removes the stream_counter that is needed to >> keep count of the calls to s_stream. Hence 1/3 becomes relevant >> again. > > So the question really is, how do we best make use of the two current > series, to achieve our goal of supporting multiple streams. > > Having not parsed Dafna's series yet, do we need to combine > elements of > both ? Or should we work towards starting with this series and get > dafna's patches built on top ? > > Or should patch 1/3 and 3/3 of this series be on top of Dafna's v4 ? > > (It might be noteworthy to say that Kaaira has reported successful > multiple stream operation from /this/ series and her development > branch > on libcamera). Dafna's patch seems still under discussion, but I don't want to block progress in Vimc either. So I was wondering if we can move forward with Vimc support for multistreaming, without considering Dafna's patchset, and we can do the clean up later once we solve that. What do you think? >>> >>> I agree with supporting multiple streams with VIMC with this patchset, >>> and then we can refactor the counters for s_stream in VIMC later (over >>> this series) if dafna includes them in subsequent version of her >>> patchset. >>> >> >> I also think that adding support in the code will take much longer and >> should not >> stop us from supporting vimc independently. >> >> Thanks, >> Dafna >> Regards, Helen > > >>> 1. >>> https://lore.kernel.org/linux-media/20200522075522.6190-1-dafna.hirschf...@collabora.com/ >>> >>>
Re: [PATCH v7 7/8] scsi: ufs: Move dumps in IRQ handler to error handler
Hi Asutosh,
On 2020-07-29 02:06, Asutosh Das (asd) wrote:
On 7/27/2020 10:00 PM, Can Guo wrote:
Sometime dumps in IRQ handler are heavy enough to cause system
stability
issues, move them to error handler.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c480823..b2bafa3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5682,6 +5682,21 @@ static void ufshcd_err_handler(struct
work_struct *work)
UFSHCD_UIC_DL_TCx_REPLAY_ERROR
needs_reset = true;
+ if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR |
+ UFSHCD_UIC_HIBERN8_MASK)) {
+ bool pr_prdt = !!(hba->saved_err & SYSTEM_BUS_FATAL_ERROR);
+
+ dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 0x%x\n",
+ __func__, hba->saved_err, hba->saved_uic_err);
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+ ufshcd_print_host_state(hba);
+ ufshcd_print_pwr_info(hba);
+ ufshcd_print_host_regs(hba);
+ ufshcd_print_tmrs(hba, hba->outstanding_tasks);
+ ufshcd_print_trs(hba, hba->outstanding_reqs, pr_prdt);
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ }
+
/*
* if host reset is required then skip clearing the pending
* transfers forcefully because they will get cleared during
@@ -5900,22 +5915,6 @@ static irqreturn_t ufshcd_check_errors(struct
ufs_hba *hba)
/* block commands from scsi mid-layer */
ufshcd_scsi_block_requests(hba);
-
- /* dump controller state before resetting */
- if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR)) {
- bool pr_prdt = !!(hba->saved_err &
- SYSTEM_BUS_FATAL_ERROR);
-
- dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err
0x%x\n",
- __func__, hba->saved_err,
- hba->saved_uic_err);
-
- ufshcd_print_host_regs(hba);
- ufshcd_print_pwr_info(hba);
How about keep the above prints and move the tmrs and trs to eh?
Sometimes in system instability, the eh may not get a chance to run
even. Still the above prints would provide some clues.
Here is the IRQ handler, ufshcd_print_host_regs() is sometime heavy
enough to cause stability issues during my fault injection test, since
it prints host regs, reg's history, crypto debug infos plus prints
from vops_dump.
How about just printing host regs and reg history here? Most time, these
infos are enough.
Thanks,
Can Guo.
- ufshcd_print_tmrs(hba, hba->outstanding_tasks);
- ufshcd_print_trs(hba, hba->outstanding_reqs,
- pr_prdt);
- }
ufshcd_schedule_eh_work(hba);
retval |= IRQ_HANDLED;
}
Re: [RFC PATCH 0/6] decrease unnecessary gap due to pmem kmem alignment
On 29.07.20 15:00, Mike Rapoport wrote: > On Wed, Jul 29, 2020 at 11:35:20AM +0200, David Hildenbrand wrote: >> On 29.07.20 11:31, Mike Rapoport wrote: >>> Hi Justin, >>> >>> On Wed, Jul 29, 2020 at 08:27:58AM +, Justin He wrote: Hi David >> >> Without this series, if qemu creates a 4G bytes nvdimm device, we can > only >> use 2G bytes for dax pmem(kmem) in the worst case. >> e.g. >> 24000-33fdf : Persistent Memory >> We can only use the memblock between [24000, 2] due to the > hard >> limitation. It wastes too much memory space. >> >> Decreasing the SECTION_SIZE_BITS on arm64 might be an alternative, but > there >> are too many concerns from other constraints, e.g. PAGE_SIZE, hugetlb, >> SPARSEMEM_VMEMMAP, page bits in struct page ... >> >> Beside decreasing the SECTION_SIZE_BITS, we can also relax the kmem > alignment >> with memory_block_size_bytes(). >> >> Tested on arm64 guest and x86 guest, qemu creates a 4G pmem device. dax > pmem >> can be used as ram with smaller gap. Also the kmem hotplug add/remove > are both >> tested on arm64/x86 guest. >> > > Hi, > > I am not convinced this use case is worth such hacks (that’s what it is) > for now. On real machines pmem is big - your example (losing 50% is > extreme). > > I would much rather want to see the section size on arm64 reduced. I > remember there were patches and that at least with a base page size of 4k > it can be reduced drastically (64k base pages are more problematic due to > the ridiculous THP size of 512M). But could be a section size of 512 is > possible on all configs right now. Yes, I once investigated how to reduce section size on arm64 thoughtfully: There are many constraints for reducing SECTION_SIZE_BITS 1. Given page->flags bits is limited, SECTION_SIZE_BITS can't be reduced too much. 2. Once CONFIG_SPARSEMEM_VMEMMAP is enabled, section id will not be counted into page->flags. 3. MAX_ORDER depends on SECTION_SIZE_BITS - 3.1 mmzone.h #if (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_SIZE_BITS #error Allocator MAX_ORDER exceeds SECTION_SIZE #endif - 3.2 hugepage_init() MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER); Hence when ARM64_4K_PAGES && CONFIG_SPARSEMEM_VMEMMAP are enabled, SECTION_SIZE_BITS can be reduced to 27. But when ARM64_64K_PAGES, given 3.2, MAX_ORDER > 29-16 = 13. Given 3.1 SECTION_SIZE_BITS >= MAX_ORDER+15 > 28. So SECTION_SIZE_BITS can not be reduced to 27. In one word, if we considered to reduce SECTION_SIZE_BITS on arm64, the Kconfig might be very complicated,e.g. we still need to consider the case for ARM64_16K_PAGES. >>> >>> It is not necessary to pollute Kconfig with that. >>> arch/arm64/include/asm/sparesemem.h can have something like >>> >>> #ifdef CONFIG_ARM64_64K_PAGES >>> #define SPARSE_SECTION_SIZE 29 >>> #elif defined(CONFIG_ARM16K_PAGES) >>> #define SPARSE_SECTION_SIZE 28 >>> #elif defined(CONFIG_ARM4K_PAGES) >>> #define SPARSE_SECTION_SIZE 27 >>> #else >>> #error >>> #endif >> >> ack >> >>> >>> There is still large gap with ARM64_64K_PAGES, though. >>> >>> As for SPARSEMEM without VMEMMAP, are there actual benefits to use it? >> >> I was asking myself the same question a while ago and didn't really find >> a compelling one. > > Memory overhead for VMEMMAP is larger, especially for arm64 that knows > how to free empty parts of the memory map with "classic" SPARSEMEM. You mean the hole punching within section memmap? (which is why their pfn_valid() implementation is special) (I do wonder why that shouldn't work with VMEMMAP, or is it simply not implemented?) > >> I think it's always enabled as default (SPARSEMEM_VMEMMAP_ENABLE) and >> would require config tweaks to even disable it. > > Nope, it's right there in menuconfig, > > "Memory Management options" -> "Sparse Memory virtual memmap" Ah, good to know. -- Thanks, David / dhildenb
Re: [PATCH v1 2/2] timer: mt6873: porting Mediatek timer driver to loadable module
Freddy,
Freddy Hsin writes:
again, please be more careful with subject lines. git log $FILE will
give you a hint.
> porting Mediatek timer driver to loadable module
Repeating the sentence in the subject line is not giving any
information. Also changelogs want to tell the WHY and not the WHAT. This
also lacks any information why this is actually safe when booting such a
system w/o this particular driver built in. What is early boot - up to
module load - using as clocksource and timer?
> diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
> index 9de7515..5504569 100644
> --- a/drivers/clocksource/mmio.c
> +++ b/drivers/clocksource/mmio.c
> @@ -21,6 +21,7 @@ u64 clocksource_mmio_readl_up(struct clocksource *c)
> {
> return (u64)readl_relaxed(to_mmio_clksrc(c)->reg);
> }
> +EXPORT_SYMBOL(clocksource_mmio_readl_up);
Again EXPORT_SYMBOL_GPL() and this wants to be a seperate patch. It has
absolutely no business with the mediatek timer changes.
> u64 clocksource_mmio_readl_down(struct clocksource *c)
> {
> @@ -46,7 +47,7 @@ u64 clocksource_mmio_readw_down(struct clocksource *c)
> * @bits:Number of valid bits
> * @read:One of clocksource_mmio_read*() above
> */
> -int __init clocksource_mmio_init(void __iomem *base, const char *name,
> +int clocksource_mmio_init(void __iomem *base, const char *name,
>
> unsigned long hz, int rating, unsigned bits,
> u64 (*read)(struct clocksource *))
> {
> @@ -68,3 +69,4 @@ int __init clocksource_mmio_init(void __iomem *base, const
> char *name,
>
> return clocksource_register_hz(&cs->clksrc, hz);
> }
> +EXPORT_SYMBOL(clocksource_mmio_init);
See above.
> diff --git a/drivers/clocksource/timer-mediatek.c
> b/drivers/clocksource/timer-mediatek.c
> index 9318edc..5c89b6b 100644
> --- a/drivers/clocksource/timer-mediatek.c
> +++ b/drivers/clocksource/timer-mediatek.c
> @@ -13,6 +13,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include "timer-of.h"
> @@ -309,5 +312,41 @@ static int __init mtk_gpt_init(struct device_node *node)
>
> return 0;
> }
> +
> +#ifdef MODULE
> +static int mtk_timer_probe(struct platform_device *pdev)
> +{
> + int (*timer_init)(struct device_node *node);
> + struct device_node *np = pdev->dev.of_node;
> +
> + timer_init = of_device_get_match_data(&pdev->dev);
> + return timer_init(np);
> +}
> +
> +static const struct of_device_id mtk_timer_match_table[] = {
> + {
> + .compatible = "mediatek,mt6577-timer",
> + .data = mtk_gpt_init,
> + },
> + {
> + .compatible = "mediatek,mt6765-timer",
> + .data = mtk_syst_init,
> + },
> + {}
> +};
> +
> +static struct platform_driver mtk_timer_driver = {
> + .probe = mtk_timer_probe,
> + .driver = {
> + .name = "mtk-timer",
> + .of_match_table = mtk_timer_match_table,
> + },
> +};
> +MODULE_DESCRIPTION("MEDIATEK Module timer driver");
> +MODULE_LICENSE("GPL v2");
> +
> +module_platform_driver(mtk_timer_driver);
> +#else
> TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_gpt_init);
> TIMER_OF_DECLARE(mtk_mt6765, "mediatek,mt6765-timer", mtk_syst_init);
> +#endif
Sorry no. This is not going to happen.
The above probe, match table and platform driver structs plus the module*
thingies are going to be repeated in every single driver which is going
to support module build. Tons of boilerplate copied over and over
again.
We had exactly the same before TIMER_OF_DECLARE() came around, so pretty
please this want's to be some smart macro which handles all of this
automatically.
Thanks,
tglx
Re: [RFC PATCH 0/6] decrease unnecessary gap due to pmem kmem alignment
On Wed, Jul 29, 2020 at 11:35:20AM +0200, David Hildenbrand wrote: > On 29.07.20 11:31, Mike Rapoport wrote: > > Hi Justin, > > > > On Wed, Jul 29, 2020 at 08:27:58AM +, Justin He wrote: > >> Hi David > > Without this series, if qemu creates a 4G bytes nvdimm device, we can > >>> only > use 2G bytes for dax pmem(kmem) in the worst case. > e.g. > 24000-33fdf : Persistent Memory > We can only use the memblock between [24000, 2] due to the > >>> hard > limitation. It wastes too much memory space. > > Decreasing the SECTION_SIZE_BITS on arm64 might be an alternative, but > >>> there > are too many concerns from other constraints, e.g. PAGE_SIZE, hugetlb, > SPARSEMEM_VMEMMAP, page bits in struct page ... > > Beside decreasing the SECTION_SIZE_BITS, we can also relax the kmem > >>> alignment > with memory_block_size_bytes(). > > Tested on arm64 guest and x86 guest, qemu creates a 4G pmem device. dax > >>> pmem > can be used as ram with smaller gap. Also the kmem hotplug add/remove > >>> are both > tested on arm64/x86 guest. > > >>> > >>> Hi, > >>> > >>> I am not convinced this use case is worth such hacks (that’s what it is) > >>> for now. On real machines pmem is big - your example (losing 50% is > >>> extreme). > >>> > >>> I would much rather want to see the section size on arm64 reduced. I > >>> remember there were patches and that at least with a base page size of 4k > >>> it can be reduced drastically (64k base pages are more problematic due to > >>> the ridiculous THP size of 512M). But could be a section size of 512 is > >>> possible on all configs right now. > >> > >> Yes, I once investigated how to reduce section size on arm64 thoughtfully: > >> There are many constraints for reducing SECTION_SIZE_BITS > >> 1. Given page->flags bits is limited, SECTION_SIZE_BITS can't be reduced > >> too > >>much. > >> 2. Once CONFIG_SPARSEMEM_VMEMMAP is enabled, section id will not be counted > >>into page->flags. > >> 3. MAX_ORDER depends on SECTION_SIZE_BITS > >> - 3.1 mmzone.h > >> #if (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_SIZE_BITS > >> #error Allocator MAX_ORDER exceeds SECTION_SIZE > >> #endif > >> - 3.2 hugepage_init() > >> MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER); > >> > >> Hence when ARM64_4K_PAGES && CONFIG_SPARSEMEM_VMEMMAP are enabled, > >> SECTION_SIZE_BITS can be reduced to 27. > >> But when ARM64_64K_PAGES, given 3.2, MAX_ORDER > 29-16 = 13. > >> Given 3.1 SECTION_SIZE_BITS >= MAX_ORDER+15 > 28. So SECTION_SIZE_BITS can > >> not > >> be reduced to 27. > >> > >> In one word, if we considered to reduce SECTION_SIZE_BITS on arm64, the > >> Kconfig > >> might be very complicated,e.g. we still need to consider the case for > >> ARM64_16K_PAGES. > > > > It is not necessary to pollute Kconfig with that. > > arch/arm64/include/asm/sparesemem.h can have something like > > > > #ifdef CONFIG_ARM64_64K_PAGES > > #define SPARSE_SECTION_SIZE 29 > > #elif defined(CONFIG_ARM16K_PAGES) > > #define SPARSE_SECTION_SIZE 28 > > #elif defined(CONFIG_ARM4K_PAGES) > > #define SPARSE_SECTION_SIZE 27 > > #else > > #error > > #endif > > ack > > > > > There is still large gap with ARM64_64K_PAGES, though. > > > > As for SPARSEMEM without VMEMMAP, are there actual benefits to use it? > > I was asking myself the same question a while ago and didn't really find > a compelling one. Memory overhead for VMEMMAP is larger, especially for arm64 that knows how to free empty parts of the memory map with "classic" SPARSEMEM. > I think it's always enabled as default (SPARSEMEM_VMEMMAP_ENABLE) and > would require config tweaks to even disable it. Nope, it's right there in menuconfig, "Memory Management options" -> "Sparse Memory virtual memmap" > -- > Thanks, > > David / dhildenb > -- Sincerely yours, Mike.
Re: [Linux-kernel-mentees] [PATCH v2] block/floppy: Prevent kernel-infoleak in raw_cmd_copyout()
Argh... This isn't right still. The "ptr" comes from raw_cmd_copyin() ptr = kmalloc(sizeof(struct floppy_raw_cmd), GFP_KERNEL); The struct hole could still be uninitialized from kmalloc() and instead of from the stack. Smatch is only looking for the common stack info leaks and doesn't worn about holes in kmalloc()ed memory. regards, dan carpenter
Re: [PATCH 0/2] locking/qspinlock: Break qspinlock_types.h header loop
On Wed, Jul 29, 2020 at 10:51:44PM +1000, Herbert Xu wrote: > On Wed, Jul 29, 2020 at 02:47:44PM +0200, pet...@infradead.org wrote: > > > > How did you run into this, I haven't seen any build failures due to > > this. > > I didn't, Stephen ran into it after merging the printk tree together > with the powerpc tree: > > https://lore.kernel.org/lkml/20200729210311.425d0...@canb.auug.org.au/ > > > Anyway, the patches look sane enough, I'll go stick them in > > tip/locking/core or somesuch. > > Perhaps add them on top of the other two patches in locking/header? Can do,
[PATCH] checkpatch: skip macros when finding missing switch/case break
The checkpatch.pl only searches 3 previous lines when finding missing
switch/case break, and macros are treated as normal statements. If the
cases are surrounded with CONFIG, checkpatch.pl may report false
warnings. For example:
\+#if xxx
\+ case xxx: {
\+ ...
\+ break/return/...;
\+ }
\+#endif
\+#if xxx
\+ case xxx:
\+ ...
\+#endif
This patch skips lines starting with whitespaces and #, so the counter
of previous statements won't increase in these cases.
Signed-off-by: Cambda Zhu
---
scripts/checkpatch.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4c820607540b..2c0a51ac82a7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6503,6 +6503,7 @@ sub process {
next if ($fline =~
/^.(?:\s*(?:case\s+(?:$Ident|$Constant)[\s$;]*|default):[\s$;]*)*$/);
$has_break = 1 if ($rline =~
/fall[\s_-]*(through|thru)/i);
next if ($fline =~ /^.[\s$;]*$/);
+ next if ($fline =~ /^.\s*#/);
$has_statement = 1;
$count++;
$has_break = 1 if ($fline =~
/\bswitch\b|\b(?:break\s*;[\s$;]*$|exit\s*\(\b|return\b|goto\b|continue\b)/);
--
2.16.6
Re: [PATCH 4/7] gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip
On Mon, Jul 27, 2020 at 12:22:28AM +0200, Linus Walleij wrote:
> On Sat, Jul 25, 2020 at 1:03 AM Serge Semin
> wrote:
>
> > According to the DW APB GPIO databook it can be configured to provide
> > either a
> > combined IRQ line or multiple interrupt signals for each GPIO. It's up to
> > the platform which of those signals are connected to an embedded IRQ
> > controller. So I guess theoretically the array values can be sparse.
> >
> > Anyway now I see it's rather problematic. I didn't forget about the sparse
> > IRQs
> > array case. I just thought it would work out-of-box. Before getting your
> > comment
> > and digging deeper into the IRQ subsystem I had thought that it wasn't a
> > problem
> > passing invalid IRQ numbers to the irq_set_chained_handler_and_data()
> > especially
> > seeing zero IRQ number was supposed to be considered as invalid. That
> > method shall
> > just ignore the invalid IRQs since the method irq_to_desc() calling
> > radix_tree_lookup()
> > will fail to find a descriptor with invalid IRQ value and return NULL. So
> > after
> > getting a NULL irq_desc the method irq_set_chained_handler_and_data() would
> > have stopped setting the handler. But turns out it may work only for
> > CONFIG_SPARSE_IRQ. If that config isn't enabled, then a very first IRQ
> > descriptor will be returned for zero IRQ number. That descriptor will be
> > initialized with the passed parent_handler callback, which isn't what we
> > want.
>
> Ouch but different beahviour on the outside of the irqchip API depending
> on whether IRQs are sparse or not on some particular system seems to
> be a problem with irqchip reallty, if we wanna get to the bottom of things.
> (paging Marc)
>
> > So in order to fix the problem we could follow either of the next paths:
> > 1) Just make sure the passed IRQs array is not sparse for instance by
> > remapping
> >it to be linear.
> > 2) Move "if (gc->irq.parents[i]) irq_set_chained_handler_and_data()"
> > statement to the
> >gpiochip_add_irqchip() method.
> >
> > What to you think? Linus?
>
> What about (3) fixing irqchip?
>
> Else (2), making the code inside gpiolib be careful and skip over
> invalid IRQs.
Sorry for a delay with a response to this issue. I had to give it a more
thorough
thought since the problem is a bit more complex than it seemed originally. As I
see it now It might be wrong to implement the cases 2) and 3), but 1) is more
appropriate.
First of all we need to note that GPIOlib framework provides the next parameters
to describe the IRQ-chip:
gc->irq.num_parents - number of parental IRQ numbers.
gc->irq.parents[] - array of parental IRQ numbers.
*gc->irq.valid_mask - a mask of IRQ/GPIO lines describing a valid IRQ.
*gc->irq.map - mapping of hw IRQ/GPIO ID -> parental IRQ numbers.
Using that set we can handle any case of linear and sparse parental IRQs. Here
is how it can be implemented in the framework of DW APB GPIO controller.
DW APB GPIO can be synthesized with two configs:
1) Combined IRQ line (GPIO_INTR_IO == True),
2) Multiple interrupt signals for each GPIO (GPIO_INTR_IO == False).
Obviously the former case is trivial:
IRQ_combined
__^
/_ _ _ _ _ ___ _\
|_|_|_|_|_|...|_| - GPIOs
In that case
gc->irq.num_parents = 1;
gc->irq.parents[0] = IRQ_combined;
*gc->irq.valid_mask = GENMASK(ngpio - 1, 0); // This is done by the GPIOlib
core itself.
The later one (when multiple interrupt signals are involved) can be a bit more
complicated. It can be also split up into two cases:
2a) One-on-one GPIO-IRQ mapping.
2b) Sparse GPIO-IRQ mapping.
It's straightforward to implement 2a):
i1i2i3i4i5 ... iN
_ _ _ _ _ ___ _
|_|_|_|_|_|...|_| - GPIOs
In that case
gc->irq.num_parents = ngpio;
gc->irq.parents[] = {i1, i2, i3, i4, i5, ... iN};
gc->irq.map = {i1, i2, i3, i4, i5, ... iN};
*gc->irq.valid_mask = GENMASK(ngpio - 1, 0);
The complication starts when we get to implementing 2b):
i1 xi3i4 x ... iN
_ _ _ _ _ ___ _
|_|_|_|_|_|...|_| - GPIOs
In order to cover this case we need to answer on two question.
Firstly how to get such platform config? I am not sure about ACPI, but
aside from straightforward platform_data-based setup such configuration
can be reached by setting up the "interrupts-extended" DT-property with
zeroed phandle.
Ok, since it's possible to meet such platform config, we need to think
how to handle it and here is the second question. How to describe such
case in the framework of GPIOlib-IRQchip?
So from my side it was wrong to set the sparse IRQs array to
gc->irq.parents. Instead I should have scanned the sparse IRQs array,
calculated the number of non-empty parental IRQs, created an array of linear
(non-sparse) IRQs, initialized *gc->irq.valid_mask in accordance with the
sparse parental IRQs array. In other words it was wrong to assume, that
each gc->irq.parents entry corresponds to the IRQ/GPIO line. The gc->irq.parents
array just describes the parental IRQs and nothing else.
Re: INFO: rcu detected stall in smp_call_function
On Wed, Jul 29, 2020 at 01:44:15AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:6ba1b005 Merge tag 'asm-generic-fixes-5.8' of git://git.ke..
Bit useless, having git://git.ke... there, that doesn't really narrow
things down.
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14da552290
> kernel config: https://syzkaller.appspot.com/x/.config?x=812bbfcb6ae2cd60
> dashboard link: https://syzkaller.appspot.com/bug?extid=cb3b69ae80afd6535b0e
> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/
> c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+cb3b69ae80afd6535...@syzkaller.appspotmail.com
>
> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1):
> [ cut here ]
> IRQs not enabled as expected
> WARNING: CPU: 0 PID: 32297 at kernel/sched/core.c:2701
> try_invoke_on_locked_down_task+0x18b/0x320 kernel/sched/core.c:2701
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 0 PID: 32297 Comm: syz-executor.2 Not tainted 5.8.0-rc7-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1f0/0x31e lib/dump_stack.c:118
> panic+0x264/0x7a0 kernel/panic.c:231
> __warn+0x227/0x250 kernel/panic.c:600
> report_bug+0x1b1/0x2e0 lib/bug.c:198
> handle_bug+0x42/0x80 arch/x86/kernel/traps.c:235
> exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:255
> asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:540
> RIP: 0010:try_invoke_on_locked_down_task+0x18b/0x320 kernel/sched/core.c:2701
> Code: 48 89 df e8 f7 35 09 00 4c 89 f7 e8 df b5 cf 06 e9 b5 00 00 00 c6 05 34
> 82 38 08 01 48 c7 c7 8c d7 07 89 31 c0 e8 a5 a9 f5 ff <0f> 0b e9 15 ff ff ff
> 48 c7 c1 30 71 8d 89 80 e1 07 80 c1 03 38 c1
> RSP: 0018:c9007c50 EFLAGS: 00010046
> RAX: 1aaa08be6903c500 RBX: 888085d16ac8 RCX: 888085d16240
> RDX: 00010004 RSI: 00010004 RDI:
> RBP: 888085d16b0c R08: 815dd389 R09: ed1015d041c3
> R10: ed1015d041c3 R11: R12:
> R13: 8880a8bac140 R14: 8880a8bac4c0 R15: dc00
> rcu_print_task_stall kernel/rcu/tree_stall.h:269 [inline]
> print_other_cpu_stall kernel/rcu/tree_stall.h:477 [inline]
Ha, that calls it with IRQs already disabled,
So I'm thinking we want something like so?
---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2142c6767682..3182caf14844 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2694,12 +2694,11 @@ try_to_wake_up(struct task_struct *p, unsigned int
state, int wake_flags)
*/
bool try_invoke_on_locked_down_task(struct task_struct *p, bool (*func)(struct
task_struct *t, void *arg), void *arg)
{
- bool ret = false;
struct rq_flags rf;
+ bool ret = false;
struct rq *rq;
- lockdep_assert_irqs_enabled();
- raw_spin_lock_irq(&p->pi_lock);
+ raw_spin_lock_irqsave(&p->pi_lock, rf.flags);
if (p->on_rq) {
rq = __task_rq_lock(p, &rf);
if (task_rq(p) == rq)
@@ -2716,7 +2715,7 @@ bool try_invoke_on_locked_down_task(struct task_struct
*p, bool (*func)(struct t
ret = func(p, arg);
}
}
- raw_spin_unlock_irq(&p->pi_lock);
+ raw_spin_unlock_irqrestore(&p->pi_lock, rf.flags);
return ret;
}
Re: [PATCH 0/7] Optimization to improve cpu online/offline on Powerpc
On Mon, Jul 27, 2020 at 01:25:25PM +0530, Srikar Dronamraju wrote: > Anton reported that his 4096 cpu (1024 cores in a socket) was taking too > long to boot. He also analyzed that most of the time was being spent on > updating cpu_core_mask. > > Here are some optimizations and fixes to make ppc64_cpu --smt=8/ppc64_cpu > --smt=1 run faster and hence boot the kernel also faster. > > Its based on top of my v4 coregroup support patchset. > http://lore.kernel.org/lkml/20200727053230.19753-1-sri...@linux.vnet.ibm.com/t/#u > > The first two patches should solve Anton's immediate problem. > On the unofficial patches, Anton reported that the boot time came from 30 > mins to 6 seconds. (Basically a high core count in a single socket > configuration). Satheesh also reported similar numbers. > > The rest are simple cleanups/optimizations. > > Since cpu_core_mask is an exported symbol for a long duration, lets retain > as a snapshot of cpumask_of_node. boot tested on P9 KVM guest. without this series: # dmesg|grep smp [0.066624] smp: Bringing up secondary CPUs ... [ 347.521264] smp: Brought up 1 node, 2048 CPUs with this series: # dmesg|grep smp [0.067744] smp: Bringing up secondary CPUs ... [5.416910] smp: Brought up 1 node, 2048 CPUs Tested-by: Satheesh Rajendran Regards, -Satheesh > > Architecture:ppc64le > Byte Order: Little Endian > CPU(s): 160 > On-line CPU(s) list: 0-159 > Thread(s) per core: 4 > Core(s) per socket: 20 > Socket(s): 2 > NUMA node(s):2 > Model: 2.2 (pvr 004e 1202) > Model name: POWER9, altivec supported > CPU max MHz: 3800. > CPU min MHz: 2166. > L1d cache: 32K > L1i cache: 32K > L2 cache:512K > L3 cache:10240K > NUMA node0 CPU(s): 0-79 > NUMA node8 CPU(s): 80-159 > > without patch (powerpc/next) > [0.099347] smp: Bringing up secondary CPUs ... > [0.832513] smp: Brought up 2 nodes, 160 CPUs > > with powerpc/next + coregroup support patchset > [0.099241] smp: Bringing up secondary CPUs ... > [0.835627] smp: Brought up 2 nodes, 160 CPUs > > with powerpc/next + coregroup + this patchset > [0.097232] smp: Bringing up secondary CPUs ... > [0.528457] smp: Brought up 2 nodes, 160 CPUs > > x ppc64_cpu --smt=1 > + ppc64_cpu --smt=4 > > without patch > N Min MaxMedian AvgStddev > x 100 11.82 17.06 14.01 14.05 1.2665247 > + 100 12.25 16.59 13.86 14.1143 1.164293 > > with patch > N Min MaxMedian AvgStddev > x 100 12.68 16.15 14.2414.2380.75489246 > + 100 12.93 15.85 14.35 14.28970.60041813 > > Cc: linuxppc-dev > Cc: LKML > Cc: Michael Ellerman > Cc: Nicholas Piggin > Cc: Anton Blanchard > Cc: Oliver O'Halloran > Cc: Nathan Lynch > Cc: Michael Neuling > Cc: Gautham R Shenoy > Cc: Satheesh Rajendran > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Valentin Schneider > > Srikar Dronamraju (7): > powerpc/topology: Update topology_core_cpumask > powerpc/smp: Stop updating cpu_core_mask > powerpc/smp: Remove get_physical_package_id > powerpc/smp: Optimize remove_cpu_from_masks > powerpc/smp: Limit cpus traversed to within a node. > powerpc/smp: Stop passing mask to update_mask_by_l2 > powerpc/smp: Depend on cpu_l1_cache_map when adding cpus > > arch/powerpc/include/asm/smp.h | 5 -- > arch/powerpc/include/asm/topology.h | 7 +-- > arch/powerpc/kernel/smp.c | 79 + > 3 files changed, 24 insertions(+), 67 deletions(-) > > -- > 2.17.1 >
Re: [PATCH 1/1] vt_ioctl: prevent VT_RESIZEX font height change from causing potential out-of-bounds access
On Wed, Jul 29, 2020 at 08:39:41AM -0400, George Kennedy wrote: > Add a VT_RESIZEX check to ensure that changing the font height will not > cause a potential out-of-bounds access. The candidate font height contained > in "v_clin", though below the max, could still result in accesses beyond > the allocated font data size. > > Signed-off-by: George Kennedy > Reported-by: syzbot+38a3699c7eaf165b9...@syzkaller.appspotmail.com Did syzbot also test this that it fixes the reported issue? What commit does this fix? Should it go back farther to stable releases too? thanks, greg k-h
Re: [PATCH 0/2] locking/qspinlock: Break qspinlock_types.h header loop
On Wed, Jul 29, 2020 at 02:47:44PM +0200, pet...@infradead.org wrote: > > How did you run into this, I haven't seen any build failures due to > this. I didn't, Stephen ran into it after merging the printk tree together with the powerpc tree: https://lore.kernel.org/lkml/20200729210311.425d0...@canb.auug.org.au/ > Anyway, the patches look sane enough, I'll go stick them in > tip/locking/core or somesuch. Perhaps add them on top of the other two patches in locking/header? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V4] Softirq:avoid large sched delay from the pending softirqs
On Wed, Jul 29, 2020 at 8:16 PM Thomas Gleixner wrote: > > Qian, > > jun qian writes: > > On Mon, Jul 27, 2020 at 11:41 PM Thomas Gleixner wrote: > >> > + or_softirq_pending(pending << (vec_nr + 1)); > >> > >> To or the value interrupts need to be disabled because otherwise you can > >> lose a bit when an interrupt happens in the middle of the RMW operation > >> and raises a softirq which is not in @pending and not in the per CPU > >> local softirq pending storage. > >> > > I can't understand the problem described above, could you explain in > > detail. > > Oring a value to a memory location is a Read Modify Write (RMW) > operation. > > x |= a; > > translates to pseudo code: > > R1 = x // Load content of memory location x into register R1 > R1 |= a // Or value a on R1 > x = R1 // Write back result > > So assume: > >x = 0 >a = 1 > >R1 = x --> R1 == 0 >R1 |= a --> R1 == 1 > > interrupt sets bit 1 in x --> x == 0x02 > >x = R1 --> x == 1 > > So you lost the set bit 1, right? Not really what you want. > wow, thanks a lot, i got it. > >> There is another problem. Assume bit 0 and 1 are pending when the > >> processing starts. Now it breaks out after bit 0 has been handled and > >> stores back bit 1 as pending. Before ksoftirqd runs bit 0 gets raised > >> again. ksoftirqd runs and handles bit 0, which takes more than the > >> timeout. As a result the bit 0 processing can starve all other softirqs. > >> > > May I use a percpu val to record the order of processing softirq, by the > > order > > val, when it is in ksoftirqd we can process the pending softirq in order. > > In the > > scenario you described above, before ksoftirqd runs, bit 0 gets raised > > again, > > ksoftirqd runs and handles bit 1 by the percpu val. just like a ring. > > Yes, you need something to save information about the not-processed > bits. Keeping track of which bit to process next works, but whether > that's going to result in efficient and simple code is a different > question. > ok, i will modify it in the next version. > Thanks, > > tglx >
[PATCH V2] dmaengine: bcm-sba-raid: add missing put_device() call in sba_probe()
if of_find_device_by_node() succeed, sba_probe() doesn't have a
corresponding put_device(). Thus add a jump target to fix the
exception handling for this function implementation.
Fixes: 743e1c8ffe4e ("dmaengine: Add Broadcom SBA RAID driver")
Signed-off-by: Yu Kuai
---
changes from V1:
-forgot to add params in put_device(), sorry about that.
drivers/dma/bcm-sba-raid.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
index 64239da02e74..322d48b397e7 100644
--- a/drivers/dma/bcm-sba-raid.c
+++ b/drivers/dma/bcm-sba-raid.c
@@ -1707,7 +1707,7 @@ static int sba_probe(struct platform_device *pdev)
/* Prealloc channel resource */
ret = sba_prealloc_channel_resources(sba);
if (ret)
- goto fail_free_mchan;
+ goto put_device;
/* Check availability of debugfs */
if (!debugfs_initialized())
@@ -1737,6 +1737,8 @@ static int sba_probe(struct platform_device *pdev)
fail_free_resources:
debugfs_remove_recursive(sba->root);
sba_freeup_channel_resources(sba);
+put_device:
+ put_device(&mbox_pdev->dev);
fail_free_mchan:
mbox_free_channel(sba->mchan);
return ret;
--
2.25.4
Re: [PATCH 0/2] locking/qspinlock: Break qspinlock_types.h header loop
On Wed, Jul 29, 2020 at 10:28:07PM +1000, Herbert Xu wrote: > This miniseries breaks a header loop involving qspinlock_types.h. > The issue is that qspinlock_types.h includes atomic.h, which then > eventually includes kernel.h which could lead back to the original > file via spinlock_types.h. How did you run into this, I haven't seen any build failures due to this. > The first patch moves ATOMIC_INIT into linux/types.h while the second > patch actuallys breaks the loop by no longer including atomic.h > in qspinlock_types.h. Anyway, the patches look sane enough, I'll go stick them in tip/locking/core or somesuch.
Re: [PATCH v1 1/2] kernel: time: export sched_clock_register function
Freddy,
Freddy Hsin writes:
please do not come up with random prefixes. Just look at the topmost two
commits on that file:
2c8bd58812ee ("time/sched_clock: Expire timer in hardirq context")
2707745533d6 ("time/sched_clock: Disable interrupts in sched_clock_register()")
Also the sentence after the colon starts with an uppercase letter.
Please change 'sched_clock_register function' to
'sched_clock_register()' which makes it clear that this is a function
> export sched_clock_register function, because the Mediatek timer
> loadable module depends on this function
Again sentences start with an uppercase letter. Also the reason for
exporting this is wrong. There is no mediatek timer module now.
The point of exporting this (if at all) is that it's required for any
ARM SoC timer driver to be modularized.
> @@ -239,6 +239,7 @@ static enum hrtimer_restart sched_clock_poll(struct
> hrtimer *hrt)
>
> pr_debug("Registered %pS as sched_clock source\n", read);
> }
> +EXPORT_SYMBOL(sched_clock_register);
EXPORT_SYMBOL_GPL() please.
Thanks,
tglx
Re: [PATCH 11/17] clk: imx: Add blk_ctrl combo driver
Hi Abel,
On Wed, 2020-07-29 at 15:07 +0300, Abel Vesa wrote:
> On i.MX8MP, there is a new type of IP which is called BLK_CTRL in
> RM and usually is comprised of some GPRs that are considered too
> generic to be part of any dedicated IP from that specific subsystem.
>
> In general, some of the GPRs have some clock bits, some have reset bits,
> so in order to be able to use the imx clock API, this needs to be
> in a clock driver. From there it can use the reset controller API and
> leave the rest to the syscon.
>
> This driver is intended to work with the following BLK_CTRL IPs found in
> i.MX8MP (but it might be reused by the future i.MX platforms that
> have this kind of IP in their design):
> - Audio
> - Media
> - HDMI
>
> Signed-off-by: Abel Vesa
> ---
> drivers/clk/imx/Makefile | 2 +-
> drivers/clk/imx/clk-blk-ctrl.c | 318
> +
> drivers/clk/imx/clk-blk-ctrl.h | 81 +++
> 3 files changed, 400 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/imx/clk-blk-ctrl.c
> create mode 100644 drivers/clk/imx/clk-blk-ctrl.h
>
> diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
> index 928f874c..7afe1df 100644
> --- a/drivers/clk/imx/Makefile
> +++ b/drivers/clk/imx/Makefile
> @@ -27,7 +27,7 @@ obj-$(CONFIG_MXC_CLK_SCU) += \
>
> obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o
> obj-$(CONFIG_CLK_IMX8MN) += clk-imx8mn.o
> -obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o
> +obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o clk-blk-ctrl.o
> obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o
> obj-$(CONFIG_CLK_IMX8QXP) += clk-imx8qxp.o clk-imx8qxp-lpcg.o
>
> diff --git a/drivers/clk/imx/clk-blk-ctrl.c b/drivers/clk/imx/clk-blk-ctrl.c
> new file mode 100644
> index ..a46e674
> --- /dev/null
> +++ b/drivers/clk/imx/clk-blk-ctrl.c
> @@ -0,0 +1,318 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2020 NXP.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk.h"
> +#include "clk-blk-ctrl.h"
> +
> +struct reset_hw {
> + u32 offset;
> + u32 shift;
> + u32 mask;
> +};
> +
> +struct pm_safekeep_info {
> + uint32_t *regs_values;
> + uint32_t *regs_offsets;
> + uint32_t regs_num;
> +};
> +
> +struct imx_blk_ctrl_drvdata {
> + void __iomem *base;
> + struct reset_controller_dev rcdev;
> + struct reset_hw *rst_hws;
> + struct pm_safekeep_info pm_info;
> +
> + spinlock_t lock;
> +};
> +
> +static int imx_blk_ctrl_reset_set(struct reset_controller_dev *rcdev,
> + unsigned long id, bool assert)
> +{
> + struct imx_blk_ctrl_drvdata *drvdata = container_of(rcdev,
> + struct imx_blk_ctrl_drvdata, rcdev);
> + unsigned int offset = drvdata->rst_hws[id].offset;
> + unsigned int shift = drvdata->rst_hws[id].shift;
> + unsigned int mask = drvdata->rst_hws[id].mask;
> + void __iomem *reg_addr = drvdata->base + offset;
> + unsigned long flags;
> + u32 reg;
> +
> + if (assert) {
> + pm_runtime_get_sync(rcdev->dev);
> + spin_lock_irqsave(&drvdata->lock, flags);
> + reg = readl(reg_addr);
> + writel(reg & ~(mask << shift), reg_addr);
> + spin_unlock_irqrestore(&drvdata->lock, flags);
> + } else {
> + spin_lock_irqsave(&drvdata->lock, flags);
> + reg = readl(reg_addr);
> + writel(reg | (mask << shift), reg_addr);
> + spin_unlock_irqrestore(&drvdata->lock, flags);
> + pm_runtime_put(rcdev->dev);
This still has the issue of potentially letting exclusive reset control
users break the device usage counter.
Also shared reset control users start with deassert(), and you end probe
with pm_runtime_put(), so the first shared reset control user that
deasserts its reset will decrement the dev->power.usage_count to -1 ?
For multiple resets being initially deasserted this would decrement
multiple times.
I think you'll have to track the (number of) asserted reset bits in this
reset controller and limit when to call pm_runtime_get/put_sync().
> + }
> +
> + return 0;
> +}
> +
> +static int imx_blk_ctrl_reset_reset(struct reset_controller_dev *rcdev,
> +unsigned long id)
> +{
> + imx_blk_ctrl_reset_set(rcdev, id, true);
> + return imx_blk_ctrl_reset_set(rcdev, id, false);
Does this work for all peripherals? Are there none that require the
reset line to be asserted for a certain number of bus clocks or similar?
> +}
> +
> +static int imx_blk_ctrl_reset_assert(struct reset_controller_dev *rcdev,
> +unsigned long id)
> +{
> + return imx_blk_ctrl_reset_set(rcdev, id, true);
> +}
> +
> +static int imx_blk_ctrl_reset_deassert(struct reset_controller_dev *rcdev,
> +
Re: [char-misc-next] MAINTAINERS: Fix maintainer entry for mei driver
On 7/29/20 06:05, Tomas Winkler wrote: > mei driver has sub modules, those are not > listed via scripts/get_maintainer.pl when using asterisk: > drivers/misc/mei/* > The correct notation is: > drivers/misc/mei/ > Yes; it works fine now: $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback -f drivers/misc/mei/hdcp/mei_hdcp.c Tomas Winkler (supporter:INTEL MANAGEMENT ENGINE (mei)) Arnd Bergmann (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman (supporter:CHAR and MISC DRIVERS) linux-kernel@vger.kernel.org (open list:INTEL MANAGEMENT ENGINE (mei)) > Cc: Joe Perches > Cc: Gustavo A. R. Silva > Signed-off-by: Tomas Winkler Reviewed-by: Gustavo A. R. Silva Thanks -- Gustavo > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 86994c35d56e..dbe6a71eb6f2 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8789,7 +8789,7 @@ M: Tomas Winkler > L: linux-kernel@vger.kernel.org > S: Supported > F: Documentation/driver-api/mei/* > -F: drivers/misc/mei/* > +F: drivers/misc/mei/ > F: drivers/watchdog/mei_wdt.c > F: include/linux/mei_cl_bus.h > F: include/uapi/linux/mei.h >
Re: Minor RST rant
On Sat, Jul 25, 2020 at 09:46:55AM +1000, NeilBrown wrote: > Constant names stand out least effectively by themselves. In > kernel-doc comments they are preceded by a '%'. Would that make the > text more readable for you? Does our doc infrastructure honour that in > .rst documents? It does not. It also still reads really weird. And for some reason firefox chokes on the HTML file I tried it with, and make htmldocs takes for bloody ever. Give me a plain text file, please. All this modern crap just doesn't work.
Re: [f2fs-dev] [PATCH] f2fs: fix deadlock between quota writes and checkpoint
On 2020-7-29 15:02, Jaegeuk Kim wrote:
f2fs_write_data_pages(quota_mapping)
__f2fs_write_data_pages f2fs_write_checkpoint
* blk_start_plug(&plug);
* add bio in write_io[DATA]
- block_operations
- skip syncing quota by
>DEFAULT_RETRY_QUOTA_FLUSH_COUNT
- down_write(&sbi->node_write);
- f2fs_write_single_data_page
After commit 79963d967b49 ("f2fs: shrink node_write lock coverage"),
node_write lock was moved to f2fs_write_single_data_page() and
f2fs_write_compressed_pages().
So it needs to update the callstack.
- down_write(node_write)
Otherwise it looks good to me.
Reviewed-by: Chao Yu
Thanks,
- f2fs_do_write_data_page
- f2fs_outplace_write_data
- do_write_page
- f2fs_allocate_data_block
- down_write(node_write)
- f2fs_wait_on_all_pages(F2FS_WB_CP_DATA);
Signed-off-by: Daeho Jeong
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 8c782d3f324f0..99c8061da55b9 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -1269,6 +1269,8 @@ void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, int
type)
if (type == F2FS_DIRTY_META)
f2fs_sync_meta_pages(sbi, META, LONG_MAX,
FS_CP_META_IO);
+ else if (type == F2FS_WB_CP_DATA)
+ f2fs_submit_merged_write(sbi, DATA);
io_schedule_timeout(DEFAULT_IO_TIMEOUT);
}
finish_wait(&sbi->cp_wait, &wait);
[PATCH 1/1] vt_ioctl: prevent VT_RESIZEX font height change from causing potential out-of-bounds access
Add a VT_RESIZEX check to ensure that changing the font height will not
cause a potential out-of-bounds access. The candidate font height contained
in "v_clin", though below the max, could still result in accesses beyond
the allocated font data size.
Signed-off-by: George Kennedy
Reported-by: syzbot+38a3699c7eaf165b9...@syzkaller.appspotmail.com
---
drivers/tty/vt/vt_ioctl.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
index daf61c2..6185f1a 100644
--- a/drivers/tty/vt/vt_ioctl.c
+++ b/drivers/tty/vt/vt_ioctl.c
@@ -342,6 +342,9 @@ static void vt_disallocate_all(void)
}
}
+/* from fbcon.c */
+#define FNTSIZE(fd) (((int *)(fd))[-2])
+#define FNTCHARCNT(fd) (((int *)(fd))[-3])
/*
* We handle the console-specific ioctl's here. We allow the
@@ -895,8 +898,23 @@ int vt_ioctl(struct tty_struct *tty,
if (vcp) {
if (v.v_vlin)
vcp->vc_scan_lines = v.v_vlin;
- if (v.v_clin)
+ if (v.v_clin) {
+ int width, pitch, size;
+
+ width = (vcp->vc_font.width > 8) ? 8 :
vcp->vc_font.width;
+ pitch = (width + 7) >> 3;
+
+ pitch = (pitch) ? pitch : 1;
+
+ /* font size = height * pitch *
charcount */
+ size = v.v_clin * pitch *
FNTCHARCNT(vcp->vc_font.data);
+
+ if (size > FNTSIZE(vcp->vc_font.data)) {
+ console_unlock();
+ return -EINVAL;
+ }
vcp->vc_font.height = v.v_clin;
+ }
vcp->vc_resize_user = 1;
vc_resize(vcp, v.v_cols, v.v_rows);
}
--
1.8.3.1
Re: [PATCH RFC] rcu/segcblist: Add counters to segcblist datastructure
On Mon, Jul 20, 2020 at 07:29:23AM -0700, Davidlohr Bueso wrote:
> On Sat, 18 Jul 2020, Joel Fernandes (Google) wrote:
>
> > +/* Move from's segment length to to's segment. */
> > +static void rcu_segcblist_move_seglen(struct rcu_segcblist *rsclp, int
> > from, int to)
> > +{
> > + long len = rcu_segcblist_get_seglen(rsclp, from);
> > +
> > + if (!len || from == to)
> > + return;
>
> Nit: You probably wanna do the parameter sanity checks before the
> atomic_read.
Ok, I'll do that next revision. Thank you.
- Joel
Re: [PATCH] arm64: dts: sun50i-pinephone: add led flash
Hi!
On Sat, Jul 25, 2020 at 01:08:12PM +0200, Luca Weiss wrote:
> All revisions of the PinePhone have an SGM3140 LED flash. The gpios were
> swapped on v1.0 of the board but this was fixed in later revisions.
>
> Signed-off-by: Luca Weiss
> ---
> .../boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts | 5 +
> .../boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts | 5 +
> .../boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts | 5 +
> .../boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 11 +++
> 4 files changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> index 0c42272106afa..b579b03d4e026 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> @@ -9,3 +9,8 @@ / {
> model = "Pine64 PinePhone Developer Batch (1.0)";
> compatible = "pine64,pinephone-1.0", "allwinner,sun50i-a64";
> };
> +
> +&sgm3140 {
> + flash-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
> + enable-gpios = <&pio 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> index 3e99a87e9ce52..8552587aac248 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> @@ -28,3 +28,8 @@ &backlight {
> num-interpolated-steps = <50>;
> default-brightness-level = <400>;
> };
> +
> +&sgm3140 {
> + flash-gpios = <&pio 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
> + enable-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
> index a9f5b670c9b82..ec77715ba4a2a 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
> @@ -38,3 +38,8 @@ &lis3mdl {
> interrupt-parent = <&pio>;
> interrupts = <1 1 IRQ_TYPE_EDGE_RISING>; /* PB1 */
> };
> +
> +&sgm3140 {
> + flash-gpios = <&pio 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
> + enable-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> index 25150aba749dc..e0bc1bcc1c1f3 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> @@ -60,6 +60,17 @@ vibrator {
> enable-gpios = <&pio 3 2 GPIO_ACTIVE_HIGH>; /* PD2 */
> vcc-supply = <®_dcdc1>;
> };
> +
> + sgm3140: led-controller {
The nodes should be ordered by node-name here
> + compatible = "sgmicro,sgm3140";
> + vin-supply = <®_dcdc1>;
> +
> + sgm3140_flash: led {
What do you need the label for?
Thanks!
Maxime
signature.asc
Description: PGP signature
Re: WARNING: suspicious RCU usage - while installing a VM on a CPU listed under nohz_full
On 7/28/20 10:38 PM, Wanpeng Li wrote: > Hi Nitesh， > On Wed, 29 Jul 2020 at 09:00, Wanpeng Li wrote: >> On Tue, 28 Jul 2020 at 22:40, Nitesh Narayan Lal wrote: >>> Hi, >>> >>> I have recently come across an RCU trace with the 5.8-rc7 kernel that has >>> the >>> debug configs enabled while installing a VM on a CPU that is listed under >>> nohz_full. >>> >>> Based on some of the initial debugging, my impression is that the issue is >>> triggered because of the fastpath that is meant to optimize the writes to >>> x2APIC >>> ICR that eventually leads to a virtual IPI in fixed delivery mode, is >>> getting >>> invoked from the quiescent state. > Could you try latest linux-next tree? I guess maybe some patches are > pending in linux-next tree, I can't reproduce against linux-next tree. Sure, I will try this today. > -- Nitesh signature.asc Description: OpenPGP digital signature
[PATCH v2] interconnect: Add bulk API helpers
There are drivers which just need to get multiple interconnect paths,
request some predefined amounts of bandwidth and then just toggle the
paths between enabled/disabled state.
The aim of this patch is simplify the above and to allow drivers to put
all the path names and bandwidth data into a single static icc_bulk_data
table and call the icc_bulk_* functions on that table in order to scale
all the interconnect paths in parallel.
Suggested-by: Evan Green
Suggested-by: Bjorn Andersson
Signed-off-by: Georgi Djakov
---
v2:
* Fix kernel-doc. (Bjorn)
* Do not print EPROBE_DEFER errors. (Bjorn)
v1: https://lore.kernel.org/r/20200528162542.30158-1-georgi.dja...@linaro.org/
drivers/interconnect/Makefile | 2 +-
drivers/interconnect/bulk.c | 117 ++
include/linux/interconnect.h | 22 +++
3 files changed, 140 insertions(+), 1 deletion(-)
create mode 100644 drivers/interconnect/bulk.c
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 4825c287ca13..d203520b0a56 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
CFLAGS_core.o := -I$(src)
-icc-core-objs := core.o
+icc-core-objs := core.o bulk.o
obj-$(CONFIG_INTERCONNECT) += icc-core.o
obj-$(CONFIG_INTERCONNECT_IMX) += imx/
diff --git a/drivers/interconnect/bulk.c b/drivers/interconnect/bulk.c
new file mode 100644
index ..73e2c8d0a412
--- /dev/null
+++ b/drivers/interconnect/bulk.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+
+/**
+ * of_icc_bulk_get() - get interconnect paths
+ * @dev: the device requesting the path
+ * @num_paths: the number of icc_bulk_data
+ * @paths: the table with the paths we want to get
+ *
+ * Returns 0 on success or negative errno otherwise.
+ */
+int __must_check of_icc_bulk_get(struct device *dev, int num_paths,
+struct icc_bulk_data *paths)
+{
+ int ret, i;
+
+ for (i = 0; i < num_paths; i++) {
+ paths[i].path = of_icc_get(dev, paths[i].name);
+ if (IS_ERR(paths[i].path)) {
+ ret = PTR_ERR(paths[i].path);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "of_icc_get() failed on path %s
(%d)\n",
+ paths[i].name, ret);
+ paths[i].path = NULL;
+ goto err;
+ }
+ }
+
+ return 0;
+
+err:
+ icc_bulk_put(i, paths);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_icc_bulk_get);
+
+/**
+ * icc_bulk_put() - put a list of interconnect paths
+ * @num_paths: the number of icc_bulk_data
+ * @paths: the icc_bulk_data table with the paths being put
+ */
+void icc_bulk_put(int num_paths, struct icc_bulk_data *paths)
+{
+ while (--num_paths >= 0) {
+ icc_put(paths[num_paths].path);
+ paths[num_paths].path = NULL;
+ }
+}
+EXPORT_SYMBOL_GPL(icc_bulk_put);
+
+/**
+ * icc_bulk_set() - set bandwidth to a set of paths
+ * @num_paths: the number of icc_bulk_data
+ * @paths: the icc_bulk_data table containing the paths and bandwidth
+ *
+ * Returns 0 on success or negative errno otherwise.
+ */
+int icc_bulk_set_bw(int num_paths, const struct icc_bulk_data *paths)
+{
+ int ret = 0;
+ int i;
+
+ for (i = 0; i < num_paths; i++) {
+ ret = icc_set_bw(paths[i].path, paths[i].avg_bw,
paths[i].peak_bw);
+ if (ret) {
+ pr_err("icc_set_bw() failed on path %s (%d)\n",
paths[i].name, ret);
+ return ret;
+ }
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(icc_bulk_set_bw);
+
+/**
+ * icc_bulk_enable() - enable a previously disabled set of paths
+ * @num_paths: the number of icc_bulk_data
+ * @paths: the icc_bulk_data table containing the paths and bandwidth
+ *
+ * Returns 0 on success or negative errno otherwise.
+ */
+int icc_bulk_enable(int num_paths, const struct icc_bulk_data *paths)
+{
+ int ret, i;
+
+ for (i = 0; i < num_paths; i++) {
+ ret = icc_enable(paths[i].path);
+ if (ret) {
+ pr_err("icc_enable() failed on path %s (%d)\n",
paths[i].name, ret);
+ goto err;
+ }
+ }
+
+ return 0;
+
+err:
+ icc_bulk_disable(i, paths);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(icc_bulk_enable);
+
+/**
+ * icc_bulk_disable() - disable a set of interconnect paths
+ * @num_paths: the number of icc_bulk_data
+ * @paths: the icc_bulk_data table containing the paths and bandwidth
+ */
+void icc_bulk_disable(int num_paths, const struct icc_bulk_data *paths)
+{
+ while (--num_paths >= 0)
+ icc_disable(paths[num_paths].path);
+}
+EXPORT_SYMB
Re: [PATCH v2 1/9] dt-bindings: arm: mstar: Add binding details for mstar,pmsleep
Hi Arnd, On Wed, 29 Jul 2020 at 21:14, Arnd Bergmann wrote: > > Does calling it "mstar,pmsleepv7" make more sense? I'm not sure what > > to call it really. > > Use the name of the oldest chip you know that supports it in there, > such as "mstar,msc313-pmsleep" if this one is specific to msc313. That makes sense. I think the original patch got merged to soc/arm/newsoc. Should I recreate the series or create a new patch to do the corrections? Slightly off topic but I'm working on the series for the interrupt controller and I've just renamed it from mstar,msc313e-intc to mstar,v7intc. I originally called it msc313e because I only knew of that chip but the same controller is present at the same place in all of the chips so far. I guess I should probably rename it to mstar,msc313-intc to keep with the first chip it appeared in pattern? Thanks, Daniel
[PATCH] net/mlx5e: fix bpf_prog refcnt leaks in mlx5e_alloc_rq
The function invokes bpf_prog_inc(), which increases the refcount of a bpf_prog object "rq->xdp_prog" if the object isn't NULL. The refcount leak issues take place in two error handling paths. When mlx5_wq_ll_create() or mlx5_wq_cyc_create() fails, the function simply returns the error code and forgets to drop the refcount increased earlier, causing a refcount leak of "rq->xdp_prog". Fix this issue by jumping to the error handling path err_rq_wq_destroy when either function fails. Signed-off-by: Xin Xiong Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan --- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c index a836a02a2116..8e1b1ab416d8 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c @@ -419,7 +419,7 @@ static int mlx5e_alloc_rq(struct mlx5e_channel *c, err = mlx5_wq_ll_create(mdev, &rqp->wq, rqc_wq, &rq->mpwqe.wq, &rq->wq_ctrl); if (err) - return err; + goto err_rq_wq_destroy; rq->mpwqe.wq.db = &rq->mpwqe.wq.db[MLX5_RCV_DBR]; @@ -470,7 +470,7 @@ static int mlx5e_alloc_rq(struct mlx5e_channel *c, err = mlx5_wq_cyc_create(mdev, &rqp->wq, rqc_wq, &rq->wqe.wq, &rq->wq_ctrl); if (err) - return err; + goto err_rq_wq_destroy; rq->wqe.wq.db = &rq->wqe.wq.db[MLX5_RCV_DBR]; -- 2.25.1
