Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7181850yba; Thu, 2 May 2019 05:49:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqzJ5ufVYacZfVJpCAMEo500dClIDhE4buZDdvh9o9kyW8m51iCbbk5yOkldJA5OI5iB2DSI X-Received: by 2002:a24:e85:: with SMTP id 127mr2118813ite.4.1556801340235; Thu, 02 May 2019 05:49:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556801340; cv=none; d=google.com; s=arc-20160816; b=ulusIYqR4IKbFkrHByHF1BcCUQW6vH4U3vye0OmoAzq8QsR1SwzbXVpZiHPRb56Vfr ng/Ro1LFJbmx9BkBATdXZdDiQru4ndg7B+VTqLGGDJpy6Gy1NanehW8XayY3zknSCRts p7rPwq2QmdoH+P04muF/GoAnpyAI65g6bUztUqKefnZfahLsgFAA4GSIzxiQyfW+f7LZ eQhPKv0M0i635a4y+7rqgXZ+s7OuByXBZjt8q9CmjSBT6YG9xnRIWlXi17ZlCma4FIzx Z5iz0fKE9wuHX+rCqnbRky3sSvvV5747dxL1dd99MFtEYEi78QNnOdqSkcyBs3aokM2H uzGQ== 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 :references:in-reply-to:date:cc:to:from:subject:message-id; bh=NXk2+2fLUsQCqI4fD3o6KfAKcB7xwIKGTCavM8u69tM=; b=X7KVwZzLT3oVO9yZfvgMGujrllKl7qgQA5BdmXLxGGq+cME2pZ8uOSTv6iIPIJ4/Sb XCdQhlT2/HHk5UQNgDhoVhDni9uKBv99Vg4CSXrHIaoblSKbmeff65/uB1zIgd1WuOtT ct2mXyjVp1/8kPa29OS8ae3+48dSpjQCuzVs0IAJ/C+aOhLwNE6u4iOPrTIIpPlxzcZS Eoav6VKCI7EBm5KtpSuQoxOea8QAGDfzkXLwQeCb9bVozdK3w0008SOqtzXtOVbXtm9Z 8hQ67V2WRYA3axPUq2HDalvUbN2FVox+grcsYT3aAdsw86SLP9D2Acsw9j47/gj3Zmgk QWrg== 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 d63si6383189ita.70.2019.05.02.05.48.45; Thu, 02 May 2019 05:49:00 -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 S1726321AbfEBMrv (ORCPT + 99 others); Thu, 2 May 2019 08:47:51 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:55384 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726267AbfEBMrv (ORCPT ); Thu, 2 May 2019 08:47:51 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hMB7s-0000qc-KI; Thu, 02 May 2019 14:47:48 +0200 Message-ID: Subject: Re: [PATCH 2/4] devcoredump: allow to create several coredump files in one device From: Johannes Berg To: Akinobu Mita , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg Date: Thu, 02 May 2019 14:47:47 +0200 In-Reply-To: <1556787561-5113-3-git-send-email-akinobu.mita@gmail.com> (sfid-20190502_105944_673346_AEC5725E) References: <1556787561-5113-1-git-send-email-akinobu.mita@gmail.com> <1556787561-5113-3-git-send-email-akinobu.mita@gmail.com> (sfid-20190502_105944_673346_AEC5725E) Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2019-05-02 at 17:59 +0900, Akinobu Mita wrote: > > static void devcd_del(struct work_struct *wk) > { > struct devcd_entry *devcd; > + int i; > > devcd = container_of(wk, struct devcd_entry, del_wk.work); > > + for (i = 0; i < devcd->num_files; i++) { > + device_remove_bin_file(&devcd->devcd_dev, > + &devcd->files[i].bin_attr); > + } Not much value in the braces? > +static struct devcd_entry *devcd_alloc(struct dev_coredumpm_bulk_data *files, > + int num_files, gfp_t gfp) > +{ > + struct devcd_entry *devcd; > + int i; > + > + devcd = kzalloc(sizeof(*devcd), gfp); > + if (!devcd) > + return NULL; > + > + devcd->files = kcalloc(num_files, sizeof(devcd->files[0]), gfp); > + if (!devcd->files) { > + kfree(devcd); > + return NULL; > + } > + devcd->num_files = num_files; IMHO it would be nicer to allocate all of this in one struct, i.e. have struct devcd_entry { ... struct devcd_file files[]; } (and then use struct_size()) > @@ -309,7 +339,41 @@ void dev_coredumpm(struct device *dev, struct module *owner, > put_module: > module_put(owner); > free: > - free(data); > + for (i = 0; i < num_files; i++) > + files[i].free(files[i].data); > +} and then you don't need to do all this kind of thing to free Otherwise looks fine. I'd worry a bit that existing userspace will only capture the 'data' file, rather than a tarball of all files, but I guess that's something you'd have to work out then when actually desiring to use multiple files. johannes