From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: IPv4/IPv6 sysctl unregistration deadlock Date: Wed, 25 Feb 2009 22:10:33 -0800 Message-ID: References: <49A4D5D5.5090602@trash.net> <20090225061902.GA32430@gondor.apana.org.au> <49A4E3F8.4050406@trash.net> <49A4F0D7.20304@trash.net> <20090225084321.GA1101@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Patrick McHardy , Linux Netdev List To: Herbert Xu Return-path: Received: from out02.mta.xmission.com ([166.70.13.232]:34382 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752819AbZBZGKB (ORCPT ); Thu, 26 Feb 2009 01:10:01 -0500 In-Reply-To: <20090225084321.GA1101@gondor.apana.org.au> (Herbert Xu's message of "Wed\, 25 Feb 2009 16\:43\:21 +0800") Sender: netdev-owner@vger.kernel.org List-ID: Herbert Xu writes: > On Wed, Feb 25, 2009 at 08:18:47AM +0100, Patrick McHardy wrote: >> >> Unfortunately its more complicated than I thought because of >> device renames, where the sysctl pointer is reused after >> unregistration and the rename/unregistration/re-registration >> should be atomic. Deferring unregistration means we can't perform >> the new registration immediately unless we allow multiple >> registrations for a single device to be active simulaneously, >> which introduces a whole new set of problems. > > Good point. > >> Simply ignoring the request during unregistration doesn't seem >> so bad after all, the main problem is that it intoduces a different >> race on renames where a write to the "forwarding" file returns >> success, but the change doesn't take effect. We could return >> -ENOENT, but that seems a bit strange after open() returned success. >> Maybe -EBUSY, although I would prefer to make this transparent >> to userspace. > > I'd like to avoid that for the rename case just because shell > scripts know how to deal with echo foo > /nonexist/file but not > necessarily a failed echo on write/close. > >> I think I'm stuck. Will rethink it after some coffee :) > > Yes we need more coffee :) How does adding a rename operation to sysctl sound? I am a little concerned that if we have this issue with sysctl we also have it with proc and sysfs as well. Although I admit I don't understand it yet. Eric