linux-kernel - Re: 'scheduling while atomic' during ppp connection on 2.6.37.1 and 2.6.38

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: <6627fbdd-cce6-4717-8920-3a0d7526274b@email.android.com>
Date:	Sun, 20 Mar 2011 23:05:46 +0000
From:	Jack Stone <jwjstone@...tmail.fm>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Mac <kmac@...zta.fm>, linux-kernel@...r.kernel.org,
	linux-ppp@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: 'scheduling while atomic' during ppp connection on 2.6.37.1 and 2.6.38

Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

>> +        spin_lock_irqsave(&dc->spin_mutex, flags);
>>           if (port->port.count)
>>               room = kfifo_avail(&port->fifo_ul);
>> -        mutex_unlock(&port->tty_sem);
>> +        spin_unlock_irqrestore(&dc->spin_mutex, flags);
>
>dc->spin_mutex does not protect port->port.count.

Sorry if I'm being stupid here but do you mean that port->port.count is modified outside of dc->spin_mutex or that dc->spin_mutex should not be used to protect port->port.count?

I replaced all instances of the port->tty_sem with dc->spin_mutex and port->port.count is only used if dc is non null.

The only other possible problem I see with the change is that the new locking does not allow sleeping in places where it could sleep and disabled irqs where they were not disabled before.

Thank you for your time,

Jack

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/