5.19.12-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 141/207 net: ravb: Fix PHY state warning splat during system resume
In reply to Greg Kroah-HartmanFrom: Geert Uytterhoeven <[email protected]>
[ Upstream commit 4924c0cdce75575295f8fa682851fb8e5d619dd2 ]
Since commit 744d23c71af39c7d ("net: phy: Warn about incorrect mdio_bus_phy_resume() state"), a warning splat is printed during system resume with Wake-on-LAN disabled:
WARNING: CPU: 0 PID: 1197 at drivers/net/phy/phy_device.c:323 mdio_bus_phy_resume+0xbc/0xc8
As the Renesas Ethernet AVB driver already calls phy_{stop,start}() in its suspend/resume callbacks, it is sufficient to just mark the MAC responsible for managing the power state of the PHY.
--- drivers/net/ethernet/renesas/ravb_main.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/renesas/ravb_main.c +2 -0
@@ -1449,6 +1449,8 @@ static int ravb_phy_init(struct net_device *ndev)phy_remove_link_mode (phydev, ETHTOOL_LINK_MODE_100baseT_Half_BIT); } +/* Indicate that the MAC is responsible for managing PHY PM */ + phydev->mac_managed_pm = true;phy_attached_info (phydev);return 0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 142/207 net: sh_eth: Fix PHY state warning splat during system resume
In reply to Greg Kroah-HartmanFrom: Geert Uytterhoeven <[email protected]>
[ Upstream commit 6a1dbfefdae4f7809b3e277cc76785dac0ac1cd0 ]
Since commit 744d23c71af39c7d ("net: phy: Warn about incorrect mdio_bus_phy_resume() state"), a warning splat is printed during system resume with Wake-on-LAN disabled:
WARNING: CPU: 0 PID: 626 at drivers/net/phy/phy_device.c:323 mdio_bus_phy_resume+0xbc/0xe4
As the Renesas SuperH Ethernet driver already calls phy_{stop,start}() in its suspend/resume callbacks, it is sufficient to just mark the MAC responsible for managing the power state of the PHY.
--- drivers/net/ethernet/renesas/sh_eth.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/renesas/sh_eth.c +2 -0
@@ -2029,6 +2029,8 @@ static int sh_eth_phy_init(struct net_device *ndev)if (mdp->cd->register_type !=SH_ETH_REG_GIGABIT )phy_set_max_speed (phydev,SPEED_100 ); +/* Indicate that the MAC is responsible for managing PHY PM */ + phydev->mac_managed_pm = true;phy_attached_info (phydev);return 0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 143/207 gpio: tqmx86: fix uninitialized variable girq
In reply to Greg Kroah-HartmanFrom: Dongliang Mu <[email protected]>
[ Upstream commit 21a9acc162457402c74c5c1e16471fda6eb090c0 ]
The commit 924610607f19 ("gpio: tpmx86: Move PM device over to irq domain") adds a dereference of girq that may be uninitialized.
Fix this by moving irq_domain_set_pm_device into if true branch as suggested by Marc Zyngier.
--- drivers/gpio/gpio-tqmx86.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpio/gpio-tqmx86.c +2 -2
@@ -307,6 +307,8 @@ static int tqmx86_gpio_probe(struct platform_device *pdev) girq->default_type =IRQ_TYPE_NONE ; girq->handler = handle_simple_irq; girq->init_valid_mask = tqmx86_init_irq_valid_mask; + +irq_domain_set_pm_device (girq->domain, dev); } ret =devm_gpiochip_add_data (dev, chip, gpio);
@@ -315,8 +317,6 @@ static int tqmx86_gpio_probe(struct platform_device *pdev) goto out_pm_dis; } -irq_domain_set_pm_device (girq->domain, dev); -dev_info (dev,"GPIO functionality initialized with %d pins\n" , chip->ngpio);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 144/207 can: gs_usb: gs_can_open(): fix race dev->can.state condition
In reply to Greg Kroah-HartmanFrom: Marc Kleine-Budde <[email protected]>
[ Upstream commit 5440428b3da65408dba0241985acb7a05258b85e ]
The dev->can.state is set to CAN_STATE_ERROR_ACTIVE, after the device has been started. On busy networks the CAN controller might receive CAN frame between and go into an error state before the dev->can.state is assigned.
Assign dev->can.state before starting the controller to close the race window.
--- drivers/net/can/usb/gs_usb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/can/usb/gs_usb.c +2 -2
@@ -824,6 +824,7 @@ static int gs_can_open(struct net_device *netdev) flags |=GS_CAN_MODE_TRIPLE_SAMPLE ;/* finally start device */ + dev->can.state =CAN_STATE_ERROR_ACTIVE ; dm->mode =cpu_to_le32 (GS_CAN_MODE_START ); dm->flags =cpu_to_le32 (flags); rc = usb_control_msg(interface_to_usbdev(dev->iface),
@@ -835,13 +836,12 @@ static int gs_can_open(struct net_device *netdev)if (rc <0 ) {netdev_err (netdev,"Couldn't start device (err=%d)\n" , rc);kfree (dm); + dev->can.state =CAN_STATE_STOPPED ;return rc; }kfree (dm); - dev->can.state =CAN_STATE_ERROR_ACTIVE ; - parent->active_channels++;if (!(dev->can.ctrlmode &CAN_CTRLMODE_LISTENONLY ))netif_start_queue (netdev);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 145/207 perf stat: Fix BPF program section name
In reply to Greg Kroah-HartmanFrom: Namhyung Kim <[email protected]>
[ Upstream commit 0d77326c3369e255715ed2440a78894ccc98dd69 ]
It seems the recent libbpf got more strict about the section name. I'm seeing a failure like this:
$ sudo ./perf stat -a --bpf-counters --for-each-cgroup ^. sleep 1 libbpf: prog 'on_cgrp_switch': missing BPF prog type, check ELF section name 'perf_events' libbpf: prog 'on_cgrp_switch': failed to load: -22 libbpf: failed to load object 'bperf_cgroup_bpf' libbpf: failed to load BPF skeleton 'bperf_cgroup_bpf': -22 Failed to load cgroup skeleton
The section name should be 'perf_event' (without the trailing 's'). Although it's related to the libbpf change, it'd be better fix the section name in the first place.
--- tools/perf/util/bpf_skel/bperf_cgroup.bpf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/util/bpf_skel/bperf_cgroup.bpf.c +1 -1
@@ -176,7 +176,7 @@ static int bperf_cgroup_count(void) }// This will be attached to cgroup-switches event for each cpu -SEC("perf_events") +SEC("perf_event")int BPF_PROG (on_cgrp_switch ) {return bperf_cgroup_count ();
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 146/207 perf stat: Fix cpu map index in bperf cgroup code
In reply to Greg Kroah-HartmanFrom: Namhyung Kim <[email protected]>
[ Upstream commit 3da35231d9e4949c4ae40e3ce653e7c468455d55 ]
The previous cpu map introduced a bug in the bperf cgroup counter. This results in a failure when user gives a partial cpu map starting from non-zero.
$ sudo ./perf stat -C 1-2 --bpf-counters --for-each-cgroup ^. sleep 1
libbpf: prog 'on_cgrp_switch': failed to create BPF link for perf_event FD 0:
-9 (Bad file descriptor)
Failed to attach cgroup programTo get the FD of an evsel, it should use a map index not the CPU number.
--- tools/perf/util/bpf_counter_cgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/perf/util/bpf_counter_cgroup.c +2 -2
@@ -95,7 +95,7 @@ static int bperf_load_program(struct evlist *evlist)perf_cpu_map__for_each_cpu (cpu, i, evlist->core.all_cpus) { link =bpf_program__attach_perf_event (skel->progs.on_cgrp_switch, -FD (cgrp_switch, cpu.cpu)); +FD (cgrp_switch, i));if (IS_ERR (link)) {pr_err ("Failed to attach cgroup program\n" ); err =PTR_ERR (link);
@@ -123,7 +123,7 @@ static int bperf_load_program(struct evlist *evlist) map_fd =bpf_map__fd (skel->maps.events);perf_cpu_map__for_each_cpu (cpu, j, evlist->core.all_cpus) { -int fd =FD (evsel, cpu.cpu); +int fd =FD (evsel, j);__u32 idx = evsel->core.idx * total_cpus + cpu.cpu; err = bpf_map_update_elem(map_fd, &idx, &fd,
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 147/207 perf jit: Include program header in ELF files
In reply to Greg Kroah-HartmanFrom: Lieven Hey <[email protected]>
[ Upstream commit babd04386b1df8c364cdaa39ac0e54349502e1e5 ]
The missing header makes it hard for programs like elfutils to open these files.
--- tools/perf/util/genelf.c | 14 ++++++++++++++ tools/perf/util/genelf.h | 4 ++++ 2 files changed, 18 insertions(+)
tools/perf/util/genelf.c +14 -0
@@ -251,6 +251,7 @@ jit_write_elf(int fd, uint64_t load_addr, const char *sym,Elf_Data *d;Elf_Scn *scn;Elf_Ehdr *ehdr; +Elf_Phdr *phdr;Elf_Shdr *shdr;uint64_t eh_frame_base_offset;char *strsym =NULL ;
@@ -285,6 +286,19 @@ jit_write_elf(int fd, uint64_t load_addr, const char *sym, ehdr->e_version =EV_CURRENT ; ehdr->e_shstrndx= unwinding ?4 :2 ;/* shdr index for section name */ +/* +* setup program header +*/ + phdr =elf_newphdr (e,1 ); + phdr[0 ].p_type =PT_LOAD ; + phdr[0 ].p_offset =0 ; + phdr[0 ].p_vaddr =0 ; + phdr[0 ].p_paddr =0 ; + phdr[0 ].p_filesz = csize; + phdr[0 ].p_memsz = csize; + phdr[0 ].p_flags =PF_X |PF_R ; + phdr[0 ].p_align =8 ; +/* * setup text section */
tools/perf/util/genelf.h +4 -0
@@ -53,8 +53,10 @@ int jit_add_debug_info(Elf *e, uint64_t code_addr, void *debug, int nr_debug_ent#if GEN_ELF_CLASS ==ELFCLASS64 #define elf_newehdr elf64_newehdr +#define elf_newphdr elf64_newphdr#define elf_getshdr elf64_getshdr#define Elf_Ehdr Elf64_Ehdr +#define Elf_Phdr Elf64_Phdr#define Elf_Shdr Elf64_Shdr#define Elf_Sym Elf64_Sym#define ELF_ST_TYPE (a) ELF64_ST_TYPE(a)
@@ -62,8 +64,10 @@ int jit_add_debug_info(Elf *e, uint64_t code_addr, void *debug, int nr_debug_ent#define ELF_ST_VIS (a) ELF64_ST_VISIBILITY(a)#else #define elf_newehdr elf32_newehdr +#define elf_newphdr elf32_newphdr#define elf_getshdr elf32_getshdr#define Elf_Ehdr Elf32_Ehdr +#define Elf_Phdr Elf32_Phdr#define Elf_Shdr Elf32_Shdr#define Elf_Sym Elf32_Sym#define ELF_ST_TYPE (a) ELF32_ST_TYPE(a)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 148/207 perf kcore_copy: Do not check /proc/modules is unchanged
In reply to Greg Kroah-HartmanFrom: Adrian Hunter <[email protected]>
[ Upstream commit 5b427df27b94aec1312cace48a746782a0925c53 ]
/proc/kallsyms and /proc/modules are compared before and after the copy in order to ensure no changes during the copy.
However /proc/modules also might change due to reference counts changing even though that does not make any difference.
Any modules loaded or unloaded should be visible in changes to kallsyms, so it is not necessary to check /proc/modules also anyway.
Remove the comparison checking that /proc/modules is unchanged.
--- tools/perf/util/symbol-elf.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
tools/perf/util/symbol-elf.c +2 -5
@@ -2102,8 +2102,8 @@ static int kcore_copy__compare_file(const char *from_dir, const char *to_dir,* unusual. One significant peculiarity is that the mapping (start -> pgoff) * is not the same for the kernel map and the modules map. That happens because * the data is copied adjacently whereas the original kcore has gaps. Finally, -* kallsyms and modules files are compared with their copies to check that -* modules have not been loaded or unloaded while the copies were taking place. +* kallsyms file is compared with its copy to check that modules have not been +* loaded or unloaded while the copies were taking place. * * Return: %0 on success, %-1 on failure. */
@@ -2166,9 +2166,6 @@ int kcore_copy(const char *from_dir, const char *to_dir) goto out_extract_close; } -if (kcore_copy__compare_file (from_dir, to_dir,"modules" )) - goto out_extract_close; -if (kcore_copy__compare_file (from_dir, to_dir,"kallsyms" )) goto out_extract_close;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 149/207 perf tools: Honor namespace when synthesizing build-ids
In reply to Greg Kroah-HartmanFrom: Namhyung Kim <[email protected]>
[ Upstream commit 999e4eaa4b3691acf85d094836260ec4b66c74fd ]
It needs to enter the namespace before reading a file.
--- tools/perf/util/synthetic-events.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
tools/perf/util/synthetic-events.c +14 -3
@@ -367,13 +367,24 @@ static void perf_record_mmap2__read_build_id(struct perf_record_mmap2 *event, bool is_kernel) {struct build_id bid; +struct nsinfo *nsi; +struct nscookie nc;int rc; -if (is_kernel) +if (is_kernel) { rc =sysfs__read_build_id ("/sys/kernel/notes" , &bid); -else - rc =filename__read_build_id (event->filename, &bid) >0 ?0 :-1 ; + goto out; + } + + nsi =nsinfo__new (event->pid); +nsinfo__mountns_enter (nsi, &nc); + rc =filename__read_build_id (event->filename, &bid) >0 ?0 :-1 ; + +nsinfo__mountns_exit (&nc); +nsinfo__put (nsi); + +out:if (rc ==0 ) {memcpy (event->build_id, bid.data,sizeof (bid.data)); event->build_id_size = (u8 ) bid.size;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 150/207 drm/mediatek: dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()
In reply to Greg Kroah-HartmanFrom: Nícolas F. R. A. Prado <[email protected]>
[ Upstream commit 90144dd8b0d137d9e78ef34b3c418e51a49299ad ]
As the comment right before the mtk_dsi_stop() call advises, mtk_dsi_stop() should only be called after mtk_drm_crtc_atomic_disable(). That's because that function calls drm_crtc_wait_one_vblank(), which requires the vblank irq to be enabled.
Previously mtk_dsi_stop(), being in mtk_dsi_poweroff() and guarded by a refcount, would only be called at the end of mtk_drm_crtc_atomic_disable(), through the call to mtk_crtc_ddp_hw_fini(). Commit cde7e2e35c28 ("drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs") moved the mtk_dsi_stop() call to mtk_output_dsi_disable(), causing it to be called before mtk_drm_crtc_atomic_disable(), and consequently generating vblank timeout warnings during suspend.
Move the mtk_dsi_stop() call back to mtk_dsi_poweroff() so that we have a working vblank irq during mtk_drm_crtc_atomic_disable() and stop getting vblank timeout warnings.
--- drivers/gpu/drm/mediatek/mtk_dsi.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-)
drivers/gpu/drm/mediatek/mtk_dsi.c +10 -11
@@ -685,6 +685,16 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)if (--dsi->refcount !=0 )return ; +/* +* mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since +* mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), +* which needs irq for vblank, and mtk_dsi_stop() will disable irq. +* mtk_dsi_start() needs to be called in mtk_output_dsi_enable(), +* after dsi is fully set. +*/ +mtk_dsi_stop (dsi); + +mtk_dsi_switch_to_cmd_mode (dsi,VM_DONE_INT_FLAG ,500 );mtk_dsi_reset_engine (dsi);mtk_dsi_lane0_ulp_mode_enter (dsi);mtk_dsi_clk_ulp_mode_enter (dsi);
@@ -735,17 +745,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)if (!dsi->enabled)return ; -/* -* mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since -* mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), -* which needs irq for vblank, and mtk_dsi_stop() will disable irq. -* mtk_dsi_start() needs to be called in mtk_output_dsi_enable(), -* after dsi is fully set. -*/ -mtk_dsi_stop (dsi); - -mtk_dsi_switch_to_cmd_mode (dsi,VM_DONE_INT_FLAG ,500 ); - dsi->enabled = false; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 151/207 ice: Fix ice_xdp_xmit() when XDP TX queue number is not sufficient
In reply to Greg Kroah-HartmanFrom: Larysa Zaremba <[email protected]>
[ Upstream commit 114f398d48c571bb628187a7b2dd42695156781f ]
The original patch added the static branch to handle the situation, when assigning an XDP TX queue to every CPU is not possible, so they have to be shared.
However, in the XDP transmit handler ice_xdp_xmit(), an error was returned in such cases even before static condition was checked, thus making queue sharing still impossible.
--- drivers/net/ethernet/intel/ice/ice_txrx.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/ice/ice_txrx.c +4 -1
@@ -610,7 +610,7 @@ ice_xdp_xmit(struct net_device *dev, int n, struct xdp_frame **frames,if (test_bit (ICE_VSI_DOWN , vsi->state))return -ENETDOWN ; -if (!ice_is_xdp_ena_vsi (vsi) || queue_index >= vsi->num_xdp_txq) +if (!ice_is_xdp_ena_vsi (vsi))return -ENXIO ;if (unlikely (flags & ~XDP_XMIT_FLAGS_MASK ))
@@ -621,6 +621,9 @@ ice_xdp_xmit(struct net_device *dev, int n, struct xdp_frame **frames, xdp_ring = vsi->xdp_rings[queue_index];spin_lock (&xdp_ring->tx_lock); }else { +/* Generally, should not happen */ +if (unlikely (queue_index >= vsi->num_xdp_txq)) +return -ENXIO ; xdp_ring = vsi->xdp_rings[queue_index]; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 152/207 net/smc: Stop the CLC flow if no link to map buffers on
In reply to Greg Kroah-HartmanFrom: Wen Gu <[email protected]>
[ Upstream commit e738455b2c6dcdab03e45d97de36476f93f557d2 ]
There might be a potential race between SMC-R buffer map and link group termination.
smc_smcr_terminate_all() | smc_connect_rdma()
--------------------------------------------------------------
| smc_conn_create()
for links in smcibdev |
schedule links down |
| smc_buf_create()
| \- smcr_buf_map_usable_links()
| \- no usable links found,
| (rmb->mr = NULL)
|
| smc_clc_send_confirm()
| \- access conn->rmb_desc->mr[]->rkey
| (panic)During reboot and IB device module remove, all links will be set down and no usable links remain in link groups. In such situation smcr_buf_map_usable_links() should return an error and stop the CLC flow accessing to uninitialized mr.
--- net/smc/smc_core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/smc/smc_core.c +4 -1
@@ -2148,7 +2148,7 @@ static struct smc_buf_desc *smcr_new_buf_create(struct smc_link_group *lgr,static int smcr_buf_map_usable_links (struct smc_link_group *lgr,struct smc_buf_desc *buf_desc,bool is_rmb) { -int i, rc =0 ; +int i, rc =0 , cnt =0 ;/* protect against parallel link reconfiguration */ mutex_lock (&lgr->llc_conf_mutex);
@@ -2161,9 +2161,12 @@ static int smcr_buf_map_usable_links(struct smc_link_group *lgr, rc = -ENOMEM ; goto out; } + cnt++; } out:mutex_unlock (&lgr->llc_conf_mutex); +if (!rc && !cnt) + rc = -EINVAL ;return rc; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 153/207 net: phy: micrel: fix shared interrupt on LAN8814
In reply to Greg Kroah-HartmanFrom: Michael Walle <[email protected]>
[ Upstream commit 2002fbac743b6e2391b4ed50ad9eb626768dd78a ]
Since commit ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy") the handler always returns IRQ_HANDLED, except in an error case. Before that commit, the interrupt status register was checked and if it was empty, IRQ_NONE was returned. Restore that behavior to play nice with the interrupt line being shared with others.
--- drivers/net/phy/micrel.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
drivers/net/phy/micrel.c +12 -6
@@ -2662,16 +2662,19 @@ static int lan8804_config_init(struct phy_device *phydev)static irqreturn_t lan8814_handle_interrupt (struct phy_device *phydev) {int irq_status, tsu_irq_status; +int ret =IRQ_NONE ; irq_status =phy_read (phydev,LAN8814_INTS ); -if (irq_status >0 && (irq_status &LAN8814_INT_LINK )) -phy_trigger_machine (phydev); -if (irq_status <0 ) {phy_error (phydev);return IRQ_NONE ; } +if (irq_status &LAN8814_INT_LINK ) { +phy_trigger_machine (phydev); + ret =IRQ_HANDLED ; + } +while (1 ) { tsu_irq_status =lanphy_read_page_reg (phydev,4 ,LAN8814_INTR_STS_REG );
@@ -2680,12 +2683,15 @@ static irqreturn_t lan8814_handle_interrupt(struct phy_device *phydev) (tsu_irq_status & (LAN8814_INTR_STS_REG_1588_TSU0_ | LAN8814_INTR_STS_REG_1588_TSU1_ | LAN8814_INTR_STS_REG_1588_TSU2_ | - LAN8814_INTR_STS_REG_1588_TSU3_))) + LAN8814_INTR_STS_REG_1588_TSU3_))) { lan8814_handle_ptp_interrupt(phydev); - else + ret = IRQ_HANDLED; + } else {break ; + } } -return IRQ_HANDLED ; + +return ret; }static int lan8814_ack_interrupt (struct phy_device *phydev)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 154/207 bonding: fix NULL deref in bond_rr_gen_slave_id
In reply to Greg Kroah-HartmanFrom: Jonathan Toppins <[email protected]>
[ Upstream commit 0e400d602f46360752e4b32ce842dba3808e15e6 ]
Fix a NULL dereference of the struct bonding.rr_tx_counter member because if a bond is initially created with an initial mode != zero (Round Robin) the memory required for the counter is never created and when the mode is changed there is never any attempt to verify the memory is allocated upon switching modes.
This causes the following Oops on an aarch64 machine:
[ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000
[ 334.694703] Mem abort info:
[ 334.697486] ESR = 0x0000000096000004
[ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits
[ 334.706536] SET = 0, FnV = 0
[ 334.709579] EA = 0, S1PTW = 0
[ 334.712719] FSC = 0x04: level 0 translation fault
[ 334.717586] Data abort info:
[ 334.720454] ISV = 0, ISS = 0x00000004
[ 334.724288] CM = 0, WnR = 0
[ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000
[ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000
[ 334.740734] Internal error: Oops: 96000004 [#1] SMP
[ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon
[ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4
[ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021
[ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding]
[ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding]
[ 334.807962] sp : ffff8000221733e0
[ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c
[ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000
[ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0
[ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014
[ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62
[ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000
[ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec
[ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742
[ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400
[ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0
[ 334.882532] Call trace:
[ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding]
[ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding]
[ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding]
[ 334.901001] bond_start_xmit+0x54/0xb0 [bonding]
[ 334.905622] dev_hard_start_xmit+0xb4/0x220
[ 334.909798] __dev_queue_xmit+0x1a0/0x720
[ 334.913799] arp_xmit+0x3c/0xbc
[ 334.916932] arp_send_dst+0x98/0xd0
[ 334.920410] arp_solicit+0xe8/0x230
[ 334.923888] neigh_probe+0x60/0xb0
[ 334.927279] __neigh_event_send+0x3b0/0x470
[ 334.931453] neigh_resolve_output+0x70/0x90
[ 334.935626] ip_finish_output2+0x158/0x514
[ 334.939714] __ip_finish_output+0xac/0x1a4
[ 334.943800] ip_finish_output+0x40/0xfc
[ 334.947626] ip_output+0xf8/0x1a4
[ 334.950931] ip_send_skb+0x5c/0x100
[ 334.954410] ip_push_pending_frames+0x3c/0x60
[ 334.958758] raw_sendmsg+0x458/0x6d0
[ 334.962325] inet_sendmsg+0x50/0x80
[ 334.965805] sock_sendmsg+0x60/0x6c
[ 334.969286] __sys_sendto+0xc8/0x134
[ 334.972853] __arm64_sys_sendto+0x34/0x4c
[ 334.976854] invoke_syscall+0x78/0x100
[ 334.980594] el0_svc_common.constprop.0+0x4c/0xf4
[ 334.985287] do_el0_svc+0x38/0x4c
[ 334.988591] el0_svc+0x34/0x10c
[ 334.991724] el0t_64_sync_handler+0x11c/0x150
[ 334.996072] el0t_64_sync+0x190/0x194
[ 334.999726] Code: b9001062 f9403c02 d53cd044 8b040042 (b8210040)
[ 335.005810] ---[ end trace 0000000000000000 ]---
[ 335.010416] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[ 335.017279] SMP: stopping secondary CPUs
[ 335.021374] Kernel Offset: 0x5baca8eb0000 from 0xffff800008000000
[ 335.027456] PHYS_OFFSET: 0x80000000
[ 335.030932] CPU features: 0x0000,0085c029,19805c82
[ 335.035713] Memory Limit: none
[ 335.038756] Rebooting in 180 seconds..The fix is to allocate the memory in bond_open() which is guaranteed to be called before any packets are processed.
--- drivers/net/bonding/bond_main.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-)
drivers/net/bonding/bond_main.c +6 -9
@@ -4155,6 +4155,12 @@ static int bond_open(struct net_device *bond_dev)struct list_head *iter;struct slave *slave; +if (BOND_MODE (bond) ==BOND_MODE_ROUNDROBIN && !bond->rr_tx_counter) { + bond->rr_tx_counter =alloc_percpu (u32); +if (!bond->rr_tx_counter) +return -ENOMEM ; + } +/* reset slave->backup and slave->inactive */ if (bond_has_slaves (bond)) {bond_for_each_slave (bond, slave, iter) {
@@ -6210,15 +6216,6 @@ static int bond_init(struct net_device *bond_dev)if (!bond->wq)return -ENOMEM ; -if (BOND_MODE (bond) ==BOND_MODE_ROUNDROBIN ) { - bond->rr_tx_counter =alloc_percpu (u32); -if (!bond->rr_tx_counter) { -destroy_workqueue (bond->wq); - bond->wq =NULL ; -return -ENOMEM ; - } - } -spin_lock_init (&bond->stats_lock);netdev_lockdep_set_classes (bond_dev);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 155/207 net: sunhme: Fix packet reception for len < RX_COPY_THRESHOLD
In reply to Greg Kroah-HartmanFrom: Sean Anderson <[email protected]>
[ Upstream commit 878e2405710aacfeeb19364c300f38b7a9abfe8f ]
There is a separate receive path for small packets (under 256 bytes). Instead of allocating a new dma-capable skb to be used for the next packet, this path allocates a skb and copies the data into it (reusing the existing sbk for the next packet). There are two bytes of junk data at the beginning of every packet. I believe these are inserted in order to allow aligned DMA and IP headers. We skip over them using skb_reserve. Before copying over the data, we must use a barrier to ensure we see the whole packet. The current code only synchronizes len bytes, starting from the beginning of the packet, including the junk bytes. However, this leaves off the final two bytes in the packet. Synchronize the whole packet.
To reproduce this problem, ping a HME with a payload size between 17 and 214
$ ping -s 17 <hme_address>
which will complain rather loudly about the data mismatch. Small packets (below 60 bytes on the wire) do not have this issue. I suspect this is related to the padding added to increase the minimum packet size.
--- drivers/net/ethernet/sun/sunhme.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/sun/sunhme.c +2 -2
@@ -2020,9 +2020,9 @@ static void happy_meal_rx(struct happy_meal *hp, struct net_device *dev)skb_reserve (copy_skb,2 );skb_put (copy_skb, len); -dma_sync_single_for_cpu (hp->dma_dev, dma_addr, len,DMA_FROM_DEVICE ); +dma_sync_single_for_cpu (hp->dma_dev, dma_addr, len +2 ,DMA_FROM_DEVICE );skb_copy_from_linear_data (skb, copy_skb->data, len); -dma_sync_single_for_device (hp->dma_dev, dma_addr, len,DMA_FROM_DEVICE ); +dma_sync_single_for_device (hp->dma_dev, dma_addr, len +2 ,DMA_FROM_DEVICE );/* Reuse original ring buffer. */ hme_write_rxd(hp, this, (RXFLAG_OWN|((RX_BUF_ALLOC_SIZE-RX_OFFSET)<<16)),
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 156/207 net: sched: fix possible refcount leak in tc_new_tfilter()
In reply to Greg Kroah-HartmanFrom: Hangyu Hua <[email protected]>
[ Upstream commit c2e1cfefcac35e0eea229e148c8284088ce437b5 ]
tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops.
--- net/sched/cls_api.c | 1 + 1 file changed, 1 insertion(+)
net/sched/cls_api.c +1 -0
@@ -2136,6 +2136,7 @@ static int tc_new_tfilter(struct sk_buff *skb, struct nlmsghdr *n, }if (chain->tmplt_ops && chain->tmplt_ops != tp->ops) { +tfilter_put (tp, fh);NL_SET_ERR_MSG (extack,"Chain template is set to a different filter kind" ); err = -EINVAL ; goto errout;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 157/207 bnxt: prevent skb UAF after handing over to PTP worker
In reply to Greg Kroah-HartmanFrom: Jakub Kicinski <[email protected]>
[ Upstream commit c31f26c8f69f776759cbbdfb38e40ea91aa0dd65 ]
When reading the timestamp is required bnxt_tx_int() hands over the ownership of the completed skb to the PTP worker. The skb should not be used afterwards, as the worker may run before the rest of our code and free the skb, leading to a use-after-free.
Since dev_kfree_skb_any() accepts NULL make the loss of ownership more obvious and set skb to NULL.
--- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/net/ethernet/broadcom/bnxt/bnxt.c +5 -5
@@ -662,7 +662,6 @@ static void bnxt_tx_int(struct bnxt *bp, struct bnxt_napi *bnapi, int nr_pkts)for (i =0 ; i < nr_pkts; i++) {struct bnxt_sw_tx_bd *tx_buf; -bool compl_deferred = false;struct sk_buff *skb;int j, last;
@@ -671,6 +670,8 @@ static void bnxt_tx_int(struct bnxt *bp, struct bnxt_napi *bnapi, int nr_pkts) skb = tx_buf->skb; tx_buf->skb =NULL ; + tx_bytes += skb->len; +if (tx_buf->is_push) { tx_buf->is_push =0 ; goto next_tx_int;
@@ -691,8 +692,9 @@ static void bnxt_tx_int(struct bnxt *bp, struct bnxt_napi *bnapi, int nr_pkts) }if (unlikely (skb_shinfo (skb)->tx_flags &SKBTX_IN_PROGRESS )) {if (bp->flags &BNXT_FLAG_CHIP_P5 ) { +/* PTP worker takes ownership of the skb */ if (!bnxt_get_tx_ts_p5 (bp, skb)) - compl_deferred = true; + skb =NULL ;else atomic_inc (&bp->ptp_cfg->tx_avail); }
@@ -701,9 +703,7 @@ static void bnxt_tx_int(struct bnxt *bp, struct bnxt_napi *bnapi, int nr_pkts) next_tx_int: cons =NEXT_TX (cons); - tx_bytes += skb->len; -if (!compl_deferred) -dev_kfree_skb_any (skb); +dev_kfree_skb_any (skb); }netdev_tx_completed_queue (txq, nr_pkts, tx_bytes);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 158/207 selftests: forwarding: add shebang for sch_red.sh
In reply to Greg Kroah-HartmanFrom: Hangbin Liu <[email protected]>
[ Upstream commit 83e4b196838d90799a8879e5054a3beecf9ed256 ]
RHEL/Fedora RPM build checks are stricter, and complain when executable files don't have a shebang line, e.g.
*** WARNING: ./kselftests/net/forwarding/sch_red.sh is executable but has no shebang, removing executable bit
Fix it by adding shebang line.
--- tools/testing/selftests/net/forwarding/sch_red.sh | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/net/forwarding/sch_red.sh +1 -0
@@ -1,3 +1,4 @@ +#!/bin/bash # SPDX-License-Identifier: GPL-2.0 # This test sends one stream of traffic from H1 through a TBF shaper, to a RED
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 159/207 io_uring: ensure that cached task references are always put on exit
In reply to Greg Kroah-HartmanFrom: Jens Axboe <[email protected]>
commit e775f93f2ab976a2cdb4a7b53063cbe890904f73 upstream.
io_uring caches task references to avoid doing atomics for each of them per request. If a request is put from the same task that allocated it, then we can maintain a per-ctx cache of them. This obviously relies on io_uring always pruning caches in a reliable way, and there's currently a case off io_uring fd release where we can miss that.
One example is a ring setup with IOPOLL, which relies on the task polling for completions, which will free them. However, if such a task submits a request and then exits or closes the ring without reaping the completion, then ring release will reap and put. If release happens from that very same task, the completed request task refs will get put back into the cache pool. This is problematic, as we're now beyond the point of pruning caches.
Manually drop these caches after doing an IOPOLL reap. This releases references from the current task, which is enough. If another task happens to be doing the release, then the caching will not be triggered and there's no issue.
--- io_uring/io_uring.c | 3 +++ 1 file changed, 3 insertions(+)
io_uring/io_uring.c +3 -0
@@ -10951,6 +10951,9 @@ static __cold void io_ring_ctx_wait_and_io_poll_remove_all (ctx,NULL , true);/* if we failed setting up the ctx, we might not have any rings */ io_iopoll_try_reap_events (ctx); +/* drop cached put refs after potentially doing completions */ +if (current->io_uring) +io_uring_drop_tctx_refs (current); }INIT_WORK (&ctx->exit_work, io_ring_exit_work);
Greg Kroah-Hartman
maintainerPATCH 160/207 serial: fsl_lpuart: Reset prior to registration
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit 60f361722ad2ae5ee667d0b0545d40c42f754daf upstream.
Since commit bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for imx7ulp and imx8qxp"), certain i.MX UARTs are reset after they've already been registered. Register state may thus be clobbered after user space has begun to open and access the UART.
Avoid by performing the reset prior to registration.
--- drivers/tty/serial/fsl_lpuart.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/tty/serial/fsl_lpuart.c +5 -4
@@ -2706,14 +2706,15 @@ static int lpuart_probe(struct platform_ lpuart_reg.cons =LPUART_CONSOLE ; handler = lpuart_int; } - ret =uart_add_one_port (&lpuart_reg, &sport->port); -if (ret) - goto failed_attach_port; ret =lpuart_global_reset (sport);if (ret) goto failed_reset; + ret =uart_add_one_port (&lpuart_reg, &sport->port); +if (ret) + goto failed_attach_port; + ret =uart_get_rs485_mode (&sport->port);if (ret) goto failed_get_rs485;
@@ -2736,9 +2737,9 @@ static int lpuart_probe(struct platform_ failed_irq_request: failed_get_rs485: -failed_reset:uart_remove_one_port (&lpuart_reg, &sport->port); failed_attach_port: +failed_reset:lpuart_disable_clks (sport);return ret; }
Greg Kroah-Hartman
maintainerPATCH 161/207 serial: Create uart_xmit_advance()
In reply to Greg Kroah-HartmanFrom: Ilpo Järvinen <[email protected]>
commit e77cab77f2cb3a1ca2ba8df4af45bb35617ac16d upstream.
A very common pattern in the drivers is to advance xmit tail index and do bookkeeping of Tx'ed characters. Create uart_xmit_advance() to handle it.
--- include/linux/serial_core.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
include/linux/serial_core.h +17 -0
@@ -302,6 +302,23 @@ struct uart_state {/* number of characters left in xmit buffer before we ask for more */ #define WAKEUP_CHARS 256 +/** +* uart_xmit_advance - Advance xmit buffer and account Tx'ed chars +* @up: uart_port structure describing the port +* @chars: number of characters sent +* +* This function advances the tail of circular xmit buffer by the number of +* @chars transmitted and handles accounting of transmitted bytes (into +* @up's icount.tx). +*/ +static inline void uart_xmit_advance (struct uart_port *up,unsigned int chars) +{ +struct circ_buf *xmit = &up->state->xmit; + + xmit->tail = (xmit->tail + chars) & (UART_XMIT_SIZE -1 ); + up->icount.tx += chars; +} +struct module ;struct tty_driver ;
Greg Kroah-Hartman
maintainerPATCH 162/207 serial: tegra: Use uart_xmit_advance(), fixes icount.tx accounting
In reply to Greg Kroah-HartmanFrom: Ilpo Järvinen <[email protected]>
commit 754f68044c7dd6c52534ba3e0f664830285c4b15 upstream.
DMA complete & stop paths did not correctly account Tx'ed characters into icount.tx. Using uart_xmit_advance() fixes the problem.
--- drivers/tty/serial/serial-tegra.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/tty/serial/serial-tegra.c +2 -3
@@ -525,7 +525,7 @@ static void tegra_uart_tx_dma_complete(v count = tup->tx_bytes_requested - state.residue;async_tx_ack (tup->tx_dma_desc);spin_lock_irqsave (&tup->uport.lock, flags); - xmit->tail = (xmit->tail + count) & (UART_XMIT_SIZE -1 ); +uart_xmit_advance (&tup->uport, count); tup->tx_in_progress =0 ;if (uart_circ_chars_pending (xmit) <WAKEUP_CHARS )uart_write_wakeup (&tup->uport);
@@ -613,7 +613,6 @@ static unsigned int tegra_uart_tx_empty(static void tegra_uart_stop_tx (struct uart_port *u) {struct tegra_uart_port *tup =to_tegra_uport (u); -struct circ_buf *xmit = &tup->uport.state->xmit;struct dma_tx_state state;unsigned int count;
@@ -624,7 +623,7 @@ static void tegra_uart_stop_tx(struct uadmaengine_tx_status (tup->tx_dma_chan, tup->tx_cookie, &state); count = tup->tx_bytes_requested - state.residue;async_tx_ack (tup->tx_dma_desc); - xmit->tail = (xmit->tail + count) & (UART_XMIT_SIZE -1 ); +uart_xmit_advance (&tup->uport, count); tup->tx_in_progress =0 ; }
Greg Kroah-Hartman
maintainerPATCH 163/207 serial: tegra-tcu: Use uart_xmit_advance(), fixes icount.tx accounting
In reply to Greg Kroah-HartmanFrom: Ilpo Järvinen <[email protected]>
commit 1d10cd4da593bc0196a239dcc54dac24b6b0a74e upstream.
Tx'ing does not correctly account Tx'ed characters into icount.tx. Using uart_xmit_advance() fixes the problem.
--- drivers/tty/serial/tegra-tcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/tegra-tcu.c +1 -1
@@ -101,7 +101,7 @@ static void tegra_tcu_uart_start_tx(strubreak ;tegra_tcu_write (tcu, &xmit->buf[xmit->tail], count); - xmit->tail = (xmit->tail + count) & (UART_XMIT_SIZE -1 ); +uart_xmit_advance (port, count); }uart_write_wakeup (port);
Greg Kroah-Hartman
maintainerPATCH 164/207 cgroup: cgroup_get_from_id() must check the looked-up kn is a directory
In reply to Greg Kroah-HartmanFrom: Ming Lei <[email protected]>
commit df02452f3df069a59bc9e69c84435bf115cb6e37 upstream.
cgroup has to be one kernfs dir, otherwise kernel panic is caused, especially cgroup id is provide from userspace.
--- kernel/cgroup/cgroup.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
kernel/cgroup/cgroup.c +4 -1
@@ -6026,6 +6026,9 @@ struct cgroup *cgroup_get_from_id(u64 idif (!kn) goto out; +if (kernfs_type (kn) !=KERNFS_DIR ) + goto put; +rcu_read_lock (); cgrp =rcu_dereference (*(void __rcu __force **)&kn->priv);
@@ -6033,7 +6036,7 @@ struct cgroup *cgroup_get_from_id(u64 id cgrp =NULL ;rcu_read_unlock (); - +put:kernfs_put (kn); out:return cgrp;
Greg Kroah-Hartman
maintainerPATCH 165/207 phy: marvell: phy-mvebu-a3700-comphy: Remove broken reset support
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
commit 0a6fc70d76bddf98278af2ac000379c82aec8f11 upstream.
Reset support for SATA PHY is somehow broken and after calling it, kernel is not able to detect and initialize SATA disk Samsung SSD 850 EMT0 [1].
Reset support was introduced in commit 934337080c6c ("phy: marvell:
phy-mvebu-a3700-comphy: Add native kernel implementation") as part of complete rewrite of this driver. v1 patch series of that commit [2] did not contain reset support and was tested that is working fine with Ethernet, SATA and USB PHYs without issues too.
So for now remove broken reset support and change implementation of power_off callback to power off all functions on specified lane (and not only selected function) because during startup kernel does not know which function was selected and configured by bootloader. Same logic was used also in v1 patch series of that commit.
This change fixes issues with initialization of SATA disk Samsung SSD 850 and disk is working again, like before mentioned commit.
Once problem with PHY reset callback is solved its functionality could be re-introduced. But for now it is unknown why it does not work.
[1] - https://lore.kernel.org/r/20220531124159.3e4lgn2v462irbtz@shindev/
[2] - https://lore.kernel.org/r/[email protected]/
--- drivers/phy/marvell/phy-mvebu-a3700-comphy.c | 87 ++++---------------- 1 file changed, 17 insertions(+), 70 deletions(-)
drivers/phy/marvell/phy-mvebu-a3700-comphy.c +17 -70
@@ -274,7 +274,6 @@ struct mvebu_a3700_comphy_lane {int submode;bool invert_tx;bool invert_rx; -bool needs_reset; };struct gbe_phy_init_data_fix {
@@ -1097,40 +1096,12 @@ mvebu_a3700_comphy_pcie_power_off(struct mvebu_a3700_comphy_lane *lane) 0x0, PU_PLL_BIT | PU_RX_BIT | PU_TX_BIT); } -static int mvebu_a3700_comphy_reset (struct phy *phy) +static void mvebu_a3700_comphy_usb3_power_off (struct mvebu_a3700_comphy_lane *lane) { -struct mvebu_a3700_comphy_lane *lane =phy_get_drvdata (phy); -u16 mask, data; - -dev_dbg (lane->dev,"resetting lane %d\n" , lane->id); - -/* COMPHY reset for internal logic */ -comphy_lane_reg_set (lane,COMPHY_SFT_RESET , -SFT_RST_NO_REG ,SFT_RST_NO_REG ); - -/* COMPHY register reset (cleared automatically) */ -comphy_lane_reg_set (lane,COMPHY_SFT_RESET ,SFT_RST ,SFT_RST ); - -/* PIPE soft and register reset */ - data =PIPE_SOFT_RESET |PIPE_REG_RESET ; - mask = data; -comphy_lane_reg_set (lane,COMPHY_PIPE_RST_CLK_CTRL , data, mask); - -/* Release PIPE register reset */ -comphy_lane_reg_set (lane,COMPHY_PIPE_RST_CLK_CTRL , -0x0 ,PIPE_REG_RESET ); - -/* Reset SB configuration register (only for lanes 0 and 1) */ -if (lane->id ==0 || lane->id ==1 ) { -u32 mask, data; - - data =PIN_RESET_CORE_BIT |PIN_RESET_COMPHY_BIT | -PIN_PU_PLL_BIT |PIN_PU_RX_BIT |PIN_PU_TX_BIT ; - mask = data |PIN_PU_IVREF_BIT |PIN_TX_IDLE_BIT ; -comphy_periph_reg_set (lane,COMPHY_PHY_CFG1 , data, mask); - } - -return 0 ; +/* +* The USB3 MAC sets the USB3 PHY to low state, so we do not +* need to power off USB3 PHY again. +*/ } static bool mvebu_a3700_comphy_check_mode(int lane,
@@ -1171,10 +1142,6 @@ static int mvebu_a3700_comphy_set_mode(struct phy *phy, enum phy_mode mode, (lane->mode != mode || lane->submode != submode))return -EBUSY ; -/* If changing mode, ensure reset is called */ -if (lane->mode !=PHY_MODE_INVALID && lane->mode != mode) - lane->needs_reset = true; -/* Just remember the mode, ->power_on() will do the real setup */ lane->mode = mode; lane->submode = submode;
@@ -1185,7 +1152,6 @@ static int mvebu_a3700_comphy_set_mode(struct phy *phy, enum phy_mode mode,static int mvebu_a3700_comphy_power_on (struct phy *phy) {struct mvebu_a3700_comphy_lane *lane =phy_get_drvdata (phy); -int ret;if (!mvebu_a3700_comphy_check_mode (lane->id, lane->mode, lane->submode)) {
@@ -1193,14 +1159,6 @@ static int mvebu_a3700_comphy_power_on(struct phy *phy)return -EINVAL ; } -if (lane->needs_reset) { - ret =mvebu_a3700_comphy_reset (phy); -if (ret) -return ret; - - lane->needs_reset = false; - } -switch (lane->mode) {case PHY_MODE_USB_HOST_SS :dev_dbg (lane->dev,"set lane %d to USB3 host mode\n" , lane->id);
@@ -1224,38 +1182,28 @@ static int mvebu_a3700_comphy_power_off(struct phy *phy) {struct mvebu_a3700_comphy_lane *lane =phy_get_drvdata (phy); -switch (lane->mode) { -case PHY_MODE_USB_HOST_SS : -/* -* The USB3 MAC sets the USB3 PHY to low state, so we do not -* need to power off USB3 PHY again. -*/ -break ; - -case PHY_MODE_SATA : -mvebu_a3700_comphy_sata_power_off (lane); -break ; - -case PHY_MODE_ETHERNET : +switch (lane->id) { +case 0 : +mvebu_a3700_comphy_usb3_power_off (lane);mvebu_a3700_comphy_ethernet_power_off (lane); -break ; - -case PHY_MODE_PCIE : +return 0 ; +case 1 :mvebu_a3700_comphy_pcie_power_off (lane); -break ; - +mvebu_a3700_comphy_ethernet_power_off (lane); +return 0 ; +case 2 : +mvebu_a3700_comphy_usb3_power_off (lane); +mvebu_a3700_comphy_sata_power_off (lane); +return 0 ;default :dev_err (lane->dev,"invalid COMPHY mode\n" );return -EINVAL ; } - -return 0 ; }static const struct phy_ops mvebu_a3700_comphy_ops = { .power_on = mvebu_a3700_comphy_power_on, .power_off = mvebu_a3700_comphy_power_off, - .reset = mvebu_a3700_comphy_reset, .set_mode = mvebu_a3700_comphy_set_mode, .owner =THIS_MODULE , };
@@ -1393,8 +1341,7 @@ static int mvebu_a3700_comphy_probe(struct platform_device *pdev)* To avoid relying on the bootloader/firmware configuration, * power off all comphys. */ -mvebu_a3700_comphy_reset (phy); - lane->needs_reset = false; +mvebu_a3700_comphy_power_off (phy); } provider = devm_of_phy_provider_register(&pdev->dev,
Signature · 1 line
2.37.3
Greg Kroah-Hartman
maintainerPATCH 166/207 s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup
In reply to Greg Kroah-HartmanFrom: Stefan Haberland <[email protected]>
commit db7ba07108a48c0f95b74fabbfd5d63e924f992d upstream.
Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup pointer being NULL.
The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and _lcu_update() which sets pavgroup to NULL with the lcu->lock held.
Fix by checking the pavgroup pointer with lcu->lock held.
--- drivers/s390/block/dasd_alias.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/s390/block/dasd_alias.c +7 -2
@@ -675,12 +675,12 @@ int dasd_alias_remove_device(struct dasdstruct dasd_device *dasd_alias_get_start_dev (struct dasd_device *base_device) {struct dasd_eckd_private *alias_priv, *private = base_device->private; -struct alias_pav_group *group = private->pavgroup;struct alias_lcu *lcu = private->lcu;struct dasd_device *alias_device; +struct alias_pav_group *group;unsigned long flags; -if (!group || !lcu) +if (!lcu)return NULL ;if (lcu->pav ==NO_PAV || lcu->flags & (NEED_UAC_UPDATE |UPDATE_PENDING ))
@@ -697,6 +697,11 @@ struct dasd_device *dasd_alias_get_start }spin_lock_irqsave (&lcu->lock, flags); + group = private->pavgroup; +if (!group) { +spin_unlock_irqrestore (&lcu->lock, flags); +return NULL ; + } alias_device = group->next;if (!alias_device) {if (list_empty (&group->aliaslist)) {
Greg Kroah-Hartman
maintainerPATCH 167/207 drm/i915/display: Fix handling of enable_psr parameter
In reply to Greg Kroah-HartmanFrom: José Roberto de Souza <[email protected]>
commit 5c57c099f442acab13129c9e15ad2a0c31151c98 upstream.
Commit 3cf050762534 ("drm/i915/bios: Split VBT data into per-panel vs. global parts") cause PSR to be disabled when enable_psr has the default value and there is at least one DP port that do not supports PSR.
That was happening because intel_psr_init() is called for every DP port and then enable_psr is globaly set to 0 based on the PSR support of the DP port.
Here dropping the enable_psr overwritten and using the VBT PSR value when enable_psr is set as default.
--- drivers/gpu/drm/i915/display/intel_psr.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/gpu/drm/i915/display/intel_psr.c +3 -4
@@ -86,10 +86,13 @@static bool psr_global_enabled (struct intel_dp *intel_dp) { +struct intel_connector *connector = intel_dp->attached_connector;struct drm_i915_private *i915 =dp_to_i915 (intel_dp);switch (intel_dp->psr.debug &I915_PSR_DEBUG_MODE_MASK ) {case I915_PSR_DEBUG_DEFAULT : +if (i915->params.enable_psr ==-1 ) +return connector->panel.vbt.psr.enable;return i915->params.enable_psr;case I915_PSR_DEBUG_DISABLE :return false;
@@ -2371,10 +2374,6 @@ void intel_psr_init(struct intel_dp *int intel_dp->psr.source_support = true; -if (dev_priv->params.enable_psr ==-1 ) -if (!connector->panel.vbt.psr.enable) - dev_priv->params.enable_psr =0 ; -/* Set link_standby x link_off defaults */ if (DISPLAY_VER (dev_priv) <12 )/* For new platforms up to TGL let's respect VBT back again */
Greg Kroah-Hartman
maintainerPATCH 168/207 blk-mq: fix error handling in __blk_mq_alloc_disk
In reply to Greg Kroah-HartmanFrom: Christoph Hellwig <[email protected]>
commit 0a3e5cc7bbfcd571a2e53779ef7d7aa3c57d5432 upstream.
To fully clean up the queue if the disk allocation fails we need to call blk_mq_destroy_queue and not just blk_put_queue.
--- block/blk-mq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
block/blk-mq.c +1 -1
@@ -3949,7 +3949,7 @@ struct gendisk *__blk_mq_alloc_disk(stru disk =__alloc_disk_node (q, set->numa_node, lkclass);if (!disk) { -blk_put_queue (q); +blk_mq_destroy_queue (q);return ERR_PTR (-ENOMEM ); }set_bit (GD_OWNS_QUEUE , &disk->state);
Greg Kroah-Hartman
maintainerPATCH 169/207 block: call blk_mq_exit_queue from disk_release for never added disks
In reply to Greg Kroah-HartmanFrom: Christoph Hellwig <[email protected]>
commit c5db2cfc6274692d821d33b59acb6ff615e350c1 upstream.
To undo the all initialization from blk_mq_init_allocated_queue in case of a probe failure where add_disk is never called we have to call blk_mq_exit_queue from put_disk.
This relies on the fact that drivers always call blk_mq_free_tag_set after calling put_disk in the probe error path if they have a gendisk at all.
We should be doing this in general, but can't do it for the normal teardown case (yet) as the tagset can be gone by the time the disk is released once it was added. I hope to sort this out properly eventually but for now this isolated hack will do it.
--- block/genhd.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
block/genhd.c +15 -0
@@ -1158,6 +1158,18 @@ static void disk_release(struct device *might_sleep ();WARN_ON_ONCE (disk_live (disk)); +/* +* To undo the all initialization from blk_mq_init_allocated_queue in +* case of a probe failure where add_disk is never called we have to +* call blk_mq_exit_queue here. We can't do this for the more common +* teardown case (yet) as the tagset can be gone by the time the disk +* is released once it was added. +*/ +if (queue_is_mq (disk->queue) && +test_bit (GD_OWNS_QUEUE , &disk->state) && + !test_bit (GD_ADDED , &disk->state)) +blk_mq_exit_queue (disk->queue); +blkcg_exit_queue (disk->queue);disk_release_events (disk);
@@ -1422,6 +1434,9 @@ EXPORT_SYMBOL(__blk_alloc_disk);* This decrements the refcount for the struct gendisk. When this reaches 0 * we'll have disk_release() called. * +* Note: for blk-mq disk put_disk must be called before freeing the tag_set +* when handling probe errors (that is before add_disk() is called). +* * Context: Any context, but the last reference must not be dropped from * atomic context. */
Greg Kroah-Hartman
maintainerPATCH 170/207 block: Do not call blk_put_queue() if gendisk allocation fails
In reply to Greg Kroah-HartmanFrom: Rafael Mendonca <[email protected]>
commit aa0c680c3aa96a5f9f160d90dd95402ad578e2b0 upstream.
Commit 6f8191fdf41d ("block: simplify disk shutdown") removed the call to blk_get_queue() during gendisk allocation but missed to remove the corresponding cleanup code blk_put_queue() for it. Thus, if the gendisk allocation fails, the request_queue refcount gets decremented and reaches 0, causing blk_mq_release() to be called with a hctx still alive. That triggers a WARNING report, as found by syzkaller:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 23016 at block/blk-mq.c:3881 blk_mq_release+0xf8/0x3e0 block/blk-mq.c:3881 [...] stripped RIP: 0010:blk_mq_release+0xf8/0x3e0 block/blk-mq.c:3881 [...] stripped Call Trace: <TASK> blk_release_queue+0x153/0x270 block/blk-sysfs.c:780 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 __alloc_disk_node+0x4f7/0x610 block/genhd.c:1388 __blk_mq_alloc_disk+0x13b/0x1f0 block/blk-mq.c:3961 loop_add+0x3e2/0xaf0 drivers/block/loop.c:1978 loop_control_ioctl+0x133/0x620 drivers/block/loop.c:2150 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...] stripped
--- block/genhd.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
block/genhd.c +1 -3
@@ -1359,7 +1359,7 @@ struct gendisk *__alloc_disk_node(struct disk =kzalloc_node (sizeof (struct gendisk ),GFP_KERNEL , node_id);if (!disk) - goto out_put_queue; +return NULL ; disk->bdi =bdi_alloc (node_id);if (!disk->bdi)
@@ -1403,8 +1403,6 @@ out_free_bdi:bdi_put (disk->bdi); out_free_disk:kfree (disk); -out_put_queue: -blk_put_queue (q);return NULL ; }
Greg Kroah-Hartman
maintainerPATCH 171/207 Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region
In reply to Greg Kroah-HartmanFrom: Vitaly Kuznetsov <[email protected]>
[ Upstream commit f0880e2cb7e1f8039a048fdd01ce45ab77247221 ]
Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
$ cat /proc/iomem
...
f8000000-fffbffff : PCI Bus 0000:00
f8000000-fbffffff : 0000:00:08.0
f8000000-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
...
fe0000000-fffffffff : PCI Bus 0000:00
fe0000000-fe07fffff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
fe0000000-fe07fffff : 2ba2:00:02.0
fe0000000-fe07fffff : mlx4_corethe interesting part is the 'f8000000' region as it is actually the VM's framebuffer:
$ lspci -v ... 0000:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA (prog-if 00 [VGA controller]) Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f8000000 (32-bit, non-prefetchable) [size=64M] ...
hv_vmbus: registering driver hyperv_drm
hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Synthvid Version major 3, minor 5 hyperv_drm 0000:00:08.0: vgaarb: deactivate vga console
hyperv_drm 0000:00:08.0: BAR 0: can't reserve [mem 0xf8000000-0xfbffffff]
hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Cannot request framebuffer, boot fb still active?
Note: "Cannot request framebuffer" is not a fatal error in hyperv_setup_gen1() as the code assumes there's some other framebuffer device there but we actually have some other PCI device (mlx4 in this case) config space there!
The problem appears to be that vmbus_allocate_mmio() can use dedicated framebuffer region to serve any MMIO request from any device. The semantics one might assume of a parameter named "fb_overlap_ok" aren't implemented because !fb_overlap_ok essentially has no effect. The existing semantics are really "prefer_fb_overlap". This patch implements the expected and needed semantics, which is to not allocate from the frame buffer space when !fb_overlap_ok.
Note, Gen2 VMs are usually unaffected by the issue because framebuffer region is already taken by EFI fb (in case kernel supports it) but Gen1 VMs may have this region unclaimed by the time Hyper-V PCI pass-through driver tries allocating MMIO space if Hyper-V DRM/FB drivers load after it. Devices can be brought up in any sequence so let's resolve the issue by always ignoring 'fb_mmio' region for non-FB requests, even if the region is unclaimed.
--- drivers/hv/vmbus_drv.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/hv/vmbus_drv.c +9 -1
@@ -2309,7 +2309,7 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj, bool fb_overlap_ok) {struct resource *iter, *shadow; -resource_size_t range_min, range_max, start; +resource_size_t range_min, range_max, start, end;const char *dev_n =dev_name (&device_obj->device);int retval;
@@ -2344,6 +2344,14 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj, range_max = iter->end; start = (range_min + align -1 ) & ~(align -1 );for (; start + size -1 <= range_max; start += align) { + end = start + size -1 ; + +/* Skip the whole fb_mmio region if not fb_overlap_ok */ +if (!fb_overlap_ok && fb_mmio && + (((start >= fb_mmio->start) && (start <= fb_mmio->end)) || + ((end >= fb_mmio->start) && (end <= fb_mmio->end)))) +continue ; + shadow =__request_region (iter, start, size,NULL ,IORESOURCE_BUSY );if (!shadow)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 172/207 drm/gma500: Fix BUG: sleeping function called from invalid context errors
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
[ Upstream commit 63e37a79f7bd939314997e29c2f5a9f0ef184281 ]
gma_crtc_page_flip() was holding the event_lock spinlock while calling crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on errors re-take the lock and clear gma_crtc->page_flip_event it it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870 [ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell [ 512.123031] preempt_count: 1, expected: 0 [ 512.123048] RCU nest depth: 0, expected: 0 [ 512.123066] INFO: lockdep is turned off. [ 512.123080] irq event stamp: 0 [ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 512.123134] hardirqs last disabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123176] softirqs last enabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123207] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 512.123233] Preemption disabled at: [ 512.123241] [<0000000000000000>] 0x0 [ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G W 5.19.0+ #1 [ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 512.123323] Call Trace: [ 512.123346] <TASK> [ 512.123370] dump_stack_lvl+0x5b/0x77 [ 512.123412] __might_resched.cold+0xff/0x13a [ 512.123458] ww_mutex_lock+0x1e/0xa0 [ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx] [ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx] [ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx] [ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0 [ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.123936] drm_ioctl_kernel+0xa1/0x150 [ 512.123984] drm_ioctl+0x21f/0x420 [ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60 [ 512.124104] ? lock_release+0x1ef/0x2d0 [ 512.124161] __x64_sys_ioctl+0x8d/0xd0 [ 512.124203] do_syscall_64+0x58/0x80 [ 512.124239] ? do_syscall_64+0x67/0x80 [ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0 [ 512.124300] ? do_syscall_64+0x67/0x80 [ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80 [ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 512.124411] RIP: 0033:0x7fcc4a70740f [ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f [ 512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009 [ 512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034 [ 512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0 [ 512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0 [ 512.124647] </TASK>
--- drivers/gpu/drm/gma500/gma_display.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/gpu/drm/gma500/gma_display.c +7 -4
@@ -531,15 +531,18 @@ int gma_crtc_page_flip(struct drm_crtc *crtc,WARN_ON (drm_crtc_vblank_get (crtc) !=0 ); gma_crtc->page_flip_event = event; +spin_unlock_irqrestore (&dev->event_lock, flags);/* Call this locked if we want an event at vblank interrupt. */ ret = crtc_funcs->mode_set_base (crtc, crtc->x, crtc->y, old_fb);if (ret) { - gma_crtc->page_flip_event =NULL ; -drm_crtc_vblank_put (crtc); +spin_lock_irqsave (&dev->event_lock, flags); +if (gma_crtc->page_flip_event) { + gma_crtc->page_flip_event =NULL ; +drm_crtc_vblank_put (crtc); + } +spin_unlock_irqrestore (&dev->event_lock, flags); } - -spin_unlock_irqrestore (&dev->event_lock, flags); }else { ret = crtc_funcs->mode_set_base (crtc, crtc->x, crtc->y, old_fb); }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 173/207 drm/gma500: Fix WARN_ON(lock->magic != lock) error
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
[ Upstream commit b6f25c3b94f2aadbf5cbef954db4073614943d74 ]
psb_gem_unpin() calls dma_resv_lock() but the underlying ww_mutex gets destroyed by drm_gem_object_release() move the drm_gem_object_release() call in psb_gem_free_object() to after the unpin to fix the below warning:
[ 79.693962] ------------[ cut here ]------------ [ 79.693992] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 79.694015] WARNING: CPU: 0 PID: 240 at kernel/locking/mutex.c:582 __ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694052] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer qrtr bnep ath9k ath9k_common ath9k_hw snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel ath3k snd_intel_dspcfg mac80211 snd_intel_sdw_acpi btusb snd_hda_codec btrtl btbcm btintel btmtk bluetooth at24 snd_hda_core snd_hwdep uvcvideo snd_seq libarc4 videobuf2_vmalloc ath videobuf2_memops videobuf2_v4l2 videobuf2_common snd_seq_device videodev acer_wmi intel_powerclamp coretemp mc snd_pcm joydev sparse_keymap ecdh_generic pcspkr wmi_bmof cfg80211 i2c_i801 i2c_smbus snd_timer snd r8169 rfkill lpc_ich soundcore acpi_cpufreq zram rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci gma500_gfx(E) video wmi ip6_tables ip_tables i2c_dev fuse [ 79.694436] CPU: 0 PID: 240 Comm: plymouthd Tainted: G W E 6.0.0-rc3+ #490 [ 79.694457] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 79.694469] RIP: 0010:__ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694496] Code: ff 85 c0 0f 84 15 fb ff ff 8b 05 ca 3c 11 01 85 c0 0f 85 07 fb ff ff 48 c7 c6 30 cb 84 aa 48 c7 c7 a3 e1 82 aa e8 ac 29 f8 ff <0f> 0b e9 ed fa ff ff e8 5b 83 8a ff 85 c0 74 10 44 8b 0d 98 3c 11 [ 79.694513] RSP: 0018:ffffad1dc048bbe0 EFLAGS: 00010282 [ 79.694623] RAX: 0000000000000028 RBX: 0000000000000000 RCX: 0000000000000000 [ 79.694636] RDX: 0000000000000001 RSI: ffffffffaa8b0ffc RDI: 00000000ffffffff [ 79.694650] RBP: ffffad1dc048bc80 R08: 0000000000000000 R09: ffffad1dc048ba90 [ 79.694662] R10: 0000000000000003 R11: ffffffffaad62fe8 R12: ffff9ff302103138 [ 79.694675] R13: ffff9ff306ec8000 R14: ffff9ff307779078 R15: ffff9ff3014c0270 [ 79.694690] FS: 00007ff1cccf1740(0000) GS:ffff9ff3bc200000(0000) knlGS:0000000000000000 [ 79.694705] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 79.694719] CR2: 0000559ecbcb4420 CR3: 0000000013210000 CR4: 00000000000006f0 [ 79.694734] Call Trace: [ 79.694749] <TASK> [ 79.694761] ? __schedule+0x47f/0x1670 [ 79.694796] ? psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694830] ? lock_is_held_type+0xe3/0x140 [ 79.694864] ? ww_mutex_lock+0x38/0xa0 [ 79.694885] ? __cond_resched+0x1c/0x30 [ 79.694902] ww_mutex_lock+0x38/0xa0 [ 79.694925] psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694964] psb_gem_unpin+0x199/0x1a0 [gma500_gfx] [ 79.694996] drm_gem_object_release_handle+0x50/0x60 [ 79.695020] ? drm_gem_object_handle_put_unlocked+0xf0/0xf0 [ 79.695042] idr_for_each+0x4b/0xb0 [ 79.695066] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 79.695095] drm_gem_release+0x1c/0x30 [ 79.695118] drm_file_free.part.0+0x1ea/0x260 [ 79.695150] drm_release+0x6a/0x120 [ 79.695175] __fput+0x9f/0x260 [ 79.695203] task_work_run+0x59/0xa0 [ 79.695227] do_exit+0x387/0xbe0 [ 79.695250] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 79.695275] ? lockdep_hardirqs_on+0x7d/0x100 [ 79.695304] do_group_exit+0x33/0xb0 [ 79.695331] __x64_sys_exit_group+0x14/0x20 [ 79.695353] do_syscall_64+0x58/0x80 [ 79.695376] ? up_read+0x17/0x20 [ 79.695401] ? lock_is_held_type+0xe3/0x140 [ 79.695429] ? asm_exc_page_fault+0x22/0x30 [ 79.695450] ? lockdep_hardirqs_on+0x7d/0x100 [ 79.695473] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 79.695493] RIP: 0033:0x7ff1ccefe3f1 [ 79.695516] Code: Unable to access opcode bytes at RIP 0x7ff1ccefe3c7. [ 79.695607] RSP: 002b:00007ffed4413378 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 79.695629] RAX: ffffffffffffffda RBX: 00007ff1cd0159e0 RCX: 00007ff1ccefe3f1 [ 79.695644] RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 [ 79.695656] RBP: 0000000000000000 R08: ffffffffffffff80 R09: 00007ff1cd020b20 [ 79.695671] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff1cd0159e0 [ 79.695684] R13: 0000000000000000 R14: 00007ff1cd01aee8 R15: 00007ff1cd01af00 [ 79.695733] </TASK> [ 79.695746] irq event stamp: 725979 [ 79.695757] hardirqs last enabled at (725979): [<ffffffffa9132d54>] finish_task_switch.isra.0+0xe4/0x3f0 [ 79.695780] hardirqs last disabled at (725978): [<ffffffffa9eb4113>] __schedule+0xdd3/0x1670 [ 79.695803] softirqs last enabled at (725974): [<ffffffffa90fbc9d>] __irq_exit_rcu+0xed/0x160 [ 79.695825] softirqs last disabled at (725969): [<ffffffffa90fbc9d>] __irq_exit_rcu+0xed/0x160 [ 79.695845] ---[ end trace 0000000000000000 ]---
--- drivers/gpu/drm/gma500/gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/gma500/gem.c +2 -2
@@ -112,12 +112,12 @@ static void psb_gem_free_object(struct drm_gem_object *obj) {struct psb_gem_object *pobj =to_psb_gem_object (obj); -drm_gem_object_release (obj); -/* Undo the mmap pin if we are destroying the object */ if (pobj->mmapping)psb_gem_unpin (pobj); +drm_gem_object_release (obj); +WARN_ON (pobj->in_gart && !pobj->stolen);release_resource (&pobj->resource);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 174/207 drm/gma500: Fix (vblank) IRQs not working after suspend/resume
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
[ Upstream commit 235fdbc32d559db21e580f85035c59372704f09e ]
Fix gnome-shell (and other page-flip users) hanging after suspend/resume because of the gma500's IRQs not working.
This fixes 2 problems with the IRQ handling:
1. gma_power_off() calls gma_irq_uninstall() which does a free_irq(), but gma_power_on() called gma_irq_preinstall() + gma_irq_postinstall() which do not call request_irq. Replace the pre- + post-install calls with gma_irq_install() which does prep + request + post.
2. After fixing 1. IRQs still do not work on a Packard Bell Dot SC (Intel Atom N2600, cedarview) netbook.
Cederview uses MSI interrupts and it seems that the BIOS re-configures things back to normal APIC based interrupts during S3 suspend. There is some MSI PCI-config registers save/restore code which tries to deal with this, but on the Packard Bell Dot SC this is not sufficient to restore MSI IRQ functionality after a suspend/resume.
Replace the PCI-config registers save/restore with pci_disable_msi() on suspend + pci_enable_msi() on resume. Fixing e.g. gnome-shell hanging.
--- drivers/gpu/drm/gma500/cdv_device.c | 4 +--- drivers/gpu/drm/gma500/oaktrail_device.c | 5 +---- drivers/gpu/drm/gma500/power.c | 8 +------- drivers/gpu/drm/gma500/psb_drv.c | 2 +- drivers/gpu/drm/gma500/psb_drv.h | 5 +---- drivers/gpu/drm/gma500/psb_irq.c | 15 ++++++++++++--- drivers/gpu/drm/gma500/psb_irq.h | 2 +- 7 files changed, 18 insertions(+), 23 deletions(-)
drivers/gpu/drm/gma500/cdv_device.c +1 -3
@@ -581,11 +581,9 @@ static const struct psb_offset cdv_regmap[2] = {static int cdv_chip_setup (struct drm_device *dev) {struct drm_psb_private *dev_priv =to_drm_psb_private (dev); -struct pci_dev *pdev =to_pci_dev (dev->dev);INIT_WORK (&dev_priv->hotplug_work, cdv_hotplug_work_func); -if (pci_enable_msi (pdev)) -dev_warn (dev->dev,"Enabling MSI failed!\n" ); + dev_priv->use_msi = true; dev_priv->regmap = cdv_regmap;gma_get_core_freq (dev);psb_intel_opregion_init (dev);
drivers/gpu/drm/gma500/oaktrail_device.c +1 -4
@@ -501,12 +501,9 @@ static const struct psb_offset oaktrail_regmap[2] = {static int oaktrail_chip_setup (struct drm_device *dev) {struct drm_psb_private *dev_priv =to_drm_psb_private (dev); -struct pci_dev *pdev =to_pci_dev (dev->dev);int ret; -if (pci_enable_msi (pdev)) -dev_warn (dev->dev,"Enabling MSI failed!\n" ); - + dev_priv->use_msi = true; dev_priv->regmap = oaktrail_regmap; ret =mid_chip_setup (dev);
drivers/gpu/drm/gma500/power.c +1 -7
@@ -139,8 +139,6 @@ static void gma_suspend_pci(struct pci_dev *pdev) dev_priv->regs.saveBSM = bsm;pci_read_config_dword (pdev,0xFC , &vbt); dev_priv->regs.saveVBT = vbt; -pci_read_config_dword (pdev, PSB_PCIx_MSI_ADDR_LOC, &dev_priv->msi_addr); -pci_read_config_dword (pdev, PSB_PCIx_MSI_DATA_LOC, &dev_priv->msi_data);pci_disable_device (pdev);pci_set_power_state (pdev, PCI_D3hot);
@@ -168,9 +166,6 @@ static bool gma_resume_pci(struct pci_dev *pdev)pci_restore_state (pdev);pci_write_config_dword (pdev,0x5c , dev_priv->regs.saveBSM);pci_write_config_dword (pdev,0xFC , dev_priv->regs.saveVBT); -/* restoring MSI address and data in PCIx space */ -pci_write_config_dword (pdev, PSB_PCIx_MSI_ADDR_LOC, dev_priv->msi_addr); -pci_write_config_dword (pdev, PSB_PCIx_MSI_DATA_LOC, dev_priv->msi_data); ret =pci_enable_device (pdev);if (ret !=0 )
@@ -223,8 +218,7 @@ int gma_power_resume(struct device *_dev)mutex_lock (&power_mutex);gma_resume_pci (pdev);gma_resume_display (pdev); -gma_irq_preinstall (dev); -gma_irq_postinstall (dev); +gma_irq_install (dev);mutex_unlock (&power_mutex);return 0 ; }
drivers/gpu/drm/gma500/psb_drv.c +1 -1
@@ -383,7 +383,7 @@ static int psb_driver_load(struct drm_device *dev, unsigned long flags)PSB_WVDC32 (0xFFFFFFFF ,PSB_INT_MASK_R );spin_unlock_irqrestore (&dev_priv->irqmask_lock, irqflags); -gma_irq_install (dev, pdev->irq); +gma_irq_install (dev); dev->max_vblank_count =0xffffff ;/* only 24 bits of frame count */
drivers/gpu/drm/gma500/psb_drv.h +1 -4
@@ -490,6 +490,7 @@ struct drm_psb_private {int rpm_enabled;/* MID specific */ +bool use_msi;bool has_gct;struct oaktrail_gct_data gct_data;
@@ -499,10 +500,6 @@ struct drm_psb_private {/* Register state */ struct psb_save_area regs; -/* MSI reg save */ -uint32_t msi_addr; -uint32_t msi_data; -/* Hotplug handling */ struct work_struct hotplug_work;
drivers/gpu/drm/gma500/psb_irq.c +12 -3
@@ -316,17 +316,24 @@ void gma_irq_postinstall(struct drm_device *dev)spin_unlock_irqrestore (&dev_priv->irqmask_lock, irqflags); } -int gma_irq_install (struct drm_device *dev,unsigned int irq) +int gma_irq_install (struct drm_device *dev) { +struct drm_psb_private *dev_priv =to_drm_psb_private (dev); +struct pci_dev *pdev =to_pci_dev (dev->dev);int ret; -if (irq ==IRQ_NOTCONNECTED ) +if (dev_priv->use_msi &&pci_enable_msi (pdev)) { +dev_warn (dev->dev,"Enabling MSI failed!\n" ); + dev_priv->use_msi = false; + } + +if (pdev->irq ==IRQ_NOTCONNECTED )return -ENOTCONN ;gma_irq_preinstall (dev);/* PCI devices require shared interrupts. */ - ret =request_irq (irq, gma_irq_handler,IRQF_SHARED , dev->driver->name, dev); + ret =request_irq (pdev->irq, gma_irq_handler,IRQF_SHARED , dev->driver->name, dev);if (ret)return ret;
@@ -369,6 +376,8 @@ void gma_irq_uninstall(struct drm_device *dev)spin_unlock_irqrestore (&dev_priv->irqmask_lock, irqflags);free_irq (pdev->irq, dev); +if (dev_priv->use_msi) +pci_disable_msi (pdev); }int gma_crtc_enable_vblank (struct drm_crtc *crtc)
drivers/gpu/drm/gma500/psb_irq.h +1 -1
@@ -17,7 +17,7 @@ struct drm_device;void gma_irq_preinstall (struct drm_device *dev);void gma_irq_postinstall (struct drm_device *dev); -int gma_irq_install (struct drm_device *dev,unsigned int irq); +int gma_irq_install (struct drm_device *dev);void gma_irq_uninstall (struct drm_device *dev);int gma_crtc_enable_vblank (struct drm_crtc *crtc);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 175/207 gpio: ixp4xx: Make irqchip immutable
In reply to Greg Kroah-HartmanFrom: Linus Walleij <[email protected]>
[ Upstream commit 94e9bc73d85aa6ecfe249e985ff57abe0ab35f34 ]
This turns the IXP4xx GPIO irqchip into an immutable irqchip, a bit different from the standard template due to being hierarchical.
Tested on the IXP4xx which uses drivers/ata/pata_ixp4xx_cf.c for a rootfs on compact flash with IRQs from this GPIO block to the CF ATA controller.
--- drivers/gpio/gpio-ixp4xx.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
drivers/gpio/gpio-ixp4xx.c +14 -3
@@ -63,6 +63,14 @@ static void ixp4xx_gpio_irq_ack(struct irq_data *d)__raw_writel (BIT (d->hwirq), g->base +IXP4XX_REG_GPIS ); } +static void ixp4xx_gpio_mask_irq (struct irq_data *d) +{ +struct gpio_chip *gc =irq_data_get_irq_chip_data (d); + +irq_chip_mask_parent (d); +gpiochip_disable_irq (gc, d->hwirq); +} +static void ixp4xx_gpio_irq_unmask (struct irq_data *d) {struct gpio_chip *gc =irq_data_get_irq_chip_data (d);
@@ -72,6 +80,7 @@ static void ixp4xx_gpio_irq_unmask(struct irq_data *d)if (!(g->irq_edge &BIT (d->hwirq)))ixp4xx_gpio_irq_ack (d); +gpiochip_enable_irq (gc, d->hwirq);irq_chip_unmask_parent (d); }
@@ -149,12 +158,14 @@ static int ixp4xx_gpio_irq_set_type(struct irq_data *d, unsigned int type)return irq_chip_set_type_parent (d,IRQ_TYPE_LEVEL_HIGH ); } -static struct irq_chip ixp4xx_gpio_irqchip = { +static const struct irq_chip ixp4xx_gpio_irqchip = { .name ="IXP4GPIO" , .irq_ack = ixp4xx_gpio_irq_ack, - .irq_mask = irq_chip_mask_parent, + .irq_mask = ixp4xx_gpio_mask_irq, .irq_unmask = ixp4xx_gpio_irq_unmask, .irq_set_type = ixp4xx_gpio_irq_set_type, + .flags =IRQCHIP_IMMUTABLE , +GPIOCHIP_IRQ_RESOURCE_HELPERS , }; static int ixp4xx_gpio_child_to_parent_hwirq(struct gpio_chip *gc,
@@ -263,7 +274,7 @@ static int ixp4xx_gpio_probe(struct platform_device *pdev) g->gc.owner =THIS_MODULE ; girq = &g->gc.irq; - girq->chip = &ixp4xx_gpio_irqchip; +gpio_irq_chip_set_chip (girq, &ixp4xx_gpio_irqchip); girq->fwnode = g->fwnode; girq->parent_domain = parent; girq->child_to_parent_hwirq = ixp4xx_gpio_child_to_parent_hwirq;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 176/207 drm/amd/pm: disable BACO entry/exit completely on several sienna cichlid cards
In reply to Greg Kroah-HartmanFrom: Guchun Chen <[email protected]>
[ Upstream commit 7c6fb61a400bf3218c6504cb2d48858f98822c9d ]
To avoid hardware intermittent failures.
--- .../gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c +11 -0
@@ -368,6 +368,17 @@ static void sienna_cichlid_check_bxco_support(struct smu_context *smu) smu_baco->platform_support = (val &RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK ) ? true : false; + +/* +* Disable BACO entry/exit completely on below SKUs to +* avoid hardware intermittent failures. +*/ +if (((adev->pdev->device ==0x73A1 ) && + (adev->pdev->revision ==0x00 )) || + ((adev->pdev->device ==0x73BF ) && + (adev->pdev->revision ==0xCF ))) + smu_baco->platform_support = false; + } }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 177/207 drm/amdgpu: use dirty framebuffer helper
In reply to Greg Kroah-HartmanFrom: Hamza Mahfooz <[email protected]>
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs struct.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +2 -0
@@ -35,6 +35,7 @@#include <linux/pci.h> #include <linux/pm_runtime.h> #include <drm/drm_crtc_helper.h> +#include <drm/drm_damage_helper.h> #include <drm/drm_edid.h> #include <drm/drm_gem_framebuffer_helper.h> #include <drm/drm_fb_helper.h>
@@ -493,6 +494,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector *amdgpu_connector,static const struct drm_framebuffer_funcs amdgpu_fb_funcs = { .destroy = drm_gem_fb_destroy, .create_handle = drm_gem_fb_create_handle, + .dirty = drm_atomic_helper_dirtyfb, }; uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 178/207 drm/amdgpu: change the alignment size of TMR BO to 1M
In reply to Greg Kroah-HartmanFrom: Yang Wang <[email protected]>
[ Upstream commit 36de13fdb04abef3ee03ade5129ab146de63983b ]
align TMR BO size TO tmr size is not necessary, modify the size to 1M to avoid re-create BO fail when serious VRAM fragmentation.
v2:
add new macro PSP_TMR_ALIGNMENT for TMR BO alignment size
--- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c +1 -1
@@ -748,7 +748,7 @@ static int psp_tmr_init(struct psp_context *psp) } pptr =amdgpu_sriov_vf (psp->adev) ? &tmr_buf :NULL ; - ret =amdgpu_bo_create_kernel (psp->adev, tmr_size,PSP_TMR_SIZE (psp->adev), + ret =amdgpu_bo_create_kernel (psp->adev, tmr_size,PSP_TMR_ALIGNMENT ,AMDGPU_GEM_DOMAIN_VRAM , &psp->tmr_bo, &psp->tmr_mc_addr, pptr);
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h +1 -0
@@ -36,6 +36,7 @@#define PSP_CMD_BUFFER_SIZE 0x1000#define PSP_1_MEG 0x100000#define PSP_TMR_SIZE (adev) ((adev)->asic_type == CHIP_ALDEBARAN ? 0x800000 : 0x400000) +#define PSP_TMR_ALIGNMENT 0x100000#define PSP_FW_NAME_LEN 0x24enum psp_shared_mem_size {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 179/207 drm/amdgpu: add HDP remap functionality to nbio 7.7
In reply to Greg Kroah-HartmanFrom: Alex Deucher <[email protected]>
[ Upstream commit 8c5708d3da37b8c7c3c22c7e945b9a76a7c9539b ]
Was missing before and would have resulted in a write to a non-existant register. Normally APUs don't use HDP, but other asics could use this code and APUs do use the HDP when used in passthrough.
--- drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c +9 -0
@@ -28,6 +28,14 @@#include "nbio/nbio_7_7_0_sh_mask.h" #include <uapi/linux/kfd_ioctl.h> +static void nbio_v7_7_remap_hdp_registers (struct amdgpu_device *adev) +{ +WREG32_SOC15 (NBIO ,0 , regBIF_BX0_REMAP_HDP_MEM_FLUSH_CNTL, + adev->rmmio_remap.reg_offset +KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL ); +WREG32_SOC15 (NBIO ,0 , regBIF_BX0_REMAP_HDP_REG_FLUSH_CNTL, + adev->rmmio_remap.reg_offset +KFD_MMIO_REMAP_HDP_REG_FLUSH_CNTL ); +} +static u32 nbio_v7_7_get_rev_id (struct amdgpu_device *adev) {u32 tmp;
@@ -237,4 +245,5 @@ const struct amdgpu_nbio_funcs nbio_v7_7_funcs = { .ih_doorbell_range = nbio_v7_7_ih_doorbell_range, .ih_control = nbio_v7_7_ih_control, .init_registers = nbio_v7_7_init_registers, + .remap_hdp_registers = nbio_v7_7_remap_hdp_registers, };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 180/207 drm/amdgpu: Skip reset error status for psp v13_0_0
In reply to Greg Kroah-HartmanFrom: Candice Li <[email protected]>
[ Upstream commit 86875d558b91cb46f43be112799c06ecce60ec1e ]
No need to reset error status since only umc ras supported on psp v13_0_0.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +2 -1
@@ -1805,7 +1805,8 @@ static void amdgpu_ras_log_on_err_counter(struct amdgpu_device *adev)amdgpu_ras_query_error_status (adev, &info);if (adev->ip_versions[MP0_HWIP ][0 ] !=IP_VERSION (11 ,0 ,2 ) && - adev->ip_versions[MP0_HWIP ][0 ] !=IP_VERSION (11 ,0 ,4 )) { + adev->ip_versions[MP0_HWIP ][0 ] !=IP_VERSION (11 ,0 ,4 ) && + adev->ip_versions[MP0_HWIP ][0 ] !=IP_VERSION (13 ,0 ,0 )) {if (amdgpu_ras_reset_error_status (adev, info.head.block))dev_warn (adev->dev,"Failed to reset error counter and error status" ); }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 181/207 drm/amd/display: Limit user regamma to a valid value
In reply to Greg Kroah-HartmanFrom: Yao Wang1 <[email protected]>
[ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ]
[Why]
For HDR mode, we get total 512 tf_point and after switching to SDR mode we actually get 400 tf_point and the rest of points(401~512) still use dirty value from HDR mode. We should limit the rest of the points to max value.
[How]
Limit the value when coordinates_x.x > 1, just like what we do in translate_from_linear_space for other re-gamma build paths.
--- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/amd/display/modules/color/color_gamma.c +4 -0
@@ -1603,6 +1603,7 @@ static void interpolate_user_regamma(uint32_t hw_points_num,struct fixed31_32 lut2;struct fixed31_32 delta_lut;struct fixed31_32 delta_index; +const struct fixed31_32 one =dc_fixpt_from_int (1 ); i =0 ;/* fixed_pt library has problems handling too small values */
@@ -1631,6 +1632,9 @@ static void interpolate_user_regamma(uint32_t hw_points_num, }else hw_x = coordinates_x[i].x; +if (dc_fixpt_le (one, hw_x)) + hw_x = one; + norm_x =dc_fixpt_mul (norm_factor, hw_x); index =dc_fixpt_floor (norm_x);if (index <0 || index >255 )
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 182/207 drm/amd/display: Reduce number of arguments of dml31s CalculateWatermarksAndDRAMSpeedChangeSupport()
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
[ Upstream commit 37934d4118e22bceb80141804391975078f31734 ]
Most of the arguments are identical between the two call sites and they can be accessed through the 'struct vba_vars_st' pointer. This reduces the total amount of stack space that dml31_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with LLVM 16 (2216 -> 1976), helping clear up the following clang warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6: error: stack frame size (2216) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
--- .../dc/dml/dcn31/display_mode_vba_31.c | 248 ++++-------------- 1 file changed, 52 insertions(+), 196 deletions(-)
drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c +52 -196
@@ -321,64 +321,28 @@ static void CalculateVupdateAndDynamicMetadataParameters(static void CalculateWatermarksAndDRAMSpeedChangeSupport (struct display_mode_lib *mode_lib,unsigned int PrefetchMode, -unsigned int NumberOfActivePlanes, -unsigned int MaxLineBufferLines, -unsigned int LineBufferSize, -unsigned int WritebackInterfaceBufferSize,double DCFCLK ,double ReturnBW, -bool SynchronizedVBlank, -unsigned int dpte_group_bytes[], -unsigned int MetaChunkSize,double UrgentLatency,double ExtraLatency, -double WritebackLatency, -double WritebackChunkSize,double SOCCLK , -double DRAMClockChangeLatency, -double SRExitTime, -double SREnterPlusExitTime, -double SRExitZ8Time, -double SREnterPlusExitZ8Time,double DCFCLKDeepSleep,unsigned int DETBufferSizeY[],unsigned int DETBufferSizeC[],unsigned int SwathHeightY[],unsigned int SwathHeightC[], -unsigned int LBBitPerPixel[],double SwathWidthY[],double SwathWidthC[], -double HRatio[], -double HRatioChroma[], -unsigned int vtaps[], -unsigned int VTAPsChroma[], -double VRatio[], -double VRatioChroma[], -unsigned int HTotal[], -double PixelClock[], -unsigned int BlendingAndTiming[],unsigned int DPPPerPlane[],double BytePerPixelDETY[],double BytePerPixelDETC[], -double DSTXAfterScaler[], -double DSTYAfterScaler[], -bool WritebackEnable[], -enum source_format_class WritebackPixelFormat[], -double WritebackDestinationWidth[], -double WritebackDestinationHeight[], -double WritebackSourceHeight[],bool UnboundedRequestEnabled,int unsigned CompressedBufferSizeInkByte,enum clock_change_support *DRAMClockChangeSupport, -double *UrgentWatermark, -double *WritebackUrgentWatermark, -double *DRAMClockChangeWatermark, -double *WritebackDRAMClockChangeWatermark,double *StutterExitWatermark,double *StutterEnterPlusExitWatermark,double *Z8StutterExitWatermark, -double *Z8StutterEnterPlusExitWatermark, -double *MinActiveDRAMClockChangeLatencySupported); +double *Z8StutterEnterPlusExitWatermark); static void CalculateDCFCLKDeepSleep( struct display_mode_lib *mode_lib,
@@ -3027,64 +2991,28 @@ static void DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanCalculateWatermarksAndDRAMSpeedChangeSupport ( mode_lib, PrefetchMode, - v->NumberOfActivePlanes, - v->MaxLineBufferLines, - v->LineBufferSize, - v->WritebackInterfaceBufferSize, v->DCFCLK, v->ReturnBW, - v->SynchronizedVBlank, - v->dpte_group_bytes, - v->MetaChunkSize, v->UrgentLatency, v->UrgentExtraLatency, - v->WritebackLatency, - v->WritebackChunkSize, v->SOCCLK, - v->DRAMClockChangeLatency, - v->SRExitTime, - v->SREnterPlusExitTime, - v->SRExitZ8Time, - v->SREnterPlusExitZ8Time, v->DCFCLKDeepSleep, v->DETBufferSizeY, v->DETBufferSizeC, v->SwathHeightY, v->SwathHeightC, - v->LBBitPerPixel, v->SwathWidthY, v->SwathWidthC, - v->HRatio, - v->HRatioChroma, - v->vtaps, - v->VTAPsChroma, - v->VRatio, - v->VRatioChroma, - v->HTotal, - v->PixelClock, - v->BlendingAndTiming, v->DPPPerPlane, v->BytePerPixelDETY, v->BytePerPixelDETC, - v->DSTXAfterScaler, - v->DSTYAfterScaler, - v->WritebackEnable, - v->WritebackPixelFormat, - v->WritebackDestinationWidth, - v->WritebackDestinationHeight, - v->WritebackSourceHeight, v->UnboundedRequestEnabled, v->CompressedBufferSizeInkByte, &DRAMClockChangeSupport, - &v->UrgentWatermark, - &v->WritebackUrgentWatermark, - &v->DRAMClockChangeWatermark, - &v->WritebackDRAMClockChangeWatermark, &v->StutterExitWatermark, &v->StutterEnterPlusExitWatermark, &v->Z8StutterExitWatermark, - &v->Z8StutterEnterPlusExitWatermark, - &v->MinActiveDRAMClockChangeLatencySupported); + &v->Z8StutterEnterPlusExitWatermark);for (k =0 ; k < v->NumberOfActivePlanes; ++k) {if (v->WritebackEnable[k] == true) {
@@ -5481,64 +5409,28 @@ void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lCalculateWatermarksAndDRAMSpeedChangeSupport ( mode_lib, v->PrefetchModePerState[i][j], - v->NumberOfActivePlanes, - v->MaxLineBufferLines, - v->LineBufferSize, - v->WritebackInterfaceBufferSize, v->DCFCLKState[i][j], v->ReturnBWPerState[i][j], - v->SynchronizedVBlank, - v->dpte_group_bytes, - v->MetaChunkSize, v->UrgLatency[i], v->ExtraLatency, - v->WritebackLatency, - v->WritebackChunkSize, v->SOCCLKPerState[i], - v->DRAMClockChangeLatency, - v->SRExitTime, - v->SREnterPlusExitTime, - v->SRExitZ8Time, - v->SREnterPlusExitZ8Time, v->ProjectedDCFCLKDeepSleep[i][j], v->DETBufferSizeYThisState, v->DETBufferSizeCThisState, v->SwathHeightYThisState, v->SwathHeightCThisState, - v->LBBitPerPixel, v->SwathWidthYThisState, v->SwathWidthCThisState, - v->HRatio, - v->HRatioChroma, - v->vtaps, - v->VTAPsChroma, - v->VRatio, - v->VRatioChroma, - v->HTotal, - v->PixelClock, - v->BlendingAndTiming, v->NoOfDPPThisState, v->BytePerPixelInDETY, v->BytePerPixelInDETC, - v->DSTXAfterScaler, - v->DSTYAfterScaler, - v->WritebackEnable, - v->WritebackPixelFormat, - v->WritebackDestinationWidth, - v->WritebackDestinationHeight, - v->WritebackSourceHeight, UnboundedRequestEnabledThisState, CompressedBufferSizeInkByteThisState, &v->DRAMClockChangeSupport[i][j], - &v->UrgentWatermark, - &v->WritebackUrgentWatermark, - &v->DRAMClockChangeWatermark, - &v->WritebackDRAMClockChangeWatermark, - &dummy, &dummy, &dummy, &dummy, - &v->MinActiveDRAMClockChangeLatencySupported); + &dummy); } }
@@ -5663,64 +5555,28 @@ void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lstatic void CalculateWatermarksAndDRAMSpeedChangeSupport (struct display_mode_lib *mode_lib,unsigned int PrefetchMode, -unsigned int NumberOfActivePlanes, -unsigned int MaxLineBufferLines, -unsigned int LineBufferSize, -unsigned int WritebackInterfaceBufferSize,double DCFCLK ,double ReturnBW, -bool SynchronizedVBlank, -unsigned int dpte_group_bytes[], -unsigned int MetaChunkSize,double UrgentLatency,double ExtraLatency, -double WritebackLatency, -double WritebackChunkSize,double SOCCLK , -double DRAMClockChangeLatency, -double SRExitTime, -double SREnterPlusExitTime, -double SRExitZ8Time, -double SREnterPlusExitZ8Time,double DCFCLKDeepSleep,unsigned int DETBufferSizeY[],unsigned int DETBufferSizeC[],unsigned int SwathHeightY[],unsigned int SwathHeightC[], -unsigned int LBBitPerPixel[],double SwathWidthY[],double SwathWidthC[], -double HRatio[], -double HRatioChroma[], -unsigned int vtaps[], -unsigned int VTAPsChroma[], -double VRatio[], -double VRatioChroma[], -unsigned int HTotal[], -double PixelClock[], -unsigned int BlendingAndTiming[],unsigned int DPPPerPlane[],double BytePerPixelDETY[],double BytePerPixelDETC[], -double DSTXAfterScaler[], -double DSTYAfterScaler[], -bool WritebackEnable[], -enum source_format_class WritebackPixelFormat[], -double WritebackDestinationWidth[], -double WritebackDestinationHeight[], -double WritebackSourceHeight[],bool UnboundedRequestEnabled,int unsigned CompressedBufferSizeInkByte,enum clock_change_support *DRAMClockChangeSupport, -double *UrgentWatermark, -double *WritebackUrgentWatermark, -double *DRAMClockChangeWatermark, -double *WritebackDRAMClockChangeWatermark,double *StutterExitWatermark,double *StutterEnterPlusExitWatermark,double *Z8StutterExitWatermark, -double *Z8StutterEnterPlusExitWatermark, -double *MinActiveDRAMClockChangeLatencySupported) +double *Z8StutterEnterPlusExitWatermark) {struct vba_vars_st *v = &mode_lib->vba;double EffectiveLBLatencyHidingY;
@@ -5740,103 +5596,103 @@ static void CalculateWatermarksAndDRAMSpeedChangeSupport(double TotalPixelBW =0.0 ;int k, j; - *UrgentWatermark = UrgentLatency + ExtraLatency; + v->UrgentWatermark = UrgentLatency + ExtraLatency;#ifdef __DML_VBA_DEBUG__dml_print ("DML::%s: UrgentLatency = %f\n" , __func__, UrgentLatency);dml_print ("DML::%s: ExtraLatency = %f\n" , __func__, ExtraLatency); -dml_print ("DML::%s: UrgentWatermark = %f\n" , __func__, *UrgentWatermark); +dml_print ("DML::%s: UrgentWatermark = %f\n" , __func__, v->UrgentWatermark);#endif - *DRAMClockChangeWatermark = DRAMClockChangeLatency + *UrgentWatermark; + v->DRAMClockChangeWatermark = v->DRAMClockChangeLatency + v->UrgentWatermark;#ifdef __DML_VBA_DEBUG__ -dml_print ("DML::%s: DRAMClockChangeLatency = %f\n" , __func__, DRAMClockChangeLatency); -dml_print ("DML::%s: DRAMClockChangeWatermark = %f\n" , __func__, *DRAMClockChangeWatermark); +dml_print ("DML::%s: v->DRAMClockChangeLatency = %f\n" , __func__, v->DRAMClockChangeLatency); +dml_print ("DML::%s: DRAMClockChangeWatermark = %f\n" , __func__, v->DRAMClockChangeWatermark);#endif v->TotalActiveWriteback =0 ; -for (k =0 ; k < NumberOfActivePlanes; ++k) { -if (WritebackEnable[k] == true) { +for (k =0 ; k < v->NumberOfActivePlanes; ++k) { +if (v->WritebackEnable[k] == true) { v->TotalActiveWriteback = v->TotalActiveWriteback +1 ; } }if (v->TotalActiveWriteback <=1 ) { - *WritebackUrgentWatermark = WritebackLatency; + v->WritebackUrgentWatermark = v->WritebackLatency; }else { - *WritebackUrgentWatermark = WritebackLatency + WritebackChunkSize *1024.0 /32.0 /SOCCLK ; + v->WritebackUrgentWatermark = v->WritebackLatency + v->WritebackChunkSize *1024.0 /32.0 /SOCCLK ; }if (v->TotalActiveWriteback <=1 ) { - *WritebackDRAMClockChangeWatermark = DRAMClockChangeLatency + WritebackLatency; + v->WritebackDRAMClockChangeWatermark = v->DRAMClockChangeLatency + v->WritebackLatency; }else { - *WritebackDRAMClockChangeWatermark = DRAMClockChangeLatency + WritebackLatency + WritebackChunkSize *1024.0 /32.0 /SOCCLK ; + v->WritebackDRAMClockChangeWatermark = v->DRAMClockChangeLatency + v->WritebackLatency + v->WritebackChunkSize *1024.0 /32.0 /SOCCLK ; } -for (k =0 ; k < NumberOfActivePlanes; ++k) { +for (k =0 ; k < v->NumberOfActivePlanes; ++k) { TotalPixelBW = TotalPixelBW - + DPPPerPlane[k] * (SwathWidthY[k] * BytePerPixelDETY[k] * VRatio[k] + SwathWidthC[k] * BytePerPixelDETC[k] * VRatioChroma[k]) - / (HTotal[k] / PixelClock[k]); + + DPPPerPlane[k] * (SwathWidthY[k] * BytePerPixelDETY[k] * v->VRatio[k] + SwathWidthC[k] * BytePerPixelDETC[k] * v->VRatioChroma[k]) + / (v->HTotal[k] / v->PixelClock[k]); } -for (k =0 ; k < NumberOfActivePlanes; ++k) { +for (k =0 ; k < v->NumberOfActivePlanes; ++k) {double EffectiveDETBufferSizeY = DETBufferSizeY[k]; v->LBLatencyHidingSourceLinesY =dml_min ( - (double ) MaxLineBufferLines, -dml_floor (LineBufferSize / LBBitPerPixel[k] / (SwathWidthY[k] /dml_max (HRatio[k],1.0 )),1 )) - (vtaps[k] -1 ); + (double ) v->MaxLineBufferLines, +dml_floor (v->LineBufferSize / v->LBBitPerPixel[k] / (SwathWidthY[k] /dml_max (v->HRatio[k],1.0 )),1 )) - (v->vtaps[k] -1 ); v->LBLatencyHidingSourceLinesC =dml_min ( - (double ) MaxLineBufferLines, -dml_floor (LineBufferSize / LBBitPerPixel[k] / (SwathWidthC[k] /dml_max (HRatioChroma[k],1.0 )),1 )) - (VTAPsChroma[k] -1 ); + (double ) v->MaxLineBufferLines, +dml_floor (v->LineBufferSize / v->LBBitPerPixel[k] / (SwathWidthC[k] /dml_max (v->HRatioChroma[k],1.0 )),1 )) - (v->VTAPsChroma[k] -1 ); - EffectiveLBLatencyHidingY = v->LBLatencyHidingSourceLinesY / VRatio[k] * (HTotal[k] / PixelClock[k]); + EffectiveLBLatencyHidingY = v->LBLatencyHidingSourceLinesY / v->VRatio[k] * (v->HTotal[k] / v->PixelClock[k]); - EffectiveLBLatencyHidingC = v->LBLatencyHidingSourceLinesC / VRatioChroma[k] * (HTotal[k] / PixelClock[k]); + EffectiveLBLatencyHidingC = v->LBLatencyHidingSourceLinesC / v->VRatioChroma[k] * (v->HTotal[k] / v->PixelClock[k]);if (UnboundedRequestEnabled) { EffectiveDETBufferSizeY = EffectiveDETBufferSizeY - + CompressedBufferSizeInkByte *1024 * SwathWidthY[k] * BytePerPixelDETY[k] * VRatio[k] / (HTotal[k] / PixelClock[k]) / TotalPixelBW; + + CompressedBufferSizeInkByte *1024 * SwathWidthY[k] * BytePerPixelDETY[k] * v->VRatio[k] / (v->HTotal[k] / v->PixelClock[k]) / TotalPixelBW; } LinesInDETY[k] = (double ) EffectiveDETBufferSizeY / BytePerPixelDETY[k] / SwathWidthY[k]; LinesInDETYRoundedDownToSwath[k] =dml_floor (LinesInDETY[k], SwathHeightY[k]); - FullDETBufferingTimeY = LinesInDETYRoundedDownToSwath[k] * (HTotal[k] / PixelClock[k]) / VRatio[k]; + FullDETBufferingTimeY = LinesInDETYRoundedDownToSwath[k] * (v->HTotal[k] / v->PixelClock[k]) / v->VRatio[k];if (BytePerPixelDETC[k] >0 ) { LinesInDETC = v->DETBufferSizeC[k] / BytePerPixelDETC[k] / SwathWidthC[k]; LinesInDETCRoundedDownToSwath =dml_floor (LinesInDETC, SwathHeightC[k]); - FullDETBufferingTimeC = LinesInDETCRoundedDownToSwath * (HTotal[k] / PixelClock[k]) / VRatioChroma[k]; + FullDETBufferingTimeC = LinesInDETCRoundedDownToSwath * (v->HTotal[k] / v->PixelClock[k]) / v->VRatioChroma[k]; }else { LinesInDETC =0 ; FullDETBufferingTimeC =999999 ; } ActiveDRAMClockChangeLatencyMarginY = EffectiveLBLatencyHidingY + FullDETBufferingTimeY - - ((double ) DSTXAfterScaler[k] / HTotal[k] + DSTYAfterScaler[k]) * HTotal[k] / PixelClock[k] - *UrgentWatermark - *DRAMClockChangeWatermark; + - ((double ) v->DSTXAfterScaler[k] / v->HTotal[k] + v->DSTYAfterScaler[k]) * v->HTotal[k] / v->PixelClock[k] - v->UrgentWatermark - v->DRAMClockChangeWatermark; -if (NumberOfActivePlanes >1 ) { +if (v->NumberOfActivePlanes >1 ) { ActiveDRAMClockChangeLatencyMarginY = ActiveDRAMClockChangeLatencyMarginY - - (1 -1.0 / NumberOfActivePlanes) * SwathHeightY[k] * HTotal[k] / PixelClock[k] / VRatio[k]; + - (1 -1.0 / v->NumberOfActivePlanes) * SwathHeightY[k] * v->HTotal[k] / v->PixelClock[k] / v->VRatio[k]; }if (BytePerPixelDETC[k] >0 ) { ActiveDRAMClockChangeLatencyMarginC = EffectiveLBLatencyHidingC + FullDETBufferingTimeC - - ((double ) DSTXAfterScaler[k] / HTotal[k] + DSTYAfterScaler[k]) * HTotal[k] / PixelClock[k] - *UrgentWatermark - *DRAMClockChangeWatermark; + - ((double ) v->DSTXAfterScaler[k] / v->HTotal[k] + v->DSTYAfterScaler[k]) * v->HTotal[k] / v->PixelClock[k] - v->UrgentWatermark - v->DRAMClockChangeWatermark; -if (NumberOfActivePlanes >1 ) { +if (v->NumberOfActivePlanes >1 ) { ActiveDRAMClockChangeLatencyMarginC = ActiveDRAMClockChangeLatencyMarginC - - (1 -1.0 / NumberOfActivePlanes) * SwathHeightC[k] * HTotal[k] / PixelClock[k] / VRatioChroma[k]; + - (1 -1.0 / v->NumberOfActivePlanes) * SwathHeightC[k] * v->HTotal[k] / v->PixelClock[k] / v->VRatioChroma[k]; } v->ActiveDRAMClockChangeLatencyMargin[k] =dml_min (ActiveDRAMClockChangeLatencyMarginY, ActiveDRAMClockChangeLatencyMarginC); }else { v->ActiveDRAMClockChangeLatencyMargin[k] = ActiveDRAMClockChangeLatencyMarginY; } -if (WritebackEnable[k] == true) { - WritebackDRAMClockChangeLatencyHiding = WritebackInterfaceBufferSize *1024 - / (WritebackDestinationWidth[k] * WritebackDestinationHeight[k] / (WritebackSourceHeight[k] * HTotal[k] / PixelClock[k]) *4 ); -if (WritebackPixelFormat[k] == dm_444_64) { +if (v->WritebackEnable[k] == true) { + WritebackDRAMClockChangeLatencyHiding = v->WritebackInterfaceBufferSize *1024 + / (v->WritebackDestinationWidth[k] * v->WritebackDestinationHeight[k] / (v->WritebackSourceHeight[k] * v->HTotal[k] / v->PixelClock[k]) *4 ); +if (v->WritebackPixelFormat[k] == dm_444_64) { WritebackDRAMClockChangeLatencyHiding = WritebackDRAMClockChangeLatencyHiding /2 ; } WritebackDRAMClockChangeLatencyMargin = WritebackDRAMClockChangeLatencyHiding - v->WritebackDRAMClockChangeWatermark;
@@ -5846,14 +5702,14 @@ static void CalculateWatermarksAndDRAMSpeedChangeSupport( v->MinActiveDRAMClockChangeMargin =999999 ; PlaneWithMinActiveDRAMClockChangeMargin =0 ; -for (k =0 ; k < NumberOfActivePlanes; ++k) { +for (k =0 ; k < v->NumberOfActivePlanes; ++k) {if (v->ActiveDRAMClockChangeLatencyMargin[k] < v->MinActiveDRAMClockChangeMargin) { v->MinActiveDRAMClockChangeMargin = v->ActiveDRAMClockChangeLatencyMargin[k]; -if (BlendingAndTiming[k] == k) { +if (v->BlendingAndTiming[k] == k) { PlaneWithMinActiveDRAMClockChangeMargin = k; }else { -for (j =0 ; j < NumberOfActivePlanes; ++j) { -if (BlendingAndTiming[k] == j) { +for (j =0 ; j < v->NumberOfActivePlanes; ++j) { +if (v->BlendingAndTiming[k] == j) { PlaneWithMinActiveDRAMClockChangeMargin = j; } }
@@ -5861,11 +5717,11 @@ static void CalculateWatermarksAndDRAMSpeedChangeSupport( } } - *MinActiveDRAMClockChangeLatencySupported = v->MinActiveDRAMClockChangeMargin + DRAMClockChangeLatency; + v->MinActiveDRAMClockChangeLatencySupported = v->MinActiveDRAMClockChangeMargin + v->DRAMClockChangeLatency ; SecondMinActiveDRAMClockChangeMarginOneDisplayInVBLank =999999 ; -for (k =0 ; k < NumberOfActivePlanes; ++k) { -if (!((k == PlaneWithMinActiveDRAMClockChangeMargin) && (BlendingAndTiming[k] == k)) && !(BlendingAndTiming[k] == PlaneWithMinActiveDRAMClockChangeMargin) +for (k =0 ; k < v->NumberOfActivePlanes; ++k) { +if (!((k == PlaneWithMinActiveDRAMClockChangeMargin) && (v->BlendingAndTiming[k] == k)) && !(v->BlendingAndTiming[k] == PlaneWithMinActiveDRAMClockChangeMargin) && v->ActiveDRAMClockChangeLatencyMargin[k] < SecondMinActiveDRAMClockChangeMarginOneDisplayInVBLank) { SecondMinActiveDRAMClockChangeMarginOneDisplayInVBLank = v->ActiveDRAMClockChangeLatencyMargin[k]; }
@@ -5873,25 +5729,25 @@ static void CalculateWatermarksAndDRAMSpeedChangeSupport( v->TotalNumberOfActiveOTG =0 ; -for (k =0 ; k < NumberOfActivePlanes; ++k) { -if (BlendingAndTiming[k] == k) { +for (k =0 ; k < v->NumberOfActivePlanes; ++k) { +if (v->BlendingAndTiming[k] == k) { v->TotalNumberOfActiveOTG = v->TotalNumberOfActiveOTG +1 ; } }if (v->MinActiveDRAMClockChangeMargin >0 && PrefetchMode ==0 ) { *DRAMClockChangeSupport = dm_dram_clock_change_vactive; - }else if ((SynchronizedVBlank == true || v->TotalNumberOfActiveOTG ==1 + }else if ((v->SynchronizedVBlank == true || v->TotalNumberOfActiveOTG ==1 || SecondMinActiveDRAMClockChangeMarginOneDisplayInVBLank >0 ) && PrefetchMode ==0 ) { *DRAMClockChangeSupport = dm_dram_clock_change_vblank; }else { *DRAMClockChangeSupport = dm_dram_clock_change_unsupported; } - *StutterExitWatermark = SRExitTime + ExtraLatency +10 / DCFCLKDeepSleep; - *StutterEnterPlusExitWatermark = (SREnterPlusExitTime + ExtraLatency +10 / DCFCLKDeepSleep); - *Z8StutterExitWatermark = SRExitZ8Time + ExtraLatency +10 / DCFCLKDeepSleep; - *Z8StutterEnterPlusExitWatermark = SREnterPlusExitZ8Time + ExtraLatency +10 / DCFCLKDeepSleep; + *StutterExitWatermark = v->SRExitTime + ExtraLatency +10 / DCFCLKDeepSleep; + *StutterEnterPlusExitWatermark = (v->SREnterPlusExitTime + ExtraLatency +10 / DCFCLKDeepSleep); + *Z8StutterExitWatermark = v->SRExitZ8Time + ExtraLatency +10 / DCFCLKDeepSleep; + *Z8StutterEnterPlusExitWatermark = v->SREnterPlusExitZ8Time + ExtraLatency +10 / DCFCLKDeepSleep;#ifdef __DML_VBA_DEBUG__dml_print ("DML::%s: StutterExitWatermark = %f\n" , __func__, *StutterExitWatermark);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 183/207 drm/amd/display: Reduce number of arguments of dml31s CalculateFlipSchedule()
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
[ Upstream commit 21485d3da659b66c37d99071623af83ee1c6733d ]
Most of the arguments are identical between the two call sites and they can be accessed through the 'struct vba_vars_st' pointer. This reduces the total amount of stack space that dml31_ModeSupportAndSystemConfigurationFull() uses by 112 bytes with LLVM 16 (1976 -> 1864), helping clear up the following clang warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6: error: stack frame size (2216) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
--- .../dc/dml/dcn31/display_mode_vba_31.c | 172 +++++------------- 1 file changed, 47 insertions(+), 125 deletions(-)
drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c +47 -125
@@ -261,33 +261,13 @@ static void CalculateRowBandwidth(static void CalculateFlipSchedule (struct display_mode_lib *mode_lib, +unsigned int k,double HostVMInefficiencyFactor,double UrgentExtraLatency,double UrgentLatency, -unsigned int GPUVMMaxPageTableLevels, -bool HostVMEnable, -unsigned int HostVMMaxNonCachedPageTableLevels, -bool GPUVMEnable, -double HostVMMinPageSize,double PDEAndMetaPTEBytesPerFrame,double MetaRowBytes, -double DPTEBytesPerRow, -double BandwidthAvailableForImmediateFlip, -unsigned int TotImmediateFlipBytes, -enum source_format_class SourcePixelFormat, -double LineTime, -double VRatio, -double VRatioChroma, -double Tno_bw, -bool DCCEnable, -unsigned int dpte_row_height, -unsigned int meta_row_height, -unsigned int dpte_row_height_chroma, -unsigned int meta_row_height_chroma, -double *DestinationLinesToRequestVMInImmediateFlip, -double *DestinationLinesToRequestRowInImmediateFlip, -double *final_flip_bw, -bool *ImmediateFlipSupportedForPipe); +double DPTEBytesPerRow); static double CalculateWriteBackDelay( enum source_format_class WritebackPixelFormat, double WritebackHRatio,
@@ -2878,33 +2858,13 @@ static void DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanfor (k =0 ; k < v->NumberOfActivePlanes; ++k) {CalculateFlipSchedule ( mode_lib, + k, HostVMInefficiencyFactor, v->UrgentExtraLatency, v->UrgentLatency, - v->GPUVMMaxPageTableLevels, - v->HostVMEnable, - v->HostVMMaxNonCachedPageTableLevels, - v->GPUVMEnable, - v->HostVMMinPageSize, v->PDEAndMetaPTEBytesFrame[k], v->MetaRowByte[k], - v->PixelPTEBytesPerRow[k], - v->BandwidthAvailableForImmediateFlip, - v->TotImmediateFlipBytes, - v->SourcePixelFormat[k], - v->HTotal[k] / v->PixelClock[k], - v->VRatio[k], - v->VRatioChroma[k], - v->Tno_bw[k], - v->DCCEnable[k], - v->dpte_row_height[k], - v->meta_row_height[k], - v->dpte_row_height_chroma[k], - v->meta_row_height_chroma[k], - &v->DestinationLinesToRequestVMInImmediateFlip[k], - &v->DestinationLinesToRequestRowInImmediateFlip[k], - &v->final_flip_bw[k], - &v->ImmediateFlipSupportedForPipe[k]); + v->PixelPTEBytesPerRow[k]); } v->total_dcn_read_bw_with_flip =0.0 ;
@@ -3624,61 +3584,43 @@ static void CalculateRowBandwidth(static void CalculateFlipSchedule (struct display_mode_lib *mode_lib, +unsigned int k,double HostVMInefficiencyFactor,double UrgentExtraLatency,double UrgentLatency, -unsigned int GPUVMMaxPageTableLevels, -bool HostVMEnable, -unsigned int HostVMMaxNonCachedPageTableLevels, -bool GPUVMEnable, -double HostVMMinPageSize,double PDEAndMetaPTEBytesPerFrame,double MetaRowBytes, -double DPTEBytesPerRow, -double BandwidthAvailableForImmediateFlip, -unsigned int TotImmediateFlipBytes, -enum source_format_class SourcePixelFormat, -double LineTime, -double VRatio, -double VRatioChroma, -double Tno_bw, -bool DCCEnable, -unsigned int dpte_row_height, -unsigned int meta_row_height, -unsigned int dpte_row_height_chroma, -unsigned int meta_row_height_chroma, -double *DestinationLinesToRequestVMInImmediateFlip, -double *DestinationLinesToRequestRowInImmediateFlip, -double *final_flip_bw, -bool *ImmediateFlipSupportedForPipe) +double DPTEBytesPerRow) { +struct vba_vars_st *v = &mode_lib->vba;double min_row_time =0.0 ;unsigned int HostVMDynamicLevelsTrips;double TimeForFetchingMetaPTEImmediateFlip;double TimeForFetchingRowInVBlankImmediateFlip;double ImmediateFlipBW; +double LineTime = v->HTotal[k] / v->PixelClock[k]; -if (GPUVMEnable == true && HostVMEnable == true) { - HostVMDynamicLevelsTrips = HostVMMaxNonCachedPageTableLevels; +if (v->GPUVMEnable == true && v->HostVMEnable == true) { + HostVMDynamicLevelsTrips = v->HostVMMaxNonCachedPageTableLevels; }else { HostVMDynamicLevelsTrips =0 ; } -if (GPUVMEnable == true || DCCEnable == true) { - ImmediateFlipBW = (PDEAndMetaPTEBytesPerFrame + MetaRowBytes + DPTEBytesPerRow) * BandwidthAvailableForImmediateFlip / TotImmediateFlipBytes; +if (v->GPUVMEnable == true || v->DCCEnable[k] == true) { + ImmediateFlipBW = (PDEAndMetaPTEBytesPerFrame + MetaRowBytes + DPTEBytesPerRow) * v->BandwidthAvailableForImmediateFlip / v->TotImmediateFlipBytes; } -if (GPUVMEnable == true) { +if (v->GPUVMEnable == true) { TimeForFetchingMetaPTEImmediateFlip =dml_max3 ( - Tno_bw + PDEAndMetaPTEBytesPerFrame * HostVMInefficiencyFactor / ImmediateFlipBW, - UrgentExtraLatency + UrgentLatency * (GPUVMMaxPageTableLevels * (HostVMDynamicLevelsTrips +1 ) -1 ), + v->Tno_bw[k] + PDEAndMetaPTEBytesPerFrame * HostVMInefficiencyFactor / ImmediateFlipBW, + UrgentExtraLatency + UrgentLatency * (v->GPUVMMaxPageTableLevels * (HostVMDynamicLevelsTrips +1 ) -1 ), LineTime /4.0 ); }else { TimeForFetchingMetaPTEImmediateFlip =0 ; } - *DestinationLinesToRequestVMInImmediateFlip =dml_ceil (4.0 * (TimeForFetchingMetaPTEImmediateFlip / LineTime),1 ) /4.0 ; -if ((GPUVMEnable == true || DCCEnable == true)) { + v->DestinationLinesToRequestVMInImmediateFlip[k] =dml_ceil (4.0 * (TimeForFetchingMetaPTEImmediateFlip / LineTime),1 ) /4.0 ; +if ((v->GPUVMEnable == true || v->DCCEnable[k] == true)) { TimeForFetchingRowInVBlankImmediateFlip = dml_max3( (MetaRowBytes + DPTEBytesPerRow * HostVMInefficiencyFactor) / ImmediateFlipBW, UrgentLatency * (HostVMDynamicLevelsTrips + 1),
@@ -3687,54 +3629,54 @@ static void CalculateFlipSchedule( TimeForFetchingRowInVBlankImmediateFlip =0 ; } - *DestinationLinesToRequestRowInImmediateFlip =dml_ceil (4.0 * (TimeForFetchingRowInVBlankImmediateFlip / LineTime),1 ) /4.0 ; + v->DestinationLinesToRequestRowInImmediateFlip[k] =dml_ceil (4.0 * (TimeForFetchingRowInVBlankImmediateFlip / LineTime),1 ) /4.0 ; -if (GPUVMEnable == true) { - *final_flip_bw =dml_max ( - PDEAndMetaPTEBytesPerFrame * HostVMInefficiencyFactor / (*DestinationLinesToRequestVMInImmediateFlip * LineTime), - (MetaRowBytes + DPTEBytesPerRow * HostVMInefficiencyFactor) / (*DestinationLinesToRequestRowInImmediateFlip * LineTime)); - }else if ((GPUVMEnable == true || DCCEnable == true)) { - *final_flip_bw = (MetaRowBytes + DPTEBytesPerRow * HostVMInefficiencyFactor) / (*DestinationLinesToRequestRowInImmediateFlip * LineTime); +if (v->GPUVMEnable == true) { + v->final_flip_bw[k] =dml_max ( + PDEAndMetaPTEBytesPerFrame * HostVMInefficiencyFactor / (v->DestinationLinesToRequestVMInImmediateFlip[k] * LineTime), + (MetaRowBytes + DPTEBytesPerRow * HostVMInefficiencyFactor) / (v->DestinationLinesToRequestRowInImmediateFlip[k] * LineTime)); + }else if ((v->GPUVMEnable == true || v->DCCEnable[k] == true)) { + v->final_flip_bw[k] = (MetaRowBytes + DPTEBytesPerRow * HostVMInefficiencyFactor) / (v->DestinationLinesToRequestRowInImmediateFlip[k] * LineTime); }else { - *final_flip_bw =0 ; + v->final_flip_bw[k] =0 ; } -if (SourcePixelFormat == dm_420_8 || SourcePixelFormat == dm_420_10 || SourcePixelFormat == dm_rgbe_alpha) { -if (GPUVMEnable == true && DCCEnable != true) { - min_row_time =dml_min (dpte_row_height * LineTime / VRatio, dpte_row_height_chroma * LineTime / VRatioChroma); - }else if (GPUVMEnable != true && DCCEnable == true) { - min_row_time =dml_min (meta_row_height * LineTime / VRatio, meta_row_height_chroma * LineTime / VRatioChroma); +if (v->SourcePixelFormat[k] == dm_420_8 || v->SourcePixelFormat[k] == dm_420_10 || v->SourcePixelFormat[k] == dm_rgbe_alpha) { +if (v->GPUVMEnable == true && v->DCCEnable[k] != true) { + min_row_time =dml_min (v->dpte_row_height[k] * LineTime / v->VRatio[k], v->dpte_row_height_chroma[k] * LineTime / v->VRatioChroma[k]); + }else if (v->GPUVMEnable != true && v->DCCEnable[k] == true) { + min_row_time =dml_min (v->meta_row_height[k] * LineTime / v->VRatio[k], v->meta_row_height_chroma[k] * LineTime / v->VRatioChroma[k]); }else { min_row_time =dml_min4 ( - dpte_row_height * LineTime / VRatio, - meta_row_height * LineTime / VRatio, - dpte_row_height_chroma * LineTime / VRatioChroma, - meta_row_height_chroma * LineTime / VRatioChroma); + v->dpte_row_height[k] * LineTime / v->VRatio[k], + v->meta_row_height[k] * LineTime / v->VRatio[k], + v->dpte_row_height_chroma[k] * LineTime / v->VRatioChroma[k], + v->meta_row_height_chroma[k] * LineTime / v->VRatioChroma[k]); } }else { -if (GPUVMEnable == true && DCCEnable != true) { - min_row_time = dpte_row_height * LineTime / VRatio; - }else if (GPUVMEnable != true && DCCEnable == true) { - min_row_time = meta_row_height * LineTime / VRatio; +if (v->GPUVMEnable == true && v->DCCEnable[k] != true) { + min_row_time = v->dpte_row_height[k] * LineTime / v->VRatio[k]; + }else if (v->GPUVMEnable != true && v->DCCEnable[k] == true) { + min_row_time = v->meta_row_height[k] * LineTime / v->VRatio[k]; }else { - min_row_time =dml_min (dpte_row_height * LineTime / VRatio, meta_row_height * LineTime / VRatio); + min_row_time =dml_min (v->dpte_row_height[k] * LineTime / v->VRatio[k], v->meta_row_height[k] * LineTime / v->VRatio[k]); } } -if (*DestinationLinesToRequestVMInImmediateFlip >=32 || *DestinationLinesToRequestRowInImmediateFlip >=16 +if (v->DestinationLinesToRequestVMInImmediateFlip[k] >=32 || v->DestinationLinesToRequestRowInImmediateFlip[k] >=16 || TimeForFetchingMetaPTEImmediateFlip +2 * TimeForFetchingRowInVBlankImmediateFlip > min_row_time) { - *ImmediateFlipSupportedForPipe = false; + v->ImmediateFlipSupportedForPipe[k] = false; }else { - *ImmediateFlipSupportedForPipe = true; + v->ImmediateFlipSupportedForPipe[k] = true; }#ifdef __DML_VBA_DEBUG__ -dml_print ("DML::%s: DestinationLinesToRequestVMInImmediateFlip = %f\n" , __func__, *DestinationLinesToRequestVMInImmediateFlip); -dml_print ("DML::%s: DestinationLinesToRequestRowInImmediateFlip = %f\n" , __func__, *DestinationLinesToRequestRowInImmediateFlip); +dml_print ("DML::%s: DestinationLinesToRequestVMInImmediateFlip = %f\n" , __func__, v->DestinationLinesToRequestVMInImmediateFlip[k]); +dml_print ("DML::%s: DestinationLinesToRequestRowInImmediateFlip = %f\n" , __func__, v->DestinationLinesToRequestRowInImmediateFlip[k]);dml_print ("DML::%s: TimeForFetchingMetaPTEImmediateFlip = %f\n" , __func__, TimeForFetchingMetaPTEImmediateFlip);dml_print ("DML::%s: TimeForFetchingRowInVBlankImmediateFlip = %f\n" , __func__, TimeForFetchingRowInVBlankImmediateFlip);dml_print ("DML::%s: min_row_time = %f\n" , __func__, min_row_time); -dml_print ("DML::%s: ImmediateFlipSupportedForPipe = %d\n" , __func__, *ImmediateFlipSupportedForPipe); +dml_print ("DML::%s: ImmediateFlipSupportedForPipe = %d\n" , __func__, v->ImmediateFlipSupportedForPipe[k]);#endif }
@@ -5325,33 +5267,13 @@ void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lfor (k =0 ; k < v->NumberOfActivePlanes; k++) {CalculateFlipSchedule ( mode_lib, + k, HostVMInefficiencyFactor, v->ExtraLatency, v->UrgLatency[i], - v->GPUVMMaxPageTableLevels, - v->HostVMEnable, - v->HostVMMaxNonCachedPageTableLevels, - v->GPUVMEnable, - v->HostVMMinPageSize, v->PDEAndMetaPTEBytesPerFrame[i][j][k], v->MetaRowBytes[i][j][k], - v->DPTEBytesPerRow[i][j][k], - v->BandwidthAvailableForImmediateFlip, - v->TotImmediateFlipBytes, - v->SourcePixelFormat[k], - v->HTotal[k] / v->PixelClock[k], - v->VRatio[k], - v->VRatioChroma[k], - v->Tno_bw[k], - v->DCCEnable[k], - v->dpte_row_height[k], - v->meta_row_height[k], - v->dpte_row_height_chroma[k], - v->meta_row_height_chroma[k], - &v->DestinationLinesToRequestVMInImmediateFlip[k], - &v->DestinationLinesToRequestRowInImmediateFlip[k], - &v->final_flip_bw[k], - &v->ImmediateFlipSupportedForPipe[k]); + v->DPTEBytesPerRow[i][j][k]); } v->total_dcn_read_bw_with_flip =0.0 ;for (k =0 ; k < v->NumberOfActivePlanes; k++) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 184/207 drm/amd/display: Mark dml30s UseMinimumDCFCLK() as noinline for stack usage
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
[ Upstream commit 41012d715d5d7b9751ae84b8fb255e404ac9c5d0 ]
This function consumes a lot of stack space and it blows up the size of dml30_ModeSupportAndSystemConfigurationFull() with clang:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3542:6: error: stack frame size (2200) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
Commit a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning") aimed to address this for i386 but it did not help x86_64.
To reduce the amount of stack space that dml30_ModeSupportAndSystemConfigurationFull() uses, mark UseMinimumDCFCLK() as noinline, using the _for_stack variant for documentation. While this will increase the total amount of stack usage between the two functions (1632 and 1304 bytes respectively), it will make sure both stay below the limit of 2048 bytes for these files. The aforementioned change does help reduce UseMinimumDCFCLK()'s stack usage so it should not be reverted in favor of this change.
--- drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c +1 -2
@@ -6651,8 +6651,7 @@ static double CalculateUrgentLatency(return ret; } - -static void UseMinimumDCFCLK( +static noinline_for_stack void UseMinimumDCFCLK( struct display_mode_lib *mode_lib, int MaxInterDCNTileRepeaters, int MaxPrefetchMode,
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 185/207 drm/rockchip: Fix return type of cdn_dp_connector_mode_valid
In reply to Greg Kroah-HartmanFrom: Nathan Huckleberry <[email protected]>
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode *mode);
The mismatched return type breaks forward edge kCFI since the underlying function definition does not match the function hook definition.
The return type of cdn_dp_connector_mode_valid should be changed from int to enum drm_mode_status.
--- drivers/gpu/drm/rockchip/cdn-dp-core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/rockchip/cdn-dp-core.c +3 -2
@@ -283,8 +283,9 @@ static int cdn_dp_connector_get_modes(struct drm_connector *connector)return ret; } -static int cdn_dp_connector_mode_valid (struct drm_connector *connector, -struct drm_display_mode *mode) +static enum drm_mode_status +cdn_dp_connector_mode_valid (struct drm_connector *connector, +struct drm_display_mode *mode) {struct cdn_dp_device *dp =connector_to_dp (connector);struct drm_display_info *display_info = &dp->connector.display_info;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 186/207 gpio: mt7621: Make the irqchip immutable
In reply to Greg Kroah-HartmanFrom: Sergio Paracuellos <[email protected]>
[ Upstream commit 09eed5a1ed3c752892663976837eb4244c2f1984 ]
Commit 6c846d026d49 ("gpio: Don't fiddle with irqchips marked as immutable") added a warning to indicate if the gpiolib is altering the internals of irqchips. Following this change the following warnings are now observed for the mt7621 driver:
gpio gpiochip0: (1e000600.gpio-bank0): not an immutable chip, please consider fixing it! gpio gpiochip1: (1e000600.gpio-bank1): not an immutable chip, please consider fixing it! gpio gpiochip2: (1e000600.gpio-bank2): not an immutable chip, please consider fixing it!
Fix this by making the irqchip in the mt7621 driver immutable.
--- drivers/gpio/gpio-mt7621.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
drivers/gpio/gpio-mt7621.c +15 -6
@@ -112,6 +112,8 @@ mediatek_gpio_irq_unmask(struct irq_data *d)unsigned long flags;u32 rise, fall, high, low; +gpiochip_enable_irq (gc, d->hwirq); +spin_lock_irqsave (&rg->lock, flags); rise =mtk_gpio_r32 (rg,GPIO_REG_REDGE ); fall =mtk_gpio_r32 (rg,GPIO_REG_FEDGE );
@@ -143,6 +145,8 @@ mediatek_gpio_irq_mask(struct irq_data *d)mtk_gpio_w32 (rg,GPIO_REG_HLVL , high & ~BIT (pin));mtk_gpio_w32 (rg,GPIO_REG_LLVL , low & ~BIT (pin));spin_unlock_irqrestore (&rg->lock, flags); + +gpiochip_disable_irq (gc, d->hwirq); } static int
@@ -204,6 +208,16 @@ mediatek_gpio_xlate(struct gpio_chip *chip,return gpio %MTK_BANK_WIDTH ; } +static const struct irq_chip mt7621_irq_chip = { + .name ="mt7621-gpio" , + .irq_mask_ack = mediatek_gpio_irq_mask, + .irq_mask = mediatek_gpio_irq_mask, + .irq_unmask = mediatek_gpio_irq_unmask, + .irq_set_type = mediatek_gpio_irq_type, + .flags =IRQCHIP_IMMUTABLE , +GPIOCHIP_IRQ_RESOURCE_HELPERS , +}; +static int mediatek_gpio_bank_probe (struct device *dev,int bank) {
@@ -238,11 +252,6 @@ mediatek_gpio_bank_probe(struct device *dev, int bank)return -ENOMEM ; rg->chip.offset = bank *MTK_BANK_WIDTH ; - rg->irq_chip.name =dev_name (dev); - rg->irq_chip.irq_unmask = mediatek_gpio_irq_unmask; - rg->irq_chip.irq_mask = mediatek_gpio_irq_mask; - rg->irq_chip.irq_mask_ack = mediatek_gpio_irq_mask; - rg->irq_chip.irq_set_type = mediatek_gpio_irq_type;if (mtk->gpio_irq) {struct gpio_irq_chip *girq;
@@ -262,7 +271,7 @@ mediatek_gpio_bank_probe(struct device *dev, int bank) } girq = &rg->chip.irq; - girq->chip = &rg->irq_chip; +gpio_irq_chip_set_chip (girq, &mt7621_irq_chip);/* This will let us handle the parent IRQ in the driver */ girq->parent_handler =NULL ; girq->num_parents =0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 187/207 pmem: fix a name collision
In reply to Greg Kroah-HartmanFrom: Jane Chu <[email protected]>
[ Upstream commit 149d17140bcedc906082c4f874dec98b1ffc5a90 ]
Kernel test robot detected name collision when compiled on 'um' architecture. Rename "to_phys()" to "pmem_to_phys()".
Quoted 1 line
Quoted 1 line
drivers/nvdimm/pmem.c:48:20: error: conflicting types for 'to_phys'; have 'phys_addr_t(struct pmem_device *, phys_addr_t)' {aka 'long long unsignedint(struct pmem_device *, long long unsigned int)'}
48 | static phys_addr_t to_phys(struct pmem_device *pmem, phys_addr_t offset)
| ^~~~~~~
In file included from arch/um/include/asm/page.h:98,
from arch/um/include/asm/thread_info.h:15,
from include/linux/thread_info.h:60,
from include/asm-generic/preempt.h:5,
from ./arch/um/include/generated/asm/preempt.h:1,
arch/um/include/shared/mem.h:12:29: note: previous definition of 'to_phys' with type 'long unsigned int(void *)'
12 | static inline unsigned long to_phys(void *virt)
| ^~~~~~~
vim +48 drivers/nvdimm/pmem.c
47
Quoted 1 line
48 static
phys_addr_tto_phys(struct pmem_device *pmem, phys_addr_t offset)
49 {
50 return pmem->phys_addr + offset;
51 }
52--- drivers/nvdimm/pmem.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/nvdimm/pmem.c +3 -3
@@ -45,7 +45,7 @@ static struct nd_region *to_region(struct pmem_device *pmem)return to_nd_region (to_dev (pmem)->parent); } -static phys_addr_t to_phys (struct pmem_device *pmem,phys_addr_t offset) +static phys_addr_t pmem_to_phys (struct pmem_device *pmem,phys_addr_t offset) {return pmem->phys_addr + offset; }
@@ -63,7 +63,7 @@ static phys_addr_t to_offset(struct pmem_device *pmem, sector_t sector)static void pmem_mkpage_present (struct pmem_device *pmem,phys_addr_t offset,unsigned int len) { -phys_addr_t phys =to_phys (pmem, offset); +phys_addr_t phys =pmem_to_phys (pmem, offset);unsigned long pfn_start, pfn_end, pfn;/* only pmem in the linear map supports HWPoison */
@@ -97,7 +97,7 @@ static void pmem_clear_bb(struct pmem_device *pmem, sector_t sector, long blks)static long __pmem_clear_poison (struct pmem_device *pmem,phys_addr_t offset,unsigned int len) { -phys_addr_t phys =to_phys (pmem, offset); +phys_addr_t phys =pmem_to_phys (pmem, offset);long cleared =nvdimm_clear_poison (to_dev (pmem), phys, len);if (cleared >0 ) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 188/207 fsdax: Fix infinite loop in dax_iomap_rw()
In reply to Greg Kroah-HartmanFrom: Li Jinlin <[email protected]>
[ Upstream commit 17d9c15c9b9e7fb285f7ac5367dfb5f00ff575e3 ]
I got an infinite loop and a WARNING report when executing a tail command in virtiofs.
WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0 Modules linked in: CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7 Call Trace: <TASK> dax_iomap_rw+0xea/0x620 ? __this_cpu_preempt_check+0x13/0x20 fuse_dax_read_iter+0x47/0x80 fuse_file_read_iter+0xae/0xd0 new_sync_read+0xfe/0x180 ? 0xffffffff81000000 vfs_read+0x14d/0x1a0 ksys_read+0x6d/0xf0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The tail command will call read() with a count of 0. In this case, iomap_iter() will report this WARNING, and always return 1 which casuing the infinite loop in dax_iomap_rw().
Fixing by checking count whether is 0 in dax_iomap_rw().
--- fs/dax.c | 3 +++ 1 file changed, 3 insertions(+)
fs/dax.c +3 -0
@@ -1241,6 +1241,9 @@ dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter,loff_t done =0 ;int ret; +if (!iomi.len) +return 0 ; +if (iov_iter_rw (iter) ==WRITE ) {lockdep_assert_held_write (&iomi.inode->i_rwsem); iomi.flags |=IOMAP_WRITE ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 189/207 workqueue: dont skip lockdep work dependency in cancel_work_sync()
In reply to Greg Kroah-HartmanFrom: Tetsuo Handa <[email protected]>
[ Upstream commit c0feea594e058223973db94c1c32a830c9807c86 ]
Like Hillf Danton mentioned
syzbot should have been able to catch cancel_work_sync() in work context by checking lockdep_map in __flush_work() for both flush and cancel.
in [1], being unable to report an obvious deadlock scenario shown below is broken. From locking dependency perspective, sync version of cancel request should behave as if flush request, for it waits for completion of work if that work has already started execution.
----------
#include <linux/module.h>
#include <linux/sched.h>
static DEFINE_MUTEX(mutex);
static void work_fn(struct work_struct *work)
{
schedule_timeout_uninterruptible(HZ / 5);
mutex_lock(&mutex);
mutex_unlock(&mutex);
}
static DECLARE_WORK(work, work_fn);
static int __init test_init(void)
{
schedule_work(&work);
schedule_timeout_uninterruptible(HZ / 10);
mutex_lock(&mutex);
cancel_work_sync(&work);
mutex_unlock(&mutex);
return -EINVAL;
}
module_init(test_init);
MODULE_LICENSE("GPL");
----------The check this patch restores was added by commit 0976dfc1d0cd80a4 ("workqueue: Catch more locking problems with flush_work()").
Then, lockdep's crossrelease feature was added by commit b09be676e0ff25bd ("locking/lockdep: Implement the 'crossrelease' feature"). As a result, this check was once removed by commit fd1a5b04dfb899f8 ("workqueue: Remove now redundant lock acquisitions wrt. workqueue flushes").
But lockdep's crossrelease feature was removed by commit e966eaeeb623f099 ("locking/lockdep: Remove the cross-release locking checks"). At this point, this check should have been restored.
Then, commit d6e89786bed977f3 ("workqueue: skip lockdep wq dependency in cancel_work_sync()") introduced a boolean flag in order to distinguish flush_work() and cancel_work_sync(), for checking "struct workqueue_struct" dependency when called from cancel_work_sync() was causing false positives.
Then, commit 87915adc3f0acdf0 ("workqueue: re-add lockdep dependencies for flushing") tried to restore "struct work_struct" dependency check, but by error checked this boolean flag. Like an example shown above indicates, "struct work_struct" dependency needs to be checked for both flush_work() and cancel_work_sync().
--- kernel/workqueue.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
kernel/workqueue.c +2 -4
@@ -3066,10 +3066,8 @@ static bool __flush_work(struct work_struct *work, bool from_cancel)if (WARN_ON (!work->func))return false; -if (!from_cancel) { -lock_map_acquire (&work->lockdep_map); -lock_map_release (&work->lockdep_map); - } +lock_map_acquire (&work->lockdep_map); +lock_map_release (&work->lockdep_map);if (start_flush_work (work, &barr, from_cancel)) {wait_for_completion (&barr.done);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 190/207 i2c: imx: If pm_runtime_get_sync() returned 1 device access is possible
In reply to Greg Kroah-HartmanFrom: Uwe Kleine-König <[email protected]>
[ Upstream commit 085aacaa73163f4b8a89dec24ecb32cfacd34017 ]
pm_runtime_get_sync() returning 1 also means the device is powered. So resetting the chip registers in .remove() is possible and should be done.
--- drivers/i2c/busses/i2c-imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i2c/busses/i2c-imx.c +1 -1
@@ -1583,7 +1583,7 @@ static int i2c_imx_remove(struct platform_device *pdev)if (i2c_imx->dma)i2c_imx_dma_free (i2c_imx); -if (ret ==0 ) { +if (ret >=0 ) {/* setup chip registers to defaults */ imx_i2c_write_reg (0 , i2c_imx,IMX_I2C_IADR );imx_i2c_write_reg (0 , i2c_imx,IMX_I2C_IFDR );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 191/207 i2c: mlxbf: incorrect base address passed during io write
In reply to Greg Kroah-HartmanFrom: Asmaa Mnebhi <[email protected]>
[ Upstream commit 2a5be6d1340c0fefcee8a6489cff7fd88a0d5b85 ]
Correct the base address used during io write.
This bug had no impact over the overall functionality of the read and write transactions. MLXBF_I2C_CAUSE_OR_CLEAR=0x18 so writing to (smbus->io + 0x18) instead of (mst_cause->ioi + 0x18) actually writes to the sc_low_timeout register which just sets the timeout value before a read/write aborts.
--- drivers/i2c/busses/i2c-mlxbf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i2c/busses/i2c-mlxbf.c +1 -1
@@ -669,7 +669,7 @@ static int mlxbf_i2c_smbus_enable(struct mlxbf_i2c_priv *priv, u8 slave,/* Clear status bits. */ writel (0x0 , priv->smbus->io +MLXBF_I2C_SMBUS_MASTER_STATUS );/* Set the cause data. */ -writel (~0x0 , priv->smbus->io +MLXBF_I2C_CAUSE_OR_CLEAR ); +writel (~0x0 , priv->mst_cause->io +MLXBF_I2C_CAUSE_OR_CLEAR );/* Zero PEC byte. */ writel (0x0 , priv->smbus->io +MLXBF_I2C_SMBUS_MASTER_PEC );/* Zero byte count. */
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 192/207 i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()
In reply to Greg Kroah-HartmanFrom: Asmaa Mnebhi <[email protected]>
[ Upstream commit de24aceb07d426b6f1c59f33889d6a964770547b ]
memcpy() is called in a loop while 'operation->length' upper bound is not checked and 'data_idx' also increments.
--- drivers/i2c/busses/i2c-mlxbf.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/i2c/busses/i2c-mlxbf.c +3 -0
@@ -738,6 +738,9 @@ mlxbf_i2c_smbus_start_transaction(struct mlxbf_i2c_priv *priv,if (flags &MLXBF_I2C_F_WRITE ) { write_en =1 ; write_len += operation->length; +if (data_idx + operation->length > +MLXBF_I2C_MASTER_DATA_DESC_SIZE ) +return -ENOBUFS ;memcpy (data_desc + data_idx, operation->buffer, operation->length); data_idx += operation->length;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 193/207 i2c: mlxbf: Fix frequency calculation
In reply to Greg Kroah-HartmanFrom: Asmaa Mnebhi <[email protected]>
[ Upstream commit 37f071ec327b04c83d47637c5e5c2199b39899ca ]
The i2c-mlxbf.c driver is currently broken because there is a bug in the calculation of the frequency. core_f, core_r and core_od are components read from hardware registers and are used to compute the frequency used to compute different timing parameters. The shifting mechanism used to get core_f, core_r and core_od is wrong. Use FIELD_GET to mask and shift the bitfields properly.
--- drivers/i2c/busses/i2c-mlxbf.c | 63 +++++++++++++--------------------- 1 file changed, 23 insertions(+), 40 deletions(-)
drivers/i2c/busses/i2c-mlxbf.c +23 -40
@@ -6,6 +6,7 @@*/ #include <linux/acpi.h> +#include <linux/bitfield.h> #include <linux/delay.h> #include <linux/err.h> #include <linux/interrupt.h>
@@ -63,13 +64,14 @@*/ #define MLXBF_I2C_TYU_PLL_OUT_FREQ (400 * 1000 * 1000)/* Reference clock for Bluefield - 156 MHz. */ -#define MLXBF_I2C_PLL_IN_FREQ (156 * 1000 * 1000) +#define MLXBF_I2C_PLL_IN_FREQ 156250000ULL/* Constant used to determine the PLL frequency. */ -#define MLNXBF_I2C_COREPLL_CONST 16384 +#define MLNXBF_I2C_COREPLL_CONST 16384ULL + +#define MLXBF_I2C_FREQUENCY_1GHZ 1000000000ULL/* PLL registers. */ -#define MLXBF_I2C_CORE_PLL_REG0 0x0#define MLXBF_I2C_CORE_PLL_REG1 0x4#define MLXBF_I2C_CORE_PLL_REG2 0x8
@@ -181,22 +183,15 @@#define MLXBF_I2C_COREPLL_FREQ MLXBF_I2C_TYU_PLL_OUT_FREQ/* Core PLL TYU configuration. */ -#define MLXBF_I2C_COREPLL_CORE_F_TYU_MASK GENMASK(12, 0) -#define MLXBF_I2C_COREPLL_CORE_OD_TYU_MASK GENMASK(3, 0) -#define MLXBF_I2C_COREPLL_CORE_R_TYU_MASK GENMASK(5, 0) - -#define MLXBF_I2C_COREPLL_CORE_F_TYU_SHIFT 3 -#define MLXBF_I2C_COREPLL_CORE_OD_TYU_SHIFT 16 -#define MLXBF_I2C_COREPLL_CORE_R_TYU_SHIFT 20 +#define MLXBF_I2C_COREPLL_CORE_F_TYU_MASK GENMASK(15, 3) +#define MLXBF_I2C_COREPLL_CORE_OD_TYU_MASK GENMASK(19, 16) +#define MLXBF_I2C_COREPLL_CORE_R_TYU_MASK GENMASK(25, 20)/* Core PLL YU configuration. */ #define MLXBF_I2C_COREPLL_CORE_F_YU_MASK GENMASK(25, 0)#define MLXBF_I2C_COREPLL_CORE_OD_YU_MASK GENMASK(3, 0) -#define MLXBF_I2C_COREPLL_CORE_R_YU_MASK GENMASK(5, 0) +#define MLXBF_I2C_COREPLL_CORE_R_YU_MASK GENMASK(31, 26) -#define MLXBF_I2C_COREPLL_CORE_F_YU_SHIFT 0 -#define MLXBF_I2C_COREPLL_CORE_OD_YU_SHIFT 1 -#define MLXBF_I2C_COREPLL_CORE_R_YU_SHIFT 26/* Core PLL frequency. */ static u64 mlxbf_i2c_corepll_frequency;
@@ -479,8 +474,6 @@ static struct mutex mlxbf_i2c_bus_lock;#define MLXBF_I2C_MASK_8 GENMASK(7, 0)#define MLXBF_I2C_MASK_16 GENMASK(15, 0) -#define MLXBF_I2C_FREQUENCY_1GHZ 1000000000 -/* * Function to poll a set of bits at a specific address; it checks whether * the bits are equal to zero when eq_zero is set to 'true', and not equal
@@ -1410,24 +1403,19 @@ static int mlxbf_i2c_init_master(struct platform_device *pdev,return 0 ; } -static u64 mlxbf_calculate_freq_from_tyu (struct mlxbf_i2c_resource *corepll_res) +static u64 mlxbf_i2c_calculate_freq_from_tyu (struct mlxbf_i2c_resource *corepll_res) { -u64 core_frequency, pad_frequency; +u64 core_frequency;u8 core_od, core_r;u32 corepll_val;u16 core_f; - pad_frequency =MLXBF_I2C_PLL_IN_FREQ ; - corepll_val =readl (corepll_res->io +MLXBF_I2C_CORE_PLL_REG1 );/* Get Core PLL configuration bits. */ - core_f =rol32 (corepll_val,MLXBF_I2C_COREPLL_CORE_F_TYU_SHIFT ) & -MLXBF_I2C_COREPLL_CORE_F_TYU_MASK ; - core_od =rol32 (corepll_val,MLXBF_I2C_COREPLL_CORE_OD_TYU_SHIFT ) & -MLXBF_I2C_COREPLL_CORE_OD_TYU_MASK ; - core_r =rol32 (corepll_val,MLXBF_I2C_COREPLL_CORE_R_TYU_SHIFT ) & -MLXBF_I2C_COREPLL_CORE_R_TYU_MASK ; + core_f =FIELD_GET (MLXBF_I2C_COREPLL_CORE_F_TYU_MASK , corepll_val); + core_od =FIELD_GET (MLXBF_I2C_COREPLL_CORE_OD_TYU_MASK , corepll_val); + core_r =FIELD_GET (MLXBF_I2C_COREPLL_CORE_R_TYU_MASK , corepll_val);/* * Compute PLL output frequency as follow:
@@ -1439,31 +1427,26 @@ static u64 mlxbf_calculate_freq_from_tyu(struct mlxbf_i2c_resource *corepll_res)* Where PLL_OUT_FREQ and PLL_IN_FREQ refer to CoreFrequency * and PadFrequency, respectively. */ - core_frequency = pad_frequency * (++core_f); + core_frequency =MLXBF_I2C_PLL_IN_FREQ * (++core_f); core_frequency /= (++core_r) * (++core_od);return core_frequency; } -static u64 mlxbf_calculate_freq_from_yu (struct mlxbf_i2c_resource *corepll_res) +static u64 mlxbf_i2c_calculate_freq_from_yu (struct mlxbf_i2c_resource *corepll_res) {u32 corepll_reg1_val, corepll_reg2_val; -u64 corepll_frequency, pad_frequency; +u64 corepll_frequency;u8 core_od, core_r;u32 core_f; - pad_frequency =MLXBF_I2C_PLL_IN_FREQ ; - corepll_reg1_val =readl (corepll_res->io +MLXBF_I2C_CORE_PLL_REG1 ); corepll_reg2_val =readl (corepll_res->io +MLXBF_I2C_CORE_PLL_REG2 );/* Get Core PLL configuration bits */ - core_f =rol32 (corepll_reg1_val,MLXBF_I2C_COREPLL_CORE_F_YU_SHIFT ) & -MLXBF_I2C_COREPLL_CORE_F_YU_MASK ; - core_r =rol32 (corepll_reg1_val,MLXBF_I2C_COREPLL_CORE_R_YU_SHIFT ) & -MLXBF_I2C_COREPLL_CORE_R_YU_MASK ; - core_od =rol32 (corepll_reg2_val,MLXBF_I2C_COREPLL_CORE_OD_YU_SHIFT ) & -MLXBF_I2C_COREPLL_CORE_OD_YU_MASK ; + core_f =FIELD_GET (MLXBF_I2C_COREPLL_CORE_F_YU_MASK , corepll_reg1_val); + core_r =FIELD_GET (MLXBF_I2C_COREPLL_CORE_R_YU_MASK , corepll_reg1_val); + core_od =FIELD_GET (MLXBF_I2C_COREPLL_CORE_OD_YU_MASK , corepll_reg2_val);/* * Compute PLL output frequency as follow:
@@ -1475,7 +1458,7 @@ static u64 mlxbf_calculate_freq_from_yu(struct mlxbf_i2c_resource *corepll_res)* Where PLL_OUT_FREQ and PLL_IN_FREQ refer to CoreFrequency * and PadFrequency, respectively. */ - corepll_frequency = (pad_frequency * core_f) /MLNXBF_I2C_COREPLL_CONST ; + corepll_frequency = (MLXBF_I2C_PLL_IN_FREQ * core_f) /MLNXBF_I2C_COREPLL_CONST ; corepll_frequency /= (++core_r) * (++core_od);return corepll_frequency;
@@ -2183,14 +2166,14 @@ static struct mlxbf_i2c_chip_info mlxbf_i2c_chip[] = { [1] = &mlxbf_i2c_corepll_res[MLXBF_I2C_CHIP_TYPE_1], [2 ] = &mlxbf_i2c_gpio_res[MLXBF_I2C_CHIP_TYPE_1 ] }, - .calculate_freq = mlxbf_calculate_freq_from_tyu + .calculate_freq = mlxbf_i2c_calculate_freq_from_tyu }, [MLXBF_I2C_CHIP_TYPE_2] = { .type = MLXBF_I2C_CHIP_TYPE_2, .shared_res = { [0 ] = &mlxbf_i2c_corepll_res[MLXBF_I2C_CHIP_TYPE_2 ] }, - .calculate_freq = mlxbf_calculate_freq_from_yu + .calculate_freq = mlxbf_i2c_calculate_freq_from_yu } };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 194/207 i2c: mux: harden i2c_mux_alloc() against integer overflows
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit b7af938f4379a884f15713319648a7653497a907 ]
A couple years back we went through the kernel an automatically converted size calculations to use struct_size() instead. The struct_size() calculation is protected against integer overflows.
However it does not make sense to use the result from struct_size() for additional math operations as that would negate any safeness.
--- drivers/i2c/i2c-mux.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/i2c/i2c-mux.c +3 -2
@@ -243,9 +243,10 @@ struct i2c_mux_core *i2c_mux_alloc(struct i2c_adapter *parent, int (*deselect)(struct i2c_mux_core *, u32)) {struct i2c_mux_core *muxc; +size_t mux_size; - muxc =devm_kzalloc (dev,struct_size (muxc, adapter, max_adapters) - + sizeof_priv,GFP_KERNEL ); + mux_size =struct_size (muxc, adapter, max_adapters); + muxc =devm_kzalloc (dev,size_add (mux_size, sizeof_priv),GFP_KERNEL );if (!muxc)return NULL ;if (sizeof_priv)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 195/207 drm/amdgpu: dont register a dirty callback for non-atomic
In reply to Greg Kroah-HartmanFrom: Alex Deucher <[email protected]>
[ Upstream commit abbc7a3dafb91b9d4ec56b70ec9a7520f8e13334 ]
Some asics still support non-atomic code paths.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +10 -1
@@ -36,6 +36,7 @@#include <linux/pm_runtime.h> #include <drm/drm_crtc_helper.h> #include <drm/drm_damage_helper.h> +#include <drm/drm_drv.h> #include <drm/drm_edid.h> #include <drm/drm_gem_framebuffer_helper.h> #include <drm/drm_fb_helper.h>
@@ -494,6 +495,11 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector *amdgpu_connector,static const struct drm_framebuffer_funcs amdgpu_fb_funcs = { .destroy = drm_gem_fb_destroy, .create_handle = drm_gem_fb_create_handle, +}; + +static const struct drm_framebuffer_funcs amdgpu_fb_funcs_atomic = { + .destroy = drm_gem_fb_destroy, + .create_handle = drm_gem_fb_create_handle, .dirty = drm_atomic_helper_dirtyfb, };
@@ -1071,7 +1077,10 @@ static int amdgpu_display_gem_fb_verify_and_init(struct drm_device *dev,if (ret) goto err; - ret =drm_framebuffer_init (dev, &rfb->base, &amdgpu_fb_funcs); +if (drm_drv_uses_atomic_modeset (dev)) + ret =drm_framebuffer_init (dev, &rfb->base, &amdgpu_fb_funcs_atomic); +else + ret =drm_framebuffer_init (dev, &rfb->base, &amdgpu_fb_funcs);if (ret) goto err;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 196/207 certs: make system keyring depend on built-in x509 parser
In reply to Greg Kroah-HartmanFrom: Masahiro Yamada <[email protected]>
[ Upstream commit 2154aca21408752eaa3eeaf2ba6e942724ff2a4d ]
Commit e90886291c7c ("certs: make system keyring depend on x509 parser") is not the right fix because x509_load_certificate_list() can be modular.
The combination of CONFIG_SYSTEM_TRUSTED_KEYRING=y and CONFIG_X509_CERTIFICATE_PARSER=m still results in the following error:
LD .tmp_vmlinux.kallsyms1
ld: certs/system_keyring.o: in function `load_system_certificate_list':
system_keyring.c:(.init.text+0x8c): undefined reference to `x509_load_certificate_list'
make: *** [Makefile:1169: vmlinux] Error 1
--- certs/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
certs/Kconfig +1 -1
@@ -43,7 +43,7 @@ config SYSTEM_TRUSTED_KEYRING bool "Provide system-wide ring of trusted keys" depends on KEYS depends on ASYMMETRIC_KEY_TYPE - depends on X509_CERTIFICATE_PARSER + depends on X509_CERTIFICATE_PARSER = y help Provide a system keyring to which trusted keys can be added. Keys in the keyring are considered to be trusted. Keys may be added at will
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 197/207 Makefile.debug: set -g unconditional on CONFIG_DEBUG_INFO_SPLIT
In reply to Greg Kroah-HartmanFrom: Nick Desaulniers <[email protected]>
[ Upstream commit 61f2b7c7497ba96cdde5bbaeb9e07f4c48f41f97 ]
Dmitrii, Fangrui, and Mashahiro note:
Before GCC 11 and Clang 12 -gsplit-dwarf implicitly uses -g2.
Fix CONFIG_DEBUG_INFO_SPLIT for gcc-11+ & clang-12+ which now need -g specified in order for -gsplit-dwarf to work at all.
-gsplit-dwarf has been mutually exclusive with -g since support for CONFIG_DEBUG_INFO_SPLIT was introduced in
commit 866ced950bcd ("kbuild: Support split debug info v4") I don't think it ever needed to be.
Stable-dep-of: 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files")
--- scripts/Makefile.debug | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
scripts/Makefile.debug +1 -3
@@ -1,9 +1,7 @@ -DEBUG_CFLAGS := +DEBUG_CFLAGS := -g ifdef CONFIG_DEBUG_INFO_SPLIT DEBUG_CFLAGS += -gsplit-dwarf -else -DEBUG_CFLAGS += -g endif ifndef CONFIG_AS_IS_LLVM
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 198/207 Makefile.debug: re-enable debug info for .S files
In reply to Greg Kroah-HartmanFrom: Nick Desaulniers <[email protected]>
[ Upstream commit 32ef9e5054ec0321b9336058c58ec749e9c6b0fe ]
Alexey reported that the fraction of unknown filename instances in kallsyms grew from ~0.3% to ~10% recently; Bill and Greg tracked it down to assembler defined symbols, which regressed as a result of:
commit b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1")
In that commit, I allude to restoring debug info for assembler defined symbols in a follow up patch, but it seems I forgot to do so in
commit a66049e2cf0e ("Kbuild: make DWARF version a choice")
--- lib/Kconfig.debug | 4 +++- scripts/Makefile.debug | 21 +++++++++++---------- 2 files changed, 14 insertions(+), 11 deletions(-)
lib/Kconfig.debug +3 -1
@@ -264,8 +264,10 @@ config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT config DEBUG_INFO_DWARF4 bool "Generate DWARF Version 4 debuginfo" select DEBUG_INFO + depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502))) help - Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+. + Generate DWARF v4 debug info. This requires gcc 4.5+, binutils 2.35.2 + if using clang without clang's integrated assembler, and gdb 7.0+. If you have consumers of DWARF debug info that are not ready for newer revisions of DWARF, you may wish to choose this or have your
scripts/Makefile.debug +11 -10
@@ -1,18 +1,19 @@ -DEBUG_CFLAGS := -g +DEBUG_CFLAGS := +debug-flags-y := -g ifdef CONFIG_DEBUG_INFO_SPLIT DEBUG_CFLAGS += -gsplit-dwarf endif -ifndef CONFIG_AS_IS_LLVM -KBUILD_AFLAGS += -Wa,-gdwarf-2 -endif - -ifndef CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4 -dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5 -DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y) +debug-flags-$(CONFIG_DEBUG_INFO_DWARF4) += -gdwarf-4 +debug-flags-$(CONFIG_DEBUG_INFO_DWARF5) += -gdwarf-5 +ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_AS_IS_GNU),yy) +# Clang does not pass -g or -gdwarf-* option down to GAS. +# Add -Wa, prefix to explicitly specify the flags. +KBUILD_AFLAGS += $(addprefix -Wa$(comma), $(debug-flags-y)) endif +DEBUG_CFLAGS += $(debug-flags-y) +KBUILD_AFLAGS += $(debug-flags-y) ifdef CONFIG_DEBUG_INFO_REDUCED DEBUG_CFLAGS += -fno-var-tracking
@@ -27,5 +28,5 @@ KBUILD_AFLAGS += -gz=zlib KBUILD_LDFLAGS += --compress-debug-sections=zlib endif -KBUILD_CFLAGS += $(DEBUG_CFLAGS) +KBUILD_CFLAGS += $(DEBUG_CFLAGS) export DEBUG_CFLAGS
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 199/207 devdax: Fix soft-reservation memory description
In reply to Greg Kroah-HartmanFrom: Dan Williams <[email protected]>
commit 67feaba413ec68daf4124e9870878899b4ed9a0e upstream.
The "hmem" platform-devices that are created to represent the platform-advertised "Soft Reserved" memory ranges end up inserting a resource that causes the iomem_resource tree to look like this:
340000000-43fffffff : hmem.0
340000000-43fffffff : Soft Reserved
340000000-43fffffff : dax0.0
This is because insert_resource() reparents ranges when they completely intersect an existing range.
This matters because code that uses region_intersects() to scan for a given IORES_DESC will only check that top-level 'hmem.0' resource and not the 'Soft Reserved' descendant.
So, to support EINJ (via einj_error_inject()) to inject errors into memory hosted by a dax-device, be sure to describe the memory as IORES_DESC_SOFT_RESERVED. This is a follow-on to:
commit b13a3e5fd40b ("ACPI: APEI: Fix _EINJ vs EFI_MEMORY_SP")
...that fixed EINJ support for "Soft Reserved" ranges in the first instance.
--- drivers/dax/hmem/device.c | 1 + 1 file changed, 1 insertion(+)
drivers/dax/hmem/device.c +1 -0
@@ -15,6 +15,7 @@ void hmem_register_device(int target_nid .start = r->start, .end = r->end, .flags = IORESOURCE_MEM, + .desc = IORES_DESC_SOFT_RESERVED, };struct platform_device *pdev;struct memregion_info info;
Greg Kroah-Hartman
maintainerPATCH 200/207 ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0
In reply to Greg Kroah-HartmanFrom: Luís Henriques <[email protected]>
commit 29a5b8a137ac8eb410cc823653a29ac0e7b7e1b0 upstream.
When walking through an inode extents, the ext4_ext_binsearch_idx() function assumes that the extent header has been previously validated. However, there are no checks that verify that the number of entries (eh->eh_entries) is non-zero when depth is > 0. And this will lead to problems because the EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:
[ 135.245946] ------------[ cut here ]------------ [ 135.247579] kernel BUG at fs/ext4/extents.c:2258! [ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4 [ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 [ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0 [ 135.256475] Code: [ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246 [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023 [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c [ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024 [ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000 [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0 [ 135.277952] Call Trace: [ 135.278635] <TASK> [ 135.279247] ? preempt_count_add+0x6d/0xa0 [ 135.280358] ? percpu_counter_add_batch+0x55/0xb0 [ 135.281612] ? _raw_read_unlock+0x18/0x30 [ 135.282704] ext4_map_blocks+0x294/0x5a0 [ 135.283745] ? xa_load+0x6f/0xa0 [ 135.284562] ext4_mpage_readpages+0x3d6/0x770 [ 135.285646] read_pages+0x67/0x1d0 [ 135.286492] ? folio_add_lru+0x51/0x80 [ 135.287441] page_cache_ra_unbounded+0x124/0x170 [ 135.288510] filemap_get_pages+0x23d/0x5a0 [ 135.289457] ? path_openat+0xa72/0xdd0 [ 135.290332] filemap_read+0xbf/0x300 [ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40 [ 135.292192] new_sync_read+0x103/0x170 [ 135.293014] vfs_read+0x15d/0x180 [ 135.293745] ksys_read+0xa1/0xe0 [ 135.294461] do_syscall_64+0x3c/0x80 [ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0
This patch simply adds an extra check in __ext4_ext_check(), verifying that eh_entries is not 0 when eh_depth is > 0.
--- fs/ext4/extents.c | 4 ++++ 1 file changed, 4 insertions(+)
fs/ext4/extents.c +4 -0
@@ -460,6 +460,10 @@ static int __ext4_ext_check(const char * error_msg ="invalid eh_entries" ; goto corrupted; } +if (unlikely ((eh->eh_entries ==0 ) && (depth >0 ))) { + error_msg ="eh_entries is 0 but eh_depth is > 0" ; + goto corrupted; + }if (!ext4_valid_extent_entries (inode, eh, lblk, &pblk, depth)) { error_msg ="invalid extent entries" ; goto corrupted;
Greg Kroah-Hartman
maintainerPATCH 201/207 ext4: limit the number of retries after discarding preallocations blocks
In reply to Greg Kroah-HartmanFrom: Theodore Ts'o <[email protected]>
commit 80fa46d6b9e7b1527bfd2197d75431fd9c382161 upstream.
This patch avoids threads live-locking for hours when a large number threads are competing over the last few free extents as they blocks getting added and removed from preallocation pools. From our bug reporter:
A reliable way for triggering this has multiple writers continuously write() to files when the filesystem is full, while small amounts of space are freed (e.g. by truncating a large file -1MiB at a time). In the local filesystem, this can be done by simply not checking the return code of write (0) and/or the error (ENOSPACE) that is set. Over NFS with an async mount, even clients with proper error checking will behave this way since the linux NFS client implementation will not propagate the server errors [the write syscalls immediately return success] until the file handle is closed. This leads to a situation where NFS clients send a continuous stream of WRITE rpcs which result in ERRNOSPACE -- but since the client isn't seeing this, the stream of writes continues at maximum network speed.
When some space does appear, multiple writers will all attempt to claim it for their current write. For NFS, we may see dozens to hundreds of threads that do this.
The real-world scenario of this is database backup tooling (in particular, github.com/mdkent/percona-xtrabackup) which may write large files (>1TiB) to NFS for safe keeping. Some temporary files are written, rewound, and read back -- all before closing the file handle (the temp file is actually unlinked, to trigger automatic deletion on close/crash.) An application like this operating on an async NFS mount will not see an error code until TiB have been written/read.
The lockup was observed when running this database backup on large filesystems (64 TiB in this case) with a high number of block groups and no free space. Fragmentation is generally not a factor in this filesystem (~thousands of large files, mostly contiguous except for the parts written while the filesystem is at capacity.)
--- fs/ext4/mballoc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/ext4/mballoc.c +3 -1
@@ -5559,6 +5559,7 @@ ext4_fsblk_t ext4_mb_new_blocks(handle_text4_fsblk_t block =0 ;unsigned int inquota =0 ;unsigned int reserv_clstrs =0 ; +int retries =0 ;u64 seq;might_sleep ();
@@ -5661,7 +5662,8 @@ repeat: ar->len = ac->ac_b_ex.fe_len; } }else { -if (ext4_mb_discard_preallocations_should_retry (sb, ac, &seq)) +if (++retries <3 && +ext4_mb_discard_preallocations_should_retry (sb, ac, &seq)) goto repeat;/* * If block allocation fails then the pa allocated above
Greg Kroah-Hartman
maintainerPATCH 202/207 ext4: make mballoc try target group first even with mb_optimize_scan
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit 4fca50d440cc5d4dc570ad5484cc0b70b381bc2a upstream.
One of the side-effects of mb_optimize_scan was that the optimized functions to select next group to try were called even before we tried the goal group. As a result we no longer allocate files close to corresponding inodes as well as we don't try to expand currently allocated extent in the same group. This results in reaim regression with workfile.disk workload of upto 8% with many clients on my test machine:
baseline mb_optimize_scan
Hmean disk-1 2114.16 ( 0.00%) 2099.37 ( -0.70%) Hmean disk-41 87794.43 ( 0.00%) 83787.47 * -4.56%* Hmean disk-81 148170.73 ( 0.00%) 135527.05 * -8.53%* Hmean disk-121 177506.11 ( 0.00%) 166284.93 * -6.32%* Hmean disk-161 220951.51 ( 0.00%) 207563.39 * -6.06%* Hmean disk-201 208722.74 ( 0.00%) 203235.59 ( -2.63%) Hmean disk-241 222051.60 ( 0.00%) 217705.51 ( -1.96%) Hmean disk-281 252244.17 ( 0.00%) 241132.72 * -4.41%* Hmean disk-321 255844.84 ( 0.00%) 245412.84 * -4.08%*
Also this is causing huge regression (time increased by a factor of 5 or so) when untarring archive with lots of small files on some eMMC storage cards.
Fix the problem by making sure we try goal group first.
--- fs/ext4/mballoc.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
fs/ext4/mballoc.c +7 -7
@@ -1049,8 +1049,10 @@ static void ext4_mb_choose_next_group(st { *new_cr = ac->ac_criteria; -if (!should_optimize_scan (ac) || ac->ac_groups_linear_remaining) +if (!should_optimize_scan (ac) || ac->ac_groups_linear_remaining) { + *group =next_linear_group (ac, *group, ngroups);return ; + }if (*new_cr ==0 ) {ext4_mb_choose_next_group_cr0 (ac, new_cr, group, ngroups);
@@ -2630,7 +2632,7 @@ static noinline_for_stack int ext4_mb_regular_allocator(struct ext4_allocation_context *ac) {ext4_group_t prefetch_grp =0 , ngroups, group, i; -int cr =-1 ; +int cr =-1 , new_cr;int err =0 , first_err =0 ;unsigned int nr =0 , prefetch_ios =0 ;struct ext4_sb_info *sbi;
@@ -2705,13 +2707,11 @@ repeat: ac->ac_groups_linear_remaining = sbi->s_mb_max_linear_groups; prefetch_grp = group; -for (i =0 ; i < ngroups; group =next_linear_group (ac, group, ngroups), - i++) { -int ret =0 , new_cr; +for (i =0 , new_cr = cr; i < ngroups; i++, +ext4_mb_choose_next_group (ac, &new_cr, &group, ngroups)) { +int ret =0 ;cond_resched (); - -ext4_mb_choose_next_group (ac, &new_cr, &group, ngroups);if (new_cr != cr) { cr = new_cr; goto repeat;
Greg Kroah-Hartman
maintainerPATCH 203/207 ext4: avoid unnecessary spreading of allocations among groups
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit 1940265ede6683f6317cba0d428ce6505eaca944 upstream.
mb_set_largest_free_order() updates lists containing groups with largest chunk of free space of given order. The way it updates it leads to always moving the group to the tail of the list. Thus allocations looking for free space of given order effectively end up cycling through all groups (and due to initialization in last to first order). This spreads allocations among block groups which reduces performance for rotating disks or low-end flash media. Change mb_set_largest_free_order() to only update lists if the order of the largest free chunk in the group changed.
--- fs/ext4/mballoc.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-)
fs/ext4/mballoc.c +13 -11
@@ -1077,23 +1077,25 @@ mb_set_largest_free_order(struct super_bstruct ext4_sb_info *sbi =EXT4_SB (sb);int i; -if (test_opt2 (sb,MB_OPTIMIZE_SCAN ) && grp->bb_largest_free_order >=0 ) { +for (i =MB_NUM_ORDERS (sb) -1 ; i >=0 ; i--) +if (grp->bb_counters[i] >0 ) +break ; +/* No need to move between order lists? */ +if (!test_opt2 (sb,MB_OPTIMIZE_SCAN ) || + i == grp->bb_largest_free_order) { + grp->bb_largest_free_order = i; +return ; + } + +if (grp->bb_largest_free_order >=0 ) {write_lock (&sbi->s_mb_largest_free_orders_locks[ grp->bb_largest_free_order]);list_del_init (&grp->bb_largest_free_order_node);write_unlock (&sbi->s_mb_largest_free_orders_locks[ grp->bb_largest_free_order]); } - grp->bb_largest_free_order =-1 ;/* uninit */ - -for (i =MB_NUM_ORDERS (sb) -1 ; i >=0 ; i--) { -if (grp->bb_counters[i] >0 ) { - grp->bb_largest_free_order = i; -break ; - } - } -if (test_opt2 (sb,MB_OPTIMIZE_SCAN ) && - grp->bb_largest_free_order >=0 && grp->bb_free) { + grp->bb_largest_free_order = i; +if (grp->bb_largest_free_order >=0 && grp->bb_free) {write_lock (&sbi->s_mb_largest_free_orders_locks[ grp->bb_largest_free_order]); list_add_tail(&grp->bb_largest_free_order_node,
Greg Kroah-Hartman
maintainerPATCH 204/207 ext4: make directory inode spreading reflect flexbg size
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit 613c5a85898d1cd44e68f28d65eccf64a8ace9cf upstream.
Currently the Orlov inode allocator searches for free inodes for a directory only in flex block groups with at most inodes_per_group/16 more directory inodes than average per flex block group. However with growing size of flex block group this becomes unnecessarily strict. Scale allowed difference from average directory count per flex block group with flex block group size as we do with other metrics.
--- fs/ext4/ialloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/ialloc.c +1 -1
@@ -510,7 +510,7 @@ static int find_group_orlov(struct super goto fallback; } - max_dirs = ndirs / ngroups + inodes_per_group /16 ; + max_dirs = ndirs / ngroups + inodes_per_group*flex_size /16 ; min_inodes = avefreei - inodes_per_group*flex_size /4 ;if (min_inodes <1 ) min_inodes =1 ;
Greg Kroah-Hartman
maintainerPATCH 205/207 ext4: use locality group preallocation for small closed files
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit a9f2a2931d0e197ab28c6007966053fdababd53f upstream.
Curently we don't use any preallocation when a file is already closed when allocating blocks (from writeback code when converting delayed allocation). However for small files, using locality group preallocation is actually desirable as that is not specific to a particular file. Rather it is a method to pack small files together to reduce fragmentation and for that the fact the file is closed is actually even stronger hint the file would benefit from packing. So change the logic to allow locality group preallocation in this case.
--- fs/ext4/mballoc.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-)
fs/ext4/mballoc.c +15 -12
@@ -5189,6 +5189,7 @@ static void ext4_mb_group_or_file(structstruct ext4_sb_info *sbi =EXT4_SB (ac->ac_sb);int bsbits = ac->ac_sb->s_blocksize_bits;loff_t size, isize; +bool inode_pa_eligible, group_pa_eligible;if (!(ac->ac_flags &EXT4_MB_HINT_DATA ))return ;
@@ -5196,25 +5197,27 @@ static void ext4_mb_group_or_file(structif (unlikely (ac->ac_flags &EXT4_MB_HINT_GOAL_ONLY ))return ; + group_pa_eligible = sbi->s_mb_group_prealloc >0 ; + inode_pa_eligible = true; size = ac->ac_o_ex.fe_logical +EXT4_C2B (sbi, ac->ac_o_ex.fe_len); isize = (i_size_read (ac->ac_inode) + ac->ac_sb->s_blocksize -1 ) >> bsbits; +/* No point in using inode preallocation for closed files */ if ((size == isize) && !ext4_fs_is_busy (sbi) && - !inode_is_open_for_write (ac->ac_inode)) { - ac->ac_flags |=EXT4_MB_HINT_NOPREALLOC ; -return ; - } - -if (sbi->s_mb_group_prealloc <=0 ) { - ac->ac_flags |=EXT4_MB_STREAM_ALLOC ; -return ; - } + !inode_is_open_for_write (ac->ac_inode)) + inode_pa_eligible = false; -/* don't use group allocation for large files */ size =max (size, isize); -if (size > sbi->s_mb_stream_request) { - ac->ac_flags |=EXT4_MB_STREAM_ALLOC ; +/* Don't use group allocation for large files */ +if (size > sbi->s_mb_stream_request) + group_pa_eligible = false; + +if (!group_pa_eligible) { +if (inode_pa_eligible) + ac->ac_flags |=EXT4_MB_STREAM_ALLOC ; +else + ac->ac_flags |=EXT4_MB_HINT_NOPREALLOC ;return ; }
Greg Kroah-Hartman
maintainerPATCH 206/207 ext4: use buckets for cr 1 block scan instead of rbtree
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit 83e80a6e3543f37f74c8e48a5f305b054b65ce2a upstream.
Using rbtree for sorting groups by average fragment size is relatively expensive (needs rbtree update on every block freeing or allocation) and leads to wide spreading of allocations because selection of block group is very sentitive both to changes in free space and amount of blocks allocated. Furthermore selecting group with the best matching average fragment size is not necessary anyway, even more so because the variability of fragment sizes within a group is likely large so average is not telling much. We just need a group with large enough average fragment size so that we have high probability of finding large enough free extent and we don't want average fragment size to be too big so that we are likely to find free extent only somewhat larger than what we need.
So instead of maintaing rbtree of groups sorted by fragment size keep bins (lists) or groups where average fragment size is in the interval [2^i, 2^(i+1)). This structure requires less updates on block allocation / freeing, generally avoids chaotic spreading of allocations into block groups, and still is able to quickly (even faster that the rbtree) provide a block group which is likely to have a suitably sized free space extent.
This patch reduces number of block groups used when untarring archive with medium sized files (size somewhat above 64k which is default mballoc limit for avoiding locality group preallocation) to about half and thus improves write speeds for eMMC flash significantly.
--- fs/ext4/ext4.h | 10 +- fs/ext4/mballoc.c | 249 ++++++++++++++++++++++-------------------------------- fs/ext4/mballoc.h | 1 3 files changed, 111 insertions(+), 149 deletions(-)
fs/ext4/ext4.h +5 -5
@@ -167,8 +167,6 @@ enum SHIFT_DIRECTION {#define EXT4_MB_CR0_OPTIMIZED 0x8000/* Avg fragment size rb tree lookup succeeded at least once for cr = 1 */ #define EXT4_MB_CR1_OPTIMIZED 0x00010000 -/* Perform linear traversal for one group */ -#define EXT4_MB_SEARCH_NEXT_LINEAR 0x00020000struct ext4_allocation_request {/* target inode for block we're allocating */ struct inode *inode;
@@ -1589,8 +1587,8 @@ struct ext4_sb_info {struct list_head s_discard_list;struct work_struct s_discard_work;atomic_t s_retry_alloc_pending; -struct rb_root s_mb_avg_fragment_size_root; -rwlock_t s_mb_rb_lock; +struct list_head *s_mb_avg_fragment_size; +rwlock_t *s_mb_avg_fragment_size_locks;struct list_head *s_mb_largest_free_orders;rwlock_t *s_mb_largest_free_orders_locks;
@@ -3402,6 +3400,8 @@ struct ext4_group_info {ext4_grpblk_t bb_first_free;/* first free block */ ext4_grpblk_t bb_free;/* total free blocks */ ext4_grpblk_t bb_fragments;/* nr of freespace fragments */ +int bb_avg_fragment_size_order;/* order of average +fragment in BG */ ext4_grpblk_t bb_largest_free_order;/* order of largest frag in BG */ ext4_group_t bb_group;/* Group number */ struct list_head bb_prealloc_list;
@@ -3409,7 +3409,7 @@ struct ext4_group_info {void *bb_bitmap;#endif struct rw_semaphore alloc_sem; -struct rb_node bb_avg_fragment_size_rb; +struct list_head bb_avg_fragment_size_node;struct list_head bb_largest_free_order_node;ext4_grpblk_t bb_counters[];/* Nr of free power-of-two-block * regions, index is order.
fs/ext4/mballoc.c +106 -143
407 lines not on this page · raw message
fs/ext4/mballoc.h +0 -1
@@ -178,7 +178,6 @@ struct ext4_allocation_context {/* copy of the best found extent taken before preallocation efforts */ struct ext4_free_extent ac_f_ex; -ext4_group_t ac_last_optimal_group;__u32 ac_groups_considered;__u32 ac_flags;/* allocation hints */ __u16 ac_groups_scanned;
Greg Kroah-Hartman
maintainerPATCH 207/207 Revert "block: freeze the queue earlier in del_gendisk"
In reply to Greg Kroah-HartmanFrom: Christoph Hellwig <[email protected]>
commit 4c66a326b5ab784cddd72de07ac5b6210e9e1b06 upstream.
This reverts commit a09b314005f3a0956ebf56e01b3b80339df577cc.
Dusty Mabe reported consistent hang during CoreOS shutdown with a MD RAID1 setup. Although apparently similar hangs happened before, and this patch most likely is not the root cause it made it much more severe. Revert it until we can figure out what is going on with the md driver.
--- block/genhd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
block/genhd.c +2 -1
@@ -625,7 +625,6 @@ void del_gendisk(struct gendisk *disk)* Prevent new I/O from crossing bio_queue_enter(). */ blk_queue_start_drain (q); -blk_mq_freeze_queue_wait (q);if (!(disk->flags &GENHD_FL_HIDDEN )) {sysfs_remove_link (&disk_to_dev (disk)->kobj,"bdi" );
@@ -649,6 +648,8 @@ void del_gendisk(struct gendisk *disk)pm_runtime_set_memalloc_noio (disk_to_dev (disk), false);device_del (disk_to_dev (disk)); +blk_mq_freeze_queue_wait (q); +blk_throtl_cancel_bios (disk->queue);blk_sync_queue (q);
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.thanks,
greg k-h
Running successfully on three different systems (server, desktop, laptop), no dmesg or behavioural regressions noticed so far. Thanks!
Hey Greg,
Ran tests and boot tested on my system, no regressions found
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.thanks,
greg k-h
Hi Greg,
Compiled and booted on my test system Lenovo P50s: Intel Core i7 No emergency and critical messages in the dmesg
./perf bench sched all
# Running sched/messaging benchmark...
# 20 sender and receiver processes per group
# 10 groups == 400 processes run
Total time: 0.693 [sec]
# Running sched/pipe benchmark...
# Executed 1000000 pipe operations between two processes
Total time: 9.496 [sec]
9.496474 usecs/op
105302 ops/secThanks
-Zan
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and powerpc (ps3_defconfig, GCC 12.1.0).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro's test farm.
No regressions on arm, x86_64, and i386.
Following deadlock warning noticed on arm64 with kselftests Kconfigs.
NOTE:
Following kernel boot warning noticed on arm64 bcm2711-rpi-4-b, dragonboard-845c and devices with kselftest Kconfigs [1].
[ 51.802754] ======================================================
[ 51.809016] WARNING: possible circular locking dependency detected
[ 51.815280] 5.19.12-rc1 #1 Not tainted
[ 51.819078] ------------------------------------------------------
[ 51.825340] kworker/u9:0/170 is trying to acquire lock:
[ 51.830635] ffff000044f1b048 (&hdev->req_lock){+.+.}-{3:3}, at:
scan_update_work+0x2c/0x70 [bluetooth]
[ 51.840186]
[ 51.840186] but task is already holding lock:
[ 51.846095] ffff80000c563dd0
((work_completion)(&hdev->scan_update)){+.+.}-{0:0}, at:
process_one_work+0x1e8/0x6d4
[ 51.856610]
[ 51.856610] which lock already depends on the new lock.
[ 51.856610]
[ 51.864898]
[ 51.864898] the existing dependency chain (in reverse order) is:
[ 51.872482]
[ 51.872482] -> #1 ((work_completion)(&hdev->scan_update)){+.+.}-{0:0}:
[ 51.880603] lock_acquire+0x84/0xa0
[ 51.884668] __flush_work+0x88/0x510
[ 51.888820] __cancel_work_timer+0x150/0x1d0
[ 51.893678] cancel_work_sync+0x28/0x40
[ 51.898094] hci_request_cancel_all+0x38/0x110 [bluetooth]
[ 51.904265] hci_dev_close_sync+0x3c/0x620 [bluetooth]
[ 51.910071] hci_dev_do_close+0x38/0x80 [bluetooth]
[ 51.915600] hci_power_off+0x2c/0x70 [bluetooth]
[ 51.920870] process_one_work+0x280/0x6d4
[ 51.925472] worker_thread+0x7c/0x430
[ 51.929711] kthread+0x108/0x114
[ 51.933509] ret_from_fork+0x10/0x20
[ 51.937660]
[ 51.937660] -> #0 (&hdev->req_lock){+.+.}-{3:3}:
[ 51.943843] __lock_acquire+0x12d8/0x205c
[ 51.948434] lock_acquire.part.0+0xe4/0x22c
[ 51.953201] lock_acquire+0x84/0xa0
[ 51.957261] __mutex_lock+0x9c/0x410
[ 51.961413] mutex_lock_nested+0x64/0xa0
[ 51.965914] scan_update_work+0x2c/0x70 [bluetooth]
[ 51.971477] process_one_work+0x280/0x6d4
[ 51.976074] worker_thread+0x7c/0x430
[ 51.980313] kthread+0x108/0x114
[ 51.984110] ret_from_fork+0x10/0x20
[ 51.988261]
[ 51.988261] other info that might help us debug this:
[ 51.988261]
[ 51.996373] Possible unsafe locking scenario:
[ 51.996373]
[ 52.002370] CPU0 CPU1
[ 52.006956] ---- ----
[ 52.011543] lock((work_completion)(&hdev->scan_update));
[ 52.017103] lock(&hdev->req_lock);
[ 52.023280]
lock((work_completion)(&hdev->scan_update));
[ 52.031395] lock(&hdev->req_lock);
[ 52.035015]
[ 52.035015] *** DEADLOCK ***
[ 52.035015]
[ 52.041013] 2 locks held by kworker/u9:0/170:
[ 52.045425] #0: ffff000048b8d938
((wq_completion)hci0){+.+.}-{0:0}, at: process_one_work+0x1e8/0x6d4
[ 52.054788] #1: ffff80000c563dd0
((work_completion)(&hdev->scan_update)){+.+.}-{0:0}, at:
process_one_work+0x1e8/0x6d4
[ 52.065736]
[ 52.065736] stack backtrace:
[ 52.070149] CPU: 1 PID: 170 Comm: kworker/u9:0 Not tainted 5.19.12-rc1 #1
[ 52.077031] Hardware name: Raspberry Pi 4 Model B (DT)
[ 52.082237] Workqueue: hci0 scan_update_work [bluetooth]
[ 52.087725] Call trace:
[ 52.090197] dump_backtrace+0xbc/0x130
[ 52.093997] show_stack+0x30/0x70
[ 52.097352] dump_stack_lvl+0x8c/0xb8
[ 52.101062] dump_stack+0x18/0x34
[ 52.104416] print_circular_bug+0x1f8/0x200
[ 52.108655] check_noncircular+0x12c/0x140
[ 52.112804] __lock_acquire+0x12d8/0x205c
[ 52.116864] lock_acquire.part.0+0xe4/0x22c
[ 52.121101] lock_acquire+0x84/0xa0
[ 52.124633] __mutex_lock+0x9c/0x410
[ 52.128255] mutex_lock_nested+0x64/0xa0
[ 52.132228] scan_update_work+0x2c/0x70 [bluetooth]
[ 52.137265] process_one_work+0x280/0x6d4
[ 52.141330] worker_thread+0x7c/0x430
[ 52.145039] kthread+0x108/0x114
[ 52.148308] ret_from_fork+0x10/0x20[1] https://builds.tuxbuild.com/2FJZaTWmWVmCtAL2pw1Fvo1uWXw/config
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.19.y/build/v5.19.11-208-gddfc03723522/testrun/12111785/suite/log-parser-boot/tests/
## Build
* kernel: 5.19.12-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.19.y
* git commit: ddfc03723522344950fd8eddeec14bd1facf0ba5
* git describe: v5.19.11-208-gddfc03723522
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.19.y/build/v5.19.11-208-gddfc03723522
## No test Regressions (compared to v5.19.11)
## No metric Regressions (compared to v5.19.11)
## No test Fixes (compared to v5.19.11)
## No metric Fixes (compared to v5.19.11)
## Test result summary
total: 117926, pass: 103539, fail: 1113, skip: 13021, xfail: 253
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 333 total, 333 passed, 0 failed
* arm64: 65 total, 63 passed, 2 failed
* i386: 55 total, 53 passed, 2 failed
* mips: 56 total, 56 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 69 total, 63 passed, 6 failed
* riscv: 27 total, 22 passed, 5 failed
* s390: 21 total, 21 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 58 total, 56 passed, 2 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* 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-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 17 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +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.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.
Quoted 7 lines
Quoted 3 lines
thanks,
greg k-h
Results from Linaro's test farm.
No regressions on arm,x86_64, and i386.
Following deadlock warning noticed on arm64 with kselftests Kconfigs.
Is this new? If so, what commit causes it?
thanks,
greg k-h
Hi Greg,
Quoted 21 lines · Greg Kroah-Hartman
Quoted 19 lines · Naresh Kamboju
Quoted 17 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +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.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.thanks,
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
greg k-h
Results from Linaro's test farm.
No regressions on arm,x86_64, and i386.
Following deadlock warning noticed on arm64 with kselftests Kconfigs.Is this new? If so, what commit causes it?
Anders bisected this reported problem [1] and found this commit caused deadlock on all arm64 devices.
Quoted 2 lines
Tetsuo Handa <[email protected]>
workqueue: don't skip lockdep work dependency incancel_work_sync()
[1] https://lore.kernel.org/stable/CA+G9fYtxogp--B0Em6VCL0C3wwVFXa6xW-Rq2kQk3br+FPGLgg@mail.gmail.com/
- Naresh
--
Linaro LKFT
https://lkft.linaro.org
Quoted 5 lines · Naresh Kamboju
Anders bisected this reported problem [1] and found this commit caused deadlock on all arm64 devices.
Quoted 2 lines
Tetsuo Handa <[email protected]>
workqueue: don't skip lockdep work dependency incancel_work_sync()
My patch itself is correct; just started reporting possibility of deadlock. You will see several reports like this, but that is an expected result.
Quoted 3 lines
[1] https://lore.kernel.org/stable/CA+G9fYtxogp--B0Em6VCL0C3wwVFXa6xW-Rq2kQk3br+FPGLgg@mail.gmail.com/
The line which causes this report will be removed by commit bb87672562f871ed ("Bluetooth: Remove update_scan hci_request dependancy").
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +0000. Anything received after that time might be too late.
Build test (gcc version 12.2.1 20220925):
mips: 59 configs -> no failure
arm: 99 configs -> no failure
arm64: 3 configs -> no failurex86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> 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]
mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/1907
[2]. https://openqa.qa.codethink.co.uk/tests/1912
[3]. https://openqa.qa.codethink.co.uk/tests/1914
--
Regards
Sudip
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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 Wed, 28 Sep 2022 10:07:26 +0000. Anything received after that time might be too late.
Build results:
total: 150 pass: 150 fail: 0 Qemu test results: total: 490 pass: 490 fail: 0
Guenter
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.19.12 release. There are 207 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.
Quoted 8 lines
Responses should be made by Wed, 28 Sep 2022 10:07:26 +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.19.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.19.y
and the diffstat can be found below.
openSUSE configs¹⁾ all green. x86_64 runs fine.
¹⁾ armv6hl armv7hl arm64 i386 ppc64 ppc64le riscv64 s390x x86_64
Signature · 2 lines
js suse labs