[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141008234119.19126.4182.stgit@notabene.brown>
Date: Thu, 09 Oct 2014 10:57:06 +1100
From: NeilBrown <neilb@...e.de>
To: Tejun Heo <tj@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, Al Viro <viro@...IV.linux.org.uk>
Subject: [PATCH 0/2 V2] Allow access to sysfs attributes without mem
allocations.
Hi Tejun,
thanks for the review. This version incorporates your suggestions.
You are certainly right about there being issues deeper than just the
sysfs/kernfs level - I've been cleaning up the locking in md to avoid
the "reconfig_mutex" as much as possible. It is something that has
been at the back of my mind for a while, but this need has pushed it
to the fore-front. All the attributes that mdmon needs to touch will
soon only take a spinlock or nothing.
On the topic of inadvertently locking in semantics, I noticed that
prior to kernfs, sysfs would allocate a buffer on first read or
write, and continue to use that buffer. I could try to argue that I
was using those semantics, which have now changed ... though I wasn't
doing it consciously... Certainly this is a thorny issue.
As well as checking that ->seq_show isn't used with ->prealloc,
I've also made sure that sysfs_kf_read() doesn't call the attribute
->show() function unless it is certain it has a preallocated (and
hence >= PAGE_SIZE) buffer.
Thanks,
NeilBrown
---
NeilBrown (2):
sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
sysfs/kernfs: make read requests on pre-alloc files use the buffer.
fs/kernfs/file.c | 70 ++++++++++++++++++++++++++++++++----------------
fs/sysfs/file.c | 53 +++++++++++++++++++++++++++++++-----
include/linux/kernfs.h | 2 +
include/linux/sysfs.h | 9 ++++++
4 files changed, 103 insertions(+), 31 deletions(-)
--
Signature
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists