Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3744121imu; Fri, 30 Nov 2018 05:27:33 -0800 (PST) X-Google-Smtp-Source: AFSGD/UlVqjev0PzyYzT4aub+iHAFCl4Bo+dIBN+us15cb+yl91Rv9wfVRYB/kkyK2vjjzMFdfmr X-Received: by 2002:a17:902:2a0a:: with SMTP id i10mr5574451plb.323.1543584453484; Fri, 30 Nov 2018 05:27:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543584453; cv=none; d=google.com; s=arc-20160816; b=o/F0ZHVme5r3ASc4PVf5+yF5a8gQuBmdusERxUFivW2LfySXHT/sZ9Pbcgsrkh2TCz Zmpgy4dXbJVviu6p+ievXFCOWjmdA/PwNb67tPq0BfAaeGcZBpLzqgoSKGNIX3MdeRZN cn+v2S9RCKpnSTLDDP8WPQlwnkmy2CjOg2J0+1+EkStFjmBmYpDx/dFat4PbHMeLwN0q Qxjng4sTJ0XutvvTnmNiFUmj9EqZrbD+zOGEcM3L23+Uh4qw7YTos6Rhtbqmwnz1ZZSx vz1rbEn7SBIbEEDpoGma4EsXOr+cHZIZ7TH/je+VGJ5VqHlOq2/vFHlOVig8LHpfIEYN dwJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=OiIiq+eBwupJMmehByf87me5bWCoRjY4A7/Tc6drQ5A=; b=XCqIRrOqR1YCmvV1IyU4Rh/Tm0CkdIJV35eRXVXuR/AR8ys8zVvZXWryJHxQnrpit/ RrKaTxfGVYQqnWHeSh2C/a2xp/NtDrXhqEtVYh6Onf4iShvz/fhE+1RjiXTBybEgY2mf GFIaJzuk38np6XPd64dVq7CCzaxUZILnL3ArvXEXZzoUVboBYBTwkctpZExKW6pMdqYo +RQnQimWShNoqoe5Aup5/f0Z8g9rHlA5Hi6HzmhKPk7qCpTo7wWOn2+rIFp4/6WycUq3 SgbdKmz50U3k/T+212IGnZ5I2s223BkHzET8IW6jcJ959X+ygikXRzPTqtG2N3lJtN2S LWQA== 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 i18si5034976pgl.414.2018.11.30.05.27.18; Fri, 30 Nov 2018 05:27:33 -0800 (PST) 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 S1726886AbeLAAgB (ORCPT + 99 others); Fri, 30 Nov 2018 19:36:01 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:36107 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726070AbeLAAgA (ORCPT ); Fri, 30 Nov 2018 19:36:00 -0500 Received: by mail-qt1-f193.google.com with SMTP id t13so5859419qtn.3; Fri, 30 Nov 2018 05:26:42 -0800 (PST) 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=OiIiq+eBwupJMmehByf87me5bWCoRjY4A7/Tc6drQ5A=; b=VW5bYGcrMmVEBT6uA27po1fI2QyeFmVVbQ7gz7gWdOgAu7O1H9sliIk564QsFNB+7x f7zZ4gq8B6cja49P612LhIcpLhZdRWBhMy6Z5PIR7jMz82z5CMFs+fesElTZCdgRUak4 7E6Y/LfDW3tzx+DHUz9CfwVMshKhNh9zyEZNZ8VYDpUuS65Mx2mhgWCQIg/oOJY5zUOS 1VAlhS8ykOtb31saEcucIexM6BaC8vR0W9hEYixIJ+xh77zcDUQ64iKA8l6sbvJuhABB lJt+bxg1YTTqmJa49MLfeC7ta5SjqvYml5a260rnsnjOF3kJJo2Dsgqc+1gDcBqZq/0p 3q7A== X-Gm-Message-State: AA+aEWbKptVocN4wheNpYveeoKzp99W4++7+5dg0fzRlte75BHfwWblI 4jsimXnWMVAZLITcnDx4mbdRKm2nnyM1EvY4iRU= X-Received: by 2002:ac8:2c34:: with SMTP id d49mr5554344qta.152.1543584401848; Fri, 30 Nov 2018 05:26:41 -0800 (PST) MIME-Version: 1.0 References: <20181130104657.14875-1-srinivas.kandagatla@linaro.org> <20181130104657.14875-5-srinivas.kandagatla@linaro.org> In-Reply-To: <20181130104657.14875-5-srinivas.kandagatla@linaro.org> From: Arnd Bergmann Date: Fri, 30 Nov 2018 14:26:23 +0100 Message-ID: Subject: Re: [RFC PATCH 4/6] char: fastrpc: Add support for create remote init process To: Srinivas Kandagatla Cc: Rob Herring , gregkh , Mark Rutland , DTML , Linux Kernel Mailing List , Bjorn Andersson , linux-arm-msm@vger.kernel.org, bkumar@qti.qualcomm.com, thierry.escande@linaro.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 30, 2018 at 11:48 AM Srinivas Kandagatla wrote: > + > +static int fastrpc_init_process(struct fastrpc_user *fl, > + struct fastrpc_ioctl_init *init) > +{ > + struct fastrpc_ioctl_invoke *ioctl; > + struct fastrpc_phy_page pages[1]; > + struct fastrpc_map *file = NULL, *mem = NULL; > + struct fastrpc_buf *imem = NULL; > + int err = 0; > + > + ioctl = kzalloc(sizeof(*ioctl), GFP_KERNEL); > + if (!ioctl) > + return -ENOMEM; > + > + if (init->flags == FASTRPC_INIT_ATTACH) { > + remote_arg_t ra[1]; > + int tgid = fl->tgid; > + > + ra[0].buf.pv = (void *)&tgid; > + ra[0].buf.len = sizeof(tgid); > + ioctl->handle = 1; > + ioctl->sc = FASTRPC_SCALARS(FASTRPC_RMID_INIT_ATTACH, 1, 0); > + ioctl->pra = ra; > + fl->pd = 0; > + > + err = fastrpc_internal_invoke(fl, 1, ioctl); > + if (err) > + goto bail; It doesn't seem right to me to dynamically allocate an 'ioctl' data structure from kernel context and pass that down to another function. Maybe eliminate that structure and change fastrpc_internal_invoke to take the individual arguments here instead of a pointer? > + } else if (init->flags == FASTRPC_INIT_CREATE) { How about splitting each flags== case into a separate function? > diff --git a/include/uapi/linux/fastrpc.h b/include/uapi/linux/fastrpc.h > index 8fec66601337..6b596fc7ddf3 100644 > --- a/include/uapi/linux/fastrpc.h > +++ b/include/uapi/linux/fastrpc.h > @@ -6,6 +6,12 @@ > #include > > #define FASTRPC_IOCTL_INVOKE _IOWR('R', 3, struct fastrpc_ioctl_invoke) > +#define FASTRPC_IOCTL_INIT _IOWR('R', 4, struct fastrpc_ioctl_init) > + > +/* INIT a new process or attach to guestos */ > +#define FASTRPC_INIT_ATTACH 0 > +#define FASTRPC_INIT_CREATE 1 > +#define FASTRPC_INIT_CREATE_STATIC 2 Maybe use three command codes here, and remove the 'flags' member? > @@ -53,4 +59,16 @@ struct fastrpc_ioctl_invoke { > unsigned int *crc; > }; > > +struct fastrpc_ioctl_init { > + uint32_t flags; /* one of FASTRPC_INIT_* macros */ > + uintptr_t file; /* pointer to elf file */ > + uint32_t filelen; /* elf file length */ > + int32_t filefd; /* ION fd for the file */ What does this have to do with ION? The driver seems to otherwise just use the generic dma_buf interfaces. > + uintptr_t mem; /* mem for the PD */ > + uint32_t memlen; /* mem length */ > + int32_t memfd; /* fd for the mem */ > + int attrs; > + unsigned int siglen; > +}; This structure is again not suitable for ioctls. Please used fixed-length members and no holes in the structure. Arnd