From owner-freebsd-net Fri Nov 22 7:20:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3AE637B401 for ; Fri, 22 Nov 2002 07:20:30 -0800 (PST) Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BA0443E88 for ; Fri, 22 Nov 2002 07:20:27 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A0B54431AC; Fri, 22 Nov 2002 16:20:23 +0100 (CET) Received: from it.uc3m.es (zangano.it.uc3m.es [163.117.140.41]) by smtp02.uc3m.es (Postfix) with ESMTP id 5CCF999F36; Fri, 22 Nov 2002 16:20:19 +0100 (CET) Message-ID: <3DDE4B32.107DD140@it.uc3m.es> Date: Fri, 22 Nov 2002 16:20:18 +0100 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mattias Pettersson Cc: snap-users@kame.net, freebsd-net@FreeBSD.ORG Subject: Re: (KAME-snap 7197) Interrupt levels and concurrency References: <3DDD0E1B.80C8C4AA@it.uc3m.es> <3DDE045F.5CC8F5B5@era.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Mattias, Mattias Pettersson escribió: > > Hi, > > Giving it a try: > > Juan Francisco Rodriguez Hervella wrote: > > > > Hello (again :) > > > > I'm doing my best, but I'm in a mess trying to understand > > the interrup levels and if I should take it into account > > to implement what I want to implement :) > > > > As I'm working with KAME source code, I will CC this question. > > (KAME people always help me a lot :) > > > > I have the following situation: I've got an array, which > > is filled in using received packets, but it can also be filled in > > using the function "getaddrinfo()". Finally, this array > > is searched inside ip_output() function. > > > > So I was thinking of implementing the interaction between "getaddrinfo" > > and this kernel-array using "sysctl" interface, but I was wondering > > if I need to low the interrup level to fill in this array inside the > > sysctl_function(), because it could happen that at the same time > > a new packet arrived at and it can try to access the same structure. > > Yes, I think you should protect that piece of code with "spl(net)... " > inside sysctl, in case ip_input is pre-empting it. > > Doing that you can be sure that no other code running at "net" level > will mess with the array. > > > > I've implemented some other code with sysctls calls and I've never > > worried about the interrups levels, but now I've got a doubt... > > does "sysctl" takes into account the likehood of concurrent system calls > > ? > > I hope so.... > > > > Returning to my implementation, Would I have to worry about the case > > when "getaddrinfo" is calling to sysctl to add a new entry and then the > > function ip_output() begins to search the share structure also ? > > > > No. ip_output() I think runs at spl(net) too, so as long as sysctl is > running at net it should work fine. > > In addition, user space does not really have any priority over kernel. > > > I can see that my array can be accesed from (at least) the following > > points: > > > > 1. User layer (getaddrinfo) > > 2. IP layer (ip_input, ip_output) > > > > I was thinking of calling directly to the sysctl_function() inside > > ip_input() and also inside ip_output(). I hope there's no problem with > > this. > > Not sure. >I once tried to reuse in6_control() in the kernel to >achieve >something like an "ifconfig", but KAME didn't like that. > >Hope it helps. > > /Mattias Thanks for your fast reply... After thinking of it, I think you're right, with splnet inside sysctl function should be enough. Forget about my last paragraph, when I was talking about calling directly to sysctl_function from the ip_input(), I wanted to make that because the code for adding a new element in the array was implemented there.... forget it and thank you very much :) -- JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message