From owner-freebsd-hackers@freebsd.org Tue Dec 18 17:06:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDE2413377B6 for ; Tue, 18 Dec 2018 17:06:51 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83436760DE for ; Tue, 18 Dec 2018 17:06:51 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: by mail-qt1-x843.google.com with SMTP id k12so18966894qtf.7 for ; Tue, 18 Dec 2018 09:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=XF0sy7bzh2p5i1t7TCgCQRr29np6d7o3utSdICogpQc=; b=qcyGLWktdgBztZYmxZm6so4UWZLA8A9KCGf7R8qvvSSErXdiU81KOpz//cO/MYM6j3 4MwIoSA7heoCWz5KHIVisqpAG4GlLhiECl9z4E1si5EpfpaXh8vydVdgveLWqEhINmgn jH4ee8RoSJJ0CWjlc5pWUcsxpGjNByAvw/4V0l17wdM0PNSufvVQmiKqHgo5Ec0GWERF uQm40RxmeiamrF0bI64qiBBVDn7RHpg1/pXaxWn5b/H3dVlvY4wU9C7JZTXDxbnXN7x7 j9ob8ZVDbWWlychD2ZESGXrdTLkwxb736YSF8DaxabjogLou0lVJZsIlxp0w3QFvvyHJ 7KmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=XF0sy7bzh2p5i1t7TCgCQRr29np6d7o3utSdICogpQc=; b=e05cWYFj5NMd2UTYFN6KyzsLC4/fDRhGAiMWLRIjHxcBQq/CknQr6usxINiF31TGfL CCPDOjjrnVgjKemVEZbj2z1s5q7spx91CdwrWSD8GT6up/g0kwKKhCLhmzxmLDSss9nk Pw1ihbH7X7G3CqO40NisF6hYT06QLy8s2UX5DNJlK9y0GciPKF6KVC0WWWzo1c1fDhz0 rhBDEfC3YvUkaWHZtRSFl+yFiIj1ycwGlc9JHuXhLySlKpbpE8bSF6UhhvnupmCVJ48b e4t63Cje4hfWVXPzKAeJCiuzkEeO+bbljCyq2+4lT1eg6ch9W87boKdc1XmbjexcqnXS iy+Q== X-Gm-Message-State: AA+aEWb0HIgoUtCaXdQsWiWWzl8ZacOSyIfJgnEt2653h8umS+coQNDe HA+uqpPZ+hV53IOajRxBCKKNPqiZ X-Google-Smtp-Source: AFSGD/XfKdXHkrV3KapAy56+wx3aMF8yaFtAg/GXT+2wsmkJ9kwSVADYI5rRR0RK7u6F9Vs4UcW1KQ== X-Received: by 2002:a0c:981b:: with SMTP id c27mr18584461qvd.184.1545152811030; Tue, 18 Dec 2018 09:06:51 -0800 (PST) Received: from localhost ([178.128.156.9]) by smtp.gmail.com with ESMTPSA id s9sm316723qta.35.2018.12.18.09.06.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 09:06:49 -0800 (PST) From: Austin Shafer To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: ENOMEM when calling sysctl_handle_int from custom handler In-Reply-To: <20181218055828.GA60291@kib.kiev.ua> References: <861s6fpyua.fsf@triplebuff.com> <20181218055828.GA60291@kib.kiev.ua> Date: Tue, 18 Dec 2018 12:06:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 83436760DE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 17:06:52 -0000 Konstantin Belousov writes: > On Mon, Dec 17, 2018 at 05:34:05PM -0500, Austin Shafer wrote: >> My best guess: >> I've tried to dig around in the debugger (using kgdb) but haven't been >> able to find anything. The only difference I noticed while tracing was >> that the "oldlenp" field in the sysctl_args struct passed in from >> userland was 0 when calling my handler and 8 when calling the default >> handler. I am not very familiar with the sysctl implementation, but this >> affected the valid length in the sysctl_req which ended up returning >> ENOMEM from sysctl_old_user. You can watch/confirm this change in sysctl_req >> using the following dtrace one-liner. Its unclear why changing the >> sysctl handler would affect the arguments passed to it. > Yes, this is most likely cause for your issue. ENOMEM does not have > anything with the memory shortage, but with the fact that the oldlen > is too short for int copyout. > > Note that for the int-typed oid, old and new len should be 4 (not 0 and > not 8). Why your userspace code passed such length is the question to > you. > Thanks for the reply! I'm just using the sysctl(8) utility in the examples above so the valid length passing from userspace is not done by me. Based on what you said it seems to me that sysctl(8) is not passing the correct values then? This would be strange since all other sysctls work using sysctl(8). I'm more than happy to dig deep and debug sysctl(8) to see if it is the culprit. I had assumed it was working fine and that the error was on my end in the kernel module. You are right about the userspace passed values being whats causing my problems though. I wrote a short program to call sysctlbyname (with the correct length as you specified above) and now I can set the value of the sysctl: // read_sysctl.c int main (int argc, char *argv[]) { int error, old, new = 3; size_t size; size = sizeof(int); ... error = sysctlbyname(argv[1], &old, &size, &new, size); ... } // dtrace -n '*::sysctl_handle_int:entry /execname == "read_sysctl" / { print(*args[3]); }' CPU ID FUNCTION:NAME 2 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff80003b38580 int lock = 0x1 void *oldptr = 0x7fffffffd71c size_t oldlen = 0x4 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0 size_t newlen = 0 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0x4 int flags = 0 } 2 27761 sysctl_handle_int:entry struct sysctl_req { struct thread *td = 0xfffff80003b38580 int lock = 0x1 void *oldptr = 0x7fffffffeb28 size_t oldlen = 0x4 size_t oldidx = 0 int (*)() oldfunc = kernel`sysctl_old_user void *newptr = 0x7fffffffeb24 size_t newlen = 0x4 size_t newidx = 0 int (*)() newfunc = kernel`sysctl_new_user size_t validlen = 0x4 int flags = 0 } Also out of curiosity, the dtrace probes show multiple sysctl_handle_int evaluations. Is this for each root and sub-node in the sysctl tree? Thats what it looks like to me but I'd love to know for sure. Thanks for all the help! Austin Shafer