On Wed, Nov 16, 2016 at 5:32 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Wednesday, November 16, 2016 4:20:47 PM CET Linus Walleij wrote: >> On Wed, Nov 16, 2016 at 1:46 PM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: >> >> > Well, we had a session at the KS regarding usage of the freezer on >> > kernel threads and the conclusion was to get rid of that (as opposed >> > to freezing user space, which is necessary IMO). So this change would >> > go in the opposite direction. >> >> Aha so I should not make this thread look like everyone else, instead >> everyone else should look like this thread, haha >> >> Ah well, I'll just drop it. > > It would still be good to remove the semaphore and do something else, > as we also want to remove all semaphores. ;-) > > We could check "mq->flags & MMC_QUEUE_SUSPENDED" in the kthread to see > if the queue is currently suspended, and otherwise go to sleep there, > and then call wake_up() in the resume function. Hm... so simply: if (mq->flags & MMC_QUEUE_SUSPENDED) schedule(); ? This whole kthread business is pretty messy. I would prefer if I could just convert it to a workqueue. Just that it's not very simple the way it speculates around in the request queue from the block layer. > While looking at that code, I just noticed that access to > mq->flags is racy and should be fixed as well. I guess we should take the queue lock &q->lock around accessing the flags. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
