From nobody Tue Apr 7 00:29:45 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6212C433FE for ; Sun, 9 Oct 2022 09:18:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229927AbiJIJSb (ORCPT ); Sun, 9 Oct 2022 05:18:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229899AbiJIJSZ (ORCPT ); Sun, 9 Oct 2022 05:18:25 -0400 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5164129C91 for ; Sun, 9 Oct 2022 02:18:24 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id h10so8080978plb.2 for ; Sun, 09 Oct 2022 02:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=zzW8eZ7a7hfTNZL5FpK7RIdYTP8PmTGim0k673uis3U=; b=vLWtU1/9k302WJB1R1VTrd+dZzHdZaWXm75UGvq+XOhcUTNQs1q+gO9JDPy2/QGYSa /UTrDI1Q9CSViqHTafA2Y7H+ha77O6fOq1lV0t9+19gXEUGImOzCWJCqvOVLt7vyDL+E UTilFJb4p6nXPWL7ntw8FQaeB0nJHFGOacrDU4ligDURcGUJcUFflz1GoJPDR1aL8vGx uzmpSowMh4Wd4tTNd+e7/mvxFVGb8eojyslp7UqN6NKPiKo6jMuOEba9MeLdA0MD8X0p Dh7s6RUf1qjYH4NXj+furAKRluoFagRteWRlGUbsh3QTLVXI3j3LNZwvMlumbWNo2D9Q 4+4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zzW8eZ7a7hfTNZL5FpK7RIdYTP8PmTGim0k673uis3U=; b=hTbV+PLqqLozNpPL04js9x5E8Nex7Pn42T0ABP9ynqmRS0LjPfm2NxmIN76u4oA3pb coxMQNO4teFASwHmI3C/u+GWb8+iDoBJvvyNzu2p0PmeB9sv7ryIDU2bcbw6BrZkcIXe bJAiCrBlPolGFAu75u1CDq5Chgzm4ETiC0Jr31OPscXncVcIB9JwfP4qwOvXxUPWoisH r/NejSHtgAbYWVMSznldNtCGmfhZgMQJnAQHahcYDMAKz2Wi3ZBrDipdWBCDHHkdQeeP 9RgMtqBJ451DiytFZl70PmM6zEI7K23tFiy2kcUyddpw9Ogor0PX8t/HicaRRSf3itqV IzHg== X-Gm-Message-State: ACrzQf2QS+uLeIIUVNlhud6TpHH8u+XZlw49leIPTCSrZJZaWI07vBID +KFQjW6o8vpoo7c2S4HUqsZ3ufHDHxiDwA== X-Google-Smtp-Source: AMsMyM5Pq0fzYL4VXG6ZwI5yV+7ecYkkOYUa+FglI4AO5zX1l3VL+AZd/uxM77w9Qja4hkIUEJ0VoQ== X-Received: by 2002:a17:902:9a8b:b0:17a:455:d967 with SMTP id w11-20020a1709029a8b00b0017a0455d967mr13415545plp.52.1665307103775; Sun, 09 Oct 2022 02:18:23 -0700 (PDT) Received: from localhost.localdomain ([139.177.225.234]) by smtp.gmail.com with ESMTPSA id f38-20020a635566000000b004405c6eb962sm4328711pgm.4.2022.10.09.02.18.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Oct 2022 02:18:23 -0700 (PDT) From: Zhang Yuchen To: minyard@acm.org Cc: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org, qi.zheng@linux.dev, Zhang Yuchen Subject: [PATCH v2 1/3] ipmi: fix msg stack when IPMI is disconnected Date: Sun, 9 Oct 2022 17:18:09 +0800 Message-Id: <20221009091811.40240-2-zhangyuchen.lcr@bytedance.com> X-Mailer: git-send-email 2.37.0 (Apple Git-136) In-Reply-To: <20221009091811.40240-1-zhangyuchen.lcr@bytedance.com> References: <20221009091811.40240-1-zhangyuchen.lcr@bytedance.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" If you continue to access and send messages at a high frequency (once every 55s) when the IPMI is disconnected, messages will accumulate in intf->[hp_]xmit_msg. If it lasts long enough, it takes up a lot of memory. The reason is that if IPMI is disconnected, each message will be set to IDLE after it returns to HOSED through IDLE->ERROR0->HOSED. The next message goes through the same process when it comes in. This process needs to wait for IBF_TIMEOUT * (MAX_ERROR_RETRIES + 1) =3D 55s. Each message takes 55S to destroy. This results in a continuous increase in memory. I find that if I wait 5 seconds after the first message fails, the status changes to ERROR0 in smi_timeout(). The next message will return the error code IPMI_NOT_IN_MY_STATE_ERR directly without wait. This is more in line with our needs. So instead of setting each message state to IDLE after it reaches the state HOSED, set state to ERROR0. After testing, the problem has been solved, no matter how many consecutive sends, will not cause continuous memory growth. It also returns to normal immediately after the IPMI is restored. In addition, the HOSED state should also count as invalid. So the HOSED is removed from the invalid judgment in start_kcs_transaction(). The verification operations are as follows: 1. Use BPF to record the ipmi_alloc/free_smi_msg(). $ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc %p\n",retval);} kprobe:free_recv_msg {printf("free %p\n",arg0)}' 2. Exec `date; time for x in $(seq 1 2); do ipmitool mc info; done`. 3. Record the output of `time` and when free all msgs. Before: `time` takes 120s, This is because `ipmitool mc info` send 4 msgs and waits only 15 seconds for each message. Last msg is free after 440s. $ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc %p\n",retval);} kprobe:free_recv_msg {printf("free %p\n",arg0)}' Oct 05 11:40:55 Attaching 2 probes... Oct 05 11:41:12 alloc 0xffff9558a05f0c00 Oct 05 11:41:27 alloc 0xffff9558a05f1a00 Oct 05 11:41:42 alloc 0xffff9558a05f0000 Oct 05 11:41:57 alloc 0xffff9558a05f1400 Oct 05 11:42:07 free 0xffff9558a05f0c00 Oct 05 11:42:07 alloc 0xffff9558a05f7000 Oct 05 11:42:22 alloc 0xffff9558a05f2a00 Oct 05 11:42:37 alloc 0xffff9558a05f5a00 Oct 05 11:42:52 alloc 0xffff9558a05f3a00 Oct 05 11:43:02 free 0xffff9558a05f1a00 Oct 05 11:43:57 free 0xffff9558a05f0000 Oct 05 11:44:52 free 0xffff9558a05f1400 Oct 05 11:45:47 free 0xffff9558a05f7000 Oct 05 11:46:42 free 0xffff9558a05f2a00 Oct 05 11:47:37 free 0xffff9558a05f5a00 Oct 05 11:48:32 free 0xffff9558a05f3a00 $ root@dc00-pb003-t106-n078:~# date;time for x in $(seq 1 2); do ipmitool mc info; done Wed Oct 5 11:41:12 CST 2022 No data available Get Device ID command failed No data available No data available No valid response received Get Device ID command failed: Unspecified error No data available Get Device ID command failed No data available No data available No valid response received No data available Get Device ID command failed real 1m55.052s user 0m0.001s sys 0m0.001s After: `time` takes 55s, all msgs is returned and free after 55s. $ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc %p\n",retval);} kprobe:free_recv_msg {printf("free %p\n",arg0)}' Oct 07 16:30:35 Attaching 2 probes... Oct 07 16:30:45 alloc 0xffff955943aa9800 Oct 07 16:31:00 alloc 0xffff955943aacc00 Oct 07 16:31:15 alloc 0xffff955943aa8c00 Oct 07 16:31:30 alloc 0xffff955943aaf600 Oct 07 16:31:40 free 0xffff955943aa9800 Oct 07 16:31:40 free 0xffff955943aacc00 Oct 07 16:31:40 free 0xffff955943aa8c00 Oct 07 16:31:40 free 0xffff955943aaf600 Oct 07 16:31:40 alloc 0xffff9558ec8f7e00 Oct 07 16:31:40 free 0xffff9558ec8f7e00 Oct 07 16:31:40 alloc 0xffff9558ec8f7800 Oct 07 16:31:40 free 0xffff9558ec8f7800 Oct 07 16:31:40 alloc 0xffff9558ec8f7e00 Oct 07 16:31:40 free 0xffff9558ec8f7e00 Oct 07 16:31:40 alloc 0xffff9558ec8f7800 Oct 07 16:31:40 free 0xffff9558ec8f7800 root@dc00-pb003-t106-n078:~# date;time for x in $(seq 1 2); do ipmitool mc info; done Fri Oct 7 16:30:45 CST 2022 No data available Get Device ID command failed No data available No data available No valid response received Get Device ID command failed: Unspecified error Get Device ID command failed: 0xd5 Command not supported in present state Get Device ID command failed: Command not supported in present state real 0m55.038s user 0m0.001s sys 0m0.001s Signed-off-by: Zhang Yuchen --- drivers/char/ipmi/ipmi_kcs_sm.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/char/ipmi/ipmi_kcs_sm.c b/drivers/char/ipmi/ipmi_kcs_s= m.c index efda90dcf5b3..ecfcb50302f6 100644 --- a/drivers/char/ipmi/ipmi_kcs_sm.c +++ b/drivers/char/ipmi/ipmi_kcs_sm.c @@ -122,10 +122,10 @@ struct si_sm_data { unsigned long error0_timeout; }; =20 -static unsigned int init_kcs_data(struct si_sm_data *kcs, - struct si_sm_io *io) +static unsigned int init_kcs_data_with_state(struct si_sm_data *kcs, + struct si_sm_io *io, enum kcs_states state) { - kcs->state =3D KCS_IDLE; + kcs->state =3D state; kcs->io =3D io; kcs->write_pos =3D 0; kcs->write_count =3D 0; @@ -140,6 +140,12 @@ static unsigned int init_kcs_data(struct si_sm_data *k= cs, return 2; } =20 +static unsigned int init_kcs_data(struct si_sm_data *kcs, + struct si_sm_io *io) +{ + return init_kcs_data_with_state(kcs, io, KCS_IDLE); +} + static inline unsigned char read_status(struct si_sm_data *kcs) { return kcs->io->inputb(kcs->io, 1); @@ -270,7 +276,7 @@ static int start_kcs_transaction(struct si_sm_data *kcs= , unsigned char *data, if (size > MAX_KCS_WRITE_SIZE) return IPMI_REQ_LEN_EXCEEDED_ERR; =20 - if ((kcs->state !=3D KCS_IDLE) && (kcs->state !=3D KCS_HOSED)) { + if (kcs->state !=3D KCS_IDLE) { dev_warn(kcs->io->dev, "KCS in invalid state %d\n", kcs->state); return IPMI_NOT_IN_MY_STATE_ERR; } @@ -495,7 +501,7 @@ static enum si_sm_result kcs_event(struct si_sm_data *k= cs, long time) } =20 if (kcs->state =3D=3D KCS_HOSED) { - init_kcs_data(kcs, kcs->io); + init_kcs_data_with_state(kcs, kcs->io, KCS_ERROR0); return SI_SM_HOSED; } =20 --=20 2.30.2 From nobody Tue Apr 7 00:29:45 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 267B5C433F5 for ; Sun, 9 Oct 2022 09:18:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229979AbiJIJSl (ORCPT ); Sun, 9 Oct 2022 05:18:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229923AbiJIJS2 (ORCPT ); Sun, 9 Oct 2022 05:18:28 -0400 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACF272B1AA for ; Sun, 9 Oct 2022 02:18:27 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id p14so4122006pfq.5 for ; Sun, 09 Oct 2022 02:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kKFjny/9mWuO/iG0Kxc5VvaxquxrAamtdUptPDp0d74=; b=ojQqKCdE1xWnmbi41ppc32d+eOC7AWp0Z8fAmyiBCoOubBhyz21Z9rC7wh21wSzkWr Blh98iWF76sGUhTbkD20/++kK597nR3eZKk9Q8+XUaTP7xZWD+znQoJva6NviowPO09E rEpoKXUyqJ3MHO0Zmx9VAIwUuW0LiY/5kEQeOzzmcCSEUys8Csa4jrUuW+b0vbCDKoTd B7A6LKNJo6lZbsYaWcq92O+uPUk7yXDvOYXzCeNlYNSkM0ozVwAc+oBtCrGpyQcsKa3S yIIVa5FTtlLaIPL6tZhecGJu8mYNLn+v+46/m1iBsAely7nOeCqkxF6hZPFePoY1G1wm bw2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kKFjny/9mWuO/iG0Kxc5VvaxquxrAamtdUptPDp0d74=; b=vz8MWcb5W1CpWDFkXXWyPP4vLAE22bFb/OkP3KJf7JRJT3dsHINcNywOrZ9Z+OEUvK ShaG2sr3dp/q2Etbf/9gLXlQxB71QL7ZrFX7onqdU4gdEWD+B3bcehUMBFzzRNb1ou0y 3m7f7GtOxQKnvdmHUhWmhTTDoAN4ILUzTbSoJUKizEzNxge7ZRxKbSfeJkIRN4CTZmYw gc+/pxwUhfD5KlhOF2xw1oHbyCux3Th4EBLczRxbi106V29wPCa+kmCfknEq7z+YWKD2 Ij8xZz42I1SBbmvbQBAF7/0s1lWR/Aq2OrPyxaVVTy5W0qe8YtzcJkJqtxlPp0Yc5jZ8 iptw== X-Gm-Message-State: ACrzQf1pXmU5gW9jOLnDPRny9w45cMudGd8Lc2VshCOZl6CuQknoD5DJ WLOOyjW4vLtRuXpAdQKZqb+QFw== X-Google-Smtp-Source: AMsMyM4tSxYbXYtzOq11CTZtT49IL2PjNyOj9GZtNR3Z8wRpNJP4JMMrmFnExO9hOFCydmTujtOhIA== X-Received: by 2002:a63:ff1b:0:b0:43c:e4ee:e5e0 with SMTP id k27-20020a63ff1b000000b0043ce4eee5e0mr11382651pgi.540.1665307107095; Sun, 09 Oct 2022 02:18:27 -0700 (PDT) Received: from localhost.localdomain ([139.177.225.234]) by smtp.gmail.com with ESMTPSA id f38-20020a635566000000b004405c6eb962sm4328711pgm.4.2022.10.09.02.18.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Oct 2022 02:18:26 -0700 (PDT) From: Zhang Yuchen To: minyard@acm.org Cc: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org, qi.zheng@linux.dev, Zhang Yuchen Subject: [PATCH v2 2/3] ipmi: fix long wait in unload when IPMI disconnect Date: Sun, 9 Oct 2022 17:18:10 +0800 Message-Id: <20221009091811.40240-3-zhangyuchen.lcr@bytedance.com> X-Mailer: git-send-email 2.37.0 (Apple Git-136) In-Reply-To: <20221009091811.40240-1-zhangyuchen.lcr@bytedance.com> References: <20221009091811.40240-1-zhangyuchen.lcr@bytedance.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" When fixing the problem mentioned in PATCH1, we also found the following problem: If the IPMI is disconnected and in the sending process, the uninstallation driver will be stuck for a long time. The main problem is that uninstalling the driver waits for curr_msg to be sent or HOSED. After stopping tasklet, the only place to trigger the timeout mechanism is the circular poll in shutdown_smi. The poll function delays 10us and calls smi_event_handler(smi_info,10). Smi_event_handler deducts 10us from kcs->ibf_timeout. But the poll func is followed by schedule_timeout_uninterruptible(1). The time consumed here is not counted in kcs->ibf_timeout. So when 10us is deducted from kcs->ibf_timeout, at least 1 jiffies has actually passed. The waiting time has increased by more than a hundredfold. Now instead of calling poll(). call smi_event_handler() directly and calculate the elapsed time. For verification, you can directly use ebpf to check the kcs-> ibf_timeout for each call to kcs_event() when IPMI is disconnected. Decrement at normal rate before unloading. The decrement rate becomes very slow after unloading. $ bpftrace -e 'kprobe:kcs_event {printf("kcs->ibftimeout : %d\n", *(arg0+584));}' Signed-off-by: Zhang Yuchen --- drivers/char/ipmi/ipmi_si_intf.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_i= ntf.c index 6e357ad76f2e..abddd7e43a9a 100644 --- a/drivers/char/ipmi/ipmi_si_intf.c +++ b/drivers/char/ipmi/ipmi_si_intf.c @@ -2153,6 +2153,20 @@ static int __init init_ipmi_si(void) } module_init(init_ipmi_si); =20 +static void wait_msg_processed(struct smi_info *smi_info) +{ + unsigned long jiffies_now; + long time_diff; + + while (smi_info->curr_msg || (smi_info->si_state !=3D SI_NORMAL)) { + jiffies_now =3D jiffies; + time_diff =3D (((long)jiffies_now - (long)smi_info->last_timeout_jiffies) + * SI_USEC_PER_JIFFY); + smi_event_handler(smi_info, time_diff); + schedule_timeout_uninterruptible(1); + } +} + static void shutdown_smi(void *send_info) { struct smi_info *smi_info =3D send_info; @@ -2187,16 +2201,13 @@ static void shutdown_smi(void *send_info) * in the BMC. Note that timers and CPU interrupts are off, * so no need for locks. */ - while (smi_info->curr_msg || (smi_info->si_state !=3D SI_NORMAL)) { - poll(smi_info); - schedule_timeout_uninterruptible(1); - } + wait_msg_processed(smi_info); + if (smi_info->handlers) disable_si_irq(smi_info); - while (smi_info->curr_msg || (smi_info->si_state !=3D SI_NORMAL)) { - poll(smi_info); - schedule_timeout_uninterruptible(1); - } + + wait_msg_processed(smi_info); + if (smi_info->handlers) smi_info->handlers->cleanup(smi_info->si_sm); =20 --=20 2.30.2 From nobody Tue Apr 7 00:29:45 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7964C433FE for ; Sun, 9 Oct 2022 09:18:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230042AbiJIJSw (ORCPT ); Sun, 9 Oct 2022 05:18:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229950AbiJIJSd (ORCPT ); Sun, 9 Oct 2022 05:18:33 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A64342B63D for ; Sun, 9 Oct 2022 02:18:30 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id c24so8081372plo.3 for ; Sun, 09 Oct 2022 02:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=260/9mSp6N4PpoN+t1d8Szrje/MbRn7Uh6Ecn3s2qCU=; b=zJER6xqZquJ/D6Jn6QCwMKJQKP0O8vuTCfztN0u7I4uVIW8F9fysfOJhyloKWH03b9 rT1mwwjyFDrbMIk6uUuB1va9N6qkz6dfHnKLsvX36Om4cILlHvh90JnI3/MkIE27+DOL BVbKeCLk/OOHz0qYSWO1VFVV6nesf2YOzWHOGfZLlRMESh6eoBzCM5KbiMfHHTkisquB 0BYHKDWu+REcQozKfAcqNSxNxhE0WsLoRKsObc9YQHBXAvutEY6JJirtUxzvzzyYQOHJ CIinOXqVH5g1dPDi20DbS5k6XJnXdmwUuUcB11dN7OPMld8FztoBkSd3NmpyPj1sjkcq Q+bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=260/9mSp6N4PpoN+t1d8Szrje/MbRn7Uh6Ecn3s2qCU=; b=5QMUeXdckoJy0cDIwg5Xqedxb7lWUuABVdZqt3W3xbMC57Qzj4mJDIFX8IphTfDNJL SKvet/4gxCtSviJLPlfpW+GOarUT03/9nSDEi802dmrCzrdk3WiktZmqvgskXCPmk/hW j7u1CVmKyGf9Yfpl+jhTyXDCQec8dDrn9nRR4JjAApxtZuAhSZioBCEHqMN7y/gYQpT+ f/8aGUtNcLnlYN2lazfiGg961zHIWzOd+tpIaa86VAQWVGv/cYEFTZRGCWXnP/JWJljf YnjSPCWVeGMyd7JvgFj3OCAtZ9pyHPh6WX53oqsWUkRw2qj2f2TwZxKSPYB5Q0oPpRp7 UcgA== X-Gm-Message-State: ACrzQf2YDJeXkDVbU58kpbfbZUvO7kCjZ/ky/YIAB9PCnR39FjOfso+F xc2i6rnBm4dhhy8S8vuaoQjIGw== X-Google-Smtp-Source: AMsMyM7rJdAD6jzLSqpd5byQGnIXhnyu1XJxY73dndrP6nl4twcAIGjdUQT+yuvVkQdugSwgSiCLSg== X-Received: by 2002:a17:902:bb96:b0:17d:9ed7:e9af with SMTP id m22-20020a170902bb9600b0017d9ed7e9afmr13013182pls.15.1665307110193; Sun, 09 Oct 2022 02:18:30 -0700 (PDT) Received: from localhost.localdomain ([139.177.225.234]) by smtp.gmail.com with ESMTPSA id f38-20020a635566000000b004405c6eb962sm4328711pgm.4.2022.10.09.02.18.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Oct 2022 02:18:29 -0700 (PDT) From: Zhang Yuchen To: minyard@acm.org Cc: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org, qi.zheng@linux.dev, Zhang Yuchen Subject: [PATCH v2 3/3] ipmi: fix memleak when unload ipmi driver Date: Sun, 9 Oct 2022 17:18:11 +0800 Message-Id: <20221009091811.40240-4-zhangyuchen.lcr@bytedance.com> X-Mailer: git-send-email 2.37.0 (Apple Git-136) In-Reply-To: <20221009091811.40240-1-zhangyuchen.lcr@bytedance.com> References: <20221009091811.40240-1-zhangyuchen.lcr@bytedance.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" After the IPMI disconnect problem, the memory kept rising and we tried to unload the driver to free the memory. However, only part of the free memory is recovered after the driver is uninstalled. Using ebpf to hook free functions, we find that neither ipmi_user nor ipmi_smi_msg is free, only ipmi_recv_msg is free. We find that the deliver_smi_err_response call in clean_smi_msgs does the destroy processing on each message from the xmit_msg queue without checking the return value and free ipmi_smi_msg. deliver_smi_err_response is called only at this location. Adding the free handling has no effect. To verify, try using ebpf to trace the free function. $ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc rcv %p\n",retval);} kprobe:free_recv_msg {printf("free recv %p\n", arg0)} kretprobe:ipmi_alloc_smi_msg {printf("alloc smi %p\n", retval);} kprobe:free_smi_msg {printf("free smi %p\n",arg0)}' Signed-off-by: Zhang Yuchen --- drivers/char/ipmi/ipmi_msghandler.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_m= sghandler.c index c8a3b208f923..bd522868efef 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -3710,12 +3710,15 @@ static void deliver_smi_err_response(struct ipmi_sm= i *intf, struct ipmi_smi_msg *msg, unsigned char err) { + int rv; msg->rsp[0] =3D msg->data[0] | 4; msg->rsp[1] =3D msg->data[1]; msg->rsp[2] =3D err; msg->rsp_size =3D 3; - /* It's an error, so it will never requeue, no need to check return. */ - handle_one_recv_msg(intf, msg); + + rv =3D handle_one_recv_msg(intf, msg); + if (rv =3D=3D 0) + ipmi_free_smi_msg(msg); } =20 static void cleanup_smi_msgs(struct ipmi_smi *intf) --=20 2.30.2