<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/s390, branch v4.14.263</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-11-26T10:40:37+00:00</updated>
<entry>
<title>s390/cio: check the subchannel validity for dev_busid</title>
<updated>2021-11-26T10:40:37+00:00</updated>
<author>
<name>Vineeth Vijayan</name>
<email>vneethv@linux.ibm.com</email>
</author>
<published>2021-11-05T15:44:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b3d54a8ad509543fbed0998c5a0dc948f3b098c0'/>
<id>urn:sha1:b3d54a8ad509543fbed0998c5a0dc948f3b098c0</id>
<content type='text'>
commit a4751f157c194431fae9e9c493f456df8272b871 upstream.

Check the validity of subchanel before reading other fields in
the schib.

Fixes: d3683c055212 ("s390/cio: add dev_busid sysfs entry for each subchannel")
CC: &lt;stable@vger.kernel.org&gt;
Reported-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Signed-off-by: Vineeth Vijayan &lt;vneethv@linux.ibm.com&gt;
Reviewed-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Link: https://lore.kernel.org/r/20211105154451.847288-1-vneethv@linux.ibm.com
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>s390/cio: add dev_busid sysfs entry for each subchannel</title>
<updated>2021-09-22T09:45:18+00:00</updated>
<author>
<name>Vineeth Vijayan</name>
<email>vneethv@linux.ibm.com</email>
</author>
<published>2021-04-25T08:52:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=93a562afc96798ba8de2e020ff06825c0dcd1480'/>
<id>urn:sha1:93a562afc96798ba8de2e020ff06825c0dcd1480</id>
<content type='text'>
[ Upstream commit d3683c055212bf910d4e318f7944910ce10dbee6 ]

Introduce dev_busid, which exports the device-id associated with the
io-subchannel (and message-subchannel). The dev_busid indicates that of
the device which may be physically installed on the corrosponding
subchannel. The dev_busid value "none" indicates that the subchannel
is not valid, there is no I/O device currently associated with the
subchannel.

The dev_busid information would be helpful to write device-specific
udev-rules associated with the subchannel. The dev_busid interface would
be available even when the sch is not bound to any driver or if there is
no operational device connected on it. Hence this attribute can be used to
write udev-rules which are specific to the device associated with the
subchannel.

Signed-off-by: Vineeth Vijayan &lt;vneethv@linux.ibm.com&gt;
Reviewed-by: Peter Oberparleiter &lt;oberpar@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/sclp_vt220: fix console name to match device</title>
<updated>2021-07-20T14:17:50+00:00</updated>
<author>
<name>Valentin Vidic</name>
<email>vvidic@valentin-vidic.from.hr</email>
</author>
<published>2021-04-27T19:40:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b359cb3d33ae0080937d1b6f5e5cd1e8ab27dc06'/>
<id>urn:sha1:b359cb3d33ae0080937d1b6f5e5cd1e8ab27dc06</id>
<content type='text'>
[ Upstream commit b7d91d230a119fdcc334d10c9889ce9c5e15118b ]

Console name reported in /proc/consoles:

  ttyS1                -W- (EC p  )    4:65

does not match the char device name:

  crw--w----    1 root     root        4,  65 May 17 12:18 /dev/ttysclp0

so debian-installer inside a QEMU s390x instance gets confused and fails
to start with the following error:

  steal-ctty: No such file or directory

Signed-off-by: Valentin Vidic &lt;vvidic@valentin-vidic.from.hr&gt;
Link: https://lore.kernel.org/r/20210427194010.9330-1-vvidic@valentin-vidic.from.hr
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/cio: dont call css_wait_for_slow_path() inside a lock</title>
<updated>2021-07-20T14:17:29+00:00</updated>
<author>
<name>Vineeth Vijayan</name>
<email>vneethv@linux.ibm.com</email>
</author>
<published>2021-06-09T07:21:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1f85e7a002d1f91761d917b74848dd405f4cdacc'/>
<id>urn:sha1:1f85e7a002d1f91761d917b74848dd405f4cdacc</id>
<content type='text'>
commit c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 upstream.

Currently css_wait_for_slow_path() gets called inside the chp-&gt;lock.
The path-verification-loop of slowpath inside this lock could lead to
deadlock as reported by the lockdep validator.

