Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752761AbbKYU60 (ORCPT ); Wed, 25 Nov 2015 15:58:26 -0500 Received: from tiger.mobileactivedefense.com ([217.174.251.109]:39773 "EHLO tiger.mobileactivedefense.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751211AbbKYU6X (ORCPT ); Wed, 25 Nov 2015 15:58:23 -0500 From: Rainer Weikusat To: Eric Dumazet Cc: Rainer Weikusat , Eric Dumazet , Dmitry Vyukov , Benjamin LaHaise , "David S. Miller" , Hannes Frederic Sowa , Al Viro , David Howells , Ying Xue , "Eric W. Biederman" , netdev , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin Subject: Re: use-after-free in sock_wake_async In-Reply-To: <1448483017.24696.33.camel@edumazet-glaptop2.roam.corp.google.com> (Eric Dumazet's message of "Wed, 25 Nov 2015 12:23:37 -0800") References: <87poyzj7j2.fsf@doppelsaurus.mobileactivedefense.com> <87io4qevdp.fsf@doppelsaurus.mobileactivedefense.com> <87io4q3u8u.fsf@doppelsaurus.mobileactivedefense.com> <1448471494.24696.18.camel@edumazet-glaptop2.roam.corp.google.com> <87a8q23s2a.fsf@doppelsaurus.mobileactivedefense.com> <1448473891.24696.21.camel@edumazet-glaptop2.roam.corp.google.com> <87610q3pjg.fsf@doppelsaurus.mobileactivedefense.com> <1448476744.24696.25.camel@edumazet-glaptop2.roam.corp.google.com> <87y4dl3m5c.fsf@doppelsaurus.mobileactivedefense.com> <1448481002.24696.30.camel@edumazet-glaptop2.roam.corp.google.com> <1448483017.24696.33.camel@edumazet-glaptop2.roam.corp.google.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Wed, 25 Nov 2015 20:57:59 +0000 Message-ID: <87two93ig8.fsf@doppelsaurus.mobileactivedefense.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (tiger.mobileactivedefense.com [217.174.251.109]); Wed, 25 Nov 2015 20:58:08 +0000 (GMT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1129 Lines: 26 Eric Dumazet writes: > On Wed, 2015-11-25 at 11:50 -0800, Eric Dumazet wrote: > >> > other->sk_data_ready(other); >> > + unix_state_unlock(other); > > > Also, problem with such construct is that we wakeup a thread that will > block on the lock we hold. > > Beauty of sk_data_ready() is to call it once we hold no lock any more, > to enable another cpu to immediately proceed. > > In this case, 'other' can not disappear, so it should be safe. I do agree that keeping the ->sk_data_ready outside of the lock will very likely have performance advantages. That's just something I wouldn't have undertaken because I'd be reluctant to make a fairly complicated change to a lot of code in order to improve performance unless performance was actually found to be lacking and because it would step onto to many different people's turf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/