As discussed earlier,
From: Wang Han <wanghan1995315(a)gmail.com>
Date: Sat, 3 Feb 2018 03:28:35 +1400
Subject: [PATCH] ipv4: Map neigh lookup keys in __ipv4_neigh_lookup_noref()
Commit 6c16fa957e84 is an incorrect backport as we map the keys in
struct __ipv4_neigh_lookup(), but the correct place to add the
code is struct __ipv4_neigh_lookup_noref(), compared to upstream.
Fix it by moving the code, or fewer cases will be covered as
__ipv4_neigh_lookup_noref() will be called unconditionally from
__ipv4_neigh_lookup(), and it can be called from other places
such as ip_output.c.
Fixes: 6c16fa957e84 (ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY)
Signed-off-by: Wang Han <wanghan1995315(a)gmail.com>
---
include/net/arp.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/arp.h b/include/net/arp.h
index 174014585ade..5d8c7990582f 100644
--- a/include/net/arp.h
+++ b/include/net/arp.h
@@ -22,6 +22,9 @@ static inline struct neighbour *__ipv4_neigh_lookup_noref(struct net_device *dev
struct neighbour *n;
u32 hash_val;
+ if (dev->flags & (IFF_LOOPBACK | IFF_POINTOPOINT))
+ key = INADDR_ANY;
+
hash_val = arp_hashfn(key, dev, nht->hash_rnd[0]) >> (32 - nht->hash_shift);
for (n = rcu_dereference_bh(nht->hash_buckets[hash_val]);
n != NULL;
@@ -37,9 +40,6 @@ static inline struct neighbour *__ipv4_neigh_lookup(struct net_device *dev, u32
{
struct neighbour *n;
- if (dev->flags & (IFF_LOOPBACK | IFF_POINTOPOINT))
- key = INADDR_ANY;
-
rcu_read_lock_bh();
n = __ipv4_neigh_lookup_noref(dev, key);
if (n && !atomic_inc_not_zero(&n->refcnt))
--
2.14.1
On Wed, Feb 07, 2018 at 03:19:07PM +0000, Harsh Shandilya wrote:
> On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, <gregkh(a)linuxfoundation.org>
> wrote:
>
> > This is the start of the stable review cycle for the 3.18.94 release.
> > There are 36 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Feb 7 18:23:41 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> Let's find out if I am too late.
>
> https://www.spinics.net/lists/stable/msg213160.html will have to be lined
> up for 3.18.94, or to .95 if I'm late since it's fixing a erroneous
> backport from 3.18.93 which went unnoticed until after release. The email
> bringing it up and the subsequent patch were probably lost in the usual
> stable noise. I have applied it to the CAF tree for the oneplus3 and
> verified that it does not break compilation or userspace for arm64.
It will be queued up for the next release, I missed it this time, sorry.
greg k-h
On Sat, Feb 03, 2018 at 07:25:54PM +0100, Markus Demleitner wrote:
> On Tue, Jan 30, 2018 at 07:32:04AM +0100, Greg KH wrote:
> > On Mon, Jan 29, 2018 at 07:21:09PM +0100, Markus Demleitner wrote:
> > > A while ago I opened bug #197863 in the kernel bugzilla:
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=197863
> > >
> > > Essentially, xhci_hcd on a resume from RAM takes several seconds on a
> > > Thinkpad X240 that is equipped with a Sierra LTE modem after an
> > > upgrade to 4.13:
> [...]
> > > Now, interestingly, there are quick resumes in 4.15.0, too, now and
> > > then. In that case, things look pretty much like on 4.12.2. Here's
> > > a 4.15.0 fast resume example:
> > >
> > > [ 873.127570] usb 1-4: device firmware changed
> > > [ 873.277351] usb 1-8: reset high-speed USB device number 4 using xhci_hcd
> > > [ 873.515141] restoring control 00000000-0000-0000-0000-000000000101/0/2
> > > [ 873.583238] OOM killer enabled.
> > > [ 873.583240] Restarting tasks ...
> > > [ 873.583339] usb 1-4: USB disconnect, device number 10
> > > [ 873.586356] done.
> > > [ 873.604420] PM: suspend exit
> > > [ 873.737283] usb 1-4: new high-speed USB device number 11 using xhci_hcd
> > > [ 880.867398] usb 1-4: device descriptor read/64, error -110
> > > [ 881.175558] usb 1-4: New USB device found, idVendor=1199, idProduct=a001
> > > [ 881.175563] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > > [ 881.175566] usb 1-4: Product: Sierra Wireless EM7345 4G LTE
> > > [ 881.175568] usb 1-4: Manufacturer: Sierra Wireless Inc.
> > > [ 881.175570] usb 1-4: SerialNumber: 013937002544516
> > >
> > > Any guess what might be behind this?
> >
> > Any chance you can run 'git bisect' to find the offending commit for
> > this issue?
>
> It's 662591461c4b9a1e3b9b159dbf37648a585ebaae. To my eyes, it even
> looks plausible that it's causing the problematic behaviour, but
> since I can't say I understand what I'd be doing if I dabbled with
> the change, I've refrained from guessing how to fix it.
>
> I'm happy to try patches, though.
Ok, thanks. I've added the authors of this patch to the email here,
perhaps they have an idea of what is going on?
greg k-h
commit 9862b43624 upstream
There has been a race condition identified with initialization of the dell-laptop
driver due to changes in 4.15. This commit has been shown to resolve the race
condition.
I'd like to see this brought back to 4.15 stable. It doesn't apply to anything earlier.
Thanks,
This reverts commit dbac5d07d13e330e6706813c9fde477140fb5d80.
commit dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")
along with commit b5801212229f ("usb: musb: host: clear rxcsr error bit if set")
try to solve the issue described in [1], but the latter alone is sufficient,
and the former causes the issue as in [2], so now revert it.
[1] https://marc.info/?l=linux-usb&m=146173995117456&w=2
[2] https://marc.info/?l=linux-usb&m=151689238420622&w=2
Signed-off-by: Bin Liu <b-liu(a)ti.com>
---
drivers/usb/musb/musb_host.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 394b4ac86161..45ed32c2cba9 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -391,13 +391,7 @@ static void musb_advance_schedule(struct musb *musb, struct urb *urb,
}
}
- /*
- * The pipe must be broken if current urb->status is set, so don't
- * start next urb.
- * TODO: to minimize the risk of regression, only check urb->status
- * for RX, until we have a test case to understand the behavior of TX.
- */
- if ((!status || !is_in) && qh && qh->is_ready) {
+ if (qh != NULL && qh->is_ready) {
musb_dbg(musb, "... next ep%d %cX urb %p",
hw_ep->epnum, is_in ? 'R' : 'T', next_urb(qh));
musb_start_urb(musb, is_in, qh);
--
1.9.1
The patch titled
Subject: mm, swap, frontswap: Fix THP swap if frontswap enabled
has been added to the -mm tree. Its filename is
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-frontswap-fix-thp-swap-if-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-swap-frontswap-fix-thp-swap-if-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Subject: mm, swap, frontswap: Fix THP swap if frontswap enabled
It was reported by Sergey Senozhatsky that if THP (Transparent Huge Page)
and frontswap (via zswap) are both enabled, when memory goes low so that
swap is triggered, segfault and memory corruption will occur in random
user space applications as follow,
kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
#0 0x00007fc08889ae0d _int_malloc (libc.so.6)
#1 0x00007fc08889c2f3 malloc (libc.so.6)
#2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
#3 0x0000560e6005e75c n/a (urxvt)
#4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
#5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
#6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
#7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
#8 0x0000560e6005cb55 ev_run (urxvt)
#9 0x0000560e6003b9b9 main (urxvt)
#10 0x00007fc08883af4a __libc_start_main (libc.so.6)
#11 0x0000560e6003f9da _start (urxvt)
After bisection, it was found the first bad commit is bd4c82c22c367e068
("mm, THP, swap: delay splitting THP after swapped out").
The root cause is as follows:
When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages instead
to improve the performance. But zswap (frontswap) will treat THP as
normal page, so only the head page is saved. After swapping in, tail
pages will not be restored to its original contents, so cause the memory
corruption in the applications.
This is fixed via splitting THP before writing the page to swap device if
frontswap is enabled. To deal with the situation where frontswap is
enabled at runtime, whether the page is THP is checked before using
frontswap during swapping out too.
Link: http://lkml.kernel.org/r/20180207070035.30302-1-ying.huang@intel.com
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Dan Streetman <ddstreet(a)ieee.org>
Cc: Seth Jennings <sjenning(a)redhat.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Shaohua Li <shli(a)kernel.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.14+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_io.c | 2 +-
mm/swapfile.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff -puN mm/page_io.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled mm/page_io.c
--- a/mm/page_io.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled
+++ a/mm/page_io.c
@@ -250,7 +250,7 @@ int swap_writepage(struct page *page, st
unlock_page(page);
goto out;
}
- if (frontswap_store(page) == 0) {
+ if (!PageTransHuge(page) && frontswap_store(page) == 0) {
set_page_writeback(page);
unlock_page(page);
end_page_writeback(page);
diff -puN mm/swapfile.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled mm/swapfile.c
--- a/mm/swapfile.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled
+++ a/mm/swapfile.c
@@ -934,6 +934,9 @@ int get_swap_pages(int n_goal, bool clus
/* Only single cluster request supported */
WARN_ON_ONCE(n_goal > 1 && cluster);
+ /* Frontswap doesn't support THP */
+ if (frontswap_enabled() && cluster)
+ goto noswap;
avail_pgs = atomic_long_read(&nr_swap_pages) / nr_pages;
if (avail_pgs <= 0)
_
Patches currently in -mm which might be from huang.ying.caritas(a)gmail.com are
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch
fontswap-thp-fix.patch