Linux 4.14.294
Greg Kroah-Hartman
maintainerI'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
Greg Kroah-Hartman
maintainerMakefile +1 -1
@@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 4 PATCHLEVEL = 14 -SUBLEVEL = 293 +SUBLEVEL = 294 EXTRAVERSION = NAME = Petit Gorille
drivers/gpu/drm/msm/msm_rd.c +3 -0
@@ -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. */
drivers/hid/intel-ish-hid/ishtp-hid.h +1 -1
@@ -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 */
drivers/net/ethernet/broadcom/tg3.c +6 -2
@@ -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); }/**
drivers/net/ieee802154/cc2520.c +1 -0
@@ -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; }
drivers/platform/x86/acer-wmi.c +8 -1
@@ -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 */
fs/tracefs/inode.c +23 -8
@@ -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 ;
mm/mmap.c +7 -2
@@ -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 );
On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
[]
drivers/hid/intel-ish-hid/ishtp-hid.h
Quoted 1 line
drivers/hid/intel-ish-hid/ishtp-hid.h +0
-0
[]
drivers/hid/intel-ish-hid/ishtp-hid.h struct report_list { · line 124
Quoted 9 lines
drivers/hid/intel-ish-hid/ishtp-hid.h +1
-1@@ -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.
Quoted 4 lines · Joe Perches
On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
[]drivers/hid/intel-ish-hid/ishtp-hid.h
Quoted 1 line
drivers/hid/intel-ish-hid/ishtp-hid.h +0
-0[]
Quoted 13 lines
drivers/hid/intel-ish-hid/ishtp-hid.h struct report_list { · line 124
Quoted 9 lines
drivers/hid/intel-ish-hid/ishtp-hid.h +1
-1@@ -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/[email protected]/
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Greg Kroah-Hartman
maintainerQuoted 19 lines · Bagas Sanjaya
Quoted 4 lines · Joe Perches
On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
[]drivers/hid/intel-ish-hid/ishtp-hid.h
Quoted 1 line
drivers/hid/intel-ish-hid/ishtp-hid.h +0
-0[]
Quoted 13 lines
drivers/hid/intel-ish-hid/ishtp-hid.h struct report_list { · line 124
Quoted 9 lines
drivers/hid/intel-ish-hid/ishtp-hid.h +1
-1@@ -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.
Quoted 4 lines
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.
Quoted 20 lines · Greg Kroah-Hartman
Quoted 19 lines · Bagas Sanjaya
Quoted 17 lines · Joe Perches
On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
[]drivers/hid/intel-ish-hid/ishtp-hid.h
Quoted 1 line
drivers/hid/intel-ish-hid/ishtp-hid.h +0
-0[]
drivers/hid/intel-ish-hid/ishtp-hid.h struct report_list { · line 124
Quoted 9 lines
drivers/hid/intel-ish-hid/ishtp-hid.h +1
-1@@ -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.
Quoted 6 lines
Quoted 4 lines
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?
Greg Kroah-Hartman
maintainerQuoted 24 lines · Joe Perches
Quoted 23 lines · Greg Kroah-Hartman
Quoted 22 lines · Bagas Sanjaya
Quoted 4 lines · Joe Perches
On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
[]drivers/hid/intel-ish-hid/ishtp-hid.h
Quoted 1 line
drivers/hid/intel-ish-hid/ishtp-hid.h +0
-0[]
Quoted 13 lines
drivers/hid/intel-ish-hid/ishtp-hid.h struct report_list { · line 124
Quoted 9 lines
drivers/hid/intel-ish-hid/ishtp-hid.h +1
-1@@ -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].
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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
Quoted 27 lines · Greg Kroah-Hartman
Quoted 26 lines · Joe Perches
Quoted 25 lines · Greg Kroah-Hartman
Quoted 23 lines · Bagas Sanjaya
Quoted 4 lines · Joe Perches
On Tue, 2022-09-20 at 12:17 +0200, Greg Kroah-Hartman wrote:
[]drivers/hid/intel-ish-hid/ishtp-hid.h
Quoted 1 line
drivers/hid/intel-ish-hid/ishtp-hid.h +0
-0[]
Quoted 13 lines
drivers/hid/intel-ish-hid/ishtp-hid.h struct report_list { · line 124
Quoted 9 lines
drivers/hid/intel-ish-hid/ishtp-hid.h +1
-1@@ -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.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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 <[email protected]> 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.
--------------------------
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
Hi!
Quoted 39 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 4 lines
Quoted 4 lines
(quoted diff) +0
-0@@ -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 likeQuoted 9 lines
Review struct report_list { · line 124
Quoted 5 lines
(quoted diff) +1
-1- * 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.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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:
--------------------------
commit94553f8a218540d676efbf3f7827ed493d1057cfAuthor: Jason Wang <[email protected]> Date: Thu Aug 4 08:58:14 2022 +0800HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo
The double `like' is duplicated in the comment, remove one.
Quoted 7 lines
Signed-off-by Jason Wang <[email protected]>Signed-off-by Jiri Kosina <[email protected]>--------------------------
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
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Re: stable-kernel-rules need updating? Re: Linux 4.14.294
Quoted 4 lines · Pavel Machek
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?
Quoted 10 lines
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?
Quoted 9 lines
# - 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.
Quoted 4 lines
# - 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.
Signature · 1 line
An old man doll... just what I always wanted! - Clara