From owner-freebsd-pf@FreeBSD.ORG Wed Sep 19 19:42:50 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0DAF106566C; Wed, 19 Sep 2012 19:42:49 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 236B18FC0A; Wed, 19 Sep 2012 19:42:48 +0000 (UTC) Received: by bkcje9 with SMTP id je9so718091bkc.13 for ; Wed, 19 Sep 2012 12:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4fjmPerd4LUUALXfu3oesyYwCWkL9kpeTV10UaI25w8=; b=0O9wmJpF4SgVSgMHvc6EH+cV7VoKEVQ2fNhLoCaEAUMID4ypqevSt9p014YKcHAmxc d3h2C8JbkHtZEZHoe0DcCIWXH8R6MIN4OVFQE5gHVYcl+6FwjEKZ0smLmjwV4zC3pvGK 85/bYNPPSR1wAxVCFnu2+xKAHdLQiLb6SaCG01822RdnNk4D/uvBMMfNU4K2Y7bBQCpr q5zHepRH7ayBbAw23OfXAhA9TYCGyA9o0QZZ4BP4yyXLPNg7UdIlJYxU6/dlFnCuezQR sXAgLLrg3Mdczs5r3dwi8/TFOdsgOQ2aLeyMpvwqG5gzwDC16MkwYmk2fk1UKjtKsok3 AKoQ== MIME-Version: 1.0 Received: by 10.204.3.207 with SMTP id 15mr1663761bko.98.1348083767997; Wed, 19 Sep 2012 12:42:47 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.204.48.194 with HTTP; Wed, 19 Sep 2012 12:42:47 -0700 (PDT) In-Reply-To: <20120918161516.GG85604@glebius.int.ru> References: <201209181234.q8ICYaFB091109@svn.freebsd.org> <20120918161516.GG85604@glebius.int.ru> Date: Wed, 19 Sep 2012 21:42:47 +0200 X-Google-Sender-Auth: f6LAbNeiC5sCbh08c34nlK1m7Dk Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: Sergey Kandaurov , freebsd-pf@freebsd.org Subject: Re: svn commit: r240646 - head/sys/contrib/altq/altq X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 19:42:50 -0000 On Tue, Sep 18, 2012 at 6:15 PM, Gleb Smirnoff wrote: > Ermal, > > On Tue, Sep 18, 2012 at 06:02:06PM +0200, Ermal Lu?i wrote: > E> The issue is that this hides the problem per se. > > What had hidden problem per se, was the following code: > > PF_UNLOCK(); > error = altq_add(a2); > PF_LOCK(); > > That's what we have in stable/9. > > E> The ioctl and pfctl loading of ruleset is not ready for handling failures here! > > They do. Error from altq_add() is returned by pf_ioctl() as response > to DIOCADDALTQ command. The code in pfctl, which does DIOCADDALTQ also > is handling errors. The issue is that you will fail a ruleset loading now that before could not fail. You need to teach pfctl that is ok if ALTQ ruleset load fails now, no? I think the most important thing in ruleset loading is the rules than comes ALTQ. Since ALTQ failure is tolerable and the risk from that faling is low! Its better to do a best effort loading of ruleset and just report where it failed? You just committed a 'questionable' patch for default block, just for security, though break that contract by making security depend on unpredictable behaviour! Am i missing something here? Review of things before implementation? > > -- > Totus tuus, Glebius. -- Ermal