RE: [HPDD-discuss] [PATCH] staging: lustre: fix sparse warnings related to lock context imbalance
Dan,
I disagree about the change suggested here. In this particular code,
'object_attr' is distinct from 'attr', as in a 'setattr' call on an inode.
'cl_object' is a distinct thing from an inode/file on disk, and specifying it
is the objects attr is helpful in understanding there is not a direct
relationship to 'attr' in the general filesystem sense. (cl_object attrs are
used in determining actual on disk attributes, but there is not a one-to-one
correspondence.)
I am willing to be corrected, but that is my first feeling here.
- Patrick
From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Dan
Carpenter [dan.carpen...@oracle.com]
Sent: Friday, November 28, 2014 4:00 AM
To: Loïc Pefferkorn
Cc: de...@driverdev.osuosl.org; Greg KH; linux-ker...@vger.kernel.org;
gdon...@gmail.com; hpdd-disc...@ml01.01.org
Subject: Re: [HPDD-discuss] [PATCH] staging: lustre: fix sparse warnings
related to lock context imbalance
On Thu, Nov 27, 2014 at 07:34:10PM +0100, Loïc Pefferkorn wrote:
> 1827 if (valid != 0) {
> 1828 cl_object_attr_lock(obj);
> 1829 cl_object_attr_set(env, obj, attr, valid);
> 1830 cl_object_attr_unlock(obj);
>
> after:
>
> 1827 if (valid != 0) {
> 1828 spin_lock(cl_object_attr_guard(obj));
> 1829 cl_object_attr_set(env, obj, attr, valid);
> 1830 spin_unlock(cl_object_attr_guard(obj));
The word "_object" doesn't add any new information to the name. If you
remove it then the code is improved.
spin_lock(cl_attr_guard(obj));
cl_attr_set(env, obj, attr, valid);
spin_unlock(cl_attr_guard(obj));
regards,
dan carpenter
___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [HPDD-discuss] [PATCH] staging: lustre: lustre: obdclass: lprocfs_status.c: Fix for possible null pointer dereference
Strongly agreed that execution speed is not critical here. It's the update of
a proc variable, not a tight loop or critical section.
Normally I'd leave it alone, but since you're writing a patch anyway, I'd do
'tolower' myself. I dislike the stacked case statements on a single line like
that. (It's the only time I've seen them written that way. Perhaps it's
common and I've just missed it.)
Regards,
- Patrick
From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Joe Perches
[j...@perches.com]
Sent: Monday, December 15, 2014 5:53 PM
To: Rickard Strandqvist
Cc: de...@driverdev.osuosl.org; Fabian Frederick; Julia Lawall; James Simmons;
Greg Kroah-Hartman; linux-ker...@vger.kernel.org; Greg Donald;
hpdd-disc...@lists.01.org; Andriy Skulysh
Subject: Re: [HPDD-discuss] [PATCH] staging: lustre: lustre: obdclass:
lprocfs_status.c: Fix for possible null pointer dereference
On Mon, 2014-12-15 at 23:23 +0100, Rickard Strandqvist wrote:
> Hi Joe
Hello Rickard
> No, it does not look like end can be NULL then.
> Then remove the end != NULL instead?
> ...
> if (end != NULL && *end == '.') {
Up to you.
> However, I am hesitant to the tolower() I think double case is faster...?
I doubt code execution speed is paramount here.
Maybe see if the object code size is smaller one
way or the other.
___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [HPDD-discuss] [PATCH] staging: lustre: lustre: include: lustre_update.h: Fix for possible null pointer dereference
Ashley, I sort of understand your larger point, but in this case, I think the purpose of the assert is much better served by the move Rickard is suggesting. Otherwise only one of its conditions will ever trigger. It's not that different to die on the assertion or from a null dereference, but I think it's marginally better to fail the assertion. And it definitely doesn't make sense to have it there and never triggered, which it was before. - Patrick From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Ashley Pittman [apitt...@ddn.com] Sent: Friday, January 02, 2015 11:55 AM To: Rickard Strandqvist Cc: de...@driverdev.osuosl.org; hpdd-disc...@lists.01.org; Greg Kroah-Hartman; linux-ker...@vger.kernel.org Subject: Re: [HPDD-discuss] [PATCH] staging: lustre: lustre:include: lustre_update.h: Fix for possible null pointer dereference Rickard, > On 21 Dec 2014, at 22:43, Rickard Strandqvist > wrote: > > The NULL check was done to late, and there it was a risk > of a possible null pointer dereference. > > This was partially found by using a static code analysis program called > cppcheck. > > Signed-off-by: Rickard Strandqvist > --- > drivers/staging/lustre/lustre/include/lustre_update.h |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/staging/lustre/lustre/include/lustre_update.h > b/drivers/staging/lustre/lustre/include/lustre_update.h > index 84defce..00e1361 100644 > --- a/drivers/staging/lustre/lustre/include/lustre_update.h > +++ b/drivers/staging/lustre/lustre/include/lustre_update.h > @@ -165,12 +165,14 @@ static inline int update_get_reply_buf(struct > update_reply *reply, void **buf, > int result; > > ptr = update_get_buf_internal(reply, index, &size); > + > + LASSERT((ptr != NULL && size >= sizeof(int))); > + > result = *(int *)ptr; > > if (result < 0) > return result; > > - LASSERT((ptr != NULL && size >= sizeof(int))); This looks odd to me, LASSERT is essentially BUG_ON() so is used for checking logic bugs. Moving LASSERT calls doesn’t seem the correct way of resolving a logic problem and if you’re doing static analysis it might be more productive to do it this with LASSERT disabled. > *buf = ptr + sizeof(int); > return size - sizeof(int); > } > -- > 1.7.10.4 > > ___ > HPDD-discuss mailing list > hpdd-disc...@lists.01.org > https://lists.01.org/mailman/listinfo/hpdd-discuss ___ HPDD-discuss mailing list hpdd-disc...@lists.01.org https://lists.01.org/mailman/listinfo/hpdd-discuss ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [HPDD-discuss] [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
Since it is not actually doing a printk - at least, not necessarily - I like lustre_logmsg. lustre_output seems too vague. - Patrick From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Joe Perches [j...@perches.com] Sent: Friday, May 22, 2015 7:36 PM To: Drokin, Oleg Cc: ; ; ; ; Julia Lawall; ; Subject: Re: [HPDD-discuss] [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes On Sat, 2015-05-23 at 00:25 +, Drokin, Oleg wrote: > On May 22, 2015, at 8:18 PM, Joe Perches wrote: > I wonder what is more clear about that in your opinion ve > lustre_error/lustre_debug? > >>> > >>> The fact that you have to explain this shows that it's > >>> at least misleading unless you completely understand the > >>> code. > >> > >> Or you know, you might take the function name at the face value > >> and assume that CERROR means it's an error and CDEBUG means it's a debug > >> message? > > > > Maybe, but I think that it'd be better if the mechanism > > it uses was more plainly named something like lustre_log. > > While the idea seems good, the biggest obstacle here is such that > there's already a thing called lustre log (llog for short too) - > it's kind of a distributed journal of operations. > > Its there a different synonym, I wonder? Maybe: lustre_printk, lustre_logmsg, lustre_output ___ HPDD-discuss mailing list hpdd-disc...@lists.01.org https://lists.01.org/mailman/listinfo/hpdd-discuss ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [lustre-devel] [PATCH] staging: lustre: add __user attributes to llite/file.c
Greg just recently replied to a similar patch rejecting it. I don't have his response handy, but I bet you can find it in the archives. Briefly, this hides possible errors rather than fixing them. From: lustre-devel [lustre-devel-boun...@lists.lustre.org] on behalf of Wim de With [nauxu...@wimdewith.com] Sent: Tuesday, December 08, 2015 2:34 PM To: oleg.dro...@intel.com; andreas.dil...@intel.com; gre...@linuxfoundation.org Cc: de...@driverdev.osuosl.org; Wim de With; linux-ker...@vger.kernel.org; lustre-de...@lists.lustre.org Subject: [lustre-devel] [PATCH] staging: lustre: add __user attributes to llite/file.c This fixes the following sparse warnings: drivers/staging/lustre/lustre/llite/file.c:1310:38:expected void const [noderef] *from drivers/staging/lustre/lustre/llite/file.c:1310:38:got struct ll_recreate_obj * drivers/staging/lustre/lustre/llite/file.c:1328:35: warning: incorrect type in argument 2 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:1328:35:expected void const [noderef] *from drivers/staging/lustre/lustre/llite/file.c:1328:35:got struct lu_fid * drivers/staging/lustre/lustre/llite/file.c:1475:35: warning: incorrect type in argument 2 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:1475:35:expected void const [noderef] *from drivers/staging/lustre/lustre/llite/file.c:1475:35:got struct lov_user_md_v1 * drivers/staging/lustre/lustre/llite/file.c:1500:35: warning: incorrect type in argument 2 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:1500:35:expected void const [noderef] *from drivers/staging/lustre/lustre/llite/file.c:1500:35:got struct lov_user_md_v1 *lumv1p drivers/staging/lustre/lustre/llite/file.c:1505:44: warning: incorrect type in argument 2 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:1505:44:expected void const [noderef] *from drivers/staging/lustre/lustre/llite/file.c:1505:44:got struct lov_user_md_v3 *lumv3p drivers/staging/lustre/lustre/llite/file.c:1516:17: warning: incorrect type in argument 1 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:1516:17:expected void const volatile [noderef] * drivers/staging/lustre/lustre/llite/file.c:1516:17:got unsigned short * drivers/staging/lustre/lustre/llite/file.c:1829:27: warning: incorrect type in argument 1 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:1829:27:expected void [noderef] *to drivers/staging/lustre/lustre/llite/file.c:1829:27:got void * drivers/staging/lustre/lustre/llite/file.c:2214:24: warning: incorrect type in argument 1 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:2214:24:expected void const volatile [noderef] * drivers/staging/lustre/lustre/llite/file.c:2214:24:got int * drivers/staging/lustre/lustre/llite/file.c:2221:21: warning: incorrect type in argument 1 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:2221:21:expected void const volatile [noderef] * drivers/staging/lustre/lustre/llite/file.c:2221:21:got int * drivers/staging/lustre/lustre/llite/file.c:2245:43: warning: incorrect type in argument 2 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:2245:43:expected void const [noderef] *from drivers/staging/lustre/lustre/llite/file.c:2245:43:got char * drivers/staging/lustre/lustre/llite/file.c:2275:24: warning: incorrect type in argument 1 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:2275:24:expected void const volatile [noderef] * drivers/staging/lustre/lustre/llite/file.c:2275:24:got int * drivers/staging/lustre/lustre/llite/file.c:2292:35: warning: incorrect type in argument 1 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:2292:35:expected void [noderef] *to drivers/staging/lustre/lustre/llite/file.c:2292:35:got void * drivers/staging/lustre/lustre/llite/file.c:2299:44: warning: incorrect type in argument 2 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:2299:44:expected void [noderef] *arg drivers/staging/lustre/lustre/llite/file.c:2299:44:got void * drivers/staging/lustre/lustre/llite/file.c:2304:43: warning: incorrect type in argument 2 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:2304:43:expected void const [noderef] *from drivers/staging/lustre/lustre/llite/file.c:2304:43:got char * drivers/staging/lustre/lustre/llite/file.c:2310:46: warning: incorrect type in argument 1 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:2310:46:expected void [noderef] *to drivers/staging/lustre/lustre/llite/file.c:2310:46:got char * drivers/staging/lustre/lustre/llite/file.c:2323:21: warning: incorrect type in argument 1 (different address spaces) drivers/staging/lustre/lustre/llite/file.c:2323:21
Re: [lustre-devel] [PATCH v2] staging/lustre/ptlrpc: Removes potential null dereference
James,
No. You've got it backwards. 0 is false, any non-zero value is true.
if(desc) would be equal to if (desc != 0).
- Patrick
On 05/16/2016 01:16 PM, James Simmons wrote:
This looks wrong - You return -EINVAL from sptlrpc_pack_user_desc, but then
the caller checks "!desc". Desc will not be null, since you've returned
-EINVAL.
Actually 'if (!desc)' is equal to 'if (desc != 0). Yes it can be confusing.
I recommend 'if (desc < 0)' instead to make it clearer what is being
tested for.
- Patrick
On 05/16/2016 09:17 AM, Lidza Louina wrote:
The lustre_msg_buf method could return NULL. Subsequent code didn't
check if it's null before using it. This patch adds two checks.
Signed-off-by: Lidza Louina
---
drivers/staging/lustre/lustre/ptlrpc/sec.c | 2 ++
drivers/staging/lustre/lustre/ptlrpc/sec_plain.c | 9 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec.c
b/drivers/staging/lustre/lustre/ptlrpc/sec.c
index 187fd1d..e6fedc3 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/sec.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/sec.c
@@ -2195,6 +2195,8 @@ int sptlrpc_pack_user_desc(struct lustre_msg *msg, int
offset)
struct ptlrpc_user_desc *pud;
pud = lustre_msg_buf(msg, offset, 0);
+ if (!pud)
+ return -EINVAL;
pud->pud_uid = from_kuid(&init_user_ns, current_uid());
pud->pud_gid = from_kgid(&init_user_ns, current_gid());
diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec_plain.c
b/drivers/staging/lustre/lustre/ptlrpc/sec_plain.c
index 37c9f4c..51741c8 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/sec_plain.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/sec_plain.c
@@ -542,6 +542,7 @@ int plain_alloc_reqbuf(struct ptlrpc_sec *sec,
{
__u32 buflens[PLAIN_PACK_SEGMENTS] = { 0, };
int alloc_len;
+ int desc;
buflens[PLAIN_PACK_HDR_OFF] = sizeof(struct plain_header);
buflens[PLAIN_PACK_MSG_OFF] = msgsize;
@@ -574,8 +575,12 @@ int plain_alloc_reqbuf(struct ptlrpc_sec *sec,
lustre_init_msg_v2(req->rq_reqbuf, PLAIN_PACK_SEGMENTS, buflens, NULL);
req->rq_reqmsg = lustre_msg_buf(req->rq_reqbuf, PLAIN_PACK_MSG_OFF, 0);
-if (req->rq_pack_udesc)
- sptlrpc_pack_user_desc(req->rq_reqbuf, PLAIN_PACK_USER_OFF);
+ if (req->rq_pack_udesc) {
+ desc = sptlrpc_pack_user_desc(req->rq_reqbuf,
+ PLAIN_PACK_USER_OFF);
+ if (!desc)
+ return desc;
+ }
return 0;
}
___
lustre-devel mailing list
lustre-de...@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [HPDD-discuss] [PATCH] staging: lustre: libcfs: move assignment out of if condition
This changes the logic here; the assignment is done conditionally based on the
precheck.
From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Perry
Hooker [perry.hoo...@gmail.com]
Sent: Sunday, July 12, 2015 4:27 PM
To: oleg.dro...@intel.com; andreas.dil...@intel.com;
gre...@linuxfoundation.org; de...@driverdev.osuosl.org;
hpdd-disc...@lists.01.org
Cc: Perry Hooker
Subject: [HPDD-discuss] [PATCH] staging: lustre: libcfs: move assignment out
of if condition
Found by checkpatch.pl
Signed-off-by: Perry Hooker
---
drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
index eea55d9..133ff34 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
@@ -79,8 +79,9 @@ static inline int cfs_fail_check_set(__u32 id, __u32 value,
{
int ret = 0;
- if (unlikely(CFS_FAIL_PRECHECK(id) &&
-(ret = __cfs_fail_check_set(id, value, set {
+ ret = __cfs_fail_check_set(id, value, set);
+
+ if (unlikely(CFS_FAIL_PRECHECK(id) && ret)) {
if (quiet) {
CDEBUG(D_INFO, "*** cfs_fail_loc=%x, val=%u***\n",
id, value);
--
2.1.4
___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [HPDD-discuss] [PATCH] staging: lustre: libcfs: move assignment out of conditional
Looks good, thanks!
From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Perry
Hooker [perry.hoo...@gmail.com]
Sent: Sunday, July 12, 2015 9:22 PM
To: oleg.dro...@intel.com; andreas.dil...@intel.com;
gre...@linuxfoundation.org; de...@driverdev.osuosl.org;
hpdd-disc...@lists.01.org
Cc: Perry Hooker
Subject: [HPDD-discuss] [PATCH] staging: lustre: libcfs: move assignment out
of conditional
Found by checkpatch.pl
Signed-off-by: Perry Hooker
Please enter the commit message for your changes. Lines starting
---
.../staging/lustre/include/linux/libcfs/libcfs_fail.h | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
index eea55d9..aa69c6a 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
@@ -79,14 +79,16 @@ static inline int cfs_fail_check_set(__u32 id, __u32 value,
{
int ret = 0;
- if (unlikely(CFS_FAIL_PRECHECK(id) &&
-(ret = __cfs_fail_check_set(id, value, set {
- if (quiet) {
- CDEBUG(D_INFO, "*** cfs_fail_loc=%x, val=%u***\n",
- id, value);
- } else {
- LCONSOLE_INFO("*** cfs_fail_loc=%x, val=%u***\n",
- id, value);
+ if (unlikely(CFS_FAIL_PRECHECK(id))) {
+ ret = __cfs_fail_check_set(id, value, set);
+ if (ret) {
+ if (quiet) {
+ CDEBUG(D_INFO, "*** cfs_fail_loc=%x,
val=%u***\n",
+ id, value);
+ } else {
+ LCONSOLE_INFO("*** cfs_fail_loc=%x,
val=%u***\n",
+ id, value);
+ }
}
}
--
2.1.4
___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HPDD-discuss] [PATCH] staging: lustre: libcfs: move assignment out of conditional
Actually, commit message looks malformatted. Signed-off-by line is not
the last line. Not sure if that's a problem for Greg or not.
On 07/13/2015 07:50 AM, Patrick Farrell wrote:
Looks good, thanks!
From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Perry
Hooker [perry.hoo...@gmail.com]
Sent: Sunday, July 12, 2015 9:22 PM
To: oleg.dro...@intel.com; andreas.dil...@intel.com;
gre...@linuxfoundation.org; de...@driverdev.osuosl.org;
hpdd-disc...@lists.01.org
Cc: Perry Hooker
Subject: [HPDD-discuss] [PATCH] staging: lustre: libcfs: move assignment out
of conditional
Found by checkpatch.pl
Signed-off-by: Perry Hooker
Please enter the commit message for your changes. Lines starting
---
.../staging/lustre/include/linux/libcfs/libcfs_fail.h | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
index eea55d9..aa69c6a 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
@@ -79,14 +79,16 @@ static inline int cfs_fail_check_set(__u32 id, __u32 value,
{
int ret = 0;
- if (unlikely(CFS_FAIL_PRECHECK(id) &&
-(ret = __cfs_fail_check_set(id, value, set {
- if (quiet) {
- CDEBUG(D_INFO, "*** cfs_fail_loc=%x, val=%u***\n",
- id, value);
- } else {
- LCONSOLE_INFO("*** cfs_fail_loc=%x, val=%u***\n",
- id, value);
+ if (unlikely(CFS_FAIL_PRECHECK(id))) {
+ ret = __cfs_fail_check_set(id, value, set);
+ if (ret) {
+ if (quiet) {
+ CDEBUG(D_INFO, "*** cfs_fail_loc=%x,
val=%u***\n",
+ id, value);
+ } else {
+ LCONSOLE_INFO("*** cfs_fail_loc=%x,
val=%u***\n",
+ id, value);
+ }
}
}
--
2.1.4
___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HPDD-discuss] [PATCH] Staging: lustre: file.c: fix coding style
Perhaps this is just a formatting error in my email client, but
shouldn't NULL be one more space over to line up with the '(' above?
On 03/18/2015 02:08 PM, p...@amd48-systeme.lip6.fr wrote:
+ rc = ll_intent_file_open(file->f_path.dentry,
+ NULL, 0, it);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HPDD-discuss] [PATCH] Staging: lustre: file.c: fix coding style
Uck, my reply made the formatting even worse. I'm trying to say it
should look like this:
+rc = ll_intent_file_open(file->f_path.dentry,
+NULL, 0, it);
Not like this:
+rc = ll_intent_file_open(file->f_path.dentry,
+ NULL, 0, it);
On 03/18/2015 02:31 PM, Patrick Farrell wrote:
Perhaps this is just a formatting error in my email client, but
shouldn't NULL be one more space over to line up with the '(' above?
On 03/18/2015 02:08 PM, p...@amd48-systeme.lip6.fr wrote:
+rc = ll_intent_file_open(file->f_path.dentry,
+NULL, 0, it);
___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
