<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/block/bsg.c, branch linux-4.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2018-07-11T14:48:28Z</updated>
<entry>
<title>bsg: fix bogus EINVAL on non-data commands</title>
<updated>2018-07-11T14:48:28Z</updated>
<author>
<name>Tony Battersby</name>
</author>
<published>2018-07-11T14:46:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=70dbcc2254fa2a9add74a122b9dac954c4736e01'/>
<id>urn:sha1:70dbcc2254fa2a9add74a122b9dac954c4736e01</id>
<content type='text'>
Fix a regression introduced in Linux kernel 4.17 where sending a SCSI
command that does not transfer data (such as TEST UNIT READY) via
/dev/bsg/* results in EINVAL.

Fixes: 17cb960f29c2 ("bsg: split handling of SCSI CDBs vs transport requeues")
Cc: &lt;stable@vger.kernel.org&gt; # 4.17+
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Tony Battersby &lt;tonyb@cybernetics.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>bsg: fix race of bsg_open and bsg_unregister</title>
<updated>2018-06-15T14:15:37Z</updated>
<author>
<name>Anatoliy Glagolev</name>
</author>
<published>2018-06-13T21:38:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d6c73964f1e2a07f75057fb32ae46f6599036f93'/>
<id>urn:sha1:d6c73964f1e2a07f75057fb32ae46f6599036f93</id>
<content type='text'>
The existing implementation allows races between bsg_unregister and
bsg_open paths. bsg_unregister and request_queue cleanup and deletion
may start and complete right after bsg_get_device (in bsg_open path)
retrieves bsg_class_device and releases the mutex. Then bsg_open path
touches freed memory of bsg_class_device and request_queue.

One possible fix is to hold the mutex all the way through bsg_get_device
instead of releasing it after bsg_class_device retrieval.

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-Off-By: Anatoliy Glagolev &lt;glagolig@gmail.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>block: remove parent device reference from struct bsg_class_device</title>
<updated>2018-05-29T19:00:25Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2018-05-29T06:40:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5de815a7eedfacf593817ef34634eaa9b75a1482'/>
<id>urn:sha1:5de815a7eedfacf593817ef34634eaa9b75a1482</id>
<content type='text'>
Bsg holding a reference to the parent device may result in a crash if a
bsg file handle is closed after the parent device driver has unloaded.

Holding a reference is not really needed: the parent device must exist
between bsg_register_queue and bsg_unregister_queue.  Before the device
goes away the caller does blk_cleanup_queue so that all in-flight
requests to the device are gone and all new requests cannot pass beyond
the queue.  The queue itself is a refcounted object and it will stay
alive with a bsg file.

Based on analysis, previous patch and changelog from Anatoliy Glagolev.

Reported-by: Anatoliy Glagolev &lt;glagolig@gmail.com&gt;
Reviewed-by: James E.J. Bottomley &lt;jejb@linux.vnet.ibm.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>block: sanitize blk_get_request calling conventions</title>
<updated>2018-05-14T14:55:12Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2018-05-09T07:54:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ff005a066240efb73ae29a2bb9269ae726bc2eae'/>
<id>urn:sha1:ff005a066240efb73ae29a2bb9269ae726bc2eae</id>
<content type='text'>
Switch everyone to blk_get_request_flags, and then rename
blk_get_request_flags to blk_get_request.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>bsg: split handling of SCSI CDBs vs transport requeues</title>
<updated>2018-03-13T17:40:24Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2018-03-13T16:28:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=17cb960f29c29ee07bf6848ada3265f4be55972e'/>
<id>urn:sha1:17cb960f29c29ee07bf6848ada3265f4be55972e</id>
<content type='text'>
The current BSG design tries to shoe-horn the transport-specific
passthrough commands into the overall framework for SCSI passthrough
requests.  This has a couple problems:

 - each passthrough queue has to set the QUEUE_FLAG_SCSI_PASSTHROUGH flag
   despite not dealing with SCSI commands at all.  Because of that these
   queues could also incorrectly accept SCSI commands from in-kernel
   users or through the legacy SCSI_IOCTL_SEND_COMMAND ioctl.
 - the real SCSI bsg queues also incorrectly accept bsg requests of the
   BSG_SUB_PROTOCOL_SCSI_TRANSPORT type
 - the bsg transport code is almost unredable because it tries to reuse
   different SCSI concepts for its own purpose.

This patch instead adds a new bsg_ops structure to handle the two cases
differently, and thus solves all of the above problems.  Another side
effect is that the bsg-lib queues also don't need to embedd a
struct scsi_request anymore.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>vfs: do bulk POLL* -&gt; EPOLL* replacement</title>
<updated>2018-02-11T22:34:03Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2018-02-11T22:34:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a9a08845e9acbd224e4ee466f5c1275ed50054e8'/>
<id>urn:sha1:a9a08845e9acbd224e4ee466f5c1275ed50054e8</id>
<content type='text'>
This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\&lt;POLL$V\&gt;\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.

Scripted-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'misc.poll' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2018-01-31T01:58:07Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2018-01-31T01:58:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=168fe32a072a4b8dc81a3aebf0e5e588d38e2955'/>
<id>urn:sha1:168fe32a072a4b8dc81a3aebf0e5e588d38e2955</id>
<content type='text'>
Pull poll annotations from Al Viro:
 "This introduces a __bitwise type for POLL### bitmap, and propagates
  the annotations through the tree. Most of that stuff is as simple as
  'make -&gt;poll() instances return __poll_t and do the same to local
  variables used to hold the future return value'.

  Some of the obvious brainos found in process are fixed (e.g. POLLIN
  misspelled as POLL_IN). At that point the amount of sparse warnings is
  low and most of them are for genuine bugs - e.g. -&gt;poll() instance
  deciding to return -EINVAL instead of a bitmap. I hadn't touched those
  in this series - it's large enough as it is.

  Another problem it has caught was eventpoll() ABI mess; select.c and
  eventpoll.c assumed that corresponding POLL### and EPOLL### were
  equal. That's true for some, but not all of them - EPOLL### are
  arch-independent, but POLL### are not.

  The last commit in this series separates userland POLL### values from
  the (now arch-independent) kernel-side ones, converting between them
  in the few places where they are copied to/from userland. AFAICS, this
  is the least disruptive fix preserving poll(2) ABI and making epoll()
  work on all architectures.

  As it is, it's simply broken on sparc - try to give it EPOLLWRNORM and
  it will trigger only on what would've triggered EPOLLWRBAND on other
  architectures. EPOLLWRBAND and EPOLLRDHUP, OTOH, are never triggered
  at all on sparc. With this patch they should work consistently on all
  architectures"

* 'misc.poll' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (37 commits)
  make kernel-side POLL... arch-independent
  eventpoll: no need to mask the result of epi_item_poll() again
  eventpoll: constify struct epoll_event pointers
  debugging printk in sg_poll() uses %x to print POLL... bitmap
  annotate poll(2) guts
  9p: untangle -&gt;poll() mess
  -&gt;si_band gets POLL... bitmap stored into a user-visible long field
  ring_buffer_poll_wait() return value used as return value of -&gt;poll()
  the rest of drivers/*: annotate -&gt;poll() instances
  media: annotate -&gt;poll() instances
  fs: annotate -&gt;poll() instances
  ipc, kernel, mm: annotate -&gt;poll() instances
  net: annotate -&gt;poll() instances
  apparmor: annotate -&gt;poll() instances
  tomoyo: annotate -&gt;poll() instances
  sound: annotate -&gt;poll() instances
  acpi: annotate -&gt;poll() instances
  crypto: annotate -&gt;poll() instances
  block: annotate -&gt;poll() instances
  x86: annotate -&gt;poll() instances
  ...
</content>
</entry>
<entry>
<title>bsg: use pr_debug instead of hand crafted macros</title>
<updated>2018-01-24T16:50:06Z</updated>
<author>
<name>Johannes Thumshirn</name>
</author>
<published>2018-01-24T16:50:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3124b65dad946c20feaaf08959ee38ec27361da9'/>
<id>urn:sha1:3124b65dad946c20feaaf08959ee38ec27361da9</id>
<content type='text'>
Use pr_debug instead of hand crafted macros. This way it is not needed to
re-compile the kernel to enable bsg debug outputs and it's possible to
selectively enable specific prints.

Cc: Joe Perches &lt;joe@perches.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>block: annotate -&gt;poll() instances</title>
<updated>2017-11-27T21:20:00Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2017-07-03T03:03:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1771e70a2ea40f01433de656195d85cc7732ead0'/>
<id>urn:sha1:1771e70a2ea40f01433de656195d85cc7732ead0</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>block: pass full fmode_t to blk_verify_command</title>
<updated>2017-11-11T02:53:25Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2017-11-05T07:36:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f00c4d80ffdac9e3a64947ebd57489f3232d5a74'/>
<id>urn:sha1:f00c4d80ffdac9e3a64947ebd57489f3232d5a74</id>
<content type='text'>
Use the obvious calling convention.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
</feed>
