* Re: [PATCH 0/3] iopmem : A block device for PCIe memory
From: Stephen Bates @ 2016-10-19 18:48 UTC (permalink / raw)
To: Dan Williams
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-block-u79uwXL29TY76Z2rM5mHXA, Linux MM, Ross Zwisler,
Matthew Wilcox, jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
haggaie-VPRAkNaXOzVWk0Htik3J/w, Christoph Hellwig, Jens Axboe,
Jonathan Corbet, jim.macdonald-FgSLVYC75IpWk0Htik3J/w,
sbates-Rgftl6RXld5BDgjK7y7TUQ, Logan Gunthorpe, David Woodhouse,
Raj, Ashok
In-Reply-To: <CAPcyv4gJ_c-6s2BUjsu6okR1EF53R+KNuXnOc5jv0fuwJaa3cQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Oct 18, 2016 at 08:51:15PM -0700, Dan Williams wrote:
> [ adding Ashok and David for potential iommu comments ]
>
Hi Dan
Thanks for adding Ashok and David!
>
> I agree with the motivation and the need for a solution, but I have
> some questions about this implementation.
>
> >
> > Consumers
> > ---------
> >
> > We provide a PCIe device driver in an accompanying patch that can be
> > used to map any PCIe BAR into a DAX capable block device. For
> > non-persistent BARs this simply serves as an alternative to using
> > system memory bounce buffers. For persistent BARs this can serve as an
> > additional storage device in the system.
>
> Why block devices? I wonder if iopmem was initially designed back
> when we were considering enabling DAX for raw block devices. However,
> that support has since been ripped out / abandoned. You currently
> need a filesystem on top of a block-device to get DAX operation.
> Putting xfs or ext4 on top of PCI-E memory mapped range seems awkward
> if all you want is a way to map the bar for another PCI-E device in
> the topology.
>
> If you're only using the block-device as a entry-point to create
> dax-mappings then a device-dax (drivers/dax/) character-device might
> be a better fit.
>
We chose a block device because we felt it was intuitive for users to
carve up a memory region but putting a DAX filesystem on it and creating
files on that DAX aware FS. It seemed like a convenient way to
partition up the region and to be easily able to get the DMA address
for the memory backing the device.
That said I would be very keen to get other peoples thoughts on how
they would like to see this done. And I know some people have had some
reservations about using DAX mounted FS to do this in the past.
>
> > 2. Memory Segment Spacing. This patch has the same limitations that
> > ZONE_DEVICE does in that memory regions must be spaces at least
> > SECTION_SIZE bytes part. On x86 this is 128MB and there are cases where
> > BARs can be placed closer together than this. Thus ZONE_DEVICE would not
> > be usable on neighboring BARs. For our purposes, this is not an issue as
> > we'd only be looking at enabling a single BAR in a given PCIe device.
> > More exotic use cases may have problems with this.
>
> I'm working on patches for 4.10 to allow mixing multiple
> devm_memremap_pages() allocations within the same physical section.
> Hopefully this won't be a problem going forward.
>
Thanks Dan. Your patches will help address the problem of how to
partition a /dev/dax device but they don't help the case then BARs
themselves are small, closely spaced and non-segment aligned. However
I think most people using iopmem will want to use reasonbly large
BARs so I am not sure item 2 is that big of an issue.
> I haven't yet grokked the motivation for this, but I'll go comment on
> that separately.
Thanks Dan!
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rdma-core 2/4] glue/redhat: add udev/systemd/etc infrastructure bits
From: Jason Gunthorpe @ 2016-10-19 18:59 UTC (permalink / raw)
To: Weiny, Ira
Cc: Jarod Wilson, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Doug Ledford, Hefty, Sean
In-Reply-To: <2807E5FD2F6FDA4886F6618EAC48510E24F0DF57-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Wed, Oct 19, 2016 at 06:38:52PM +0000, Weiny, Ira wrote:
> I have the C code ported to rdma-core but how do I do this in cmake?
Attached, you will also need
target_link_libraries(rdma-ndd ${UDEV_LIBRARIES})
> PKG_CHECK_EXISTS(libudev >= 218, [with_dev_logging=no],
> [with_udev_logging=yes])
> if test "$with_udev_logging" = "yes"; then
> AC_DEFINE_UNQUOTED([HAVE_UDEV_LOGGING], 1,
> [whether libudev logging can be used])
Dump HAVE_UDEV_LOGGING from the code, upstream deleted support for it:
https://www.redhat.com/archives/libvir-list/2014-December/msg00749.html
src.c:3:2: warning: 'udev_set_log_fn' is deprecated (declared at /usr/include/libudev.h:41) [-Wdeprecated-declarations]
int main(int argc,const char *argv[]) {udev_set_log_fn(NULL, NULL); return 0;}
^
> I've found a "modules" file which looks like it has a compatible BSD
> license and could be added but is there a better way?
Basically the right idea, but I prefer to avoid pkgconfig whenever
possible as it screws up cross compiling.
> I also have to convert the man page from *.rst to man in some way...
> Would it be ok if I put a dependency on rst2man in the repo?
We have talked about it, maybe for now just include both the .rst and
the rst2man output and we can revisit it..
Jason
>From b0062acc238e06289aa946dacd5c534cf6c68d7d Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Date: Wed, 19 Oct 2016 12:57:25 -0600
Subject: [PATCH] Add a dependency on libudev
incomplete, needs the RH stuff too.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
.travis.yml | 1 +
CMakeLists.txt | 4 ++++
README.md | 2 +-
buildlib/FindUDev.cmake | 10 ++++++++++
debian/control | 1 +
5 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 buildlib/FindUDev.cmake
diff --git a/.travis.yml b/.travis.yml
index d81b699294eb..d9c36cc9c649 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -24,6 +24,7 @@ addons:
- gcc-6
- libnl-3-dev
- libnl-route-3-dev
+ - libudev-dev
- make
- ninja-build
- pkg-config
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a23aa860e6d3..9402bacf70ce 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -237,6 +237,10 @@ if (NOT NL_KIND EQUAL 0)
set(CMAKE_REQUIRED_INCLUDES "${SAFE_CMAKE_REQUIRED_INCLUDES}")
endif()
+# udev
+find_package(UDev REQUIRED)
+include_directories(${UDEV_INCLUDE_DIRS})
+
# Statically determine sizeof(long), this is largely unnecessary, no new code
# should rely on this.
check_type_size("long" SIZEOF_LONG BUILTIN_TYPES_ONLY LANGUAGE C)
diff --git a/README.md b/README.md
index 66aee3f49f00..d24fd0bf2606 100644
--- a/README.md
+++ b/README.md
@@ -48,7 +48,7 @@ only load from the system path.
### Debian Derived
```sh
-$ apt-get install build-essential cmake gcc libnl-3-dev libnl-route-3-dev ninja-build pkg-config valgrind
+$ apt-get install build-essential cmake gcc libudev-dev libnl-3-dev libnl-route-3-dev ninja-build pkg-config valgrind
```
### Fedora
diff --git a/buildlib/FindUDev.cmake b/buildlib/FindUDev.cmake
new file mode 100644
index 000000000000..ce05ddf991a1
--- /dev/null
+++ b/buildlib/FindUDev.cmake
@@ -0,0 +1,10 @@
+# COPYRIGHT (c) 2016 Obsidian Research Corporation. See COPYING file
+
+find_library(LIBUDEV_LIBRARY NAMES udev libudev)
+
+set(UDEV_LIBRARIES ${LIBUDEV_LIBRARY})
+
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(UDev REQUIRED_VARS LIBUDEV_LIBRARY)
+
+mark_as_advanced(LIBUDEV_LIBRARY)
diff --git a/debian/control b/debian/control
index 2335d1f4814d..ed9850a348be 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Build-Depends: build-essential,
dh-systemd,
dpkg-dev (>= 1.17),
gcc,
+ libudev-dev,
libnl-3-dev,
libnl-route-3-dev,
make,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support
From: Parav Pandit @ 2016-10-19 19:03 UTC (permalink / raw)
To: Tejun Heo
Cc: Leon Romanovsky, cgroups-u79uwXL29TY76Z2rM5mHXA, linux-rdma,
Li Zefan, Johannes Weiner, Doug Ledford, Christoph Hellwig,
Liran Liss, Hefty, Sean, Jason Gunthorpe, Haggai Eran,
james.l.morris-QHcLZuEGTsvQT0dZR+AlfA, Or Gerlitz, Matan Barak
In-Reply-To: <20161019143345.GA18532-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
Hi Tejun,
On Wed, Oct 19, 2016 at 8:03 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hello,
>
> On Wed, Oct 19, 2016 at 03:04:52PM +0530, Parav Pandit wrote:
>> > Heh, we can go for per-mil and use %0 as the suffix if absolutely
>> > necessary but is this a real issue?
>>
>> We need to provide current version to exceed the 100 containers limit first. :-)
>> Please let me know if such user interface already exist as reference point.
>> I prefer to avoid introducing such configuration.
>
> We don't have such usage yet. rdmacg would be the first one doing
> something like this.
>
>> > I think it's a lot more consistent to implement all absoulte limits
>> > through max.
>>
>> I agree. I will implement reporting actual max values instead of
>> reporting "max" string so that percentage configuration can be done by
>> the user space tools.
>> (post merging of v12).
>> Waiting for direction from Doug.
>
> That doesn't sound like a good idea. What happens when the amount of
> available resources changes either through underlying resource changes
To my knowledge device configuration cannot change on the fly while
its still active.
PCIe SR-IOV VF might be able to do so. In that case we might need to
introduce event notifier framework.
This can be possibility regardless of percentage configuration if such
device comes up.
However this appears far fetched.
> or config changes in one of the ancestors? What "max" means is "no
> limit is imposed" which is different from "limit it to 100% of what's
> currently available".
Charging is hierarchical for rdmacg too.
rdma.max configuration exist at all the levels so ancestors change
won't affect its children.
rdma.max absolute (or future percentage) value is with reference to
the total device resources.
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support
From: Tejun Heo @ 2016-10-19 19:20 UTC (permalink / raw)
To: Parav Pandit
Cc: Leon Romanovsky, cgroups-u79uwXL29TY76Z2rM5mHXA, linux-rdma,
Li Zefan, Johannes Weiner, Doug Ledford, Christoph Hellwig,
Liran Liss, Hefty, Sean, Jason Gunthorpe, Haggai Eran,
james.l.morris-QHcLZuEGTsvQT0dZR+AlfA, Or Gerlitz, Matan Barak
In-Reply-To: <CAG53R5WUyA7JBn=PeivUc5F5k210xf_HccPXFt3r7ZGYHOPaGA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello,
On Thu, Oct 20, 2016 at 12:33:53AM +0530, Parav Pandit wrote:
> > or config changes in one of the ancestors? What "max" means is "no
> > limit is imposed" which is different from "limit it to 100% of what's
> > currently available".
>
> Charging is hierarchical for rdmacg too.
> rdma.max configuration exist at all the levels so ancestors change
> won't affect its children.
> rdma.max absolute (or future percentage) value is with reference to
> the total device resources.
Ah, right, the percentage is out of the total device resources
regardless of the hierarchical restrictions. I still don't think it's
a good idea for rdmacg to deviate from the common interface
conventions. If you want to do the percentage calculation in the
userland and the base numbers are system-wide numbers which are
hardware dependent, it'd be best if there's an existing place where
the numbers can be exposed naturally. That'd be more in line with
others too. The amount of total resources available for the device
isn't tied to cgroup after all.
Thanks.
--
tejun
^ permalink raw reply
* Re: New providers in rdma-core
From: Adit Ranadive @ 2016-10-19 19:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Christoph Hellwig, Leon Romanovsky, Amrani, Ram, Lijun Ou,
Knut Omang, Doug Ledford, linux-rdma
In-Reply-To: <20161019175926.GD29879-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Wed, Oct 19, 2016 at 11:59:26AM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 19, 2016 at 10:28:36AM -0700, Adit Ranadive wrote:
>
> > > Requiring installed super updtodate kernel headers isn't going to
> > > help development. It would be good to keep a copy of the kernel
> > > headers in the rdma-core repo, similar to what most kernel tools
> > > tied to bleeding edge ABIs do.
> >
> > Thanks for the heads up. I had a few questions regarding the ABI stuff.
> > What happens in case of providers that arent part of the kernel as yet?
> > I would like to send out a pull request soonish for libpvrdma. I would
> > need to include the abi files in that request since cmake would fail.
>
> Follow the pattern rxe is using:
>
> CHECK_INCLUDE_FILE("rdma/rdma_user_rxe.h" HAVE_RDMA_USER_RXE)
> RDMA_DoFixup("${HAVE_RDMA_USER_RXE}" "rdma/rdma_user_rxe.h")
>
> Which uses the compat header file in
> buildlib/fixup-include/rdma-rdma_user_rxe.h, which must be a
> byte-for-byte copy of the kernel header.
I see that rxe still has a rxe-abi header in the providers/rxe folder.
Would that also move to the kernel as part of the conversion?
One of the things I'm unclear about what happends to the IBV structs
included in the user-level ABI headers, for example, the ibv_get_context_resp
here:
https://github.com/linux-rdma/rdma-core/blob/master/providers/mlx4/mlx4-abi.h#L48
Since these are not present in the kernel, how would the libibverbs/core
uverbs stack handle this? Would there be forthcoming changes for that too?
> > Or do you want me to wait till Doug adds the PVRDMA driver to the tree?
>
> FWIW, we can't take a rdma-core provider until the kernel side is
> accepted, but you can certainly start the process now and get it to an
> OK state. Doug will be able to take both parts simultaneously.
>
Makes sense.
Thanks,
Adit
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support
From: Parav Pandit @ 2016-10-19 19:54 UTC (permalink / raw)
To: Tejun Heo
Cc: Leon Romanovsky, cgroups-u79uwXL29TY76Z2rM5mHXA, linux-rdma,
Li Zefan, Johannes Weiner, Doug Ledford, Christoph Hellwig,
Liran Liss, Hefty, Sean, Jason Gunthorpe, Haggai Eran,
james.l.morris-QHcLZuEGTsvQT0dZR+AlfA, Or Gerlitz, Matan Barak
In-Reply-To: <20161019192006.GB3044-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
Hi Tejun,
On Thu, Oct 20, 2016 at 12:50 AM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hello,
>
> On Thu, Oct 20, 2016 at 12:33:53AM +0530, Parav Pandit wrote:
>> > or config changes in one of the ancestors? What "max" means is "no
>> > limit is imposed" which is different from "limit it to 100% of what's
>> > currently available".
>>
>> Charging is hierarchical for rdmacg too.
>> rdma.max configuration exist at all the levels so ancestors change
>> won't affect its children.
>> rdma.max absolute (or future percentage) value is with reference to
>> the total device resources.
>
> Ah, right, the percentage is out of the total device resources
> regardless of the hierarchical restrictions. I still don't think it's
> a good idea for rdmacg to deviate from the common interface
> conventions. If you want to do the percentage calculation in the
> userland and the base numbers are system-wide numbers which are
> hardware dependent, it'd be best if there's an existing place where
> the numbers can be exposed naturally. That'd be more in line with
> others too. The amount of total resources available for the device
> isn't tied to cgroup after all.
>
userland can get the max numbers using other framework which is used
by control & data plane available in C library form or in form of
system tools.
I was preferring to get and set through same interface because,
It simplifies user land software which is often not written in C so
its likely that it needs to rely on system tools and parse the
content, iterate through devices etc.
Getting these info through rdma.max just makes it simple. There will
be logic built to read/write rdma.max in userland anyway, which can be
leveraged for percentage calculation instead of doing it from two
places.
> Thanks.
>
> --
> tejun
^ permalink raw reply
* Re: [PATCH 0/3] iopmem : A block device for PCIe memory
From: Dan Williams @ 2016-10-19 19:58 UTC (permalink / raw)
To: Stephen Bates
Cc: linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma, linux-block, Linux MM, Ross Zwisler, Matthew Wilcox,
Jason Gunthorpe, haggaie, Christoph Hellwig, Jens Axboe,
Jonathan Corbet, jim.macdonald, sbates, Logan Gunthorpe,
David Woodhouse, Raj, Ashok
In-Reply-To: <20161019184814.GC16550@cgy1-donard.priv.deltatee.com>
On Wed, Oct 19, 2016 at 11:48 AM, Stephen Bates <sbates@raithlin.com> wrote:
> On Tue, Oct 18, 2016 at 08:51:15PM -0700, Dan Williams wrote:
>> [ adding Ashok and David for potential iommu comments ]
>>
>
> Hi Dan
>
> Thanks for adding Ashok and David!
>
>>
>> I agree with the motivation and the need for a solution, but I have
>> some questions about this implementation.
>>
>> >
>> > Consumers
>> > ---------
>> >
>> > We provide a PCIe device driver in an accompanying patch that can be
>> > used to map any PCIe BAR into a DAX capable block device. For
>> > non-persistent BARs this simply serves as an alternative to using
>> > system memory bounce buffers. For persistent BARs this can serve as an
>> > additional storage device in the system.
>>
>> Why block devices? I wonder if iopmem was initially designed back
>> when we were considering enabling DAX for raw block devices. However,
>> that support has since been ripped out / abandoned. You currently
>> need a filesystem on top of a block-device to get DAX operation.
>> Putting xfs or ext4 on top of PCI-E memory mapped range seems awkward
>> if all you want is a way to map the bar for another PCI-E device in
>> the topology.
>>
>> If you're only using the block-device as a entry-point to create
>> dax-mappings then a device-dax (drivers/dax/) character-device might
>> be a better fit.
>>
>
> We chose a block device because we felt it was intuitive for users to
> carve up a memory region but putting a DAX filesystem on it and creating
> files on that DAX aware FS. It seemed like a convenient way to
> partition up the region and to be easily able to get the DMA address
> for the memory backing the device.
>
> That said I would be very keen to get other peoples thoughts on how
> they would like to see this done. And I know some people have had some
> reservations about using DAX mounted FS to do this in the past.
I guess it depends on the expected size of these devices BARs, but I
get the sense they may be smaller / more precious such that you
wouldn't want to spend capacity on filesystem metadata? For the target
use case is it assumed that these device BARs are always backed by
non-volatile memory? Otherwise this is a mkfs each boot for a
volatile device.
>>
>> > 2. Memory Segment Spacing. This patch has the same limitations that
>> > ZONE_DEVICE does in that memory regions must be spaces at least
>> > SECTION_SIZE bytes part. On x86 this is 128MB and there are cases where
>> > BARs can be placed closer together than this. Thus ZONE_DEVICE would not
>> > be usable on neighboring BARs. For our purposes, this is not an issue as
>> > we'd only be looking at enabling a single BAR in a given PCIe device.
>> > More exotic use cases may have problems with this.
>>
>> I'm working on patches for 4.10 to allow mixing multiple
>> devm_memremap_pages() allocations within the same physical section.
>> Hopefully this won't be a problem going forward.
>>
>
> Thanks Dan. Your patches will help address the problem of how to
> partition a /dev/dax device but they don't help the case then BARs
> themselves are small, closely spaced and non-segment aligned. However
> I think most people using iopmem will want to use reasonbly large
> BARs so I am not sure item 2 is that big of an issue.
I think you might have misunderstood what I'm proposing. The patches
I'm working on are separate from a facility to carve up a /dev/dax
device. The effort is to allow devm_memremap_pages() to maintain
several allocations within the same 128MB section. I need this for
persistent memory to handle platforms that mix pmem and system-ram in
the same section. I want to be able to map ZONE_DEVICE pages for a
portion of a section and be able to remove portions of section that
may collide with allocations of a different lifetime.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages.
From: Dan Williams @ 2016-10-19 20:01 UTC (permalink / raw)
To: Stephen Bates
Cc: Jason Gunthorpe, sbates-Rgftl6RXld5BDgjK7y7TUQ,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jim.macdonald-FgSLVYC75IpWk0Htik3J/w,
linux-block-u79uwXL29TY76Z2rM5mHXA, Linux MM, Jens Axboe,
Christoph Hellwig, haggaie-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <20161019184028.GB16550-Fu/sLxIRQ7hz7qcAzjI/l7KmtST0zaCzZeezCHUQhQ4@public.gmane.org>
On Wed, Oct 19, 2016 at 11:40 AM, Stephen Bates <sbates-pv7U853sEMVWk0Htik3J/w@public.gmane.org> wrote:
> On Wed, Oct 19, 2016 at 10:50:25AM -0700, Dan Williams wrote:
>> On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates <sbates-pv7U853sEMVWk0Htik3J/w@public.gmane.org> wrote:
>> > From: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
>> >
>> > We build on recent work that adds memory regions owned by a device
>> > driver (ZONE_DEVICE) [1] and to add struct page support for these new
>> > regions of memory [2].
>> >
>> > 1. Add an extra flags argument into dev_memremap_pages to take in a
>> > MEMREMAP_XX argument. We update the existing calls to this function to
>> > reflect the change.
>> >
>> > 2. For completeness, we add MEMREMAP_WT support to the memremap;
>> > however we have no actual need for this functionality.
>> >
>> > 3. We add the static functions, add_zone_device_pages and
>> > remove_zone_device pages. These are similar to arch_add_memory except
>> > they don't create the memory mapping. We don't believe these need to be
>> > made arch specific, but are open to other opinions.
>> >
>> > 4. dev_memremap_pages and devm_memremap_pages_release are updated to
>> > treat IO memory slightly differently. For IO memory we use a combination
>> > of the appropriate io_remap function and the zone_device pages functions
>> > created above. A flags variable and kaddr pointer are added to struct
>> > page_mem to facilitate this for the release function. We also set up
>> > the page attribute tables for the mapped region correctly based on the
>> > desired mapping.
>> >
>>
>> This description says "what" is being done, but not "why".
>
> Hi Dan
>
> We discuss the motivation in the cover letter.
>
>>
>> In the cover letter, "[PATCH 0/3] iopmem : A block device for PCIe
>> memory", it mentions that the lack of I/O coherency is a known issue
>> and users of this functionality need to be cognizant of the pitfalls.
>> If that is the case why do we need support for different cpu mapping
>> types than the default write-back cache setting? It's up to the
>> application to handle cache cpu flushing similar to what we require of
>> device-dax users in the persistent memory case.
>
> Some of the iopmem hardware we have tested has certain alignment
> restrictions on BAR accesses. At the very least we require write
> combine mappings for these. We then felt it appropriate to add the
> other mappings for the sake of completeness.
If the device can support write-combine then it can support bursts, so
I wonder why it couldn't support read bursts for cache fills...
^ permalink raw reply
* Re: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support
From: Tejun Heo @ 2016-10-19 20:05 UTC (permalink / raw)
To: Parav Pandit
Cc: Leon Romanovsky, cgroups-u79uwXL29TY76Z2rM5mHXA, linux-rdma,
Li Zefan, Johannes Weiner, Doug Ledford, Christoph Hellwig,
Liran Liss, Hefty, Sean, Jason Gunthorpe, Haggai Eran,
james.l.morris-QHcLZuEGTsvQT0dZR+AlfA, Or Gerlitz, Matan Barak
In-Reply-To: <CAG53R5X5dyo7J-UkeMxi_mSxgv=c54fV=anuCZtmf9kaYwDbPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello, Parav.
On Thu, Oct 20, 2016 at 01:24:42AM +0530, Parav Pandit wrote:
> userland can get the max numbers using other framework which is used
> by control & data plane available in C library form or in form of
> system tools.
> I was preferring to get and set through same interface because,
> It simplifies user land software which is often not written in C so
> its likely that it needs to rely on system tools and parse the
> content, iterate through devices etc.
> Getting these info through rdma.max just makes it simple. There will
> be logic built to read/write rdma.max in userland anyway, which can be
> leveraged for percentage calculation instead of doing it from two
> places.
Yeah, I get that this can be convenient in this case but it isn't a
generic approach. I'd much prefer keeping it in line with other
resources.
Thanks.
--
tejun
^ permalink raw reply
* Re: New providers in rdma-core
From: Jason Gunthorpe @ 2016-10-19 20:09 UTC (permalink / raw)
To: Adit Ranadive
Cc: Christoph Hellwig, Leon Romanovsky, Amrani, Ram, Lijun Ou,
Knut Omang, Doug Ledford, linux-rdma
In-Reply-To: <12243e3b-87cf-2bd4-d097-1dd0a7907f41-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
On Wed, Oct 19, 2016 at 12:51:02PM -0700, Adit Ranadive wrote:
> I see that rxe still has a rxe-abi header in the providers/rxe folder.
> Would that also move to the kernel as part of the conversion?
Ideally, but it is blocked by this:
> One of the things I'm unclear about what happends to the IBV structs
> included in the user-level ABI headers, for example, the ibv_get_context_resp
> here:
> https://github.com/linux-rdma/rdma-core/blob/master/providers/mlx4/mlx4-abi.h#L48
This is the main thing preventing the use of the uapi headers - they
are actually *different* :(
It would be great if you have have some ideas on how to deal with
that.. This hasn't been tackled yet.
One choice is to write this:
struct mlx4_alloc_ucontext_resp_v3 {
struct ibv_get_context_resp ibv_resp;
__u32 qp_tab_size;
__u16 bf_reg_size;
__u16 bf_regs_per_page;
};
as:
struct user_mlx4_alloc_ucontext_resp_v3 {
struct ibv_get_context_resp ibv_resp;
struct mlx4_alloc_ucontext_resp_v3 udata;
};
Perhaps aided by a macro so we get high uniformity:
#define DECLARE_DRIVER_UDATA(struct_driver, struct_common)
struct user # struct_driver {
struct struct_common ibv_resp;
struct struct_driver udata;
};
Where mlx4_alloc_ucontext_resp_v3 comes from the uapi header, and is
not inlined, so each driver gets an 'abi wrapper' header that just
builds all these structs.
I'd probably advocate for that for new drivers if nothing more clever
comes forward. At least it is a step closer..
Another approach might be a different way to marshal the kernel call..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support
From: Parav Pandit @ 2016-10-19 20:18 UTC (permalink / raw)
To: Tejun Heo
Cc: Leon Romanovsky, cgroups-u79uwXL29TY76Z2rM5mHXA, linux-rdma,
Li Zefan, Johannes Weiner, Doug Ledford, Christoph Hellwig,
Liran Liss, Hefty, Sean, Jason Gunthorpe, Haggai Eran,
james.l.morris-QHcLZuEGTsvQT0dZR+AlfA, Or Gerlitz, Matan Barak
In-Reply-To: <20161019200536.GC3044-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
On Thu, Oct 20, 2016 at 1:35 AM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hello, Parav.
>
> On Thu, Oct 20, 2016 at 01:24:42AM +0530, Parav Pandit wrote:
>> userland can get the max numbers using other framework which is used
>> by control & data plane available in C library form or in form of
>> system tools.
>> I was preferring to get and set through same interface because,
>> It simplifies user land software which is often not written in C so
>> its likely that it needs to rely on system tools and parse the
>> content, iterate through devices etc.
>> Getting these info through rdma.max just makes it simple. There will
>> be logic built to read/write rdma.max in userland anyway, which can be
>> leveraged for percentage calculation instead of doing it from two
>> places.
>
> Yeah, I get that this can be convenient in this case but it isn't a
> generic approach. I'd much prefer keeping it in line with other
> resources.
>
Hmm. we don't have /proc/sys/kernel/pid_max type of simple interface
to get the max values for rdma resources.
rdma.max is close to that simplicity.
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug 178581] New: v4.9-rc1: Deadlock while unloading IPoIB
From: bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r @ 2016-10-19 20:31 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
https://bugzilla.kernel.org/show_bug.cgi?id=178581
Bug ID: 178581
Summary: v4.9-rc1: Deadlock while unloading IPoIB
Product: Drivers
Version: 2.5
Kernel Version: v4.9-rc1
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Infiniband/RDMA
Assignee: drivers_infiniband-rdma-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
Reporter: bvanassche-HInyCGIudOg@public.gmane.org
Regression: No
Created attachment 241991
--> https://bugzilla.kernel.org/attachment.cgi?id=241991&action=edit
Lockdep output
The output produced by lockdep has been attached. Call trace from that
attachment:
Call Trace:
[<ffffffff81329695>] dump_stack+0x68/0x93
[<ffffffff810baafe>] print_circular_bug+0x1be/0x210
[<ffffffff810bd31c>] __lock_acquire+0x10fc/0x1270
[<ffffffff810bd8b9>] lock_acquire+0xe9/0x1d0
[<ffffffff8126275a>] __kernfs_remove+0x24a/0x310
[<ffffffff812632ae>] kernfs_remove+0x1e/0x30
[<ffffffff8126559c>] sysfs_remove_dir+0x4c/0x80
[<ffffffff8132bec8>] kobject_del+0x18/0x50
[<ffffffff81450fb0>] device_del+0x190/0x240
[<ffffffff81550a27>] netdev_unregister_kobject+0x57/0x60
[<ffffffff81527df0>] rollback_registered_many+0x220/0x370
[<ffffffff81527f6c>] rollback_registered+0x2c/0x40
[<ffffffff81528e54>] unregister_netdevice_queue+0x44/0x90
[<ffffffff81528eb7>] unregister_netdev+0x17/0x20
[<ffffffffa02bdc47>] ipoib_remove_one+0x97/0xe0 [ib_ipoib]
[<ffffffffa032c539>] ib_unregister_device+0xa9/0x150 [ib_core]
[<ffffffffa036d7e5>] mlx4_ib_remove+0x65/0x250 [mlx4_ib]
[<ffffffffa025131e>] mlx4_remove_device+0x6e/0x80 [mlx4_core]
[<ffffffffa0251738>] mlx4_unregister_device+0x48/0x90 [mlx4_core]
[<ffffffffa025364d>] mlx4_unload_one+0x7d/0x310 [mlx4_core]
[<ffffffffa02539cd>] mlx4_shutdown+0x5d/0x70 [mlx4_core]
[<ffffffff8136c768>] pci_device_shutdown+0x28/0x60
[<ffffffff81452f70>] device_shutdown+0xd0/0x1d0
[<ffffffff8108c7e1>] kernel_restart_prepare+0x31/0x40
[<ffffffff8108c88d>] kernel_restart+0xd/0x50
[<ffffffff8108cad9>] SYSC_reboot+0xf9/0x1e0
[<ffffffff8108cc09>] SyS_reboot+0x9/0x10
[<ffffffff8163ed2a>] entry_SYSCALL_64_fastpath+0x18/0xad
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] i40iw: Enable message packing
From: Henry Orosco @ 2016-10-19 20:32 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Henry Orosco
Remove the parameter to disable message packing and
always enable it.
Signed-off-by: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 5 -----
drivers/infiniband/hw/i40iw/i40iw_main.c | 2 +-
drivers/infiniband/hw/i40iw/i40iw_type.h | 2 +-
3 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
index 31c4a0c..6c6a1ef 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
@@ -429,12 +429,10 @@ static enum i40iw_status_code i40iw_sc_cqp_init(struct i40iw_sc_cqp *cqp,
/**
* i40iw_sc_cqp_create - create cqp during bringup
* @cqp: struct for cqp hw
- * @disable_pfpdus: if pfpdu to be disabled
* @maj_err: If error, major err number
* @min_err: If error, minor err number
*/
static enum i40iw_status_code i40iw_sc_cqp_create(struct i40iw_sc_cqp *cqp,
- bool disable_pfpdus,
u16 *maj_err,
u16 *min_err)
{
@@ -453,9 +451,6 @@ static enum i40iw_status_code i40iw_sc_cqp_create(struct i40iw_sc_cqp *cqp,
temp = LS_64(cqp->hw_sq_size, I40IW_CQPHC_SQSIZE) |
LS_64(cqp->struct_ver, I40IW_CQPHC_SVER);
- if (disable_pfpdus)
- temp |= LS_64(1, I40IW_CQPHC_DISABLE_PFPDUS);
-
set_64bit_val(cqp->host_ctx, 0, temp);
set_64bit_val(cqp->host_ctx, 8, cqp->sq_pa);
temp = LS_64(cqp->enabled_vf_count, I40IW_CQPHC_ENABLED_VFS) |
diff --git a/drivers/infiniband/hw/i40iw/i40iw_main.c b/drivers/infiniband/hw/i40iw/i40iw_main.c
index e6dafc7..2a4ca8a 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_main.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_main.c
@@ -603,7 +603,7 @@ static enum i40iw_status_code i40iw_create_cqp(struct i40iw_device *iwdev)
i40iw_pr_err("cqp init status %d\n", status);
goto exit;
}
- status = dev->cqp_ops->cqp_create(dev->cqp, true, &maj_err, &min_err);
+ status = dev->cqp_ops->cqp_create(dev->cqp, &maj_err, &min_err);
if (status) {
i40iw_pr_err("cqp create status %d maj_err %d min_err %d\n",
status, maj_err, min_err);
diff --git a/drivers/infiniband/hw/i40iw/i40iw_type.h b/drivers/infiniband/hw/i40iw/i40iw_type.h
index b6f448a..d1847e6 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_type.h
+++ b/drivers/infiniband/hw/i40iw/i40iw_type.h
@@ -988,7 +988,7 @@ struct i40iw_cqp_query_fpm_values {
struct i40iw_cqp_ops {
enum i40iw_status_code (*cqp_init)(struct i40iw_sc_cqp *,
struct i40iw_cqp_init_info *);
- enum i40iw_status_code (*cqp_create)(struct i40iw_sc_cqp *, bool, u16 *, u16 *);
+ enum i40iw_status_code (*cqp_create)(struct i40iw_sc_cqp *, u16 *, u16 *);
void (*cqp_post_sq)(struct i40iw_sc_cqp *);
u64 *(*cqp_get_next_send_wqe)(struct i40iw_sc_cqp *, u64 scratch);
enum i40iw_status_code (*cqp_destroy)(struct i40iw_sc_cqp *);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] i40iw: Remove workaround for pre-production errata
From: Henry Orosco @ 2016-10-19 20:33 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Henry Orosco
Pre-production silicon incorrectly truncates 4 bytes of the MPA
packet in UDP loopback case. Remove the workaround as it is no
longer necessary.
Signed-off-by: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
drivers/infiniband/hw/i40iw/i40iw_cm.c | 26 +++-----------------------
drivers/infiniband/hw/i40iw/i40iw_cm.h | 2 --
drivers/infiniband/hw/i40iw/i40iw_utils.c | 2 +-
3 files changed, 4 insertions(+), 26 deletions(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index 460a367..e202ff0 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -361,15 +361,6 @@ static void i40iw_cleanup_retrans_entry(struct i40iw_cm_node *cm_node)
spin_unlock_irqrestore(&cm_node->retrans_list_lock, flags);
}
-static bool is_remote_ne020_or_chelsio(struct i40iw_cm_node *cm_node)
-{
- if ((cm_node->rem_mac[0] == 0x0) &&
- (((cm_node->rem_mac[1] == 0x12) && (cm_node->rem_mac[2] == 0x55)) ||
- ((cm_node->rem_mac[1] == 0x07 && (cm_node->rem_mac[2] == 0x43)))))
- return true;
- return false;
-}
-
/**
* i40iw_form_cm_frame - get a free packet and build frame
* @cm_node: connection's node ionfo to use in frame
@@ -410,11 +401,8 @@ static struct i40iw_puda_buf *i40iw_form_cm_frame(struct i40iw_cm_node *cm_node,
if (hdr)
hdr_len = hdr->size;
- if (pdata) {
+ if (pdata)
pd_len = pdata->size;
- if (!is_remote_ne020_or_chelsio(cm_node))
- pd_len += MPA_ZERO_PAD_LEN;
- }
if (cm_node->vlan_id < VLAN_TAG_PRESENT)
eth_hlen += 4;
@@ -3604,7 +3592,7 @@ int i40iw_accept(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)
iwqp->cm_node = (void *)cm_node;
cm_node->iwqp = iwqp;
- buf_len = conn_param->private_data_len + I40IW_MAX_IETF_SIZE + MPA_ZERO_PAD_LEN;
+ buf_len = conn_param->private_data_len + I40IW_MAX_IETF_SIZE;
status = i40iw_allocate_dma_mem(dev->hw, &iwqp->ietf_mem, buf_len, 1);
@@ -3638,18 +3626,10 @@ int i40iw_accept(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)
iwqp->lsmm_mr = ibmr;
if (iwqp->page)
iwqp->sc_qp.qp_uk.sq_base = kmap(iwqp->page);
- if (is_remote_ne020_or_chelsio(cm_node))
- dev->iw_priv_qp_ops->qp_send_lsmm(
- &iwqp->sc_qp,
+ dev->iw_priv_qp_ops->qp_send_lsmm(&iwqp->sc_qp,
iwqp->ietf_mem.va,
(accept.size + conn_param->private_data_len),
ibmr->lkey);
- else
- dev->iw_priv_qp_ops->qp_send_lsmm(
- &iwqp->sc_qp,
- iwqp->ietf_mem.va,
- (accept.size + conn_param->private_data_len + MPA_ZERO_PAD_LEN),
- ibmr->lkey);
} else {
if (iwqp->page)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.h b/drivers/infiniband/hw/i40iw/i40iw_cm.h
index 945ed26..24615c2 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.h
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.h
@@ -56,8 +56,6 @@
#define I40IW_MAX_IETF_SIZE 32
-#define MPA_ZERO_PAD_LEN 4
-
/* IETF RTR MSG Fields */
#define IETF_PEER_TO_PEER 0x8000
#define IETF_FLPDU_ZERO_LEN 0x4000
diff --git a/drivers/infiniband/hw/i40iw/i40iw_utils.c b/drivers/infiniband/hw/i40iw/i40iw_utils.c
index 218e9fd..805603b 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_utils.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_utils.c
@@ -1250,7 +1250,7 @@ enum i40iw_status_code i40iw_puda_get_tcpip_info(struct i40iw_puda_completion_in
buf->totallen = pkt_len + buf->maclen;
- if (info->payload_len < buf->totallen - 4) {
+ if (info->payload_len < buf->totallen) {
i40iw_pr_err("payload_len = 0x%x totallen expected0x%x\n",
info->payload_len, buf->totallen);
return I40IW_ERR_INVALID_SIZE;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] i40iw: Set MAX IRD, MAX ORD size to max supported value
From: Henry Orosco @ 2016-10-19 20:33 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Henry Orosco
Set the MAX_IRD and MAX_ORD size negotiated to the maximum
supported values.
Signed-off-by: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 5 -----
drivers/infiniband/hw/i40iw/i40iw_user.h | 5 ++---
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
index 31c4a0c..89eddbc 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
@@ -2626,11 +2626,6 @@ static enum i40iw_status_code i40iw_sc_qp_setctx(
152,
LS_64(iw->last_byte_sent, I40IWQPC_LASTBYTESENT));
- /*
- * Hard-code IRD_SIZE to hw-limit, 128, in qpctx, i.e matching an
- *advertisable IRD of 64
- */
- iw->ird_size = I40IW_QPCTX_ENCD_MAXIRD;
set_64bit_val(qp_ctx,
160,
LS_64(iw->ord_size, I40IWQPC_ORDSIZE) |
diff --git a/drivers/infiniband/hw/i40iw/i40iw_user.h b/drivers/infiniband/hw/i40iw/i40iw_user.h
index 276bcef..e65c2baa 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_user.h
+++ b/drivers/infiniband/hw/i40iw/i40iw_user.h
@@ -72,10 +72,9 @@ enum i40iw_device_capabilities_const {
I40IW_MAX_SQ_PAYLOAD_SIZE = 2145386496,
I40IW_MAX_INLINE_DATA_SIZE = 48,
I40IW_MAX_PUSHMODE_INLINE_DATA_SIZE = 48,
- I40IW_MAX_IRD_SIZE = 32,
- I40IW_QPCTX_ENCD_MAXIRD = 3,
+ I40IW_MAX_IRD_SIZE = 63,
+ I40IW_MAX_ORD_SIZE = 127,
I40IW_MAX_WQ_ENTRIES = 2048,
- I40IW_MAX_ORD_SIZE = 32,
I40IW_Q2_BUFFER_SIZE = (248 + 100),
I40IW_QP_CTX_SIZE = 248
};
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 04/11] blk-mq: Introduce blk_mq_quiesce_queue()
From: Bart Van Assche @ 2016-10-19 21:04 UTC (permalink / raw)
To: Jens Axboe
Cc: Christoph Hellwig, James Bottomley, Martin K. Petersen,
Mike Snitzer, Doug Ledford, Keith Busch, Ming Lei,
Laurence Oberman, linux-block@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-nvme@lists.infradead.org
In-Reply-To: <e42a952c-f245-eb39-d0a1-0336035573f9@sandisk.com>
On 10/18/2016 02:50 PM, Bart Van Assche wrote:
> blk_mq_quiesce_queue() waits until ongoing .queue_rq() invocations
> have finished. This function does *not* wait until all outstanding
> requests have finished (this means invocation of request.end_io()).
(replying to my own e-mail)
The zero-day kernel test infrastructure reported to me that this patch
causes a build failure with CONFIG_SRCU=n. Should I add "select SRCU" to
block/Kconfig (excludes TINY_RCU) or should I rather modify this patch
such that a mutex or rwsem is used instead of SRCU?
Thanks,
Bart.
^ permalink raw reply
* RE: [PATCH rdma-core 2/4] glue/redhat: add udev/systemd/etc infrastructure bits
From: Weiny, Ira @ 2016-10-19 21:35 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Jarod Wilson, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Doug Ledford, Hefty, Sean
In-Reply-To: <20161019185920.GA20600-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Udev below works great. Thanks!
But I have another cmake question.
I have specified the following:
install(FILES rdma-ndd.conf DESTINATION "${CMAKE_INSTALL_SYSCONFDIR}")
set(rdma_ndd_CONFIG_PATH "${CMAKE_INSTALL_SYSCONFDIR}")
configure_file ("${PROJECT_SOURCE_DIR}/rdma-ndd/rdma-config.h.in"
"${PROJECT_BINARY_DIR}/rdma-ndd/rdma-config.h")
include_directories("${PROJECT_BINARY_DIR}/rdma-ndd")
The idea here is to have an rdma-ndd.conf file which allows the user to configure their names. (previously this was the infiniband-diags.conf file). But I have ported over the code.
The value in rdma-config.h ends up being:
17:30:34 > cat build/rdma-ndd/rdma-config.h
/* Pick up configuration items from cmake */
#define RDMA_NDD_CONFIG_PATH "etc"
#define PACKAGE_VERSION 11
Which seems fine but after a "make install" I'm left with an incorrect path:
[root@phcppriv13 sbin]# pwd && ./rdma-ndd -f
/usr/local/sbin
rdma-ndd[91656]: Using config file (etc/rdma-ndd.conf)
...
So it is not reading the correct config file.
How do I link the install to this variable in the code?
Ira
> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org]
> Sent: Wednesday, October 19, 2016 11:59 AM
> To: Weiny, Ira <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Jarod Wilson <jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Doug
> Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>; Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Subject: Re: [PATCH rdma-core 2/4] glue/redhat: add udev/systemd/etc
> infrastructure bits
>
> On Wed, Oct 19, 2016 at 06:38:52PM +0000, Weiny, Ira wrote:
>
> > I have the C code ported to rdma-core but how do I do this in cmake?
>
> Attached, you will also need
>
> target_link_libraries(rdma-ndd ${UDEV_LIBRARIES})
>
> > PKG_CHECK_EXISTS(libudev >= 218, [with_dev_logging=no],
> > [with_udev_logging=yes])
> > if test "$with_udev_logging" = "yes"; then
> > AC_DEFINE_UNQUOTED([HAVE_UDEV_LOGGING], 1,
> > [whether libudev logging can be used])
>
> Dump HAVE_UDEV_LOGGING from the code, upstream deleted support for it:
>
> https://www.redhat.com/archives/libvir-list/2014-December/msg00749.html
>
> src.c:3:2: warning: 'udev_set_log_fn' is deprecated (declared at
> /usr/include/libudev.h:41) [-Wdeprecated-declarations]
> int main(int argc,const char *argv[]) {udev_set_log_fn(NULL, NULL); return 0;}
> ^
>
> > I've found a "modules" file which looks like it has a compatible BSD
> > license and could be added but is there a better way?
>
> Basically the right idea, but I prefer to avoid pkgconfig whenever possible as it
> screws up cross compiling.
>
> > I also have to convert the man page from *.rst to man in some way...
> > Would it be ok if I put a dependency on rst2man in the repo?
>
> We have talked about it, maybe for now just include both the .rst and the
> rst2man output and we can revisit it..
>
> Jason
>
> From b0062acc238e06289aa946dacd5c534cf6c68d7d Mon Sep 17 00:00:00
> 2001
> From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> Date: Wed, 19 Oct 2016 12:57:25 -0600
> Subject: [PATCH] Add a dependency on libudev
>
> incomplete, needs the RH stuff too.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> ---
> .travis.yml | 1 +
> CMakeLists.txt | 4 ++++
> README.md | 2 +-
> buildlib/FindUDev.cmake | 10 ++++++++++
> debian/control | 1 +
> 5 files changed, 17 insertions(+), 1 deletion(-) create mode 100644
> buildlib/FindUDev.cmake
>
> diff --git a/.travis.yml b/.travis.yml
> index d81b699294eb..d9c36cc9c649 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -24,6 +24,7 @@ addons:
> - gcc-6
> - libnl-3-dev
> - libnl-route-3-dev
> + - libudev-dev
> - make
> - ninja-build
> - pkg-config
> diff --git a/CMakeLists.txt b/CMakeLists.txt index a23aa860e6d3..9402bacf70ce
> 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -237,6 +237,10 @@ if (NOT NL_KIND EQUAL 0)
> set(CMAKE_REQUIRED_INCLUDES "${SAFE_CMAKE_REQUIRED_INCLUDES}")
> endif()
>
> +# udev
> +find_package(UDev REQUIRED)
> +include_directories(${UDEV_INCLUDE_DIRS})
> +
> # Statically determine sizeof(long), this is largely unnecessary, no new code #
> should rely on this.
> check_type_size("long" SIZEOF_LONG BUILTIN_TYPES_ONLY LANGUAGE C) diff
> --git a/README.md b/README.md index 66aee3f49f00..d24fd0bf2606 100644
> --- a/README.md
> +++ b/README.md
> @@ -48,7 +48,7 @@ only load from the system path.
> ### Debian Derived
>
> ```sh
> -$ apt-get install build-essential cmake gcc libnl-3-dev libnl-route-3-dev ninja-
> build pkg-config valgrind
> +$ apt-get install build-essential cmake gcc libudev-dev libnl-3-dev
> +libnl-route-3-dev ninja-build pkg-config valgrind
> ```
>
> ### Fedora
> diff --git a/buildlib/FindUDev.cmake b/buildlib/FindUDev.cmake new file mode
> 100644 index 000000000000..ce05ddf991a1
> --- /dev/null
> +++ b/buildlib/FindUDev.cmake
> @@ -0,0 +1,10 @@
> +# COPYRIGHT (c) 2016 Obsidian Research Corporation. See COPYING file
> +
> +find_library(LIBUDEV_LIBRARY NAMES udev libudev)
> +
> +set(UDEV_LIBRARIES ${LIBUDEV_LIBRARY})
> +
> +include(FindPackageHandleStandardArgs)
> +find_package_handle_standard_args(UDev REQUIRED_VARS
> LIBUDEV_LIBRARY)
> +
> +mark_as_advanced(LIBUDEV_LIBRARY)
> diff --git a/debian/control b/debian/control index
> 2335d1f4814d..ed9850a348be 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -8,6 +8,7 @@ Build-Depends: build-essential,
> dh-systemd,
> dpkg-dev (>= 1.17),
> gcc,
> + libudev-dev,
> libnl-3-dev,
> libnl-route-3-dev,
> make,
> --
> 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 0/11] Fix race conditions related to stopping block layer queues
From: Keith Busch @ 2016-10-19 22:24 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jens Axboe, Christoph Hellwig, James Bottomley,
Martin K. Petersen, Mike Snitzer, Doug Ledford, Ming Lin,
Laurence Oberman, linux-block@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-nvme@lists.infradead.org
In-Reply-To: <b39eb0e7-1007-eb63-8e7f-9a7f08508379@sandisk.com>
Hi Bart,
I'm running linux 4.9-rc1 + linux-block/for-linus, and alternating tests
with and without this series.
Without this, I'm not seeing any problems in a link-down test while
running fio after ~30 runs.
With this series, I only see the test pass infrequently. Most of the
time I observe one of several failures. In all cases, it looks like the
rq->queuelist is in an unexpected state.
I think I've almost got this tracked down, but I have to leave for the
day soon. Rather than having a more useful suggestion, I've put the two
failures below.
First failure:
[ 214.782075] ------------[ cut here ]------------
[ 214.782098] kernel BUG at block/blk-mq.c:498!
[ 214.782117] invalid opcode: 0000 [#1] SMP
[ 214.782133] Modules linked in: nvme nvme_core nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security ebtable_filter ebtables ip6table_filter ip6_tables vfat fat
[ 214.782356] CPU: 6 PID: 160 Comm: kworker/u16:6 Not tainted 4.9.0-rc1+ #28
[ 214.782383] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD5H/Z97X-UD5H, BIOS F8 06/17/2014
[ 214.782419] Workqueue: nvme nvme_reset_work [nvme]
[ 214.782440] task: ffff8c0815403b00 task.stack: ffffb6ad01384000
[ 214.782463] RIP: 0010:[<ffffffff9f3b88a5>] [<ffffffff9f3b88a5>] blk_mq_requeue_request+0x35/0x40
[ 214.782502] RSP: 0018:ffffb6ad01387b88 EFLAGS: 00010287
[ 214.782524] RAX: ffff8c0814b98400 RBX: ffff8c0814b98200 RCX: 0000000000007530
[ 214.782551] RDX: 0000000000000007 RSI: 0000000000000001 RDI: ffff8c0814b98200
[ 214.782578] RBP: ffffb6ad01387b98 R08: 0000000000000000 R09: ffffffff9f408680
[ 214.783394] R10: 0000000000000394 R11: 0000000000000388 R12: 0000000000000001
[ 214.784212] R13: ffff8c081593a000 R14: 0000000000000001 R15: ffff8c080cdea740
[ 214.785033] FS: 0000000000000000(0000) GS:ffff8c081fb80000(0000) knlGS:0000000000000000
[ 214.785869] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 214.786710] CR2: 00007ffae4497f34 CR3: 00000001dfe06000 CR4: 00000000001406e0
[ 214.787559] Stack:
[ 214.788406] ffff8c0814b98200 0000000000000000 ffffb6ad01387ba8 ffffffffc03451b3
[ 214.789287] ffffb6ad01387bd0 ffffffffc0357a4a ffff8c0814b98200 ffffd6acffc81a00
[ 214.790174] 0000000000000006 ffffb6ad01387bf8 ffffffff9f3b8e22 ffff8c0814b98200
[ 214.791066] Call Trace:
[ 214.791935] [<ffffffffc03451b3>] nvme_requeue_req+0x13/0x20 [nvme_core]
[ 214.792810] [<ffffffffc0357a4a>] nvme_complete_rq+0x16a/0x1d0 [nvme]
[ 214.793680] [<ffffffff9f3b8e22>] __blk_mq_complete_request+0x72/0xe0
[ 214.794551] [<ffffffff9f3b8eac>] blk_mq_complete_request+0x1c/0x20
[ 214.795422] [<ffffffffc0345e70>] nvme_cancel_request+0x50/0x90 [nvme_core]
[ 214.796299] [<ffffffff9f3bc09e>] bt_tags_iter+0x2e/0x40
[ 214.797157] [<ffffffff9f3bc523>] blk_mq_tagset_busy_iter+0x173/0x1e0
[ 214.798005] [<ffffffffc0345e20>] ? nvme_shutdown_ctrl+0x100/0x100 [nvme_core]
[ 214.798852] [<ffffffffc0345e20>] ? nvme_shutdown_ctrl+0x100/0x100 [nvme_core]
[ 214.799682] [<ffffffffc035603d>] nvme_dev_disable+0x11d/0x380 [nvme]
[ 214.800511] [<ffffffff9f0479fa>] ? acpi_unregister_gsi_ioapic+0x3a/0x40
[ 214.801344] [<ffffffff9f52d33c>] ? dev_warn+0x6c/0x90
[ 214.802157] [<ffffffffc0356bc4>] nvme_reset_work+0xa4/0xdc0 [nvme]
[ 214.802961] [<ffffffff9f025736>] ? __switch_to+0x2b6/0x5f0
[ 214.803773] [<ffffffff9f0bb1bf>] process_one_work+0x15f/0x430
[ 214.804593] [<ffffffff9f0bb4de>] worker_thread+0x4e/0x490
[ 214.805419] [<ffffffff9f0bb490>] ? process_one_work+0x430/0x430
[ 214.806255] [<ffffffff9f0c0d09>] kthread+0xd9/0xf0
[ 214.807096] [<ffffffff9f0c0c30>] ? kthread_park+0x60/0x60
[ 214.807946] [<ffffffff9f81dc15>] ret_from_fork+0x25/0x30
[ 214.808801] Code: 54 53 48 89 fb 41 89 f4 e8 a9 fa ff ff 48 8b 03 48 39 c3 75 16 41 0f b6 d4 48 89 df be 01 00 00 00 e8 10 ff ff ff 5b 41 5c 5d c3 <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 be 40 00 00
[ 214.810714] RIP [<ffffffff9f3b88a5>] blk_mq_requeue_request+0x35/0x40
[ 214.811628] RSP <ffffb6ad01387b88>
[ 214.812545] ---[ end trace 6ef3a3b6f8cea418 ]---
[ 214.813437] ------------[ cut here ]------------
Second failure, warning followed by NMI watchdog:
[ 410.736619] ------------[ cut here ]------------
[ 410.736624] WARNING: CPU: 2 PID: 577 at lib/list_debug.c:29 __list_add+0x62/0xb0
[ 410.736883] list_add corruption. next->prev should be prev (ffffacf481847d78), but was ffff931f8fb78000. (next=ffff931f8fb78000).
[ 410.736884] Modules linked in: nvme nvme_core nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw ip6table_mangle iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw iptable_mangle ebtable_filter ebtables ip6table_filter ip6_tables vfat fat
[ 410.736902] CPU: 2 PID: 577 Comm: kworker/2:1H Not tainted 4.9.0-rc1+ #28
[ 410.736903] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD5H/Z97X-UD5H, BIOS F8 06/17/2014
[ 410.736906] Workqueue: kblockd blk_mq_run_work_fn
[ 410.736907] ffffacf481847c80 ffffffffae3dce7e ffffacf481847cd0 0000000000000000
[ 410.736909] ffffacf481847cc0 ffffffffae0a116b 0000001dae0b9cac ffff931f8fb78000
[ 410.736910] ffffacf481847d78 ffff931f8fb78000 ffff931f8fb78000 0000000000000000
[ 410.736912] Call Trace:
[ 410.736916] [<ffffffffae3dce7e>] dump_stack+0x63/0x85
[ 410.736918] [<ffffffffae0a116b>] __warn+0xcb/0xf0
[ 410.736920] [<ffffffffae0a11ef>] warn_slowpath_fmt+0x5f/0x80
[ 410.736921] [<ffffffffae3fc362>] __list_add+0x62/0xb0
[ 410.736923] [<ffffffffae3ba108>] blk_mq_process_rq_list+0x258/0x350
[ 410.736925] [<ffffffffae3ba289>] __blk_mq_run_hw_queue+0x89/0x90
[ 410.736926] [<ffffffffae3ba2d2>] blk_mq_run_work_fn+0x12/0x20
[ 410.736928] [<ffffffffae0bb1bf>] process_one_work+0x15f/0x430
[ 410.736929] [<ffffffffae0bb4de>] worker_thread+0x4e/0x490
[ 410.736931] [<ffffffffae0bb490>] ? process_one_work+0x430/0x430
[ 410.736932] [<ffffffffae0bb490>] ? process_one_work+0x430/0x430
[ 410.736934] [<ffffffffae003c27>] ? do_syscall_64+0x67/0x180
[ 410.736936] [<ffffffffae0c0d09>] kthread+0xd9/0xf0
[ 410.736937] [<ffffffffae0c0c30>] ? kthread_park+0x60/0x60
[ 410.736940] [<ffffffffae81dc15>] ret_from_fork+0x25/0x30
[ 410.736941] ---[ end trace 0d9c0b78654a9c5e ]---
[ 410.736942] ------------[ cut here ]-----------
[ 436.159108] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [kworker/2:1H:577]
[ 436.159126] Modules linked in: nvme nvme_core nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw ip6table_mangle iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw iptable_mangle ebtable_filter ebtables ip6table_filter ip6_tables vfat fat
[ 436.159138] CPU: 2 PID: 577 Comm: kworker/2:1H Tainted: G W 4.9.0-rc1+ #28
[ 436.159138] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD5H/Z97X-UD5H, BIOS F8 06/17/2014
[ 436.159142] Workqueue: kblockd blk_mq_run_work_fn
[ 436.159143] task: ffff931f95411d80 task.stack: ffffacf481844000
[ 436.159143] RIP: 0010:[<ffffffffae3b7f11>] [<ffffffffae3b7f11>] __blk_mq_free_request+0x31/0x50
[ 436.159145] RSP: 0018:ffffacf481847d08 EFLAGS: 00000246
[ 436.159146] RAX: ffff931f8fb78000 RBX: ffff931f8f9f8000 RCX: 0000000000010000
[ 436.159146] RDX: 0000000000000040 RSI: ffffccf47fc81800 RDI: ffff931f8da45c00
[ 436.159147] RBP: ffffacf481847d10 R08: 0000000000000000 R09: ffff931f8fb78000
[ 436.159147] R10: 0000000000000000 R11: 0000000000000015 R12: 00000000fffffffb
[ 436.159147] R13: ffffacf481847d88 R14: ffff931f8fb78000 R15: 0000000000000000
[ 436.159148] FS: 0000000000000000(0000) GS:ffff931f9fa80000(0000) knlGS:0000000000000000
[ 436.159148] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 436.159149] CR2: 000055dab2dc8b70 CR3: 000000009de06000 CR4: 00000000001406e0
[ 436.159149] Stack:
[ 436.159150] ffff931f8fb78000 ffffacf481847d20 ffffffffae3b7f6d ffffacf481847d30
[ 436.159151] ffffffffae3b7fa2 ffffacf481847d50 ffffffffae3b8d93 ffff931f8da45c00
[ 436.159152] ffffacf481847d78 ffffacf481847de0 ffffffffae3ba1db ffff931f8f9f8000
[ 436.159153] Call Trace:
[ 436.159155] [<ffffffffae3b7f6d>] blk_mq_free_hctx_request+0x3d/0x40
[ 436.159156] [<ffffffffae3b7fa2>] blk_mq_free_request+0x32/0x40
[ 436.159157] [<ffffffffae3b8d93>] blk_mq_end_request+0x53/0x70
[ 436.159158] [<ffffffffae3ba1db>] blk_mq_process_rq_list+0x32b/0x350
[ 436.159159] [<ffffffffae3ba289>] __blk_mq_run_hw_queue+0x89/0x90
[ 436.159160] [<ffffffffae3ba2d2>] blk_mq_run_work_fn+0x12/0x20
[ 436.159162] [<ffffffffae0bb1bf>] process_one_work+0x15f/0x430
[ 436.159163] [<ffffffffae0bb4de>] worker_thread+0x4e/0x490
[ 436.159164] [<ffffffffae0bb490>] ? process_one_work+0x430/0x430
[ 436.159165] [<ffffffffae0bb490>] ? process_one_work+0x430/0x430
[ 436.159166] [<ffffffffae003c27>] ? do_syscall_64+0x67/0x180
[ 436.159168] [<ffffffffae0c0d09>] kthread+0xd9/0xf0
[ 436.159169] [<ffffffffae0c0c30>] ? kthread_park+0x60/0x60
[ 436.159171] [<ffffffffae81dc15>] ret_from_fork+0x25/0x30
[ 436.159172] Code: 89 d0 55 f6 40 4b 20 48 89 e5 53 8b 92 00 01 00 00 48 8b 58 30 74 07 f0 ff 8f e0 01 00 00 48 c7 40 48 00 00 00 00 f0 80 60 50 fd <e8> ba 47 00 00 48 89 df e8 d2 70 ff ff 5b 5d c3 66 66 66 66 66
^ permalink raw reply
* Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers
From: Stefan Richter @ 2016-10-19 22:38 UTC (permalink / raw)
To: Sabrina Dubroca, Jarod Wilson
Cc: linux-kernel, netdev, Faisal Latif, linux-rdma, Cliff Whickman,
Robin Holt, Jes Sorensen, Marek Lindner, Simon Wunderlich,
Antonio Quartulli
In-Reply-To: <20161019160546.GC11224@bistromath.localdomain>
On Oct 19 Sabrina Dubroca wrote:
> 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
> [...]
> > diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
> > index 309311b..b5f125c 100644
> > --- a/drivers/firewire/net.c
> > +++ b/drivers/firewire/net.c
> > @@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
> > return NETDEV_TX_OK;
> > }
> >
> > -static int fwnet_change_mtu(struct net_device *net, int new_mtu)
> > -{
> > - if (new_mtu < 68)
> > - return -EINVAL;
> > -
> > - net->mtu = new_mtu;
> > - return 0;
> > -}
> > -
>
> This doesn't do any upper bound checking.
I need to check more closely, but I think the RFC 2734 encapsulation spec
and our implementation do not impose a particular upper limit. Though I
guess it's bad to let userland set arbitrarily large values here.
> > static const struct ethtool_ops fwnet_ethtool_ops = {
> > .get_link = ethtool_op_get_link,
> > };
> > @@ -1366,7 +1357,6 @@ static const struct net_device_ops fwnet_netdev_ops = {
> > .ndo_open = fwnet_open,
> > .ndo_stop = fwnet_stop,
> > .ndo_start_xmit = fwnet_tx,
> > - .ndo_change_mtu = fwnet_change_mtu,
> > };
> >
> > static void fwnet_init_dev(struct net_device *net)
> > @@ -1481,6 +1471,8 @@ static int fwnet_probe(struct fw_unit *unit,
> > max_mtu = (1 << (card->max_receive + 1))
> > - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> > net->mtu = min(1500U, max_mtu);
> > + net->min_mtu = ETH_MIN_MTU;
> > + net->max_mtu = net->mtu;
>
> But that will now prevent increasing the MTU above the initial value?
Indeed, therefore NAK.
PS:
If the IP packet plus encapsulation header fits into IEEE 1394 packet
payload, it is transported without link fragmentation. If it does not
fit, link fragmentation occurs (which reduces bandwidth a bit and
consumes additional buffering resources at the transmitter and the
receiver).
Broadcast and multicast packets are transmitted via IEEE 1394 asynchronous
stream packets at a low bus speed (because our code does not attempt to
find the maximum speed and size that is supported by all potential
listeners). This limits the payload to 512 bytes.
Unicast packets are transmitted via IEEE 1394 asynchronous write request
packets at optimum speed. In most cases, this means that 2048 bytes
payload is possible, in some cases 4096 bytes. Many CardBus FireWire
cards support only 1024 bytes payload of these packets though.
Furthermore, some low-speed long-haul cablings may cap the bus speed and
thereby the payload size to 1024 or 512 bytes, but this is uncommon in
practice.
--
Stefan Richter
-======----- =-=- =-=--
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 0/3] iopmem : A block device for PCIe memory
From: Stephen Bates @ 2016-10-19 22:54 UTC (permalink / raw)
To: Dan Williams
Cc: linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma, linux-block, Linux MM, Ross Zwisler, Matthew Wilcox,
Jason Gunthorpe, haggaie, Christoph Hellwig, Jens Axboe,
Jonathan Corbet, jim.macdonald, sbates, Logan Gunthorpe,
David Woodhouse, Raj, Ashok
In-Reply-To: <CAPcyv4ht=ZtQOyUp8khzzJtZhWcsaCgQi=feEuaj1AY3f9wd=g@mail.gmail.com>
> >>
> >> If you're only using the block-device as a entry-point to create
> >> dax-mappings then a device-dax (drivers/dax/) character-device might
> >> be a better fit.
> >>
> >
> > We chose a block device because we felt it was intuitive for users to
> > carve up a memory region but putting a DAX filesystem on it and creating
> > files on that DAX aware FS. It seemed like a convenient way to
> > partition up the region and to be easily able to get the DMA address
> > for the memory backing the device.
> >
> > That said I would be very keen to get other peoples thoughts on how
> > they would like to see this done. And I know some people have had some
> > reservations about using DAX mounted FS to do this in the past.
>
> I guess it depends on the expected size of these devices BARs, but I
> get the sense they may be smaller / more precious such that you
> wouldn't want to spend capacity on filesystem metadata? For the target
> use case is it assumed that these device BARs are always backed by
> non-volatile memory? Otherwise this is a mkfs each boot for a
> volatile device.
Dan
Fair point and this is a concern I share. We are not assuming that all
iopmem devices are backed by non-volatile memory so the mkfs
recreation comment is valid. All in all I think you are persuading us
to take a look at /dev/dax ;-). I will see if anyone else chips in
with their thoughts on this.
>
> >>
> >> > 2. Memory Segment Spacing. This patch has the same limitations that
> >> > ZONE_DEVICE does in that memory regions must be spaces at least
> >> > SECTION_SIZE bytes part. On x86 this is 128MB and there are cases where
> >> > BARs can be placed closer together than this. Thus ZONE_DEVICE would not
> >> > be usable on neighboring BARs. For our purposes, this is not an issue as
> >> > we'd only be looking at enabling a single BAR in a given PCIe device.
> >> > More exotic use cases may have problems with this.
> >>
> >> I'm working on patches for 4.10 to allow mixing multiple
> >> devm_memremap_pages() allocations within the same physical section.
> >> Hopefully this won't be a problem going forward.
> >>
> >
> > Thanks Dan. Your patches will help address the problem of how to
> > partition a /dev/dax device but they don't help the case then BARs
> > themselves are small, closely spaced and non-segment aligned. However
> > I think most people using iopmem will want to use reasonbly large
> > BARs so I am not sure item 2 is that big of an issue.
>
> I think you might have misunderstood what I'm proposing. The patches
> I'm working on are separate from a facility to carve up a /dev/dax
> device. The effort is to allow devm_memremap_pages() to maintain
> several allocations within the same 128MB section. I need this for
> persistent memory to handle platforms that mix pmem and system-ram in
> the same section. I want to be able to map ZONE_DEVICE pages for a
> portion of a section and be able to remove portions of section that
> may collide with allocations of a different lifetime.
Oh I did misunderstand. This is very cool and would be useful to us.
One more reason to consider moving to /dev/dax in the next spin of
this patchset ;-).
Thanks
Stephen
^ permalink raw reply
* RE: [PATCH rdma-core 2/4] glue/redhat: add udev/systemd/etc infrastructure bits
From: Weiny, Ira @ 2016-10-19 22:55 UTC (permalink / raw)
To: Weiny, Ira, Jason Gunthorpe
Cc: Jarod Wilson, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Doug Ledford, Hefty, Sean
In-Reply-To: <2807E5FD2F6FDA4886F6618EAC48510E24F0E288-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
Nevermind I think I have it...
Just need to test with an rpm build...
Ira
> -----Original Message-----
> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Weiny, Ira
> Sent: Wednesday, October 19, 2016 2:35 PM
> To: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> Cc: Jarod Wilson <jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Doug
> Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>; Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Subject: RE: [PATCH rdma-core 2/4] glue/redhat: add udev/systemd/etc
> infrastructure bits
>
> Udev below works great. Thanks!
>
> But I have another cmake question.
>
> I have specified the following:
>
> install(FILES rdma-ndd.conf DESTINATION "${CMAKE_INSTALL_SYSCONFDIR}")
> set(rdma_ndd_CONFIG_PATH "${CMAKE_INSTALL_SYSCONFDIR}")
> configure_file ("${PROJECT_SOURCE_DIR}/rdma-ndd/rdma-config.h.in"
> "${PROJECT_BINARY_DIR}/rdma-ndd/rdma-config.h")
> include_directories("${PROJECT_BINARY_DIR}/rdma-ndd")
>
> The idea here is to have an rdma-ndd.conf file which allows the user to
> configure their names. (previously this was the infiniband-diags.conf file). But I
> have ported over the code.
>
> The value in rdma-config.h ends up being:
>
> 17:30:34 > cat build/rdma-ndd/rdma-config.h
> /* Pick up configuration items from cmake */ #define
> RDMA_NDD_CONFIG_PATH "etc"
> #define PACKAGE_VERSION 11
>
> Which seems fine but after a "make install" I'm left with an incorrect path:
>
> [root@phcppriv13 sbin]# pwd && ./rdma-ndd -f /usr/local/sbin
> rdma-ndd[91656]: Using config file (etc/rdma-ndd.conf) ...
>
> So it is not reading the correct config file.
>
> How do I link the install to this variable in the code?
>
> Ira
>
>
> > -----Original Message-----
> > From: Jason Gunthorpe [mailto:jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org]
> > Sent: Wednesday, October 19, 2016 11:59 AM
> > To: Weiny, Ira <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Cc: Jarod Wilson <jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Doug
> > Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>; Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Subject: Re: [PATCH rdma-core 2/4] glue/redhat: add udev/systemd/etc
> > infrastructure bits
> >
> > On Wed, Oct 19, 2016 at 06:38:52PM +0000, Weiny, Ira wrote:
> >
> > > I have the C code ported to rdma-core but how do I do this in cmake?
> >
> > Attached, you will also need
> >
> > target_link_libraries(rdma-ndd ${UDEV_LIBRARIES})
> >
> > > PKG_CHECK_EXISTS(libudev >= 218, [with_dev_logging=no],
> > > [with_udev_logging=yes])
> > > if test "$with_udev_logging" = "yes"; then
> > > AC_DEFINE_UNQUOTED([HAVE_UDEV_LOGGING], 1,
> > > [whether libudev logging can be
> > > used])
> >
> > Dump HAVE_UDEV_LOGGING from the code, upstream deleted support for it:
> >
> > https://www.redhat.com/archives/libvir-list/2014-December/msg00749.htm
> > l
> >
> > src.c:3:2: warning: 'udev_set_log_fn' is deprecated (declared at
> > /usr/include/libudev.h:41) [-Wdeprecated-declarations]
> > int main(int argc,const char *argv[]) {udev_set_log_fn(NULL, NULL); return
> 0;}
> > ^
> >
> > > I've found a "modules" file which looks like it has a compatible BSD
> > > license and could be added but is there a better way?
> >
> > Basically the right idea, but I prefer to avoid pkgconfig whenever
> > possible as it screws up cross compiling.
> >
> > > I also have to convert the man page from *.rst to man in some way...
> > > Would it be ok if I put a dependency on rst2man in the repo?
> >
> > We have talked about it, maybe for now just include both the .rst and
> > the rst2man output and we can revisit it..
> >
> > Jason
> >
> > From b0062acc238e06289aa946dacd5c534cf6c68d7d Mon Sep 17 00:00:00
> > 2001
> > From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> > Date: Wed, 19 Oct 2016 12:57:25 -0600
> > Subject: [PATCH] Add a dependency on libudev
> >
> > incomplete, needs the RH stuff too.
> >
> > Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> > ---
> > .travis.yml | 1 +
> > CMakeLists.txt | 4 ++++
> > README.md | 2 +-
> > buildlib/FindUDev.cmake | 10 ++++++++++
> > debian/control | 1 +
> > 5 files changed, 17 insertions(+), 1 deletion(-) create mode 100644
> > buildlib/FindUDev.cmake
> >
> > diff --git a/.travis.yml b/.travis.yml index
> > d81b699294eb..d9c36cc9c649 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -24,6 +24,7 @@ addons:
> > - gcc-6
> > - libnl-3-dev
> > - libnl-route-3-dev
> > + - libudev-dev
> > - make
> > - ninja-build
> > - pkg-config
> > diff --git a/CMakeLists.txt b/CMakeLists.txt index
> > a23aa860e6d3..9402bacf70ce
> > 100644
> > --- a/CMakeLists.txt
> > +++ b/CMakeLists.txt
> > @@ -237,6 +237,10 @@ if (NOT NL_KIND EQUAL 0)
> > set(CMAKE_REQUIRED_INCLUDES
> "${SAFE_CMAKE_REQUIRED_INCLUDES}")
> > endif()
> >
> > +# udev
> > +find_package(UDev REQUIRED)
> > +include_directories(${UDEV_INCLUDE_DIRS})
> > +
> > # Statically determine sizeof(long), this is largely unnecessary, no
> > new code # should rely on this.
> > check_type_size("long" SIZEOF_LONG BUILTIN_TYPES_ONLY LANGUAGE C)
> > diff --git a/README.md b/README.md index 66aee3f49f00..d24fd0bf2606
> > 100644
> > --- a/README.md
> > +++ b/README.md
> > @@ -48,7 +48,7 @@ only load from the system path.
> > ### Debian Derived
> >
> > ```sh
> > -$ apt-get install build-essential cmake gcc libnl-3-dev
> > libnl-route-3-dev ninja- build pkg-config valgrind
> > +$ apt-get install build-essential cmake gcc libudev-dev libnl-3-dev
> > +libnl-route-3-dev ninja-build pkg-config valgrind
> > ```
> >
> > ### Fedora
> > diff --git a/buildlib/FindUDev.cmake b/buildlib/FindUDev.cmake new
> > file mode
> > 100644 index 000000000000..ce05ddf991a1
> > --- /dev/null
> > +++ b/buildlib/FindUDev.cmake
> > @@ -0,0 +1,10 @@
> > +# COPYRIGHT (c) 2016 Obsidian Research Corporation. See COPYING file
> > +
> > +find_library(LIBUDEV_LIBRARY NAMES udev libudev)
> > +
> > +set(UDEV_LIBRARIES ${LIBUDEV_LIBRARY})
> > +
> > +include(FindPackageHandleStandardArgs)
> > +find_package_handle_standard_args(UDev REQUIRED_VARS
> > LIBUDEV_LIBRARY)
> > +
> > +mark_as_advanced(LIBUDEV_LIBRARY)
> > diff --git a/debian/control b/debian/control index
> > 2335d1f4814d..ed9850a348be 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -8,6 +8,7 @@ Build-Depends: build-essential,
> > dh-systemd,
> > dpkg-dev (>= 1.17),
> > gcc,
> > + libudev-dev,
> > libnl-3-dev,
> > libnl-route-3-dev,
> > make,
> > --
> > 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body
> of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 04/11] blk-mq: Introduce blk_mq_quiesce_queue()
From: Ming Lei @ 2016-10-19 23:47 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jens Axboe, Christoph Hellwig, James Bottomley,
Martin K. Petersen, Mike Snitzer, Doug Ledford, Keith Busch,
Laurence Oberman, linux-block@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-nvme@lists.infradead.org
In-Reply-To: <0718ec72-d525-2e75-a123-3bf9ea129319@sandisk.com>
On Thu, Oct 20, 2016 at 5:04 AM, Bart Van Assche
<bart.vanassche@sandisk.com> wrote:
> On 10/18/2016 02:50 PM, Bart Van Assche wrote:
>>
>> blk_mq_quiesce_queue() waits until ongoing .queue_rq() invocations
>> have finished. This function does *not* wait until all outstanding
>> requests have finished (this means invocation of request.end_io()).
>
>
> (replying to my own e-mail)
>
> The zero-day kernel test infrastructure reported to me that this patch
> causes a build failure with CONFIG_SRCU=n. Should I add "select SRCU" to
> block/Kconfig (excludes TINY_RCU) or should I rather modify this patch such
Select SRCU is fine, and you can see it is done in lots of
places(btrfs, net, quota, kvm, power,...)
> that a mutex or rwsem is used instead of SRCU?
Both should be much worse than SRCU, even not as good as atomic_t.
Thanks,
Ming
>
> Thanks,
>
> Bart.
>
--
Ming Lei
^ permalink raw reply
* Re: [PATCH v3 01/11] blk-mq: Do not invoke .queue_rq() for a stopped queue
From: Ming Lei @ 2016-10-19 23:48 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jens Axboe, Christoph Hellwig, James Bottomley,
Martin K. Petersen, Mike Snitzer, Doug Ledford, Keith Busch,
Ming Lin, Laurence Oberman,
linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <595d4b59-3892-ef24-ef91-b7cab6611af7-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
On Wed, Oct 19, 2016 at 5:48 AM, Bart Van Assche
<bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> wrote:
> The meaning of the BLK_MQ_S_STOPPED flag is "do not call
> .queue_rq()". Hence modify blk_mq_make_request() such that requests
> are queued instead of issued if a queue has been stopped.
>
> Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Cc: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> Cc: Hannes Reinecke <hare-IBi9RG/b67k@public.gmane.org>
> Cc: Sagi Grimberg <sagi-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
> Cc: Johannes Thumshirn <jthumshirn-l3A5Bk7waGM@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Reviewed-by: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> block/blk-mq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index ddc2eed..b5dcafb 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1332,9 +1332,9 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
> blk_mq_put_ctx(data.ctx);
> if (!old_rq)
> goto done;
> - if (!blk_mq_direct_issue_request(old_rq, &cookie))
> - goto done;
> - blk_mq_insert_request(old_rq, false, true, true);
> + if (test_bit(BLK_MQ_S_STOPPED, &data.hctx->state) ||
> + blk_mq_direct_issue_request(old_rq, &cookie) != 0)
> + blk_mq_insert_request(old_rq, false, true, true);
> goto done;
> }
>
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 0/11] Fix race conditions related to stopping block layer queues
From: Bart Van Assche @ 2016-10-19 23:51 UTC (permalink / raw)
To: Keith Busch
Cc: Jens Axboe, Christoph Hellwig, James Bottomley,
Martin K. Petersen, Mike Snitzer, Doug Ledford, Ming Lin,
Laurence Oberman, linux-block@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-nvme@lists.infradead.org
In-Reply-To: <20161019222454.GA1215@localhost.localdomain>
On 10/19/2016 03:14 PM, Keith Busch wrote:
> I'm running linux 4.9-rc1 + linux-block/for-linus, and alternating tests
> with and without this series.
>
> Without this, I'm not seeing any problems in a link-down test while
> running fio after ~30 runs.
>
> With this series, I only see the test pass infrequently. Most of the
> time I observe one of several failures. In all cases, it looks like the
> rq->queuelist is in an unexpected state.
>
> I think I've almost got this tracked down, but I have to leave for the
> day soon. Rather than having a more useful suggestion, I've put the two
> failures below.
>
> First failure:
>
> [ 214.782098] kernel BUG at block/blk-mq.c:498!
Hello Keith,
Thank you for having taken the time to test this patch series. Since I
think that the second and third failures are consequences of the first,
I will focus on the first failure triggered by your tests.
I assume that line 498 in blk-mq.c corresponds to
BUG_ON(blk_queued_rq(rq))? Anyway, it seems to me like this is a bug in
the NVMe code and also that this bug is completely unrelated to my patch
series. In nvme_complete_rq() I see that blk_mq_requeue_request() is
called. I don't think this is allowed from the context of
nvme_cancel_request() because blk_mq_requeue_request() assumes that a
request has already been removed from the request list. However, neither
blk_mq_tagset_busy_iter() nor nvme_cancel_request() remove a request
from the request list before nvme_complete_rq() is called. I think this
is what triggers the BUG_ON() statement in blk_mq_requeue_request().
Have you noticed that e.g. the scsi-mq code only calls
blk_mq_requeue_request() after __blk_mq_end_request() has finished? Have
you considered to follow the same approach in nvme_cancel_request()?
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers
From: Jarod Wilson @ 2016-10-20 3:16 UTC (permalink / raw)
To: Stefan Richter
Cc: Sabrina Dubroca, linux-kernel, netdev, Faisal Latif, linux-rdma,
Cliff Whickman, Robin Holt, Jes Sorensen, Marek Lindner,
Simon Wunderlich, Antonio Quartulli
In-Reply-To: <20161020003846.64f85f7e@kant>
On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:
> On Oct 19 Sabrina Dubroca wrote:
> > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
> > [...]
> > > diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
> > > index 309311b..b5f125c 100644
> > > --- a/drivers/firewire/net.c
> > > +++ b/drivers/firewire/net.c
> > > @@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
> > > return NETDEV_TX_OK;
> > > }
> > >
> > > -static int fwnet_change_mtu(struct net_device *net, int new_mtu)
> > > -{
> > > - if (new_mtu < 68)
> > > - return -EINVAL;
> > > -
> > > - net->mtu = new_mtu;
> > > - return 0;
> > > -}
> > > -
> >
> > This doesn't do any upper bound checking.
>
> I need to check more closely, but I think the RFC 2734 encapsulation spec
> and our implementation do not impose a particular upper limit. Though I
> guess it's bad to let userland set arbitrarily large values here.
In which case, that would suggest using IP_MAX_MTU (65535) here.
> > > static const struct ethtool_ops fwnet_ethtool_ops = {
> > > .get_link = ethtool_op_get_link,
> > > };
> > > @@ -1366,7 +1357,6 @@ static const struct net_device_ops fwnet_netdev_ops = {
> > > .ndo_open = fwnet_open,
> > > .ndo_stop = fwnet_stop,
> > > .ndo_start_xmit = fwnet_tx,
> > > - .ndo_change_mtu = fwnet_change_mtu,
> > > };
> > >
> > > static void fwnet_init_dev(struct net_device *net)
> > > @@ -1481,6 +1471,8 @@ static int fwnet_probe(struct fw_unit *unit,
> > > max_mtu = (1 << (card->max_receive + 1))
> > > - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> > > net->mtu = min(1500U, max_mtu);
> > > + net->min_mtu = ETH_MIN_MTU;
> > > + net->max_mtu = net->mtu;
> >
> > But that will now prevent increasing the MTU above the initial value?
>
> Indeed, therefore NAK.
However, there's an explicit calculation for 'max_mtu' right there that I
glazed right over. It would seem perhaps *that* should be used for
net->max_mtu here, no?
> PS:
> If the IP packet plus encapsulation header fits into IEEE 1394 packet
> payload, it is transported without link fragmentation. If it does not
> fit, link fragmentation occurs (which reduces bandwidth a bit and
> consumes additional buffering resources at the transmitter and the
> receiver).
>
> Broadcast and multicast packets are transmitted via IEEE 1394 asynchronous
> stream packets at a low bus speed (because our code does not attempt to
> find the maximum speed and size that is supported by all potential
> listeners). This limits the payload to 512 bytes.
>
> Unicast packets are transmitted via IEEE 1394 asynchronous write request
> packets at optimum speed. In most cases, this means that 2048 bytes
> payload is possible, in some cases 4096 bytes. Many CardBus FireWire
> cards support only 1024 bytes payload of these packets though.
> Furthermore, some low-speed long-haul cablings may cap the bus speed and
> thereby the payload size to 1024 or 512 bytes, but this is uncommon in
> practice.
Thorough as always, Stefan! :)
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox