Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755524Ab2K3BjS (ORCPT ); Thu, 29 Nov 2012 20:39:18 -0500 Received: from hedwig.cmf.nrl.navy.mil ([134.207.12.162]:38180 "EHLO hedwig.cmf.nrl.navy.mil" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752787Ab2K3BjO (ORCPT ); Thu, 29 Nov 2012 20:39:14 -0500 Message-Id: <201211300138.qAU1c8sE003388@thirdoffive.cmf.nrl.navy.mil> From: "Chas Williams (CONTRACTOR)" To: David Woodhouse cc: Krzysztof Mazur , David Laight , davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, nathan@traverse.com.au Subject: Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc In-reply-to: <1354227428.21562.230.camel@shinybook.infradead.org> Date: Thu, 29 Nov 2012 20:38:08 -0500 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1009 Lines: 18 In message <1354227428.21562.230.camel@shinybook.infradead.org>,David Woodhouse writes: >At this point, I think we're better off as we are (with Krzysztof's >patch 1/7 dropped, and leaving vcc->dev->ops->close() being called >before vcc->push(NULL). We've fairly much solved the issues with that >arrangement, by checking ATM_VF_READY in the protocols' ->push() >functions. it isnt clear to me that fixes the race entirely either. vcc_destroy_socket() and any of the push()/sends()'s are not serialized. while you may clear the ATM_VF_READY flag, you might not clear it soon enough for any particular push() that is already running. so it still seems like you are racing close() against push() at this point. the window is greatly reduced, but it still exists. -- 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/