* [PATCH v4 02/16] s390x: protvirt: Add diag308 subcodes 8 - 10
From: Janosch Frank @ 2020-02-20 12:56 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-s390x, mihajlov, david, cohuck
In-Reply-To: <20200220125638.7241-1-frankja@linux.ibm.com>
For diag308 subcodes 8 - 10 we have a new ipib of type 5. The ipib
holds the address and length of the secure execution header, as well
as a list of guest components.
Each component is a block of memory, for example kernel or initrd,
which needs to be decrypted by the Ultravisor in order to run a
protected VM. The secure execution header instructs the Ultravisor on
how to handle the protected VM and its components.
Subcodes 8 and 9 are similiar to 5 and 6 and subcode 10 will finally
start the protected guest.
Subcodes 8-10 are not valid in protected mode, we have to do a subcode
3 and then the 8 and 10 combination for a protected reboot.
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
---
hw/s390x/ipl.c | 48 ++++++++++++++++++++++++++++++++++++++++++---
hw/s390x/ipl.h | 31 +++++++++++++++++++++++++++++
target/s390x/diag.c | 27 ++++++++++++++++++++++---
3 files changed, 100 insertions(+), 6 deletions(-)
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index 7773499d7f..e92d989813 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -538,15 +538,56 @@ static bool is_virtio_scsi_device(IplParameterBlock *iplb)
return is_virtio_ccw_device_of_type(iplb, VIRTIO_ID_SCSI);
}
+int s390_ipl_pv_check_components(IplParameterBlock *iplb)
+{
+ int i;
+ IPLBlockPV *ipib_pv = &iplb->pv;
+
+ if (ipib_pv->num_comp == 0) {
+ return -EINVAL;
+ }
+
+ for (i = 0; i < ipib_pv->num_comp; i++) {
+
+ /* Addr must be 4k aligned */
+ if (ipib_pv->components[i].addr & ~TARGET_PAGE_MASK) {
+ return -EINVAL;
+ }
+
+ /* Tweak prefix is monotonously increasing with each component */
+ if (i < ipib_pv->num_comp - 1 &&
+ ipib_pv->components[i].tweak_pref >
+ ipib_pv->components[i + 1].tweak_pref) {
+ return -EINVAL;
+ }
+ }
+ return 1;
+}
+
void s390_ipl_update_diag308(IplParameterBlock *iplb)
{
S390IPLState *ipl = get_ipl_device();
- ipl->iplb = *iplb;
- ipl->iplb_valid = true;
+ if (iplb->pbt == S390_IPL_TYPE_PV) {
+ ipl->iplb_pv = *iplb;
+ ipl->iplb_valid_pv = true;
+ } else {
+ ipl->iplb = *iplb;
+ ipl->iplb_valid = true;
+ }
ipl->netboot = is_virtio_net_device(iplb);
}
+IplParameterBlock *s390_ipl_get_iplb_secure(void)
+{
+ S390IPLState *ipl = get_ipl_device();
+
+ if (!ipl->iplb_valid_pv) {
+ return NULL;
+ }
+ return &ipl->iplb_pv;
+}
+
IplParameterBlock *s390_ipl_get_iplb(void)
{
S390IPLState *ipl = get_ipl_device();
@@ -561,7 +602,8 @@ void s390_ipl_reset_request(CPUState *cs, enum s390_reset reset_type)
{
S390IPLState *ipl = get_ipl_device();
- if (reset_type == S390_RESET_EXTERNAL || reset_type == S390_RESET_REIPL) {
+ if (reset_type == S390_RESET_EXTERNAL || reset_type == S390_RESET_REIPL ||
+ reset_type == S390_RESET_PV) {
/* use CPU 0 for full resets */
ipl->reset_cpu_index = 0;
} else {
diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
index d4813105db..3c4bb66eda 100644
--- a/hw/s390x/ipl.h
+++ b/hw/s390x/ipl.h
@@ -15,6 +15,23 @@
#include "cpu.h"
#include "hw/qdev-core.h"
+struct IPLBlockPVComp {
+ uint64_t tweak_pref;
+ uint64_t addr;
+ uint64_t size;
+} QEMU_PACKED;
+typedef struct IPLBlockPVComp IPLBlockPVComp;
+
+struct IPLBlockPV {
+ uint8_t reserved[87];
+ uint8_t version;
+ uint32_t num_comp;
+ uint64_t pv_header_addr;
+ uint64_t pv_header_len;
+ struct IPLBlockPVComp components[];
+} QEMU_PACKED;
+typedef struct IPLBlockPV IPLBlockPV;
+
struct IplBlockCcw {
uint8_t reserved0[85];
uint8_t ssid;
@@ -71,6 +88,7 @@ union IplParameterBlock {
union {
IplBlockCcw ccw;
IplBlockFcp fcp;
+ IPLBlockPV pv;
IplBlockQemuScsi scsi;
};
} QEMU_PACKED;
@@ -84,9 +102,11 @@ union IplParameterBlock {
typedef union IplParameterBlock IplParameterBlock;
int s390_ipl_set_loadparm(uint8_t *loadparm);
+int s390_ipl_pv_check_components(IplParameterBlock *iplb);
void s390_ipl_update_diag308(IplParameterBlock *iplb);
void s390_ipl_prepare_cpu(S390CPU *cpu);
IplParameterBlock *s390_ipl_get_iplb(void);
+IplParameterBlock *s390_ipl_get_iplb_secure(void);
enum s390_reset {
/* default is a reset not triggered by a CPU e.g. issued by QMP */
@@ -94,6 +114,7 @@ enum s390_reset {
S390_RESET_REIPL,
S390_RESET_MODIFIED_CLEAR,
S390_RESET_LOAD_NORMAL,
+ S390_RESET_PV,
};
void s390_ipl_reset_request(CPUState *cs, enum s390_reset reset_type);
void s390_ipl_get_reset_request(CPUState **cs, enum s390_reset *reset_type);
@@ -133,6 +154,7 @@ struct S390IPLState {
/*< private >*/
DeviceState parent_obj;
IplParameterBlock iplb;
+ IplParameterBlock iplb_pv;
QemuIplParameters qipl;
uint64_t start_addr;
uint64_t compat_start_addr;
@@ -140,6 +162,7 @@ struct S390IPLState {
uint64_t compat_bios_start_addr;
bool enforce_bios;
bool iplb_valid;
+ bool iplb_valid_pv;
bool netboot;
/* reset related properties don't have to be migrated or reset */
enum s390_reset reset_type;
@@ -161,9 +184,11 @@ QEMU_BUILD_BUG_MSG(offsetof(S390IPLState, iplb) & 3, "alignment of iplb wrong");
#define S390_IPL_TYPE_FCP 0x00
#define S390_IPL_TYPE_CCW 0x02
+#define S390_IPL_TYPE_PV 0x05
#define S390_IPL_TYPE_QEMU_SCSI 0xff
#define S390_IPLB_HEADER_LEN 8
+#define S390_IPLB_MIN_PV_LEN 148
#define S390_IPLB_MIN_CCW_LEN 200
#define S390_IPLB_MIN_FCP_LEN 384
#define S390_IPLB_MIN_QEMU_SCSI_LEN 200
@@ -185,4 +210,10 @@ static inline bool iplb_valid_fcp(IplParameterBlock *iplb)
iplb->pbt == S390_IPL_TYPE_FCP;
}
+static inline bool iplb_valid_pv(IplParameterBlock *iplb)
+{
+ return be32_to_cpu(iplb->len) >= S390_IPLB_MIN_PV_LEN &&
+ iplb->pbt == S390_IPL_TYPE_PV;
+}
+
#endif
diff --git a/target/s390x/diag.c b/target/s390x/diag.c
index b5aec06d6b..5e77d85652 100644
--- a/target/s390x/diag.c
+++ b/target/s390x/diag.c
@@ -52,6 +52,8 @@ int handle_diag_288(CPUS390XState *env, uint64_t r1, uint64_t r3)
#define DIAG_308_RC_OK 0x0001
#define DIAG_308_RC_NO_CONF 0x0102
#define DIAG_308_RC_INVALID 0x0402
+#define DIAG_308_RC_NO_PV_CONF 0x0a02
+#define DIAG_308_RC_INVAL_FOR_PV 0x0b02
#define DIAG308_RESET_MOD_CLR 0
#define DIAG308_RESET_LOAD_NORM 1
@@ -59,6 +61,9 @@ int handle_diag_288(CPUS390XState *env, uint64_t r1, uint64_t r3)
#define DIAG308_LOAD_NORMAL_DUMP 4
#define DIAG308_SET 5
#define DIAG308_STORE 6
+#define DIAG308_PV_SET 8
+#define DIAG308_PV_STORE 9
+#define DIAG308_PV_START 10
static int diag308_parm_check(CPUS390XState *env, uint64_t r1, uint64_t addr,
uintptr_t ra, bool write)
@@ -105,6 +110,7 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
s390_ipl_reset_request(cs, S390_RESET_REIPL);
break;
case DIAG308_SET:
+ case DIAG308_PV_SET:
if (diag308_parm_check(env, r1, addr, ra, false)) {
return;
}
@@ -117,7 +123,8 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
- if (!iplb_valid_ccw(iplb) && !iplb_valid_fcp(iplb)) {
+ if (!iplb_valid_ccw(iplb) && !iplb_valid_fcp(iplb) &&
+ !(iplb_valid_pv(iplb) && s390_ipl_pv_check_components(iplb) >= 0)) {
env->regs[r1 + 1] = DIAG_308_RC_INVALID;
goto out;
}
@@ -128,17 +135,31 @@ out:
g_free(iplb);
return;
case DIAG308_STORE:
+ case DIAG308_PV_STORE:
if (diag308_parm_check(env, r1, addr, ra, true)) {
return;
}
- iplb = s390_ipl_get_iplb();
+ 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 {
env->regs[r1 + 1] = DIAG_308_RC_NO_CONF;
}
- return;
+ break;
+ case DIAG308_PV_START:
+ iplb = s390_ipl_get_iplb_secure();
+ if (!iplb || !iplb_valid_pv(iplb)) {
+ env->regs[r1 + 1] = DIAG_308_RC_NO_PV_CONF;
+ return;
+ }
+
+ s390_ipl_reset_request(cs, S390_RESET_PV);
+ break;
default:
s390_program_interrupt(env, PGM_SPECIFICATION, ra);
break;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 11/19] afs: Support fsinfo() [ver #16]
From: David Howells @ 2020-02-20 12:58 UTC (permalink / raw)
To: Jann Horn
Cc: dhowells, Al Viro, raven, Miklos Szeredi, Christian Brauner,
Linux API, linux-fsdevel, kernel list
In-Reply-To: <CAG48ez0fsB_XTmNfE-2tuabH7JHyQdih8bu7Qwu9HGWJXti7tQ@mail.gmail.com>
Jann Horn <jannh@google.com> wrote:
> Ewww. So basically, having one static set of .fsinfo_attributes is not
> sufficiently flexible for everyone, but instead of allowing the
> filesystem to dynamically provide a list of supported attributes, you
> just duplicate the super_operations? Seems to me like it'd be cleaner
> to add a function pointer to the super_operations that can dynamically
> fill out the supported fsinfo attributes.
>
> It seems to me like the current API is going to be a dead end if you
> ever want to have decent passthrough of these things for e.g. FUSE, or
> overlayfs, or VirtFS?
Ummm...
Would it be sufficient to have a function that returns a list of attributes?
Or does it need to be able to call to vfs_do_fsinfo() if it supports an
attribute?
There are two things I want to be able to do:
(1) Do the buffer wrangling in the core - which means the core needs to see
the type of the attribute. That's fine if, say, afs_fsinfo() can call
vfs_do_fsinfo() with the definition for any attribute it wants to handle
and, say, return -ENOPKG otherways so that the core can then fall back to
its private list.
(2) Be able to retrieve the list of attributes and/or query an attribute.
Now, I can probably manage this even through the same interface. If,
say, seeing FSINFO_ATTR_FSINFO_ATTRIBUTES causes the handler to simply
append on the IDs of its own supported attributes (a helper can be
provided for that).
If it sees FSINFO_ATR_FSINFO_ATTRIBUTE_INFO, it can just look to see if
it has the attribute with the ID matching Nth and return that, else
ENOPKG - again a helper could be provided.
Chaining through overlayfs gets tricky. You end up with multiple contributory
filesystems with different properties - and any one of those layers could
perhaps be another overlay. Overlayfs would probably needs to integrate the
info and derive the lowest common set.
David
^ permalink raw reply
* [PATCH v4 00/16] s390x: Protected Virtualization support
From: Janosch Frank @ 2020-02-20 12:56 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-s390x, mihajlov, david, cohuck
Most of the QEMU changes for PV are related to the new IPL type with
subcodes 8 - 10 and the execution of the necessary Ultravisor calls to
IPL secure guests. Note that we can only boot into secure mode from
normal mode, i.e. stfle 161 is not active in secure mode.
The other changes related to data gathering for emulation and
disabling addressing checks in secure mode, as well as CPU resets.
v4:
* Dropped reset patches which are already picked up
* Sync with KVM changes
* Review changes
V3:
* Use dedicated functions to access SIDA
* Smaller cleanups and segfault fixes
* Error reporting for Ultravisor calls
* Inject of RC of diag308 subcode 10 fails
V2:
* Split out cleanups
* Internal PV state tracking
* Review feedback
Christian Borntraeger (1):
s390x: Add unpack feature to GA1
Janosch Frank (15):
Sync pv
s390x: protvirt: Add diag308 subcodes 8 - 10
s390x: protvirt: Support unpack facility
s390x: protvirt: Add migration blocker
s390x: protvirt: Handle diag 308 subcodes 0,1,3,4
s390x: protvirt: KVM intercept changes
s390x: Add SIDA memory ops
s390x: protvirt: Move STSI data over SIDAD
s390x: protvirt: SCLP interpretation
s390x: protvirt: Set guest IPL PSW
s390x: protvirt: Move diag 308 data over SIDAD
s390x: protvirt: Disable address checks for PV guest IO emulation
s390x: protvirt: Move IO control structures over SIDA
s390x: protvirt: Handle SIGP store status correctly
docs: Add protvirt docs
docs/protvirt.rst | 53 +++++++++++
hw/s390x/Makefile.objs | 1 +
hw/s390x/ipl.c | 81 ++++++++++++++++-
hw/s390x/ipl.h | 33 +++++++
hw/s390x/pv.c | 106 ++++++++++++++++++++++
hw/s390x/pv.h | 34 +++++++
hw/s390x/s390-virtio-ccw.c | 135 +++++++++++++++++++++++++++-
hw/s390x/sclp.c | 17 ++++
include/hw/s390x/s390-virtio-ccw.h | 1 +
include/hw/s390x/sclp.h | 2 +
linux-headers/linux/kvm.h | 48 +++++++++-
target/s390x/cpu.c | 27 ++++--
target/s390x/cpu.h | 8 +-
target/s390x/cpu_features_def.inc.h | 1 +
target/s390x/diag.c | 61 ++++++++++---
target/s390x/gen-features.c | 1 +
target/s390x/helper.c | 4 +
target/s390x/ioinst.c | 113 ++++++++++++++++-------
target/s390x/kvm.c | 54 ++++++++++-
target/s390x/kvm_s390x.h | 2 +
target/s390x/mmu_helper.c | 9 ++
target/s390x/sigp.c | 1 +
22 files changed, 726 insertions(+), 66 deletions(-)
create mode 100644 docs/protvirt.rst
create mode 100644 hw/s390x/pv.c
create mode 100644 hw/s390x/pv.h
--
2.20.1
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t] tools/i915-perf: workaround overzelous compiler warnings
From: Petri Latvala @ 2020-02-20 12:58 UTC (permalink / raw)
To: Lionel Landwerlin; +Cc: igt-dev
In-Reply-To: <20200220125152.1188880-1-lionel.g.landwerlin@intel.com>
On Thu, Feb 20, 2020 at 02:51:52PM +0200, Lionel Landwerlin wrote:
> 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);
> +
Same warning still. My compiler is clever enough to see that even with
another pointer indirection, the area pointed at is an array of 0
elements.
--
Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* [Xen-devel] [xen-unstable-smoke test] 147354: tolerable all pass - PUSHED
From: osstest service owner @ 2020-02-20 12:58 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147354 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147354/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
version targeted for testing:
xen 6e0b445ee738cd829ed28c7532cded8afe25886d
baseline version:
xen 5872c83b42c60801a2bfcd1800a56bbb8fc13400
Last test of basis 147308 2020-02-19 16:08:08 Z 0 days
Testing same since 147354 2020-02-20 11:01:37 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-libvirt pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
To xenbits.xen.org:/home/xen/git/xen.git
5872c83b42..6e0b445ee7 6e0b445ee738cd829ed28c7532cded8afe25886d -> smoke
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v7] erofs-utils: introduce exclude dirs and files
From: Li GuiFu via Linux-erofs @ 2020-02-20 12:57 UTC (permalink / raw)
To: Gao Xiang; +Cc: linux-erofs, David Michael
In-Reply-To: <20200219022056.GA56477@architecture4>
On 2020/2/19 10:20, Gao Xiang wrote:
> Hi Guifu,
>
> On Tue, Feb 18, 2020 at 10:30:47PM +0800, Li Guifu wrote:
>> From: Li GuiFu <bluce.lee@aliyun.com>
>>
>> Add excluded file feature "--exclude-path=" and '--exclude-regex=',
>> which can be used to build EROFS image without some user specific
>> files or dirs. Note that you may give multiple '--exclude-path'
>> or '--exclude-regex' options.
>>
>> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
>> Signed-off-by: Li Guifu <bluce.lee@aliyun.com>
>
> Applied to experimental branch with the following minor updates.
>
> If you have more suggestions, please kindly point out. Or I will
> push it out to dev branch later.
>
> Thanks,
> Gao Xiang
>
It looks good
^ permalink raw reply
* Re: [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP)
From: Allan W. Nielsen @ 2020-02-20 12:58 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Horatiu Vultur, linux-kernel, netdev, bridge, jiri, ivecera,
davem, roopa, anirudh.venkataramanan, olteanv, andrew,
jeffrey.t.kirsher, UNGLinuxDriver
In-Reply-To: <3afba55f-f953-7aaa-8425-14777db1b27d@cumulusnetworks.com>
Hi Nik,
On 20.02.2020 12:48, Nikolay Aleksandrov wrote:
> In light of all the discussions and details that were explained, and as you've
> noted above, I think more code should be put in kernel space at the very least
> the performance/latency critical parts would benefit from being executed in the
> kernel (kind of control/data-plane separation). It seems from the switchdev calls there's
> a minimal state working set which define the behaviour and can be used to make
> decisions (similar to STP) in the kernel, but the complex logic how to set them can be
> executed in user-space meaning that maybe these hw-offload calls can have a simple SW
> fallback logic based on their current values. I think it is worth considering if this can
> be achieved before going to full in-kernel implementation of the state machine.
> Since you intend to hw-offload it then putting in some SW fallback logic would be good
> when the HW can't offload everything, what you suggest above also sounds good to me and
> I think you'll have to extend mdb and the multicast code to do it, but IIRC you already
> have code to do that based on previous discussions.
Sounds good. We will continue working on defining a good control/data-plane separation
and only keep the data-plane in the kernel. Also it seems that we agree that the SW fallback
of the data-plane should stay in the kernel - we will do that.
> As was already suggested you can put the MRP options in the bridge's options and
> process them from the bridge netlink code, that should simplify your code.
I'm okay with this.
The main argument I see for creating a seperate MRP netlink interface
instead of extending the bridge, is that MRP is properly not the last
bridge protocol we will want to work on.
To complete the MRP-2018 implementation, we will also need some CFM
support (defined in 802.1Qag or the latest version of 802.1Q). And
furhter out we will properly want to implement the full CFM protocol.
DLR may also be relevant at some point, and there may be other.
My main point is, that at some point we will properly want to do
seperate NETLINK interfaces for this. Not sure if that is now or later.
> You could also make the port's "mrp_aware" bool into an internal port
> flag (use net_bridge_port's flags field) so it can be quickly tested
> and in a hot cache line.
Good point, we will do that.
/Allan
^ permalink raw reply
* Re: [Bridge] [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP)
From: Allan W. Nielsen @ 2020-02-20 12:58 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: ivecera, andrew, jiri, netdev, roopa, bridge, linux-kernel, davem,
UNGLinuxDriver, anirudh.venkataramanan, jeffrey.t.kirsher,
olteanv, Horatiu Vultur
In-Reply-To: <3afba55f-f953-7aaa-8425-14777db1b27d@cumulusnetworks.com>
Hi Nik,
On 20.02.2020 12:48, Nikolay Aleksandrov wrote:
> In light of all the discussions and details that were explained, and as you've
> noted above, I think more code should be put in kernel space at the very least
> the performance/latency critical parts would benefit from being executed in the
> kernel (kind of control/data-plane separation). It seems from the switchdev calls there's
> a minimal state working set which define the behaviour and can be used to make
> decisions (similar to STP) in the kernel, but the complex logic how to set them can be
> executed in user-space meaning that maybe these hw-offload calls can have a simple SW
> fallback logic based on their current values. I think it is worth considering if this can
> be achieved before going to full in-kernel implementation of the state machine.
> Since you intend to hw-offload it then putting in some SW fallback logic would be good
> when the HW can't offload everything, what you suggest above also sounds good to me and
> I think you'll have to extend mdb and the multicast code to do it, but IIRC you already
> have code to do that based on previous discussions.
Sounds good. We will continue working on defining a good control/data-plane separation
and only keep the data-plane in the kernel. Also it seems that we agree that the SW fallback
of the data-plane should stay in the kernel - we will do that.
> As was already suggested you can put the MRP options in the bridge's options and
> process them from the bridge netlink code, that should simplify your code.
I'm okay with this.
The main argument I see for creating a seperate MRP netlink interface
instead of extending the bridge, is that MRP is properly not the last
bridge protocol we will want to work on.
To complete the MRP-2018 implementation, we will also need some CFM
support (defined in 802.1Qag or the latest version of 802.1Q). And
furhter out we will properly want to implement the full CFM protocol.
DLR may also be relevant at some point, and there may be other.
My main point is, that at some point we will properly want to do
seperate NETLINK interfaces for this. Not sure if that is now or later.
> You could also make the port's "mrp_aware" bool into an internal port
> flag (use net_bridge_port's flags field) so it can be quickly tested
> and in a hot cache line.
Good point, we will do that.
/Allan
^ permalink raw reply
* [PATCH] ASoC: samsung: Update dependencies for Arizona machine drivers
From: Charles Keepax @ 2020-02-20 12:56 UTC (permalink / raw)
To: broonie; +Cc: alsa-devel, sbkim73, patches, rdunlap, lgirdwood, s.nawrocki
Currently it is possible to get the following bad config:
WARNING: unmet direct dependencies detected for SND_SOC_WM5110
Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && MFD_WM5110 [=n]
commit ea00d95200d0 ("ASoC: Use imply for SND_SOC_ALL_CODECS")
commit d8dd3f92a6ba ("ASoC: Fix SND_SOC_ALL_CODECS imply misc fallout")
After these two patches the machine drivers still selects the
SND_SOC_WM5110 symbol which doesn't take account of the dependency
added on the MFD_WM5110 symbol, fix this by also adding a dependency on
MFD_WM5110 itself.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
---
sound/soc/samsung/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 1a0b163ca47b5..112911dc271ba 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -151,7 +151,7 @@ config SND_SOC_TOBERMORY
config SND_SOC_BELLS
tristate "Audio support for Wolfson Bells"
- depends on MFD_ARIZONA && I2C && SPI_MASTER
+ depends on MFD_ARIZONA && MFD_WM5102 && MFD_WM5110 && I2C && SPI_MASTER
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM5102
@@ -204,7 +204,7 @@ config SND_SOC_ARNDALE
config SND_SOC_SAMSUNG_TM2_WM5110
tristate "SoC I2S Audio support for WM5110 on TM2 board"
- depends on SND_SOC_SAMSUNG && MFD_ARIZONA && I2C && SPI_MASTER
+ depends on SND_SOC_SAMSUNG && MFD_ARIZONA && MFD_WM5110 && I2C && SPI_MASTER
depends on GPIOLIB || COMPILE_TEST
select SND_SOC_MAX98504
select SND_SOC_WM5110
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] vsprintf: sanely handle NULL passed to %pe
From: Petr Mladek @ 2020-02-20 12:57 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Ilya Dryomov, Steven Rostedt, Sergey Senozhatsky, Andy Shevchenko,
Jonathan Corbet, Kees Cook, Tobin C . Harding, Linus Torvalds,
linux-doc, LKML
In-Reply-To: <bcfb2f94-e7a8-0860-86e3-9fc866d98742@rasmusvillemoes.dk>
On Wed 2020-02-19 16:40:08, Rasmus Villemoes wrote:
> On 19/02/2020 15.45, Petr Mladek wrote:
> > On Wed 2020-02-19 14:56:32, Rasmus Villemoes wrote:
> >> On 19/02/2020 14.48, Petr Mladek wrote:
> >>> On Wed 2020-02-19 12:53:22, Rasmus Villemoes wrote:
> >>>> --- a/lib/vsprintf.c
> >>>> +++ b/lib/vsprintf.c
> >>> The test should go into null_pointer() instead of errptr().
> >>
> >> Eh, no, the behaviour of %pe is tested by errptr(). I'll keep it that
> >> way. But I should add a #else section that tests how %pe behaves without
> >> CONFIG_SYMBOLIC_ERRNAME - though that's orthogonal to this patch.
> >
> > OK, we should agree on some structure first.
> >
> > We already have two top level functions that test how a particular
> > pointer is printed using different pointer modifiers:
> >
> > null_pointer(); -> NULL with %p, %pX, %pE
> > invalid_pointer(); -> random pointer with %p, %pX, %pE
> >
> > Following this logic, errptr() should test how a pointer from IS_ERR() range
> > is printed using different pointer formats.
>
> Oh please. I wrote test_printf.c originally and structured it with one
> helper for each %p<whatever>. How are your additions null_pointer and
> invalid_pointer good examples for what the existing style is?
I see, I was the one who broke the style. Please, find below a patch
that tries to fix it. If you agree with the approach then I could
split it into smaller steps.
Also it would make sense to add checks for NULL and ERR pointer
into each existing %p modifier check. It will make sure that
check_pointer() is called in all handlers.
> So yeah, I'm going to continue testing the behaviour of %pe in errptr, TYVM.
OK.
> >>>> BTW., your original patch for %p lacks corresponding update of
> >>>> test_vsprintf.c. Please add appropriate test cases.
> >>>
> >>> diff --git a/lib/test_printf.c b/lib/test_printf.c
> >>> index 2d9f520d2f27..1726a678bccd 100644
> >>> --- a/lib/test_printf.c
> >>> +++ b/lib/test_printf.c
> >>> @@ -333,7 +333,7 @@ test_hashed(const char *fmt, const void *p)
> >>> static void __init
> >>> null_pointer(void)
> >>> {
> >>> - test_hashed("%p", NULL);
> >>> + test(ZEROS "00000000", "%p", NULL);
> >>
> >> No, it most certainly also needs to check a few "%p", ERR_PTR(-4) cases
> >> (where one of course has to use explicit integers and not E* constants).
> >
> > Yes, it would be great to add checks for %p, %px for IS_ERR() range.
> > But it is different story. The above change is for the original patch
> > and it was about NULL pointer handling.
>
> Wrong. The original patch (i.e. Ilya's) had subject "vsprintf: don't
> obfuscate NULL and error pointers" and did
>
> + if (IS_ERR_OR_NULL(ptr))
>
> so the tests that should be part of that patch very much need to cover
> both NULL and ERR_PTRs passed to plain %p.
Grr, I see. I was too fast yesterday. OK, I suggest to fix the
structure of the tests first. All these patches are for 5.7
anyway.
Here is the proposed clean up:
From 855909f2a1945d3a5bf490ddf4f2cca775ef967b Mon Sep 17 00:00:00 2001
From: Petr Mladek <pmladek@suse.com>
Date: Thu, 20 Feb 2020 12:53:43 +0100
Subject: [PATCH] lib/test_printf: Clean up basic pointer testing
The pointer testing has been originally split by the %p modifiers,
for example, the function dentry() tested %pd and %pD handling.
There were recently added tests that do not really fit into
the existing structure, namely:
+ hashed pointers tested by a maze of functions
+ null and invalid pointer handling with various modifiers
The hash pointer test is really special because the hash depends
on a random key that is generated during boot. Though, it is
still possible to check some aspects:
+ output string length
+ hash differs from the original pointer value
+ top half bites are zeroed on 64-bit systems
Let's put all these checks into test_hashed() function that has
the same behavior as the test() functions for well-defined output.
It increments the number of tests and eventual failures. It prints
warnings/errors when some aspects of the output are not as expected.
Most of these checks were there even before. The only addition is
the check whether hash differs from the original pointer value.
There is a small chance of a false error. It might be reduced
by checking more pointers but let's keep it simple for now.
The existing null_pointer() and invalid_pointer() checks are
newly split per-format modifier. And there is also fixed
difference between invalid pointer in the IS_ERR() range
and invalid pointer that looks like a valid one.
The invalid pointer Oxdeaddead00000000 should work on most
architectures. But I am not able to check it everywhere.
So there is a small chance of a false error. It might get
fixed when anyone reports a problem.
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
lib/test_printf.c | 162 ++++++++++++++++++++----------------------------------
1 file changed, 59 insertions(+), 103 deletions(-)
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 2d9f520d2f27..4e89b508def6 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -206,146 +206,101 @@ test_string(void)
}
#define PLAIN_BUF_SIZE 64 /* leave some space so we don't oops */
+#define PTR_ERROR ERR_PTR(-EFAULT)
+#define PTR_VAL_ERROR "fffffff2"
#if BITS_PER_LONG == 64
#define PTR_WIDTH 16
#define PTR ((void *)0xffff0123456789abUL)
#define PTR_STR "ffff0123456789ab"
+#define PTR_INVALID ((void *)0xdeaddead000000ab)
+#define PTR_VAL_INVALID "deaddead000000ab"
#define PTR_VAL_NO_CRNG "(____ptrval____)"
+#define ONES "ffffffff" /* hex 32 one bits */
#define ZEROS "00000000" /* hex 32 zero bits */
-static int __init
-plain_format(void)
-{
- char buf[PLAIN_BUF_SIZE];
- int nchars;
-
- nchars = snprintf(buf, PLAIN_BUF_SIZE, "%p", PTR);
-
- if (nchars != PTR_WIDTH)
- return -1;
-
- if (strncmp(buf, PTR_VAL_NO_CRNG, PTR_WIDTH) == 0) {
- pr_warn("crng possibly not yet initialized. plain 'p' buffer contains \"%s\"",
- PTR_VAL_NO_CRNG);
- return 0;
- }
-
- if (strncmp(buf, ZEROS, strlen(ZEROS)) != 0)
- return -1;
-
- return 0;
-}
-
#else
#define PTR_WIDTH 8
#define PTR ((void *)0x456789ab)
#define PTR_STR "456789ab"
+#define PTR_INVALID ((void *)0x000000ab)
+#define PTR_VAL_INVALID "000000ab"
#define PTR_VAL_NO_CRNG "(ptrval)"
+#define ONES ""
#define ZEROS ""
-static int __init
-plain_format(void)
-{
- /* Format is implicitly tested for 32 bit machines by plain_hash() */
- return 0;
-}
-
#endif /* BITS_PER_LONG == 64 */
-static int __init
-plain_hash_to_buffer(const void *p, char *buf, size_t len)
+static void __init
+test_hashed(const char *fmt, const void *p)
{
+ char pointer[PLAIN_BUF_SIZE];
+ char hash[PLAIN_BUF_SIZE];
int nchars;
- nchars = snprintf(buf, len, "%p", p);
-
- if (nchars != PTR_WIDTH)
- return -1;
+ total_tests++;
- if (strncmp(buf, PTR_VAL_NO_CRNG, PTR_WIDTH) == 0) {
- pr_warn("crng possibly not yet initialized. plain 'p' buffer contains \"%s\"",
- PTR_VAL_NO_CRNG);
- return 0;
+ nchars = snprintf(pointer, sizeof(pointer), "%px", p);
+ if (nchars != PTR_WIDTH) {
+ pr_err("error in test suite: vsprintf(\"%%px\", p) returned number of characters %d, expected %d\n",
+ nchars, PTR_WIDTH);
+ goto err;
}
- return 0;
-}
-
-static int __init
-plain_hash(void)
-{
- char buf[PLAIN_BUF_SIZE];
- int ret;
-
- ret = plain_hash_to_buffer(PTR, buf, PLAIN_BUF_SIZE);
- if (ret)
- return ret;
-
- if (strncmp(buf, PTR_STR, PTR_WIDTH) == 0)
- return -1;
-
- return 0;
-}
-
-/*
- * We can't use test() to test %p because we don't know what output to expect
- * after an address is hashed.
- */
-static void __init
-plain(void)
-{
- int err;
-
- err = plain_hash();
- if (err) {
- pr_warn("plain 'p' does not appear to be hashed\n");
- failed_tests++;
- return;
+ nchars = snprintf(hash, sizeof(hash), fmt, p);
+ if (nchars != PTR_WIDTH) {
+ pr_warn("vsprintf(\"%s\", p) returned number of characters %d, expected %d\n",
+ fmt, nchars, PTR_WIDTH);
+ goto err;
}
- err = plain_format();
- if (err) {
- pr_warn("hashing plain 'p' has unexpected format\n");
- failed_tests++;
+ if (strncmp(hash, PTR_VAL_NO_CRNG, PTR_WIDTH) == 0) {
+ pr_warn_once("crng possibly not yet initialized. vsprinf(\"%s\", p) printed \"%s\"",
+ fmt, hash);
+ total_tests--;
+ return;
}
-}
-
-static void __init
-test_hashed(const char *fmt, const void *p)
-{
- char buf[PLAIN_BUF_SIZE];
- int ret;
/*
- * No need to increase failed test counter since this is assumed
- * to be called after plain().
+ * There is a small chance of a false negative on 32-bit systems
+ * when the hash is the same as the pointer value.
*/
- ret = plain_hash_to_buffer(p, buf, PLAIN_BUF_SIZE);
- if (ret)
- return;
+ if (strncmp(hash, pointer, PTR_WIDTH) == 0) {
+ pr_warn("vsprintf(\"%s\", p) returned %s, expected hashed pointer\n",
+ fmt, hash);
+ goto err;
+ }
+
+#if BITS_PER_LONG == 64
+ if (strncmp(hash, ZEROS, PTR_WIDTH / 2) != 0) {
+ pr_warn("vsprintf(\"%s\", p) returned %s, expected %s in the top half bits\n",
+ fmt, hash, ZEROS);
+ goto err;
+ }
+#endif
+ return;
- test(buf, fmt, p);
+err:
+ failed_tests++;
}
static void __init
-null_pointer(void)
+plain_pointer(void)
{
test_hashed("%p", NULL);
- test(ZEROS "00000000", "%px", NULL);
- test("(null)", "%pE", NULL);
+ test_hashed("%p", PTR_ERROR);
+ test_hashed("%p", PTR_INVALID);
}
-#define PTR_INVALID ((void *)0x000000ab)
static void __init
-invalid_pointer(void)
+real_pointer(void)
{
- test_hashed("%p", PTR_INVALID);
- test(ZEROS "000000ab", "%px", PTR_INVALID);
- test("(efault)", "%pE", PTR_INVALID);
+ test(ZEROS "00000000", "%px", NULL);
+ test(ONES PTR_VAL_ERROR, "%px", PTR_ERROR);
+ test(PTR_VAL_INVALID, "%px", PTR_INVALID);
}
static void __init
@@ -372,6 +327,8 @@ addr(void)
static void __init
escaped_str(void)
{
+ test("(null)", "%pE", NULL);
+ test("(efault)", "%pE", PTR_ERROR);
}
static void __init
@@ -458,9 +415,9 @@ dentry(void)
test("foo", "%pd2", &test_dentry[0]);
test("(null)", "%pd", NULL);
- test("(efault)", "%pd", PTR_INVALID);
+ test("(efault)", "%pd", PTR_ERROR);
test("(null)", "%pD", NULL);
- test("(efault)", "%pD", PTR_INVALID);
+ test("(efault)", "%pD", PTR_ERROR);
test("romeo", "%pd", &test_dentry[3]);
test("alfa/romeo", "%pd2", &test_dentry[3]);
@@ -647,9 +604,8 @@ errptr(void)
static void __init
test_pointer(void)
{
- plain();
- null_pointer();
- invalid_pointer();
+ plain_pointer();
+ real_pointer();
symbol_ptr();
kernel_ptr();
struct_resource();
--
2.16.4
^ permalink raw reply related
* Re: [PATCH -next v2] fork: annotate a data race in vm_area_dup()
From: Kirill A. Shutemov @ 2020-02-20 12:56 UTC (permalink / raw)
To: Qian Cai; +Cc: paulmck, akpm, elver, peterz, linux-mm, linux-kernel
In-Reply-To: <1582122495-12885-1-git-send-email-cai@lca.pw>
On Wed, Feb 19, 2020 at 09:28:15AM -0500, Qian Cai wrote:
> struct vm_area_struct could be accessed concurrently as noticed by
> KCSAN,
>
> write to 0xffff9cf8bba08ad8 of 8 bytes by task 14263 on cpu 35:
> vma_interval_tree_insert+0x101/0x150:
> rb_insert_augmented_cached at include/linux/rbtree_augmented.h:58
> (inlined by) vma_interval_tree_insert at mm/interval_tree.c:23
> __vma_link_file+0x6e/0xe0
> __vma_link_file at mm/mmap.c:629
> vma_link+0xa2/0x120
> mmap_region+0x753/0xb90
> do_mmap+0x45c/0x710
> vm_mmap_pgoff+0xc0/0x130
> ksys_mmap_pgoff+0x1d1/0x300
> __x64_sys_mmap+0x33/0x40
> do_syscall_64+0x91/0xc44
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> read to 0xffff9cf8bba08a80 of 200 bytes by task 14262 on cpu 122:
> vm_area_dup+0x6a/0xe0
> vm_area_dup at kernel/fork.c:362
> __split_vma+0x72/0x2a0
> __split_vma at mm/mmap.c:2661
> split_vma+0x5a/0x80
> mprotect_fixup+0x368/0x3f0
> do_mprotect_pkey+0x263/0x420
> __x64_sys_mprotect+0x51/0x70
> do_syscall_64+0x91/0xc44
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> vm_area_dup() blindly copies all fields of original VMA to the new one.
> This includes coping vm_area_struct::shared.rb which is normally
> protected by i_mmap_lock. But this is fine because the read value will
> be overwritten on the following __vma_link_file() under proper
> protection. Thus, mark it as an intentional data race and insert a few
> assertions for the fields that should not be modified concurrently.
>
> Signed-off-by: Qian Cai <cai@lca.pw>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
Kirill A. Shutemov
^ permalink raw reply
* 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
* 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: [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
* 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
* 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 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
* [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
* [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
* 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
* 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
* [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: [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
* 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: [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
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.