FWIW, the 3 upstream commits (currently in cifs-next, not in linus) in the series for this bug do not backport cleanly against kernel-3.10.0-1117.el7 which likely means we may need more commits:
9150c3adbf24d77cfba37f03639d4a908ca4ac25 CIFS: Close open handle after interrupted close
7b71843fa7028475b052107664cbe120156a2cfc CIFS: Do not miss cancelled OPEN responses
86a7964be7afaf3df6b64faaa10a7032d2444e51 CIFS: Fix NULL pointer dereference in mid callback

9150c3adbf24d77cfba37f03639d4a908ca4ac25 depends on 97ca1762246d6eeb1b48dff8a179d1a92ce24227
- seems ok to backport

7b71843fa7028475b052107664cbe120156a2cfc may depend on ?? - maybe afe6f65353b64 and 3190b59a050ec and others?

The last commit may be peripheral to this bug, commit 86a7964be7afaf3df6b64faaa10a7032d2444e51 seems to depend on a non-stable patch that is fairly invasive which adds 'cifs_credits':
commit 335b7b62ffb69d18055f2bb6f3a029263a07c735
Author: Pavel Shilovsky <pshilov>
Date:   Wed Jan 16 11:12:41 2019 -0800

    CIFS: Respect reconnect in MTU credits calculations
    
    Every time after a session reconnect we don't need to account for
    credits obtained in previous sessions. Introduce new struct cifs_credits
    which contains both credits value and reconnect instance of the
    time those credits were taken. Modify a routine that add credits
    back to handle the reconnect instance by assuming zero credits
    if the reconnect happened after the credits were obtained and
    before we decided to add them back due to some errors during sending.
    
    This patch fixes the MTU credits cases. The subsequent patch
    will handle non-MTU ones.
    
    Signed-off-by: Pavel Shilovsky <pshilov>
    Signed-off-by: Steve French <stfrench>


I'm not sure how likely this is to make RHEL7.8 given they are just going upstream and given dependencies such as above.  The patches addressing this bug do have stable cc on them though, and are not a huge # of lines.  Possibly it is not without conception they could be fixed up, assuming impact is high enough and no workaround, etc. but Ronnie can say more.

NOTE: If they go into 7.8 we need to make sure they also go into 8.2

Hi,

We are seeing our field reporting customers on RHEL (7.7 and others) who are looking for this fix for RHEL 7 SKUs as well.
Could RedHat team please work on this fix on supported SKUs for RHEL 7 as well?

(In reply to Mayank Thapliyal from comment #8)
> Hi,
> 
> We are seeing our field reporting customers on RHEL (7.7 and others) who are
> looking for this fix for RHEL 7 SKUs as well.

How many customers would you say are affected?  And do you have a specific customer that we might get a case filed, so we can work on a more targetted fix?  If we have at least one customer that is willing to try test kernels it will increase chances we may be able to get something into RHEL7, though there's no guarantees.

At the time of the original assessment, it was thought this issue is very hard to hit, so not many customers would be affected.  If you're seeing something different we may need to dig in further.

> Could RedHat team please work on this fix on supported SKUs for RHEL 7 as
> well?

We had decided against this patchset over a year ago, so to set expectations, it may be unlikely to get fixed in RHEL7.  However, I'm not sure if there's some specific patch or patches possible that can still be appropriate for RHEL7 given the lifecycle.  

We're at a point where many customers are still on RHEL7, but need to start migrating to RHEL8 due to lifecycle.  This bug is just one of many example of something fixed in RHEL8, but unfortunately still exists on RHEL7.

We have at least one big customer (A big European car manufacturer) who is using these VMs on Azure. And then there are smaller 3PP publishers. There might be others as well who might come at a later point in time as they might not be aware of this leak.

(In reply to Mayank Thapliyal from comment #11)
> We have at least one big customer (A big European car manufacturer) who is
> using these VMs on Azure. And then there are smaller 3PP publishers. There
> might be others as well who might come at a later point in time as they
> might not be aware of this leak.

Do you have a current customer that is hitting this problem, and would be willing to use a test kernel and verify the fix?

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days