This is the start of the stable review cycle for the 5.10.59 release.
There are 19 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun, 15 Aug 2021 15:05:12 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.59-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.10.59-rc1
YueHaibing <[email protected]>
net: xilinx_emaclite: Do not print real IOMEM pointer
Miklos Szeredi <[email protected]>
ovl: prevent private clone if bind mount is not allowed
Pali Rohár <[email protected]>
ppp: Fix generating ppp unit id when ifname is not specified
Luke D Jones <[email protected]>
ALSA: hda: Add quirk for ASUS Flow x13
Jeremy Szu <[email protected]>
ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 650 G8 Notebook PC
Takashi Iwai <[email protected]>
ALSA: pcm: Fix mmap breakage without explicit buffer setup
Longfang Liu <[email protected]>
USB:ehci:fix Kunpeng920 ehci hardware problem
Hans de Goede <[email protected]>
vboxsf: Make vboxsf_dir_create() return the handle for the created file
Hans de Goede <[email protected]>
vboxsf: Honor excl flag to the dir-inode create op
Adam Ford <[email protected]>
arm64: dts: renesas: beacon: Fix USB ref clock references
Adam Ford <[email protected]>
arm64: dts: renesas: beacon: Fix USB extal reference
Adam Ford <[email protected]>
arm64: dts: renesas: rzg2: Add usb2_clksel to RZ/G2 M/N/H
Mike Rapoport <[email protected]>
mm: make zone_to_nid() and zone_set_nid() available for DISCONTIGMEM
Reinette Chatre <[email protected]>
Revert "selftests/resctrl: Use resctrl/info for feature detection"
Daniel Borkmann <[email protected]>
bpf: Add lockdown check for probe_write_user helper
Daniel Borkmann <[email protected]>
bpf: Add _kernel suffix to internal lockdown_bpf_read
Allen Pais <[email protected]>
firmware: tee_bnxt: Release TEE shm, session, and context during kexec
Sumit Garg <[email protected]>
tee: Correct inappropriate usage of TEE_SHM_DMA_BUF flag
Sean Christopherson <[email protected]>
KVM: SVM: Fix off-by-one indexing when nullifying last used SEV VMCB
-------------
Diffstat:
Makefile | 4 +-
.../boot/dts/renesas/beacon-renesom-baseboard.dtsi | 4 +-
.../arm64/boot/dts/renesas/beacon-renesom-som.dtsi | 6 ++-
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 15 +++++++
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 15 +++++++
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 15 +++++++
arch/x86/kvm/svm/sev.c | 2 +-
drivers/firmware/broadcom/tee_bnxt_fw.c | 14 ++++--
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 5 +--
drivers/net/ppp/ppp_generic.c | 19 ++++++--
drivers/tee/optee/call.c | 2 +-
drivers/tee/optee/core.c | 3 +-
drivers/tee/optee/rpc.c | 5 ++-
drivers/tee/optee/shm_pool.c | 8 +++-
drivers/tee/tee_shm.c | 4 +-
drivers/usb/host/ehci-pci.c | 3 ++
fs/namespace.c | 42 +++++++++++------
fs/vboxsf/dir.c | 28 +++++++-----
include/linux/mmzone.h | 4 +-
include/linux/security.h | 3 +-
include/linux/tee_drv.h | 1 +
kernel/bpf/helpers.c | 4 +-
kernel/trace/bpf_trace.c | 13 +++---
security/security.c | 3 +-
sound/core/pcm_native.c | 5 ++-
sound/pci/hda/patch_realtek.c | 2 +
tools/testing/selftests/resctrl/resctrl.h | 6 +--
tools/testing/selftests/resctrl/resctrlfs.c | 52 +++++-----------------
28 files changed, 178 insertions(+), 109 deletions(-)
From: Sumit Garg <[email protected]>
[ Upstream commit 376e4199e327a5cf29b8ec8fb0f64f3d8b429819 ]
Currently TEE_SHM_DMA_BUF flag has been inappropriately used to not
register shared memory allocated for private usage by underlying TEE
driver: OP-TEE in this case. So rather add a new flag as TEE_SHM_PRIV
that can be utilized by underlying TEE drivers for private allocation
and usage of shared memory.
With this corrected, allow tee_shm_alloc_kernel_buf() to allocate a
shared memory region without the backing of dma-buf.
Cc: [email protected]
Signed-off-by: Sumit Garg <[email protected]>
Co-developed-by: Tyler Hicks <[email protected]>
Signed-off-by: Tyler Hicks <[email protected]>
Reviewed-by: Jens Wiklander <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Signed-off-by: Jens Wiklander <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/tee/optee/call.c | 2 +-
drivers/tee/optee/core.c | 3 ++-
drivers/tee/optee/rpc.c | 5 +++--
drivers/tee/optee/shm_pool.c | 8 ++++++--
drivers/tee/tee_shm.c | 4 ++--
include/linux/tee_drv.h | 1 +
6 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
index 1231ce56e712..f8f1594bea43 100644
--- a/drivers/tee/optee/call.c
+++ b/drivers/tee/optee/call.c
@@ -181,7 +181,7 @@ static struct tee_shm *get_msg_arg(struct tee_context *ctx, size_t num_params,
struct optee_msg_arg *ma;
shm = tee_shm_alloc(ctx, OPTEE_MSG_GET_ARG_SIZE(num_params),
- TEE_SHM_MAPPED);
+ TEE_SHM_MAPPED | TEE_SHM_PRIV);
if (IS_ERR(shm))
return shm;
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 7b17248f1527..823a81d8ff0e 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -278,7 +278,8 @@ static void optee_release(struct tee_context *ctx)
if (!ctxdata)
return;
- shm = tee_shm_alloc(ctx, sizeof(struct optee_msg_arg), TEE_SHM_MAPPED);
+ shm = tee_shm_alloc(ctx, sizeof(struct optee_msg_arg),
+ TEE_SHM_MAPPED | TEE_SHM_PRIV);
if (!IS_ERR(shm)) {
arg = tee_shm_get_va(shm, 0);
/*
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
index 6cbb3643c6c4..9dbdd783d6f2 100644
--- a/drivers/tee/optee/rpc.c
+++ b/drivers/tee/optee/rpc.c
@@ -313,7 +313,7 @@ static void handle_rpc_func_cmd_shm_alloc(struct tee_context *ctx,
shm = cmd_alloc_suppl(ctx, sz);
break;
case OPTEE_MSG_RPC_SHM_TYPE_KERNEL:
- shm = tee_shm_alloc(ctx, sz, TEE_SHM_MAPPED);
+ shm = tee_shm_alloc(ctx, sz, TEE_SHM_MAPPED | TEE_SHM_PRIV);
break;
default:
arg->ret = TEEC_ERROR_BAD_PARAMETERS;
@@ -501,7 +501,8 @@ void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param,
switch (OPTEE_SMC_RETURN_GET_RPC_FUNC(param->a0)) {
case OPTEE_SMC_RPC_FUNC_ALLOC:
- shm = tee_shm_alloc(ctx, param->a1, TEE_SHM_MAPPED);
+ shm = tee_shm_alloc(ctx, param->a1,
+ TEE_SHM_MAPPED | TEE_SHM_PRIV);
if (!IS_ERR(shm) && !tee_shm_get_pa(shm, 0, &pa)) {
reg_pair_from_64(¶m->a1, ¶m->a2, pa);
reg_pair_from_64(¶m->a4, ¶m->a5,
diff --git a/drivers/tee/optee/shm_pool.c b/drivers/tee/optee/shm_pool.c
index da06ce9b9313..c41a9a501a6e 100644
--- a/drivers/tee/optee/shm_pool.c
+++ b/drivers/tee/optee/shm_pool.c
@@ -27,7 +27,11 @@ static int pool_op_alloc(struct tee_shm_pool_mgr *poolm,
shm->paddr = page_to_phys(page);
shm->size = PAGE_SIZE << order;
- if (shm->flags & TEE_SHM_DMA_BUF) {
+ /*
+ * Shared memory private to the OP-TEE driver doesn't need
+ * to be registered with OP-TEE.
+ */
+ if (!(shm->flags & TEE_SHM_PRIV)) {
unsigned int nr_pages = 1 << order, i;
struct page **pages;
@@ -60,7 +64,7 @@ err:
static void pool_op_free(struct tee_shm_pool_mgr *poolm,
struct tee_shm *shm)
{
- if (shm->flags & TEE_SHM_DMA_BUF)
+ if (!(shm->flags & TEE_SHM_PRIV))
optee_shm_unregister(shm->ctx, shm);
free_pages((unsigned long)shm->kaddr, get_order(shm->size));
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index c65e44707cd6..8a9384a64f3e 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -117,7 +117,7 @@ struct tee_shm *tee_shm_alloc(struct tee_context *ctx, size_t size, u32 flags)
return ERR_PTR(-EINVAL);
}
- if ((flags & ~(TEE_SHM_MAPPED | TEE_SHM_DMA_BUF))) {
+ if ((flags & ~(TEE_SHM_MAPPED | TEE_SHM_DMA_BUF | TEE_SHM_PRIV))) {
dev_err(teedev->dev.parent, "invalid shm flags 0x%x", flags);
return ERR_PTR(-EINVAL);
}
@@ -207,7 +207,7 @@ EXPORT_SYMBOL_GPL(tee_shm_alloc);
*/
struct tee_shm *tee_shm_alloc_kernel_buf(struct tee_context *ctx, size_t size)
{
- return tee_shm_alloc(ctx, size, TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
+ return tee_shm_alloc(ctx, size, TEE_SHM_MAPPED);
}
EXPORT_SYMBOL_GPL(tee_shm_alloc_kernel_buf);
diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
index 9b24cc3d3024..459e9a76d7e6 100644
--- a/include/linux/tee_drv.h
+++ b/include/linux/tee_drv.h
@@ -27,6 +27,7 @@
#define TEE_SHM_USER_MAPPED BIT(4) /* Memory mapped in user space */
#define TEE_SHM_POOL BIT(5) /* Memory allocated from pool */
#define TEE_SHM_KERNEL_MAPPED BIT(6) /* Memory mapped in kernel space */
+#define TEE_SHM_PRIV BIT(7) /* Memory private to TEE driver */
struct device;
struct tee_device;
--
2.30.2
From: Adam Ford <[email protected]>
commit ebc666f39ff67a01e748c34d670ddf05a9e45220 upstream
The RZ/G2 boards expect there to be an external clock reference for
USB2 EHCI controllers. For the Beacon boards, this reference clock
is controlled by a programmable versaclock. Because the RZ/G2
family has a special clock driver when using an external clock,
the third clock reference in the EHCI node needs to point to this
special clock, called usb2_clksel.
Since the usb2_clksel does not keep the usb_extal clock enabled,
the 4th clock entry for the EHCI nodes needs to reference it to
keep the clock running and make USB functional.
Signed-off-by: Adam Ford <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Sudip Mukherjee <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -271,12 +271,12 @@
&ehci0 {
dr_mode = "otg";
status = "okay";
- clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+ clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&usb2_clksel>, <&versaclock5 3>;
};
&ehci1 {
status = "okay";
- clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+ clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&usb2_clksel>, <&versaclock5 3>;
};
&hdmi0 {
From: Sean Christopherson <[email protected]>
[ Upstream commit 179c6c27bf487273652efc99acd3ba512a23c137 ]
Use the raw ASID, not ASID-1, when nullifying the last used VMCB when
freeing an SEV ASID. The consumer, pre_sev_run(), indexes the array by
the raw ASID, thus KVM could get a false negative when checking for a
different VMCB if KVM manages to reallocate the same ASID+VMCB combo for
a new VM.
Note, this cannot cause a functional issue _in the current code_, as
pre_sev_run() also checks which pCPU last did VMRUN for the vCPU, and
last_vmentry_cpu is initialized to -1 during vCPU creation, i.e. is
guaranteed to mismatch on the first VMRUN. However, prior to commit
8a14fe4f0c54 ("kvm: x86: Move last_cpu into kvm_vcpu_arch as
last_vmentry_cpu"), SVM tracked pCPU on its own and zero-initialized the
last_cpu variable. Thus it's theoretically possible that older versions
of KVM could miss a TLB flush if the first VMRUN is on pCPU0 and the ASID
and VMCB exactly match those of a prior VM.
Fixes: 70cd94e60c73 ("KVM: SVM: VMRUN should use associated ASID when SEV is enabled")
Cc: Tom Lendacky <[email protected]>
Cc: Brijesh Singh <[email protected]>
Cc: [email protected]
Signed-off-by: Sean Christopherson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/x86/kvm/svm/sev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 01547bdbfb06..6c82ef22985d 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -124,7 +124,7 @@ static void sev_asid_free(int asid)
for_each_possible_cpu(cpu) {
sd = per_cpu(svm_data, cpu);
- sd->sev_vmcbs[pos] = NULL;
+ sd->sev_vmcbs[asid] = NULL;
}
mutex_unlock(&sev_bitmap_lock);
--
2.30.2
From: Reinette Chatre <[email protected]>
This reverts commit 19eaad1400eab34e97ec4467cd2ab694d1caf20c which is
ee0415681eb661efa1eb2db7acc263f2c7df1e23 upstream.
This commit is not a stable candidate and was backported without needed
dependencies that results in the resctrl tests unable to compile.
Signed-off-by: Reinette Chatre <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/resctrl/resctrl.h | 6 ---
tools/testing/selftests/resctrl/resctrlfs.c | 50 +++++-----------------------
2 files changed, 11 insertions(+), 45 deletions(-)
--- a/tools/testing/selftests/resctrl/resctrl.h
+++ b/tools/testing/selftests/resctrl/resctrl.h
@@ -28,10 +28,6 @@
#define RESCTRL_PATH "/sys/fs/resctrl"
#define PHYS_ID_PATH "/sys/devices/system/cpu/cpu"
#define CBM_MASK_PATH "/sys/fs/resctrl/info"
-#define L3_PATH "/sys/fs/resctrl/info/L3"
-#define MB_PATH "/sys/fs/resctrl/info/MB"
-#define L3_MON_PATH "/sys/fs/resctrl/info/L3_MON"
-#define L3_MON_FEATURES_PATH "/sys/fs/resctrl/info/L3_MON/mon_features"
#define PARENT_EXIT(err_msg) \
do { \
@@ -83,7 +79,7 @@ int remount_resctrlfs(bool mum_resctrlfs
int get_resource_id(int cpu_no, int *resource_id);
int umount_resctrlfs(void);
int validate_bw_report_request(char *bw_report);
-bool validate_resctrl_feature_request(const char *resctrl_val);
+bool validate_resctrl_feature_request(char *resctrl_val);
char *fgrep(FILE *inf, const char *str);
int taskset_benchmark(pid_t bm_pid, int cpu_no);
void run_benchmark(int signum, siginfo_t *info, void *ucontext);
--- a/tools/testing/selftests/resctrl/resctrlfs.c
+++ b/tools/testing/selftests/resctrl/resctrlfs.c
@@ -616,56 +616,26 @@ char *fgrep(FILE *inf, const char *str)
* validate_resctrl_feature_request - Check if requested feature is valid.
* @resctrl_val: Requested feature
*
- * Return: True if the feature is supported, else false
+ * Return: 0 on success, non-zero on failure
*/
-bool validate_resctrl_feature_request(const char *resctrl_val)
+bool validate_resctrl_feature_request(char *resctrl_val)
{
- struct stat statbuf;
+ FILE *inf = fopen("/proc/cpuinfo", "r");
bool found = false;
char *res;
- FILE *inf;
- if (!resctrl_val)
+ if (!inf)
return false;
- if (remount_resctrlfs(false))
- return false;
-
- if (!strncmp(resctrl_val, CAT_STR, sizeof(CAT_STR))) {
- if (!stat(L3_PATH, &statbuf))
- return true;
- } else if (!strncmp(resctrl_val, MBA_STR, sizeof(MBA_STR))) {
- if (!stat(MB_PATH, &statbuf))
- return true;
- } else if (!strncmp(resctrl_val, MBM_STR, sizeof(MBM_STR)) ||
- !strncmp(resctrl_val, CMT_STR, sizeof(CMT_STR))) {
- if (!stat(L3_MON_PATH, &statbuf)) {
- inf = fopen(L3_MON_FEATURES_PATH, "r");
- if (!inf)
- return false;
+ res = fgrep(inf, "flags");
- if (!strncmp(resctrl_val, CMT_STR, sizeof(CMT_STR))) {
- res = fgrep(inf, "llc_occupancy");
- if (res) {
- found = true;
- free(res);
- }
- }
+ if (res) {
+ char *s = strchr(res, ':');
- if (!strncmp(resctrl_val, MBM_STR, sizeof(MBM_STR))) {
- res = fgrep(inf, "mbm_total_bytes");
- if (res) {
- free(res);
- res = fgrep(inf, "mbm_local_bytes");
- if (res) {
- found = true;
- free(res);
- }
- }
- }
- fclose(inf);
- }
+ found = s && !strstr(s, resctrl_val);
+ free(res);
}
+ fclose(inf);
return found;
}
From: Adam Ford <[email protected]>
commit e1076ce07b7736aed269c5d8154f2442970d9137 upstream
Per the reference manual for the RZ/G Series, 2nd Generation,
the RZ/G2M, RZ/G2N, and RZ/G2H have a bit that can be set to
choose between a crystal oscillator and an external oscillator.
Because only boards that need this should enable it, it's marked
as disabled by default for backwards compatibility with existing
boards.
Signed-off-by: Adam Ford <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Sudip Mukherjee <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 15 +++++++++++++++
3 files changed, 45 insertions(+)
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -836,6 +836,21 @@
status = "disabled";
};
+ usb2_clksel: clock-controller@e6590630 {
+ compatible = "renesas,r8a774a1-rcar-usb2-clock-sel",
+ "renesas,rcar-gen3-usb2-clock-sel";
+ reg = <0 0xe6590630 0 0x02>;
+ clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>,
+ <&usb_extal_clk>, <&usb3s0_clk>;
+ clock-names = "ehci_ohci", "hs-usb-if",
+ "usb_extal", "usb_xtal";
+ #clock-cells = <0>;
+ power-domains = <&sysc R8A774A1_PD_ALWAYS_ON>;
+ resets = <&cpg 703>, <&cpg 704>;
+ reset-names = "ehci_ohci", "hs-usb-if";
+ status = "disabled";
+ };
+
usb_dmac0: dma-controller@e65a0000 {
compatible = "renesas,r8a774a1-usb-dmac",
"renesas,usb-dmac";
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -709,6 +709,21 @@
status = "disabled";
};
+ usb2_clksel: clock-controller@e6590630 {
+ compatible = "renesas,r8a774b1-rcar-usb2-clock-sel",
+ "renesas,rcar-gen3-usb2-clock-sel";
+ reg = <0 0xe6590630 0 0x02>;
+ clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>,
+ <&usb_extal_clk>, <&usb3s0_clk>;
+ clock-names = "ehci_ohci", "hs-usb-if",
+ "usb_extal", "usb_xtal";
+ #clock-cells = <0>;
+ power-domains = <&sysc R8A774B1_PD_ALWAYS_ON>;
+ resets = <&cpg 703>, <&cpg 704>;
+ reset-names = "ehci_ohci", "hs-usb-if";
+ status = "disabled";
+ };
+
usb_dmac0: dma-controller@e65a0000 {
compatible = "renesas,r8a774b1-usb-dmac",
"renesas,usb-dmac";
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@ -890,6 +890,21 @@
status = "disabled";
};
+ usb2_clksel: clock-controller@e6590630 {
+ compatible = "renesas,r8a774e1-rcar-usb2-clock-sel",
+ "renesas,rcar-gen3-usb2-clock-sel";
+ reg = <0 0xe6590630 0 0x02>;
+ clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>,
+ <&usb_extal_clk>, <&usb3s0_clk>;
+ clock-names = "ehci_ohci", "hs-usb-if",
+ "usb_extal", "usb_xtal";
+ #clock-cells = <0>;
+ power-domains = <&sysc R8A774E1_PD_ALWAYS_ON>;
+ resets = <&cpg 703>, <&cpg 704>;
+ reset-names = "ehci_ohci", "hs-usb-if";
+ status = "disabled";
+ };
+
usb_dmac0: dma-controller@e65a0000 {
compatible = "renesas,r8a774e1-usb-dmac",
"renesas,usb-dmac";
From: Hans de Goede <[email protected]>
commit cc3ddee97cff034cea4d095de4a484c92a219bf5 upstream
Honor the excl flag to the dir-inode create op, instead of behaving
as if it is always set.
Note the old behavior still worked most of the time since a non-exclusive
open only calls the create op, if there is a race and the file is created
between the dentry lookup and the calling of the create call.
While at it change the type of the is_dir parameter to the
vboxsf_dir_create() helper from an int to a bool, to be consistent with
the use of bool for the excl parameter.
Fixes: 0fd169576648 ("fs: Add VirtualBox guest shared folder (vboxsf) support")
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Sudip Mukherjee <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/vboxsf/dir.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/fs/vboxsf/dir.c
+++ b/fs/vboxsf/dir.c
@@ -253,7 +253,7 @@ static int vboxsf_dir_instantiate(struct
}
static int vboxsf_dir_create(struct inode *parent, struct dentry *dentry,
- umode_t mode, int is_dir)
+ umode_t mode, bool is_dir, bool excl)
{
struct vboxsf_inode *sf_parent_i = VBOXSF_I(parent);
struct vboxsf_sbi *sbi = VBOXSF_SBI(parent->i_sb);
@@ -261,10 +261,12 @@ static int vboxsf_dir_create(struct inod
int err;
params.handle = SHFL_HANDLE_NIL;
- params.create_flags = SHFL_CF_ACT_CREATE_IF_NEW |
- SHFL_CF_ACT_FAIL_IF_EXISTS |
- SHFL_CF_ACCESS_READWRITE |
- (is_dir ? SHFL_CF_DIRECTORY : 0);
+ params.create_flags = SHFL_CF_ACT_CREATE_IF_NEW | SHFL_CF_ACCESS_READWRITE;
+ if (is_dir)
+ params.create_flags |= SHFL_CF_DIRECTORY;
+ if (excl)
+ params.create_flags |= SHFL_CF_ACT_FAIL_IF_EXISTS;
+
params.info.attr.mode = (mode & 0777) |
(is_dir ? SHFL_TYPE_DIRECTORY : SHFL_TYPE_FILE);
params.info.attr.additional = SHFLFSOBJATTRADD_NOTHING;
@@ -291,13 +293,13 @@ static int vboxsf_dir_create(struct inod
static int vboxsf_dir_mkfile(struct inode *parent, struct dentry *dentry,
umode_t mode, bool excl)
{
- return vboxsf_dir_create(parent, dentry, mode, 0);
+ return vboxsf_dir_create(parent, dentry, mode, false, excl);
}
static int vboxsf_dir_mkdir(struct inode *parent, struct dentry *dentry,
umode_t mode)
{
- return vboxsf_dir_create(parent, dentry, mode, 1);
+ return vboxsf_dir_create(parent, dentry, mode, true, true);
}
static int vboxsf_dir_unlink(struct inode *parent, struct dentry *dentry)
From: Hans de Goede <[email protected]>
commit ab0c29687bc7a890d1a86ac376b0b0fd78b2d9b6 upstream
Make vboxsf_dir_create() optionally return the vboxsf-handle for
the created file. This is a preparation patch for adding atomic_open
support.
Fixes: 0fd169576648 ("fs: Add VirtualBox guest shared folder (vboxsf) support")
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Sudip Mukherjee <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/vboxsf/dir.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
--- a/fs/vboxsf/dir.c
+++ b/fs/vboxsf/dir.c
@@ -253,7 +253,7 @@ static int vboxsf_dir_instantiate(struct
}
static int vboxsf_dir_create(struct inode *parent, struct dentry *dentry,
- umode_t mode, bool is_dir, bool excl)
+ umode_t mode, bool is_dir, bool excl, u64 *handle_ret)
{
struct vboxsf_inode *sf_parent_i = VBOXSF_I(parent);
struct vboxsf_sbi *sbi = VBOXSF_SBI(parent->i_sb);
@@ -278,28 +278,32 @@ static int vboxsf_dir_create(struct inod
if (params.result != SHFL_FILE_CREATED)
return -EPERM;
- vboxsf_close(sbi->root, params.handle);
-
err = vboxsf_dir_instantiate(parent, dentry, ¶ms.info);
if (err)
- return err;
+ goto out;
/* parent directory access/change time changed */
sf_parent_i->force_restat = 1;
- return 0;
+out:
+ if (err == 0 && handle_ret)
+ *handle_ret = params.handle;
+ else
+ vboxsf_close(sbi->root, params.handle);
+
+ return err;
}
static int vboxsf_dir_mkfile(struct inode *parent, struct dentry *dentry,
umode_t mode, bool excl)
{
- return vboxsf_dir_create(parent, dentry, mode, false, excl);
+ return vboxsf_dir_create(parent, dentry, mode, false, excl, NULL);
}
static int vboxsf_dir_mkdir(struct inode *parent, struct dentry *dentry,
umode_t mode)
{
- return vboxsf_dir_create(parent, dentry, mode, true, true);
+ return vboxsf_dir_create(parent, dentry, mode, true, true, NULL);
}
static int vboxsf_dir_unlink(struct inode *parent, struct dentry *dentry)
From: Takashi Iwai <[email protected]>
commit dc0dc8a73e8e4dc33fba93dfe23356cc5a500c57 upstream.
The recent fix c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
restricts the mmap capability only to the drivers that properly set up
the buffers, but it caused a regression for a few drivers that manage
the buffer on its own way.
For those with UNKNOWN buffer type (i.e. the uninitialized / unused
substream->dma_buffer), just assume that the driver handles the mmap
properly and blindly trust the hardware info bit.
Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
Reported-and-tested-by: Jeff Woods <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/core/pcm_native.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -251,7 +251,10 @@ static bool hw_support_mmap(struct snd_p
switch (substream->dma_buffer.dev.type) {
case SNDRV_DMA_TYPE_UNKNOWN:
- return false;
+ /* we can't know the device, so just assume that the driver does
+ * everything right
+ */
+ return true;
case SNDRV_DMA_TYPE_CONTINUOUS:
case SNDRV_DMA_TYPE_VMALLOC:
return true;
From: Daniel Borkmann <[email protected]>
commit 51e1bb9eeaf7868db56e58f47848e364ab4c4129 upstream.
Back then, commit 96ae52279594 ("bpf: Add bpf_probe_write_user BPF helper
to be called in tracers") added the bpf_probe_write_user() helper in order
to allow to override user space memory. Its original goal was to have a
facility to "debug, divert, and manipulate execution of semi-cooperative
processes" under CAP_SYS_ADMIN. Write to kernel was explicitly disallowed
since it would otherwise tamper with its integrity.
One use case was shown in cf9b1199de27 ("samples/bpf: Add test/example of
using bpf_probe_write_user bpf helper") where the program DNATs traffic
at the time of connect(2) syscall, meaning, it rewrites the arguments to
a syscall while they're still in userspace, and before the syscall has a
chance to copy the argument into kernel space. These days we have better
mechanisms in BPF for achieving the same (e.g. for load-balancers), but
without having to write to userspace memory.
Of course the bpf_probe_write_user() helper can also be used to abuse
many other things for both good or bad purpose. Outside of BPF, there is
a similar mechanism for ptrace(2) such as PTRACE_PEEK{TEXT,DATA} and
PTRACE_POKE{TEXT,DATA}, but would likely require some more effort.
Commit 96ae52279594 explicitly dedicated the helper for experimentation
purpose only. Thus, move the helper's availability behind a newly added
LOCKDOWN_BPF_WRITE_USER lockdown knob so that the helper is disabled under
the "integrity" mode. More fine-grained control can be implemented also
from LSM side with this change.
Fixes: 96ae52279594 ("bpf: Add bpf_probe_write_user BPF helper to be called in tracers")
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/security.h | 1 +
kernel/trace/bpf_trace.c | 5 +++--
security/security.c | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -120,6 +120,7 @@ enum lockdown_reason {
LOCKDOWN_MMIOTRACE,
LOCKDOWN_DEBUGFS,
LOCKDOWN_XMON_WR,
+ LOCKDOWN_BPF_WRITE_USER,
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_KCORE,
LOCKDOWN_KPROBES,
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1272,12 +1272,13 @@ bpf_tracing_func_proto(enum bpf_func_id
return &bpf_get_numa_node_id_proto;
case BPF_FUNC_perf_event_read:
return &bpf_perf_event_read_proto;
- case BPF_FUNC_probe_write_user:
- return bpf_get_probe_write_proto();
case BPF_FUNC_current_task_under_cgroup:
return &bpf_current_task_under_cgroup_proto;
case BPF_FUNC_get_prandom_u32:
return &bpf_get_prandom_u32_proto;
+ case BPF_FUNC_probe_write_user:
+ return security_locked_down(LOCKDOWN_BPF_WRITE_USER) < 0 ?
+ NULL : bpf_get_probe_write_proto();
case BPF_FUNC_probe_read_user:
return &bpf_probe_read_user_proto;
case BPF_FUNC_probe_read_kernel:
--- a/security/security.c
+++ b/security/security.c
@@ -58,6 +58,7 @@ const char *const lockdown_reasons[LOCKD
[LOCKDOWN_MMIOTRACE] = "unsafe mmio",
[LOCKDOWN_DEBUGFS] = "debugfs access",
[LOCKDOWN_XMON_WR] = "xmon write access",
+ [LOCKDOWN_BPF_WRITE_USER] = "use of bpf to write user RAM",
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_KPROBES] = "use of kprobes",
Hi!
> commit ab0c29687bc7a890d1a86ac376b0b0fd78b2d9b6 upstream
>
> Make vboxsf_dir_create() optionally return the vboxsf-handle for
> the created file. This is a preparation patch for adding atomic_open
> support.
Follow up commits using this functionality are in 5.13 but not in
5.10, so I believe we don't need this in 5.10, either?
(Plus someone familiar with the code should check if we need "vboxsf:
Honor excl flag to the dir-inode create op" in 5.10; it may have same
problem).
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
On 8/13/21 9:07 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.59 release.
> There are 19 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 15 Aug 2021 15:05:12 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.59-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
Hi Greg,
On Fri, Aug 13, 2021 at 05:07:17PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.59 release.
> There are 19 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 15 Aug 2021 15:05:12 +0000.
> Anything received after that time might be too late.
Build test:
mips (gcc version 11.1.1 20210723): 63 configs -> no failure
arm (gcc version 11.1.1 20210723): 105 configs -> no new failure
arm64 (gcc version 11.1.1 20210723): 3 configs -> no failure
x86_64 (gcc version 10.2.1 20210110): 4 configs -> no failure
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
[1]. https://openqa.qa.codethink.co.uk/tests/29
[2]. https://openqa.qa.codethink.co.uk/tests/30
Tested-by: Sudip Mukherjee <[email protected]>
--
Regards
Sudip
On Fri, 13 Aug 2021 at 20:44, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.10.59 release.
> There are 19 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 15 Aug 2021 15:05:12 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.59-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <[email protected]>
## Build
* kernel: 5.10.59-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: ed2493daa915286093123bc53c2172d717bc5d82
* git describe: v5.10.57-155-ged2493daa915
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.57-155-ged2493daa915
## No regressions (compared to v5.10.57-155-g81212a8abbf6)
## No fixes (compared to v5.10.57-155-g81212a8abbf6)
## Test result summary
total: 82479, pass: 69458, fail: 306, skip: 11842, xfail: 873
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 194 total, 194 passed, 0 failed
* arm64: 28 total, 28 passed, 0 failed
* i386: 26 total, 26 passed, 0 failed
* mips: 45 total, 45 passed, 0 failed
* parisc: 9 total, 9 passed, 0 failed
* powerpc: 27 total, 27 passed, 0 failed
* riscv: 21 total, 21 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 18 total, 18 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x86_64: 28 total, 28 passed, 0 failed
## Test suites summary
* fwts
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
On Fri, 13 Aug 2021 17:07:17 +0200, Greg Kroah-Hartman <[email protected]> wrote:
> This is the start of the stable review cycle for the 5.10.59 release.
> There are 19 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 15 Aug 2021 15:05:12 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.59-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
5.10.59-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Tested-by: Fox Chen <[email protected]>
On Fri, Aug 13, 2021 at 05:07:17PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.59 release.
> There are 19 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 15 Aug 2021 15:05:12 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 472 pass: 472 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter
Is there a reason for skipping the selftests/netfilter tests?
eg;
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.57-155-ged2493daa915/testrun/5442487/suite/kselftest-net/test/netfilter:nft_trans_stress.sh/details/
I have not double checked (n=1) but it looks like this patch is the
first for that test to hang on for 13 hours. The state just before I
killed the test;
ps ax --forest
...
2013 pts/2 Ss 0:00 \_ -bash
2025 pts/2 S+ 0:00 \_ bash scripts/kernel_test_diff.sh
2064 pts/2 S+ 0:00 \_ make SKIP_TARGETS=ptrace rtc
breakpoints kselftest
2285 pts/2 S+ 0:00 \_ make -C
./tools/testing/selftests run_tests
2953 pts/2 S+ 0:00 \_ /bin/sh -c for TARGET
in android arm64 bpf capabilities cgroup clone3 core cpufreq
cpu-hotplug drivers/dma-buf efivarfs exec filesystems
filesystems/binde
13616 pts/2 S+ 0:00 \_ make
OUTPUT=/media/btrfs/linux/tools/testing/selftests/netfilter -C
netfilter run_tests
13617 pts/2 S+ 0:00 \_ /bin/sh -c
BASE_DIR="/media/btrfs/linux/tools/testing/selftests"; .
/media/btrfs/linux/tools/testing/selftests/kselftest/runner.sh; if [
"X" != "X
13624 pts/2 S+ 0:00 \_ /bin/sh
-c BASE_DIR="/media/btrfs/linux/tools/testing/selftests"; .
/media/btrfs/linux/tools/testing/selftests/kselftest/runner.sh; if [
"X" !
13625 pts/2 S+ 0:00 \_
/bin/sh -c BASE_DIR="/media/btrfs/linux/tools/testing/selftests"; .
/media/btrfs/linux/tools/testing/selftests/kselftest/runner.sh; if [ "
13626 pts/2 S+ 0:00 \_
/bin/sh -c BASE_DIR="/media/btrfs/linux/tools/testing/selftests"; .
/media/btrfs/linux/tools/testing/selftests/kselftest/runner.sh; if
13629 pts/2 S+ 0:00
\_ /bin/sh -c BASE_DIR="/media/btrfs/linux/tools/testing/selftests"; .
/media/btrfs/linux/tools/testing/selftests/kselftest/runner.sh
13631 pts/2 S+ 0:00
\_ perl /media/btrfs/linux/tools/testing/selftests/kselftest/prefix.pl
16853 pts/2 R+ 188:32 ping -4 127.0.0.1 -fq
16854 pts/2 R+ 188:32 ping -6 ::1 -fq
16856 pts/2 R+ 189:36 ping -4 127.0.0.1 -fq
16857 pts/2 R+ 189:36 ping -6 ::1 -fq
16859 pts/2 R+ 189:24 ping -4 127.0.0.1 -fq
16860 pts/2 R+ 189:24 ping -6 ::1 -fq
16862 pts/2 R+ 189:22 ping -4 127.0.0.1 -fq
16863 pts/2 R+ 189:22 ping -6 ::1 -fq
dmesg
...
[ 248.609199] BUG: scheduling while atomic: cpuhp/1/15/0x00000002
...
[ 248.609658] Call trace:
[ 248.609670] dump_backtrace+0x0/0x1a8
[ 248.609675] show_stack+0x18/0x68
[ 248.609681] dump_stack+0xd0/0x12c
[ 248.609687] __schedule_bug+0x60/0x78
[ 248.609692] __schedule+0x5d8/0x650
[ 248.609696] schedule+0x70/0x108
[ 248.609702] schedule_timeout+0x228/0x288
[ 248.609707] wait_for_completion_killable+0x88/0x170
[ 248.609712] __kthread_create_on_node+0xbc/0x1a8
[ 248.609716] kthread_create_on_node+0x58/0x80
[ 248.609723] spl_kthread_create+0x9c/0x110
[ 248.609727] taskq_thread_create+0x64/0x108
[ 248.609732] spl_taskq_expand+0xc4/0xf0
[ 248.609738] cpuhp_invoke_callback+0x180/0x210
[ 248.609743] cpuhp_thread_fun+0xd8/0x170
[ 248.609747] smpboot_thread_fn+0x1c4/0x280
[ 248.609752] kthread+0x140/0x160
[ 248.609756] ret_from_fork+0x10/0x34
...
[ 385.330256] IPv6: ADDRCONF(NETDEV_CHANGE): ns2eth3: link becomes ready
On Fri, Aug 13, 2021 at 09:31:58PM +0200, Pavel Machek wrote:
> Hi!
>
> > commit ab0c29687bc7a890d1a86ac376b0b0fd78b2d9b6 upstream
> >
> > Make vboxsf_dir_create() optionally return the vboxsf-handle for
> > the created file. This is a preparation patch for adding atomic_open
> > support.
>
> Follow up commits using this functionality are in 5.13 but not in
> 5.10, so I believe we don't need this in 5.10, either?
It was asked to be backported, so I'll leave it in for now, thanks.
greg k-h
Hi,
On 8/13/21 9:31 PM, Pavel Machek wrote:
> Hi!
>
>> commit ab0c29687bc7a890d1a86ac376b0b0fd78b2d9b6 upstream
>>
>> Make vboxsf_dir_create() optionally return the vboxsf-handle for
>> the created file. This is a preparation patch for adding atomic_open
>> support.
>
> Follow up commits using this functionality are in 5.13 but not in
> 5.10, so I believe we don't need this in 5.10, either?
>
> (Plus someone familiar with the code should check if we need "vboxsf:
> Honor excl flag to the dir-inode create op" in 5.10; it may have same
> problem).
Actually those follow up commits fix an actual bug, so I was expecting
the person who did the backport to also submit the rest of the set.
FWIW having these patches in but not the cannot hurt.
Hopefully the rest applies cleanly, I don't know.
To be clear I'm talking about also adding the following to patches
to 5.10.y:
02f840f90764 ("vboxsf: Add vboxsf_[create|release]_sf_handle() helpers")
52dfd86aa568 ("vboxsf: Add support for the atomic_open directory-inode op")
I have no idea of these will apply cleanly.
Regards,
Hans
Hi!
> This is the start of the stable review cycle for the 5.10.59 release.
> There are 19 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 15 Aug 2021 15:05:12 +0000.
> Anything received after that time might be too late.
CIP testing did not find any kernel problems here: (but we have some
infrastructure problems)
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Tested-by: Pavel Machek (CIP) <[email protected]>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
On 2021/8/13 23:07, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.59 release.
> There are 19 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 15 Aug 2021 15:05:12 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.59-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Tested on arm64 and x86 for 5.10.59-rc1,
Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.10.y
Version: 5.10.59-rc1
Commit: ed2493daa915286093123bc53c2172d717bc5d82
Compiler: gcc version 7.3.0 (GCC)
arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8907
passed: 8907
failed: 0
timeout: 0
--------------------------------------------------------------------
x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8907
passed: 8907
failed: 0
timeout: 0
--------------------------------------------------------------------
Tested-by: Hulk Robot <[email protected]>
On Sun, Aug 15, 2021 at 03:57:24PM +0200, Hans de Goede wrote:
> Hi,
>
> On 8/13/21 9:31 PM, Pavel Machek wrote:
> > Hi!
> >
> >> commit ab0c29687bc7a890d1a86ac376b0b0fd78b2d9b6 upstream
> >>
> >> Make vboxsf_dir_create() optionally return the vboxsf-handle for
> >> the created file. This is a preparation patch for adding atomic_open
> >> support.
> >
> > Follow up commits using this functionality are in 5.13 but not in
> > 5.10, so I believe we don't need this in 5.10, either?
> >
> > (Plus someone familiar with the code should check if we need "vboxsf:
> > Honor excl flag to the dir-inode create op" in 5.10; it may have same
> > problem).
>
> Actually those follow up commits fix an actual bug, so I was expecting
> the person who did the backport to also submit the rest of the set.
>
> FWIW having these patches in but not the cannot hurt.
>
> Hopefully the rest applies cleanly, I don't know.
>
> To be clear I'm talking about also adding the following to patches
> to 5.10.y:
>
> 02f840f90764 ("vboxsf: Add vboxsf_[create|release]_sf_handle() helpers")
> 52dfd86aa568 ("vboxsf: Add support for the atomic_open directory-inode op")
>
> I have no idea of these will apply cleanly.
They do, now queued up, thanks.
greg k-h
Hi Tim,
On Sun, 15 Aug 2021 at 08:41, Tim Lewis <[email protected]> wrote:
>
> Is there a reason for skipping the selftests/netfilter tests?
>
> eg;
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.57-155-ged2493daa915/testrun/5442487/suite/kselftest-net/test/netfilter:nft_trans_stress.sh/details/
>
> I have not double checked (n=1) but it looks like this patch is the
> first for that test to hang on for 13 hours. The state just before I
> killed the test;
I have seen a set of test cases hang so I have skipped them.
x86_64 is using NFS root file system the net and netfilter tests performing
network interfaces up and down causing network failure and system hang.
The reasons for failure are listed in this document.
https://github.com/Linaro/test-definitions/blob/master/automated/linux/kselftest/skipfile-lkft.yaml
- Naresh
On Sun, Aug 15, 2021 at 2:57 PM Hans de Goede <[email protected]> wrote:
>
> Hi,
>
> On 8/13/21 9:31 PM, Pavel Machek wrote:
> > Hi!
> >
> >> commit ab0c29687bc7a890d1a86ac376b0b0fd78b2d9b6 upstream
> >>
> >> Make vboxsf_dir_create() optionally return the vboxsf-handle for
> >> the created file. This is a preparation patch for adding atomic_open
> >> support.
> >
> > Follow up commits using this functionality are in 5.13 but not in
> > 5.10, so I believe we don't need this in 5.10, either?
> >
> > (Plus someone familiar with the code should check if we need "vboxsf:
> > Honor excl flag to the dir-inode create op" in 5.10; it may have same
> > problem).
>
> Actually those follow up commits fix an actual bug, so I was expecting
> the person who did the backport to also submit the rest of the set.
I only track Greg's failed messages when I find time for stable and
this one was one of those. So, no idea who has originally requested
this and why were the other two not requested.
--
Regards
Sudip
Hi,
On 8/17/21 5:52 PM, Sudip Mukherjee wrote:
> On Sun, Aug 15, 2021 at 2:57 PM Hans de Goede <[email protected]> wrote:
>>
>> Hi,
>>
>> On 8/13/21 9:31 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>>> commit ab0c29687bc7a890d1a86ac376b0b0fd78b2d9b6 upstream
>>>>
>>>> Make vboxsf_dir_create() optionally return the vboxsf-handle for
>>>> the created file. This is a preparation patch for adding atomic_open
>>>> support.
>>>
>>> Follow up commits using this functionality are in 5.13 but not in
>>> 5.10, so I believe we don't need this in 5.10, either?
>>>
>>> (Plus someone familiar with the code should check if we need "vboxsf:
>>> Honor excl flag to the dir-inode create op" in 5.10; it may have same
>>> problem).
>>
>> Actually those follow up commits fix an actual bug, so I was expecting
>> the person who did the backport to also submit the rest of the set.
>
> I only track Greg's failed messages when I find time for stable and
> this one was one of those. So, no idea who has originally requested
> this and why were the other two not requested.
I understand, thank you for backporting the 2 failing commits.
Regards,
Hans