* Re: [PATCH v3 06/17] s390x: protvirt: Add migration blocker
From: Janosch Frank @ 2020-02-20 11:24 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220114815.01634a4c.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2672 bytes --]
On 2/20/20 11:48 AM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 10:16:25 -0500
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> Migration is not yet supported.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> ---
>> hw/s390x/s390-virtio-ccw.c | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index 5fa4372083..d64724af91 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>> +++ b/hw/s390x/s390-virtio-ccw.c
>> @@ -42,6 +42,9 @@
>> #include "hw/s390x/tod.h"
>> #include "sysemu/sysemu.h"
>> #include "hw/s390x/pv.h"
>> +#include "migration/blocker.h"
>> +
>> +static Error *pv_mig_blocker;
>>
>> S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
>> {
>> @@ -373,6 +376,7 @@ static void s390_machine_reset(MachineState *machine)
>> CPUState *cs, *t;
>> S390CPU *cpu;
>> S390CcwMachineState *ms = S390_CCW_MACHINE(machine);
>> + static Error *local_err;
>>
>> /* get the reset parameters, reset them once done */
>> s390_ipl_get_reset_request(&cs, &reset_type);
>> @@ -422,6 +426,17 @@ static void s390_machine_reset(MachineState *machine)
>> }
>> run_on_cpu(cs, s390_do_cpu_reset, RUN_ON_CPU_NULL);
>>
>> + if (!pv_mig_blocker) {
>> + error_setg(&pv_mig_blocker,
>> + "protected VMs are currently not migrateable.");
>> + }
>> + migrate_add_blocker(pv_mig_blocker, &local_err);
>
> If I'm not lost in the context, that's during PV_RESET. I'm a bit
> confused why you'd add the blocker here?
Where would you want me to add it?
It's here where we switch into secure mode and I need to block before
switching and unblock if it fails.
When having the blocker in diag.c, I'd have a hard time unblocking on a
PV switch fail.
>
>> + if (local_err) {
>> + error_report_err(local_err);
>> + error_free(pv_mig_blocker);
>> + exit(1);
>
> Why the exit()? Can't you fail the call?
Well, if that fails and we go protected, I wouldn't be protected agains
migrations, right?
>
>> + }
>> +
>> if (s390_machine_pv_secure(ms)) {
>> CPU_FOREACH(t) {
>> s390_pv_vcpu_destroy(t);
>> @@ -430,6 +445,7 @@ static void s390_machine_reset(MachineState *machine)
>> ms->pv = false;
>>
>> s390_machine_inject_pv_error(cs);
>> + migrate_del_blocker(pv_mig_blocker);
>> s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
>> return;
>> }
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] describe: output tag's ref instead of embedded name
From: Jeff King @ 2020-02-20 11:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matheus Tavares, git, rhi
In-Reply-To: <xmqqftf6hlrt.fsf@gitster-ct.c.googlers.com>
On Wed, Feb 19, 2020 at 03:14:14AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I think a left a few things unsaid in my "v1.0-bob" example. I was
> > imagining that there are _two_ v1.0 tags floating around. One that you
> > consider "wrong", tagged by Bob, and one you like. You keep the latter
> > in refs/tags/v1.0.
>
> Ahh, OK.
>
> To continue playing devil's advocate and to step back a bit,
>
> - The "git describe" command finds that the given commit is
> "closest" to that tag Bob called "v1.0".
>
> - But if it outputs "v1.0" like the current code does, it cannot be
> fed back to get_oid() to name the right object, if the given commit
> is "at" the tag (i.e. there is no "-$number-g$objectname" suffix),
> which is a problem. We want "git describe" to give an output
> usable with get_oid() and the name must refer to the correct
> object (i.e. the one given to "git describe" as an input).
>
> There are multiple approaches to make it possible to feed the output
> back to get_oid() to obtain correct result:
> [...]
Thanks for clearly laying out your thinking. All of what you wrote makes
sense to me and I'd be OK with any of the options you described.
The "-g$objectname" one is kind of clever, and definitely not something
I had thought of. We already have "--long", and of course we'd show the
long version for any name that isn't an exact match anyway. So as an
added bonus, it seems unlikely to surprise anybody who is expecting the
current "show the tag, not the refname" output (though again, this is
rare enough that I think people simply expect them to be the same ;) ).
-Peff
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] net/mlx5: fix incorrect set VLAN ID action offset
From: Raslan Darawsheh @ 2020-02-20 11:25 UTC (permalink / raw)
To: Suanming Mou, Slava Ovsiienko, Matan Azrad, Dekel Peled
Cc: dev@dpdk.org, stable@dpdk.org
In-Reply-To: <1582121717-53976-1-git-send-email-suanmingm@mellanox.com>
Hi,
> -----Original Message-----
> From: Suanming Mou <suanmingm@mellanox.com>
> Sent: Wednesday, February 19, 2020 4:15 PM
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Matan Azrad
> <matan@mellanox.com>; Dekel Peled <dekelp@mellanox.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@mellanox.com>;
> stable@dpdk.org
> Subject: [PATCH] net/mlx5: fix incorrect set VLAN ID action offset
>
> Currently, the set VLAN ID header modify action has already got the
> action pointer with offset from the header modify action array, but
> the configuration saves the detail to the memory of action with the
> offset again. It causes double offset to set the VLAN ID action to
> the wrong place in the header modify array.
>
> Remove the offset when get the action pointer to fix that issue.
>
> Fixes: 5f163d520cff ("net/mlx5: support modify VLAN ID on existing VLAN
> header")
> Cc: stable@dpdk.org
>
> Signed-off-by: Suanming Mou <suanmingm@mellanox.com>
> Acked-by: Dekel Peled <dekelp@mellanox.com>
> ---
> drivers/net/mlx5/mlx5_flow_dv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c
> index 359a037..5950274 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -637,7 +637,7 @@ struct field_modify_info modify_tcp[] = {
> const struct rte_flow_action_of_set_vlan_vid *conf =
> (const struct rte_flow_action_of_set_vlan_vid *)(action-
> >conf);
> int i = resource->actions_num;
> - struct mlx5_modification_cmd *actions = &resource->actions[i];
> + struct mlx5_modification_cmd *actions = resource->actions;
> struct field_modify_info *field = modify_vlan_out_first_vid;
>
> if (i >= MLX5_MAX_MODIFY_NUM)
> --
> 1.8.3.1
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
^ permalink raw reply
* Re: [PATCH v1 13/13] migrate/ram: Tolerate partially changed mappings in postcopy code
From: David Hildenbrand @ 2020-02-20 11:24 UTC (permalink / raw)
To: qemu-devel
Cc: Andrea Arcangeli, Eduardo Habkost, Juan Quintela,
Dr . David Alan Gilbert, Peter Xu, Paolo Bonzini,
Richard Henderson
In-Reply-To: <20200219161725.115218-14-david@redhat.com>
On 19.02.20 17:17, David Hildenbrand wrote:
> When we partially change mappings (e.g., mmap over parts of an existing
> mmap) where we have a userfaultfd handler registered, the handler will
> implicitly be unregistered from the parts that changed. This is e.g., the
> case when doing a qemu_ram_remap(), but is also a preparation for RAM
> blocks with resizable allocations and we're shrinking RAM blocks.
>
> When the mapping is changed and the handler is removed, any waiters are
> woken up. Trying to place pages will fail. We can simply ignore erors
> due to that when placing pages - as the mapping changed on the migration
> destination, also the content is stale. E.g., after shrinking a RAM
> block, nobody should be using that memory. After doing a
> qemu_ram_remap(), the old memory is expected to have vanished.
>
> Let's tolerate such errors (but still warn for now) when placing pages.
> Also, add a comment why unregistering will continue to work even though
> the mapping might have changed.
>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Juan Quintela <quintela@redhat.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> migration/postcopy-ram.c | 43 ++++++++++++++++++++++++++++++++++------
> 1 file changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
> index c68caf4e42..df9d27c004 100644
> --- a/migration/postcopy-ram.c
> +++ b/migration/postcopy-ram.c
> @@ -506,6 +506,13 @@ static int cleanup_range(RAMBlock *rb, void *opaque)
> range_struct.start = (uintptr_t)host_addr;
> range_struct.len = length;
>
> + /*
> + * In case the mapping was partially changed since we enabled userfault
> + * (esp. when whrinking RAM blocks and we have resizable allocations, or
> + * via qemu_ram_remap()), the userfaultfd handler was already removed for
> + * the mappings that changed. Unregistering will, however, still work and
> + * ignore mappings without a registered handler.
> + */
> if (ioctl(mis->userfault_fd, UFFDIO_UNREGISTER, &range_struct)) {
> error_report("%s: userfault unregister %s", __func__, strerror(errno));
>
> @@ -1239,10 +1246,28 @@ int postcopy_place_page(MigrationIncomingState *mis, void *host, void *from,
> */
> if (qemu_ufd_copy_ioctl(mis->userfault_fd, host, from, pagesize, rb)) {
> int e = errno;
> - error_report("%s: %s copy host: %p from: %p (size: %zd)",
> - __func__, strerror(e), host, from, pagesize);
>
> - return -e;
> + /*
> + * When the mapping gets partially changed before we try to place a page
> + * (esp. when whrinking RAM blocks and we have resizable allocations, or
> + * via qemu_ram_remap()), the userfaultfd handler will be removed and
> + * placing pages will fail. In that case, any waiter was already woken
> + * up when the mapping was changed. We can safely ignore this, as
> + * mappings that change once we're running on the destination imply
> + * that memory of these mappings vanishes. Let's still print a warning
> + * for now.
> + *
After talking to Andrea, on mapping changes, no waiter will be woken up
automatically. We have to do an UFFDIO_WAKE, which even works when there
is no longer a handler registered for that reason. Interesting stuff :)
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCHv5 29/34] drm/arm/malidp: Make verify funcitons invocations independent
From: Boris Brezillon @ 2020-02-20 11:26 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: kernel, Mihail Atanassov, David Airlie, Liviu Dudau, Sandy Huang,
dri-devel, James Wang, Ayan Halder, Sean Paul
In-Reply-To: <20191217145020.14645-30-andrzej.p@collabora.com>
In the subject: s/funcitons/functions/
On Tue, 17 Dec 2019 15:50:15 +0100
Andrzej Pietrasiewicz <andrzej.p@collabora.com> wrote:
> This will make it easier to transition to generic afbc-aware helpers.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index 37d92a06318e..961e5a3f5b08 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -362,10 +362,10 @@ static bool
> malidp_verify_afbc_framebuffer(struct drm_device *dev, struct drm_file *file,
> const struct drm_mode_fb_cmd2 *mode_cmd)
> {
> - if (malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> - return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> + if (!malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> + return false;
>
> - return false;
> + return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> }
>
> static struct drm_framebuffer *
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH net-next v3 0/9] net: fix sysfs permssions when device changes network
From: Greg KH @ 2020-02-20 11:26 UTC (permalink / raw)
To: David Miller
Cc: christian.brauner, linux-kernel, netdev, rafael, pavel, kuba,
edumazet, stephen, linux-pm
In-Reply-To: <20200219.162416.1910523123736311797.davem@davemloft.net>
On Wed, Feb 19, 2020 at 04:24:16PM -0800, David Miller wrote:
> From: Christian Brauner <christian.brauner@ubuntu.com>
> Date: Tue, 18 Feb 2020 17:29:34 +0100
>
> > This is v3 with explicit uid and gid parameters added to functions that
> > change sysfs object ownership as Greg requested.
>
> Greg, please review.
Give me a chance :)
It's looking better, still needs a little bit of work before I'm happy
with the driver core and sysfs bits, see my review comments so far.
thanks,
greg k-h
^ permalink raw reply
* [leo:next 3/3] drivers/soc/fsl/dpio/qbman-portal.c:869:14: warning: cast from pointer to integer of different size
From: kbuild test robot @ 2020-02-20 11:26 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3782 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git next
head: 3b2abda7d28c69f564c1157b9b9c21ef40092ee9
commit: 3b2abda7d28c69f564c1157b9b9c21ef40092ee9 [3/3] soc: fsl: dpio: Replace QMAN array mode with ring mode enqueue
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
git checkout 3b2abda7d28c69f564c1157b9b9c21ef40092ee9
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/soc/fsl/dpio/qbman-portal.c: In function 'qbman_swp_enqueue_multiple_desc_direct':
>> drivers/soc/fsl/dpio/qbman-portal.c:869:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
addr_cena = (uint64_t)s->addr_cena;
^
vim +869 drivers/soc/fsl/dpio/qbman-portal.c
804
805 /**
806 * qbman_swp_enqueue_multiple_desc_direct() - Issue a multi enqueue command
807 * using multiple enqueue descriptor
808 * @s: the software portal used for enqueue
809 * @d: table of minimal enqueue descriptor
810 * @fd: table pointer of frame descriptor table to be enqueued
811 * @num_frames: number of fd to be enqueued
812 *
813 * Return the number of fd enqueued, or a negative error number.
814 */
815 static
816 int qbman_swp_enqueue_multiple_desc_direct(struct qbman_swp *s,
817 const struct qbman_eq_desc *d,
818 const struct dpaa2_fd *fd,
819 int num_frames)
820 {
821 uint32_t *p;
822 const uint32_t *cl;
823 uint32_t eqcr_ci, eqcr_pi, half_mask, full_mask;
824 int i, num_enqueued = 0;
825 uint64_t addr_cena;
826
827 half_mask = (s->eqcr.pi_ci_mask>>1);
828 full_mask = s->eqcr.pi_ci_mask;
829 if (!s->eqcr.available) {
830 eqcr_ci = s->eqcr.ci;
831 p = s->addr_cena + QBMAN_CENA_SWP_EQCR_CI;
832 s->eqcr.ci = qbman_read_register(s, QBMAN_CINH_SWP_EQCR_CI);
833 s->eqcr.available = qm_cyc_diff(s->eqcr.pi_ring_size,
834 eqcr_ci, s->eqcr.ci);
835 if (!s->eqcr.available)
836 return 0;
837 }
838
839 eqcr_pi = s->eqcr.pi;
840 num_enqueued = (s->eqcr.available < num_frames) ?
841 s->eqcr.available : num_frames;
842 s->eqcr.available -= num_enqueued;
843 /* Fill in the EQCR ring */
844 for (i = 0; i < num_enqueued; i++) {
845 p = (s->addr_cena + QBMAN_CENA_SWP_EQCR(eqcr_pi & half_mask));
846 cl = (uint32_t *)(&d[i]);
847 /* Skip copying the verb */
848 memcpy(&p[1], &cl[1], EQ_DESC_SIZE_WITHOUT_FD - 1);
849 memcpy(&p[EQ_DESC_SIZE_FD_START/sizeof(uint32_t)],
850 &fd[i], sizeof(*fd));
851 eqcr_pi++;
852 }
853
854 dma_wmb();
855
856 /* Set the verb byte, have to substitute in the valid-bit */
857 eqcr_pi = s->eqcr.pi;
858 for (i = 0; i < num_enqueued; i++) {
859 p = (s->addr_cena + QBMAN_CENA_SWP_EQCR(eqcr_pi & half_mask));
860 cl = (uint32_t *)(&d[i]);
861 p[0] = cl[0] | s->eqcr.pi_vb;
862 eqcr_pi++;
863 if (!(eqcr_pi & half_mask))
864 s->eqcr.pi_vb ^= QB_VALID_BIT;
865 }
866
867 /* Flush all the cacheline without load/store in between */
868 eqcr_pi = s->eqcr.pi;
> 869 addr_cena = (uint64_t)s->addr_cena;
870 for (i = 0; i < num_enqueued; i++)
871 eqcr_pi++;
872 s->eqcr.pi = eqcr_pi & full_mask;
873
874 return num_enqueued;
875 }
876
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 72054 bytes --]
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 0/2] net/mlx5: fix incorrect layer choose with decap
From: Raslan Darawsheh @ 2020-02-20 11:26 UTC (permalink / raw)
To: Suanming Mou, Slava Ovsiienko, Matan Azrad; +Cc: dev@dpdk.org
In-Reply-To: <1582122380-54467-1-git-send-email-suanmingm@mellanox.com>
Hi,
> -----Original Message-----
> From: Suanming Mou <suanmingm@mellanox.com>
> Sent: Wednesday, February 19, 2020 4:26 PM
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Matan Azrad
> <matan@mellanox.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@mellanox.com>
> Subject: [PATCH 0/2] net/mlx5: fix incorrect layer choose with decap
>
> For header modify actions after decapsulation action, the header modify
> actions should be applied to the inner layers.
>
> Currently, it always treats the outermost layers as the corresponding
> layer even though with decapsulation action.
>
> Add the layer validation with decapsulation for the header modify action
> and fix the incorrect layers chosen in header modify action with
> decapsulation action.
>
> Suanming Mou (2):
> net/mlx5: fix wrong layer validation with decapsulation
> net/mlx5: fix header modifiy choose wrong layer type
>
> drivers/net/mlx5/mlx5_flow_dv.c | 104
> +++++++++++++++++++++++++++++++++-------
> 1 file changed, 87 insertions(+), 17 deletions(-)
>
> --
> 1.8.3.1
Series applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
^ permalink raw reply
* Re: [RESEND RFC PATCH v3] clk: Use new helper in managed functions
From: Greg Kroah-Hartman @ 2020-02-20 11:27 UTC (permalink / raw)
To: Marc Gonzalez
Cc: Stephen Boyd, Michael Turquette, Kuninori Morimoto, Russell King,
Sudip Mukherjee, Dmitry Torokhov, Guenter Roeck, Bjorn Andersson,
Robin Murphy, Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel,
Rafael Wysocki, Suzuki Poulose, Mark Rutland, linux-clk,
Linux ARM, LKML
In-Reply-To: <f48d1df3-fc1f-ac5c-b11e-330f18aad539@free.fr>
On Thu, Feb 20, 2020 at 11:04:58AM +0100, Marc Gonzalez wrote:
> Introduce devm_add() to wrap devres_alloc() / devres_add() calls.
>
> Using that helper produces simpler code, and smaller object size.
> E.g. with gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu:
>
> text data bss dec hex filename
> - 1708 80 0 1788 6fc drivers/clk/clk-devres.o
> + 1524 80 0 1604 644 drivers/clk/clk-devres.o
>
> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
> ---
> Differences from v2 to v3
> x Make devm_add() return an error-code rather than the raw data pointer
> (in case devres_alloc ever returns an ERR_PTR) as suggested by Geert
> x Provide a variadic version devm_vadd() to work with structs as suggested
> by Geert
> x Don't use nested ifs in clk_devm* implementations (hopefully simpler
> code logic to follow) as suggested by Geert
>
> Questions:
> x This patch might need to be split in two? (Introduce the new API, then use it)
> x Convert other subsystems to show the value of this proposal?
> x Maybe comment the API usage somewhere
> ---
> drivers/base/devres.c | 15 ++++++
> drivers/clk/clk-devres.c | 99 ++++++++++++++--------------------------
> include/linux/device.h | 3 ++
> 3 files changed, 53 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> index 0bbb328bd17f..b2603789755b 100644
> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -685,6 +685,21 @@ int devres_release_group(struct device *dev, void *id)
> }
> EXPORT_SYMBOL_GPL(devres_release_group);
>
> +int devm_add(struct device *dev, dr_release_t func, void *arg, size_t size)
Please add a bunch of kerneldoc here, as I have no idea what this
function does just by looking at the name of it :(
thanks,
greg k-h
^ permalink raw reply
* Re: [RESEND RFC PATCH v3] clk: Use new helper in managed functions
From: Greg Kroah-Hartman @ 2020-02-20 11:27 UTC (permalink / raw)
To: Marc Gonzalez
Cc: Mark Rutland, linux-clk, LKML, Arnd Bergmann, Kuninori Morimoto,
Ard Biesheuvel, Stephen Boyd, Suzuki Poulose, Michael Turquette,
Dmitry Torokhov, Rafael Wysocki, Russell King, Bjorn Andersson,
Geert Uytterhoeven, Linux ARM, Robin Murphy, Sudip Mukherjee,
Guenter Roeck
In-Reply-To: <f48d1df3-fc1f-ac5c-b11e-330f18aad539@free.fr>
On Thu, Feb 20, 2020 at 11:04:58AM +0100, Marc Gonzalez wrote:
> Introduce devm_add() to wrap devres_alloc() / devres_add() calls.
>
> Using that helper produces simpler code, and smaller object size.
> E.g. with gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu:
>
> text data bss dec hex filename
> - 1708 80 0 1788 6fc drivers/clk/clk-devres.o
> + 1524 80 0 1604 644 drivers/clk/clk-devres.o
>
> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
> ---
> Differences from v2 to v3
> x Make devm_add() return an error-code rather than the raw data pointer
> (in case devres_alloc ever returns an ERR_PTR) as suggested by Geert
> x Provide a variadic version devm_vadd() to work with structs as suggested
> by Geert
> x Don't use nested ifs in clk_devm* implementations (hopefully simpler
> code logic to follow) as suggested by Geert
>
> Questions:
> x This patch might need to be split in two? (Introduce the new API, then use it)
> x Convert other subsystems to show the value of this proposal?
> x Maybe comment the API usage somewhere
> ---
> drivers/base/devres.c | 15 ++++++
> drivers/clk/clk-devres.c | 99 ++++++++++++++--------------------------
> include/linux/device.h | 3 ++
> 3 files changed, 53 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> index 0bbb328bd17f..b2603789755b 100644
> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -685,6 +685,21 @@ int devres_release_group(struct device *dev, void *id)
> }
> EXPORT_SYMBOL_GPL(devres_release_group);
>
> +int devm_add(struct device *dev, dr_release_t func, void *arg, size_t size)
Please add a bunch of kerneldoc here, as I have no idea what this
function does just by looking at the name of it :(
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Bitbake returning non-zero due to sstate errors
From: Paul Barker @ 2020-02-20 11:26 UTC (permalink / raw)
To: Yocto discussion list
In my new CI setup I'm using an sstate mirror which seems to have some
occasional download issues. This results in the setscene task failing.
For example:
ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
do_package_write_ipk_setscene: Fetcher failure: Unable to find file
file://fd/sstate:qt3d:armv7at2hf-neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf-neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a74_package_write_ipk.tgz
anywhere. The paths that were searched were:
/builds/SanCloudLtd/sancloud-arago/build/sstate-cache
/builds/SanCloudLtd/sancloud-arago/build/sstate-cache
ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
do_package_write_ipk_setscene: No suitable staging package found
ERROR: Logfile of failure stored in:
/builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon-linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59-r0/temp/log.do_package_write_ipk_setscene.10524
NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
do_package_write_ipk_setscene: Failed
WARNING: Setscene task
(/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes-qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene)
failed with exit code '1' - real task will be run instead
As indicated in the final warning message there the real tasks run
since no sstate artifact is available. These tasks succeed:
NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
do_package_write_ipk: Succeeded
The result is a successful build of the desired images. However, the
build is marked as a failure due to those sstate errors:
Summary: There were 11 ERROR messages shown, returning a non-zero exit code.
Is this the expected behaviour? The final images are built correctly.
I can't see any simple way to mask those setscene errors but I might
be missing something.
The full log can be seen at
https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw.
I'm on the zeus branch here, I'll try to re-test on master later if I
can.
Thanks,
Paul
^ permalink raw reply
* Re: [PATCH v3 09/17] s390: protvirt: Move STSI data over SIDAD
From: Janosch Frank @ 2020-02-20 11:25 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220115401.50658d2c.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1944 bytes --]
On 2/20/20 11:54 AM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 10:16:28 -0500
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> For protected guests, we need to put the STSI emulation results into
>> the SIDA, so SIE will write them into the guest at the next entry.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> ---
>> target/s390x/kvm.c | 15 ++++++++++++---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
>> index eec0b92479..fe669ed24c 100644
>> --- a/target/s390x/kvm.c
>> +++ b/target/s390x/kvm.c
>> @@ -1772,11 +1772,16 @@ static int handle_tsch(S390CPU *cpu)
>>
>> static void insert_stsi_3_2_2(S390CPU *cpu, __u64 addr, uint8_t ar)
>> {
>> + CPUS390XState *env = &cpu->env;
>> SysIB_322 sysib;
>> int del;
>>
>> - if (s390_cpu_virt_mem_read(cpu, addr, ar, &sysib, sizeof(sysib))) {
>> - return;
>> + if (env->pv) {
>> + s390_cpu_pv_mem_read(cpu, 0, &sysib, sizeof(sysib));
>
> This is only introduced by the next patch, right?
Ups, time to reorder.
>
>> + } else {
>> + if (s390_cpu_virt_mem_read(cpu, addr, ar, &sysib, sizeof(sysib))) {
>> + return;
>> + }
>> }
>> /* Shift the stack of Extended Names to prepare for our own data */
>> memmove(&sysib.ext_names[1], &sysib.ext_names[0],
>> @@ -1815,7 +1820,11 @@ static void insert_stsi_3_2_2(S390CPU *cpu, __u64 addr, uint8_t ar)
>> /* Insert UUID */
>> memcpy(sysib.vm[0].uuid, &qemu_uuid, sizeof(sysib.vm[0].uuid));
>>
>> - s390_cpu_virt_mem_write(cpu, addr, ar, &sysib, sizeof(sysib));
>> + if (env->pv) {
>> + s390_cpu_pv_mem_write(cpu, 0, &sysib, sizeof(sysib));
>> + } else {
>> + s390_cpu_virt_mem_write(cpu, addr, ar, &sysib, sizeof(sysib));
>> + }
>> }
>>
>> static int handle_stsi(S390CPU *cpu)
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Race condition in overlayed qcow2?
From: Vladimir Sementsov-Ogievskiy @ 2020-02-20 11:26 UTC (permalink / raw)
To: Pavel Dovgalyuk; +Cc: kwolf, qemu-devel, mreitz
In-Reply-To: <003701d5e7d4$90bcc130$b2364390$@ru>
20.02.2020 13:00, Pavel Dovgalyuk wrote:
>> From: Vladimir Sementsov-Ogievskiy [mailto:vsementsov@virtuozzo.com]
>> 20.02.2020 11:31, dovgaluk wrote:
>>> Vladimir Sementsov-Ogievskiy писал 2020-02-19 19:07:
>>>> 19.02.2020 17:32, dovgaluk wrote:
>>>>> I encountered a problem with record/replay of QEMU execution and figured out the
>> following, when
>>>>> QEMU is started with one virtual disk connected to the qcow2 image with applied 'snapshot'
>> option.
>>>>>
>>>>> The patch d710cf575ad5fb3ab329204620de45bfe50caa53 "block/qcow2: introduce parallel
>> subrequest handling in read and write"
>>>>> introduces some kind of race condition, which causes difference in the data read from the
>> disk.
>>>>>
>>>>> I detected this by adding the following code, which logs IO operation checksum. And this
>> checksum may be different in different runs of the same recorded execution.
>>>>>
>>>>> logging in blk_aio_complete function:
>>>>> qemu_log("%"PRId64": blk_aio_complete\n", replay_get_current_icount());
>>>>> QEMUIOVector *qiov = acb->rwco.iobuf;
>>>>> if (qiov && qiov->iov) {
>>>>> size_t i, j;
>>>>> uint64_t sum = 0;
>>>>> int count = 0;
>>>>> for (i = 0 ; i < qiov->niov ; ++i) {
>>>>> for (j = 0 ; j < qiov->iov[i].iov_len ; ++j) {
>>>>> sum += ((uint8_t*)qiov->iov[i].iov_base)[j];
>>>>> ++count;
>>>>> }
>>>>> }
>>>>> qemu_log("--- iobuf offset %"PRIx64" len %x sum: %"PRIx64"\n", acb-
>>> rwco.offset, count, sum);
>>>>> }
>>>>>
>>>>> I tried to get rid of aio task by patching qcow2_co_preadv_part:
>>>>> ret = qcow2_co_preadv_task(bs, ret, cluster_offset, offset, cur_bytes, qiov, qiov_offset);
>>>>>
>>>>> That change fixed a bug, but I have no idea what to debug next to figure out the exact
>> reason of the failure.
>>>>>
>>>>> Do you have any ideas or hints?
>>>>>
>>>>
>>>> Hi!
>>>>
>>>> Hmm, do mean that read from the disk may return wrong data? It would
>>>> be very bad of course :(
>>>> Could you provide a reproducer, so that I can look at it and debug?
>>>
>>> It is just a winxp-32 image. I record the execution and replay it with the following command
>> lines:
>>>
>>> qemu-system-i386 -icount shift=7,rr=record,rrfile=replay.bin -m 512M -drive
>> file=xp.qcow2,if=none,id=device-34-file,snapshot -drive driver=blkreplay,if=none,image=device-
>> 34-file,id=device-34-driver -device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -net
>> none
>>>
>>> qemu-system-i386 -icount shift=7,rr=replay,rrfile=replay.bin -m 512M -drive
>> file=xp.qcow2,if=none,id=device-34-file,snapshot -drive driver=blkreplay,if=none,image=device-
>> 34-file,id=device-34-driver -device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -net
>> none
>>>
>>> Replay stalls at some moment due to the non-determinism of the execution (probably caused by
>> the wrong data read).
>>
>> Hmm.. I tried it (with x86_64 qemu and centos image). I waited for some time for a first
>> command, than Ctrl+C it. After it replay.bin was 4M. Than started the second command. It
>> works, not failing, not finishing. Is it bad? What is expected behavior and what is wrong?
>
> The second command should finish. There is no replay introspection yet (in master), but you can
> stop qemu with gdb and inspect replay_state.current_icount field. It should increase with every
> virtual CPU instruction execution. If that counter has stopped, it means that replay hangs.
It hangs for me even with QCOW2_MAX_WORKERS = 1..
>
>>>> What is exactly the case? May be you have other parallel aio
>>>> operations to the same region?
>>>
>>> As far as I understand, all aio operations, initiated by IDE controller, are performed one-
>> by-one.
>>> I don't see anything else in the logs.
>>>
>>>> Ideas to experiment:
>>>>
>>>> 1. change QCOW2_MAX_WORKERS to 1 or to 2, will it help?
>>>
>>> 1 or 2 are ok, and 4 or 8 lead to the failures.
>>>
>>>> 2. understand what is the case in code: is it read from one or several
>>>> clusters, is it aligned,
>>>> what is the type of clusters, is encryption in use, compression?
>>>
>>> There is no encryption and I thinks compression is not enabled too.
>>> Clusters are read from the temporary overlay:
>>>
>>> blk_aio_prwv
>>> blk_aio_read_entry
>>> bdrv_co_preadv_part complete offset: 26300000 qiov_offset: 1c200 len: 1e00
>>> bdrv_co_preadv_part complete offset: 24723e00 qiov_offset: 0 len: 1c200
>>> bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 1e000
>>> bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 1e000
>>> bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 1e000
>>>
>>>
>>>> 3. understand what kind of data corruption. What we read instead of
>>>> correct data? Just garbage, or may be zeroes, or what..
>>>
>>> Most bytes are the same, but some are different:
>>>
>>> < 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00
>>> < 46 49 4c 45 30 00 03 00 18 d1 33 02 00 00 00 00
>>> < 01 00 01 00 38 00 01 00 68 01 00 00 00 04 00 00
>>> < 00 00 00 00 00 00 00 00 04 00 00 00 9d 0e 00 00
>>> < 02 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00
>>> ---
>>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00
>>>> 46 49 4c 45 30 00 03 00 86 78 35 03 00 00 00 00
>>>> 01 00 01 00 38 00 01 00 60 01 00 00 00 04 00 00
>>>> 00 00 00 00 00 00 00 00 04 00 00 00 a1 0e 00 00
>>>> 04 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00
>>>
>>> That is strange. I could think, that it was caused by the bugs in
>>> deterministic CPU execution, but the first difference in logs
>>> occur in READ operation (I dump read/write buffers in blk_aio_complete).
>>>
>>
>> Aha, yes, looks strange.
>>
>> Then next steps:
>>
>> 1. Does problem hit into the same offset every time?
>
> Yes, almost the same offset, almost the same phase of the execution.
>
>> 2. Do we write to this region before this strange read?
>
> No.
>
>> 2.1. If yes, we need to check that we read what we write.. You say you dump buffers
>> in blk_aio_complete... I think it would be more reliable to dump at start of
>> bdrv_co_pwritev and at end of bdrv_co_preadv. Also, guest may modify its buffers
>> during operation which would be strange but possible.
>
> I dumped every write in file-posix.c handle_aiocb_rw_linear and qemu_pwritev
> and found no difference in executions.
>
>> 2.2 If not, hmm...
>
> Exactly.
>
> Pavel Dovgalyuk
>
--
Best regards,
Vladimir
^ permalink raw reply
* w83627ehf crash in 5.6.0-rc2-00055-gca7e1fd1026c
From: Meelis Roos @ 2020-02-20 11:18 UTC (permalink / raw)
To: linux-hwmon; +Cc: LKML, Dr. David Alan Gilbert, Chen Zhou
While reading w83627ehf sensors output on D425KT mainboard, I consistently get NULL dereference as below.
5.5.0 worked OK but gave a warning on driver load:
[ 104.514954] w83627ehf: Found W83627DHG-P chip at 0x290
[ 104.515634] w83627ehf w83627ehf.656: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
This is dmesg from current git (loading the driver and reading sensors with lm-sensors - no driver loading warning any more):
[ 764.718192] w83627ehf: Found W83627DHG-P chip at 0x290
[ 774.574874] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 774.574889] #PF: supervisor read access in kernel mode
[ 774.574895] #PF: error_code(0x0000) - not-present page
[ 774.574901] PGD 0 P4D 0
[ 774.574909] Oops: 0000 [#1] SMP NOPTI
[ 774.574917] CPU: 0 PID: 604 Comm: sensors Not tainted 5.6.0-rc2-00055-gca7e1fd1026c #29
[ 774.574923] Hardware name: /D425KT, BIOS MWPNT10N.86A.0132.2013.0726.1534 07/26/2013
[ 774.574939] RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
[ 774.574947] Code: 00 00 00 55 53 48 8d 64 24 f0 83 fa 15 48 8b 5f 78 75 29 83 fe 01 75 24 48 63 c9 48 8b 6b 58 48 83 f9 03 77 24 0f b6 44 0b 50 <48> 8b 44 c5 00 49 89 00 48 8d 64 24 10 5b 31 c0 5d c3 48 8d 64 24
[ 774.574958] RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
[ 774.574965] RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
[ 774.574972] RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
[ 774.574978] RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
[ 774.574985] R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
[ 774.574991] R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
[ 774.574999] FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
[ 774.575008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 774.575015] CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
[ 774.575021] Call Trace:
[ 774.575036] ? cp_new_stat+0x12d/0x160
[ 774.575048] hwmon_attr_show_string+0x37/0x70 [hwmon]
[ 774.575060] dev_attr_show+0x14/0x50
[ 774.575071] sysfs_kf_seq_show+0xb5/0x1b0
[ 774.575081] seq_read+0xcf/0x460
[ 774.575091] vfs_read+0x9b/0x150
[ 774.575100] ksys_read+0x5f/0xe0
[ 774.575111] do_syscall_64+0x48/0x190
[ 774.575121] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 774.575130] RIP: 0033:0x7fbc7c715871
[ 774.575138] Code: fe ff ff 50 48 8d 3d 76 e5 09 00 e8 e9 ef 01 00 66 0f 1f 84 00 00 00 00 00 48 8d 05 69 3b 0d 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 c3 66 0f 1f 44 00 00 48 83 ec 28 48 89 54
[ 774.575151] RSP: 002b:00007ffe5092d848 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 774.575161] RAX: ffffffffffffffda RBX: 00005630bdfb1330 RCX: 00007fbc7c715871
[ 774.575168] RDX: 0000000000001000 RSI: 00007ffe5092d8e0 RDI: 0000000000000003
[ 774.575175] RBP: 00007fbc7c7e5560 R08: 0000000000000003 R09: 00007fbc7c7e43b0
[ 774.575182] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000001000
[ 774.575190] R13: 00007ffe5092d8e0 R14: 0000000000000d68 R15: 00007fbc7c7e4960
[ 774.575199] Modules linked in: w83627ehf hwmon_vid snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_pcsp snd_hda_core ir_rc6_decoder rc_rc6_mce uas r8169 mceusb snd_pcm
iTCO_wdt rc_core snd_timer iTCO_vendor_support realtek snd libphy soundcore i2c_i801 lpc_ich parport_pc mfd_core parport coretemp hwmon autofs4
[ 774.575247] CR2: 0000000000000000
[ 774.575254] ---[ end trace 607462057ab8a988 ]---
[ 774.575264] RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
[ 774.575273] Code: 00 00 00 55 53 48 8d 64 24 f0 83 fa 15 48 8b 5f 78 75 29 83 fe 01 75 24 48 63 c9 48 8b 6b 58 48 83 f9 03 77 24 0f b6 44 0b 50 <48> 8b 44 c5 00 49 89 00 48 8d 64 24 10 5b 31 c0 5d c3 48 8d 64 24
[ 774.575287] RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
[ 774.575294] RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
[ 774.575301] RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
[ 774.575308] RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
[ 774.575316] R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
[ 774.575323] R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
[ 774.575331] FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
[ 774.575340] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 774.575347] CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
--
Meelis Roos <mroos@linux.ee>
^ permalink raw reply
* Re: [PATCHv5 29/34] drm/arm/malidp: Make verify funcitons invocations independent
From: Boris Brezillon @ 2020-02-20 11:29 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: Mihail Atanassov, David Airlie, Liviu Dudau, Sandy Huang,
dri-devel, Ayan Halder, James Wang, kernel, Sean Paul
In-Reply-To: <20200220122601.1e2212a4@collabora.com>
On Thu, 20 Feb 2020 12:26:01 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> In the subject: s/funcitons/functions/
>
> On Tue, 17 Dec 2019 15:50:15 +0100
> Andrzej Pietrasiewicz <andrzej.p@collabora.com> wrote:
>
> > This will make it easier to transition to generic afbc-aware helpers.
> >
> > Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>
> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Wait, patch 30 is this patch completely irrelevant, so I take R-b back
:-). You can just squash that one in patch 30.
>
> > ---
> > drivers/gpu/drm/arm/malidp_drv.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> > index 37d92a06318e..961e5a3f5b08 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -362,10 +362,10 @@ static bool
> > malidp_verify_afbc_framebuffer(struct drm_device *dev, struct drm_file *file,
> > const struct drm_mode_fb_cmd2 *mode_cmd)
> > {
> > - if (malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> > - return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> > + if (!malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> > + return false;
> >
> > - return false;
> > + return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> > }
> >
> > static struct drm_framebuffer *
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2] Avoid address_space_rw() with a constant is_write argument
From: Paolo Bonzini @ 2020-02-20 11:28 UTC (permalink / raw)
To: Laurent Vivier, Peter Maydell, qemu-devel
Cc: Thomas Huth, Alistair Francis, Eduardo Habkost, Cornelia Huck,
Halil Pasic, Christian Borntraeger, Cédric Le Goater,
Edgar E. Iglesias, David Gibson
In-Reply-To: <fc70075c-0098-632e-7d60-4534202bf2f5@redhat.com>
On 18/02/20 14:13, Laurent Vivier wrote:
> There is one in target/i386/hvf/vmx.h: macvm_set_cr0() you didn't change.
>
> You must update the script name in the script comment (as suggested by
> Philippe) and in the commit message.
>
> Anyway:
>
> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Thanks, I squashed the change to vmx.h.
Paolo
^ permalink raw reply
* Re: [PATCH v4 1/4] nvmem: fix memory leak in error path
From: Srinivas Kandagatla @ 2020-02-20 11:30 UTC (permalink / raw)
To: Bartosz Golaszewski, Linus Walleij, Khouloud Touil,
Geert Uytterhoeven
Cc: linux-gpio, linux-kernel, Bartosz Golaszewski
In-Reply-To: <20200220100141.5905-2-brgl@bgdev.pl>
On 20/02/2020 10:01, Bartosz Golaszewski wrote:
> - if (IS_ERR(nvmem->wp_gpio))
> + if (IS_ERR(nvmem->wp_gpio)) {
> + ida_simple_remove(&nvmem_ida, nvmem->id);
> + kfree(nvmem);
> return ERR_CAST(nvmem->wp_gpio);
You freed nvmem just before this statement, how can nvmem->wp_gpio be
still be valid?
Are you able to test this changes at your end?
Or
these are just compile tested?
--srini
> + }
>
^ permalink raw reply
* Re: [PATCH v3 13/17] s390x: protvirt: Move diag 308 data over SIDAD
From: Janosch Frank @ 2020-02-20 11:29 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220120052.7691f6f8.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 3988 bytes --]
On 2/20/20 12:00 PM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 10:16:32 -0500
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> For protected guests the IPIB is written/read to/from the satellite
>> block, so we need to make those accesses virtual to make them go
>> through KVM mem ops.
..we need those accesses to go through s390_cpu_pv_mem_read/write() so
we use the memop IOCTL to access the sattelite block.
>
> Confused. What does 'make those accesses virtual' mean?
I need to update the patch description.
Virtual memory access was needed when I overloaded the normal memops to
access the SIDA. Real access would have accessed guest memory directly
which results in a guest crash for protected VMs.
>
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> ---
>> target/s390x/diag.c | 32 +++++++++++++++++++++++++-------
>> 1 file changed, 25 insertions(+), 7 deletions(-)
>>
>> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
>> index 6aaeef6029..59ae122e82 100644
>> --- a/target/s390x/diag.c
>> +++ b/target/s390x/diag.c
>> @@ -88,6 +88,7 @@ static int diag308_parm_check(CPUS390XState *env, uint64_t r1, uint64_t addr,
>> void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
>> {
>> CPUState *cs = env_cpu(env);
>> + S390CPU *cpu = S390_CPU(cs);
>> uint64_t addr = env->regs[r1];
>> uint64_t subcode = env->regs[r3];
>> IplParameterBlock *iplb;
>> @@ -118,14 +119,24 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
>> if (diag308_parm_check(env, r1, addr, ra, false)) {
>> return;
>> }
>> +
>
> Whitespace.
Ack.
>
>> iplb = g_new0(IplParameterBlock, 1);
>> - cpu_physical_memory_read(addr, iplb, sizeof(iplb->len));
>> + if (!env->pv) {
>> + cpu_physical_memory_read(addr, iplb, sizeof(iplb->len));
>> + } else {
>> + s390_cpu_pv_mem_read(cpu, 0, iplb, sizeof(iplb->len));
>> + }
>> +
>> if (!iplb_valid_len(iplb)) {
>> env->regs[r1 + 1] = DIAG_308_RC_INVALID;
>> goto out;
>> }
>>
>> - cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
>> + if (!env->pv) {
>> + cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
>> + } else {
>> + s390_cpu_pv_mem_read(cpu, 0, iplb, be32_to_cpu(iplb->len));
>> + }
>>
>> if (!iplb_valid_ccw(iplb) && !iplb_valid_fcp(iplb) &&
>> !(iplb_valid_pv(iplb) && s390_ipl_pv_check_components(iplb) >= 0)) {
>> @@ -137,23 +148,30 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
>> env->regs[r1 + 1] = DIAG_308_RC_OK;
>> out:
>> g_free(iplb);
>> - return;
>> + break;
>> case DIAG308_STORE:
>> case DIAG308_PV_STORE:
>> if (diag308_parm_check(env, r1, addr, ra, true)) {
>> return;
>> }
>> +
>
> Whitespace.
Ack.
>
>> if (subcode == DIAG308_PV_STORE) {
>> iplb = s390_ipl_get_iplb_secure();
>> } else {
>> iplb = s390_ipl_get_iplb();
>> }
>> - if (iplb) {
>> - cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
>> - env->regs[r1 + 1] = DIAG_308_RC_OK;
>> - } else {
>> + if (!iplb) {
>> env->regs[r1 + 1] = DIAG_308_RC_NO_CONF;
>> + return;
>> }
>> +
>> + if (!env->pv) {
>> + cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
>> + } else {
>> + s390_cpu_pv_mem_write(cpu, 0, iplb, be32_to_cpu(iplb->len));
>> + }
>> +
>> + env->regs[r1 + 1] = DIAG_308_RC_OK;
>> break;
>> case DIAG308_PV_START:
>> iplb = s390_ipl_get_iplb_secure();
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 05/12] ceph: cap tracking for async directory operations
From: Jeff Layton @ 2020-02-20 11:30 UTC (permalink / raw)
To: Yan, Zheng
Cc: ceph-devel, Ilya Dryomov, Sage Weil, Zheng Yan, Patrick Donnelly,
Xiubo Li
In-Reply-To: <CAAM7YAk-cjnPqH0UhBRvzvZdk4JTXwuVzxBD8ObunQqVxm2NuQ@mail.gmail.com>
On Thu, 2020-02-20 at 14:42 +0800, Yan, Zheng wrote:
> On Wed, Feb 19, 2020 at 9:27 PM Jeff Layton <jlayton@kernel.org> wrote:
> > Track and correctly handle directory caps for asynchronous operations.
> > Add aliases for Frc caps that we now designate at Dcu caps (when dealing
> > with directories).
> >
> > Unlike file caps, we don't reclaim these when the session goes away, and
> > instead preemptively release them. In-flight async dirops are instead
> > handled during reconnect phase. The client needs to re-do a synchronous
> > operation in order to re-get directory caps.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/ceph/caps.c | 29 ++++++++++++++++++++---------
> > fs/ceph/mds_client.c | 31 ++++++++++++++++++++++++++-----
> > fs/ceph/mds_client.h | 6 +++++-
> > include/linux/ceph/ceph_fs.h | 6 ++++++
> > 4 files changed, 57 insertions(+), 15 deletions(-)
> >
> > diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> > index 295837215a3a..d6c5ee33f30f 100644
> > --- a/fs/ceph/caps.c
> > +++ b/fs/ceph/caps.c
> > @@ -992,7 +992,11 @@ int __ceph_caps_file_wanted(struct ceph_inode_info *ci)
> > int __ceph_caps_wanted(struct ceph_inode_info *ci)
> > {
> > int w = __ceph_caps_file_wanted(ci) | __ceph_caps_used(ci);
> > - if (!S_ISDIR(ci->vfs_inode.i_mode)) {
> > + if (S_ISDIR(ci->vfs_inode.i_mode)) {
> > + /* we want EXCL if holding caps of dir ops */
> > + if (w & CEPH_CAP_ANY_DIR_OPS)
> > + w |= CEPH_CAP_FILE_EXCL;
> > + } else {
> > /* we want EXCL if dirty data */
> > if (w & CEPH_CAP_FILE_BUFFER)
> > w |= CEPH_CAP_FILE_EXCL;
> > @@ -1890,10 +1894,13 @@ void ceph_check_caps(struct ceph_inode_info *ci, int flags,
> > * revoking the shared cap on every create/unlink
> > * operation.
> > */
> > - if (IS_RDONLY(inode))
> > + if (IS_RDONLY(inode)) {
> > want = CEPH_CAP_ANY_SHARED;
> > - else
> > - want = CEPH_CAP_ANY_SHARED | CEPH_CAP_FILE_EXCL;
> > + } else {
> > + want = CEPH_CAP_ANY_SHARED |
> > + CEPH_CAP_FILE_EXCL |
> > + CEPH_CAP_ANY_DIR_OPS;
> > + }
> > retain |= want;
> > } else {
> >
> > @@ -2750,13 +2757,17 @@ int ceph_try_get_caps(struct inode *inode, int need, int want,
> > int ret;
> >
> > BUG_ON(need & ~CEPH_CAP_FILE_RD);
> > - BUG_ON(want & ~(CEPH_CAP_FILE_CACHE|CEPH_CAP_FILE_LAZYIO|CEPH_CAP_FILE_SHARED));
> > - ret = ceph_pool_perm_check(inode, need);
> > - if (ret < 0)
> > - return ret;
> > + if (need) {
> > + ret = ceph_pool_perm_check(inode, need);
> > + if (ret < 0)
> > + return ret;
> > + }
> >
> > + BUG_ON(want & ~(CEPH_CAP_FILE_CACHE | CEPH_CAP_FILE_LAZYIO |
> > + CEPH_CAP_FILE_SHARED | CEPH_CAP_FILE_EXCL |
> > + CEPH_CAP_ANY_DIR_OPS));
> > ret = try_get_cap_refs(inode, need, want, 0,
> > - (nonblock ? NON_BLOCKING : 0), got);
> > + nonblock ? NON_BLOCKING : 0, got);
> > return ret == -EAGAIN ? 0 : ret;
> > }
> >
> > diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> > index 38eb9dd5062b..ef3dd6fe2f4d 100644
> > --- a/fs/ceph/mds_client.c
> > +++ b/fs/ceph/mds_client.c
> > @@ -699,6 +699,7 @@ void ceph_mdsc_release_request(struct kref *kref)
> > struct ceph_mds_request *req = container_of(kref,
> > struct ceph_mds_request,
> > r_kref);
> > + ceph_mdsc_release_dir_caps(req);
>
> I think we can do this in complete_request()
>
That's what I was doing originally, but doing it there complicates the
error handling in the case where we end up tearing down the request
before it's ever submitted for transmission. It's also weird, as
ceph_mdsc_release_request is where other resources for the request are
released.
It's safe to call it more than once though, so I suppose we could do it
in complete_request and here.
> > destroy_reply_info(&req->r_reply_info);
> > if (req->r_request)
> > ceph_msg_put(req->r_request);
> > @@ -3280,6 +3281,17 @@ static void handle_session(struct ceph_mds_session *session,
> > return;
> > }
> >
> > +void ceph_mdsc_release_dir_caps(struct ceph_mds_request *req)
> > +{
> > + int dcaps;
> > +
> > + dcaps = xchg(&req->r_dir_caps, 0);
> > + if (dcaps) {
> > + dout("releasing r_dir_caps=%s\n", ceph_cap_string(dcaps));
> > + ceph_put_cap_refs(ceph_inode(req->r_parent), dcaps);
> > + }
> > +}
> > +
> > /*
> > * called under session->mutex.
> > */
> > @@ -3307,9 +3319,14 @@ static void replay_unsafe_requests(struct ceph_mds_client *mdsc,
> > continue;
> > if (req->r_attempts == 0)
> > continue; /* only old requests */
> > - if (req->r_session &&
> > - req->r_session->s_mds == session->s_mds)
> > - __send_request(mdsc, session, req, true);
> > + if (!req->r_session)
> > + continue;
> > + if (req->r_session->s_mds != session->s_mds)
> > + continue;
> > +
> > + ceph_mdsc_release_dir_caps(req);
> > +
> > + __send_request(mdsc, session, req, true);
> > }
> > mutex_unlock(&mdsc->mutex);
> > }
> > @@ -3393,7 +3410,7 @@ static int send_reconnect_partial(struct ceph_reconnect_state *recon_state)
> > /*
> > * Encode information about a cap for a reconnect with the MDS.
> > */
> > -static int encode_caps_cb(struct inode *inode, struct ceph_cap *cap,
> > +static int reconnect_caps_cb(struct inode *inode, struct ceph_cap *cap,
> > void *arg)
> > {
> > union {
> > @@ -3416,6 +3433,10 @@ static int encode_caps_cb(struct inode *inode, struct ceph_cap *cap,
> > cap->mseq = 0; /* and migrate_seq */
> > cap->cap_gen = cap->session->s_cap_gen;
> >
> > + /* These are lost when the session goes away */
> > + if (S_ISDIR(inode->i_mode))
> > + cap->issued &= ~CEPH_CAP_ANY_DIR_OPS;
> > +
> > if (recon_state->msg_version >= 2) {
> > rec.v2.cap_id = cpu_to_le64(cap->cap_id);
> > rec.v2.wanted = cpu_to_le32(__ceph_caps_wanted(ci));
> > @@ -3712,7 +3733,7 @@ static void send_mds_reconnect(struct ceph_mds_client *mdsc,
> > recon_state.msg_version = 2;
> > }
> > /* trsaverse this session's caps */
> > - err = ceph_iterate_session_caps(session, encode_caps_cb, &recon_state);
> > + err = ceph_iterate_session_caps(session, reconnect_caps_cb, &recon_state);
> >
> > spin_lock(&session->s_cap_lock);
> > session->s_cap_reconnect = 0;
> > diff --git a/fs/ceph/mds_client.h b/fs/ceph/mds_client.h
> > index 8043f2b439b1..f10d342ea585 100644
> > --- a/fs/ceph/mds_client.h
> > +++ b/fs/ceph/mds_client.h
> > @@ -284,8 +284,11 @@ struct ceph_mds_request {
> > struct ceph_msg *r_request; /* original request */
> > struct ceph_msg *r_reply;
> > struct ceph_mds_reply_info_parsed r_reply_info;
> > - struct page *r_locked_page;
> > int r_err;
> > +
> > +
> > + struct page *r_locked_page;
> > + int r_dir_caps;
> > int r_num_caps;
> > u32 r_readdir_offset;
> >
> > @@ -489,6 +492,7 @@ extern int ceph_mdsc_submit_request(struct ceph_mds_client *mdsc,
> > extern int ceph_mdsc_do_request(struct ceph_mds_client *mdsc,
> > struct inode *dir,
> > struct ceph_mds_request *req);
> > +extern void ceph_mdsc_release_dir_caps(struct ceph_mds_request *req);
> > static inline void ceph_mdsc_get_request(struct ceph_mds_request *req)
> > {
> > kref_get(&req->r_kref);
> > diff --git a/include/linux/ceph/ceph_fs.h b/include/linux/ceph/ceph_fs.h
> > index 94cc4b047987..91d09cf37649 100644
> > --- a/include/linux/ceph/ceph_fs.h
> > +++ b/include/linux/ceph/ceph_fs.h
> > @@ -663,6 +663,12 @@ int ceph_flags_to_mode(int flags);
> > #define CEPH_CAP_LOCKS (CEPH_LOCK_IFILE | CEPH_LOCK_IAUTH | CEPH_LOCK_ILINK | \
> > CEPH_LOCK_IXATTR)
> >
> > +/* cap masks async dir operations */
> > +#define CEPH_CAP_DIR_CREATE CEPH_CAP_FILE_CACHE
> > +#define CEPH_CAP_DIR_UNLINK CEPH_CAP_FILE_RD
> > +#define CEPH_CAP_ANY_DIR_OPS (CEPH_CAP_FILE_CACHE | CEPH_CAP_FILE_RD | \
> > + CEPH_CAP_FILE_WREXTEND | CEPH_CAP_FILE_LAZYIO)
> > +
> > int ceph_caps_for_mode(int mode);
> >
> > enum {
> > --
> > 2.24.1
> >
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver #16]
From: Ian Kent @ 2020-02-20 11:30 UTC (permalink / raw)
To: Christian Brauner
Cc: David Howells, viro, mszeredi, christian, linux-api,
linux-fsdevel, linux-kernel
In-Reply-To: <20200220090939.4e2mpmdixcyruzda@wittgenstein>
On Thu, 2020-02-20 at 10:09 +0100, Christian Brauner wrote:
> On Thu, Feb 20, 2020 at 12:42:15PM +0800, Ian Kent wrote:
> > On Wed, 2020-02-19 at 15:46 +0100, Christian Brauner wrote:
> > > On Tue, Feb 18, 2020 at 05:04:55PM +0000, David Howells wrote:
> > > > Here are a set of patches that adds system calls, that (a)
> > > > allow
> > > > information about the VFS, mount topology, superblock and files
> > > > to
> > > > be
> > > > retrieved and (b) allow for notifications of mount topology
> > > > rearrangement
> > > > events, mount and superblock attribute changes and other
> > > > superblock
> > > > events,
> > > > such as errors.
> > > >
> > > > ============================
> > > > FILESYSTEM INFORMATION QUERY
> > > > ============================
> > > >
> > > > The first system call, fsinfo(), allows information about the
> > > > filesystem at
> > > > a particular path point to be queried as a set of attributes,
> > > > some
> > > > of which
> > > > may have more than one value.
> > > >
> > > > Attribute values are of four basic types:
> > > >
> > > > (1) Version dependent-length structure (size defined by type).
> > > >
> > > > (2) Variable-length string (up to 4096, including NUL).
> > > >
> > > > (3) List of structures (up to INT_MAX size).
> > > >
> > > > (4) Opaque blob (up to INT_MAX size).
> > >
> > > I mainly have an organizational question. :) This is a huge
> > > patchset
> > > with lots and lots of (good) features. Wouldn't it make sense to
> > > make
> > > the fsinfo() syscall a completely separate patchset from the
> > > watch_mount() and watch_sb() syscalls? It seems that they don't
> > > need
> > > to
> > > depend on each other at all. This would make reviewing this so
> > > much
> > > nicer and likely would mean that fsinfo() could proceed a little
> > > faster.
> >
> > The remainder of the fsinfo() series would need to remain useful
> > if this was done.
> >
> > For context I want work on improving handling of large mount
> > tables.
>
> Yeah, I've talked to David about this; polling on a large mountinfo
> file
> is not great, I agree.
>
> > Ultimately I expect to solve a very long standing autofs problem
> > of using large direct mount maps without prohibitive performance
> > overhead (and there a lot of rather challenging autofs changes to
> > do for this too) and I believe the fsinfo() system call, and
> > related bits, is the way to do this.
> >
> > But improving the handling of large mount tables for autofs
> > will have the side effect of improvements for other mount table
> > users, even in the early stages of this work.
> >
> > For example I want to use this for mount table handling
> > improvements
> > in libmount. Clearly that ultimately needs mount change
> > notification
> > in the end but ...
> >
> > There's a bunch of things that need to be done alone the way
> > to even get started.
> >
> > One thing that's needed is the ability to call fsinfo() to get
> > information on a mount to avoid constant reading of the proc based
> > mount table, which happens a lot (since the mount info. needs
> > to be up to date) so systemd (and others) would see an improvement
> > with the fsinfo() system call alone able to be used in libmount.
> >
> > But for the fsinfo() system call to be used for this the file
> > system specific mount options need to also be obtained when
> > using fsinfo(). That means the super block operation fsinfo uses
> > to provide this must be implemented for at least most file systems.
> >
> > So separating out the notifications part, leaving whatever is
> > needed
> > to still be able to do this, should be fine and the system call
> > would be immediately useful once the super operation is implemented
> > for the needed file systems.
> >
> > Whether the implementation of the super operation should be done
> > as part of this series is another question but would certainly
> > be a challenge and make the series more complicated. But is needed
> > for the change to be useful in my case.
>
> I think what would might work - and what David had already brought up
> briefly - is to either base the fsinfo branch on top of the mount
> notificaiton branch or break the notification counters pieces into a
> separate patch and base both mount notifications and fsinfo on top of
> it.
Possibly, but I'm pretty sure David has more fsinfo patches.
So I suspect there will be a right time to post patches for the
fsinfo super block operation that David doesn't already have. I'm
going to have to find time for that ...
The post was more to let David know what my first goal is and what
I need for it, and to let others know there is someone wanting to
use this for user space improvements and give some initial insight
into my longer term goals.
Ian
^ permalink raw reply
* Re: [PATCH v5 07/12] ceph: perform asynchronous unlink if we have sufficient caps
From: Jeff Layton @ 2020-02-20 11:32 UTC (permalink / raw)
To: Yan, Zheng
Cc: ceph-devel, Ilya Dryomov, Sage Weil, Zheng Yan, Patrick Donnelly,
Xiubo Li
In-Reply-To: <CAAM7YAnLELDoaWdO38Jez_HxiuC6mQhUgBJHspgkFYzVD7fnNQ@mail.gmail.com>
On Thu, 2020-02-20 at 14:44 +0800, Yan, Zheng wrote:
> On Wed, Feb 19, 2020 at 9:27 PM Jeff Layton <jlayton@kernel.org> wrote:
> > The MDS is getting a new lock-caching facility that will allow it
> > to cache the necessary locks to allow asynchronous directory operations.
> > Since the CEPH_CAP_FILE_* caps are currently unused on directories,
> > we can repurpose those bits for this purpose.
> >
> > When performing an unlink, if we have Fx on the parent directory,
> > and CEPH_CAP_DIR_UNLINK (aka Fr), and we know that the dentry being
> > removed is the primary link, then then we can fire off an unlink
> > request immediately and don't need to wait on reply before returning.
> >
> > In that situation, just fix up the dcache and link count and return
> > immediately after issuing the call to the MDS. This does mean that we
> > need to hold an extra reference to the inode being unlinked, and extra
> > references to the caps to avoid races. Those references are put and
> > error handling is done in the r_callback routine.
> >
> > If the operation ends up failing, then set a writeback error on the
> > directory inode, and the inode itself that can be fetched later by
> > an fsync on the dir.
> >
> > The behavior of dir caps is slightly different from caps on normal
> > files. Because these are just considered an optimization, if the
> > session is reconnected, we will not automatically reclaim them. They
> > are instead considered lost until we do another synchronous op in the
> > parent directory.
> >
> > Async dirops are enabled via the "nowsync" mount option, which is
> > patterned after the xfs "wsync" mount option. For now, the default
> > is "wsync", but eventually we may flip that.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/ceph/dir.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++--
> > fs/ceph/super.c | 20 ++++++++++
> > fs/ceph/super.h | 5 ++-
> > 3 files changed, 123 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
> > index 5b83bda57056..37ab09d223fc 100644
> > --- a/fs/ceph/dir.c
> > +++ b/fs/ceph/dir.c
> > @@ -1036,6 +1036,73 @@ static int ceph_link(struct dentry *old_dentry, struct inode *dir,
> > return err;
> > }
> >
> > +static void ceph_async_unlink_cb(struct ceph_mds_client *mdsc,
> > + struct ceph_mds_request *req)
> > +{
> > + int result = req->r_err ? req->r_err :
> > + le32_to_cpu(req->r_reply_info.head->result);
> > +
> > + /* If op failed, mark everyone involved for errors */
> > + if (result) {
>
> I think this function will get called for -EJUKEBOX case.
>
Good catch. I'll have another look at how to handle this better.
>
> > + int pathlen;
> > + u64 base;
> > + char *path = ceph_mdsc_build_path(req->r_dentry, &pathlen,
> > + &base, 0);
> > +
> > + /* mark error on parent + clear complete */
> > + mapping_set_error(req->r_parent->i_mapping, result);
> > + ceph_dir_clear_complete(req->r_parent);
> > +
> > + /* drop the dentry -- we don't know its status */
> > + if (!d_unhashed(req->r_dentry))
> > + d_drop(req->r_dentry);
> > +
> > + /* mark inode itself for an error (since metadata is bogus) */
> > + mapping_set_error(req->r_old_inode->i_mapping, result);
> > +
> > + pr_warn("ceph: async unlink failure path=(%llx)%s result=%d!\n",
> > + base, IS_ERR(path) ? "<<bad>>" : path, result);
> > + ceph_mdsc_free_path(path, pathlen);
> > + }
> > + iput(req->r_old_inode);
> > +}
> > +
> > +static int get_caps_for_async_unlink(struct inode *dir, struct dentry *dentry)
> > +{
> > + struct ceph_inode_info *ci = ceph_inode(dir);
> > + struct ceph_dentry_info *di;
> > + int got = 0, want = CEPH_CAP_FILE_EXCL | CEPH_CAP_DIR_UNLINK;
> > +
> > + spin_lock(&ci->i_ceph_lock);
> > + if ((__ceph_caps_issued(ci, NULL) & want) == want) {
> > + ceph_take_cap_refs(ci, want, false);
> > + got = want;
> > + }
> > + spin_unlock(&ci->i_ceph_lock);
> > +
> > + /* If we didn't get anything, return 0 */
> > + if (!got)
> > + return 0;
> > +
> > + spin_lock(&dentry->d_lock);
> > + di = ceph_dentry(dentry);
> > + /*
> > + * - We are holding Fx, which implies Fs caps.
> > + * - Only support async unlink for primary linkage
> > + */
> > + if (atomic_read(&ci->i_shared_gen) != di->lease_shared_gen ||
> > + !(di->flags & CEPH_DENTRY_PRIMARY_LINK))
> > + want = 0;
> > + spin_unlock(&dentry->d_lock);
> > +
> > + /* Do we still want what we've got? */
> > + if (want == got)
> > + return got;
> > +
> > + ceph_put_cap_refs(ci, got);
> > + return 0;
> > +}
> > +
> > /*
> > * rmdir and unlink are differ only by the metadata op code
> > */
> > @@ -1045,6 +1112,7 @@ static int ceph_unlink(struct inode *dir, struct dentry *dentry)
> > struct ceph_mds_client *mdsc = fsc->mdsc;
> > struct inode *inode = d_inode(dentry);
> > struct ceph_mds_request *req;
> > + bool try_async = ceph_test_mount_opt(fsc, ASYNC_DIROPS);
> > int err = -EROFS;
> > int op;
> >
> > @@ -1059,6 +1127,7 @@ static int ceph_unlink(struct inode *dir, struct dentry *dentry)
> > CEPH_MDS_OP_RMDIR : CEPH_MDS_OP_UNLINK;
> > } else
> > goto out;
> > +retry:
> > req = ceph_mdsc_create_request(mdsc, op, USE_AUTH_MDS);
> > if (IS_ERR(req)) {
> > err = PTR_ERR(req);
> > @@ -1067,13 +1136,39 @@ static int ceph_unlink(struct inode *dir, struct dentry *dentry)
> > req->r_dentry = dget(dentry);
> > req->r_num_caps = 2;
> > req->r_parent = dir;
> > - set_bit(CEPH_MDS_R_PARENT_LOCKED, &req->r_req_flags);
> > req->r_dentry_drop = CEPH_CAP_FILE_SHARED;
> > req->r_dentry_unless = CEPH_CAP_FILE_EXCL;
> > req->r_inode_drop = ceph_drop_caps_for_unlink(inode);
> > - err = ceph_mdsc_do_request(mdsc, dir, req);
> > - if (!err && !req->r_reply_info.head->is_dentry)
> > - d_delete(dentry);
> > +
> > + if (try_async && op == CEPH_MDS_OP_UNLINK &&
> > + (req->r_dir_caps = get_caps_for_async_unlink(dir, dentry))) {
> > + dout("async unlink on %lu/%.*s caps=%s", dir->i_ino,
> > + dentry->d_name.len, dentry->d_name.name,
> > + ceph_cap_string(req->r_dir_caps));
> > + set_bit(CEPH_MDS_R_ASYNC, &req->r_req_flags);
> > + req->r_callback = ceph_async_unlink_cb;
> > + req->r_old_inode = d_inode(dentry);
> > + ihold(req->r_old_inode);
> > + err = ceph_mdsc_submit_request(mdsc, dir, req);
> > + if (!err) {
> > + /*
> > + * We have enough caps, so we assume that the unlink
> > + * will succeed. Fix up the target inode and dcache.
> > + */
> > + drop_nlink(inode);
> > + d_delete(dentry);
> > + } else if (err == -EJUKEBOX) {
> > + try_async = false;
> > + ceph_mdsc_put_request(req);
> > + goto retry;
> > + }
> > + } else {
> > + set_bit(CEPH_MDS_R_PARENT_LOCKED, &req->r_req_flags);
> > + err = ceph_mdsc_do_request(mdsc, dir, req);
> > + if (!err && !req->r_reply_info.head->is_dentry)
> > + d_delete(dentry);
> > + }
> > +
> > ceph_mdsc_put_request(req);
> > out:
> > return err;
> > diff --git a/fs/ceph/super.c b/fs/ceph/super.c
> > index b1329cd5388a..c9784eb1159a 100644
> > --- a/fs/ceph/super.c
> > +++ b/fs/ceph/super.c
> > @@ -155,6 +155,7 @@ enum {
> > Opt_acl,
> > Opt_quotadf,
> > Opt_copyfrom,
> > + Opt_wsync,
> > };
> >
> > enum ceph_recover_session_mode {
> > @@ -194,6 +195,7 @@ static const struct fs_parameter_spec ceph_mount_parameters[] = {
> > fsparam_string ("snapdirname", Opt_snapdirname),
> > fsparam_string ("source", Opt_source),
> > fsparam_u32 ("wsize", Opt_wsize),
> > + fsparam_flag_no ("wsync", Opt_wsync),
> > {}
> > };
> >
> > @@ -444,6 +446,12 @@ static int ceph_parse_mount_param(struct fs_context *fc,
> > fc->sb_flags &= ~SB_POSIXACL;
> > }
> > break;
> > + case Opt_wsync:
> > + if (!result.negated)
> > + fsopt->flags &= ~CEPH_MOUNT_OPT_ASYNC_DIROPS;
> > + else
> > + fsopt->flags |= CEPH_MOUNT_OPT_ASYNC_DIROPS;
> > + break;
> > default:
> > BUG();
> > }
> > @@ -567,6 +575,9 @@ static int ceph_show_options(struct seq_file *m, struct dentry *root)
> > if (fsopt->flags & CEPH_MOUNT_OPT_CLEANRECOVER)
> > seq_show_option(m, "recover_session", "clean");
> >
> > + if (fsopt->flags & CEPH_MOUNT_OPT_ASYNC_DIROPS)
> > + seq_puts(m, ",nowsync");
> > +
> > if (fsopt->wsize != CEPH_MAX_WRITE_SIZE)
> > seq_printf(m, ",wsize=%u", fsopt->wsize);
> > if (fsopt->rsize != CEPH_MAX_READ_SIZE)
> > @@ -1115,6 +1126,15 @@ static void ceph_free_fc(struct fs_context *fc)
> >
> > static int ceph_reconfigure_fc(struct fs_context *fc)
> > {
> > + struct ceph_parse_opts_ctx *pctx = fc->fs_private;
> > + struct ceph_mount_options *fsopt = pctx->opts;
> > + struct ceph_fs_client *fsc = ceph_sb_to_client(fc->root->d_sb);
> > +
> > + if (fsopt->flags & CEPH_MOUNT_OPT_ASYNC_DIROPS)
> > + ceph_set_mount_opt(fsc, ASYNC_DIROPS);
> > + else
> > + ceph_clear_mount_opt(fsc, ASYNC_DIROPS);
> > +
> > sync_filesystem(fc->root->d_sb);
> > return 0;
> > }
> > diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> > index 2393803c38de..1b4996efc111 100644
> > --- a/fs/ceph/super.h
> > +++ b/fs/ceph/super.h
> > @@ -43,13 +43,16 @@
> > #define CEPH_MOUNT_OPT_MOUNTWAIT (1<<12) /* mount waits if no mds is up */
> > #define CEPH_MOUNT_OPT_NOQUOTADF (1<<13) /* no root dir quota in statfs */
> > #define CEPH_MOUNT_OPT_NOCOPYFROM (1<<14) /* don't use RADOS 'copy-from' op */
> > +#define CEPH_MOUNT_OPT_ASYNC_DIROPS (1<<15) /* allow async directory ops */
> >
> > #define CEPH_MOUNT_OPT_DEFAULT \
> > (CEPH_MOUNT_OPT_DCACHE | \
> > CEPH_MOUNT_OPT_NOCOPYFROM)
> >
> > #define ceph_set_mount_opt(fsc, opt) \
> > - (fsc)->mount_options->flags |= CEPH_MOUNT_OPT_##opt;
> > + (fsc)->mount_options->flags |= CEPH_MOUNT_OPT_##opt
> > +#define ceph_clear_mount_opt(fsc, opt) \
> > + (fsc)->mount_options->flags &= ~CEPH_MOUNT_OPT_##opt
> > #define ceph_test_mount_opt(fsc, opt) \
> > (!!((fsc)->mount_options->flags & CEPH_MOUNT_OPT_##opt))
> >
> > --
> > 2.24.1
> >
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: Device Tree Evolution Project - call notes - 12th February
From: Steve McIntyre @ 2020-02-20 11:32 UTC (permalink / raw)
To: Frank Rowand
Cc: devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
dte-all-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <6391cf01-ebf0-fcb7-9c86-679d335c16d2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Feb 19, 2020 at 12:26:54PM -0600, Frank Rowand wrote:
>On 2/19/20 12:05 PM, Steve McIntyre wrote:
>>
>> Do you have any pointers to previous discussions about the format
>> update please? The only relevant things I can find are in the thread
>> "DTBO magic and dtbo format options" but that's back in the middle of
>> 2016.
>
>Documenting all the previous proposals in one place is the next item
>on my todo list after finishing my "why I don't want .dts to move out
>of the kernel tree" document. Once the format discussion history
>document exists then I intend to restart the discussion on the mail
>lists.
ACK. It's taking a while to get there - is there anything we can do to
help?
Cheers,
--
Steve McIntyre steve.mcintyre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
^ permalink raw reply
* Re: [Xen-devel] [PATCH] Avoid cpu_physical_memory_rw() with a constant is_write argument
From: Paolo Bonzini @ 2020-02-20 11:32 UTC (permalink / raw)
To: Peter Maydell, Stefan Weil
Cc: Stefano Stabellini, Eduardo Habkost, Paul Durrant,
QEMU Developers, Anthony Perard, open list:X86,
Philippe Mathieu-Daudé, Richard Henderson
In-Reply-To: <CAFEAcA9Jr2Yi1K8_9MGUJYt8C=OcKbWDh1UJjTQG1EspLux3JQ@mail.gmail.com>
On 18/02/20 19:49, Peter Maydell wrote:
> Depending on which way we go we would either want to remove these
> casts, or not.
>
> I guess that we have more cases of 'void*', and that would
> certainly be the easier way to convert (otherwise we probably
> need to add a bunch of new casts to uint8_t* in various callsites),
> but I don't have a strong opinion. Paolo ?
I agree we should use void* (possibly const).
Paolo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] Avoid cpu_physical_memory_rw() with a constant is_write argument
From: Paolo Bonzini @ 2020-02-20 11:32 UTC (permalink / raw)
To: Peter Maydell, Stefan Weil
Cc: Stefano Stabellini, Eduardo Habkost, Paul Durrant,
QEMU Developers, Anthony Perard, open list:X86,
Philippe Mathieu-Daudé, Richard Henderson
In-Reply-To: <CAFEAcA9Jr2Yi1K8_9MGUJYt8C=OcKbWDh1UJjTQG1EspLux3JQ@mail.gmail.com>
On 18/02/20 19:49, Peter Maydell wrote:
> Depending on which way we go we would either want to remove these
> casts, or not.
>
> I guess that we have more cases of 'void*', and that would
> certainly be the easier way to convert (otherwise we probably
> need to add a bunch of new casts to uint8_t* in various callsites),
> but I don't have a strong opinion. Paolo ?
I agree we should use void* (possibly const).
Paolo
^ permalink raw reply
* [PATCH] powerpc: Include .BTF section
From: Naveen N. Rao @ 2020-02-20 11:31 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
Selecting CONFIG_DEBUG_INFO_BTF results in the below warning from ld:
ld: warning: orphan section `.BTF' from `.btf.vmlinux.bin.o' being placed in section `.BTF'
Include .BTF section in vmlinux explicitly to fix the same.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/kernel/vmlinux.lds.S | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index b4c89a1acebb..a32d478a7f41 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -303,6 +303,12 @@ SECTIONS
*(.branch_lt)
}
+#ifdef CONFIG_DEBUG_INFO_BTF
+ .BTF : AT(ADDR(.BTF) - LOAD_OFFSET) {
+ *(.BTF)
+ }
+#endif
+
.opd : AT(ADDR(.opd) - LOAD_OFFSET) {
__start_opd = .;
KEEP(*(.opd))
--
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.