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] [day] [month] [year] [list]
Message-ID: <wlgbeskxv3z3mpoaydcktkgqsn3g7vewhto6vcjarexlvsqlk2@ug5y4efk7yt6>
Date: Tue, 19 Nov 2024 16:01:38 -0300
From: Kurt Borja <kuurtb@...il.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.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, Nov 19, 2024 at 06:22:34PM +0200, Ilpo Järvinen wrote:
> 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.

That's good to know, thank you very much :).

> 
> -- 
>  i.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