Received: by 10.213.65.68 with SMTP id h4csp205043imn; Thu, 15 Mar 2018 23:50:09 -0700 (PDT) X-Google-Smtp-Source: AG47ELv2Sa6qfZwxE5MO8OA0QtXZG9+x0qMGV+psgoTQrabeKbfY51Jd8ZIOZ0ZHgAO5+Ma/RVlT X-Received: by 10.98.65.198 with SMTP id g67mr637140pfd.127.1521183009547; Thu, 15 Mar 2018 23:50:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521183009; cv=none; d=google.com; s=arc-20160816; b=lp/cizfD1p1Wm14XRNnGad0IIqRV8VjDOkeZ/EwudRj/j7NXY7KH9BcNyIVdJzzPHf 3gXNGQjc9irrLE3FqoAzKb1YSsIEsJ9f+F+viUE2etGOC04ZYlHSY1X4Nab8rn98UkXQ e3AmKRa079T2f+I2tzWICg/hhR0UEhUTqVybrsTYkPSyO04PZkyj83TjteUVHRrTj//2 qp0hSpwz9dzq7eJJCpDEk0ofgPDv9zYS8pP4qgOnkKXqYz7p7lIullqyp8F/MQDBZ79C 3akDebQLVHYRFmBj8OvEZL0mITfneKGDRvY75wjUhvosXy+VyDfh9uWFbYb64nlUfGN0 UkPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:arc-authentication-results; bh=ojxCOpSyNOJIZhtBT7Q5aIWW8nvqxkCVe3nRvEbk1Go=; b=Ybi5QluJef2Lu8gRD/uav21qO/ghMyMmQKu88vcbus2gn/WtItO2iNaSb0VyOMjGm5 wfGKgttCHg8rM516wGBBid/ZncwyTDM+u3ChDrQua4sT51/krUUFpt/JgeHBQ+moA62+ NeaS3If+GLgGarHw1GMfhcU/9FmhoPmGQx/H4TtVMrCj/vKDmmIV/SdKeUn7yXv0wrI2 FZLnVKZc4cYMR8pjtS4mkdLN02hQoELeSJlUMd0FFa0VKu/8prtDXIDxIwtqheNQXrn5 1vpquW4EdQQMQOw0UeMkkD6RVB9zSsCZIH+Z/iDopcC0nwFwDBEVHfx0UtWCZlj8yI3F 6cEw== ARC-Authentication-Results: i=1; mx.google.com; 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 r1-v6si5724045plb.102.2018.03.15.23.49.55; Thu, 15 Mar 2018 23:50: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; 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 S1753036AbeCPGsr (ORCPT + 99 others); Fri, 16 Mar 2018 02:48:47 -0400 Received: from isis.lip6.fr ([132.227.60.2]:61580 "EHLO isis.lip6.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750969AbeCPGsq (ORCPT ); Fri, 16 Mar 2018 02:48:46 -0400 X-Greylist: delayed 375 seconds by postgrey-1.27 at vger.kernel.org; Fri, 16 Mar 2018 02:48:45 EDT Received: from poleia.lip6.fr (poleia.lip6.fr [132.227.201.8]) by isis.lip6.fr (8.15.2/lip6) with ESMTP id w2G6flGa017392 ; Fri, 16 Mar 2018 07:41:47 +0100 (CET) X-pt: isis.lip6.fr Received: from newmail.lip6.fr (localhost [127.0.0.1]) by poleia.lip6.fr (Postfix) with ESMTPA id 6498A32B208; Fri, 16 Mar 2018 07:41:47 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 16 Mar 2018 07:41:47 +0100 From: Julia Lawall To: Kees Cook Cc: Kieran Bingham , LKML , Laurent Pinchart , linux-media@vger.kernel.org, Andrew Morton , Ingo Molnar , Thomas Gleixner , Herbert Xu , Masahiro Yamada , Greg Kroah-Hartman , Krzysztof Kozlowski , Randy Dunlap , Ian Abbott , cocci@systeme.lip6.fr, keescook@google.com Subject: Re: [PATCH][RFC] kernel.h: provide array iterator In-Reply-To: References: <1521108052-26861-1-git-send-email-kieran.bingham@ideasonboard.com> Message-ID: <3d969683074366dfa32e2fbb83bf3b65@lip6.fr> X-Sender: Julia.Lawall@lip6.fr User-Agent: Roundcube Webmail/1.3.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (isis.lip6.fr [132.227.60.2]); Fri, 16 Mar 2018 07:41:47 +0100 (CET) X-Scanned-By: MIMEDefang 2.78 on 132.227.60.2 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 16.03.2018 05:21, Kees Cook a écrit : > On Thu, Mar 15, 2018 at 3:00 AM, Kieran Bingham > wrote: >> Simplify array iteration with a helper to iterate each entry in an >> array. >> Utilise the existing ARRAY_SIZE macro to identify the length of the >> array >> and pointer arithmetic to process each item as a for loop. >> >> Signed-off-by: Kieran Bingham >> --- >> include/linux/kernel.h | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> The use of static arrays to store data is a common use case throughout >> the >> kernel. Along with that is the obvious need to iterate that data. >> >> In fact there are just shy of 5000 instances of iterating a static >> array: >> git grep "for .*ARRAY_SIZE" | wc -l >> 4943 > > I suspect the main question is "Does this macro make the code easier to > read?" > > I think it does, and we have other kinds of iterators like this in the > kernel already. Would it be worth building a Coccinelle script to do > the 5000 replacements? Coccinelle should be able to replace the for loop header. Coccinelle could create the local macro. Coccinelle might not put the definition in exactly the right place. Before the function of the first use would be possible, or before any function. I don't think that Coccinelle could figure out how to split one loop into two as done here, unless that specific pattern is very common. I guess that the split is to add the flush_workqueue, and is not the main goal? julia > -Kees > >> >> When working on the UVC driver - I found that I needed to split one >> such >> iteration into two parts, and at the same time felt that this could be >> refactored to be cleaner / easier to read. >> >> I do however worry that this simple short patch might not be desired >> or could >> also be heavily bikeshedded due to it's potential wide spread use >> (though >> perhaps that would be a good thing to have more users) ... but here >> it is, >> along with an example usage below which is part of a separate series. >> >> The aim is to simplify iteration on static arrays, in the same way >> that we have >> iterators for lists. The use of the ARRAY_SIZE macro, provides all the >> protections given by "__must_be_array(arr)" to this macro too. >> >> Regards >> >> Kieran >> >> ============================================================================= >> Example Usage from a pending UVC development: >> >> +#define for_each_uvc_urb(uvc_urb, uvc_streaming) \ >> + for_each_array_element(uvc_urb, uvc_streaming->uvc_urb) >> >> /* >> * Uninitialize isochronous/bulk URBs and free transfer buffers. >> */ >> static void uvc_uninit_video(struct uvc_streaming *stream, int >> free_buffers) >> { >> - struct urb *urb; >> - unsigned int i; >> + struct uvc_urb *uvc_urb; >> >> uvc_video_stats_stop(stream); >> >> - for (i = 0; i < UVC_URBS; ++i) { >> - struct uvc_urb *uvc_urb = &stream->uvc_urb[i]; >> + for_each_uvc_urb(uvc_urb, stream) >> + usb_kill_urb(uvc_urb->urb); >> >> - urb = uvc_urb->urb; >> - if (urb == NULL) >> - continue; >> + flush_workqueue(stream->async_wq); >> >> - usb_kill_urb(urb); >> - usb_free_urb(urb); >> + for_each_uvc_urb(uvc_urb, stream) { >> + usb_free_urb(uvc_urb->urb); >> uvc_urb->urb = NULL; >> } >> >> if (free_buffers) >> uvc_free_urb_buffers(stream); >> } >> ============================================================================= >> >> >> >> >> diff --git a/include/linux/kernel.h b/include/linux/kernel.h >> index ce51455e2adf..95d7dae248b7 100644 >> --- a/include/linux/kernel.h >> +++ b/include/linux/kernel.h >> @@ -70,6 +70,16 @@ >> */ >> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + >> __must_be_array(arr)) >> >> +/** >> + * for_each_array_element - Iterate all items in an array >> + * @elem: pointer of array type for iteration cursor >> + * @array: array to be iterated >> + */ >> +#define for_each_array_element(elem, array) \ >> + for (elem = &(array)[0]; \ >> + elem < &(array)[ARRAY_SIZE(array)]; \ >> + ++elem) >> + >> #define u64_to_user_ptr(x) ( \ >> { \ >> typecheck(u64, x); \ >> -- >> 2.7.4 >>