The ccw_device_get_chp_desc() during the instance of a device-set-online
would try to acquire the same 'chp-&gt;lock' to read the chp-&gt;desc.
The instance of this function can get called from multiple scenario,
like probing or setting-device online manually. This could, in some
corner-cases lead to the deadlock.

lockdep validator reported this as,

        CPU0                    CPU1
        ----                    ----
   lock(&amp;chp-&gt;lock);
                                lock(kn-&gt;active#43);
                                lock(&amp;chp-&gt;lock);
   lock((wq_completion)cio);

The chp-&gt;lock was introduced to serialize the access of struct
channel_path. This lock is not needed for the css_wait_for_slow_path()
function, so invoke the slow-path function outside this lock.

Fixes: b730f3a93395 ("[S390] cio: add lock to struct channel_path")
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Peter Oberparleiter &lt;oberpar@linux.ibm.com&gt;
Signed-off-by: Vineeth Vijayan &lt;vneethv@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/dasd: fix hanging IO request during DASD driver unbind</title>
<updated>2021-03-17T15:34:31+00:00</updated>
<author>
<name>Stefan Haberland</name>
<email>sth@linux.ibm.com</email>
</author>
<published>2021-03-05T12:54:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8ce9c0b414ed1a95734cb2489587f5ffd38cd554'/>
<id>urn:sha1:8ce9c0b414ed1a95734cb2489587f5ffd38cd554</id>
<content type='text'>
commit 66f669a272898feb1c69b770e1504aa2ec7723d1 upstream.

Prevent that an IO request is build during device shutdown initiated by
a driver unbind. This request will never be able to be processed or
canceled and will hang forever. This will lead also to a hanging unbind.

Fix by checking not only if the device is in READY state but also check
that there is no device offline initiated before building a new IO request.

Fixes: e443343e509a ("s390/dasd: blk-mq conversion")

Cc: &lt;stable@vger.kernel.org&gt; # v4.14+
Signed-off-by: Stefan Haberland &lt;sth@linux.ibm.com&gt;
Tested-by: Bjoern Walk &lt;bwalk@linux.ibm.com&gt;
Reviewed-by: Jan Hoeppner &lt;hoeppner@linux.ibm.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>s390/dasd: fix hanging DASD driver unbind</title>
<updated>2021-03-17T15:34:31+00:00</updated>
<author>
<name>Stefan Haberland</name>
<email>sth@linux.ibm.com</email>
</author>
<published>2021-03-05T12:54:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3bf1f5e9d776b4840dc9db315c8a02c46cb019f9'/>
<id>urn:sha1:3bf1f5e9d776b4840dc9db315c8a02c46cb019f9</id>
<content type='text'>
commit 7d365bd0bff3c0310c39ebaffc9a8458e036d666 upstream.

In case of an unbind of the DASD device driver the function
dasd_generic_remove() is called which shuts down the device.
Among others this functions removes the int_handler from the cdev.
During shutdown the device cancels all outstanding IO requests and waits
for completion of the clear request.
Unfortunately the clear interrupt will never be received when there is no
interrupt handler connected.

Fix by moving the int_handler removal after the call to the state machine
where no request or interrupt is outstanding.

Cc: stable@vger.kernel.org
Signed-off-by: Stefan Haberland &lt;sth@linux.ibm.com&gt;
Tested-by: Bjoern Walk &lt;bwalk@linux.ibm.com&gt;
Reviewed-by: Jan Hoeppner &lt;hoeppner@linux.ibm.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>s390/cio: return -EFAULT if copy_to_user() fails</title>
<updated>2021-03-17T15:34:30+00:00</updated>
<author>
<name>Eric Farman</name>
<email>farman@linux.ibm.com</email>
</author>
<published>2021-03-01T18:33:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ce8235bcf1f77d9a7d7467163d184062c64e3417'/>
<id>urn:sha1:ce8235bcf1f77d9a7d7467163d184062c64e3417</id>
<content type='text'>
commit d9c48a948d29bcb22f4fe61a81b718ef6de561a0 upstream.

Fixes: 120e214e504f ("vfio: ccw: realize VFIO_DEVICE_G(S)ET_IRQ_INFO ioctls")
Signed-off-by: Eric Farman &lt;farman@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>s390/cio: return -EFAULT if copy_to_user() fails again</title>
<updated>2021-03-17T15:34:29+00:00</updated>
<author>
<name>Wang Qing</name>
<email>wangqing@vivo.com</email>
</author>
<published>2021-03-01T12:01:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=87515f38983d913cf196f0fadf2bef7f9dd4f84e'/>
<id>urn:sha1:87515f38983d913cf196f0fadf2bef7f9dd4f84e</id>
<content type='text'>
commit 51c44babdc19aaf882e1213325a0ba291573308f upstream.

The copy_to_user() function returns the number of bytes remaining to be
copied, but we want to return -EFAULT if the copy doesn't complete.

Fixes: e01bcdd61320 ("vfio: ccw: realize VFIO_DEVICE_GET_REGION_INFO ioctl")
Signed-off-by: Wang Qing &lt;wangqing@vivo.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/1614600093-13992-1-git-send-email-wangqing@vivo.com
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>virtio/s390: implement virtio-ccw revision 2 correctly</title>
<updated>2021-03-07T10:27:42+00:00</updated>
<author>
<name>Cornelia Huck</name>
<email>cohuck@redhat.com</email>
</author>
<published>2021-02-16T11:06:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bed4b4569ce69f573a794b9400993835f5110fad'/>
<id>urn:sha1:bed4b4569ce69f573a794b9400993835f5110fad</id>
<content type='text'>
commit 182f709c5cff683e6732d04c78e328de0532284f upstream.

CCW_CMD_READ_STATUS was introduced with revision 2 of virtio-ccw,
and drivers should only rely on it being implemented when they
negotiated at least that revision with the device.

However, virtio_ccw_get_status() issued READ_STATUS for any
device operating at least at revision 1. If the device accepts
READ_STATUS regardless of the negotiated revision (which some
implementations like QEMU do, even though the spec currently does
not allow it), everything works as intended. While a device
rejecting the command should also be handled gracefully, we will
not be able to see any changes the device makes to the status,
such as setting NEEDS_RESET or setting the status to zero after
a completed reset.

We negotiated the revision to at most 1, as we never bumped the
maximum revision; let's do that now and properly send READ_STATUS
only if we are operating at least at revision 2.

Cc: stable@vger.kernel.org
Fixes: 7d3ce5ab9430 ("virtio/s390: support READ_STATUS command for virtio-ccw")
Reviewed-by: Halil Pasic &lt;pasic@linux.ibm.com&gt;
Signed-off-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20210216110645.1087321-1-cohuck@redhat.com
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/dasd: fix hanging device offline processing</title>
<updated>2021-01-09T12:37:37+00:00</updated>
<author>
<name>Stefan Haberland</name>
<email>sth@linux.ibm.com</email>
</author>
<published>2020-12-17T15:59:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=80a49c5756911d0c3ca3177225ae917697de4326'/>
<id>urn:sha1:80a49c5756911d0c3ca3177225ae917697de4326</id>
<content type='text'>
[ Upstream commit 658a337a606f48b7ebe451591f7681d383fa115e ]

For an LCU update a read unit address configuration IO is required.
This is started using sleep_on(), which has early exit paths in case the
device is not usable for IO. For example when it is in offline processing.

In those cases the LCU update should fail and not be retried.
Therefore lcu_update_work checks if EOPNOTSUPP is returned or not.

Commit 41995342b40c ("s390/dasd: fix endless loop after read unit address configuration")
accidentally removed the EOPNOTSUPP return code from
read_unit_address_configuration(), which in turn might lead to an endless
loop of the LCU update in offline processing.

Fix by returning EOPNOTSUPP again if the device is not able to perform the
request.

Fixes: 41995342b40c ("s390/dasd: fix endless loop after read unit address configuration")
Cc: stable@vger.kernel.org #5.3
Signed-off-by: Stefan Haberland &lt;sth@linux.ibm.com&gt;
Reviewed-by: Jan Hoeppner &lt;hoeppner@linux.ibm.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
