From patchwork Mon May 6 14:32:41 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 163411 Delivered-To: patch@linaro.org Received: by 2002:a05:6e02:81:0:0:0:0 with SMTP id l1csp64100ilm; Mon, 6 May 2019 07:47:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqzJ1+BAwREh8Gk/P9GF/xwBDozQNaLaDajLIXS8TF9gpApII8H/D6WE/MxAHjWvdc/HzQ0b X-Received: by 2002:a62:ea0a:: with SMTP id t10mr17317977pfh.236.1557154031204; Mon, 06 May 2019 07:47:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557154031; cv=none; d=google.com; s=arc-20160816; b=C9v0Ho6n+DpmEdjCCQlXBvoXf1Ct7RnbuSVPYaucE28z/a4lgqziIT1TKlILx+5Qqx h4lxXRR3yoZrltT5QsxfVFbY7jn/7FC3RkuERx06JQXGnsu9M/U5z0qfE3gM2ZXus+tU +lqN+J4KcIrZYtHmfsjJBjvfL5nnl7fE0fbeMSpC1K1qIA9999+pP6GFEQIo3BIybiTE mO+D/69sxxikkabEkvGgrANbkbwatr9tK4eYuu8yXIVBTuYSA/b40Gtj6Go7dvpFEAKZ qN93EY8xI3DvZy0n5SRguwnPgkLKzdWS4NV5mKIPRpULUlJ8vt/jS7Sg8hKCPwJWb18Q AxmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=F3ttaiBRMSnz6yzdDPpQeMbEEFUYYxwhlATftvYGTVw=; b=MAZUzizwWHZH64+wwKlXfrBUwxX32BvkUZudZXqPLHOjRt//0YxbmS6ei9SXUldHgQ E1FWSSrKwNsU1CZdpP2T94CYj8bFmmPHk2mG+txuRSSGgnfYExfffR/g6hAOfKuTAklk CB0wTdfFbjz/naQ+ZcAjvb0Mh9oENJF0ffXyx12m4LMJX+wEc2XFcFywsQ+tJup4lQW6 UiAToAGc56wLuK3HEDRcAYknPU9LsgWUN8/Y0iCLpNaHyddcyx+ZozAoBEuIWv2KlJOQ 02ofIxeVqo/lCfaT/8WdnzPR4CD/s3DIXClB2BmXXc+dMD6AHhm3aP3u8LTbKSZfLZY1 bWVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=W4B+JHyV; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y1si16261872plb.276.2019.05.06.07.47.09; Mon, 06 May 2019 07:47:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=W4B+JHyV; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729253AbfEFOrH (ORCPT + 30 others); Mon, 6 May 2019 10:47:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:45750 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729240AbfEFOrG (ORCPT ); Mon, 6 May 2019 10:47:06 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B4A5520449; Mon, 6 May 2019 14:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557154025; bh=Qp5xjF9TSxL23beNqDWAspMhGR0iab2aZi4HZvkaLOg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W4B+JHyVzKbFmpRsG9B7OPXh0Et5RQOPfxwrMQa7GdQhARbyBr56mCtqliNzlDDnD d4XoZ0MSU+gyVyJAwcYdWibTR/1jBn8+Dh9t/p0ojEaLeEO3cbn5oS65cECEDkw/1m tgpPiu9zAaltCQyQJwa5ro2e4CY2N3sFOWp7303M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , Andrey Ryabinin , Mauro Carvalho Chehab , Alexander Potapenko , Dmitry Vyukov , Andrey Konovalov , Andrew Morton , Linus Torvalds Subject: [PATCH 4.9 10/62] kasan: rework Kconfig settings Date: Mon, 6 May 2019 16:32:41 +0200 Message-Id: <20190506143051.984481239@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190506143051.102535767@linuxfoundation.org> References: <20190506143051.102535767@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream. We get a lot of very large stack frames using gcc-7.0.1 with the default -fsanitize-address-use-after-scope --param asan-stack=1 options, which can easily cause an overflow of the kernel stack, e.g. drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes To reduce this risk, -fsanitize-address-use-after-scope is now split out into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack frames that are smaller than 2 kilobytes most of the time on x86_64. An earlier version of this patch also prevented combining KASAN_EXTRA with KASAN_INLINE, but that is no longer necessary with gcc-7.0.1. All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can bring back that default now. KASAN_EXTRA=y still causes lots of warnings but now defaults to !COMPILE_TEST to disable it in allmodconfig, and it remains disabled in all other defconfigs since it is a new option. I arbitrarily raise the warning limit for KASAN_EXTRA to 3072 to reduce the noise, but an allmodconfig kernel still has around 50 warnings on gcc-7. I experimented a bit more with smaller stack frames and have another follow-up series that reduces the warning limit for 64-bit architectures to 1280 bytes (without CONFIG_KASAN). With earlier versions of this patch series, I also had patches to address the warnings we get with KASAN and/or KASAN_EXTRA, using a "noinline_if_stackbloat" annotation. That annotation now got replaced with a gcc-8 bugfix (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for older compilers, which means that KASAN_EXTRA is now just as bad as before and will lead to an instant stack overflow in a few extreme cases. This reverts parts of commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y"). Two patches in linux-next should be merged first to avoid introducing warnings in an allmodconfig build: 3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN") 16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN") Do we really need to backport this? I think we do: without this patch, enabling KASAN will lead to unavoidable kernel stack overflow in certain device drivers when built with gcc-7 or higher on linux-4.10+ or any version that contains a backport of commit c5caf21ab0cf8. Most people are probably still on older compilers, but it will get worse over time as they upgrade their distros. The warnings we get on kernels older than this should all be for code that uses dangerously large stack frames, though most of them do not cause an actual stack overflow by themselves.The asan-stack option was added in linux-4.0, and commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y") effectively turned off the warning for allmodconfig kernels, so I would like to see this fix backported to any kernels later than 4.0. I have done dozens of fixes for individual functions with stack frames larger than 2048 bytes with asan-stack, and I plan to make sure that all those fixes make it into the stable kernels as well (most are already there). Part of the complication here is that asan-stack (from 4.0) was originally assumed to always require much larger stacks, but that turned out to be a combination of multiple gcc bugs that we have now worked around and fixed, but sanitize-address-use-after-scope (from v4.10) has a much higher inherent stack usage and also suffers from at least three other problems that we have analyzed but not yet fixed upstream, each of them makes the stack usage more severe than it should be. Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.de Signed-off-by: Arnd Bergmann Acked-by: Andrey Ryabinin Cc: Mauro Carvalho Chehab Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Andrey Konovalov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- lib/Kconfig.debug | 1 + lib/Kconfig.kasan | 11 +++++++++++ scripts/Makefile.kasan | 2 ++ 3 files changed, 14 insertions(+) --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -197,6 +197,7 @@ config ENABLE_MUST_CHECK config FRAME_WARN int "Warn for stack frames larger than (needs gcc 4.4)" range 0 8192 + default 3072 if KASAN_EXTRA default 2048 if GCC_PLUGIN_LATENT_ENTROPY default 1024 if !64BIT default 2048 if 64BIT --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -20,6 +20,17 @@ config KASAN Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB (the resulting kernel does not boot). +config KASAN_EXTRA + bool "KAsan: extra checks" + depends on KASAN && DEBUG_KERNEL && !COMPILE_TEST + help + This enables further checks in the kernel address sanitizer, for now + it only includes the address-use-after-scope check that can lead + to excessive kernel stack usage, frame size warnings and longer + compile time. + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 has more + + choice prompt "Instrumentation type" depends on KASAN --- a/scripts/Makefile.kasan +++ b/scripts/Makefile.kasan @@ -29,7 +29,9 @@ else endif endif +ifdef CONFIG_KASAN_EXTRA CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope) +endif CFLAGS_KASAN_NOSANITIZE := -fno-builtin From patchwork Mon May 6 14:32:44 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 163412 Delivered-To: patch@linaro.org Received: by 2002:a05:6e02:81:0:0:0:0 with SMTP id l1csp64239ilm; Mon, 6 May 2019 07:47:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqxubZXpxDWS8JaWXF4O3Q3za8sIiVFVrdDZ1ZAmhw3/nHmGvSy8RpQDOJ9FOGm01WgGIjCk X-Received: by 2002:a17:902:9686:: with SMTP id n6mr33274103plp.282.1557154038775; Mon, 06 May 2019 07:47:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557154038; cv=none; d=google.com; s=arc-20160816; b=ZUMXH+SkPStvv0B4TrXg/RtHMqbR95OrtVil7TyaZH/KTWshG6WL4BWg6tGssATuVc TYjV0O8s7dqtQ8zSFACrdKWVwcsoGsUqrr23jiOMiBXPPPgb69HP21jBJQu0bA25mzyB n+6k3K9EjBmuskQHBEOh/6wxAMvNsDM6qSH4pFgi1x6XlmfnIx3GQTlngX9blDIoyqfQ p0/et1/UH2A2VNo4h1utH8dT9z1rzvQctKsqQhBrj2/53EQ0G+3RjoD4RLD4I6qw+PrV /9bm4MZsBINZIEWH4HWAJIdDMss+e+0rYwWzbOa4Hssj0RRj8SyGyUE9dR5xDA8Zg6Be TV0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Fcr/aSf/skuIpB8gJx1ZUjLdosGsDWh+qhK+ZzmZgfs=; b=b3MDdok1TpcK9VfINd/HUdomYxPie1q56Y8eWaXvAdxyGKrF/nZCORtfcdZoUfEHis zNC3FsoxI+15y0zr4AzfXtN5Jw+HkG5jeKaSHQEaHBLE5HTr4uFVyaqGviWNLnM3imRg W6Y2XgUfJqaOdGbSXDV0GuwDqe7zYCKTGuLpfpWG3LAJqAAW8Pr1+J8FgeJCld4+ao7V Hu9z8wkfj0YYKt2OqhAWU0GxAzLFuec4wh1acbtrR6d7OTXYEbwR7BnezH0diSiBdfXb +QrfXYsvqWRnGJX+t6Kum4QyruB2hysMyM82ZjhDKZuTBqCo0JswmVhD7fzaP1pxTf29 lrOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="obu/ygWj"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 23si14742307pfh.2.2019.05.06.07.47.17; Mon, 06 May 2019 07:47:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="obu/ygWj"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728771AbfEFOrQ (ORCPT + 30 others); Mon, 6 May 2019 10:47:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:46084 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729267AbfEFOrN (ORCPT ); Mon, 6 May 2019 10:47:13 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 64F0720449; Mon, 6 May 2019 14:47:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557154032; bh=ZWme/I8XL5DLX6KM91dRGi4a4dE7wwzF7MHXMGfGN9E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=obu/ygWjkqXN3BWalGEjXQYSsY6ht/3WCtLYa2Yusn9fiejiAhcrZUPLqn54yzLMy f5dLd+u1/3P6WgsB5HFEXi2npGfQz1YyfT1Sk0LnHyfoNm2ozxt3yXHoNygd9UqWvT 7zV78hgU1N8P5ZyVAzq1ugt9N54uiqfnRbY0XgGU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Catalin Marinas , Will Deacon , Laura Abbott , Mark Rutland , Andrey Konovalov Subject: [PATCH 4.9 13/62] arm64: kasan: avoid bad virt_to_pfn() Date: Mon, 6 May 2019 16:32:44 +0200 Message-Id: <20190506143052.234114233@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190506143051.102535767@linuxfoundation.org> References: <20190506143051.102535767@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mark Rutland commit b0de0ccc8b9edd8846828e0ecdc35deacdf186b0 upstream. Booting a v4.11-rc1 kernel with DEBUG_VIRTUAL and KASAN enabled produces the following splat (trimmed for brevity): [ 0.000000] virt_to_phys used for non-linear address: ffff200008080000 (0xffff200008080000) [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:14 __virt_to_phys+0x48/0x70 [ 0.000000] PC is at __virt_to_phys+0x48/0x70 [ 0.000000] LR is at __virt_to_phys+0x48/0x70 [ 0.000000] Call trace: [ 0.000000] [] __virt_to_phys+0x48/0x70 [ 0.000000] [] kasan_init+0x1c0/0x498 [ 0.000000] [] setup_arch+0x2fc/0x948 [ 0.000000] [] start_kernel+0xb8/0x570 [ 0.000000] [] __primary_switched+0x6c/0x74 This is because we use virt_to_pfn() on a kernel image address when trying to figure out its nid, so that we can allocate its shadow from the same node. As with other recent changes, this patch uses lm_alias() to solve this. We could instead use NUMA_NO_NODE, as x86 does for all shadow allocations, though we'll likely want the "real" memory shadow to be backed from its corresponding nid anyway, so we may as well be consistent and find the nid for the image shadow. Cc: Catalin Marinas Cc: Will Deacon Acked-by: Laura Abbott Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Andrey Konovalov Signed-off-by: Greg Kroah-Hartman --- arch/arm64/mm/kasan_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm64/mm/kasan_init.c +++ b/arch/arm64/mm/kasan_init.c @@ -153,7 +153,7 @@ void __init kasan_init(void) clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END); vmemmap_populate(kimg_shadow_start, kimg_shadow_end, - pfn_to_nid(virt_to_pfn(_text))); + pfn_to_nid(virt_to_pfn(lm_alias(_text)))); /* * vmemmap_populate() has populated the shadow region that covers the From patchwork Mon May 6 14:32:46 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 163414 Delivered-To: patch@linaro.org Received: by 2002:a05:6e02:81:0:0:0:0 with SMTP id l1csp70719ilm; Mon, 6 May 2019 07:53:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqzrWcUAbNspgp06QYsmU7ye/rHBYNjJH5smQ//iLN+xK8Z6FoL21T4TV2vGJXCjXjT/1EZl X-Received: by 2002:a63:fd4a:: with SMTP id m10mr8017814pgj.302.1557154402767; Mon, 06 May 2019 07:53:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557154402; cv=none; d=google.com; s=arc-20160816; b=kDhNO+lVyZZKm2wxISyJJdvGA/3AyQoxBCwQh7QQgtnp3Ok6xaBSo1dKvwe3fPktzj o412kU7f05yqdgEWkjIDrgYijAdDwXOQ+9S0RMU6yzhjRenQ5GlLRAyuUSqFTwseNN+R bmZ6UQ3gsIb6UYM0OQ+6hIsKxn5TQ4UZ2ADbNBvLNL+nDEY2cYivm75pYDJGwpnHgMsu Jeh2vRM2uUXNTWpXu+JN7YlNiFTp4PT/0B2YpzAbhsh7f2AkvzQzHQEUDMFWd1MIMITu IMlQOHqmVNFOBEMcOe2KYqy16DI1nf1RvjIlqInL9mq8wRSnknhUymwUVOoX5DeDEFQX BpEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=793cLtw3HLHmuUR38m9SG7aHo3wnwmakxoLW5VIW/Ho=; b=WsH9YNpeRXDJBnrFL2DMsk1VMP94nHdtnkiEsxdpMSPIPdGw+vwcUQ5byW+KcF0thb ZDA8iL7krjLqn/aW3R8FLwJChDf1JO+nbpuwuRLKnbMp+jOXrt284JZRZMTUUqUCPECR LkKqnZS3//ok+uT37VNCWTLGWHk+b2lCw7hBjUJPxycay3D+X5SOMWGRJ86V3JVnqIby xeHZA3IZSYJ2hZIXEx3FgYR+sOHQwAaCqQ4t3/ad/LrEMDPHUJXgB++WGx6hgQcZ6bKr pSM0X2fKz8HYQKfMsz3Bgd3vAi58aF6GSlROcWIzVAPXW/XWcafUjJMkY0tglaPQVQMj v4/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=a9qkcwul; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l11si15789622plb.370.2019.05.06.07.53.22; Mon, 06 May 2019 07:53:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=a9qkcwul; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729326AbfEFOrg (ORCPT + 30 others); Mon, 6 May 2019 10:47:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:46292 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727382AbfEFOrT (ORCPT ); Mon, 6 May 2019 10:47:19 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AC8FC20449; Mon, 6 May 2019 14:47:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557154038; bh=vbPwdDLTa7OrWI0SflkBBJ7iLeQtCJf62w+l948vi5U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a9qkcwulZLKR6zNcFJBYvGoS9Xa56qiqjXrNsesEpaB3rmDEXXbl8KAXRluVy8hle rO44TB43iCc3+OmsN3u+kvcHY1rn2isUbsVvM6ZP3QfOkBLl18dP5f9YeWvCG1LWx1 xf421H83RbfifHERmKsKj3kgKGX4nLlWCgRHL36s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , Alexander Potapenko , Andrey Ryabinin , Dmitry Vyukov , Andrew Morton , Linus Torvalds , Andrey Konovalov Subject: [PATCH 4.9 15/62] kasan: avoid -Wmaybe-uninitialized warning Date: Mon, 6 May 2019 16:32:46 +0200 Message-Id: <20190506143052.384495640@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190506143051.102535767@linuxfoundation.org> References: <20190506143051.102535767@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit e7701557bfdd81ff44cab13a80439319a735d8e2 upstream. gcc-7 produces this warning: mm/kasan/report.c: In function 'kasan_report': mm/kasan/report.c:351:3: error: 'info.first_bad_addr' may be used uninitialized in this function [-Werror=maybe-uninitialized] print_shadow_for_address(info->first_bad_addr); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mm/kasan/report.c:360:27: note: 'info.first_bad_addr' was declared here The code seems fine as we only print info.first_bad_addr when there is a shadow, and we always initialize it in that case, but this is relatively hard for gcc to figure out after the latest rework. Adding an intialization to the most likely value together with the other struct members shuts up that warning. Fixes: b235b9808664 ("kasan: unify report headers") Link: https://patchwork.kernel.org/patch/9641417/ Link: http://lkml.kernel.org/r/20170725152739.4176967-1-arnd@arndb.de Signed-off-by: Arnd Bergmann Suggested-by: Alexander Potapenko Suggested-by: Andrey Ryabinin Acked-by: Andrey Ryabinin Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Andrey Konovalov Signed-off-by: Greg Kroah-Hartman --- mm/kasan/report.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/kasan/report.c +++ b/mm/kasan/report.c @@ -302,6 +302,7 @@ void kasan_report(unsigned long addr, si disable_trace_on_warning(); info.access_addr = (void *)addr; + info.first_bad_addr = (void *)addr; info.access_size = size; info.is_write = is_write; info.ip = ip; From patchwork Mon May 6 14:32:48 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 163415 Delivered-To: patch@linaro.org Received: by 2002:a05:6e02:81:0:0:0:0 with SMTP id l1csp70881ilm; Mon, 6 May 2019 07:53:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqyredGb2mPiS3SBS/Cj4gyLkdNnHuDidceAVAgqIKwIb+2dwUY+N3NaoWKYKF0AOdHWIztm X-Received: by 2002:a17:902:6949:: with SMTP id k9mr31981115plt.59.1557154412340; Mon, 06 May 2019 07:53:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557154412; cv=none; d=google.com; s=arc-20160816; b=rC3+0Atlhgc8U6LmEsp/Wu2uBYUODObXhpZ74GK754XTuWVu7Nryp2dyaI2KE5VAH2 JeTHqf8llCKRQVgY+Pfg1zc/ZMfS8m0oQ5FT8y+q9/sOjiTwj7iKAnfvDn9T6XiT2Tp2 Tww3j/md6OaunKbx/7zL8EY8VejT+V9edVRVlCN5ybiQ4VjbYgC8l8iR4KoQ5qmXc2nt orfg5ToVOlzvBzosIVM3Fo4m6GWq8F7aBO8cLOqE/Ep6w7NLAA6YGhUSxHwlZzdTbI7F HxtrU44ikETweQ0v80s6uI/5CeMItG2QIxsMJ412uwwxaFADa/VEBGS0myL55pSI/VDr 2DUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Vwrkds/PP6hTwCa/mFqBLSWcEM4YoxY/cSFLZ31lvEM=; b=bkTcFbxLNAgFDGOajUjeFcKD7v6L2wwG1J5g6MPDrdbgVEPIyhgo6vZNxqN+dHh8j/ LsEi71isPZ2UgqGfk8nzMU0fVAWMF9C8BnTFk/rTtF31kofjDe7zDeZpSeLUL4YWl1ec WT41kr4OpH/nkMyK9Qb2BRKJafcnIHZ912N7UviFXaYDuFGanaz+uR6N3EDGtaOHhBh1 9DJuVFs4KhmM1QvNS0kDS6tnoXWWzYwRO64nD0qcO922w68C6GzmyCyzD7SpVsZp5yCS FSnUdTdw7ON/oDk6vmcQoMl1wUFDPWWVC2EMoN0yUxfvdLcKRMJ/09I34vbdj5Zzijgg HjcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="A/F/BCj1"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f14si14353574pgg.336.2019.05.06.07.53.32; Mon, 06 May 2019 07:53:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="A/F/BCj1"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728812AbfEFOre (ORCPT + 30 others); Mon, 6 May 2019 10:47:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:46500 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728798AbfEFOrY (ORCPT ); Mon, 6 May 2019 10:47:24 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DA158214AE; Mon, 6 May 2019 14:47:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557154043; bh=AlTtKsKgZWXRO+VchEO+ZdakVY1Z7mSRhb03uM8VTsM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A/F/BCj1dIW3N47tAP1U7ftupgzJqcweIS5+suq/UxWLcqqWkH/+SsZThzRc/ZsWN scYgC98OQ4B5qm91Hk2I45VtiZ0VTOMIZS2fx2g5svYfiAx826jVd6BU6dDN+jUCOB QMzjCJIklP2kWcWrO1avlL4pp8+zKH1oBJ0PCJSk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Rutland , Will Deacon , Catalin Marinas , Andrey Konovalov Subject: [PATCH 4.9 17/62] arm64: proc: Set PTE_NG for table entries to avoid traversing them twice Date: Mon, 6 May 2019 16:32:48 +0200 Message-Id: <20190506143052.549892170@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190506143051.102535767@linuxfoundation.org> References: <20190506143051.102535767@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Will Deacon commit 2ce77f6d8a9ae9ce6d80397d88bdceb84a2004cd upstream. When KASAN is enabled, the swapper page table contains many identical mappings of the zero page, which can lead to a stall during boot whilst the G -> nG code continually walks the same page table entries looking for global mappings. This patch sets the nG bit (bit 11, which is IGNORED) in table entries after processing the subtree so we can easily skip them if we see them a second time. Tested-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Andrey Konovalov Signed-off-by: Greg Kroah-Hartman --- arch/arm64/mm/proc.S | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -181,7 +181,8 @@ ENDPROC(idmap_cpu_replace_ttbr1) dc cvac, cur_\()\type\()p // Ensure any existing dirty dmb sy // lines are written back before ldr \type, [cur_\()\type\()p] // loading the entry - tbz \type, #0, next_\()\type // Skip invalid entries + tbz \type, #0, skip_\()\type // Skip invalid and + tbnz \type, #11, skip_\()\type // non-global entries .endm .macro __idmap_kpti_put_pgtable_ent_ng, type @@ -241,8 +242,9 @@ ENTRY(idmap_kpti_install_ng_mappings) add end_pgdp, cur_pgdp, #(PTRS_PER_PGD * 8) do_pgd: __idmap_kpti_get_pgtable_ent pgd tbnz pgd, #1, walk_puds - __idmap_kpti_put_pgtable_ent_ng pgd next_pgd: + __idmap_kpti_put_pgtable_ent_ng pgd +skip_pgd: add cur_pgdp, cur_pgdp, #8 cmp cur_pgdp, end_pgdp b.ne do_pgd @@ -270,8 +272,9 @@ walk_puds: add end_pudp, cur_pudp, #(PTRS_PER_PUD * 8) do_pud: __idmap_kpti_get_pgtable_ent pud tbnz pud, #1, walk_pmds - __idmap_kpti_put_pgtable_ent_ng pud next_pud: + __idmap_kpti_put_pgtable_ent_ng pud +skip_pud: add cur_pudp, cur_pudp, 8 cmp cur_pudp, end_pudp b.ne do_pud @@ -290,8 +293,9 @@ walk_pmds: add end_pmdp, cur_pmdp, #(PTRS_PER_PMD * 8) do_pmd: __idmap_kpti_get_pgtable_ent pmd tbnz pmd, #1, walk_ptes - __idmap_kpti_put_pgtable_ent_ng pmd next_pmd: + __idmap_kpti_put_pgtable_ent_ng pmd +skip_pmd: add cur_pmdp, cur_pmdp, #8 cmp cur_pmdp, end_pmdp b.ne do_pmd @@ -309,7 +313,7 @@ walk_ptes: add end_ptep, cur_ptep, #(PTRS_PER_PTE * 8) do_pte: __idmap_kpti_get_pgtable_ent pte __idmap_kpti_put_pgtable_ent_ng pte -next_pte: +skip_pte: add cur_ptep, cur_ptep, #8 cmp cur_ptep, end_ptep b.ne do_pte From patchwork Mon May 6 14:32:52 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 163413 Delivered-To: patch@linaro.org Received: by 2002:a05:6e02:81:0:0:0:0 with SMTP id l1csp70498ilm; Mon, 6 May 2019 07:53:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqzVE57OraZLyi7DwvLYDCrMu1xgZeY4GStcYmDR9NuonxkxKRadt3S10XINqK2MhCE2JTly X-Received: by 2002:a17:902:a510:: with SMTP id s16mr7959635plq.334.1557154389651; Mon, 06 May 2019 07:53:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557154389; cv=none; d=google.com; s=arc-20160816; b=kvngVt9hgylMXoxhP4iSyKlKRDY/Gmis+qoao9WfgRjRLBD4VVzWIrdFwmRD0rBXkh Lj4TIWWOOIo9AfQXzm+56QCfwK0DunLLZew9tfDOX/u5gnpqKk+LmfiMPUMEfexzN37W Dmrck4NQnYPURbiTcBvOiHPkktGtj2SID9Gxn2twkwQeIF5JB5ICOxOZQGdu2lrCIcwt o9WFZjB0iEJ/WSVQNbWwNjIsiYA9Dys3ltytCjC/wn1ghzZxUzYKanURobd04XH+xahR ixiV0RpdCIxQjEAUtYjHY2oujlvZ1H7f6xUWsnKRPki7lFhN9AUtt+srM0fUZTWnbcLG xzAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=UErZ/fsZHFbp85BYtmol1hWZYiHT1WQ/nIi8hBfRU40=; b=jmIy9TDlf7b61Vl25iGetsPlkRMGN9Mu50ANnQKMTvaktl3o/z07Aj523vMws48avn 491+rkilTCfTHwes/jneZjKLGUwJExKcxLQiSdhN10Ybptlvwse7hyppPxIPvSe1xnz+ /rwed1Gjsh9qw5kbbz5o5Ju9IRkOTNa4CEzBjHtxSlNYdV0kW4QDiKBml790fHijD/bm i02M3+fTds2PtVG8Xof93MiiWmaa1Fw/D6njdDT1HtLEoCwjm7NfBbJDAPL1hdvqFW0L h8lUXL5GLIvzekRI/LBxhH09tGJeZMX4x6h4tKGfJNeuEPNMHCU0Vy1N65qN9ucvNtnE Mjcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NpkBMauJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a18si8583835pgj.514.2019.05.06.07.53.09; Mon, 06 May 2019 07:53:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NpkBMauJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729355AbfEFOrk (ORCPT + 30 others); Mon, 6 May 2019 10:47:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:46988 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728440AbfEFOrj (ORCPT ); Mon, 6 May 2019 10:47:39 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D1A0020578; Mon, 6 May 2019 14:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557154057; bh=p4k4VEEcg6/JvNjILCfPYUNlLZeYKtbYzZxS21BDptg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NpkBMauJk5ZaiNT21vvUyp7jSFLCiv0tCDhkAvY/CNLshhOWaY9EDbFwWa6r6raJU 3pZkky4poX8oVxiXWBkrVZTFDhdo3HvSz3HxK2aHVmpBFc4h770Al1AdyjrnOg8cIn Pz2ZZT/O6iy4KS/ED6LHGdXrgoOt9JMSTPESKRLc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , "David S. Miller" , Andrey Konovalov Subject: [PATCH 4.9 21/62] caif: reduce stack size with KASAN Date: Mon, 6 May 2019 16:32:52 +0200 Message-Id: <20190506143052.887801316@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190506143051.102535767@linuxfoundation.org> References: <20190506143051.102535767@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit ce6289661b14a8b391d90db918c91b6d6da6540a upstream. When CONFIG_KASAN is set, we can use relatively large amounts of kernel stack space: net/caif/cfctrl.c:555:1: warning: the frame size of 1600 bytes is larger than 1280 bytes [-Wframe-larger-than=] This adds convenience wrappers around cfpkt_extr_head(), which is responsible for most of the stack growth. With those wrapper functions, gcc apparently starts reusing the stack slots for each instance, thus avoiding the problem. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Andrey Konovalov Signed-off-by: Greg Kroah-Hartman --- include/net/caif/cfpkt.h | 27 +++++++++++++++++++++++++ net/caif/cfctrl.c | 50 ++++++++++++++++++++--------------------------- 2 files changed, 49 insertions(+), 28 deletions(-) --- a/include/net/caif/cfpkt.h +++ b/include/net/caif/cfpkt.h @@ -32,6 +32,33 @@ void cfpkt_destroy(struct cfpkt *pkt); */ int cfpkt_extr_head(struct cfpkt *pkt, void *data, u16 len); +static inline u8 cfpkt_extr_head_u8(struct cfpkt *pkt) +{ + u8 tmp; + + cfpkt_extr_head(pkt, &tmp, 1); + + return tmp; +} + +static inline u16 cfpkt_extr_head_u16(struct cfpkt *pkt) +{ + __le16 tmp; + + cfpkt_extr_head(pkt, &tmp, 2); + + return le16_to_cpu(tmp); +} + +static inline u32 cfpkt_extr_head_u32(struct cfpkt *pkt) +{ + __le32 tmp; + + cfpkt_extr_head(pkt, &tmp, 4); + + return le32_to_cpu(tmp); +} + /* * Peek header from packet. * Reads data from packet without changing packet. --- a/net/caif/cfctrl.c +++ b/net/caif/cfctrl.c @@ -352,15 +352,14 @@ static int cfctrl_recv(struct cflayer *l u8 cmdrsp; u8 cmd; int ret = -1; - u16 tmp16; u8 len; u8 param[255]; - u8 linkid; + u8 linkid = 0; struct cfctrl *cfctrl = container_obj(layer); struct cfctrl_request_info rsp, *req; - cfpkt_extr_head(pkt, &cmdrsp, 1); + cmdrsp = cfpkt_extr_head_u8(pkt); cmd = cmdrsp & CFCTRL_CMD_MASK; if (cmd != CFCTRL_CMD_LINK_ERR && CFCTRL_RSP_BIT != (CFCTRL_RSP_BIT & cmdrsp) @@ -378,13 +377,12 @@ static int cfctrl_recv(struct cflayer *l u8 physlinkid; u8 prio; u8 tmp; - u32 tmp32; u8 *cp; int i; struct cfctrl_link_param linkparam; memset(&linkparam, 0, sizeof(linkparam)); - cfpkt_extr_head(pkt, &tmp, 1); + tmp = cfpkt_extr_head_u8(pkt); serv = tmp & CFCTRL_SRV_MASK; linkparam.linktype = serv; @@ -392,13 +390,13 @@ static int cfctrl_recv(struct cflayer *l servtype = tmp >> 4; linkparam.chtype = servtype; - cfpkt_extr_head(pkt, &tmp, 1); + tmp = cfpkt_extr_head_u8(pkt); physlinkid = tmp & 0x07; prio = tmp >> 3; linkparam.priority = prio; linkparam.phyid = physlinkid; - cfpkt_extr_head(pkt, &endpoint, 1); + endpoint = cfpkt_extr_head_u8(pkt); linkparam.endpoint = endpoint & 0x03; switch (serv) { @@ -407,45 +405,43 @@ static int cfctrl_recv(struct cflayer *l if (CFCTRL_ERR_BIT & cmdrsp) break; /* Link ID */ - cfpkt_extr_head(pkt, &linkid, 1); + linkid = cfpkt_extr_head_u8(pkt); break; case CFCTRL_SRV_VIDEO: - cfpkt_extr_head(pkt, &tmp, 1); + tmp = cfpkt_extr_head_u8(pkt); linkparam.u.video.connid = tmp; if (CFCTRL_ERR_BIT & cmdrsp) break; /* Link ID */ - cfpkt_extr_head(pkt, &linkid, 1); + linkid = cfpkt_extr_head_u8(pkt); break; case CFCTRL_SRV_DATAGRAM: - cfpkt_extr_head(pkt, &tmp32, 4); linkparam.u.datagram.connid = - le32_to_cpu(tmp32); + cfpkt_extr_head_u32(pkt); if (CFCTRL_ERR_BIT & cmdrsp) break; /* Link ID */ - cfpkt_extr_head(pkt, &linkid, 1); + linkid = cfpkt_extr_head_u8(pkt); break; case CFCTRL_SRV_RFM: /* Construct a frame, convert * DatagramConnectionID * to network format long and copy it out... */ - cfpkt_extr_head(pkt, &tmp32, 4); linkparam.u.rfm.connid = - le32_to_cpu(tmp32); + cfpkt_extr_head_u32(pkt); cp = (u8 *) linkparam.u.rfm.volume; - for (cfpkt_extr_head(pkt, &tmp, 1); + for (tmp = cfpkt_extr_head_u8(pkt); cfpkt_more(pkt) && tmp != '\0'; - cfpkt_extr_head(pkt, &tmp, 1)) + tmp = cfpkt_extr_head_u8(pkt)) *cp++ = tmp; *cp = '\0'; if (CFCTRL_ERR_BIT & cmdrsp) break; /* Link ID */ - cfpkt_extr_head(pkt, &linkid, 1); + linkid = cfpkt_extr_head_u8(pkt); break; case CFCTRL_SRV_UTIL: @@ -454,13 +450,11 @@ static int cfctrl_recv(struct cflayer *l * to network format long and copy it out... */ /* Fifosize KB */ - cfpkt_extr_head(pkt, &tmp16, 2); linkparam.u.utility.fifosize_kb = - le16_to_cpu(tmp16); + cfpkt_extr_head_u16(pkt); /* Fifosize bufs */ - cfpkt_extr_head(pkt, &tmp16, 2); linkparam.u.utility.fifosize_bufs = - le16_to_cpu(tmp16); + cfpkt_extr_head_u16(pkt); /* name */ cp = (u8 *) linkparam.u.utility.name; caif_assert(sizeof(linkparam.u.utility.name) @@ -468,24 +462,24 @@ static int cfctrl_recv(struct cflayer *l for (i = 0; i < UTILITY_NAME_LENGTH && cfpkt_more(pkt); i++) { - cfpkt_extr_head(pkt, &tmp, 1); + tmp = cfpkt_extr_head_u8(pkt); *cp++ = tmp; } /* Length */ - cfpkt_extr_head(pkt, &len, 1); + len = cfpkt_extr_head_u8(pkt); linkparam.u.utility.paramlen = len; /* Param Data */ cp = linkparam.u.utility.params; while (cfpkt_more(pkt) && len--) { - cfpkt_extr_head(pkt, &tmp, 1); + tmp = cfpkt_extr_head_u8(pkt); *cp++ = tmp; } if (CFCTRL_ERR_BIT & cmdrsp) break; /* Link ID */ - cfpkt_extr_head(pkt, &linkid, 1); + linkid = cfpkt_extr_head_u8(pkt); /* Length */ - cfpkt_extr_head(pkt, &len, 1); + len = cfpkt_extr_head_u8(pkt); /* Param Data */ cfpkt_extr_head(pkt, ¶m, len); break; @@ -522,7 +516,7 @@ static int cfctrl_recv(struct cflayer *l } break; case CFCTRL_CMD_LINK_DESTROY: - cfpkt_extr_head(pkt, &linkid, 1); + linkid = cfpkt_extr_head_u8(pkt); cfctrl->res.linkdestroy_rsp(cfctrl->serv.layer.up, linkid); break; case CFCTRL_CMD_LINK_ERR: