[RFC v3 0/1] s390/cio: remove uevent suppress

[RFC v3 0/1] s390/cio: remove uevent suppress

[Vineeth Vijayan]

Here is the update on this RFC. Few more tests as mentioned below.

	1. Boot tested EADM subchannel on LPAR
	2. Test on LPARs with custom-kernel, with modified
subchannel-init calls simulating snsid-failed devices.
Also, modified changelog as suggested by Conny

Previous versions:
v2: https://lore.kernel.org/linux-s390/20211027085059.544736-1-vneethv@linux.ibm.com/
v1: https://lore.kernel.org/linux-s390/20201124093407.23189-1-vneethv@linux.ibm.com/	

Vineeth Vijayan (1):
  s390/cio: remove uevent suppress from cio driver

 drivers/s390/cio/chsc_sch.c     |  5 -----
 drivers/s390/cio/css.c          | 19 -------------------
 drivers/s390/cio/device.c       | 18 ------------------
 drivers/s390/cio/eadm_sch.c     |  5 -----
 drivers/s390/cio/vfio_ccw_drv.c |  5 -----
 5 files changed, 52 deletions(-)

-- 
2.25.1

[RFC v3 1/1] s390/cio: remove uevent suppress from cio driver

[Vineeth Vijayan]

commit fa1a8c23eb7d ("s390: cio: Delay uevents for subchannels")
introduced suppression of uevents for a subchannel until after it is
clear that the subchannel would not be unregistered again
immediately. This was done to avoid uevents being generated for I/O
subchannels with no valid device, which can happen on LPAR.

However, this also has some drawbacks: All subchannel drivers need to
manually remove the uevent suppression and generate an ADD uevent as
soon as they are sure that the subchannel will stay around. This misses
out on all uevents that are not the initial ADD uevent that would be
generated while uevents are suppressed; for example, all subchannels
were missing the BIND uevent.

As uevents being generated even for I/O subchannels without an
operational device turned out to be not as bad as missing uevents and
complicating the code flow, let's remove uevent suppression for
subchannel

Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
[cohuck@redhat.com: modified changelog]
---
 drivers/s390/cio/chsc_sch.c     |  5 -----
 drivers/s390/cio/css.c          | 19 -------------------
 drivers/s390/cio/device.c       | 18 ------------------
 drivers/s390/cio/eadm_sch.c     |  5 -----
 drivers/s390/cio/vfio_ccw_drv.c |  5 -----
 5 files changed, 52 deletions(-)

diff --git a/drivers/s390/cio/chsc_sch.c b/drivers/s390/cio/chsc_sch.c
index 684348d82f08..962dfa25a310 100644
--- a/drivers/s390/cio/chsc_sch.c
+++ b/drivers/s390/cio/chsc_sch.c
@@ -91,11 +91,6 @@ static int chsc_subchannel_probe(struct subchannel *sch)
 			 sch->schid.ssid, sch->schid.sch_no, ret);
 		dev_set_drvdata(&sch->dev, NULL);
 		kfree(private);
-	} else {
-		if (dev_get_uevent_suppress(&sch->dev)) {
-			dev_set_uevent_suppress(&sch->dev, 0);
-			kobject_uevent(&sch->dev.kobj, KOBJ_ADD);
-		}
 	}
 	return ret;
 }
diff --git a/drivers/s390/cio/css.c b/drivers/s390/cio/css.c
index ce9e7517430f..fa8293335077 100644
--- a/drivers/s390/cio/css.c
+++ b/drivers/s390/cio/css.c
@@ -470,16 +470,6 @@ int css_register_subchannel(struct subchannel *sch)
 	if (sch->st == SUBCHANNEL_TYPE_IO)
 		sch->dev.type = &io_subchannel_type;
 
-	/*
-	 * We don't want to generate uevents for I/O subchannels that don't
-	 * have a working ccw device behind them since they will be
-	 * unregistered before they can be used anyway, so we delay the add
-	 * uevent until after device recognition was successful.
-	 * Note that we suppress the uevent for all subchannel types;
-	 * the subchannel driver can decide itself when it wants to inform
-	 * userspace of its existence.
-	 */
-	dev_set_uevent_suppress(&sch->dev, 1);
 	css_update_ssd_info(sch);
 	/* make it known to the system */
 	ret = css_sch_device_register(sch);
@@ -488,15 +478,6 @@ int css_register_subchannel(struct subchannel *sch)
 			      sch->schid.ssid, sch->schid.sch_no, ret);
 		return ret;
 	}
-	if (!sch->driver) {
-		/*
-		 * No driver matched. Generate the uevent now so that
-		 * a fitting driver module may be loaded based on the
-		 * modalias.
-		 */
-		dev_set_uevent_suppress(&sch->dev, 0);
-		kobject_uevent(&sch->dev.kobj, KOBJ_ADD);
-	}
 	return ret;
 }
 
diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index 07a17613fab5..74e7d652d34f 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -838,14 +838,6 @@ static void io_subchannel_register(struct ccw_device *cdev)
 		adjust_init_count = 0;
 		goto out;
 	}
-	/*
-	 * Now we know this subchannel will stay, we can throw
-	 * our delayed uevent.
-	 */
-	if (dev_get_uevent_suppress(&sch->dev)) {
-		dev_set_uevent_suppress(&sch->dev, 0);
-		kobject_uevent(&sch->dev.kobj, KOBJ_ADD);
-	}
 	/* make it known to the system */
 	ret = device_add(&cdev->dev);
 	if (ret) {
@@ -1035,16 +1027,6 @@ static int io_subchannel_probe(struct subchannel *sch)
 				      "attributes for subchannel "
 				      "0.%x.%04x (rc=%d)\n",
 				      sch->schid.ssid, sch->schid.sch_no, rc);
-		/*
-		 * The console subchannel already has an associated ccw_device.
-		 * Throw the delayed uevent for the subchannel, register
-		 * the ccw_device and exit.
-		 */
-		if (dev_get_uevent_suppress(&sch->dev)) {
-			/* should always be the case for the console */
-			dev_set_uevent_suppress(&sch->dev, 0);
-			kobject_uevent(&sch->dev.kobj, KOBJ_ADD);
-		}
 		cdev = sch_get_cdev(sch);
 		rc = device_add(&cdev->dev);
 		if (rc) {
diff --git a/drivers/s390/cio/eadm_sch.c b/drivers/s390/cio/eadm_sch.c
index 15bdae5981ca..8b463681a149 100644
--- a/drivers/s390/cio/eadm_sch.c
+++ b/drivers/s390/cio/eadm_sch.c
@@ -243,11 +243,6 @@ static int eadm_subchannel_probe(struct subchannel *sch)
 	spin_lock_irq(&list_lock);
 	list_add(&private->head, &eadm_list);
 	spin_unlock_irq(&list_lock);
-
-	if (dev_get_uevent_suppress(&sch->dev)) {
-		dev_set_uevent_suppress(&sch->dev, 0);
-		kobject_uevent(&sch->dev.kobj, KOBJ_ADD);
-	}
 out:
 	return ret;
 }
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 040742777095..ee182cfb467d 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -244,11 +244,6 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
 	if (ret)
 		goto out_disable;
 
-	if (dev_get_uevent_suppress(&sch->dev)) {
-		dev_set_uevent_suppress(&sch->dev, 0);
-		kobject_uevent(&sch->dev.kobj, KOBJ_ADD);
-	}
-
 	VFIO_CCW_MSG_EVENT(4, "bound to subchannel %x.%x.%04x\n",
 			   sch->schid.cssid, sch->schid.ssid,
 			   sch->schid.sch_no);
-- 
2.25.1

Re: [RFC v3 1/1] s390/cio: remove uevent suppress from cio driver

[Peter Oberparleiter]

On 22.11.2021 11:37, Vineeth Vijayan wrote:
> commit fa1a8c23eb7d ("s390: cio: Delay uevents for subchannels")
> introduced suppression of uevents for a subchannel until after it is
> clear that the subchannel would not be unregistered again
> immediately. This was done to avoid uevents being generated for I/O
> subchannels with no valid device, which can happen on LPAR.
> 
> However, this also has some drawbacks: All subchannel drivers need to
> manually remove the uevent suppression and generate an ADD uevent as
> soon as they are sure that the subchannel will stay around. This misses
> out on all uevents that are not the initial ADD uevent that would be
> generated while uevents are suppressed; for example, all subchannels
> were missing the BIND uevent.
> 
> As uevents being generated even for I/O subchannels without an
> operational device turned out to be not as bad as missing uevents and
> complicating the code flow, let's remove uevent suppression for
> subchannel
> 
> Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
> [cohuck@redhat.com: modified changelog]

Looks good to me!

Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>


Regards,
  Peter

-- 
Peter Oberparleiter
Linux on Z Development - IBM Germany

Re: [RFC v3 1/1] s390/cio: remove uevent suppress from cio driver

[Cornelia Huck]

On Mon, Nov 22 2021, Vineeth Vijayan <vneethv@linux.ibm.com> wrote:

> commit fa1a8c23eb7d ("s390: cio: Delay uevents for subchannels")
> introduced suppression of uevents for a subchannel until after it is
> clear that the subchannel would not be unregistered again
> immediately. This was done to avoid uevents being generated for I/O
> subchannels with no valid device, which can happen on LPAR.
>
> However, this also has some drawbacks: All subchannel drivers need to
> manually remove the uevent suppression and generate an ADD uevent as
> soon as they are sure that the subchannel will stay around. This misses
> out on all uevents that are not the initial ADD uevent that would be
> generated while uevents are suppressed; for example, all subchannels
> were missing the BIND uevent.
>
> As uevents being generated even for I/O subchannels without an
> operational device turned out to be not as bad as missing uevents and
> complicating the code flow, let's remove uevent suppression for
> subchannel

s/subchannel/subchannels./

>
> Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
> [cohuck@redhat.com: modified changelog]
> ---
>  drivers/s390/cio/chsc_sch.c     |  5 -----
>  drivers/s390/cio/css.c          | 19 -------------------
>  drivers/s390/cio/device.c       | 18 ------------------
>  drivers/s390/cio/eadm_sch.c     |  5 -----
>  drivers/s390/cio/vfio_ccw_drv.c |  5 -----
>  5 files changed, 52 deletions(-)

(...)

> @@ -1035,16 +1027,6 @@ static int io_subchannel_probe(struct subchannel *sch)
>  				      "attributes for subchannel "
>  				      "0.%x.%04x (rc=%d)\n",
>  				      sch->schid.ssid, sch->schid.sch_no, rc);
> -		/*
> -		 * The console subchannel already has an associated ccw_device.
> -		 * Throw the delayed uevent for the subchannel, register
> -		 * the ccw_device and exit.

Maybe keep at least part of this comment?

/*
 * The console subchannel already has an associated ccw_device.
 * Register it and exit.
 */

> -		 */
> -		if (dev_get_uevent_suppress(&sch->dev)) {
> -			/* should always be the case for the console */
> -			dev_set_uevent_suppress(&sch->dev, 0);
> -			kobject_uevent(&sch->dev.kobj, KOBJ_ADD);
> -		}
>  		cdev = sch_get_cdev(sch);
>  		rc = device_add(&cdev->dev);
>  		if (rc) {

Otherwise looks good to me.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>