Christoph, Sagi: it seems you think /proc/irq/$IRP/smp_affinity
shouldn't be allowed if drivers support managed affinity. Is that correct?
Not just shouldn't, but simply can't.
But as it stands, things are just plain borked if an rdma driver
supports ib_get_vector_affinity() yet the admin
On Mon, Oct 22, 2018 at 06:50:04AM -0400, Theodore Ts'o wrote:
> A number of kernel modules used by blktests must be compiled as
> modules, since the module needs to be loaded with specific options, or
> part of the test is to exercise what what happens when the kernel
> module is loaded. This is
On Thu, Oct 18, 2018 at 12:31:47PM +0200, Jan Kara wrote:
> Add regression test for patch "block/loop: Use global lock for ioctl()
> operation." where we can oops while traversing list of loop devices
> backing newly created device.
>
> Signed-off-by: Jan Kara
Looks good, sans a missing addition
On Thu, Oct 18, 2018 at 12:31:46PM +0200, Jan Kara wrote:
> Add test for setting partscan flag.
>
> Signed-off-by: Jan Kara
Sorry I didn't notice this earlier, but loop/001 already does a
partition rescan (via losetup -P). Does that cover this test case?
> ---
> src/Makefile
On 10/22/18 1:31 PM, Konrad Rzeszutek Wilk wrote:
>
> Hi Jens,
>
> Please git pull the following branch:
>
> git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> stable/for-jens-4.20
>
> which has exactly one tiny patch fixing an NULL pointer issue (also has
> stable tree C
Hi Jens,
Please git pull the following branch:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.20
which has exactly one tiny patch fixing an NULL pointer issue (also has stable
tree CCed).
Thank you!
drivers/block/xen-blkfront.c | 3 +++
1 file change
Allow the creation of conventional zones by adding the nr_conv_zones
configuration attribute. This new attribute is used only for zoned devices and
indicates the number of conventional zones to create. The default value is 0.
Since host-managed zoned block devices must always have at least one sequ
A number of kernel modules used by blktests must be compiled as
modules, since the module needs to be loaded with specific options, or
part of the test is to exercise what what happens when the kernel
module is loaded. This is not true for the loop driver, so add a new
bash function, _have_kernel_
In current pblk implementation, l2p mapping for not closed lines
is always stored only in OOB metadata and recovered from it.
Such a solution does not provide data integrity when drives does
not have such a OOB metadata space.
The goal of this patch is to add support for so called packed
metadata
Currently pblk assumes that size of OOB metadata on drive is always
equal to size of pblk_sec_meta struct. This commit add helpers which will
allow to handle different sizes of OOB metadata on drive.
Signed-off-by: Igor Konopko
---
drivers/lightnvm/pblk-core.c | 5 +++--
drivers/lightnvm/pb
Currently whole lightnvm and pblk uses single DMA pool,
for which entry size is always equal to PAGE_SIZE.
PPA list always needs 8b*64, so there is only 56b*64
space for OOB meta. Since NVMe OOB meta can be bigger,
such as 128b, this solution is not robustness.
This patch add the possiblity to sup
This series of patches extends the way how pblk can
store L2P sector metadata. After this set of changes
any size of NVMe metadata (including 0) is supported.
Patches are rebased on top of block/for-next since
there was no ocssd/for-4.21 branch yet.
Changes v1 --> v2:
-Revert sector meta size bac
Currently pblk and lightnvm does only check for size
of OOB metadata and does not care wheather this meta
is located in separate buffer or is interleaved with
data in single buffer.
In reality only the first scenario is supported, where
second mode will break pblk functionality during any
IO opera
Currently DMA allocated memory is reused on partial read
for lba_list_mem and lba_list_media arrays. In preparation
for dynamic DMA pool sizes we need to move this arrays
into pblk_pr_ctx structures.
Signed-off-by: Igor Konopko
---
drivers/lightnvm/pblk-read.c | 20 +---
drivers/
On 10/22/18 5:08 PM, Christoph Hellwig wrote:
> On Mon, Oct 22, 2018 at 05:06:02PM +0800, Ming Lei wrote:
>>
>> The above may be changed to 'if (blk_try_merge(req) ==
>> ELEVATOR_DISCARD_MERGE)'
>> or sort of in future, which may has document benefit at least, since
>> ELEVATOR_DISCARD_MERGE me
On 10/22/18 5:00 PM, Christoph Hellwig wrote:
> On Sat, Oct 20, 2018 at 10:29:37PM +0800, Jianchao Wang wrote:
>> There are two cases when handle DISCARD merge
>> - max_discard_segments == 1
>>bios need to be contiguous
>> - max_discard_segments > 1
>>Only nvme right now. It takes ever
On 10/19/18 12:44 PM, Gustavo A. R. Silva wrote:
> Check return values of dma_set_mask_and_coherent().
>
> Otherwise, if dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> fails, the following piece of code will be executed even when the call
> to dma_set_mask_and_coherent(&pdev->dev, DMA_
On Fri, Oct 19, 2018 at 08:44:17PM +0200, Gustavo A. R. Silva wrote:
> Check return values of dma_set_mask_and_coherent().
>
> Otherwise, if dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> fails, the following piece of code will be executed even when the call
> to dma_set_mask_and_coher
On Mon, Oct 22, 2018 at 05:06:02PM +0800, Ming Lei wrote:
>
> The above may be changed to 'if (blk_try_merge(req) ==
> ELEVATOR_DISCARD_MERGE)'
> or sort of in future, which may has document benefit at least, since
> ELEVATOR_DISCARD_MERGE means multi-segment discard merge.
I like that idea, and
On Sat, Oct 20, 2018 at 10:29:37PM +0800, Jianchao Wang wrote:
> There are two cases when handle DISCARD merge
> - max_discard_segments == 1
>bios need to be contiguous
> - max_discard_segments > 1
>Only nvme right now. It takes every bio as a range and different
>range needn't to be
On Sat, Oct 20, 2018 at 10:29:37PM +0800, Jianchao Wang wrote:
> There are two cases when handle DISCARD merge
> - max_discard_segments == 1
>bios need to be contiguous
> - max_discard_segments > 1
>Only nvme right now. It takes every bio as a range and different
>range needn't to be
On 10/19/18 4:59 AM, Paolo Valente wrote:
>
>
>> Il giorno 15 ott 2018, alle ore 20:26, Paolo Valente
>> ha scritto:
>>
>> ...
>>> This kind of policy does not belong in the kernel, at least
>>> not in the current form. If we had some sort of "enable best
>>> options for a desktop" then it coul
On 10/19/18 2:42 AM, Linus Walleij wrote:
> On Wed, Oct 17, 2018 at 4:59 PM Bryan Gurney wrote:
>
>> I feel strongly about the prevention of users running into errors
>> because of an incorrect scheduler default, because I encountered that
>> situation three times in my testing with zoned block d
On 10/19/18 2:22 AM, Pavel Machek wrote:
> Hi!
>
Which is also the approach that I've been advocating for here, instead
of a kernel patch...
>>>
>>> I know you've been advocating the use of udev for IO scheduler selection.
>>> But do you want to force everybody to use udev? And for peopl
Hi Linus,
This is the main pull request for block changes for 4.20. This pull
request contains:
- Series enabling runtime PM for blk-mq (Bart).
- Two pull requests from Christoph for NVMe, with items such as;
- Better AEN tracking
- Multipath improvements
- RDMA fixes
25 matches
Mail list logo
