Linux 4.14.294

Linux 4.14.294

[Greg Kroah-Hartman]

I'm announcing the release of the 4.14.294 kernel.

All users of the 4.14 kernel series must upgrade.

The updated 4.14.y git tree can be found at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y
and can be browsed at the normal kernel.org git web browser:
	https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h

------------

 Makefile                              |    2 +-
 drivers/gpu/drm/msm/msm_rd.c          |    3 +++
 drivers/hid/intel-ish-hid/ishtp-hid.h |    2 +-
 drivers/net/ethernet/broadcom/tg3.c   |    8 ++++++--
 drivers/net/ieee802154/cc2520.c       |    1 +
 drivers/platform/x86/acer-wmi.c       |    9 ++++++++-
 fs/tracefs/inode.c                    |   31 +++++++++++++++++++++++--------
 mm/mmap.c                             |    9 +++++++--
 8 files changed, 50 insertions(+), 15 deletions(-)

Brian Norris (1):
      tracefs: Only clobber mode/uid/gid on remount if asked

Greg Kroah-Hartman (1):
      Linux 4.14.294

Hans de Goede (1):
      platform/x86: acer-wmi: Acer Aspire One AOD270/Packard Bell Dot keymap fixes

Jann Horn (1):
      mm: Fix TLB flush for not-first PFNMAP mappings in unmap_region()

Jason Wang (1):
      HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo

Kai-Heng Feng (1):
      tg3: Disable tg3 device on system reboot to avoid triggering AER

Li Qiong (1):
      ieee802154: cc2520: add rc code in cc2520_tx()

Rob Clark (1):
      drm/msm/rd: Fix FIFO-full deadlock

Re: Linux 4.14.294

[Greg Kroah-Hartman]

diff --git a/Makefile b/Makefile
index e1f7e128afb0..222468241414 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 293
+SUBLEVEL = 294
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index bdce1c9434c6..54891cbf4f50 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -193,6 +193,9 @@ static int rd_open(struct inode *inode, struct file *file)
 	file->private_data = rd;
 	rd->open = true;
 
