* Re: [Freedreno] [PATCH v6] arm64: dts: qcom: sc7180: Add A618 gpu dt blob
From: Rob Clark @ 2020-02-20 16:19 UTC (permalink / raw)
To: Sharat Masetty
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Douglas Anderson, Bjorn Andersson,
Matthias Kaehlcke, dri-devel, linux-arm-msm, freedreno
In-Reply-To: <1581320465-15854-2-git-send-email-smasetty@codeaurora.org>
On Sun, Feb 9, 2020 at 11:41 PM Sharat Masetty <smasetty@codeaurora.org> wrote:
>
> This patch adds the required dt nodes and properties
> to enabled A618 GPU.
>
> Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 102 +++++++++++++++++++++++++++++++++++
> 1 file changed, 102 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index f3fcc5c..63fff15 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -1043,6 +1043,108 @@
> };
> };
>
> + gpu: gpu@5000000 {
> + compatible = "qcom,adreno-618.0", "qcom,adreno";
> + #stream-id-cells = <16>;
> + reg = <0 0x05000000 0 0x40000>, <0 0x0509e000 0 0x1000>,
> + <0 0x05061000 0 0x800>;
> + reg-names = "kgsl_3d0_reg_memory", "cx_mem", "cx_dbgc";
> + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&adreno_smmu 0>;
> + operating-points-v2 = <&gpu_opp_table>;
> + qcom,gmu = <&gmu>;
> +
> + gpu_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-800000000 {
> + opp-hz = /bits/ 64 <800000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
> + };
> +
> + opp-650000000 {
> + opp-hz = /bits/ 64 <650000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
> + };
> +
> + opp-565000000 {
> + opp-hz = /bits/ 64 <565000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
> + };
> +
> + opp-430000000 {
> + opp-hz = /bits/ 64 <430000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
> + };
> +
> + opp-355000000 {
> + opp-hz = /bits/ 64 <355000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
> + };
> +
> + opp-267000000 {
> + opp-hz = /bits/ 64 <267000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
> + };
> +
> + opp-180000000 {
> + opp-hz = /bits/ 64 <180000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
> + };
> + };
> + };
> +
> + adreno_smmu: iommu@5040000 {
> + compatible = "qcom,sc7180-smmu-v2", "qcom,smmu-v2";
> + reg = <0 0x05040000 0 0x10000>;
> + #iommu-cells = <1>;
> + #global-interrupts = <2>;
> + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 364 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 365 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 366 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 367 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 368 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 369 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 370 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 371 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
> + <&gcc GCC_GPU_CFG_AHB_CLK>,
> + <&gcc GCC_DDRSS_GPU_AXI_CLK>;
> +
> + clock-names = "bus", "iface", "mem_iface_clk";
> + power-domains = <&gpucc CX_GDSC>;
> + };
> +
> + gmu: gmu@506a000 {
> + compatible="qcom,adreno-gmu-618.0", "qcom,adreno-gmu";
> + reg = <0 0x0506a000 0 0x31000>, <0 0x0b290000 0 0x10000>,
> + <0 0x0b490000 0 0x10000>;
> + reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
> + interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "hfi", "gmu";
> + clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
> + <&gpucc GPU_CC_CXO_CLK>,
> + <&gcc GCC_DDRSS_GPU_AXI_CLK>,
> + <&gcc GCC_GPU_MEMNOC_GFX_CLK>;
> + clock-names = "gmu", "cxo", "axi", "memnoc";
> + power-domains = <&gpucc CX_GDSC>, <&gpucc GX_GDSC>;
> + power-domain-names = "cx", "gx";
> + iommus = <&adreno_smmu 5>;
> + operating-points-v2 = <&gmu_opp_table>;
jfyi, this will shortly require a dma-ranges property[1].. it might
simplify things, wrt. to which order patches land (this vs dma-ranges)
to go ahead and add the dma-ranges property now
BR,
-R
[1] https://lists.freedesktop.org/archives/freedreno/2020-February/006903.html
> +
> + gmu_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-200000000 {
> + opp-hz = /bits/ 64 <200000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
> + };
> + };
> + };
> +
> gpucc: clock-controller@5090000 {
> compatible = "qcom,sc7180-gpucc";
> reg = <0 0x05090000 0 0x9000>;
> --
> 1.9.1
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Freedreno] [PATCH v6] arm64: dts: qcom: sc7180: Add A618 gpu dt blob
From: Rob Clark @ 2020-02-20 16:19 UTC (permalink / raw)
To: Sharat Masetty
Cc: freedreno,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Douglas Anderson, linux-arm-msm, Linux Kernel Mailing List,
Bjorn Andersson, Jordan Crouse, Matthias Kaehlcke, dri-devel
In-Reply-To: <1581320465-15854-2-git-send-email-smasetty@codeaurora.org>
On Sun, Feb 9, 2020 at 11:41 PM Sharat Masetty <smasetty@codeaurora.org> wrote:
>
> This patch adds the required dt nodes and properties
> to enabled A618 GPU.
>
> Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 102 +++++++++++++++++++++++++++++++++++
> 1 file changed, 102 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index f3fcc5c..63fff15 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -1043,6 +1043,108 @@
> };
> };
>
> + gpu: gpu@5000000 {
> + compatible = "qcom,adreno-618.0", "qcom,adreno";
> + #stream-id-cells = <16>;
> + reg = <0 0x05000000 0 0x40000>, <0 0x0509e000 0 0x1000>,
> + <0 0x05061000 0 0x800>;
> + reg-names = "kgsl_3d0_reg_memory", "cx_mem", "cx_dbgc";
> + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&adreno_smmu 0>;
> + operating-points-v2 = <&gpu_opp_table>;
> + qcom,gmu = <&gmu>;
> +
> + gpu_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-800000000 {
> + opp-hz = /bits/ 64 <800000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
> + };
> +
> + opp-650000000 {
> + opp-hz = /bits/ 64 <650000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
> + };
> +
> + opp-565000000 {
> + opp-hz = /bits/ 64 <565000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
> + };
> +
> + opp-430000000 {
> + opp-hz = /bits/ 64 <430000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
> + };
> +
> + opp-355000000 {
> + opp-hz = /bits/ 64 <355000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
> + };
> +
> + opp-267000000 {
> + opp-hz = /bits/ 64 <267000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
> + };
> +
> + opp-180000000 {
> + opp-hz = /bits/ 64 <180000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
> + };
> + };
> + };
> +
> + adreno_smmu: iommu@5040000 {
> + compatible = "qcom,sc7180-smmu-v2", "qcom,smmu-v2";
> + reg = <0 0x05040000 0 0x10000>;
> + #iommu-cells = <1>;
> + #global-interrupts = <2>;
> + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 364 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 365 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 366 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 367 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 368 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 369 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 370 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 371 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
> + <&gcc GCC_GPU_CFG_AHB_CLK>,
> + <&gcc GCC_DDRSS_GPU_AXI_CLK>;
> +
> + clock-names = "bus", "iface", "mem_iface_clk";
> + power-domains = <&gpucc CX_GDSC>;
> + };
> +
> + gmu: gmu@506a000 {
> + compatible="qcom,adreno-gmu-618.0", "qcom,adreno-gmu";
> + reg = <0 0x0506a000 0 0x31000>, <0 0x0b290000 0 0x10000>,
> + <0 0x0b490000 0 0x10000>;
> + reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
> + interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "hfi", "gmu";
> + clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
> + <&gpucc GPU_CC_CXO_CLK>,
> + <&gcc GCC_DDRSS_GPU_AXI_CLK>,
> + <&gcc GCC_GPU_MEMNOC_GFX_CLK>;
> + clock-names = "gmu", "cxo", "axi", "memnoc";
> + power-domains = <&gpucc CX_GDSC>, <&gpucc GX_GDSC>;
> + power-domain-names = "cx", "gx";
> + iommus = <&adreno_smmu 5>;
> + operating-points-v2 = <&gmu_opp_table>;
jfyi, this will shortly require a dma-ranges property[1].. it might
simplify things, wrt. to which order patches land (this vs dma-ranges)
to go ahead and add the dma-ranges property now
BR,
-R
[1] https://lists.freedesktop.org/archives/freedreno/2020-February/006903.html
> +
> + gmu_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-200000000 {
> + opp-hz = /bits/ 64 <200000000>;
> + opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
> + };
> + };
> + };
> +
> gpucc: clock-controller@5090000 {
> compatible = "qcom,sc7180-gpucc";
> reg = <0 0x05090000 0 0x9000>;
> --
> 1.9.1
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t] intel-ci: add a pre-merge blacklist to reduce the testing queue
From: Peres, Martin @ 2020-02-20 16:19 UTC (permalink / raw)
To: Chris Wilson, igt-dev@lists.freedesktop.org
In-Reply-To: <158221348330.8112.1847874725528060647@skylake-alporthouse-com>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
On 2020-02-20 17:44, Chris Wilson wrote:
> Quoting Martin Peres (2020-02-20 15:32:09)
>> +###############################################################################
>> +# Perf tests are for people using performance counters to get details about
>> +# how the execution is performed (Observability Architecture). As such, the
>> +# audience is very limited (game developers, driver developers), and it does
>> +# not justify the overall execution time:
>> +#
>> +# - shard-skl: 0%
>> +# - shard-kbl: 0%
>> +# - shard-apl: 0%
>> +# - shard-glk: 0%
>> +# - shard-icl: 0%
>> +# - shard-tgl: 1.7% (~3.5 minutes)
>> +#
>> +# Data acquired on 2020-02-20 by Martin Peres
>> +###############################################################################
>> +igt@perf@gen12-mi-rpc
>
> Nak. That is just a straightforward BUG. The test is doing it's job in
> reporting the interface is snafu. Then the test screws up by deadlocking
> due to unclean exit handling after detecting the error.
I raised the severity, but this has been opened for 3 weeks without much
work being done on it.
That being said, I don't mind dropping this hunk.
Martin
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1774 bytes --]
[-- Attachment #3: Type: text/plain, Size: 154 bytes --]
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [Lsf-pc] [LSF/MM TOPIC] Memory cgroups, whether you like it or not
From: Michal Hocko @ 2020-02-20 16:19 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Tim Chen, lsf-pc, linux-mm, Dave Hansen, Dan Williams, Huang Ying
In-Reply-To: <20200220160604.ak33n3hrqouyiuyv@box>
On Thu 20-02-20 19:06:04, Kirill A. Shutemov wrote:
> On Fri, Feb 14, 2020 at 11:45:41AM +0100, Michal Hocko wrote:
> > On Wed 05-02-20 10:34:57, Tim Chen wrote:
> > > There is existing infrastructure for memory soft limit per cgroup we
> > > can leverage to implement such a scheme. We'll like to find out if this
> > > approach makes sense for people working on systems with multiple memory tiers.
> >
> > Soft limit is dead.
>
> Michal, could you remind what the deal with soft limit? Why is it dead?
because of the very disruptive semantic. Essentially the way how it was
grafted into the normal reclaim. It is essentially a priority 0 reclaim
round to shrink a hierarchy which is the most in excess before we do a
normal reclaim. This can lead to an over reclaim, long stalls etc.
There were a lot of discussions on that matter on the mailing list few
years back. We have tried to make the semantic more reasonable but
failed on that and the result is a new cgroup v2 interface essentially.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [MODERATED] Re: [PATCH 0/2] more sampling fun 0
From: Greg KH @ 2020-02-20 16:18 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220154007.GC58564@mtg-dev.jf.intel.com>
On Thu, Feb 20, 2020 at 07:40:07AM -0800, speck for mark gross wrote:
> On Thu, Feb 20, 2020 at 03:27:20PM +0100, speck for Greg KH wrote:
> > On Thu, Feb 20, 2020 at 09:14:20AM +0100, speck for Greg KH wrote:
> > > On Wed, Feb 19, 2020 at 02:45:22PM -0800, speck for mark gross wrote:
> > > > From: mark gross <mgross@linux.intel.com>
> > > > Subject: [PATCH 0/2] Special Register Buffer Data Sampling patch set
> > > >
> > > > Special Register Buffer Data Sampling is a sampling type of vulnerability that
> > > > leaks data across cores sharing the HW-RNG for vulnerable processors.
> > > >
> > > > This leak is fixed by a microcode update and is enabled by default.
> > > >
> > > > This new microcode serializes processor access during execution of RDRAND
> > > > or RDSEED. It ensures that the shared buffer is overwritten before it
> > > > is released for reuse.
> > > >
> > > > The mitigation impacts the throughput of the RDRAND and RDSEED instructions
> > > > and latency of RT processing running on the socket while executing RDRAND or
> > > > RDSEED. The micro bechmark of calling RDRAND many times shows a 10x slowdown.
> > >
> > > Then we need to stop using RDRAND internally for our "give me a random
> > > number api" which has spread to more and more parts of the kernel.
> > >
> > > Here's a patch that does so:
> > > https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/
> > > which I'm going to advise get merged now and backported to the stable
> > > branches.
> >
> > Note, the author of that patch has reached out to me to say they found
> > this same issue. He did so independantly so odds are others already
> > know about this. He found it because he was wondering why rdrand was so
> > slow on newer systems, and then traced things backwards like all the
> > other researchers in this area.
> Are you saying the author has seen the RNG data leaking across processors or
> the slowdown?
slowdown from what? Relative to older processors, yes.
Leaking across, yes, I think so.
> > So, what's the timeline here? Looks like this is already "in the wild"
> > from what I can tell.
> >
> The uCode mitigation is coming out with the 2020.1 IPU (intel platform update)
> (fist ucode update of 2020) that I belive is slated for an official May
> disclosure.
{sigh} That's a long time, we should just fix up the kernel internally
to not worry about this now so that we are not sitting on this any
longer.
thanks,
greg k-h
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 16/52] drm/repaper: Use drmm_add_final_kfree
From: Noralf Trønnes @ 2020-02-20 16:18 UTC (permalink / raw)
To: Daniel Vetter, DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
In-Reply-To: <20200219102122.1607365-17-daniel.vetter@ffwll.ch>
Den 19.02.2020 11.20, skrev Daniel Vetter:
> With this we can drop the final kfree from the release function.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: "Noralf Trønnes" <noralf@tronnes.org>
> ---
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 16/52] drm/repaper: Use drmm_add_final_kfree
From: Noralf Trønnes @ 2020-02-20 16:18 UTC (permalink / raw)
To: Daniel Vetter, DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
In-Reply-To: <20200219102122.1607365-17-daniel.vetter@ffwll.ch>
Den 19.02.2020 11.20, skrev Daniel Vetter:
> With this we can drop the final kfree from the release function.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: "Noralf Trønnes" <noralf@tronnes.org>
> ---
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] btrfs: clear file extent mapping for punch past i_size
From: Filipe Manana @ 2020-02-20 16:18 UTC (permalink / raw)
To: Josef Bacik; +Cc: linux-btrfs, kernel-team
In-Reply-To: <20200220142947.3880392-1-josef@toxicpanda.com>
On Thu, Feb 20, 2020 at 2:30 PM Josef Bacik <josef@toxicpanda.com> wrote:
>
> In my stress testing we were still seeing some hole's with my patches to
> fix missing hole extents. Turns out we do not fill in holes during hole
> punch if the punch is past i_size. I incorrectly assumed this was fine,
> because anybody extending would use btrfs_cont_expand, however there is
> a corner that still can give us trouble. Start with an empty file and
>
> fallocate KEEP_SIZE 1m-2m
>
> We now have a 0 length file, and a hole file extent from 0-1m, and a
> prealloc extent from 1m-2m. Now
>
> punch 1m-1.5m
>
> Because this is past i_size we have
>
> [HOLE EXTENT][ NOTHING ][PREALLOC]
> [0 1m][1m 1.5m][1.5m 2m]
>
> with an i_size of 0. Now if we pwrite 0-1.5m we'll increas our i_size
> to 1.5m, but our disk_i_size is still 0 until the ordered extent
> completes.
>
> However if we now immediately truncate 2m on the file we'll just call
> btrfs_cont_expand(inode, 1.5m, 2m), since our old i_size is 1.5m. If we
> commit the transaction here and crash we'll expose the gap.
>
> To fix this we need to clear the file extent mapping for the range that
> we punched but didn't insert a corresponding file extent for. This will
> mean the truncate will only get an disk_i_size set to 1m if we crash
> before the finish ordered io happens.
>
> I've written an xfstest to reproduce the problem and validate this fix.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
I hit another case, besides the one I reported last week, in my
automated tests during one of these evenings.
This is probably it, but I haven't tried to debug it yet - reusing the
same fsstress seed didn't trigger it, as the test used 20 fsstress
processes (with dm log writes).
Looks good,
Reviewed-by: Filipe Manana <fdmanana@suse.com>
> ---
> - Dave, this needs to be folded into "btrfs: use the file extent tree
> infrastructure" and the changelog needs to be adjusted since I incorrectly
> point out that we don't need to clear for hole punch. We definitely need to
> clear for the case that we're punching past i_size as we aren't inserting hole
> file extents.
>
> fs/btrfs/file.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> index 5cdcdbdd908b..6f6f1805e6fd 100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -2597,6 +2597,24 @@ int btrfs_punch_hole_range(struct inode *inode, struct btrfs_path *path,
> btrfs_abort_transaction(trans, ret);
> break;
> }
> + } else if (!clone_info && cur_offset < drop_end) {
> + /*
> + * We are past the i_size here, but since we didn't
> + * insert holes we need to clear the mapped area so we
> + * know to not set disk_i_size in this area until a new
> + * file extent is inserted here.
> + */
> + ret = btrfs_inode_clear_file_extent_range(BTRFS_I(inode),
> + cur_offset, drop_end - cur_offset);
> + if (ret) {
> + /*
> + * We couldn't clear our area, so we could
> + * presumably adjust up and corrupt the fs, so
> + * we need to abort.
> + */
> + btrfs_abort_transaction(trans, ret);
> + break;
> + }
> }
>
> if (clone_info && drop_end > clone_info->file_offset) {
> @@ -2687,6 +2705,15 @@ int btrfs_punch_hole_range(struct inode *inode, struct btrfs_path *path,
> btrfs_abort_transaction(trans, ret);
> goto out_trans;
> }
> + } else if (!clone_info && cur_offset < drop_end) {
> + /* See the comment in the loop above for the reasoning here. */
> + ret = btrfs_inode_clear_file_extent_range(BTRFS_I(inode),
> + cur_offset, drop_end - cur_offset);
> + if (ret) {
> + btrfs_abort_transaction(trans, ret);
> + goto out_trans;
> + }
> +
> }
> if (clone_info) {
> ret = btrfs_insert_clone_extent(trans, inode, path, clone_info,
> --
> 2.24.1
>
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply
* Re: [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers
From: Noralf Trønnes @ 2020-02-20 16:18 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Zimmermann, David Airlie, Intel Graphics Development,
Daniel Vetter, Kamlesh Gurudasani, Sam Ravnborg, David Lechner
In-Reply-To: <20200219102122.1607365-6-daniel.vetter@ffwll.ch>
Den 19.02.2020 11.20, skrev Daniel Vetter:
> They all share mipi_dbi_release so we need to switch them all
> together. With this we can drop the final kfree from the release
> function.
>
> Aside, I think we could perhaps have a tiny additional helper for
> these mipi_dbi drivers, the first few lines around devm_drm_dev_init
> are all the same (except for the drm_driver pointer).
>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: David Lechner <david@lechnology.com>
> Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>
> Cc: "Noralf Trønnes" <noralf@tronnes.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
I really would have preferred having devm_drm_dev_alloc() in this
series, drmm_add_final_kfree() is rather odd.
But I can wait:
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
I have tested the whole series on tiny/mi0283qt:
Tested-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers
From: Noralf Trønnes @ 2020-02-20 16:18 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Zimmermann, David Airlie, Intel Graphics Development,
Maxime Ripard, Eric Anholt, Daniel Vetter, Kamlesh Gurudasani,
Sam Ravnborg, David Lechner
In-Reply-To: <20200219102122.1607365-6-daniel.vetter@ffwll.ch>
Den 19.02.2020 11.20, skrev Daniel Vetter:
> They all share mipi_dbi_release so we need to switch them all
> together. With this we can drop the final kfree from the release
> function.
>
> Aside, I think we could perhaps have a tiny additional helper for
> these mipi_dbi drivers, the first few lines around devm_drm_dev_init
> are all the same (except for the drm_driver pointer).
>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: David Lechner <david@lechnology.com>
> Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>
> Cc: "Noralf Trønnes" <noralf@tronnes.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
I really would have preferred having devm_drm_dev_alloc() in this
series, drmm_add_final_kfree() is rather odd.
But I can wait:
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
I have tested the whole series on tiny/mi0283qt:
Tested-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PULL 14/18] iotests: Add test for image creation fallback
From: Max Reitz @ 2020-02-20 16:07 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200122164532.178040-6-mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
[mreitz: Added a note that NBD does not support resizing, which is why
the second case is expected to fail]
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
tests/qemu-iotests/259 | 62 ++++++++++++++++++++++++++++++++++++++
tests/qemu-iotests/259.out | 14 +++++++++
tests/qemu-iotests/group | 1 +
3 files changed, 77 insertions(+)
create mode 100755 tests/qemu-iotests/259
create mode 100644 tests/qemu-iotests/259.out
diff --git a/tests/qemu-iotests/259 b/tests/qemu-iotests/259
new file mode 100755
index 0000000000..62e29af05f
--- /dev/null
+++ b/tests/qemu-iotests/259
@@ -0,0 +1,62 @@
+#!/usr/bin/env bash
+#
+# Test generic image creation fallback (by using NBD)
+#
+# Copyright (C) 2019 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+
+# creator
+owner=mreitz@redhat.com
+
+seq=$(basename $0)
+echo "QA output created by $seq"
+
+status=1 # failure is the default!
+
+_cleanup()
+{
+ _cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt raw
+_supported_proto nbd
+_supported_os Linux
+
+
+_make_test_img 64M
+
+echo
+echo '--- Testing creation ---'
+
+$QEMU_IMG create -f qcow2 "$TEST_IMG" 64M | _filter_img_create
+$QEMU_IMG info "$TEST_IMG" | _filter_img_info
+
+echo
+echo '--- Testing creation for which the node would need to grow ---'
+
+# NBD does not support resizing, so this will fail
+$QEMU_IMG create -f qcow2 -o preallocation=metadata "$TEST_IMG" 64M 2>&1 \
+ | _filter_img_create
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/259.out b/tests/qemu-iotests/259.out
new file mode 100644
index 0000000000..ffed19c2a0
--- /dev/null
+++ b/tests/qemu-iotests/259.out
@@ -0,0 +1,14 @@
+QA output created by 259
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
+
+--- Testing creation ---
+Formatting 'TEST_DIR/t.IMGFMT', fmt=qcow2 size=67108864
+image: TEST_DIR/t.IMGFMT
+file format: qcow2
+virtual size: 64 MiB (67108864 bytes)
+disk size: unavailable
+
+--- Testing creation for which the node would need to grow ---
+qemu-img: TEST_DIR/t.IMGFMT: Could not resize image: Image format driver does not support resize
+Formatting 'TEST_DIR/t.IMGFMT', fmt=qcow2 size=67108864 preallocation=metadata
+*** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 818380a8f0..b17711d17d 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -273,6 +273,7 @@
256 rw auto quick
257 rw
258 rw quick
+259 rw auto quick
260 rw quick
261 rw
262 rw quick migration
--
2.24.1
^ permalink raw reply related
* Re: [PATCH] selftests/rseq: Fix out-of-tree compilation
From: Shuah Khan @ 2020-02-20 16:17 UTC (permalink / raw)
To: Mathieu Desnoyers, Michael Ellerman
Cc: linux-kselftest, linux-kernel, Peter Zijlstra, paulmck,
Boqun Feng, skh >> Shuah Khan
In-Reply-To: <763647628.2256.1582215383750.JavaMail.zimbra@efficios.com>
On 2/20/20 9:16 AM, Mathieu Desnoyers wrote:
> ----- On Feb 20, 2020, at 6:37 AM, Michael Ellerman mpe@ellerman.id.au wrote:
>
>> Currently if you build with O=... the rseq tests don't build:
>>
>> $ make O=$PWD/output -C tools/testing/selftests/ TARGETS=rseq
>> make: Entering directory '/linux/tools/testing/selftests'
>> ...
>> make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
>> gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ -shared
>> -fPIC rseq.c -lpthread -o /linux/output/rseq/librseq.so
>> gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./
>> basic_test.c -lpthread -lrseq -o /linux/output/rseq/basic_test
>> /usr/bin/ld: cannot find -lrseq
>> collect2: error: ld returned 1 exit status
>>
>> This is because the library search path points to the source
>> directory, not the output.
>>
>> We can fix it by changing the library search path to $(OUTPUT).
>
> Good catch!
>
> Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>
> Shuah, can you pick this up please ?
>
I applied it to linux-kselftest fixes just a little while ago.
I will send this in for rc4.
thanks,
-- Shuah
^ permalink raw reply
* [PULL 17/18] block: Fix VM size field width in snapshot dump
From: Max Reitz @ 2020-02-20 16:07 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
When printing the snapshot list (e.g. with qemu-img snapshot -l), the VM
size field is only seven characters wide. As of de38b5005e9, this is
not necessarily sufficient: We generally print three digits, and this
may require a decimal point. Also, the unit field grew from something
as plain as "M" to " MiB". This means that number and unit may take up
eight characters in total; but we also want spaces in front.
Considering previously the maximum width was four characters and the
field width was chosen to be three characters wider, let us adjust the
field width to be eleven now.
Fixes: de38b5005e946aa3714963ea4c501e279e7d3666
Buglink: https://bugs.launchpad.net/qemu/+bug/1859989
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200117105859.241818-2-mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
block/qapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/qapi.c b/block/qapi.c
index 3f09477cc5..afd9f3b4a7 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -664,7 +664,7 @@ void bdrv_snapshot_dump(QEMUSnapshotInfo *sn)
char *sizing = NULL;
if (!sn) {
- qemu_printf("%-10s%-20s%7s%20s%15s",
+ qemu_printf("%-10s%-20s%11s%20s%15s",
"ID", "TAG", "VM SIZE", "DATE", "VM CLOCK");
} else {
ti = sn->date_sec;
@@ -679,7 +679,7 @@ void bdrv_snapshot_dump(QEMUSnapshotInfo *sn)
(int)(secs % 60),
(int)((sn->vm_clock_nsec / 1000000) % 1000));
sizing = size_to_str(sn->vm_state_size);
- qemu_printf("%-10s%-20s%7s%20s%15s",
+ qemu_printf("%-10s%-20s%11s%20s%15s",
sn->id_str, sn->name,
sizing,
date_buf,
--
2.24.1
^ permalink raw reply related
* [PULL 11/18] block: Generic file creation fallback
From: Max Reitz @ 2020-02-20 16:07 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
If a protocol driver does not support image creation, we can see whether
maybe the file exists already. If so, just truncating it will be
sufficient.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200122164532.178040-3-mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
block.c | 159 +++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 147 insertions(+), 12 deletions(-)
diff --git a/block.c b/block.c
index 08372ced26..308a91c96b 100644
--- a/block.c
+++ b/block.c
@@ -532,20 +532,139 @@ out:
return ret;
}
-int bdrv_create_file(const char *filename, QemuOpts *opts, Error **errp)
+/**
+ * Helper function for bdrv_create_file_fallback(): Resize @blk to at
+ * least the given @minimum_size.
+ *
+ * On success, return @blk's actual length.
+ * Otherwise, return -errno.
+ */
+static int64_t create_file_fallback_truncate(BlockBackend *blk,
+ int64_t minimum_size, Error **errp)
{
- BlockDriver *drv;
+ Error *local_err = NULL;
+ int64_t size;
+ int ret;
+
+ ret = blk_truncate(blk, minimum_size, false, PREALLOC_MODE_OFF, &local_err);
+ if (ret < 0 && ret != -ENOTSUP) {
+ error_propagate(errp, local_err);
+ return ret;
+ }
+
+ size = blk_getlength(blk);
+ if (size < 0) {
+ error_free(local_err);
+ error_setg_errno(errp, -size,
+ "Failed to inquire the new image file's length");
+ return size;
+ }
+
+ if (size < minimum_size) {
+ /* Need to grow the image, but we failed to do that */
+ error_propagate(errp, local_err);
+ return -ENOTSUP;
+ }
+
+ error_free(local_err);
+ local_err = NULL;
+
+ return size;
+}
+
+/**
+ * Helper function for bdrv_create_file_fallback(): Zero the first
+ * sector to remove any potentially pre-existing image header.
+ */
+static int create_file_fallback_zero_first_sector(BlockBackend *blk,
+ int64_t current_size,
+ Error **errp)
+{
+ int64_t bytes_to_clear;
+ int ret;
+
+ bytes_to_clear = MIN(current_size, BDRV_SECTOR_SIZE);
+ if (bytes_to_clear) {
+ ret = blk_pwrite_zeroes(blk, 0, bytes_to_clear, BDRV_REQ_MAY_UNMAP);
+ if (ret < 0) {
+ error_setg_errno(errp, -ret,
+ "Failed to clear the new image's first sector");
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int bdrv_create_file_fallback(const char *filename, BlockDriver *drv,
+ QemuOpts *opts, Error **errp)
+{
+ BlockBackend *blk;
+ QDict *options = qdict_new();
+ int64_t size = 0;
+ char *buf = NULL;
+ PreallocMode prealloc;
Error *local_err = NULL;
int ret;
+ size = qemu_opt_get_size_del(opts, BLOCK_OPT_SIZE, 0);
+ buf = qemu_opt_get_del(opts, BLOCK_OPT_PREALLOC);
+ prealloc = qapi_enum_parse(&PreallocMode_lookup, buf,
+ PREALLOC_MODE_OFF, &local_err);
+ g_free(buf);
+ if (local_err) {
+ error_propagate(errp, local_err);
+ return -EINVAL;
+ }
+
+ if (prealloc != PREALLOC_MODE_OFF) {
+ error_setg(errp, "Unsupported preallocation mode '%s'",
+ PreallocMode_str(prealloc));
+ return -ENOTSUP;
+ }
+
+ qdict_put_str(options, "driver", drv->format_name);
+
+ blk = blk_new_open(filename, NULL, options,
+ BDRV_O_RDWR | BDRV_O_RESIZE, errp);
+ if (!blk) {
+ error_prepend(errp, "Protocol driver '%s' does not support image "
+ "creation, and opening the image failed: ",
+ drv->format_name);
+ return -EINVAL;
+ }
+
+ size = create_file_fallback_truncate(blk, size, errp);
+ if (size < 0) {
+ ret = size;
+ goto out;
+ }
+
+ ret = create_file_fallback_zero_first_sector(blk, size, errp);
+ if (ret < 0) {
+ goto out;
+ }
+
+ ret = 0;
+out:
+ blk_unref(blk);
+ return ret;
+}
+
+int bdrv_create_file(const char *filename, QemuOpts *opts, Error **errp)
+{
+ BlockDriver *drv;
+
drv = bdrv_find_protocol(filename, true, errp);
if (drv == NULL) {
return -ENOENT;
}
- ret = bdrv_create(drv, filename, opts, &local_err);
- error_propagate(errp, local_err);
- return ret;
+ if (drv->bdrv_co_create_opts) {
+ return bdrv_create(drv, filename, opts, errp);
+ } else {
+ return bdrv_create_file_fallback(filename, drv, opts, errp);
+ }
}
/**
@@ -1444,6 +1563,24 @@ QemuOptsList bdrv_runtime_opts = {
},
};
+static QemuOptsList fallback_create_opts = {
+ .name = "fallback-create-opts",
+ .head = QTAILQ_HEAD_INITIALIZER(fallback_create_opts.head),
+ .desc = {
+ {
+ .name = BLOCK_OPT_SIZE,
+ .type = QEMU_OPT_SIZE,
+ .help = "Virtual disk size"
+ },
+ {
+ .name = BLOCK_OPT_PREALLOC,
+ .type = QEMU_OPT_STRING,
+ .help = "Preallocation mode (allowed values: off)"
+ },
+ { /* end of list */ }
+ }
+};
+
/*
* Common part for opening disk images and files
*
@@ -5772,15 +5909,13 @@ void bdrv_img_create(const char *filename, const char *fmt,
return;
}
- if (!proto_drv->create_opts) {
- error_setg(errp, "Protocol driver '%s' does not support image creation",
- proto_drv->format_name);
- return;
- }
-
/* Create parameter list */
create_opts = qemu_opts_append(create_opts, drv->create_opts);
- create_opts = qemu_opts_append(create_opts, proto_drv->create_opts);
+ if (proto_drv->create_opts) {
+ create_opts = qemu_opts_append(create_opts, proto_drv->create_opts);
+ } else {
+ create_opts = qemu_opts_append(create_opts, &fallback_create_opts);
+ }
opts = qemu_opts_create(create_opts, NULL, 0, &error_abort);
--
2.24.1
^ permalink raw reply related
* [PULL 09/18] iotests/279: Fix for non-qcow2 formats
From: Max Reitz @ 2020-02-20 16:07 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
First, driver=qcow2 will not work so well with non-qcow2 formats (and
this test claims to support qcow, qed, and vmdk).
Second, vmdk will always report the backing file format to be vmdk.
Filter that out so the output looks like for all other formats.
Third, the flat vmdk subformats do not support backing files, so they
will not work with this test.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20191219144243.1763246-1-mreitz@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
tests/qemu-iotests/279 | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/279 b/tests/qemu-iotests/279
index 6682376808..30d29b1cb2 100755
--- a/tests/qemu-iotests/279
+++ b/tests/qemu-iotests/279
@@ -38,6 +38,8 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
_supported_fmt qcow qcow2 vmdk qed
_supported_proto file
_supported_os Linux
+_unsupported_imgopts "subformat=monolithicFlat" \
+ "subformat=twoGbMaxExtentFlat" \
TEST_IMG="$TEST_IMG.base" _make_test_img 64M
TEST_IMG="$TEST_IMG.mid" _make_test_img -b "$TEST_IMG.base"
@@ -45,11 +47,12 @@ _make_test_img -b "$TEST_IMG.mid"
echo
echo '== qemu-img info --backing-chain =='
-_img_info --backing-chain | _filter_img_info
+_img_info --backing-chain | _filter_img_info | grep -v 'backing file format'
echo
echo '== qemu-img info --backing-chain --image-opts =='
-TEST_IMG="driver=qcow2,file.driver=file,file.filename=$TEST_IMG" _img_info --backing-chain --image-opts | _filter_img_info
+TEST_IMG="driver=$IMGFMT,file.driver=file,file.filename=$TEST_IMG" _img_info --backing-chain --image-opts \
+ | _filter_img_info | grep -v 'backing file format'
# success, all done
echo "*** done"
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v5 3/8] pmem: Enable pmem_do_write() to deal with arbitrary ranges
From: Christoph Hellwig @ 2020-02-20 16:17 UTC (permalink / raw)
To: Vivek Goyal; +Cc: linux-fsdevel, linux-nvdimm, hch, dm-devel
In-Reply-To: <20200218214841.10076-4-vgoyal@redhat.com>
On Tue, Feb 18, 2020 at 04:48:36PM -0500, Vivek Goyal wrote:
> Currently pmem_do_write() is written with assumption that all I/O is
> sector aligned. Soon I want to use this function in zero_page_range()
> where range passed in does not have to be sector aligned.
>
> Modify this function to be able to deal with an arbitrary range. Which
> is specified by pmem_off and len.
>
> Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply
* Re: [PATCH v5 3/8] pmem: Enable pmem_do_write() to deal with arbitrary ranges
From: Christoph Hellwig @ 2020-02-20 16:17 UTC (permalink / raw)
To: Vivek Goyal
Cc: linux-fsdevel, linux-nvdimm, hch, dan.j.williams, dm-devel,
vishal.l.verma
In-Reply-To: <20200218214841.10076-4-vgoyal@redhat.com>
On Tue, Feb 18, 2020 at 04:48:36PM -0500, Vivek Goyal wrote:
> Currently pmem_do_write() is written with assumption that all I/O is
> sector aligned. Soon I want to use this function in zero_page_range()
> where range passed in does not have to be sector aligned.
>
> Modify this function to be able to deal with an arbitrary range. Which
> is specified by pmem_off and len.
>
> Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: crash on connect
From: Jens Axboe @ 2020-02-20 16:17 UTC (permalink / raw)
To: Glauber Costa, io-uring, Avi Kivity
In-Reply-To: <CAD-J=zbBU2j=a0t2zD7k_aGqguwwkzLpPnnrOUAm2DJ3ZUJFvg@mail.gmail.com>
On 2/20/20 7:19 AM, Glauber Costa wrote:
> Hi there, me again
>
> Kernel is at 043f0b67f2ab8d1af418056bc0cc6f0623d31347
>
> This test is easier to explain: it essentially issues a connect and a
> shutdown right away.
>
> It currently fails due to no fault of io_uring. But every now and then
> it crashes (you may have to run more than once to get it to crash)
>
> Instructions are similar to my last test.
> Except the test to build is now "tests/unit/connect_test"
> Code is at git@github.com:glommer/seastar.git branch io-uring-connect-crash
>
> Run it with ./build/release/tests/unit/connect_test -- -c1
> --reactor-backend=uring
>
> Backtrace attached
Perfect thanks, I'll take a look!
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v5 2/8] drivers/pmem: Allow pmem_clear_poison() to accept arbitrary offset and len
From: Christoph Hellwig @ 2020-02-20 16:17 UTC (permalink / raw)
To: Vivek Goyal; +Cc: linux-fsdevel, linux-nvdimm, hch, dm-devel
In-Reply-To: <20200218214841.10076-3-vgoyal@redhat.com>
On Tue, Feb 18, 2020 at 04:48:35PM -0500, Vivek Goyal wrote:
> Currently pmem_clear_poison() expects offset and len to be sector aligned.
> Atleast that seems to be the assumption with which code has been written.
> It is called only from pmem_do_bvec() which is called only from pmem_rw_page()
> and pmem_make_request() which will only passe sector aligned offset and len.
>
> Soon we want use this function from dax_zero_page_range() code path which
> can try to zero arbitrary range of memory with-in a page. So update this
> function to assume that offset and length can be arbitrary and do the
> necessary alignments as needed.
>
> nvdimm_clear_poison() seems to assume offset and len to be aligned to
> clear_err_unit boundary. But this is currently internal detail and is
> not exported for others to use. So for now, continue to align offset and
> length to SECTOR_SIZE boundary. Improving it further and to align it
> to clear_err_unit boundary is a TODO item for future.
>
> Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
This looks sensibel to me, but I'd really like to have Dan take at look.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply
* Re: [PATCH v5 2/8] drivers/pmem: Allow pmem_clear_poison() to accept arbitrary offset and len
From: Christoph Hellwig @ 2020-02-20 16:17 UTC (permalink / raw)
To: Vivek Goyal
Cc: linux-fsdevel, linux-nvdimm, hch, dan.j.williams, dm-devel,
vishal.l.verma
In-Reply-To: <20200218214841.10076-3-vgoyal@redhat.com>
On Tue, Feb 18, 2020 at 04:48:35PM -0500, Vivek Goyal wrote:
> Currently pmem_clear_poison() expects offset and len to be sector aligned.
> Atleast that seems to be the assumption with which code has been written.
> It is called only from pmem_do_bvec() which is called only from pmem_rw_page()
> and pmem_make_request() which will only passe sector aligned offset and len.
>
> Soon we want use this function from dax_zero_page_range() code path which
> can try to zero arbitrary range of memory with-in a page. So update this
> function to assume that offset and length can be arbitrary and do the
> necessary alignments as needed.
>
> nvdimm_clear_poison() seems to assume offset and len to be aligned to
> clear_err_unit boundary. But this is currently internal detail and is
> not exported for others to use. So for now, continue to align offset and
> length to SECTOR_SIZE boundary. Improving it further and to align it
> to clear_err_unit boundary is a TODO item for future.
>
> Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
This looks sensibel to me, but I'd really like to have Dan take at look.
^ permalink raw reply
* Re: [yocto] Lots of basehash related errors
From: Quentin Schulz @ 2020-02-20 16:16 UTC (permalink / raw)
To: Dmitri Toubelis; +Cc: yocto
In-Reply-To: <RlLC.1582214577544571845.5egw@lists.yoctoproject.org>
Hi Dmitri,
On Thu, Feb 20, 2020 at 08:02:57AM -0800, Dmitri Toubelis wrote:
> Hi,
>
> I'm migrating from yocto morty to zeus and I'm receiving a whole lot of errors like this:
>
> >
> > ERROR: When reparsing
> > /srv/yocto/poky/meta-loopedge/meta-loopedge-dist/recipes-core/images/loopedge-std.bb:do_image_wic,
> > the basehash value changed from
> > 8dd96e09d0b7defa552e586e626933ca37ace5180918ea65addbfcb6c1247b1c to
> > e38fae3f400b3e3de114fcd668d46a1f7c3eec436ec72962e78df906714a6fb0. The
> > metadata is not deterministic and this needs to be fixed.
> > ERROR: The following commands may help:
> > ERROR: $ bitbake loopedge-std -cdo_image_wic -Snone
> > ERROR: Then:
> > ERROR: $ bitbake loopedge-std -cdo_image_wic -Sprintdiff
> >
> > ERROR: When reparsing
> > /srv/yocto/poky/meta-loopedge/meta-loopedge-dist/recipes-core/images/loopedge-std.bb:do_image_ext4,
> > the basehash value changed from
> > a8209ab35324ce59bb193b80871c12c492f69f42fd97b03801165bd4a12670f6 to
> > 1ab2d25ef217fe87b4cce1106d122acd4286043b04dcd74d98df30a01aa6a0b9. The
> > metadata is not deterministic and this needs to be fixed.
> > ERROR: The following commands may help:
> > ERROR: $ bitbake loopedge-std -cdo_image_ext4 -Snone
> > ERROR: Then:
> > ERROR: $ bitbake loopedge-std -cdo_image_ext4 -Sprintdiff
> >
> > ERROR: When reparsing
> > /srv/yocto/poky/meta-loopedge/meta-loopedge-dist/recipes-core/images/loopedge-std.bb:do_image_tar,
> > the basehash value changed from
> > c5ab62cac832e502a338d59124efc690e66560a4e877bc4ba3487c3a734c2497 to
> > bb7ca72863614cb5c9915eb502259b1ffa8b98992f7ad3280d1e049a1824b930. The
> > metadata is not deterministic and this needs to be fixed.
> > ERROR: The following commands may help:
> > ERROR: $ bitbake loopedge-std -cdo_image_tar -Snone
> > ERROR: Then:
> > ERROR: $ bitbake loopedge-std -cdo_image_tar -Sprintdiff
> >
>
> I search around for answers and there are here are reasons and solutions for this that I found:
> - to make sure any date related variables are excluded from basehash via `do_task_name[vardepsexclude] = "DATE DATETIME"`
> - clears state cache with `bitbake image -c cleansstate`
> - delete tmp directory and build from scratch
>
> Here is my observation and interpretation:
> - this messages occur when running with pristine build directory, i.e. it only contains 2 files in `conf` dir - `local.conf` and `bblatyers.conf`, so I can rule out contamination from a previous run.
> - same messages reapeat over and over totalling ~900 errors at the end of the run
> - I have few custom classes and I removed them from the image to rule out contamination from my own code.
> - Tasks that give this error are coming from image.bbclass from poky and none of them have been altered in any way.
> - The image build runs through the end but because bitbake exits with non-zero exit code it breaks lots of our tools, so just ignoring them is a bad option.
>
I've had this before with a vendor layer. The culprit was the distro
having some weird USERADDEXTENSION messing up with everything.
How we found out what it was was by uncommenting:
https://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/siggen.py#n187
187 to 189.
Then you go to tmp/stamps/...your-recipe.../ and you'll have more
sigdata in there. Use bitbake-diffsigs between the both and you'll find
which variable messes up with your build.
Hope this helps, good luck!
Quentin
^ permalink raw reply
* Re: [PATCH] selftests/rseq: Fix out-of-tree compilation
From: Mathieu Desnoyers @ 2020-02-20 16:16 UTC (permalink / raw)
To: Michael Ellerman, Shuah Khan
Cc: linux-kselftest, linux-kernel, Peter Zijlstra, paulmck,
Boqun Feng
In-Reply-To: <20200220113748.15990-1-mpe@ellerman.id.au>
----- On Feb 20, 2020, at 6:37 AM, Michael Ellerman mpe@ellerman.id.au wrote:
> Currently if you build with O=... the rseq tests don't build:
>
> $ make O=$PWD/output -C tools/testing/selftests/ TARGETS=rseq
> make: Entering directory '/linux/tools/testing/selftests'
> ...
> make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ -shared
> -fPIC rseq.c -lpthread -o /linux/output/rseq/librseq.so
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./
> basic_test.c -lpthread -lrseq -o /linux/output/rseq/basic_test
> /usr/bin/ld: cannot find -lrseq
> collect2: error: ld returned 1 exit status
>
> This is because the library search path points to the source
> directory, not the output.
>
> We can fix it by changing the library search path to $(OUTPUT).
Good catch!
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Shuah, can you pick this up please ?
Thanks,
Mathieu
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
>
> This works in all cases.
>
> With O= set:
>
> $ make O=$PWD/output -C tools/testing/selftests/ TARGETS=rseq
> ...
> make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq
> -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/output/rseq/basic_test
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq
> -Wl,-rpath=./ basic_percpu_ops_test.c -lpthread -lrseq -o
> /linux/output/rseq/basic_percpu_ops_test
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq
> -Wl,-rpath=./ param_test.c -lpthread -lrseq -o /linux/output/rseq/param_test
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq
> -Wl,-rpath=./ -DBENCHMARK param_test.c -lpthread -lrseq -o
> /linux/output/rseq/param_test_benchmark
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq
> -Wl,-rpath=./ -DRSEQ_COMPARE_TWICE param_test.c -lpthread -lrseq -o
> /linux/output/rseq/param_test_compare_twice
> make[1]: Leaving directory '/linux/tools/testing/selftests/rseq'
> make: Leaving directory '/linux/tools/testing/selftests'
>
> And also without, in which case the selftest makefiles set OUTPUT to
> the full path of the source directory:
>
> $ make -C tools/testing/selftests/ TARGETS=rseq
> ...
> make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -shared -fPIC rseq.c
> -lpthread -o /linux/tools/testing/selftests/rseq/librseq.so
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_test.c -lpthread
> -lrseq -o /linux/tools/testing/selftests/rseq/basic_test
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_percpu_ops_test.c
> -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_percpu_ops_test
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ param_test.c -lpthread
> -lrseq -o /linux/tools/testing/selftests/rseq/param_test
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DBENCHMARK param_test.c
> -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_benchmark
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DRSEQ_COMPARE_TWICE
> param_test.c -lpthread -lrseq -o
> /linux/tools/testing/selftests/rseq/param_test_compare_twice
> make[1]: Leaving directory '/linux/tools/testing/selftests/rseq'
> make: Leaving directory '/linux/tools/testing/selftests'
>
> And finally, it also works if you build directly in the rseq
> directory, eg:
>
> $ cd tools/testing/selftests/rseq
> $ make
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -shared -fPIC rseq.c
> -lpthread -o /linux/tools/testing/selftests/rseq/librseq.so
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_test.c -lpthread
> -lrseq -o /linux/tools/testing/selftests/rseq/basic_test
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_percpu_ops_test.c
> -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_percpu_ops_test
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ param_test.c -lpthread
> -lrseq -o /linux/tools/testing/selftests/rseq/param_test
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DBENCHMARK param_test.c
> -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_benchmark
> gcc -O2 -Wall -g -I./ -I../../../../usr/include/
> -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DRSEQ_COMPARE_TWICE
> param_test.c -lpthread -lrseq -o
> /linux/tools/testing/selftests/rseq/param_test_compare_twice
> ---
> tools/testing/selftests/rseq/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/rseq/Makefile
> b/tools/testing/selftests/rseq/Makefile
> index d6469535630a..708c1b345245 100644
> --- a/tools/testing/selftests/rseq/Makefile
> +++ b/tools/testing/selftests/rseq/Makefile
> @@ -4,7 +4,7 @@ ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
> CLANG_FLAGS += -no-integrated-as
> endif
>
> -CFLAGS += -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ \
> +CFLAGS += -O2 -Wall -g -I./ -I../../../../usr/include/ -L$(OUTPUT)
> -Wl,-rpath=./ \
> $(CLANG_FLAGS)
> LDLIBS += -lpthread
>
>
> base-commit: 11a48a5a18c63fd7621bb050228cebf13566e4d8
> --
> 2.21.1
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH 2/2] build: Disable PIE in TARGET_CCASFLAGS if needed
From: John Paul Adrian Glaubitz @ 2020-02-20 16:16 UTC (permalink / raw)
To: The development of GNU GRUB, Matt Turner; +Cc: Mike Gilbert
In-Reply-To: <20200220065142.869129-2-mattst88@gmail.com>
Hi Mike!
On 2/20/20 7:51 AM, Matt Turner wrote:
> PIE should be disabled in assembly sources as well, or else grub will
> fail to boot.
Indeed. We have always passed -fno-PIE on Debian/sparc64 in the debian/rules
file to TARGET_CCASFLAGS, but it makes more sense to fix the issue in the
configure.ac.
> Bug: https://bugs.gentoo.org/667852
> ---
> configure.ac | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/configure.ac b/configure.ac
> index b5e31c787..e2c783652 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1263,6 +1263,7 @@ grub_CHECK_LINK_PIE
> # `-fPIE' or '-fpie' and '-pie' in the default specs.
> if [ x"$pie_possible" = xyes ]; then
> TARGET_CFLAGS="$TARGET_CFLAGS -fno-PIE -fno-pie"
> + TARGET_CCASFLAGS="$TARGET_CCASFLAGS -fno-PIE -fno-pie"
> fi
>
> if [ x"$link_nopie_needed" = xyes ] || [ x"$pie_possible" = xyes ]; then
I have not verified yet that fix yet but it makes sense for
the aforementioned reasons.
Thanks for fixing this.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [CIFS][PATCH] Honor the AT_SYNC_TYPE flags
From: Aurélien Aptel @ 2020-02-20 16:15 UTC (permalink / raw)
To: Steve French, CIFS; +Cc: linux-fsdevel
In-Reply-To: <CAH2r5ms3dnvhH1L145krNgMZxoe-E58eAW0=vEBpp6Grfu2H0w@mail.gmail.com>
Reviewed-by: Aurelien Aptel <aaptel@suse.com>
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
^ permalink raw reply
* [PULL 16/18] iotests: Test convert -n -B to backing-less target
From: Max Reitz @ 2020-02-20 16:07 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
This must not crash.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200121155915.98232-3-mreitz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
tests/qemu-iotests/122 | 14 ++++++++++++++
tests/qemu-iotests/122.out | 5 +++++
2 files changed, 19 insertions(+)
diff --git a/tests/qemu-iotests/122 b/tests/qemu-iotests/122
index dfa350936f..f7a3ae684a 100755
--- a/tests/qemu-iotests/122
+++ b/tests/qemu-iotests/122
@@ -276,6 +276,20 @@ $QEMU_IMG convert -O $IMGFMT -n "$TEST_IMG" "$TEST_IMG".orig
$QEMU_IMG compare "$TEST_IMG" "$TEST_IMG".orig
+echo
+echo '=== -n -B to an image without a backing file ==='
+echo
+
+# Base for the output
+TEST_IMG="$TEST_IMG".base _make_test_img 64M
+
+# Output that does have $TEST_IMG.base set as its (implicit) backing file
+TEST_IMG="$TEST_IMG".orig _make_test_img 64M
+
+# Convert with -n, which should not confuse -B with "target BDS has a
+# backing file"
+$QEMU_IMG convert -O $IMGFMT -B "$TEST_IMG".base -n "$TEST_IMG" "$TEST_IMG".orig
+
# success, all done
echo '*** done'
rm -f $seq.full
diff --git a/tests/qemu-iotests/122.out b/tests/qemu-iotests/122.out
index 849b6cc2ef..1a35951a80 100644
--- a/tests/qemu-iotests/122.out
+++ b/tests/qemu-iotests/122.out
@@ -228,4 +228,9 @@ Formatting 'TEST_DIR/t.IMGFMT.orig', fmt=IMGFMT size=67108864
wrote 65536/65536 bytes at offset 0
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
Images are identical.
+
+=== -n -B to an image without a backing file ===
+
+Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=67108864
+Formatting 'TEST_DIR/t.IMGFMT.orig', fmt=IMGFMT size=67108864
*** done
--
2.24.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.