linux-kernel - Re: [PATCH 4/5] alienware-wmi: Fix module init error handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <31712d24-e1ae-0928-a7ab-a1f7116844ff@linux.intel.com>
Date: Tue, 19 Nov 2024 18:22:34 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Kurt Borja <kuurtb@...il.com>
cc: Markus Elfring <Markus.Elfring@....de>, 
    platform-driver-x86@...r.kernel.org, Dell.Client.Kernel@...l.com, 
    LKML <linux-kernel@...r.kernel.org>, Armin Wolf <W_Armin@....de>, 
    Hans de Goede <hdegoede@...hat.com>, 
    Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH 4/5] alienware-wmi: Fix module init error handling

On Tue, 19 Nov 2024, Kurt Borja wrote:

> On Tue, Nov 19, 2024 at 03:55:08PM +0100, Markus Elfring wrote:
> > > Propagate led_classdev_register return value in case of error.
> > > Call led_classdev_unregister in case sysfs_create_group fails.
> > >
> > > If alienware_zone_init fails, alienware_zone_exit should not be called
> > > because the latter unregisters/removes the led class and the sysfs
> > > group, which may not be registered/created if the former failed
> > > prematurely.
> > 
> > How do you think about to add any tags (like “Fixes” and “Cc”) accordingly?
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.12#n145
> 
> Sure! I will on v2.
> 
> This might be kind of obvious but, if I add the Fixes tag, do I have to
> make the patch over that commit, over stable trees or leave it as is?

Hi Kurt,

You do it normally on top of pdx86 fixes branch. In this case because of 
the on-going merge window, you'll have for-next patch to enter there 
before your fix will get merged after -rc1.

Don't worry about stable at this point too much, other than try to have
the fixes patches as early as possible in your series to avoid conflicts 
with the other patches within your own patch series.

-- 
 i.