From: Juergen Gross jgross@suse.com
[ Upstream commit 897919ad8b42eb8222553838ab82414a924694aa ]
This configuration option provides a misc device as an API to userspace. Make this API usable without having to select the module as a transitive dependency.
This also fixes an issue where localyesconfig would select CONFIG_XEN_PRIVCMD=m because it was not visible and defaulted to building as module.
[boris: clarified help message per Jan's suggestion]
Based-on-patch-by: Thomas Weißschuh linux@weissschuh.net Signed-off-by: Juergen Gross jgross@suse.com Link: https://lore.kernel.org/r/20211116143323.18866-1-jgross@suse.com Reviewed-by: Jan Beulich jbeulich@suse.com Reviewed-by: Thomas Weißschuh linux@weissschuh.net Signed-off-by: Boris Ostrovsky boris.ostrovsky@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/xen/Kconfig | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 3a14948269b1e..59f862350a6ec 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -199,9 +199,15 @@ config XEN_SCSI_BACKEND if guests need generic access to SCSI devices.
config XEN_PRIVCMD - tristate + tristate "Xen hypercall passthrough driver" depends on XEN default m + help + The hypercall passthrough driver allows privileged user programs to + perform Xen hypercalls. This driver is normally required for systems + running as Dom0 to perform privileged operations, but in some + disaggregated Xen setups this driver might be needed for other + domains, too.
config XEN_STUB bool "Xen stub drivers"
From: Olga Kornievskaia kolga@netapp.com
[ Upstream commit ea027cb2e1b59c76582af867b71d5c037fa6bb8e ]
When the client receives ERR_NOSPC on reply to CREATE_SESSION it leads to a client hanging in nfs_wait_client_init_complete(). Instead, complete and fail the client initiation with an EIO error which allows for the mount command to fail instead of hanging.
Signed-off-by: Olga Kornievskaia kolga@netapp.com Signed-off-by: Trond Myklebust trond.myklebust@hammerspace.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/nfs/nfs4state.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c index ef3ed2b1fd278..9e872db0f70ea 100644 --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -1843,6 +1843,10 @@ static int nfs4_handle_reclaim_lease_error(struct nfs_client *clp, int status) dprintk("%s: exit with error %d for server %s\n", __func__, -EPROTONOSUPPORT, clp->cl_hostname); return -EPROTONOSUPPORT; + case -ENOSPC: + if (clp->cl_cons_state == NFS_CS_SESSION_INITING) + nfs_mark_client_ready(clp, -EIO); + return -EIO; case -NFS4ERR_NOT_SAME: /* FixMe: implement recovery * in nfs4_exchange_id */ default:
From: Ondrej Zary linux@zary.sk
[ Upstream commit 32bea35746097985c48cec836d5f557a3b66b60a ]
Iiyama ProLite T1931SAW does not work with Linux - input devices are created but cursor does not move.
It has the infamous 0eef:0001 ID which has been reused for various devices before.
It seems to require export_all_inputs = true.
Hopefully there are no HID devices using this ID that will break. It should not break non-HID devices (handled by usbtouchscreen).
Signed-off-by: Ondrej Zary linux@zary.sk Reviewed-by: Benjamin Tissoires benjamin.tissoires@redhat.com Signed-off-by: Jiri Kosina jkosina@suse.cz Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/hid/hid-multitouch.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index 5187f3975c655..852df842b9f66 100644 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -1245,6 +1245,11 @@ static const struct hid_device_id mt_devices[] = { MT_USB_DEVICE(USB_VENDOR_ID_CVTOUCH, USB_DEVICE_ID_CVTOUCH_SCREEN) },
+ /* eGalax devices (SAW) */ + { .driver_data = MT_CLS_EXPORT_ALL_INPUTS, + MT_USB_DEVICE(USB_VENDOR_ID_DWAV, + USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER) }, + /* eGalax devices (resistive) */ { .driver_data = MT_CLS_EGALAX, MT_USB_DEVICE(USB_VENDOR_ID_DWAV,
From: Helge Deller deller@gmx.de
[ Upstream commit 169d1a4a2adb2c246396c56aa2f9eec3868546f1 ]
The extru instruction leaves the most significant 32 bits of the target register in an undefined state on PA 2.0 systems. Provide a macro to safely use extru on 32- and 64-bit machines.
Suggested-by: John David Anglin dave.anglin@bell.net Signed-off-by: Helge Deller deller@gmx.de Signed-off-by: Sasha Levin sashal@kernel.org --- arch/parisc/include/asm/assembly.h | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/arch/parisc/include/asm/assembly.h b/arch/parisc/include/asm/assembly.h index b3069fd83468c..a6784745c571e 100644 --- a/arch/parisc/include/asm/assembly.h +++ b/arch/parisc/include/asm/assembly.h @@ -153,6 +153,17 @@ extrd,u \r, 63-(\sa), 64-(\sa), \t .endm
+ /* Extract unsigned for 32- and 64-bit + * The extru instruction leaves the most significant 32 bits of the + * target register in an undefined state on PA 2.0 systems. */ + .macro extru_safe r, p, len, t +#ifdef CONFIG_64BIT + extrd,u \r, 32+(\p), \len, \t +#else + extru \r, \p, \len, \t +#endif + .endm + /* load 32-bit 'value' into 'reg' compensating for the ldil * sign-extension when running in wide mode. * WARNING!! neither 'value' nor 'reg' can be expressions
Hi!
From: Helge Deller deller@gmx.de
[ Upstream commit 169d1a4a2adb2c246396c56aa2f9eec3868546f1 ]
The extru instruction leaves the most significant 32 bits of the target register in an undefined state on PA 2.0 systems. Provide a macro to safely use extru on 32- and 64-bit machines.
As the macro is not used by subsequent 4.4 patches, I don't believe this is suitable for -stable.
Best regards, Pavel
On 12/4/21 13:15, Pavel Machek wrote:
Hi!
From: Helge Deller deller@gmx.de
[ Upstream commit 169d1a4a2adb2c246396c56aa2f9eec3868546f1 ]
The extru instruction leaves the most significant 32 bits of the target register in an undefined state on PA 2.0 systems. Provide a macro to safely use extru on 32- and 64-bit machines.
As the macro is not used by subsequent 4.4 patches,
That's basically true, but in case we backport some patches later on, it's handy if it's already in.
I don't believe this is suitable for -stable.
Please note that I didn't added a backport-request in my original commit. I'm fine with any decision if it's either dropped or kept.
Helge
From: Jon Hunter jonathanh@nvidia.com
[ Upstream commit 5f719948b5d43eb39356e94e8d0b462568915381 ]
Commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT compatible") added a test to check that every SPI driver has a spi_device_id for each DT compatiable string defined by the driver and warns if the spi_device_id is missing. The spi_device_id is missing for the MMC SPI driver and the following warning is now seen.
WARNING KERN SPI driver mmc_spi has no spi_device_id for mmc-spi-slot
Fix this by adding the necessary spi_device_id.
Signed-off-by: Jon Hunter jonathanh@nvidia.com Link: https://lore.kernel.org/r/20211115113813.238044-1-jonathanh@nvidia.com Signed-off-by: Ulf Hansson ulf.hansson@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/mmc/host/mmc_spi.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c index b52489a67097e..a3e049248be8d 100644 --- a/drivers/mmc/host/mmc_spi.c +++ b/drivers/mmc/host/mmc_spi.c @@ -1523,6 +1523,12 @@ static int mmc_spi_remove(struct spi_device *spi) return 0; }
+static const struct spi_device_id mmc_spi_dev_ids[] = { + { "mmc-spi-slot"}, + { }, +}; +MODULE_DEVICE_TABLE(spi, mmc_spi_dev_ids); + static const struct of_device_id mmc_spi_of_match_table[] = { { .compatible = "mmc-spi-slot", }, {}, @@ -1534,6 +1540,7 @@ static struct spi_driver mmc_spi_driver = { .name = "mmc_spi", .of_match_table = mmc_spi_of_match_table, }, + .id_table = mmc_spi_dev_ids, .probe = mmc_spi_probe, .remove = mmc_spi_remove, };
From: Steve French stfrench@microsoft.com
[ Upstream commit 350f4a562e1ffc2e4869e3083dc9b0ec4bca6c3a ]
It is clearer to initialize rc at the beginning of the function.
Reported-by: kernel test robot lkp@intel.com Reported-by: Dan Carpenter dan.carpenter@oracle.com Reviewed-by: Paulo Alcantara (SUSE) pc@cjr.nz Signed-off-by: Steve French stfrench@microsoft.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/cifs/smb2pdu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 4ffd5e177288e..a8fcaee83d8f3 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -158,7 +158,7 @@ smb2_hdr_assemble(struct smb2_hdr *hdr, __le16 smb2_cmd /* command */ , static int smb2_reconnect(__le16 smb2_command, struct cifs_tcon *tcon) { - int rc; + int rc = 0; struct nls_table *nls_codepage; struct cifs_ses *ses; struct TCP_Server_Info *server;
From: Evan Green evgreen@chromium.org
[ Upstream commit 88a5045f176b78c33a269a30a7b146e99c550bd9 ]
snapshot_write() is inappropriately limiting the amount of data that can be written in cases where a partial page has already been written. For example, one would expect to be able to write 1 byte, then 4095 bytes to the snapshot device, and have both of those complete fully (since now we're aligned to a page again). But what ends up happening is we write 1 byte, then 4094/4095 bytes complete successfully.
The reason is that simple_write_to_buffer()'s second argument is the total size of the buffer, not the size of the buffer minus the offset. Since simple_write_to_buffer() accounts for the offset in its implementation, snapshot_write() can just pass the full page size directly down.
Signed-off-by: Evan Green evgreen@chromium.org Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- kernel/power/user.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/power/user.c b/kernel/power/user.c index f83c1876b39c0..67659e507747e 100644 --- a/kernel/power/user.c +++ b/kernel/power/user.c @@ -181,7 +181,7 @@ static ssize_t snapshot_write(struct file *filp, const char __user *buf, if (res <= 0) goto unlock; } else { - res = PAGE_SIZE - pg_offp; + res = PAGE_SIZE; }
if (!data_of(data->handle)) {
From: Vladimir Oltean vladimir.oltean@nxp.com
[ Upstream commit ec15baec3272bbec576f2ce7ce47765a8e9b7b1c ]
As opposed to event messages (Sync, PdelayReq etc) which require timestamping, general messages (Announce, FollowUp etc) do not. In PTP they are part of different streams of data.
IEEE 1588-2008 Annex D.2 "UDP port numbers" states that the UDP destination port assigned by IANA is 319 for event messages, and 320 for general messages. Yet the kernel seems to be missing the definition for general messages. This patch adds it.
Signed-off-by: Vladimir Oltean vladimir.oltean@nxp.com Acked-by: Richard Cochran richardcochran@gmail.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- include/linux/ptp_classify.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/linux/ptp_classify.h b/include/linux/ptp_classify.h index a079656b614cd..c0a02aa7ed9bd 100644 --- a/include/linux/ptp_classify.h +++ b/include/linux/ptp_classify.h @@ -45,6 +45,7 @@ #define PTP_CLASS_L4 (PTP_CLASS_IPV4 | PTP_CLASS_IPV6)
#define PTP_EV_PORT 319 +#define PTP_GEN_PORT 320 #define PTP_GEN_BIT 0x08 /* indicates general message, if set in message type */
#define OFF_PTP_SOURCE_UUID 22 /* PTPv1 only */
Hi!
[ Upstream commit ec15baec3272bbec576f2ce7ce47765a8e9b7b1c ]
As opposed to event messages (Sync, PdelayReq etc) which require timestamping, general messages (Announce, FollowUp etc) do not. In PTP they are part of different streams of data.
IEEE 1588-2008 Annex D.2 "UDP port numbers" states that the UDP destination port assigned by IANA is 319 for event messages, and 320 for general messages. Yet the kernel seems to be missing the definition for general messages. This patch adds it.
This does not fix any bug in 4.4, right? We do not need it in stable.
Best regards, Pavel
From: Guenter Roeck linux@roeck-us.net
[ Upstream commit 4eec7faf6775263d9e450ae7ee5bc4101d4a0bc9 ]
NTFS_RW code allocates page size dependent arrays on the stack. This results in build failures if the page size is 64k or larger.
fs/ntfs/aops.c: In function 'ntfs_write_mst_block': fs/ntfs/aops.c:1311:1: error: the frame size of 2240 bytes is larger than 2048 bytes
Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit book3s") this affects ppc:allmodconfig builds, but other architectures supporting page sizes of 64k or larger are also affected.
Increasing the maximum frame size for affected architectures just to silence this error does not really help. The frame size would have to be set to a really large value for 256k pages. Also, a large frame size could potentially result in stack overruns in this code and elsewhere and is therefore not desirable. Make NTFS_RW dependent on page sizes smaller than 64k instead.
Signed-off-by: Guenter Roeck linux@roeck-us.net Cc: Anton Altaparmakov anton@tuxera.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- fs/ntfs/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig index f5a868cc9152e..5b384ec44793f 100644 --- a/fs/ntfs/Kconfig +++ b/fs/ntfs/Kconfig @@ -51,6 +51,7 @@ config NTFS_DEBUG config NTFS_RW bool "NTFS write support" depends on NTFS_FS + depends on PAGE_SIZE_LESS_THAN_64KB help This enables the partial, but safe, write support in the NTFS driver.
Hi!
[ Upstream commit 4eec7faf6775263d9e450ae7ee5bc4101d4a0bc9 ]
NTFS_RW code allocates page size dependent arrays on the stack. This results in build failures if the page size is 64k or larger.
fs/ntfs/aops.c: In function 'ntfs_write_mst_block': fs/ntfs/aops.c:1311:1: error: the frame size of 2240 bytes is larger than 2048 bytes
Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit book3s") this affects ppc:allmodconfig builds, but other architectures supporting page sizes of 64k or larger are also affected.
NAK, this will disable NTFS_RW support in 4.4 entirely.
+++ b/fs/ntfs/Kconfig @@ -51,6 +51,7 @@ config NTFS_DEBUG config NTFS_RW bool "NTFS write support" depends on NTFS_FS
- depends on PAGE_SIZE_LESS_THAN_64KB help This enables the partial, but safe, write support in the NTFS driver.
AFAICT CONFIG_PAGE_SIZE_LESS_THAN_64KB is not present in 4.4 (and probably other) -stable kernels, nor it is queued to be added there.
Best regards, Pavel
linux-stable-mirror@lists.linaro.org
-
Helge Deller -
Pavel Machek -
Sasha Levin