From owner-freebsd-current Mon Apr 15 16:40:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 8D11B37B405; Mon, 15 Apr 2002 16:40:09 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020415234008.VPQX1901.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 15 Apr 2002 23:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA88954; Mon, 15 Apr 2002 16:24:10 -0700 (PDT) Date: Mon, 15 Apr 2002 16:24:09 -0700 (PDT) From: Julian Elischer To: Maksim Yevmenkin Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Bluetooth stack for FreeBSD In-Reply-To: <3CBB36DB.850B4BEE@digisle.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi... I have been reading the (well actually, "looking at" may be more acurate.. some minor comments.. ng_btsocket.c: unmodified: line 674 sbappendrecord(&pcb->so->so_snd, m); m = m_dup(m, M_TRYWAIT); if (m == NULL) { error = ENOBUFS; goto drop1; } you are m_dup'ing an mbuf you have given away to the socket layer. on an SMP system this may already be destroyed by the time you do the m_dup() in fact if the sbappendrecord() fails due to a full queue, it may already be invalid... (I think) also all functions should be 'prototype format' e.g. static int ng_btsocket_peeraddr(so, nam) struct socket *so; struct sockaddr **nam; { should be: static int ng_btsocket_peeraddr(struct socket *so, struct sockaddr **nam) { also: __P() is now "deprecated" and should not be used in new code. Your idea of making a special bluetooth socket type, implemented by a Netgraph node is interesting. Maybe we should it easier to do this by extending the netgraph socket type with the ability to make sockets of arbitrary types... i.e. register a node type that acts as a 'subtype' of the 'socket' type, and inherrits generic socket behaviour, but allow the 'child type' to specify other parts to replace normal behaviour.. I guess we would need to see a few more cases of this done before we could deduce what is likely to be a good candidate for abstraction. you ask: /* * XXX FIXME/VERIFY i assume here that "hook" is a pointer * to the local hook we have received message from. For * L2CAP messages "hook" is required. */ This is true for 5.0 in 4.x there is no such thing as an arrival hook for a message. You should however not assume that it is non-NULL. test it in normal running code.. not in a KASSERT. There are transitional moments (during shutdown for example) when a message may arrive without a hook, in fact a malicious user might force that to happen at any time by simply send ing that message directly to the ID of the node. For messages passed by a neighbour via a hokk the hook field will be filled in but there are other ways that you may get a message. [out of time for now.. will read more later] Julian On Mon, 15 Apr 2002, Maksim Yevmenkin wrote: > Folks, > > [probably should be cc'd to -mobile as well] > > An engineering release of Bluetooth stack for -current FreeBSD > is available for download at > > http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz > > i'm interested to hear from people who familiar with FreeBSD > kernel, Netgraph and/or Bluetooth. all your questions/comments/ > suggestions are accepted and greatly appreciated. this is my > first Netgraph stack, so please don't me hard :) > > thanks, > max > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message