Hi,
commit ab6f762f0f53 ("printk: queue wake_up_klogd irq_work only if per-CPU
areas are ready") fixes a critical problem introduced with commit
1b710b1b10ef ("char/random: silence a lockdep splat with printk()").
Since commit 1b710b1b10ef has been applied to v5.4.y, commit ab6f762f0f53
needs to be applied as well.
An alternative might be to revert commit 1b710b1b10ef from v5.4.y, as
it was done for older kernel branches. However, we found that ab6f762f0f53
applies cleanly to v5.4.y and fixes the problem, so applying the fix
is probably a better solution.
Commit ab6f762f0f53 also needs to be applied to v5.6.y.
Thanks,
Guenter
From: Shubhrajyoti Datta <shubhrajyoti.datta(a)xilinx.com>
Update the console index. Once the serial node is found update it to the
console index.
Fixes: 18cc7ac8a28e ("Revert "serial: uartps: Register own uart console and driver structures"")
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta(a)xilinx.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Michal Simek <michal.simek(a)xilinx.com>
---
Greg: Would be good if you can take this patch to 5.7 and also to stable
trees.
---
drivers/tty/serial/xilinx_uartps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 672cfa075e28..b9d672af8b65 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1465,6 +1465,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
cdns_uart_uart_driver.nr = CDNS_UART_NR_PORTS;
#ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE
cdns_uart_uart_driver.cons = &cdns_uart_console;
+ cdns_uart_console.index = id;
#endif
rc = uart_register_driver(&cdns_uart_uart_driver);
--
2.26.2
Commit a408e4a86b36 ("ima: open a new file instance if no read
permissions") tries to create a new file descriptor to calculate a file
digest if the file has not been opened with O_RDONLY flag. However, if a
new file descriptor cannot be obtained, it sets the FMODE_READ flag to
file->f_flags instead of file->f_mode.
This patch fixes this issue by replacing f_flags with f_mode as it was
before that commit.
Changelog
v1:
- fix comment for f_mode change (suggested by Mimi)
- rename modified_flags variable to modified_mode (suggested by Mimi)
Cc: stable(a)vger.kernel.org # 4.20.x
Fixes: a408e4a86b36 ("ima: open a new file instance if no read permissions")
Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com>
---
security/integrity/ima/ima_crypto.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 5201f5ec2ce4..f3a7f4eb1fc1 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -537,7 +537,7 @@ int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash)
loff_t i_size;
int rc;
struct file *f = file;
- bool new_file_instance = false, modified_flags = false;
+ bool new_file_instance = false, modified_mode = false;
/*
* For consistency, fail file's opened with the O_DIRECT flag on
@@ -557,13 +557,13 @@ int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash)
f = dentry_open(&file->f_path, flags, file->f_cred);
if (IS_ERR(f)) {
/*
- * Cannot open the file again, lets modify f_flags
+ * Cannot open the file again, lets modify f_mode
* of original and continue
*/
pr_info_ratelimited("Unable to reopen file for reading.\n");
f = file;
- f->f_flags |= FMODE_READ;
- modified_flags = true;
+ f->f_mode |= FMODE_READ;
+ modified_mode = true;
} else {
new_file_instance = true;
}
@@ -581,8 +581,8 @@ int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash)
out:
if (new_file_instance)
fput(f);
- else if (modified_flags)
- f->f_flags &= ~FMODE_READ;
+ else if (modified_mode)
+ f->f_mode &= ~FMODE_READ;
return rc;
}
--
2.17.1
----- Ursprüngliche Mail -----
> Von: "John Ogness" <john.ogness(a)linutronix.de>
> An: "richard" <richard(a)nod.at>
> CC: "linux-mtd" <linux-mtd(a)lists.infradead.org>, "linux-kernel" <linux-kernel(a)vger.kernel.org>
> Gesendet: Mittwoch, 29. April 2020 16:56:31
> Betreff: Re: [PATCH] ubifs: Fix ubifs_tnc_lookup() usage in do_kill_orphans()
> Hi Richard,
>
> Could you CC this patch to stable? It fixes a serious problem that I am
> seeing on real devices (i.e. Linux not being able to mount its root
> filesystem after a power cut). Thanks.
Just checked again, better ask stable maintainers. :-)
Stable maintainers, can you please make sure this patch will make it
into stable?
The upstream commit is:
4ab25ac8b2b5 ("ubifs: Fix ubifs_tnc_lookup() usage in do_kill_orphans()")
I always thought havings a Fixes-Tag is enough to make sure it will
get picked up. Isn't this the case?
Thanks,
//richard
> John Ogness
>
> On 2020-01-19, Richard Weinberger <richard(a)nod.at> wrote:
>> Orphans are allowed to point to deleted inodes.
>> So -ENOENT is not a fatal error.
>>
>> Reported-by: Кочетков Максим <fido_max(a)inbox.ru>
>> Reported-and-tested-by: "Christian Berger" <Christian.Berger(a)de.bosch.com>
>> Fixes: ee1438ce5dc4 ("ubifs: Check link count of inodes when killing orphans.")
>> Signed-off-by: Richard Weinberger <richard(a)nod.at>
>> ---
>> fs/ubifs/orphan.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/ubifs/orphan.c b/fs/ubifs/orphan.c
>> index 54d6db61106f..2645917360b9 100644
>> --- a/fs/ubifs/orphan.c
>> +++ b/fs/ubifs/orphan.c
>> @@ -688,14 +688,14 @@ static int do_kill_orphans(struct ubifs_info *c, struct
>> ubifs_scan_leb *sleb,
>>
>> ino_key_init(c, &key1, inum);
>> err = ubifs_tnc_lookup(c, &key1, ino);
>> - if (err)
>> + if (err && err != -ENOENT)
>> goto out_free;
>>
>> /*
>> * Check whether an inode can really get deleted.
>> * linkat() with O_TMPFILE allows rebirth of an inode.
>> */
>> - if (ino->nlink == 0) {
>> + if (err == 0 && ino->nlink == 0) {
>> dbg_rcvry("deleting orphaned inode %lu",
> > (unsigned long)inum);
This is a note to let you know that I've just added the patch titled
USB: uas: add quirk for LaCie 2Big Quadra
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 9f04db234af691007bb785342a06abab5fb34474 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Wed, 29 Apr 2020 17:52:18 +0200
Subject: USB: uas: add quirk for LaCie 2Big Quadra
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This device needs US_FL_NO_REPORT_OPCODES to avoid going
through prolonged error handling on enumeration.
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Reported-by: Julian Groß <julian.g(a)posteo.de>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20200429155218.7308-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_uas.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
index 1b23741036ee..37157ed9a881 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -28,6 +28,13 @@
* and don't forget to CC: the USB development list <linux-usb(a)vger.kernel.org>
*/
+/* Reported-by: Julian Groß <julian.g(a)posteo.de> */
+UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
+ "LaCie",
+ "2Big Quadra USB3",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_REPORT_OPCODES),
+
/*
* Apricorn USB3 dongle sometimes returns "USBSUSBSUSBS" in response to SCSI
* commands in UAS mode. Observed with the 1.28 firmware; are there others?
--
2.26.2
Hi,
On Fri, 4 Oct 2019 Clement Leger <cleger(a)kalray.eu> wrote:
>
> Index of rvring is computed using pointer arithmetic. However, since
> rvring->rvdev->vring is the base of the vring array, computation
> of rvring idx should be reversed. It previously lead to writing at negative
> indices in the resource table.
>
> Signed-off-by: Clement Leger <cleger(a)kalray.eu>
> ---
> drivers/remoteproc/remoteproc_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Randomly stumbled upon this in a list of patches. This patch landed
in mainline as:
00a0eec59ddb remoteproc: Fix wrong rvring index computation
Should it be queued up for stable? I'm guessing:
Fixes: c0d631570ad5 ("remoteproc: set vring addresses in resource table")
-Doug