[PATCH] ceph: minor coding style tweaks
Fixed some coding style issues, improve code reading. 1. Move the pointer location 2. Move brace position 3. Alignment to open parenthesis This patch adds whitespace to clearly separate the parameters. Signed-off-by: Zhiyuan Dai --- fs/ceph/addr.c | 3 +-- fs/ceph/cache.c | 14 +++--- fs/ceph/caps.c | 2 +- fs/ceph/dir.c| 6 +++--- fs/ceph/export.c | 2 +- fs/ceph/inode.c | 6 +++--- fs/ceph/locks.c | 2 +- fs/ceph/mds_client.c | 8 fs/ceph/mdsmap.c | 4 ++-- fs/ceph/snap.c | 6 +++--- fs/ceph/xattr.c | 4 ++-- 11 files changed, 28 insertions(+), 29 deletions(-) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index 9505529..94ce73e 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -493,8 +493,7 @@ static int ceph_readpages(struct file *file, struct address_space *mapping, return rc; } -struct ceph_writeback_ctl -{ +struct ceph_writeback_ctl { loff_t i_size; u64 truncate_size; u32 truncate_seq; diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c index 2f5cb6b..795523e 100644 --- a/fs/ceph/cache.c +++ b/fs/ceph/cache.c @@ -50,7 +50,7 @@ void ceph_fscache_unregister(void) fscache_unregister_netfs(_cache_netfs); } -int ceph_fscache_register_fs(struct ceph_fs_client* fsc, struct fs_context *fc) +int ceph_fscache_register_fs(struct ceph_fs_client *fsc, struct fs_context *fc) { const struct ceph_fsid *fsid = >client->fsid; const char *fscache_uniq = fsc->mount_options->fscache_uniq; @@ -110,8 +110,8 @@ static enum fscache_checkaux ceph_fscache_inode_check_aux( loff_t object_size) { struct ceph_aux_inode aux; - struct ceph_inode_info* ci = cookie_netfs_data; - struct inode* inode = >vfs_inode; + struct ceph_inode_info *ci = cookie_netfs_data; + struct inode *inode = >vfs_inode; if (dlen != sizeof(aux) || i_size_read(inode) != object_size) @@ -164,9 +164,9 @@ void ceph_fscache_register_inode_cookie(struct inode *inode) inode_unlock(inode); } -void ceph_fscache_unregister_inode_cookie(struct ceph_inode_info* ci) +void ceph_fscache_unregister_inode_cookie(struct ceph_inode_info *ci) { - struct fscache_cookie* cookie; + struct fscache_cookie *cookie; if ((cookie = ci->fscache) == NULL) return; @@ -296,7 +296,7 @@ void ceph_readpage_to_fscache(struct inode *inode, struct page *page) fscache_uncache_page(ci->fscache, page); } -void ceph_invalidate_fscache_page(struct inode* inode, struct page *page) +void ceph_invalidate_fscache_page(struct inode *inode, struct page *page) { struct ceph_inode_info *ci = ceph_inode(inode); @@ -307,7 +307,7 @@ void ceph_invalidate_fscache_page(struct inode* inode, struct page *page) fscache_uncache_page(ci->fscache, page); } -void ceph_fscache_unregister_fs(struct ceph_fs_client* fsc) +void ceph_fscache_unregister_fs(struct ceph_fs_client *fsc) { if (fscache_cookie_valid(fsc->fscache)) { struct ceph_fscache_entry *ent; diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c index 255a512..39fe5d8 100644 --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -2270,7 +2270,7 @@ static int caps_are_flushed(struct inode *inode, u64 flush_tid) spin_lock(>i_ceph_lock); if (!list_empty(>i_cap_flush_list)) { - struct ceph_cap_flush * cf = + struct ceph_cap_flush *cf = list_first_entry(>i_cap_flush_list, struct ceph_cap_flush, i_list); if (cf->tid <= flush_tid) diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c index 858ee73..2b7edd00 100644 --- a/fs/ceph/dir.c +++ b/fs/ceph/dir.c @@ -1269,7 +1269,7 @@ void __ceph_dentry_lease_touch(struct ceph_dentry_info *di) spin_unlock(>dentry_list_lock); } -static void __dentry_dir_lease_touch(struct ceph_mds_client* mdsc, +static void __dentry_dir_lease_touch(struct ceph_mds_client *mdsc, struct ceph_dentry_info *di) { di->flags &= ~(CEPH_DENTRY_LEASE_LIST | CEPH_DENTRY_REFERENCED); @@ -1351,7 +1351,7 @@ struct ceph_lease_walk_control { { struct ceph_dentry_info *di, *tmp; struct dentry *dentry, *last = NULL; - struct list_head* list; + struct list_head *list; LIST_HEAD(dispose); unsigned long freed = 0; int ret = 0; @@ -1498,7 +1498,7 @@ int ceph_trim_dentries(struct ceph_mds_client *mdsc) lwc.dir_lease = true; lwc.expire_dir_lease = freed < count; lwc.dir_lease_ttl = mdsc->fsc->mount_options->caps_wanted_delay_max * HZ; - freed +=__dentry_leases_walk(mdsc, , __dir_lease_check); + freed += __dentry_leases_walk(mdsc, , __dir_lease_check); if (!lwc.nr_to_scan) /* more to check */ return -EAGAIN; diff --git a/fs/ceph/export.c b/fs/ceph/export.c index e088843..83ec43f
Re: [PATCH v13 2/4] phy: Add ethernet serdes configuration option
On 29-01-21, 14:07, Steen Hegelund wrote: > Provide a new ethernet phy configuration structure, that > allow PHYs used for ethernet to be configured with > speed, media type and clock information. This lgtm, Kishon ? > > Signed-off-by: Lars Povlsen > Signed-off-by: Steen Hegelund > Reviewed-by: Andrew Lunn > Reviewed-by: Alexandre Belloni > --- > drivers/phy/phy-core.c | 30 ++ > include/linux/phy/phy.h | 26 ++ > 2 files changed, 56 insertions(+) > > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > index 71cb10826326..ccb575b13777 100644 > --- a/drivers/phy/phy-core.c > +++ b/drivers/phy/phy-core.c > @@ -373,6 +373,36 @@ int phy_set_mode_ext(struct phy *phy, enum phy_mode > mode, int submode) > } > EXPORT_SYMBOL_GPL(phy_set_mode_ext); > > +int phy_set_media(struct phy *phy, enum phy_media media) > +{ > + int ret; > + > + if (!phy || !phy->ops->set_media) > + return 0; > + > + mutex_lock(>mutex); > + ret = phy->ops->set_media(phy, media); > + mutex_unlock(>mutex); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(phy_set_media); > + > +int phy_set_speed(struct phy *phy, int speed) > +{ > + int ret; > + > + if (!phy || !phy->ops->set_speed) > + return 0; > + > + mutex_lock(>mutex); > + ret = phy->ops->set_speed(phy, speed); > + mutex_unlock(>mutex); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(phy_set_speed); > + > int phy_reset(struct phy *phy) > { > int ret; > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h > index e435bdb0bab3..e4fd69a1faa7 100644 > --- a/include/linux/phy/phy.h > +++ b/include/linux/phy/phy.h > @@ -44,6 +44,12 @@ enum phy_mode { > PHY_MODE_DP > }; > > +enum phy_media { > + PHY_MEDIA_DEFAULT, > + PHY_MEDIA_SR, > + PHY_MEDIA_DAC, > +}; > + > /** > * union phy_configure_opts - Opaque generic phy configuration > * > @@ -64,6 +70,8 @@ union phy_configure_opts { > * @power_on: powering on the phy > * @power_off: powering off the phy > * @set_mode: set the mode of the phy > + * @set_media: set the media type of the phy (optional) > + * @set_speed: set the speed of the phy (optional) > * @reset: resetting the phy > * @calibrate: calibrate the phy > * @release: ops to be performed while the consumer relinquishes the PHY > @@ -75,6 +83,8 @@ struct phy_ops { > int (*power_on)(struct phy *phy); > int (*power_off)(struct phy *phy); > int (*set_mode)(struct phy *phy, enum phy_mode mode, int submode); > + int (*set_media)(struct phy *phy, enum phy_media media); > + int (*set_speed)(struct phy *phy, int speed); > > /** >* @configure: > @@ -215,6 +225,8 @@ int phy_power_off(struct phy *phy); > int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode); > #define phy_set_mode(phy, mode) \ > phy_set_mode_ext(phy, mode, 0) > +int phy_set_media(struct phy *phy, enum phy_media media); > +int phy_set_speed(struct phy *phy, int speed); > int phy_configure(struct phy *phy, union phy_configure_opts *opts); > int phy_validate(struct phy *phy, enum phy_mode mode, int submode, >union phy_configure_opts *opts); > @@ -344,6 +356,20 @@ static inline int phy_set_mode_ext(struct phy *phy, enum > phy_mode mode, > #define phy_set_mode(phy, mode) \ > phy_set_mode_ext(phy, mode, 0) > > +static inline int phy_set_media(struct phy *phy, enum phy_media media) > +{ > + if (!phy) > + return 0; > + return -ENOSYS; > +} > + > +static inline int phy_set_speed(struct phy *phy, int speed) > +{ > + if (!phy) > + return 0; > + return -ENOSYS; > +} > + > static inline enum phy_mode phy_get_mode(struct phy *phy) > { > return PHY_MODE_INVALID; > -- > 2.30.0 -- ~Vinod
[PATCH] fscache: rectify minor kernel-doc issues
The command './scripts/kernel-doc -none include/linux/fscache.h' reports some minor mismatches of the kernel-doc and function signature, which are easily resolved. Rectify the kernel-doc, such that no issues remain for fscache.h. Signed-off-by: Lukas Bulwahn --- applies cleanly on current master and next-20210202 David, please pick the quick kernel-doc fix. include/linux/fscache.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/fscache.h b/include/linux/fscache.h index 3f177faa0ac2..7e1f12e52baf 100644 --- a/include/linux/fscache.h +++ b/include/linux/fscache.h @@ -418,7 +418,7 @@ int fscache_pin_cookie(struct fscache_cookie *cookie) } /** - * fscache_pin_cookie - Unpin a data-storage cache object in its cache + * fscache_unpin_cookie - Unpin a data-storage cache object in its cache * @cookie: The cookie representing the cache object * * Permit data-storage cache objects to be unpinned from the cache. @@ -490,7 +490,7 @@ void fscache_wait_on_invalidate(struct fscache_cookie *cookie) /** * fscache_reserve_space - Reserve data space for a cached object * @cookie: The cookie representing the cache object - * @i_size: The amount of space to be reserved + * @size: The amount of space to be reserved * * Reserve an amount of space in the cache for the cache object attached to a * cookie so that a write to that object within the space can always be -- 2.17.1
Re: [PATCH v6 3/7] phy: phy-hi3670-usb3: move driver from staging into phy
On 27-01-21, 20:08, Mauro Carvalho Chehab wrote: > The phy USB3 driver for Hisilicon 970 (hi3670) is ready > for mainstream. Mode it from staging into the main driver's > phy/ directory. I guess Greg will pick this, so: Acked-By: Vinod Koul -- ~Vinod
Re: [Linaro-mm-sig] [PATCH 1/2] mm: replace BUG_ON in vm_insert_page with a return of an error
Am 03.02.21 um 21:20 schrieb Suren Baghdasaryan: [SNIP] If there is a reason to set this flag other than historical use of carveout memory then we wanted to catch such cases and fix the drivers that moved to using dmabuf heaps. However maybe there are other reasons and if so I would be very grateful if someone could explain them. That would help me to come up with a better solution. Well one major reason for this is to prevent accounting of DMA-buf pages. So you are going in circles here and trying to circumvent an intentional behavior. Daniel is right that this is the completely wrong approach and we need to take a step back and think about it on a higher level. Going to replay to his mail as well. Regards, Christian.
[PATCH] scsi: isci: Remove redundant initialization of variable 'status'
This patch removes unneeded return variables. It fixes the following warning detected by coccinelle: ./drivers/scsi/isci/request.c:1483:17-23: Unneeded variable: "status". Return "SCI_SUCCESS" on line 1503 ./drivers/scsi/isci/request.c:2157:17-23: Unneeded variable: "status". Return "SCI_SUCCESS" on line 2177 Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/scsi/isci/request.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c index 6e08179..8676282 100644 --- a/drivers/scsi/isci/request.c +++ b/drivers/scsi/isci/request.c @@ -1480,8 +1480,6 @@ static enum sci_status sci_stp_request_pio_data_in_copy_data( stp_request_pio_await_h2d_completion_tc_event(struct isci_request *ireq, u32 completion_code) { - enum sci_status status = SCI_SUCCESS; - switch (SCU_GET_COMPLETION_TL_STATUS(completion_code)) { case SCU_MAKE_COMPLETION_STATUS(SCU_TASK_DONE_GOOD): ireq->scu_status = SCU_TASK_DONE_GOOD; @@ -1500,7 +1498,7 @@ static enum sci_status sci_stp_request_pio_data_in_copy_data( break; } - return status; + return SCI_SUCCESS; } static enum sci_status @@ -2154,8 +2152,6 @@ static enum sci_status stp_request_udma_await_tc_event(struct isci_request *ireq static enum sci_status atapi_raw_completion(struct isci_request *ireq, u32 completion_code, enum sci_base_request_states next) { - enum sci_status status = SCI_SUCCESS; - switch (SCU_GET_COMPLETION_TL_STATUS(completion_code)) { case SCU_MAKE_COMPLETION_STATUS(SCU_TASK_DONE_GOOD): ireq->scu_status = SCU_TASK_DONE_GOOD; @@ -2174,7 +2170,7 @@ static enum sci_status atapi_raw_completion(struct isci_request *ireq, u32 compl break; } - return status; + return SCI_SUCCESS; } static enum sci_status atapi_data_tc_completion_handler(struct isci_request *ireq, -- 1.8.3.1
Re: [PATCH v4 0/5] Promote Hikey 970 USB phy out of staging
On 26-01-21, 18:49, Greg Kroah-Hartman wrote: > On Tue, Jan 19, 2021 at 11:44:38AM +0100, Mauro Carvalho Chehab wrote: > > Hi Vinod/Rob, > > > > This series moves the Hikey 970 USB PHY driver out of staging. > > > > Patches 1 to 4 contain the fixes from staging. Patch 5 moves the > > driver from staging: > > > > $ git show 82ce73ac9a38 --summary > > ... > > rename drivers/staging/hikey9xx/phy-hi3670-usb3.yaml => > > Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml (100%) > > rename drivers/{staging/hikey9xx => phy/hisilicon}/phy-hi3670-usb3.c > > (100%) > > > > I opted to use --no-renames on this series in order to make easier to > > review via e-mail, as the entire driver and DT bindings will be seen > > at the last patch on this series. > > First 4 patches applied to my tree, thanks. I have acked the last one, pls apply that one too -- ~Vinod
[PATCH v2 2/2] drivers/clocksource: Fixup csky,mptimer compile error with CPU_CK610
From: Guo Ren The timer-mp-csky.c only could support CPU_CK860 and it will compile error with CPU_CK610. It has been selected in arch/csky/Kconfig. Signed-off-by: Guo Ren Cc: Daniel Lezcano Cc: Thomas Gleixner Cc: Marc Zyngier --- drivers/clocksource/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- v2: Drop the string after bool, as suggested by Marc Zyngier diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index 14c7c4712478..d39e6ca86d25 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -662,7 +662,7 @@ config CLINT_TIMER driver is usually used for NoMMU RISC-V systems. config CSKY_MP_TIMER - bool "SMP Timer for the C-SKY platform" if COMPILE_TEST + bool depends on CSKY select TIMER_OF help -- 2.17.1
[PATCH v2 1/2] drivers/irqchip: Fixup csky,mpintc compile error with CPU_CK610
From: Guo Ren The irq-csky-mpintc.c only could support CPU_CK860 and it will compile error with CPU_CK610. It has beed selected in arch/csky/Kconfig Signed-off-by: Guo Ren Cc: Marc Zyngier --- drivers/irqchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- v2: Drop the string after bool, as suggested by Marc Zyngier diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index b147f22a78f4..53abecb8c792 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -432,7 +432,7 @@ config QCOM_PDC IRQs for Qualcomm Technologies Inc (QTI) mobile chips. config CSKY_MPINTC - bool "C-SKY Multi Processor Interrupt Controller" + bool depends on CSKY help Say yes here to enable C-SKY SMP interrupt controller driver used -- 2.17.1
Re: [PATCH v4 5/5] phy: phy-hi3670-usb3: move driver from staging into phy
On 19-01-21, 11:44, Mauro Carvalho Chehab wrote: > The phy USB3 driver for Hisilicon 970 (hi3670) is ready > for mainstream. Mode it from staging into the main driver's > phy/ directory. Acked-By: Vinod Koul I think it makes sense if Greg applies this as well -- ~Vinod
Re: [PATCH v8 0/2] Kbuild: DWARF v5 support
On Wed, Feb 3, 2021 at 10:58 PM Sedat Dilek wrote: > > I guess I need to test harder to get a Tested-by credit :-)? You're right Sedat, I'm sorry. Your testing is invaluable; thank you for taking the time to help and credit is a powerful incentive. It can be difficult to know whether to carry forward tags or not when a patch is revised. Keeping track whether someone sent an explicit Tested By vs including it based on feedback that implied they tried it. If you've tested v7 or v8, please reply explicitly with tested by tags, or perhaps Masahiro can apply those for you. It can be difficult to know what's broken if you apply too many out of tree patches though. -- Thanks, ~Nick Desaulniers
Re: [PATCH 1/2] ARM: dts: am335x-pocketbeagle: unique gpio-line-names
On Thu, Feb 04, 2021 at 08:58:20AM +0200, Tony Lindgren wrote: > * Drew Fustini [210127 02:04]: > > Based on linux-gpio discussion [1], it is best practice to make the > > gpio-line-names unique. Generic names like "[ethernet]" are replaced > > with the name of the unique signal on the AM3358 SoC ball corresponding > > to the gpio line. "[NC]" is also renamed to the standard "NC" name to > > represent "not connected". > > > > [1] https://lore.kernel.org/linux-gpio/20201216195357.GA2583366@x1/ > > So are these needed for v5.12 as fixes, or can these wait until after > the merge window for v5.13? > > Regards, > > Tony I suppose it depends on if/when the patches to make gpio lines unique go in. I believe the last response from Linus W. was in mid-December and indicated he holding off merging as it was immature [1] Thanks, Drew [1] https://lore.kernel.org/linux-gpio/cacrpkdbxrhcdgx-ybbny7cmob0dznhi1eta3qnc71ztoyb3...@mail.gmail.com/
[PATCH net-next] xfrm: Return the correct errno code
When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. Signed-off-by: Zheng Yongjun --- net/xfrm/xfrm_user.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index d0c32a8fcc4a..ad63a6c77edd 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -2444,7 +2444,7 @@ static int xfrm_do_migrate(struct sk_buff *skb, struct nlmsghdr *nlh, encap = kmemdup(nla_data(attrs[XFRMA_ENCAP]), sizeof(*encap), GFP_KERNEL); if (!encap) - return 0; + return -ENOMEM; } err = xfrm_migrate(>sel, pi->dir, type, m, n, kmp, net, encap); -- 2.22.0
Re: [PATCH V7 6/6] of: unittest: Statically apply overlays using fdtoverlay
On 03-02-21, 19:54, Rob Herring wrote: > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index b00855b247e0..886d2e6c58f0 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -66,6 +66,9 @@ multi-used := $(multi-used-y) $(multi-used-m) > real-obj-y := $(foreach m, $(obj-y), $(if $(strip $($(m:.o=-objs)) > $($(m:.o=-y)) $($(m:.o=-))),$($(m:.o=-objs)) $($(m:.o=-y)),$(m))) > real-obj-m := $(foreach m, $(obj-m), $(if $(strip $($(m:.o=-objs)) > $($(m:.o=-y)) $($(m:.o=-m)) $($(m:.o=-))),$($(m:.o=-objs)) $($(m:.o=-y)) > $($(m:.o=-m)),$(m))) > > +real-dtb-y := $(foreach m,$(dtb-y), $(if $(strip > $($(m:.dtb=-dtbs))),$($(m:.dtb=-dtbs)),)) > +dtb-y += $(real-dtb-y) > + > always-y += $(always-m) > > # hostprogs-always-y += foo > @@ -332,6 +335,15 @@ $(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE > $(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE > $(call if_changed_dep,dtc) > > + > +quiet_cmd_fdtoverlay = DTOVL $@ > + cmd_fdtoverlay = $(objtree)/scripts/dtc/fdtoverlay -o $@ -i > $(real-prereqs) > + > +.SECONDEXPANSION: > + > +$(obj)/%.dtb: $$(addprefix $$(obj)/,$$(%-dtbs)) FORCE > + $(call if_changed,fdtoverlay) > + > DT_CHECKER ?= dt-validate > DT_BINDING_DIR := Documentation/devicetree/bindings > # DT_TMP_SCHEMA may be overridden from > Documentation/devicetree/bindings/Makefile Thanks, this simplifies it greatly for platform guys. -- viresh
[PATCH v2] firewire: convert sysfs sprintf/snprintf family to sysfs_emit
Fix the following coccicheck warning: ./drivers/firewire/core-device.c:375:8-16: WARNING: use scnprintf or sprintf. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- Changes in v2: - Modified print format. drivers/firewire/core-device.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c index 80db43a..25508a8 100644 --- a/drivers/firewire/core-device.c +++ b/drivers/firewire/core-device.c @@ -372,8 +372,7 @@ static ssize_t rom_index_show(struct device *dev, struct fw_device *device = fw_device(dev->parent); struct fw_unit *unit = fw_unit(dev); - return snprintf(buf, PAGE_SIZE, "%d\n", - (int)(unit->directory - device->config_rom)); + return sysfs_emit(buf, "%td\n", unit->directory - device->config_rom); } static struct device_attribute fw_unit_attributes[] = { @@ -403,8 +402,7 @@ static ssize_t guid_show(struct device *dev, int ret; down_read(_device_rwsem); - ret = snprintf(buf, PAGE_SIZE, "0x%08x%08x\n", - device->config_rom[3], device->config_rom[4]); + ret = sysfs_emit(buf, "0x%08x%08x\n", device->config_rom[3], device->config_rom[4]); up_read(_device_rwsem); return ret; -- 1.8.3.1
Re: [PATCH] ath11k: remove h from printk format specifier
t...@redhat.com wrote: > This change fixes the checkpatch warning described in this commit > commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of > unnecessary %h[xudi] and %hh[xudi]") > > Standard integer promotion is already done and %hx and %hhx is useless > so do not encourage the use of %hh[xudi] or %h[xudi]. > > Signed-off-by: Tom Rix > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. bb2d2dfd3c93 ath11k: remove h from printk format specifier -- https://patchwork.kernel.org/project/linux-wireless/patch/20210128144928.2557605-1-t...@redhat.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: linux-next: build warning after merge of the drivers-x86 tree
Hi Stephen, Andy, On 2/4/21 6:13 AM, Stephen Rothwell wrote: > Hi all, > > After merging the drivers-x86 tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/platform/x86/intel_scu_wdt.c: In function 'register_mid_wdt': > drivers/platform/x86/intel_scu_wdt.c:66:28: warning: assignment discards > 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] >66 | wdt_dev.dev.platform_data = (const struct intel_mid_wdt_pdata > *)id->driver_data; > |^ > > Introduced by commit > > a507e5d90f3d ("platform/x86: intel_scu_wdt: Get rid of custom x86 model > comparison") Thank you for the bug report. Andy can you send me a fix for this please ? Regards, Hans
Re: [PATCH] ath10k: remove h from printk format specifier
t...@redhat.com wrote: > This change fixes the checkpatch warning described in this commit > commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of > unnecessary %h[xudi] and %hh[xudi]") > > Standard integer promotion is already done and %hx and %hhx is useless > so do not encourage the use of %hh[xudi] or %h[xudi]. > > Signed-off-by: Tom Rix > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 779750bb153d ath10k: remove h from printk format specifier -- https://patchwork.kernel.org/project/linux-wireless/patch/20210127222344.2445641-1-t...@redhat.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH net-next] net: sched: Return the correct errno code
When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. Signed-off-by: Zheng Yongjun --- net/sched/em_nbyte.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/em_nbyte.c b/net/sched/em_nbyte.c index 2c1192a2ee5e..a83b237cbeb0 100644 --- a/net/sched/em_nbyte.c +++ b/net/sched/em_nbyte.c @@ -31,7 +31,7 @@ static int em_nbyte_change(struct net *net, void *data, int data_len, em->datalen = sizeof(*nbyte) + nbyte->len; em->data = (unsigned long)kmemdup(data, em->datalen, GFP_KERNEL); if (em->data == 0UL) - return -ENOBUFS; + return -ENOMEM; return 0; } -- 2.22.0
Re: [PATCH] kprobes: Warn if the kprobe is reregistered
On 2/3/21 8:29 PM, Masami Hiramatsu wrote: Warn if the kprobe is reregistered, since there must be a software bug (actively used resource must not be re-registered) and caller must be fixed. Signed-off-by: Masami Hiramatsu Acked-by: Ananth N Mavinakayanahalli
[PATCH v1] vdpa/mlx5: Restore the hardware used index after change map
When a change of memory map occurs, the hardware resources are destroyed and then re-created again with the new memory map. In such case, we need to restore the hardware available and used indices. The driver failed to restore the used index which is added here. Also, since the driver also fails to reset the available and used indices upon device reset, fix this here to avoid regression caused by the fact that used index may not be zero upon device reset. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen --- v0 -> v1: Clear indices upon device reset drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c index 88dde3455bfd..b5fe6d2ad22f 100644 --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c @@ -87,6 +87,7 @@ struct mlx5_vq_restore_info { u64 device_addr; u64 driver_addr; u16 avail_index; + u16 used_index; bool ready; struct vdpa_callback cb; bool restore; @@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue { u32 virtq_id; struct mlx5_vdpa_net *ndev; u16 avail_idx; + u16 used_idx; int fw_state; /* keep last in the struct */ @@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtque obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in, obj_context); MLX5_SET(virtio_net_q_object, obj_context, hw_available_index, mvq->avail_idx); + MLX5_SET(virtio_net_q_object, obj_context, hw_used_index, mvq->used_idx); MLX5_SET(virtio_net_q_object, obj_context, queue_feature_bit_mask_12_3, get_features_12_3(ndev->mvdev.actual_features)); vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context, virtio_q_context); @@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *m struct mlx5_virtq_attr { u8 state; u16 available_index; + u16 used_index; }; static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *mvq, @@ -1052,6 +1056,7 @@ static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueu memset(attr, 0, sizeof(*attr)); attr->state = MLX5_GET(virtio_net_q_object, obj_context, state); attr->available_index = MLX5_GET(virtio_net_q_object, obj_context, hw_available_index); + attr->used_index = MLX5_GET(virtio_net_q_object, obj_context, hw_used_index); kfree(out); return 0; @@ -1535,6 +1540,16 @@ static void teardown_virtqueues(struct mlx5_vdpa_net *ndev) } } +static void clear_virtqueues(struct mlx5_vdpa_net *ndev) +{ + int i; + + for (i = ndev->mvdev.max_vqs - 1; i >= 0; i--) { + ndev->vqs[i].avail_idx = 0; + ndev->vqs[i].used_idx = 0; + } +} + /* TODO: cross-endian support */ static inline bool mlx5_vdpa_is_little_endian(struct mlx5_vdpa_dev *mvdev) { @@ -1610,6 +1625,7 @@ static int save_channel_info(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqu return err; ri->avail_index = attr.available_index; + ri->used_index = attr.used_index; ri->ready = mvq->ready; ri->num_ent = mvq->num_ent; ri->desc_addr = mvq->desc_addr; @@ -1654,6 +1670,7 @@ static void restore_channels_info(struct mlx5_vdpa_net *ndev) continue; mvq->avail_idx = ri->avail_index; + mvq->used_idx = ri->used_index; mvq->ready = ri->ready; mvq->num_ent = ri->num_ent; mvq->desc_addr = ri->desc_addr; @@ -1768,6 +1785,7 @@ static void mlx5_vdpa_set_status(struct vdpa_device *vdev, u8 status) if (!status) { mlx5_vdpa_info(mvdev, "performing device reset\n"); teardown_driver(ndev); + clear_virtqueues(ndev); mlx5_vdpa_destroy_mr(>mvdev); ndev->mvdev.status = 0; ndev->mvdev.mlx_features = 0; -- 2.29.2
[PATCH] scsi: lpfc: Remove unneeded return variable
This patch removes unneeded return variables, using only '1' instead. It fixes the following warning detected by coccinelle: Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/scsi/lpfc/lpfc_sli.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index 95caad7..31f97f6 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -3376,7 +3376,6 @@ struct lpfc_hbq_init *lpfc_hbq_defs[] = { struct lpfc_iocbq *saveq) { struct lpfc_iocbq *cmdiocbp; - int rc = 1; unsigned long iflag; cmdiocbp = lpfc_sli_iocbq_lookup(phba, pring, saveq); @@ -3501,7 +3500,7 @@ struct lpfc_hbq_init *lpfc_hbq_defs[] = { } } - return rc; + return 1; } /** -- 1.8.3.1
Re: [PATCH 1/2] quota: Add mountpath based quota support
On Tue, Feb 02, 2021 at 07:02:41PM +0100, Jan Kara wrote: > Hum, let me think out loud. The path we pass to Q_QUOTAON is a path to > quota file - unless the filesystem stores quota in hidden files in which > case this argument is just ignored. You're right we could require that > specifically for Q_QUOTAON, the mountpoint path would actually need to > point to the quota file if it is relevant, otherwise anywhere in the > appropriate filesystem. We don't allow quota file to reside on a different > filesystem (for a past decade or so) so it should work fine. > > So the only problem I have is whether requiring the mountpoint argument to > point quota file for Q_QUOTAON isn't going to be somewhat confusing to > users. At the very least it would require some careful explanation in the > manpage to explain the difference between quotactl_path() and quotactl() > in this regard. But is saving the second path for Q_QUOTAON really worth the > bother? I find the doubled path argument a really horrible API, so I'd pretty strongly prefer to avoid that. > > Given how cheap quotactl_cmd_onoff and quotactl_cmd_write are we > > could probably simplify this down do: > > > > if (quotactl_cmd_write(cmd)) { > > This needs to be (quotactl_cmd_write(cmd) || quotactl_cmd_onoff(cmd)). > Otherwise I agree what you suggest is somewhat more readable given how > small the function is. The way I read quotactl_cmd_write, it only special cases a few commands and returns 0 there, so we should not need the extra quotactl_cmd_onoff call, as all those commands are not explicitly listed.
Re: [PATCH] ceph: minor coding style tweaks
On Thu, 2021-02-04 at 14:32 +0800, Zhiyuan Dai wrote: > Fixed some coding style issues, improve code reading. Might describe the patch does 3 things: o Move the pointer location struct foo* bar; -> struct foo *bar; o Move brace position from struct foo { to struct foo { o Alignment to open parenthesis And one more comment: > diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c [] > @@ -309,8 +309,8 @@ static int ceph_fill_dirfrag(struct inode *inode, > > static int frag_tree_split_cmp(const void *l, const void *r) > { > - struct ceph_frag_tree_split *ls = (struct ceph_frag_tree_split*)l; > - struct ceph_frag_tree_split *rs = (struct ceph_frag_tree_split*)r; > + struct ceph_frag_tree_split *ls = (struct ceph_frag_tree_split *)l; > + struct ceph_frag_tree_split *rs = (struct ceph_frag_tree_split *)r; It's unnecessary to cast void pointers and it's bad form to lose the const qualifier. const struct ceph_frag_tree_split *ls = l; const struct ceph_frag_tree_split *rs = r; > return ceph_frag_compare(le32_to_cpu(ls->frag), > le32_to_cpu(rs->frag)); > }
[PATCH v4 1/1] mm/highmem: Remove deprecated kmap_atomic
From: Ira Weiny kmap_atomic() is being deprecated in favor of kmap_local_page(). Replace the uses of kmap_atomic() within the highmem code. On profiling clear_huge_page() using ftrace an improvement of 62% was observed on the below setup. Setup:- Below data has been collected on Qualcomm's SM7250 SoC THP enabled (kernel v4.19.113) with only CPU-0(Cortex-A55) and CPU-7(Cortex-A76) switched on and set to max frequency, also DDR set to perf governor. FTRACE Data:- Base data:- Number of iterations: 48 Mean of allocation time: 349.5 us std deviation: 74.5 us v4 data:- Number of iterations: 48 Mean of allocation time: 131 us std deviation: 32.7 us The following simple userspace experiment to allocate 100MB(BUF_SZ) of pages and writing to it gave us a good insight, we observed an improvement of 42% in allocation and writing timings. - Test code snippet - clock_start(); buf = malloc(BUF_SZ); /* Allocate 100 MB of memory */ for(i=0; i < BUF_SZ_PAGES; i++) { *((int *)(buf + (i*PAGE_SIZE))) = 1; } clock_end(); - Malloc test timings for 100MB anon allocation:- Base data:- Number of iterations: 100 Mean of allocation time: 31831 us std deviation: 4286 us v4 data:- Number of iterations: 100 Mean of allocation time: 18193 us std deviation: 4915 us Signed-off-by: Ira Weiny Signed-off-by: Prathu Baronia [Updated commit text with test data] --- include/linux/highmem.h | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/include/linux/highmem.h b/include/linux/highmem.h index d2c70d3772a3..9a202c7e4e26 100644 --- a/include/linux/highmem.h +++ b/include/linux/highmem.h @@ -146,9 +146,9 @@ static inline void invalidate_kernel_vmap_range(void *vaddr, int size) #ifndef clear_user_highpage static inline void clear_user_highpage(struct page *page, unsigned long vaddr) { - void *addr = kmap_atomic(page); + void *addr = kmap_local_page(page); clear_user_page(addr, vaddr, page); - kunmap_atomic(addr); + kunmap_local(addr); } #endif @@ -199,9 +199,9 @@ alloc_zeroed_user_highpage_movable(struct vm_area_struct *vma, static inline void clear_highpage(struct page *page) { - void *kaddr = kmap_atomic(page); + void *kaddr = kmap_local_page(page); clear_page(kaddr); - kunmap_atomic(kaddr); + kunmap_local(kaddr); } /* @@ -216,7 +216,7 @@ static inline void zero_user_segments(struct page *page, unsigned start1, unsigned end1, unsigned start2, unsigned end2) { - void *kaddr = kmap_atomic(page); + void *kaddr = kmap_local_page(page); unsigned int i; BUG_ON(end1 > page_size(page) || end2 > page_size(page)); @@ -227,7 +227,7 @@ static inline void zero_user_segments(struct page *page, if (end2 > start2) memset(kaddr + start2, 0, end2 - start2); - kunmap_atomic(kaddr); + kunmap_local(kaddr); for (i = 0; i < compound_nr(page); i++) flush_dcache_page(page + i); } @@ -252,11 +252,11 @@ static inline void copy_user_highpage(struct page *to, struct page *from, { char *vfrom, *vto; - vfrom = kmap_atomic(from); - vto = kmap_atomic(to); + vfrom = kmap_local_page(from); + vto = kmap_local_page(to); copy_user_page(vto, vfrom, vaddr, to); - kunmap_atomic(vto); - kunmap_atomic(vfrom); + kunmap_local(vto); + kunmap_local(vfrom); } #endif @@ -267,11 +267,11 @@ static inline void copy_highpage(struct page *to, struct page *from) { char *vfrom, *vto; - vfrom = kmap_atomic(from); - vto = kmap_atomic(to); + vfrom = kmap_local_page(from); + vto = kmap_local_page(to); copy_page(vto, vfrom); - kunmap_atomic(vto); - kunmap_atomic(vfrom); + kunmap_local(vto); + kunmap_local(vfrom); } #endif -- 2.17.1
[PATCH v4 0/1] mm/highmem: Remove deprecated kmap_atomic
Updated the commit text. Changelog: Added my test data to Ira's v3 patch. Ira Weiny (1): mm/highmem: Remove deprecated kmap_atomic include/linux/highmem.h | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) -- 2.17.1
Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order
On Wed, 3 Feb 2021 at 12:10, Bharata B Rao wrote: > > On Wed, Jan 27, 2021 at 12:04:01PM +0100, Vlastimil Babka wrote: > > On 1/27/21 10:10 AM, Christoph Lameter wrote: > > > On Tue, 26 Jan 2021, Will Deacon wrote: > > > > > >> > Hm, but booting the secondaries is just a software (kernel) action? > > >> > They are > > >> > already physically there, so it seems to me as if the cpu_present_mask > > >> > is not > > >> > populated correctly on arm64, and it's just a mirror of > > >> > cpu_online_mask? > > >> > > >> I think the present_mask retains CPUs if they are hotplugged off, whereas > > >> the online mask does not. We can't really do any better on arm64, as > > >> there's > > >> no way of telling that a CPU is present until we've seen it. > > > > > > The order of each page in a kmem cache --and therefore also the number > > > of objects in a slab page-- can be different because that information is > > > stored in the page struct. > > > > > > Therefore it is possible to retune the order while the cache is in > > > operaton. > > > > Yes, but it's tricky to do the retuning safely, e.g. if freelist > > randomization > > is enabled, see [1]. > > > > But as a quick fix for the regression, the heuristic idea could work > > reasonably > > on all architectures? > > - if num_present_cpus() is > 1, trust that it doesn't have the issue such as > > arm64, and use it > > - otherwise use nr_cpu_ids > > > > Long-term we can attempt to do the retuning safe, or decide that number of > > cpus > > shouldn't determine the order... > > > > [1] > > https://lore.kernel.org/linux-mm/d7fb9425-9a62-c7b8-604d-5828d7e6b...@suse.cz/ > > So what is preferrable here now? Above or other quick fix or reverting > the original commit? I'm fine with whatever the solution as long as we can use keep using nr_cpu_ids when other values like num_present_cpus, don't reflect correctly the system Regards, Vincent > > Regards, > Bharata.
AW: [PATCH v1] leds: lp50xx: add setting of default intensity from DT
Helo Pavel, > > > Yes, sounds reasonable. Could we get default intensity of 100% on all > > > channels if nothing else is specified? > > > > > > Or maybe simply "if intensity is not specified, start with 100%, and > > > use explicit =0 if other color is expected". > > > > > Mh, if someone is already using the led driver and updates to a newer kernel > > we would then turn on all leds per default to the maximum intensity during > > boot > > until they are set the way they should be from userspace. I don't know if > > this > > is what we want? If yes, sure, we could set them to maximum per > > default. > > Not really. If they don't have trigger configured, nothing will happen. Oops, you are right, my fault. > > > Also if we want to use Percentage Values (%) for setting the intensity > > I think this should also be done for the userspace interfaces and > > not only from DT. > > We don't want to use percentages in the API (but let me still use > percentages in discussion). No Problem. Best Regards, Sven
[PATCH] x86: Remove HPET_EMULATE_RTC depends on RTC
The RTC config option was removed in commit f52ef24be21a ("rtc/alpha: remove legacy rtc driver") Signed-off-by: Anand K Mistry --- arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 21f851179ff0..37775478d86f 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -890,7 +890,7 @@ config HPET_TIMER config HPET_EMULATE_RTC def_bool y - depends on HPET_TIMER && (RTC=y || RTC=m || RTC_DRV_CMOS=m || RTC_DRV_CMOS=y) + depends on HPET_TIMER && (RTC_DRV_CMOS=m || RTC_DRV_CMOS=y) config APB_TIMER def_bool y if X86_INTEL_MID -- 2.30.0.365.g02bc693789-goog
[PATCH net-next] net: Return the correct errno code
When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. Signed-off-by: Zheng Yongjun --- net/mpls/af_mpls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c index f2868a8a50c3..7e73611c48dd 100644 --- a/net/mpls/af_mpls.c +++ b/net/mpls/af_mpls.c @@ -1427,7 +1427,7 @@ static int mpls_dev_sysctl_register(struct net_device *dev, free: kfree(table); out: - return -ENOBUFS; + return -ENOMEM; } static void mpls_dev_sysctl_unregister(struct net_device *dev, -- 2.22.0
AW: [PATCH v1] leds: lp50xx: add setting of default intensity from DT
Hello Pavel, hello Marek > > Is the property default-intensity documented in DT bindings? I updated the documentation in leds-lp50xx.yaml. Is it this what you mean? > > Wouldn't it be better if the property was used in the multi-led node > > instead of the channel node? I.e. > > multi-led@3 { > > color = ; > > default-intensity = <100 0 0>; > > }; > > Yes, this would be better. Sound good, I will see what I can do here. Regards, Sven
Re: [PATCH RFC v1 2/6] swiotlb: convert variables to arrays
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote: > This patch converts several swiotlb related variables to arrays, in > order to maintain stat/status for different swiotlb buffers. Here are > variables involved: > > - io_tlb_start and io_tlb_end > - io_tlb_nslabs and io_tlb_used > - io_tlb_list > - io_tlb_index > - max_segment > - io_tlb_orig_addr > - no_iotlb_memory > > There is no functional change and this is to prepare to enable 64-bit > swiotlb. Claire Chang (on Cc) already posted a patch like this a month ago, which looks much better because it actually uses a struct instead of all the random variables.
[PATCH net-next] dccp: Return the correct errno code
When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. Signed-off-by: Zheng Yongjun --- net/dccp/feat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/dccp/feat.c b/net/dccp/feat.c index 788dd629c420..4cb813bee7b4 100644 --- a/net/dccp/feat.c +++ b/net/dccp/feat.c @@ -371,7 +371,7 @@ static int dccp_feat_clone_sp_val(dccp_feat_val *fval, u8 const *val, u8 len) fval->sp.vec = kmemdup(val, len, gfp_any()); if (fval->sp.vec == NULL) { fval->sp.len = 0; - return -ENOBUFS; + return -ENOMEM; } } return 0; -- 2.22.0
Re: [PATCH v2] x86/fault: Send a SIGBUS to user process always for hwpoison page access.
Hi Aili, On Mon, Feb 01, 2021 at 04:17:49PM +0800, Aili Yao wrote: > When one page is already hwpoisoned by AO action, process may not be > killed, the process mapping this page may make a syscall include this > page and result to trigger a VM_FAULT_HWPOISON fault, if it's in kernel > mode it may be fixed by fixup_exception. Current code will just return > error code to user process. > > This is not sufficient, we should send a SIGBUS to the process and log > the info to console, as we can't trust the process will handle the error > correctly. > > Suggested-by: Feng Yang > Signed-off-by: Aili Yao > --- ... > @@ -662,12 +662,32 @@ no_context(struct pt_regs *regs, unsigned long > error_code, >* In this case we need to make sure we're not recursively >* faulting through the emulate_vsyscall() logic. >*/ > + > + if (IS_ENABLED(CONFIG_MEMORY_FAILURE) && > + fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) { > + unsigned int lsb = 0; > + > + pr_err("MCE: Killing %s:%d due to hardware memory > corruption fault at %lx\n", > + current->comm, current->pid, address); > + > + sanitize_error_code(address, _code); > + set_signal_archinfo(address, error_code); > + > + if (fault & VM_FAULT_HWPOISON_LARGE) > + lsb = > hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault)); > + if (fault & VM_FAULT_HWPOISON) > + lsb = PAGE_SHIFT; > + > + force_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, > lsb); This part contains some duplicated code with do_sigbus(), so some refactoring (like adding a common function) would be more helpful. Thanks, Naoya Horiguchi
[PATCH net-next] ipv6: Return the correct errno code
When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. Signed-off-by: Zheng Yongjun --- net/ipv6/addrconf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 8b6eb384bac7..347b95bc00fd 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -6943,7 +6943,7 @@ static int __addrconf_sysctl_register(struct net *net, char *dev_name, free: kfree(table); out: - return -ENOBUFS; + return -ENOMEM; } static void __addrconf_sysctl_unregister(struct net *net, -- 2.22.0
[PATCH] scsi: ipr: Remove unneeded return variable
This patch removes unneeded return variables, using only '0' instead. It fixes the following warning detected by coccinelle: ./drivers/scsi/ipr.c:9508:5-7: Unneeded variable: "rc". Return "0" on line 9524 Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/scsi/ipr.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c index e451102..8eced7c 100644 --- a/drivers/scsi/ipr.c +++ b/drivers/scsi/ipr.c @@ -9505,7 +9505,6 @@ static pci_ers_result_t ipr_pci_error_detected(struct pci_dev *pdev, **/ static int ipr_probe_ioa_part2(struct ipr_ioa_cfg *ioa_cfg) { - int rc = 0; unsigned long host_lock_flags = 0; ENTER; @@ -9521,7 +9520,7 @@ static int ipr_probe_ioa_part2(struct ipr_ioa_cfg *ioa_cfg) spin_unlock_irqrestore(ioa_cfg->host->host_lock, host_lock_flags); LEAVE; - return rc; + return 0; } /** -- 1.8.3.1
[PATCH net-next] net: ipv4: Return the correct errno code
When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. Signed-off-by: Zheng Yongjun --- net/ipv4/devinet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c index 123a6d39438f..fa586e915621 100644 --- a/net/ipv4/devinet.c +++ b/net/ipv4/devinet.c @@ -2582,7 +2582,7 @@ static int __devinet_sysctl_register(struct net *net, char *dev_name, free: kfree(t); out: - return -ENOBUFS; + return -ENOMEM; } static void __devinet_sysctl_unregister(struct net *net, -- 2.22.0
Re: Kernel version numbers after 4.9.255 and 4.4.255
On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote: On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote: Greg, I hope that your linux kernel release scripts are implemented in a way that understands that PATCHLEVEL= and SUBLEVEL= numbers in top-level linux Makefile are encoded as 8-bit numbers for LINUX_VERSION_CODE and KERNEL_VERSION() macros, and must stay in range 0...255. These 8-bit limits are hardcoded in both kernel source and userspace ABI. After 4.9.255 and 4.4.255, your scripts should be incrementing a number in EXTRAVERSION= in top-level linux Makefile. Should already be fixed in linux-next, right? I assume you mean: commit 537896fabed11f8d976d1aacdb977213c7b3 Author: Sasha Levin Date: Mon Jan 18 14:54:53 2021 -0500 kbuild: give the SUBLEVEL more room in KERNEL_VERSION That would IMO break userspace as definition of kernel version has changed. And that one is UAPI/ABI (see include/generated/uapi/linux/version.h) as Jari writes. For example will glibc still work: http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/configure.ac;h=13abda0a51484c5951ffc6d718aa36b72f3a9429;hb=HEAD#l14 ? Or gcc 10 (11 will have this differently): https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf.c;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l165 and https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf-helpers.h;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l53 It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z) assumptions all around the world. So this doesn't look like a good idea. thanks, -- js suse labs
Re: [v6 PATCH 03/11] mm: vmscan: use shrinker_rwsem to protect shrinker_maps allocation
On 03.02.2021 20:20, Yang Shi wrote: > Since memcg_shrinker_map_size just can be changed under holding shrinker_rwsem > exclusively, the read side can be protected by holding read lock, so it sounds > superfluous to have a dedicated mutex. > > Kirill Tkhai suggested use write lock since: > > * We want the assignment to shrinker_maps is visible for > shrink_slab_memcg(). > * The rcu_dereference_protected() dereferrencing in shrink_slab_memcg(), but > in case of we use READ lock in alloc_shrinker_maps(), the dereferrencing > is not actually protected. > * READ lock makes alloc_shrinker_info() racy against memory allocation fail. > alloc_shrinker_info()->free_shrinker_info() may free memory right after > shrink_slab_memcg() dereferenced it. You may say > shrink_slab_memcg()->mem_cgroup_online() protects us from it? Yes, sure, > but this is not the thing we want to remember in the future, since this > spreads modularity. > > And a test with heavy paging workload didn't show write lock makes things > worse. > > Acked-by: Vlastimil Babka > Signed-off-by: Yang Shi Acked-by: Kirill Tkhai > --- > mm/vmscan.c | 16 ++-- > 1 file changed, 6 insertions(+), 10 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 96b08c79f18d..e4ddaaaeffe2 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -187,7 +187,6 @@ static DECLARE_RWSEM(shrinker_rwsem); > #ifdef CONFIG_MEMCG > > static int memcg_shrinker_map_size; > -static DEFINE_MUTEX(memcg_shrinker_map_mutex); > > static void free_shrinker_map_rcu(struct rcu_head *head) > { > @@ -200,8 +199,6 @@ static int expand_one_shrinker_map(struct mem_cgroup > *memcg, > struct memcg_shrinker_map *new, *old; > int nid; > > - lockdep_assert_held(_shrinker_map_mutex); > - > for_each_node(nid) { > old = rcu_dereference_protected( > mem_cgroup_nodeinfo(memcg, nid)->shrinker_map, true); > @@ -249,7 +246,7 @@ int alloc_shrinker_maps(struct mem_cgroup *memcg) > if (mem_cgroup_is_root(memcg)) > return 0; > > - mutex_lock(_shrinker_map_mutex); > + down_write(_rwsem); > size = memcg_shrinker_map_size; > for_each_node(nid) { > map = kvzalloc_node(sizeof(*map) + size, GFP_KERNEL, nid); > @@ -260,7 +257,7 @@ int alloc_shrinker_maps(struct mem_cgroup *memcg) > } > rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_map, map); > } > - mutex_unlock(_shrinker_map_mutex); > + up_write(_rwsem); > > return ret; > } > @@ -275,9 +272,8 @@ static int expand_shrinker_maps(int new_id) > if (size <= old_size) > return 0; > > - mutex_lock(_shrinker_map_mutex); > if (!root_mem_cgroup) > - goto unlock; > + goto out; > > memcg = mem_cgroup_iter(NULL, NULL, NULL); > do { > @@ -286,13 +282,13 @@ static int expand_shrinker_maps(int new_id) > ret = expand_one_shrinker_map(memcg, size, old_size); > if (ret) { > mem_cgroup_iter_break(NULL, memcg); > - goto unlock; > + goto out; > } > } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL); > -unlock: > +out: > if (!ret) > memcg_shrinker_map_size = size; > - mutex_unlock(_shrinker_map_mutex); > + > return ret; > } > >
[PATCH] crypto: picoxcell - convert sysfs sprintf/snprintf family to sysfs_emit
Fix the following coccicheck warning: ./drivers/crypto/picoxcell_crypto.c:1201:8-16: WARNING: use scnprintf or sprintf. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/crypto/picoxcell_crypto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c index 84f9c16..d7a7def 100644 --- a/drivers/crypto/picoxcell_crypto.c +++ b/drivers/crypto/picoxcell_crypto.c @@ -1198,7 +1198,7 @@ static ssize_t spacc_stat_irq_thresh_show(struct device *dev, { struct spacc_engine *engine = spacc_dev_to_engine(dev); - return snprintf(buf, PAGE_SIZE, "%u\n", engine->stat_irq_thresh); + return sysfs_emit(buf, "%u\n", engine->stat_irq_thresh); } static ssize_t spacc_stat_irq_thresh_store(struct device *dev, -- 1.8.3.1
Re: [v6 PATCH 02/11] mm: vmscan: consolidate shrinker_maps handling code
On 03.02.2021 20:20, Yang Shi wrote: > The shrinker map management is not purely memcg specific, it is at the > intersection > between memory cgroup and shrinkers. It's allocation and assignment of a > structure, > and the only memcg bit is the map is being stored in a memcg structure. So > move the > shrinker_maps handling code into vmscan.c for tighter integration with > shrinker code, > and remove the "memcg_" prefix. There is no functional change. > > Acked-by: Vlastimil Babka > Signed-off-by: Yang Shi Acked-by: Kirill Tkhai > --- > include/linux/memcontrol.h | 11 ++-- > mm/huge_memory.c | 4 +- > mm/list_lru.c | 6 +- > mm/memcontrol.c| 129 +--- > mm/vmscan.c| 131 - > 5 files changed, 141 insertions(+), 140 deletions(-) > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index eeb0b52203e9..1739f17e0939 100644 > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -1581,10 +1581,9 @@ static inline bool > mem_cgroup_under_socket_pressure(struct mem_cgroup *memcg) > return false; > } > > -extern int memcg_expand_shrinker_maps(int new_id); > - > -extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg, > -int nid, int shrinker_id); > +int alloc_shrinker_maps(struct mem_cgroup *memcg); > +void free_shrinker_maps(struct mem_cgroup *memcg); > +void set_shrinker_bit(struct mem_cgroup *memcg, int nid, int shrinker_id); > #else > #define mem_cgroup_sockets_enabled 0 > static inline void mem_cgroup_sk_alloc(struct sock *sk) { }; > @@ -1594,8 +1593,8 @@ static inline bool > mem_cgroup_under_socket_pressure(struct mem_cgroup *memcg) > return false; > } > > -static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg, > - int nid, int shrinker_id) > +static inline void set_shrinker_bit(struct mem_cgroup *memcg, > + int nid, int shrinker_id) > { > } > #endif > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 9237976abe72..05190d7f32ae 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2823,8 +2823,8 @@ void deferred_split_huge_page(struct page *page) > ds_queue->split_queue_len++; > #ifdef CONFIG_MEMCG > if (memcg) > - memcg_set_shrinker_bit(memcg, page_to_nid(page), > -deferred_split_shrinker.id); > + set_shrinker_bit(memcg, page_to_nid(page), > + deferred_split_shrinker.id); > #endif > } > spin_unlock_irqrestore(_queue->split_queue_lock, flags); > diff --git a/mm/list_lru.c b/mm/list_lru.c > index fe230081690b..628030fa5f69 100644 > --- a/mm/list_lru.c > +++ b/mm/list_lru.c > @@ -125,8 +125,8 @@ bool list_lru_add(struct list_lru *lru, struct list_head > *item) > list_add_tail(item, >list); > /* Set shrinker bit if the first element was added */ > if (!l->nr_items++) > - memcg_set_shrinker_bit(memcg, nid, > -lru_shrinker_id(lru)); > + set_shrinker_bit(memcg, nid, > + lru_shrinker_id(lru)); > nlru->nr_items++; > spin_unlock(>lock); > return true; > @@ -548,7 +548,7 @@ static void memcg_drain_list_lru_node(struct list_lru > *lru, int nid, > > if (src->nr_items) { > dst->nr_items += src->nr_items; > - memcg_set_shrinker_bit(dst_memcg, nid, lru_shrinker_id(lru)); > + set_shrinker_bit(dst_memcg, nid, lru_shrinker_id(lru)); > src->nr_items = 0; > } > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 1bdb93ee8e72..f5c9a0d2160b 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -397,129 +397,6 @@ DEFINE_STATIC_KEY_FALSE(memcg_kmem_enabled_key); > EXPORT_SYMBOL(memcg_kmem_enabled_key); > #endif > > -static int memcg_shrinker_map_size; > -static DEFINE_MUTEX(memcg_shrinker_map_mutex); > - > -static void memcg_free_shrinker_map_rcu(struct rcu_head *head) > -{ > - kvfree(container_of(head, struct memcg_shrinker_map, rcu)); > -} > - > -static int memcg_expand_one_shrinker_map(struct mem_cgroup *memcg, > - int size, int old_size) > -{ > - struct memcg_shrinker_map *new, *old; > - int nid; > - > - lockdep_assert_held(_shrinker_map_mutex); > - > - for_each_node(nid) { > - old = rcu_dereference_protected( > - mem_cgroup_nodeinfo(memcg, nid)->shrinker_map, true); > - /* Not yet online memcg */ > - if (!old) > - return 0; > - > - new = kvmalloc_node(sizeof(*new) + size, GFP_KERNEL, nid); > -
Re: [PATCH] bpf: Hoise pahole version checks into Kconfig
On Thu, Jan 14, 2021 at 12:07 AM Nathan Chancellor wrote: > > On Wed, Jan 13, 2021 at 02:38:27PM -0800, Andrii Nakryiko wrote: > > Hm.. Just saw Linus proposing using $(error-if) in Kconfig for an > > unrelated issue ([0]). If we can make this work, then it would catch > > such issue early on, yet won't have any downsides of hiding > > CONFIG_DEBUG_INFO_BTF if pahole is too old. WDYT? > > > > [0] > > https://lore.kernel.org/lkml/CAHk-=wh-+TMHPTFo1qs-MYyK7tZh-OQovA=pP3=e06acvp6...@mail.gmail.com/ > > Yes, I think that would be exactly what we want because DEBUG_INFO_BTF > could cause the build to error if PAHOLE_VERSION is not >= 116. I will > try to keep an eye on that thread to see how it goes then respin this > based on anything that comes from it. > For BPF/pahole testing (see [1]) with CONFIG_DEBUG_INFO_DWARF5=y I did: $ git diff diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index b0840d192e95..f15b37143165 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -272,7 +272,7 @@ config DEBUG_INFO_DWARF5 bool "Generate DWARF Version 5 debuginfo" depends on GCC_VERSION >= 5 || CC_IS_CLANG depends on CC_IS_GCC || $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS)) - depends on !DEBUG_INFO_BTF + depends on !DEBUG_INFO_BTF || (DEBUG_INFO_BTF && PAHOLE_VERSION >= 120) help Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc 5.0+ accepts the -gdwarf-5 flag but only had partial support for some Thanks again for that patch. - Sedat - [1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=tmp.1.20
Re: [v6 PATCH 01/11] mm: vmscan: use nid from shrink_control for tracepoint
On 03.02.2021 20:20, Yang Shi wrote: > The tracepoint's nid should show what node the shrink happens on, the start > tracepoint > uses nid from shrinkctl, but the nid might be set to 0 before end tracepoint > if the > shrinker is not NUMA aware, so the traceing log may show the shrink happens > on one > node but end up on the other node. It seems confusing. And the following > patch > will remove using nid directly in do_shrink_slab(), this patch also helps > cleanup > the code. > > Acked-by: Vlastimil Babka > Signed-off-by: Yang Shi Acked-by: Kirill Tkhai > --- > mm/vmscan.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index b1b574ad199d..b512dd5e3a1c 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -535,7 +535,7 @@ static unsigned long do_shrink_slab(struct shrink_control > *shrinkctl, > else > new_nr = atomic_long_read(>nr_deferred[nid]); > > - trace_mm_shrink_slab_end(shrinker, nid, freed, nr, new_nr, total_scan); > + trace_mm_shrink_slab_end(shrinker, shrinkctl->nid, freed, nr, new_nr, > total_scan); > return freed; > } > >
Re: [PATCH] add chan->cl check in mbox_chan_received_data()
Oh, I see, thank you 2021-02-01 14:28 GMT+08:00, Jassi Brar : > On Thu, Jan 7, 2021 at 5:53 AM haidong yao wrote: >> >> Hi Jassi Brar >> >> Thank you very much for your reply. >> >> Look at the function sprd_mbox_outbox_isr . >> >> Chan is !NULL. >> >> chan->cl is NULL when the client driver not loaded, the controller >> driver don't know the client driver loaded successfully, so, I do not >> use mbox_free_channel. >> >> Here,How do you know chan->cl is ok? >> > The channel is supposed to get/send data _only_ if it is being used by a > client. > Which you can mark in .startup() and .shutdown(). > > Checking for chan->cl will make your symptoms disappear but that is > not the right fix for the issue. > The right fix is to EITHER not cause Rx/Tx interrupt on a channel not > being used, OR not send it to upper layers. > > thanks. >
Re: [PATCH] vdpa/mlx5: Restore the hardware used index after change map
On Wed, Feb 03, 2021 at 12:33:26PM -0800, Si-Wei Liu wrote: > On Tue, Feb 2, 2021 at 10:48 PM Eli Cohen wrote: > > > > On Tue, Feb 02, 2021 at 09:14:02AM -0800, Si-Wei Liu wrote: > > > On Tue, Feb 2, 2021 at 6:34 AM Eli Cohen wrote: > > > > > > > > When a change of memory map occurs, the hardware resources are destroyed > > > > and then re-created again with the new memory map. In such case, we need > > > > to restore the hardware available and used indices. The driver failed to > > > > restore the used index which is added here. > > > > > > > > Fixes 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 > > > > devices") > > > > Signed-off-by: Eli Cohen > > > > --- > > > > This patch is being sent again a single patch the fixes hot memory > > > > addtion to a qemy process. > > > > > > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +++ > > > > 1 file changed, 7 insertions(+) > > > > > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c > > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c > > > > index 88dde3455bfd..839f57c64a6f 100644 > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c > > > > @@ -87,6 +87,7 @@ struct mlx5_vq_restore_info { > > > > u64 device_addr; > > > > u64 driver_addr; > > > > u16 avail_index; > > > > + u16 used_index; > > > > bool ready; > > > > struct vdpa_callback cb; > > > > bool restore; > > > > @@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue { > > > > u32 virtq_id; > > > > struct mlx5_vdpa_net *ndev; > > > > u16 avail_idx; > > > > + u16 used_idx; > > > > int fw_state; > > > > > > > > /* keep last in the struct */ > > > > @@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net > > > > *ndev, struct mlx5_vdpa_virtque > > > > > > > > obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in, > > > > obj_context); > > > > MLX5_SET(virtio_net_q_object, obj_context, hw_available_index, > > > > mvq->avail_idx); > > > > + MLX5_SET(virtio_net_q_object, obj_context, hw_used_index, > > > > mvq->used_idx); > > > > > > The saved indexes will apply to the new virtqueue object whenever it > > > is created. In virtio spec, these indexes will reset back to zero when > > > the virtio device is reset. But I don't see how it's done today. IOW, > > > I don't see where avail_idx and used_idx get cleared from the mvq for > > > device reset via set_status(). > > > > > > > Right, but this is not strictly related to this patch. I will post > > another patch to fix this. > > Better to post these two patches in a series.Or else it may cause VM > reboot problem as that is where the device gets reset. The avail_index > did not as the correct value will be written to by driver right after, > but used_idx introduced by this patch is supplied by device hence this > patch alone would introduce regression. > Thinking it over, I think this should be all fixed in a single patch. This fix alone introduces a regerssion as you pointed and there's no point in fixing it in another patch. > > > > BTW, can you describe a secnario that would cause a reset (through > > calling set_status()) that happens after the VQ has been used? > > You can try reboot the guest, that'll be the easy way to test. > > -Siwei > > > > > > -Siwei > > > > > > > > > > MLX5_SET(virtio_net_q_object, obj_context, > > > > queue_feature_bit_mask_12_3, > > > > get_features_12_3(ndev->mvdev.actual_features)); > > > > vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context, > > > > virtio_q_context); > > > > @@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net > > > > *ndev, struct mlx5_vdpa_virtqueue *m > > > > struct mlx5_virtq_attr { > > > > u8 state; > > > > u16 available_index; > > > > + u16 used_index; > > > > }; > > > > > > > > static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct > > > > mlx5_vdpa_virtqueue *mvq, > > > > @@ -1052,6 +1056,7 @@ static int query_virtqueue(struct mlx5_vdpa_net > > > > *ndev, struct mlx5_vdpa_virtqueu > > > > memset(attr, 0, sizeof(*attr)); > > > > attr->state = MLX5_GET(virtio_net_q_object, obj_context, state); > > > > attr->available_index = MLX5_GET(virtio_net_q_object, > > > > obj_context, hw_available_index); > > > > + attr->used_index = MLX5_GET(virtio_net_q_object, obj_context, > > > > hw_used_index); > > > > kfree(out); > > > > return 0; > > > > > > > > @@ -1610,6 +1615,7 @@ static int save_channel_info(struct mlx5_vdpa_net > > > > *ndev, struct mlx5_vdpa_virtqu > > > > return err; > > > > > > > > ri->avail_index = attr.available_index; > > > > + ri->used_index = attr.used_index; > > > > ri->ready = mvq->ready; > > > > ri->num_ent = mvq->num_ent; > > > > ri->desc_addr = mvq->desc_addr; > > > > @@ -1654,6 +1660,7 @@ static void
[PATCH] scsi: qla4xxx: Remove unneeded return variable
This patch removes unneeded return variables, using only '0' instead. It fixes the following warning detected by coccinelle: ./drivers/scsi/qla4xxx/ql4_os.c:3642:5-7: Unneeded variable: "rc". Return "0" on line 3741 Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/scsi/qla4xxx/ql4_os.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c index a4b014e..ed92534 100644 --- a/drivers/scsi/qla4xxx/ql4_os.c +++ b/drivers/scsi/qla4xxx/ql4_os.c @@ -3639,7 +3639,6 @@ static int qla4xxx_copy_to_fwddb_param(struct iscsi_bus_flash_session *sess, struct dev_db_entry *fw_ddb_entry) { uint16_t options; - int rc = 0; options = le16_to_cpu(fw_ddb_entry->options); SET_BITVAL(conn->is_fw_assigned_ipv6, options, BIT_11); @@ -3738,7 +3737,7 @@ static int qla4xxx_copy_to_fwddb_param(struct iscsi_bus_flash_session *sess, COPY_ISID(fw_ddb_entry->isid, sess->isid); - return rc; + return 0; } static void qla4xxx_copy_to_sess_conn_params(struct iscsi_conn *conn, -- 1.8.3.1
Re: [PATCH v2 1/2] platform/chrome: cros_ec: Import Type C control command
Hi Prashant, On Tue, 2 Feb 2021 18:15:37 -0800, Prashant Malani wrote: > This command is used to communicate with the Chrome Embedded Controller > (EC) regarding USB Type C events and state. > > These header updates are included in the latest Chrome OS EC headers [1] > > [1] > https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h Applied, thanks! [1/2] platform/chrome: cros_ec: Import Type C control command commit: 3ec28d3673362076444e290bdb0d94ec6432dc09 [2/2] platform/chrome: cros_ec_typec: Clear Type C disc events commit: d521119c8b0d70b91971d632430ec1143e5d2e26 Best regards, -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[PATCH] usb: host: ehci: remove casting dma_alloc_coherent
Remove casting the values returned by dma_alloc_coherent. Signed-off-by: Xu Wang --- drivers/usb/host/ehci-mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c index 6361d81272bc..769329032257 100644 --- a/drivers/usb/host/ehci-mem.c +++ b/drivers/usb/host/ehci-mem.c @@ -185,7 +185,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t flags) } /* Hardware periodic table */ - ehci->periodic = + ehci->periodic = dma_alloc_coherent(ehci_to_hcd(ehci)->self.sysdev, ehci->periodic_size * sizeof(__le32), >periodic_dma, flags); -- 2.17.1
[rcu:willy-maple 175/202] mm/ksm.c:979 unmerge_and_remove_all_rmap_items() error: uninitialized symbol 'mm'.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git willy-maple head: 7e346d2845b4bd77663394f39fa70456e0084c86 commit: 3fd77bfa4f25fa2e3caec024c69168bf6a0ca8d7 [175/202] mm/ksm: Use maple tree iterators instead of vma linked list config: x86_64-randconfig-m001-20210202 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot Reported-by: Dan Carpenter smatch warnings: mm/ksm.c:979 unmerge_and_remove_all_rmap_items() error: uninitialized symbol 'mm'. vim +/mm +979 mm/ksm.c d952b79136a6c3 Hugh Dickins 2009-09-21 965 static int unmerge_and_remove_all_rmap_items(void) 31dbd01f314364 Izik Eidus2009-09-21 966 { 31dbd01f314364 Izik Eidus2009-09-21 967 struct mm_slot *mm_slot; 31dbd01f314364 Izik Eidus2009-09-21 968 struct mm_struct *mm; 31dbd01f314364 Izik Eidus2009-09-21 969 struct vm_area_struct *vma; d952b79136a6c3 Hugh Dickins 2009-09-21 970 int err = 0; 31dbd01f314364 Izik Eidus2009-09-21 971 d952b79136a6c3 Hugh Dickins 2009-09-21 972 spin_lock(_mmlist_lock); 9ba6929480088a Hugh Dickins 2009-09-21 973 ksm_scan.mm_slot = list_entry(ksm_mm_head.mm_list.next, d952b79136a6c3 Hugh Dickins 2009-09-21 974 struct mm_slot, mm_list); d952b79136a6c3 Hugh Dickins 2009-09-21 975 spin_unlock(_mmlist_lock); d952b79136a6c3 Hugh Dickins 2009-09-21 976 9ba6929480088a Hugh Dickins 2009-09-21 977 for (mm_slot = ksm_scan.mm_slot; 3fd77bfa4f25fa Liam R. Howlett 2021-01-04 978 mm_slot != _mm_head; mm_slot = ksm_scan.mm_slot, mm = mm_slot->mm) { 3fd77bfa4f25fa Liam R. Howlett 2021-01-04 @979 MA_STATE(mas, >mm_mt, 0, 0); ^^ Not initialized on the first iteration through the loop? 3fd77bfa4f25fa Liam R. Howlett 2021-01-04 980 d8ed45c5dcd455 Michel Lespinasse 2020-06-08 981 mmap_read_lock(mm); 3fd77bfa4f25fa Liam R. Howlett 2021-01-04 982 mas_set(, 0); 3fd77bfa4f25fa Liam R. Howlett 2021-01-04 983 mas_for_each(, vma, ULONG_MAX) { 9ba6929480088a Hugh Dickins 2009-09-21 984 if (ksm_test_exit(mm)) 9ba6929480088a Hugh Dickins 2009-09-21 985 break; 31dbd01f314364 Izik Eidus2009-09-21 986 if (!(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma) 31dbd01f314364 Izik Eidus2009-09-21 987 continue; d952b79136a6c3 Hugh Dickins 2009-09-21 988 err = unmerge_ksm_pages(vma, d952b79136a6c3 Hugh Dickins 2009-09-21 989 vma->vm_start, vma->vm_end); 9ba6929480088a Hugh Dickins 2009-09-21 990 if (err) 9ba6929480088a Hugh Dickins 2009-09-21 991 goto error; 31dbd01f314364 Izik Eidus2009-09-21 992 } 9ba6929480088a Hugh Dickins 2009-09-21 993 6514d511dbe5a7 Hugh Dickins 2009-12-14 994 remove_trailing_rmap_items(mm_slot, _slot->rmap_list); d8ed45c5dcd455 Michel Lespinasse 2020-06-08 995 mmap_read_unlock(mm); d952b79136a6c3 Hugh Dickins 2009-09-21 996 d952b79136a6c3 Hugh Dickins 2009-09-21 997 spin_lock(_mmlist_lock); 9ba6929480088a Hugh Dickins 2009-09-21 998 ksm_scan.mm_slot = list_entry(mm_slot->mm_list.next, d952b79136a6c3 Hugh Dickins 2009-09-21 999 struct mm_slot, mm_list); 9ba6929480088a Hugh Dickins 2009-09-21 1000 if (ksm_test_exit(mm)) { 4ca3a69bcb6875 Sasha Levin 2013-02-22 1001 hash_del(_slot->link); 9ba6929480088a Hugh Dickins 2009-09-21 1002 list_del(_slot->mm_list); 9ba6929480088a Hugh Dickins 2009-09-21 1003 spin_unlock(_mmlist_lock); 9ba6929480088a Hugh Dickins 2009-09-21 1004 9ba6929480088a Hugh Dickins 2009-09-21 1005 free_mm_slot(mm_slot); 9ba6929480088a Hugh Dickins 2009-09-21 1006 clear_bit(MMF_VM_MERGEABLE, >flags); 9ba6929480088a Hugh Dickins 2009-09-21 1007 mmdrop(mm); 7496fea9a6bf64 Zhou Chengming2016-05-12 1008 } else d952b79136a6c3 Hugh Dickins 2009-09-21 1009 spin_unlock(_mmlist_lock); 31dbd01f314364 Izik Eidus2009-09-21 1010 } 31dbd01f314364 Izik Eidus2009-09-21 1011 cbf86cfe04a664 Hugh Dickins 2013-02-22 1012 /* Clean up stable nodes, but don't worry if some
[PATCH v4 2/2] iommu: add Unisoc IOMMU basic driver
From: Chunyan Zhang This IOMMU module can be used by Unisoc's multimedia devices, such as display, Image codec(jpeg) and a few signal processors, including VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc. Signed-off-by: Chunyan Zhang --- drivers/iommu/Kconfig | 12 + drivers/iommu/Makefile | 1 + drivers/iommu/sprd-iommu.c | 599 + 3 files changed, 612 insertions(+) create mode 100644 drivers/iommu/sprd-iommu.c diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 192ef8f61310..2ef0b3918440 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -408,4 +408,16 @@ config VIRTIO_IOMMU Say Y here if you intend to run this kernel as a guest. +config SPRD_IOMMU + tristate "Unisoc IOMMU Support" + depends on ARCH_SPRD || COMPILE_TEST + select IOMMU_API + help + Support for IOMMU on Unisoc's SoCs, this IOMMU can be used by + Unisoc's multimedia devices, such as display, Image codec(jpeg) + and a few signal processors, including VSP(video), GSP(graphic), + ISP(image), and CPP(camera pixel processor), etc. + + Say Y here if you want to use the multimedia devices listed above. + endif # IOMMU_SUPPORT diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 61bd30cd8369..5925b6af2123 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -28,3 +28,4 @@ obj-$(CONFIG_S390_IOMMU) += s390-iommu.o obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o obj-$(CONFIG_IOMMU_SVA_LIB) += iommu-sva-lib.o +obj-$(CONFIG_SPRD_IOMMU) += sprd-iommu.o diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c new file mode 100644 index ..022fe62027c0 --- /dev/null +++ b/drivers/iommu/sprd-iommu.c @@ -0,0 +1,599 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Unisoc IOMMU driver + * + * Copyright (C) 2020 Unisoc, Inc. + * Author: Chunyan Zhang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define SPRD_IOMMU_PAGE_SHIFT 12 +#define SPRD_IOMMU_PAGE_SIZE SZ_4K + +#define SPRD_EX_CFG0x0 +#define SPRD_IOMMU_VAOR_BYPASS BIT(4) +#define SPRD_IOMMU_GATE_EN BIT(1) +#define SPRD_IOMMU_EN BIT(0) +#define SPRD_EX_UPDATE 0x4 +#define SPRD_EX_FIRST_VPN 0x8 +#define SPRD_EX_VPN_RANGE 0xc +#define SPRD_EX_FIRST_PPN 0x10 +#define SPRD_EX_DEFAULT_PPN0x14 + +#define SPRD_IOMMU_VERSION 0x0 +#define SPRD_VERSION_MASK GENMASK(15, 8) +#define SPRD_VERSION_SHIFT 0x8 +#define SPRD_VAU_CFG 0x4 +#define SPRD_VAU_UPDATE0x8 +#define SPRD_VAU_AUTH_CFG 0xc +#define SPRD_VAU_FIRST_PPN 0x10 +#define SPRD_VAU_DEFAULT_PPN_RD0x14 +#define SPRD_VAU_DEFAULT_PPN_WR0x18 +#define SPRD_VAU_FIRST_VPN 0x1c +#define SPRD_VAU_VPN_RANGE 0x20 + +enum sprd_iommu_version { + SPRD_IOMMU_EX, + SPRD_IOMMU_VAU, +}; + +/* + * struct sprd_iommu_device - high-level sprd IOMMU device representation, + * including hardware information and configuration, also driver data, etc + * + * @ver: sprd IOMMU IP version + * @prot_page_va: protect page base virtual address + * @prot_page_pa: protect page base physical address, data would be + * written to here while translation fault + * @base: mapped base address for accessing registers + * @reg_offset: some IOMMU shares the same range of registers with the multimedia + * device which use it, this represents the IOMMU register offset + * @dev: pointer to basic device structure + * @iommu: IOMMU core representation + * @group: IOMMU group + * @eb: gate clock which controls IOMMU access + */ +struct sprd_iommu_device { + enum sprd_iommu_version ver; + u32 *prot_page_va; + dma_addr_t prot_page_pa; + struct regmap *base; + unsigned intreg_offset; + struct device *dev; + struct iommu_device iommu; + struct iommu_group *group; + struct clk *eb; +}; + +struct sprd_iommu_domain { + spinlock_t pgtlock; /* lock for page table */ + struct iommu_domain domain; + u32 *pgt_va; /* page table virtual address base */ + dma_addr_t pgt_pa; /* page table physical address base */ + struct sprd_iommu_device*sdev; +}; + +static const struct iommu_ops sprd_iommu_ops; + +static struct sprd_iommu_domain *to_sprd_domain(struct iommu_domain *dom) +{ + return container_of(dom, struct sprd_iommu_domain, domain); +} + +static inline void +sprd_iommu_write(struct sprd_iommu_device *sdev, unsigned int reg, u32 val) +{ + regmap_write(sdev->base, sdev->reg_offset + reg, val); +} + +static inline u32 +sprd_iommu_read(struct
Re: [PATCH 03/14] cxl/mem: Find device capabilities
On Wed, Feb 03, 2021 at 01:23:31PM -0800, Dan Williams wrote: > > I'd prefer to keep the helpers for now as I do find them helpful, and so far > > nobody else who has touched the code has complained. If you feel strongly, I > > will change it. > > After seeing the options, I think I'd prefer to not have to worry what > extra magic is happening with cxl_read_mbox_reg32() > > cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CAPS_OFFSET); > > readl(cxlm->mbox_regs + CXLDEV_MB_CAPS_OFFSET); > > The latter is both shorter and more idiomatic. Same here. That being said I know some driver maintainers like wrappers, my real main irk was the macro magic to generate them.
Re: [PATCH] platform/chrome: cros_ec_typec: Decouple partner removal
Hi Prashant, On Tue, 2 Feb 2021 14:40:01 -0800, Prashant Malani wrote: > Currently, we return if there is no partner present when > !PD_CTRL_RESP_ENABLED_CONNECTED, without proceeding further. This ties > partner removal to cable removal, whereas the two should be independent. > > Update the check to remove a partner if one was registered, but continue > after that instead of returning. Applied to for-kernelci, thanks! [1/1] platform/chrome: cros_ec_typec: Decouple partner removal commit: d9f12f9e6c3695c32e681e9d266c4dc1c9016f66 Best regards, -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[PATCH v4 1/2] dt-bindings: iommu: add bindings for sprd IOMMU
From: Chunyan Zhang This IOMMU module can be used by Unisoc's multimedia devices, such as display, Image codec(jpeg) and a few signal processors, including VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc. Signed-off-by: Chunyan Zhang --- .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml new file mode 100644 index ..36abd2187a19 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2020 Unisoc Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Unisoc IOMMU and Multi-media MMU + +maintainers: + - Chunyan Zhang + +properties: + compatible: +enum: + - sprd,iommu-v1 + + "#iommu-cells": +const: 0 +description: + Unisoc IOMMUs are all single-master IOMMU devices, therefore no + additional information needs to associate with its master device. + Please refer to the generic bindings document for more details, + Documentation/devicetree/bindings/iommu/iommu.txt + + reg: +maxItems: 1 +description: + Not required if 'sprd,iommu-regs' is defined. + + clocks: +description: + Reference to a gate clock phandle, since access to some of IOMMUs are + controlled by gate clock, but this is not required. + + sprd,iommu-regs: +$ref: /schemas/types.yaml#/definitions/phandle-array +description: + Reference to a syscon phandle plus 1 cell, the syscon defines the + register range used by IOMMU and multimedia device, the cell + defines the offset for IOMMU registers. Since IOMMU module shares + the same register range with the multimedia device which uses it. + +required: + - compatible + - "#iommu-cells" + +oneOf: + - required: + - reg + - required: + - sprd,iommu-regs + +additionalProperties: false + +examples: + - | +iommu_disp: iommu-disp { + compatible = "sprd,iommu-v1"; + sprd,iommu-regs = <_regs 0x800>; + #iommu-cells = <0>; +}; + + - | +iommu_jpg: iommu-jpg { + compatible = "sprd,iommu-v1"; + sprd,iommu-regs = <_regs 0x300>; + #iommu-cells = <0>; + clocks = <_gate 1>; +}; + +... -- 2.25.1
[PATCH v4 0/2] Add Unisoc IOMMU basic driver
From: Chunyan Zhang Changes since v3: * Rebased on iommu/next, and fixed compile error reported by kernel test robot ; * %s/iommu/IOMMU/ properly in the whole patchset. Changes since v2: * Added a WARN and return 0 if an invalid iova was passed to sprd_iommu_iova_to_phys(); * Changed the name of sprd_iommu_write(); * Revised CONFIG_SPRD_IOMMU help graph in Kconfig. * Revised comments for the struct sprd_iommu_device; * Converted to use "GPL" instread of "GPL v2", they are same as license-rules.rst shows. Changes since v1: * Fixed compile errors reported by kernel test robot . * Changed to use syscon to get mapped registers for iommu and media devices to avoid double map issue. * Addressed Robin's comments: - Added including offset in the returned physical address if the input virtual address isn't page-aligned; - Added platform_device_put() after calling of_find_device_by_node(); - Removed iommu register offset from driver, it will be defined as the cell of DT reference to syscon phandle; - Removed multi compatible strings which are not needed; - Added comments for the function sprd_iommu_clk_enable(); - Added clocks property in bindings; - Set device_driver.suppress_bind_attrs to disable unbind the devices via sysfs; - A few trivial fixes. Changes since RFC v2: * Addressed Robin's comments: - Add COMPILE_TEST support; - Use DMA allocator for PTE; - Revised to avoid resource leak issue; - Added ->iotlb_sync implemented; - Moved iommu group allocation to probe; - Changed some function names to make them sprd specific; * Added support for more iommu instance; Changes since RFC v1: * Rebased on v5.11-rc1; * Changed sprd-iommu to tristate; * Removed check for args_count of iommu OF node, since there's no args for sprd-iommu device node; * Added another IP version (i.e. vau); * Removed unnecessary configs selection from CONFIG_SPRD_IOMMU; * Changed to get zeroed pages. Chunyan Zhang (2): dt-bindings: iommu: add bindings for sprd IOMMU iommu: add Unisoc IOMMU basic driver .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++ drivers/iommu/Kconfig | 12 + drivers/iommu/Makefile| 1 + drivers/iommu/sprd-iommu.c| 599 ++ 4 files changed, 684 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml create mode 100644 drivers/iommu/sprd-iommu.c -- 2.25.1
[next] Unable to handle kernel NULL pointer dereference at - pc : gpiodevice_release
While running kselftest gpio mockup test case on qualcomm dragonboard 410c the following kernel crash reported on Linux next tag 20210203. # selftests: gpio: gpio-mockup.sh # 1. Module load tests # 1.1. dynamic allocation of gpio # ./gpio-mockup.sh: line 106: ./gpio-mockup-cdev: No such file or directory # test failed: line value is 127 when 1 was expected # GPIO gpio-mockup test FAIL [ 124.539778] Unable to handle kernel NULL pointer dereference at virtual address 05a8 [ 124.539864] Mem abort info: [ 124.547998] ESR = 0x9606 [ 124.550188] EC = 0x25: DABT (current EL), IL = 32 bits [ 124.553473] SET = 0, FnV = 0 [ 124.558926] EA = 0, S1PTW = 0 [ 124.561646] Data abort info: [ 124.564863] ISV = 0, ISS = 0x0006 [ 124.567933] CM = 0, WnR = 0 [ 124.571507] user pgtable: 4k pages, 48-bit VAs, pgdp=8b721000 [ 124.574694] [05a8] pgd=91cd2003, p4d=91cd2003, pud=917ac003, pmd= [ 124.581396] Internal error: Oops: 9606 [#1] PREEMPT SMP [ 124.591499] Modules linked in: gpio_mockup(-) snd_soc_hdmi_codec adv7511 cec rfkill snd_soc_msm8916_analog qcom_spmi_temp_alarm qcom_pon rtc_pm8xxx msm snd_soc_lpass_apq8016 snd_soc_lpass_cpu snd_soc_lpass_platform snd_soc_msm8916_digital qcom_camss videobuf2_dma_sg snd_soc_apq8016_sbc v4l2_fwnode snd_soc_qcom_common videobuf2_memops videobuf2_v4l2 mdt_loader videobuf2_common drm_kms_helper qnoc_msm8916 qcom_rng i2c_qcom_cci icc_smd_rpm crct10dif_ce socinfo rmtfs_mem display_connector drm qrtr ns fuse [ 124.619092] CPU: 0 PID: 5055 Comm: modprobe Not tainted 5.11.0-rc6-next-20210203 #1 [ 124.641324] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 124.648877] pstate: 8005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 124.655819] pc : gpiodevice_release+0x38/0x80 [ 124.661806] lr : device_release+0x3c/0x98 [ 124.666058] sp : 800013f23b30 [ 124.670051] x29: 800013f23b30 x28: 157baf80 [ 124.673351] x27: x26: [ 124.678734] x25: 0045 x24: 0b5d6cd0 [ 124.684029] x23: 800013f23c88 x22: [ 124.689324] x21: 0fb5f080 x20: 02334e00 [ 124.694619] x19: x18: 800012dd6a50 [ 124.699914] x17: x16: [ 124.705210] x15: 000694e0 x14: [ 124.710512] x13: 0001 x12: e107 [ 124.715799] x11: e10a x10: 800012d34a50 [ 124.721096] x9 : 80001344a000 x8 : 512c1926 [ 124.726391] x7 : 0cb44760 x6 : 800013f23a40 [ 124.731685] x5 : dead0100 x4 : dead0122 [ 124.736981] x3 : 800012891000 x2 : 2be62a0e7519e400 [ 124.742275] x1 : 800010829ad0 x0 : 800012a694e0 [ 124.747571] Call trace: [ 124.752862] gpiodevice_release+0x38/0x80 [ 124.755035] device_release+0x3c/0x98 [ 124.759201] kobject_put+0x90/0x220 [ 124.762846] put_device+0x24/0x30 [ 124.766145] gpiochip_remove+0xf4/0x120 [ 124.769618] devm_gpio_chip_release+0x20/0x30 [ 124.773263] devm_action_release+0x20/0x30 [ 124.77] release_nodes+0x150/0x248 [ 124.781771] devres_release_all+0x3c/0x60 [ 124.785503] device_release_driver_internal+0x128/0x1f0 [ 124.789584] driver_detach+0x5c/0xe8 [ 124.794618] bus_remove_driver+0x64/0x118 [ 124.798439] driver_unregister+0x34/0x60 [ 124.802344] platform_driver_unregister+0x20/0x30 [ 124.806339] gpio_mockup_exit+0x30/0x3d0 [gpio_mockup] [ 124.810939] __arm64_sys_delete_module+0x1c8/0x2b8 [ 124.815973] el0_svc_common+0x88/0x1b8 [ 124.820745] do_el0_svc+0x38/0x90 [ 124.824478] el0_svc+0x1c/0x28 [ 124.827864] el0_sync_handler+0x8c/0xb0 [ 124.830815] el0_sync+0x13c/0x140 [ 124.834555] Code: f2fbd5a4 90011200 91124000 91014000 (f942d663) [ 124.838029] ---[ end trace 15e9a0840604e538 ]--- Reported-by: Naresh Kamboju full test log link, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20210203/testrun/3878290/suite/linux-log-parser/test/check-kernel-oops-2224485/log metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git describe: next-20210203 kernel-config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-next/952/config build: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-next/952/ vmlinux: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-next/952/vmlinux -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 1/3] kunit: add kunit.filter_glob cmdline option to filter suites
Hi Daniel, url: https://github.com/0day-ci/linux/commits/Daniel-Latypov/kunit-support-running-subsets-of-test-suites-from/20210204-074405 base: 88bb507a74ea7d75fa49edd421eaa710a7d80598 config: x86_64-randconfig-m001-20210202 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot Reported-by: Dan Carpenter smatch warnings: lib/kunit/executor.c:110 kunit_run_all_tests() error: double free of 'suite_set.start' vim +110 lib/kunit/executor.c 8c0d884986ba22 Brendan Higgins 2020-08-04 96 int kunit_run_all_tests(void) aac35468ca20a3 Alan Maguire2020-08-04 97 { aac35468ca20a3 Alan Maguire2020-08-04 98 struct kunit_suite * const * const *suites; aac35468ca20a3 Alan Maguire2020-08-04 99 d5554dd78a454b Daniel Latypov 2021-02-03 100 struct suite_set suite_set = kunit_filter_suites(); 45dcbb6f5ef78b Brendan Higgins 2020-08-04 101 d5554dd78a454b Daniel Latypov 2021-02-03 102 kunit_print_tap_header(_set); d5554dd78a454b Daniel Latypov 2021-02-03 103 d5554dd78a454b Daniel Latypov 2021-02-03 104 for (suites = suite_set.start; suites < suite_set.end; suites++) aac35468ca20a3 Alan Maguire2020-08-04 105 __kunit_test_suites_init(*suites); aac35468ca20a3 Alan Maguire2020-08-04 106 d5554dd78a454b Daniel Latypov 2021-02-03 107 if (filter_glob) { /* a copy was made of each array */ d5554dd78a454b Daniel Latypov 2021-02-03 108 for (suites = suite_set.start; suites < suite_set.end; suites++) This will free "suite_set.start" will in the first iteration through the loop d5554dd78a454b Daniel Latypov 2021-02-03 109 kfree(suites); d5554dd78a454b Daniel Latypov 2021-02-03 @110 kfree(suite_set.start); ^^^ and then double free it. d5554dd78a454b Daniel Latypov 2021-02-03 111 } d5554dd78a454b Daniel Latypov 2021-02-03 112 aac35468ca20a3 Alan Maguire2020-08-04 113 return 0; aac35468ca20a3 Alan Maguire2020-08-04 114 } --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] crypto: cavium: remove casting dma_alloc_coherent
Remove casting the values returned by dma_alloc_coherent. Signed-off-by: Xu Wang --- drivers/crypto/cavium/cpt/cptvf_main.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c b/drivers/crypto/cavium/cpt/cptvf_main.c index f016448e43bb..112b12a32542 100644 --- a/drivers/crypto/cavium/cpt/cptvf_main.c +++ b/drivers/crypto/cavium/cpt/cptvf_main.c @@ -233,10 +233,10 @@ static int alloc_command_queues(struct cpt_vf *cptvf, c_size = (rem_q_size > qcsize_bytes) ? qcsize_bytes : rem_q_size; - curr->head = (u8 *)dma_alloc_coherent(>dev, - c_size + CPT_NEXT_CHUNK_PTR_SIZE, - >dma_addr, - GFP_KERNEL); + curr->head = dma_alloc_coherent(>dev, + c_size + CPT_NEXT_CHUNK_PTR_SIZE, + >dma_addr, + GFP_KERNEL); if (!curr->head) { dev_err(>dev, "Command Q (%d) chunk (%d) allocation failed\n", i, queue->nchunks); -- 2.17.1
Re: [PATCH v15 04/14] KVM: x86: Add #CP support in guest exception dispatch
On Wed, Feb 03, 2021 at 01:46:42PM -0800, Sean Christopherson wrote: > On Wed, Feb 03, 2021, Yang Weijiang wrote: > > Add handling for Control Protection (#CP) exceptions, vector 21, used > > and introduced by Intel's Control-Flow Enforcement Technology (CET). > > relevant CET violation case. See Intel's SDM for details. > > > > Signed-off-by: Yang Weijiang > > --- > > arch/x86/include/uapi/asm/kvm.h | 1 + > > arch/x86/kvm/x86.c | 1 + > > arch/x86/kvm/x86.h | 2 +- > > 3 files changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/include/uapi/asm/kvm.h > > b/arch/x86/include/uapi/asm/kvm.h > > index 8e76d3701db3..507263d1d0b2 100644 > > --- a/arch/x86/include/uapi/asm/kvm.h > > +++ b/arch/x86/include/uapi/asm/kvm.h > > @@ -32,6 +32,7 @@ > > #define MC_VECTOR 18 > > #define XM_VECTOR 19 > > #define VE_VECTOR 20 > > +#define CP_VECTOR 21 > > > > /* Select x86 specific features in */ > > #define __KVM_HAVE_PIT > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 99f787152d12..d9d3bae40a8c 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -436,6 +436,7 @@ static int exception_class(int vector) > > case NP_VECTOR: > > case SS_VECTOR: > > case GP_VECTOR: > > + case CP_VECTOR: > > return EXCPT_CONTRIBUTORY; > > default: > > break; > > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h > > index c5ee0f5ce0f1..bdbd0b023ecc 100644 > > --- a/arch/x86/kvm/x86.h > > +++ b/arch/x86/kvm/x86.h > > @@ -116,7 +116,7 @@ static inline bool > > x86_exception_has_error_code(unsigned int vector) > > { > > static u32 exception_has_error_code = BIT(DF_VECTOR) | BIT(TS_VECTOR) | > > BIT(NP_VECTOR) | BIT(SS_VECTOR) | BIT(GP_VECTOR) | > > - BIT(PF_VECTOR) | BIT(AC_VECTOR); > > + BIT(PF_VECTOR) | BIT(AC_VECTOR) | BIT(CP_VECTOR); > > These need to be conditional on CET being exposed to the guest. TBD > exceptions > are non-contributory and don't have an error code. Found when running unit > tests in L1 with a kvm/queue as L1, but an older L0. cr4_guest_rsvd_bits can > be > used to avoid guest_cpuid_has() lookups. > > The SDM also gets this wrong. Section 26.2.1.3, VM-Entry Control Fields, > needs > to be updated to add #CP to the list. > > — The field's deliver-error-code bit (bit 11) is 1 if each of the following > holds: (1) the interruption type is hardware exception; (2) bit 0 > (corresponding to CR0.PE) is set in the CR0 field in the guest-state area; > (3) IA32_VMX_BASIC[56] is read as 0 (see Appendix A.1); and (4) the vector > indicates one of the following exceptions: #DF (vector 8), #TS (10), > #NP (11), #SS (12), #GP (13), #PF (14), or #AC (17). > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > index dbca1687ae8e..0b6dab6915a3 100644 > --- a/arch/x86/kvm/vmx/nested.c > +++ b/arch/x86/kvm/vmx/nested.c > @@ -2811,7 +2811,7 @@ static int nested_check_vm_entry_controls(struct > kvm_vcpu *vcpu, > /* VM-entry interruption-info field: deliver error code */ > should_have_error_code = > intr_type == INTR_TYPE_HARD_EXCEPTION && prot_mode && > - x86_exception_has_error_code(vector); > + x86_exception_has_error_code(vcpu, vector); > if (CC(has_error_code != should_have_error_code)) > return -EINVAL; > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 28fea7ff7a86..0288d6a364bd 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -437,17 +437,20 @@ EXPORT_SYMBOL_GPL(kvm_spurious_fault); > #define EXCPT_CONTRIBUTORY 1 > #define EXCPT_PF 2 > > -static int exception_class(int vector) > +static int exception_class(struct kvm_vcpu *vcpu, int vector) > { > switch (vector) { > case PF_VECTOR: > return EXCPT_PF; > + case CP_VECTOR: > + if (vcpu->arch.cr4_guest_rsvd_bits & X86_CR4_CET) > + return EXCPT_BENIGN; > + return EXCPT_CONTRIBUTORY; > case DE_VECTOR: > case TS_VECTOR: > case NP_VECTOR: > case SS_VECTOR: > case GP_VECTOR: > - case CP_VECTOR: > return EXCPT_CONTRIBUTORY; > default: > break; > @@ -588,8 +591,8 @@ static void kvm_multiple_exception(struct kvm_vcpu *vcpu, > kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu); > return; > } > - class1 = exception_class(prev_nr); > - class2 = exception_class(nr); > + class1 = exception_class(vcpu, prev_nr); > + class2 = exception_class(vcpu, nr); > if ((class1 == EXCPT_CONTRIBUTORY && class2 == EXCPT_CONTRIBUTORY) > || (class1 == EXCPT_PF && class2 != EXCPT_BENIGN)) { > /* > diff --git
[PATCH] mmc: cavium: Replace spin_lock_irqsave with spin_lock in hard IRQ
It is redundant to do irqsave and irqrestore in hardIRQ context, where it has been in a irq-disabled context. Signed-off-by: Xiaofei Tan --- drivers/mmc/host/cavium.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c index c5da3aa..4bb8f28 100644 --- a/drivers/mmc/host/cavium.c +++ b/drivers/mmc/host/cavium.c @@ -436,12 +436,11 @@ irqreturn_t cvm_mmc_interrupt(int irq, void *dev_id) { struct cvm_mmc_host *host = dev_id; struct mmc_request *req; - unsigned long flags = 0; u64 emm_int, rsp_sts; bool host_done; if (host->need_irq_handler_lock) - spin_lock_irqsave(>irq_handler_lock, flags); + spin_lock(>irq_handler_lock); else __acquire(>irq_handler_lock); @@ -504,7 +503,7 @@ irqreturn_t cvm_mmc_interrupt(int irq, void *dev_id) host->release_bus(host); out: if (host->need_irq_handler_lock) - spin_unlock_irqrestore(>irq_handler_lock, flags); + spin_unlock(>irq_handler_lock); else __release(>irq_handler_lock); return IRQ_RETVAL(emm_int != 0); -- 2.8.1
[PATCH v4 2/2] nbd: share exception handling code by goto put_nbd
Replace the following two statements by the statement “goto put_nbd;” nbd_put(nbd); return 0; Signed-off-by: Sun Ke --- drivers/block/nbd.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index 3c9b3bf3f4c2..ecae81e43122 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -2029,12 +2029,11 @@ static int nbd_genl_disconnect(struct sk_buff *skb, struct genl_info *info) } mutex_unlock(>config_lock); mutex_unlock(_index_mutex); - if (!refcount_inc_not_zero(>config_refs)) { - nbd_put(nbd); - return 0; - } + if (!refcount_inc_not_zero(>config_refs)) + goto put_nbd; nbd_disconnect_and_put(nbd); nbd_config_put(nbd); +put_nbd: nbd_put(nbd); return 0; } -- 2.25.4
[PATCH v4 1/2] nbd: Fix NULL pointer in flush_workqueue
Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d [ 656.378934] RSP: 0018:c95eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: RBX: RCX: [ 656.379915] RDX: 888104cf2600 RSI: aae8f452 RDI: 0020 [ 656.380473] RBP: 0020 R08: R09: 88813bd6b318 [ 656.381039] R10: 00c7 R11: fefefefefefefeff R12: 888102710b40 [ 656.381599] R13: c95eb9e0 R14: b2930680 R15: 88810770ef00 [ 656.382166] FS: 7fdf117ebb40() GS:88813bd4() knlGS: [ 656.382806] CS: 0010 DS: ES: CR0: 80050033 [ 656.383261] CR2: 0020 CR3: 000100c84000 CR4: 06e0 [ 656.383819] DR0: DR1: DR2: [ 656.384370] DR3: DR6: fffe0ff0 DR7: 0400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 656.388162] netlink_sendmsg+0x398/0x6c0 [ 656.388451] ? netlink_rcv_skb+0x180/0x180 [ 656.388750] sys_sendmsg+0x1da/0x320 [ 656.389038] ? sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [ 656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs") Signed-off-by: Sun Ke --- v4: Share exception handling code for if branches v3: Do not use unlock and add put_nbd. v2: Use jump target unlock. --- drivers/block/nbd.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index e6ea5d344f87..3c9b3bf3f4c2 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -2014,17 +2014,20 @@ static int nbd_genl_disconnect(struct sk_buff *skb, struct genl_info *info) mutex_lock(_index_mutex); nbd = idr_find(_index_idr, index); if (!nbd) { - mutex_unlock(_index_mutex); printk(KERN_ERR "nbd: couldn't find device at index %d\n", index); - return -EINVAL; + goto unlock_index; } - if (!refcount_inc_not_zero(>refs)) { - mutex_unlock(_index_mutex); + mutex_lock(>config_lock); + if (!refcount_inc_not_zero(>refs) || !nbd->recv_workq) { + mutex_unlock(>config_lock); printk(KERN_ERR "nbd: device at index %d is going down\n", index); +unlock_index: + mutex_unlock(_index_mutex); return -EINVAL; } + mutex_unlock(>config_lock); mutex_unlock(_index_mutex); if (!refcount_inc_not_zero(>config_refs)) { nbd_put(nbd); -- 2.25.4
[PATCH v4 0/2] fix a NULL pointer bug and simplify the code
v4: Share exception handling code for if branches and move put_nbd adjustment to a separate patch. v3: Do not use unlock and add put_nbd. v2: Use jump target unlock. Sun Ke (2): nbd: Fix NULL pointer in flush_workqueue nbd: share exception handling code by goto put_nbd drivers/block/nbd.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) -- 2.25.4
Re: [PATCH v5 3/3] PM / devfreq: Add required OPPs support to passive governor
On Thu, Feb 4, 2021 at 10:49 AM Viresh Kumar wrote: > > On 03-02-21, 17:24, Hsin-Yi Wang wrote: > > From: Saravana Kannan > > > > Look at the required OPPs of the "parent" device to determine the OPP that > > is required from the slave device managed by the passive governor. This > > allows having mappings between a parent device and a slave device even when > > they don't have the same number of OPPs. > > > > Signed-off-by: Saravana Kannan > > Acked-by: MyungJoo Ham > > Acked-by: Chanwoo Choi > > Signed-off-by: Hsin-Yi Wang > > --- > > drivers/devfreq/governor_passive.c | 20 +++- > > 1 file changed, 15 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/devfreq/governor_passive.c > > b/drivers/devfreq/governor_passive.c > > index 63332e4a65ae8..8d92b1964f9c3 100644 > > --- a/drivers/devfreq/governor_passive.c > > +++ b/drivers/devfreq/governor_passive.c > > @@ -19,7 +19,7 @@ static int devfreq_passive_get_target_freq(struct devfreq > > *devfreq, > > = (struct devfreq_passive_data *)devfreq->data; > > struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent; > > unsigned long child_freq = ULONG_MAX; > > - struct dev_pm_opp *opp; > > + struct dev_pm_opp *opp = NULL, *p_opp = NULL; > > I would initialize p_opp to ERR_PTR(-ENODEV) to avoid using > IS_ERR_OR_NULL. There is no need to initialize opp as well. > > > int i, count, ret = 0; > > > > /* > > @@ -56,13 +56,20 @@ static int devfreq_passive_get_target_freq(struct > > devfreq *devfreq, > >* list of parent device. Because in this case, *freq is temporary > >* value which is decided by ondemand governor. > >*/ > > - opp = devfreq_recommended_opp(parent_devfreq->dev.parent, freq, 0); > > - if (IS_ERR(opp)) { > > - ret = PTR_ERR(opp); > > + p_opp = devfreq_recommended_opp(parent_devfreq->dev.parent, freq, 0); > > + if (IS_ERR(p_opp)) { > > + ret = PTR_ERR(p_opp); > > goto out; > > Perhaps just return from here, the goto is useless here. > > > } > > > > - dev_pm_opp_put(opp); > > + if (devfreq->opp_table && parent_devfreq->opp_table) > > + opp = dev_pm_opp_xlate_required_opp(parent_devfreq->opp_table, > > + devfreq->opp_table, > > p_opp); > > + if (opp) { > > This needs to be part of the above if block itself, else the opp will > always be NULL, isn't it ? > > > + *freq = dev_pm_opp_get_freq(opp); > > + dev_pm_opp_put(opp); > > + goto out; > > + } > > > > /* > >* Get the OPP table's index of decided freqeuncy by governor > > @@ -89,6 +96,9 @@ static int devfreq_passive_get_target_freq(struct devfreq > > *devfreq, > > *freq = child_freq; > > > > out: > > + if (!IS_ERR_OR_NULL(opp)) > > you should be checking for p_opp here, isn't it ? And perhaps we don't > need this check as well as p_opp can't be invalid here. > > > + dev_pm_opp_put(p_opp); > > + > > return ret; > > } > > > > -- > > 2.30.0.365.g02bc693789-goog > Thanks for the review. I'll fix them and send next version > -- > viresh
Re: [PATCH 1/2] dt-bindings: phy: qcom,qmp: Add SC8180X USB phy
On 20-01-21, 17:43, Bjorn Andersson wrote: > Add compatibles for the Qualcomm QMP PHY binding for the SuperSpeed USB > phys found in the SC8180x platform. Applied, thanks -- ~Vinod
Re: [PATCH 1/2] dt-bindings: phy: qcom,qmp: Add SC8180X UFS to the QMP binding
On 20-01-21, 14:45, Bjorn Andersson wrote: > Add compatible for the SC8180x UFS PHY to the QMP binding. Applied, thanks -- ~Vinod
Re: [PATCH] vdpa/mlx5: Restore the hardware used index after change map
On Wed, Feb 03, 2021 at 12:33:26PM -0800, Si-Wei Liu wrote: > On Tue, Feb 2, 2021 at 10:48 PM Eli Cohen wrote: > > > > On Tue, Feb 02, 2021 at 09:14:02AM -0800, Si-Wei Liu wrote: > > > On Tue, Feb 2, 2021 at 6:34 AM Eli Cohen wrote: > > > > > > > > When a change of memory map occurs, the hardware resources are destroyed > > > > and then re-created again with the new memory map. In such case, we need > > > > to restore the hardware available and used indices. The driver failed to > > > > restore the used index which is added here. > > > > > > > > Fixes 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 > > > > devices") > > > > Signed-off-by: Eli Cohen > > > > --- > > > > This patch is being sent again a single patch the fixes hot memory > > > > addtion to a qemy process. > > > > > > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +++ > > > > 1 file changed, 7 insertions(+) > > > > > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c > > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c > > > > index 88dde3455bfd..839f57c64a6f 100644 > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c > > > > @@ -87,6 +87,7 @@ struct mlx5_vq_restore_info { > > > > u64 device_addr; > > > > u64 driver_addr; > > > > u16 avail_index; > > > > + u16 used_index; > > > > bool ready; > > > > struct vdpa_callback cb; > > > > bool restore; > > > > @@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue { > > > > u32 virtq_id; > > > > struct mlx5_vdpa_net *ndev; > > > > u16 avail_idx; > > > > + u16 used_idx; > > > > int fw_state; > > > > > > > > /* keep last in the struct */ > > > > @@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net > > > > *ndev, struct mlx5_vdpa_virtque > > > > > > > > obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in, > > > > obj_context); > > > > MLX5_SET(virtio_net_q_object, obj_context, hw_available_index, > > > > mvq->avail_idx); > > > > + MLX5_SET(virtio_net_q_object, obj_context, hw_used_index, > > > > mvq->used_idx); > > > > > > The saved indexes will apply to the new virtqueue object whenever it > > > is created. In virtio spec, these indexes will reset back to zero when > > > the virtio device is reset. But I don't see how it's done today. IOW, > > > I don't see where avail_idx and used_idx get cleared from the mvq for > > > device reset via set_status(). > > > > > > > Right, but this is not strictly related to this patch. I will post > > another patch to fix this. > > Better to post these two patches in a series.Or else it may cause VM > reboot problem as that is where the device gets reset. The avail_index > did not as the correct value will be written to by driver right after, > but used_idx introduced by this patch is supplied by device hence this > patch alone would introduce regression. > OK, will do. > > > > BTW, can you describe a secnario that would cause a reset (through > > calling set_status()) that happens after the VQ has been used? > > You can try reboot the guest, that'll be the easy way to test. > Thanks! > -Siwei > > > > > > -Siwei > > > > > > > > > > MLX5_SET(virtio_net_q_object, obj_context, > > > > queue_feature_bit_mask_12_3, > > > > get_features_12_3(ndev->mvdev.actual_features)); > > > > vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context, > > > > virtio_q_context); > > > > @@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net > > > > *ndev, struct mlx5_vdpa_virtqueue *m > > > > struct mlx5_virtq_attr { > > > > u8 state; > > > > u16 available_index; > > > > + u16 used_index; > > > > }; > > > > > > > > static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct > > > > mlx5_vdpa_virtqueue *mvq, > > > > @@ -1052,6 +1056,7 @@ static int query_virtqueue(struct mlx5_vdpa_net > > > > *ndev, struct mlx5_vdpa_virtqueu > > > > memset(attr, 0, sizeof(*attr)); > > > > attr->state = MLX5_GET(virtio_net_q_object, obj_context, state); > > > > attr->available_index = MLX5_GET(virtio_net_q_object, > > > > obj_context, hw_available_index); > > > > + attr->used_index = MLX5_GET(virtio_net_q_object, obj_context, > > > > hw_used_index); > > > > kfree(out); > > > > return 0; > > > > > > > > @@ -1610,6 +1615,7 @@ static int save_channel_info(struct mlx5_vdpa_net > > > > *ndev, struct mlx5_vdpa_virtqu > > > > return err; > > > > > > > > ri->avail_index = attr.available_index; > > > > + ri->used_index = attr.used_index; > > > > ri->ready = mvq->ready; > > > > ri->num_ent = mvq->num_ent; > > > > ri->desc_addr = mvq->desc_addr; > > > > @@ -1654,6 +1660,7 @@ static void restore_channels_info(struct > > > > mlx5_vdpa_net *ndev) > > > > continue; > > > > > > > > mvq->avail_idx = ri->avail_index;
[PATCH] net: bridge: mcast: Use ERR_CAST instead of ERR_PTR(PTR_ERR())
Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)). net/bridge/br_multicast.c:1246:9-16: WARNING: ERR_CAST can be used with mp Generated by: scripts/coccinelle/api/err_cast.cocci Signed-off-by: Xu Wang --- net/bridge/br_multicast.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c index 257ac4e25f6d..dfbb4dd01fa9 100644 --- a/net/bridge/br_multicast.c +++ b/net/bridge/br_multicast.c @@ -1243,7 +1243,7 @@ __br_multicast_add_group(struct net_bridge *br, mp = br_multicast_new_group(br, group); if (IS_ERR(mp)) - return ERR_PTR(PTR_ERR(mp)); + return ERR_CAST(mp); if (!port) { br_multicast_host_join(mp, true); -- 2.17.1
Re: [PATCH] firewire: convert sysfs sprintf/snprintf family to sysfs_emit
On Thu, 2021-02-04 at 14:50 +0800, Jiapeng Chong wrote: > Fix the following coccicheck warning: > > ./drivers/firewire/core-device.c:375:8-16: WARNING: use scnprintf or > sprintf. [] > diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c [] > @@ -372,8 +372,7 @@ static ssize_t rom_index_show(struct device *dev, > struct fw_device *device = fw_device(dev->parent); > struct fw_unit *unit = fw_unit(dev); > > > - return snprintf(buf, PAGE_SIZE, "%d\n", > - (int)(unit->directory - device->config_rom)); > + return sysfs_emit(buf, "%d\n", (int)(unit->directory - > device->config_rom)); Perhaps this should use the ptrdiff_t qualifier '%td' instead: return sysfs_emit(buf, "%td\n", unit->directory - device->config_rom);
[rcu:willy-maple 164/202] fs/proc/task_mmu.c:941 show_smaps_rollup() error: uninitialized symbol 'vma_start'.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git willy-maple head: 7e346d2845b4bd77663394f39fa70456e0084c86 commit: c4e6b1dfcb6f997eb870e859ab84ca9f39572eab [164/202] fs/proc/task_mmu: Stop using linked list and highest_vm_end config: x86_64-randconfig-m001-20210202 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot Reported-by: Dan Carpenter smatch warnings: fs/proc/task_mmu.c:941 show_smaps_rollup() error: uninitialized symbol 'vma_start'. vim +/vma_start +941 fs/proc/task_mmu.c 258f669e7e88c1 Vlastimil Babka 2018-08-21 839 static int show_smaps_rollup(struct seq_file *m, void *v) 258f669e7e88c1 Vlastimil Babka 2018-08-21 840 { 258f669e7e88c1 Vlastimil Babka 2018-08-21 841struct proc_maps_private *priv = m->private; 258f669e7e88c1 Vlastimil Babka 2018-08-21 842struct mem_size_stats mss; c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 843struct mm_struct *mm = priv->mm; 258f669e7e88c1 Vlastimil Babka 2018-08-21 844struct vm_area_struct *vma; c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 845unsigned long vma_start, last_vma_end = 0; 258f669e7e88c1 Vlastimil Babka 2018-08-21 846int ret = 0; c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 847MA_STATE(mas, >mm_mt, 0, 0); 258f669e7e88c1 Vlastimil Babka 2018-08-21 848 258f669e7e88c1 Vlastimil Babka 2018-08-21 849priv->task = get_proc_task(priv->inode); 258f669e7e88c1 Vlastimil Babka 2018-08-21 850if (!priv->task) 258f669e7e88c1 Vlastimil Babka 2018-08-21 851return -ESRCH; 258f669e7e88c1 Vlastimil Babka 2018-08-21 852 258f669e7e88c1 Vlastimil Babka 2018-08-21 853if (!mm || !mmget_not_zero(mm)) { 258f669e7e88c1 Vlastimil Babka 2018-08-21 854ret = -ESRCH; 258f669e7e88c1 Vlastimil Babka 2018-08-21 855goto out_put_task; 258f669e7e88c1 Vlastimil Babka 2018-08-21 856} 258f669e7e88c1 Vlastimil Babka 2018-08-21 857 258f669e7e88c1 Vlastimil Babka 2018-08-21 858memset(, 0, sizeof(mss)); 258f669e7e88c1 Vlastimil Babka 2018-08-21 859 d8ed45c5dcd455 Michel Lespinasse 2020-06-08 860ret = mmap_read_lock_killable(mm); a26a9781554857 Konstantin Khlebnikov 2019-07-11 861if (ret) a26a9781554857 Konstantin Khlebnikov 2019-07-11 862goto out_put_mm; a26a9781554857 Konstantin Khlebnikov 2019-07-11 863 258f669e7e88c1 Vlastimil Babka 2018-08-21 864 hold_task_mempolicy(priv); c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 865vma = mas_find(, 0); c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 866 c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 867if (vma) c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 868vma_start = vma->vm_start; "vma_start" not initialized on else path. 258f669e7e88c1 Vlastimil Babka 2018-08-21 869 c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 870mas_set(, 0); c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 871mas_for_each(, vma, -1) { 03b4b1149308b0 Chinwen Chang 2020-10-13 872 smap_gather_stats(vma, , 0); 258f669e7e88c1 Vlastimil Babka 2018-08-21 873last_vma_end = vma->vm_end; ff9f47f6f00cfe Chinwen Chang 2020-10-13 874 ff9f47f6f00cfe Chinwen Chang 2020-10-13 875/* ff9f47f6f00cfe Chinwen Chang 2020-10-13 876 * Release mmap_lock temporarily if someone wants to ff9f47f6f00cfe Chinwen Chang 2020-10-13 877 * access it for write request. ff9f47f6f00cfe Chinwen Chang 2020-10-13 878 */ ff9f47f6f00cfe Chinwen Chang 2020-10-13 879if (mmap_lock_is_contended(mm)) { c4e6b1dfcb6f99 Liam R. Howlett 2021-01-04 880 mas_pause(); ff9f47f6f00cfe Chinwen Chang 2020-10-13 881 mmap_read_unlock(mm); ff9f47f6f00cfe Chinwen Chang 2020-10-13 882ret = mmap_read_lock_killable(mm); ff9f47f6f00cfe Chinwen Chang 2020-10-13 883if (ret) { ff9f47f6f00cfe Chinwen Chang 2020-10-13 884 release_task_mempolicy(priv); ff9f47f6f00cfe Chinwen Chang 2020-10-13 885 goto out_put_mm; ff9f47f6f00cfe Chinwen Chang 2020-10-13 886} ff9f47f6f00cfe Chinwen Chang 2020-10-13 887 ff9f47f6f00cfe Chinwen Chang 2020-10-13 888/* ff9f47f6f00cfe Chinwen Chang 2020-10-13 889 * After dropping the lock, there are four cases to ff9f47f6f00cfe Chinwen Chang 2020-10-13 890 * consider. See the following example for explanation. ff9f47f6f00cfe Chinwen Chang 2020-10-13 891
[PATCH] media: atomisp: Remove unneeded return variable
This patch removes unneeded return variables, using only '0' instead. It fixes the following warning detected by coccinelle: ./drivers/staging/media/atomisp/pci/sh_css_mipi.c:39:5-8: Unneeded variable: "err". Return "0" on line 44 Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/staging/media/atomisp/pci/sh_css_mipi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/media/atomisp/pci/sh_css_mipi.c b/drivers/staging/media/atomisp/pci/sh_css_mipi.c index d5ae7f0..de8ee45 100644 --- a/drivers/staging/media/atomisp/pci/sh_css_mipi.c +++ b/drivers/staging/media/atomisp/pci/sh_css_mipi.c @@ -36,12 +36,10 @@ int ia_css_mipi_frame_specify(const unsigned int size_mem_words, const bool contiguous) { - int err = 0; - my_css.size_mem_words = size_mem_words; (void)contiguous; - return err; + return 0; } /* -- 1.8.3.1
[RFC 3/3] dma-contiguous: Type cast MAX_ORDER as unsigned int
Type cast MAX_ORDER as unsigned int to fix the following build warning. In file included from ./include/linux/kernel.h:14, from ./include/asm-generic/bug.h:20, from ./arch/arm64/include/asm/bug.h:26, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./arch/arm64/include/asm/memory.h:166, from ./arch/arm64/include/asm/page.h:42, from kernel/dma/contiguous.c:46: kernel/dma/contiguous.c: In function ‘rmem_cma_setup’: ./include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^~ ./include/linux/minmax.h:32:4: note: in expansion of macro ‘__typecheck’ (__typecheck(x, y) && __no_side_effects(x, y)) ^~~ ./include/linux/minmax.h:42:24: note: in expansion of macro ‘__safe_cmp’ __builtin_choose_expr(__safe_cmp(x, y), \ ^~ ./include/linux/minmax.h:58:19: note: in expansion of macro ‘__careful_cmp’ #define max(x, y) __careful_cmp(x, y, >) ^ kernel/dma/contiguous.c:402:35: note: in expansion of macro ‘max’ phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order); Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Cc: io...@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual --- kernel/dma/contiguous.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index 3d63d91cba5c..1c2782349d71 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -399,7 +399,7 @@ static const struct reserved_mem_ops rmem_cma_ops = { static int __init rmem_cma_setup(struct reserved_mem *rmem) { - phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order); + phys_addr_t align = PAGE_SIZE << max((unsigned int)MAX_ORDER - 1, pageblock_order); phys_addr_t mask = align - 1; unsigned long node = rmem->fdt_node; bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL); -- 2.20.1
[rcu:willy-maple 137/202] mm/mmap.c:1895 mmap_region() error: uninitialized symbol 'next'.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git willy-maple head: 7e346d2845b4bd77663394f39fa70456e0084c86 commit: 059c8a0bb9679195f39e18eaa5b3f548f13e7226 [137/202] mm/mmap: Change mmap_region to use maple tree state config: x86_64-randconfig-m001-20210202 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot Reported-by: Dan Carpenter smatch warnings: mm/mmap.c:1895 mmap_region() error: uninitialized symbol 'next'. vim +/next +1895 mm/mmap.c 0165ab443556bd Miklos Szeredi2007-07-15 1753 unsigned long mmap_region(struct file *file, unsigned long addr, 897ab3e0c49e24 Mike Rapoport 2017-02-24 1754 unsigned long len, vm_flags_t vm_flags, unsigned long pgoff, 897ab3e0c49e24 Mike Rapoport 2017-02-24 1755 struct list_head *uf) 0165ab443556bd Miklos Szeredi2007-07-15 1756 { 0165ab443556bd Miklos Szeredi2007-07-15 1757 struct mm_struct *mm = current->mm; 059c8a0bb96791 Liam R. Howlett 2020-11-10 1758 struct vm_area_struct *vma = NULL; 059c8a0bb96791 Liam R. Howlett 2020-11-10 1759 struct vm_area_struct *prev, *next; 059c8a0bb96791 Liam R. Howlett 2020-11-10 1760 pgoff_t pglen = len >> PAGE_SHIFT; 0165ab443556bd Miklos Szeredi2007-07-15 1761 unsigned long charged = 0; 059c8a0bb96791 Liam R. Howlett 2020-11-10 1762 unsigned long end = addr + len; 059c8a0bb96791 Liam R. Howlett 2020-11-10 1763 unsigned long merge_start = addr, merge_end = end; 059c8a0bb96791 Liam R. Howlett 2020-11-10 1764 pgoff_t vm_pgoff; 059c8a0bb96791 Liam R. Howlett 2020-11-10 1765 int error; 059c8a0bb96791 Liam R. Howlett 2020-11-10 1766 MA_STATE(mas, >mm_mt, addr, end - 1); 0165ab443556bd Miklos Szeredi2007-07-15 1767 e8420a8ece80b3 Cyril Hrubis 2013-04-29 1768 /* Check against address space limit. */ 84638335900f19 Konstantin Khlebnikov 2016-01-14 1769 if (!may_expand_vm(mm, vm_flags, len >> PAGE_SHIFT)) { e8420a8ece80b3 Cyril Hrubis 2013-04-29 1770 unsigned long nr_pages; e8420a8ece80b3 Cyril Hrubis 2013-04-29 1771 e8420a8ece80b3 Cyril Hrubis 2013-04-29 1772 /* e8420a8ece80b3 Cyril Hrubis 2013-04-29 1773* MAP_FIXED may remove pages of mappings that intersects with e8420a8ece80b3 Cyril Hrubis 2013-04-29 1774* requested mapping. Account for the pages it would unmap. e8420a8ece80b3 Cyril Hrubis 2013-04-29 1775*/ 059c8a0bb96791 Liam R. Howlett 2020-11-10 1776 nr_pages = count_vma_pages_range(mm, addr, end); e8420a8ece80b3 Cyril Hrubis 2013-04-29 1777 84638335900f19 Konstantin Khlebnikov 2016-01-14 1778 if (!may_expand_vm(mm, vm_flags, 84638335900f19 Konstantin Khlebnikov 2016-01-14 1779 (len >> PAGE_SHIFT) - nr_pages)) e8420a8ece80b3 Cyril Hrubis 2013-04-29 1780 return -ENOMEM; e8420a8ece80b3 Cyril Hrubis 2013-04-29 1781 } e8420a8ece80b3 Cyril Hrubis 2013-04-29 1782 059c8a0bb96791 Liam R. Howlett 2020-11-10 1783 /* Unmap any existing mapping in the area */ 059c8a0bb96791 Liam R. Howlett 2020-11-10 1784 if (do_munmap(mm, addr, len, uf)) ^1da177e4c3f41 Linus Torvalds2005-04-16 1785 return -ENOMEM; 059c8a0bb96791 Liam R. Howlett 2020-11-10 1786 ^1da177e4c3f41 Linus Torvalds2005-04-16 1787 /* ^1da177e4c3f41 Linus Torvalds2005-04-16 1788* Private writable mapping: check memory availability ^1da177e4c3f41 Linus Torvalds2005-04-16 1789*/ 5a6fe125950676 Mel Gorman2009-02-10 1790 if (accountable_mapping(file, vm_flags)) { ^1da177e4c3f41 Linus Torvalds2005-04-16 1791 charged = len >> PAGE_SHIFT; 191c542442fdf5 Al Viro 2012-02-13 1792 if (security_vm_enough_memory_mm(mm, charged)) ^1da177e4c3f41 Linus Torvalds2005-04-16 1793 return -ENOMEM; ^1da177e4c3f41 Linus Torvalds2005-04-16 1794 vm_flags |= VM_ACCOUNT; ^1da177e4c3f41 Linus Torvalds2005-04-16 1795 } ^1da177e4c3f41 Linus Torvalds2005-04-16 1796 ^1da177e4c3f41 Linus Torvalds2005-04-16 1797 059c8a0bb96791 Liam R. Howlett 2020-11-10 1798 if (vm_flags & VM_SPECIAL) { 059c8a0bb96791 Liam R. Howlett 2020-11-10 1799 prev = mas_prev(, 0); 059c8a0bb96791 Liam R. Howlett 2020-11-10 1800 goto cannot_expand; "next" not initialized on this path. 059c8a0bb96791 Liam R. Howlett 2020-11-10 1801 } 059c8a0bb96791 Liam R. Howlett 2020-11-10 1802 059c8a0bb96791 Liam R. Howlett 2020-11-10 1803 /* Attempt to expand an old mapping */ 059c8a0bb96791
[RFC 2/3] arm64/hugetlb: Enable HUGETLB_PAGE_SIZE_VARIABLE
MAX_ORDER which invariably depends on FORCE_MAX_ZONEORDER can be a variable for a given page size, depending on whether TRANSPARENT_HUGEPAGE is enabled or not. In certain page size and THP combinations HUGETLB_PAGE_ORDER can be greater than MAX_ORDER, making it unusable as pageblock_order. This enables HUGETLB_PAGE_SIZE_VARIABLE making pageblock_order a variable rather than the compile time constant HUGETLB_PAGE_ORDER which could break MAX_ORDER rule for certain configurations. Cc: Catalin Marinas Cc: Will Deacon Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual --- arch/arm64/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 175914f2f340..c4acf8230f20 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1918,6 +1918,10 @@ config ARCH_ENABLE_THP_MIGRATION def_bool y depends on TRANSPARENT_HUGEPAGE +config HUGETLB_PAGE_SIZE_VARIABLE + def_bool y + depends on HUGETLB_PAGE + menu "Power management options" source "kernel/power/Kconfig" -- 2.20.1
[RFC 1/3] mm/page_alloc: Fix pageblock_order when HUGETLB_PAGE_ORDER >= MAX_ORDER
With HUGETLB_PAGE_SIZE_VARIABLE enabled, pageblock_order cannot be assigned as HUGETLB_PAGE_ORDER when it is greater than or equal to MAX_ORDER during set_pageblock_order(). Otherwise the following warning is triggered during boot as detected on an arm64 platform. WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0 Modules linked in: CPU: 5 PID: 124 Comm: kswapd0 Not tainted 5.11.0-rc6-4-ga0ea7d62002 #159 Hardware name: linux,dummy-virt (DT) [8.810673] pstate: 2045 (nzCv daif +PAN -UAO -TCO BTYPE=--) [8.811732] pc : __fragmentation_index+0xa4/0xc0 [8.812555] lr : fragmentation_index+0xf8/0x138 [8.813360] sp : 864079b0 [8.813958] x29: 864079b0 x28: 0372 [8.814901] x27: 7682 x26: 8000135b3948 [8.815847] x25: 1fffe00010c80f48 x24: [8.816805] x23: x22: 000d [8.817764] x21: 0030 x20: 0005ffcb4d58 [8.818712] x19: 000b x18: [8.819656] x17: x16: [8.820613] x15: x14: 8000114c6258 [8.821560] x13: 6000bff969ba x12: 1fffe000bff969b9 [8.822514] x11: 1fffe000bff969b9 x10: 6000bff969b9 [8.823461] x9 : dfff8000 x8 : 0005ffcb4dcf [8.824415] x7 : 0001 x6 : 41b58ab3 [8.825359] x5 : 600010c80f48 x4 : dfff8000 [8.826313] x3 : 8000102be670 x2 : 0007 [8.827259] x1 : 86407a60 x0 : 000d [8.828218] Call trace: [8.828667] __fragmentation_index+0xa4/0xc0 [8.829436] fragmentation_index+0xf8/0x138 [8.830194] compaction_suitable+0x98/0xb8 [8.830934] wakeup_kcompactd+0xdc/0x128 [8.831640] balance_pgdat+0x71c/0x7a0 [8.832327] kswapd+0x31c/0x520 [8.832902] kthread+0x224/0x230 [8.833491] ret_from_fork+0x10/0x30 [8.834150] ---[ end trace 472836f79c15516b ]--- The above warning happens because pageblock_order exceeds MAX_ORDER, caused by large HUGETLB_PAGE_ORDER on certain platforms like arm64. Lets prevent the scenario by first checking HUGETLB_PAGE_ORDER against MAX_ORDER, before its assignment as pageblock_order. Cc: Andrew Morton Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 519a60d5b6f7..36473f2fa683 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6798,7 +6798,7 @@ void __init set_pageblock_order(void) if (pageblock_order) return; - if (HPAGE_SHIFT > PAGE_SHIFT) + if ((HPAGE_SHIFT > PAGE_SHIFT) && (HUGETLB_PAGE_ORDER < MAX_ORDER)) order = HUGETLB_PAGE_ORDER; else order = MAX_ORDER - 1; -- 2.20.1
Re: [PATCH] bus: omap_l3_noc: mark l3 irqs as IRQF_NO_THREAD
* Grygorii Strashko [210128 21:16]: > The main purpose of l3 IRQs is to catch OCP bus access errors and identify > corresponding code places by showing call stack, so it's important to > handle L3 interconnect errors as fast as possible. On RT these IRQs will > became threaded and will be scheduled mach more late from the moment actual > error occurred so showing completely useless information. > > Hence, mark l3 IRQs as IRQF_NO_THREAD so they will not be forced threaded > on RT or if force_irqthreads = true. > > Fixes: 0ee7261c9212 ("drivers: bus: Move the OMAP interconnect driver to > drivers/bus/") Thanks applying into fixes. Tony
[RFC 0/3] mm/page_alloc: Fix pageblock_order with HUGETLB_PAGE_SIZE_VARIABLE
The following warning gets triggered while trying to boot a 64K page size without THP config kernel on arm64 platform. WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0 Modules linked in: CPU: 5 PID: 124 Comm: kswapd0 Not tainted 5.11.0-rc6-4-ga0ea7d62002 #159 Hardware name: linux,dummy-virt (DT) [8.810673] pstate: 2045 (nzCv daif +PAN -UAO -TCO BTYPE=--) [8.811732] pc : __fragmentation_index+0xa4/0xc0 [8.812555] lr : fragmentation_index+0xf8/0x138 [8.813360] sp : 864079b0 [8.813958] x29: 864079b0 x28: 0372 [8.814901] x27: 7682 x26: 8000135b3948 [8.815847] x25: 1fffe00010c80f48 x24: [8.816805] x23: x22: 000d [8.817764] x21: 0030 x20: 0005ffcb4d58 [8.818712] x19: 000b x18: [8.819656] x17: x16: [8.820613] x15: x14: 8000114c6258 [8.821560] x13: 6000bff969ba x12: 1fffe000bff969b9 [8.822514] x11: 1fffe000bff969b9 x10: 6000bff969b9 [8.823461] x9 : dfff8000 x8 : 0005ffcb4dcf [8.824415] x7 : 0001 x6 : 41b58ab3 [8.825359] x5 : 600010c80f48 x4 : dfff8000 [8.826313] x3 : 8000102be670 x2 : 0007 [8.827259] x1 : 86407a60 x0 : 000d [8.828218] Call trace: [8.828667] __fragmentation_index+0xa4/0xc0 [8.829436] fragmentation_index+0xf8/0x138 [8.830194] compaction_suitable+0x98/0xb8 [8.830934] wakeup_kcompactd+0xdc/0x128 [8.831640] balance_pgdat+0x71c/0x7a0 [8.832327] kswapd+0x31c/0x520 [8.832902] kthread+0x224/0x230 [8.833491] ret_from_fork+0x10/0x30 [8.834150] ---[ end trace 472836f79c15516b ]--- This warning comes from __fragmentation_index() when the requested order is greater than MAX_ORDER. static int __fragmentation_index(unsigned int order, struct contig_page_info *info) { unsigned long requested = 1UL << order; if (WARN_ON_ONCE(order >= MAX_ORDER)) <= Triggered here return 0; Digging it further reveals that pageblock_order has been assigned a value which is greater than MAX_ORDER failing the above check. But why this happened ? Because HUGETLB_PAGE_ORDER for the given config on arm64 is greater than MAX_ORDER. The solution involves enabling HUGETLB_PAGE_SIZE_VARIABLE which would make pageblock_order a variable instead of constant HUGETLB_PAGE_ORDER. But that change alone also did not really work as pageblock_order still got assigned as HUGETLB_PAGE_ORDER in set_pageblock_order(). HUGETLB_PAGE_ORDER needs to be less than MAX_ORDER for its appropriateness as pageblock_order otherwise just fallback to MAX_ORDER - 1 as before. While here it also fixes a build problem via type casting MAX_ORDER in rmem_cma_setup(). This series applies in v5.11-rc6 and has been slightly tested on arm64. But looking for some early feedbacks particularly with respect to concerns in subscribing HUGETLB_PAGE_SIZE_VARIABLE on a platform where the hugetlb page size is config dependent but not really a runtime variable. Even though it appears that HUGETLB_PAGE_SIZE_VARIABLE is used only while computing the pageblock_order, could there be other implications ? Cc: Catalin Marinas Cc: Will Deacon Cc: Robin Murphy Cc: Marek Szyprowski Cc: Christoph Hellwig Cc: Andrew Morton Cc: linux-arm-ker...@lists.infradead.org Cc: io...@lists.linux-foundation.org Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Anshuman Khandual (3): mm/page_alloc: Fix pageblock_order when HUGETLB_PAGE_ORDER >= MAX_ORDER arm64/hugetlb: Enable HUGETLB_PAGE_SIZE_VARIABLE dma-contiguous: Type cast MAX_ORDER as unsigned int arch/arm64/Kconfig | 4 kernel/dma/contiguous.c | 2 +- mm/page_alloc.c | 2 +- 3 files changed, 6 insertions(+), 2 deletions(-) -- 2.20.1
Re: [PATCH v8 0/2] Kbuild: DWARF v5 support
On Thu, Feb 4, 2021 at 7:40 AM Nick Desaulniers wrote: > > DWARF v5 is the latest standard of the DWARF debug info format. > > DWARF5 wins significantly in terms of size and especially so when mixed > with compression (CONFIG_DEBUG_INFO_COMPRESSED). > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf > > Patch 1 is a cleanup that lays the ground work and isn't DWARF > v5 specific. > Patch 2 implements Kconfig and Kbuild support for DWARFv5. > > Changes from v7: > (Strictly commit message changes) > * Pick up Nathan's reviewed by tags for both patches. > * Add note about only modifying compiler dwarf info, not assembler dwarf > info, as per Nathan. > * Add link to Red Hat bug report and Chris' reported by on patch 2. > * Add more info from Jakub on patch 2 commit message. > * Reorder info about validating version, noting the tree is not "clean" > in the sense that parts mess up existing CFLAGS, or don't use > DEBUG_CFLAGS. I will not be adding such cleanups to this series. They > can be done AFTER. > * Update note about 2.35.2 (rather than include the full text Jakub > wrote on it in > https://patchwork.kernel.org/project/linux-kbuild/patch/20201022012106.1875129-1-ndesaulni...@google.com/#23727667). > * Add note that GCC 11 has changed the implicit default version. > I have intensively tested a lot of versions of this series and some other issues reported and got fixed. So my comments for followers: [ Download v8 with b4 ] link="https://lore.kernel.org/r/20210204064037.1281726-1-ndesaulni...@google.com; b4 -d am $link [ Pre-Patch before applying v8 ] "kbuild: Remove $(cc-option,-gdwarf-4) dependency from DEBUG_INFO_DWARF4" https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44 [ DEBUG_CFLAGS thread and fix ] https://marc.info/?t=16123389346=1=2 https://marc.info/?l=linux-kbuild=161233892923723=2 Feel free to be more verbose and include links (to patches). I guess I need to test harder to get a Tested-by credit :-)? Thanks for v8, I will use it for some testing with BTF/pahole. - Sedat - > Changes from v6: > * Reorder sections from linker script to match order from BFD's internal > linker script. > * Add .debug_names section, as per Fangrui. > * Drop CONFIG_DEBUG_INFO_DWARF2. Patch 0001 becomes a menu with 1 > choice. GCC's implicit default version of DWARF has been DWARF v4 > since ~4.8. > * Modify the test script to check for the presence of > https://sourceware.org/bugzilla/show_bug.cgi?id=27195. > * Drop the clang without integrated assembler block in > 0002. Bumps the version requirement for GAS to 2.35.2, which isn't > released yet (but should be released soon). Folks looking to test > with clang but without the integrated assembler should fetch > binutils-gdb, build it from source, add a symlink to > binutils-gdb/gas/as-new to binutils-gdb/gas/as, then prefix > binutils-gdb/gas/as to their $PATH when building the kernel. > > Changes from v5: > * Drop previous patch 1, it has been accepted into kbuild: > > https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44 > * Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of > additional complexity. Drop it that part of the patch. We can revisit > clang without the integrated assembler setting -Wa,-gdwarf-4 later. > That is a separate problem from generally supporting DWARF v5. > * Rework the final patch for clang without the integrated assembler. > -Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will > not accept the assembler directives clang produces from C code when > generating asm. > > Changes from v4: > * drop set -e from script as per Nathan. > * add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat. > * Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and > Masahiro. Sorry it took me a few tries to understand the point (I > might still not), but it looks much cleaner this way. Sorry Nathan, I > did not carry forward your previous reviews as a result, but I would > appreciate if you could look again. > * Add Nathan's reviewed by tag to patch 1. > * Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5 > binutils addition later, and BTF issue. > * I still happen to see a pahole related error spew for the combination > of: > * LLVM=1 > * LLVM_IAS=1 > * CONFIG_DEBUG_INFO_DWARF4 > * CONFIG_DEBUG_INFO_BTF > Though they're non-fatal to the build. I'm not sure yet why removing > any one of the above prevents the warning spew. Maybe we'll need a v6. > > Changes from v3: > > Changes as per Arvind: > * only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds. > * add -gdwarf-5 to Kconfig shell script. > * only run Kconfig shell script for Clang. > > Apologies to Sedat and Nathan; I appreciate previous testing/review, but > I did no carry
Re: [PATCH 1/2] ARM: dts: am335x-pocketbeagle: unique gpio-line-names
* Drew Fustini [210127 02:04]: > Based on linux-gpio discussion [1], it is best practice to make the > gpio-line-names unique. Generic names like "[ethernet]" are replaced > with the name of the unique signal on the AM3358 SoC ball corresponding > to the gpio line. "[NC]" is also renamed to the standard "NC" name to > represent "not connected". > > [1] https://lore.kernel.org/linux-gpio/20201216195357.GA2583366@x1/ So are these needed for v5.12 as fixes, or can these wait until after the merge window for v5.13? Regards, Tony
Re: [PATCH] kprobes: Warn if the kprobe is reregistered
On 2021/02/03 11:59PM, Masami Hiramatsu wrote: > Warn if the kprobe is reregistered, since there must be > a software bug (actively used resource must not be re-registered) > and caller must be fixed. > > Signed-off-by: Masami Hiramatsu > --- > kernel/kprobes.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) Suggested-by: Naveen N. Rao Acked-by: Naveen N. Rao Thanks, Naveen
Re: [PATCH v2 3/3] arch/arm/configs: Enable VMSPLIT_2G in imx_v6_v7_defconfig
On Tue, Feb 2, 2021 at 11:50 PM Arnd Bergmann wrote: > > On Wed, Feb 3, 2021 at 3:37 AM Alistair Francis wrote: > > > > On Thu, Jan 28, 2021 at 11:13 PM Shawn Guo wrote: > > > > > > On Sun, Jan 17, 2021 at 10:03:01AM -0800, Alistair Francis wrote: > > > > The reMarkable2 requires VMSPLIT_2G, so lets set this in the > > > > imx_v6_v7_defconfig. > > > > > > Hmm, why is VMSPLIT_2G required by reMarkable2? > > > > I'm not too sure. It's difficult to debug problems as I only have a > > UART but without this I don't see any kernel prints so it seems like > > the kernel doesn't get very far. I haven't had any luck with earlycon > > on the device so I don't know how I can get more information. > > In the dts file, I can see that the machine has 1GB of RAM at > contiguous addresses. My first guess would be a problem with > highmem, as this configuration means that with VMSPLIT_3G > there are 768MB of lowmem and 256MB of highmem. > > Can you try these two things to narrow the problem down > further? > > a) disable CONFIG_HIGHMEM when using VMSPLIT_3G > b) use VMSPLIT_3G_OPT Thanks Arnd, I was working on testing the config changes you mentioned, but it seems like all of them work now. VMSPLIT_2G: Boots to userspace VMSPLIT_3G && HIGHMEM: Boots to userspace VMSPLIT_3G && !HIGHMEM: Boots to userspace VMSPLIT_3G_OPT && HIGHMEM:Boots to userspace > > If both of them solve the problem, then highmem is likely > the root cause. One possible issue might be that the boot > loader loads the initramfs or the dtb into a location outside > of the first 768 MB of lowmem where it is unreachable > in the VMSPLIT_3G configuration. It boots with u-boot, which I am building so I can change these addresses. I'm guessing that I have changed the addresses at some point and now it works. I'm going to drop this patch. Alistair > > Arnd
Re: [PATCH] x86: Add a prompt for HPET_EMULATE_RTC
On Thu, 4 Feb 2021 at 17:30, Randy Dunlap wrote: > > On 2/3/21 10:13 PM, Anand K. Mistry wrote: > >> Hi, > >> > >> When you run "make olddefconfig", should this "depends on" > >> line evaluate to true or false? > > > > True. RTC_DRV_CMOS=y by default on x86 systems and HPET_TIMER also > > appears to default yes (on x86-64 if I'm reading this right). > > > > Oddly, the RTC config option doesn't appear to exist. Probably a separate > > issue. > > Yes, just a separate simple patch. > > >> I.e., what are the settings of these symbols in the old .config file? > >> > >> > >> depends on HPET_TIMER && (RTC=y || RTC=m || RTC_DRV_CMOS=m || > >> RTC_DRV_CMOS=y) > > > > Actually, none of these options are set in the old config. > > RTC_DRV_CMOS and HPET_TIMER appear to default to yes. > > > > % grep HPET .config > > CONFIG_HPET=y > > # CONFIG_HPET_EMULATE_RTC is not set > > # CONFIG_HPET_MMAP is not set > > % grep RTC .config > > CONFIG_RTC_CLASS=y > > # CONFIG_HPET_EMULATE_RTC is not set > > CONFIG_PM_TRACE_RTC=y > > # CONFIG_RTC_HCTOSYS is not set > > > >> > >> If not, is there some out-of-tree driver involved? > > > > No out of tree drivers involved. I tried this on a vanilla 5.11-rc6. > > > >> I'm having a little trouble seeing why this is needed. > > > > So am I. But this is the magic that lets me keep > > CONFIG_HPET_EMULATE_RTC from the old config. I did manage to trace > > where the option is being overridden in the conf tool, but the > > reasoning why is beyond my knowledge. > > Can you post the .config that you are feeding to 'make olddefconfig', please. > I'll take a look (or the x86 guys can do so). Sure. Here it is: # # Config options generated by splitconfig # CONFIG_ANDROID=y CONFIG_ANDROID_BINDER_IPC=y CONFIG_ASHMEM=y CONFIG_AUDIT=y CONFIG_BFQ_GROUP_IOSCHED=y CONFIG_BINFMT_MISC=y CONFIG_BLK_CGROUP=y # CONFIG_BLK_DEBUG_FS is not set CONFIG_BLK_DEV_DM=y CONFIG_BLK_DEV_INITRD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=m CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y CONFIG_BPF_JIT=y CONFIG_BPF_JIT_ALWAYS_ON=y CONFIG_BPF_SYSCALL=y CONFIG_BRIDGE=m CONFIG_BT=m CONFIG_BT_FEATURE_DEBUG=y CONFIG_BT_FEATURE_DEBUG_FUNC_NAMES=y CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIBTUSB=m CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y CONFIG_BT_HCIBTUSB_INTERVAL=y CONFIG_BT_HCIVHCI=m CONFIG_BT_HIDP=m CONFIG_BT_RFCOMM=m CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_CFG80211=m CONFIG_CFG80211_CERTIFICATION_ONUS=y CONFIG_CFG80211_DEBUGFS=y # CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is not set CONFIG_CFG80211_WEXT=y CONFIG_CFS_BANDWIDTH=y CONFIG_CGROUPS=y CONFIG_CGROUP_BPF=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_SCHED=y CONFIG_CHROME_PLATFORMS=y CONFIG_CLS_U32_MARK=y # CONFIG_COMPAT_BRK is not set CONFIG_CONFIGFS_FS=y CONFIG_CONNECTOR=y CONFIG_CPUSETS=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_TEO=y CONFIG_CRC7=m CONFIG_CROS_EC=y CONFIG_CROS_EC_PD_UPDATE=y CONFIG_CROS_EC_SENSORHUB=m CONFIG_CROS_EC_SPI=y CONFIG_CRYPTO_ARC4=y CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_DAX=y CONFIG_DEBUG_ATOMIC_SLEEP=y CONFIG_DEBUG_CREDENTIALS=y CONFIG_DEBUG_DEVRES=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_DWARF4=y # CONFIG_DEBUG_PREEMPT is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEFAULT_HOSTNAME="localhost" CONFIG_DEFAULT_MMAP_MIN_ADDR=32768 CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_DM_CRYPT=y CONFIG_DM_FLAKEY=m CONFIG_DM_INIT=y CONFIG_DM_INTEGRITY=m CONFIG_DM_THIN_PROVISIONING=y CONFIG_DM_VERITY=y CONFIG_DM_VERITY_CHROMEOS=y # CONFIG_DNOTIFY is not set CONFIG_DRM=y CONFIG_DRM_DP_AUX_CHARDEV=y CONFIG_DRM_EVDI=m # CONFIG_DRM_FBDEV_EMULATION is not set CONFIG_DRM_UDL=y CONFIG_DRM_VGEM=y CONFIG_ECRYPT_FS=y CONFIG_EMBEDDED=y CONFIG_ENCRYPTED_KEYS=y CONFIG_ERROR_ON_WARNING=y CONFIG_ESD_FS=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y CONFIG_FANOTIFY=y CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y CONFIG_FORTIFY_SOURCE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_FS_ENCRYPTION=y CONFIG_FS_VERITY=y CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y CONFIG_FUNCTION_TRACER=y CONFIG_FUSE_FS=m CONFIG_GOOGLE_COREBOOT_TABLE=y CONFIG_GOOGLE_FIRMWARE=y CONFIG_GOOGLE_MEMCONSOLE_COREBOOT=y CONFIG_GOOGLE_VPD=y CONFIG_HARDENED_USERCOPY=y CONFIG_HFSPLUS_FS=m CONFIG_HIDRAW=y CONFIG_HID_APPLE=m CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HID_CHERRY=m CONFIG_HID_CHICONY=y CONFIG_HID_HOLTEK=y CONFIG_HID_KENSINGTON=y CONFIG_HID_LOGITECH=m CONFIG_HID_LOGITECH_DJ=m CONFIG_HID_MAGICMOUSE=m CONFIG_HID_MICROSOFT=m CONFIG_HID_MULTITOUCH=y CONFIG_HID_PLANTRONICS=m CONFIG_HID_PRIMAX=m CONFIG_HID_QUICKSTEP=m CONFIG_HID_SONY=m CONFIG_HID_THINGM=m CONFIG_HID_WACOM=m CONFIG_HID_WIIMOTE=m CONFIG_HIGH_RES_TIMERS=y CONFIG_HOSTAP=m CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_FIRMWARE_NVRAM=y CONFIG_HW_RANDOM=y
Re: [PATCH 1/2] vdpa/mlx5: Avoid unnecessary query virtqueue
On Wed, Feb 03, 2021 at 03:19:40PM -0800, Si-Wei Liu wrote: > On Tue, Feb 2, 2021 at 9:16 PM Jason Wang wrote: > > > > > > On 2021/2/3 上午1:54, Si-Wei Liu wrote: > > > On Tue, Feb 2, 2021 at 1:23 AM Eli Cohen wrote: > > >> On Tue, Feb 02, 2021 at 12:38:51AM -0800, Si-Wei Liu wrote: > > >>> Thanks Eli and Jason for clarifications. See inline. > > >>> > > >>> On Mon, Feb 1, 2021 at 11:06 PM Eli Cohen wrote: > > On Tue, Feb 02, 2021 at 02:02:25PM +0800, Jason Wang wrote: > > > On 2021/2/2 下午12:15, Si-Wei Liu wrote: > > >> On Mon, Feb 1, 2021 at 7:13 PM Jason Wang > > >> wrote: > > >>> On 2021/2/2 上午3:17, Si-Wei Liu wrote: > > On Mon, Feb 1, 2021 at 10:51 AM Si-Wei Liu > > wrote: > > > On Thu, Jan 28, 2021 at 5:46 AM Eli Cohen wrote: > > >> suspend_vq should only suspend the VQ on not save the current > > >> available > > >> index. This is done when a change of map occurs when the driver > > >> calls > > >> save_channel_info(). > > > Hmmm, suspend_vq() is also called by teardown_vq(), the latter of > > > which doesn't save the available index as save_channel_info() > > > doesn't > > > get called in that path at all. How does it handle the case that > > > aget_vq_state() is called from userspace (e.g. QEMU) while the > > > hardware VQ object was torn down, but userspace still wants to > > > access > > > the queue index? > > > > > > Refer to > > > https://lore.kernel.org/netdev/1601583511-15138-1-git-send-email-si-wei@oracle.com/ > > > > > > vhost VQ 0 ring restore failed: -1: Resource temporarily > > > unavailable (11) > > > vhost VQ 1 ring restore failed: -1: Resource temporarily > > > unavailable (11) > > > > > > QEMU will complain with the above warning while VM is being > > > rebooted > > > or shut down. > > > > > > Looks to me either the kernel driver should cover this > > > requirement, or > > > the userspace has to bear the burden in saving the index and not > > > call > > > into kernel if VQ is destroyed. > > Actually, the userspace doesn't have the insights whether virt > > queue > > will be destroyed if just changing the device status via > > set_status(). > > Looking at other vdpa driver in tree i.e. ifcvf it doesn't behave > > like > > so. Hence this still looks to me to be Mellanox specifics and > > mlx5_vdpa implementation detail that shouldn't expose to userspace. > > >>> So I think we can simply drop this patch? > > >> Yep, I think so. To be honest I don't know why it has anything to do > > >> with the memory hotplug issue. > > > > > > Eli may know more, my understanding is that, during memory hotplut, > > > qemu > > > need to propagate new memory mappings via set_map(). For mellanox, it > > > means > > > it needs to rebuild memory keys, so the virtqueue needs to be > > > suspended. > > > > > I think Siwei was asking why the first patch was related to the hotplug > > issue. > > >>> I was thinking how consistency is assured when saving/restoring this > > >>> h/w avail_index against the one in the virtq memory, particularly in > > >>> the region_add/.region_del() context (e.g. the hotplug case). Problem > > >>> is I don't see explicit memory barrier when guest thread updates the > > >>> avail_index, how does the device make sure the h/w avail_index is > > >>> uptodate while guest may race with updating the virtq's avail_index in > > >>> the mean while? Maybe I completely miss something obvious? > > >> DKIM-Signature: v1; arsa-sha256; crelaxed/relaxed; dnvidia.com; sn1; > > >> t 12257780; bhHnB0z4VEKwRS3WGY8d836MJgxu5Eln/jbFZlNXVxc08; > > >> hX-PGP-Universal:Date:From:To:CC:Subject:Message-ID:References: > > >> MIME-Version:Content-Type:Content-Disposition: > > >> > > >> Content-Transfer-Encoding:In-Reply-To:User-Agent:X-Originating-IP: > > >> X-ClientProxiedBy; > > >> > > >> bgGmb8+rcn3/rKzKQ/7QzSnghWzZ+FAU0XntsRZYGQ66sFvT7zsYPHogG3LIWNY77t > > >> > > >> wNHPw7GCJrNaH3nEXPbOp0FMOZw4Kv4W7UPuYPobbLeTkvuPAidjB8dM42vz+1X61t > > >> > > >> 9IVQT9X4hnAxRjI5CqZOo41GS4Tl1X+ykGoA+VE80BR/R/+nQ3tXDVULfppzeB+vu3 > > >> > > >> TWnnpaZ2GyoNyPlMiyVRkHdXzDVgA4uQHxwHn7otGK5J4lzyu8KrFyQtiP+f6hfu5v > > >> > > >> crJkYS8e9A+rfzUmKWuyHcKcmhPhAVJ4XdpzZcDXXlMHVxG7nR1o88xttC6D1+oNIP > > >> 9xHI3DkNBpEuA > > >> If you're asking about syncronization upon hot plug of memory, the > > >> hardware always goes to read the available index from memory when a new > > >> hardware object is associted with a virtqueue. You can argue then that > > >> you don't need to restore the
RE: [RFC PATCH v1 0/4] vfio: Add IOPF support for VFIO passthrough
> From: Shenming Lu > Sent: Tuesday, February 2, 2021 2:42 PM > > On 2021/2/1 15:56, Tian, Kevin wrote: > >> From: Alex Williamson > >> Sent: Saturday, January 30, 2021 6:58 AM > >> > >> On Mon, 25 Jan 2021 17:03:58 +0800 > >> Shenming Lu wrote: > >> > >>> Hi, > >>> > >>> The static pinning and mapping problem in VFIO and possible solutions > >>> have been discussed a lot [1, 2]. One of the solutions is to add I/O > >>> page fault support for VFIO devices. Different from those relatively > >>> complicated software approaches such as presenting a vIOMMU that > >> provides > >>> the DMA buffer information (might include para-virtualized > optimizations), > >>> IOPF mainly depends on the hardware faulting capability, such as the > PCIe > >>> PRI extension or Arm SMMU stall model. What's more, the IOPF support > in > >>> the IOMMU driver is being implemented in SVA [3]. So do we consider to > >>> add IOPF support for VFIO passthrough based on the IOPF part of SVA at > >>> present? > >>> > >>> We have implemented a basic demo only for one stage of translation > (GPA > >>> -> HPA in virtualization, note that it can be configured at either stage), > >>> and tested on Hisilicon Kunpeng920 board. The nested mode is more > >> complicated > >>> since VFIO only handles the second stage page faults (same as the non- > >> nested > >>> case), while the first stage page faults need to be further delivered to > >>> the guest, which is being implemented in [4] on ARM. My thought on this > >>> is to report the page faults to VFIO regardless of the occured stage (try > >>> to carry the stage information), and handle respectively according to the > >>> configured mode in VFIO. Or the IOMMU driver might evolve to support > >> more... > >>> > >>> Might TODO: > >>> - Optimize the faulting path, and measure the performance (it might still > >>>be a big issue). > >>> - Add support for PRI. > >>> - Add a MMU notifier to avoid pinning. > >>> - Add support for the nested mode. > >>> ... > >>> > >>> Any comments and suggestions are very welcome. :-) > >> > >> I expect performance to be pretty bad here, the lookup involved per > >> fault is excessive. There are cases where a user is not going to be > >> willing to have a slow ramp up of performance for their devices as they > >> fault in pages, so we might need to considering making this > >> configurable through the vfio interface. Our page mapping also only > > > > There is another factor to be considered. The presence of IOMMU_ > > DEV_FEAT_IOPF just indicates the device capability of triggering I/O > > page fault through the IOMMU, but not exactly means that the device > > can tolerate I/O page fault for arbitrary DMA requests. > > Yes, so I add a iopf_enabled field in VFIO to indicate the whole path faulting > capability and set it to true after registering a VFIO page fault handler. > > > In reality, many > > devices allow I/O faulting only in selective contexts. However, there > > is no standard way (e.g. PCISIG) for the device to report whether > > arbitrary I/O fault is allowed. Then we may have to maintain device > > specific knowledge in software, e.g. in an opt-in table to list devices > > which allows arbitrary faults. For devices which only support selective > > faulting, a mediator (either through vendor extensions on vfio-pci-core > > or a mdev wrapper) might be necessary to help lock down non-faultable > > mappings and then enable faulting on the rest mappings. > > For devices which only support selective faulting, they could tell it to the > IOMMU driver and let it filter out non-faultable faults? Do I get it wrong? Not exactly to IOMMU driver. There is already a vfio_pin_pages() for selectively page-pinning. The matter is that 'they' imply some device specific logic to decide which pages must be pinned and such knowledge is outside of VFIO. From enabling p.o.v we could possibly do it in phased approach. First handles devices which tolerate arbitrary DMA faults, and then extends to devices with selective-faulting. The former is simpler, but with one main open whether we want to maintain such device IDs in a static table in VFIO or rely on some hints from other components (e.g. PF driver in VF assignment case). Let's see how Alex thinks about it. > > > > >> grows here, should mappings expire or do we need a least recently > >> mapped tracker to avoid exceeding the user's locked memory limit? How > >> does a user know what to set for a locked memory limit? The behavior > >> here would lead to cases where an idle system might be ok, but as soon > >> as load increases with more inflight DMA, we start seeing > >> "unpredictable" I/O faults from the user perspective. Seems like there > >> are lots of outstanding considerations and I'd also like to hear from > >> the SVA folks about how this meshes with their work. Thanks, > >> > > > > The main overlap between this feature and SVA is the IOPF reporting > > framework, which currently still has gap to
[PATCH] media: atomisp: Remove unneeded return variable
This patch removes unneeded return variables, using only '0' instead. It fixes the following warning detected by coccinelle: ./drivers/staging/media/atomisp/pci/sh_css_mipi.c:39:5-8: Unneeded variable: "err". Return "0" on line 44 Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/staging/media/atomisp/pci/sh_css_mipi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/media/atomisp/pci/sh_css_mipi.c b/drivers/staging/media/atomisp/pci/sh_css_mipi.c index d5ae7f0..de8ee45 100644 --- a/drivers/staging/media/atomisp/pci/sh_css_mipi.c +++ b/drivers/staging/media/atomisp/pci/sh_css_mipi.c @@ -36,12 +36,10 @@ int ia_css_mipi_frame_specify(const unsigned int size_mem_words, const bool contiguous) { - int err = 0; - my_css.size_mem_words = size_mem_words; (void)contiguous; - return err; + return 0; } /* -- 1.8.3.1
[PATCH] firewire: convert sysfs sprintf/snprintf family to sysfs_emit
Fix the following coccicheck warning: ./drivers/firewire/core-device.c:375:8-16: WARNING: use scnprintf or sprintf. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/firewire/core-device.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c index 80db43a..795f69e 100644 --- a/drivers/firewire/core-device.c +++ b/drivers/firewire/core-device.c @@ -372,8 +372,7 @@ static ssize_t rom_index_show(struct device *dev, struct fw_device *device = fw_device(dev->parent); struct fw_unit *unit = fw_unit(dev); - return snprintf(buf, PAGE_SIZE, "%d\n", - (int)(unit->directory - device->config_rom)); + return sysfs_emit(buf, "%d\n", (int)(unit->directory - device->config_rom)); } static struct device_attribute fw_unit_attributes[] = { @@ -403,8 +402,7 @@ static ssize_t guid_show(struct device *dev, int ret; down_read(_device_rwsem); - ret = snprintf(buf, PAGE_SIZE, "0x%08x%08x\n", - device->config_rom[3], device->config_rom[4]); + ret = sysfs_emit(buf, "0x%08x%08x\n", device->config_rom[3], device->config_rom[4]); up_read(_device_rwsem); return ret; -- 1.8.3.1
Re: [PATCH] ARM: dts: am33xx: add aliases for mmc interfaces
* Måns Rullgård [210129 11:40]: > Tony Lindgren writes: > > > * Mans Rullgard [210128 18:09]: > >> Without DT aliases, the numbering of mmc interfaces is unpredictable. > >> Adding them makes it possible to refer to devices consistently. The > >> popular suggestion to use UUIDs obviously doesn't work with a blank > >> device fresh from the factory. > >> > >> See fa2d0aa96941 "mmc: core: Allow setting slot index via device tree > >> alias" for more discussion. > > > > Sounds good to me, but will wait a few days before applying to make sure > > this is still what we have agreed on :) > > If it helps the decision, my existing systems fail to boot without > something like this due to the eMMC moving from /dev/mmcblk1 to mmcblk0, > at least sometimes. I guess the kernel cares deeply about not breaking > userspace, except when it doesn't give a damn. > > I've been fighting this problem in various forms for the last 10 years > or so, and I was hoping it would finally be over. Yes this issue has been bugging folks for long time. Applying into fixes thanks. Tony
[PATCH v8 2/2] Kbuild: implement support for DWARF v5
DWARF v5 is the latest standard of the DWARF debug info format. GCC 11 will change the implicit default DWARF version, if left unspecified, to DWARF v5. DWARF5 wins significantly in terms of size when mixed with compression (CONFIG_DEBUG_INFO_COMPRESSED). 363Mvmlinux.clang12.dwarf5.compressed 434Mvmlinux.clang12.dwarf4.compressed 439Mvmlinux.clang12.dwarf2.compressed 457Mvmlinux.clang12.dwarf5 536Mvmlinux.clang12.dwarf4 548Mvmlinux.clang12.dwarf2 515Mvmlinux.gcc10.2.dwarf5.compressed 599Mvmlinux.gcc10.2.dwarf4.compressed 624Mvmlinux.gcc10.2.dwarf2.compressed 630Mvmlinux.gcc10.2.dwarf5 765Mvmlinux.gcc10.2.dwarf4 809Mvmlinux.gcc10.2.dwarf2 Though the quality of debug info is harder to quantify; size is not a proxy for quality. Jakub notes: One thing is GCC DWARF-5 support, that is whether the compiler will support -gdwarf-5 flag, and that support should be there from GCC 7 onwards. All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental option that enabled some small DWARF subset (initially only a few DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released after DWARF 5 has been finalized) started emitting DWARF5 section headers and got most of the DWARF5 changes in... Another separate thing is whether the assembler does support the -gdwarf-5 option (i.e. if you can compile assembler files with -Wa,-gdwarf-5) ... That option is about whether the assembler will emit DWARF5 or DWARF2 .debug_line. It is fine to compile C sources with -gdwarf-5 and use DWARF2 .debug_line for assembler files if as doesn't support it. Version check GCC so that we don't need to worry about the difference in command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to validate the DWARF Version in the assembler feature detection script. Most issues with clang produced assembler were fixed in binutils 2.35.1, but 2.35.2 fixed issues related to requiring the flag -Wa,-gdwarf-5 explicitly. The added shell script test checks for the latter, and is only required when using clang without its integrated assembler, though we use for clang regardless as we do not yet have a way to query the assembler from Kconfig. Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet recognize the new additions to the DWARF debug info. This only modifies the DWARF version emitted by the compiler, not the assembler. The DWARF version of a binary can be validated with: $ llvm-dwarfdump | head -n 4 | grep version or $ readelf --debug-dump=info 2>/dev/null | grep Version Parts of the tree don't reuse DEBUG_CFLAGS as they should; such cleanup is left as a follow up. Link: http://www.dwarfstd.org/doc/DWARF5.pdf Link: https://bugzilla.redhat.com/show_bug.cgi?id=1922707 Reported-by: Sedat Dilek Reported-by: Chris Murphy Suggested-by: Arvind Sankar Suggested-by: Caroline Tice Suggested-by: Fangrui Song Suggested-by: Jakub Jelinek Suggested-by: Masahiro Yamada Suggested-by: Nathan Chancellor Reviewed-by: Nathan Chancellor Signed-off-by: Nick Desaulniers --- Makefile | 1 + include/asm-generic/vmlinux.lds.h | 7 ++- lib/Kconfig.debug | 18 ++ scripts/test_dwarf5_support.sh| 8 4 files changed, 33 insertions(+), 1 deletion(-) create mode 100755 scripts/test_dwarf5_support.sh diff --git a/Makefile b/Makefile index bed5cc150009..8b2deca568ee 100644 --- a/Makefile +++ b/Makefile @@ -831,6 +831,7 @@ KBUILD_AFLAGS += -Wa,-gdwarf-2 endif dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4 +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5 DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y) ifdef CONFIG_DEBUG_INFO_REDUCED diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index 34b7e0d2346c..1e7cde4bd3f9 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -842,8 +842,13 @@ /* DWARF 4 */ \ .debug_types0 : { *(.debug_types) } \ /* DWARF 5 */ \ + .debug_addr 0 : { *(.debug_addr) } \ + .debug_line_str 0 : { *(.debug_line_str) } \ + .debug_loclists 0 : { *(.debug_loclists) } \ .debug_macro0 : { *(.debug_macro) } \ - .debug_addr 0 : { *(.debug_addr) } + .debug_names0 : { *(.debug_names) } \ + .debug_rnglists 0 : { *(.debug_rnglists) } \ + .debug_str_offsets 0 : { *(.debug_str_offsets) } /* Stabs debugging sections. */ #define STABS_DEBUG\ diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 94c1a7ed6306..ad6f78989d4f 100644 --- a/lib/Kconfig.debug +++
[PATCH v8 1/2] Kbuild: make DWARF version a choice
Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice which is the default. Does so in a way that's forward compatible with existing configs, and makes adding future versions more straightforward. GCC since ~4.8 has defaulted to this DWARF version implicitly. Reviewed-by: Nathan Chancellor Suggested-by: Arvind Sankar Suggested-by: Fangrui Song Suggested-by: Nathan Chancellor Suggested-by: Masahiro Yamada Signed-off-by: Nick Desaulniers --- Makefile | 5 ++--- lib/Kconfig.debug | 16 +++- 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 407816375983..bed5cc150009 100644 --- a/Makefile +++ b/Makefile @@ -830,9 +830,8 @@ ifneq ($(LLVM_IAS),1) KBUILD_AFLAGS += -Wa,-gdwarf-2 endif -ifdef CONFIG_DEBUG_INFO_DWARF4 -DEBUG_CFLAGS += -gdwarf-4 -endif +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4 +DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y) ifdef CONFIG_DEBUG_INFO_REDUCED DEBUG_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \ diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index e906ea906cb7..94c1a7ed6306 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -256,13 +256,19 @@ config DEBUG_INFO_SPLIT to know about the .dwo files and include them. Incompatible with older versions of ccache. +choice + prompt "DWARF version" + help + Which version of DWARF debug info to emit. + config DEBUG_INFO_DWARF4 - bool "Generate dwarf4 debuginfo" + bool "Generate DWARF Version 4 debuginfo" help - Generate dwarf4 debug info. This requires recent versions - of gcc and gdb. It makes the debug information larger. - But it significantly improves the success of resolving - variables in gdb on optimized code. + Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+. + It makes the debug information larger, but it significantly + improves the success of resolving variables in gdb on optimized code. + +endchoice # "DWARF version" config DEBUG_INFO_BTF bool "Generate BTF typeinfo" -- 2.30.0.365.g02bc693789-goog
[PATCH v8 0/2] Kbuild: DWARF v5 support
DWARF v5 is the latest standard of the DWARF debug info format. DWARF5 wins significantly in terms of size and especially so when mixed with compression (CONFIG_DEBUG_INFO_COMPRESSED). Link: http://www.dwarfstd.org/doc/DWARF5.pdf Patch 1 is a cleanup that lays the ground work and isn't DWARF v5 specific. Patch 2 implements Kconfig and Kbuild support for DWARFv5. Changes from v7: (Strictly commit message changes) * Pick up Nathan's reviewed by tags for both patches. * Add note about only modifying compiler dwarf info, not assembler dwarf info, as per Nathan. * Add link to Red Hat bug report and Chris' reported by on patch 2. * Add more info from Jakub on patch 2 commit message. * Reorder info about validating version, noting the tree is not "clean" in the sense that parts mess up existing CFLAGS, or don't use DEBUG_CFLAGS. I will not be adding such cleanups to this series. They can be done AFTER. * Update note about 2.35.2 (rather than include the full text Jakub wrote on it in https://patchwork.kernel.org/project/linux-kbuild/patch/20201022012106.1875129-1-ndesaulni...@google.com/#23727667). * Add note that GCC 11 has changed the implicit default version. Changes from v6: * Reorder sections from linker script to match order from BFD's internal linker script. * Add .debug_names section, as per Fangrui. * Drop CONFIG_DEBUG_INFO_DWARF2. Patch 0001 becomes a menu with 1 choice. GCC's implicit default version of DWARF has been DWARF v4 since ~4.8. * Modify the test script to check for the presence of https://sourceware.org/bugzilla/show_bug.cgi?id=27195. * Drop the clang without integrated assembler block in 0002. Bumps the version requirement for GAS to 2.35.2, which isn't released yet (but should be released soon). Folks looking to test with clang but without the integrated assembler should fetch binutils-gdb, build it from source, add a symlink to binutils-gdb/gas/as-new to binutils-gdb/gas/as, then prefix binutils-gdb/gas/as to their $PATH when building the kernel. Changes from v5: * Drop previous patch 1, it has been accepted into kbuild: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44 * Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of additional complexity. Drop it that part of the patch. We can revisit clang without the integrated assembler setting -Wa,-gdwarf-4 later. That is a separate problem from generally supporting DWARF v5. * Rework the final patch for clang without the integrated assembler. -Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will not accept the assembler directives clang produces from C code when generating asm. Changes from v4: * drop set -e from script as per Nathan. * add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat. * Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and Masahiro. Sorry it took me a few tries to understand the point (I might still not), but it looks much cleaner this way. Sorry Nathan, I did not carry forward your previous reviews as a result, but I would appreciate if you could look again. * Add Nathan's reviewed by tag to patch 1. * Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5 binutils addition later, and BTF issue. * I still happen to see a pahole related error spew for the combination of: * LLVM=1 * LLVM_IAS=1 * CONFIG_DEBUG_INFO_DWARF4 * CONFIG_DEBUG_INFO_BTF Though they're non-fatal to the build. I'm not sure yet why removing any one of the above prevents the warning spew. Maybe we'll need a v6. Changes from v3: Changes as per Arvind: * only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds. * add -gdwarf-5 to Kconfig shell script. * only run Kconfig shell script for Clang. Apologies to Sedat and Nathan; I appreciate previous testing/review, but I did no carry forward your Tested-by and Reviewed-by tags, as the patches have changed too much IMO. Changes from v2: * Drop two of the earlier patches that have been accepted already. * Add measurements with GCC 10.2 to commit message. * Update help text as per Arvind with help from Caroline. * Improve case/wording between DWARF Versions as per Masahiro. Changes from the RFC: * split patch in 3 patch series, include Fangrui's patch, too. * prefer `DWARF vX` format, as per Fangrui. * use spaces between assignment in Makefile as per Masahiro. * simplify setting dwarf-version-y as per Masahiro. * indent `prompt` in Kconfig change as per Masahiro. * remove explicit default in Kconfig as per Masahiro. * add comments to test_dwarf5_support.sh. * change echo in test_dwarf5_support.sh as per Masahiro. * remove -u from test_dwarf5_support.sh as per Masahiro. * add a -gdwarf-5 cc-option check to Kconfig as per Jakub. Nick Desaulniers (2): Kbuild: make DWARF version a choice Kbuild: implement support for DWARF v5 Makefile | 6
Re: [PATCH] ALSA: usb-audio: endpoint : remove redundant check before usb_free_coherent()
On Thu, 04 Feb 2021 03:05:18 +0100, Xu Wang wrote: > > usb_free_coherent() is safe with NULL addr and this check is > not required. The check there isn't about NULL buffer or not; instead it checks whether the buffer was allocated for each or it shares the single buffer (for sync endpoints). In the latter case, your patch will lead to double-free. thanks, Takashi
[PATCH] drm/komeda: convert sysfs sprintf/snprintf family to sysfs_emit
Fix the following coccicheck warning: ./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING: use scnprintf or sprintf. ./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING: use scnprintf or sprintf. ./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:65:8-16: WARNING: use scnprintf or sprintf. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c index ca891ae..cc7664c 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c @@ -62,7 +62,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev) { struct komeda_dev *mdev = dev_to_mdev(dev); - return snprintf(buf, PAGE_SIZE, "0x%08x\n", mdev->chip.core_id); + return sysfs_emit(buf, "0x%08x\n", mdev->chip.core_id); } static DEVICE_ATTR_RO(core_id); @@ -85,7 +85,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev) if (pipe->layers[i]->layer_type == KOMEDA_FMT_RICH_LAYER) config_id.n_richs++; } - return snprintf(buf, PAGE_SIZE, "0x%08x\n", config_id.value); + return sysfs_emit(buf, "0x%08x\n", config_id.value); } static DEVICE_ATTR_RO(config_id); @@ -94,7 +94,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev) { struct komeda_dev *mdev = dev_to_mdev(dev); - return snprintf(buf, PAGE_SIZE, "%lu\n", clk_get_rate(mdev->aclk)); + return sysfs_emit(buf, "%lu\n", clk_get_rate(mdev->aclk)); } static DEVICE_ATTR_RO(aclk_hz); -- 1.8.3.1
Re: [PATCH v14 8/8] mm: hugetlb: optimize the code with the help of the compiler
On 2021/2/4 11:50, Muchun Song wrote: > We cannot optimize if a "struct page" crosses page boundaries. If > it is true, we can optimize the code with the help of a compiler. > When free_vmemmap_pages_per_hpage() returns zero, most functions are > optimized by the compiler. > > Signed-off-by: Muchun Song I like it. Thanks. Reviewed-by: Miaohe Lin > --- > include/linux/hugetlb.h | 3 ++- > mm/hugetlb_vmemmap.c| 13 + > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > index 822ab2f5542a..7bfb06e16298 100644 > --- a/include/linux/hugetlb.h > +++ b/include/linux/hugetlb.h > @@ -878,7 +878,8 @@ extern bool hugetlb_free_vmemmap_enabled; > > static inline bool is_hugetlb_free_vmemmap_enabled(void) > { > - return hugetlb_free_vmemmap_enabled; > + return hugetlb_free_vmemmap_enabled && > +is_power_of_2(sizeof(struct page)); > } > #else > static inline bool is_hugetlb_free_vmemmap_enabled(void) > diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c > index 8efad9978821..068d0e0cebc8 100644 > --- a/mm/hugetlb_vmemmap.c > +++ b/mm/hugetlb_vmemmap.c > @@ -211,6 +211,12 @@ early_param("hugetlb_free_vmemmap", > early_hugetlb_free_vmemmap_param); > */ > static inline unsigned int free_vmemmap_pages_per_hpage(struct hstate *h) > { > + /* > + * This check aims to let the compiler help us optimize the code as > + * much as possible. > + */ > + if (!is_power_of_2(sizeof(struct page))) > + return 0; > return h->nr_free_vmemmap_pages; > } > > @@ -280,6 +286,13 @@ void __init hugetlb_vmemmap_init(struct hstate *h) > BUILD_BUG_ON(NR_USED_SUBPAGE >= >RESERVE_VMEMMAP_SIZE / sizeof(struct page)); > > + /* > + * The compiler can help us to optimize this function to null > + * when the size of the struct page is not power of 2. > + */ > + if (!is_power_of_2(sizeof(struct page))) > + return; > + > if (!hugetlb_free_vmemmap_enabled) > return; > >
[PATCH] ceph: minor coding style tweaks
Fixed some coding style issues, improve code reading. Signed-off-by: Zhiyuan Dai --- fs/ceph/addr.c | 3 +-- fs/ceph/cache.c | 14 +++--- fs/ceph/caps.c | 2 +- fs/ceph/dir.c| 6 +++--- fs/ceph/export.c | 2 +- fs/ceph/inode.c | 6 +++--- fs/ceph/locks.c | 2 +- fs/ceph/mds_client.c | 8 fs/ceph/mdsmap.c | 4 ++-- fs/ceph/snap.c | 6 +++--- fs/ceph/xattr.c | 4 ++-- 11 files changed, 28 insertions(+), 29 deletions(-) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index 9505529..94ce73e 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -493,8 +493,7 @@ static int ceph_readpages(struct file *file, struct address_space *mapping, return rc; } -struct ceph_writeback_ctl -{ +struct ceph_writeback_ctl { loff_t i_size; u64 truncate_size; u32 truncate_seq; diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c index 2f5cb6b..795523e 100644 --- a/fs/ceph/cache.c +++ b/fs/ceph/cache.c @@ -50,7 +50,7 @@ void ceph_fscache_unregister(void) fscache_unregister_netfs(_cache_netfs); } -int ceph_fscache_register_fs(struct ceph_fs_client* fsc, struct fs_context *fc) +int ceph_fscache_register_fs(struct ceph_fs_client *fsc, struct fs_context *fc) { const struct ceph_fsid *fsid = >client->fsid; const char *fscache_uniq = fsc->mount_options->fscache_uniq; @@ -110,8 +110,8 @@ static enum fscache_checkaux ceph_fscache_inode_check_aux( loff_t object_size) { struct ceph_aux_inode aux; - struct ceph_inode_info* ci = cookie_netfs_data; - struct inode* inode = >vfs_inode; + struct ceph_inode_info *ci = cookie_netfs_data; + struct inode *inode = >vfs_inode; if (dlen != sizeof(aux) || i_size_read(inode) != object_size) @@ -164,9 +164,9 @@ void ceph_fscache_register_inode_cookie(struct inode *inode) inode_unlock(inode); } -void ceph_fscache_unregister_inode_cookie(struct ceph_inode_info* ci) +void ceph_fscache_unregister_inode_cookie(struct ceph_inode_info *ci) { - struct fscache_cookie* cookie; + struct fscache_cookie *cookie; if ((cookie = ci->fscache) == NULL) return; @@ -296,7 +296,7 @@ void ceph_readpage_to_fscache(struct inode *inode, struct page *page) fscache_uncache_page(ci->fscache, page); } -void ceph_invalidate_fscache_page(struct inode* inode, struct page *page) +void ceph_invalidate_fscache_page(struct inode *inode, struct page *page) { struct ceph_inode_info *ci = ceph_inode(inode); @@ -307,7 +307,7 @@ void ceph_invalidate_fscache_page(struct inode* inode, struct page *page) fscache_uncache_page(ci->fscache, page); } -void ceph_fscache_unregister_fs(struct ceph_fs_client* fsc) +void ceph_fscache_unregister_fs(struct ceph_fs_client *fsc) { if (fscache_cookie_valid(fsc->fscache)) { struct ceph_fscache_entry *ent; diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c index 255a512..39fe5d8 100644 --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -2270,7 +2270,7 @@ static int caps_are_flushed(struct inode *inode, u64 flush_tid) spin_lock(>i_ceph_lock); if (!list_empty(>i_cap_flush_list)) { - struct ceph_cap_flush * cf = + struct ceph_cap_flush *cf = list_first_entry(>i_cap_flush_list, struct ceph_cap_flush, i_list); if (cf->tid <= flush_tid) diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c index 858ee73..2b7edd00 100644 --- a/fs/ceph/dir.c +++ b/fs/ceph/dir.c @@ -1269,7 +1269,7 @@ void __ceph_dentry_lease_touch(struct ceph_dentry_info *di) spin_unlock(>dentry_list_lock); } -static void __dentry_dir_lease_touch(struct ceph_mds_client* mdsc, +static void __dentry_dir_lease_touch(struct ceph_mds_client *mdsc, struct ceph_dentry_info *di) { di->flags &= ~(CEPH_DENTRY_LEASE_LIST | CEPH_DENTRY_REFERENCED); @@ -1351,7 +1351,7 @@ struct ceph_lease_walk_control { { struct ceph_dentry_info *di, *tmp; struct dentry *dentry, *last = NULL; - struct list_head* list; + struct list_head *list; LIST_HEAD(dispose); unsigned long freed = 0; int ret = 0; @@ -1498,7 +1498,7 @@ int ceph_trim_dentries(struct ceph_mds_client *mdsc) lwc.dir_lease = true; lwc.expire_dir_lease = freed < count; lwc.dir_lease_ttl = mdsc->fsc->mount_options->caps_wanted_delay_max * HZ; - freed +=__dentry_leases_walk(mdsc, , __dir_lease_check); + freed += __dentry_leases_walk(mdsc, , __dir_lease_check); if (!lwc.nr_to_scan) /* more to check */ return -EAGAIN; diff --git a/fs/ceph/export.c b/fs/ceph/export.c index e088843..83ec43f 100644 --- a/fs/ceph/export.c +++ b/fs/ceph/export.c @@ -343,7 +343,7 @@ static struct dentry *ceph_get_parent(struct dentry *child) struct
[PATCH 1/1] PCI/AER: Change to use helper pcie_aer_is_native() in some places
Use helper function pcie_aer_is_native() in some places to keep the code tidy. No function changes. Signed-off-by: Xiaofei Tan --- drivers/pci/pcie/aer.c | 4 ++-- drivers/pci/pcie/err.c | 2 +- drivers/pci/pcie/portdrv_core.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c index 77b0f2c..03212d0 100644 --- a/drivers/pci/pcie/aer.c +++ b/drivers/pci/pcie/aer.c @@ -1397,7 +1397,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev *dev) */ aer = root ? root->aer_cap : 0; - if ((host->native_aer || pcie_ports_native) && aer) { + if (pcie_aer_is_native(dev) && aer) { /* Disable Root's interrupt in response to error messages */ pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, ); reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK; @@ -1417,7 +1417,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev *dev) pci_info(dev, "Root Port link has been reset (%d)\n", rc); } - if ((host->native_aer || pcie_ports_native) && aer) { + if (pcie_aer_is_native(dev) && aer) { /* Clear Root Error Status */ pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, ); pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32); diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c index 510f31f..1d6cfb9 100644 --- a/drivers/pci/pcie/err.c +++ b/drivers/pci/pcie/err.c @@ -237,7 +237,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev, * this status. In that case, the signaling device may not even be * visible to the OS. */ - if (host->native_aer || pcie_ports_native) { + if (pcie_aer_is_native(dev)) { pcie_clear_device_status(bridge); pci_aer_clear_nonfatal_status(bridge); } diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c index e1fed664..1e6a690 100644 --- a/drivers/pci/pcie/portdrv_core.c +++ b/drivers/pci/pcie/portdrv_core.c @@ -222,7 +222,7 @@ static int get_port_device_capability(struct pci_dev *dev) #ifdef CONFIG_PCIEAER if (dev->aer_cap && pci_aer_available() && - (pcie_ports_native || host->native_aer)) { + pcie_aer_is_native(dev)) { services |= PCIE_PORT_SERVICE_AER; /* -- 2.8.1
Re: [PATCH][next] usb: cdnsp: Fix spelling mistake "delagete" -> "delegate"
On Thu, Feb 04, 2021 at 05:07:16AM +, Pawel Laszczak wrote: > Hi Dan, > > >> From: Colin Ian King > >> > >> There is a spelling mistake in a literal string. Fix it. > >> > >> Signed-off-by: Colin Ian King > >> --- > >> drivers/usb/cdns3/cdnsp-ep0.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/usb/cdns3/cdnsp-ep0.c b/drivers/usb/cdns3/cdnsp-ep0.c > >> index e2b1bcb3f80e..e30931ebc870 100644 > >> --- a/drivers/usb/cdns3/cdnsp-ep0.c > >> +++ b/drivers/usb/cdns3/cdnsp-ep0.c > >> @@ -45,7 +45,7 @@ static int cdnsp_ep0_delegate_req(struct cdnsp_device > >> *pdev, > >> { > >>int ret; > >> > >> - trace_cdnsp_ep0_request("delagete"); > >> + trace_cdnsp_ep0_request("delegate"); > >> > > > >This printk is useless and should just be deleted. Use ftrace instead. > > Maybe this printk is redundant but it's more comfortable in use. > To debug I can simply enable cdns-dev events (echo cdnsp-dev:* > set_event) > and I will get the full picture of what the driver is doing. > > Otherwise, I must remember which function I need to add to set_ftrace_filter. > Of course, by default I can simply add all cdnsp* functions (echo cdnsp* > > set_ftrace_filter) but it > increases the trace log and makes it a little more difficult to analyze. > > So maybe in some cases we shouldn't complain for such printk ? > > It's my private opinion and not necessarily correct :) Please don't have duplicate tracepoints for something like "this function is now called", it's redundant. thanks, greg k-h
Re: [PATCH] x86: Add a prompt for HPET_EMULATE_RTC
On 2/3/21 10:13 PM, Anand K. Mistry wrote: >> Hi, >> >> When you run "make olddefconfig", should this "depends on" >> line evaluate to true or false? > > True. RTC_DRV_CMOS=y by default on x86 systems and HPET_TIMER also > appears to default yes (on x86-64 if I'm reading this right). > > Oddly, the RTC config option doesn't appear to exist. Probably a separate > issue. Yes, just a separate simple patch. >> I.e., what are the settings of these symbols in the old .config file? >> >> >> depends on HPET_TIMER && (RTC=y || RTC=m || RTC_DRV_CMOS=m || >> RTC_DRV_CMOS=y) > > Actually, none of these options are set in the old config. > RTC_DRV_CMOS and HPET_TIMER appear to default to yes. > > % grep HPET .config > CONFIG_HPET=y > # CONFIG_HPET_EMULATE_RTC is not set > # CONFIG_HPET_MMAP is not set > % grep RTC .config > CONFIG_RTC_CLASS=y > # CONFIG_HPET_EMULATE_RTC is not set > CONFIG_PM_TRACE_RTC=y > # CONFIG_RTC_HCTOSYS is not set > >> >> If not, is there some out-of-tree driver involved? > > No out of tree drivers involved. I tried this on a vanilla 5.11-rc6. > >> I'm having a little trouble seeing why this is needed. > > So am I. But this is the magic that lets me keep > CONFIG_HPET_EMULATE_RTC from the old config. I did manage to trace > where the option is being overridden in the conf tool, but the > reasoning why is beyond my knowledge. Can you post the .config that you are feeding to 'make olddefconfig', please. I'll take a look (or the x86 guys can do so). thanks. -- ~Randy
[PATCH] btrfs: Remove unneeded return variable
This patch removes unneeded return variables, using only '0' instead. It fixes the following warning detected by coccinelle: ./fs/btrfs/extent_map.c:299:5-8: Unneeded variable: "ret". Return "0" on line 331 ./fs/btrfs/disk-io.c:4402:5-8: Unneeded variable: "ret". Return "0" on line 4410 Reported-by: Abaci Robot Signed-off-by: Yang Li --- fs/btrfs/disk-io.c| 5 ++--- fs/btrfs/extent_map.c | 3 +-- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 6b35b7e..e951da7 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -4399,7 +4399,6 @@ static int btrfs_destroy_delayed_refs(struct btrfs_transaction *trans, struct rb_node *node; struct btrfs_delayed_ref_root *delayed_refs; struct btrfs_delayed_ref_node *ref; - int ret = 0; delayed_refs = >delayed_refs; @@ -4407,7 +4406,7 @@ static int btrfs_destroy_delayed_refs(struct btrfs_transaction *trans, if (atomic_read(_refs->num_entries) == 0) { spin_unlock(_refs->lock); btrfs_debug(fs_info, "delayed_refs has NO entry"); - return ret; + return 0; } while ((node = rb_first_cached(_refs->href_root)) != NULL) { @@ -4473,7 +4472,7 @@ static int btrfs_destroy_delayed_refs(struct btrfs_transaction *trans, spin_unlock(_refs->lock); - return ret; + return 0; } static void btrfs_destroy_delalloc_inodes(struct btrfs_root *root) diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c index bd6229f..bac7eba 100644 --- a/fs/btrfs/extent_map.c +++ b/fs/btrfs/extent_map.c @@ -296,7 +296,6 @@ static void try_merge_map(struct extent_map_tree *tree, struct extent_map *em) int unpin_extent_cache(struct extent_map_tree *tree, u64 start, u64 len, u64 gen) { - int ret = 0; struct extent_map *em; bool prealloc = false; @@ -328,7 +327,7 @@ int unpin_extent_cache(struct extent_map_tree *tree, u64 start, u64 len, free_extent_map(em); out: write_unlock(>lock); - return ret; + return 0; } -- 1.8.3.1
Re: [PATCH] usb: pd: Reland VDO definitions of PD2.0
On Thu, Feb 04, 2021 at 02:17:56PM +0800, Kyle Tso wrote: > On Thu, Feb 4, 2021 at 8:55 AM Kyle Tso wrote: > > > > Hi, Benson and Prashant, > > > > On Thu, Feb 4, 2021 at 8:50 AM Kyle Tso wrote: > > > > > > Reland VDO definitions of PD Revision 2.0 as they are still used in > > > PD2.0 products. > > > > > > Fixes: 0e1d6f55a12e ("usb: pd: Update VDO definitions") > > > Signed-off-by: Kyle Tso > > > --- > > > include/linux/usb/pd_vdo.h | 69 -- > > > 1 file changed, 66 insertions(+), 3 deletions(-) > > > > > Is there any chance that you have free time to verify this patch with > > CrOS configuration? > > > > thanks, > > Kyle > > > > Hi, > > I tried to enable the config "CONFIG_CROS_EC_TYPEC=m" and it can make now. Thanks for verifying, I'll go queue this up to keep the tree building properly. greg k-h
Re: [PATCH] usb: typec: remove unused variable ‘ret’ in typec_partner_set_pd_revision
On Thu, Feb 04, 2021 at 09:24:30AM +0800, Ye Bin wrote: > Fix follow warning: > drivers/usb/typec/class.c:763:6: warning: unused variable ‘ret’ > [-Wunused-variable] > int ret; > ^~~ > > Reported-by: Hulk Robot > Signed-off-by: Ye Bin > --- > drivers/usb/typec/class.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c > index b6ceab3dc16b..1c2d50e016e2 100644 > --- a/drivers/usb/typec/class.c > +++ b/drivers/usb/typec/class.c > @@ -760,8 +760,6 @@ EXPORT_SYMBOL_GPL(typec_partner_set_identity); > */ > int typec_partner_set_pd_revision(struct typec_partner *partner, u16 > pd_revision) > { > - int ret; > - > if (partner->pd_revision == pd_revision) > return 0; > This is already fixed in my tree, right? What did you make this against? thanks, greg k-h
Re: [PATCH v2 1/4] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
> On Sat, 9 Jan 2021 at 11:33, Lecopzer Chen wrote: > > > > Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 > > ("kasan: support backing vmalloc space with real shadow memory") > > > > Like how the MODULES_VADDR does now, just not to early populate > > the VMALLOC_START between VMALLOC_END. > > similarly, the kernel code mapping is now in the VMALLOC area and > > should keep these area populated. > > > > Signed-off-by: Lecopzer Chen > > > This commit log text is a bit hard to follow. You are saying that the > vmalloc region is *not* backed with zero shadow or any default mapping > at all, right, and everything gets allocated on demand, just like is > the case for modules? It's much more like: before: MODULE_VADDR: no mapping, no zoreo shadow at init VMALLOC_VADDR: backed with zero shadow at init after: MODULE_VADDR: no mapping, no zoreo shadow at init VMALLOC_VADDR: no mapping, no zoreo shadow at init So it should be both "not backed with zero shadow" and "not any mapping and everything gets allocated on demand". And the "not backed with zero shadow" is like a subset of "not any mapping ...". Is that being more clear if the commit revises to: -- Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END. Before: MODULE_VADDR: no mapping, no zoreo shadow at init VMALLOC_VADDR: backed with zero shadow at init After: VMALLOC_VADDR: no mapping, no zoreo shadow at init Thus the mapping will get allocate on demand by the core function of KASAN vmalloc. similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated. Or would you have any suggestion? Thanks a lot for your review! BRs, Lecopzer