+	/* Reset fifo to clear any previously unread data: */
+	rd->fifo.head = rd->fifo.tail = 0;
+
 	/* the parsing tools need to know gpu-id to know which
 	 * register database to load.
 	 */
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.h b/drivers/hid/intel-ish-hid/ishtp-hid.h
index f5c7eb79b7b5..fa16983007f6 100644
--- a/drivers/hid/intel-ish-hid/ishtp-hid.h
+++ b/drivers/hid/intel-ish-hid/ishtp-hid.h
@@ -118,7 +118,7 @@ struct report_list {
  * @multi_packet_cnt:	Count of fragmented packet count
  *
  * This structure is used to store completion flags and per client data like
- * like report description, number of HID devices etc.
+ * report description, number of HID devices etc.
  */
 struct ishtp_cl_data {
 	/* completion flags */
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 480179ddc45b..3279a6e48f3b 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -18157,16 +18157,20 @@ static void tg3_shutdown(struct pci_dev *pdev)
 	struct net_device *dev = pci_get_drvdata(pdev);
 	struct tg3 *tp = netdev_priv(dev);
 
+	tg3_reset_task_cancel(tp);
+
 	rtnl_lock();
+
 	netif_device_detach(dev);
 
 	if (netif_running(dev))
 		dev_close(dev);
 
-	if (system_state == SYSTEM_POWER_OFF)
-		tg3_power_down(tp);
+	tg3_power_down(tp);
 
 	rtnl_unlock();
+
+	pci_disable_device(pdev);
 }
 
 /**
diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
index d50add705a79..436cf2007138 100644
--- a/drivers/net/ieee802154/cc2520.c
+++ b/drivers/net/ieee802154/cc2520.c
@@ -512,6 +512,7 @@ cc2520_tx(struct ieee802154_hw *hw, struct sk_buff *skb)
 		goto err_tx;
 
 	if (status & CC2520_STATUS_TX_UNDERFLOW) {
+		rc = -EINVAL;
 		dev_err(&priv->spi->dev, "cc2520 tx underflow exception\n");
 		goto err_tx;
 	}
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 5ddc359135a8..8b4af118ff94 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -106,6 +106,7 @@ static const struct key_entry acer_wmi_keymap[] __initconst = {
 	{KE_KEY, 0x22, {KEY_PROG2} },    /* Arcade */
 	{KE_KEY, 0x23, {KEY_PROG3} },    /* P_Key */
 	{KE_KEY, 0x24, {KEY_PROG4} },    /* Social networking_Key */
+	{KE_KEY, 0x27, {KEY_HELP} },
 	{KE_KEY, 0x29, {KEY_PROG3} },    /* P_Key for TM8372 */
 	{KE_IGNORE, 0x41, {KEY_MUTE} },
 	{KE_IGNORE, 0x42, {KEY_PREVIOUSSONG} },
@@ -119,7 +120,13 @@ static const struct key_entry acer_wmi_keymap[] __initconst = {
 	{KE_IGNORE, 0x48, {KEY_VOLUMEUP} },
 	{KE_IGNORE, 0x49, {KEY_VOLUMEDOWN} },
 	{KE_IGNORE, 0x4a, {KEY_VOLUMEDOWN} },
-	{KE_IGNORE, 0x61, {KEY_SWITCHVIDEOMODE} },
+	/*
+	 * 0x61 is KEY_SWITCHVIDEOMODE. Usually this is a duplicate input event
+	 * with the "Video Bus" input device events. But sometimes it is not
+	 * a dup. Map it to KEY_UNKNOWN instead of using KE_IGNORE so that
+	 * udev/hwdb can override it on systems where it is not a dup.
+	 */
+	{KE_KEY, 0x61, {KEY_UNKNOWN} },
 	{KE_IGNORE, 0x62, {KEY_BRIGHTNESSUP} },
 	{KE_IGNORE, 0x63, {KEY_BRIGHTNESSDOWN} },
 	{KE_KEY, 0x64, {KEY_SWITCHVIDEOMODE} },	/* Display Switch */
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 6ac0a079c5b7..304e85354c87 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -142,6 +142,8 @@ struct tracefs_mount_opts {
 	kuid_t uid;
 	kgid_t gid;
 	umode_t mode;
+	/* Opt_* bitfield. */
+	unsigned int opts;
 };
 
 enum {
@@ -242,6 +244,7 @@ static int tracefs_parse_options(char *data, struct tracefs_mount_opts *opts)
 	kgid_t gid;
 	char *p;
 
+	opts->opts = 0;
 	opts->mode = TRACEFS_DEFAULT_MODE;
 
 	while ((p = strsep(&data, ",")) != NULL) {
@@ -276,24 +279,36 @@ static int tracefs_parse_options(char *data, struct tracefs_mount_opts *opts)
 		 * but traditionally tracefs has ignored all mount options
 		 */
 		}
+
+		opts->opts |= BIT(token);
 	}
 
 	return 0;
 }
 
-static int tracefs_apply_options(struct super_block *sb)
+static int tracefs_apply_options(struct super_block *sb, bool remount)
 {
 	struct tracefs_fs_info *fsi = sb->s_fs_info;
 	struct inode *inode = sb->s_root->d_inode;
 	struct tracefs_mount_opts *opts = &fsi->mount_opts;
 
-	inode->i_mode &= ~S_IALLUGO;
-	inode->i_mode |= opts->mode;
+	/*
+	 * On remount, only reset mode/uid/gid if they were provided as mount
+	 * options.
+	 */
+
+	if (!remount || opts->opts & BIT(Opt_mode)) {
+		inode->i_mode &= ~S_IALLUGO;
+		inode->i_mode |= opts->mode;
+	}
 
-	inode->i_uid = opts->uid;
+	if (!remount || opts->opts & BIT(Opt_uid))
+		inode->i_uid = opts->uid;
 
-	/* Set all the group ids to the mount option */
-	set_gid(sb->s_root, opts->gid);
+	if (!remount || opts->opts & BIT(Opt_gid)) {
+		/* Set all the group ids to the mount option */
+		set_gid(sb->s_root, opts->gid);
+	}
 
 	return 0;
 }
@@ -308,7 +323,7 @@ static int tracefs_remount(struct super_block *sb, int *flags, char *data)
 	if (err)
 		goto fail;
 
-	tracefs_apply_options(sb);
+	tracefs_apply_options(sb, true);
 
 fail:
 	return err;
@@ -360,7 +375,7 @@ static int trace_fill_super(struct super_block *sb, void *data, int silent)
 
 	sb->s_op = &tracefs_super_operations;
 
-	tracefs_apply_options(sb);
+	tracefs_apply_options(sb, false);
 
 	return 0;
 
diff --git a/mm/mmap.c b/mm/mmap.c
index 17caf44807de..e230e08d47b8 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2524,6 +2524,7 @@ static void unmap_region(struct mm_struct *mm,
 {
 	struct vm_area_struct *next = prev ? prev->vm_next : mm->mmap;
 	struct mmu_gather tlb;
+	struct vm_area_struct *cur_vma;
 
 	lru_add_drain();
 	tlb_gather_mmu(&tlb, mm, start, end);
@@ -2538,8 +2539,12 @@ static void unmap_region(struct mm_struct *mm,
 	 * concurrent flush in this region has to be coming through the rmap,
 	 * and we synchronize against that using the rmap lock.
 	 */
-	if ((vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) != 0)
-		tlb_flush_mmu(&tlb);
+	for (cur_vma = vma; cur_vma; cur_vma = cur_vma->vm_next) {
+		if ((cur_vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) != 0) {
+			tlb_flush_mmu(&tlb);
+			break;
+		}
+	}
 
 	free_pgtables(&tlb, vma, prev ? prev->vm_end : FIRST_USER_ADDRESS,
 				 next ? next->vm_start : USER_PGTABLES_CEILING);

Re: Linux 4.14.294

[Joe Perches]

On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
[]
> diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.h b/drivers/hid/intel-ish-hid/ishtp-hid.h
[]
> @@ -118,7 +118,7 @@ struct report_list {
>   * @multi_packet_cnt:	Count of fragmented packet count
>   *
>   * This structure is used to store completion flags and per client data like
> - * like report description, number of HID devices etc.
> + * report description, number of HID devices etc.
>   */
>  struct ishtp_cl_data {
>  	/* completion flags */

Needless backporting of typo fixes reduces confidence in the
backport process.

Re: Linux 4.14.294

[Bagas Sanjaya]

On 9/22/22 01:03, Joe Perches wrote:
> On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
> []
>> diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.h b/drivers/hid/intel-ish-hid/ishtp-hid.h
> []
>> @@ -118,7 +118,7 @@ struct report_list {
>>   * @multi_packet_cnt:	Count of fragmented packet count
>>   *
>>   * This structure is used to store completion flags and per client data like
>> - * like report description, number of HID devices etc.
>> + * report description, number of HID devices etc.
>>   */
>>  struct ishtp_cl_data {
>>  	/* completion flags */
> 
> Needless backporting of typo fixes reduces confidence in the
> backport process.
> 

The upstream commit 94553f8a218540 ("HID: ishtp-hid-clientHID: ishtp-hid-client:
Fix comment typo") didn't Cc: stable, but got AUTOSELed [1].

I think we should only AUTOSEL patches that have explicit Cc: stable.

[1]: https://lore.kernel.org/stable/20220910211938.70997-2-sashal@kernel.org/

-- 
An old man doll... just what I always wanted! - Clara

Re: Linux 4.14.294

[Greg Kroah-Hartman]

On Thu, Sep 22, 2022 at 11:02:21AM +0700, Bagas Sanjaya wrote:
> On 9/22/22 01:03, Joe Perches wrote:
> > On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
> > []
> >> diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.h b/drivers/hid/intel-ish-hid/ishtp-hid.h
> > []
> >> @@ -118,7 +118,7 @@ struct report_list {
> >>   * @multi_packet_cnt:	Count of fragmented packet count
> >>   *
> >>   * This structure is used to store completion flags and per client data like
> >> - * like report description, number of HID devices etc.
> >> + * report description, number of HID devices etc.
> >>   */
> >>  struct ishtp_cl_data {
> >>  	/* completion flags */
> > 
> > Needless backporting of typo fixes reduces confidence in the
> > backport process.
> > 
> 
> The upstream commit 94553f8a218540 ("HID: ishtp-hid-clientHID: ishtp-hid-client:
> Fix comment typo") didn't Cc: stable, but got AUTOSELed [1].
> 
> I think we should only AUTOSEL patches that have explicit Cc: stable.

That's not how AUTOSEL works or why it is there at all, sorry.

Re: Linux 4.14.294

[Joe Perches]

On Thu, 2022-09-22 at 08:53 +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 22, 2022 at 11:02:21AM +0700, Bagas Sanjaya wrote:
> > On 9/22/22 01:03, Joe Perches wrote:
> > > On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
> > > []
> > > > diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.h b/drivers/hid/intel-ish-hid/ishtp-hid.h
> > > []
> > > > @@ -118,7 +118,7 @@ struct report_list {
> > > >   * @multi_packet_cnt:	Count of fragmented packet count
> > > >   *
> > > >   * This structure is used to store completion flags and per client data like
> > > > - * like report description, number of HID devices etc.
> > > > + * report description, number of HID devices etc.
> > > >   */
> > > >  struct ishtp_cl_data {
> > > >  	/* completion flags */
> > > 
> > > Needless backporting of typo fixes reduces confidence in the
> > > backport process.
> > > 
> > 
> > The upstream commit 94553f8a218540 ("HID: ishtp-hid-clientHID: ishtp-hid-client:
> > Fix comment typo") didn't Cc: stable, but got AUTOSELed [1].
> > 
> > I think we should only AUTOSEL patches that have explicit Cc: stable.
> 
> That's not how AUTOSEL works or why it is there at all, sorry.

Perhaps not, but why is AUTOSEL choosing this and why is
this being applied without apparent human review?

Re: Linux 4.14.294

[Greg Kroah-Hartman]

On Thu, Sep 22, 2022 at 01:26:59AM -0700, Joe Perches wrote:
> On Thu, 2022-09-22 at 08:53 +0200, Greg Kroah-Hartman wrote:
> > On Thu, Sep 22, 2022 at 11:02:21AM +0700, Bagas Sanjaya wrote:
> > > On 9/22/22 01:03, Joe Perches wrote:
> > > > On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
> > > > []
> > > > > diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.h b/drivers/hid/intel-ish-hid/ishtp-hid.h
> > > > []
> > > > > @@ -118,7 +118,7 @@ struct report_list {
> > > > >   * @multi_packet_cnt:	Count of fragmented packet count
> > > > >   *
> > > > >   * This structure is used to store completion flags and per client data like
> > > > > - * like report description, number of HID devices etc.
> > > > > + * report description, number of HID devices etc.
> > > > >   */
> > > > >  struct ishtp_cl_data {
> > > > >  	/* completion flags */
> > > > 
> > > > Needless backporting of typo fixes reduces confidence in the
> > > > backport process.
> > > > 
> > > 
> > > The upstream commit 94553f8a218540 ("HID: ishtp-hid-clientHID: ishtp-hid-client:
> > > Fix comment typo") didn't Cc: stable, but got AUTOSELed [1].
> > > 
> > > I think we should only AUTOSEL patches that have explicit Cc: stable.
> > 
> > That's not how AUTOSEL works or why it is there at all, sorry.
> 
> Perhaps not, but why is AUTOSEL choosing this and why is
> this being applied without apparent human review?

We always appreciate more review, and welcome it.  Sometimes things slip
by us as well, like it did for this one.  The changelog makes it look
like a real fix that is needed.

thanks,

greg k-h

Re: Linux 4.14.294

[Joe Perches]

On Thu, 2022-09-22 at 10:32 +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 22, 2022 at 01:26:59AM -0700, Joe Perches wrote:
> > On Thu, 2022-09-22 at 08:53 +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 22, 2022 at 11:02:21AM +0700, Bagas Sanjaya wrote:
> > > > On 9/22/22 01:03, Joe Perches wrote:
> > > > > On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
> > > > > []
> > > > > > diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.h b/drivers/hid/intel-ish-hid/ishtp-hid.h
> > > > > []
> > > > > > @@ -118,7 +118,7 @@ struct report_list {
> > > > > >   * @multi_packet_cnt:	Count of fragmented packet count
> > > > > >   *
> > > > > >   * This structure is used to store completion flags and per client data like
> > > > > > - * like report description, number of HID devices etc.
> > > > > > + * report description, number of HID devices etc.
> > > > > >   */
> > > > > >  struct ishtp_cl_data {
> > > > > >  	/* completion flags */
> > > > > 
> > > > > Needless backporting of typo fixes reduces confidence in the
> > > > > backport process.
> > > > > 
> > > > 
> > > > The upstream commit 94553f8a218540 ("HID: ishtp-hid-clientHID: ishtp-hid-client:
> > > > Fix comment typo") didn't Cc: stable, but got AUTOSELed [1].
> > > > 
> > > > I think we should only AUTOSEL patches that have explicit Cc: stable.
> > > 
> > > That's not how AUTOSEL works or why it is there at all, sorry.
> > 
> > Perhaps not, but why is AUTOSEL choosing this and why is
> > this being applied without apparent human review?
> 
> We always appreciate more review, and welcome it.  Sometimes things slip
> by us as well, like it did for this one.  The changelog makes it look
> like a real fix that is needed.

What part of:

--------------------------
commit 94553f8a218540d676efbf3f7827ed493d1057cf
Author: Jason Wang <wangborong@cdjrlc.com>
Date:   Thu Aug 4 08:58:14 2022 +0800

    HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo
    
    The double `like' is duplicated in the comment, remove one.
    
    Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
--------------------------

makes it seem like a candidate for backporting?

Perhaps the eagerness to backport is simply too high.

stable-kernel-rules need updating? Re: Linux 4.14.294

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 4151 bytes --]

Hi!

> > > > > > > @@ -118,7 +118,7 @@ struct report_list {
> > > > > > >   * @multi_packet_cnt:	Count of fragmented packet count
> > > > > > >   *
> > > > > > >   * This structure is used to store completion flags and per client data like
> > > > > > > - * like report description, number of HID devices etc.
> > > > > > > + * report description, number of HID devices etc.
> > > > > > >   */
> > > > > > >  struct ishtp_cl_data {
> > > > > > >  	/* completion flags */
> > > > > > 
> > > > > > Needless backporting of typo fixes reduces confidence in the
> > > > > > backport process.
> > > > > > 
> > > > > 
> > > > > The upstream commit 94553f8a218540 ("HID: ishtp-hid-clientHID: ishtp-hid-client:
> > > > > Fix comment typo") didn't Cc: stable, but got AUTOSELed [1].
> > > > > 
> > > > > I think we should only AUTOSEL patches that have explicit Cc: stable.
> > > > 
> > > > That's not how AUTOSEL works or why it is there at all, sorry.
> > > 
> > > Perhaps not, but why is AUTOSEL choosing this and why is
> > > this being applied without apparent human review?
> > 
> > We always appreciate more review, and welcome it.  Sometimes things slip
> > by us as well, like it did for this one.  The changelog makes it look
> > like a real fix that is needed.
> 
> What part of:
> 
> --------------------------
> commit 94553f8a218540d676efbf3f7827ed493d1057cf
> Author: Jason Wang <wangborong@cdjrlc.com>
> Date:   Thu Aug 4 08:58:14 2022 +0800
> 
>     HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo

>     The double `like' is duplicated in the comment, remove one.
>     
>     Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
>     Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> --------------------------
> 
> makes it seem like a candidate for backporting?
> 
> Perhaps the eagerness to backport is simply too high.

Eagerness to backport is too high, yes. In this case, I guess "Fix" is
what triggered AUTOSEL.

We (as in CIP project) review patches going to stable, and review some
at AUTOSEL phase.

OTOH ammount of "too trivial" patches in AUTOSEL and -stable is quite
high. I tried to report some, but it did not appear stable team is
willing to drop patches just because they are "too trivial".

[Plus there's worse stuff in stable, like known-broken patch being
applied then reverted, because that apparently makes it easier for
some scripts.]

To make problem worse, sometimes "too trivial" patch is prerequisite
for some other patch; but there's no marking making it easy to
identify such stuff.

Basically... stable-kernel-rules.rst "needs some updating", or some
explanation that people can not expect patches in -stable to follow
them.

# Rules on what kind of patches are accepted, and which ones are not, into the
# "-stable" tree:
# 
#  - It must be obviously correct and tested.

Known-bad patches are applied and reverted.

#  - It cannot be bigger than 100 lines, with context.

Way bigger patches are often seen.

#  - It must fix only one thing.

If upstream patch fixes 3 things and does 5 cleanups, stable accepts that.

#  - It must fix a real bug that bothers people (not a, "This could be a
#    problem..." type thing).

Patches where changelog says bug is theoretical are often taken. Can
get examples if neccessary.

#  - It must fix a problem that causes a build error (but not for things
#    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
#    security issue, or some "oh, that's not good" issue.  In short, something
#    critical.

All kind of bugs are fair game. For example, tweaks to remove noise printks. 

#  - It cannot contain any "trivial" fixes in it (spelling changes,
#    whitespace cleanups, etc).

This is not enforced, nor it can be enforced easily.

#  - It or an equivalent fix must already exist in Linus' tree (upstream).

This is the only real rule for the -stable tree.

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: stable-kernel-rules need updating? Re: Linux 4.14.294

[Bagas Sanjaya]

On 9/25/22 01:21, Pavel Machek wrote:
> To make problem worse, sometimes "too trivial" patch is prerequisite
> for some other patch; but there's no marking making it easy to
> identify such stuff.
> 

Seems like these prerequisite trivial patches should have been
Cc: stable, right?

> Basically... stable-kernel-rules.rst "needs some updating", or some
> explanation that people can not expect patches in -stable to follow
> them.
> 
> # Rules on what kind of patches are accepted, and which ones are not, into the
> # "-stable" tree:
> # 
> #  - It must be obviously correct and tested.
> 
> Known-bad patches are applied and reverted.

Shouldn't kernel test robot catch build failures due to bad patches?

> 
> #  - It cannot be bigger than 100 lines, with context.
> 
> Way bigger patches are often seen.
> 
> #  - It must fix only one thing.
> 
> If upstream patch fixes 3 things and does 5 cleanups, stable accepts that.
> 

As long as these multi-things constitute as one logical change and
requires hundreds of lines, that's OK.


> #  - It cannot contain any "trivial" fixes in it (spelling changes,
> #    whitespace cleanups, etc).
> 
> This is not enforced, nor it can be enforced easily.

But some people had like to see these trivial fixes go through stable tree
(perhaps timing of merging to mainline issues that such fixes miss the
intended merge window).

Thanks.

-- 
An old man doll... just what I always wanted! - Clara