Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2671552pxb; Tue, 23 Feb 2021 12:33:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJzxhSb9wduWMpNPE3bCvMBb6Gilln3Ua+cDuyeQHLejsf2B7Or9JVjLv5EFRmxong56qKG8 X-Received: by 2002:a17:907:da0:: with SMTP id go32mr6020492ejc.203.1614112425797; Tue, 23 Feb 2021 12:33:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614112425; cv=none; d=google.com; s=arc-20160816; b=z2xj7YKgygPH1z55D3zg0imEPO02PmA2dNyC1Ug3hv+oEeng0XzC/7+B87Fj/P1K25 8esOtRnKaSNsgJsR4cvB5PZwx7WkkBLxcBL7xGgUjGSqj5YW/5nIFqLowpmqNbQNqUwR 2hPVzXF7XK5D11MNA/W0QZSDQ8gHdTrg/0kWzrJm1/xoDL7tlGGy5G3etwJOYLkoI2a/ DFxxJJbxbmU7MM7wiMNwqUs1LAPNiBqsUK1/SSHmyvWk7E2v/q5QHMY2X7qpZ1oZiO5C 9ZbIDXuruC12nlAvOi59UJV9P2oDWOzG2Hj773ARyk+hZgvbmmyXMtkuZ9CG1NuQG2yk r1iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=0sCzg+nKVxIuCagcfYdWxuIEnUuuQqfinjAUu5/j1YI=; b=toO8HE2y58n9HRvKkbLHoDhbhBjCdK3DJwau0eyIo6hfXyDNTiIXx4JVg59NhSnPbg 45fFxRMgAIg0fXhcbSwX3UG5YxYH5Bu7tSLmoBWGFqZ6flrE3Xe+023Fo5ZdcsYj+mXu GjRvyzbS7gm2fFURd5mw2IEnXe7ueOz5ZzFqatocKoms7TVDI3GOY5ejt+g3WIuL06Wv JqiYNM8r6/KbXYUL+FrYm5/v+dVuMTVqLzlbbso4RvHExkYe2EZ3C6Pqk54XPUSbiVKW HoHLGimFKGAKYZ+FjwsqJxpcngETieUCf2htGcZuDYq7uTzO2gecCDm1R5JIBbRnIDwq OfQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=HY5ll+63; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id de24si13935915ejc.234.2021.02.23.12.33.16; Tue, 23 Feb 2021 12:33:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=HY5ll+63; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233718AbhBWRdM (ORCPT + 99 others); Tue, 23 Feb 2021 12:33:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233709AbhBWRdL (ORCPT ); Tue, 23 Feb 2021 12:33:11 -0500 Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 711AAC06174A for ; Tue, 23 Feb 2021 09:32:31 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id d15so9774144ioe.4 for ; Tue, 23 Feb 2021 09:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0sCzg+nKVxIuCagcfYdWxuIEnUuuQqfinjAUu5/j1YI=; b=HY5ll+63utPg958PzpC+i8JM7QhPmHqigip37BLFjKnX5XT478VILpqKcgs8iYpGFO HN0nVkDqRo/rGPNfeQgu0V2baqGLNx0MMVwEzm57EeDqGl44IGdLWB3bk+iMCgIJ3TX4 5ENjgC8usx5r7M2TZW3Wcvhhjgmqx8vtNAWCL7dgUKiA8r3fXevwPT5TqTLwtQ6If4Da f3n7IcZKeAv8+ov6DVC0bC+hJ9DRNIQpRwKdKaC8TfGzlzVG/00fmjamSinRAIf7Cjyh s8cQGcDvsm0dGZtxiqedZDalM+PlQpwU4y+LCjVM3JgI855hd2qRJw5Iy+a/gPP25D+c aRrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0sCzg+nKVxIuCagcfYdWxuIEnUuuQqfinjAUu5/j1YI=; b=HGHCga+Ntf4gusx3PnTK4eFPdBpVXelefAyQXVwdog7GL19Wb6ruMuARIG0CK08oGW Cw0+sUOkN+anZ2RwMlDJTiLjDmFeMLX5sahLRVdVXvUimR0tNM82zKAwlLBv1pRecNtI +Tbttc6sRPY65WkOGa7U6gxbLX1tqCaNeYUtY0sgPmwn6/xMMYPOtDNUZoZVn1+eDzQf p3RhG1dqRiq55UucJJdU96X0u17FY25gc+qVX0UqJL2oWtJ/Ee4IFF+0jUFtxf4iPNMq Mh7qSon1PKehMShEduXIc/D0YGV6aKROBjtMdMwaQCs7HlsI2GMeuyuybaDW6QF/n84p xMAA== X-Gm-Message-State: AOAM532DmVPzGm5sOGbYm5oHqoXr8FweFBBZMqITL8+a4NobWA0Q2q50 oUYnUaJAZHC324cKcjiopQZKrgiLydahOJoDYfuaKA== X-Received: by 2002:a05:6638:1390:: with SMTP id w16mr710607jad.83.1614101550799; Tue, 23 Feb 2021 09:32:30 -0800 (PST) MIME-Version: 1.0 References: <20210222072217.15633-1-jindong.yue@nxp.com> In-Reply-To: From: Mathieu Poirier Date: Tue, 23 Feb 2021 10:32:19 -0700 Message-ID: Subject: Re: [PATCH] remoteproc: core: Remove casting to rproc_handle_resource_t To: Sami Tolvanen Cc: Jindong Yue , Ohad Ben-Cohen , Bjorn Andersson , linux-remoteproc , Peng Fan , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Feb 2021 at 09:49, Sami Tolvanen wrote: > > On Tue, Feb 23, 2021 at 8:41 AM Mathieu Poirier > wrote: > > > > On Mon, 22 Feb 2021 at 15:48, Sami Tolvanen wrote: > > > > > > Hi, > > > > > > On Sun, Feb 21, 2021 at 11:18 PM Jindong Yue wrote: > > > > > > > > There are four different callback functions that are used for the > > > > rproc_handle_resource_t callback that all have different second > > > > parameter types. > > > > > > > > rproc_handle_vdev -> struct fw_rsc_vdev > > > > rproc_handle_trace -> struct fw_rsc_trace > > > > rproc_handle_devmem -> struct fw_rsc_devmem > > > > rproc_handle_carveout -> struct fw_rsc_carveout > > > > > > > > These callbacks are cast to rproc_handle_resource_t so that there is no > > > > error about incompatible pointer types. Unfortunately, this is a control > > > > flow integrity violation, which verifies that the callback function's > > > > types match the prototypes exactly before jumping. > > > > > > Thank you for sending the patch! It might be worth noting that Clang's > > > Control-Flow Integrity checking is currently used only in Android > > > kernels, so while the type mismatches are real and should be fixed, > > > they don't result in runtime errors without this feature. > > > > > > > To fix this, change the second parameter of all functions to void * and > > > > use a local variable with the correct type so that everything works > > > > properly. With this, we can remove casting to rproc_handle_resource_t > > > > for these functions. > > > > > > > > Signed-off-by: Jindong Yue > > > > Reviewed-by: Peng Fan > > > > > > This looks correct to me. Please feel free to add: > > > > > > Reviewed-by: Sami Tolvanen > > > > Where is the original patch? I can't find it on the linux-remoteproc > > and linux-kernel mailing lists. > > Looks like it was sent to linux-remoteproc, but I also don't see it in > lore.kernel.org. Not sure what happened there. Jindong, perhaps it's > worth resending and including linux-kernel too? Something definitely happened because I can't find anything from Jindong on the linux-remoteproc list... A resend it indeed in order. > > Sami