MIPS: cm: Detect CM quirks from device tree
Subsystems (4)
Sasha Levin
maintainerPATCH 1/6 MIPS: cm: Detect CM quirks from device tree
From: Gregory CLEMENT <[email protected]>
[ Upstream commit e27fbe16af5cfc40639de4ced67d1a866a1953e9 ]
Some information that should be retrieved at runtime for the Coherence Manager can be either absent or wrong. This patch allows checking if some of this information is available from the device tree and updates the internal variable accordingly.
For now, only the compatible string associated with the broken HCI is being retrieved.
--- arch/mips/include/asm/mips-cm.h | 22 ++++++++++++++++++++++ arch/mips/kernel/mips-cm.c | 14 ++++++++++++++ 2 files changed, 36 insertions(+)
arch/mips/include/asm/mips-cm.h +22 -0
@@ -47,6 +47,16 @@ extern phys_addr_t __mips_cm_phys_base(void);*/ extern int mips_cm_is64; +/* +* mips_cm_is_l2_hci_broken - determine if HCI is broken +* +* Some CM reports show that Hardware Cache Initialization is +* complete, but in reality it's not the case. They also incorrectly +* indicate that Hardware Cache Initialization is supported. This +* flags allows warning about this broken feature. +*/ +extern bool mips_cm_is_l2_hci_broken; +/** * mips_cm_error_report - Report CM cache errors */
@@ -85,6 +95,18 @@ static inline bool mips_cm_present(void)#endif } +/** +* mips_cm_update_property - update property from the device tree +* +* Retrieve the properties from the device tree if a CM node exist and +* update the internal variable based on this. +*/ +#ifdef CONFIG_MIPS_CM +extern void mips_cm_update_property (void ); +#else +static void mips_cm_update_property (void ) {} +#endif +/** * mips_cm_has_l2sync - determine whether an L2-only sync region is present *
arch/mips/kernel/mips-cm.c +14 -0
@@ -5,6 +5,7 @@*/ #include <linux/errno.h> +#include <linux/of.h> #include <linux/percpu.h> #include <linux/spinlock.h>
@@ -14,6 +15,7 @@void __iomem *mips_gcr_base;void __iomem *mips_cm_l2sync_base;int mips_cm_is64; +bool mips_cm_is_l2_hci_broken;static char *cm2_tr[8 ] = {"mem" ,"gcr" ,"gic" ,"mmio" ,
@@ -238,6 +240,18 @@ static void mips_cm_probe_l2sync(void) mips_cm_l2sync_base =ioremap (addr,MIPS_CM_L2SYNC_SIZE ); } +void mips_cm_update_property (void ) +{ +struct device_node *cm_node; + + cm_node =of_find_compatible_node (of_root,NULL ,"mobileye,eyeq6-cm" ); +if (!cm_node) +return ; +pr_info ("HCI (Hardware Cache Init for the L2 cache) in GCR_L2_RAM_CONFIG from the CM3 is broken" ); + mips_cm_is_l2_hci_broken = true; +of_node_put (cm_node); +} +int mips_cm_probe (void ) {phys_addr_t addr;
Signature · 1 line
2.39.5
Sasha Levin
maintainerPATCH 2/6 crypto: null - Use spin lock instead of mutex
From: Herbert Xu <[email protected]>
[ Upstream commit dcc47a028c24e793ce6d6efebfef1a1e92f80297 ]
As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm.
--- crypto/crypto_null.c | 39 ++++++++++++++++++++++++++------------- 1 file changed, 26 insertions(+), 13 deletions(-)
crypto/crypto_null.c +26 -13
@@ -17,10 +17,10 @@#include <crypto/internal/skcipher.h> #include <linux/init.h> #include <linux/module.h> -#include <linux/mm.h> +#include <linux/spinlock.h> #include <linux/string.h> -static DEFINE_MUTEX (crypto_default_null_skcipher_lock); +static DEFINE_SPINLOCK (crypto_default_null_skcipher_lock);static struct crypto_sync_skcipher *crypto_default_null_skcipher;static int crypto_default_null_skcipher_refcnt;
@@ -152,23 +152,32 @@ MODULE_ALIAS_CRYPTO("cipher_null");struct crypto_sync_skcipher *crypto_get_default_null_skcipher (void ) { +struct crypto_sync_skcipher *ntfm =NULL ;struct crypto_sync_skcipher *tfm; -mutex_lock (&crypto_default_null_skcipher_lock); +spin_lock_bh (&crypto_default_null_skcipher_lock); tfm = crypto_default_null_skcipher;if (!tfm) { - tfm =crypto_alloc_sync_skcipher ("ecb(cipher_null)" ,0 ,0 ); -if (IS_ERR (tfm)) - goto unlock; - - crypto_default_null_skcipher = tfm; +spin_unlock_bh (&crypto_default_null_skcipher_lock); + + ntfm =crypto_alloc_sync_skcipher ("ecb(cipher_null)" ,0 ,0 ); +if (IS_ERR (ntfm)) +return ntfm; + +spin_lock_bh (&crypto_default_null_skcipher_lock); + tfm = crypto_default_null_skcipher; +if (!tfm) { + tfm = ntfm; + ntfm =NULL ; + crypto_default_null_skcipher = tfm; + } } crypto_default_null_skcipher_refcnt++; +spin_unlock_bh (&crypto_default_null_skcipher_lock); -unlock: -mutex_unlock (&crypto_default_null_skcipher_lock); +crypto_free_sync_skcipher (ntfm);return tfm; }
@@ -176,12 +185,16 @@ EXPORT_SYMBOL_GPL(crypto_get_default_null_skcipher);void crypto_put_default_null_skcipher (void ) { -mutex_lock (&crypto_default_null_skcipher_lock); +struct crypto_sync_skcipher *tfm =NULL ; + +spin_lock_bh (&crypto_default_null_skcipher_lock);if (!--crypto_default_null_skcipher_refcnt) { -crypto_free_sync_skcipher (crypto_default_null_skcipher); + tfm = crypto_default_null_skcipher; crypto_default_null_skcipher =NULL ; } -mutex_unlock (&crypto_default_null_skcipher_lock); +spin_unlock_bh (&crypto_default_null_skcipher_lock); + +crypto_free_sync_skcipher (tfm); }EXPORT_SYMBOL_GPL (crypto_put_default_null_skcipher);
Signature · 1 line
2.39.5
Sasha Levin
maintainerPATCH 3/6 HSI: ssi_protocol: Fix use after free vulnerability in ssi_protocol Driver Due to Race Condition
In reply to Sasha LevinFrom: Kaixin Wang <[email protected]>
[ Upstream commit e3f88665a78045fe35c7669d2926b8d97b892c11 ]
In the ssi_protocol_probe() function, &ssi->work is bound with ssip_xmit_work(), In ssip_pn_setup(), the ssip_pn_xmit() function within the ssip_pn_ops structure is capable of starting the work.
If we remove the module which will call ssi_protocol_remove() to make a cleanup, it will free ssi through kfree(ssi), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:
CPU0 CPU1
| ssip_xmit_work
ssi_protocol_remove |
kfree(ssi); |
| struct hsi_client *cl = ssi->cl;
| // use ssiFix it by ensuring that the work is canceled before proceeding with the cleanup in ssi_protocol_remove().
--- drivers/hsi/clients/ssi_protocol.c | 1 + 1 file changed, 1 insertion(+)
drivers/hsi/clients/ssi_protocol.c +1 -0
@@ -403,6 +403,7 @@ static void ssip_reset(struct hsi_client *cl)del_timer (&ssi->rx_wd);del_timer (&ssi->tx_wd);del_timer (&ssi->keep_alive); +cancel_work_sync (&ssi->work); ssi->main_state =0 ; ssi->send_state =0 ; ssi->recv_state =0 ;
Signature · 1 line
2.39.5
Sasha Levin
maintainerPATCH 4/6 clk: check for disabled clock-provider in of_clk_get_hw_from_clkspec()
In reply to Sasha LevinFrom: Heiko Stuebner <[email protected]>
[ Upstream commit b20150d499b3ee5c2d632fbc5ac94f98dd33accf ]
of_clk_get_hw_from_clkspec() checks all available clock-providers by comparing their of nodes to the one from the clkspec. If no matching clock provider is found, the function returns -EPROBE_DEFER to cause a re-check at a later date. If a matching clock provider is found, an authoritative answer can be retrieved from it whether the clock exists or not.
This does not take into account that the clock-provider may never appear, because it's node is disabled. This can happen when a clock is optional, provided by a separate block which never gets enabled.
One example of this happening is the rk3588's VOP, which has optional additional display clocks coming from PLLs inside the hdmiphy blocks. These can be used for better rates, but the system will also work without them.
The problem around that is described in the followups to[1]. As we already know the of node of the presumed clock provider, add a check via of_device_is_available() whether this is a "valid" device node. This prevents eternal defer loops.
--- drivers/clk/clk.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/clk/clk.c +4 -0
@@ -4858,6 +4858,10 @@ of_clk_get_hw_from_clkspec(struct of_phandle_args *clkspec)if (!clkspec)return ERR_PTR (-EINVAL ); +/* Check if node in clkspec is in disabled/fail state */ +if (!of_device_is_available (clkspec->np)) +return ERR_PTR (-ENOENT ); +mutex_lock (&of_clk_mutex);list_for_each_entry (provider, &of_clk_providers, link) {if (provider->node == clkspec->np) {
Signature · 1 line
2.39.5
Sasha Levin
maintainerPATCH 5/6 parisc: PDT: Fix missing prototype warning
In reply to Sasha LevinFrom: Yu-Chun Lin <[email protected]>
[ Upstream commit b899981750dcb958ceffa4462d903963ee494aa2 ]
As reported by the kernel test robot, the following error occurs:
arch/parisc/kernel/pdt.c:65:6: warning: no previous prototype for 'arch_report_meminfo' [-Wmissing-prototypes]
65 | void arch_report_meminfo(struct seq_file *m)
| ^~~~~~~~~~~~~~~~~~~
arch_report_meminfo() is declared in include/linux/proc_fs.h and only defined when CONFIG_PROC_FS is enabled. Wrap its definition in #ifdef CONFIG_PROC_FS to fix the -Wmissing-prototypes warning.
--- arch/parisc/kernel/pdt.c | 2 ++ 1 file changed, 2 insertions(+)
arch/parisc/kernel/pdt.c +2 -0
@@ -62,6 +62,7 @@ static unsigned long pdt_entry[MAX_PDT_ENTRIES] __page_aligned_bss;#define PDT_ADDR_PERM_ERR (pdt_type != PDT_PDC ? 2UL : 0UL)#define PDT_ADDR_SINGLE_ERR 1UL +#ifdef CONFIG_PROC_FS /* report PDT entries via /proc/meminfo */ void arch_report_meminfo (struct seq_file *m) {
@@ -73,6 +74,7 @@ void arch_report_meminfo(struct seq_file *m)seq_printf (m,"PDT_cur_entries: %7lu\n" , pdt_status.pdt_entries); } +#endif static int get_info_pat_new (void ) {
Signature · 1 line
2.39.5
Sasha Levin
maintainerPATCH 6/6 x86/Kconfig: Make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32
In reply to Sasha LevinFrom: Mateusz Jończyk <[email protected]>
[ Upstream commit d9f87802676bb23b9425aea8ad95c76ad9b50c6e ]
I was unable to find a good description of the ServerWorks CNB20LE chipset. However, it was probably exclusively used with the Pentium III processor (this CPU model was used in all references to it that I found where the CPU model was provided: dmesgs in [1] and [2];
[3] page 2; [4]-[7]).
As is widely known, the Pentium III processor did not support the 64-bit mode, support for which was introduced by Intel a couple of years later. So it is safe to assume that no systems with the CNB20LE chipset have amd64 and the CONFIG_PCI_CNB20LE_QUIRK may now depend on X86_32.
Additionally, I have determined that most computers with the CNB20LE chipset did have ACPI support and this driver was inactive on them. I have submitted a patch to remove this driver, but it was met with resistance [8].
[1] Jim Studt, Re: Problem with ServerWorks CNB20LE and lost interrupts
Linux Kernel Mailing List, https://lkml.org/lkml/2002/1/11/111
[2] RedHat Bug 665109 - e100 problems on old Compaq Proliant DL320
https://bugzilla.redhat.com/show_bug.cgi?id=665109
[3] R. Hughes-Jones, S. Dallison, G. Fairey, Performance Measurements on Gigabit Ethernet NICs and Server Quality Motherboards,
http://datatag.web.cern.ch/papers/pfldnet2003-rhj.doc
[4] "Hardware for Linux",
Probe #d6b5151873 of Intel STL2-bd A28808-302 Desktop Computer (STL2)
https://linux-hardware.org/?probe=d6b5151873[5] "Hardware for Linux", Probe #0b5d843f10 of Compaq ProLiant DL380
https://linux-hardware.org/?probe=0b5d843f10
[6] Ubuntu Forums, Dell Poweredge 2400 - Adaptec SCSI Bus AIC-7880
https://ubuntuforums.org/showthread.php?t=1689552
[7] Ira W. Snyder, "BISECTED: 2.6.35 (and -git) fail to boot: APIC problems"
https://lkml.org/lkml/2010/8/13/220
[8] Bjorn Helgaas, "Re: [PATCH] x86/pci: drop ServerWorks / Broadcom CNB20LE PCI host bridge driver"
https://lore.kernel.org/lkml/20220318165535.GA840063@bhelgaas/T/
--- arch/x86/Kconfig | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
arch/x86/Kconfig +10 -2
@@ -2766,13 +2766,21 @@ config MMCONF_FAM10H depends on X86_64 && PCI_MMCONFIG && ACPI config PCI_CNB20LE_QUIRK - bool "Read CNB20LE Host Bridge Windows" if EXPERT - depends on PCI + bool "Read PCI host bridge windows from the CNB20LE chipset" if EXPERT + depends on X86_32 && PCI help Read the PCI windows out of the CNB20LE host bridge. This allows PCI hotplug to work on systems with the CNB20LE chipset which do not have ACPI. + The ServerWorks (later Broadcom) CNB20LE was a chipset designed + most probably only for Pentium III. + + To find out if you have such a chipset, search for a PCI device with + 1166:0009 PCI IDs, for example by executing + lspci -nn | grep '1166:0009' + The code is inactive if there is none. + There's no public spec for this chipset, and this functionality is known to be incomplete.
Signature · 1 line
2.39.5