On Thu, Jun 06, 2019 at 08:02:07AM +0200, Hannes Reinecke wrote:
> > scsi_change_queue_depth(sdev, device_qd);
> >
> What happened to the NOMERGES queue flag?
Quote from the patch description:
"Also remove the bogus nomerges flag, merges do take the virt_boundary
into account."
On Wed, Jun 05, 2019 at 05:22:35PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 05, 2019 at 09:08:31PM +0200, Christoph Hellwig wrote:
> > This ensures all proper DMA layer handling is taken care of by the
> > SCSI midlayer.
>
> Maybe not entirely related to this series, but it looks like the SCSI
On 6/5/19 9:08 PM, Christoph Hellwig wrote:
> This ensures all proper DMA layer handling is taken care of by the
> SCSI midlayer. Note that the effect is global, as the IOMMU merging
> is based off a paramters in struct device. We could still turn if off
> if no PCIe devices are present, but I do
The xfs patch (xfs: serialize unaligned dio writes against all other dio
writes) does fix the data corruption bug of kernel 4.19 on xfs.
As for 3110fc79606f ("blk-mq: improve plug list sorting"), it happens to fix
the logic error of the sort function in the block layer and it is based on the
mul
This ensures all proper DMA layer handling is taken care of by the
SCSI midlayer.
Maybe not entirely related to this series, but it looks like the SCSI
layer is changing the device global dma_set_max_seg_size() - at least
in RDMA the dma device is being shared between many users, so we
really
We introduce blk-crypto, which manages programming keyslots for struct
bios. With blk-crypto, filesystems only need to call bio_crypt_set_ctx with
the encryption key, algorithm and data_unit_num; they don't have to worry
about getting a keyslot for each encryption context, as blk-crypto handles
tha
Introduce functions to manipulate UFS inline encryption hardware
in line with the JEDEC UFSHCI v2.1 specification and to work with the
block keyslot manager.
Signed-off-by: Satya Tangirala
---
drivers/scsi/ufs/Kconfig | 10 +
drivers/scsi/ufs/Makefile| 1 +
drivers/scsi/ufs/uf
Wire up ufshcd.c with the UFS Crypto API, the block layer inline
encryption additions and the keyslot manager.
Signed-off-by: Satya Tangirala
---
drivers/scsi/ufs/ufshcd.c | 84 ---
drivers/scsi/ufs/ufshcd.h | 18 +
2 files changed, 97 insertions(+), 5
Inline Encryption hardware allows software to specify an encryption context
(an encryption key, crypto algorithm, data unit num, data unit size, etc.)
along with a data transfer request to a storage device, and the inline
encryption hardware will use that context to en/decrypt the data. The
inline
Introduce fscrypt_set_bio_crypt_ctx for filesystems to call to set up
encryption contexts in bios, and fscrypt_evict_crypt_key to evict
the encryption context associated with an inode.
Inline encryption is controlled by a policy flag in the fscrypt_info
in the inode, and filesystems may check if a
Signed-off-by: Satya Tangirala
---
fs/f2fs/data.c | 77 ++---
fs/f2fs/super.c | 1 +
2 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index eda4181d2092..25e691947fb4 100644
--- a/fs/f2fs/data.c
+++ b/fs/
Add the crypto registers and structs defined in v2.1 of the JEDEC UFSHCI
specification in preparation to add support for inline encryption to
UFS.
Signed-off-by: Satya Tangirala
---
drivers/scsi/ufs/ufshcd.h | 5 +++
drivers/scsi/ufs/ufshci.h | 67 +--
2 file
This patch series adds support for Inline Encryption to the block layer,
UFS, fscrypt and f2fs.
Inline Encryption hardware allows software to specify an encryption context
(an encryption key, crypto algorithm, data unit num, data unit size, etc.)
along with a data transfer request to a storage dev
We must have some way of letting a storage device driver know what
encryption context it should use for en/decrypting a request. However,
it's the filesystem/fscrypt that knows about and manages encryption
contexts. As such, when the filesystem layer submits a bio to the block
layer, and this bio e
On 19/6/5 21:57, Brian Foster wrote:
> On Wed, Jun 05, 2019 at 02:42:27PM +0200, gregkh wrote:
>> On Wed, Jun 05, 2019 at 08:21:44PM +0800, Alvin Zheng wrote:
>>> Hi,
>>> I was using kernel v4.19.48 and found that it cannot pass the generic/538
>>> on xfs. The error output is as follows:
>>
>
On Fri, May 31, 2019 at 10:59:12AM +0900, Shin'ichiro Kawasaki wrote:
> As a preparation for the zone mapping test case, add several helper
> functions. _find_last_sequential_zone() and
> _find_sequential_zone_in_middle() help to select test target zones.
> _test_dev_is_logical() checks TEST_DEV is
On Fri, May 31, 2019 at 10:59:13AM +0900, Shin'ichiro Kawasaki wrote:
> Add the test case to check zones sector mapping of logical devices. This
> test case requires that such a logical device be specified in TEST_DEVS
> in config. The test is skipped for devices that are identified as not
> logica
Casey Schaufler wrote:
> Right. You're mixing the kind of things that can generate events,
> and that makes having a single policy difficult.
Whilst that's true, the notifications are clearly marked as to type, so it
should be possible to select different policies for different notification
type
On 6/5/19 3:28 PM, Greg KH wrote:
On Wed, Jun 05, 2019 at 02:25:33PM -0400, Stephen Smalley wrote:
On 6/5/19 1:47 PM, Andy Lutomirski wrote:
On Jun 5, 2019, at 10:01 AM, Casey Schaufler wrote:
On 6/5/2019 9:04 AM, Andy Lutomirski wrote:
On Wed, Jun 5, 2019 at 7:51 AM Casey Schaufler wrot
On 05.06.19 18:32, Joe Perches wrote:
Likely change all of these too:
$ git grep -P '\blikely.*IS_ERR'
drivers/net/vxlan.c:if (likely(!IS_ERR(rt))) {
fs/ntfs/lcnalloc.c: if (likely(page && !IS_ERR(page))) {
fs/ntfs/mft.c: if (likely(!IS_ERR(page))) {
fs/ntfs/mft.c: if (likely(!IS_ERR(
On Wed, Jun 05, 2019 at 09:08:31PM +0200, Christoph Hellwig wrote:
> This ensures all proper DMA layer handling is taken care of by the
> SCSI midlayer.
Maybe not entirely related to this series, but it looks like the SCSI
layer is changing the device global dma_set_max_seg_size() - at least
in RD
On Wed, Jun 05, 2019 at 02:25:33PM -0400, Stephen Smalley wrote:
> On 6/5/19 1:47 PM, Andy Lutomirski wrote:
> >
> > > On Jun 5, 2019, at 10:01 AM, Casey Schaufler
> > > wrote:
> > >
> > > > On 6/5/2019 9:04 AM, Andy Lutomirski wrote:
> > > > > On Wed, Jun 5, 2019 at 7:51 AM Casey Schaufler
>
On Wed, Jun 05, 2019 at 01:17:15PM -0600, Jens Axboe wrote:
> Since I'm heading out shortly and since I think this should make
> the next -rc, I'll tentatively queue this up.
The SCSI bits will need a bit more review, and possibly tweaking
fo megaraid and mpt3sas. But they are really independent
On 6/5/19 1:08 PM, Christoph Hellwig wrote:
> Hi Jens,
>
> we've always had a bit of a problem communicating the block layer
> queue limits to the DMA layer, which needs to respect them when
> an IOMMU that could merge segments is used. Unfortunately most
> drivers don't get this right. Oddly en
This ensures all proper DMA layer handling is taken care of by the
SCSI midlayer. Note that the effect is global, as the IOMMU merging
is based off a paramters in struct device. We could still turn if off
if no PCIe devices are present, but I don't know how to find that out.
Also remove the bogu
This ensures all proper DMA layer handling is taken care of by the
SCSI midlayer.
Signed-off-by: Christoph Hellwig
---
drivers/usb/storage/scsiglue.c | 10 --
drivers/usb/storage/usb.c | 10 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/stor
This ensures all proper DMA layer handling is taken care of by the
SCSI midlayer.
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/ulp/iser/iscsi_iser.c | 35 +---
1 file changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
This allows drivers setting it up easily instead of branching out to
block layer calls in slave_alloc, and ensures the upgraded
max_segment_size setting gets picked up by the DMA layer.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/hosts.c | 3 +++
drivers/scsi/scsi_lib.c | 3 ++-
inclu
We need to also mirror the value to the device to ensure IOMMU merging
doesn't undo it, and the SCSI host level parameter will ensure that.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/ufs/ufshcd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd
This ensures all proper DMA layer handling is taken care of by the
SCSI midlayer.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/storvsc_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 8472de1007ff..e
This ensures all proper DMA layer handling is taken care of by the
SCSI midlayer.
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/ulp/srp/ib_srp.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infini
This ensures all proper DMA layer handling is taken care of by the
SCSI midlayer.
Signed-off-by: Christoph Hellwig
---
drivers/usb/storage/uas.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/stor
If we only set the max_segment_size on the queue an IOMMU merge might
create bigger segments again, so limit the IOMMU merges as well.
Signed-off-by: Christoph Hellwig
---
drivers/block/mtip32xx/mtip32xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/d
This ensures all proper DMA layer handling is taken care of by the
SCSI midlayer. Note that the effect is global, as the IOMMU merging
is based off a paramters in struct device. We could still turn if off
if no PCIe devices are present, but I don't know how to find that out.
Also remove the bogu
Hi Jens,
we've always had a bit of a problem communicating the block layer
queue limits to the DMA layer, which needs to respect them when
an IOMMU that could merge segments is used. Unfortunately most
drivers don't get this right. Oddly enough we've been mostly
getting away with it, although la
If we only set the max_segment_size on the queue an IOMMU merge might
create bigger segments again, so limit the IOMMU merges as well.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/core/queue.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/q
NVMe uses PRPs (or optionally unlimited SGLs) for data transfers and
has no specific limit for a single DMA segement. Limiting the size
will cause problems because the block layer assumes PRP-ish devices
using a virt boundary mask don't have a segment limit. And while this
is true, we also really
This driver does never uses dma_map_sg, so the setting is rather
pointless.
Signed-off-by: Christoph Hellwig
---
drivers/block/rsxx/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index de9b2d2f8654..76b73ddf8fd7 100644
--- a/driver
On Wed, 2019-06-05 at 18:24 +, Enrico Weigelt, metux IT consult
wrote:
> On 05.06.19 14:24, Kefeng Wang wrote:
>
> > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> > index b97b479e4f64..1f7127b03490 100644
> > --- a/block/blk-cgroup.c
> > +++ b/block/blk-cgroup.c
> > @@ -881,7 +881,7 @
On 6/5/19 1:47 PM, Andy Lutomirski wrote:
On Jun 5, 2019, at 10:01 AM, Casey Schaufler wrote:
On 6/5/2019 9:04 AM, Andy Lutomirski wrote:
On Wed, Jun 5, 2019 at 7:51 AM Casey Schaufler wrote:
On 6/5/2019 1:41 AM, David Howells wrote:
Casey Schaufler wrote:
I will try to explain the pro
On 05.06.19 14:24, Kefeng Wang wrote:
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index b97b479e4f64..1f7127b03490 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -881,7 +881,7 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct
blkcg_policy *pol,
On 6/5/2019 10:47 AM, Andy Lutomirski wrote:
>> On Jun 5, 2019, at 10:01 AM, Casey Schaufler wrote:
>>
>>> On 6/5/2019 9:04 AM, Andy Lutomirski wrote:
On Wed, Jun 5, 2019 at 7:51 AM Casey Schaufler
wrote:
> On 6/5/2019 1:41 AM, David Howells wrote:
> Casey Schaufler wrote:
>>>
> On Jun 5, 2019, at 10:01 AM, Casey Schaufler wrote:
>
>> On 6/5/2019 9:04 AM, Andy Lutomirski wrote:
>>> On Wed, Jun 5, 2019 at 7:51 AM Casey Schaufler
>>> wrote:
On 6/5/2019 1:41 AM, David Howells wrote:
Casey Schaufler wrote:
> I will try to explain the problem once a
On 6/5/2019 9:56 AM, David Howells wrote:
> Casey Schaufler wrote:
>
>> YES!
> I'm trying to decide if that's fervour or irritation at this point ;-)
I think I finally got the point that the underlying mechanism,
direct or indirect, isn't the issue. It's the end result that
matters. That makes me
Casey Schaufler wrote:
> > But there are problems with not sending the event:
> >
> > (1) B's internal state is then corrupt (or, at least, unknowingly invalid).
>
> Then B is a badly written program.
No. It may have the expectation that it will get events but then it is denied
those events a
On 6/5/2019 9:04 AM, Andy Lutomirski wrote:
> On Wed, Jun 5, 2019 at 7:51 AM Casey Schaufler wrote:
>> On 6/5/2019 1:41 AM, David Howells wrote:
>>> Casey Schaufler wrote:
>>>
I will try to explain the problem once again. If process A
sends a signal (writes information) to process B the
Casey Schaufler wrote:
> YES!
I'm trying to decide if that's fervour or irritation at this point ;-)
> And it would be really great if you put some thought into what
> a rational model would be for UID based controls, too.
I have put some thought into it, but I don't see a single rational mode
On Wed, Jun 5, 2019 at 7:51 AM Casey Schaufler wrote:
>
> On 6/5/2019 1:41 AM, David Howells wrote:
> > Casey Schaufler wrote:
> >
> >> I will try to explain the problem once again. If process A
> >> sends a signal (writes information) to process B the kernel
> >> checks that either process A has
On 6/5/2019 1:41 AM, David Howells wrote:
> Casey Schaufler wrote:
>
>> I will try to explain the problem once again. If process A
>> sends a signal (writes information) to process B the kernel
>> checks that either process A has the same UID as process B
>> or that process A has privilege to over
On 6/5/19 8:24 AM, Kefeng Wang wrote:
> IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag,
> so no need to do that again from its callers. Drop it.
Applied, thanks.
--
Jens Axboe
IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag,
so no need to do that again from its callers. Drop it.
Cc: Jens Axboe
Cc: linux-block@vger.kernel.org
Signed-off-by: Kefeng Wang
---
block/blk-cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-cgr
On 31/05/2019 03:27, Ming Lei wrote:
index 32b8ad3d341b..49d73d979cb3 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2433,6 +2433,11 @@ static bool __blk_mq_alloc_rq_map(struct blk_mq_tag_set
*set, int hctx_idx)
{
int ret = 0;
Hi Ming,
+ if ((set->flags & BLK_MQ_F_HOST_
On Wed, Jun 05, 2019 at 02:42:27PM +0200, gregkh wrote:
> On Wed, Jun 05, 2019 at 08:21:44PM +0800, Alvin Zheng wrote:
> > Hi,
> > I was using kernel v4.19.48 and found that it cannot pass the generic/538
> > on xfs. The error output is as follows:
>
> Has 4.19 ever been able to pass that test?
On Wed, 5 Jun 2019, Christoph Hellwig wrote:
> Actually, it looks like something completely general isn't
> easily doable, not without some major dma API work. Here is what
> should fix nvme, but a few other drivers will need fixes as well:
>
> ---
> From 745541130409bc837a3416300f529b16eded8513
On 6/5/19 12:19 AM, Andy Lutomirski wrote:
On Tue, Jun 4, 2019 at 6:18 PM Stephen Smalley
wrote:
On Tue, Jun 4, 2019 at 4:58 PM Andy Lutomirski wrote:
On Tue, Jun 4, 2019 at 1:39 PM David Howells wrote:
Andy Lutomirski wrote:
Here's a set of patches to add a general variable-length no
Actually, it looks like something completely general isn't
easily doable, not without some major dma API work. Here is what
should fix nvme, but a few other drivers will need fixes as well:
---
>From 745541130409bc837a3416300f529b16eded8513 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date:
On Wed, Jun 05, 2019 at 08:21:44PM +0800, Alvin Zheng wrote:
> Hi,
> I was using kernel v4.19.48 and found that it cannot pass the generic/538
> on xfs. The error output is as follows:
Has 4.19 ever been able to pass that test? If not, I wouldn't worry
about it :)
>
> FSTYP -- xfs
Hi,
I was using kernel v4.19.48 and found that it cannot pass the generic/538 on
xfs. The error output is as follows:
FSTYP -- xfs (non-debug)
PLATFORM -- Linux/x86_64 alinux2-6 4.19.48
MKFS_OPTIONS -- -f -bsize=4096 /dev/vdc
MOUNT_OPTIONS -- /dev/vdc /mnt/testarea/scra
The problem is that we don't communicate the block level max_segment
size to the iommu, and the commit really is just the messenger.
I'll cook up a series to fix this as papering over it in every driver
does not seem sustainable.
Hi,
this warning turned up on s390:
[7.041512] [ cut here ]
[7.041518] DMA-API: nvme :00:00.0: mapping sg segment longer than
device claims to support [len=106496] [max=65536]
[7.041531] WARNING: CPU: 1 PID: 229 at kernel/dma/debug.c:1233
debug_dma_map_sg
Casey Schaufler wrote:
> I will try to explain the problem once again. If process A
> sends a signal (writes information) to process B the kernel
> checks that either process A has the same UID as process B
> or that process A has privilege to override that policy.
> Process B is passive in this
There is a race between mca_reap(), btree_node_free() and journal code
btree_flush_write(), which results very rare and strange deadlock or
panic and are very hard to reproduce.
Let me explain how the race happens. In btree_flush_write() one btree
node with oldest journal pin is selected, then it
Now we have counters for how many times jouranl is reclaimed, how many
times cached dirty btree nodes are flushed, but we don't know how many
jouranl buckets are really reclaimed.
This patch adds reclaimed_journal_buckets into struct cache_set, this
is an increasing only counter, to tell how many
This reverts commit 6268dc2c4703aabfb0b35681be709acf4c2826c6.
This patch depends on commit c4dc2497d50d ("bcache: fix high CPU
occupancy during journal") which is reverted in previous patch. So
revert this one too.
Fixes: 6268dc2c4703 ("bcache: free heap cache_set->flush_btree in
bch_journal_fre
In journal_read_bucket() when setting ja->seq[bucket_index], there might
be potential case that a later non-maximum overwrites a better sequence
number to ja->seq[bucket_index]. This patch adds a check to make sure
that ja->seq[bucket_index] will be only set a new value if it is bigger
then current
There is a race happens in btree_flush_write() which may cause
system hang or panic. This patch set is an effor to fix such race,
and it is also necessary for the jouranl-no-space deadlock fixes.
Any review or comments is welcome.
Thanks in advance.
Coly Li
---
Coly Li (6):
bcache: Revert "b
In struct cache_set, retry_flush_write is added for commit c4dc2497d50d
("bcache: fix high CPU occupancy during journal") which is reverted in
previous patch.
Now it is useless anymore, and this patch removes it from bcache code.
Signed-off-by: Coly Li
---
drivers/md/bcache/bcache.h | 1 -
driv
This reverts commit c4dc2497d50d9c6fb16aa0d07b6a14f3b2adb1e0.
This patch enlarges a race between normal btree flush code path and
flush_btree_write(), which causes deadlock when journal space is
exhausted. Reverts this patch makes the race window from 128 btree
nodes to only 1 btree nodes.
Fixes:
hi，
In case I missed, is it possible to include iostat patch corresponding
to this kernel patch ?
I hadn't make a iostat patch and will make one later.
Regards,
Xiaoguang Wang
On 6/3/19 6:29 PM, Xiaoguang Wang wrote:
Indeed tool iostat's await is not good enough, which is somewhat sketchy
69 matches
Mail list logo
