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]
Date:	Thu, 30 Sep 2010 22:22:03 -0300
From:	"Gustavo F. Padovan" <padovan@...fusion.mobi>
To:	David Miller <davem@...emloft.net>
Cc:	linville@...driver.com, marcel@...tmann.org,
	linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: pull-request: bluetooth-2.6 2010-09-27

Hi Dave,

* David Miller <davem@...emloft.net> [2010-09-30 17:26:57 -0700]:

> From: "Gustavo F. Padovan" <padovan@...fusion.mobi>
> Date: Tue, 28 Sep 2010 19:49:41 -0300
> 
> > Actually sk_stream_wait_memory is another point why it's safe to release
> > the lock and block waiting for memory. We've been doing that safely in
> > protocols like TCP, SCTP and DCCP for a long time.
> 
> Do you notice what TCP does when sk_stream_wait_memory() returns?
> 
> It reloads all volatile state that might have changed in the socket
> while the lock was dropped.
> 
> For example, TCP will reload the current MSS that can change
> asynchronously while we don't have the socket lock.

I got your point. And what I tried to say in the last e-mail is that
ERTM doesn't have such volatile states that need to restore after get
the lock back. The others code path it affect are very simple and also
doesn't have such problem. So we are safe against asynchronous changes.
We obvious have volatiles states, but the code paths where
bt_skb_send_alloc() is used doesn't rely on that states. I'm seeing no
problem on release the lock, alloc memory, and lock it again.

-- 
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists