lustre/lnet/lnet/lib-move.c: memcpy with (struct iovec*)->iov_base, which is __user
by Andrey Utkin
Dear maintainers of LustreFS and other experienced kernel developers!
I am working on fixing some sparse warnings as a task of Eudyptula Challenge.
There's a thing that look suspiciously to me (or I just don't
understand it). This looks same both in upstream kernel code in
drivers/staging/ and in https://github.com/Xyratex/lustre-stable.git
(it doesn't fetch from http://git.whamcloud.com/fs/lustre-release.git,
but I guess it is similar with Xyratex repo).
In lnet/lnet/lib-move.c, in lnet_copy_iov2iov(), at line 209, there is
memcpy((char *)diov->iov_base + doffset,
(char *)siov->iov_base + soffset, this_nob);
diov and siov are struct iovec *, and iov_base in it is void __user *.
Are diov and siov really used semantically correctly here, holding
userspace addresses in iov_base?
Is it semantically correct to use memcpy to copy bytes from one
userspace address to another?
How to treat the comment "/* NB diov, siov are READ-ONLY */" at line
177 in the same procedure? Is it adequate?
This above-mentioned memcpy operation causes sparse warnings "warning:
cast removes address space of expression" for both first and second
line. When i change it to
memcpy((void __user *)((char __user *)diov->iov_base + doffset),
(void __user *)((char __user *)siov->iov_base
+ soffset), this_nob);
It gives other sparse warnings:
drivers/staging/lustre/lnet/lnet/lib-move.c:208:25: warning: incorrect
type in argument 1 (different address spaces)
drivers/staging/lustre/lnet/lnet/lib-move.c:208:25: expected void *to
drivers/staging/lustre/lnet/lnet/lib-move.c:208:25: got void
[noderef] <asn:1>*<noident>
drivers/staging/lustre/lnet/lnet/lib-move.c:209:26: warning: incorrect
type in argument 2 (different address spaces)
drivers/staging/lustre/lnet/lnet/lib-move.c:209:26: expected void const *from
drivers/staging/lustre/lnet/lnet/lib-move.c:209:26: got void
[noderef] <asn:1>*<noident>
What is supposed way to avoid warnings in this case?
Thanks.
--
Andrey Utkin
7 years, 4 months
[PATCH] staging: lustre: do not ignore try_module_get() fail in obd_class_open()
by Alexey Khoroshilov
obd_class_open() ignores error code of try_module_get(),
while it can lead to race with module unload.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
---
drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
index 66ceab20c743..bb4bc72ddac7 100644
--- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
@@ -168,8 +168,7 @@ EXPORT_SYMBOL(obd_ioctl_popdata);
/* opening /dev/obd */
static int obd_class_open(struct inode *inode, struct file *file)
{
- try_module_get(THIS_MODULE);
- return 0;
+ return try_module_get(THIS_MODULE);
}
/* closing /dev/obd */
--
1.9.1
7 years, 4 months
/proc/sys/lnet/stats
by John Bauer
I am writing a tool to monitor Lustre performance and have been unable
to find any documentation for the 11 integers that are in
/proc/sys/lnet/stats.
Could someone point me to some?
Thanks
John
7 years, 4 months
[PATCH] staging: lustre: Add blank lines after declarations
by Arno Tiemersma
Fixes this checkpatch warning:
WARNING: Missing a blank line after declarations
Signed-off-by: Arno Tiemersma <arno.tiemersma(a)gmail.com>
---
drivers/staging/lustre/lustre/include/lclient.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/lustre/lustre/include/lclient.h b/drivers/staging/lustre/lustre/include/lclient.h
index b3b841f..316500c 100644
--- a/drivers/staging/lustre/lustre/include/lclient.h
+++ b/drivers/staging/lustre/lustre/include/lclient.h
@@ -135,6 +135,7 @@ static inline struct ccc_thread_info *ccc_env_info(const struct lu_env *env)
static inline struct cl_attr *ccc_env_thread_attr(const struct lu_env *env)
{
struct cl_attr *attr = &ccc_env_info(env)->cti_attr;
+
memset(attr, 0, sizeof(*attr));
return attr;
}
@@ -142,6 +143,7 @@ static inline struct cl_attr *ccc_env_thread_attr(const struct lu_env *env)
static inline struct cl_io *ccc_env_thread_io(const struct lu_env *env)
{
struct cl_io *io = &ccc_env_info(env)->cti_io;
+
memset(io, 0, sizeof(*io));
return io;
}
--
2.1.0
7 years, 4 months
[PATCH v4 0/2] lprocfs_write_frac_u64_helper cleanup
by Chris Rorvick
Removed "drivers" from the subject. I saw examples of this in the
commit log but have since realized this is not preferred.
v3:
Added Andreas as reviewer (thanks!)
v2:
Added a second patch to address Dan Carpenter's concern with the
complexity of passing the sign through `mult'. Compile tested only.
Chris Rorvick (2):
staging: lustre: Use mult if units not specified
staging: lustre: Track sign separately
drivers/staging/lustre/lustre/obdclass/lprocfs_status.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--
2.1.0
7 years, 4 months
[PATCH] staging: lustre: Fix the warning messages about casting without __user macro
by Shalin Mehta
From: Shalin Mehta <shalinmehta85(a)gmail.com>
This issue is showed up while compiling with sparse. The iov_base in struct iovec struct explicitly declares that the assigned value should be user space pointer with __user macro. Where as here, the __user macro isn't used while casting.
Signed-off-by: Shalin Mehta <shalinmehta85(a)gmail.com>
---
drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index d29f5f1..c40b7e0 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -131,7 +131,7 @@ ksocknal_send_iov (ksock_conn_t *conn, ksock_tx_t *tx)
LASSERT (tx->tx_niov > 0);
if (nob < (int) iov->iov_len) {
- iov->iov_base = (void *)((char *)iov->iov_base + nob);
+ iov->iov_base = (void __user *)((char __user *)iov->iov_base + nob);
iov->iov_len -= nob;
return rc;
}
@@ -1052,7 +1052,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
case KSOCK_PROTO_V3:
conn->ksnc_rx_state = SOCKNAL_RX_KSM_HEADER;
conn->ksnc_rx_iov = (struct iovec *)&conn->ksnc_rx_iov_space;
- conn->ksnc_rx_iov[0].iov_base = (char *)&conn->ksnc_msg;
+ conn->ksnc_rx_iov[0].iov_base = (char __user *)&conn->ksnc_msg;
conn->ksnc_rx_nob_wanted = offsetof(ksock_msg_t, ksm_u);
conn->ksnc_rx_nob_left = offsetof(ksock_msg_t, ksm_u);
@@ -1066,7 +1066,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
conn->ksnc_rx_nob_left = sizeof(lnet_hdr_t);
conn->ksnc_rx_iov = (struct iovec *)&conn->ksnc_rx_iov_space;
- conn->ksnc_rx_iov[0].iov_base = (char *)&conn->ksnc_msg.ksm_u.lnetmsg;
+ conn->ksnc_rx_iov[0].iov_base = (char __user *)&conn->ksnc_msg.ksm_u.lnetmsg;
conn->ksnc_rx_iov[0].iov_len = sizeof (lnet_hdr_t);
break;
@@ -1093,7 +1093,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
do {
nob = MIN (nob_to_skip, sizeof (ksocknal_slop_buffer));
- conn->ksnc_rx_iov[niov].iov_base = ksocknal_slop_buffer;
+ conn->ksnc_rx_iov[niov].iov_base = (void __user *)ksocknal_slop_buffer;
conn->ksnc_rx_iov[niov].iov_len = nob;
niov++;
skipped += nob;
@@ -1218,7 +1218,7 @@ ksocknal_process_receive (ksock_conn_t *conn)
conn->ksnc_rx_nob_left = sizeof(ksock_lnet_msg_t);
conn->ksnc_rx_iov = (struct iovec *)&conn->ksnc_rx_iov_space;
- conn->ksnc_rx_iov[0].iov_base = (char *)&conn->ksnc_msg.ksm_u.lnetmsg;
+ conn->ksnc_rx_iov[0].iov_base = (char __user *)&conn->ksnc_msg.ksm_u.lnetmsg;
conn->ksnc_rx_iov[0].iov_len = sizeof(ksock_lnet_msg_t);
conn->ksnc_rx_niov = 1;
--
1.9.1
7 years, 4 months
Upgrading lustre servers from 2.6.0 to 2.6.90 risks
by Jérôme BECOT
Hello,
Can someone here confirm if i'm safe from any risk of data corruption or
any further troubles by upgrading my MDS and OSS servers software from
the online feature release
2.6.0-RC2--PRISTINE-2.6.32-431.20.3.el6_lustre.x86_64 to the last 2.6.91
version ? or is there some modifications that may lead to a possible crash ?
(proceeding to the usual stop-start services respecting the good order)
We are running test over our new platform here that lasts for more
consequent purposes and as the 2.7 will be out there shortly we want to
keep it functionnal in 2.6.
Thanks
--
Jérome BECOT
Administrateur Systèmes et Réseaux
Molécules à visée Thérapeutique par des approches in Silico (MTi)
Univ Paris Diderot, UMRS973 Inserm
Case 013
Bât. Lamarck A, porte 412
35, rue Hélène Brion 75205 Paris Cedex 13
France
Tel : 01 57 27 83 82
7 years, 4 months
LUG 2015 Call for Presentations, Posters, and Panel Sessions
by OpenSFS Administration
Doing something interesting with Lustre? Pushing the boundaries? We'd love
to have you involved in the 13th annual LustreR User Group (LUG) conference!
LUG 2015 is the primary event for technical presentations and discussions on
the Lustre parallel file system. This year's conference is being held in
Denver, Colorado, from April 13-15, 2015. Save the date!
Call for Presentations
OpenSFS relies on the real world experience of the open source Lustre
community members to provide valuable sessions to LUG attendees. We're
pleased to extend a call for presentations to solicit topics from Lustre
users.
The LUG planning committee is looking for insight into best practices in
deploying and operating Lustre, case studies by Lustre users, and
experiences from members of the business community who rely on Lustre. We
are also looking for presentations related to specific development
challenges, new feature development, project updates, edge-case
implementations, and more.
All LUG presentations will be 30 minutes, with a total of 25-30 speaking
opportunities available. We encourage you to review the agendas and caliber
of presentations at past LUG events <http://www.opensfs.org/past-events/> .
To submit an abstract, please visit the LUG 2015 Call for Presentations web
page <http://opensfs.org/lug-call-for-presentations/> . Submission deadline
is February 6, 2015.
Panel Discussions
Panel discussions are the ideal forum for hearing from leading developers,
vendors, and users of Lustre as they debate future requirements, explore
upcoming enhancements, and share real world best practices. If you'd like to
organize or suggest a topic for a panel discussion - or be part of a panel,
please contact admin(a)opensfs.org <mailto:panelist@opensfs.org> .
Poster Sessions
Poster sessions provide an opportunity for informal, interactive
presentation and discussion of diverse topics related to Lustre technology.
Authors are invited to submit proposals related to innovative projects, best
practices, and original research findings. Proposals should include a brief
abstract, place an emphasis on the unique value of the work, and summarize
contributions or results being presented.
To submit an abstract, please visit the LUG 2015 Call for Presentations web
page <http://opensfs.org/lug-call-for-presentations/> . Submission deadline
is February 18, 2015.
Sponsorships
LUG 2015 Sponsorships offer a unique opportunity for your company to reach
more than 200+ focused Lustre attendees. Contact OpenSFS Administration to
learn more about the sponsorship opportunities available.
Contribute to LUG
Want to participate in the LUG planning committee? This group of vital
volunteers is responsible for providing input, vetting presentation
submissions, and advising on event details. If you've attended LUG and have
feedback on what went well, suggested improvements, and speaking
recommendations, we want to hear from you!
The LUG planning committee will meet 2-4 times a month in order to review
event plans, select presentation content, and ensure this year's LUG is a
smashing success. We look forward to participation from the broader Lustre
community. If you're interested in participating in the LUG planning
committee, please contact OpenSFS Administration with the following
information by Wednesday, January 14th.
* Name
* Company
* Email
* Time zone/physical location
With the ongoing growth and outstanding progress of the Lustre community,
LUG 2015 promises to be an exciting and informative event! Registration
details and additional information will be available in the coming weeks on
the LUG 2015 web site <http://opensfs.org/events/lug-2015/> . We look
forward to seeing you in Denver at LUG 2015!
_________________________
OpenSFS Administration
3855 SW 153rd Drive Beaverton, OR 97006 USA
Phone: +1 503-619-0561 | Fax: +1 503-644-6708
Twitter: <https://twitter.com/opensfs> @OpenSFS
Email: <mailto:admin@opensfs.org> admin(a)opensfs.org | Website:
<http://www.opensfs.org> www.opensfs.org
7 years, 4 months
2015 OpenSFS Community Representative Director Nominations
by OpenSFS Administration
Dear OpenSFS Adopters and Supporters,
Nominations are now being accepted for candidates to serve as the 2015
OpenSFS Community Representative Director on the OpenSFS Board of Directors.
This position will be open from February 2015 to February 2016.
Nominations must be emailed to admin(a)opensfs.org <mailto:admin@opensfs.org>
before 5pm Pacific Time, Friday, January 30th.
Please take a moment to give this nomination serious consideration. The
person selected for this position is responsible for representing the
OpenSFS Supporter and Adopter Participants and has a full Board seat and
voting rights to carry out that responsibility. Community participation is
growing and we want to be sure all Supporters and Adopters have a strong
voice in the decisions made by the OpenSFS Board. Your Community Board
Member is guided by Supporter and Adopter values as the Board makes
decisions for OpenSFS including how OpenSFS Development and Support funding
is spent.
We'd like to thank Steve Simms from Indiana University for his excellent
service as the 2014 Community Representative Director.
Full details regarding the nomination process can be found on the Community
Director Election web page <http://opensfs.org/about/community-director/> .
Sincerely,
OpenSFS Board of Directors
7 years, 4 months
