Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Jes Sorensen <jes.sorensen@gmail.com>
To:     minyard@acm.org
Cc:     linux-kernel@vger.kernel.org,
        openipmi-developer@lists.sourceforge.net, kernel-team@fb.com
Subject: [PATCH 0/1] Fix race in ipmi timer cleanup
Date:   Wed, 28 Aug 2019 16:36:24 -0400
Message-Id: <20190828203625.32093-1-Jes.Sorensen@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Jes Sorensen <jsorensen@fb.com>

I came across this in 4.16, but I believe the bug is still present
in current 5.x, even if it is less likely to trigger.

Basially stop_timer_and_thread() only calls del_timer_sync() if
timer_running == true. However smi_mod_timer enables the timer before
setting timer_running = true.

I was able to reproduce this in 4.16 running the following on a host

   while :; do rmmod ipmi_si ; modprobe ipmi_si; done

while rebooting the BMC on it in parallel.

5.2 moves the error handling around and does it more centralized, but
relying on timer_running still seems dubious to me.

static void smi_mod_timer(struct smi_info *smi_info, unsigned long new_val)
{
        if (!smi_info->timer_can_start)
                return;
        smi_info->last_timeout_jiffies = jiffies;
        mod_timer(&smi_info->si_timer, new_val);
        smi_info->timer_running = true;
}

static inline void stop_timer_and_thread(struct smi_info *smi_info)
{
        if (smi_info->thread != NULL) {
                kthread_stop(smi_info->thread);
                smi_info->thread = NULL;
        }

        smi_info->timer_can_start = false;
        if (smi_info->timer_running)
                del_timer_sync(&smi_info->si_timer);
}

Cheers,
Jes

Jes Sorensen (1):
  ipmi_si_intf: Fix race in timer shutdown handling

 drivers/char/ipmi/ipmi_si_intf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.21.0