When locking a region, we currently clamp to a PAGE_SIZE as the minimum
lock region. While this is valid for Midgard, it is invalid for Bifrost,
where the minimum locking size is 8x larger than the 4k page size. Add a
hardware definition for the minimum lock region size (corresponding to
KBASE_LOCK_REGION_MIN_SIZE_LOG2 in kbase) and respect it.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig(a)collabora.com>
Tested-by: Chris Morgan <macromorgan(a)hotmail.com>
Reviewed-by: Steven Price <steven.price(a)arm.com>
Cc: <stable(a)vger.kernel.org>
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_regs.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 3a795273e505..dfe5f1d29763 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -66,7 +66,7 @@ static void lock_region(struct panfrost_device *pfdev, u32 as_nr,
/* The size is encoded as ceil(log2) minus(1), which may be calculated
* with fls. The size must be clamped to hardware bounds.
*/
- size = max_t(u64, size, PAGE_SIZE);
+ size = max_t(u64, size, AS_LOCK_REGION_MIN_SIZE);
region_width = fls64(size - 1) - 1;
region |= region_width;
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h b/drivers/gpu/drm/panfrost/panfrost_regs.h
index 1940ff86e49a..6c5a11ef1ee8 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -316,6 +316,8 @@
#define AS_FAULTSTATUS_ACCESS_TYPE_READ (0x2 << 8)
#define AS_FAULTSTATUS_ACCESS_TYPE_WRITE (0x3 << 8)
+#define AS_LOCK_REGION_MIN_SIZE (1ULL << 15)
+
#define gpu_write(dev, reg, data) writel(data, dev->iomem + reg)
#define gpu_read(dev, reg) readl(dev->iomem + reg)
--
2.30.2
Gianluca Anzolin <gianluca(a)sottospazio.it> wrote:
[ CC stable ]
> I'm writing to request a backport of the following commit:
>
> 2e34328b396a netfilter: nft_exthdr: fix endianness of tcp option cast
> to the stable version of Linux v5.4.
Hello stable maintainers, can you please pick this change
for 5.4, 4.19 and 4.14?
It applies cleanly to all of those branches.
I'll leave rest as full-quote for context.
> This bugfix never landed to Linux v5.4: a later similar endianness bugfix
> (b428336676db) instead did (see commit 666d1d1a0584).
>
> The aforementioned commit fixes an endianness bug in the mangling of the MSS
> tcp option for nftables.
>
> This bug bites hard big-endian routers (MIPS for example) running the PPPoE
> stack and nftables.
>
> The following rule:
>
> nft add rule ip filter forward tcp flags syn tcp option maxseg size set
> rt mtu
>
> instead of changing the MSS value the one in the routing cache, ZEROES it,
> disrupting the tcp connections.
>
> A backport would be nice because Linux v5.4 is the release used in the
> upcoming stable release of OpenWRT (21.02).
>
> I already submitted a bug-report to OpenWRT a few weeks ago but I've got no
> answer yet maybe because they still use iptables as the default netfilter
> tool, even if they offer nftables as an alternative.
>
> Still I think this bug should be fixed in the stable versions of the kernel.
>
> This way it will also come to OpenWRT when they update the kernel to the
> latest minor version, even if the maintainers don't see the my bug report is
> ignored.
>
> I'd like to thank you for the attention you paid to this message even if I
> probably didn't follow the right process for reporting the problem.
>
> Regards,
>
> Gianluca Anzolin
From: Jens Axboe <axboe(a)kernel.dk>
[ upstream commit 21f965221e7c42609521342403e8fb91b8b3e76e ]
If an SQPOLL based ring is newly created and an application issues an
io_uring_enter(2) system call on it, then we can return a spurious
-EOWNERDEAD error. This happens because there's nothing to submit, and
if the caller doesn't specify any other action, the initial error
assignment of -EOWNERDEAD never gets overwritten. This causes us to
return it directly, even if it isn't valid.
Move the error assignment into the actual failure case instead.
Cc: stable(a)vger.kernel.org
Fixes: d9d05217cb69 ("io_uring: stop SQPOLL submit on creator's death")
Reported-by: Sherlock Holo sherlockya(a)gmail.com
Link: https://github.com/axboe/liburing/issues/413
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com>
---
fs/io_uring.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index ed641dca7957..8492b4e7c4d7 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -9078,9 +9078,10 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit,
if (ctx->flags & IORING_SETUP_SQPOLL) {
io_cqring_overflow_flush(ctx, false, NULL, NULL);
- ret = -EOWNERDEAD;
- if (unlikely(ctx->sqo_dead))
+ if (unlikely(ctx->sqo_dead)) {
+ ret = -EOWNERDEAD;
goto out;
+ }
if (flags & IORING_ENTER_SQ_WAKEUP)
wake_up(&ctx->sq_data->wait);
if (flags & IORING_ENTER_SQ_WAIT) {
--
2.32.0
From: Jens Axboe <axboe(a)kernel.dk>
[ upstream commit a30f895ad3239f45012e860d4f94c1a388b36d14 ]
We currently check for ret != 0 to indicate error, but '1' is a valid
return and just indicates that the allocation succeeded with a wrap.
Correct the check to be for < 0, like it was before the xarray
conversion.
Cc: stable(a)vger.kernel.org
Fixes: 61cf93700fe6 ("io_uring: Convert personality_idr to XArray")
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com>
---
fs/io_uring.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 8492b4e7c4d7..108b0ed31c11 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -9602,11 +9602,12 @@ static int io_register_personality(struct io_ring_ctx *ctx)
ret = xa_alloc_cyclic(&ctx->personalities, &id, (void *)iod,
XA_LIMIT(0, USHRT_MAX), &ctx->pers_next, GFP_KERNEL);
- if (!ret)
- return id;
- put_cred(iod->creds);
- kfree(iod);
- return ret;
+ if (ret < 0) {
+ put_cred(iod->creds);
+ kfree(iod);
+ return ret;
+ }
+ return id;
}
static int io_register_restrictions(struct io_ring_ctx *ctx, void __user *arg,
--
2.32.0
This reverts commit 3c18e9baee0ef97510dcda78c82285f52626764b.
These devices do not appear to send a zero-length packet when the
transfer size is a multiple of the bulk-endpoint max-packet size. This
means that incoming data may not be processed by the driver until a
short packet is received or the receive buffer is full.
Revert back to using endpoint-sized receive buffers to avoid stalled
reads.
Reported-by: Paul Größel <pb.g(a)gmx.de>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=214131
Fixes: 3c18e9baee0e ("USB: serial: ch341: fix character loss at high transfer rates")
Cc: stable(a)vger.kernel.org
Cc: Willy Tarreau <w(a)1wt.eu>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/usb/serial/ch341.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index 8a521b5ea769..2db917eab799 100644
--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -851,7 +851,6 @@ static struct usb_serial_driver ch341_device = {
.owner = THIS_MODULE,
.name = "ch341-uart",
},
- .bulk_in_size = 512,
.id_table = id_table,
.num_ports = 1,
.open = ch341_open,
--
2.31.1