On Wed, May 02, 2018 at 12:00:40AM +0000, Sasha Levin wrote: > On Tue, May 01, 2018 at 03:09:46PM -0700, Greg KH wrote: > >On Fri, Apr 27, 2018 at 02:00:43AM +0000, Sasha Levin wrote: > >> Hi Greg, > >> > >> Pleae pull commits for Linux 4.16 . > >> > >> I've sent a review request for all commits over a week ago and all > >> comments were addressed. > > > >I reviewed all of these, and found 6 that I don't think really should be > >applied. Attached is the mbox with those 6, anything there that you > >want to lobby for to be included, or any background information I need > >to make it easier for me to accept them? > > I'll try (see below). Thanks, if this format doesn't work for you, I can reply to the individual patches as well. > > >From 8a81b29dc572635e5f32dd8c2dc0afe109c91f8e Mon Sep 17 00:00:00 2001 > >From: Davidlohr Bueso <dave@xxxxxxxxxxxx> > >Date: Tue, 10 Apr 2018 16:35:26 -0700 > >Subject: [PATCH 015/345] ipc/sem: introduce semctl(SEM_STAT_ANY) > >Content-Length: 4689 > >Lines: 134 > > > >[ Upstream commit a280d6dc77eb6002f269d58cd47c7c7e69b617b6 ] > > This tries to deal with a missing security check by adding audit() to > catch accesses. > > SUSE ended up pulling this patch for their kernel: > https://www.suse.com/support/update/announcement/2018/suse-su-20180834-1/ Yeah, but it feels like it is a "new feature", to catch something that had never been "caught" before. The author of this is also confused as to why it is backported, see his other email about this. > >From a90b3b30ab51dd2c1e903be526047bd72f59f7f2 Mon Sep 17 00:00:00 2001 > >From: Davidlohr Bueso <dave@xxxxxxxxxxxx> > >Date: Tue, 10 Apr 2018 16:35:23 -0700 > >Subject: [PATCH 019/345] ipc/shm: introduce shmctl(SHM_STAT_ANY) > >Content-Length: 7377 > >Lines: 212 > > > >[ Upstream commit c21a6970ae727839a2f300cd8dd957de0d0238c3 ] > > Same as the above. Same, I also missed one of these, so I've now dropped the third patch in this series. > >From 00ba54b54545fe7261686e167090f02638534697 Mon Sep 17 00:00:00 2001 > >From: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> > >Date: Fri, 16 Mar 2018 16:33:06 +0200 > >Subject: [PATCH 153/345] xhci: Show what USB release number the xHC supports > > from protocol capablity > >Content-Length: 1985 > >Lines: 58 > > > >[ Upstream commit 0ee78c101425aae681c631ba59c6ac7f44b1d83a ] > > > >xhci driver displays the supported xHC USB revision in a message during > >driver load: > > > >"Host supports USB 3.1 Enhanced SuperSpeed" > > > >Get the USB minor revision number from the xhci protocol capability. > >This will show the correct supported revisions for new USB 3.2 and later > >hosts > > > >Don't rely on the SBRN (serial bus revision number) register, it's often > >showing 0x30 (USB3.0) for hosts that support USB 3.1 > > In general, I'll try to pull in a commit that fixes a warning (or > incorrect information, in this case) shown to the user. > > You've also in the past pulled in similar commits (such as > https://lkml.org/lkml/2017/10/24/603 which basically fixed the same > bug). Ah, I missed that this was fixing an issue, I thought it was only a dmesg "update". I'll go queue this one up now, thanks. > >From 22acee3325a6ec984c80cc8222339dd53c6e28a9 Mon Sep 17 00:00:00 2001 > >From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> > >Date: Mon, 8 Jan 2018 14:35:52 -0800 > >Subject: [PATCH 282/345] rcu: Create RCU-specific workqueues with rescuers > >Content-Length: 4106 > >Lines: 113 > > > >[ Upstream commit ad7c946b35ad455417fdd4bc0e17deda4011841b ] > > This fixes the hard lockup reported here: > https://lkml.org/lkml/2018/1/8/1207 Ah, that wasn't obvious, I'll go add this one back, thanks. greg k-h
