On 8/14/19 7:30 AM, Max Gurtovoy wrote:
>
> On 8/2/2019 2:45 AM, Logan Gunthorpe wrote:
>> This function will be needed by the upcoming passthru code.
>
> Same here. As a standalone commit I can't take a lot from here.
>
> Maybe should be squashed ?
This commit changes the existing code which i
So, what are we going to do with this series? As said before I'd
volunteer to pick this up through the dma-mapping tree, but I'd like
to see ACKs from the other maintainers as well.
Just clean up the code, no function changes.
Signed-off-by: Jackie Liu
---
fs/io_uring.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index d542f1c..e5d9f3d 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2029,13 +2029,11 @@ static int i
On 8/2/2019 2:45 AM, Logan Gunthorpe wrote:
nvme_ctrl_get_by_path() is analagous to blkdev_get_by_path() except it
gets a struct nvme_ctrl from the path to its char dev (/dev/nvme0).
It makes use of filp_open() to open the file and uses the private
data to obtain a pointer to the struct nvme_ct
Commit bd11b3a391e3 ("io_uring: don't use iov_iter_advance() for fixed
buffers") introduced an optimization to avoid using the slow
iov_iter_advance by manually populating the iov_iter iterator in some
cases.
However, the computation of the iterator count field was erroneous: The
first bvec was al
It is reported that sysfs buffer overflow can be triggered in case
of too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs in
one hctx.
So use snprintf for avoiding the potential buffer overflow.
Cc: sta...@vger.kernel.org
Cc: Mark Ray
Fixes: 676141e48af7("blk-mq: don't dump CPU -> hw queu
On 8/2/2019 2:45 AM, Logan Gunthorpe wrote:
This patch adds helper functions which are used in the NVMeOF configfs
when the user is configuring the passthru subsystem. Here we ensure
that only one subsys is assigned to each nvme_ctrl by using an xarray
on the cntlid.
[chaitanya.kulka...@wdc.co
On Thu, Aug 15, 2019 at 08:15:18PM +0800, Ming Lei wrote:
> It is reported that sysfs buffer overflow can be triggered in case
> of too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs in
> one hctx.
>
> So use snprintf for avoiding the potential buffer overflow.
>
> Cc: sta...@vger.kernel.
On Thu, Aug 15, 2019 at 02:24:19PM +0200, Greg KH wrote:
> On Thu, Aug 15, 2019 at 08:15:18PM +0800, Ming Lei wrote:
> > It is reported that sysfs buffer overflow can be triggered in case
> > of too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs in
> > one hctx.
> >
> > So use snprintf for
On Thu, Aug 15, 2019 at 08:29:10PM +0800, Ming Lei wrote:
> On Thu, Aug 15, 2019 at 02:24:19PM +0200, Greg KH wrote:
> > On Thu, Aug 15, 2019 at 08:15:18PM +0800, Ming Lei wrote:
> > > It is reported that sysfs buffer overflow can be triggered in case
> > > of too many CPU cores(>841 on 4K PAGE_SIZ
On 8/2/2019 2:45 AM, Logan Gunthorpe wrote:
This patch rejects any new connection to the passthru-ctrl if this
controller is already connected to a different host. At the time of
allocating the controller we check if the subsys associated with
the passthru ctrl is already connected to a host an
On Thu, Aug 15, 2019 at 02:35:35PM +0200, Greg KH wrote:
> On Thu, Aug 15, 2019 at 08:29:10PM +0800, Ming Lei wrote:
> > On Thu, Aug 15, 2019 at 02:24:19PM +0200, Greg KH wrote:
> > > On Thu, Aug 15, 2019 at 08:15:18PM +0800, Ming Lei wrote:
> > > > It is reported that sysfs buffer overflow can be
On 8/2/2019 2:45 AM, Logan Gunthorpe wrote:
When CONFIG_NVME_TARGET_PASSTHRU as 'passthru' directory will
be added to each subsystem. The directory is similar to a namespace
and has two attributes: device_path and enable. The user must set the
path to the nvme controller's char device and write
On 14/08/2019 16:08, Keith Busch wrote:
> On Wed, Aug 14, 2019 at 11:29:17AM -0700, Guilherme G. Piccoli wrote:
>> It is a suggestion from my colleague Dan (CCed here), something like:
>> for non-multipath nvme, keep nvmeC and nvmeCnN (C=controller ida,
>> N=namespace); for multipath nvme, use nvme
On Thu, Aug 15, 2019 at 08:43:22PM +0800, Ming Lei wrote:
> On Thu, Aug 15, 2019 at 02:35:35PM +0200, Greg KH wrote:
> > On Thu, Aug 15, 2019 at 08:29:10PM +0800, Ming Lei wrote:
> > > On Thu, Aug 15, 2019 at 02:24:19PM +0200, Greg KH wrote:
> > > > On Thu, Aug 15, 2019 at 08:15:18PM +0800, Ming Le
On Fri 02-08-19 12:07:38, Tejun Heo wrote:
> WB_FRN_TIME_CUT_DIV is used to tell the foreign inode detection logic
> to ignore short writeback rounds to prevent getting confused by a
> burst of short writebacks. The parameter is currently 2 meaning that
> anything smaller than half of the running
On Fri 02-08-19 12:08:13, Tejun Heo wrote:
> As inode wb switching may make sync(2) miss some inodes, they're
> synchronized using wb_switch_rwsem so that no wb switching happens
> while sync(2) is in progress. In addition to synchronizing the actual
> switching, the rwsem is also used to prevent
On Sat 03-08-19 07:01:54, Tejun Heo wrote:
> Implement cgroup_writeback_by_id() which initiates cgroup writeback
> from bdi and memcg IDs. This will be used by memcg foreign inode
> flushing.
>
> Signed-off-by: Tejun Heo
> ---
> fs/fs-writeback.c | 64 +++
On Sat 03-08-19 07:01:55, Tejun Heo wrote:
> +void mem_cgroup_track_foreign_dirty_slowpath(struct page *page,
> + struct bdi_writeback *wb)
> +{
> + struct mem_cgroup *memcg = page->mem_cgroup;
> + struct memcg_cgwb_frn *frn;
> + u64 now = jiffie
On Sat 03-08-19 07:01:52, Tejun Heo wrote:
> wb_completion is used to track writeback completions. We want to use
> it from memcg side for foreign inode flushes. This patch updates it
> to remember the target waitq instead of assuming bdi->wb_waitq and
> expose it outside of fs-writeback.c.
>
>
On Sat 03-08-19 07:01:53, Tejun Heo wrote:
> There currently is no way to universally identify and lookup a bdi
> without holding a reference and pointer to it. This patch adds an
> non-recycling bdi->id and implements bdi_get_by_id() which looks up
> bdis by their ids. This will be used by memcg
On Wed, Aug 14, 2019 at 4:29 PM Bart Van Assche wrote:
> Hi Martijn,
>
> Is the loop driver used in Android Q to make a file on a filesystem
> visible as a block device or rather to make a subset of a block device
> visible as a block device? In the latter case, have you considered to
> use the dm
On Sat 03-08-19 07:01:54, Tejun Heo wrote:
> Implement cgroup_writeback_by_id() which initiates cgroup writeback
> from bdi and memcg IDs. This will be used by memcg foreign inode
> flushing.
>
> Signed-off-by: Tejun Heo
> ---
> fs/fs-writeback.c | 64 +++
On Wed, Aug 14, 2019 at 12:47 PM Ming Lei wrote:
> blk_queue_init_done() is only called in blk_queue_init_done() for
> this purpose, so this approach should be fine, IMO.
I was thinking somebody might add more stuff to "init" in the future,
and then that new stuff would now no longer be executed
On Thu, Aug 15, 2019 at 04:05:35PM +0200, Jan Kara wrote:
> > +int cgroup_writeback_by_id(u64 bdi_id, int memcg_id, unsigned long
> > nr_pages,
> > + enum wb_reason reason, struct wb_completion *done);
> > +int writeback_by_id(int id, unsigned long nr, enum wb_reason reason,
>
On 2019-08-15 5:46 a.m., Max Gurtovoy wrote:
>
> On 8/2/2019 2:45 AM, Logan Gunthorpe wrote:
>> nvme_ctrl_get_by_path() is analagous to blkdev_get_by_path() except it
>> gets a struct nvme_ctrl from the path to its char dev (/dev/nvme0).
>> It makes use of filp_open() to open the file and uses
On 2019-08-15 6:20 a.m., Max Gurtovoy wrote:
>
> On 8/2/2019 2:45 AM, Logan Gunthorpe wrote:
>> This patch adds helper functions which are used in the NVMeOF configfs
>> when the user is configuring the passthru subsystem. Here we ensure
>> that only one subsys is assigned to each nvme_ctrl by
On 2019-08-15 6:36 a.m., Max Gurtovoy wrote:
>
> On 8/2/2019 2:45 AM, Logan Gunthorpe wrote:
>> This patch rejects any new connection to the passthru-ctrl if this
>> controller is already connected to a different host. At the time of
>> allocating the controller we check if the subsys associate
The re-definition error is thrown only when 2 different values are assigned to
the same #define variable.
But in this case, the same value is defined twice... hence the compiler doesn't
throw error.
Thank you :)
Revanth Rajashekar
-Original Message-
From: Scott Bauer [mailto:sba...@plzdo
On Thu, Aug 15, 2019 at 04:54:21PM +0200, Jan Kara wrote:
> > + /* and find the associated wb */
> > + wb = wb_get_create(bdi, memcg_css, GFP_NOWAIT | __GFP_NOWARN);
> > + if (!wb) {
> > + ret = -ENOMEM;
> > + goto out_css_put;
> > + }
>
> One more thought: You don't wa
On Thu, Aug 15, 2019 at 11:38 PM Martijn Coenen wrote:
>
> On Wed, Aug 14, 2019 at 12:47 PM Ming Lei wrote:
> > blk_queue_init_done() is only called in blk_queue_init_done() for
> > this purpose, so this approach should be fine, IMO.
>
> I was thinking somebody might add more stuff to "init" in t
The mvsas driver declares LED_* enums for enum sgpio_led_status. The
LED_OFF and LED_ON enums cause redeclaration of enumerator with the
LED subsystem's LED_OFF and LED_ON enums.
This adds 'SGPIO_' prefix to these enums in mvsas driver.
Cc: Frank Steiner
Cc: Jacek Anaszewski
Cc: Pavel Machek
C
The umem driver defines LED_* macros for MEMCTRLCMD_LEDCTRL register
values. The LED_OFF and LED_ON macros conflict with the LED subsystem's
LED_OFF and LED_ON enums.
This renames these LED_* macros to MEMCTRL_LED_* in umem driver.
Cc: Frank Steiner
Cc: Jacek Anaszewski
Cc: Pavel Machek
Cc: D
This work is inspired by the report on linux-nvme mailing list.
disk-activity trigger not working for nvme disk:
http://lists.infradead.org/pipermail/linux-nvme/2019-July/025253.html
This LED block device activity trigger works with any block devices.
* v4
- Squash patch 'add interface to stop a
The nsp32 driver defines LED_ON and LED_OFF macros for EXT_PORT_DDR or
EXT_PORT register values. The LED_OFF and LED_ON macros conflict with
the LED subsystem's LED_OFF and LED_ON enums.
This renames these LED_* macros to EXT_PORT_LED_* in nsp32 driver.
Cc: Frank Steiner
Cc: Jacek Anaszewski
C
The LED block device activity trigger periodically polls the disk stats
to collect the activity. However, it is pointless to poll while the
scsi device is in runtime suspend.
This stops polling disk stats when the device is successfully runtime
suspended, and restarts polling when the device is s
This allows LEDs to be controlled by block device activity.
We already have ledtrig-disk (LED disk activity trigger), but the lower
level disk drivers need to utilize ledtrig_disk_activity() to make the
LED blink.
The LED block device trigger doesn't require the lower level drivers to
have any in
On 8/14/19 3:35 AM, Jackie Liu wrote:
> Suppose there are three IOs here, and their order is as follows:
>
> Submit:
> [1] IO_LINK
> |
> |--- [2] IO_LINK | IO_DRAIN
> |
> |- [3] NORMAL_IO
>
> In theory, they all need to be inserte
On 8/14/19 3:35 AM, Jackie Liu wrote:
> This patch may fix two issues:
>
> First, when IOSQE_IO_DARIN set, the next IOs need to be inserted into defer
> list to delay execution, but link io will be actively scheduled to run by
> calling io_queue_sqe.
>
> Second, when multiple LINK_IOs are inserte
On 8/15/19 6:03 AM, Aleix Roca Nonell wrote:
> Commit bd11b3a391e3 ("io_uring: don't use iov_iter_advance() for fixed
> buffers") introduced an optimization to avoid using the slow
> iov_iter_advance by manually populating the iov_iter iterator in some
> cases.
>
> However, the computation of the
Pulling this to nvme-5.3-rc
On 8/13/19 9:19 PM, Douglas Gilbert wrote:
Bart Van Assche hinted at a better API design but didn't present
it. If he did, that would be the first time an alternate API
design was presented for async usage in the 20 years that I have
been associated with the driver.
I would like to start from t
Hello, Jan.
On Thu, Aug 15, 2019 at 04:34:04PM +0200, Jan Kara wrote:
> I have to say I'm a bit nervous about the completely lockless handling
> here. I understand that garbage in the cgwb_frn will just result in this
> mechanism not working and possibly flushing wrong wb's but still it seems a
>
Hello,
On Thu, Aug 15, 2019 at 04:46:23PM +0200, Jan Kara wrote:
> Although I would note that here you take effort not to recycle bdi->id so
> that you don't flush wrong devices while in patch 4 you take pretty lax
> approach to feeding garbage into the writeback system. So these two don't
> quite
On 15/08/2019 14:24, Sagi Grimberg wrote:
> Pulling this to nvme-5.3-rc
Thanks Sagi!
On Thu, Aug 15, 2019 at 6:34 PM Ming Lei wrote:
> If nothing will change, why does the userspace bother to send
> SET_STATUS?
We don't change transfer, but we do change the offset and sizelimit.
In our specific case, we know there won't be any I/O from userspace at
this point; so from that point
WB_FRN_TIME_CUT_DIV is used to tell the foreign inode detection logic
to ignore short writeback rounds to prevent getting confused by a
burst of short writebacks. The parameter is currently 2 meaning that
anything smaller than half of the running average writback duration
will be ignored.
This is
On 8/15/19 1:25 PM, Tejun Heo wrote:
> WB_FRN_TIME_CUT_DIV is used to tell the foreign inode detection logic
> to ignore short writeback rounds to prevent getting confused by a
> burst of short writebacks. The parameter is currently 2 meaning that
> anything smaller than half of the running averag
Hello,
Changes from v1[1]:
* More comments explaining the parameters.
* 0003-writeback-Separate-out-wb_get_lookup-from-wb_get_create.patch
added and avoid spuriously creating missing wbs for foreign
flushing.
There's an inherent mismatch between memcg and writeback. The former
trackes owne
wb_completion is used to track writeback completions. We want to use
it from memcg side for foreign inode flushes. This patch updates it
to remember the target waitq instead of assuming bdi->wb_waitq and
expose it outside of fs-writeback.c.
Signed-off-by: Tejun Heo
Reviewed-by: Jan Kara
---
f
There currently is no way to universally identify and lookup a bdi
without holding a reference and pointer to it. This patch adds an
non-recycling bdi->id and implements bdi_get_by_id() which looks up
bdis by their ids. This will be used by memcg foreign inode flushing.
I left bdi_list alone for
Separate out wb_get_lookup() which doesn't try to create one if there
isn't already one from wb_get_create(). This will be used by later
patches.
Signed-off-by: Tejun Heo
---
include/linux/backing-dev.h |2 +
mm/backing-dev.c| 55 +---
2
Implement cgroup_writeback_by_id() which initiates cgroup writeback
from bdi and memcg IDs. This will be used by memcg foreign inode
flushing.
Signed-off-by: Tejun Heo
---
fs/fs-writeback.c | 67 ++
include/linux/writeback.h |2 +
2 file
There's an inherent mismatch between memcg and writeback. The former
trackes ownership per-page while the latter per-inode. This was a
deliberate design decision because honoring per-page ownership in the
writeback path is complicated, may lead to higher CPU and IO overheads
and deemed unnecessar
Hi Ming,
In the customer case, the cpu_list file was not needed. It was just part of a
SAP Hana script to collect all the block device data (similar to sosreport).
So they were just dumping everything, and it picks up the mq-related files.
I know with IRQs, we have bitmaps/mask, and can
On Wed, Aug 14, 2019 at 11:24 AM Julia Suvorova wrote:
>
> On Mon, Aug 12, 2019 at 6:03 PM Jens Axboe wrote:
> >
> > On 8/12/19 7:55 AM, Bart Van Assche wrote:
> > > On 8/12/19 5:39 AM, Julia Suvorova wrote:
> > >> -#define mb()asm volatile("mfence" ::: "memory")
> > >> -#define rmb()
在 2019年8月16日，01:07，Jens Axboe 写道：
>
> On 8/14/19 3:35 AM, Jackie Liu wrote:
>> Suppose there are three IOs here, and their order is as follows:
>>
>> Submit:
>> [1] IO_LINK
>> |
>> |--- [2] IO_LINK | IO_DRAIN
>>|
>>|- [3] NORMAL_
On 8/15/19 6:48 PM, Jackie Liu wrote:
>
> 在 2019年8月16日，01:07，Jens Axboe 写道：
>
>>
>> On 8/14/19 3:35 AM, Jackie Liu wrote:
>>> Suppose there are three IOs here, and their order is as follows:
>>>
>>> Submit:
>>> [1] IO_LINK
>>> |
>>> |--- [2] IO_LINK | IO_DRAIN
>>>
Hi Adrian,
On Mon, 12 Aug 2019 at 17:44, Baolin Wang wrote:
>
> Hi Adrian,
>
> On Mon, 12 Aug 2019 at 16:59, Adrian Hunter wrote:
> >
> > On 12/08/19 8:20 AM, Baolin Wang wrote:
> > > Hi,
> > >
> > > On Mon, 22 Jul 2019 at 21:10, Baolin Wang wrote:
> > >>
> > >> Hi All,
> > >>
> > >> Now some S
On Thu, Aug 15, 2019 at 11:10:35PM +, Ray, Mark C (Global Solutions
Engineering (GSE)) wrote:
> Hi Ming,
>
> In the customer case, the cpu_list file was not needed. It was just part of
> a SAP Hana script to collect all the block device data (similar to
> sosreport).So they were just
It is reported that sysfs buffer overflow can be triggered in case
of too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs in
blk_mq_hw_sysfs_cpus_show().
So use cpumap_print_to_pagebuf() to print the info and fix the potential
buffer overflow issue.
Cc: sta...@vger.kernel.org
Cc: Mark Ray
On 8/15/19 7:54 PM, Ming Lei wrote:
It is reported that sysfs buffer overflow can be triggered in case
of too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs in
blk_mq_hw_sysfs_cpus_show().
So use cpumap_print_to_pagebuf() to print the info and fix the potential
buffer overflow issue.
Cc
On Fri, Aug 16, 2019 at 11:42 AM Bart Van Assche wrote:
>
> On 8/15/19 7:54 PM, Ming Lei wrote:
> > It is reported that sysfs buffer overflow can be triggered in case
> > of too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs in
> > blk_mq_hw_sysfs_cpus_show().
> >
> > So use cpumap_print_t
> 在 2019年8月16日，09:21，Jens Axboe 写道：
>
> On 8/15/19 6:48 PM, Jackie Liu wrote:
>>
>> 在 2019年8月16日，01:07，Jens Axboe 写道：
>>
>>>
>>> On 8/14/19 3:35 AM, Jackie Liu wrote:
Suppose there are three IOs here, and their order is as follows:
Submit:
[1] IO_LINK
|
>
64 matches
Mail list logo
