* [LTP] [PATCH v2] syscalls/quotactl07: add regresstion test for Q_XQTUOTARM
From: Cyril Hrubis @ 2020-02-20 12:48 UTC (permalink / raw)
To: ltp
In-Reply-To: <1575526664-25738-1-git-send-email-xuyang2018.jy@cn.fujitsu.com>
Hi!
> This is a regresstion test to check Q_XQUOTARM whether has
> quota flags check.
>
> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
>
> ---------------------
> 1.Simplify test code
> 2.add comment for invalid_type,
> ---------------------
^
Btw this belongs under the three dashes below, otherwise it ends up in
the commit message when applied.
...
> +static void setup(void)
> +{
> + TEST(quotactl(QCMD(Q_XQUOTAOFF, USRQUOTA), tst_device->dev, 0, (void *)&qflag_acct));
> + if (TST_RET == -1)
> + tst_brk(TBROK | TTERRNO, "quotactl with Q_XQUOTAOFF failed");
> +
> + TEST(quotactl(QCMD(Q_XQUOTARM, USRQUOTA), tst_device->dev, 0, (void *)&valid_type));
> + if (TST_ERR == EINVAL) {
> + tst_res(TCONF, "current system doesn't support Q_XQUOTARM, skip it");
> + return;
I've changed this to tst_brk() because doing return from setup has no
efect here, and pushed, thanks.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply
* Re: [Xen-devel] [PATCH v6] x86: introduce a new set of APIs to manage Xen page tables
From: Wei Liu @ 2020-02-20 12:47 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, Andrew Cooper, jgrall, Hongyan Xia, xen-devel,
Roger Pau Monné
In-Reply-To: <f2560c00-dc49-f709-d59a-dc057288ab67@suse.com>
On Thu, Feb 20, 2020 at 01:10:56PM +0100, Jan Beulich wrote:
> On 28.01.2020 15:21, Wei Liu wrote:
> > On Tue, Jan 28, 2020 at 01:50:05PM +0000, Hongyan Xia wrote:
> >> From: Wei Liu <wei.liu2@citrix.com>
> >>
> >> We are going to switch to using domheap page for page tables.
> >> A new set of APIs is introduced to allocate and free pages of page
> >> tables based on mfn instead of the xenheap direct map address. The
> >> allocation and deallocation work on mfn_t but not page_info, because
> >> they are required to work even before frame table is set up.
> >>
> >> Implement the old functions with the new ones. We will rewrite, site
> >> by site, other mm functions that manipulate page tables to use the new
> >> APIs.
> >>
> >> After the allocation, one needs to map and unmap via map_domain_page to
> >> access the PTEs. This does not break xen half way, since the new APIs
> >> still use xenheap pages underneath, and map_domain_page will just use
> >> the directmap for mappings. They will be switched to use domheap and
> >> dynamic mappings when usage of old APIs is eliminated.
> >>
> >> No functional change intended in this patch.
> >>
> >> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> >> Reviewed-by: Julien Grall <jgrall@amazon.com>
> >
> > Reviewed-by: Wei Liu <wl@xen.org>
>
> Acked-by: Jan Beulich <jbeulich@suse.com>
Thanks. I have pushed this patch to unblock Hongyan.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 06/12] drm: Shrink {width,height}_mm to u16
From: Emil Velikov @ 2020-02-20 12:48 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200219203544.31013-7-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Instead of supporting ~2000km wide displayes let's limit ourselves
> to ~65m. That seems plenty big enough to me.
>
> Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
> 10*0xfff which fits into the 16 bits.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> include/drm/drm_modes.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 52e8ca613e4b..2bb2b1a8592a 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -330,7 +330,7 @@ struct drm_display_mode {
> * Addressable size of the output in mm, projectors should set this to
> * 0.
> */
> - int width_mm;
> + u16 width_mm;
>
> /**
> * @height_mm:
> @@ -338,7 +338,7 @@ struct drm_display_mode {
> * Addressable size of the output in mm, projectors should set this to
> * 0.
> */
> - int height_mm;
> + u16 height_mm;
>
Fwiw we could do the same for struct drm_display_info, although we
should be carefull since that info sets passed to userspace.
Regardless, this patch is:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 06/12] drm: Shrink {width,height}_mm to u16
From: Emil Velikov @ 2020-02-20 12:48 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200219203544.31013-7-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Instead of supporting ~2000km wide displayes let's limit ourselves
> to ~65m. That seems plenty big enough to me.
>
> Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
> 10*0xfff which fits into the 16 bits.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> include/drm/drm_modes.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 52e8ca613e4b..2bb2b1a8592a 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -330,7 +330,7 @@ struct drm_display_mode {
> * Addressable size of the output in mm, projectors should set this to
> * 0.
> */
> - int width_mm;
> + u16 width_mm;
>
> /**
> * @height_mm:
> @@ -338,7 +338,7 @@ struct drm_display_mode {
> * Addressable size of the output in mm, projectors should set this to
> * 0.
> */
> - int height_mm;
> + u16 height_mm;
>
Fwiw we could do the same for struct drm_display_info, although we
should be carefull since that info sets passed to userspace.
Regardless, this patch is:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
From: Jan Beulich @ 2020-02-20 12:48 UTC (permalink / raw)
To: Roger Pau Monne
Cc: Jürgen Groß, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
xen-devel
In-Reply-To: <20200220120231.86907-1-roger.pau@citrix.com>
On 20.02.2020 13:02, Roger Pau Monne wrote:
> I've done some testing and at least the CPU down case is fixed now.
> Posting early in order to get feedback on the approach taken.
Looks good, thanks, just a question and two comments:
> --- a/xen/include/xen/rwlock.h
> +++ b/xen/include/xen/rwlock.h
> @@ -20,21 +20,30 @@ typedef struct {
> #define DEFINE_RWLOCK(l) rwlock_t l = RW_LOCK_UNLOCKED
> #define rwlock_init(l) (*(l) = (rwlock_t)RW_LOCK_UNLOCKED)
>
> -/*
> - * Writer states & reader shift and bias.
> - *
> - * Writer field is 8 bit to allow for potential optimisation, see
> - * _write_unlock().
> - */
> -#define _QW_WAITING 1 /* A writer is waiting */
> -#define _QW_LOCKED 0xff /* A writer holds the lock */
> -#define _QW_WMASK 0xff /* Writer mask.*/
> -#define _QR_SHIFT 8 /* Reader count shift */
> +/* Writer states & reader shift and bias. */
> +#define _QW_WAITING 1 /* A writer is waiting */
> +#define _QW_LOCKED 3 /* A writer holds the lock */
Aiui things would work equally well if 2 was used here?
> +#define _QW_WMASK 3 /* Writer mask */
> +#define _QW_CPUSHIFT 2 /* Writer CPU shift */
> +#define _QW_CPUMASK 0x3ffc /* Writer CPU mask */
At least on x86, the shift involved here is quite certainly
more expensive than using wider immediates on AND and CMP
resulting from the _QW_MASK-based comparisons. I'd therefore
like to suggest to put the CPU in the low 12 bits.
Another option is to use the recurse_cpu field of the
associated spin lock: The field is used for recursive locks
only, and hence the only conflict would be with
_spin_is_locked(), which we don't (and in the future then
also shouldn't) use on this lock.
> @@ -166,7 +180,8 @@ static inline void _write_unlock(rwlock_t *lock)
> * If the writer field is atomic, it can be cleared directly.
> * Otherwise, an atomic subtraction will be used to clear it.
> */
> - atomic_sub(_QW_LOCKED, &lock->cnts);
> + ASSERT(_is_write_locked_by_me(atomic_read(&lock->cnts)));
> + atomic_sub(_write_lock_val(), &lock->cnts);
I think this would be more efficient with atomic_and(), not
the least because of the then avoided smp_processor_id().
Whether to mask off just _QW_WMASK or also the CPU number of
the last write owner would need to be determined. But with
using subtraction, in case of problems it'll likely be
harder to understand what actually went on, from looking at
the resulting state of the lock (this is in part a pre-
existing problem, but gets worse with subtraction of CPU
numbers).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [LTP] ksm03, ksm04 testcases don't work with cgroup
From: Pankaj Vinadrao Joshi @ 2020-02-20 12:49 UTC (permalink / raw)
To: ltp
Hi,
I am running ksm03 and kms04 on my RISC v system wth linux 5.4.3,LTP Version: 20200120-55-g537fb6535
with custom Yocto distro,the test is getting failed with following errors.why it is failing?
root@exaleapsemi:~/pankaj_ltp/ltp/testcases/kernel/mem/ksm# ./ksm03
tst_test.c:1215: INFO: Timeout per run is 0h 05m 00s
safe_macros.c:167: BROK: mem.c:750: mkdir(/dev/cgroup,0777) failed: EEXIST (17)
Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200220/3cc5cefb/attachment.htm>
^ permalink raw reply
* Re: [PATCH v4 01/14] drm/i915: Fix sha_text population code
From: Sasha Levin @ 2020-02-20 12:49 UTC (permalink / raw)
To: Sasha Levin, Sean Paul, Sean Paul, dri-devel, intel-gfx
Cc: intel-gfx, Rodrigo Vivi, Sean Paul, stable, Daniel Vetter,
juston.li
In-Reply-To: <20200218220242.107265-2-sean@poorly.run>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation").
The bot has tested the following trees: v5.5.4, v5.4.20, v4.19.104.
v5.5.4: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register access")
v5.4.20: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register access")
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.104: Failed to apply! Possible dependencies:
04707f971636 ("drm/i915: Initialize HDCP2.2")
09d56393c1d8 ("drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking")
2f80d7bd8d93 ("drm/i915: drop all drmP.h includes")
33b7f3ee6e00 ("drm/i915: Add CRTC output format YCBCR 4:2:0")
340a44bef234 ("drm/i915/icl: program MG_DP_MODE")
342ac601df64 ("drm/i915: hdcp_check_link only on CP_IRQ")
47658556da85 ("drm/i915/dp: Do not grab crtc modeset lock in intel_dp_detect()")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register access")
668b6c176c33 ("drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON")
7b610f1fbed2 ("drm/i915/dp: Add DSC params and DSC config to intel_crtc_state")
9055aac76589 ("drm/i915: MEI interface implementation")
9844bc87cb7a ("drm/i915/dp: Fix duplication of DEVICE_SERVICE_IRQ handling")
bdc93fe0eb82 ("drm/i915/debugfs: hdcp capability of a sink")
cbfa8ac835cb ("drm/i915/dp: Kill intel_dp->detect_done flag")
d3dacc70797b ("drm/i915: wrapping all hdcp var into intel_hdcp")
d5acd97f5571 ("drm/i915/dp: Use a local variable for intel_encoder *")
d78aa650670d ("drm: Add drm/drm_util.h header file")
de25eb7f3075 ("drm/i915: introduce dp_to_i915() helper")
f106d1005ac7 ("drm/i915: Pullout the bksv read and validation")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v4 01/14] drm/i915: Fix sha_text population code
From: Sasha Levin @ 2020-02-20 12:49 UTC (permalink / raw)
To: Sasha Levin, Sean Paul, Sean Paul, dri-devel, intel-gfx
Cc: intel-gfx, Sean Paul, stable, Daniel Vetter
In-Reply-To: <20200218220242.107265-2-sean@poorly.run>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation").
The bot has tested the following trees: v5.5.4, v5.4.20, v4.19.104.
v5.5.4: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register access")
v5.4.20: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register access")
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.104: Failed to apply! Possible dependencies:
04707f971636 ("drm/i915: Initialize HDCP2.2")
09d56393c1d8 ("drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking")
2f80d7bd8d93 ("drm/i915: drop all drmP.h includes")
33b7f3ee6e00 ("drm/i915: Add CRTC output format YCBCR 4:2:0")
340a44bef234 ("drm/i915/icl: program MG_DP_MODE")
342ac601df64 ("drm/i915: hdcp_check_link only on CP_IRQ")
47658556da85 ("drm/i915/dp: Do not grab crtc modeset lock in intel_dp_detect()")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register access")
668b6c176c33 ("drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON")
7b610f1fbed2 ("drm/i915/dp: Add DSC params and DSC config to intel_crtc_state")
9055aac76589 ("drm/i915: MEI interface implementation")
9844bc87cb7a ("drm/i915/dp: Fix duplication of DEVICE_SERVICE_IRQ handling")
bdc93fe0eb82 ("drm/i915/debugfs: hdcp capability of a sink")
cbfa8ac835cb ("drm/i915/dp: Kill intel_dp->detect_done flag")
d3dacc70797b ("drm/i915: wrapping all hdcp var into intel_hdcp")
d5acd97f5571 ("drm/i915/dp: Use a local variable for intel_encoder *")
d78aa650670d ("drm: Add drm/drm_util.h header file")
de25eb7f3075 ("drm/i915: introduce dp_to_i915() helper")
f106d1005ac7 ("drm/i915: Pullout the bksv read and validation")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v7 1/5] btrfs: Introduce per-profile available space facility
From: Nikolay Borisov @ 2020-02-20 12:49 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: Josef Bacik
In-Reply-To: <20200211051153.19466-2-wqu@suse.com>
<snip>
>
> Suggested-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> fs/btrfs/volumes.c | 216 ++++++++++++++++++++++++++++++++++++++++-----
> fs/btrfs/volumes.h | 11 +++
> 2 files changed, 207 insertions(+), 20 deletions(-)
>
<snip>
> +
> +/*
> + * Return 0 if we allocated any virtual(*) chunk, and restore the size to
> + * @allocated_size
> + * Return -ENOSPC if we have no more space to allocate virtual chunk
> + *
> + * *: virtual chunk is a space holder for per-profile available space
> + * calculator.
> + * Such virtual chunks won't take on-disk space, thus called virtual, and
> + * only affects per-profile available space calulation.
> + */
Document that the last parameter is an output value which contains the
size of the allocated virtual chunk.
> +static int alloc_virtual_chunk(struct btrfs_fs_info *fs_info,
> + struct btrfs_device_info *devices_info,
> + enum btrfs_raid_types type,
> + u64 *allocated)
> +{
> + const struct btrfs_raid_attr *raid_attr = &btrfs_raid_array[type];
> + struct btrfs_fs_devices *fs_devices = fs_info->fs_devices;
> + struct btrfs_device *device;
> + u64 stripe_size;
> + int i;
> + int ndevs = 0;
> +
> + lockdep_assert_held(&fs_info->chunk_mutex);
> +
> + /* Go through devices to collect their unallocated space */
> + list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list) {
> + u64 avail;
> + if (!test_bit(BTRFS_DEV_STATE_IN_FS_METADATA,
> + &device->dev_state) ||
> + test_bit(BTRFS_DEV_STATE_REPLACE_TGT, &device->dev_state))
> + continue;
> +
> + if (device->total_bytes > device->bytes_used +
> + device->virtual_allocated)
> + avail = device->total_bytes - device->bytes_used -
> + device->virtual_allocated;
> + else
> + avail = 0;
> +
> + /* And exclude the [0, 1M) reserved space */
> + if (avail > SZ_1M)
> + avail -= SZ_1M;
> + else
> + avail = 0;
> +
> + if (avail < fs_info->sectorsize)
> + continue;
> + /*
> + * Unlike chunk allocator, we don't care about stripe or hole
> + * size, so here we use @avail directly
> + */
> + devices_info[ndevs].dev_offset = 0;
> + devices_info[ndevs].total_avail = avail;
> + devices_info[ndevs].max_avail = avail;
> + devices_info[ndevs].dev = device;
> + ++ndevs;
> + }
> + sort(devices_info, ndevs, sizeof(struct btrfs_device_info),
> + btrfs_cmp_device_info, NULL);
> + ndevs -= ndevs % raid_attr->devs_increment;
nit: ndevs = rounddown(ndevs, raid_attr->devs_increment);
makes it more clear what's going on. Since you are working with at most
int it's not a problem for 32bits.
> + if (ndevs < raid_attr->devs_min)
> + return -ENOSPC;
> + if (raid_attr->devs_max)
> + ndevs = min(ndevs, (int)raid_attr->devs_max);
> + else
> + ndevs = min(ndevs, (int)BTRFS_MAX_DEVS(fs_info));
Instead of casting simply use min_t(int, ndevs, BTRFS_MAX_DEVS...)
> +
> + /*
> + * Now allocate a virtual chunk using the unallocate space of the
nit: missing d after 'unallocate'
> + * device with the least unallocated space.
> + */
> + stripe_size = round_down(devices_info[ndevs - 1].total_avail,
> + fs_info->sectorsize);
> + if (stripe_size == 0)
> + return -ENOSPC;
Isn't this check redundant - in the loop where you iterate the devices
you always ensure total_avail is at least a sector size, this guarantees
that stripe_size cannot be 0 at this point.
> +
> + for (i = 0; i < ndevs; i++)
> + devices_info[i].dev->virtual_allocated += stripe_size;
> + *allocated = stripe_size * (ndevs - raid_attr->nparity) /
> + raid_attr->ncopies;
> + return 0;
> +}
> +
> +static int calc_one_profile_avail(struct btrfs_fs_info *fs_info,
> + enum btrfs_raid_types type,
> + u64 *result_ret)
> +{
> + struct btrfs_device_info *devices_info = NULL;
> + struct btrfs_fs_devices *fs_devices = fs_info->fs_devices;
> + struct btrfs_device *device;
> + u64 allocated;
> + u64 result = 0;
> + int ret = 0;
> +
lockdep assert that chunk mutex is held since you access alloc_list.
> + ASSERT(type >= 0 && type < BTRFS_NR_RAID_TYPES);
> +
> + /* Not enough devices, quick exit, just update the result */
> + if (fs_devices->rw_devices < btrfs_raid_array[type].devs_min)
> + goto out;
You can directly return.
> +
> + devices_info = kcalloc(fs_devices->rw_devices, sizeof(*devices_info),
> + GFP_NOFS);
> + if (!devices_info) {
> + ret = -ENOMEM;
> + goto out;
Same here.
> + }
> + /* Clear virtual chunk used space for each device */
> + list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list)
> + device->virtual_allocated = 0;
> + while (ret == 0) {
> + ret = alloc_virtual_chunk(fs_info, devices_info, type,
> + &allocated);
The 'allocated' variable is used only in this loop so declare it in the
loop. Ideally we want variables to have the shortest possible lifecycle.
> + if (ret == 0)
> + result += allocated;
> + }
Why do you need to call this in a loop calling alloc_virtual_chunk once
simply calculate the available space for the given raid type.
> + list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list)
> + device->virtual_allocated = 0;
> +out:
> + kfree(devices_info);
> + if (ret < 0 && ret != -ENOSPC)
> + return ret;
> + *result_ret = result;
> + return 0;
> +}
<snip>
> @@ -259,6 +266,10 @@ struct btrfs_fs_devices {
> struct kobject fsid_kobj;
> struct kobject *devices_kobj;
> struct completion kobj_unregister;
> +
> + /* Records per-type available space */
> + spinlock_t per_profile_lock;
> + u64 per_profile_avail[BTRFS_NR_RAID_TYPES];
Since every avail quantity is independent of any other, can you turn
this into an array of atomic64 values and get rid of the spinlock? My
head spins how many locks we have in btrfs.
> };
>
> #define BTRFS_BIO_INLINE_CSUM_SIZE 64
>
^ permalink raw reply
* Re: [PATCH 2/8] net: ll_temac: Add more error handling of dma_map_single() calls
From: Sasha Levin @ 2020-02-20 12:49 UTC (permalink / raw)
To: Sasha Levin, Esben Haabendal, netdev
Cc: stable, linux-kernel, linux-arm-kernel
In-Reply-To: <20200218082631.7204-1-esben@geanix.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.5.4, v5.4.20, v4.19.104, v4.14.171, v4.9.214, v4.4.214.
v5.5.4: Build OK!
v5.4.20: Build OK!
v4.19.104: Failed to apply! Possible dependencies:
d1441d4782f2 ("net: xilinx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles")
d84aec42151b ("net: ll_temac: Fix support for 64-bit platforms")
fdd7454ecb29 ("net: ll_temac: Fix support for little-endian platforms")
v4.14.171: Failed to apply! Possible dependencies:
aa5848bc4043 ("net: emaclite: Simplify if-else statements")
d1441d4782f2 ("net: xilinx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles")
d84aec42151b ("net: ll_temac: Fix support for 64-bit platforms")
fdd7454ecb29 ("net: ll_temac: Fix support for little-endian platforms")
v4.9.214: Failed to apply! Possible dependencies:
aa5848bc4043 ("net: emaclite: Simplify if-else statements")
d1441d4782f2 ("net: xilinx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles")
d84aec42151b ("net: ll_temac: Fix support for 64-bit platforms")
fdd7454ecb29 ("net: ll_temac: Fix support for little-endian platforms")
v4.4.214: Failed to apply! Possible dependencies:
860e9538a948 ("treewide: replace dev->trans_start update with helper")
aa5848bc4043 ("net: emaclite: Simplify if-else statements")
d1441d4782f2 ("net: xilinx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles")
d84aec42151b ("net: ll_temac: Fix support for 64-bit platforms")
fdd7454ecb29 ("net: ll_temac: Fix support for little-endian platforms")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/8] net: ll_temac: Fix RX buffer descriptor handling on GFP_ATOMIC pressure
From: Sasha Levin @ 2020-02-20 12:49 UTC (permalink / raw)
To: Sasha Levin, Esben Haabendal, netdev
Cc: stable, linux-kernel, linux-arm-kernel
In-Reply-To: <20200218082642.7288-1-esben@geanix.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.5.4, v5.4.20, v4.19.104, v4.14.171, v4.9.214, v4.4.214.
v5.5.4: Build OK!
v5.4.20: Build OK!
v4.19.104: Failed to apply! Possible dependencies:
73f7375d3ed6 ("net: ll_temac: Enable DMA when ready, not before")
7e97a194aca0 ("net: ll_temac: Allow configuration of IRQ coalescing")
8425c41d1ef7 ("net: ll_temac: Extend support to non-device-tree platforms")
a3246dc41aa3 ("net: ll_temac: Add support for non-native register endianness")
a63625d2a0e7 ("net: ll_temac: Fix and simplify error handling by using devres functions")
a8c9bd3ba840 ("net: ll_temac: Fix iommu/swiotlb leak")
d1441d4782f2 ("net: xilinx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles")
d84aec42151b ("net: ll_temac: Fix support for 64-bit platforms")
f14f5c11f051 ("net: ll_temac: Support indirect_mutex share within TEMAC IP")
fdd7454ecb29 ("net: ll_temac: Fix support for little-endian platforms")
v4.14.171: Failed to apply! Possible dependencies:
73f7375d3ed6 ("net: ll_temac: Enable DMA when ready, not before")
7e97a194aca0 ("net: ll_temac: Allow configuration of IRQ coalescing")
8425c41d1ef7 ("net: ll_temac: Extend support to non-device-tree platforms")
a3246dc41aa3 ("net: ll_temac: Add support for non-native register endianness")
a63625d2a0e7 ("net: ll_temac: Fix and simplify error handling by using devres functions")
a8c9bd3ba840 ("net: ll_temac: Fix iommu/swiotlb leak")
aa5848bc4043 ("net: emaclite: Simplify if-else statements")
d1441d4782f2 ("net: xilinx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles")
d84aec42151b ("net: ll_temac: Fix support for 64-bit platforms")
f14f5c11f051 ("net: ll_temac: Support indirect_mutex share within TEMAC IP")
fdd7454ecb29 ("net: ll_temac: Fix support for little-endian platforms")
v4.9.214: Failed to apply! Possible dependencies:
062054727654 ("net: ll_temac: Utilize of_get_mac_address()")
30c57f073449 ("net: ethernet: ti: cpsw: fix race condition during open()")
342fa1964439 ("mdio: mux: make child bus walking more permissive and errors more verbose")
7e97a194aca0 ("net: ll_temac: Allow configuration of IRQ coalescing")
8425c41d1ef7 ("net: ll_temac: Extend support to non-device-tree platforms")
9ad1a3749333 ("dpaa_eth: add support for DPAA Ethernet")
a3246dc41aa3 ("net: ll_temac: Add support for non-native register endianness")
a63625d2a0e7 ("net: ll_temac: Fix and simplify error handling by using devres functions")
f14f5c11f051 ("net: ll_temac: Support indirect_mutex share within TEMAC IP")
f7ce91038d52 ("net: Convert to using %pOF instead of full_name")
v4.4.214: Failed to apply! Possible dependencies:
062054727654 ("net: ll_temac: Utilize of_get_mac_address()")
158bc065f29c ("net: dsa: mv88e6xxx: replace ds with ps where possible")
31abbe34e0f0 ("net: ethernet: ll_temac: use phydev from struct net_device")
48ace4ef4c3f ("dsa: mv88e6xxx: Kill the REG_READ and REG_WRITE macros")
7543a6d5359e ("net: dsa: Have the switch driver allocate there own private memory")
7e97a194aca0 ("net: ll_temac: Allow configuration of IRQ coalescing")
8425c41d1ef7 ("net: ll_temac: Extend support to non-device-tree platforms")
893f83e6bcc3 ("ARM: mvebu: Reenable DSA in mvebu_v5_defconfig")
a1a6a4d1f76a ("net: dsa: mv88e6xxx: factorize switch setup")
a63625d2a0e7 ("net: ll_temac: Fix and simplify error handling by using devres functions")
a6cbc340d1e1 ("ARM: config: Reenable DSA in multi_v5_defconfig")
a77d43f1e9d5 ("net: dsa: Keep the mii bus and address in the private structure")
b516d4532395 ("net: dsa: mv88e6xxx: Refactor MDIO so driver registers mdio bus")
bbb8d793994c ("net: dsa: Pass the dsa device to the switch drivers")
ca3dfa51e67c ("dsa: Rename mv88e6123_61_65 to mv88e6123 to be consistent")
f7ce91038d52 ("net: Convert to using %pOF instead of full_name")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/8] net: ll_temac: Fix race condition causing TX hang
From: Sasha Levin @ 2020-02-20 12:49 UTC (permalink / raw)
To: Sasha Levin, Esben Haabendal, netdev
Cc: stable, linux-kernel, linux-arm-kernel
In-Reply-To: <20200218082619.7119-1-esben@geanix.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.5.4, v5.4.20, v4.19.104, v4.14.171, v4.9.214, v4.4.214.
v5.5.4: Build OK!
v5.4.20: Build OK!
v4.19.104: Failed to apply! Possible dependencies:
2c9938e738a2 ("net: ll_temac: Fix bug causing buffer descriptor overrun")
v4.14.171: Failed to apply! Possible dependencies:
2c9938e738a2 ("net: ll_temac: Fix bug causing buffer descriptor overrun")
v4.9.214: Failed to apply! Possible dependencies:
2c9938e738a2 ("net: ll_temac: Fix bug causing buffer descriptor overrun")
v4.4.214: Failed to apply! Possible dependencies:
2c9938e738a2 ("net: ll_temac: Fix bug causing buffer descriptor overrun")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/4] gpiolib: use kref in gpio_desc
From: Bartosz Golaszewski @ 2020-02-20 12:51 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Bartosz Golaszewski, Linus Walleij, Khouloud Touil,
Geert Uytterhoeven, linux-gpio, LKML
In-Reply-To: <5970b17a-b29b-154f-033e-6da007d6a289@linaro.org>
czw., 20 lut 2020 o 13:05 Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> napisał(a):
>
>
>
> On 20/02/2020 10:01, Bartosz Golaszewski wrote:
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -2798,6 +2798,8 @@ static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
> > goto done;
> > }
> >
> > + kref_init(&desc->ref);
> > +
>
> Should we not decrement refcount on the error path of this function?
>
On error the descriptor will still be unrequested so there's no point
in potentially calling gpiod_free(). Also: the next time someone
requests it and succeeds, we'll set it back to 1.
Bartosz
^ permalink raw reply
* Re: [Xen-devel] [PATCH V3] x86/altp2m: Hypercall to set altp2m view visibility
From: Alexandru Stefan ISAILA @ 2020-02-20 12:51 UTC (permalink / raw)
To: George Dunlap, xen-devel@lists.xenproject.org
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Jun Nakajima,
Wei Liu, Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper,
Ian Jackson, Jan Beulich, Roger Pau Monné
In-Reply-To: <d1c77b95-8607-fede-d4dc-ab99db74a014@citrix.com>
On 20.02.2020 14:21, George Dunlap wrote:
> On 2/19/20 9:18 AM, Alexandru Stefan ISAILA wrote:
>> At this moment a guest can call vmfunc to change the altp2m view. This
>> should be limited in order to avoid any unwanted view switch.
>>
>> The new xc_altp2m_set_visibility() solves this by making views invisible
>> to vmfunc.
>> This is done by having a separate arch.altp2m_working_eptp that is
>> populated and made invalid in the same places as altp2m_eptp. This is
>> written to EPTP_LIST_ADDR.
>> The views are made in/visible by marking them with INVALID_MFN or
>> copying them back from altp2m_eptp.
>> To have consistency the visibility also applies to
>> p2m_switch_domain_altp2m_by_id().
>
>
> So it looks like by default the views are visible, until they're made
> non-visible?
Yes, by default all the active views are visible until they're made
non-visible.
>
> Also, does the last line mean that the toolstack can't change to a
> "non-visible" altp2m either?
The last line means that xc_altp2m_switch_to_view() will not be able to
switch to a non-visible view.
-Alex
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [igt-dev] [PATCH i-g-t] tools/i915-perf: workaround overzelous compiler warnings
From: Lionel Landwerlin @ 2020-02-20 12:51 UTC (permalink / raw)
To: igt-dev
Give me a break :)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
---
tools/i915-perf/i915_perf_control.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/i915-perf/i915_perf_control.c b/tools/i915-perf/i915_perf_control.c
index a8d0d30f..dcbc2f59 100644
--- a/tools/i915-perf/i915_perf_control.c
+++ b/tools/i915-perf/i915_perf_control.c
@@ -95,10 +95,12 @@ main(int argc, char *argv[])
struct recorder_command_base base;
struct recorder_command_dump dump;
} *data = malloc(total_len);
+ char *path = (char *) data->dump.path;
data->base.command = RECORDER_COMMAND_DUMP;
data->base.size = total_len;
- snprintf((char *) data->dump.path, strlen(dump_file) + 1, "%s", dump_file);
+ snprintf(path, strlen(dump_file) + 1, "%s", dump_file);
+
fwrite(data, total_len, 1, command_fifo_file);
} else {
@@ -109,10 +111,11 @@ main(int argc, char *argv[])
struct recorder_command_base base;
struct recorder_command_dump dump;
} *data = malloc(total_len);
+ char *path = (char *) data->dump.path;
data->base.command = RECORDER_COMMAND_DUMP;
data->base.size = total_len;
- snprintf((char *) data->dump.path, path_len, "%s/%s", cwd, dump_file);
+ snprintf(path, path_len, "%s/%s", cwd, dump_file);
fwrite(data, total_len, 1, command_fifo_file);
}
--
2.25.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [meta-oe][PATCH] meta-oe: master: remmina - use PACKAGECONFIG for spice
From: Peter Kjellerstedt @ 2020-02-20 12:52 UTC (permalink / raw)
To: Jan-Simon Moeller, openembedded-devel@lists.openembedded.org
In-Reply-To: <20200219115654.25186-1-dl9pf@gmx.de>
> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org <openembedded-
> devel-bounces@lists.openembedded.org> On Behalf Of Jan-Simon Moeller
> Sent: den 19 februari 2020 12:57
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] [meta-oe][PATCH] meta-oe: master: remmina - use PACKAGECONFIG for spice
Change the subject to:
[meta-oe][PATCH] remmina: use PACKAGECONFIG for spice
The target layer and branch should be specified within [] as they are only
there for the review process. Typically you only prefix the Git commit
subject with "<recipe name>: " and then use, e.g., `git format-patch
--subject-prefix='meta-oe][master][PATCH' ...` to create the patch with the
appropriate prefixes.
> remmina depends on spice and spice-protocol but they are in meta-networking.
> Use the PACKAGECONFIG flag to avoid hardcoding the dependency.
>
> Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>
> ---
> meta-oe/recipes-support/remmina/remmina_1.3.6.bb | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/meta-oe/recipes-support/remmina/remmina_1.3.6.bb b/meta-oe/recipes-support/remmina/remmina_1.3.6.bb
> index f9963ff65..f9860a11f 100644
> --- a/meta-oe/recipes-support/remmina/remmina_1.3.6.bb
> +++ b/meta-oe/recipes-support/remmina/remmina_1.3.6.bb
> @@ -5,8 +5,6 @@ LICENSE = "GPLv2 & openssl"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=dab7215512044d49037272ce1ac4ea8f file://LICENSE.OpenSSL;md5=c1eb3cee0a4dea27503c531267a69769"
> DEPENDS += "openssl freerdp gtk+3 gdk-pixbuf atk libgcrypt avahi-ui libsodium libssh vte json-glib libsoup-2.4 libvncserver libsecret"
>
> -DEPENDS_append_x86 = " spice spice-protocol"
> -DEPENDS_append_x86-64 = " spice spice-protocol"
>
> DEPENDS_append_libc-musl = " libexecinfo"
> LDFLAGS_append_libc-musl = " -lexecinfo"
> @@ -23,11 +21,7 @@ inherit cmake features_check mime-xdg
> # depends on avahi-ui with this restriction
> ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
>
> -EXTRA_OECMAKE += "-DWITH_APPINDICATOR=OFF -DWITH_GETTEXT=OFF -DWITH_TRANSLATIONS=OFF -DWITH_SPICE=OFF"
> -
> -EXTRA_OECMAKE_append_x86 = " -DWITH_SPICE=ON"
> -EXTRA_OECMAKE_append_x86-64 = " -DWITH_SPICE=ON"
> -
> +EXTRA_OECMAKE += "-DWITH_APPINDICATOR=OFF -DWITH_GETTEXT=OFF -DWITH_TRANSLATIONS=OFF"
>
> do_install_append(){
> # We dont need the extra stuff form other desktop environments
> @@ -36,6 +30,8 @@ do_install_append(){
> rm -rf ${D}/${datadir}/gnome-session
> }
>
> +PACKAGECONFIG[spice] = "-DWITH_SPICE=ON, -DWITH_SPICE=OFF, spice spice-protocol"
> +
PACKAGECONFIGs are typically placed before inherit in the recipes.
> RDEPENDS_${PN} = "bash"
>
> FILES_${PN}_append = " ${datadir}/icons/hicolor/*"
> --
> 2.11.0
//Peter
^ permalink raw reply
* Applied "ASoC: dpcm: remove confusing trace in dpcm_get_be()" to the asoc tree
From: Mark Brown @ 2020-02-20 12:52 UTC (permalink / raw)
To: Jerome Brunet
Cc: alsa-devel, Kuninori Morimoto, Liam Girdwood, linux-kernel,
Mark Brown, Pierre-Louis Bossart
In-Reply-To: <20200219115048.934678-1-jbrunet@baylibre.com>
The patch
ASoC: dpcm: remove confusing trace in dpcm_get_be()
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 9d6ee3656a9fbfe906be5ce6f828f1639da1ee7f Mon Sep 17 00:00:00 2001
From: Jerome Brunet <jbrunet@baylibre.com>
Date: Wed, 19 Feb 2020 12:50:48 +0100
Subject: [PATCH] ASoC: dpcm: remove confusing trace in dpcm_get_be()
Now that dpcm_get_be() is used in dpcm_end_walk_at_be(), it is not a error
if this function does not find a BE for the provided widget. Remove the
related dev_err() trace which is confusing since things might be working
as expected.
When called from dpcm_add_paths(), it is an error if dpcm_get_be() fails to
find a BE for the provided widget. The necessary error trace is already
done in this case.
Fixes: 027a48387183 ("ASoC: soc-pcm: use dpcm_get_be() at dpcm_end_walk_at_be()")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200219115048.934678-1-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/soc-pcm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index 63f67eb7c077..aff27c8599ef 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -1270,9 +1270,7 @@ static struct snd_soc_pcm_runtime *dpcm_get_be(struct snd_soc_card *card,
}
}
- /* dai link name and stream name set correctly ? */
- dev_err(card->dev, "ASoC: can't get %s BE for %s\n",
- stream ? "capture" : "playback", widget->name);
+ /* Widget provided is not a BE */
return NULL;
}
--
2.20.1
^ permalink raw reply related
* [igt-dev] [PATCH i-g-t 2/2] intel-ci: Kernel selftest changes to fast-feedback and blacklist
From: Petri Latvala @ 2020-02-20 12:52 UTC (permalink / raw)
To: igt-dev; +Cc: Tomi Sarvela, Petri Latvala
In-Reply-To: <20200220125207.16423-1-petri.latvala@intel.com>
Now that selftest launchers are enumerable, we can control them with
fast-feedback.testlist and blacklist.txt. For now, apply the status
quo.
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
---
tests/intel-ci/blacklist.txt | 5 -----
tests/intel-ci/fast-feedback.testlist | 4 ++++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
index 51d0417c..390e4fa0 100644
--- a/tests/intel-ci/blacklist.txt
+++ b/tests/intel-ci/blacklist.txt
@@ -1,10 +1,5 @@
igt@meta_test(@.*)?
###############################################
-# Kernel selftests (run separately)
-###############################################
-igt@i915_selftest(@.*)?
-igt@drm_mm(@.*)?
-###############################################
# Handle module reloads with great care!
#
# Reloading a module is more likely to leave
diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist
index 1b00485e..b41fb4a0 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -171,3 +171,7 @@ igt@vgem_basic@sysfs
igt@vgem_basic@unload
igt@i915_module_load@reload
igt@i915_pm_rpm@module-reload
+
+# Kernel selftests
+igt@i915_selftest@live
+igt@dmabuf@all
--
2.20.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* [igt-dev] [PATCH i-g-t 1/2] lib: Update selftests to use dynamic subtests
From: Petri Latvala @ 2020-02-20 12:52 UTC (permalink / raw)
To: igt-dev; +Cc: Tomi Sarvela, Petri Latvala
From: Chris Wilson <chris@chris-wilson.co.uk>
Use the new igt_subtest_with_dynamic to nicely group the dynamic
subtests together.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
Acked-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
---
lib/igt_kmod.c | 23 +++++++++++++++++++----
tests/igt_command_line.sh | 9 ++-------
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index 05019c24..e701545d 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -21,6 +21,7 @@
* IN THE SOFTWARE.
*/
+#include <ctype.h>
#include <signal.h>
#include <errno.h>
@@ -602,6 +603,18 @@ void igt_kselftest_fini(struct igt_kselftest *tst)
kmod_module_unref(tst->kmod);
}
+static const char *unfilter(const char *filter, const char *name)
+{
+ if (!filter)
+ return name;
+
+ name += strlen(filter);
+ if (!isalpha(*name))
+ name++;
+
+ return name;
+}
+
void igt_kselftests(const char *module_name,
const char *options,
const char *result,
@@ -618,10 +631,12 @@ void igt_kselftests(const char *module_name,
igt_require(igt_kselftest_begin(&tst) == 0);
igt_kselftest_get_tests(tst.kmod, filter, &tests);
- igt_list_for_each_entry_safe(tl, tn, &tests, link) {
- igt_subtest_f("%s", tl->name)
- igt_kselftest_execute(&tst, tl, options, result);
- free(tl);
+ igt_subtest_with_dynamic(filter ?: "all") {
+ igt_list_for_each_entry_safe(tl, tn, &tests, link) {
+ igt_dynamic_f("%s", unfilter(filter, tl->name))
+ igt_kselftest_execute(&tst, tl, options, result);
+ free(tl);
+ }
}
igt_fixture {
diff --git a/tests/igt_command_line.sh b/tests/igt_command_line.sh
index 291b6526..5356877c 100755
--- a/tests/igt_command_line.sh
+++ b/tests/igt_command_line.sh
@@ -89,13 +89,8 @@ check_test ()
fi
if [ $RET -eq 0 -a -z "$LIST" ]; then
- # Subtest enumeration of kernel selftest launchers depends
- # on the running kernel. If selftests are not enabled,
- # they will output nothing and exit with 0.
- if [ "$testname" != "i915_selftest" -a "$testname" != "drm_mm" -a "$testname" != "kms_selftest" -a "$testname" != "dmabuf" ]; then
- echo " test does seem to be using igt_main() (should have subtests) and yet --list-subtests is empty!"
- fail $test
- fi
+ echo " test does seem to be using igt_main() (should have subtests) and yet --list-subtests is empty!"
+ fail $test
fi
}
--
2.20.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH 1/6] drm/i915/gt: Protect signaler walk with RCU
From: Chris Wilson @ 2020-02-20 12:52 UTC (permalink / raw)
To: Matthew Auld, intel-gfx
In-Reply-To: <a916179e-8f26-902d-5707-d6b85337e732@intel.com>
Quoting Matthew Auld (2020-02-20 12:47:28)
> On 20/02/2020 07:50, Chris Wilson wrote:
> > While we know that the waiters cannot disappear as we walk our list
> > (only that they might be added), the same cannot be said for our
> > signalers as they may be completed by the HW and retired as we process
> > this request. Ergo we need to use rcu to protect the list iteration and
> > remember to mark up the list_del_rcu.
> >
> > v2: Mark the deps as safe-for-rcu
> >
> > Fixes: 793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new waiters")
> > Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight requests")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++++++++++------
> > drivers/gpu/drm/i915/i915_scheduler.c | 7 ++++---
> > 2 files changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index ba31cbe8c68e..47561dc29304 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1668,9 +1668,9 @@ last_active(const struct intel_engine_execlists *execlists)
> > wait_link)
> >
> > #define for_each_signaler(p__, rq__) \
> > - list_for_each_entry_lockless(p__, \
> > - &(rq__)->sched.signalers_list, \
> > - signal_link)
> > + list_for_each_entry_rcu(p__, \
> > + &(rq__)->sched.signalers_list, \
> > + signal_link)
> >
> > static void defer_request(struct i915_request *rq, struct list_head * const pl)
> > {
> > @@ -2533,11 +2533,13 @@ static bool execlists_hold(struct intel_engine_cs *engine,
> > static bool hold_request(const struct i915_request *rq)
> > {
> > struct i915_dependency *p;
> > + bool result = false;
> >
> > /*
> > * If one of our ancestors is on hold, we must also be on hold,
> > * otherwise we will bypass it and execute before it.
> > */
> > + rcu_read_lock();
> > for_each_signaler(p, rq) {
> > const struct i915_request *s =
> > container_of(p->signaler, typeof(*s), sched);
> > @@ -2545,11 +2547,13 @@ static bool hold_request(const struct i915_request *rq)
> > if (s->engine != rq->engine)
> > continue;
> >
> > - if (i915_request_on_hold(s))
> > - return true;
> > + result = i915_request_on_hold(s);
> > + if (result)
> > + break;
> > }
> > + rcu_read_unlock();
> >
> > - return false;
> > + return result;
> > }
> >
> > static void __execlists_unhold(struct i915_request *rq)
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c
> > index e19a37a83397..59f70b674665 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > @@ -486,7 +486,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
> > list_for_each_entry_safe(dep, tmp, &node->signalers_list, signal_link) {
> > GEM_BUG_ON(!list_empty(&dep->dfs_link));
> >
> > - list_del(&dep->wait_link);
> > + list_del_rcu(&dep->wait_link);
> > if (dep->flags & I915_DEPENDENCY_ALLOC)
> > i915_dependency_free(dep);
> > }
> > @@ -497,7 +497,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
> > GEM_BUG_ON(dep->signaler != node);
> > GEM_BUG_ON(!list_empty(&dep->dfs_link));
> >
> > - list_del(&dep->signal_link);
> > + list_del_rcu(&dep->signal_link);
> > if (dep->flags & I915_DEPENDENCY_ALLOC)
> > i915_dependency_free(dep);
> > }
> > @@ -526,7 +526,8 @@ static struct i915_global_scheduler global = { {
> > int __init i915_global_scheduler_init(void)
> > {
> > global.slab_dependencies = KMEM_CACHE(i915_dependency,
> > - SLAB_HWCACHE_ALIGN);
> > + SLAB_HWCACHE_ALIGN |
> > + SLAB_TYPESAFE_BY_RCU);
>
> So, the claim is that we should be fine if the node is re-used and then
> initialised, even though there might exist a minuscule window where
> hold_request might still be able to see it, somehow?
Yes. That is my claim. The saving grace here is that for the on-hold
transitions we must go through the engine->active.lock which we are
holding. Ergo hold_request() is safe.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Applied "ASoC: dpcm: remove confusing trace in dpcm_get_be()" to the asoc tree
From: Mark Brown @ 2020-02-20 12:52 UTC (permalink / raw)
To: Jerome Brunet
Cc: alsa-devel, Kuninori Morimoto, linux-kernel, Pierre-Louis Bossart,
Liam Girdwood, Mark Brown
In-Reply-To: <20200219115048.934678-1-jbrunet@baylibre.com>
The patch
ASoC: dpcm: remove confusing trace in dpcm_get_be()
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 9d6ee3656a9fbfe906be5ce6f828f1639da1ee7f Mon Sep 17 00:00:00 2001
From: Jerome Brunet <jbrunet@baylibre.com>
Date: Wed, 19 Feb 2020 12:50:48 +0100
Subject: [PATCH] ASoC: dpcm: remove confusing trace in dpcm_get_be()
Now that dpcm_get_be() is used in dpcm_end_walk_at_be(), it is not a error
if this function does not find a BE for the provided widget. Remove the
related dev_err() trace which is confusing since things might be working
as expected.
When called from dpcm_add_paths(), it is an error if dpcm_get_be() fails to
find a BE for the provided widget. The necessary error trace is already
done in this case.
Fixes: 027a48387183 ("ASoC: soc-pcm: use dpcm_get_be() at dpcm_end_walk_at_be()")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200219115048.934678-1-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/soc-pcm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index 63f67eb7c077..aff27c8599ef 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -1270,9 +1270,7 @@ static struct snd_soc_pcm_runtime *dpcm_get_be(struct snd_soc_card *card,
}
}
- /* dai link name and stream name set correctly ? */
- dev_err(card->dev, "ASoC: can't get %s BE for %s\n",
- stream ? "capture" : "playback", widget->name);
+ /* Widget provided is not a BE */
return NULL;
}
--
2.20.1
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH 12/12] drm: pahole struct drm_display_mode
From: Emil Velikov @ 2020-02-20 12:53 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200219203544.31013-13-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Reorganize drm_display_mode to eliminate all the holes.
> We'll put all the actual timings to the start of the
> struct and all the extra junk to the end.
>
> Gets the size down to 136 bytes on 64bit and 120 bytes on
> 32bit. With a bit more work we should be able to get this
> below the two cacheline mark even on 64bit.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Patches 07-12 are:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 12/12] drm: pahole struct drm_display_mode
From: Emil Velikov @ 2020-02-20 12:53 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200219203544.31013-13-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Reorganize drm_display_mode to eliminate all the holes.
> We'll put all the actual timings to the start of the
> struct and all the extra junk to the end.
>
> Gets the size down to 136 bytes on 64bit and 120 bytes on
> 32bit. With a bit more work we should be able to get this
> below the two cacheline mark even on 64bit.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Patches 07-12 are:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Applied "ASoC: soc-core: fix for_rtd_codec_dai_rollback() macro" to the asoc tree
From: Mark Brown @ 2020-02-20 12:52 UTC (permalink / raw)
To: Pierre-Louis Bossart; +Cc: tiwai, alsa-devel, Mark Brown, Kuninori Morimoto
In-Reply-To: <20200219222130.29933-1-pierre-louis.bossart@linux.intel.com>
The patch
ASoC: soc-core: fix for_rtd_codec_dai_rollback() macro
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 63d68382f5fb5f71772357e31841c19c4a133182 Mon Sep 17 00:00:00 2001
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date: Wed, 19 Feb 2020 16:21:30 -0600
Subject: [PATCH] ASoC: soc-core: fix for_rtd_codec_dai_rollback() macro
The use of parentheses to protect the argument is fine for (i)++ but
not for (--i).
Fixes: 83f94a2e293d61 ("ASoC: soc-core: add snd_soc_close_delayed_work()")
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200219222130.29933-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
include/sound/soc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index f0e4f36f83bf..8a2266676b2d 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1157,7 +1157,7 @@ struct snd_soc_pcm_runtime {
((i) < rtd->num_codecs) && ((dai) = rtd->codec_dais[i]); \
(i)++)
#define for_each_rtd_codec_dai_rollback(rtd, i, dai) \
- for (; ((--i) >= 0) && ((dai) = rtd->codec_dais[i]);)
+ for (; (--(i) >= 0) && ((dai) = rtd->codec_dais[i]);)
void snd_soc_close_delayed_work(struct snd_soc_pcm_runtime *rtd);
--
2.20.1
^ permalink raw reply related
* Re: [Xen-devel] [PATCH v5 0/2] docs: Migration design documents
From: Durrant, Paul @ 2020-02-20 12:54 UTC (permalink / raw)
To: Durrant, Paul, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Jan Beulich
In-Reply-To: <20200213105325.3022-1-pdurrant@amazon.com>
Ping?
I have not receieved any further comments on v5. Can I please get acks or otherwise so we can (hopefully) move on with coding?
Paul
> -----Original Message-----
> From: Paul Durrant <pdurrant@amazon.com>
> Sent: 13 February 2020 10:53
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul <pdurrant@amazon.co.uk>; Andrew Cooper
> <andrew.cooper3@citrix.com>; George Dunlap <George.Dunlap@eu.citrix.com>;
> Ian Jackson <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>;
> Julien Grall <julien@xen.org>; Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>; Stefano Stabellini <sstabellini@kernel.org>; Wei
> Liu <wl@xen.org>
> Subject: [PATCH v5 0/2] docs: Migration design documents
>
> Paul Durrant (2):
> docs/designs: Add a design document for non-cooperative live migration
> docs/designs: Add a design document for migration of xenstore data
>
> docs/designs/non-cooperative-migration.md | 272 ++++++++++++++++++++++
> docs/designs/xenstore-migration.md | 136 +++++++++++
> 2 files changed, 408 insertions(+)
> create mode 100644 docs/designs/non-cooperative-migration.md
> create mode 100644 docs/designs/xenstore-migration.md
> ---
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: George Dunlap <George.Dunlap@eu.citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Wei Liu <wl@xen.org>
> --
> 2.20.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ 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.