kernel-packages team mailing list archive

[Leann Ogasawara <leann.ogasawara@xxxxxxxxxxxxx>]

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.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1521123

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

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Amartey S. Pearson <apearson@xxxxxxxxxx> - 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 (apearson@xxxxxxxxxx), Steven Royer (seroyer@xxxxxxxxxx) 
   
  ---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 (apearson@xxxxxxxxxx), Steven Royer (seroyer@xxxxxxxxxx): 
  -Attach sysctl -a output output to the bug.

  == Comment: #10 - Thierry Fauck <thierry.fauck@xxxxxxxxxx> -
  2015-11-30 04:55:37 ==

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521123/+subscriptions