Re: [PATCH] tee: amdtee: unload TA only when its refcount becomes 0
On 15/03/21 2:59 pm, Jens Wiklander wrote: > On Sun, Mar 07, 2021 at 12:05:01PM +0530, Rijo Thomas wrote: >> Same Trusted Application (TA) can be loaded in multiple TEE contexts. >> >> If it is a single instance TA, the TA should not get unloaded from AMD >> Secure Processor, while it is still in use in another TEE context. >> >> Therefore reference count TA and unload it when the count becomes zero. >> >> Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") >> Reviewed-by: Devaraj Rangasamy >> Signed-off-by: Rijo Thomas >> --- >> drivers/tee/amdtee/amdtee_private.h | 13 + >> drivers/tee/amdtee/call.c | 73 +++-- >> drivers/tee/amdtee/core.c | 15 +++--- >> 3 files changed, 92 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/tee/amdtee/amdtee_private.h >> b/drivers/tee/amdtee/amdtee_private.h >> index 337c8d82f74e..6d0f7062bb87 100644 >> --- a/drivers/tee/amdtee/amdtee_private.h >> +++ b/drivers/tee/amdtee/amdtee_private.h >> @@ -21,6 +21,7 @@ >> #define TEEC_SUCCESS0x >> #define TEEC_ERROR_GENERIC 0x >> #define TEEC_ERROR_BAD_PARAMETERS 0x0006 >> +#define TEEC_ERROR_OUT_OF_MEMORY0x000C >> #define TEEC_ERROR_COMMUNICATION0x000E >> >> #define TEEC_ORIGIN_COMMS 0x0002 >> @@ -93,6 +94,18 @@ struct amdtee_shm_data { >> u32 buf_id; >> }; >> >> +/** >> + * struct amdtee_ta_data - Keeps track of all TAs loaded in AMD Secure >> + * Processor >> + * @ta_handle: Handle to TA loaded in TEE >> + * @refcount: Reference count for the loaded TA >> + */ >> +struct amdtee_ta_data { >> +struct list_head list_node; >> +u32 ta_handle; >> +u32 refcount; >> +}; >> + >> #define LOWER_TWO_BYTE_MASK 0x >> >> /** >> diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c >> index 096dd4d92d39..e10601417ea3 100644 >> --- a/drivers/tee/amdtee/call.c >> +++ b/drivers/tee/amdtee/call.c >> @@ -121,15 +121,69 @@ static int amd_params_to_tee_params(struct tee_param >> *tee, u32 count, >> return ret; >> } >> >> +static DEFINE_MUTEX(ta_refcount_mutex); >> +static struct list_head ta_list = LIST_HEAD_INIT(ta_list); >> + >> +static u32 get_ta_refcount(u32 ta_handle) >> +{ >> +struct amdtee_ta_data *ta_data; >> +u32 count = 0; >> + >> +/* Caller must hold a mutex */ >> +list_for_each_entry(ta_data, &ta_list, list_node) >> +if (ta_data->ta_handle == ta_handle) >> +return ++ta_data->refcount; >> + >> +ta_data = kzalloc(sizeof(*ta_data), GFP_KERNEL); >> +if (ta_data) { >> +ta_data->ta_handle = ta_handle; >> +ta_data->refcount = 1; >> +count = ta_data->refcount; >> +list_add(&ta_data->list_node, &ta_list); >> +} >> + >> +return count; >> +} >> + >> +static u32 put_ta_refcount(u32 ta_handle) >> +{ >> +struct amdtee_ta_data *ta_data; >> +u32 count = 0; >> + >> +/* Caller must hold a mutex */ >> +list_for_each_entry(ta_data, &ta_list, list_node) >> +if (ta_data->ta_handle == ta_handle) { >> +count = --ta_data->refcount; >> +if (count == 0) { >> +list_del(&ta_data->list_node); >> +kfree(ta_data); >> +break; >> +} >> +} >> + >> +return count; >> +} >> + >> int handle_unload_ta(u32 ta_handle) >> { >> struct tee_cmd_unload_ta cmd = {0}; >> -u32 status; >> +u32 status, count; >> int ret; >> >> if (!ta_handle) >> return -EINVAL; >> >> +mutex_lock(&ta_refcount_mutex); >> + >> +count = put_ta_refcount(ta_handle); >> + >> +if (count) { >> +pr_debug("unload ta: not unloading %u count %u\n", >> + ta_handle, count); >> +ret = -EBUSY; >> +goto unlock; >> +} >> + >> cmd.ta_handle = ta_handle; >> >> ret = psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, (void *)&cmd, >> @@ -137,8 +191,12 @@ int handle_unload_ta(u32 ta_handle) >> if (!ret && status != 0) { >> pr_err("unload ta: status = 0x%x\n", status); >> ret = -EBUSY; >> +} else { >> +pr_debug("unloaded ta handle %u\n", ta_handle); >> } >> >> +unlock: >> +mutex_unlock(&ta_refcount_mutex); >> return ret; >> } >> >> @@ -357,14 +415,23 @@ int handle_load_ta(void *data, u32 size, struct >> tee_ioctl_open_session_arg *arg) >> cmd.low_addr = lower_32_bits(blob); >> cmd.size = size; >> >> +mutex_lock(&ta_refcount_mutex); >> + >> ret = psp_tee_process_cmd(TEE_CMD_ID_LOAD_TA, (void *)&cmd, >>sizeof(cmd), &arg->ret); >> if (ret) { >> arg->ret_origin = TEEC_ORIGIN_COMMS; >> arg->ret = TEEC_ERROR_COMMUNICATION; >> -} else { >> -
Re: [PATCH v3 0/2] PSP TEE driver update and bug fixes
On 26/03/21 2:59 pm, Herbert Xu wrote: > On Mon, Mar 15, 2021 at 01:55:27PM +0530, Rijo Thomas wrote: >> The first patch helps to improve the response time by reducing the >> polling time of the tee command status variable. >> >> Second patch is a bug fix to handle multi-threaded use-case. >> During testing, race condition was seen due to missing synchronisation >> in writes to the TEE ring buffer. This patch helps to resolve that. >> >> v3: >> * Fixed checkpatch.pl warning >> >> v2: >> * Updated copyright year as a part of code change >> >> Rijo Thomas (2): >> crypto: ccp - reduce tee command status polling interval from 5ms to >> 1ms >> crypto: ccp - fix command queuing to TEE ring buffer >> >> drivers/crypto/ccp/tee-dev.c | 57 >> drivers/crypto/ccp/tee-dev.h | 20 +++-- >> 2 files changed, 57 insertions(+), 20 deletions(-) > > All applied. Thanks. > Thanks for pulling in the changes. Cheers, Rijo
Re: [PATCH next 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support
On Mon, Apr 05, 2021 at 01:52:39AM +, Min Li wrote: > > > > Any specific reason you are not using the misc_device api? That would clean > > up this driver a lot, there's no need to create a whole class just for a > > single > > driver. > > > > Hi Greg > > No specific reason. I just didn't know the existence of misc_register API. Your file is in drivers/misc/ :) > Do you recommend using this API to create the device? Yes. > If yes, can you tell me how to obtain a appropriate MINOR number from > miscdevice.h? No need to reserve one, we don't do that anymore, just ask for a dynamic value and the next availble one will be given to your driver automatically. thanks, greg k-h
Re: [PATCH 02/10] tty/sysrq: Fix issues of code indent should use tabs
Hi Xiaofei, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tty/tty-testing] [also build test WARNING on v5.12-rc6 next-20210401] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Xiaofei-Tan/tty-Fix-some-coding-style-issues/20210405-113900 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing config: x86_64-randconfig-a004-20210405 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 2760a808b9916a2839513b7fd7314a464f52481e) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://github.com/0day-ci/linux/commit/da18c35dce46cd938810b3ca12275fac9c97f64d git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Xiaofei-Tan/tty-Fix-some-coding-style-issues/20210405-113900 git checkout da18c35dce46cd938810b3ca12275fac9c97f64d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> drivers/tty/sysrq.c:558:3: warning: misleading indentation; statement is not >> part of the previous 'if' [-Wmisleading-indentation] return op_p; ^ drivers/tty/sysrq.c:555:2: note: previous statement is here if (i != -1) ^ 1 warning generated. vim +/if +558 drivers/tty/sysrq.c ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 545 ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 546 /* ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 547 * get and put functions for the table, exposed to modules. ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 548 */ 23cbedf812ff7c drivers/tty/sysrq.c Emil Velikov2020-05-13 549 static const struct sysrq_key_op *__sysrq_get_key_op(int key) bf36b9011e3c5b drivers/char/sysrq.c Andrew Morton 2006-03-25 550 { 23cbedf812ff7c drivers/tty/sysrq.c Emil Velikov2020-05-13 551 const struct sysrq_key_op *op_p = NULL; ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 552 int i; ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 553 ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 554 i = sysrq_key_table_key2index(key); bf36b9011e3c5b drivers/char/sysrq.c Andrew Morton 2006-03-25 555 if (i != -1) bf36b9011e3c5b drivers/char/sysrq.c Andrew Morton 2006-03-25 556 op_p = sysrq_key_table[i]; 97f5f0cd8cd0a0 drivers/char/sysrq.c Dmitry Torokhov 2010-03-21 557 ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 @558 return op_p; ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 559 } ^1da177e4c3f41 drivers/char/sysrq.c Linus Torvalds 2005-04-16 560 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] debugfs: Fix use-after-free in debugfs_create_devm_seqfile()
On Sun, Apr 04, 2021 at 12:26:10PM -0500, Samuel Holland wrote: > On 4/4/21 5:08 AM, Greg Kroah-Hartman wrote: > > On Sat, Apr 03, 2021 at 07:45:04PM -0500, Samuel Holland wrote: > >> This function uses devres to clean up its allocation, but it never removes > >> the > >> file referencing that allocation. This causes a use-after-free and an oops > >> if > >> the file is accessed after the owning device is removed. > > > > What in-kernel user of this is having this problem? > > > > The driver should clean up the debugfs file, it is not the debugfs > > core's job to auto-remove the file. > > The function returns void. debugfs_remove() requires the dentry pointer, > which the caller does not have. How is the driver expected to clean up > the file? Like it does for any other debugfs function (you will not that almost all of them return void now.) You remove the parent directory. > Do you expect the driver to remove the file as a side effect of > recursively removing its parent? Yes. > If so, that conflicts with the documentation for > debugfs_create_devm_seqfile(), which describes NULL as > a valid parent: > > @parent: a pointer to the parent dentry for this file. This should be a > directory dentry if set. If this parameter is %NULL, then the > file will be created in the root of the debugfs filesystem. > > There is one in-kernel caller that uses a NULL parent, in > drivers/gpio/gpio-tegra.c That code should be fixed up, putting a driver-specific file in the root of debugfs is a bit rude. > > The resource is what is being cleaned up by the devm usage in debugfs, > > that's all, not the file. > > > > Please fix up the driver that is creating the file but then not removing > > it. > > In that case, the function documentation should be modified to state > that the driver is responsible for removing the parent directory, and > that NULL is not a valid parent here. I can send a patch doing that instead. Please feel free to fix up allmost of the debugfs functions as I think they all say the same thing :) I've been slowly cleaning up the debugfs api, but have not been paying that much attention to the documentation yet, sorry. thanks, greg k-h
Re: [PATCH] staging: qlge: remove else after break
On Mon, Apr 05, 2021 at 06:11:43AM +0530, Mitali Borkar wrote: > linux-staging@lists,linux-kernel@vger.kernel.org > Bcc: > Subject: [PATCH] staging: qlge:remove else after break > Reply-To: Very odd, why is this in the body of the email? > > Fixed Warning:- else is not needed after break > break terminates the loop if encountered. else is unnecessary and > increases indenatation > > Signed-off-by: Mitali Borkar > --- > drivers/staging/qlge/qlge_mpi.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c > index 2630ebf50341..3a49f187203b 100644 > --- a/drivers/staging/qlge/qlge_mpi.c > +++ b/drivers/staging/qlge/qlge_mpi.c > @@ -935,13 +935,11 @@ static int qlge_idc_wait(struct qlge_adapter *qdev) > netif_err(qdev, drv, qdev->ndev, "IDC Success.\n"); > status = 0; > break; > - } else { > - netif_err(qdev, drv, qdev->ndev, > + } netif_err(qdev, drv, qdev->ndev, > "IDC: Invalid State 0x%.04x.\n", > mbcp->mbox_out[0]); > status = -EIO; > break; > - } Indentation is now no longer correct :( thanks, greg k-h
Re: [PATCH rdma-next 1/8] RDMA/core: Check if client supports IB device or not
On 05/04/2021 8:49, Leon Romanovsky wrote: > From: Parav Pandit > > RDMA devices are of different transport(iWarp, IB, RoCE) and have > different attributes. > Not all clients are interested in all type of devices. > > Implement a generic callback that each IB client can implement to decide > if client add() or remove() should be done by the IB core or not for a > given IB device, client combination. > > Signed-off-by: Parav Pandit > Signed-off-by: Leon Romanovsky > --- > drivers/infiniband/core/device.c | 3 +++ > include/rdma/ib_verbs.h | 9 + > 2 files changed, 12 insertions(+) > > diff --git a/drivers/infiniband/core/device.c > b/drivers/infiniband/core/device.c > index c660cef66ac6..c9af2deba8c1 100644 > --- a/drivers/infiniband/core/device.c > +++ b/drivers/infiniband/core/device.c > @@ -691,6 +691,9 @@ static int add_client_context(struct ib_device *device, > if (!device->kverbs_provider && !client->no_kverbs_req) > return 0; > > + if (client->is_supported && !client->is_supported(device)) > + return 0; Isn't it better to remove the kverbs_provider flag (from previous if statement) and unify it with this generic support check?
[PATCH v6] USB: serial: cp210x: Add support for GPIOs on CP2108
From: Pho Tran Similar to other CP210x devices, GPIO interfaces (gpiochip) should be supported for CP2108. CP2108 has 4 serial interfaces but only 1 set of GPIO pins are shared to all of those interfaces. So, just need to initialize GPIOs of CP2108 with only one interface (I use interface 0). It means just only 1 gpiochip device file will be created for CP2108. CP2108 has 16 GPIOs, So data types of several variables need to be is u16 instead of u8(in struct cp210x_serial_private). This doesn't affect other CP210x devices. Because CP2108 has 16 GPIO pins, the parameter passed by cp210x functions will be different from other CP210x devices. So need to check part number of the device to use correct data format before sending commands to devices. Like CP2104, CP2108 have GPIO pins with configurable options. Therefore, should be mask all pins which are not in GPIO mode in cp2108_gpio_init() function. Alternate functions of GPIO0 to GPIO3 is determine by enhancedfxn_IFC[0] and similar for enhancedfxn_IFC[1] and enhancedfxn_IFC[2]. Refer to CP2108 datasheet at sector "9: GPIO and UART pins" for more detail: https://www.silabs.com/documents/public/data-sheets/cp2108-datasheet.pdf Signed-off-by: Pho Tran --- 03/15/2021: Patch v5 Modifed code according to comment of Johan: 1. Unified the handling of CP2108 and other types and take care about endianness. 2. Used suitable types data for variable. 3. Fixed cp2108_gpio_init and add more detail on commit message and comment. 4. Dropped some of the ones that don't add any value. 03/12/2021: Patch v4 used git send-mail instead of send patch by manual follow the instructions of Johan Hovold . 03/05/2021: Patch v3 modified format and contents of changelog follow feedback from Johan Hovold . 03/04/2021: Patch v2 modified format patch as comment from Johan Hovold : 1. Break commit message lines at 80 cols 2. Use kernel u8 and u16 instead of the c99 ones. 03/01/2021: Initialed submission of patch "Make the CP210x driver work with GPIOs of CP2108.". drivers/usb/serial/cp210x.c | 253 +++- 1 file changed, 219 insertions(+), 34 deletions(-) diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c index 7bec1e730b20..f0ecb4315056 100644 --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -245,9 +245,9 @@ struct cp210x_serial_private { #ifdef CONFIG_GPIOLIB struct gpio_chipgc; boolgpio_registered; - u8 gpio_pushpull; - u8 gpio_altfunc; - u8 gpio_input; + u16 gpio_pushpull; + u16 gpio_altfunc; + u16 gpio_input; #endif u8 partnum; speed_t min_speed; @@ -399,6 +399,18 @@ static struct usb_serial_driver * const serial_drivers[] = { #define CP210X_PARTNUM_CP2102N_QFN20 0x22 #define CP210X_PARTNUM_UNKNOWN 0xFF +/* + * CP2108 Define bit locations for EnhancedFxn_IFCx + * Refer to https://www.silabs.com/documents/public/application-notes/an978-cp210x-usb-to-uart-api-specification.pdf + * for more information. + */ +#define EF_IFC_GPIO_TXLED 0x01 +#define EF_IFC_GPIO_RXLED 0x02 +#define EF_IFC_GPIO_RS485 0x04 +#define EF_IFC_GPIO_RS485_LOGIC 0x08 +#define EF_IFC_GPIO_CLOCK 0x10 +#define EF_IFC_DYNAMIC_SUSPEND 0x40 + /* CP210X_GET_COMM_STATUS returns these 0x13 bytes */ struct cp210x_comm_status { __le32 ulErrors; @@ -500,6 +512,45 @@ struct cp210x_single_port_config { u8 device_cfg; } __packed; +/* + * Quad Port Config definitions + * Refer to https://www.silabs.com/documents/public/application-notes/an978-cp210x-usb-to-uart-api-specification.pdf + * for more information. + * CP210X_VENDOR_SPECIFIC, CP210X_GET_PORTCONFIG call reads these 0x49 bytes + * on a CP2108 chip. + * CP2108 Quad Port State structure(used in Quad Port Config structure) + */ +struct cp210x_quad_port_state { + __le16 gpio_mode_PB0; + __le16 gpio_mode_PB1; + __le16 gpio_mode_PB2; + __le16 gpio_mode_PB3; + __le16 gpio_mode_PB4; + + + __le16 gpio_lowpower_PB0; + __le16 gpio_lowpower_PB1; + __le16 gpio_lowpower_PB2; + __le16 gpio_lowpower_PB3; + __le16 gpio_lowpower_PB4; + + __le16 gpio_latch_PB0; + __le16 gpio_latch_PB1; + __le16 gpio_latch_PB2; + __le16 gpio_latch_PB3; + __le16 gpio_latch_PB4; +}; + +// Cp2108 Quad Port Config structure +struct cp210x_quad_port_config { + struct cp210x_quad_port_state reset_state; + struct cp210x_quad_port_state suspend_state; + u8 ipdelay_IFC[4]; + u8 enhancedfxn_IFC[4]; + u8 enhancedfxn_device; + u8 extclkfreq[4]; +} __packed; + /* GPIO modes */ #define CP210X_SCI_GPIO_MODE_OFFSET
[PATCH V4 2/2] drm/vkms: Add support for virtual hardware mode
Add a virtual hardware or vblank-less mode as a module to enable VKMS to emulate virtual graphic drivers. Add a new drm_crtc_helper_funcs struct, vkms_virtual_crtc_helper_funcs() which holds the atomic helpers for virtual hardware mode. Change the existing vkms_crtc_helper_funcs struct to vkms_vblank_crtc_helper_funcs which holds atomic helpers for the vblank mode. This makes the code flow clearer and easier to test virtual hardware mode. The first patch of this patchset added the function vkms_crtc_composer() for plane composition which is used in case of vblank-less mode and is directly called in the atomic hook in vkms_crtc_atomic_begin(). However, some crc captures still use vblanks which causes the crc-based igt tests to crash. Currently, I am unsure about how to approach the one-shot implementation of crc reads so I am still working on that. This patchset has been tested with the igt tests- kms_writeback, kms_atomic, kms_lease, kms_flip, kms_pipe_get_crc and preserves results except for subtests related to crc reads and skips tests that rely on vertical blanking. This patchset must be tested after incorporating the igt-tests patch: https://lists.freedesktop.org/archives/igt-dev/2021-February/029355.html . The patch is based on Rodrigo Siqueira's patch(https://patchwork.freedesktop.org/patch/316851/?series=48469&rev=3) and the ensuing review. Signed-off-by: Sumera Priyadarsini --- Changes in V3: - Refactor patchset(Melissa) Changes in V2: - Add atomic helper functions in a separate struct for virtual hardware mode (Daniel) - Remove spinlock across 'vkms_output->lock' in vkms_crtc.c(Daniel) - Add vkms_composer_common() (Daniel) --- drivers/gpu/drm/vkms/vkms_crtc.c | 51 +++- drivers/gpu/drm/vkms/vkms_drv.c | 18 +++ drivers/gpu/drm/vkms/vkms_drv.h | 1 + 3 files changed, 51 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c index 57bbd32e9beb..e6286f98d5b6 100644 --- a/drivers/gpu/drm/vkms/vkms_crtc.c +++ b/drivers/gpu/drm/vkms/vkms_crtc.c @@ -222,20 +222,20 @@ static int vkms_crtc_atomic_check(struct drm_crtc *crtc, return 0; } -static void vkms_crtc_atomic_enable(struct drm_crtc *crtc, - struct drm_atomic_state *state) +static void vkms_vblank_crtc_atomic_enable(struct drm_crtc *crtc, + struct drm_atomic_state *state) { drm_crtc_vblank_on(crtc); } -static void vkms_crtc_atomic_disable(struct drm_crtc *crtc, -struct drm_atomic_state *state) +static void vkms_vblank_crtc_atomic_disable(struct drm_crtc *crtc, + struct drm_atomic_state *state) { drm_crtc_vblank_off(crtc); } -static void vkms_crtc_atomic_begin(struct drm_crtc *crtc, - struct drm_atomic_state *state) +static void vkms_vblank_crtc_atomic_begin(struct drm_crtc *crtc, + struct drm_atomic_state *state) { struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc); @@ -245,8 +245,8 @@ static void vkms_crtc_atomic_begin(struct drm_crtc *crtc, spin_lock_irq(&vkms_output->lock); } -static void vkms_crtc_atomic_flush(struct drm_crtc *crtc, - struct drm_atomic_state *state) +static void vkms_vblank_crtc_atomic_flush(struct drm_crtc *crtc, + struct drm_atomic_state *state) { struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc); @@ -268,18 +268,38 @@ static void vkms_crtc_atomic_flush(struct drm_crtc *crtc, spin_unlock_irq(&vkms_output->lock); } -static const struct drm_crtc_helper_funcs vkms_crtc_helper_funcs = { +/* + * Crtc functions for virtual hardware/vblankless mode + */ +static void vkms_virtual_crtc_atomic_flush(struct drm_crtc *crtc, + struct drm_atomic_state *state) +{ + struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc); + struct vkms_crtc_state *vkms_state = to_vkms_crtc_state(crtc->state); + + vkms_crtc_composer(vkms_state); + + vkms_output->composer_state = to_vkms_crtc_state(crtc->state); +} + +static const struct drm_crtc_helper_funcs vkms_vblank_crtc_helper_funcs = { .atomic_check = vkms_crtc_atomic_check, - .atomic_begin = vkms_crtc_atomic_begin, - .atomic_flush = vkms_crtc_atomic_flush, - .atomic_enable = vkms_crtc_atomic_enable, - .atomic_disable = vkms_crtc_atomic_disable, + .atomic_begin = vkms_vblank_crtc_atomic_begin, + .atomic_flush = vkms_vblank_crtc_atomic_flush, + .atomic_enable = vkms_vblank_crtc_atomic_enable, + .atomic_disable = vkms_vblank_crtc_atomic_disable, +}; + +static const struct drm_crtc_helper_funcs vkms_virtual_crtc_helper_funcs = { + .atomic_check = vkms_crtc_atomic_check, + .atomic_flush = vkms_virtual_crtc_atomic_flush, }; int vkms_crtc_init(struct drm_devi
[PATCH V4 1/2] drm/vkms: Refactor vkms_composer_worker() to prep for virtual_hw mode
Add two new functions vkms_composer_common() and vkms_crtc_composer(). The actual plane composition work has been moved to the helper function, vkms_composer_common() which is called by both vkms_composer_worker() and vkms_crtc_composer(). vkms_crtc_composer() can be used when we implement virtual_hw mode. Signed-off-by: Sumera Priyadarsini --- Changes in V4: - Fix warning Changes in V3: - Refactor patchset (Melissa) Change in V2: - Add vkms_composer_common() (Daniel) --- drivers/gpu/drm/vkms/vkms_composer.c | 88 +--- drivers/gpu/drm/vkms/vkms_drv.h | 3 + 2 files changed, 58 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index 66c6842d70db..0d2bad3ff849 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -169,6 +169,44 @@ static int compose_planes(void **vaddr_out, return 0; } +int vkms_composer_common(struct vkms_crtc_state *crtc_state, +struct vkms_output *out, bool wb_pending, uint32_t *crc32) +{ + struct vkms_composer *primary_composer = NULL; + struct vkms_composer *cursor_composer = NULL; + void *vaddr_out = NULL; + int ret; + + if (crtc_state->num_active_planes >= 1) + primary_composer = crtc_state->active_planes[0]->composer; + if (crtc_state->num_active_planes == 2) + cursor_composer = crtc_state->active_planes[1]->composer; + if (!primary_composer) + return -EINVAL; + if (wb_pending) + vaddr_out = crtc_state->active_writeback; + + ret = compose_planes(&vaddr_out, primary_composer, cursor_composer); + if (ret) { + if (ret == -EINVAL && !wb_pending) + kfree(vaddr_out); + return -EINVAL; + } + + *crc32 = compute_crc(vaddr_out, primary_composer); + + if (wb_pending) { + drm_writeback_signal_completion(&out->wb_connector, 0); + spin_lock_irq(&out->composer_lock); + crtc_state->wb_pending = false; + spin_unlock_irq(&out->composer_lock); + } else { + kfree(vaddr_out); + } + + return 0; +} + /** * vkms_composer_worker - ordered work_struct to compute CRC * @@ -185,12 +223,9 @@ void vkms_composer_worker(struct work_struct *work) composer_work); struct drm_crtc *crtc = crtc_state->base.crtc; struct vkms_output *out = drm_crtc_to_vkms_output(crtc); - struct vkms_composer *primary_composer = NULL; - struct vkms_composer *cursor_composer = NULL; bool crc_pending, wb_pending; - void *vaddr_out = NULL; - u32 crc32 = 0; u64 frame_start, frame_end; + u32 crc32 = 0; int ret; spin_lock_irq(&out->composer_lock); @@ -210,36 +245,9 @@ void vkms_composer_worker(struct work_struct *work) if (!crc_pending) return; - if (crtc_state->num_active_planes >= 1) - primary_composer = crtc_state->active_planes[0]->composer; - - if (crtc_state->num_active_planes == 2) - cursor_composer = crtc_state->active_planes[1]->composer; - - if (!primary_composer) - return; - - if (wb_pending) - vaddr_out = crtc_state->active_writeback; - - ret = compose_planes(&vaddr_out, primary_composer, cursor_composer); - if (ret) { - if (ret == -EINVAL && !wb_pending) - kfree(vaddr_out); + ret = vkms_composer_common(crtc_state, out, wb_pending, &crc32); + if (ret == -EINVAL) return; - } - - crc32 = compute_crc(vaddr_out, primary_composer); - - if (wb_pending) { - drm_writeback_signal_completion(&out->wb_connector, 0); - spin_lock_irq(&out->composer_lock); - crtc_state->wb_pending = false; - spin_unlock_irq(&out->composer_lock); - } else { - kfree(vaddr_out); - } - /* * The worker can fall behind the vblank hrtimer, make sure we catch up. */ @@ -247,6 +255,20 @@ void vkms_composer_worker(struct work_struct *work) drm_crtc_add_crc_entry(crtc, true, frame_start++, &crc32); } +void vkms_crtc_composer(struct vkms_crtc_state *crtc_state) +{ + struct drm_crtc *crtc = crtc_state->base.crtc; + struct vkms_output *out = drm_crtc_to_vkms_output(crtc); + u32 crc32 = 0; + int ret; + + ret = vkms_composer_common(crtc_state, out, crtc_state->wb_pending, &crc32); + if (ret == -EINVAL) + return; + + drm_crtc_add_crc_entry(crtc, true, 0, &crc32); +} + static const char * const pipe_crc_sources[] = {"auto"}; const char *const *vkms_get_crc_sources(struct drm_crtc *crtc, diff --git a/drivers/gpu/drm/vkms/vkm
[PATCH V4 0/2] Add virtual hardware module
This patchset adds support for emulating virtual hardware with VKMS. The virtual hardware mode can be enabled by using the following command while loading the module: sudo modprobe vkms enable_virtual_hw=1 The first patch is prep work for adding virtual_hw mode and refactors the plane composition in vkms by adding a helper function vkms_composer_common() which can be used for both vblank mode and virtual mode. The second patch adds virtual hardware support as a module option. It adds new atomic helper functions for the virtual mode and modifies the existing atomic helpers for usage by the vblank mode This gives us two sets of drm_crtc_helper_funcs struct for both modes, making the code flow cleaner and easier to debug. This patchset has been tested with the igt tests- kms_writeback, kms_atomic, kms_lease, kms_flip, kms_pipe_get_crc and preserves results except for subtests related to crc reads and skips tests that rely on vertical blanking. This patchset must be tested after incorporating the igt-tests patch: https://lists.freedesktop.org/archives/igt-dev/2021-February/029355.html Sumera Priyadarsini (2): drm/vkms: Refactor vkms_composer_worker() to prep for virtual_hw mode drm/vkms: Add support for virtual hardware mode drivers/gpu/drm/vkms/vkms_composer.c | 88 +--- drivers/gpu/drm/vkms/vkms_crtc.c | 51 +++- drivers/gpu/drm/vkms/vkms_drv.c | 18 -- drivers/gpu/drm/vkms/vkms_drv.h | 4 ++ 4 files changed, 109 insertions(+), 52 deletions(-) -- 2.25.1
Re: [PATCH v6 3/9] riscv: locks: Introduce ticket-based spinlock implementation
On Wed, Mar 31, 2021 at 10:32 PM wrote: > > From: Guo Ren > > This patch introduces a ticket lock implementation for riscv, along the > same lines as the implementation for arch/arm & arch/csky. > > We still use qspinlock as default. > > Signed-off-by: Guo Ren > Cc: Peter Zijlstra > Cc: Anup Patel > Cc: Arnd Bergmann > --- > arch/riscv/Kconfig | 7 ++- > arch/riscv/include/asm/spinlock.h | 84 + > arch/riscv/include/asm/spinlock_types.h | 17 + > 3 files changed, 107 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 67cc65ba1ea1..34d0276f01d5 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -34,7 +34,7 @@ config RISCV > select ARCH_WANT_FRAME_POINTERS > select ARCH_WANT_HUGE_PMD_SHARE if 64BIT > select ARCH_USE_QUEUED_RWLOCKS > - select ARCH_USE_QUEUED_SPINLOCKS > + select ARCH_USE_QUEUED_SPINLOCKSif !RISCV_TICKET_LOCK > select ARCH_USE_QUEUED_SPINLOCKS_XCHG32 > select CLONE_BACKWARDS > select CLINT_TIMER if !MMU > @@ -344,6 +344,11 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK > def_bool y > depends on NUMA > > +config RISCV_TICKET_LOCK > + bool "Ticket-based spin-locking" > + help > + Say Y here to use ticket-based spin-locking. > + > config RISCV_ISA_C > bool "Emit compressed instructions when building Linux" > default y > diff --git a/arch/riscv/include/asm/spinlock.h > b/arch/riscv/include/asm/spinlock.h > index a557de67a425..90b7eaa950cf 100644 > --- a/arch/riscv/include/asm/spinlock.h > +++ b/arch/riscv/include/asm/spinlock.h > @@ -7,7 +7,91 @@ > #ifndef _ASM_RISCV_SPINLOCK_H > #define _ASM_RISCV_SPINLOCK_H > > +#ifdef CONFIG_RISCV_TICKET_LOCK > +#ifdef CONFIG_32BIT > +#define __ASM_SLLIW "slli\t" > +#define __ASM_SRLIW "srli\t" > +#else > +#define __ASM_SLLIW "slliw\t" > +#define __ASM_SRLIW "srliw\t" > +#endif > + > +/* > + * Ticket-based spin-locking. > + */ > +static inline void arch_spin_lock(arch_spinlock_t *lock) > +{ > + arch_spinlock_t lockval; > + u32 tmp; > + > + asm volatile ( > + "1: lr.w%0, %2 \n" > + " mv %1, %0 \n" > + " addw%0, %0, %3 \n" > + " sc.w%0, %0, %2 \n" > + " bnez%0, 1b \n" > + : "=&r" (tmp), "=&r" (lockval), "+A" (lock->lock) > + : "r" (1 << TICKET_NEXT) > + : "memory"); It's could be optimized by amoadd.w with Anup advice, and I'll update it in the next patchset version: diff --git a/arch/riscv/include/asm/spinlock.h b/arch/riscv/include/asm/spinlock.h index 90b7eaa950cf..435286ad342b 100644 --- a/arch/riscv/include/asm/spinlock.h +++ b/arch/riscv/include/asm/spinlock.h @@ -22,15 +22,10 @@ static inline void arch_spin_lock(arch_spinlock_t *lock) { arch_spinlock_t lockval; - u32 tmp; asm volatile ( - "1: lr.w%0, %2 \n" - " mv %1, %0 \n" - " addw%0, %0, %3 \n" - " sc.w%0, %0, %2 \n" - " bnez%0, 1b \n" - : "=&r" (tmp), "=&r" (lockval), "+A" (lock->lock) + " amoadd.w%0, %2, %1 \n" + : "=&r" (lockval), "+A" (lock->lock) : "r" (1 << TICKET_NEXT) : "memory"); > + > + smp_cond_load_acquire(&lock->tickets.owner, > + VAL == lockval.tickets.next); > +} > + > +static inline int arch_spin_trylock(arch_spinlock_t *lock) > +{ > + u32 tmp, contended, res; > + > + do { > + asm volatile ( > + " lr.w%0, %3 \n" > + __ASM_SRLIW"%1, %0, %5 \n" > + __ASM_SLLIW"%2, %0, %5 \n" > + " or %1, %2, %1 \n" > + " li %2, 0 \n" > + " sub %1, %1, %0 \n" > + " bnez%1, 1f \n" > + " addw%0, %0, %4 \n" > + " sc.w%2, %0, %3 \n" > + "1: \n" > + : "=&r" (tmp), "=&r" (contended), "=&r" (res), > + "+A" (lock->lock) > + : "r" (1 << TICKET_NEXT), "I" (TICKET_NEXT) > + : "memory"); > + } while (res); > + > + if (!contended) > + __atomic_acquire_fence(); > + > + return !contended; > +} > + > +static inline void arch_spin_unlock(arch_spinlock_t *lock) > +{ > + smp_store_release(&lock->tickets.owner, lock->tickets.owner + 1); > +} > + > +static inline int arch_spin_value_unlocked(arch_spinlock_t lock) > +{ > + return lock.tickets.owner
Re: [PATCH] RDMA/addr: potential uninitialized variable in ib_nl_process_good_ip_rsep()
On Mon, Apr 05, 2021 at 08:41:41AM +0300, Dan Carpenter wrote: > Could you send that and give me a reported-by? I'm going AFK for a > week. Sure, we will handle it. Thanks for the report. > > regards, > dan carpenter >
[PATCH rdma-next 8/8] net/rds: Move to client_supported callback
From: Parav Pandit Use newly introduced client_supported() callback to avoid client additional if the RDMA device is not of IB type or if it doesn't support device memory extensions. Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky --- net/rds/ib.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/net/rds/ib.c b/net/rds/ib.c index 24c9a9005a6f..bd2ff7d5a718 100644 --- a/net/rds/ib.c +++ b/net/rds/ib.c @@ -125,18 +125,23 @@ void rds_ib_dev_put(struct rds_ib_device *rds_ibdev) queue_work(rds_wq, &rds_ibdev->free_work); } -static int rds_ib_add_one(struct ib_device *device) +static bool rds_client_supported(struct ib_device *device) { - struct rds_ib_device *rds_ibdev; - int ret; - /* Only handle IB (no iWARP) devices */ if (device->node_type != RDMA_NODE_IB_CA) - return -EOPNOTSUPP; + return false; /* Device must support FRWR */ if (!(device->attrs.device_cap_flags & IB_DEVICE_MEM_MGT_EXTENSIONS)) - return -EOPNOTSUPP; + return false; + + return true; +} + +static int rds_ib_add_one(struct ib_device *device) +{ + struct rds_ib_device *rds_ibdev; + int ret; rds_ibdev = kzalloc_node(sizeof(struct rds_ib_device), GFP_KERNEL, ibdev_to_node(device)); @@ -288,7 +293,8 @@ static void rds_ib_remove_one(struct ib_device *device, void *client_data) struct ib_client rds_ib_client = { .name = "rds_ib", .add= rds_ib_add_one, - .remove = rds_ib_remove_one + .remove = rds_ib_remove_one, + .is_supported = rds_client_supported, }; static int rds_ib_conn_info_visitor(struct rds_connection *conn, -- 2.30.2
[PATCH rdma-next 4/8] IB/core: Skip device which doesn't have necessary capabilities
From: Parav Pandit If device doesn't have multicast capability, avoid client registration for it. This saves 16Kbytes of memory for a RDMA device consist of 128 ports. If device doesn't support subnet administration, avoid client registration for it. This saves 8Kbytes of memory for a RDMA device consist of 128 ports. Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky --- drivers/infiniband/core/multicast.c | 15 ++- drivers/infiniband/core/sa_query.c | 15 ++- 2 files changed, 28 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/core/multicast.c b/drivers/infiniband/core/multicast.c index a5dd4b7a74bc..8c81acc24e3e 100644 --- a/drivers/infiniband/core/multicast.c +++ b/drivers/infiniband/core/multicast.c @@ -44,11 +44,13 @@ static int mcast_add_one(struct ib_device *device); static void mcast_remove_one(struct ib_device *device, void *client_data); +static bool mcast_client_supported(struct ib_device *device); static struct ib_client mcast_client = { .name = "ib_multicast", .add= mcast_add_one, - .remove = mcast_remove_one + .remove = mcast_remove_one, + .is_supported = mcast_client_supported, }; static struct ib_sa_client sa_client; @@ -816,6 +818,17 @@ static void mcast_event_handler(struct ib_event_handler *handler, } } +static bool mcast_client_supported(struct ib_device *device) +{ + u32 i; + + rdma_for_each_port(device, i) { + if (rdma_cap_ib_mcast(device, i)) + return true; + } + return false; +} + static int mcast_add_one(struct ib_device *device) { struct mcast_device *dev; diff --git a/drivers/infiniband/core/sa_query.c b/drivers/infiniband/core/sa_query.c index 9a4a49c37922..7e00e24d9423 100644 --- a/drivers/infiniband/core/sa_query.c +++ b/drivers/infiniband/core/sa_query.c @@ -176,11 +176,13 @@ static const struct nla_policy ib_nl_policy[LS_NLA_TYPE_MAX] = { static int ib_sa_add_one(struct ib_device *device); static void ib_sa_remove_one(struct ib_device *device, void *client_data); +static bool ib_sa_client_supported(struct ib_device *device); static struct ib_client sa_client = { .name = "sa", .add= ib_sa_add_one, - .remove = ib_sa_remove_one + .remove = ib_sa_remove_one, + .is_supported = ib_sa_client_supported, }; static DEFINE_XARRAY_FLAGS(queries, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ); @@ -2293,6 +2295,17 @@ static void ib_sa_event(struct ib_event_handler *handler, } } +static bool ib_sa_client_supported(struct ib_device *device) +{ + unsigned int i; + + rdma_for_each_port(device, i) { + if (rdma_cap_ib_sa(device, i)) + return true; + } + return false; +} + static int ib_sa_add_one(struct ib_device *device) { struct ib_sa_device *sa_dev; -- 2.30.2
[PATCH rdma-next 5/8] IB/IPoIB: Skip device which doesn't have InfiniBand port
From: Parav Pandit Skip RDMA device which doesn't have InfiniBand ports using newly introduced client_supported() callback. Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky --- drivers/infiniband/ulp/ipoib/ipoib_main.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c index 8f769ebaacc6..b02c10dea242 100644 --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c @@ -93,6 +93,7 @@ static struct net_device *ipoib_get_net_dev_by_params( struct ib_device *dev, u32 port, u16 pkey, const union ib_gid *gid, const struct sockaddr *addr, void *client_data); +static bool ipoib_client_supported(struct ib_device *device); static int ipoib_set_mac(struct net_device *dev, void *addr); static int ipoib_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd); @@ -102,6 +103,7 @@ static struct ib_client ipoib_client = { .add= ipoib_add_one, .remove = ipoib_remove_one, .get_net_dev_by_params = ipoib_get_net_dev_by_params, + .is_supported = ipoib_client_supported, }; #ifdef CONFIG_INFINIBAND_IPOIB_DEBUG @@ -2530,6 +2532,17 @@ static struct net_device *ipoib_add_port(const char *format, return ERR_PTR(-ENOMEM); } +static bool ipoib_client_supported(struct ib_device *device) +{ + u32 i; + + rdma_for_each_port(device, i) { + if (rdma_protocol_ib(device, i)) + return true; + } + return false; +} + static int ipoib_add_one(struct ib_device *device) { struct list_head *dev_list; -- 2.30.2
[PATCH rdma-next 6/8] IB/opa_vnic: Move to client_supported callback
From: Parav Pandit Move to newly introduced client_supported callback Avoid client registration using newly introduced helper callback if the IB device doesn't have OPA VNIC capability. Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky --- drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c b/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c index cecf0f7cadf9..58658eba97dd 100644 --- a/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c +++ b/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c @@ -121,6 +121,7 @@ static struct ib_client opa_vnic_client = { .name = opa_vnic_driver_name, .add= opa_vnic_vema_add_one, .remove = opa_vnic_vema_rem_one, + .is_supported = rdma_cap_opa_vnic, }; /** @@ -993,9 +994,6 @@ static int opa_vnic_vema_add_one(struct ib_device *device) struct opa_vnic_ctrl_port *cport; int rc, size = sizeof(*cport); - if (!rdma_cap_opa_vnic(device)) - return -EOPNOTSUPP; - size += device->phys_port_cnt * sizeof(struct opa_vnic_vema_port); cport = kzalloc(size, GFP_KERNEL); if (!cport) -- 2.30.2
[PATCH rdma-next 7/8] net/smc: Move to client_supported callback
From: Parav Pandit Use newly introduced client_supported() callback to avoid client additional if the RDMA device is not of IB type. Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky --- net/smc/smc_ib.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/net/smc/smc_ib.c b/net/smc/smc_ib.c index 6b65c5d1f957..f7186d9d1299 100644 --- a/net/smc/smc_ib.c +++ b/net/smc/smc_ib.c @@ -767,6 +767,11 @@ void smc_ib_ndev_change(struct net_device *ndev, unsigned long event) mutex_unlock(&smc_ib_devices.mutex); } +static bool smc_client_supported(struct ib_device *ibdev) +{ + return ibdev->node_type == RDMA_NODE_IB_CA; +} + /* callback function for ib_register_client() */ static int smc_ib_add_dev(struct ib_device *ibdev) { @@ -774,9 +779,6 @@ static int smc_ib_add_dev(struct ib_device *ibdev) u8 port_cnt; int i; - if (ibdev->node_type != RDMA_NODE_IB_CA) - return -EOPNOTSUPP; - smcibdev = kzalloc(sizeof(*smcibdev), GFP_KERNEL); if (!smcibdev) return -ENOMEM; @@ -840,6 +842,7 @@ static struct ib_client smc_ib_client = { .name = "smc_ib", .add= smc_ib_add_dev, .remove = smc_ib_remove_dev, + .is_supported = smc_client_supported, }; int __init smc_ib_register_client(void) -- 2.30.2
[PATCH rdma-next 1/8] RDMA/core: Check if client supports IB device or not
From: Parav Pandit RDMA devices are of different transport(iWarp, IB, RoCE) and have different attributes. Not all clients are interested in all type of devices. Implement a generic callback that each IB client can implement to decide if client add() or remove() should be done by the IB core or not for a given IB device, client combination. Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky --- drivers/infiniband/core/device.c | 3 +++ include/rdma/ib_verbs.h | 9 + 2 files changed, 12 insertions(+) diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c index c660cef66ac6..c9af2deba8c1 100644 --- a/drivers/infiniband/core/device.c +++ b/drivers/infiniband/core/device.c @@ -691,6 +691,9 @@ static int add_client_context(struct ib_device *device, if (!device->kverbs_provider && !client->no_kverbs_req) return 0; + if (client->is_supported && !client->is_supported(device)) + return 0; + down_write(&device->client_data_rwsem); /* * So long as the client is registered hold both the client and device diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h index 59138174affa..777fbcbd4858 100644 --- a/include/rdma/ib_verbs.h +++ b/include/rdma/ib_verbs.h @@ -2756,6 +2756,15 @@ struct ib_client { const union ib_gid *gid, const struct sockaddr *addr, void *client_data); + /* +* Returns if the client is supported for a given device or not. +* @dev: An RDMA device to check if client can support this RDMA or not. +* +* A client that is interested in specific device attributes, should +* implement it to check if client can be supported for this device or +* not. +*/ + bool (*is_supported)(struct ib_device *dev); refcount_t uses; struct completion uses_zero; -- 2.30.2
[PATCH rdma-next 3/8] IB/cm: Skip device which doesn't support IB CM
From: Parav Pandit There are at least 3 types of RDMA devices which do not support IB CM. They are (1) A (eswitch) switchdev RDMA device, (2) iWARP device and (3) RDMA device without a RoCE capability Hence, avoid IB CM initialization for such devices. This saves 8Kbytes of memory for eswitch device consist of 512 ports and also avoids unnecessary initialization for all above 3 types of devices. Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky --- drivers/infiniband/core/cm.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c index 8a7791ebae69..5025f2c1347b 100644 --- a/drivers/infiniband/core/cm.c +++ b/drivers/infiniband/core/cm.c @@ -87,6 +87,7 @@ struct cm_id_private; struct cm_work; static int cm_add_one(struct ib_device *device); static void cm_remove_one(struct ib_device *device, void *client_data); +static bool cm_supported(struct ib_device *device); static void cm_process_work(struct cm_id_private *cm_id_priv, struct cm_work *work); static int cm_send_sidr_rep_locked(struct cm_id_private *cm_id_priv, @@ -103,7 +104,8 @@ static int cm_send_rej_locked(struct cm_id_private *cm_id_priv, static struct ib_client cm_client = { .name = "cm", .add= cm_add_one, - .remove = cm_remove_one + .remove = cm_remove_one, + .is_supported = cm_supported, }; static struct ib_cm { @@ -4371,6 +4373,17 @@ static void cm_remove_port_fs(struct cm_port *port) } +static bool cm_supported(struct ib_device *device) +{ + u32 i; + + rdma_for_each_port(device, i) { + if (rdma_cap_ib_cm(device, i)) + return true; + } + return false; +} + static int cm_add_one(struct ib_device *ib_device) { struct cm_device *cm_dev; -- 2.30.2
[PATCH rdma-next 2/8] RDMA/cma: Skip device which doesn't support CM
From: Parav Pandit A switchdev RDMA device do not support IB CM. When such device is added to the RDMA CM's device list, when application invokes rdma_listen(), cma attempts to listen to such device, however it has IB CM attribute disabled. Due to this, rdma_listen() call fails to listen for other non switchdev devices as well. A below error message can be seen. infiniband mlx5_0: RDMA CMA: cma_listen_on_dev, error -38 A failing call flow is below. rdma_listen() cma_listen_on_all() cma_listen_on_dev() _cma_attach_to_dev() rdma_listen() <- fails on a specific switchdev device Hence, when a IB device doesn't support IB CM or IW CM, avoid adding such device to the cma list. Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky --- drivers/infiniband/core/cma.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c index 42a1c8955c50..80156faf90de 100644 --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -157,11 +157,13 @@ EXPORT_SYMBOL(rdma_res_to_id); static int cma_add_one(struct ib_device *device); static void cma_remove_one(struct ib_device *device, void *client_data); +static bool cma_supported(struct ib_device *device); static struct ib_client cma_client = { .name = "cma", .add= cma_add_one, - .remove = cma_remove_one + .remove = cma_remove_one, + .is_supported = cma_supported, }; static struct ib_sa_client sa_client; @@ -4870,6 +4872,17 @@ static void cma_process_remove(struct cma_device *cma_dev) wait_for_completion(&cma_dev->comp); } +static bool cma_supported(struct ib_device *device) +{ + u32 i; + + rdma_for_each_port(device, i) { + if (rdma_cap_ib_cm(device, i) || rdma_cap_iw_cm(device, i)) + return true; + } + return false; +} + static int cma_add_one(struct ib_device *device) { struct rdma_id_private *to_destroy; -- 2.30.2
[PATCH rdma-next 0/8] Generalize if ULP supported check
From: Leon Romanovsky Hi, This series adds new callback to check if ib client is supported/not_supported. Such general callback allows us to save memory footprint by not starting on devices that not going to work on them anyway. Thanks Parav Pandit (8): RDMA/core: Check if client supports IB device or not RDMA/cma: Skip device which doesn't support CM IB/cm: Skip device which doesn't support IB CM IB/core: Skip device which doesn't have necessary capabilities IB/IPoIB: Skip device which doesn't have InfiniBand port IB/opa_vnic: Move to client_supported callback net/smc: Move to client_supported callback net/rds: Move to client_supported callback drivers/infiniband/core/cm.c | 15 +- drivers/infiniband/core/cma.c | 15 +- drivers/infiniband/core/device.c | 3 +++ drivers/infiniband/core/multicast.c | 15 +- drivers/infiniband/core/sa_query.c| 15 +- drivers/infiniband/ulp/ipoib/ipoib_main.c | 13 .../infiniband/ulp/opa_vnic/opa_vnic_vema.c | 4 +--- include/rdma/ib_verbs.h | 9 + net/rds/ib.c | 20 --- net/smc/smc_ib.c | 9 ++--- 10 files changed, 101 insertions(+), 17 deletions(-) -- 2.30.2
High kmalloc-32 slab cache consumption with 10k containers
Hi, When running 1 (more-or-less-empty-)containers on a bare-metal Power9 server(160 CPUs, 2 NUMA nodes, 256G memory), it is seen that memory consumption increases quite a lot (around 172G) when the containers are running. Most of it comes from slab (149G) and within slab, the majority of it comes from kmalloc-32 cache (102G) The major allocator of kmalloc-32 slab cache happens to be the list_head allocations of list_lru_one list. These lists are created whenever a FS mount happens. Specially two such lists are registered by alloc_super(), one for dentry and another for inode shrinker list. And these lists are created for all possible NUMA nodes and for all given memcgs (memcg_nr_cache_ids to be particular) If, A = Nr allocation request per mount: 2 (one for dentry and inode list) B = Nr NUMA possible nodes C = memcg_nr_cache_ids D = size of each kmalloc-32 object: 32 bytes, then for every mount, the amount of memory consumed by kmalloc-32 slab cache for list_lru creation is A*B*C*D bytes. Following factors contribute to the excessive allocations: - Lists are created for possible NUMA nodes. - memcg_nr_cache_ids grows in bulk (see memcg_alloc_cache_id() and additional list_lrus are created when it grows. Thus we end up creating list_lru_one list_heads even for those memcgs which are yet to be created. For example, when 1 memcgs are created, memcg_nr_cache_ids reach a value of 12286. - When a memcg goes offline, the list elements are drained to the parent memcg, but the list_head entry remains. - The lists are destroyed only when the FS is unmounted. So list_heads for non-existing memcgs remain and continue to contribute to the kmalloc-32 allocation. This is presumably done for performance reason as they get reused when new memcgs are created, but they end up consuming slab memory until then. - In case of containers, a few file systems get mounted and are specific to the container namespace and hence to a particular memcg, but we end up creating lists for all the memcgs. As an example, if 7 FS mounts are done for every container and when 10k containers are created, we end up creating 2*7*12286 list_lru_one lists for each NUMA node. It appears that no elements will get added to other than 2*7=14 of them in the case of containers. One straight forward way to prevent this excessive list_lru_one allocations is to limit the list_lru_one creation only to the relevant memcg. However I don't see an easy way to figure out that relevant memcg from FS mount path (alloc_super()) As an alternative approach, I have this below hack that does lazy list_lru creation. The memcg-specific list is created and initialized only when there is a request to add an element to that particular list. Though I am not sure about the full impact of this change on the owners of the lists and also the performance impact of this, the overall savings look good. Used memory Before During After W/o patch 23G 172G40G W/ patch 23G 69G 29G Slab consumption Before During After W/o patch 1.5G149G22G W/ patch 1.5G45G 10G Number of kmalloc-32 allocations Before During After W/o patch 178176 3442409472 388933632 W/ patch 190464 468992 468992 Any thoughts on other approaches to address this scenario and any specific comments about the approach that I have taken is appreciated. Meanwhile the patch looks like below: >From 9444a0c6734c2853057b1f486f85da2c409fdc84 Mon Sep 17 00:00:00 2001 From: Bharata B Rao Date: Wed, 31 Mar 2021 18:21:45 +0530 Subject: [PATCH 1/1] mm: list_lru: Allocate list_lru_one only when required. Don't pre-allocate list_lru_one list heads for all memcg_cache_ids. Instead allocate and initialize it only when required. Signed-off-by: Bharata B Rao --- mm/list_lru.c | 79 +-- 1 file changed, 38 insertions(+), 41 deletions(-) diff --git a/mm/list_lru.c b/mm/list_lru.c index 6f067b6b935f..b453fa5008cc 100644 --- a/mm/list_lru.c +++ b/mm/list_lru.c @@ -112,16 +112,32 @@ list_lru_from_kmem(struct list_lru_node *nlru, void *ptr, } #endif /* CONFIG_MEMCG_KMEM */ +static void init_one_lru(struct list_lru_one *l) +{ + INIT_LIST_HEAD(&l->list); + l->nr_items = 0; +} + bool list_lru_add(struct list_lru *lru, struct list_head *item) { int nid = page_to_nid(virt_to_page(item)); struct list_lru_node *nlru = &lru->node[nid]; struct mem_cgroup *memcg; struct list_lru_one *l; + struct list_lru_memcg *memcg_lrus; spin_lock(&nlru->lock); if (list_empty(item)) { l = list_lru_from_kmem(nlru, item, &memcg); + if (!l) { + l = kmalloc(sizeof(struct list_lru_one), GFP_
Re: [PATCH v2] net: mac802154: Fix general protection fault
Hi! On Sun, 2021-04-04 at 20:43 -0400, Alexander Aring wrote: > Hi, > > On Thu, 4 Mar 2021 at 10:25, Pavel Skripkin > wrote: > > > > syzbot found general protection fault in crypto_destroy_tfm()[1]. > > It was caused by wrong clean up loop in llsec_key_alloc(). > > If one of the tfm array members is in IS_ERR() range it will > > cause general protection fault in clean up function [1]. > > > > Call Trace: > > crypto_free_aead include/crypto/aead.h:191 [inline] [1] > > llsec_key_alloc net/mac802154/llsec.c:156 [inline] > > mac802154_llsec_key_add+0x9e0/0xcc0 net/mac802154/llsec.c:249 > > ieee802154_add_llsec_key+0x56/0x80 net/mac802154/cfg.c:338 > > rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] > > nl802154_add_llsec_key+0x3d3/0x560 net/ieee802154/nl802154.c:1584 > > genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 > > genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] > > genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 > > netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 > > genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 > > netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] > > netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 > > netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 > > sock_sendmsg_nosec net/socket.c:654 [inline] > > sock_sendmsg+0xcf/0x120 net/socket.c:674 > > sys_sendmsg+0x6e8/0x810 net/socket.c:2350 > > ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 > > __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 > > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > > > Signed-off-by: Pavel Skripkin > > Reported-by: syzbot+9ec037722d2603a9f...@syzkaller.appspotmail.com > > Change-Id: I29f7ac641a039096d63d1e6070bb32cb5a3beb07 > > I am sorry, I don't know the tag "Change-Id", I was doing a whole > grep > on Documentation/ without any luck. > I forgot to check the patch with ./scripts/checkpatch.pl :( > Dumb question: What is the meaning of it? This is for gerrit code review. This is required to push changes to gerrit public mirror. I'm using it to check patches with syzbot. Change ids are useless outside gerrit, so it shouldn't be here. Btw, should I sent v2 or this is already fixed? > > - Alex With regards, Pavel Skripkin
Re: [PATCH] RDMA/addr: potential uninitialized variable in ib_nl_process_good_ip_rsep()
Could you send that and give me a reported-by? I'm going AFK for a week. regards, dan carpenter
[syzbot] WARNING: suspicious RCU usage in do_user_addr_fault
Hello, syzbot found the following issue on: HEAD commit:d19cc4bf Merge tag 'trace-v5.12-rc5' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17a22d16d0 kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 dashboard link: https://syzkaller.appspot.com/bug?extid=3d5082ab6eec95ad4231 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+3d5082ab6eec95ad4...@syzkaller.appspotmail.com WARNING: suspicious RCU usage 5.12.0-rc5-syzkaller #0 Not tainted - kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical section! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 0 1 lock held by syz-executor.5/8582: #0: 888029093218 (&mm->mmap_lock#2){}-{3:3}, at: mmap_read_trylock include/linux/mmap_lock.h:136 [inline] #0: 888029093218 (&mm->mmap_lock#2){}-{3:3}, at: do_user_addr_fault+0x285/0x1210 arch/x86/mm/fault.c:1331 stack backtrace: CPU: 0 PID: 8582 Comm: syz-executor.5 Not tainted 5.12.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294 do_user_addr_fault+0x2c2/0x1210 arch/x86/mm/fault.c:1348 handle_page_fault arch/x86/mm/fault.c:1475 [inline] exc_page_fault+0x9e/0x180 arch/x86/mm/fault.c:1531 asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:577 RIP: 0033:0x406f13 Code: 00 00 e8 a0 a1 ff ff 85 c0 74 4e 8b 54 24 0c 49 8b 37 31 c0 48 8d 3d 79 7f 0b 00 e8 27 c3 ff ff 8b 44 24 6c 49 8d 4f 60 89 de <4d> 89 a7 b8 00 00 00 ba 40 00 00 00 44 89 ef 41 89 87 b4 00 00 00 RSP: 002b:7fff2a8e7140 EFLAGS: 00010202 RAX: 0005 RBX: RCX: 00544420 RDX: 0002 RSI: RDI: 004bee7d RBP: 7fff2a8e7160 R08: 7fff2a8e715c R09: 7fff2a8e71f0 R10: 7fff2a8e71c0 R11: 0202 R12: 7fff2a8e71c0 R13: 0003 R14: 7fff2a8e715c R15: 005443c0 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH rdma-next 10/10] xprtrdma: Enable Relaxed Ordering
From: Avihai Horon Enable Relaxed Ordering for xprtrdma. Relaxed Ordering is an optional access flag and as such, it is ignored by vendors that don't support it. Signed-off-by: Avihai Horon Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- net/sunrpc/xprtrdma/frwr_ops.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/net/sunrpc/xprtrdma/frwr_ops.c b/net/sunrpc/xprtrdma/frwr_ops.c index cfbdd197cdfe..f9334c0a1a13 100644 --- a/net/sunrpc/xprtrdma/frwr_ops.c +++ b/net/sunrpc/xprtrdma/frwr_ops.c @@ -135,7 +135,8 @@ int frwr_mr_init(struct rpcrdma_xprt *r_xprt, struct rpcrdma_mr *mr) struct ib_mr *frmr; int rc; - frmr = ib_alloc_mr(ep->re_pd, ep->re_mrtype, depth, 0); + frmr = ib_alloc_mr(ep->re_pd, ep->re_mrtype, depth, + IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(frmr)) goto out_mr_err; @@ -339,9 +340,10 @@ struct rpcrdma_mr_seg *frwr_map(struct rpcrdma_xprt *r_xprt, reg_wr = &mr->frwr.fr_regwr; reg_wr->mr = ibmr; reg_wr->key = ibmr->rkey; - reg_wr->access = writing ? -IB_ACCESS_REMOTE_WRITE | IB_ACCESS_LOCAL_WRITE : -IB_ACCESS_REMOTE_READ; + reg_wr->access = + (writing ? IB_ACCESS_REMOTE_WRITE | IB_ACCESS_LOCAL_WRITE : + IB_ACCESS_REMOTE_READ) | + IB_ACCESS_RELAXED_ORDERING; mr->mr_handle = ibmr->rkey; mr->mr_length = ibmr->length; -- 2.30.2
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Sun, Apr 04, 2021 at 09:30:38PM -0700, Paul E. McKenney wrote: > On Sun, Apr 04, 2021 at 09:01:25PM -0700, Paul E. McKenney wrote: > > On Mon, Apr 05, 2021 at 04:08:55AM +0100, Matthew Wilcox wrote: > > > On Sun, Apr 04, 2021 at 02:40:30PM -0700, Paul E. McKenney wrote: > > > > On Sun, Apr 04, 2021 at 10:38:41PM +0200, Thomas Gleixner wrote: > > > > > On Sun, Apr 04 2021 at 12:05, syzbot wrote: > > > > > > > > > > Cc + ... > > > > > > > > And a couple more... > > > > > > > > > > Hello, > > > > > > > > > > > > syzbot found the following issue on: > > > > > > > > > > > > HEAD commit:5e46d1b7 reiserfs: update > > > > > > reiserfs_xattrs_initialized() co.. > > > > > > git tree: upstream > > > > > > console output: > > > > > > https://syzkaller.appspot.com/x/log.txt?x=1125f831d0 > > > > > > kernel config: > > > > > > https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 > > > > > > dashboard link: > > > > > > https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d > > > > > > > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to > > > > > > the commit: > > > > > > Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com > > > > > > > > > > > > = > > > > > > WARNING: suspicious RCU usage > > > > > > 5.12.0-rc5-syzkaller #0 Not tainted > > > > > > - > > > > > > kernel/sched/core.c:8294 Illegal context switch in RCU-sched > > > > > > read-side critical section! > > > > > > > > > > > > other info that might help us debug this: > > > > > > > > > > > > > > > > > > rcu_scheduler_active = 2, debug_locks = 0 > > > > > > 3 locks held by syz-executor.4/8418: > > > > > > #0: > > > > > > 8880751d2b28 > > > > > > ( > > > > > > &p->pi_lock > > > > > > ){-.-.}-{2:2} > > > > > > , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345 > > > > > > #1: > > > > > > 8880b9d35258 > > > > > > ( > > > > > > &rq->lock > > > > > > ){-.-.}-{2:2} > > > > > > , at: rq_lock kernel/sched/sched.h:1321 [inline] > > > > > > , at: ttwu_queue kernel/sched/core.c:3184 [inline] > > > > > > , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464 > > > > > > #2: 8880b9d1f948 (&per_cpu_ptr(group->pcpu, > > > > > > cpu)->seq){-.-.}-{0:0}, at: psi_task_change+0x142/0x220 > > > > > > kernel/sched/psi.c:807 > > > > > > > > This looks similar to > > > > syzbot+dde0cc33951735441...@syzkaller.appspotmail.com > > > > in that rcu_sleep_check() sees an RCU lock held, but the later call to > > > > lockdep_print_held_locks() does not. Did something change recently that > > > > could let the ->lockdep_depth counter get out of sync with the actual > > > > number of locks held? > > > > > > Dmitri had a different theory here: > > > > > > https://groups.google.com/g/syzkaller-bugs/c/FmYvfZCZzqA/m/nc2CXUgsAgAJ > > > > There is always room for more than one bug. ;-) > > > > He says "one-off false positives". I was afraid of that... > > And both the examples I have been copied on today are consistent with > debug_locks getting zeroed (e.g., via a call to __debug_locks_off()) > in the midst of a call to rcu_sleep_check(). But I would expect to see > a panic or another splat if that were to happen. > > Dmitry's example did have an additional splat, but I would expect the > RCU-related one to come second. Again, there is always room for more > than one bug. > > On the other hand, there are a lot more callers to debug_locks_off() > than there were last I looked into this. And both of these splats > are consistent with an interrupt in the middle of rcu_sleep_check(), > and that interrupt's handler invoking debug_locks_off(), but without > printing anything to the console. Does that sequence of events ring a > bell for anyone? > > If this is the new normal, I could make RCU_LOCKDEP_WARN() recheck > debug_lockdep_rcu_enabled() after evaluating the condition, but with > a memory barrier immediately before the recheck. But I am not at all > excited by doing this on speculation. Especially given that doing > so might be covering up some other bug. > Just check the original console log and find: [ 356.696686][ T8418] = [ 356.696692][ T8418] WARNING: suspicious RCU usage [ 356.700193][T14782] [ 356.704548][ T8418] 5.12.0-rc5-syzkaller #0 Not tainted [ 356.729981][ T8418] - [ 356.732473][T14782] WARNING: iou-sqp-14780/14782 still has locks held! , so there are two warnnings here, one is from lockdep_rcu_suspisous() and the other is from print_held_locks_bug(). I think this is what happened: in RCU_LOCKDEP_WARN(): if (debug_lockdep_rcu_enabled() // this is true and at this time debug_locks = 1 // lockdep detects a lock bug, set debug_locks = 0 && !__warned // true && (c))
[PATCH rdma-next 09/10] net/smc: Enable Relaxed Ordering
From: Avihai Horon Enable Relaxed Ordering for smc. Relaxed Ordering is an optional access flag and as such, it is ignored by vendors that don't support it. Signed-off-by: Avihai Horon Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- net/smc/smc_ib.c | 3 ++- net/smc/smc_wr.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/smc/smc_ib.c b/net/smc/smc_ib.c index 4e91ed3dc265..6b65c5d1f957 100644 --- a/net/smc/smc_ib.c +++ b/net/smc/smc_ib.c @@ -579,7 +579,8 @@ int smc_ib_get_memory_region(struct ib_pd *pd, int access_flags, return 0; /* already done */ buf_slot->mr_rx[link_idx] = - ib_alloc_mr(pd, IB_MR_TYPE_MEM_REG, 1 << buf_slot->order, 0); + ib_alloc_mr(pd, IB_MR_TYPE_MEM_REG, 1 << buf_slot->order, + IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(buf_slot->mr_rx[link_idx])) { int rc; diff --git a/net/smc/smc_wr.c b/net/smc/smc_wr.c index cbc73a7e4d59..78e9650621f1 100644 --- a/net/smc/smc_wr.c +++ b/net/smc/smc_wr.c @@ -555,7 +555,8 @@ static void smc_wr_init_sge(struct smc_link *lnk) lnk->wr_reg.wr.num_sge = 0; lnk->wr_reg.wr.send_flags = IB_SEND_SIGNALED; lnk->wr_reg.wr.opcode = IB_WR_REG_MR; - lnk->wr_reg.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE; + lnk->wr_reg.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE | +IB_ACCESS_RELAXED_ORDERING; } void smc_wr_free_link(struct smc_link *lnk) -- 2.30.2
Re: [PATCH v5 00/19] Support ROHM BD71815 PMIC
On Fri, 2021-04-02 at 20:19 +0100, Mark Brown wrote: > On Tue, Mar 30, 2021 at 11:06:53AM +, Vaittinen, Matti wrote: > > > Do you think Lee could merge other but the regulator parts to MFD > > if > > Mark is busy? I'd like to be able to squeeze the amount of patches > > and > > recipients for future iterations. It might be easier to work > > directly > > on regulator tree if regulator part gets delayed to next cycle. (I > > do > > also plan further working with the GPIO part during 5.13-rc cycle > > to > > utilize the regmap_gpio. That could be done in the GPIO tree then). > > I > > think the other portions are in a pretty stable shape now. > > This wouldn't be a bad idea in general for these serieses, especially > the bigger ones or the ones that get a lot of review comments on some > patches. > > In any case, here's a pull request for the helpers that are added Thanks Mark. > Matti Vaittinen (2): > regulator: helpers: Export helper voltage listing > regulator: Add regmap helper for ramp-delay setting > If I understand this correctly, the idea is that Lee could pull these changes to his tree? So, I will drop these two patches from the series when I resend it. Helpers are needed for the regulator part of the series to apply. Lee, Mark, please let me know if I misunderstood. Best Regards Matti Vaittinen
[PATCH rdma-next 08/10] net/rds: Enable Relaxed Ordering
From: Avihai Horon Enable Relaxed Ordering for rds. Relaxed Ordering is an optional access flag and as such, it is ignored by vendors that don't support it. Signed-off-by: Avihai Horon Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- net/rds/ib_frmr.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/net/rds/ib_frmr.c b/net/rds/ib_frmr.c index 694eb916319e..1a60c2c90c78 100644 --- a/net/rds/ib_frmr.c +++ b/net/rds/ib_frmr.c @@ -76,7 +76,7 @@ static struct rds_ib_mr *rds_ib_alloc_frmr(struct rds_ib_device *rds_ibdev, frmr = &ibmr->u.frmr; frmr->mr = ib_alloc_mr(rds_ibdev->pd, IB_MR_TYPE_MEM_REG, - pool->max_pages, 0); + pool->max_pages, IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(frmr->mr)) { pr_warn("RDS/IB: %s failed to allocate MR", __func__); err = PTR_ERR(frmr->mr); @@ -156,9 +156,8 @@ static int rds_ib_post_reg_frmr(struct rds_ib_mr *ibmr) reg_wr.wr.num_sge = 0; reg_wr.mr = frmr->mr; reg_wr.key = frmr->mr->rkey; - reg_wr.access = IB_ACCESS_LOCAL_WRITE | - IB_ACCESS_REMOTE_READ | - IB_ACCESS_REMOTE_WRITE; + reg_wr.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ | + IB_ACCESS_REMOTE_WRITE | IB_ACCESS_RELAXED_ORDERING; reg_wr.wr.send_flags = IB_SEND_SIGNALED; ret = ib_post_send(ibmr->ic->i_cm_id->qp, ®_wr.wr, NULL); -- 2.30.2
[PATCH rdma-next 06/10] nvme-rdma: Enable Relaxed Ordering
From: Avihai Horon Enable Relaxed Ordering for nvme. Relaxed Ordering is an optional access flag and as such, it is ignored by vendors that don't support it. Signed-off-by: Avihai Horon Reviewed-by: Max Gurtovoy Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- drivers/nvme/host/rdma.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c index 4dbc17311e0b..8f106b20b39c 100644 --- a/drivers/nvme/host/rdma.c +++ b/drivers/nvme/host/rdma.c @@ -532,9 +532,8 @@ static int nvme_rdma_create_queue_ib(struct nvme_rdma_queue *queue) */ pages_per_mr = nvme_rdma_get_max_fr_pages(ibdev, queue->pi_support) + 1; ret = ib_mr_pool_init(queue->qp, &queue->qp->rdma_mrs, - queue->queue_size, - IB_MR_TYPE_MEM_REG, - pages_per_mr, 0, 0); + queue->queue_size, IB_MR_TYPE_MEM_REG, + pages_per_mr, 0, IB_ACCESS_RELAXED_ORDERING); if (ret) { dev_err(queue->ctrl->ctrl.device, "failed to initialize MR pool sized %d for QID %d\n", @@ -545,7 +544,8 @@ static int nvme_rdma_create_queue_ib(struct nvme_rdma_queue *queue) if (queue->pi_support) { ret = ib_mr_pool_init(queue->qp, &queue->qp->sig_mrs, queue->queue_size, IB_MR_TYPE_INTEGRITY, - pages_per_mr, pages_per_mr, 0); + pages_per_mr, pages_per_mr, + IB_ACCESS_RELAXED_ORDERING); if (ret) { dev_err(queue->ctrl->ctrl.device, "failed to initialize PI MR pool sized %d for QID %d\n", @@ -1382,9 +1382,9 @@ static int nvme_rdma_map_sg_fr(struct nvme_rdma_queue *queue, req->reg_wr.wr.num_sge = 0; req->reg_wr.mr = req->mr; req->reg_wr.key = req->mr->rkey; - req->reg_wr.access = IB_ACCESS_LOCAL_WRITE | -IB_ACCESS_REMOTE_READ | -IB_ACCESS_REMOTE_WRITE; + req->reg_wr.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ | +IB_ACCESS_REMOTE_WRITE | +IB_ACCESS_RELAXED_ORDERING; sg->addr = cpu_to_le64(req->mr->iova); put_unaligned_le24(req->mr->length, sg->length); @@ -1488,9 +1488,8 @@ static int nvme_rdma_map_sg_pi(struct nvme_rdma_queue *queue, wr->wr.send_flags = 0; wr->mr = req->mr; wr->key = req->mr->rkey; - wr->access = IB_ACCESS_LOCAL_WRITE | -IB_ACCESS_REMOTE_READ | -IB_ACCESS_REMOTE_WRITE; + wr->access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ | +IB_ACCESS_REMOTE_WRITE | IB_ACCESS_RELAXED_ORDERING; sg->addr = cpu_to_le64(req->mr->iova); put_unaligned_le24(req->mr->length, sg->length); -- 2.30.2
[PATCH rdma-next 07/10] cifs: smbd: Enable Relaxed Ordering
From: Avihai Horon Enable Relaxed Ordering for smbd. Relaxed Ordering is an optional access flag and as such, it is ignored by vendors that don't support it. Signed-off-by: Avihai Horon Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- fs/cifs/smbdirect.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c index 647098a5cf3b..1e86dc8bbe85 100644 --- a/fs/cifs/smbdirect.c +++ b/fs/cifs/smbdirect.c @@ -2178,8 +2178,10 @@ static void smbd_mr_recovery_work(struct work_struct *work) continue; } - smbdirect_mr->mr = ib_alloc_mr(info->pd, info->mr_type, - info->max_frmr_depth, 0); + smbdirect_mr->mr = + ib_alloc_mr(info->pd, info->mr_type, + info->max_frmr_depth, + IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(smbdirect_mr->mr)) { log_rdma_mr(ERR, "ib_alloc_mr failed mr_type=%x max_frmr_depth=%x\n", info->mr_type, @@ -2244,7 +2246,8 @@ static int allocate_mr_list(struct smbd_connection *info) if (!smbdirect_mr) goto out; smbdirect_mr->mr = ib_alloc_mr(info->pd, info->mr_type, - info->max_frmr_depth, 0); + info->max_frmr_depth, + IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(smbdirect_mr->mr)) { log_rdma_mr(ERR, "ib_alloc_mr failed mr_type=%x max_frmr_depth=%x\n", info->mr_type, info->max_frmr_depth); @@ -2406,9 +2409,10 @@ struct smbd_mr *smbd_register_mr( reg_wr->wr.send_flags = IB_SEND_SIGNALED; reg_wr->mr = smbdirect_mr->mr; reg_wr->key = smbdirect_mr->mr->rkey; - reg_wr->access = writing ? - IB_ACCESS_REMOTE_WRITE | IB_ACCESS_LOCAL_WRITE : - IB_ACCESS_REMOTE_READ; + reg_wr->access = + (writing ? IB_ACCESS_REMOTE_WRITE | IB_ACCESS_LOCAL_WRITE : + IB_ACCESS_REMOTE_READ) | + IB_ACCESS_RELAXED_ORDERING; /* * There is no need for waiting for complemtion on ib_post_send -- 2.30.2
[PATCH rdma-next 02/10] RDMA/core: Enable Relaxed Ordering in __ib_alloc_pd()
From: Avihai Horon Enable Relaxed Ordering in __ib_alloc_pd() allocation of the local_dma_lkey. This will take effect only for devices that don't pre-allocate the lkey but allocate it per PD allocation. Signed-off-by: Avihai Horon Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- drivers/infiniband/core/verbs.c | 3 ++- drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c index a1782f8a6ca0..9b719f7d6fd5 100644 --- a/drivers/infiniband/core/verbs.c +++ b/drivers/infiniband/core/verbs.c @@ -287,7 +287,8 @@ struct ib_pd *__ib_alloc_pd(struct ib_device *device, unsigned int flags, if (device->attrs.device_cap_flags & IB_DEVICE_LOCAL_DMA_LKEY) pd->local_dma_lkey = device->local_dma_lkey; else - mr_access_flags |= IB_ACCESS_LOCAL_WRITE; + mr_access_flags |= + IB_ACCESS_LOCAL_WRITE | IB_ACCESS_RELAXED_ORDERING; if (flags & IB_PD_UNSAFE_GLOBAL_RKEY) { pr_warn("%s: enabling unsafe global rkey\n", caller); diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c index b3fa783698a0..d74827694f92 100644 --- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c +++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c @@ -66,6 +66,7 @@ struct ib_mr *pvrdma_get_dma_mr(struct ib_pd *pd, int acc) int ret; /* Support only LOCAL_WRITE flag for DMA MRs */ + acc &= ~IB_ACCESS_RELAXED_ORDERING; if (acc & ~IB_ACCESS_LOCAL_WRITE) { dev_warn(&dev->pdev->dev, "unsupported dma mr access flags %#x\n", acc); -- 2.30.2
[PATCH rdma-next 05/10] RDMA/srp: Enable Relaxed Ordering
From: Avihai Horon Enable Relaxed Ordering for srp. Relaxed Ordering is an optional access flag and as such, it is ignored by vendors that don't support it. Signed-off-by: Avihai Horon Reviewed-by: Max Gurtovoy Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- drivers/infiniband/ulp/srp/ib_srp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 8481ad769ba4..0026660c3ead 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -436,7 +436,8 @@ static struct srp_fr_pool *srp_create_fr_pool(struct ib_device *device, mr_type = IB_MR_TYPE_MEM_REG; for (i = 0, d = &pool->desc[0]; i < pool->size; i++, d++) { - mr = ib_alloc_mr(pd, mr_type, max_page_list_len, 0); + mr = ib_alloc_mr(pd, mr_type, max_page_list_len, +IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(mr)) { ret = PTR_ERR(mr); if (ret == -ENOMEM) @@ -1487,9 +1488,8 @@ static int srp_map_finish_fr(struct srp_map_state *state, wr.wr.send_flags = 0; wr.mr = desc->mr; wr.key = desc->mr->rkey; - wr.access = (IB_ACCESS_LOCAL_WRITE | -IB_ACCESS_REMOTE_READ | -IB_ACCESS_REMOTE_WRITE); + wr.access = (IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ | +IB_ACCESS_REMOTE_WRITE | IB_ACCESS_RELAXED_ORDERING); *state->fr.next++ = desc; state->nmdesc++; -- 2.30.2
[PATCH rdma-next 04/10] RDMA/rtrs: Enable Relaxed Ordering
From: Avihai Horon Enable Relaxed Ordering fro rtrs client and server. Relaxed Ordering is an optional access flag and as such, it is ignored by vendors that don't support it. Signed-off-by: Avihai Horon Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- drivers/infiniband/ulp/rtrs/rtrs-clt.c | 6 -- drivers/infiniband/ulp/rtrs/rtrs-srv.c | 15 --- 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/drivers/infiniband/ulp/rtrs/rtrs-clt.c b/drivers/infiniband/ulp/rtrs/rtrs-clt.c index 0d3960ed5b2b..a3fbb47a3574 100644 --- a/drivers/infiniband/ulp/rtrs/rtrs-clt.c +++ b/drivers/infiniband/ulp/rtrs/rtrs-clt.c @@ -1099,7 +1099,8 @@ static int rtrs_clt_read_req(struct rtrs_clt_io_req *req) .mr = req->mr, .key = req->mr->rkey, .access = (IB_ACCESS_LOCAL_WRITE | - IB_ACCESS_REMOTE_WRITE), + IB_ACCESS_REMOTE_WRITE | + IB_ACCESS_RELAXED_ORDERING), }; wr = &rwr.wr; @@ -1260,7 +1261,8 @@ static int alloc_sess_reqs(struct rtrs_clt_sess *sess) goto out; req->mr = ib_alloc_mr(sess->s.dev->ib_pd, IB_MR_TYPE_MEM_REG, - sess->max_pages_per_mr, 0); + sess->max_pages_per_mr, + IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(req->mr)) { err = PTR_ERR(req->mr); req->mr = NULL; diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c index 575f31ff20fd..c28ed5e2245d 100644 --- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c @@ -312,8 +312,8 @@ static int rdma_write_sg(struct rtrs_srv_op *id) rwr.mr = srv_mr->mr; rwr.wr.send_flags = 0; rwr.key = srv_mr->mr->rkey; - rwr.access = (IB_ACCESS_LOCAL_WRITE | - IB_ACCESS_REMOTE_WRITE); + rwr.access = (IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE | + IB_ACCESS_RELAXED_ORDERING); msg = srv_mr->iu->buf; msg->buf_id = cpu_to_le16(id->msg_id); msg->type = cpu_to_le16(RTRS_MSG_RKEY_RSP); @@ -432,8 +432,8 @@ static int send_io_resp_imm(struct rtrs_srv_con *con, struct rtrs_srv_op *id, rwr.wr.send_flags = 0; rwr.mr = srv_mr->mr; rwr.key = srv_mr->mr->rkey; - rwr.access = (IB_ACCESS_LOCAL_WRITE | - IB_ACCESS_REMOTE_WRITE); + rwr.access = (IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE | + IB_ACCESS_RELAXED_ORDERING); msg = srv_mr->iu->buf; msg->buf_id = cpu_to_le16(id->msg_id); msg->type = cpu_to_le16(RTRS_MSG_RKEY_RSP); @@ -638,7 +638,7 @@ static int map_cont_bufs(struct rtrs_srv_sess *sess) goto free_sg; } mr = ib_alloc_mr(sess->s.dev->ib_pd, IB_MR_TYPE_MEM_REG, -sgt->nents, 0); +sgt->nents, IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(mr)) { err = PTR_ERR(mr); goto unmap_sg; @@ -823,8 +823,9 @@ static int process_info_req(struct rtrs_srv_con *con, rwr[mri].wr.send_flags = 0; rwr[mri].mr = mr; rwr[mri].key = mr->rkey; - rwr[mri].access = (IB_ACCESS_LOCAL_WRITE | - IB_ACCESS_REMOTE_WRITE); + rwr[mri].access = + (IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE | +IB_ACCESS_RELAXED_ORDERING); reg_wr = &rwr[mri].wr; } -- 2.30.2
[PATCH rdma-next 03/10] RDMA/iser: Enable Relaxed Ordering
From: Avihai Horon Enable Relaxed Ordering for iser. Relaxed Ordering is an optional access flag and as such, it is ignored by vendors that don't support it. Signed-off-by: Avihai Horon Reviewed-by: Max Gurtovoy Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- drivers/infiniband/ulp/iser/iser_memory.c | 10 -- drivers/infiniband/ulp/iser/iser_verbs.c | 6 -- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/infiniband/ulp/iser/iser_memory.c b/drivers/infiniband/ulp/iser/iser_memory.c index afec40da9b58..29849c9e82e8 100644 --- a/drivers/infiniband/ulp/iser/iser_memory.c +++ b/drivers/infiniband/ulp/iser/iser_memory.c @@ -271,9 +271,8 @@ iser_reg_sig_mr(struct iscsi_iser_task *iser_task, wr->wr.send_flags = 0; wr->mr = mr; wr->key = mr->rkey; - wr->access = IB_ACCESS_LOCAL_WRITE | -IB_ACCESS_REMOTE_READ | -IB_ACCESS_REMOTE_WRITE; + wr->access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ | +IB_ACCESS_REMOTE_WRITE | IB_ACCESS_RELAXED_ORDERING; rsc->mr_valid = 1; sig_reg->sge.lkey = mr->lkey; @@ -318,9 +317,8 @@ static int iser_fast_reg_mr(struct iscsi_iser_task *iser_task, wr->wr.num_sge = 0; wr->mr = mr; wr->key = mr->rkey; - wr->access = IB_ACCESS_LOCAL_WRITE | -IB_ACCESS_REMOTE_WRITE | -IB_ACCESS_REMOTE_READ; + wr->access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE | +IB_ACCESS_REMOTE_READ | IB_ACCESS_RELAXED_ORDERING; rsc->mr_valid = 1; diff --git a/drivers/infiniband/ulp/iser/iser_verbs.c b/drivers/infiniband/ulp/iser/iser_verbs.c index 3c370ee25f2f..1e236b1cf29b 100644 --- a/drivers/infiniband/ulp/iser/iser_verbs.c +++ b/drivers/infiniband/ulp/iser/iser_verbs.c @@ -121,7 +121,8 @@ iser_create_fastreg_desc(struct iser_device *device, else mr_type = IB_MR_TYPE_MEM_REG; - desc->rsc.mr = ib_alloc_mr(pd, mr_type, size, 0); + desc->rsc.mr = ib_alloc_mr(pd, mr_type, size, + IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(desc->rsc.mr)) { ret = PTR_ERR(desc->rsc.mr); iser_err("Failed to allocate ib_fast_reg_mr err=%d\n", ret); @@ -129,7 +130,8 @@ iser_create_fastreg_desc(struct iser_device *device, } if (pi_enable) { - desc->rsc.sig_mr = ib_alloc_mr_integrity(pd, size, size, 0); + desc->rsc.sig_mr = ib_alloc_mr_integrity(pd, size, size, + IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(desc->rsc.sig_mr)) { ret = PTR_ERR(desc->rsc.sig_mr); iser_err("Failed to allocate sig_mr err=%d\n", ret); -- 2.30.2
[PATCH rdma-next 01/10] RDMA: Add access flags to ib_alloc_mr() and ib_mr_pool_init()
From: Avihai Horon Add access flags parameter to ib_alloc_mr() and to ib_mr_pool_init(), and refactor relevant code. This parameter is used to pass MR access flags during MR allocation. In the following patches, the new access flags parameter will be used to enable Relaxed Ordering for ib_alloc_mr() and ib_mr_pool_init() users. Signed-off-by: Avihai Horon Reviewed-by: Max Gurtovoy Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- drivers/infiniband/core/mr_pool.c | 7 +- drivers/infiniband/core/rw.c | 12 ++-- drivers/infiniband/core/verbs.c | 23 +-- drivers/infiniband/hw/bnxt_re/ib_verbs.c | 2 +- drivers/infiniband/hw/bnxt_re/ib_verbs.h | 2 +- drivers/infiniband/hw/cxgb4/iw_cxgb4.h| 2 +- drivers/infiniband/hw/cxgb4/mem.c | 2 +- drivers/infiniband/hw/hns/hns_roce_device.h | 2 +- drivers/infiniband/hw/hns/hns_roce_mr.c | 2 +- drivers/infiniband/hw/i40iw/i40iw_verbs.c | 3 +- drivers/infiniband/hw/mlx4/mlx4_ib.h | 2 +- drivers/infiniband/hw/mlx4/mr.c | 2 +- drivers/infiniband/hw/mlx5/mlx5_ib.h | 12 ++-- drivers/infiniband/hw/mlx5/mr.c | 61 drivers/infiniband/hw/mlx5/wr.c | 69 ++- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 2 +- drivers/infiniband/hw/qedr/verbs.c| 2 +- drivers/infiniband/hw/qedr/verbs.h| 2 +- drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 3 +- .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +- drivers/infiniband/sw/rdmavt/mr.c | 3 +- drivers/infiniband/sw/rdmavt/mr.h | 2 +- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 +- drivers/infiniband/sw/siw/siw_verbs.c | 2 +- drivers/infiniband/sw/siw/siw_verbs.h | 2 +- drivers/infiniband/ulp/iser/iser_verbs.c | 4 +- drivers/infiniband/ulp/rtrs/rtrs-clt.c| 2 +- drivers/infiniband/ulp/rtrs/rtrs-srv.c| 2 +- drivers/infiniband/ulp/srp/ib_srp.c | 2 +- drivers/nvme/host/rdma.c | 4 +- fs/cifs/smbdirect.c | 7 +- include/rdma/ib_verbs.h | 11 ++- include/rdma/mr_pool.h| 3 +- net/rds/ib_frmr.c | 2 +- net/smc/smc_ib.c | 2 +- net/sunrpc/xprtrdma/frwr_ops.c| 2 +- 37 files changed, 163 insertions(+), 105 deletions(-) diff --git a/drivers/infiniband/core/mr_pool.c b/drivers/infiniband/core/mr_pool.c index c0e2df128b34..b869c3487475 100644 --- a/drivers/infiniband/core/mr_pool.c +++ b/drivers/infiniband/core/mr_pool.c @@ -34,7 +34,8 @@ void ib_mr_pool_put(struct ib_qp *qp, struct list_head *list, struct ib_mr *mr) EXPORT_SYMBOL(ib_mr_pool_put); int ib_mr_pool_init(struct ib_qp *qp, struct list_head *list, int nr, - enum ib_mr_type type, u32 max_num_sg, u32 max_num_meta_sg) + enum ib_mr_type type, u32 max_num_sg, u32 max_num_meta_sg, + u32 access) { struct ib_mr *mr; unsigned long flags; @@ -43,9 +44,9 @@ int ib_mr_pool_init(struct ib_qp *qp, struct list_head *list, int nr, for (i = 0; i < nr; i++) { if (type == IB_MR_TYPE_INTEGRITY) mr = ib_alloc_mr_integrity(qp->pd, max_num_sg, - max_num_meta_sg); + max_num_meta_sg, access); else - mr = ib_alloc_mr(qp->pd, type, max_num_sg); + mr = ib_alloc_mr(qp->pd, type, max_num_sg, access); if (IS_ERR(mr)) { ret = PTR_ERR(mr); goto out; diff --git a/drivers/infiniband/core/rw.c b/drivers/infiniband/core/rw.c index a588c2038479..d5a0038e82a4 100644 --- a/drivers/infiniband/core/rw.c +++ b/drivers/infiniband/core/rw.c @@ -110,7 +110,7 @@ static int rdma_rw_init_one_mr(struct ib_qp *qp, u32 port_num, reg->reg_wr.wr.opcode = IB_WR_REG_MR; reg->reg_wr.mr = reg->mr; - reg->reg_wr.access = IB_ACCESS_LOCAL_WRITE; + reg->reg_wr.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_RELAXED_ORDERING; if (rdma_protocol_iwarp(qp->device, port_num)) reg->reg_wr.access |= IB_ACCESS_REMOTE_WRITE; count++; @@ -437,7 +437,8 @@ int rdma_rw_ctx_signature_init(struct rdma_rw_ctx *ctx, struct ib_qp *qp, ctx->reg->reg_wr.wr.wr_cqe = NULL; ctx->reg->reg_wr.wr.num_sge = 0; ctx->reg->reg_wr.wr.send_flags = 0; - ctx->reg->reg_wr.access = IB_ACCESS_LOCAL_WRITE; + ctx->reg->reg_wr.access = + IB_ACCESS_LOCAL_WRITE | IB_ACCESS_RELAXED_ORDERING; if (rdma_protocol_iwarp(qp->device, port_num)) ctx->reg->reg_wr.acces
[PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
From: Leon Romanovsky >From Avihai, Relaxed Ordering is a PCIe mechanism that relaxes the strict ordering imposed on PCI transactions, and thus, can improve performance. Until now, relaxed ordering could be set only by user space applications for user MRs. The following patch series enables relaxed ordering for the kernel ULPs as well. Relaxed ordering is an optional capability, and as such, it is ignored by vendors that don't support it. The following test results show the performance improvement achieved with relaxed ordering. The test was performed on a NVIDIA A100 in order to check performance of storage infrastructure over xprtrdma: Without Relaxed Ordering: READ: bw=16.5GiB/s (17.7GB/s), 16.5GiB/s-16.5GiB/s (17.7GB/s-17.7GB/s), io=1987GiB (2133GB), run=120422-120422msec With relaxed ordering: READ: bw=72.9GiB/s (78.2GB/s), 72.9GiB/s-72.9GiB/s (78.2GB/s-78.2GB/s), io=2367GiB (2542GB), run=32492-32492msec Thanks Avihai Horon (10): RDMA: Add access flags to ib_alloc_mr() and ib_mr_pool_init() RDMA/core: Enable Relaxed Ordering in __ib_alloc_pd() RDMA/iser: Enable Relaxed Ordering RDMA/rtrs: Enable Relaxed Ordering RDMA/srp: Enable Relaxed Ordering nvme-rdma: Enable Relaxed Ordering cifs: smbd: Enable Relaxed Ordering net/rds: Enable Relaxed Ordering net/smc: Enable Relaxed Ordering xprtrdma: Enable Relaxed Ordering drivers/infiniband/core/mr_pool.c | 7 +- drivers/infiniband/core/rw.c | 12 ++-- drivers/infiniband/core/verbs.c | 26 +-- drivers/infiniband/hw/bnxt_re/ib_verbs.c | 2 +- drivers/infiniband/hw/bnxt_re/ib_verbs.h | 2 +- drivers/infiniband/hw/cxgb4/iw_cxgb4.h| 2 +- drivers/infiniband/hw/cxgb4/mem.c | 2 +- drivers/infiniband/hw/hns/hns_roce_device.h | 2 +- drivers/infiniband/hw/hns/hns_roce_mr.c | 2 +- drivers/infiniband/hw/i40iw/i40iw_verbs.c | 3 +- drivers/infiniband/hw/mlx4/mlx4_ib.h | 2 +- drivers/infiniband/hw/mlx4/mr.c | 2 +- drivers/infiniband/hw/mlx5/mlx5_ib.h | 12 ++-- drivers/infiniband/hw/mlx5/mr.c | 61 drivers/infiniband/hw/mlx5/wr.c | 69 ++- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 2 +- drivers/infiniband/hw/qedr/verbs.c| 2 +- drivers/infiniband/hw/qedr/verbs.h| 2 +- drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 4 +- .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +- drivers/infiniband/sw/rdmavt/mr.c | 3 +- drivers/infiniband/sw/rdmavt/mr.h | 2 +- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 +- drivers/infiniband/sw/siw/siw_verbs.c | 2 +- drivers/infiniband/sw/siw/siw_verbs.h | 2 +- drivers/infiniband/ulp/iser/iser_memory.c | 10 ++- drivers/infiniband/ulp/iser/iser_verbs.c | 6 +- drivers/infiniband/ulp/rtrs/rtrs-clt.c| 6 +- drivers/infiniband/ulp/rtrs/rtrs-srv.c| 15 ++-- drivers/infiniband/ulp/srp/ib_srp.c | 8 +-- drivers/nvme/host/rdma.c | 19 +++-- fs/cifs/smbdirect.c | 17 +++-- include/rdma/ib_verbs.h | 11 ++- include/rdma/mr_pool.h| 3 +- net/rds/ib_frmr.c | 7 +- net/smc/smc_ib.c | 3 +- net/smc/smc_wr.c | 3 +- net/sunrpc/xprtrdma/frwr_ops.c| 10 +-- 39 files changed, 209 insertions(+), 140 deletions(-) -- 2.30.2
Re: [PATCH v5 15/19] regulator: Support ROHM BD71815 regulators
On Sun, 2021-04-04 at 19:21 +0300, Matti Vaittinen wrote: > On Fri, 2021-04-02 at 18:42 +0100, Mark Brown wrote: > > On Mon, Mar 29, 2021 at 03:59:51PM +0300, Matti Vaittinen wrote: > > > > Acked-by: Mark Brown > > > > but... > > Do you want me to respin the series or do you think this can be > applied > as-is and fixed by a follow-up? Actually, this was a bit stupid question. I will resend the series as I have also some small fixes to the GPIO. Best Regards Matti Vaittinen
[PATCH] mtd: rawnand: qcom: Use dma_mapping_error() for error check
dma_mapping_error() should be used for checking the error value of dma_map_resource() API. Signed-off-by: Manivannan Sadhasivam --- drivers/mtd/nand/raw/qcom_nandc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index fe74cf3aece5..07b3c156a802 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2990,7 +2990,7 @@ static int qcom_nandc_probe(struct platform_device *pdev) nandc->base_dma = dma_map_resource(dev, res->start, resource_size(res), DMA_BIDIRECTIONAL, 0); - if (!nandc->base_dma) + if (dma_mapping_error(dev, nandc->base_dma)) return -ENXIO; ret = qcom_nandc_alloc(nandc); -- 2.25.1
Re: [PATCH RESEND v1 3/4] powerpc/vdso: Separate vvar vma from vdso
On Wed, Mar 31, 2021 at 04:48:46PM +, Christophe Leroy wrote: > From: Dmitry Safonov > > Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front") > VVAR page is in front of the VDSO area. In result it breaks CRIU > (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]" > from /proc/../maps points at ELF/vdso image, rather than at VVAR data page. > Laurent made a patch to keep CRIU working (by reading aux vector). > But I think it still makes sence to separate two mappings into different > VMAs. It will also make ppc64 less "special" for userspace and as > a side-bonus will make VVAR page un-writable by debugger (which previously > would COW page and can be unexpected). > > I opportunistically Cc stable on it: I understand that usually such > stuff isn't a stable material, but that will allow us in CRIU have > one workaround less that is needed just for one release (v5.11) on > one platform (ppc64), which we otherwise have to maintain. > I wouldn't go as far as to say that the commit 511157ab641e is ABI > regression as no other userspace got broken, but I'd really appreciate > if it gets backported to v5.11 after v5.12 is released, so as not > to complicate already non-simple CRIU-vdso code. Thanks! > > Cc: Andrei Vagin Acked-by: Andrei Vagin > Cc: Andy Lutomirski > Cc: Benjamin Herrenschmidt > Cc: Christophe Leroy > Cc: Laurent Dufour > Cc: Michael Ellerman > Cc: Paul Mackerras > Cc: linuxppc-...@lists.ozlabs.org > Cc: sta...@vger.kernel.org # v5.11 > [1]: https://github.com/checkpoint-restore/criu/issues/1417 > Signed-off-by: Dmitry Safonov > Tested-by: Christophe Leroy > Signed-off-by: Christophe Leroy
Re: [PATCH RESEND v1 2/4] lib/vdso: Add vdso_data pointer as input to __arch_get_timens_vdso_data()
On Wed, Mar 31, 2021 at 04:48:45PM +, Christophe Leroy wrote: > For the same reason as commit e876f0b69dc9 ("lib/vdso: Allow > architectures to provide the vdso data pointer"), powerpc wants to > avoid calculation of relative position to code. > > As the timens_vdso_data is next page to vdso_data, provide > vdso_data pointer to __arch_get_timens_vdso_data() in order > to ease the calculation on powerpc in following patches. > Acked-by: Andrei Vagin > Signed-off-by: Christophe Leroy
Re: [PATCH] net/mlx5: fix kfree mismatch in indir_table.c
On Mon, Apr 05, 2021 at 10:53:39AM +0800, Xiaoming Ni wrote: > Memory allocated by kvzalloc() should be freed by kvfree(). > > Fixes: 34ca65352ddf2 ("net/mlx5: E-Switch, Indirect table infrastructur") > Signed-off-by: Xiaoming Ni > --- > .../net/ethernet/mellanox/mlx5/core/esw/indir_table.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > Thanks, Reviewed-by: Leon Romanovsky
Re: [PATCH RESEND v1 4/4] powerpc/vdso: Add support for time namespaces
On Wed, Mar 31, 2021 at 04:48:47PM +, Christophe Leroy wrote: > This patch adds the necessary glue to provide time namespaces. > > Things are mainly copied from ARM64. > > __arch_get_timens_vdso_data() calculates timens vdso data position > based on the vdso data position, knowing it is the next page in vvar. > This avoids having to redo the mflr/bcl/mflr/mtlr dance to locate > the page relative to running code position. > Acked-by: Andrei Vagin > Signed-off-by: Christophe Leroy
YOUR COMPENSATION MONEY
Dear Friend, I'm sorry but happy to inform you about my success in getting those funds transferred under the cooperation of a new partner from Vietnam though i tried my best to involve you in the business but God decided the whole situations. Presently i'm in Vietnam for investment projects with my own share of the total sum. Meanwhile, i didn't forget your past efforts and attempts to assist me in transferring those funds despite that it failed us some how. Now contact my secretary her name is Ms.Aisha Atan on her e-mail address here: ( aishaatansecreta...@gmail.com ) Ask her to send you the total of ( Hundred thousand united states dollars, $100.000.00 ) which i kept for your compensation for all the past efforts and attempts to assist me in this matter. I appreciated your efforts at that time very much. so feel free and get in touched with my secretary Ms.Aisha Atan and instruct her where to send the amount to you. Please do let me know immediately you receive it so that we can share the joy after all the sufferer at that time. In the moment, I’m very busy here because of the investment projects which I and the new partner are having at hand, finally, remembers that I had forwarded instruction to the secretary on your behalf to receive that money, so feel free to get in touch with Ms.Aisha Atan.She will send the amount to you without any delay. Regards
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Sun, Apr 04, 2021 at 09:01:25PM -0700, Paul E. McKenney wrote: > On Mon, Apr 05, 2021 at 04:08:55AM +0100, Matthew Wilcox wrote: > > On Sun, Apr 04, 2021 at 02:40:30PM -0700, Paul E. McKenney wrote: > > > On Sun, Apr 04, 2021 at 10:38:41PM +0200, Thomas Gleixner wrote: > > > > On Sun, Apr 04 2021 at 12:05, syzbot wrote: > > > > > > > > Cc + ... > > > > > > And a couple more... > > > > > > > > Hello, > > > > > > > > > > syzbot found the following issue on: > > > > > > > > > > HEAD commit:5e46d1b7 reiserfs: update > > > > > reiserfs_xattrs_initialized() co.. > > > > > git tree: upstream > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=1125f831d0 > > > > > kernel config: > > > > > https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d > > > > > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > > > commit: > > > > > Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com > > > > > > > > > > = > > > > > WARNING: suspicious RCU usage > > > > > 5.12.0-rc5-syzkaller #0 Not tainted > > > > > - > > > > > kernel/sched/core.c:8294 Illegal context switch in RCU-sched > > > > > read-side critical section! > > > > > > > > > > other info that might help us debug this: > > > > > > > > > > > > > > > rcu_scheduler_active = 2, debug_locks = 0 > > > > > 3 locks held by syz-executor.4/8418: > > > > > #0: > > > > > 8880751d2b28 > > > > > ( > > > > > &p->pi_lock > > > > > ){-.-.}-{2:2} > > > > > , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345 > > > > > #1: > > > > > 8880b9d35258 > > > > > ( > > > > > &rq->lock > > > > > ){-.-.}-{2:2} > > > > > , at: rq_lock kernel/sched/sched.h:1321 [inline] > > > > > , at: ttwu_queue kernel/sched/core.c:3184 [inline] > > > > > , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464 > > > > > #2: 8880b9d1f948 (&per_cpu_ptr(group->pcpu, > > > > > cpu)->seq){-.-.}-{0:0}, at: psi_task_change+0x142/0x220 > > > > > kernel/sched/psi.c:807 > > > > > > This looks similar to > > > syzbot+dde0cc33951735441...@syzkaller.appspotmail.com > > > in that rcu_sleep_check() sees an RCU lock held, but the later call to > > > lockdep_print_held_locks() does not. Did something change recently that > > > could let the ->lockdep_depth counter get out of sync with the actual > > > number of locks held? > > > > Dmitri had a different theory here: > > > > https://groups.google.com/g/syzkaller-bugs/c/FmYvfZCZzqA/m/nc2CXUgsAgAJ > > There is always room for more than one bug. ;-) > > He says "one-off false positives". I was afraid of that... And both the examples I have been copied on today are consistent with debug_locks getting zeroed (e.g., via a call to __debug_locks_off()) in the midst of a call to rcu_sleep_check(). But I would expect to see a panic or another splat if that were to happen. Dmitry's example did have an additional splat, but I would expect the RCU-related one to come second. Again, there is always room for more than one bug. On the other hand, there are a lot more callers to debug_locks_off() than there were last I looked into this. And both of these splats are consistent with an interrupt in the middle of rcu_sleep_check(), and that interrupt's handler invoking debug_locks_off(), but without printing anything to the console. Does that sequence of events ring a bell for anyone? If this is the new normal, I could make RCU_LOCKDEP_WARN() recheck debug_lockdep_rcu_enabled() after evaluating the condition, but with a memory barrier immediately before the recheck. But I am not at all excited by doing this on speculation. Especially given that doing so might be covering up some other bug. Thanx, Paul
Re: [PATCH] Kbuild: Update config_data.gz only if KCONFIG_CONFIG materially changed
On 4/2/2021 10:11 PM, Masahiro Yamada wrote: On Fri, Apr 2, 2021 at 7:45 AM Elliot Berman wrote: If you update the timestamp of KCONFIG_CONFIG without actually changing anything, config_data.gz is re-generated and causes vmlinux to re-link. When Link Time Optimization is enabled, unnecessary re-linking of vmlinux is highly desirable since it adds several minutes to build time. Avoid touching config_data.gz by using filechk to compare the existing config_data.gz and update only if it changed. The .config can be touched, for instance, by a build script which installs the default defconfig and then applies a defconfig fragment on top. For a simple example on my x86 machine, I modified x86 default defconfig to set CONFIG_IKCONFIG=y and run: make -j50 defconfig tiny.config vmlinux make -j50 defconfig tiny.config vmlinux With this patch, vmlinux is not re-built as a result of config_data.gz change. Signed-off-by: Elliot Berman --- kernel/Makefile | 2 +- scripts/Makefile.lib | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/Makefile b/kernel/Makefile index 320f1f3..bd4e558 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -140,7 +140,7 @@ $(obj)/configs.o: $(obj)/config_data.gz targets += config_data.gz $(obj)/config_data.gz: $(KCONFIG_CONFIG) FORCE - $(call if_changed,gzip) + $(call filechk,gzip) I do not think this is the right approach because gzip is executed every time, even if the time stamp is not changed. Since .config is relatively small, gzip was quickly producing the same binary in multiple runs on my host. I thought about following gen_ikheaders.sh approach of comparing the md5sum, but I felt it was more complex than using filechk and re-compressing every time. I'll send a v2 tomorrow which follows gen_ikheaders.sh approach. $(obj)/kheaders.o: $(obj)/kheaders_data.tar.xz diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index a4fbaf8..81d3ec1 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -282,6 +282,8 @@ cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $(OBJCOPYFLAGS_$(@F)) $< $@ quiet_cmd_gzip = GZIP$@ cmd_gzip = cat $(real-prereqs) | $(KGZIP) -n -f -9 > $@ +filechk_gzip = cat $(real-prereqs) | $(KGZIP) -n -f -9 + # DTC # --- DTC ?= $(objtree)/scripts/dtc/dtc -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Mon, Apr 05, 2021 at 04:08:55AM +0100, Matthew Wilcox wrote: > On Sun, Apr 04, 2021 at 02:40:30PM -0700, Paul E. McKenney wrote: > > On Sun, Apr 04, 2021 at 10:38:41PM +0200, Thomas Gleixner wrote: > > > On Sun, Apr 04 2021 at 12:05, syzbot wrote: > > > > > > Cc + ... > > > > And a couple more... > > > > > > Hello, > > > > > > > > syzbot found the following issue on: > > > > > > > > HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized() > > > > co.. > > > > git tree: upstream > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1125f831d0 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d > > > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > > commit: > > > > Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com > > > > > > > > = > > > > WARNING: suspicious RCU usage > > > > 5.12.0-rc5-syzkaller #0 Not tainted > > > > - > > > > kernel/sched/core.c:8294 Illegal context switch in RCU-sched read-side > > > > critical section! > > > > > > > > other info that might help us debug this: > > > > > > > > > > > > rcu_scheduler_active = 2, debug_locks = 0 > > > > 3 locks held by syz-executor.4/8418: > > > > #0: > > > > 8880751d2b28 > > > > ( > > > > &p->pi_lock > > > > ){-.-.}-{2:2} > > > > , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345 > > > > #1: > > > > 8880b9d35258 > > > > ( > > > > &rq->lock > > > > ){-.-.}-{2:2} > > > > , at: rq_lock kernel/sched/sched.h:1321 [inline] > > > > , at: ttwu_queue kernel/sched/core.c:3184 [inline] > > > > , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464 > > > > #2: 8880b9d1f948 (&per_cpu_ptr(group->pcpu, > > > > cpu)->seq){-.-.}-{0:0}, at: psi_task_change+0x142/0x220 > > > > kernel/sched/psi.c:807 > > > > This looks similar to syzbot+dde0cc33951735441...@syzkaller.appspotmail.com > > in that rcu_sleep_check() sees an RCU lock held, but the later call to > > lockdep_print_held_locks() does not. Did something change recently that > > could let the ->lockdep_depth counter get out of sync with the actual > > number of locks held? > > Dmitri had a different theory here: > > https://groups.google.com/g/syzkaller-bugs/c/FmYvfZCZzqA/m/nc2CXUgsAgAJ There is always room for more than one bug. ;-) He says "one-off false positives". I was afraid of that... Thanx, Paul
Re: [PATCH 1/1] of: properly check for error returned by fdt_get_name()
Hi Guenter, Can you please test this patch to see if it prevents the crash on openrisc that you reported in https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/ Just after start of unittest you should see a warning about testcases. Thanks, Frank On 4/4/21 10:28 PM, frowand.l...@gmail.com wrote: > From: Frank Rowand > > fdt_get_name() returns error values via a parameter pointer > instead of in function return. Fix check for this error value > in populate_node() and callers of populate_node(). > > Chasing up the caller tree showed callers of various functions > failing to initialize the value of pointer parameters that > can return error values. Initialize those values to NULL. > > The bug was introduced by > commit e6a6928c3ea1 ("of/fdt: Convert FDT functions to use libfdt") > but this patch can not be backported directly to that commit > because the relevant code has further been restructured by > commit dfbd4c6eff35 ("drivers/of: Split unflatten_dt_node()") > > The bug became visible by triggering a crash on openrisc with: > commit 79edff12060f ("scripts/dtc: Update to upstream version > v1.6.0-51-g183df9e9c2b9") > as reported in: > https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/ > > Fixes: commit 79edff12060f ("scripts/dtc: Update to upstream version > v1.6.0-51-g183df9e9c2b9") > Reported-by: Guenter Roeck > Signed-off-by: Frank Rowand > > --- > > This patch papers over the unaligned pointer passed to > of_fdt_unflatten_tree() bug that Guenter reported in > https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/ > > I will create a separate patch to fix that problem. > > drivers/of/fdt.c | 36 +++- > drivers/of/overlay.c | 2 +- > drivers/of/unittest.c | 15 ++- > 3 files changed, 34 insertions(+), 19 deletions(-) > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index dcc1dd96911a..adb26aff481d 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -205,7 +205,7 @@ static void populate_properties(const void *blob, > *pprev = NULL; > } > > -static bool populate_node(const void *blob, > +static int populate_node(const void *blob, > int offset, > void **mem, > struct device_node *dad, > @@ -214,24 +214,24 @@ static bool populate_node(const void *blob, > { > struct device_node *np; > const char *pathp; > - unsigned int l, allocl; > + int len; > > - pathp = fdt_get_name(blob, offset, &l); > + pathp = fdt_get_name(blob, offset, &len); > if (!pathp) { > *pnp = NULL; > - return false; > + return len; > } > > - allocl = ++l; > + len++; > > - np = unflatten_dt_alloc(mem, sizeof(struct device_node) + allocl, > + np = unflatten_dt_alloc(mem, sizeof(struct device_node) + len, > __alignof__(struct device_node)); > if (!dryrun) { > char *fn; > of_node_init(np); > np->full_name = fn = ((char *)np) + sizeof(*np); > > - memcpy(fn, pathp, l); > + memcpy(fn, pathp, len); > > if (dad != NULL) { > np->parent = dad; > @@ -295,6 +295,7 @@ static int unflatten_dt_nodes(const void *blob, > struct device_node *nps[FDT_MAX_DEPTH]; > void *base = mem; > bool dryrun = !base; > + int ret; > > if (nodepp) > *nodepp = NULL; > @@ -322,9 +323,10 @@ static int unflatten_dt_nodes(const void *blob, > !of_fdt_device_is_available(blob, offset)) > continue; > > - if (!populate_node(blob, offset, &mem, nps[depth], > -&nps[depth+1], dryrun)) > - return mem - base; > + ret = populate_node(blob, offset, &mem, nps[depth], > +&nps[depth+1], dryrun); > + if (ret < 0) > + return ret; > > if (!dryrun && nodepp && !*nodepp) > *nodepp = nps[depth+1]; > @@ -372,6 +374,10 @@ void *__unflatten_device_tree(const void *blob, > { > int size; > void *mem; > + int ret; > + > + if (mynodes) > + *mynodes = NULL; > > pr_debug(" -> unflatten_device_tree()\n"); > > @@ -392,7 +398,7 @@ void *__unflatten_device_tree(const void *blob, > > /* First pass, scan for size */ > size = unflatten_dt_nodes(blob, NULL, dad, NULL); > - if (size < 0) > + if (size <= 0) > return NULL; > > size = ALIGN(size, 4); > @@ -410,12 +416,16 @@ void *__unflatten_device_tree(const void *blob, > pr_debug(" unflattening %p...\n", mem); > > /* Second pass, do actual unflattening */ > - unflatten_dt_nodes(blob, mem, dad, mynodes); > + ret = unflatten_dt_nodes(b
[PATCH 10/10] tty: tty_ldisc: Remove the repeated word 'the'
Remove the repeated word 'the' following advice of checkpatch.pl Signed-off-by: Xiaofei Tan --- drivers/tty/tty_ldisc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c index 56e67f7..fdc4fa3 100644 --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -147,7 +147,7 @@ static int tty_ldisc_autoload = IS_BUILTIN(CONFIG_LDISC_AUTOLOAD); * Returns: -EINVAL if the discipline index is not [N_TTY..NR_LDISCS] or * if the discipline is not registered * -EAGAIN if request_module() failed to load or register the - * the discipline + * discipline * -ENOMEM if allocation failure * * Otherwise, returns a pointer to the discipline and bumps the -- 2.8.1
[PATCH 06/10] tty: tty_ldisc: Fix an issue of code indent should use tabs
Fix an issue of code indent should use tabs, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/tty_ldisc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c index 1ba74d6..2992319 100644 --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -459,7 +459,7 @@ static int tty_ldisc_open(struct tty_struct *tty, struct tty_ldisc *ld) WARN_ON(test_and_set_bit(TTY_LDISC_OPEN, &tty->flags)); if (ld->ops->open) { int ret; -/* BTM here locks versus a hangup event */ + /* BTM here locks versus a hangup event */ ret = ld->ops->open(tty); if (ret) clear_bit(TTY_LDISC_OPEN, &tty->flags); -- 2.8.1
[PATCH 08/10] tty: tty_ldisc: Fix coding style issues of block comments
Fix coding style issues of block comments, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/tty_ldisc.c | 32 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c index df0b589..874d238 100644 --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -529,9 +529,11 @@ static void tty_ldisc_restore(struct tty_struct *tty, struct tty_ldisc *old) const char *name = tty_name(tty); pr_warn("Falling back ldisc for %s.\n", name); - /* The traditional behaviour is to fall back to N_TTY, we - want to avoid falling back to N_NULL unless we have no - choice to avoid the risk of breaking anything */ + /* +* The traditional behaviour is to fall back to N_TTY, we +* want to avoid falling back to N_NULL unless we have no +* choice to avoid the risk of breaking anything +*/ if (tty_ldisc_failto(tty, N_TTY) < 0 && tty_ldisc_failto(tty, N_NULL) < 0) panic("Couldn't open N_NULL ldisc for %s.", name); @@ -600,17 +602,21 @@ int tty_set_ldisc(struct tty_struct *tty, int disc) up_read(&tty->termios_rwsem); } - /* At this point we hold a reference to the new ldisc and a - reference to the old ldisc, or we hold two references to - the old ldisc (if it was restored as part of error cleanup - above). In either case, releasing a single reference from - the old ldisc is correct. */ + /* +* At this point we hold a reference to the new ldisc and a +* reference to the old ldisc, or we hold two references to +* the old ldisc (if it was restored as part of error cleanup +* above). In either case, releasing a single reference from +* the old ldisc is correct. +*/ new_ldisc = old_ldisc; out: tty_ldisc_unlock(tty); - /* Restart the work queue in case no characters kick it off. Safe if - already running */ + /* +* Restart the work queue in case no characters kick it off. Safe if +* already running +*/ tty_buffer_restart_work(tty->port); err: tty_ldisc_put(new_ldisc); /* drop the extra reference */ @@ -812,8 +818,10 @@ void tty_ldisc_release(struct tty_struct *tty) tty_ldisc_kill(o_tty); tty_ldisc_unlock_pair(tty, o_tty); - /* And the memory resources remaining (buffers, termios) will be - disposed of when the kref hits zero */ + /* +* And the memory resources remaining (buffers, termios) will be +* disposed of when the kref hits zero +*/ tty_ldisc_debug(tty, "released\n"); } -- 2.8.1
[PATCH 09/10] tty: tty_ldisc: Do not use assignment in if condition
Do not use assignment in if condition following the advice of checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/tty_ldisc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c index 874d238..56e67f7 100644 --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -508,7 +508,8 @@ static int tty_ldisc_failto(struct tty_struct *tty, int ld) return PTR_ERR(disc); tty->ldisc = disc; tty_set_termios_ldisc(tty, ld); - if ((r = tty_ldisc_open(tty, disc)) < 0) + r = tty_ldisc_open(tty, disc); + if (r < 0) tty_ldisc_put(disc); return r; } -- 2.8.1
[PATCH 01/10] tty/sysrq: Add a blank line after declarations
Add a blank line after declarations, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/sysrq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c index 959f9e1..0372ed7 100644 --- a/drivers/tty/sysrq.c +++ b/drivers/tty/sysrq.c @@ -118,6 +118,7 @@ static const struct sysrq_key_op sysrq_loglevel_op = { static void sysrq_handle_SAK(int key) { struct work_struct *SAK_work = &vc_cons[fg_console].SAK_work; + schedule_work(SAK_work); } static const struct sysrq_key_op sysrq_SAK_op = { -- 2.8.1
[PATCH 05/10] tty: tty_jobctrl: Remove spaces before tabs
Remove spaces before tabs following the advice of checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/tty_jobctrl.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/tty/tty_jobctrl.c b/drivers/tty/tty_jobctrl.c index 4d78422..2f7d4ba 100644 --- a/drivers/tty/tty_jobctrl.c +++ b/drivers/tty/tty_jobctrl.c @@ -244,10 +244,10 @@ int tty_signal_session_leader(struct tty_struct *tty, int exit_session) * it wants to disassociate itself from its controlling tty. * * It performs the following functions: - * (1) Sends a SIGHUP and SIGCONT to the foreground process group - * (2) Clears the tty from being controlling the session - * (3) Clears the controlling tty for all processes in the - * session group. + * (1) Sends a SIGHUP and SIGCONT to the foreground process group + * (2) Clears the tty from being controlling the session + * (3) Clears the controlling tty for all processes in the + * session group. * * The argument on_exit is set to 1 if called when a process is * exiting; it is 0 if called by the ioctl TIOCNOTTY. -- 2.8.1
[PATCH 04/10] tty: tty_jobctrl: Fix coding style issues of block comments
Fix coding style issues of block comments, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/tty_jobctrl.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/tty/tty_jobctrl.c b/drivers/tty/tty_jobctrl.c index 86070f7..4d78422 100644 --- a/drivers/tty/tty_jobctrl.c +++ b/drivers/tty/tty_jobctrl.c @@ -204,8 +204,10 @@ int tty_signal_session_leader(struct tty_struct *tty, int exit_session) spin_lock_irq(&p->sighand->siglock); if (p->signal->tty == tty) { p->signal->tty = NULL; - /* We defer the dereferences outside fo - the tasklist lock */ + /* +* We defer the dereferences outside fo +* the tasklist lock +*/ refs++; } if (!p->signal->leader) { @@ -328,9 +330,11 @@ void disassociate_ctty(int on_exit) */ void no_tty(void) { - /* FIXME: Review locking here. The tty_lock never covered any race - between a new association and proc_clear_tty but possible we need - to protect against this anyway */ + /* +* FIXME: Review locking here. The tty_lock never covered any race +* between a new association and proc_clear_tty but possible we need +* to protect against this anyway +*/ struct task_struct *tsk = current; disassociate_ctty(0); @@ -536,7 +540,7 @@ static int tiocgsid(struct tty_struct *tty, struct tty_struct *real_tty, pid_t _ /* * (tty == real_tty) is a cheap way of * testing if the tty is NOT a master pty. - */ +*/ if (tty == real_tty && current->signal->tty != real_tty) return -ENOTTY; -- 2.8.1
[PATCH 07/10] tty: tty_ldisc: Add a blank line after declarations
Add a blank line after declarations, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/tty_ldisc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c index 2992319..df0b589 100644 --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -771,6 +771,7 @@ void tty_ldisc_hangup(struct tty_struct *tty, bool reinit) int tty_ldisc_setup(struct tty_struct *tty, struct tty_struct *o_tty) { int retval = tty_ldisc_open(tty, tty->ldisc); + if (retval) return retval; @@ -829,6 +830,7 @@ EXPORT_SYMBOL_GPL(tty_ldisc_release); int tty_ldisc_init(struct tty_struct *tty) { struct tty_ldisc *ld = tty_ldisc_get(tty, N_TTY); + if (IS_ERR(ld)) return PTR_ERR(ld); tty->ldisc = ld; -- 2.8.1
[PATCH 02/10] tty/sysrq: Fix issues of code indent should use tabs
Fix issues of code indent should use tabs, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/sysrq.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c index 0372ed7..1ece100 100644 --- a/drivers/tty/sysrq.c +++ b/drivers/tty/sysrq.c @@ -548,22 +548,22 @@ static int sysrq_key_table_key2index(int key) */ static const struct sysrq_key_op *__sysrq_get_key_op(int key) { -const struct sysrq_key_op *op_p = NULL; -int i; + const struct sysrq_key_op *op_p = NULL; + int i; i = sysrq_key_table_key2index(key); if (i != -1) - op_p = sysrq_key_table[i]; + op_p = sysrq_key_table[i]; -return op_p; + return op_p; } static void __sysrq_put_key_op(int key, const struct sysrq_key_op *op_p) { -int i = sysrq_key_table_key2index(key); + int i = sysrq_key_table_key2index(key); -if (i != -1) -sysrq_key_table[i] = op_p; + if (i != -1) + sysrq_key_table[i] = op_p; } void __handle_sysrq(int key, bool check_mask) @@ -587,8 +587,8 @@ void __handle_sysrq(int key, bool check_mask) orig_log_level = console_loglevel; console_loglevel = CONSOLE_LOGLEVEL_DEFAULT; -op_p = __sysrq_get_key_op(key); -if (op_p) { + op_p = __sysrq_get_key_op(key); + if (op_p) { /* * Should we check for enabled operations (/proc/sysrq-trigger * should not) and is the invoked operation enabled? @@ -637,13 +637,13 @@ static int sysrq_reset_downtime_ms; /* Simple translation table for the SysRq keys */ static const unsigned char sysrq_xlate[KEY_CNT] = -"\000\0331234567890-=\177\t"/* 0x00 - 0x0f */ -"qwertyuiop[]\r\000as" /* 0x10 - 0x1f */ -"dfghjkl;'`\000\\zxcv" /* 0x20 - 0x2f */ -"bnm,./\000*\000 \000\201\202\203\204\205" /* 0x30 - 0x3f */ -"\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */ -"230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /* 0x50 - 0x5f */ -"\r\000/"; /* 0x60 - 0x6f */ + "\000\0331234567890-=\177\t"/* 0x00 - 0x0f */ + "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */ + "dfghjkl;'`\000\\zxcv" /* 0x20 - 0x2f */ + "bnm,./\000*\000 \000\201\202\203\204\205" /* 0x30 - 0x3f */ + "\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */ + "230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /* 0x50 - 0x5f */ + "\r\000/"; /* 0x60 - 0x6f */ struct sysrq_state { struct input_handle handle; @@ -1108,7 +1108,7 @@ int sysrq_toggle_support(int enable_mask) EXPORT_SYMBOL_GPL(sysrq_toggle_support); static int __sysrq_swap_key_ops(int key, const struct sysrq_key_op *insert_op_p, -const struct sysrq_key_op *remove_op_p) + const struct sysrq_key_op *remove_op_p) { int retval; -- 2.8.1
[PATCH 00/10] tty: Fix some coding style issues
Fix some issues reported by checkpatch.pl. All of them are coding style issues, no function changes. Xiaofei Tan (10): tty/sysrq: Add a blank line after declarations tty/sysrq: Fix issues of code indent should use tabs tty: tty_jobctrl: Add a blank line after declarations tty: tty_jobctrl: Fix coding style issues of block comments tty: tty_jobctrl: Remove spaces before tabs tty: tty_ldisc: Fix an issue of code indent should use tabs tty: tty_ldisc: Add a blank line after declarations tty: tty_ldisc: Fix coding style issues of block comments tty: tty_ldisc: Do not use assignment in if condition tty: tty_ldisc: Remove the repeated word 'the' drivers/tty/sysrq.c | 35 ++- drivers/tty/tty_jobctrl.c | 29 +++-- drivers/tty/tty_ldisc.c | 41 ++--- 3 files changed, 63 insertions(+), 42 deletions(-) -- 2.8.1
[PATCH 03/10] tty: tty_jobctrl: Add a blank line after declarations
Add a blank line after declarations, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/tty_jobctrl.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/tty/tty_jobctrl.c b/drivers/tty/tty_jobctrl.c index 4b751b9..86070f7 100644 --- a/drivers/tty/tty_jobctrl.c +++ b/drivers/tty/tty_jobctrl.c @@ -75,6 +75,7 @@ void proc_clear_tty(struct task_struct *p) { unsigned long flags; struct tty_struct *tty; + spin_lock_irqsave(&p->sighand->siglock, flags); tty = p->signal->tty; p->signal->tty = NULL; @@ -173,6 +174,7 @@ EXPORT_SYMBOL_GPL(get_current_tty); void session_clear_tty(struct pid *session) { struct task_struct *p; + do_each_pid_task(session, PIDTYPE_SID, p) { proc_clear_tty(p); } while_each_pid_task(session, PIDTYPE_SID, p); @@ -269,6 +271,7 @@ void disassociate_ctty(int on_exit) tty_vhangup_session(tty); } else { struct pid *tty_pgrp = tty_get_pgrp(tty); + if (tty_pgrp) { kill_pgrp(tty_pgrp, SIGHUP, on_exit); if (!on_exit) @@ -280,6 +283,7 @@ void disassociate_ctty(int on_exit) } else if (on_exit) { struct pid *old_pgrp; + spin_lock_irq(¤t->sighand->siglock); old_pgrp = current->signal->tty_old_pgrp; current->signal->tty_old_pgrp = NULL; @@ -328,6 +332,7 @@ void no_tty(void) between a new association and proc_clear_tty but possible we need to protect against this anyway */ struct task_struct *tsk = current; + disassociate_ctty(0); proc_clear_tty(tsk); } -- 2.8.1
[PATCH 1/1] of: properly check for error returned by fdt_get_name()
From: Frank Rowand fdt_get_name() returns error values via a parameter pointer instead of in function return. Fix check for this error value in populate_node() and callers of populate_node(). Chasing up the caller tree showed callers of various functions failing to initialize the value of pointer parameters that can return error values. Initialize those values to NULL. The bug was introduced by commit e6a6928c3ea1 ("of/fdt: Convert FDT functions to use libfdt") but this patch can not be backported directly to that commit because the relevant code has further been restructured by commit dfbd4c6eff35 ("drivers/of: Split unflatten_dt_node()") The bug became visible by triggering a crash on openrisc with: commit 79edff12060f ("scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9") as reported in: https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/ Fixes: commit 79edff12060f ("scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9") Reported-by: Guenter Roeck Signed-off-by: Frank Rowand --- This patch papers over the unaligned pointer passed to of_fdt_unflatten_tree() bug that Guenter reported in https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/ I will create a separate patch to fix that problem. drivers/of/fdt.c | 36 +++- drivers/of/overlay.c | 2 +- drivers/of/unittest.c | 15 ++- 3 files changed, 34 insertions(+), 19 deletions(-) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index dcc1dd96911a..adb26aff481d 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -205,7 +205,7 @@ static void populate_properties(const void *blob, *pprev = NULL; } -static bool populate_node(const void *blob, +static int populate_node(const void *blob, int offset, void **mem, struct device_node *dad, @@ -214,24 +214,24 @@ static bool populate_node(const void *blob, { struct device_node *np; const char *pathp; - unsigned int l, allocl; + int len; - pathp = fdt_get_name(blob, offset, &l); + pathp = fdt_get_name(blob, offset, &len); if (!pathp) { *pnp = NULL; - return false; + return len; } - allocl = ++l; + len++; - np = unflatten_dt_alloc(mem, sizeof(struct device_node) + allocl, + np = unflatten_dt_alloc(mem, sizeof(struct device_node) + len, __alignof__(struct device_node)); if (!dryrun) { char *fn; of_node_init(np); np->full_name = fn = ((char *)np) + sizeof(*np); - memcpy(fn, pathp, l); + memcpy(fn, pathp, len); if (dad != NULL) { np->parent = dad; @@ -295,6 +295,7 @@ static int unflatten_dt_nodes(const void *blob, struct device_node *nps[FDT_MAX_DEPTH]; void *base = mem; bool dryrun = !base; + int ret; if (nodepp) *nodepp = NULL; @@ -322,9 +323,10 @@ static int unflatten_dt_nodes(const void *blob, !of_fdt_device_is_available(blob, offset)) continue; - if (!populate_node(blob, offset, &mem, nps[depth], - &nps[depth+1], dryrun)) - return mem - base; + ret = populate_node(blob, offset, &mem, nps[depth], + &nps[depth+1], dryrun); + if (ret < 0) + return ret; if (!dryrun && nodepp && !*nodepp) *nodepp = nps[depth+1]; @@ -372,6 +374,10 @@ void *__unflatten_device_tree(const void *blob, { int size; void *mem; + int ret; + + if (mynodes) + *mynodes = NULL; pr_debug(" -> unflatten_device_tree()\n"); @@ -392,7 +398,7 @@ void *__unflatten_device_tree(const void *blob, /* First pass, scan for size */ size = unflatten_dt_nodes(blob, NULL, dad, NULL); - if (size < 0) + if (size <= 0) return NULL; size = ALIGN(size, 4); @@ -410,12 +416,16 @@ void *__unflatten_device_tree(const void *blob, pr_debug(" unflattening %p...\n", mem); /* Second pass, do actual unflattening */ - unflatten_dt_nodes(blob, mem, dad, mynodes); + ret = unflatten_dt_nodes(blob, mem, dad, mynodes); + if (be32_to_cpup(mem + size) != 0xdeadbeef) pr_warn("End of tree marker overwritten: %08x\n", be32_to_cpup(mem + size)); - if (detached && mynodes) { + if (ret <= 0) + return NULL; + + if (detached && mynodes && *mynodes) { of_node_set_flag(*mynodes, OF_DETACHED); pr_debug("unflattened tree is detached\n"); } dif
[PATCH] of: property: do not create device links from *nr-gpios
[,]nr-gpios property is used by some GPIO drivers[0] to indicate the number of GPIOs present on a system, not define a GPIO. nr-gpios is not configured by #gpio-cells and can't be parsed along with other "*-gpios" properties. scripts/dtc/checks.c also has a special case for nr-gpio{s}. However, nr-gpio is not really special, so we only need to fix nr-gpios suffix here. [0]: nr-gpios is referenced in Documentation/devicetree/bindings/gpio: - gpio-adnp.txt - gpio-xgene-sb.txt - gpio-xlp.txt - snps,dw-apb-gpio.yaml Fixes errors such as: OF: /palmbus@30/gpio@600: could not find phandle Call Trace: of_phandle_iterator_next+0x8c/0x16c __of_parse_phandle_with_args+0x38/0xb8 of_parse_phandle_with_args+0x28/0x3c parse_suffix_prop_cells+0x80/0xac parse_gpios+0x20/0x2c of_link_to_suppliers+0x18c/0x288 of_link_to_suppliers+0x1fc/0x288 device_add+0x4e0/0x734 of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x170/0x214 of_platform_populate+0x88/0xf4 __dt_register_buses+0xbc/0xf0 plat_of_setup+0x1c/0x34 Fixes: 7f00be96f125 ("of: property: Add device link support for interrupt-parent, dmas and -gpio(s)") Signed-off-by: Ilya Lipnitskiy Cc: Saravana Kannan Cc: # 5.5.x --- drivers/of/property.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/of/property.c b/drivers/of/property.c index 2bb3158c9e43..24672c295603 100644 --- a/drivers/of/property.c +++ b/drivers/of/property.c @@ -1271,7 +1271,16 @@ DEFINE_SIMPLE_PROP(pinctrl8, "pinctrl-8", NULL) DEFINE_SIMPLE_PROP(remote_endpoint, "remote-endpoint", NULL) DEFINE_SUFFIX_PROP(regulators, "-supply", NULL) DEFINE_SUFFIX_PROP(gpio, "-gpio", "#gpio-cells") -DEFINE_SUFFIX_PROP(gpios, "-gpios", "#gpio-cells") + +static struct device_node *parse_gpios(struct device_node *np, + const char *prop_name, int index) +{ + if (!strcmp_suffix(prop_name, "nr-gpios")) + return NULL; + + return parse_suffix_prop_cells(np, prop_name, index, "-gpios", + "#gpio-cells"); +} static struct device_node *parse_iommu_maps(struct device_node *np, const char *prop_name, int index) -- 2.31.1
Re: [ovs-dev] [PATCH net] openvswitch: fix send of uninitialized stack memory in ct limit reply
On Mon, Apr 5, 2021 at 2:01 AM Ilya Maximets wrote: > > CC: ovs-dev > > On 4/4/21 7:50 PM, Ilya Maximets wrote: > > 'struct ovs_zone_limit' has more members than initialized in > > ovs_ct_limit_get_default_limit(). The rest of the memory is a random > > kernel stack content that ends up being sent to userspace. > > > > Fix that by using designated initializer that will clear all > > non-specified fields. > > > > Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") > > Signed-off-by: Ilya Maximets > > --- > > net/openvswitch/conntrack.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c > > index c29b0ef1fc27..cadb6a29b285 100644 > > --- a/net/openvswitch/conntrack.c > > +++ b/net/openvswitch/conntrack.c > > @@ -2032,10 +2032,10 @@ static int ovs_ct_limit_del_zone_limit(struct > > nlattr *nla_zone_limit, > > static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info, > > struct sk_buff *reply) > > { > > - struct ovs_zone_limit zone_limit; > > - > > - zone_limit.zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE; > > - zone_limit.limit = info->default_limit; > > + struct ovs_zone_limit zone_limit = { > > + .zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE, > > + .limit = info->default_limit, > > + }; I review the code, userspace don't use the count of ovs_zone_lime struct, but this patch looks to to me. Thanks Ilya. Acked-by: Tonghao Zhang > > return nla_put_nohdr(reply, sizeof(zone_limit), &zone_limit); > > } > > > > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev -- Best regards, Tonghao
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Sun, Apr 04, 2021 at 02:40:30PM -0700, Paul E. McKenney wrote: > On Sun, Apr 04, 2021 at 10:38:41PM +0200, Thomas Gleixner wrote: > > On Sun, Apr 04 2021 at 12:05, syzbot wrote: > > > > Cc + ... > > And a couple more... > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized() > > > co.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1125f831d0 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > commit: > > > Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com > > > > > > = > > > WARNING: suspicious RCU usage > > > 5.12.0-rc5-syzkaller #0 Not tainted > > > - > > > kernel/sched/core.c:8294 Illegal context switch in RCU-sched read-side > > > critical section! > > > > > > other info that might help us debug this: > > > > > > > > > rcu_scheduler_active = 2, debug_locks = 0 > > > 3 locks held by syz-executor.4/8418: > > > #0: > > > 8880751d2b28 > > > ( > > > &p->pi_lock > > > ){-.-.}-{2:2} > > > , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345 > > > #1: > > > 8880b9d35258 > > > ( > > > &rq->lock > > > ){-.-.}-{2:2} > > > , at: rq_lock kernel/sched/sched.h:1321 [inline] > > > , at: ttwu_queue kernel/sched/core.c:3184 [inline] > > > , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464 > > > #2: 8880b9d1f948 (&per_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0}, > > > at: psi_task_change+0x142/0x220 kernel/sched/psi.c:807 > > This looks similar to syzbot+dde0cc33951735441...@syzkaller.appspotmail.com > in that rcu_sleep_check() sees an RCU lock held, but the later call to > lockdep_print_held_locks() does not. Did something change recently that > could let the ->lockdep_depth counter get out of sync with the actual > number of locks held? Dmitri had a different theory here: https://groups.google.com/g/syzkaller-bugs/c/FmYvfZCZzqA/m/nc2CXUgsAgAJ
Re: [syzbot] WARNING: suspicious RCU usage in dput
#syz dup: WARNING: suspicious RCU usage in getname_flags On Fri, Apr 02, 2021 at 07:52:17PM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:1e43c377 Merge tag 'xtensa-20210329' of git://github.com/j.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=16d76301d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 > dashboard link: https://syzkaller.appspot.com/bug?extid=bdef67a6b28a89e6fe71 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+bdef67a6b28a89e6f...@syzkaller.appspotmail.com > > = > WARNING: suspicious RCU usage > 5.12.0-rc5-syzkaller #0 Not tainted > - > kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical > section! > > other info that might help us debug this: > > > rcu_scheduler_active = 2, debug_locks = 0 > no locks held by systemd-udevd/4825. > > stack backtrace: > CPU: 1 PID: 4825 Comm: systemd-udevd Not tainted 5.12.0-rc5-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x141/0x1d7 lib/dump_stack.c:120 > ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294 > dput+0x4d/0xbc0 fs/dcache.c:870 > step_into+0x2cf/0x1c80 fs/namei.c:1778 > walk_component+0x171/0x6a0 fs/namei.c:1945 > link_path_walk.part.0+0x712/0xc90 fs/namei.c:2266 > link_path_walk fs/namei.c:2190 [inline] > path_lookupat+0xb7/0x830 fs/namei.c:2419 > filename_lookup+0x19f/0x560 fs/namei.c:2453 > do_readlinkat+0xcd/0x2f0 fs/stat.c:417 > __do_sys_readlinkat fs/stat.c:444 [inline] > __se_sys_readlinkat fs/stat.c:441 [inline] > __x64_sys_readlinkat+0x93/0xf0 fs/stat.c:441 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7fb5a7e200ba > Code: 48 8b 0d e1 bd 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 > 00 00 00 0f 1f 44 00 00 49 89 ca b8 0b 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 > 01 c3 48 8b 0d ae bd 2b 00 f7 d8 64 89 01 48 > RSP: 002b:7ffc9c440e38 EFLAGS: 0202 ORIG_RAX: 010b > RAX: ffda RBX: 5604089e4380 RCX: 7fb5a7e200ba > RDX: 5604089e4380 RSI: 7ffc9c440ec0 RDI: ff9c > RBP: 0064 R08: 7fb5a80dcbc8 R09: 0070 > R10: 0063 R11: 0202 R12: 7ffc9c440ec0 > R13: ff9c R14: 7ffc9c440e90 R15: 0063 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [syzbot] WARNING: suspicious RCU usage in remove_vma (2)
#syz dup: WARNING: suspicious RCU usage in getname_flags On Sat, Apr 03, 2021 at 04:23:20AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:1e43c377 Merge tag 'xtensa-20210329' of git://github.com/j.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1052e1d6d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=d1a3d65a48dbd1bc > dashboard link: https://syzkaller.appspot.com/bug?extid=26ad5e106ca477175819 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+26ad5e106ca477175...@syzkaller.appspotmail.com > > = > WARNING: suspicious RCU usage > 5.12.0-rc5-syzkaller #0 Not tainted > - > kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical > section! > > other info that might help us debug this: > > > rcu_scheduler_active = 2, debug_locks = 0 > no locks held by syz-executor.0/29105. > > stack backtrace: > CPU: 0 PID: 29105 Comm: syz-executor.0 Not tainted 5.12.0-rc5-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x141/0x1d7 lib/dump_stack.c:120 > ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294 > remove_vma+0x44/0x170 mm/mmap.c:178 > exit_mmap+0x33f/0x590 mm/mmap.c:3229 > __mmput+0x122/0x470 kernel/fork.c:1090 > mmput+0x58/0x60 kernel/fork.c: > exit_mm kernel/exit.c:501 [inline] > do_exit+0xb0a/0x2a60 kernel/exit.c:812 > do_group_exit+0x125/0x310 kernel/exit.c:922 > get_signal+0x47f/0x2150 kernel/signal.c:2781 > arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:789 > handle_signal_work kernel/entry/common.c:147 [inline] > exit_to_user_mode_loop kernel/entry/common.c:171 [inline] > exit_to_user_mode_prepare+0x148/0x250 kernel/entry/common.c:208 > __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] > syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:301 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x466459 > Code: Unable to access opcode bytes at RIP 0x46642f. > RSP: 002b:7fdfaa117218 EFLAGS: 0246 > ORIG_RAX: 00ca > RAX: RBX: 0056bf68 RCX: 00466459 > RDX: RSI: 0080 RDI: 0056bf68 > RBP: 0056bf60 R08: R09: > R10: R11: 0246 R12: 0056bf6c > R13: 7fff64c569cf R14: 7fdfaa117300 R15: 00022000 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. >
Re: [syzbot] WARNING: suspicious RCU usage in clear_huge_page
#syz dup: WARNING: suspicious RCU usage in getname_flags On Sat, Apr 03, 2021 at 07:35:16PM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:d19cc4bf Merge tag 'trace-v5.12-rc5' of git://git.kernel.o.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1611e681d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 > dashboard link: https://syzkaller.appspot.com/bug?extid=7a0c25f9520c969c15f5 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+7a0c25f9520c969c1...@syzkaller.appspotmail.com > > = > WARNING: suspicious RCU usage > 5.12.0-rc5-syzkaller #0 Not tainted > - > kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical > section! > > other info that might help us debug this: > > > rcu_scheduler_active = 2, debug_locks = 0 > 1 lock held by syz-executor.2/10002: > #0: 8880129669d8 (&mm->mmap_lock#2){}-{3:3}, at: mmap_read_trylock > include/linux/mmap_lock.h:136 [inline] > #0: 8880129669d8 (&mm->mmap_lock#2){}-{3:3}, at: > do_user_addr_fault+0x285/0x1210 arch/x86/mm/fault.c:1331 > > stack backtrace: > CPU: 0 PID: 10002 Comm: syz-executor.2 Not tainted 5.12.0-rc5-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x141/0x1d7 lib/dump_stack.c:120 > ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294 > process_huge_page mm/memory.c:5051 [inline] > clear_huge_page+0x9c/0x560 mm/memory.c:5112 > __do_huge_pmd_anonymous_page mm/huge_memory.c:607 [inline] > do_huge_pmd_anonymous_page+0x60e/0x2570 mm/huge_memory.c:772 > create_huge_pmd mm/memory.c:4189 [inline] > __handle_mm_fault+0x2e59/0x4f70 mm/memory.c:4424 > handle_mm_fault+0x1bc/0x7e0 mm/memory.c:4551 > do_user_addr_fault+0x483/0x1210 arch/x86/mm/fault.c:1390 > handle_page_fault arch/x86/mm/fault.c:1475 [inline] > exc_page_fault+0x9e/0x180 arch/x86/mm/fault.c:1531 > asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:577 > RIP: 0033:0x461b6d > Code: 48 01 d0 eb 0b 0f 1f 84 00 00 00 00 00 48 89 f8 48 83 fa 20 72 49 48 83 > fa 40 0f 87 9f 00 00 00 c5 fe 6f 06 c5 fe 6f 4c 16 e0 fe 7f 07 c5 fe 7f > 4c 17 e0 c5 f8 77 c3 48 3b 15 7e 8e 04 01 0f > RSP: 002b:7fffc28c60c8 EFLAGS: 00010287 > RAX: 2080 RBX: 0003 RCX: 0057 > RDX: 002b RSI: 00570020 RDI: 2080 > RBP: 7fffc28c6188 R08: 0097 R09: 7fffc2907090 > R10: a8e8 R11: R12: 0001 > R13: R14: 0056bf60 R15: 00035790 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. >
Re: [syzbot] WARNING: suspicious RCU usage in list_lru_destroy
#syz dup: WARNING: suspicious RCU usage in getname_flags On Sun, Apr 04, 2021 at 08:15:13AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized() co.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=15556cced0 > kernel config: https://syzkaller.appspot.com/x/.config?x=71a75beb62b62a34 > dashboard link: https://syzkaller.appspot.com/bug?extid=d7dd989878658902c6d6 > compiler: Debian clang version 11.0.1-2 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+d7dd989878658902c...@syzkaller.appspotmail.com > > EXT4-fs (loop0): mount failed > = > WARNING: suspicious RCU usage > 5.12.0-rc5-syzkaller #0 Not tainted > - > kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical > section! > > other info that might help us debug this: > > > rcu_scheduler_active = 2, debug_locks = 0 > no locks held by syz-executor.0/10672. > > stack backtrace: > CPU: 0 PID: 10672 Comm: syz-executor.0 Not tainted 5.12.0-rc5-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x176/0x24e lib/dump_stack.c:120 > ___might_sleep+0x6e/0x530 kernel/sched/core.c:8294 > down_read+0x17/0x50 kernel/locking/rwsem.c:1352 > list_lru_destroy+0x49/0x390 mm/list_lru.c:628 > deactivate_locked_super+0xbf/0xf0 fs/super.c:343 > mount_bdev+0x288/0x3a0 fs/super.c:1369 > legacy_get_tree+0xea/0x180 fs/fs_context.c:592 > vfs_get_tree+0x86/0x270 fs/super.c:1497 > do_new_mount fs/namespace.c:2903 [inline] > path_mount+0x188a/0x29a0 fs/namespace.c:3233 > do_mount fs/namespace.c:3246 [inline] > __do_sys_mount fs/namespace.c:3454 [inline] > __se_sys_mount+0x28c/0x320 fs/namespace.c:3431 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x46797a > Code: 48 c7 c2 bc ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 b8 04 00 00 > 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 > 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:7f77bde01fa8 EFLAGS: 0206 ORIG_RAX: 00a5 > RAX: ffda RBX: 2200 RCX: 0046797a > RDX: 2300 RSI: 2100 RDI: 7f77bde02000 > RBP: 7f77bde02040 R08: 7f77bde02040 R09: 2300 > R10: R11: 0206 R12: 2300 > R13: 2100 R14: 7f77bde02000 R15: 20c0 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. >
[PATCH] net/mlx5: fix kfree mismatch in indir_table.c
Memory allocated by kvzalloc() should be freed by kvfree(). Fixes: 34ca65352ddf2 ("net/mlx5: E-Switch, Indirect table infrastructur") Signed-off-by: Xiaoming Ni --- .../net/ethernet/mellanox/mlx5/core/esw/indir_table.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.c b/drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.c index 6f6772bf61a2..3da7becc1069 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.c @@ -248,7 +248,7 @@ static int mlx5_esw_indir_table_rule_get(struct mlx5_eswitch *esw, err_ethertype: kfree(rule); out: - kfree(rule_spec); + kvfree(rule_spec); return err; } @@ -328,7 +328,7 @@ static int mlx5_create_indir_recirc_group(struct mlx5_eswitch *esw, e->recirc_cnt = 0; out: - kfree(in); + kvfree(in); return err; } @@ -347,7 +347,7 @@ static int mlx5_create_indir_fwd_group(struct mlx5_eswitch *esw, spec = kvzalloc(sizeof(*spec), GFP_KERNEL); if (!spec) { - kfree(in); + kvfree(in); return -ENOMEM; } @@ -371,8 +371,8 @@ static int mlx5_create_indir_fwd_group(struct mlx5_eswitch *esw, } err_out: - kfree(spec); - kfree(in); + kvfree(spec); + kvfree(in); return err; } -- 2.27.0
arch/mips/kvm/vz.c:392:10: warning: variable 'freeze_time' set but not used
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: e49d033bddf5b565044e2abe4241353959bc9120 commit: cf99c505cf7a5b6d3deee91e3571871f20320d31 MIPS: VZ: Only include loongson_regs.h for CPU_LOONGSON64 date: 8 months ago config: mips-randconfig-r033-20210405 (attached as .config) compiler: mips-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf99c505cf7a5b6d3deee91e3571871f20320d31 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout cf99c505cf7a5b6d3deee91e3571871f20320d31 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): arch/mips/kvm/vz.c: In function '_kvm_vz_restore_htimer': >> arch/mips/kvm/vz.c:392:10: warning: variable 'freeze_time' set but not used >> [-Wunused-but-set-variable] 392 | ktime_t freeze_time; | ^~~ vim +/freeze_time +392 arch/mips/kvm/vz.c c992a4f6a9b0a3 James Hogan 2017-03-14 378 c992a4f6a9b0a3 James Hogan 2017-03-14 379 /** f4474d50c7d483 James Hogan 2017-03-14 380 * _kvm_vz_restore_htimer() - Restore hard timer state. f4474d50c7d483 James Hogan 2017-03-14 381 * @vcpu: Virtual CPU. f4474d50c7d483 James Hogan 2017-03-14 382 * @compare:CP0_Compare register value, restored by caller. f4474d50c7d483 James Hogan 2017-03-14 383 * @cause: CP0_Cause register to restore. f4474d50c7d483 James Hogan 2017-03-14 384 * f4474d50c7d483 James Hogan 2017-03-14 385 * Restore hard timer Guest.Count & Guest.Cause taking care to preserve the f4474d50c7d483 James Hogan 2017-03-14 386 * value of Guest.CP0_Cause.TI while restoring Guest.CP0_Cause. f4474d50c7d483 James Hogan 2017-03-14 387 */ f4474d50c7d483 James Hogan 2017-03-14 388 static void _kvm_vz_restore_htimer(struct kvm_vcpu *vcpu, f4474d50c7d483 James Hogan 2017-03-14 389 u32 compare, u32 cause) f4474d50c7d483 James Hogan 2017-03-14 390 { f4474d50c7d483 James Hogan 2017-03-14 391 u32 start_count, after_count; f4474d50c7d483 James Hogan 2017-03-14 @392 ktime_t freeze_time; f4474d50c7d483 James Hogan 2017-03-14 393 unsigned long flags; f4474d50c7d483 James Hogan 2017-03-14 394 f4474d50c7d483 James Hogan 2017-03-14 395 /* f4474d50c7d483 James Hogan 2017-03-14 396 * Freeze the soft-timer and sync the guest CP0_Count with it. We do f4474d50c7d483 James Hogan 2017-03-14 397 * this with interrupts disabled to avoid latency. f4474d50c7d483 James Hogan 2017-03-14 398 */ f4474d50c7d483 James Hogan 2017-03-14 399 local_irq_save(flags); f4474d50c7d483 James Hogan 2017-03-14 400 freeze_time = kvm_mips_freeze_hrtimer(vcpu, &start_count); f4474d50c7d483 James Hogan 2017-03-14 401 write_c0_gtoffset(start_count - read_c0_count()); f4474d50c7d483 James Hogan 2017-03-14 402 local_irq_restore(flags); f4474d50c7d483 James Hogan 2017-03-14 403 f4474d50c7d483 James Hogan 2017-03-14 404 /* restore guest CP0_Cause, as TI may already be set */ f4474d50c7d483 James Hogan 2017-03-14 405 back_to_back_c0_hazard(); f4474d50c7d483 James Hogan 2017-03-14 406 write_gc0_cause(cause); f4474d50c7d483 James Hogan 2017-03-14 407 f4474d50c7d483 James Hogan 2017-03-14 408 /* f4474d50c7d483 James Hogan 2017-03-14 409 * The above sequence isn't atomic and would result in lost timer f4474d50c7d483 James Hogan 2017-03-14 410 * interrupts if we're not careful. Detect if a timer interrupt is due f4474d50c7d483 James Hogan 2017-03-14 411 * and assert it. f4474d50c7d483 James Hogan 2017-03-14 412 */ f4474d50c7d483 James Hogan 2017-03-14 413 back_to_back_c0_hazard(); f4474d50c7d483 James Hogan 2017-03-14 414 after_count = read_gc0_count(); f4474d50c7d483 James Hogan 2017-03-14 415 if (after_count - start_count > compare - start_count - 1) f4474d50c7d483 James Hogan 2017-03-14 416 kvm_vz_queue_irq(vcpu, MIPS_EXC_INT_TIMER); f4474d50c7d483 James Hogan 2017-03-14 417 } f4474d50c7d483 James Hogan 2017-03-14 418 :: The code at line 392 was first introduced by commit :: f4474d50c7d483dd4432d5b0891b0bb9ad0eefc9 KVM: MIPS/VZ: Support hardware guest timer :: TO: James Hogan :: CC: James Hogan --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
drivers/remoteproc/ti_k3_r5_remoteproc.c:377:28: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: e49d033bddf5b565044e2abe4241353959bc9120 commit: 34f2653686fecc9bd5a4ee16724768c72953fb57 remoteproc: k3-r5: Initialize TCM memories for ECC date: 6 months ago config: arm64-randconfig-s032-20210405 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-279-g6d5d9b42-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f2653686fecc9bd5a4ee16724768c72953fb57 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 34f2653686fecc9bd5a4ee16724768c72953fb57 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/remoteproc/ti_k3_r5_remoteproc.c:377:28: sparse: sparse: incorrect >> type in argument 1 (different address spaces) @@ expected void *p @@ >> got void [noderef] __iomem *cpu_addr @@ drivers/remoteproc/ti_k3_r5_remoteproc.c:377:28: sparse: expected void *p drivers/remoteproc/ti_k3_r5_remoteproc.c:377:28: sparse: got void [noderef] __iomem *cpu_addr drivers/remoteproc/ti_k3_r5_remoteproc.c:380:28: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *p @@ got void [noderef] __iomem *cpu_addr @@ drivers/remoteproc/ti_k3_r5_remoteproc.c:380:28: sparse: expected void *p drivers/remoteproc/ti_k3_r5_remoteproc.c:380:28: sparse: got void [noderef] __iomem *cpu_addr vim +377 drivers/remoteproc/ti_k3_r5_remoteproc.c 346 347 /* 348 * The R5F cores have controls for both a reset and a halt/run. The code 349 * execution from DDR requires the initial boot-strapping code to be run 350 * from the internal TCMs. This function is used to release the resets on 351 * applicable cores to allow loading into the TCMs. The .prepare() ops is 352 * invoked by remoteproc core before any firmware loading, and is followed 353 * by the .start() ops after loading to actually let the R5 cores run. 354 */ 355 static int k3_r5_rproc_prepare(struct rproc *rproc) 356 { 357 struct k3_r5_rproc *kproc = rproc->priv; 358 struct k3_r5_cluster *cluster = kproc->cluster; 359 struct k3_r5_core *core = kproc->core; 360 struct device *dev = kproc->dev; 361 int ret; 362 363 ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP) ? 364 k3_r5_lockstep_release(cluster) : k3_r5_split_release(core); 365 if (ret) { 366 dev_err(dev, "unable to enable cores for TCM loading, ret = %d\n", 367 ret); 368 return ret; 369 } 370 371 /* 372 * Zero out both TCMs unconditionally (access from v8 Arm core is not 373 * affected by ATCM & BTCM enable configuration values) so that ECC 374 * can be effective on all TCM addresses. 375 */ 376 dev_dbg(dev, "zeroing out ATCM memory\n"); > 377 memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size); 378 379 dev_dbg(dev, "zeroing out BTCM memory\n"); 380 memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size); 381 382 return 0; 383 } 384 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
RE: [PATCH next 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support
> > Any specific reason you are not using the misc_device api? That would clean > up this driver a lot, there's no need to create a whole class just for a > single > driver. > Hi Greg No specific reason. I just didn't know the existence of misc_register API. Do you recommend using this API to create the device? If yes, can you tell me how to obtain a appropriate MINOR number from miscdevice.h? Thanks Min
Re: [PATCH v3] sched/debug: Use sched_debug_lock to serialize use of cgroup_path[] only
On 4/4/21 9:27 PM, Waiman Long wrote: On 4/4/21 12:02 PM, Steven Rostedt wrote: On Fri, 2 Apr 2021 23:09:09 -0400 Waiman Long wrote: The main problem with sched_debug_lock is that under certain circumstances, a lock waiter may wait a long time to acquire the lock (in seconds). We can't insert touch_nmi_watchdog() while the cpu is waiting for the spinlock. The problem I have with the patch is that it seems to be a hack (as it doesn't fix the issue in all cases). Since sched_debug_lock is "special", perhaps we can add wrappers to take it, and instead of doing the spin_lock_irqsave(), do a trylock loop. Add lockdep annotation to tell lockdep that this is not a try lock (so that it can still detect deadlocks). Then have the strategically placed touch_nmi_watchdog() also increment a counter. Then in that trylock loop, if it sees the counter get incremented, it knows that forward progress is being made by the lock holder, and it too can call touch_nmi_watchdog(). Thanks for the suggestion, but it also sound complicated. I think we can fix this lockup problem if we are willing to lose some information in case of contention. As you have suggested, a trylock will be used to acquire sched_debug_lock. If succeeded, all is good. Otherwise, a shorter stack buffer will be used for cgroup path. The path may be truncated in this case. If we detect that the full length of the buffer is used, we assume truncation and add, e.g. "...", to indicate there is more to the actual path. Do you think this is an acceptable comprise? Actually, I don't really need to disable interrupt under this situation as deadlock can't happen. Cheers, Longman
[PATCH 1/1] SUNRPC: Handle major timeout in xprt_adjust_timeout()
Currently if a major timeout value is reached, but the minor value has not been reached, an ETIMEOUT will not be sent back to the caller. This can occur if the v4 server is not responding to requests and retrans is configured larger than the default of two. For example, A TCP mount with a configured timeout value of 50 and a retransmission count of 3 to a v4 server which is not responding: 1. Initial value and increment set to 5s, maxval set to 20s, retries at 3 2. Major timeout is set to 20s, minor timeout set to 5s initially 3. xport_adjust_timeout() is called after 5s, retry with 10s timeout, minor timeout is bumped to 10s 4. And again after another 10s, 15s total time with minor timeout set to 15s 5. After 20s total time xport_adjust_timeout is called as major timeout is reached, but skipped because the minor timeout is not reached - After this time the cpu spins continually calling xport_adjust_timeout() and returning 0 for 10 seconds. As seen on perf sched: 39243.913182 [0005] mount.nfs[3794] 4607.938 0.017 9746.863 6. This continues until the 15s minor timeout condition is reached (in this case for 10 seconds). After which the ETIMEOUT is processed back to the caller, the cpu spinning stops, and normal operations continue Fixes: 7de62bc09fe6 ("SUNRPC dont update timeout value on connection reset") Signed-off-by: Chris Dion --- Hello, We recently have noticed an issue where we see a cpu spinning for a few seconds at a time bouncing between xprt_adjust_timeout() and call_connect(). This is ocurring with an v4 client mounting a non-responsive server with a low timeout and retransmissions set. In this case if the major timeout is not serviced there appears to be a spin/bouncing between these functions until such timeout is returned. It made sense to service the major timeout in this scenario. I am not clear on the implications on the original implementation here but I will submit for your review. Regards, Chris net/sunrpc/xprt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c index 691ccf8049a4..7fe975c1000a 100644 --- a/net/sunrpc/xprt.c +++ b/net/sunrpc/xprt.c @@ -698,9 +698,9 @@ int xprt_adjust_timeout(struct rpc_rqst *req) const struct rpc_timeout *to = req->rq_task->tk_client->cl_timeout; int status = 0; - if (time_before(jiffies, req->rq_minortimeo)) - return status; if (time_before(jiffies, req->rq_majortimeo)) { + if (time_before(jiffies, req->rq_minortimeo)) + return status; if (to->to_exponential) req->rq_timeout <<= 1; else -- 2.18.2
Re: [PATCH v3] sched/debug: Use sched_debug_lock to serialize use of cgroup_path[] only
On 4/4/21 12:02 PM, Steven Rostedt wrote: On Fri, 2 Apr 2021 23:09:09 -0400 Waiman Long wrote: The main problem with sched_debug_lock is that under certain circumstances, a lock waiter may wait a long time to acquire the lock (in seconds). We can't insert touch_nmi_watchdog() while the cpu is waiting for the spinlock. The problem I have with the patch is that it seems to be a hack (as it doesn't fix the issue in all cases). Since sched_debug_lock is "special", perhaps we can add wrappers to take it, and instead of doing the spin_lock_irqsave(), do a trylock loop. Add lockdep annotation to tell lockdep that this is not a try lock (so that it can still detect deadlocks). Then have the strategically placed touch_nmi_watchdog() also increment a counter. Then in that trylock loop, if it sees the counter get incremented, it knows that forward progress is being made by the lock holder, and it too can call touch_nmi_watchdog(). Thanks for the suggestion, but it also sound complicated. I think we can fix this lockup problem if we are willing to lose some information in case of contention. As you have suggested, a trylock will be used to acquire sched_debug_lock. If succeeded, all is good. Otherwise, a shorter stack buffer will be used for cgroup path. The path may be truncated in this case. If we detect that the full length of the buffer is used, we assume truncation and add, e.g. "...", to indicate there is more to the actual path. Do you think this is an acceptable comprise? Cheers, Longman
Re: [Outreachy kernel] [PATCH] staging: qlge: remove else after break
On Mon, Apr 05, 2021 at 06:11:43AM +0530, Mitali Borkar wrote: > - } else { > - netif_err(qdev, drv, qdev->ndev, > + } netif_err(qdev, drv, qdev->ndev, That's not the normal indentation style ... does checkpatch really not complain about that? > "IDC: Invalid State 0x%.04x.\n", > mbcp->mbox_out[0]); > status = -EIO; > break; > - } > } > > return status; > -- > 2.30.2 > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/YGpcx9MZuZJFy0Z/%40kali.
Re: [PATCH v3 11/12] drm/bridge: ti-sn65dsi86: Print an error if we fallback to panel modes
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:45PM -0700, Douglas Anderson wrote: > Now that we can properly read the EDID for modes there should be no > reason to fallback to the fixed modes that our downstream panel driver > provides us. Let's make that clear by: > - Putting an error message in the logs if we fall back. > - Putting a comment in saying what's going on. > > Signed-off-by: Douglas Anderson Reviewed-by: Laurent Pinchart > --- > > (no changes since v1) > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index fb50f9f95b0f..3b61898cf9cb 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -303,6 +303,13 @@ static int ti_sn_bridge_connector_get_modes(struct > drm_connector *connector) > return num; > } > > + /* > + * Ideally this should never happen and we could remove the fallback > + * but let's preserve old behavior. > + */ > + DRM_DEV_ERROR(pdata->dev, > + "Failed to read EDID; falling back to panel modes"); > + > exit: > return drm_panel_get_modes(pdata->panel, connector); > } -- Regards, Laurent Pinchart
Re: [PATCH v3 10/12] drm/bridge: ti-sn65dsi86: Read the EDID only if refclk was provided
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:44PM -0700, Douglas Anderson wrote: > Though I don't have access to any hardware that uses ti-sn65dsi86 and > _doesn't_ provide a "refclk", I believe that we'll have trouble > reading the EDID at bootup in that case. Specifically I believe that > if there's no "refclk" we need the MIPI source clock to be active > before we can successfully read the EDID. My evidence here is that, in > testing, I couldn't read the EDID until I turned on the DPPLL in the > bridge chip and that the DPPLL needs the input clock to be active. > > Since this is hard to support, let's punt trying to read the EDID if > there's no "refclk". > > I don't believe there are any users of the ti-sn65dsi86 bridge chip > that _don't_ use "refclk". The bridge chip is _very_ inflexible in > that mode. The only time I've seen that mode used was for some really > early prototype hardware that was thrown in the e-waste bin years ago > when we realized how inflexible it was. > > Even if someone is using the bridge chip without the "refclk" they're > in no worse shape than they were before the (fairly recent) commit > 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC"). > > Signed-off-by: Douglas Anderson Reviewed-by: Laurent Pinchart > --- > > (no changes since v1) > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index a76cac93cb46..fb50f9f95b0f 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -275,6 +275,18 @@ static int ti_sn_bridge_connector_get_modes(struct > drm_connector *connector) > bool was_enabled; > int num; > > + /* > + * Don't try to read the EDID if no refclk. In theory it is possible > + * to make this work but it's tricky. I believe that we need to get > + * our upstream MIPI source to provide a pixel clock before we can > + * do AUX transations but we need to be able to read the EDID before > + * we've picked a display mode. The bridge is already super limited > + * if you try to use it without a refclk so presumably limiting to > + * the fixed modes our downstream panel reports is fine. > + */ > + if (!pdata->refclk) > + goto exit; > + > if (!edid) { > was_enabled = pdata->pre_enabled; > > @@ -291,6 +303,7 @@ static int ti_sn_bridge_connector_get_modes(struct > drm_connector *connector) > return num; > } > > +exit: > return drm_panel_get_modes(pdata->panel, connector); > } > -- Regards, Laurent Pinchart
Re: [PATCH v3 07/12] drm/bridge: ti-sn65dsi86: Remove extra call: drm_connector_update_edid_property()
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:41PM -0700, Douglas Anderson wrote: > As of commit 5186421cbfe2 ("drm: Introduce epoch counter to > drm_connector") the drm_get_edid() function calls > drm_connector_update_edid_property() for us. There's no reason for us > to call it again. > > Signed-off-by: Douglas Anderson > Reviewed-by: Andrzej Hajda Reviewed-by: Laurent Pinchart This looks like a widespread issue, would you be able to send a patch to address all the other drivers ? > --- > > (no changes since v1) > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 --- > 1 file changed, 4 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index 51db30d573c1..6390bc58f29a 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -270,7 +270,7 @@ static int ti_sn_bridge_connector_get_modes(struct > drm_connector *connector) > { > struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector); > struct edid *edid = pdata->edid; > - int num, ret; > + int num; > > if (!edid) { > pm_runtime_get_sync(pdata->dev); > @@ -279,12 +279,9 @@ static int ti_sn_bridge_connector_get_modes(struct > drm_connector *connector) > } > > if (edid && drm_edid_is_valid(edid)) { > - ret = drm_connector_update_edid_property(connector, edid); > - if (!ret) { > - num = drm_add_edid_modes(connector, edid); > - if (num) > - return num; > - } > + num = drm_add_edid_modes(connector, edid); > + if (num) > + return num; > } > > return drm_panel_get_modes(pdata->panel, connector); -- Regards, Laurent Pinchart
Re: [PATCH v3 06/12] drm/bridge: ti-sn65dsi86: Get rid of the useless detect() function
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:40PM -0700, Douglas Anderson wrote: > If we just leave the detect() function as NULL then the upper layers > assume we're always connected. There's no reason for a stub. > > Signed-off-by: Douglas Anderson > Reviewed-by: Andrzej Hajda Reviewed-by: Laurent Pinchart > --- > > (no changes since v1) > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 > 1 file changed, 12 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index e30460002c48..51db30d573c1 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -306,20 +306,8 @@ static struct drm_connector_helper_funcs > ti_sn_bridge_connector_helper_funcs = { > .mode_valid = ti_sn_bridge_connector_mode_valid, > }; > > -static enum drm_connector_status > -ti_sn_bridge_connector_detect(struct drm_connector *connector, bool force) > -{ > - /** > - * TODO: Currently if drm_panel is present, then always > - * return the status as connected. Need to add support to detect > - * device state for hot pluggable scenarios. > - */ > - return connector_status_connected; > -} > - > static const struct drm_connector_funcs ti_sn_bridge_connector_funcs = { > .fill_modes = drm_helper_probe_single_connector_modes, > - .detect = ti_sn_bridge_connector_detect, > .destroy = drm_connector_cleanup, > .reset = drm_atomic_helper_connector_reset, > .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state, -- Regards, Laurent Pinchart
Re: [PATCH v3 05/12] drm/bridge: ti-sn65dsi86: Move drm_panel_unprepare() to post_disable()
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:39PM -0700, Douglas Anderson wrote: > We prepared the panel in pre_enable() so we should unprepare it in > post_disable() to match. > > This becomes important once we start using pre_enable() and > post_disable() to make sure things are powered on (and then off again) > when reading the EDID. > > Signed-off-by: Douglas Anderson > Reviewed-by: Andrzej Hajda Reviewed-by: Laurent Pinchart > --- > > (no changes since v1) > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index c006678c9921..e30460002c48 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -452,8 +452,6 @@ static void ti_sn_bridge_disable(struct drm_bridge > *bridge) > regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0); > /* disable DP PLL */ > regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 0); > - > - drm_panel_unprepare(pdata->panel); > } > > static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn_bridge *pdata) > @@ -869,6 +867,8 @@ static void ti_sn_bridge_post_disable(struct drm_bridge > *bridge) > { > struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge); > > + drm_panel_unprepare(pdata->panel); > + > clk_disable_unprepare(pdata->refclk); > > pm_runtime_put_sync(pdata->dev); -- Regards, Laurent Pinchart
Re: [PATCH v3 04/12] drm/bridge: ti-sn65dsi86: Reorder remove()
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:38PM -0700, Douglas Anderson wrote: > Let's make the remove() function strictly the reverse of the probe() > function so it's easier to reason about. > > This patch was created by code inspection and should move us closer to > a proper remove. > > Signed-off-by: Douglas Anderson > Reviewed-by: Andrzej Hajda Reviewed-by: Laurent Pinchart > --- > > Changes in v3: > - Removed "NOTES" from commit message. > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index 76f43af6735d..c006678c9921 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -1315,20 +1315,21 @@ static int ti_sn_bridge_remove(struct i2c_client > *client) > if (!pdata) > return -EINVAL; > > - kfree(pdata->edid); > - ti_sn_debugfs_remove(pdata); > - > - of_node_put(pdata->host_node); > - > - pm_runtime_disable(pdata->dev); > - > if (pdata->dsi) { > mipi_dsi_detach(pdata->dsi); > mipi_dsi_device_unregister(pdata->dsi); > } > > + kfree(pdata->edid); > + > + ti_sn_debugfs_remove(pdata); > + > drm_bridge_remove(&pdata->bridge); > > + pm_runtime_disable(pdata->dev); > + > + of_node_put(pdata->host_node); > + > return 0; > } > -- Regards, Laurent Pinchart
Re: [PATCH v3 03/12] drm/bridge: ti-sn65dsi86: Remove incorrectly tagged kerneldoc comment
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:37PM -0700, Douglas Anderson wrote: > A random comment inside a function had "/**" in front of it. That > doesn't make sense. Remove. > > Signed-off-by: Douglas Anderson > Reviewed-by: Andrzej Hajda Reviewed-by: Laurent Pinchart > --- > > (no changes since v1) > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index 96fe8f2c0ea9..76f43af6735d 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -788,7 +788,7 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge) > /* set dsi clk frequency value */ > ti_sn_bridge_set_dsi_rate(pdata); > > - /** > + /* >* The SN65DSI86 only supports ASSR Display Authentication method and >* this method is enabled by default. An eDP panel must support this >* authentication method. We need to enable this method in the eDP panel -- Regards, Laurent Pinchart
Re: [PATCH v3 01/12] drm/bridge: Fix the stop condition of drm_bridge_chain_pre_enable()
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:35PM -0700, Douglas Anderson wrote: > The drm_bridge_chain_pre_enable() is not the proper opposite of > drm_bridge_chain_post_disable(). It continues along the chain to > _before_ the starting bridge. Let's fix that. > > Fixes: 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked list") > Signed-off-by: Douglas Anderson > Reviewed-by: Andrzej Hajda > --- > > (no changes since v1) > > drivers/gpu/drm/drm_bridge.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > index 64f0effb52ac..044acd07c153 100644 > --- a/drivers/gpu/drm/drm_bridge.c > +++ b/drivers/gpu/drm/drm_bridge.c > @@ -522,6 +522,9 @@ void drm_bridge_chain_pre_enable(struct drm_bridge > *bridge) > list_for_each_entry_reverse(iter, &encoder->bridge_chain, chain_node) { > if (iter->funcs->pre_enable) > iter->funcs->pre_enable(iter); > + > + if (iter == bridge) > + break; This looks good as it matches drm_atomic_bridge_chain_disable(). Reviewed-by: Laurent Pinchart I'm curious though, given that the bridge passed to the function should be the one closest to the encoder, does this make a difference ? > } > } > EXPORT_SYMBOL(drm_bridge_chain_pre_enable); -- Regards, Laurent Pinchart
Re: [PATCH v2] net: mac802154: Fix general protection fault
Hi, On Thu, 4 Mar 2021 at 10:25, Pavel Skripkin wrote: > > syzbot found general protection fault in crypto_destroy_tfm()[1]. > It was caused by wrong clean up loop in llsec_key_alloc(). > If one of the tfm array members is in IS_ERR() range it will > cause general protection fault in clean up function [1]. > > Call Trace: > crypto_free_aead include/crypto/aead.h:191 [inline] [1] > llsec_key_alloc net/mac802154/llsec.c:156 [inline] > mac802154_llsec_key_add+0x9e0/0xcc0 net/mac802154/llsec.c:249 > ieee802154_add_llsec_key+0x56/0x80 net/mac802154/cfg.c:338 > rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] > nl802154_add_llsec_key+0x3d3/0x560 net/ieee802154/nl802154.c:1584 > genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 > genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] > genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 > netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 > genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 > netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] > netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 > netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 > sock_sendmsg_nosec net/socket.c:654 [inline] > sock_sendmsg+0xcf/0x120 net/socket.c:674 > sys_sendmsg+0x6e8/0x810 net/socket.c:2350 > ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 > __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > > Signed-off-by: Pavel Skripkin > Reported-by: syzbot+9ec037722d2603a9f...@syzkaller.appspotmail.com > Change-Id: I29f7ac641a039096d63d1e6070bb32cb5a3beb07 I am sorry, I don't know the tag "Change-Id", I was doing a whole grep on Documentation/ without any luck. Dumb question: What is the meaning of it? - Alex
[PATCH] staging: qlge: remove else after break
linux-staging@lists,linux-kernel@vger.kernel.org Bcc: Subject: [PATCH] staging: qlge:remove else after break Reply-To: Fixed Warning:- else is not needed after break break terminates the loop if encountered. else is unnecessary and increases indenatation Signed-off-by: Mitali Borkar --- drivers/staging/qlge/qlge_mpi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c index 2630ebf50341..3a49f187203b 100644 --- a/drivers/staging/qlge/qlge_mpi.c +++ b/drivers/staging/qlge/qlge_mpi.c @@ -935,13 +935,11 @@ static int qlge_idc_wait(struct qlge_adapter *qdev) netif_err(qdev, drv, qdev->ndev, "IDC Success.\n"); status = 0; break; - } else { - netif_err(qdev, drv, qdev->ndev, + } netif_err(qdev, drv, qdev->ndev, "IDC: Invalid State 0x%.04x.\n", mbcp->mbox_out[0]); status = -EIO; break; - } } return status; -- 2.30.2
Re: [PATCH] net: fix NULL ptr dereference in nl802154_del_llsec_key
Hi, On Sat, 3 Apr 2021 at 11:18, Pavel Skripkin wrote: > > syzbot reported NULL ptr dereference in nl802154_del_llsec_key()[1] > The problem was in case of info->attrs[NL802154_ATTR_SEC_KEY] == NULL. > nla_parse_nested_deprecated()[2] doesn't check this condition before calling > nla_len()[3] > this is already fixed in the same way just not in net yet. - Alex
Re: [PATCH v4 0/3] cgroup: New misc cgroup controller
On Sun, Apr 4, 2021 at 10:35 AM Tejun Heo wrote: > > Applied to cgroup/for-5.13. If there are further issues, let's address them > incrementally. > > Thanks. > > -- > tejun Thanks Tejun for accepting and guiding through each version of this patch series.
Re: [PATCH] doc: Fix mistaken diagram references in RCU
On Sun, Apr 04, 2021 at 11:58:43PM +0200, Frederic Weisbecker wrote: > The 3 diagrams describing rcu_gp_init() all spuriously refer to the same > figure, probably due to some copy/paste issue. Fix the references. > > Signed-off-by: Frederic Weisbecker Good catch, queued, thank you! Thanx, Paul > --- > .../RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst > b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst > index 3f6ce41ee0c5..11cdab037bff 100644 > --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst > +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst > @@ -339,14 +339,14 @@ The diagram below shows the path of ordering if the > leftmost > leftmost ``rcu_node`` structure offlines its last CPU and if the next > ``rcu_node`` structure has no online CPUs). > > -.. kernel-figure:: TreeRCU-gp-init-1.svg > +.. kernel-figure:: TreeRCU-gp-init-2.svg > > The final ``rcu_gp_init()`` pass through the ``rcu_node`` tree traverses > breadth-first, setting each ``rcu_node`` structure's ``->gp_seq`` field > to the newly advanced value from the ``rcu_state`` structure, as shown > in the following diagram. > > -.. kernel-figure:: TreeRCU-gp-init-1.svg > +.. kernel-figure:: TreeRCU-gp-init-3.svg > > This change will also cause each CPU's next call to > ``__note_gp_changes()`` to notice that a new grace period has started, > -- > 2.25.1 >
Re: [PATCH] libbpf: Fix KERNEL_VERSION macro
On Sun, Apr 4, 2021 at 2:53 AM Hengqi Chen wrote: > > Add missing ')' for KERNEL_VERSION macro. > > Signed-off-by: Hengqi Chen > --- The fix looks good, thank you. But your patch didn't make it into bpf/netdev patchworks instance ([0]) most probably due to too long CC list. Can you please re-send with just maintainers and bpf@ and netdev@ mailing lists in to/cc. Also for bpf and bpf-next tree, we ask to specify the tree with [PATCH bpf-next] prefix, so when re-submitting please adjust as well. Thanks. [0] https://patchwork.kernel.org/project/netdevbpf/list/ > tools/lib/bpf/bpf_helpers.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h > index cc2e51c64a54..b904128626c2 100644 > --- a/tools/lib/bpf/bpf_helpers.h > +++ b/tools/lib/bpf/bpf_helpers.h > @@ -51,7 +51,7 @@ > #endif > > #ifndef KERNEL_VERSION > -#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + ((c) > 255 ? 255 : > (c)) > +#define KERNEL_VERSION(a, b, c) (((a) << 16) + ((b) << 8) + ((c) > 255 ? 255 > : (c))) > #endif > > /* > -- > 2.25.1 >
Re: [syzbot] WARNING: suspicious RCU usage in __ext4_handle_dirty_metadata
#syz dup: WARNING: suspicious RCU usage in get_timespec64 On Sun, Apr 04, 2021 at 01:55:17PM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized() co.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=10808831d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 > dashboard link: https://syzkaller.appspot.com/bug?extid=cb293a00f01b422bac7d > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+cb293a00f01b422ba...@syzkaller.appspotmail.com > > = > WARNING: suspicious RCU usage > 5.12.0-rc5-syzkaller #0 Not tainted > - > kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical > section! > > other info that might help us debug this: > > > rcu_scheduler_active = 2, debug_locks = 0 > 7 locks held by syz-executor.2/17885: > #0: > 888014000930 > ( > &f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:961 > #1: 88802455a460 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x12d/0x250 > fs/read_write.c:658 > #2: 888080e91888 (&sb->s_type->i_mutex_key#9){+.+.}-{3:3}, at: > inode_lock include/linux/fs.h:775 [inline] > #2: 888080e91888 (&sb->s_type->i_mutex_key#9){+.+.}-{3:3}, at: > ext4_dio_write_iter fs/ext4/file.c:493 [inline] > #2: 888080e91888 (&sb->s_type->i_mutex_key#9){+.+.}-{3:3}, at: > ext4_file_write_iter+0xaeb/0x14e0 fs/ext4/file.c:661 > #3: 888080e91678 (&ei->i_data_sem){}-{3:3}, at: > ext4_map_blocks+0x5e1/0x17d0 fs/ext4/inode.c:631 > #4: 8bf718a0 (rcu_read_lock){}-{1:2}, at: > ieee80211_rx_napi+0x0/0x3d0 arch/x86/include/asm/bitops.h:207 > #5: 88807b381580 (&local->rx_path_lock){+.-.}-{2:2}, at: spin_lock_bh > include/linux/spinlock.h:359 [inline] > #5: 88807b381580 (&local->rx_path_lock){+.-.}-{2:2}, at: > ieee80211_rx_handlers+0xd7/0xae60 net/mac80211/rx.c:3758 > #6: 8880b9d26358 (hrtimer_bases.lock){-.-.}-{2:2}, at: __run_hrtimer > kernel/time/hrtimer.c:1541 [inline] > #6: 8880b9d26358 (hrtimer_bases.lock){-.-.}-{2:2}, at: > __hrtimer_run_queues+0x243/0xe40 kernel/time/hrtimer.c:1601 > > stack backtrace: > CPU: 1 PID: 17885 Comm: syz-executor.2 Not tainted 5.12.0-rc5-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x141/0x1d7 lib/dump_stack.c:120 > ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294 > __ext4_handle_dirty_metadata+0x37/0x730 fs/ext4/ext4_jbd2.c:326 > ext4_mb_mark_diskspace_used+0x991/0x1160 fs/ext4/mballoc.c:3279 > ext4_mb_new_blocks+0xd46/0x51a0 fs/ext4/mballoc.c:5000 > ext4_new_meta_blocks+0x2fe/0x360 fs/ext4/balloc.c:693 > ext4_alloc_branch fs/ext4/indirect.c:335 [inline] > ext4_ind_map_blocks+0xb0d/0x2450 fs/ext4/indirect.c:626 > ext4_map_blocks+0x9c9/0x17d0 fs/ext4/inode.c:640 > ext4_iomap_alloc fs/ext4/inode.c:3428 [inline] > ext4_iomap_begin+0x463/0x7a0 fs/ext4/inode.c:3478 > iomap_apply+0x177/0xb50 fs/iomap/apply.c:46 > __iomap_dio_rw+0x71b/0x1280 fs/iomap/direct-io.c:553 > iomap_dio_rw+0x30/0x90 fs/iomap/direct-io.c:641 > ext4_dio_write_iter fs/ext4/file.c:551 [inline] > ext4_file_write_iter+0xe18/0x14e0 fs/ext4/file.c:661 > call_write_iter include/linux/fs.h:1977 [inline] > new_sync_write+0x426/0x650 fs/read_write.c:518 > vfs_write+0x796/0xa30 fs/read_write.c:605 > ksys_write+0x12d/0x250 fs/read_write.c:658 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x466459 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 > 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 > 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:7fadff8ad188 EFLAGS: 0246 ORIG_RAX: 0001 > RAX: ffda RBX: 0056bf60 RCX: 00466459 > RDX: 00248800 RSI: 2000 RDI: 0005 > RBP: 004bf9fb R08: R09: > R10: R11: 0246 R12: 0056bf60 > R13: 7ffc9e5e3caf R14: 7fadff8ad300 R15: 00022000 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[no subject]
outreachy-ker...@googlegroups.com, mitaliborkar...@gmail.com Bcc: Subject: [PATCH] staging: qlge:remove else after break Reply-To: Fixed Warning:- else is not needed after break break terminates the loop if encountered. else is unnecessary and increases indenatation Signed-off-by: Mitali Borkar --- drivers/staging/qlge/qlge_mpi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c index 2630ebf50341..3a49f187203b 100644 --- a/drivers/staging/qlge/qlge_mpi.c +++ b/drivers/staging/qlge/qlge_mpi.c @@ -935,13 +935,11 @@ static int qlge_idc_wait(struct qlge_adapter *qdev) netif_err(qdev, drv, qdev->ndev, "IDC Success.\n"); status = 0; break; - } else { - netif_err(qdev, drv, qdev->ndev, + } netif_err(qdev, drv, qdev->ndev, "IDC: Invalid State 0x%.04x.\n", mbcp->mbox_out[0]); status = -EIO; break; - } } return status; -- 2.30.2
Re: [PATCH 0/9] sched: Core scheduling interfaces
cc'ing Michal and Christian who've been spending some time on cgroup interface issues recently and Li Zefan for cpuset. On Thu, Apr 01, 2021 at 03:10:12PM +0200, Peter Zijlstra wrote: > The cgroup interface now uses a 'core_sched' file, which still takes 0,1. It > is > however changed such that you can have nested tags. The for any given task, > the > first parent with a cookie is the effective one. The rationale is that this > way > you can delegate subtrees and still allow them some control over grouping. I find it difficult to like the proposed interface from the name (the term "core" is really confusing given how the word tends to be used internally) to the semantics (it isn't like anything else) and even the functionality (we're gonna have fixed processors at some point, right?). Here are some preliminary thoughts: * Are both prctl and cgroup based interfaces really necessary? I could be being naive but given that we're (hopefully) working around hardware deficiencies which will go away in time, I think there's a strong case for minimizing at least the interface to the bare minimum. Given how cgroups are set up (membership operations happening only for seeding, especially with the new clone interface), it isn't too difficult to synchronize process tree and cgroup hierarchy where it matters - ie. given the right per-process level interface, restricting configuration for a cgroup sub-hierarchy may not need any cgroup involvement at all. This also nicely gets rid of the interaction between prctl and cgroup bits. * If we *have* to have cgroup interface, I wonder whether this would fit a lot better as a part of cpuset. If you squint just right, this can be viewed as some dynamic form of cpuset. Implementation-wise, it probably won't integrate with the rest but I think the feature will be less jarring as a part of cpuset, which already is a bit of kitchensink anyway. > The cgroup thing also '(ab)uses' cgroup_mutex for serialization because it > needs to ensure continuity between ss->can_attach() and ss->attach() for the > memory allocation. If the prctl() were allowed to interleave it might steal > the > memory. > > Using cgroup_mutex feels icky, but is not without precedent, > kernel/bpf/cgroup.c does the same thing afaict. > > TJ, can you please have a look at this? Yeah, using cgroup_mutex for stabilizing cgroup hierarchy for consecutive operations is fine. It might be worthwhile to break that out into a proper interface but that's the least of concerns here. Can someone point me to a realistic and concrete usage scenario for this feature? Thanks. -- tejun
[PATCH] task_work: add helper for more targeted task_work canceling
The only exported helper we have right now is task_work_cancel(), which cancels any task_work from a given task where func matches the queued work item. This is a bit too coarse for some use cases. Add a task_work_cancel_match() that allows to more specifically target individual work items outside of purely the callback function used. task_work_cancel() can be trivially implemented on top of that, hence do so. Signed-off-by: Jens Axboe --- I've got a patch on top of this that uses task_work_cancel_match(), but sending this one out separately. There should be no functional changes in this patch, it just allows someone to build func == func && data == data matches on top. diff --git a/include/linux/task_work.h b/include/linux/task_work.h index 0d848a1e9e62..5b8a93f288bb 100644 --- a/include/linux/task_work.h +++ b/include/linux/task_work.h @@ -22,6 +22,8 @@ enum task_work_notify_mode { int task_work_add(struct task_struct *task, struct callback_head *twork, enum task_work_notify_mode mode); +struct callback_head *task_work_cancel_match(struct task_struct *task, + bool (*match)(struct callback_head *, void *data), void *data); struct callback_head *task_work_cancel(struct task_struct *, task_work_func_t); void task_work_run(void); diff --git a/kernel/task_work.c b/kernel/task_work.c index 9cde961875c0..e9316198c64b 100644 --- a/kernel/task_work.c +++ b/kernel/task_work.c @@ -59,18 +59,17 @@ int task_work_add(struct task_struct *task, struct callback_head *work, } /** - * task_work_cancel - cancel a pending work added by task_work_add() + * task_work_cancel_match - cancel a pending work added by task_work_add() * @task: the task which should execute the work - * @func: identifies the work to remove - * - * Find the last queued pending work with ->func == @func and remove - * it from queue. + * @match: match function to call * * RETURNS: * The found work or NULL if not found. */ struct callback_head * -task_work_cancel(struct task_struct *task, task_work_func_t func) +task_work_cancel_match(struct task_struct *task, + bool (*match)(struct callback_head *, void *data), + void *data) { struct callback_head **pprev = &task->task_works; struct callback_head *work; @@ -86,7 +85,7 @@ task_work_cancel(struct task_struct *task, task_work_func_t func) */ raw_spin_lock_irqsave(&task->pi_lock, flags); while ((work = READ_ONCE(*pprev))) { - if (work->func != func) + if (!match(work, data)) pprev = &work->next; else if (cmpxchg(pprev, work, work->next) == work) break; @@ -96,6 +95,28 @@ task_work_cancel(struct task_struct *task, task_work_func_t func) return work; } +static bool task_work_func_match(struct callback_head *cb, void *data) +{ + return cb->func == data; +} + +/** + * task_work_cancel - cancel a pending work added by task_work_add() + * @task: the task which should execute the work + * @func: identifies the work to remove + * + * Find the last queued pending work with ->func == @func and remove + * it from queue. + * + * RETURNS: + * The found work or NULL if not found. + */ +struct callback_head * +task_work_cancel(struct task_struct *task, task_work_func_t func) +{ + return task_work_cancel_match(task, task_work_func_match, func); +} + /** * task_work_run - execute the works added by task_work_add() * -- Jens Axboe
[PATCH] kpc2000: kpc2000: Removed extra blank line
Fix checkpatch warning: CHECK: Please don't use multiple blank lines Signed-off-by: David Villasana Jiménez --- drivers/staging/kpc2000/kpc2000/pcie.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/kpc2000/kpc2000/pcie.h b/drivers/staging/kpc2000/kpc2000/pcie.h index cb815c30faa4..f1fc91b4c704 100644 --- a/drivers/staging/kpc2000/kpc2000/pcie.h +++ b/drivers/staging/kpc2000/kpc2000/pcie.h @@ -6,7 +6,6 @@ #include "../kpc.h" #include "dma_common_defs.h" - /* System Register Map (BAR 1, Start Addr 0) * * BAR Size: -- 2.30.2
Re: [PATCH] net: phy: fix PHY possibly unwork after MDIO bus resume back
On 04.04.2021 16:09, Heiner Kallweit wrote: > On 04.04.2021 12:07, Joakim Zhang wrote: >> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram may cut >> off PHY power") invokes phy_init_hw() when MDIO bus resume, it will >> soft reset PHY if PHY driver implements soft_reset callback. >> commit 764d31cacfe4 ("net: phy: micrel: set soft_reset callback to >> genphy_soft_reset for KSZ8081") adds soft_reset for KSZ8081. After these >> two patches, I found i.MX6UL 14x14 EVK which connected to KSZ8081RNB doesn't >> work any more when system resume back, MAC driver is fec_main.c. >> >> It's obvious that initializing PHY hardware when MDIO bus resume back >> would introduce some regression when PHY implements soft_reset. When I > > Why is this obvious? Please elaborate on why a soft reset should break > something. > >> am debugging, I found PHY works fine if MAC doesn't support suspend/resume >> or phy_stop()/phy_start() doesn't been called during suspend/resume. This >> let me realize, PHY state machine phy_state_machine() could do something >> breaks the PHY. >> >> As we known, MAC resume first and then MDIO bus resume when system >> resume back from suspend. When MAC resume, usually it will invoke >> phy_start() where to change PHY state to PHY_UP, then trigger the stat> >> machine to run now. In phy_state_machine(), it will start/config >> auto-nego, then change PHY state to PHY_NOLINK, what to next is >> periodically check PHY link status. When MDIO bus resume, it will >> initialize PHY hardware, including soft_reset, what would soft_reset >> affect seems various from different PHYs. For KSZ8081RNB, when it in >> PHY_NOLINK state and then perform a soft reset, it will never complete >> auto-nego. > > Why? That would need to be checked in detail. Maybe chip errata > documentation provides a hint. > The KSZ8081 spec says the following about bit BMCR_PDOWN: If software reset (Register 0.15) is used to exit power-down mode (Register 0.11 = 1), two software reset writes (Register 0.15 = 1) are required. The first write clears power-down mode; the second write resets the chip and re-latches the pin strapping pin values. Maybe this causes the issue you see and genphy_soft_reset() isn't appropriate for this PHY. Please re-test with the KSZ8081 soft reset following the spec comment. >> >> This patch changes PHY state to PHY_UP when MDIO bus resume back, it >> should be reasonable after PHY hardware re-initialized. Also give state >> machine a chance to start/config auto-nego again. >> > > If the MAC driver calls phy_stop() on suspend, then phydev->suspended > is true and mdio_bus_phy_may_suspend() returns false. As a consequence > phydev->suspended_by_mdio_bus is false and mdio_bus_phy_resume() > skips the PHY hw initialization. > Please also note that mdio_bus_phy_suspend() calls phy_stop_machine() > that sets the state to PHY_UP. > Forgot that MDIO bus suspend is done before MAC driver suspend. Therefore disregard this part for now. > Having said that the current argumentation isn't convincing. I'm not > aware of such issues on other systems, therefore it's likely that > something is system-dependent. > > Please check the exact call sequence on your system, maybe it > provides a hint. > >> Signed-off-by: Joakim Zhang >> --- >> drivers/net/phy/phy_device.c | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c >> index cc38e326405a..312a6f662481 100644 >> --- a/drivers/net/phy/phy_device.c >> +++ b/drivers/net/phy/phy_device.c >> @@ -306,6 +306,13 @@ static __maybe_unused int mdio_bus_phy_resume(struct >> device *dev) >> ret = phy_resume(phydev); >> if (ret < 0) >> return ret; >> + >> +/* PHY state could be changed to PHY_NOLINK from MAC controller resume >> + * rounte with phy_start(), here change to PHY_UP after re-initializing >> + * PHY hardware, let PHY state machine to start/config auto-nego again. >> + */ >> +phydev->state = PHY_UP; >> + >> no_resume: >> if (phydev->attached_dev && phydev->adjust_link) >> phy_start_machine(phydev); >> >
Re: [PATCH] staging: rtl8188eu: replace goto with direct return
On Sun, Apr 04, 2021 at 11:54:40AM +0200, Greg KH wrote: > On Sat, Apr 03, 2021 at 10:40:08PM -0700, Deborah Brouwer wrote: > > To conform with Linux kernel coding style, replace goto statement that > > does no cleanup with a direct return. To preserve meaning, copy comments > > from the original goto statement to the return statement. Identified by > > the checkpatch warning: WARNING: void function return statements are not > > generally useful. > > > > Signed-off-by: Deborah Brouwer > > --- > > drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c > > b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c > > index 391c59490718..d21f21857c20 100644 > > --- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c > > +++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c > > @@ -139,7 +139,9 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter) > > hw_init_completed = Adapter->hw_init_completed; > > > > if (!hw_init_completed) > > - goto skip_dm; > > + /* Check GPIO to determine current RF on/off and Pbc status. */ > > + /* Check Hardware Radio ON/OFF or not */ > > + return; > > It does not make sense to have the comments in two places here. The > original code is just fine, there's nothing wrong with the goto > statement here. > > thanks, > > greg k-h Ok, thanks for this feedback.
[PATCH] staging: iio: cdc: remove repeated word
Fix checkpatch warning: WARNING: Possible repeated word: 'from' Signed-off-by: David Villasana Jiménez --- drivers/staging/iio/cdc/ad7150.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c index 48132ab157ef..1be214512ff8 100644 --- a/drivers/staging/iio/cdc/ad7150.c +++ b/drivers/staging/iio/cdc/ad7150.c @@ -57,7 +57,7 @@ * @threshold: thresholds for simple capacitance value events * @thresh_sensitivity: threshold for simple capacitance offset * from 'average' value. - * @mag_sensitity: threshold for magnitude of capacitance offset from + * @mag_sensitity: threshold for magnitude of capacitance offset * from 'average' value. * @thresh_timeout: a timeout, in samples from the moment an * adaptive threshold event occurs to when the average -- 2.30.2
[PATCH] staging: rtl8192e: move const after static
Move the const after static to conform with kernel preference for static const declaration style instead of static const. Identified by checkpatch: WARNING: Move const after static - use 'static const char'. Signed-off-by: Deborah Brouwer --- drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c index e340be3ebb97..c53aa2d305ca 100644 --- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c +++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c @@ -260,7 +260,7 @@ void rtl92e_dm_watchdog(struct net_device *dev) static void _rtl92e_dm_check_ac_dc_power(struct net_device *dev) { struct r8192_priv *priv = rtllib_priv(dev); - static char const ac_dc_script[] = "/etc/acpi/wireless-rtl-ac-dc-power.sh"; + static const char ac_dc_script[] = "/etc/acpi/wireless-rtl-ac-dc-power.sh"; char *argv[] = {(char *)ac_dc_script, DRV_NAME, NULL}; static char *envp[] = {"HOME=/", "TERM=linux", @@ -1801,7 +1801,7 @@ static void _rtl92e_dm_check_rf_ctrl_gpio(void *data) enum rt_rf_power_state eRfPowerStateToSet; bool bActuallySet = false; char *argv[3]; - static char const RadioPowerPath[] = "/etc/acpi/events/RadioPower.sh"; + static const char RadioPowerPath[] = "/etc/acpi/events/RadioPower.sh"; static char *envp[] = {"HOME=/", "TERM=linux", "PATH=/usr/bin:/bin", NULL}; -- 2.17.1