hvcs vterm driver doesn't cleanup it's tty kref allocation on close

[bugproxy]

== Comment: #0 - Amartey S. Pearson <email address hidden> - 2015-04-08 16:07:04 ==
---Problem Description---
hvcs vterm driver doesn't cleanup it's tty kref allocation on close

As a result, if the vterm device is used, closed, then hot-plug removed, the original device (/dev/hvcsX) will never be re-used as the .destruct method never gets called.

In the hvcs_close method, it should call tty_port_put. This in theory would get handled by the _cleanup method, but the _close method nulls the tty->driver_data, therefore making the _cleanup method a noop.

I made the following change which fixed the issue for me - allowed .destruct to be called on DLPAR remove of the adapter.

*** hvcs.c 2015-04-08 14:46:44.058208878 -0500
--- hvcs.c.old 2015-04-08 14:45:33.726199732 -0500
***************
*** 1240,1246 ****
    tty->driver_data = NULL;

    free_irq(irq, hvcsd);
- tty_port_put(&hvcsd->port);
    return;
   } else if (hvcsd->port.count < 0) {
    printk(KERN_ERR "HVCS: vty-server@%X open_count: %d"
--- 1240,1245 ----

Contact Information = Amartey Pearson (<email address hidden>), Steven Royer (<email address hidden>)

---uname output---
Linux ip9-114-251-60 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:18:35 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux

Machine Type = 8247-22L

---Debugger---
A debugger is not configured

---Steps to Reproduce---
 1) Create a virtual serial device from the HMC - dynamically (make sure you have rsct etc. installed for DLPAR support). In the example below, we created a device that provides a console to lpar 6.

chhwres -m <SYS_NAME> --id <LPAR_ID> -r virtualio --rsubtype serial -o a -a adapter_type=client,remote_lpar_id=6,remote_slot_num=0

2) From your linux partition, you should now see a console device available. You can use the handy '/sbin/hvcsadmin' tool to see the console.
# hvcsadmin -console 6
vty-server@30000003 partition:6 slot:0 /dev/hvcs0 vterm-state:0

Here we can see that /dev/hvcs0 got used for lpar 6

3) Now open the device. We'll use 'socat' here, but you can use pretty much anything (screen, etc). Once open, hit Ctl+] to exit

socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs0

4) Now check your hvcsadmin -console 6 again. the vterm-state will show 1. Let's close it. and verify it got closed (per the vterm_state)
# hvcsadmin -close /dev/hvcs0
# hvcsadmin -console 6
vty-server@30000003 partition:6 slot:0 /dev/hvcs0 vterm-state:0

5) Now let's remove the device alltogether. Go back to the HMC to do this. Here we will remove slot # 3 (because that's what we created above - hence the 3000000<3> value).

chhwres -m <SYS_NAME> --id <LPAR_ID> -r virtualio --rsubtype serial -o r -s 3

6) Verify you no longer have a console device on your linux lpar...this will not print anything out.
# hvcsadmin -console 6

7) Now go ahead and re-add the device with the same command as you ran in step #1

8) Now let's see what device it allocated. If this were behaving correctly, it would re-allocate /dev/hvcs0, but as you'll see, it allocates /dev/hvcs1 instead.
# hvcsadmin -console 6
vty-server@30000003 partition:6 slot:0 /dev/hvcs1 vterm-state:0

9) You can keep repeating these until you run out of hvcsX devices. Note that if you skipped the 'open' step, and simply removed the device then re-created it, the bug would not occur.

If things are working correctly, you should see the following dmesg output:
[ 5287.993312] HVCS: vty-server@30000003 added to the vio bus.
[ 5287.993326] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added
[ 5393.109677] HVCS: vty-server@30000003 connection opened.
[ 5402.237382] HVCS: Closed vty-server@30000003 and partner vty@30000000:6 connection.
[ 5412.637292] HVCS: Destroyed hvcs_struct for vty-server@30000003. <----- This is missing with the current driver
[ 5412.637298] HVCS: vty-server@30000003 removed from the vio bus.
[ 5412.637355] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 removed
[ 5417.069910] HVCS: vty-server@30000003 added to the vio bus.
[ 5417.069921] rpadlpar_io: slot U8247.22L.2125D7A-V1-C3 added

Stack trace output:
 no

Oops output:
 no

System Dump Info:
  The system is not configured to capture a system dump.

*Additional Instructions for Amartey Pearson (<email address hidden>), Steven Royer (<email address hidden>):
-Attach sysctl -a output output to the bug.

== Comment: #10 - Thierry Fauck <email address hidden> - 2015-11-30 04:55:37 ==

[bugproxy (bugproxy)]

Default Comment by Bridge

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1521123/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Leann Ogasawara (leannogasawara)]

Is this patch being sent upstream? We'd also appreciate the patch to be generated from `git format-patch` such that it contains the relevant commit information/patch description as well as an official signed-off-by from the author. Thanks.

[Tim Gardner (timg-tpi)]

The attached patch in comment #1 does not look right with respect to upstream.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-01-08 17:42 EDT-------
This has not been updated in over two years. Is it still even a problem? For sure, it is not a P1/high bug. Please update or close.