Bluetooth: cmtp: fix possible might sleep error in cmtp_session

It looks like cmtp_session has same pattern as the issue reported in
old rfcomm:

	while (1) {
		set_current_state(TASK_INTERRUPTIBLE);
		if (condition)
			break;
		// may call might_sleep here
		schedule();
	}
	__set_current_state(TASK_RUNNING);

Which fixed at:
	dfb2fae Bluetooth: Fix nested sleeps

So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/

Signed-off-by: Jeffy Chen <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Reviewed-by: AL Yu-Chen Cho <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>

0 files changed, 0 insertions, 0 deletions