Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp2494317pxy; Sat, 24 Apr 2021 18:08:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzUXeaW+YNvzGqlo6yS71KlUU+cudQqhjIZPZ6mAkivLjMp3HHEpynyLb7+mcl9ASwh8XDy X-Received: by 2002:aa7:838d:0:b029:221:cd7d:90d8 with SMTP id u13-20020aa7838d0000b0290221cd7d90d8mr10535985pfm.61.1619312907535; Sat, 24 Apr 2021 18:08:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619312907; cv=none; d=google.com; s=arc-20160816; b=E+8KgiyswqelZMAWbD2o3mhJnbOGylmpDYzutjV4xM/dpzG7+mqj3FbgK/mu8lsWI0 MHfXlAxQtgPAGG/fqFB1pyBciyM3/ox1UbiSUBRILJgmhUPL3xSHLKWMWm73deBUQ+CF EjuJIvwsntklNmRoExNu6VJhghT6QyQuBj6xKy0BmGqRjwHp3MNpe/ju9CNoFaw43RWK QrFWQVnceO8j2EECn7GsNYrRI/VwsOUFvSKETlXIHVQFV2/MJb/II93DYKb4tKCCu1uR zrhHYTFsKI49rnJ+/GsYd1Y9Vcg6yhnZ+91GDN7HnPxnxwdsakBQk+rJATOMcSHL+wYv zv/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:reply-to:cc:from:to :dkim-signature:date; bh=H1qMUcszeVpiIb8uqcXaGdv2ktJ1dJmxagIhRMHp9e0=; b=Ju16/l4Bfuia0YdjySHJzeflBvtO3HnKw96p63bD6ZyztgzYY9mCHSvwE9ONGy/2iF 8tw1rKwhpUQxha0kI0P2lxR1YtY3FT1Yo6xVCcW3jkReEG5R0Eq+Z1K7xuoyAurtO0t9 fvbGsHLeUQzVeoDyl5PAyek9Q86Py/brWOd5MblyDWdyxTshN0KX8XBbx7Q8OPZoZbCV 3gUEH3HxzFaA/NlhdsMw4KOD8q1Jc0UbcR9QRertoy8eLp9LDdGUOHbymvww0nog6Wtl /+9N6VaEf3FyN/M84FiNBYzsVnM91GZvEhCe5caQIcmFa+GnuVZehgUy8h6hoLXletaJ HAhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail header.b=hJ60eizs; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e12si11022597pgj.535.2021.04.24.18.08.15; Sat, 24 Apr 2021 18:08:27 -0700 (PDT) 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=@protonmail.com header.s=protonmail header.b=hJ60eizs; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230129AbhDYBGz (ORCPT + 99 others); Sat, 24 Apr 2021 21:06:55 -0400 Received: from mail-40133.protonmail.ch ([185.70.40.133]:45457 "EHLO mail-40133.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229723AbhDYBGz (ORCPT ); Sat, 24 Apr 2021 21:06:55 -0400 Date: Sun, 25 Apr 2021 01:06:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1619312774; bh=H1qMUcszeVpiIb8uqcXaGdv2ktJ1dJmxagIhRMHp9e0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=hJ60eizsVk6CxSGemow6q0kUrB+SAbCTu1mB3sUPcw4fE0fVIvAIbdaIp9LmzgXEw xFLFwXeB9DeueCg8q7PD8JUvJwBPwYf36AhNbziGeAOfsnr4z5O4gmqyj+XhpTu146 msKywUuN/1RUhL+H6mKlBW4B26DeldTFAG2KhJ5s= To: Anupama K Patil From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: Jaroslav Kysela , "Rafael J. Wysocki" , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "skhan@linuxfoundation.org" , "bkkarthik@pesu.pes.edu" , "gregkh@linuxfoundation.org" , "kernelnewbies@kernelnewbies.org" Reply-To: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Subject: Re: [PATCH] drivers: pnp: proc.c: Handle errors while attaching devices Message-ID: In-Reply-To: <20210424194301.jmsqpycvsm7izbk3@ubuntu> References: <20210424194301.jmsqpycvsm7izbk3@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi 2021. =C3=A1prilis 24., szombat 21:43 keltez=C3=A9ssel, Anupama K Patil = =C3=ADrta: > isapnp_proc_init() does not look at the return value from > isapnp_proc_attach_device(). Check for this return value in > isapnp_proc_detach_device(). > > Cleanup in isapnp_proc_detach_device and > isapnp_proc_detach_bus() for cleanup. > > Changed sprintf() to the kernel-space function scnprintf() as it returns > the actual number of bytes written. > > Removed unnecessary variables de, e of type 'struct proc_dir_entry' to > save memory. > > Suggested-by: Shuah Khan > Co-developed-by: B K Karthik > Signed-off-by: B K Karthik > Signed-off-by: Anupama K Patil > --- > drivers/pnp/isapnp/proc.c | 40 +++++++++++++++++++++++++++++---------- > 1 file changed, 30 insertions(+), 10 deletions(-) > > diff --git a/drivers/pnp/isapnp/proc.c b/drivers/pnp/isapnp/proc.c > index 785a796430fa..46ebc24175b7 100644 > --- a/drivers/pnp/isapnp/proc.c > +++ b/drivers/pnp/isapnp/proc.c > @@ -54,34 +54,54 @@ static const struct proc_ops isapnp_proc_bus_proc_ops= =3D { > =09.proc_read=09=3D isapnp_proc_bus_read, > }; > > +static int isapnp_proc_detach_device(struct pnp_dev *dev) > +{ > +=09proc_remove(dev->procent); > +=09dev->procent =3D NULL; > +=09return 0; > +} > + > +static int isapnp_proc_detach_bus(struct pnp_card *bus) > +{ > +=09proc_remove(bus->procdir); Is there any reason for not setting `bus->procdir` to `NULL` similarly to the previous function? > +=09return 0; > +} > + Is there any reason why the previous two functions return something? It doe= sn't seem to be necessary. > static int isapnp_proc_attach_device(struct pnp_dev *dev) > { > =09struct pnp_card *bus =3D dev->card; > -=09struct proc_dir_entry *de, *e; > =09char name[16]; > > -=09if (!(de =3D bus->procdir)) { > -=09=09sprintf(name, "%02x", bus->number); > -=09=09de =3D bus->procdir =3D proc_mkdir(name, isapnp_proc_bus_dir); > -=09=09if (!de) > +=09if (!bus->procdir) { > +=09=09scnprintf(name, 16, "%02x", bus->number); I think `sizeof(name)` would be preferable to hard-coding 16. > +=09=09bus->procdir =3D proc_mkdir(name, isapnp_proc_bus_dir); > +=09=09if (!bus->procdir) > =09=09=09return -ENOMEM; > =09} > -=09sprintf(name, "%02x", dev->number); > -=09e =3D dev->procent =3D proc_create_data(name, S_IFREG | S_IRUGO, de, > +=09scnprintf(name, 16, "%02x", dev->number); Here as well. > +=09dev->procent =3D proc_create_data(name, S_IFREG | S_IRUGO, bus->procd= ir, > =09=09=09=09=09 &isapnp_proc_bus_proc_ops, dev); Please align the continuation properly. > -=09if (!e) > +=09if (!dev->procent) { > +=09=09isapnp_proc_detach_bus(bus); I'm not sure if this should be here. If I'm not mistaken, the code creates a procfs directory for a bus when it first sees a `pnp_dev` from th= at bus. This call removes the whole directory for the bus, and with that, the files= of those `pnp_dev`s which were successfully created earlier. > =09=09return -ENOMEM; > -=09proc_set_size(e, 256); > +=09} > +=09proc_set_size(dev->procent, 256); > =09return 0; > } > > int __init isapnp_proc_init(void) > { > =09struct pnp_dev *dev; > +=09int dev_attach; > > =09isapnp_proc_bus_dir =3D proc_mkdir("bus/isapnp", NULL); You could add a check to see if this `proc_mkdir()` call succeeds, and possibly return early if it does not. > =09protocol_for_each_dev(&isapnp_protocol, dev) { > -=09=09isapnp_proc_attach_device(dev); > +=09=09dev_attach =3D isapnp_proc_attach_device(dev); > +=09=09if (!dev_attach) { `isapnp_proc_attach_device()` returns 0 on success, so the condition should= be inverted. And maybe `err` or something like that would be a better name than `dev_att= ach`. > +=09=09=09pr_info("procfs: pnp: Unable to attach the device, not enough m= emory"); If I'm not mistaken, allocation failures are logged, so this is probably no= t needed. > +=09=09=09isapnp_proc_detach_device(dev); I'm also not sure if this is needed here. If `isapnp_proc_attach_device()` = returns an error, then `dev->procdir` could not have been "created". In other words= , if the execution reaches this point, `proc_create_data()` could not have su= cceeded because either it had not yet been called or it had failed. > +=09=09=09return -ENOMEM; It is usually preferable to return the error code you receive. E.g.: err =3D isapnp_proc_attach_device(...); if (err) { ... return err; } > +=09=09} > =09} > =09return 0; > } > -- > 2.25.1 > Regards, Barnab=C3=A1s P=C5=91cze