On Tue, Apr 16, 2019 at 02:56:36PM -0400, tedheadster wrote:
> Hannes,
> I am getting this panic with an Adaptec AHA-2740/2742 controller on
> the 5.0.5 kernel (and earlier). I can gladly apply any proposed
> patches and test.
Please try this patch:
---
>From a6be529620a554b4f4e7ea18c0a08eff706
Now freeing hw queue resource is moved to hctx's release handler,
we don't need to worry about the race between blk_cleanup_queue and
run queue any more.
So don't drain in-progress dispatch in blk_cleanup_queue().
This is basically revert of c2856ae2f315 ("blk-mq: quiesce queue before
freeing que
hctx is always released after requeue is freed.
With holding queue's kobject refcount, it is safe for driver to run queue,
so one run queue might be scheduled after blk_sync_queue() is done.
So moving the cancel of hctx->run_work into blk_mq_hw_sysfs_release()
for avoiding run released queue.
Cc
Hennes reported the following kernel oops:
There is a race condition between namespace rescanning and
controller reset; during controller reset all namespaces are
quiesed vie nams_stop_ctrl(), and after reset all namespaces
are unquiesced again.
When namespace scanning was acti
Just like aio/io_uring, we need to grab 2 refcount for queuing one
request, one is for submission, another is for completion.
If the request isn't queued from plug code path, the refcount grabbed
in generic_make_request() serves for submission. In theroy, this
refcount should have been released af
Split blk_mq_alloc_and_init_hctx into two parts, and one is
blk_mq_alloc_hctx() which is for allocating all hctx resources,
another is blk_mq_init_hctx() which is for initializing hctx, and
serves as counter-part of blk_mq_exit_hctx().
Cc: Dongli Zhang
Cc: James Smart
Cc: Bart Van Assche
Cc: li
With holding queue's kobject refcount, it is safe for driver
to schedule requeue. However, blk_mq_kick_requeue_list() may
be called after blk_sync_queue() is done because of concurrent
requeue activities, then requeue work may not be completed when
freeing queue, and kernel oops is triggered.
So m
In normal queue cleanup path, hctx is released after request queue
is freed, see blk_mq_release().
However, in __blk_mq_update_nr_hw_queues(), hctx may be freed because
of hw queues shrinking. This way is easy to cause use-after-free,
because: one implicit rule is that it is safe to call almost al
Move all hctx related allocation and initialization into
__blk_mq_alloc_and_init_hctx, and prepare for splitting
blk_mq_alloc_and_init_hctx
into real two functions, one is for allocate everything, and another is for
initializing everyting.
Cc: Dongli Zhang
Cc: James Smart
Cc: Bart Van Assche
C
Hi,
Since 45a9c9d909b2 ("blk-mq: Fix a use-after-free"), run queue isn't
allowed during cleanup queue even though queue refcount is held.
This change has caused lots of kernel oops triggered in run queue path,
turns out it isn't easy to fix them all.
So move freeing of hw queue resources into hc
Once blk_cleanup_queue() returns, tags shouldn't be used any more,
because blk_mq_free_tag_set() may be called. Commit 45a9c9d909b2
("blk-mq: Fix a use-after-free") fixes this issue exactly.
However, that commit introduces another issue. Before 45a9c9d909b2,
we are allowed to run queue during clea
On 2019-04-16 4:19 p.m., Arnd Bergmann wrote:
Hi Al,
It took me way longer than I had hoped to revisit this series, see
https://lore.kernel.org/lkml/20180912150142.157913-1-a...@arndb.de/
for the previously posted version.
I've come to the point where all conversion handlers and most
COMPATIBLE
The .ioctl and .compat_ioctl file operations have the same prototype so
they can both point to the same function, which works great almost all
the time when all the commands are compatible.
One exception is the s390 architecture, where a compat pointer is only
31 bit wide, and converting it into a
MTIOCPOS and MTIOCGET are incompatible between 32-bit and 64-bit user
space, and traditionally have been translated in fs/compat_ioctl.c.
To get rid of that translation handler, move a corresponding
implementation into each of the four drivers implementing those commands.
The interesting part of
A handful of drivers all have a trivial wrapper around their ioctl
handler, but don't call the compat_ptr() conversion function at the
moment. In practice this does not matter, since none of them are used
on the s390 architecture and for all other architectures, compat_ptr()
does not do anything, b
Hi Al,
It took me way longer than I had hoped to revisit this series, see
https://lore.kernel.org/lkml/20180912150142.157913-1-a...@arndb.de/
for the previously posted version.
I've come to the point where all conversion handlers and most
COMPATIBLE_IOCTL() entries are gone from this file, but fo
Hannes,
I am getting this panic with an Adaptec AHA-2740/2742 controller on
the 5.0.5 kernel (and earlier). I can gladly apply any proposed
patches and test.
- Matthew
[5.813519] eisa 00:00: EISA: Mainboard INT3089 detected
[5.820624] eisa 00:03: EISA: slot 3: ADP7771 detected
[5.83
On Tue, Apr 16, 2019 at 03:06:34PM +0800, Fuqian Huang wrote:
> Outputting kernel addresses will reveal the locations of kernel code
> and data. And there is no need to print the address of a global object
> beiscsi_iscsi_transport in beiscsi_module_init.
> This case is similar to CVE-2018-7273[1]
Outputting kernel addresses will reveal the locations of kernel code
and data. And there is no need to print the address of a global object
beiscsi_iscsi_transport in beiscsi_module_init.
This case is similar to CVE-2018-7273[1].
Just remove the print statement.
[1] https://cve.mitre.org/cgi-bin/
19 matches
Mail list logo
