--
Jan Kara j...@suse.cz
SUSE Labs, CR
From a7c74ea9375cf0b04a11ac3f00bcd835a8499422 Mon Sep 17 00:00:00 2001
From: Jan Kara j...@suse.cz
Date: Fri, 1 Aug 2014 22:45:32 +0200
Subject: [PATCH] scsi: Keep interrupts disabled while submitting requests
scsi_request_fn() can be called from softirq context
system
shutdown*.
This is scaring me a great deal. Are we doing something different for SSDs
in the scsi-sd or libata shutdown paths?
Nothing I'm aware of but this is more a question for SCSI guys (added to
CC).
Honza
--
Jan
@vger.kernel.org
CC: sta...@vger.kernel.org
Coverity-id: 1226871
Signed-off-by: Jan Kara j...@suse.cz
---
block/scsi_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index abb2e65b24cc..cc7927a1a62e 100644
--- a/block/scsi_ioctl.c
+++ b
Adding relevant people and lists to CC...
Honza
- Forwarded message from Anders Henke [EMAIL PROTECTED] -
Date: Thu, 29 Nov 2007 13:31:50 +0100
From: Anders Henke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject:
CC: linux-scsi@vger.kernel.org
CC: Kai Makisara kai.makis...@kolumbus.fi
Signed-off-by: Jan Kara j...@suse.cz
---
drivers/scsi/st.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
index ff44b3c2cff2..ba11299c3740 100644
On Tue 07-01-14 07:58:30, Christoph Hellwig wrote:
On Mon, Jan 06, 2014 at 09:10:32PM +0100, Jan Kara wrote:
This is likely a problem of Linux direct IO implementation. The thing is
that in Linux when you are doing appending direct IO (i.e., direct IO which
changes file size), the IO
On Thu 09-01-14 12:11:16, Sergey Meirovich wrote:
Hi Jan,
On 8 January 2014 22:55, Jan Kara j...@suse.cz wrote:
So far I've seen so massive degradation only in SAN environment. I
started my investigation with RHEL6.5 kernel so below table is from it
but the trend is the same
On Fri 10-01-14 12:36:22, Sergey Meirovich wrote:
Hi Jan,
On 10 January 2014 11:36, Jan Kara j...@suse.cz wrote:
On Thu 09-01-14 12:11:16, Sergey Meirovich wrote:
...
I've done preallocation on fnic/XtremIO as Christoph suggested.
[root@dca-poc-gtsxdb3 mnt]# sysbench --max-requests=0
with the problems. So
providing some common infrastructure for dealing with blocks larger than
page size would definitely relieve some pain.
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line
? Are do you
think the memory consumption would matter?
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo
On Thu 21-05-15 11:09:55, Kent Overstreet wrote:
On Thu, May 21, 2015 at 06:54:53PM +0200, Jan Kara wrote:
On Wed 20-05-15 18:04:40, Kent Overstreet wrote:
Yeah. I never figured out a sane way to migrate pages and keep
everything
else happy. Daniel Phillips is having a go at page
that checksums the data before and after the IO
and
complains loudly if the checksums don't match. Dunno what we can do for reads.
Thoughts?
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line
the one the disk imposes:
> writes must be sequential.
>
> Granted, this view may be too simplistic and may be overlooking some hard
> to track page locking paths which will compete with this. But I think
> that this can be easily solved by forcing the zone-aligned
> generic_writepages calls to not skip any page (a flag in struct
> writeback_control would do the trick). And no modification is necessary
> on the read side (i.e. page locking only is enough) since reading an SMR
> disks blocks after a zone write-pointer position does not make sense (in
> Hannes code, this is possible, but the request does not go to the disk
> and returns garbage data).
>
> Bottom line: no fundamental change to the page caching mechanism, only
> how it is being used/controlled for writeback makes this work.
> Considering the benefits on the application side, it is in my opinion a
> valid modification to have.
See above, there are quite a few places which will break your assumptions.
And I don't think changing them all to handle SMR is worth it. IMO caching
sequential writes to SMR disks has low effect (if any) anyway so I would
just avoid that. We can talk about how to make this as seamless to
applications as possible. The only thing which I don't think is reasonably
doable without dirtying pagecache are writeable mmaps of an SMR device so
applications would have to avoid that.
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
on does not
expect.
So I would really say just avoid using page-cache when you are using SMR
drives directly without a translation layer. For writes your throughput
won't suffer anyway since you have to do big sequential writes. Using
page-cache for reads may still be beneficial and if you a
> >But you cannot rule out mm subsystem locking a page to do something (e.g.
> >migrate the page to help with compaction of large order pages). These other
> >places accessing and locking pages are what I'm worried about. Furthermore
> >kswapd can decide to writeback particular page
ches your test results. So that is
dealt with. I have no idea about the first issue though.
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
On Tue 18-10-16 14:56:09, Lorenzo Stoakes wrote:
> On Tue, Oct 18, 2016 at 02:54:25PM +0200, Jan Kara wrote:
> > > @@ -1282,7 +1282,7 @@ long get_user_pages(unsigned long start, unsigned
> > > long nr_pages,
> > > int write,
hence
> bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoa...@gmail.com>
The patch looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
> ---
> arch/cris/arch-v32/d
behaviour
> (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoa...@gmail.com>
Looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
> ---
> drivers/gpu/drm/etnaviv/
he mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoa...@gmail.com>
Looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
--
To unsubscribe from this list
guments second but I don't care that much. But it definitely should be
consistent...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoa...@gmail.com>
The patch looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
--
To unsubscribe
ng behaviour
> (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoa...@gmail.com>
Looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
--
Jan Kara <j...@suse.co
behaviour
> (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoa...@gmail.com>
After our discussion the patch looks good to me. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
--
J
remote_vm(NULL, mm, addr, buf, len,
> + write ? FOLL_WRITE : 0);
> }
>
> /*
> @@ -1871,7 +1873,8 @@ int access_process_vm(struct task_struct *tsk, unsigned
> long addr, void *buf, in
> if (!mm)
> return 0;
>
> - len
r (and hence
> bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoa...@gmail.com>
Looks good. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
Honza
> ---
> drivers/gpu/drm/exynos/exynos
s.linux-foundation.org. Is it not active
> anymore?
No sure about the current state but usually it gets populated by the
selected attendees each year.
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
--
To unsubscri
On Sat 07-01-17 21:02:00, Johannes Weiner wrote:
> On Tue, Jan 03, 2017 at 01:28:25PM +0100, Jan Kara wrote:
> > On Mon 02-01-17 16:11:36, Johannes Weiner wrote:
> > > On Fri, Dec 23, 2016 at 03:33:29AM -0500, Johannes Weiner wrote:
> > > > On Fri, Dec 23, 2016 at 02:
ning as well and I gave him a debugging
> patch (attached below), but he hasn't been able to reproduce this
> condition. I've personally never seen the warning trigger, even though
> the patches have been running on my main development machine for quite
> a while now. Albeit against an older base; I've updated to Linus's
> master branch now in case it's an interaction with other new code.
>
> If anybody manages to reproduce this, that would be helpful. Any extra
> eyes on this would be much appreciated too until I'm back at my desk.
I was looking into this but I didn't find a way how we could possibly leave
radix tree node on LRU. So your debug patch looks like a good way forward.
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 09-03-17 09:41:01, Jens Axboe wrote:
> On 03/09/2017 03:16 AM, Jan Kara wrote:
> > Hi!
> >
> > this is a second revision of the series fixing the most urgent bugs that
> > were
> > introduced by commit 165a5e22fafb "block: Move bdi_unregister() to
t;
> On recent 4.10.0+ kernel builds (i386), the resulting kernel would pause
> during the start-up when the USB stick was inserted but boot normally
> otherwise.
>
> A git-bisect lead to:
>
> commit 165a5e22fafb127ecb5914e12e8c32a1f0d3f820
> Author: Jan Kara <j...@suse.c
by: Dan Williams <dan.j.willi...@intel.com>
Signed-off-by: Jan Kara <j...@suse.cz>
---
block/blk-core.c | 2 --
block/genhd.c | 21 -
drivers/scsi/sd.c | 41 -
include/linux/blkdev.h | 1 -
include/linux/gen
<t...@kernel.org>
Signed-off-by: Jan Kara <j...@suse.cz>
---
mm/backing-dev.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index 51325489aae5..b05ace3ba178 100644
--- a/mm/backing-
eturn to the old more robust behavior of just warning when
del_gendisk() gets called for gendisk with disk->queue being NULL.
Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Tested-by: Omar Sandoval <osan...@fb.com>
Acked-by: Tejun Heo <t...@kernel.org>
Signed-off-b
Hi!
this is a second revision of the series fixing the most urgent bugs that were
introduced by commit 165a5e22fafb "block: Move bdi_unregister() to
del_gendisk()" and by 0dba1314d4f8 "scsi, block: fix duplicate bdi name
registration crashes". In fact before these commits we had a different set
EMOVE and use scsi_debug driver to create a
scsi disk which immediately hangs without this fix.
Fixes: 165a5e22fafb127ecb5914e12e8c32a1f0d3f820
Tested-by: Omar Sandoval <osan...@fb.com>
Signed-off-by: Jan Kara <j...@suse.cz>
---
mm/backing-dev.c | 7 +++
1 file changed, 7 insertions(+)
On Wed 08-03-17 17:55:42, Tejun Heo wrote:
> Hello,
>
> On Wed, Mar 08, 2017 at 05:48:31PM +0100, Jan Kara wrote:
> > @@ -710,6 +710,11 @@ static void cgwb_bdi_destroy(struct backing_dev_info
> > *bdi)
> > */
> > atomic_dec(>usage_cnt);
> >
EMOVE and use scsi_debug driver to create a
scsi disk which immediately hangs without this fix.
Fixes: 165a5e22fafb127ecb5914e12e8c32a1f0d3f820
Signed-off-by: Jan Kara <j...@suse.cz>
---
mm/backing-dev.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/mm/backing-dev.c b/mm/
detaching bdi_writeback_congested structures in
bdi_exit() instead of bdi_unregister(). This is also more logical as
they can get attached to bdi regardless whether it ever got registered
or not.
Fixes: 165a5e22fafb127ecb5914e12e8c32a1f0d3f820
Signed-off-by: Jan Kara <j...@suse.cz>
---
mm/ba
the protection provided by this commit is not needed anymore
as the problem it was fixing got also fixed by commit 165a5e22fafb
"block: Move bdi_unregister() to del_gendisk()".
[1]: http://marc.info/?l=linux-block=148554717109098=2
Signed-off-by: Jan Kara <j...@suse.cz>
---
Hi!
patches in this series fix the most urgent bugs that were introduced by commit
165a5e22fafb "block: Move bdi_unregister() to del_gendisk()" and by
0dba1314d4f8 "scsi, block: fix duplicate bdi name registration crashes".
In fact before these commits we had a different set of problems in the
eturn to the old more robust behavior of just warning when
del_gendisk() gets called for gendisk with disk->queue being NULL.
Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Jan Kara <j...@suse.cz>
---
block/genhd.c | 16 ++--
1 file changed, 10 inse
On Mon 06-03-17 06:35:21, James Bottomley wrote:
> On Mon, 2017-03-06 at 13:01 +0100, Jan Kara wrote:
> > On Mon 06-03-17 11:27:33, Jan Kara wrote:
> > > Hi,
> > >
> > > On Sun 05-03-17 10:21:11, Wu Fengguang wrote:
> > > > FYI next-201703
On Mon 06-03-17 07:44:55, James Bottomley wrote:
> On Mon, 2017-03-06 at 16:14 +0100, Jan Kara wrote:
> > On Mon 06-03-17 06:35:21, James Bottomley wrote:
> > > On Mon, 2017-03-06 at 13:01 +0100, Jan Kara wrote:
> > > > On Mon 06-03-17 11:27:33
On Mon 06-03-17 09:25:42, James Bottomley wrote:
> On Mon, 2017-03-06 at 17:13 +0100, Jan Kara wrote:
> > On Mon 06-03-17 07:44:55, James Bottomley wrote:
...
> > > > Sure. The call trace is:
> > > >
> > > > [ 41.919244] [ cut here ]---
On Tue 07-03-17 08:10:29, James Bottomley wrote:
> On Tue, 2017-03-07 at 15:41 +0100, Jan Kara wrote:
> > On Mon 06-03-17 09:25:42, James Bottomley wrote:
> > > On Mon, 2017-03-06 at 17:13 +0100, Jan Kara wrote:
> > > > On Mon 06-03-17 07:44:55, James Bottomley w
On Tue 07-03-17 17:26:56, Jan Kara wrote:
> On Tue 07-03-17 08:10:29, James Bottomley wrote:
> > On Tue, 2017-03-07 at 15:41 +0100, Jan Kara wrote:
> > > On Mon 06-03-17 09:25:42, James Bottomley wrote:
> > > > On Mon, 2017-03-06 at 17:13 +0100, Jan Kara wrote:
>
ted-by: Scott Bauer <scott.ba...@intel.com>
> Fixes: e9c787e65c0c ("scsi: allocate scsi_cmnd structures as part of struct
> request")
> Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
> Cc: Scott Bauer <scott.ba...@intel.com>
> Cc: Chri
are of any particular breakage this would cause. However
logically the freeing of request mempools really belongs to
blk_release_queue() so it seems a bit dumb to move blk_exit_rl() just
because SCSI stores the fact from which slab cache it has allocated the
sense buffer in a structure (shost) that it frees under its hands by the
time blk_release_queue() is called. :-|
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
a consensus and do
> not attempt to address reviewer feedback but instead keep arguing or do what
> they can to insult the reviewer.
Yes, then I think it is up to the maintainer to weight in with his
opinion...
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
reviewed. So
IMO ext4 could use some improvement but I'll leave up to Ted to decide
what's better for ext4.
Honza
--
Jan Kara <j...@suse.com>
SUSE Labs, CR
0 RCX:
> 7fe63d6741f0
> [ 4677.112584] RDX: 0400 RSI: 55b1645c33e8 RDI:
> 000f
> [ 4677.121037] RBP: 55b1645c32b0 R08: 7fe63d65f008 R09:
> 0430
> [ 4677.129489] R10: 55b1645c33d8 R11: 0246 R12:
> 00000
Hello,
On Wed 11-04-18 08:11:13, Jens Axboe wrote:
> On 4/11/18 7:58 AM, Jan Kara wrote:
> > On Tue 10-04-18 11:17:46, Jens Axboe wrote:
> >> Been running some tests and I keep running into issues with hotplug.
> >> This looks similar to what Bart posted the other
seccomp_filter+0x28/0x230
> ? _raw_spin_unlock+0xa/0x20
> ? __handle_mm_fault+0x7d6/0x9b0
> ? list_lru_add+0xa8/0xc0
> ? _raw_spin_unlock+0xa/0x20
> ? __alloc_fd+0xaf/0x160
> ? do_sys_open+0x1a6/0x230
> do_sys_open+0x1a6/0x230
> do_syscall_6
54 matches
Mail list logo
