netdev - Re: IrDA woes..

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+55aFyFAaHgoTe_ZVs3F0Giy4qDndKsE6GbB4DgcaK7QkXOkA@mail.gmail.com>
Date:	Thu, 2 Jan 2014 13:07:05 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
Cc:	Samuel Ortiz <samuel@...tiz.org>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: IrDA woes..

On Thu, Jan 2, 2014 at 11:11 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I get the feeling that the code was written back in the bad old days
> when we had the big kernel lock, and timers and network bottom half
> handling were all mutually exclusive.

Hmm. It even has a comment to that effect, see
irlap_resend_rejected_frames(), which does that skb_queue_walk()
without taking the queue lock. It says:

 *    Resend frames which has not been acknowledged. Should be safe to
 *    traverse the list without locking it since this function will only be
 *    called from interrupt context (BH)

and I don't *think* that is true any more.

Now, because it is in bottom half contect, I think it won't be
re-entered on the same CPU, but another cpu might be busy doing
irda_rcv(). No?

So I'd be inclined to take the queue lock (self->wx_list.lock) around
that skb_queue_walk(). Or am I just dazed and confused?

                    Linus
--
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