On Wed, 08 Nov 2006 15:08:30 -0800
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>
> > so... Is this:
> >
> > htirq-refactor-so-we-only-have-one-function-that-writes-to-the-chip.patch
> > htirq-allow-buggy-drivers-of-b
On Wed, 08 Nov 2006 14:21:26 -0700
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
> Eric's changes to the htirq infrastructure require corresponding
> modifications to the ipath HT driver code so that interrupts are still
> delivered properly.
>
> Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]
On Fri, 01 Sep 2006 14:05:36 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> Andrew> If the hardware/driver absolutely requires that the 64-bit
> Andrew> write be atomic on-the-bus then sure, the fix is to
> Andrew> disable that driver on that architecture in Kconfig.
>
> Andrew>
On Fri, 01 Sep 2006 13:51:32 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> Andrew> No, driver-specific workarounds are not legitimate, sorry.
>
> Andrew> The driver should simply fail to compile on architectures
> Andrew> which do not implement __raw_writeq().
>
> But how should i
On Fri, 1 Sep 2006 21:43:43 +0100
Russell King <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 01, 2006 at 01:04:44PM -0700, Andrew Morton wrote:
> > On Fri, 01 Sep 2006 12:53:47 -0700
> > Roland Dreier <[EMAIL PROTECTED]> wrote:
> > > Yes, I agree that's a goo
On Fri, 01 Sep 2006 12:53:47 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> Roland> My understanding is that __raw_writeq() is like writeq()
> Roland> except not strongly ordered and without the byte-swap on
> Roland> big-endian architectures. The __raw_writeX() variants are
> R
On Fri, 01 Sep 2006 10:34:24 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> Andrew> What's __raw_writeq() supposed to do, anyway? On alpha
> Andrew> it's writeq() without an mb(). On parisc it's writeq()
> Andrew> only the data is byte-reversed. On sparc64() it's
> Andrew> inc
On Fri, 1 Sep 2006 18:00:23 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm3:
> >...
> > +amso1100-build-fix.patch
> >
> > Fix git-infiniband.patch
On Thu, 13 Jul 2006 18:18:35 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Having the caller hold a chunk of memory in a stack variable was the
> > trick I came up with to get around that.
>
> Yes, that certainly works.
Problem is, I think, you'll need to p
On Thu, 13 Jul 2006 18:08:17 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> > Good point, a try-again loop would work. Do we really need the caller to
> > maintain a cache? I suspect something like
> >
> > drat:
> >if (idr_pre_get(GFP_KERNEL) == ENOMEM)
> >give_up();
>
On Thu, 13 Jul 2006 14:03:21 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> > I suspect it'll get really ugly. It's a container library which needs to
> > allocate memory when items are added, like the radix-tree. Either it needs
> > to assume GFP_ATOMIC, which is bad and can easily fail or
On Thu, 13 Jul 2006 08:42:47 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> > Sigh. It was always a mistake (of the kernel programming 101 type) to put
> > any locking at all in the idr code. At some stage we need to weed it all
> > out and move it to callers.
> >
> > Your fix is yet mor
On Wed, 12 Jul 2006 13:45:12 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> Currently, the code in lib/idr.c uses a bare spin_lock(&idp->lock) to
> do internal locking. This is a nasty trap for code that might call
> idr functions from different contexts; for example, it seems perfectly
> reaso
On Tue, 11 Jul 2006 01:19:02 +0300
"Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote:
> Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> > Yes, -mm seems like a good way to get more review.
>
> Andrew, am I using the right format to send things upstream to you?
> There's really a set of independ
On Sat, 1 Jul 2006 22:43:23 +0300
"Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote:
> Quoting r. Bryan O'Sullivan <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH 0 of 39] ipath - bug fixes, performanceenhancements,and
> > portability improvements
> >
> > On Fri, 2006-06-30 at 19:31 +0300, Michael S.
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
>
> The mb() prevents the compiler from reordering on this function, with some
> versions
> of gcc and -Os optimization. The result is random failures in the EEPROM
> read
> without this change.
>
>
> Signed-off-by: Dave Olson <[EMAIL PROTECTED]>
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
>
> diff -r fd5e733f02ac -r 9d943b828776
> drivers/infiniband/hw/ipath/ipath_file_ops.c
> --- a/drivers/infiniband/hw/ipath/ipath_file_ops.cThu Jun 29 14:33:25
> 2006 -0700
> +++ b/drivers/infiniband/hw/ipath/ipath_file_ops.cThu Jun 29 14:33:2
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
>
> Hi, Andrew -
>
> I have a pile of patches for the ipath driver that I'd like to get in
> during the "open season" window. Roland has his hands full with diapers
> and other sprog paraphernalia as of a few days ago, so I doubt he'll see
> this mess
On Wed, 07 Jun 2006 15:06:55 -0500
Steve Wise <[EMAIL PROTECTED]> wrote:
>
> +void c2_free(struct c2_alloc *alloc, u32 obj)
> +{
> + spin_lock(&alloc->lock);
> + clear_bit(obj, alloc->table);
> + spin_unlock(&alloc->lock);
> +}
The spinlock is unneeded here.
What does all the code
On Wed, 07 Jun 2006 15:06:05 -0500
Steve Wise <[EMAIL PROTECTED]> wrote:
>
> This patch provides the new files implementing the iWARP Connection
> Manager.
>
> Review Changes:
>
> - sizeof -> sizeof()
>
> - removed printks
>
> - removed TT debug code
>
> - cleaned up lock/unlock around switc
On Thu, 27 Apr 2006 14:57:26 +0200
Jörn Engel <[EMAIL PROTECTED]> wrote:
> Don't expect much cheer and rejoicing over this. I suspect that akpm
> or Linus will either want the 17 patches merged into one or have a
> patchset where every single patch leaves the kernel in a working
> state, includin
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
>
> + BUG_ON(qp->timerwait.next != LIST_POISON1);
> +list_add_tail(&qp->timerwait, &dev->pending[dev->pending_index]);
Please don't play around with list_head internals like this - some
speedfreak might legitimately choose to remove the list_h
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
>
> +/*
> + * This code is present to allow a knowledgeable person to
> + * specify the layout of processes to processors before opening
> + * this driver, and then we'll assign the process to the "closest"
> + * HT-400 to that
"Sean Hefty" <[EMAIL PROTECTED]> wrote:
>
> >I'm not exactly happy that this tree adds tons of RDMA CM
> >EXPORT_SYMBOL's that are neither currently used nor _GPL.
>
> The symbols are used by the kernel component that provides userspace support.
>
There's brevity and then there is obscurity.
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2006-03-09 at 16:01 -0800, Roland Dreier wrote:
> > Bryan> Any idea what I should be using instead?
> >
> > It depends what you're trying to do. Hence my original question: why
> > are you doing SetPageReserved?
>
> We're mapping some
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> struct neigh_ops currently has a destructor field, which no in-kernel
> drivers outside of infiniband use.
net/atm/clip.c begs to disagree.
I'm also wondering why a combination of the net and infiniband trees does this:
drivers/infiniband/ulp/ipoib/i
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Do we still have a chance to change this?
yes, please do.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> +spin_lock_irq(&priv->lock);
> +set_bit(IPOIB_MCAST_STARTED, &priv->flags);
> +spin_unlock_irq(&priv->lock);
Strange to put a lock around an atomic op like that.
Sometimes it's valid. If another cpu was doing:
spin_lock(lock);
Greg KH <[EMAIL PROTECTED]> wrote:
>
Sorry for sticking my head in a beehive, but. Stand back and look at it:
> Shouldn't you just open the proper chip device and port device itself?
> Why not just use mmap? What's the special needs?
> sysfs file.
> Use poll.
> Use netlink for subnet stuff.
> U
Robert Walsh <[EMAIL PROTECTED]> wrote:
>
> > > + movl %edx,%ecx
> > > + shrl $1,%ecx
> > > + andl $1,%edx
> > > + cld
> > > + rep
> > > + movsq
> > > + movl %edx,%ecx
> > > + rep
> > > + movsd
> > > + ret
> >
> > err, we have a portability problem.
>
> Any chance we could get these moved i
Robert Walsh <[EMAIL PROTECTED]> wrote:
>
> > I'd be inclined to stick BITS_PER_BYTE into include/linux/types.h.
>
> Really? I was just going to suggest removing it, but if sticking it in
> types.h works for you, then fine.
>
I think it's a readbility thing.
x += 8; /*
Robert Walsh <[EMAIL PROTECTED]> wrote:
>
> > > +int ipath_mlock(unsigned long start_page, size_t num_pages, struct page
> > > **p)
> > OK. It's perhaps not a very well named function.
>
> Really? Suggestion for a better name?
>
ipath_get_user_pages() would cause the least surprise.
> > > +
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> +EXPORT_SYMBOL(ipath_kset_linkstate);
> +EXPORT_SYMBOL(ipath_kset_mtu);
> +EXPORT_SYMBOL(ipath_layer_close);
> +EXPORT_SYMBOL(ipath_layer_get_bcast);
> +EXPORT_SYMBOL(ipath_layer_get_cr_errpkey);
> +EXPORT_SYMBOL(ipath_layer_get_deviceid);
> +EXPORT_SYMB
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> ...
> +/*
> + * This isn't perfect, but it's close enough for timing work. We want this
> + * to work on systems where the cycle counter isn't the same as the clock
> + * frequency. The one msec spin is OK, since we execute this only once
> + * when fir
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> + if ((ret = copy_from_user(&rpkt, p, sizeof rpkt))) {
> + _IPATH_DBG("Failed to copy in pkt struct (%d)\n", ret);
> + return ret;
> + }
The driver does this quite a lot. copy_from_user() will return the number
of bytes
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> + .globl ipath_dwordcpy
> +/* rdi destination, rsi source, rdx count */
> +ipath_dwordcpy:
> + movl %edx,%ecx
> + shrl $1,%ecx
> + andl $1,%edx
> + cld
> + rep
> + movsq
> + movl %edx,%ecx
> + rep
> + m
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> ...
>
> +#ifdef __KERNEL__
> +#include
> +#include
> +#include
> +#else/* !__KERNEL__; user mode */
> +#include
> +#include
> +#include
> +#include
> +
> +/* these aren't implemented for user mode, which is OK until
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Fix thinko in rd_atomic calculation: ffs(x) - 1 does not find the next
> power of 2 -- it should be fls(x - 1).
Please use round_up_pow_of_two().
___
openib-general mailing list
openib-general@openib.org
http:
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Andrew> a) arrange for the current infiniband devel tree to be
> Andrew> included in -mm and
>
> Sure. How do you want to handle that? The way I've been working
> lately is to merge things onto my "upstream" branch when I intend for
> them to
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> 43 files changed, 2675 insertions(+), 1773 deletions(-)
That's rather a lot of code. AFAIK it hasn't been past linux-kernel. It
hasn't been in -mm.
Can we please
a) arrange for the current infiniband devel tree to be included in -mm and
b) arrange
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2005-07-11 at 23:11, Andrew Morton wrote:
> > Well I was asking. Do you guys think that this material is appropriate to
> > and safe enough for 2.6.13?
>
> I used your versions of the patches (Tom's ucm one
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
>
> > I'll tentatively consider this material to be not-for-2.6.13?
>
> Presuming that "this material" refers to the patch to add the kernel CM
> implementation, if kernel CM does not make 2.6.13, then user CM should
> not either as it is dependent on i
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
>
> This is version 2 of a patch series to get the Infiniband core up to
> date.
Well that was interesting.
- All the patches had mangled headers:
-- linux-2.6.13-rc2-mm1-16/...
+++ linux-2.6.13-rc2-mm1-17/...
instead of
--- linux-2.6.13-rc2-mm1-16/.
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Add support for userspace completion queues (CQs) to mthca.
>
There are more interesting things happening here ;)
> @@ -177,6 +177,7 @@ struct mthca_cq {
> intcqn;
> u32cons_index;
> int
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Add support for userspace protection domains (PDs) to mthca.
What is a userspace protection domain?
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Add support for mmap() method to mthca, so that userspace can get
> access to doorbell registers. This allows userspace to get direct
> access to the HCA for data path operations.
>
> Each userspace context gets its own copy of the doorbell registers a
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Add support for pinning userspace memory regions and returning a list
> of pages in the region. This includes tracking pinned memory against
> vm_locked and preventing unprivileged users from exceeding RLIMIT_MEMLOCK.
>
Can you tell us a bit more abou
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > Why do you call mlock() and get_user_pages()? In our code, we only call
> > mlock(), and the
> > memory is pinned.
>
> this is a myth; linux is free to move the page about in physical memory
> even if it's mlock()ed!!
eh? I guess the kernel _
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Andrew> Well I was vaguely proposing that the userspace library
> Andrew> keep track of the byteranges and the underlying page
> Andrew> states. So in the above scenario userspace would leave
> Andrew> the page at 0x1000 registered until
Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> Roland Dreier wrote:
>
> > Yes, I agree. If an app wants to register half a page and pass the
> > other half to a child process, I think the only answer is "don't do
> > that then."
>
> How can the app know that, though? It would have to allocate I/
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Roland> a) app registers 0x through 0x17ff
> Roland> b) app registers 0x1800 through 0x2fff
> Roland> c) app unregisters 0x through 0x17ff
> Roland> d) the page at 0x1000 must stay pinned
>
> Andrew> The users
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Libor> Do you mean that the set/clear parameters to do_mlock()
> Libor> are the actual flags which are set/cleared by the caller?
> Libor> Also, the issue remains that the flags are not reference
> Libor> counted which is a problem if
Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>
> > I'm referring to an application which uses your syscalls to obtain pinned
> > memory and uses munlock() so that it may then use your syscalls to obtain
> > evem more pinned memory. With th
Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>
> > RLIMIT_MEMLOCK sounds like the appropriate mechanism. We cannot rely upon
> > userspace running mlock(), so perhaps it is appropriate to run sys_mlock()
> > in-kernel because that gives
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Andrew> How does the driver detect process exit?
>
> I already answered earlier but just to be clear: registration goes
> through a character device, and all regions are cleaned up in the
> ->release() of that device.
yup.
> I don't currently have
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Andrew> ug. What stops the memory from leaking if the process
> Andrew> exits?
>
> Andrew> I hope this is a privileged operation?
>
> I don't think it has to be privileged. In my implementation, the
> driver keeps a per-process list of re
Caitlin Bestler <[EMAIL PROTECTED]> wrote:
>
> >
> > > > This is because there is no file descriptor or anything else associated
> > > > with the pages which permits the kernel to clean stuff up on unclean
> > > > application exit. Also there are the obvious issues with permitting
> > > > pinning
Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> FYI, our driver detects the process termination and cleans up everything
> itself.
How is this implemented?
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-gen
Libor Michalek <[EMAIL PROTECTED]> wrote:
>
> On Mon, Apr 25, 2005 at 03:35:42PM -0700, Andrew Morton wrote:
> > Timur Tabi <[EMAIL PROTECTED]> wrote:
> > >
> > > Andrew Morton wrote:
> > >
> > > > The way we expect g
Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> Bob Woodruff wrote:
>
> > There definitely needs to be a mechanism to prevent people from pinning
> > too much memory.
>
> Any limit would have to be very high - definitely more than just half. What
> if the
> application needs to pin 2GB? The custom
Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>
> > This is because there is no file descriptor or anything else associated
> > with the pages which permits the kernel to clean stuff up on unclean
> > application exit. Also there are t
Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>
> > The way we expect get_user_pages() to be used is that the kernel will use
> > get_user_pages() once per application I/O request.
>
> Are you saying that the mapping obtained by get_user_pa
Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>
> > The way we expect get_user_pages() to be used is that the kernel will use
> > get_user_pages() once per application I/O request.
> >
> > Are you saying that RDMA clients will semi-permane
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Andrew> Do we care about that? A straightforward scenario under
> Andrew> which this can happen is:
>
> Andrew> a) app starts some read I/O in an asynchronous manner
> Andrew> b) app forks
> Andrew> c) child writes to one of the pag
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Timur> With mlock(), we don't need to use get_user_pages() at all.
> Timur> Arjan tells me the only time an mlocked page can move is
> Timur> with hot (un)plug of memory, but that isn't supported on
> Timur> the systems that we support
Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> Christoph Hellwig wrote:
> > On Mon, Apr 18, 2005 at 11:22:29AM -0500, Timur Tabi wrote:
> >
> >>That's not what we're seeing. We have hardware that does DMA over the
> >>network (much like the Infiniband stuff), and we have a testcase that fails
> >>if
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> OK, I'm by no means an expert on this, but Libor and I looked at
> rmap.c a little more, and there is code:
>
> if ((vma->vm_flags & (VM_LOCKED|VM_RESERVED)) ||
> ptep_clear_flush_young(vma, address, pte)) {
> r
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> Troy> Do we even need the mlock in userspace then?
>
> Yes, because the kernel may go through and unmap pages from userspace
> while trying to swap. Since we have the page locked in the kernel,
> the physical page won't go anywhere, but userspace m
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Roland Dreier <[EMAIL PROTECTED]> wrote:
> > >
> > > >> don't add casts to a void pointer, that's silly.
> > >
> >
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Roland Dreier <[EMAIL PROTECTED]> wrote:
> >
> > >> don't add casts to a void pointer, that's silly.
> >
> > How should we handle this nit? Should I post a new version of this
> > p
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> >> don't add casts to a void pointer, that's silly.
>
> How should we handle this nit? Should I post a new version of this
> patch or an incremental diff that fixes it up?
>
I'll fix it up.
___
openib-g
71 matches
Mail list logo
