* Re: S variable for svn fetcher Was: State of OE world - 2020-02-18
From: Adrian Bunk @ 2020-02-20 16:11 UTC (permalink / raw)
To: Martin Jansa; +Cc: openembeded-devel
In-Reply-To: <20200220153758.o25tn46hhewgmasd@jama>
On Thu, Feb 20, 2020 at 04:37:58PM +0100, Martin Jansa wrote:
> On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
> > On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> > >...
> > > Any idea why these aren't shown in our build?
> > >...
> >
> > What is your mirror configuration?
> >
> > Default configuration downloads the tarball from [1].
>
> Maybe I'm missing your point, but these aren't fetch issues.
>...
MIRRORS = "" (and deleting the downloaded tar) is what I needed for
getting a build failure.
> Cheers,
cu
Adrian
^ permalink raw reply
* Re: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h
From: Christoph Hellwig @ 2020-02-20 16:11 UTC (permalink / raw)
To: Halil Pasic
Cc: linux-s390, Janosch Frank, Michael S. Tsirkin, Jason Wang,
Cornelia Huck, Ram Pai, linux-kernel, virtualization,
Christian Borntraeger, iommu, David Gibson, Michael Mueller,
Lendacky, Thomas, Viktor Mihajlovski, Robin Murphy,
Christoph Hellwig
In-Reply-To: <20200220160606.53156-2-pasic@linux.ibm.com>
On Thu, Feb 20, 2020 at 05:06:05PM +0100, Halil Pasic wrote:
> Currently force_dma_unencrypted() is only used by the direct
> implementation of the DMA API, and thus resides in dma-direct.h. But
> there is nothing dma-direct specific about it: if one was -- for
> whatever reason -- to implement custom DMA ops that have to in the
> encrypted/protected scenarios dma-direct currently deals with, one would
> need exactly this kind of information.
I really don't think it has business being anywhre else, and your completely
bogus second patch just proves the point.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h
From: Christoph Hellwig @ 2020-02-20 16:11 UTC (permalink / raw)
To: Halil Pasic
Cc: Michael S. Tsirkin, Jason Wang, Marek Szyprowski, Robin Murphy,
Christoph Hellwig, linux-s390, virtualization, linux-kernel,
iommu, Christian Borntraeger, Janosch Frank, Viktor Mihajlovski,
Cornelia Huck, Ram Pai, Thiago Jung Bauermann, David Gibson,
Lendacky, Thomas, Michael Mueller
In-Reply-To: <20200220160606.53156-2-pasic@linux.ibm.com>
On Thu, Feb 20, 2020 at 05:06:05PM +0100, Halil Pasic wrote:
> Currently force_dma_unencrypted() is only used by the direct
> implementation of the DMA API, and thus resides in dma-direct.h. But
> there is nothing dma-direct specific about it: if one was -- for
> whatever reason -- to implement custom DMA ops that have to in the
> encrypted/protected scenarios dma-direct currently deals with, one would
> need exactly this kind of information.
I really don't think it has business being anywhre else, and your completely
bogus second patch just proves the point.
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 094/542] s390/pci: Fix possible deadlock in recover_store()
From: Sasha Levin @ 2020-02-20 16:11 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-kernel, stable, Peter Oberparleiter, Vasily Gorbik,
linux-s390
In-Reply-To: <20200217093156.GB42010@tuxmaker.boeblingen.de.ibm.com>
On Mon, Feb 17, 2020 at 10:31:56AM +0100, Niklas Schnelle wrote:
>On Fri, Feb 14, 2020 at 10:41:26AM -0500, Sasha Levin wrote:
>> From: Niklas Schnelle <schnelle@linux.ibm.com>
>>
>> [ Upstream commit 576c75e36c689bec6a940e807bae27291ab0c0de ]
>>
>> With zpci_disable() working, lockdep detected a potential deadlock
>> (lockdep output at the end).
>>
>> The deadlock is between recovering a PCI function via the
>>
>> /sys/bus/pci/devices/<dev>/recover
>>
>> attribute vs powering it off via
>>
>> /sys/bus/pci/slots/<slot>/power.
>>
>> The fix is analogous to the changes in commit 0ee223b2e1f6 ("scsi: core:
>> Avoid that SCSI device removal through sysfs triggers a deadlock")
>> that fixed a potential deadlock on removing a SCSI device via sysfs.
>[ ... snip ... ]
>
>While technically useful on its own this commit really should go together with
>the following upstream commit:
>
>17cdec960cf776b20b1fb08c622221babe591d51
>("s390/pci: Recover handle in clp_set_pci_fn()")
>
>While the problem fixed here is independent, writing to the power/recover
>attributes will often fail due to an inconsistent function handle without the
>second commit.
>In particular without it a PCI function in the error state can not be
>recovered or powered off.
>
>I would recommend adding the second commit to the backports as well.
I took that commit as well, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v3 4/5] sched/pelt: Add a new runnable average signal
From: Valentin Schneider @ 2020-02-20 16:11 UTC (permalink / raw)
To: Vincent Guittot
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel, Phil Auld,
Parth Shah, Hillf Danton
In-Reply-To: <CAKfTPtD4kz07hikCuU2_cm67ntruopN9CdJEP+fg5L4_N=qEgg@mail.gmail.com>
On 20/02/2020 14:36, Vincent Guittot wrote:
> I agree that setting by default to SCHED_CAPACITY_SCALE is too much
> for little core.
> The problem for little core can be fixed by using the cpu capacity instead
>
So that's indeed better for big.LITTLE & co. Any reason however for not
aligning with the initialization of util_avg ?
With the default MC imbalance_pct (117), it takes 875 utilization to make
a single CPU group (with 1024 capacity) overloaded (group_is_overloaded()).
For a completely idle CPU, that means forking at least 3 tasks (512 + 256 +
128 util_avg)
With your change, it only takes 2 tasks. I know I'm being nitpicky here, but
I feel like those should be aligned, unless we have a proper argument against
it - in which case this should also appear in the changelog with so far only
mentions issues with util_avg migration, not the fork time initialization.
> @@ -796,6 +794,8 @@ void post_init_entity_util_avg(struct task_struct *p)
> }
> }
>
> + sa->runnable_avg = cpu_scale;
> +
> if (p->sched_class != &fair_sched_class) {
> /*
> * For !fair tasks do:
>>
>>> sa->load_avg = scale_load_down(se->load.weight);
>>> + }
>>>
>>> /* when this task enqueue'ed, it will contribute to its cfs_rq's load_avg */
>>> }
^ permalink raw reply
* [PULL 04/18] iotests/147: Fix drive parameters
From: Max Reitz @ 2020-02-20 16:06 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
8dff69b94 added an aio parameter to the drive parameter but forgot to
add a comma before, thus breaking the test. Fix it again.
Fixes: 8dff69b9415b4287e900358744b732195e1ab2e2
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200206130812.612960-1-mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
tests/qemu-iotests/147 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/147 b/tests/qemu-iotests/147
index f4b0a11dba..d7a9f31089 100755
--- a/tests/qemu-iotests/147
+++ b/tests/qemu-iotests/147
@@ -134,7 +134,7 @@ class BuiltinNBD(NBDBlockdevAddBase):
self.server.add_drive_raw('if=none,id=nbd-export,' +
'file=%s,' % test_img +
'format=%s,' % imgfmt +
- 'cache=%s' % cachemode +
+ 'cache=%s,' % cachemode +
'aio=%s' % aiomode)
self.server.launch()
--
2.24.1
^ permalink raw reply related
* [PATCH] firmware: imx: scu: Ensure sequential TX
From: Leonard Crestez @ 2020-02-20 16:10 UTC (permalink / raw)
To: Shawn Guo
Cc: Dong Aisheng, Peng Fan, Richard Zhu, Jassi Brar, Oleksij Rempel,
linux-imx, kernel, Fabio Estevam, Daniel Baluta, linux-arm-kernel
SCU requires that all messages words are written sequentially but linux MU
driver implements multiple independent channels for each register so ordering
between different channels must be ensured by SCU API interface.
Wait for tx_done before every send to ensure that no queueing happens at the
mailbox channel level.
Fixes: edbee095fafb ("firmware: imx: add SCU firmware driver support")
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Cc: <stable@vger.kernel.org>
---
drivers/firmware/imx/imx-scu.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
This manifests as "SCU timeout" message followed by system hang.
This is not a very pretty fix but avoids inserting additional waits
except in extremely rare circumstances.
An alternative would be to implement a new type of mailbox channel which
handles all 4 registers together. Exposing the MU as 4 independent
channels is very awkward.
diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index 03b43b7a6d1d..f71eaa5bf52d 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -27,10 +27,11 @@ struct imx_sc_chan {
struct imx_sc_ipc *sc_ipc;
struct mbox_client cl;
struct mbox_chan *ch;
int idx;
+ struct completion tx_done;
};
struct imx_sc_ipc {
/* SCU uses 4 Tx and 4 Rx channels */
struct imx_sc_chan chans[SCU_MU_CHAN_NUM];
@@ -98,10 +99,18 @@ int imx_scu_get_handle(struct imx_sc_ipc **ipc)
*ipc = imx_sc_ipc_handle;
return 0;
}
EXPORT_SYMBOL(imx_scu_get_handle);
+/* Callback called when the word of a message is ack-ed, eg read by SCU */
+static void imx_scu_tx_done(struct mbox_client *cl, void *mssg, int r)
+{
+ struct imx_sc_chan *sc_chan = container_of(cl, struct imx_sc_chan, cl);
+
+ complete(&sc_chan->tx_done);
+}
+
static void imx_scu_rx_callback(struct mbox_client *c, void *msg)
{
struct imx_sc_chan *sc_chan = container_of(c, struct imx_sc_chan, cl);
struct imx_sc_ipc *sc_ipc = sc_chan->sc_ipc;
struct imx_sc_rpc_msg *hdr;
@@ -147,10 +156,23 @@ static int imx_scu_ipc_write(struct imx_sc_ipc *sc_ipc, void *msg)
dev_dbg(sc_ipc->dev, "RPC SVC %u FUNC %u SIZE %u\n", hdr->svc,
hdr->func, hdr->size);
for (i = 0; i < hdr->size; i++) {
sc_chan = &sc_ipc->chans[i % 4];
+
+ /*
+ * SCU requires that all messages words are written
+ * sequentially but linux MU driver implements multiple
+ * independent channels for each register so ordering between
+ * different channels must be ensured by SCU API interface.
+ *
+ * Wait for tx_done before every send to ensure that no
+ * queueing happens at the mailbox channel level.
+ */
+ wait_for_completion(&sc_chan->tx_done);
+ reinit_completion(&sc_chan->tx_done);
+
ret = mbox_send_message(sc_chan->ch, &data[i]);
if (ret < 0)
return ret;
}
@@ -245,10 +267,15 @@ static int imx_scu_probe(struct platform_device *pdev)
cl->dev = dev;
cl->tx_block = false;
cl->knows_txdone = true;
cl->rx_callback = imx_scu_rx_callback;
+ /* Initial tx_done completion as "done" */
+ cl->tx_done = imx_scu_tx_done;
+ init_completion(&sc_chan->tx_done);
+ complete(&sc_chan->tx_done);
+
sc_chan->sc_ipc = sc_ipc;
sc_chan->idx = i % 4;
sc_chan->ch = mbox_request_channel_byname(cl, chan_name);
if (IS_ERR(sc_chan->ch)) {
ret = PTR_ERR(sc_chan->ch);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: S variable for svn fetcher Was: State of OE world - 2020-02-18
From: Khem Raj @ 2020-02-20 16:10 UTC (permalink / raw)
To: Martin Jansa; +Cc: openembeded-devel
In-Reply-To: <20200220144848.msiyguq2bsmqokxc@jama>
On Thu, Feb 20, 2020 at 6:48 AM Martin Jansa <martin.jansa@gmail.com> wrote:
>
> On Wed, Feb 19, 2020 at 09:29:58AM -0800, Khem Raj wrote:
> > http://www.openembedded.org/wiki/Bitbake_World_Status
> >
> > == Failed tasks /media/ra_build_share/buildlogs/oe/world/dunfell/2020-02-18 ==
> >
> > INFO: jenkins-job.sh-1.8.46 Complete log available at
> > /media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.report.20200219_150007.log
> >
> > === common (0) ===
> >
> > === common-x86 (0) ===
> >
> > === qemuarm (0) ===
> >
> > === qemuarm64 (0) ===
> >
> > === qemux86 (0) ===
> >
> > === qemux86_64 (0) ===
>
> Looks great! Thanks
>
> I was running some world builds recently as well and was surprised that
> there are a few failing recipes in meta-oe:
> s3c24xx-gpio
> s3c64xx-gpio
> wmiconfig
> usbpath
> which are all using svn fetcher.
>
> Any idea why these aren't shown in our build? I was able to reproduce
> this on thud as well as latest master build:
>
perhaps it might be due to the fact that yoe distro uses yocto and oe
source mirrors for tarballs
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/usbpath/usbpath_svn.bb:do_patch
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_compile
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_compile
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_populate_lic
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_populate_lic
> /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/wmiconfig/wmiconfig_svn.bb:do_patch
>
> they have all the same root cause and that is that the
> S variable points to directory where the sources used to be, but now
> they are checked out somewhere else, e.g. s3c24xx-gpio:
>
> LIC_FILES_CHKSUM = "file://gpio.c;endline=12;md5=cfb91c686857b2e60852b4925d90a3e1"
>
> SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
>
> S = "${WORKDIR}/gpio"
>
> And now S looks like this:
> $ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/
> branches trunk
>
> While before I believe it was checking out just this directory (as ${WORKDIR}/gpio):
> $ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/trunk/src/target/gpio/
> gpio.c gpio-glamo.c gpio-s3c6410.c Makefile README
>
> Anyone still actively using svn fetcher for something?
>
> I'll check with even older bitbake to see when it changed, but it's
> still surprising that you wouldn't be seeing it with latest bitbake
> in world builds.
>
> Cheers,
^ permalink raw reply
* [PULL 03/18] iotests: Remove the superfluous 2nd check for the availability of quorum
From: Max Reitz @ 2020-02-20 16:06 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
From: Thomas Huth <thuth@redhat.com>
Commit d9df28e7b07 ("iotests: check whitelisted formats") added the
modern @iotests.skip_if_unsupported() to the functions in this test,
so we don't need the old explicit test here anymore.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20200129141751.32652-1-thuth@redhat.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Tested-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
tests/qemu-iotests/139 | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tests/qemu-iotests/139 b/tests/qemu-iotests/139
index 6b1a444364..7120d3142b 100755
--- a/tests/qemu-iotests/139
+++ b/tests/qemu-iotests/139
@@ -344,9 +344,6 @@ class TestBlockdevDel(iotests.QMPTestCase):
@iotests.skip_if_unsupported(['quorum'])
def testQuorum(self):
- if not iotests.supports_quorum():
- return
-
self.addQuorum('quorum0', 'node0', 'node1')
# We cannot remove the children of a Quorum device
self.delBlockDriverState('node0', expect_error = True)
--
2.24.1
^ permalink raw reply related
* Re: [Intel-gfx] [RFC PATCH i-g-t] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
From: Chris Wilson @ 2020-02-20 16:10 UTC (permalink / raw)
To: Janusz Krzysztofik, igt-dev; +Cc: intel-gfx
In-Reply-To: <158221495468.8112.473694413094253324@skylake-alporthouse-com>
Quoting Chris Wilson (2020-02-20 16:09:14)
> Quoting Janusz Krzysztofik (2020-02-20 15:32:03)
> > Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> > introduced a macro that makes it easy to repeat a test body within a
> > loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
> > API. However, when run on an older version of the driver, those
> > subtests are believed to be still repeated for each known mmap-offset
> > mapping type while effectively exercising GTT mapping type only. As
> > that may be confusing, fix it.
> >
> > It has been assumed that the modified macro is still suitable for use
> > inside gem_mmap_offset test itself. Would that not be case,
> > gem_mmap_offset could redefine the macro back to its initial form for
> > internal use.
> >
> > Suggested-by: Michał Winiarski <michal.winiarski@intel.com>
> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> > lib/i915/gem_mman.h | 5 +++--
> > tests/i915/gem_ctx_sseu.c | 2 +-
> > tests/i915/gem_exec_params.c | 2 +-
> > tests/i915/gem_madvise.c | 18 ++++++++++++++----
> > tests/i915/gem_mmap_offset.c | 10 +++++-----
> > tests/i915/i915_pm_rpm.c | 2 +-
> > 6 files changed, 25 insertions(+), 14 deletions(-)
> >
> > diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
> > index 4fc6a0186..491767023 100644
> > --- a/lib/i915/gem_mman.h
> > +++ b/lib/i915/gem_mman.h
> > @@ -101,9 +101,10 @@ extern const struct mmap_offset {
> > unsigned int domain;
> > } mmap_offset_types[];
> >
> > -#define for_each_mmap_offset_type(__t) \
> > +#define for_each_mmap_offset_type(fd, __t) \
> > for (const struct mmap_offset *__t = mmap_offset_types; \
> > - (__t)->name; \
> > + (__t)->name && (gem_has_mmap_offset(fd) || \
> > + (__t)->type == I915_MMAP_OFFSET_GTT); \
>
> Sigh.
>
> extern bool gem_has_mmap_offset_type(int i915, const struct mmap_offset *t);
>
> && gem_has_mmap_offset_type(fd, t)
Sorry, make that
for_each_if(gem_has_mmap_offset_type(i915, t))
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PULL 06/18] qemu-img: Add --target-is-zero to convert
From: Max Reitz @ 2020-02-20 16:06 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
From: David Edmondson <david.edmondson@oracle.com>
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (reads as zero). In this situation
there is no requirement for qemu-img to wastefully zero out the entire
device.
Add a new option, --target-is-zero, allowing the user to indicate that
an existing target device will return zeros for all reads.
Signed-off-by: David Edmondson <david.edmondson@oracle.com>
Message-Id: <20200205110248.2009589-2-david.edmondson@oracle.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
docs/interop/qemu-img.rst | 9 ++++++++-
qemu-img-cmds.hx | 4 ++--
qemu-img.c | 26 +++++++++++++++++++++++---
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/docs/interop/qemu-img.rst b/docs/interop/qemu-img.rst
index 42e4451db4..5f40137c10 100644
--- a/docs/interop/qemu-img.rst
+++ b/docs/interop/qemu-img.rst
@@ -214,6 +214,13 @@ Parameters to convert subcommand:
will still be printed. Areas that cannot be read from the source will be
treated as containing only zeroes.
+.. option:: --target-is-zero
+
+ Assume that reading the destination image will always return
+ zeros. This parameter is mutually exclusive with a destination image
+ that has a backing file. It is required to also use the ``-n``
+ parameter to skip image creation.
+
Parameters to dd subcommand:
.. program:: qemu-img-dd
@@ -366,7 +373,7 @@ Command description:
4
Error on reading data
-.. option:: convert [--object OBJECTDEF] [--image-opts] [--target-image-opts] [-U] [-C] [-c] [-p] [-q] [-n] [-f FMT] [-t CACHE] [-T SRC_CACHE] [-O OUTPUT_FMT] [-B BACKING_FILE] [-o OPTIONS] [-l SNAPSHOT_PARAM] [-S SPARSE_SIZE] [-m NUM_COROUTINES] [-W] FILENAME [FILENAME2 [...]] OUTPUT_FILENAME
+.. option:: convert [--object OBJECTDEF] [--image-opts] [--target-image-opts] [--target-is-zero] [-U] [-C] [-c] [-p] [-q] [-n] [-f FMT] [-t CACHE] [-T SRC_CACHE] [-O OUTPUT_FMT] [-B BACKING_FILE] [-o OPTIONS] [-l SNAPSHOT_PARAM] [-S SPARSE_SIZE] [-m NUM_COROUTINES] [-W] FILENAME [FILENAME2 [...]] OUTPUT_FILENAME
Convert the disk image *FILENAME* or a snapshot *SNAPSHOT_PARAM*
to disk image *OUTPUT_FILENAME* using format *OUTPUT_FMT*. It can
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index d7fbc6b1f4..c9c54de1df 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -39,9 +39,9 @@ SRST
ERST
DEF("convert", img_convert,
- "convert [--object objectdef] [--image-opts] [--target-image-opts] [-U] [-C] [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T src_cache] [-O output_fmt] [-B backing_file] [-o options] [-l snapshot_param] [-S sparse_size] [-m num_coroutines] [-W] [--salvage] filename [filename2 [...]] output_filename")
+ "convert [--object objectdef] [--image-opts] [--target-image-opts] [--target-is-zero] [-U] [-C] [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T src_cache] [-O output_fmt] [-B backing_file] [-o options] [-l snapshot_param] [-S sparse_size] [-m num_coroutines] [-W] [--salvage] filename [filename2 [...]] output_filename")
SRST
-.. option:: convert [--object OBJECTDEF] [--image-opts] [--target-image-opts] [-U] [-C] [-c] [-p] [-q] [-n] [-f FMT] [-t CACHE] [-T SRC_CACHE] [-O OUTPUT_FMT] [-B BACKING_FILE] [-o OPTIONS] [-l SNAPSHOT_PARAM] [-S SPARSE_SIZE] [-m NUM_COROUTINES] [-W] [--salvage] FILENAME [FILENAME2 [...]] OUTPUT_FILENAME
+.. option:: convert [--object OBJECTDEF] [--image-opts] [--target-image-opts] [--target-is-zero] [-U] [-C] [-c] [-p] [-q] [-n] [-f FMT] [-t CACHE] [-T SRC_CACHE] [-O OUTPUT_FMT] [-B BACKING_FILE] [-o OPTIONS] [-l SNAPSHOT_PARAM] [-S SPARSE_SIZE] [-m NUM_COROUTINES] [-W] [--salvage] FILENAME [FILENAME2 [...]] OUTPUT_FILENAME
ERST
DEF("create", img_create,
diff --git a/qemu-img.c b/qemu-img.c
index 2b4562b9d9..0faf2cd2f5 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -70,6 +70,7 @@ enum {
OPTION_PREALLOCATION = 265,
OPTION_SHRINK = 266,
OPTION_SALVAGE = 267,
+ OPTION_TARGET_IS_ZERO = 268,
};
typedef enum OutputFormat {
@@ -1984,10 +1985,9 @@ static int convert_do_copy(ImgConvertState *s)
int64_t sector_num = 0;
/* Check whether we have zero initialisation or can get it efficiently */
- if (s->target_is_new && s->min_sparse && !s->target_has_backing) {
+ if (!s->has_zero_init && s->target_is_new && s->min_sparse &&
+ !s->target_has_backing) {
s->has_zero_init = bdrv_has_zero_init(blk_bs(s->target));
- } else {
- s->has_zero_init = false;
}
if (!s->has_zero_init && !s->target_has_backing &&
@@ -2086,6 +2086,7 @@ static int img_convert(int argc, char **argv)
{"force-share", no_argument, 0, 'U'},
{"target-image-opts", no_argument, 0, OPTION_TARGET_IMAGE_OPTS},
{"salvage", no_argument, 0, OPTION_SALVAGE},
+ {"target-is-zero", no_argument, 0, OPTION_TARGET_IS_ZERO},
{0, 0, 0, 0}
};
c = getopt_long(argc, argv, ":hf:O:B:Cco:l:S:pt:T:qnm:WU",
@@ -2209,6 +2210,14 @@ static int img_convert(int argc, char **argv)
case OPTION_TARGET_IMAGE_OPTS:
tgt_image_opts = true;
break;
+ case OPTION_TARGET_IS_ZERO:
+ /*
+ * The user asserting that the target is blank has the
+ * same effect as the target driver supporting zero
+ * initialisation.
+ */
+ s.has_zero_init = true;
+ break;
}
}
@@ -2247,6 +2256,11 @@ static int img_convert(int argc, char **argv)
warn_report("This will become an error in future QEMU versions.");
}
+ if (s.has_zero_init && !skip_create) {
+ error_report("--target-is-zero requires use of -n flag");
+ goto fail_getopt;
+ }
+
s.src_num = argc - optind - 1;
out_filename = s.src_num >= 1 ? argv[argc - 1] : NULL;
@@ -2380,6 +2394,12 @@ static int img_convert(int argc, char **argv)
}
s.target_has_backing = (bool) out_baseimg;
+ if (s.has_zero_init && s.target_has_backing) {
+ error_report("Cannot use --target-is-zero when the destination "
+ "image has a backing file");
+ goto out;
+ }
+
if (s.src_num > 1 && out_baseimg) {
error_report("Having a backing file for the target makes no sense when "
"concatenating multiple input images");
--
2.24.1
^ permalink raw reply related
* [PULL 02/18] docs: qcow2: introduce compression type feature
From: Max Reitz @ 2020-02-20 16:06 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
The patch adds a new additional field to the qcow2 header: compression_type,
which specifies compression type. If field is absent or zero, default
compression type is set: ZLIB, which corresponds to current behavior.
New compression type (ZSTD) is to be added in further commit.
Suggested-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200131142219.3264-3-vsementsov@virtuozzo.com>
[mreitz: s/Bits 3-63: Reserved/Bits 4-63: Reserved/]
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
docs/interop/qcow2.txt | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index 823cc266e0..5597e24474 100644
--- a/docs/interop/qcow2.txt
+++ b/docs/interop/qcow2.txt
@@ -109,7 +109,12 @@ the next fields through header_length.
An External Data File Name header extension may
be present if this bit is set.
- Bits 3-63: Reserved (set to 0)
+ Bit 3: Compression type bit. If this bit is set,
+ a non-default compression is used for compressed
+ clusters. The compression_type field must be
+ present and not zero.
+
+ Bits 4-63: Reserved (set to 0)
80 - 87: compatible_features
Bitmask of compatible features. An implementation can
@@ -190,7 +195,19 @@ present*, if not altered by a specific incompatible bit.
to the field's offset. Also, all additional fields are not present for
version 2.
- < ... No additional fields in the header currently ... >
+ 104: compression_type
+
+ Defines the compression method used for compressed clusters.
+ All compressed clusters in an image use the same compression
+ type.
+
+ If the incompatible bit "Compression type" is set: the field
+ must be present and non-zero (which means non-zlib
+ compression type). Otherwise, this field must not be present
+ or must be zero (which means zlib).
+
+ Available compression type values:
+ 0: zlib <https://www.zlib.net/>
=== Header padding ===
--
2.24.1
^ permalink raw reply related
* [PATCH RESEND v6 08/16] sh/mm: Use helper fault_signal_pending()
From: Peter Xu @ 2020-02-20 16:02 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Peter Xu, Martin Cracauer, Mike Rapoport, Hugh Dickins,
Jerome Glisse, Kirill A . Shutemov, Matthew Wilcox,
Pavel Emelyanov, Brian Geffon, Maya Gokhale, Denis Plotnikov,
Andrea Arcangeli, Johannes Weiner, Dr . David Alan Gilbert,
Linus Torvalds, Mike Kravetz, Marty McFadden, David Hildenbrand,
Bobby Powers, Mel Gorman
In-Reply-To: <20200220155353.8676-1-peterx@redhat.com>
Let SH to use the new fault_signal_pending() helper. Here we'll need
to move the up_read() out because that's actually needed as long as
!RETRY cases. At the meantime we can drop all the rest of up_read()s
now (which seems to be cleaner).
Signed-off-by: Peter Xu <peterx@redhat.com>
---
arch/sh/mm/fault.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/sh/mm/fault.c b/arch/sh/mm/fault.c
index 5f51456f4fc7..eb4048ad0b38 100644
--- a/arch/sh/mm/fault.c
+++ b/arch/sh/mm/fault.c
@@ -302,25 +302,25 @@ mm_fault_error(struct pt_regs *regs, unsigned long error_code,
* Pagefault was interrupted by SIGKILL. We have no reason to
* continue pagefault.
*/
- if (fatal_signal_pending(current)) {
- if (!(fault & VM_FAULT_RETRY))
- up_read(¤t->mm->mmap_sem);
+ if (fault_signal_pending(fault, regs)) {
if (!user_mode(regs))
no_context(regs, error_code, address);
return 1;
}
+ /* Release mmap_sem first if necessary */
+ if (!(fault & VM_FAULT_RETRY))
+ up_read(¤t->mm->mmap_sem);
+
if (!(fault & VM_FAULT_ERROR))
return 0;
if (fault & VM_FAULT_OOM) {
/* Kernel mode? Handle exceptions or die: */
if (!user_mode(regs)) {
- up_read(¤t->mm->mmap_sem);
no_context(regs, error_code, address);
return 1;
}
- up_read(¤t->mm->mmap_sem);
/*
* We ran out of memory, call the OOM killer, and return the
--
2.24.1
^ permalink raw reply related
* Re: [Intel-gfx] [RFC PATCH i-g-t] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
From: Chris Wilson @ 2020-02-20 16:09 UTC (permalink / raw)
To: Janusz Krzysztofik, igt-dev; +Cc: intel-gfx
In-Reply-To: <20200220153203.29571-1-janusz.krzysztofik@linux.intel.com>
Quoting Janusz Krzysztofik (2020-02-20 15:32:03)
> Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> introduced a macro that makes it easy to repeat a test body within a
> loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
> API. However, when run on an older version of the driver, those
> subtests are believed to be still repeated for each known mmap-offset
> mapping type while effectively exercising GTT mapping type only. As
> that may be confusing, fix it.
>
> It has been assumed that the modified macro is still suitable for use
> inside gem_mmap_offset test itself. Would that not be case,
> gem_mmap_offset could redefine the macro back to its initial form for
> internal use.
>
> Suggested-by: Michał Winiarski <michal.winiarski@intel.com>
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> lib/i915/gem_mman.h | 5 +++--
> tests/i915/gem_ctx_sseu.c | 2 +-
> tests/i915/gem_exec_params.c | 2 +-
> tests/i915/gem_madvise.c | 18 ++++++++++++++----
> tests/i915/gem_mmap_offset.c | 10 +++++-----
> tests/i915/i915_pm_rpm.c | 2 +-
> 6 files changed, 25 insertions(+), 14 deletions(-)
>
> diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
> index 4fc6a0186..491767023 100644
> --- a/lib/i915/gem_mman.h
> +++ b/lib/i915/gem_mman.h
> @@ -101,9 +101,10 @@ extern const struct mmap_offset {
> unsigned int domain;
> } mmap_offset_types[];
>
> -#define for_each_mmap_offset_type(__t) \
> +#define for_each_mmap_offset_type(fd, __t) \
> for (const struct mmap_offset *__t = mmap_offset_types; \
> - (__t)->name; \
> + (__t)->name && (gem_has_mmap_offset(fd) || \
> + (__t)->type == I915_MMAP_OFFSET_GTT); \
Sigh.
extern bool gem_has_mmap_offset_type(int i915, const struct mmap_offset *t);
&& gem_has_mmap_offset_type(fd, t)
in case we need to fix it again in future.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 4/4] Btrfs: implement full reflink support for inline extents
From: Filipe Manana @ 2020-02-20 16:09 UTC (permalink / raw)
To: Josef Bacik; +Cc: linux-btrfs
In-Reply-To: <4ac11008-d118-1877-151d-3e7da3e9a73a@toxicpanda.com>
On Thu, Feb 20, 2020 at 3:30 PM Josef Bacik <josef@toxicpanda.com> wrote:
>
> On 2/19/20 9:06 AM, fdmanana@kernel.org wrote:
> > From: Filipe Manana <fdmanana@suse.com>
> >
> > There are a few cases where we don't allow cloning an inline extent into
> > the destination inode, returning -EOPNOTSUPP to user space. This was done
> > to prevent several types of file corruption and because it's not very
> > straightforward to deal with these cases, as they can't rely on simply
> > copying the inline extent between leaves. Such cases require copying the
> > inline extent's data into the respective page of the destination inode.
> >
> > Not supporting these cases makes it harder and more cumbersome to write
> > applications/libraries that work on any filesystem with reflink support,
> > since all these cases for which btrfs fails with -EOPNOTSUPP work just
> > fine on xfs for example. These unsupported cases are also not documented
> > anywhere and explaining which exact cases fail require a bit of too
> > technical understanding of btrfs's internal (inline extents and when and
> > where can they exist in a file), so it's not really user friendly.
> >
> > Also some test cases from fstests that use fsx, such as generic/522 for
> > example, can sporadically fail because they trigger one of these cases,
> > and fsx expects all operations to succeed.
> >
> > This change adds supports for cloning all these cases by copying the
> > inline extent's data into the respective page of the destination inode.
> >
> > With this change test case btrfs/112 from fstests fails because it
> > expects some clone operations to fail, so it will be updated. Also a
> > new test case that exercises all these previously unsupported cases
> > will be added to fstests.
> >
> > Signed-off-by: Filipe Manana <fdmanana@suse.com>
> > ---
> > fs/btrfs/reflink.c | 212 ++++++++++++++++++++++++++++++++-------------
> > 1 file changed, 152 insertions(+), 60 deletions(-)
> >
> > diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
> > index 7e7f46116db3..c19c87de6d4a 100644
> > --- a/fs/btrfs/reflink.c
> > +++ b/fs/btrfs/reflink.c
> > @@ -1,8 +1,12 @@
> > // SPDX-License-Identifier: GPL-2.0
> >
> > #include <linux/iversion.h>
> > +#include <linux/blkdev.h>
> > #include "misc.h"
> > #include "ctree.h"
> > +#include "btrfs_inode.h"
> > +#include "compression.h"
> > +#include "delalloc-space.h"
> > #include "transaction.h"
> >
> > #define BTRFS_MAX_DEDUPE_LEN SZ_16M
> > @@ -43,30 +47,121 @@ static int clone_finish_inode_update(struct btrfs_trans_handle *trans,
> > return ret;
> > }
> >
> > +static int copy_inline_to_page(struct inode *inode,
> > + const u64 file_offset,
> > + char *inline_data,
> > + const u64 size,
> > + const u64 datal,
> > + const u8 comp_type)
> > +{
> > + const u64 block_size = btrfs_inode_sectorsize(inode);
> > + const u64 range_end = file_offset + block_size - 1;
> > + const size_t inline_size = size - btrfs_file_extent_calc_inline_size(0);
> > + char *data_start = inline_data + btrfs_file_extent_calc_inline_size(0);
> > + struct extent_changeset *data_reserved = NULL;
> > + struct page *page = NULL;
> > + bool page_locked = false;
> > + int ret;
> > +
> > + ASSERT(IS_ALIGNED(file_offset, block_size));
> > +
> > + ret = btrfs_delalloc_reserve_space(inode, &data_reserved, file_offset,
> > + block_size);
>
> This could potentially deadlock, as we could need to flush delalloc for this
> inode that we've dirtied pages for and not be able to make progress because we
> have this range locked.
But we have already flushed the range before, after locking the inode
and waiting for dio requests,
so during the reflink operation no one should be able to dirty pages
in the range. Or did I miss some edge case?
thanks
>
> Josef
^ permalink raw reply
* Re: vsock CID questions
From: Ján Tomko @ 2020-02-20 16:09 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: ted.h.kim, sgarzare, netdev
In-Reply-To: <20200219154317.GB1085125@stefanha-x1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]
On Wed, Feb 19, 2020 at 03:43:17PM +0000, Stefan Hajnoczi wrote:
>On Tue, Feb 18, 2020 at 02:45:38PM -0800, ted.h.kim@oracle.com wrote:
>> 1. Is there an API to lookup CIDs of guests from the host side (in libvirt)?
>
>I wonder if it can be queried from libvirt (at a minimum the domain XML
>might have the CID)? I have CCed Ján Tomko who worked on the libvirt
>support:
>
>https://libvirt.org/formatdomain.html#vsock
>
Yes, libvirt has to know the CIDs of the guest and presents them in the
domain XML:
<domain type='kvm'>
<name>test</name>
...
<devices>
...
<vsock model='virtio'>
<cid auto='no' address='4'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</vsock>
</devices>
</domain>
>> 2. In the vsock(7) man page, it says the CID might change upon migration, if
>> it is not available.
>> Is there some notification when CID reassignment happens?
>
>All established connections are reset across live migration -
>applications will notice :).
>
>Listen sockets stay open but automatically listen on the new CID.
>
>> 3. if CID reassignment happens, is this persistent? (i.e. will I see updated
>> vsock definition in XML for the guest)
>
>Another question for Ján.
Depends on the setting.
For <cid auto='yes'/>, libvirt will try to acquire the first available CID
for the guest and pass it to QEMU.
For <cid auto='no'/>, no reassignment should happend and the CID
requested in the domain XML on the source will be used (or fail to be
used) on the destination.
Jano
>
>> 4. I would like to minimize the chance of CID collision. If I understand
>> correctly, the CID is a 32-bit unsigned. So for my application, it might
>> work to put an IPv4 address. But if I adopt this convention, then I need to
>> look forward to possibly using IPv6. Anyway, would it be hard to potentially
>> expand the size of the CID to 64 bits or even 128?
>
>A little hard, since the struct sockaddr_vm that userspace applications
>use has a 32-bit CID field. This is because the existing VMware VMCI
>vsock implementation has 32-bit CIDs.
>
>virtio-vsock is ready for 64-bit CIDs (the packet header fields are
>already 64-bit) but changes to net/vmw_vsock/ core code and to the
>userspace ABI would be necessary.
>
>Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: mvneta: comphy regression with SolidRun ClearFog
From: Willy Tarreau @ 2020-02-20 16:08 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Joel Johnson, David S. Miller, Baruch Siach, Gregory Clement,
Thomas Petazzoni, Rob Herring, netdev
In-Reply-To: <20200220154521.GB25745@shell.armlinux.org.uk>
On Thu, Feb 20, 2020 at 03:45:21PM +0000, Russell King - ARM Linux admin wrote:
> > With the current defaults, it seems like PHY_MVEBU_CP110_COMPHY may be
> > affected in Debian the same way as PHY_MVEBU_A38X_COMPHY, but I don't have
> > available Armada 7K/8K hardware yet to confirm.
On this point I can confirm that my mcbin does require
CONFIG_PHY_MVEBU_CP110_COMPHY to work correctly.
> There is no clear answer to whether should something default to Y,
> M or N - different people have different ideas and different levels
> of frustration with which-ever are picked.
>
> The root problem is that there are way too many configuration
> options that it's become quite time consuming to put together the
> proper kernel configuration for any particular platform, and things
> get even more interesting when it comes to a kernel supporting
> multiple platforms, where one may wish to avoid having a huge
> kernel image, but want to use modules for the platform specific
> bits.
>
> I wonder whether we ought to be considering something like:
>
> menuconfig ARCH_MVEBU_DEFAULTS
> tristate "Marvell Engineering Business Unit (MVEBU) SoCs"
>
> config ARCH_MVEBU
> def_bool y if ARCH_MVEBU_DEFAULTS
> ...
>
> and then have mvebu drivers default to the state of
> ARCH_MVEBU_DEFAULTS. That means, if you want to build the
> platform with modular drivers, or built-in drivers there's one top
> level config that will default all the appropriate options that way,
> and any new drivers added later can pick up on the state of that
> option.
>
> Just a thought.
I found that phys are actually a very obscure area for many users, a
bit like codecs for sound, and that even when you think you know what
you're doing you can get it wrong. Part of the reason is the common
total disconnection between certain phy chips and the places they're
used (sometimes different vendors for the PHY and the MAC), and actually
a very good approach would be to clearly enumerate a list of candidate
platforms instead of families. Typically for A38X and CP110 it's clearly
mentioned in the help messages that they're for Armada 38x/7k/8k but
often it's obscure (e.g. the USB phy descriptions in the same Kconfig
are less easy to figure, such as "28nm SoC" or "Berlin SoCs").
I tend to also agree with Russell you that having an option to turn
on sane defaults for a given platform that's well maintained like
mvebu could save quite some time.
Willy
^ permalink raw reply
* Re: [igt-dev] [RFC PATCH i-g-t] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
From: Chris Wilson @ 2020-02-20 16:09 UTC (permalink / raw)
To: Janusz Krzysztofik, igt-dev; +Cc: intel-gfx
In-Reply-To: <20200220153203.29571-1-janusz.krzysztofik@linux.intel.com>
Quoting Janusz Krzysztofik (2020-02-20 15:32:03)
> Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> introduced a macro that makes it easy to repeat a test body within a
> loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
> API. However, when run on an older version of the driver, those
> subtests are believed to be still repeated for each known mmap-offset
> mapping type while effectively exercising GTT mapping type only. As
> that may be confusing, fix it.
>
> It has been assumed that the modified macro is still suitable for use
> inside gem_mmap_offset test itself. Would that not be case,
> gem_mmap_offset could redefine the macro back to its initial form for
> internal use.
>
> Suggested-by: Michał Winiarski <michal.winiarski@intel.com>
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> lib/i915/gem_mman.h | 5 +++--
> tests/i915/gem_ctx_sseu.c | 2 +-
> tests/i915/gem_exec_params.c | 2 +-
> tests/i915/gem_madvise.c | 18 ++++++++++++++----
> tests/i915/gem_mmap_offset.c | 10 +++++-----
> tests/i915/i915_pm_rpm.c | 2 +-
> 6 files changed, 25 insertions(+), 14 deletions(-)
>
> diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
> index 4fc6a0186..491767023 100644
> --- a/lib/i915/gem_mman.h
> +++ b/lib/i915/gem_mman.h
> @@ -101,9 +101,10 @@ extern const struct mmap_offset {
> unsigned int domain;
> } mmap_offset_types[];
>
> -#define for_each_mmap_offset_type(__t) \
> +#define for_each_mmap_offset_type(fd, __t) \
> for (const struct mmap_offset *__t = mmap_offset_types; \
> - (__t)->name; \
> + (__t)->name && (gem_has_mmap_offset(fd) || \
> + (__t)->type == I915_MMAP_OFFSET_GTT); \
Sigh.
extern bool gem_has_mmap_offset_type(int i915, const struct mmap_offset *t);
&& gem_has_mmap_offset_type(fd, t)
in case we need to fix it again in future.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [yocto] Lots of basehash related errors
From: Alexander Kanavin @ 2020-02-20 16:09 UTC (permalink / raw)
To: Dmitri Toubelis; +Cc: yocto
In-Reply-To: <RlLC.1582214577544571845.5egw@lists.yoctoproject.org>
[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]
It's an issue with a recipe in your custom layer. If you can show the
layer, we may be able to help.
Are you sure a current timestamp isn't sneaked into the build by
something in that layer?
Alex
On Thu, 20 Feb 2020 at 17:03, Dmitri Toubelis <
dmitri.toubelis@litmusautomation.com> 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.
>
> So, am I doing something obviously wrong? It is a known issue in zeus? And
> if so is there a known workaround?
>
> Thanks in advance.
>
>
>
[-- Attachment #2: Type: text/html, Size: 3826 bytes --]
^ permalink raw reply
* [PULL 01/18] docs: improve qcow2 spec about extending image header
From: Max Reitz @ 2020-02-20 16:06 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Make it more obvious how to add new fields to the version 3 header and
how to interpret them.
The specification is adjusted so that for new defined optional fields:
1. Software may support some of these optional fields and ignore the
others, which means that features may be backported to downstream
Qemu independently.
2. If we want to add incompatible field (or a field, for which some of
its values would be incompatible), it must be accompanied by
incompatible feature bit.
Also the concept of "default is zero" is clarified, as it's strange to
say that the value of the field is assumed to be zero for the software
version which don't know about the field at all and don't know how to
treat it be it zero or not.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200131142219.3264-2-vsementsov@virtuozzo.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
[mreitz: s/some its/some of its/]
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
docs/interop/qcow2.txt | 45 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index af5711e533..823cc266e0 100644
--- a/docs/interop/qcow2.txt
+++ b/docs/interop/qcow2.txt
@@ -79,9 +79,9 @@ The first cluster of a qcow2 image contains the file header:
Offset into the image file at which the snapshot table
starts. Must be aligned to a cluster boundary.
-If the version is 3 or higher, the header has the following additional fields.
-For version 2, the values are assumed to be zero, unless specified otherwise
-in the description of a field.
+For version 2, the header is exactly 72 bytes in length, and finishes here.
+For version 3 or higher, the header length is at least 104 bytes, including
+the next fields through header_length.
72 - 79: incompatible_features
Bitmask of incompatible features. An implementation must
@@ -164,6 +164,45 @@ in the description of a field.
100 - 103: header_length
Length of the header structure in bytes. For version 2
images, the length is always assumed to be 72 bytes.
+ For version 3 it's at least 104 bytes and must be a multiple
+ of 8.
+
+
+=== Additional fields (version 3 and higher) ===
+
+In general, these fields are optional and may be safely ignored by the software,
+as well as filled by zeros (which is equal to field absence), if software needs
+to set field B, but does not care about field A which precedes B. More
+formally, additional fields have the following compatibility rules:
+
+1. If the value of the additional field must not be ignored for correct
+handling of the file, it will be accompanied by a corresponding incompatible
+feature bit.
+
+2. If there are no unrecognized incompatible feature bits set, an unknown
+additional field may be safely ignored other than preserving its value when
+rewriting the image header.
+
+3. An explicit value of 0 will have the same behavior as when the field is not
+present*, if not altered by a specific incompatible bit.
+
+*. A field is considered not present when header_length is less than or equal
+to the field's offset. Also, all additional fields are not present for
+version 2.
+
+ < ... No additional fields in the header currently ... >
+
+
+=== Header padding ===
+
+@header_length must be a multiple of 8, which means that if the end of the last
+additional field is not aligned, some padding is needed. This padding must be
+zeroed, so that if some existing (or future) additional field will fall into
+the padding, it will be interpreted accordingly to point [3.] of the previous
+paragraph, i.e. in the same manner as when this field is not present.
+
+
+=== Header extensions ===
Directly after the image header, optional sections called header extensions can
be stored. Each extension has a structure like the following:
--
2.24.1
^ permalink raw reply related
* [PATCH RESEND v6 16/16] mm/userfaultfd: Honor FAULT_FLAG_KILLABLE in fault path
From: Peter Xu @ 2020-02-20 16:03 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Peter Xu, Martin Cracauer, Mike Rapoport, Hugh Dickins,
Jerome Glisse, Kirill A . Shutemov, Matthew Wilcox,
Pavel Emelyanov, Brian Geffon, Maya Gokhale, Denis Plotnikov,
Andrea Arcangeli, Johannes Weiner, Dr . David Alan Gilbert,
Linus Torvalds, Mike Kravetz, Marty McFadden, David Hildenbrand,
Bobby Powers, Mel Gorman
In-Reply-To: <20200220155353.8676-1-peterx@redhat.com>
Userfaultfd fault path was by default killable even if the caller does
not have FAULT_FLAG_KILLABLE. That makes sense before in that when
with gup we don't have FAULT_FLAG_KILLABLE properly set before. Now
after previous patch we've got FAULT_FLAG_KILLABLE applied even for
gup code so it should also make sense to let userfaultfd to honor the
FAULT_FLAG_KILLABLE.
Because we're unconditionally setting FAULT_FLAG_KILLABLE in gup code
right now, this patch should have no functional change. It also
cleaned the code a little bit by introducing some helpers.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
fs/userfaultfd.c | 36 ++++++++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index c076d3295958..703c1c3faa6e 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -334,6 +334,30 @@ static inline bool userfaultfd_must_wait(struct userfaultfd_ctx *ctx,
return ret;
}
+/* Should pair with userfaultfd_signal_pending() */
+static inline long userfaultfd_get_blocking_state(unsigned int flags)
+{
+ if (flags & FAULT_FLAG_INTERRUPTIBLE)
+ return TASK_INTERRUPTIBLE;
+
+ if (flags & FAULT_FLAG_KILLABLE)
+ return TASK_KILLABLE;
+
+ return TASK_UNINTERRUPTIBLE;
+}
+
+/* Should pair with userfaultfd_get_blocking_state() */
+static inline bool userfaultfd_signal_pending(unsigned int flags)
+{
+ if (flags & FAULT_FLAG_INTERRUPTIBLE)
+ return signal_pending(current);
+
+ if (flags & FAULT_FLAG_KILLABLE)
+ return fatal_signal_pending(current);
+
+ return false;
+}
+
/*
* The locking rules involved in returning VM_FAULT_RETRY depending on
* FAULT_FLAG_ALLOW_RETRY, FAULT_FLAG_RETRY_NOWAIT and
@@ -355,7 +379,7 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason)
struct userfaultfd_ctx *ctx;
struct userfaultfd_wait_queue uwq;
vm_fault_t ret = VM_FAULT_SIGBUS;
- bool must_wait, return_to_userland;
+ bool must_wait;
long blocking_state;
/*
@@ -462,9 +486,7 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason)
uwq.ctx = ctx;
uwq.waken = false;
- return_to_userland = vmf->flags & FAULT_FLAG_INTERRUPTIBLE;
- blocking_state = return_to_userland ? TASK_INTERRUPTIBLE :
- TASK_KILLABLE;
+ blocking_state = userfaultfd_get_blocking_state(vmf->flags);
spin_lock_irq(&ctx->fault_pending_wqh.lock);
/*
@@ -490,8 +512,7 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason)
up_read(&mm->mmap_sem);
if (likely(must_wait && !READ_ONCE(ctx->released) &&
- (return_to_userland ? !signal_pending(current) :
- !fatal_signal_pending(current)))) {
+ !userfaultfd_signal_pending(vmf->flags))) {
wake_up_poll(&ctx->fd_wqh, EPOLLIN);
schedule();
ret |= VM_FAULT_MAJOR;
@@ -513,8 +534,7 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason)
set_current_state(blocking_state);
if (READ_ONCE(uwq.waken) ||
READ_ONCE(ctx->released) ||
- (return_to_userland ? signal_pending(current) :
- fatal_signal_pending(current)))
+ userfaultfd_signal_pending(vmf->flags))
break;
schedule();
}
--
2.24.1
^ permalink raw reply related
* Re: [Xen-devel] [PATCH] x86/vpt: update last_guest_time with cmpxchg and drop pl_time_lock
From: Igor Druzhinin @ 2020-02-20 16:08 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, roger.pau, wl, andrew.cooper3
In-Reply-To: <177eafce-7f19-0792-eac2-62ac7b13feb0@suse.com>
On 20/02/2020 15:47, Jan Beulich wrote:
> On 20.02.2020 16:37, Igor Druzhinin wrote:
>> On 20/02/2020 08:27, Jan Beulich wrote:
>>> On 19.02.2020 19:52, Igor Druzhinin wrote:
>>>> On 19/02/2020 07:48, Jan Beulich wrote:
>>>>> On 20.12.2019 22:39, Igor Druzhinin wrote:
>>>>>> @@ -38,24 +37,22 @@ void hvm_init_guest_time(struct domain *d)
>>>>>> uint64_t hvm_get_guest_time_fixed(const struct vcpu *v, uint64_t at_tsc)
>>>>>> {
>>>>>> struct pl_time *pl = v->domain->arch.hvm.pl_time;
>>>>>> - u64 now;
>>>>>> + s_time_t old, new, now = get_s_time_fixed(at_tsc) + pl->stime_offset;
>>>>>>
>>>>>> /* Called from device models shared with PV guests. Be careful. */
>>>>>> ASSERT(is_hvm_vcpu(v));
>>>>>>
>>>>>> - spin_lock(&pl->pl_time_lock);
>>>>>> - now = get_s_time_fixed(at_tsc) + pl->stime_offset;
>>>>>> -
>>>>>> if ( !at_tsc )
>>>>>> {
>>>>>> - if ( (int64_t)(now - pl->last_guest_time) > 0 )
>>>>>> - pl->last_guest_time = now;
>>>>>> - else
>>>>>> - now = ++pl->last_guest_time;
>>>>>> + do {
>>>>>> + old = pl->last_guest_time;
>>>>>> + new = now > pl->last_guest_time ? now : old + 1;
>>>>>> + } while ( cmpxchg(&pl->last_guest_time, old, new) != old );
>>>>>
>>>>> I wonder whether you wouldn't better re-invoke get_s_time() in
>>>>> case you need to retry here. See how the function previously
>>>>> was called only after the lock was already acquired.
>>>>
>>>> If there is a concurrent writer, wouldn't it just update pl->last_guest_time
>>>> with the new get_s_time() and then we subsequently would just use the new
>>>> time on retry?
>>>
>>> Yes, it would, but the latency until the retry actually occurs
>>> is unknown (in particular if Xen itself runs virtualized). I.e.
>>> in the at_tsc == 0 case I think the value would better be
>>> re-calculated on every iteration.
>>
>> Why does it need to be recalculated if a concurrent writer did this
>> for us already anyway and (get_s_time_fixed(at_tsc) + pl->stime_offset)
>> value is common for all of vCPUs? Yes, it might reduce jitter slightly
>> but overall latency could come from any point (especially in case of
>> rinning virtualized) and it's important just to preserve invariant that
>> the value is monotonic across vCPUs.
>
> I'm afraid I don't follow: If we rely on remote CPUs updating
> pl->last_guest_time, then what we'd return is whatever was put
> there plus one. Whereas the correct value might be dozens of
> clocks further ahead.
I'm merely stating that there might be other places contributing to
jitter and getting rid of one of them wouldn't solve the issue completely
(if there is one). But again, I'd like the code to be unified with
pv_soft_rdtsc() so will have to introduce re-calculation there as well.
>>> Anther thing I notice only now are the multiple reads of
>>> pl->last_guest_time. Wouldn't you better do
>>>
>>> do {
>>> old = ACCESS_ONCE(pl->last_guest_time);
>>> new = now > old ? now : old + 1;
>>> } while ( cmpxchg(&pl->last_guest_time, old, new) != old );
>>>
>>> ?
>>
>> Fair enough, although even reading it multiple times wouldn't cause
>> any harm as any inconsistency would be resolved by cmpxchg op.
>
> Afaics "new", if calculated from a value latched _earlier_
> than "old", could cause time to actually move backwards. Reads
> can be re-ordered, after all.
I don't think it's possible due to x86 memory model and the fact
pl->last_guest_time only goes forward. But I will change it to
make it explicit and improve readability.
>> I'd
>> prefer to make it in a separate commit to unify it with pv_soft_rdtsc().
>
> I'd be fine if you changed pv_soft_rdtsc() first, and then
> made the code here match. But I don't think the code should be
> introduced in other than its (for the time being) final shape.
Ok, I'll put pv_soft_rdtsc() commit first.
Igor
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 0/1] selinux: Add xfs quota command types
From: Christoph Hellwig @ 2020-02-20 16:08 UTC (permalink / raw)
To: Stephen Smalley
Cc: Christoph Hellwig, Darrick J. Wong, Richard Haines, paul,
linux-xfs, selinux
In-Reply-To: <2862d0b2-e0a9-149d-16e5-22c3f5f82e9e@tycho.nsa.gov>
On Thu, Feb 20, 2020 at 11:06:10AM -0500, Stephen Smalley wrote:
> > The dquot_* routines are not generic quota code, but a specific
> > implementation used by most non-XFS file systems. So if there is a bug
> > it is that the security call is not in the generic dispatch code.
>
> Hmm...any reason the security hook call couldn't be taken to
> quota_quotaon()?
I haven't touched the quota code for a while, but yes, the existing
calls should move to the quota_* routines in fs/quota/quota.c. Note
that you still need to add checks, e.g. for Q_XSETQLIM.
^ permalink raw reply
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
From: Arnd Bergmann @ 2020-02-20 16:08 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Florian Weimer, Helmut Grohne, GNU C Library, Viresh Kumar,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
In-Reply-To: <20200220164245.035e09b1@jawa>
On Thu, Feb 20, 2020 at 4:42 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> I do see two approaches here:
>
> 1. In glibc:
>
> When -D_TIME_BITS=64 is set - redirections are enabled for syscall
> wrappers; for example __clock_settime64 is used instead of
> __clock_settime (e.g. sysdeps/unix/sysv/linux/clock_settime).
>
> The latter is guarded by #ifdef __TIMESIZE != 64 so we could change
> mechanically that __clock_settime returns -1 and sets errno to -ENOTSUPP
What I meant is to remove the __clock_settime function from the
library entirely to cause a link failure. I suppose replacing most
"__TIMESIZE != 64" with '0' would do that. Ideally I'd just set
__TIMESIZE to 64, but doing that would make the ABI incompatible
with mainline glibc.
> 2. In kernel - return -ENOTSUPP when clock_settime syscall instead of
> clock_settime64 is invoked.
We already have that with CONFIG_COMPAT_32BIT_TIME, but
at the moment I think that still breaks glibc's usage of __NR_futex,
and a compile-time error is always better than a runtime error,
as it's easier to catch them reliably
Arnd
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* [PULL 00/18] Block patches
From: Max Reitz @ 2020-02-20 16:06 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
The following changes since commit 672f9d0df10a68a5c5f2b32cbc8284abf9f5ee18:
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2020-02-18 14:23:43 +0000)
are available in the Git repository at:
https://github.com/XanClic/qemu.git tags/pull-block-2020-02-20
for you to fetch changes up to dff8d44c96f128480430b0c59ed8760917dbd427:
iotests: Test snapshot -l field separation (2020-02-20 16:43:42 +0100)
----------------------------------------------------------------
Block patches:
- qemu-img convert: New --target-is-zero parameter
- qcow2: Specify non-default compression type flag
- optionally flat output for query-named-block-nodes
- some fixes
- pseudo-creation of images on block devices is now done by a generic
block layer function
----------------------------------------------------------------
Daniel P. Berrangé (1):
block: always fill entire LUKS header space with zeros
David Edmondson (1):
qemu-img: Add --target-is-zero to convert
Max Reitz (11):
iotests/147: Fix drive parameters
iotests/279: Fix for non-qcow2 formats
block/nbd: Fix hang in .bdrv_close()
block: Generic file creation fallback
file-posix: Drop hdev_co_create_opts()
iscsi: Drop iscsi_co_create_opts()
iotests: Add test for image creation fallback
qemu-img: Fix convert -n -B for backing-less targets
iotests: Test convert -n -B to backing-less target
block: Fix VM size field width in snapshot dump
iotests: Test snapshot -l field separation
Peter Krempa (1):
qapi: Allow getting flat output from 'query-named-block-nodes'
Thomas Huth (1):
iotests: Remove the superfluous 2nd check for the availability of
quorum
Vladimir Sementsov-Ogievskiy (3):
docs: improve qcow2 spec about extending image header
docs: qcow2: introduce compression type feature
block/backup-top: fix flags handling
block.c | 164 +++++++++++++++++++++++++++++++++----
block/backup-top.c | 31 ++++---
block/file-posix.c | 67 ---------------
block/iscsi.c | 56 -------------
block/nbd.c | 14 +++-
block/qapi.c | 15 +++-
block/qcow2.c | 11 ++-
blockdev.c | 8 +-
docs/interop/qcow2.txt | 64 ++++++++++++++-
docs/interop/qemu-img.rst | 9 +-
include/block/block.h | 2 +-
include/block/qapi.h | 4 +-
monitor/hmp-cmds.c | 2 +-
qapi/block-core.json | 7 +-
qemu-img-cmds.hx | 4 +-
qemu-img.c | 28 ++++++-
tests/qemu-iotests/122 | 14 ++++
tests/qemu-iotests/122.out | 5 ++
tests/qemu-iotests/139 | 3 -
tests/qemu-iotests/147 | 2 +-
tests/qemu-iotests/259 | 62 ++++++++++++++
tests/qemu-iotests/259.out | 14 ++++
tests/qemu-iotests/279 | 7 +-
tests/qemu-iotests/284 | 97 ++++++++++++++++++++++
tests/qemu-iotests/284.out | 62 ++++++++++++++
tests/qemu-iotests/286 | 76 +++++++++++++++++
tests/qemu-iotests/286.out | 8 ++
tests/qemu-iotests/group | 3 +
28 files changed, 659 insertions(+), 180 deletions(-)
create mode 100755 tests/qemu-iotests/259
create mode 100644 tests/qemu-iotests/259.out
create mode 100755 tests/qemu-iotests/284
create mode 100644 tests/qemu-iotests/284.out
create mode 100755 tests/qemu-iotests/286
create mode 100644 tests/qemu-iotests/286.out
--
2.24.1
^ permalink raw reply
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.