Jens / James, do you guys plan to send this to Linus for 3.11?
Triggering this bug is a bit esoteric but the impact is pretty nasty
(corrupting an unrelated process).
Thanks,
Roland
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to
Add Infra-structure to support extended uverbs capabilities in a
forward/backward
manner. Uverbs command opcodes which are based on the verbs extensions
approach should
be greater or equal to IB_USER_VERBS_CMD_THRESHOLD. They have new header
format
and processed a bit differently.
On Wed, Aug 7, 2013 at 9:31 AM, Douglas Gilbert wrote:
> So what kind of signal was leading to your "stomping on the memory"?
> Was it user generated or something like SIGIO, SIGPIPE or a RT signal?
It was sometimes SIGHUP (for reopening log files) and sometimes
SIGALARM (for various periodic
On Wed, Aug 7, 2013 at 9:31 AM, Douglas Gilbert dgilb...@interlog.com wrote:
So what kind of signal was leading to your stomping on the memory?
Was it user generated or something like SIGIO, SIGPIPE or a RT signal?
It was sometimes SIGHUP (for reopening log files) and sometimes
SIGALARM (for
On Wed, Aug 7, 2013 at 9:31 AM, Douglas Gilbert dgilb...@interlog.com wrote:
So what kind of signal was leading to your stomping on the memory?
Was it user generated or something like SIGIO, SIGPIPE or a RT signal?
It was sometimes SIGHUP (for reopening log files) and sometimes
SIGALARM (for
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn wrote:
> I was able to succesfully test this patch overnight, I had been experimenting
> with the
> sg driver setting the BIO_NULL_MAPPED flag in sg_rq_end_io_usercontext for a
> orphan process
> which prevented the corruption, but your solution
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn dmilb...@redhat.com wrote:
I was able to succesfully test this patch overnight, I had been experimenting
with the
sg driver setting the BIO_NULL_MAPPED flag in sg_rq_end_io_usercontext for a
orphan process
which prevented the corruption, but
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn dmilb...@redhat.com wrote:
I was able to succesfully test this patch overnight, I had been experimenting
with the
sg driver setting the BIO_NULL_MAPPED flag in sg_rq_end_io_usercontext for a
orphan process
which prevented the corruption, but
On Tue, Aug 6, 2013 at 6:14 AM, Or Gerlitz or.gerl...@gmail.com wrote:
Any time estimate for when you start accepting 3.12 patches into your
for-next branch?
No.
- R.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
On Tue, Aug 6, 2013 at 8:03 AM, Or Gerlitz or.gerl...@gmail.com wrote:
Could you finally-long-lastish post some comments on how you see this?
any bugs or flames you find here, is this going to be accepted? when?
Have you read the patches? Any comments?
- R.
--
To unsubscribe from this list:
On Tue, Aug 6, 2013 at 8:34 AM, Vipul Pandya vi...@chelsio.com wrote:
This series is on top of previously submitted series Add IPv6 support for
iWARP which can be found at following location:
http://comments.gmane.org/gmane.linux.network/272124
We request Roland to merge above series first
From: Roland Dreier
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process issues an SG_IO ioctl
bio_free_map_data(bmd);
> bio_put(bio);
> return ret;
Yes, looks reasonable -- I can't think of any reason why anyone would
ever want the bio code to copy to a random userspace address space.
Acked-by: Roland Dreier
--
To unsubscribe from this list: send the line
From: Roland Dreier
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process issues an SG_IO ioctl
From: Roland Dreier rol...@purestorage.com
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process
to copy to a random userspace address space.
Acked-by: Roland Dreier rol...@purestorage.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
From: Roland Dreier rol...@purestorage.com
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process
On Sat, Aug 3, 2013 at 3:12 PM, Or Gerlitz or.gerl...@gmail.com wrote:
OK, Roland, I see that you didn't pick this for 3.11, probably as you
consider this non-fix, well the patches makes the initiator to avoid
bounce buffer for IOs 4K, which saves kernel memory and CPU - which
I think can be
On Wed, Jul 17, 2013 at 10:57 AM, Doug Ledford dledf...@redhat.com wrote:
- doing it this way preserves ABI, so existing binaries are safe
I still don't get this. Wouldn't an existing binary be pretty
surprised to get a value wildly out of range of the enum?
Yes, but there's no way around
On Mon, Aug 5, 2013 at 12:02 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
Wouldn't the following be a better path forward:
- Add a new API (ibv_get_max_datagram_size() or some such) that
returns the real value as an int, based on the true MTU
- Have old query verbs continue to
On Mon, Aug 5, 2013 at 3:22 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
Okay, but if you want to narrow things to just be Jeff's application
like that, then do we even need this to be part of verbs?
IP path MTU should be discovered by a netlink routing query to lookup
the
From: Roland Dreier rol...@purestorage.com
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process
to copy to a random userspace address space.
Acked-by: Roland Dreier rol...@purestorage.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Roland Dreier rol...@purestorage.com
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process
contains the default pkey
Mike Marciniszyn (1):
IB/qib: Add err_decode() call for ring dump
Or Gerlitz (1):
IPoIB: Make sure child devices use valid/proper pkeys
Paul Bolle (1):
RDMA/cma: Fix gcc warning
Roland Dreier (3):
RDMA/ocrdma: Remove unused include
Revert
contains the default pkey
Mike Marciniszyn (1):
IB/qib: Add err_decode() call for ring dump
Or Gerlitz (1):
IPoIB: Make sure child devices use valid/proper pkeys
Paul Bolle (1):
RDMA/cma: Fix gcc warning
Roland Dreier (3):
RDMA/ocrdma: Remove unused include
Revert RDMA
Public bug reported:
Seems to be related to resume problems turning on the video outputg
ProblemType: KernelOops
DistroRelease: Ubuntu 13.10
Package: linux-image-3.10.0-6-generic 3.10.0-6.17
ProcVersionSignature: Ubuntu 3.10.0-6.17-generic 3.10.3
Uname: Linux 3.10.0-6-generic x86_64
Annotation:
contains the default pkey
Mike Marciniszyn (1):
IB/qib: Add err_decode() call for ring dump
Or Gerlitz (1):
IPoIB: Make sure child devices use valid/proper pkeys
Paul Bolle (1):
RDMA/cma: Fix gcc warning
Roland Dreier (3):
RDMA/ocrdma: Remove unused include
Revert RDMA
Public bug reported:
Seems to be related to resume problems turning on the video outputg
ProblemType: KernelOops
DistroRelease: Ubuntu 13.10
Package: linux-image-3.10.0-6-generic 3.10.0-6.17
ProcVersionSignature: Ubuntu 3.10.0-6.17-generic 3.10.3
Uname: Linux 3.10.0-6-generic x86_64
Annotation:
affecting me on a system upgraded from raring around saucy-alpha1.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1197395
Title:
/run/user/$ID/pulse owned by root and not by the
affecting me on a system upgraded from raring around saucy-alpha1.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1197395
Title:
/run/user/$ID/pulse owned by root and not by the user
To manage
Public bug reported:
might be relevant that I suspended undocked and then resumed docked.
ProblemType: KernelOops
DistroRelease: Ubuntu 13.10
Package: linux-image-3.10.0-3-generic 3.10.0-3.12
ProcVersionSignature: Ubuntu 3.10.0-3.12-generic 3.10.1
Uname: Linux 3.10.0-3-generic x86_64
Annotation:
On Tue, Jul 16, 2013 at 10:11 AM, Jeff Squyres (jsquyres)
jsquy...@cisco.com wrote:
- doing it this way preserves ABI, so existing binaries are safe
I still don't get this. Wouldn't an existing binary be pretty
surprised to get a value wildly out of range of the enum?
- R.
--
To unsubscribe
IB/qib: Add dual-rail NUMA awareness for PSM processes
Roland Dreier (6):
mlx5: Fix parameter type of health_handler_t
IB/mlx5: Make profile[] static in main.c
mlx5_core: Fixes for sparse warnings
IB/uverbs: Use get_unused_fd_flags(O_CLOEXEC) instead of get_unused_fd
IB/qib: Add dual-rail NUMA awareness for PSM processes
Roland Dreier (6):
mlx5: Fix parameter type of health_handler_t
IB/mlx5: Make profile[] static in main.c
mlx5_core: Fixes for sparse warnings
IB/uverbs: Use get_unused_fd_flags(O_CLOEXEC) instead of get_unused_fd
On Wed, Jul 10, 2013 at 7:35 AM, Sebastian Riemer
wrote:
>
> I've checked the commits on that tag and the following commit is not
> what we've agreed on:
Sorry about that. The discussion was long and complex and I probably
made a mistake in aplying the patches. Please me send a patch to fix
On Wed, Jul 10, 2013 at 7:35 AM, Sebastian Riemer
sebastian.rie...@profitbricks.com wrote:
I've checked the commits on that tag and the following commit is not
what we've agreed on:
Sorry about that. The discussion was long and complex and I probably
made a mistake in aplying the patches.
On Wed, Jul 10, 2013 at 7:35 AM, Sebastian Riemer
sebastian.rie...@profitbricks.com wrote:
I've checked the commits on that tag and the following commit is not
what we've agreed on:
Sorry about that. The discussion was long and complex and I probably
made a mistake in aplying the patches.
RDMA/ocrdma: Set bad_wr in error case
RDMA/ocrdma: Change macros to inline funtions
RDMA/ocrdma: Reorg structures to avoid padding
Ramkrishna Vepa (2):
IB/qib: Add optional NUMA affinity
IB/qib: Add dual-rail NUMA awareness for PSM processes
Roland Dreier (5):
mlx5
RDMA/ocrdma: Set bad_wr in error case
RDMA/ocrdma: Change macros to inline funtions
RDMA/ocrdma: Reorg structures to avoid padding
Ramkrishna Vepa (2):
IB/qib: Add optional NUMA affinity
IB/qib: Add dual-rail NUMA awareness for PSM processes
Roland Dreier (5):
mlx5
Thanks, I just applied a patch to convert to
get_unused_fd_flags(O_CLOEXEC) in uverbs, since there isn't anything
useful that can be done with uverbs fds across an exec.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Thanks, I just applied a patch to convert to
get_unused_fd_flags(O_CLOEXEC) in uverbs, since there isn't anything
useful that can be done with uverbs fds across an exec.
- R.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
[resending to reply-all, sorry Jeff]
On Mon, Jul 8, 2013 at 9:26 AM, Jeff Squyres (jsquyres)
jsquy...@cisco.com wrote:
So what happens if I have an old application binary, and I run against
a new libibverbs without recompiling?
Also it seems that I'm forced to change my source code to be able
Thanks, I just applied a patch to convert to
get_unused_fd_flags(O_CLOEXEC) in uverbs, since there isn't anything
useful that can be done with uverbs fds across an exec.
- R.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
On Tue, Jul 2, 2013 at 5:31 AM, Jeff Squyres jsquy...@cisco.com wrote:
Keep IBV_MTU_* enums values as they are, but pass MTU values around as
a struct containing a single int.
Per lengthy discusson on the linux-rdma list, this patch introdces a
source code incompatibility. Although legacy
On Wed, Jul 3, 2013 at 9:41 AM, Or Gerlitz ogerl...@mellanox.com wrote:
Jack looked on this comment/code and he says that the active flag is used
to prevent re-scheduling the timer from inside the timer handling routine.
In the kernel, the comment header in the source file for del_timer_sync
In general I don't think overriding the CFLAGS (as you do in the mlx5
Makefiles) is a good idea, and in particular here your -Wall -Werror
break the build, at least for my gcc 4.7.3:
CC drivers/infiniband/hw/mlx5/qp.o
/home/roland/Src/linux-merge.git/drivers/infiniband/hw/mlx5/qp.c: In
On Mon, Jul 1, 2013 at 11:03 AM, Joe Perches j...@perches.com wrote:
There's some value in block enabling/disabling messages
that dynamic_debug doesn't currently offer.
As far as I can see, the mlx5 stuff ends up being per-file. Which
dynamic debug already does offer.
- R.
--
To unsubscribe
Also, sparse warns about the following. It seems there's an endianness bug in
int mlx5_ib_umem_populate_pas(struct mlx5_ib_dev *dev, struct ib_umem *umem,
int npages, u64 *pas)
in mem.c, since it doesn't match what
void mlx5_ib_populate_pas(struct mlx5_ib_dev *dev, struct
From: Roland Dreier rol...@purestorage.com
Currently, the getopt table in osmtest labels the -guid option as
taking an optional argument; however, running osmtest with the -guid
option but no argument just leads to:
$ /usr/sbin/osmtest -guid
Command Line Arguments
Segmentation fault
On Thu, Jun 27, 2013 at 2:01 PM, David Dillow dillo...@ornl.gov wrote:
On Wed, 2013-06-12 at 15:20 +0200, Bart Van Assche wrote:
If the add_one callback fails during driver load no resources are
allocated so there isn't a need to release any resources. Trying
to clean the resource may lead to
On Wed, Jun 26, 2013 at 5:57 AM, Or Gerlitz ogerl...@mellanox.com wrote:
Add Infra-structure to support extended uverbs capabilities in a
forward/backward
manner. Uverbs command opcodes which are based on the verbs extensions
approach should
be greater or equal to
On Wed, Jun 19, 2013 at 12:47 AM, Or Gerlitz ogerl...@mellanox.com wrote:
Add Infra-structure to support extended uverbs capabilities in a
forward/backward
manner. Uverbs command opcodes which are based on the verbs extensions
approach should
be greater or equal to
On Tue, Jun 11, 2013 at 4:42 AM, Or Gerlitz ogerl...@mellanox.com wrote:
+struct ib_kern_flow {
+ struct ib_device *device;
+ struct ib_uobject *uobject;
+ void *flow_context;
+};
I don't think it makes sense to put a structure with kernel pointers
in it into
On Thu, Jun 20, 2013 at 7:48 AM, Christoph Lameter wrote:
> There is no way that user space can initiate a page pin right now. Perf is
> pinning the page from the kernel. Similarly the IB subsystem pins memory
> meeded for device I/O.
Christoph, your argument would be a lot more convincing if
On Thu, Jun 20, 2013 at 7:48 AM, Christoph Lameter c...@linux.com wrote:
There is no way that user space can initiate a page pin right now. Perf is
pinning the page from the kernel. Similarly the IB subsystem pins memory
meeded for device I/O.
Christoph, your argument would be a lot more
On Thu, Jun 20, 2013 at 7:48 AM, Christoph Lameter c...@linux.com wrote:
There is no way that user space can initiate a page pin right now. Perf is
pinning the page from the kernel. Similarly the IB subsystem pins memory
meeded for device I/O.
Christoph, your argument would be a lot more
On Thu, Jun 20, 2013 at 5:09 PM, Stephen Rothwell wrote:
> I noticed that the infiniband tree is now based on the net-next tree. I
> assume that is deliberate? I do have to question how much testing that
> tree has had since it is now based on a tree that Dave only released in
> the last 24
On Thu, Jun 20, 2013 at 5:09 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
I noticed that the infiniband tree is now based on the net-next tree. I
assume that is deliberate? I do have to question how much testing that
tree has had since it is now based on a tree that Dave only released in
On Thu, Jun 20, 2013 at 5:09 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
I noticed that the infiniband tree is now based on the net-next tree. I
assume that is deliberate? I do have to question how much testing that
tree has had since it is now based on a tree that Dave only released in
removal flow
Roland Dreier (1):
Merge branches 'iser' and 'qib' into for-next
MAINTAINERS | 10 ++
drivers/infiniband/hw/qib/qib_keys.c | 2 +-
drivers/infiniband/ulp/iser/iscsi_iser.c | 1 +
drivers/infiniband/ulp/iser/iscsi_iser.h
removal flow
Roland Dreier (1):
Merge branches 'iser' and 'qib' into for-next
MAINTAINERS | 10 ++
drivers/infiniband/hw/qib/qib_keys.c | 2 +-
drivers/infiniband/ulp/iser/iscsi_iser.c | 1 +
drivers/infiniband/ulp/iser/iscsi_iser.h
removal flow
Roland Dreier (1):
Merge branches 'iser' and 'qib' into for-next
MAINTAINERS | 10 ++
drivers/infiniband/hw/qib/qib_keys.c | 2 +-
drivers/infiniband/ulp/iser/iscsi_iser.c | 1 +
drivers/infiniband/ulp/iser/iscsi_iser.h
On Wed, Jun 5, 2013 at 1:50 AM, Gottumukkala, Naresh
b.a.l.nraju.gottumukk...@emulex.com wrote:
Can we get this patch approved from you ? Can you please let us know your
feedback ?
Yes, looks fine. I'll merge it for 3.11.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma
From: Roland Dreier rol...@purestorage.com
Suppose an initiator sends a DATA IN command with an allocation length
shorter than the FC transfer length -- we get a target message like
TARGET_CORE[qla2xxx]: Expected Transfer Length: 256 does not match SCSI CDB
Length: 0 for SAM Opcode: 0x12
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Thu, 30 May 2013 10:39:15 -0700
Source: libmlx4
Binary: libmlx4-1 libmlx4-dev libmlx4-1-dbg
Architecture: source amd64
Version: 1.0.5-1
Distribution: unstable
Urgency: low
Maintainer: Roland Dreier r...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 28 May 2013 09:31:54 -0700
Source: libibverbs
Binary: libibverbs1 libibverbs-dev libibverbs1-dbg ibverbs-utils
Architecture: source amd64
Version: 1.1.7-1
Distribution: unstable
Urgency: low
Maintainer: Roland Dreier rol
On Tue, May 28, 2013 at 10:51 AM, Jeff Squyres (jsquyres)
jsquy...@cisco.com wrote:
I see a ummunot branch on your kernel tree at git.kernel.org
(https://git.kernel.org/cgit/linux/kernel/git/roland/infiniband.git/log/?h=ummunot).
Just curious -- what's the status of this tree? I ask because,
to send UD messages larger than MTU
Don't print link phys state on iWARP
Jeff Squyres (2):
libibverbs: Use autoreconf in autogen.sh
.gitignore updates; rename configure.in-.ac
Or Gerlitz (1):
Add raw packet QP type
Roland Dreier (1):
Roll libibverbs 1.1.7 release
At LSF this year, we had a discussion about error handling and in
particular the problem that SCSI midlayer error handling waits for the
entire SCSI host (HBA) to quiesce before it starts to abort commands
etc.
James made the suggestion that FC should handle things the way SAS
does, because SAS
On Mon, May 20, 2013 at 2:43 PM, Yann Droneaud ydrone...@opteya.com wrote:
libibverbs must refuse to load arbitrary shared objects.
This patch check the configuration directory and files for
- being owned by root;
- not being writable by others.
uverbs is an unprivileged interface. Right
On Mon, May 20, 2013 at 7:53 AM, Jack Morgenstein
ja...@dev.mellanox.co.il wrote:
This is racy and can cause use-after-free, null pointer dereference, etc,
which
result in kernel crashes.
Sounds fine and I'd be happy to apply your final patch, but I'd be
curious to know what the race is in
On Mon, May 20, 2013 at 5:37 AM, Or Gerlitz ogerl...@mellanox.com wrote:
Following what we discussed last week during the Linux Foundation EU summit,
I think it would be good to follow what you said and have a point release for
libibverbs and libmlx4 before we pull in the verbs extensions
On Fri, May 17, 2013 at 12:25 PM, Tom Tucker t...@opengridcomputing.com wrote:
I'm looking at the Linux MLX4 net driver and found something that confuses me
mightily. In particular in the file net/ethernet/mellanox/mlx4/cq.c, the
mlx4_ib_completion function does not take any kind of lock when
informational messages from error to info level
Roland Dreier (1):
Merge branches 'cxgb4', 'ipoib', 'iser', 'misc', 'mlx4', 'qib' and 'srp'
into for-next
Shlomo Pongratz (3):
IB/core: Verify that QP handler is valid before dispatching events
mlx4_core: Implement SRQ object lookup from
informational messages from error to info level
Roland Dreier (1):
Merge branches 'cxgb4', 'ipoib', 'iser', 'misc', 'mlx4', 'qib' and 'srp'
into for-next
Shlomo Pongratz (3):
IB/core: Verify that QP handler is valid before dispatching events
mlx4_core: Implement SRQ object lookup from
informational messages from error to info level
Roland Dreier (1):
Merge branches 'cxgb4', 'ipoib', 'iser', 'misc', 'mlx4', 'qib' and 'srp'
into for-next
Shlomo Pongratz (3):
IB/core: Verify that QP handler is valid before dispatching events
mlx4_core: Implement SRQ object lookup from
On Wed, May 1, 2013 at 4:11 PM, Or Gerlitz or.gerl...@gmail.com wrote:
This was done over kernel 3.5.x, I will re-run tomorrow with latest
upstream and send the top perf hits for both cases, but does this
rings some bells? basically it makes sense for some extra latency, but
I didn't expect
On Wed, May 1, 2013 at 4:11 PM, Or Gerlitz or.gerl...@gmail.com wrote:
This was done over kernel 3.5.x, I will re-run tomorrow with latest
upstream and send the top perf hits for both cases, but does this
rings some bells? basically it makes sense for some extra latency, but
I didn't expect
Thanks, applied all 4.
I just moved and the box with some of my private keys etc. still needs
to be set up, so it will be a day or two until I get this pushed out
to kernel.org.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
On Thu, Apr 25, 2013 at 6:21 AM, Jan Kara j...@suse.cz wrote:
get_user_pages() actually goes to some trouble to return all small pages,
even when it has to split a single huge page into many entries in the
page array. (Which is actually a bit unfortunate for our use here)
Does it? As far
On Wed, Apr 24, 2013 at 8:38 AM, Jan Kara j...@suse.cz wrote:
when checking users of get_user_pages() (I'm doing some cleanups in that
area to fix filesystem's issues with mmap_sem locking) I've noticed that
infiniband drivers add number of pages obtained from get_user_pages() to
On Wed, Apr 17, 2013 at 12:10 PM, Eric Dumazet eduma...@google.com wrote:
+ prefetch(page_address(frag-page.p));
Would it also make sense to do a
prefetchw(skb-data);
here? (That's where we'll copy the header, right?)
--
To unsubscribe from this list: send the line
On Wed, Apr 17, 2013 at 11:06 AM, Randy Dunlap wrote:
> on x86_64:
>
> drivers/built-in.o: In function `isert_free_np':
> ib_isert.c:(.text+0x6e8a77): undefined reference to `rdma_destroy_id'
> drivers/built-in.o: In function `isert_conn_setup_qp':
> ib_isert.c:(.text+0x6e9038): undefined
On Wed, Apr 17, 2013 at 11:06 AM, Randy Dunlap rdun...@infradead.org wrote:
on x86_64:
drivers/built-in.o: In function `isert_free_np':
ib_isert.c:(.text+0x6e8a77): undefined reference to `rdma_destroy_id'
drivers/built-in.o: In function `isert_conn_setup_qp':
ib_isert.c:(.text+0x6e9038):
On Wed, Apr 17, 2013 at 11:06 AM, Randy Dunlap rdun...@infradead.org wrote:
on x86_64:
drivers/built-in.o: In function `isert_free_np':
ib_isert.c:(.text+0x6e8a77): undefined reference to `rdma_destroy_id'
drivers/built-in.o: In function `isert_conn_setup_qp':
ib_isert.c:(.text+0x6e9038):
On Wed, Apr 17, 2013 at 12:10 PM, Eric Dumazet eduma...@google.com wrote:
+ prefetch(page_address(frag-page.p));
I guess we would have to change our allocation to __get_free_page()
(instead of alloc_page()), so that we make sure never to get a highmem
page?
Other than that, seems
On Mon, Apr 15, 2013 at 2:10 PM, Wendy Cheng s.wendy.ch...@gmail.com wrote:
Before closing this thread . I see there is a clear warning in
IPOIB code that enabling connected mode will cause multicast packet to
drop. I assume this is due to message ordering requirement and the
multicast
On Tue, Apr 16, 2013 at 9:22 AM, Markus Stockhausen
markus.stockhau...@gmx.de wrote:
if I think about the current situation we can make it only better.
When receiving a packet on a 4K HCA we have to pull the IP header
into the linear part of the SKB during GRO handling. That consumes
extra CPU
On Tue, Apr 16, 2013 at 9:56 AM, Eric Dumazet eduma...@google.com wrote:
I am afraid I don't understand what the issue is.
the pull_tail() in itself is not a performance issue : Intel guys only
fixed last gays ago fact that IGB/IXGBE drivers were not pulling tcp
headers in skb-head , and
Thanks, applied all 3.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 9, 2013 at 12:52 PM, Markus Stockhausen
markus.stockhau...@gmx.de wrote:
IPOIB_UD_HEAD_SIZE = IB_GRH_BYTES + IPOIB_ENCAP_LEN + 3072
In my 2044 MTU case this brings the netperf NFS throughput to
the same levels as the dirty hack. Of course this no longer
reflects a head but
On Tue, Apr 9, 2013 at 6:13 AM, Luick, Dean dean.lu...@intel.com wrote:
Can you go through the else of the first if (page is NULL), then enter the
second if? If so, isn't the page lost?
Thanks, good catch. I'll fix that up.
--
To unsubscribe from this list: send the line unsubscribe
On Fri, Apr 5, 2013 at 1:44 PM, Roland Dreier rol...@kernel.org wrote:
Thanks. I guess I'll have to set up a testbed and debug this myself.
I'll try to work on that this weekend.
So I was able to reproduce the problem (or at least a problem) with
netpipe. Doing NPtcp -i -2 hit bad data pretty
On Mon, Apr 8, 2013 at 9:44 AM, Eric Dumazet eduma...@google.com wrote:
Am empty page in the frag list ? You mean a frag with a zero length ?
Yep... the code would do
skb_fill_page_desc(skb, 0, page, 0, PAGE_SIZE);
but then later on it did the equivalent of
skb_frag_size_set(frag, 0);
From: Roland Dreier rol...@purestorage.com
Markus Stockhausen markus.stockhau...@gmx.de noticed that IPoIB was
spending significant time doing memcpy() in __pskb_pull_tail(). He
found that this is because his adapter reports a maximum MTU of 4K,
which causes IPoIB datagram mode to receive all
On Mon, Apr 8, 2013 at 12:03 PM, Markus Stockhausen
markus.stockhau...@gmx.de wrote:
First I thought perfect memory allocation inside ipoib_alloc_rx_skb()
could be realized by passing the received packet size from function
ipoib_ib_handle_rx_wc(). But I'm unable to estimate the requirements
of
On Fri, Apr 5, 2013 at 1:51 PM, Michael R. Hines
wrote:
> Sorry, I was wrong. ignore the comments about cgroups. That's still broken.
> (i.e. trying to register RDMA memory while using a cgroup swap limit cause
> the process get killed).
>
> But the GIFT flag patch works (my understanding is that
On Fri, Apr 5, 2013 at 1:17 PM, Michael R. Hines
wrote:
> I also removed the IBV_*_WRITE flags on the sender-side and activated
> cgroups with the "memory.memsw.limit_in_bytes" activated and the migration
> with RDMA also succeeded without any problems (both with *and* without GIFT
> also
On Fri, Apr 5, 2013 at 1:17 PM, Michael R. Hines
mrhi...@linux.vnet.ibm.com wrote:
I also removed the IBV_*_WRITE flags on the sender-side and activated
cgroups with the memory.memsw.limit_in_bytes activated and the migration
with RDMA also succeeded without any problems (both with *and*
401 - 500 of 10769 matches
Mail list logo
