linux-kernel - Re: [PATCH] soundwire: cadence: fix race condition between suspend and Slave device alerts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <77ecb4bc-10d6-8fbd-e97f-923d01a5e555@linux.intel.com>
Date:   Fri, 28 Aug 2020 10:14:50 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     Bard Liao <yung-chuan.liao@...ux.intel.com>,
        alsa-devel@...a-project.org, tiwai@...e.de,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        ranjani.sridharan@...ux.intel.com, hui.wang@...onical.com,
        broonie@...nel.org, srinivas.kandagatla@...aro.org,
        jank@...ence.com, mengdong.lin@...el.com, sanyog.r.kale@...el.com,
        rander.wang@...ux.intel.com, bard.liao@...el.com
Subject: Re: [PATCH] soundwire: cadence: fix race condition between suspend
 and Slave device alerts




> Is this timeout for suspend or resume? Somehow I was under the
> assumption that it is former? Or is the result seen on resume?
> 
> Rereading the race describe above in steps, I think this should be
> handled in step c above. Btw is that suspend or runtime suspend which
> causes this? Former would be bigger issue as we should not have work
> running when we return from suspend call. Latter should be dealt with
> anyway as device might be off after suspend.

This happens with a system suspend. Because we disable the interrupts, 
the workqueue never completes, and we have a timeout on system resume.

That's why we want to prevent the workqueue from starting, or let it 
complete, but not have this zombie state where we suspend but there's 
still a wait for completion that times out later. The point here is 
really  making sure the workqueue is not used before suspend.