* [PATCH] librdmacm: define struct ibv_path_record if not defined
From: Sean Hefty @ 2010-05-17 22:03 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
librdmacm relies on struct ibv_path_record from libibverbs. However,
to support older versions of libibverbs, define struct ibv_path_record
if it is not already defined.
Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
I don't know if this is the ideal fix, but it allows librdmacm to build
with older versions of libibverbs. I selected this rather than surrounding
the code that requires these definitions with an #ifdef.
configure.in | 4 ++++
src/cma.h | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/configure.in b/configure.in
index 3db4247..6650bbd 100644
--- a/configure.in
+++ b/configure.in
@@ -49,6 +49,10 @@ AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_MSG_ERROR([ibv_get_device_list() not found. librdmacm requires libibverbs.]))
fi
+AC_CHECK_MEMBER(struct ibv_path_record.service_id, [],
+ AC_DEFINE(DEFINE_PATH_RECORD, 1, [adding path record definition]),
+ [#include <infiniband/sa.h>])
+
dnl Checks for header files.
AC_HEADER_STDC
if test "$disable_libcheck" != "yes"; then
diff --git a/src/cma.h b/src/cma.h
index de012c2..d88c6b1 100644
--- a/src/cma.h
+++ b/src/cma.h
@@ -89,4 +89,44 @@ void ucma_ib_resolve(struct rdma_addrinfo *rai);
#define ucma_ib_resolve(x)
#endif
+/* Define path record definition if using older version of libibverbs */
+#ifdef DEFINE_PATH_RECORD
+#define IBV_PATH_RECORD_REVERSIBLE 0x80
+
+struct ibv_path_record
+{
+ uint64_t service_id;
+ union ibv_gid dgid;
+ union ibv_gid sgid;
+ uint16_t dlid;
+ uint16_t slid;
+ uint32_t flowlabel_hoplimit; /* resv-31:28 flow label-27:8 hop limit-7:0*/
+ uint8_t tclass;
+ uint8_t reversible_numpath; /* reversible-7:7 num path-6:0 */
+ uint16_t pkey;
+ uint16_t qosclass_sl; /* qos class-15:4 sl-3:0 */
+ uint8_t mtu; /* mtu selector-7:6 mtu-5:0 */
+ uint8_t rate; /* rate selector-7:6 rate-5:0 */
+ uint8_t packetlifetime; /* lifetime selector-7:6 lifetime-5:0 */
+ uint8_t preference;
+ uint8_t reserved[6];
+};
+
+#define IBV_PATH_FLAG_GMP (1<<0)
+#define IBV_PATH_FLAG_PRIMARY (1<<1)
+#define IBV_PATH_FLAG_ALTERNATE (1<<2)
+#define IBV_PATH_FLAG_OUTBOUND (1<<3)
+#define IBV_PATH_FLAG_INBOUND (1<<4)
+#define IBV_PATH_FLAG_INBOUND_REVERSE (1<<5)
+#define IBV_PATH_FLAG_BIDIRECTIONAL (IBV_PATH_FLAG_OUTBOUND | \
+ IBV_PATH_FLAG_INBOUND_REVERSE)
+
+struct ibv_path_data
+{
+ uint32_t flags;
+ uint32_t reserved;
+ struct ibv_path_record path;
+};
+#endif
+
#endif /* CMA_H */
--
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: InfiniBand/RDMA merge plans for 2.6.35
From: Sean Hefty @ 2010-05-17 19:58 UTC (permalink / raw)
To: 'Roland Dreier', linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Jason Gunthorpe'
In-Reply-To: <adaiq6mo58m.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
>Here are a few topics that are not ready in time for the 2.6.35 window
>and will need to wait for 2.6.36 at least:
I just wanted to make sure that this didn't get dropped off the radar for 2.6.36
review. I have a set of patches to add support for AF_IB to the rdma_cm. At
this point, all received feedback has been incorporated. I won't repost the
entire patch set unless requested, but it's also available from:
git://git.openfabrics.org/~shefty/rdma-dev.git af_ib
which has been updated to 2.6.34-rc7. I tried to keep the patches small, to
make review a little easier.
Jason, you've been most involved in reviewing the patches so far. Any chance I
can ask you to assist Roland with a more formal review?
drivers/infiniband/core/addr.c | 20 ++-
drivers/infiniband/core/cma.c | 469 ++++++++++++++++++++++--------
drivers/infiniband/core/sa_query.c | 6 +
drivers/infiniband/core/ucma.c | 356 ++++++++++++++++++++---
drivers/infiniband/ulp/iser/iser_verbs.c | 2 +-
include/linux/socket.h | 2 +
include/rdma/ib.h | 89 ++++++
include/rdma/ib_addr.h | 6 +-
include/rdma/ib_sa.h | 6 +
include/rdma/rdma_cm.h | 19 ++-
include/rdma/rdma_user_cm.h | 76 ++++-
net/9p/trans_rdma.c | 3 +-
net/rds/ib.c | 2 +-
net/rds/ib_cm.c | 2 +-
net/rds/iw.c | 2 +-
net/rds/iw_cm.c | 2 +-
net/rds/rdma_transport.c | 3 +-
net/sunrpc/xprtrdma/svc_rdma_transport.c | 3 +-
net/sunrpc/xprtrdma/verbs.c | 2 +-
19 files changed, 877 insertions(+), 193 deletions(-)
- Sean
--
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: compiling against lustre 1.8.2 kernel
From: Brian J. Murrell @ 2010-05-17 18:10 UTC (permalink / raw)
To: linux-rdma
In-Reply-To: <AANLkTikwu0pcBUNaxJQvTJdBDi18KpcQiUeyM3d_YhSi-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
On Mon, 2010-05-17 at 13:32 -0400, Michael Di Domenico wrote:
> it wouldn't appear so, guess i should have checked that. sorry... i'm
> little baffled how they can claim it supports ofed 1.4.2 on a
> 2.6.18-146.11.1 kernel if ofed doesn't support a 2.6.18-164.11.1...
> but i digress, that questions for another list...
Indeed, it is, so any followups should be CC'd to
lustre-discuss-aLEFhgZF4x6X6Mz3xDxJMA@public.gmane.org and should likely drop the linux-rdma
list. Anyone interested in following, can subscribe to lustre-discuss.
But to address the confusion regarding 2.6.18-164.11.1 and the statement
of support for OFED 1.4.2 in the Lustre release notes, the list of
supported OFED releases and supported vendor kernels is not intended to
be a complete and exhaustive matrix. We can of course, only provide
support where there is upstream support (i.e. intersection).
I have Bcc'd our release manager to have some verbage to that extent
(i.e. that the matrix is not complete) to our future release notes.
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: compiling against lustre 1.8.2 kernel
From: Michael Di Domenico @ 2010-05-17 17:32 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: linux-rdma
In-Reply-To: <1274113630.396.41.camel-lA68w17JHpfIgqYUaR6mlLDks+cytr/Z@public.gmane.org>
it wouldn't appear so, guess i should have checked that. sorry... i'm
little baffled how they can claim it supports ofed 1.4.2 on a
2.6.18-146.11.1 kernel if ofed doesn't support a 2.6.18-164.11.1...
but i digress, that questions for another list...
On Mon, May 17, 2010 at 12:27 PM, Brian J. Murrell
<Brian.Murrell-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, 2010-05-17 at 12:15 -0400, Michael Di Domenico wrote:
>> I ran across an error when trying to compile OFED-1.4.2 agianst the
>> Lustre 1.8.2 kernel on Redhat v5.4 (2.6.18-164.11.1)
>>
>> /var/tmp/ofed.topdir/BUILD/ofa_kernel_1.4.2/kernel_addons/backport/2.6.18-EL5.3/include/linux/sched.h:13
>> error: static declaration of '__fatal_signal_pending' follows
>> non-static declaration include/linux/sched.h: 1570 error: previous
>> declaration of '__fatal_signal_pending' was here
>>
>> Any suggestions?
>
> Have you checked that OFED 1.4.2 supports the RHEL5 2.6.18-164.11.1
> kernel? I don't have release notes handy so I don't know.
>
> b.
>
>
--
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
* InfiniBand/RDMA merge plans for 2.6.35
From: Roland Dreier @ 2010-05-17 16:36 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Since 2.6.34 is here, it's probably a good time to talk about 2.6.35
merge plans. All the pending things that I'm aware of are listed below.
Boilerplate:
If something isn't already in my tree and it isn't listed below, I
probably missed it or dropped it unintentionally. Please remind me.
As usual, when submitting a patch:
- Give a good changelog that explains what issue your patch
addresses, how you address the issue, how serious the issue is, and
any other information that would be useful to someone evaluating
your patch now, or trying to understand it years from now.
- Please make sure that you include a "Signed-off-by:" line, and put
any extra junk that should not go into the final kernel log *after*
the "---" line so that git tools strip it off automatically. Make
the subject line be appropriate for inclusion in the kernel log as
well once the leading "[PATCH ...]" stuff is stripped off. I waste a
lot of time fixing patches by hand that could otherwise be spent
doing something productive like watching youtube.
- Run your patch through checkpatch.pl so I don't have to nag you to
fix trivial issues (or spend time fixing them myself).
- Check your patch over at least enough so I don't see a memory leak
or deadlock as soon as I look at it.
- Build your patch with sparse checking ("C=2 CF=-D__CHECK_ENDIAN__")
and make sure it doesn't introduce new warnings. (A big bonus in
goodwill for sending patches that fix old warnings)
- Test your patch on a kernel with things like slab debugging and
lockdep turned on.
And while you're waiting for me to get to your patch, I sure wouldn't
mind if you read and commented on someone else's patch. We currently
have a big imbalance between people who are writing patches (many) and
people who are reviewing patches (mostly me). None of this means you
shouldn't remind me about pending patches, since I often lose track of
things and drop them accidentally.
Core:
- Added support for masked atomic operations.
ULPs:
- Merged a series of iSER failover improvements.
HW specific:
- Added the iw_cxgb4 driver for new Chelsio T4 adapters.
- Added masked atomic support to mlx4.
- Removed use of the older PCI state API in favor of the new DMA
state API.
- A few other fixes here and there.
Here are a few topics that are not ready in time for the 2.6.35 window
and will need to wait for 2.6.36 at least:
- XRC. While I think we made significant progress here, the fact is
that this is not ready to merge at the beginning of the merge
window, and so we'll need to keep working on it and wait for the
next merge window.
- IBoE. Same as XRC; we made significant progress (and I opened an
iboe branch to track this), but we still do not have even the
user-kernel interface really nailed down yet.
- New QLogic qib driver. If a new set of patches shows up soon, we
can probably sneak this in, since it is essentially a new hardware
driver that affects little else. However the sheer size of the
driver means we need to get this in early in the release cycle.
Here all the patches I already have in my for-next branch:
Chien Tung (1):
RDMA/nes: Make nesadapter->phy_lock usage consistent
Dan Carpenter (1):
IB/iser: Fix error flow in iser_create_ib_conn_res()
FUJITA Tomonori (3):
RDMA/cxgb3: Use the dma state API instead of pci equivalents
RDMA/amso1100: Use the dma state API instead of pci equivalents
IB/mthca: Use the dma state API instead of pci equivalents
Julia Lawall (1):
IB/core: Use kmemdup() instead of kmalloc()+memcpy()
Or Gerlitz (4):
IPoIB: Allow disabling/enabling TSO on the fly through ethtool
IB/iser: Add asynchronous event handler
IB/iser: Remove buggy back-pointer setting
IB/iser: Enhance disconnection logic for multi-pathing
Roland Dreier (4):
IB: Explicitly rule out llseek to avoid BKL in default_llseek()
RDMA/nes: Make unnecessarily global functions static
RDMA/cxgb3: Shrink .text with compile-time init of handlers arrays
MAINTAINERS: Add cxgb4 and iw_cxgb4 entries
Steve Wise (2):
RDMA/cxgb3: Don't free skbs on NET_XMIT_* indications from LLD
RDMA/cxgb4: Add driver for Chelsio T4 RNIC
Tetsuo Handa (1):
RDMA/cma: Randomize local port allocation
Vladimir Sokolovsky (2):
IB/core: Add support for masked atomic operations
IB/mlx4: Add support for masked atomic operations
--
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.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: [PATCHv8 07/11] ib_core: Add API to support IBoE from userspace
From: Liran Liss @ 2010-05-17 16:31 UTC (permalink / raw)
To: Roland Dreier, Sean Hefty; +Cc: Linux RDMA list, Eli Cohen, ewg
In-Reply-To: <ada4oibsj9c.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
If we have a dedicated ABI call for this mapping, then it seems reasonable to have it device independent.
However, this mapping is really only used when creating address handles.
So, we can base the mapping on the (device specific) create_ah() flow, but provide generic mapping functions for all devices to use (this is kind of what happens now).
Also, using create_ah() doesn't introduce an ABI call that is specific to ib-->eth mappings.
This is similar to how device-specific ib_reg_user_mr() functions call the generic ib_umem_get()...
-----Original Message-----
From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Roland Dreier
Sent: Thursday, May 13, 2010 10:18 PM
To: Sean Hefty
Cc: 'Eli Cohen'; Eli Cohen; Linux RDMA list; ewg
Subject: Re: [PATCHv8 07/11] ib_core: Add API to support IBoE from userspace
> Basically, what I want to understand is why does this change make sense?
>
> @@ -1139,6 +1139,10 @@ struct ib_device {
> struct ib_grh *in_grh,
> struct ib_mad *in_mad,
> struct ib_mad *out_mad);
> + int (*get_eth_l2_addr)(struct ib_device *device,
> u8 port,
> + union ib_gid *dgid, int
> sgid_idx,
> + u8 *mac, u16 *vlan_id, u8
> *tagged);
> +
Yes, that was pretty much my original question. Why do we have a verb for userspace to call a device-specific method to do the mapping? The layering seems wrong somewhere if we have a generic verb to do this mapping, but then put the mapping in device-specific code.
- R.
--
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.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: compiling against lustre 1.8.2 kernel
From: Brian J. Murrell @ 2010-05-17 16:27 UTC (permalink / raw)
To: linux-rdma
In-Reply-To: <AANLkTil_7L_cbglOcaHKPRmrrntXew9jwxvSrTkxNcnF-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
On Mon, 2010-05-17 at 12:15 -0400, Michael Di Domenico wrote:
> I ran across an error when trying to compile OFED-1.4.2 agianst the
> Lustre 1.8.2 kernel on Redhat v5.4 (2.6.18-164.11.1)
>
> /var/tmp/ofed.topdir/BUILD/ofa_kernel_1.4.2/kernel_addons/backport/2.6.18-EL5.3/include/linux/sched.h:13
> error: static declaration of '__fatal_signal_pending' follows
> non-static declaration include/linux/sched.h: 1570 error: previous
> declaration of '__fatal_signal_pending' was here
>
> Any suggestions?
Have you checked that OFED 1.4.2 supports the RHEL5 2.6.18-164.11.1
kernel? I don't have release notes handy so I don't know.
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCHv8 05/11] ib_core: IBoE UD packet packing support
From: Roland Dreier @ 2010-05-17 16:18 UTC (permalink / raw)
To: Eli Cohen; +Cc: Eli Cohen, Linux RDMA list, ewg
In-Reply-To: <20100517123004.GC663-8YAHvHwT2UEvbXDkjdHOrw/a8Rv0c6iv@public.gmane.org>
> I thought you were referring to the changes made by this patch
> 920d706. Should I re-send this patch?
Yes, please work out what changes are still required and send a new patch.
--
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.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
* compiling against lustre 1.8.2 kernel
From: Michael Di Domenico @ 2010-05-17 16:15 UTC (permalink / raw)
To: linux-rdma
I ran across an error when trying to compile OFED-1.4.2 agianst the
Lustre 1.8.2 kernel on Redhat v5.4 (2.6.18-164.11.1)
/var/tmp/ofed.topdir/BUILD/ofa_kernel_1.4.2/kernel_addons/backport/2.6.18-EL5.3/include/linux/sched.h:13
error: static declaration of '__fatal_signal_pending' follows
non-static declaration include/linux/sched.h: 1570 error: previous
declaration of '__fatal_signal_pending' was here
Any suggestions?
--
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
* Dear Winner
From: Motorola Company Award 2010 @ 2010-05-17 14:44 UTC (permalink / raw)
To: info-U2fvuRwOCqDQT0dZR+AlfA
You have been selected for a cash prize of £400,000.00GBP from Motorola Promotion 2010. Contact YORKSHIRE BANK OF LONDON U.K for your funds release .Home Address: Age: Country: Sex: Occupation. Reply this email with the information for claim (yorkshire.onlineuk-cG17fTKFUrW8rjiVs5Nzzw@public.gmane.org)
--
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 v2] libibverbs: add path record definitions to sa.h
From: Steve Wise @ 2010-05-17 13:38 UTC (permalink / raw)
To: Roland Dreier; +Cc: Sean Hefty, linux-rdma
In-Reply-To: <adavdano5lb.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
Roland Dreier wrote:
> thanks, applied this. Will roll a new libibverbs release early next week.
>
Can you add the RAW_ETY qp type in this release as well?
--
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: [ewg] [PATCHv8 03/11] IB/umad: Enable support only for IB ports
From: Eli Cohen @ 2010-05-17 13:11 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Roland Dreier, Eli Cohen, Linux RDMA list
In-Reply-To: <4BEF80D9.5060200-smomgflXvOZWk0Htik3J/w@public.gmane.org>
On Sun, May 16, 2010 at 08:21:29AM +0300, Or Gerlitz wrote:
> Eli, any reason not to let reading (e.g perfquery) the HCA/port
> traffic counters with IBoE?
>
RoCE assumes Eth management practices (including performance
management). But this is an interesting idea that we can consider for
the future.
--
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: [PATCHv8 05/11] ib_core: IBoE UD packet packing support
From: Eli Cohen @ 2010-05-17 12:30 UTC (permalink / raw)
To: Roland Dreier; +Cc: Eli Cohen, Linux RDMA list, ewg
In-Reply-To: <adad3wzsnz8.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
On Thu, May 13, 2010 at 10:36:27AM -0700, Roland Dreier wrote:
>
> Doesn't seem to be all there... eg there is nothing for ethernet headers.
I thought you were referring to the changes made by this patch
920d706. Should I re-send this patch?
--
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: [ewg] [PATCHv8 02/11] ib_core: IBoE support only QP1
From: Eli Cohen @ 2010-05-17 11:59 UTC (permalink / raw)
To: Roland Dreier; +Cc: Eli Cohen, Linux RDMA list, ewg
In-Reply-To: <adahbmbso19.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
On Thu, May 13, 2010 at 10:35:14AM -0700, Roland Dreier wrote:
> > One reason is that get_src_path_mask() may access ah_lock.
>
> I don't see that:
>
> static u8 get_src_path_mask(struct ib_device *device, u8 port_num)
> {
> struct ib_sa_device *sa_dev;
> struct ib_sa_port *port;
> unsigned long flags;
> u8 src_path_mask;
>
> sa_dev = ib_get_client_data(device, &sa_client);
> if (!sa_dev)
> return 0x7f;
>
> so if we never add the sa_client structure it just returns.
>
I see... so I have no good reason to not treat sa_query.c in the same
manner I did for multicast.c.
By the way, how do you prefer to work out all these comments. Would
you prefer a new patch set or would you prefer to push the fixed
versions to your tree?
Also, there are a few fixes that I pushed to OFED that were pushed
after I sent V8. How would you like me to communicate them?
--
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] opensm/osm_log.c: add OSM_LOG_SYS to default flags
From: Yevgeny Kliteynik @ 2010-05-17 7:22 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Linux RDMA
As suggested by Sasha, instead of checking OSM_LOG_SYS in
osm_log_is_active(), just adding OSM_LOG_SYS to default flags.
Signed-off-by: Yevgeny Kliteynik <kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
---
opensm/opensm/osm_log.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/opensm/opensm/osm_log.c b/opensm/opensm/osm_log.c
index 54c2f36..bd4a200 100644
--- a/opensm/opensm/osm_log.c
+++ b/opensm/opensm/osm_log.c
@@ -119,7 +119,7 @@ void osm_log(IN osm_log_t * p_log, IN osm_log_level_t verbosity,
#endif /* __WIN__ */
/* If this is a call to syslog - always print it */
- if (!(verbosity & (OSM_LOG_SYS | p_log->level)))
+ if (!(verbosity & p_log->level))
return;
va_start(args, p_str);
@@ -306,7 +306,7 @@ ib_api_status_t osm_log_init_v2(IN osm_log_t * p_log, IN boolean_t flush,
IN unsigned long max_size,
IN boolean_t accum_log_file)
{
- p_log->level = log_flags;
+ p_log->level = log_flags | OSM_LOG_SYS;
p_log->flush = flush;
p_log->count = 0;
p_log->max_size = max_size << 20; /* convert size in MB to bytes */
--
1.5.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: [PATCH] opensm/osm_log.h: osm_log_is_active should return true for syslog
From: Yevgeny Kliteynik @ 2010-05-17 7:16 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Linux RDMA
In-Reply-To: <4BE9A006.8030707-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
On 11-May-10 9:20 PM, Yevgeny Kliteynik wrote:
> On 11-May-10 7:21 PM, Sasha Khapyorsky wrote:
>> On 12:06 Tue 11 May , Yevgeny Kliteynik wrote:
>>>
>>> osm_log() always logs messages that came with OSM_LOG_SYS level,
>>> so osm_log_is_active() should concur with this.
>>> As a by-product of this fix, OSM_LOG_SYS messages can now be
>>> printed with OSM_LOG macro, instead of using osm_log() directly.
>>>
>>> Signed-off-by: Yevgeny Kliteynik<kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
>>> ---
>>> opensm/include/opensm/osm_log.h | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/opensm/include/opensm/osm_log.h
>>> b/opensm/include/opensm/osm_log.h
>>> index b2f105a..a494bc3 100644
>>> --- a/opensm/include/opensm/osm_log.h
>>> +++ b/opensm/include/opensm/osm_log.h
>>> @@ -355,7 +355,7 @@ static inline void osm_log_set_level(IN osm_log_t
>>> * p_log,
>>> static inline boolean_t osm_log_is_active(IN const osm_log_t * p_log,
>>> IN osm_log_level_t level)
>>> {
>>> - return ((p_log->level& level) != 0);
>>> + return (((OSM_LOG_SYS | p_log->level)& level) != 0);
>>> }
>>
>> What about to set OSM_LOG_SYS bits in p_log->level at stage of
>> initialization and to remove all subsequent explicit checks? Like this
>> (against master):
>>
>> diff --git a/opensm/opensm/osm_log.c b/opensm/opensm/osm_log.c
>> index 54c2f36..bd4a200 100644
>> --- a/opensm/opensm/osm_log.c
>> +++ b/opensm/opensm/osm_log.c
>> @@ -119,7 +119,7 @@ void osm_log(IN osm_log_t * p_log, IN
>> osm_log_level_t verbosity,
>> #endif /* __WIN__ */
>>
>> /* If this is a call to syslog - always print it */
>> - if (!(verbosity& (OSM_LOG_SYS | p_log->level)))
>> + if (!(verbosity& p_log->level))
>> return;
>>
>> va_start(args, p_str);
>> @@ -306,7 +306,7 @@ ib_api_status_t osm_log_init_v2(IN osm_log_t *
>> p_log, IN boolean_t flush,
>> IN unsigned long max_size,
>> IN boolean_t accum_log_file)
>> {
>> - p_log->level = log_flags;
>> + p_log->level = log_flags | OSM_LOG_SYS;
>
> Sure, that should do the trick too.
> Want me to send a patch, or will you do it?
OK, no answer, never mind.
I'll post the patch shortly.
-- Yevgeny
> -- Yevgeny
>
>> p_log->flush = flush;
>> p_log->count = 0;
>> p_log->max_size = max_size<< 20; /* convert size in MB to bytes */
>>
>>
>> Sasha
>>
>
> --
> 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 1/9] mm: add generic adaptive large memory allocationAPIs
From: KOSAKI Motohiro @ 2010-05-17 1:34 UTC (permalink / raw)
To: Tetsuo Handa
Cc: kosaki.motohiro, peterz, xiaosuo, akpm, hnguyen, raisch, rolandd,
sean.hefty, hal.rosenstock, divy, James.Bottomley, tytso, adilger,
viro, menage, lizf, linux-rdma, linux-kernel, netdev, linux-scsi,
linux-ext4, linux-fsdevel, linux-mm, containers, eric.dumazet
In-Reply-To: <201005132236.ADJ57893.FLFFMtOVJHOOSQ@I-love.SAKURA.ne.jp>
> Peter Zijlstra wrote:
> > NAK, I really utterly dislike that inatomic argument. The alloc side
> > doesn't function in atomic context either. Please keep the thing
> > symmetric in that regards.
>
> Excuse me. kmalloc(GFP_KERNEL) may sleep (and therefore cannot be used in
> atomic context). However, kfree() for memory allocated with kmalloc(GFP_KERNEL)
> never sleep (and therefore can be used in atomic context).
> Why kmalloc() and kfree() are NOT kept symmetric?
In kmalloc case, we need to consider both kmalloc(GFP_KERNEL)/kfree() pair and
kmalloc(GFP_ATOMIC)/kfree() pair. latter is mainly used on atomic context.
To make kfree() atomic help to keep the implementation simple.
But kvmalloc don't have GFP_ATOMIC feautre. that's big difference.
^ permalink raw reply
* Re: [PATCH v2] libibverbs: add path record definitions to sa.h
From: Roland Dreier @ 2010-05-16 22:16 UTC (permalink / raw)
To: Sean Hefty; +Cc: linux-rdma
In-Reply-To: <63BD07796ED544AEAC6E41E669DC6EAC-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
thanks, applied this. Will roll a new libibverbs release early next week.
--
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.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: [ewg] [PATCHv8 03/11] IB/umad: Enable support only for IB ports
From: Or Gerlitz @ 2010-05-16 5:21 UTC (permalink / raw)
To: Eli Cohen; +Cc: Roland Dreier, Eli Cohen, Linux RDMA list
In-Reply-To: <20100506104848.GA29792-8YAHvHwT2UEvbXDkjdHOrw/a8Rv0c6iv@public.gmane.org>
Eli Cohen wrote:
> Roland Dreier wrote:
>
>> Why do we not allow umad for IBoE ports? I understand there's no QP0 but why can't userspace use QP1 just like for IB link layer ports?
>>
> Currently QP1 is only used by the CM protocol which is implemented in the kernel. Since we handle the iboe specific flow in the cma rather than the SA, there is no need to expose qp1 to userspace.
Eli, any reason not to let reading (e.g perfquery) the HCA/port traffic
counters with IBoE?
Or.
--
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: [ewg] [PATCHv8 02/11] ib_core: IBoE support only QP1
From: Or Gerlitz @ 2010-05-16 5:17 UTC (permalink / raw)
To: Eli Cohen; +Cc: Roland Dreier, Linux RDMA list
In-Reply-To: <20100506142849.GC29792-8YAHvHwT2UEvbXDkjdHOrw/a8Rv0c6iv@public.gmane.org>
Eli Cohen wrote:
> Roland Dreier wrote:
>
>> > @@ -1007,7 +1010,7 @@ static void ib_sa_add_one(struct ib_device *device)
>> > - sa_dev = kmalloc(sizeof *sa_dev +
>> > + sa_dev = kzalloc(sizeof *sa_dev +
>>
>> Do you happen to remember why you needed these kmalloc -> kzalloc conversions?
>>
> I can't remember why. I do have this habbit of prefering kzalloc over kmalloc because it saves troubles sometimes.
>
Hi Eli, just a friendly comment, best if such cleanup is done in a
separate patch, else later someone attempting to debug/bisect (who might
be yourself btw) could spend a hell of time wondering why it was done
here and in the framework of this patch...
Or.
--
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 31/37] drivers/infiniband/core: Use kmemdup
From: Roland Dreier @ 2010-05-16 3:05 UTC (permalink / raw)
To: Julia Lawall
Cc: Roland Dreier, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.64.1005152322190.21345-QfmoRoYWmW9knbxzx/v8hQ@public.gmane.org>
looks good, applied, thanks.
--
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.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
* [PATCH 31/37] drivers/infiniband/core: Use kmemdup
From: Julia Lawall @ 2010-05-15 21:22 UTC (permalink / raw)
To: Roland Dreier, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, kernel-jani
From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
---
drivers/infiniband/core/cma.c | 4 ++--
drivers/infiniband/core/mad.c | 4 +---
2 files changed, 3 insertions(+), 5 deletions(-)
diff -u -p a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -1676,13 +1676,13 @@ int rdma_set_ib_paths(struct rdma_cm_id
if (!cma_comp_exch(id_priv, CMA_ADDR_RESOLVED, CMA_ROUTE_RESOLVED))
return -EINVAL;
- id->route.path_rec = kmalloc(sizeof *path_rec * num_paths, GFP_KERNEL);
+ id->route.path_rec = kmemdup(path_rec, sizeof *path_rec * num_paths,
+ GFP_KERNEL);
if (!id->route.path_rec) {
ret = -ENOMEM;
goto err;
}
- memcpy(id->route.path_rec, path_rec, sizeof *path_rec * num_paths);
id->route.num_paths = num_paths;
return 0;
err:
diff -u -p a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -291,13 +291,11 @@ struct ib_mad_agent *ib_register_mad_age
}
if (mad_reg_req) {
- reg_req = kmalloc(sizeof *reg_req, GFP_KERNEL);
+ reg_req = kmemdup(mad_reg_req, sizeof *reg_req, GFP_KERNEL);
if (!reg_req) {
ret = ERR_PTR(-ENOMEM);
goto error3;
}
- /* Make a copy of the MAD registration request */
- memcpy(reg_req, mad_reg_req, sizeof *reg_req);
}
/* Now, fill in the various structures */
--
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: [PATCHv8 04/11] ib_core: IBoE CMA device binding
From: Roland Dreier @ 2010-05-14 22:08 UTC (permalink / raw)
To: Eli Cohen; +Cc: Eli Cohen, Linux RDMA list, ewg
In-Reply-To: <20100513082613.GC16073-8YAHvHwT2UEvbXDkjdHOrw/a8Rv0c6iv@public.gmane.org>
> > I'm having a hard time working out why the iboe case needs to schedule
> > to a work queue here since its already in process context, right? It
> > seems it would be really preferable to avoid all the extra pointer
> > munging and reference counting, and just call things directly.
> I assume that the caller might attempt to acquire the same lock when
> calling join and in the callback. Specifically, ucma_join_multicast()
> calls rdma_join_multicast() with file->mut acquired and
> ucma_event_handler() does the same.
I see... we can't call the consumer's callback directly since it might
have locking assumptions.
It would be nice if we didn't have this reference counting sometimes
used and sometimes not used. I'll have to think about whether this can
be made cleaner.
- R.
--
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.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
* vl15 drops
From: Bob Ciotti @ 2010-05-14 19:55 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
We are chasing down some issues related to fabric discovery and SM failover
and occasionally we see a significant number of vl15 drops and are not sure
if this is a problem or not. Anyone have a reference on what controls are
available to reduce the number of drops? We would like to keep maxsmps set to at
least 16 or even raise it. Spec says at least one vl15 buffer, but are there
controls for buffer allocation on the switches wrt vl15, or other vl15
specific controls (in SM or switches or?) that might reduce drops?
Its a collection of InfiniscaleIII and IV.
Here is a small subset of the VL15 counters on a few on the switches.
Each line corresponds to a 24 port infiniscaleIII switch. All the d1
thru d11 (hypercube dimensions) connections are to other switches (not HCA).
r53i3/sw0/port 24 is where the SM is connected showing 9678 drops...
-- cb1 ib0 sw0 . . . . d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 io
== cb1 ib0 sw0 . . . SWPORT 9 13 14 15 16 17 18 19 20 21 22 23 24
r49i0 cb1 ib0 sw0 SwLid 7842 port-1 VL15Dropped: . . 1 3 8 13 11 . . . . . .
r49i1 cb1 ib0 sw0 SwLid 8349 port-1 VL15Dropped: . . 17 8 20 16 2 2 . . . . .
r49i2 cb1 ib0 sw0 SwLid 8554 port-1 VL15Dropped: . 4 . 12 23 2 2 . 2 . . . .
r49i3 cb1 ib0 sw0 SwLid 7330 port-1 VL15Dropped: 3 1 1 25 71 57 7 8 1 . . . .
r50i0 cb1 ib0 sw0 SwLid 8682 port-1 VL15Dropped: . 2 61 3 6 7 . 5 . . . . .
r50i1 cb1 ib0 sw0 SwLid 8132 port-1 VL15Dropped: . 3 58 33 20 44 1 9 4 . . . .
r50i2 cb1 ib0 sw0 SwLid 6435 port-1 VL15Dropped: 4 122 14 8 13 36 2 . . . . . .
r50i3 cb1 ib0 sw0 SwLid 8027 port-1 VL15Dropped: 22 171 167 49 113 57 . 2 . . . . .
r51i0 cb1 ib0 sw0 SwLid 7756 port-1 VL15Dropped: . . 3 24 16 11 . 2 . . . . .
r51i1 cb1 ib0 sw0 SwLid 6678 port-1 VL15Dropped: . 5 8 28 7 27 2 . 4 . . . .
r51i2 cb1 ib0 sw0 SwLid 7933 port-1 VL15Dropped: 1 34 29 3 7 5 2 . . . . . .
r51i3 cb1 ib0 sw0 SwLid 7426 port-1 VL15Dropped: 14 31 145 683 18 5 2 . 1 . . . .
r52i0 cb1 ib0 sw0 SwLid 6990 port-1 VL15Dropped: 1 26 65 23 132 49 1 1 1 . . . .
r52i1 cb1 ib0 sw0 SwLid 7465 port-1 VL15Dropped: 33 66 388 48 18 4 4 . 2 . . . .
r52i2 cb1 ib0 sw0 SwLid 6914 port-1 VL15Dropped: 17 320 39 14 15 12 4 5 4 . . . .
r52i3 cb1 ib0 sw0 SwLid 7895 port-1 VL15Dropped: 1770 614 1449 189 299 197 35 124 56 . 55 . 9678
r53i0 cb1 ib0 sw0 SwLid 8171 port-1 VL15Dropped: . . . . 1 5 . . . . . . .
r53i1 cb1 ib0 sw0 SwLid 8471 port-1 VL15Dropped: . . 1 . . 15 3 1 5 . . . .
r53i2 cb1 ib0 sw0 SwLid 6485 port-1 VL15Dropped: . . . . 8 17 2 . 2 . . . .
r53i3 cb1 ib0 sw0 SwLid 5949 port-1 VL15Dropped: . . 1 3 3 1 8 . . . . . .
r54i0 cb1 ib0 sw0 SwLid 7809 port-1 VL15Dropped: . . . . 2 . 2 . . . . . .
r54i1 cb1 ib0 sw0 SwLid 7890 port-1 VL15Dropped: . . . 4 16 1 . . 2 . . . .
r54i2 cb1 ib0 sw0 SwLid 6913 port-1 VL15Dropped: . 1 . 1 21 4 4 . 3 . . . .
r54i3 cb1 ib0 sw0 SwLid 7283 port-1 VL15Dropped: 1 11 1 7 34 4 18 . 2 . . . .
r55i0 cb1 ib0 sw0 SwLid 8350 port-1 VL15Dropped: . . . 2 . 8 7 . . . . . .
r55i1 cb1 ib0 sw0 SwLid 7516 port-1 VL15Dropped: . . 3 24 13 3 4 . 1 . . . .
r55i2 cb1 ib0 sw0 SwLid 8518 port-1 VL15Dropped: . 6 . 16 . 1 4 1 . . . . .
r55i3 cb1 ib0 sw0 SwLid 7666 port-1 VL15Dropped: . . 9 12 4 4 20 1 . . . . .
r56i0 cb1 ib0 sw0 SwLid 8219 port-1 VL15Dropped: . 3 29 12 . 6 . . 1 . . . .
r56i1 cb1 ib0 sw0 SwLid 5912 port-1 VL15Dropped: . 3 11 13 4 13 . . 2 . . . .
r56i2 cb1 ib0 sw0 SwLid 7329 port-1 VL15Dropped: 1 105 39 27 1 1 1 . . . . . .
r56i3 cb1 ib0 sw0 SwLid 7424 port-1 VL15Dropped: 14 6 11 77 10 46 4 2 . . . . .
--
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 1/9] mm: add generic adaptive large memory allocation APIs
From: Changli Gao @ 2010-05-14 8:12 UTC (permalink / raw)
To: Peter Zijlstra
Cc: akpm, Hoang-Nam Nguyen, Christoph Raisch, Roland Dreier,
Sean Hefty, Hal Rosenstock, Divy Le Ray, James E.J. Bottomley,
Theodore Ts'o, Andreas Dilger, Alexander Viro, Paul Menage,
Li Zefan, linux-rdma, linux-kernel, netdev, linux-scsi,
linux-ext4, linux-fsdevel, linux-mm, containers, Eric Dumazet,
Tetsuo Handa
In-Reply-To: <1273824214.5605.3625.camel@twins>
On Fri, May 14, 2010 at 4:03 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2010-05-13 at 22:08 +0800, Changli Gao wrote:
>> > NAK, I really utterly dislike that inatomic argument. The alloc side
>> > doesn't function in atomic context either. Please keep the thing
>> > symmetric in that regards.
>> >
>>
>> There are some users, who release memory in atomic context. for
>> example: fs/file.c: fdmem.
>
> urgh, but yeah, aside from not using vmalloc to allocate fd tables one
> needs to deal with this.
>
> But if that is the only one, I'd let them do the workqueue thing that's
> already there. If there really are more people wanting to do this, then
> maybe add: kvfree_atomic().
>
Tetsuo has pointed another one in apparmor.
http://kernel.ubuntu.com/git?p=jj/ubuntu-lucid.git;a=blobdiff;f=security/apparmor/match.c;h=d2cd55419acfcae85cb748c8f837a4384a3a0d29;hp=afc2dd2260edffcf88521ae86458ad03aa8ea12c;hb=f5eba4b0a01cc671affa429ba1512b6de7caeb5b;hpb=abdff9ddaf2644d0f9962490f73e030806ba90d3
, though apparmor hasn't been merged into mainline.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
--
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
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