* [Qemu-devel] Re: [PATCH 08/11] vnc: avoid write only variables
From: Blue Swirl @ 2010-10-07 18:04 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <4CAD7565.5040909@redhat.com>
On Thu, Oct 7, 2010 at 7:23 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 10/06/2010 11:33 PM, Blue Swirl wrote:
>>
>> +#if defined(CONFIG_VNC_TLS) || defined(CONFIG_VNC_SASL)
>> } else if (strncmp(options, "acl", 3) == 0) {
>> acl = 1;
>> +#endif
>
> Not sure it's okay to reject the option altogether (i.e. maybe the #if
> should only include "acl = 1".
It's OK with current code, it doesn't check for invalid options. This
also matches how other options are handled.
^ permalink raw reply
* [PATCH] JFFS2: Dynamically choose inocache hash size
From: Daniel Drake @ 2010-10-07 18:14 UTC (permalink / raw)
To: dwmw2; +Cc: linux-mtd
When JFFS2 is used for large volumes, the mount times are quite long.
Increasing the hash size provides a significant speed boost on the OLPC
XO-1 laptop.
Add logic that dynamically selects a hash size based on the size of
the medium. A 64mb medium will result in a hash size of 128, and a 512mb
medium will result in a hash size of 1024.
Signed-off-by: Daniel Drake <dsd@laptop.org>
---
fs/jffs2/build.c | 2 +-
fs/jffs2/fs.c | 22 +++++++++++++++++++++-
fs/jffs2/jffs2_fs_sb.h | 1 +
fs/jffs2/nodelist.c | 8 ++++----
fs/jffs2/nodelist.h | 3 ++-
5 files changed, 29 insertions(+), 7 deletions(-)
Yesterday I wrote saying this patch didn't work. It's actually working fine.
The problem was that I was comparing linus tree to linux-next (with this
patch applied), and linux-next introduced a bug:
http://www.spinics.net/lists/linux-fsdevel/msg37534.html
This seems to be already fixed in more recent linux-next as well.
diff --git a/fs/jffs2/build.c b/fs/jffs2/build.c
index a906f53..85c6be2 100644
--- a/fs/jffs2/build.c
+++ b/fs/jffs2/build.c
@@ -23,7 +23,7 @@ static void jffs2_build_remove_unlinked_inode(struct jffs2_sb_info *,
static inline struct jffs2_inode_cache *
first_inode_chain(int *i, struct jffs2_sb_info *c)
{
- for (; *i < INOCACHE_HASHSIZE; (*i)++) {
+ for (; *i < c->inocache_hashsize; (*i)++) {
if (c->inocache_list[*i])
return c->inocache_list[*i];
}
diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
index 6b2964a..2701b37 100644
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@ -478,6 +478,25 @@ struct inode *jffs2_new_inode (struct inode *dir_i, int mode, struct jffs2_raw_i
return inode;
}
+static int calculate_inocache_hashsize(uint32_t flash_size)
+{
+ /*
+ * Pick a inocache hash size based on the size of the medium.
+ * Count how many megabytes we're dealing with, apply a hashsize twice
+ * that size, but rounding down to the usual big powers of 2. And keep
+ * to sensible bounds.
+ */
+
+ int size_mb = flash_size / 1024 / 1024;
+ int hashsize = (size_mb * 2) & ~0x3f;
+
+ if (hashsize < INOCACHE_HASHSIZE_MIN)
+ return INOCACHE_HASHSIZE_MIN;
+ if (hashsize > INOCACHE_HASHSIZE_MAX)
+ return INOCACHE_HASHSIZE_MAX;
+
+ return hashsize;
+}
int jffs2_do_fill_super(struct super_block *sb, void *data, int silent)
{
@@ -524,7 +543,8 @@ int jffs2_do_fill_super(struct super_block *sb, void *data, int silent)
if (ret)
return ret;
- c->inocache_list = kcalloc(INOCACHE_HASHSIZE, sizeof(struct jffs2_inode_cache *), GFP_KERNEL);
+ c->inocache_hashsize = calculate_inocache_hashsize(c->flash_size);
+ c->inocache_list = kcalloc(c->inocache_hashsize, sizeof(struct jffs2_inode_cache *), GFP_KERNEL);
if (!c->inocache_list) {
ret = -ENOMEM;
goto out_wbuf;
diff --git a/fs/jffs2/jffs2_fs_sb.h b/fs/jffs2/jffs2_fs_sb.h
index 6784bc8..f864005 100644
--- a/fs/jffs2/jffs2_fs_sb.h
+++ b/fs/jffs2/jffs2_fs_sb.h
@@ -100,6 +100,7 @@ struct jffs2_sb_info {
wait_queue_head_t erase_wait; /* For waiting for erases to complete */
wait_queue_head_t inocache_wq;
+ int inocache_hashsize;
struct jffs2_inode_cache **inocache_list;
spinlock_t inocache_lock;
diff --git a/fs/jffs2/nodelist.c b/fs/jffs2/nodelist.c
index af02bd1..5e03233 100644
--- a/fs/jffs2/nodelist.c
+++ b/fs/jffs2/nodelist.c
@@ -420,7 +420,7 @@ struct jffs2_inode_cache *jffs2_get_ino_cache(struct jffs2_sb_info *c, uint32_t
{
struct jffs2_inode_cache *ret;
- ret = c->inocache_list[ino % INOCACHE_HASHSIZE];
+ ret = c->inocache_list[ino % c->inocache_hashsize];
while (ret && ret->ino < ino) {
ret = ret->next;
}
@@ -441,7 +441,7 @@ void jffs2_add_ino_cache (struct jffs2_sb_info *c, struct jffs2_inode_cache *new
dbg_inocache("add %p (ino #%u)\n", new, new->ino);
- prev = &c->inocache_list[new->ino % INOCACHE_HASHSIZE];
+ prev = &c->inocache_list[new->ino % c->inocache_hashsize];
while ((*prev) && (*prev)->ino < new->ino) {
prev = &(*prev)->next;
@@ -462,7 +462,7 @@ void jffs2_del_ino_cache(struct jffs2_sb_info *c, struct jffs2_inode_cache *old)
dbg_inocache("del %p (ino #%u)\n", old, old->ino);
spin_lock(&c->inocache_lock);
- prev = &c->inocache_list[old->ino % INOCACHE_HASHSIZE];
+ prev = &c->inocache_list[old->ino % c->inocache_hashsize];
while ((*prev) && (*prev)->ino < old->ino) {
prev = &(*prev)->next;
@@ -487,7 +487,7 @@ void jffs2_free_ino_caches(struct jffs2_sb_info *c)
int i;
struct jffs2_inode_cache *this, *next;
- for (i=0; i<INOCACHE_HASHSIZE; i++) {
+ for (i=0; i < c->inocache_hashsize; i++) {
this = c->inocache_list[i];
while (this) {
next = this->next;
diff --git a/fs/jffs2/nodelist.h b/fs/jffs2/nodelist.h
index 523a916..5a53d9b 100644
--- a/fs/jffs2/nodelist.h
+++ b/fs/jffs2/nodelist.h
@@ -199,7 +199,8 @@ struct jffs2_inode_cache {
#define RAWNODE_CLASS_XATTR_DATUM 1
#define RAWNODE_CLASS_XATTR_REF 2
-#define INOCACHE_HASHSIZE 128
+#define INOCACHE_HASHSIZE_MIN 128
+#define INOCACHE_HASHSIZE_MAX 1024
#define write_ofs(c) ((c)->nextblock->offset + (c)->sector_size - (c)->nextblock->free_size)
--
1.7.2.3
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Yehuda Sadeh Weinraub @ 2010-10-07 18:08 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, kvm, qemu-devel, ceph-devel, Christian Brunner
In-Reply-To: <4CADD567.9010606@codemonkey.ws>
On Thu, Oct 7, 2010 at 7:12 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 08/03/2010 03:14 PM, Christian Brunner wrote:
>>
>> +#include "qemu-common.h"
>> +#include "qemu-error.h"
>> +#include<sys/types.h>
>> +#include<stdbool.h>
>> +
>> +#include<qemu-common.h>
>>
>
> This looks to be unnecessary. Generally, system includes shouldn't be
> required so all of these should go away except rado/librados.h
Removed.
>
>> +
>> +#include "rbd_types.h"
>> +#include "module.h"
>> +#include "block_int.h"
>> +
>> +#include<stdio.h>
>> +#include<stdlib.h>
>> +#include<rados/librados.h>
>> +
>> +#include<signal.h>
>> +
>> +
>> +int eventfd(unsigned int initval, int flags);
>>
>
> This is not quite right. Depending on eventfd is curious but in the very
> least, you need to detect the presence of eventfd in configure and provide a
> wrapper that redefines it as necessary.
Can fix that, though please see my later remarks.
>> +static int create_tmap_op(uint8_t op, const char *name, char **tmap_desc)
>> +{
>> + uint32_t len = strlen(name);
>> + /* total_len = encoding op + name + empty buffer */
>> + uint32_t total_len = 1 + (sizeof(uint32_t) + len) + sizeof(uint32_t);
>> + char *desc = NULL;
>>
>
> char is the wrong type to use here as it may be signed or unsigned. That
> can have weird effects with binary data when you're directly manipulating
> it.
Well, I can change it to uint8_t, so that it matches the op type, but
that'll require adding some other castings. In any case, you usually
get such a weird behavior when you cast to types of different sizes
and have the sign bit padded which is not the case in here.
>
>> +
>> + desc = qemu_malloc(total_len);
>> +
>> + *tmap_desc = desc;
>> +
>> + *desc = op;
>> + desc++;
>> + memcpy(desc,&len, sizeof(len));
>> + desc += sizeof(len);
>> + memcpy(desc, name, len);
>> + desc += len;
>> + len = 0;
>> + memcpy(desc,&len, sizeof(len));
>> + desc += sizeof(len);
>>
>
> Shouldn't endianness be a concern?
Right. Fixed that.
>
>> +
>> + return desc - *tmap_desc;
>> +}
>> +
>> +static void free_tmap_op(char *tmap_desc)
>> +{
>> + qemu_free(tmap_desc);
>> +}
>> +
>> +static int rbd_register_image(rados_pool_t pool, const char *name)
>> +{
>> + char *tmap_desc;
>> + const char *dir = RBD_DIRECTORY;
>> + int ret;
>> +
>> + ret = create_tmap_op(CEPH_OSD_TMAP_SET, name,&tmap_desc);
>> + if (ret< 0) {
>> + return ret;
>> + }
>> +
>> + ret = rados_tmap_update(pool, dir, tmap_desc, ret);
>> + free_tmap_op(tmap_desc);
>> +
>> + return ret;
>> +}
>>
>
> This ops are all synchronous? IOW, rados_tmap_update() call blocks until
> the operation is completed?
Yeah. And this is only called from the rbd_create() callback.
>> + header_snap += strlen(header_snap) + 1;
>> + if (header_snap> end)
>> + error_report("bad header, snapshot list broken");
>>
>
> Missing curly braces here.
Fixed.
>> + if (strncmp(hbuf + 68, RBD_HEADER_VERSION, 8)) {
>> + error_report("Unknown image version %s", hbuf + 68);
>> + r = -EMEDIUMTYPE;
>> + goto failed;
>> + }
>> +
>> + RbdHeader1 *header;
>>
>>
>
> Don't mix variable definitions with code.
Fixed.
>> + s->efd = eventfd(0, 0);
>> + if (s->efd< 0) {
>> + error_report("error opening eventfd");
>> + goto failed;
>> + }
>> + fcntl(s->efd, F_SETFL, O_NONBLOCK);
>> + qemu_aio_set_fd_handler(s->efd, rbd_aio_completion_cb, NULL,
>> + rbd_aio_flush_cb, NULL, s);
>>
>
> It looks like you just use the eventfd to signal aio completion callbacks.
> A better way to do this would be to schedule a bottom half. eventfds are
> Linux specific and specific to recent kernels.
Digging back why we introduced the eventfd, it was due to some issues
seen with do_savevm() hangs on qemu_aio_flush(). The reason seemed
that we had no fd associated with the block device, which seemed to
not work well with the qemu aio model. If that assumption is wrong,
we'd be happy to change it. In any case, there are other more portable
ways to generate fds, so if it's needed we can do that.
>> +static int rbd_rw(BlockDriverState *bs, int64_t sector_num,
>> + uint8_t *buf, int nb_sectors, int write)
>> +{
>> + BDRVRBDState *s = bs->opaque;
>> + char n[RBD_MAX_SEG_NAME_SIZE];
>> +
>
> You don't need to implement synchronous functions as long as you have the
> async interfaces implemented.
Snipped.
>> + */
>> + if (sn_info->id_str[0] != '\0'&&
>> + strcmp(sn_info->id_str, sn_info->name) != 0)
>> + return -EINVAL;
>>
>
> I don't fully understand. Does this mean that snapshots are stored in a
> shared namespace? IOW, if a user root creates a snapshot of in one VM, the
> other VM running as root sees it too?
>
Snapshots are stored in a namespace for each block device. If you
share a block device between different vms, you'll also share its
snapshots.
Thanks,
Yehuda
^ permalink raw reply
* Re: memory clobber in rx path, maybe related to ath9k.
From: Johannes Berg @ 2010-10-07 18:14 UTC (permalink / raw)
To: Ben Greear; +Cc: Luis R. Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <4CAE0474.4090605@candelatech.com>
On Thu, 2010-10-07 at 10:33 -0700, Ben Greear wrote:
> In case it helps, here is a dump of where the corrupted SKB was deleted.
I wonder, do you have a machine with a decent IOMMU? Adding IOMMU
debugging into the mix could help you figure out if it's a DMA problem.
johannes
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/5] spice: make compression configurable.
From: Blue Swirl @ 2010-10-07 18:12 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Yonit Halperin, qemu-devel
In-Reply-To: <1286438126-11250-3-git-send-email-kraxel@redhat.com>
On Thu, Oct 7, 2010 at 7:55 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> From: Yonit Halperin <yhalperi@redhat.com>
>
No description?
> ---
> qemu-config.c | 9 ++++++
> qemu-options.hx | 9 ++++++
> ui/spice-core.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 3 files changed, 93 insertions(+), 2 deletions(-)
>
> diff --git a/qemu-config.c b/qemu-config.c
> index 26748a5..8b545b1 100644
> --- a/qemu-config.c
> +++ b/qemu-config.c
> @@ -391,6 +391,15 @@ QemuOptsList qemu_spice_opts = {
> },{
> .name = "tls-ciphers",
> .type = QEMU_OPT_STRING,
> + },{
> + .name = "image-compression",
> + .type = QEMU_OPT_STRING,
> + },{
> + .name = "jpeg-wan-compression",
> + .type = QEMU_OPT_STRING,
> + },{
> + .name = "zlib-glz-wan-compression",
> + .type = QEMU_OPT_STRING,
> },
> { /* end if list */ }
> },
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 9d3f8ef..59db632 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -704,6 +704,15 @@ The x509 file names can also be configured individually.
> @item tls-ciphers=<list>
> Specify which ciphers to use.
>
> +@item image-compression=[auto_glz|auto_lz|quic|glz|lz|off]
> +Configure image compression (lossless).
> +Default is auto_glz.
> +
> +@item jpeg-wan-compression=[auto|never|allways]
> +@item zlib-glz-wan-compression=[auto|never|allways]
'allways' does not match what the code uses:
> + [ SPICE_WAN_COMPRESSION_ALWAYS ] = "always",
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Jeff King @ 2010-10-07 18:13 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <AANLkTinu6fhd9DwfJpjiaxOUu_MrTym_RepR9f44=vrv@mail.gmail.com>
On Thu, Oct 07, 2010 at 08:05:20PM +0200, Erik Faye-Lund wrote:
> >> I don't know which one would be most portable, but if fwrite is the
> >> problem, then
> >>
> >> printf("%*s%c", buf.buf, buf.len, info->hdr_termination);
> >>
> >> should do the trick.
> >
> > It does work, but you have to cast the buf.len size_t to an int.
> >
> I'm not sure how portable it is, though. This is what K&R has to say
> on the matter: "characters from the string are printed until a ´\0´ is
> reached or until the number of characters indicated by the precision
> have been printed". To me it's not clear if that means that either
> cases can terminate the printing when the precision has been
> specified.
I take it back. It doesn't actually work (I thought I had done this just
recently, but clearly not). Try:
#include <stdio.h>
int main()
{
char buf[] = "123456789";
buf[2] = '\0';
printf("%.*s\n", 5, buf);
return 0;
}
It prints just "12" for me.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: Staticise CS4270 DAI
From: Liam Girdwood @ 2010-10-07 18:13 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, patches, Timur Tabi
In-Reply-To: <1286407557-30413-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On Wed, 2010-10-06 at 16:25 -0700, Mark Brown wrote:
> It's not needed with multi-component.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> sound/soc/codecs/cs4270.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sound/soc/codecs/cs4270.c b/sound/soc/codecs/cs4270.c
> index 5fd8e0d..6d4bdc6 100644
> --- a/sound/soc/codecs/cs4270.c
> +++ b/sound/soc/codecs/cs4270.c
> @@ -518,7 +518,7 @@ static struct snd_soc_dai_ops cs4270_dai_ops = {
> .digital_mute = cs4270_dai_mute,
> };
>
> -struct snd_soc_dai_driver cs4270_dai = {
> +static struct snd_soc_dai_driver cs4270_dai = {
> .name = "cs4270-hifi",
> .playback = {
> .stream_name = "Playback",
Both
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
^ permalink raw reply
* Differing results between gitk --follow and git log --follow
From: Joshua Jensen @ 2010-10-07 18:13 UTC (permalink / raw)
To: git@vger.kernel.org
When I run git log --follow, I see a nice history of my file as it was
renamed.
When I run gitk --follow, I see the beginnings of the history, but there
are missing parts.
Is there a way to convince gitk to show me the same bits as git log
--follow?
Thanks.
Josh
^ permalink raw reply
* Re: [PATCH] ASoC: Use delayed work for debounce of GPIO based jacks
From: Liam Girdwood @ 2010-10-07 18:13 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, Peter Ujfalusi
In-Reply-To: <1286406301-25767-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On Wed, 2010-10-06 at 16:05 -0700, Mark Brown wrote:
> Rather than block the workqueue by sleeping to do the debounce use delayed
> work to implement the debounce time. This should also mean that we extend
> the debounce time on each new bounce, potentially allowing shorter debounce
> times for clean insertions.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
^ permalink raw reply
* Re: [Xenomai-core] Overcoming the "foreign" stack
From: Gilles Chanteperdrix @ 2010-10-07 18:12 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai core
In-Reply-To: <4CAE04B1.9070503@domain.hid>
Jan Kiszka wrote:
>> I'm on a wait and see stance about generalizing the use of the ftrace
>> framework for our needs; like Gilles saw with ARM, I must admit that I
>> did notice a massive overhead on low-end ppc as well when we moved the
>> pipeline tracer over it. I'm aware of the mcount optimizations that
>> should be there when cycles really matter, and that ftrace does branch
>> directly to the trace function when only a single one exists, but this
>> may not be easy to keep after the generalization has taken place.
>> Anyway, I'll wait for more data to make my opinion.
>
> As I said, ftrace is more the a simple mcount-tracer. And it's standard,
> distros start to enable it in their production kernels these days
> (except for the function tracer).
>
> If the overhead of the ftrace's mcount is too high on low-end platforms
> (I personally haven't tried it there yet), it would probably be a good
> idea to develop some optimizations or allow some variant that does not
> suffer that much - but upstream then.
I can talk about ARM on that subject: the "fix" is to use dynamic ftrace
(I did not get it working, so I am not sure it still has not one too
many indirection layers, but it looks like it does not). But the patches
to get dynamic ftrace working on ARM, though known since march, have not
been merged yet, so will not be here in the upcoming 2.6.36. I suspect
other architectures such as blackfin also lag behind x86. So, in the
mean-time, if we want to get the I-pipe tracer working with a reasonable
overhead, we have to make our own version, and from that perspective,
the version where mcount calls directly the ipipe tracer, is much
simpler than importing the whole dynamic ftrace stuff. So, I vote for
keeping some #ifdefs or Kconfig stuff in the ipipe tracer code to be
able to use a standalone tracer, as it will also simplify getting it to
work with architectures which lag even more behind x86 than ARM or
Blackfin. Say for instance, microblaze, nios, or sparc.
--
Gilles.
^ permalink raw reply
* Re: Vendor specific data within a beacon frame
From: Luis R. Rodriguez @ 2010-10-07 18:11 UTC (permalink / raw)
To: Bjoern Czybik; +Cc: linux-wireless
In-Reply-To: <4CAD9368.70608@gmx.com>
On Thu, Oct 7, 2010 at 2:31 AM, Bjoern Czybik <wlfw@gmx.com> wrote:
> Hi all,
>
> I am a student from Germany and a newbie to Linux device driver programming
> and the wireless drivers.
> We are using the ath5k device driver and hostapd.
>
> In our project we are looking to send some specific data within each beacon
> (should be set from the hostapd).
> In which struct can I set the vendor specific data in a beacon frame?
This can be done from userspace. This is from nl80211.h:
* @NL80211_CMD_SET_MGMT_EXTRA_IE: Set extra IEs for management frames. The
* interface is identified with %NL80211_ATTR_IFINDEX and the management
* frame subtype with %NL80211_ATTR_MGMT_SUBTYPE. The extra IE data to be
* added to the end of the specified management frame is specified with
* %NL80211_ATTR_IE. If the command succeeds, the requested data will be
* added to all specified management frames generated by
* kernel/firmware/driver.
* Note: This command has been removed and it is only reserved at this
* point to avoid re-using existing command number. The functionality this
* command was planned for has been provided with cleaner design with the
* option to specify additional IEs in NL80211_CMD_TRIGGER_SCAN,
* NL80211_CMD_AUTHENTICATE, NL80211_CMD_ASSOCIATE,
* NL80211_CMD_DEAUTHENTICATE, and NL80211_CMD_DISASSOCIATE.
Luis
^ permalink raw reply
* Re: [PATCH 3/3] pnfs_submit: enforce requested DS only pNFS role
From: Fred Isaman @ 2010-10-07 18:12 UTC (permalink / raw)
To: Benny Halevy; +Cc: andros, linux-nfs
In-Reply-To: <AANLkTin6MDKMEPxZR=qcH5gaF0KKpsbg12=w7u8Xm8cN@mail.gmail.com>
On Thu, Oct 7, 2010 at 2:10 PM, Fred Isaman <iisaman@netapp.com> wrote:
> On Thu, Oct 7, 2010 at 1:06 PM, Benny Halevy <bhalevy@panasas.com> wrote:
>> On 2010-10-07 15:37, andros@netapp.com wrote:
>>> From: Andy Adamson <andros@netapp.com>
>>>
>>> Signed-off-by: Andy Adamson <andros@netapp.com>
>>> ---
>>> fs/nfs/nfs4filelayoutdev.c | 5 -----
>>> fs/nfs/nfs4state.c | 5 +++++
>>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/nfs/nfs4filelayoutdev.c b/fs/nfs/nfs4filelayoutdev.c
>>> index e0edf93..1f0ab62 100644
>>> --- a/fs/nfs/nfs4filelayoutdev.c
>>> +++ b/fs/nfs/nfs4filelayoutdev.c
>>> @@ -183,11 +183,6 @@ nfs4_pnfs_ds_create(struct nfs_server *mds_srv, struct nfs4_pnfs_ds *ds)
>>> goto out_put;
>>> }
>>> /*
>>> - * Mask the (possibly) returned EXCHGID4_FLAG_USE_PNFS_MDS pNFS role
>>> - * The is_ds_only_session depends on this.
>>> - */
>>> - clp->cl_exchange_flags &= ~EXCHGID4_FLAG_USE_PNFS_MDS;
>>> - /*
>>> * Set DS lease equal to the MDS lease, renewal is scheduled in
>>> * create_session
>>> */
>>> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
>>> index 91584ad..e2fc175 100644
>>> --- a/fs/nfs/nfs4state.c
>>> +++ b/fs/nfs/nfs4state.c
>>> @@ -188,6 +188,7 @@ static int nfs4_begin_drain_session(struct nfs_client *clp)
>>> int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>>> {
>>> int status;
>>> + u32 req_exchange_flags = clp->cl_exchange_flags;
>>>
>>> nfs4_begin_drain_session(clp);
>>> status = nfs4_proc_exchange_id(clp, cred);
>>> @@ -196,6 +197,10 @@ int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>>> status = nfs4_proc_create_session(clp);
>>> if (status != 0)
>>> goto out;
>>> + if (is_ds_only_session(req_exchange_flags))
>>> + /* Mask the (possibly) returned MDS and non-pNFS roles */
>>
>> This comment does not really add anything substantial that the code doesn't tell you :)
>>
>>> + clp->cl_exchange_flags &=
>>> + ~(EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_NON_PNFS);
>>
>> I'm not why you want to mask out EXCHGID4_FLAG_USE_NON_PNFS.
>> If the server is not a DS why not just return an error?
>
> We *know* _USE_PNFS_DS is set. We just want to mask out
> _USE_NON_PNFS, which would indicate it is also a 4.0 server.
>
Oops...we *know* _PNFS_DS is set in req_exchange_flags. As you point
out, we would like to know it is in the reply.
Fred
> Fred
>
>>
>> Benny
>>
>>> nfs41_setup_state_renewal(clp);
>>> nfs_mark_client_ready(clp, NFS_CS_READY);
>>> out:
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: [PATCH 3/3] pnfs_submit: enforce requested DS only pNFS role
From: Fred Isaman @ 2010-10-07 18:10 UTC (permalink / raw)
To: Benny Halevy; +Cc: andros, linux-nfs
In-Reply-To: <4CADFE2E.7050401@panasas.com>
On Thu, Oct 7, 2010 at 1:06 PM, Benny Halevy <bhalevy@panasas.com> wrote:
> On 2010-10-07 15:37, andros@netapp.com wrote:
>> From: Andy Adamson <andros@netapp.com>
>>
>> Signed-off-by: Andy Adamson <andros@netapp.com>
>> ---
>> fs/nfs/nfs4filelayoutdev.c | 5 -----
>> fs/nfs/nfs4state.c | 5 +++++
>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/nfs/nfs4filelayoutdev.c b/fs/nfs/nfs4filelayoutdev.c
>> index e0edf93..1f0ab62 100644
>> --- a/fs/nfs/nfs4filelayoutdev.c
>> +++ b/fs/nfs/nfs4filelayoutdev.c
>> @@ -183,11 +183,6 @@ nfs4_pnfs_ds_create(struct nfs_server *mds_srv, struct nfs4_pnfs_ds *ds)
>> goto out_put;
>> }
>> /*
>> - * Mask the (possibly) returned EXCHGID4_FLAG_USE_PNFS_MDS pNFS role
>> - * The is_ds_only_session depends on this.
>> - */
>> - clp->cl_exchange_flags &= ~EXCHGID4_FLAG_USE_PNFS_MDS;
>> - /*
>> * Set DS lease equal to the MDS lease, renewal is scheduled in
>> * create_session
>> */
>> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
>> index 91584ad..e2fc175 100644
>> --- a/fs/nfs/nfs4state.c
>> +++ b/fs/nfs/nfs4state.c
>> @@ -188,6 +188,7 @@ static int nfs4_begin_drain_session(struct nfs_client *clp)
>> int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>> {
>> int status;
>> + u32 req_exchange_flags = clp->cl_exchange_flags;
>>
>> nfs4_begin_drain_session(clp);
>> status = nfs4_proc_exchange_id(clp, cred);
>> @@ -196,6 +197,10 @@ int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>> status = nfs4_proc_create_session(clp);
>> if (status != 0)
>> goto out;
>> + if (is_ds_only_session(req_exchange_flags))
>> + /* Mask the (possibly) returned MDS and non-pNFS roles */
>
> This comment does not really add anything substantial that the code doesn't tell you :)
>
>> + clp->cl_exchange_flags &=
>> + ~(EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_NON_PNFS);
>
> I'm not why you want to mask out EXCHGID4_FLAG_USE_NON_PNFS.
> If the server is not a DS why not just return an error?
We *know* _USE_PNFS_DS is set. We just want to mask out
_USE_NON_PNFS, which would indicate it is also a 4.0 server.
Fred
>
> Benny
>
>> nfs41_setup_state_renewal(clp);
>> nfs_mark_client_ready(clp, NFS_CS_READY);
>> out:
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: server 4.1 issues list
From: Benny Halevy @ 2010-10-07 18:10 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux-nfs
In-Reply-To: <20101007175424.GA31443@fieldses.org>
On 2010-10-07 13:54, J. Bruce Fields wrote:
> On Thu, Oct 07, 2010 at 11:53:06AM -0400, bfields wrote:
>> Someone also asked whether we've fixed the backchannel attribute
>> checking. We haven't, but that should be fairly quick--I'll take a look
>> at it now.
>
> Actually there's a bit of tedious arithmetic to do here to figure out
> what we need e.g. for the maximum request size. I'm setting this aside
> for now, so this is up for grabs.
Ack. FWIW :)
>
> --b.
>
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 6233917..0f8e90b 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -1493,6 +1493,23 @@ nfsd4_replay_create_session(struct nfsd4_create_session *cr_ses,
> return slot->sl_status;
> }
>
> +static __be32 verify_backchannel_attributes(struct nfsd4_create_session *cr_ses)
> +{
> + struct nfsd4_channel_attrs *attrs;
> +
> + if (!cses->flags & SESSION4_BACK_CHAN)
> + return nfs_ok;
> + if (attrs.maxreqs < 1)
> + return nfserr_inval;
> + /* XXX: check other fields here; see
> + * http://tools.ietf.org/search/rfc5661#section-18.36 to
> + * determine when we can modify the fields to be acceptable, and
> + * when we must return inval. We'll need to figure out the
> + * things like how large a callback request we need to be able to
> + * send. */
> + return nfs_ok;
> +}
> +
> __be32
> nfsd4_create_session(struct svc_rqst *rqstp,
> struct nfsd4_compound_state *cstate,
> @@ -1553,6 +1570,9 @@ nfsd4_create_session(struct svc_rqst *rqstp,
> cr_ses->flags &= ~SESSION4_PERSIST;
> cr_ses->flags &= ~SESSION4_RDMA;
>
> + status = verify_backchannel_attributes(cr_ses);
> + if (status)
> + goto out;
> status = nfserr_jukebox;
> new = alloc_init_session(rqstp, conf, cr_ses);
> if (!new)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
=
^ permalink raw reply
* RE: Issue : jffs2 and ecc layout
From: Ghorai, Sukumar @ 2010-10-07 18:09 UTC (permalink / raw)
To: Vimal Singh; +Cc: linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org
In-Reply-To: <AANLkTi=y1JwSBrELd=KyUsmhitSCF2eWW9iYFg3a_-J4@mail.gmail.com>
> -----Original Message-----
> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
> Sent: Thursday, October 07, 2010 11:02 PM
> To: Ghorai, Sukumar
> Cc: linux-mtd@lists.infradead.org; linux-omap@vger.kernel.org
> Subject: Re: Issue : jffs2 and ecc layout
>
> On Mon, Oct 4, 2010 at 12:59 PM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> owner@vger.kernel.org] On Behalf Of Ghorai, Sukumar
> >> Sent: Tuesday, September 28, 2010 6:17 PM
> >> To: linux-mtd@lists.infradead.org
> >> Cc: linux-omap@vger.kernel.org
> >> Subject: Issue : jffs2 and ecc layout
> >>
> >> Hi,
> >> I was using the following ecc layout which is not working to mount the
> >> jffs2 File-system. I was in 2.6.32 kernel and working; but same layout
> is
> >> not working with latest 2.6 kernel.
> >>
> >> Observation is that - no read request issued to the driver (say
> omap2.c).
> >>
> >> # mount -t jffs2 /dev/mtdblock4 /mnt/nand
> >> [ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes,
> read
> >> 0 bytes, error -22
> >> mount: Mounting /dev/mtdblock4 on /mnt/nand failed: Input/output error
> >>
> >> # dmesg
> >> <3>[ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes,
> >> read 0 bytes, error -22
> >>
> I do not think above issue has anything to do with the ECC layout.
> But as I earlier pointed (in [1]), this change [2] has messed up
> function 'omap_hwcontrol'.
[Ghorai] in that case how other layout is working? Say storing the ecc at end of the spare area is working.
> All read/write functions read/write data from/to address
> info->nand.IO_ADDR_(R/W), which is not set by new function
> 'gpmc_nand_write' (which still take care of writing address/cmd to
> write registers). But since above pointer is not set (hence points to
> address '0'), driver tries to read data from wrong location.
[Ghorai] you can see following two line in _probe() function
info->nand.IO_ADDR_R = ioremap(info->phys_base, NAND_IO_SIZE);
info->nand.IO_ADDR_W = info->nand.IO_ADDR_R;
>
> In fact, I would even suggest to try dumping nand command registers(or
> use T32) and verify if commands issued were written correctly to
> appropriate registers.
[Ghorai] I mentioned read request does not come to driver.
>
>
>
> [1]: http://marc.info/?l=linux-omap&m=128302624528822&w=2
> [2] commit: http://git.infradead.org/mtd-
> 2.6.git/commitdiff/2c01946c6b9ebaa5a89710bc42ca224a7f52f227
>
> --
> Regards,
> Vimal Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Issue : jffs2 and ecc layout
From: Ghorai, Sukumar @ 2010-10-07 18:09 UTC (permalink / raw)
To: Vimal Singh; +Cc: linux-omap@vger.kernel.org, linux-mtd@lists.infradead.org
In-Reply-To: <AANLkTi=y1JwSBrELd=KyUsmhitSCF2eWW9iYFg3a_-J4@mail.gmail.com>
> -----Original Message-----
> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
> Sent: Thursday, October 07, 2010 11:02 PM
> To: Ghorai, Sukumar
> Cc: linux-mtd@lists.infradead.org; linux-omap@vger.kernel.org
> Subject: Re: Issue : jffs2 and ecc layout
>
> On Mon, Oct 4, 2010 at 12:59 PM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> owner@vger.kernel.org] On Behalf Of Ghorai, Sukumar
> >> Sent: Tuesday, September 28, 2010 6:17 PM
> >> To: linux-mtd@lists.infradead.org
> >> Cc: linux-omap@vger.kernel.org
> >> Subject: Issue : jffs2 and ecc layout
> >>
> >> Hi,
> >> I was using the following ecc layout which is not working to mount the
> >> jffs2 File-system. I was in 2.6.32 kernel and working; but same layout
> is
> >> not working with latest 2.6 kernel.
> >>
> >> Observation is that - no read request issued to the driver (say
> omap2.c).
> >>
> >> # mount -t jffs2 /dev/mtdblock4 /mnt/nand
> >> [ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes,
> read
> >> 0 bytes, error -22
> >> mount: Mounting /dev/mtdblock4 on /mnt/nand failed: Input/output error
> >>
> >> # dmesg
> >> <3>[ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes,
> >> read 0 bytes, error -22
> >>
> I do not think above issue has anything to do with the ECC layout.
> But as I earlier pointed (in [1]), this change [2] has messed up
> function 'omap_hwcontrol'.
[Ghorai] in that case how other layout is working? Say storing the ecc at end of the spare area is working.
> All read/write functions read/write data from/to address
> info->nand.IO_ADDR_(R/W), which is not set by new function
> 'gpmc_nand_write' (which still take care of writing address/cmd to
> write registers). But since above pointer is not set (hence points to
> address '0'), driver tries to read data from wrong location.
[Ghorai] you can see following two line in _probe() function
info->nand.IO_ADDR_R = ioremap(info->phys_base, NAND_IO_SIZE);
info->nand.IO_ADDR_W = info->nand.IO_ADDR_R;
>
> In fact, I would even suggest to try dumping nand command registers(or
> use T32) and verify if commands issued were written correctly to
> appropriate registers.
[Ghorai] I mentioned read request does not come to driver.
>
>
>
> [1]: http://marc.info/?l=linux-omap&m=128302624528822&w=2
> [2] commit: http://git.infradead.org/mtd-
> 2.6.git/commitdiff/2c01946c6b9ebaa5a89710bc42ca224a7f52f227
>
> --
> Regards,
> Vimal Singh
^ permalink raw reply
* Re: Can you please define "snapshot" and "subvolume"?
From: Goffredo Baroncelli @ 2010-10-07 18:08 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <AANLkTimBsVGS=eJvpdf2Sq_Dg76zQRgy=E+3089zQ9D4@mail.gmail.com>
On Thursday, 07 October, 2010, Francis Galiegue wrote:
> I have difficulties grabbing these two concepts.
>=20
> As far as I can tell, a snapshot is an instant, synchronized,
> photography of the filesystem at a given point in time; a subvolume i=
s
> a "subroot" to a btrfs filesystem.
>=20
> While I fully understand (and use) the purpose of snapshots, I don't
> quite fathom the use case for subvolumes, apart from btrfs-convert...
> Why has btrfs grown such a feature in the first place? Can someone
> give me a use case for them?
By design in btrfs a snapshot is "a instant, synchronized, photography =
of" a=20
subvolume.
In fact you can snapshot only a subvolume [*].=20
Moreover the subvolumes have the following properties:
1) it is possible to mount a subvolume of a filesystem: if you execute =
the=20
following commands:
# mount -o subvol=3Dname-of-subvol /dev/sdxx /mn/test
the kernel will use the subvolume "name-of-subvol" of the btrfs filesys=
tem of=20
the partition /dev/sdxx. Pay attention: this work *only* if the subvolu=
me=20
"name-of-subvol" is under the root of the filesystem.
2) a subvolume may be deleted asynchronously by the command "btrfs subv=
ol=20
delete <path>". Pay attention that the deletion is performed not instan=
taneous=20
but in background. In fact even though the subvolume disappear instanta=
neous=20
the space is freed during the background removing.
3) If you have a subvolume into another one, and you snapshot the latte=
r, in=20
the snapshot you cannot see the nested subvolume.=20
=46or example you have the root ('/') under a subvolume and the /home u=
nder=20
another subvolume. If you snapshot the root, this snapshot will not con=
tain=20
the subvolume /home. This may be useful if you want restore an old snap=
shot of=20
the root filesystem without affecting the users homes directories.
In the future some attributes (raid mode, compression) may be set per-
subvolume basis.
Regards
G.Baroncelli
[*] The btrfsctl utility doesn't return an error when you snapshot a=20
directory. But instead of snapshotting the directory you get a snapshot=
of the=20
subvolume which contain the directory.
>=20
> --=20
> Francis Galiegue, fgaliegue@gmail.com
> "It seems obvious [...] that at least some 'business intelligence'
> tools invest so much intelligence on the business side that they have
> nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "=
The
> Art of SQL", ISBN 0-596-00894-5)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>=20
--=20
gpg key@ keyserver.linux.it:Goffredo Baroncelli (ghigo) <kreijackATinwi=
nd.it>
Key fingerprint =3D 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] pnfs_submit: enforce requested DS only pNFS role
From: Benny Halevy @ 2010-10-07 18:08 UTC (permalink / raw)
To: andros; +Cc: linux-nfs
In-Reply-To: <4CADFE2E.7050401@panasas.com>
On 2010-10-07 13:06, Benny Halevy wrote:
> On 2010-10-07 15:37, andros@netapp.com wrote:
>> From: Andy Adamson <andros@netapp.com>
>>
>> Signed-off-by: Andy Adamson <andros@netapp.com>
>> ---
>> fs/nfs/nfs4filelayoutdev.c | 5 -----
>> fs/nfs/nfs4state.c | 5 +++++
>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/nfs/nfs4filelayoutdev.c b/fs/nfs/nfs4filelayoutdev.c
>> index e0edf93..1f0ab62 100644
>> --- a/fs/nfs/nfs4filelayoutdev.c
>> +++ b/fs/nfs/nfs4filelayoutdev.c
>> @@ -183,11 +183,6 @@ nfs4_pnfs_ds_create(struct nfs_server *mds_srv, struct nfs4_pnfs_ds *ds)
>> goto out_put;
>> }
>> /*
>> - * Mask the (possibly) returned EXCHGID4_FLAG_USE_PNFS_MDS pNFS role
>> - * The is_ds_only_session depends on this.
>> - */
>> - clp->cl_exchange_flags &= ~EXCHGID4_FLAG_USE_PNFS_MDS;
>> - /*
>> * Set DS lease equal to the MDS lease, renewal is scheduled in
>> * create_session
>> */
>> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
>> index 91584ad..e2fc175 100644
>> --- a/fs/nfs/nfs4state.c
>> +++ b/fs/nfs/nfs4state.c
>> @@ -188,6 +188,7 @@ static int nfs4_begin_drain_session(struct nfs_client *clp)
>> int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>> {
>> int status;
>> + u32 req_exchange_flags = clp->cl_exchange_flags;
>>
>> nfs4_begin_drain_session(clp);
>> status = nfs4_proc_exchange_id(clp, cred);
>> @@ -196,6 +197,10 @@ int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>> status = nfs4_proc_create_session(clp);
>> if (status != 0)
>> goto out;
>> + if (is_ds_only_session(req_exchange_flags))
>> + /* Mask the (possibly) returned MDS and non-pNFS roles */
>
> This comment does not really add anything substantial that the code doesn't tell you :)
>
>> + clp->cl_exchange_flags &=
>> + ~(EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_NON_PNFS);
>
> I'm not why you want to mask out EXCHGID4_FLAG_USE_NON_PNFS.
> If the server is not a DS why not just return an error?
So Andy convinced me and the spec. says that USE_PNFS_DS | USE_NON_PNFS
is a valid response.
However, if USE_PNFS_DS is unset in the response in this case
we need not create the client and better return an error.
I'll send a patch that does that.
Benny
>
> Benny
>
>> nfs41_setup_state_renewal(clp);
>> nfs_mark_client_ready(clp, NFS_CS_READY);
>> out:
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Yehuda Sadeh Weinraub @ 2010-10-07 18:08 UTC (permalink / raw)
To: Anthony Liguori
Cc: Christian Brunner, malc, kvm, qemu-devel, Kevin Wolf, ceph-devel
In-Reply-To: <4CADD567.9010606@codemonkey.ws>
On Thu, Oct 7, 2010 at 7:12 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 08/03/2010 03:14 PM, Christian Brunner wrote:
>>
>> +#include "qemu-common.h"
>> +#include "qemu-error.h"
>> +#include<sys/types.h>
>> +#include<stdbool.h>
>> +
>> +#include<qemu-common.h>
>>
>
> This looks to be unnecessary. Generally, system includes shouldn't be
> required so all of these should go away except rado/librados.h
Removed.
>
>> +
>> +#include "rbd_types.h"
>> +#include "module.h"
>> +#include "block_int.h"
>> +
>> +#include<stdio.h>
>> +#include<stdlib.h>
>> +#include<rados/librados.h>
>> +
>> +#include<signal.h>
>> +
>> +
>> +int eventfd(unsigned int initval, int flags);
>>
>
> This is not quite right. Depending on eventfd is curious but in the very
> least, you need to detect the presence of eventfd in configure and provide a
> wrapper that redefines it as necessary.
Can fix that, though please see my later remarks.
>> +static int create_tmap_op(uint8_t op, const char *name, char **tmap_desc)
>> +{
>> + uint32_t len = strlen(name);
>> + /* total_len = encoding op + name + empty buffer */
>> + uint32_t total_len = 1 + (sizeof(uint32_t) + len) + sizeof(uint32_t);
>> + char *desc = NULL;
>>
>
> char is the wrong type to use here as it may be signed or unsigned. That
> can have weird effects with binary data when you're directly manipulating
> it.
Well, I can change it to uint8_t, so that it matches the op type, but
that'll require adding some other castings. In any case, you usually
get such a weird behavior when you cast to types of different sizes
and have the sign bit padded which is not the case in here.
>
>> +
>> + desc = qemu_malloc(total_len);
>> +
>> + *tmap_desc = desc;
>> +
>> + *desc = op;
>> + desc++;
>> + memcpy(desc,&len, sizeof(len));
>> + desc += sizeof(len);
>> + memcpy(desc, name, len);
>> + desc += len;
>> + len = 0;
>> + memcpy(desc,&len, sizeof(len));
>> + desc += sizeof(len);
>>
>
> Shouldn't endianness be a concern?
Right. Fixed that.
>
>> +
>> + return desc - *tmap_desc;
>> +}
>> +
>> +static void free_tmap_op(char *tmap_desc)
>> +{
>> + qemu_free(tmap_desc);
>> +}
>> +
>> +static int rbd_register_image(rados_pool_t pool, const char *name)
>> +{
>> + char *tmap_desc;
>> + const char *dir = RBD_DIRECTORY;
>> + int ret;
>> +
>> + ret = create_tmap_op(CEPH_OSD_TMAP_SET, name,&tmap_desc);
>> + if (ret< 0) {
>> + return ret;
>> + }
>> +
>> + ret = rados_tmap_update(pool, dir, tmap_desc, ret);
>> + free_tmap_op(tmap_desc);
>> +
>> + return ret;
>> +}
>>
>
> This ops are all synchronous? IOW, rados_tmap_update() call blocks until
> the operation is completed?
Yeah. And this is only called from the rbd_create() callback.
>> + header_snap += strlen(header_snap) + 1;
>> + if (header_snap> end)
>> + error_report("bad header, snapshot list broken");
>>
>
> Missing curly braces here.
Fixed.
>> + if (strncmp(hbuf + 68, RBD_HEADER_VERSION, 8)) {
>> + error_report("Unknown image version %s", hbuf + 68);
>> + r = -EMEDIUMTYPE;
>> + goto failed;
>> + }
>> +
>> + RbdHeader1 *header;
>>
>>
>
> Don't mix variable definitions with code.
Fixed.
>> + s->efd = eventfd(0, 0);
>> + if (s->efd< 0) {
>> + error_report("error opening eventfd");
>> + goto failed;
>> + }
>> + fcntl(s->efd, F_SETFL, O_NONBLOCK);
>> + qemu_aio_set_fd_handler(s->efd, rbd_aio_completion_cb, NULL,
>> + rbd_aio_flush_cb, NULL, s);
>>
>
> It looks like you just use the eventfd to signal aio completion callbacks.
> A better way to do this would be to schedule a bottom half. eventfds are
> Linux specific and specific to recent kernels.
Digging back why we introduced the eventfd, it was due to some issues
seen with do_savevm() hangs on qemu_aio_flush(). The reason seemed
that we had no fd associated with the block device, which seemed to
not work well with the qemu aio model. If that assumption is wrong,
we'd be happy to change it. In any case, there are other more portable
ways to generate fds, so if it's needed we can do that.
>> +static int rbd_rw(BlockDriverState *bs, int64_t sector_num,
>> + uint8_t *buf, int nb_sectors, int write)
>> +{
>> + BDRVRBDState *s = bs->opaque;
>> + char n[RBD_MAX_SEG_NAME_SIZE];
>> +
>
> You don't need to implement synchronous functions as long as you have the
> async interfaces implemented.
Snipped.
>> + */
>> + if (sn_info->id_str[0] != '\0'&&
>> + strcmp(sn_info->id_str, sn_info->name) != 0)
>> + return -EINVAL;
>>
>
> I don't fully understand. Does this mean that snapshots are stored in a
> shared namespace? IOW, if a user root creates a snapshot of in one VM, the
> other VM running as root sees it too?
>
Snapshots are stored in a namespace for each block device. If you
share a block device between different vms, you'll also share its
snapshots.
Thanks,
Yehuda
^ permalink raw reply
* RE: New Hypercall Declaration
From: Dan Magenheimer @ 2010-10-07 18:07 UTC (permalink / raw)
To: Nimgaonkar, Satyajeet, xen-devel
In-Reply-To: <12871952FC0E29439F861FA745BCDD8503EC410F@CH1PRD0104MB027.prod.exchangelabs.com>
[-- Attachment #1.1: Type: text/plain, Size: 6578 bytes --]
The hypercall_table and hypercall_args_table are initialized sequences of quads and bytes. Even though you have put 56 in the comment, you are initializing the table entry immediately following the 48th entry, which would be hypercall 49. You need to fill the entries from 49 to 55 in both tables with the appropriate values. (The assembler syntax for these tables is weird, e.g. endr and rept, and I am not an expert on it.)
From: Nimgaonkar, Satyajeet [mailto:SatyajeetNimgaonkar@my.unt.edu]
Sent: Thursday, October 07, 2010 11:37 AM
To: Dan Magenheimer; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] New Hypercall Declaration
Hi Dan,
I followed your instruction from the below email, but still I am getting -1 for hypercall invocation. These are the steps I followed.
1. Add my hypercall in xen.h ---- #define __HYPERVISOR_jeet1 56
2. Added it to entry.S - hypercall table ---- .quad do_mca /* 48 */
.quad do_jeet1 /* 56 */
- hypercall_args_table ---- .byte 1 /* do_mca */ /* 48 */
.byte 0 /* do_jeet1 */ /* 56 */
3. Then declared my hypercall in asm-x86/hypercall.h ---- void do_jeet1(void);
4. Then calling it in domctl.c in xen/common --- void do_jeet1(void){
printk ("Successfull Hypercall made to __HYPERVISOR_jeet1");
}
5. Declared a function in xc_domain.c in xen/tools to call this hypercall
int hypercall_test(int handle){
int rc;
int arg=0;
//int cmd=1;
//
//int test;
/* Hypercall definitions */
DECLARE_HYPERCALL;
hypercall.op = __HYPERVISOR_jeet1;
rc = do_xen_hypercall(handle, &hypercall);
hypercall.arg[0] = 0;
hypercall.arg[1] = (unsigned long)&arg;
//printf ("Hypercall Details: %d\n", rc);
//xc_interface_close(handle);
return rc;
}
6. Then wrote a userlevel program to call function hypercall_test and invoke my hypercall.
#include <xenctrl.h>
#include <stdio.h>
int main(){
printf("Attempt to invoke the hypercall: __HYPERVISOR_jeet1\n");
int handle, rc;
/* Acquire Hypervisor Interface Handle.
This handle goes as the first argument for the function do_xen_hypercall()
*/
handle = xc_interface_open();
printf ("Acquired handle to Xen Hypervisor:%d\n",handle);
rc = hypercall_test(handle);
printf ("Hypercall Details: %d\n", rc);
xc_interface_close(handle);
printf ("Hypervisor handle closed\n");
return 0;
}
I compiled entire xen, installed it and booted into the atest compiled xen. But still my userlevel program compiles error free but returns me a -1 error for hypercall invocation. Can you please tell me what is that I doing wrong.
Thanks.
Regards,
Satyajeet Nimgaonkar
_____
From: Dan Magenheimer [dan.magenheimer@oracle.com]
Sent: Thursday, September 30, 2010 4:47 PM
To: Nimgaonkar, Satyajeet; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] New Hypercall Declaration
Do you understand that you must also change the hypervisor to recognize and do something with your new hypercall? Your userland code may actually be working and the hypercall may actually be resulting in an entry into the hypervisor, but unless the hypervisor is modified to recognize the new hypercall (#56) and do something with it, the hypervisor will generate a return value of -1 (essentially saying "I don't recognize this hypercall number").
If you have modified the hypervisor, please share that patch. If not, you will need to modify at least the hypercall_table and the hypercall_args_table in entry.S (under x86, x86_64, and x86_64/compat, or all three, depending on the bit-ness of your hypervisor and guest) and create a do_my_hypercall() routine somewhere. Then of course you will need to ensure that you are properly building, installing, and booting your newly modified hypervisor.
Printk's done inside the hypervisor can be viewed using "xm dmesg" or via a properly configured serial port.
Use "xm info" and look at cc_compile_date to ensure you are booting your newly modified hypervisor.
Hope that helps,
Dan
From: Nimgaonkar, Satyajeet [mailto:SatyajeetNimgaonkar@my.unt.edu]
Sent: Thursday, September 30, 2010 4:03 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] New Hypercall Declaration
Hello Xen Developers,
I am currently working on declaring a new hypercall in Xen.
For this i have declared my hypercall in xen.h -
#define __HYPERVISOR_jeet1 56
Then I modified the xcom_privcmd.c to accomodate my hypercall -
case __HYPERVISOR_jeet1:
printk("Successfull Hypercall made to
__HYPERVISOR_jeet1");
I defined the structure for the Hypercall in xc_domain.c
int hypercall_test(int handle){
int rc;
/* Hypercall definitions */
DECLARE_HYPERCALL;
hypercall.op = __HYPERVISOR_jeet1;
rc = do_xen_hypercall(handle, &hypercall);
hypercall.arg[0] = 0;
hypercall.arg[1] = 1;
//printf ("Hypercall Details: %d\n", rc);
//xc_interface_close(handle);
return rc;
}
And then I am calling this Hypercall through an user level program-
#include <xenctrl.h>
#include <stdio.h>
int main(){
printf("Attempt to invoke the hypercall: __HYPERVISOR_jeet1\n");
int handle, rc;
/* Acquire Hypervisor Interface Handle.
This handle goes as the first argument for the function do_xen_hypercall()
*/
handle = xc_interface_open();
printf ("Acquired handle to Xen Hypervisor:%d\n",handle);
rc = hypercall_test(handle);
printf ("Hypercall Details: %d\n", rc);
xc_interface_close(handle);
return 0;
}
The program compiles properly but gives me -1 error for rc. I have posted the same query and I got replies on it. But even after trying many things, I am still stuck with this problem. Can anyone please tell me what I am doing wrong here. Also please tell me where
should I view the output of printk in xen.
Thanks in advance.
Regards,
Satyajeet Nimgaonkar
[-- Attachment #1.2: Type: text/html, Size: 16899 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [linux-lvm] Grub with UUID
From: Fabricio Archanjo @ 2010-10-07 18:07 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <1286473135.2287.0@raydesk1.bettercgi.com>
Ray,
When I use root=/dev/mapper/myvg-root (example) i can mount my root
partition, but when i use UUID i cannot mount and the lvm was
included in initramfs, i've checked it. It's too strange..
I get my UUID through vol_id, it's a tools of udev.
Thanks for reply,
On Thu, Oct 7, 2010 at 2:38 PM, Ray Morris <support@bettercgi.com> wrote:
>> I wanted to use GRUB with UUID when i pass the
>> boot flags root=. When i did this, my system cannot mount the root
>> more.
>
> root= is not a grub argument, it's a kernel argument.
> If it's wrong, you'll get a few dozen lines of output and then
> it'll say "can not mount root filesystem" or something similar.
>
> root (hd0,0) would be grub. �If it's wrong, you'll get less than
> a dozen lines of output before the error message.
>
> Try mounting first with root=/dev/sda2 or whatever, then double
> check a) the UUID and b) the syntax you're using, which should be
> something like:
> root=UUID=xxx
>
> If the root volume isn't a plain disk partition, but is rather
> a logical voume or mdadm, your initrd will need to include lvm,
> raid, or whatever else is needed to get the root volume up and
> running.
>
> See also super grub disk, which can be helpful for figuring all
> of this stuff out.
> --
> Ray Morris
> support@bettercgi.com
>
> Strongbox - The next generation in site security:
> http://www.bettercgi.com/strongbox/
>
> Throttlebox - Intelligent Bandwidth Control
> http://www.bettercgi.com/throttlebox/
>
> Strongbox / Throttlebox affiliate program:
> http://www.bettercgi.com/affiliates/user/register.php
>
>
> On 10/07/2010 12:12:56 PM, Fabricio Archanjo wrote:
>>
>> Hey all,
>>
>>
>> Sorry because my stupid question, but i don't know more. I'm using
>> Debian with LVM and I wanted to use GRUB with UUID when i pass the
>> boot flags root=. When i did this, my system cannot mount the root
>> more. May someone know why it happend? is there a problem with GRUB
>> v1??
>>
>>
>> Thanks all,
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
^ permalink raw reply
* Re: [RFC PATCH] poll(): add poll_wait_set_exclusive()
From: Mathieu Desnoyers @ 2010-10-07 18:07 UTC (permalink / raw)
To: Steven Rostedt
Cc: Linus Torvalds, LKML, Andrew Morton, Peter Zijlstra, Ingo Molnar,
Frederic Weisbecker, Thomas Gleixner, Christoph Hellwig, Li Zefan,
Lai Jiangshan, Johannes Berg, Masami Hiramatsu,
Arnaldo Carvalho de Melo, Tom Zanussi, KOSAKI Motohiro,
Andi Kleen, Paul E. McKenney
In-Reply-To: <1286473864.6661.16.camel@gandalf.stny.rr.com>
* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Thu, 2010-10-07 at 13:07 -0400, Mathieu Desnoyers wrote:
> > * Steven Rostedt (rostedt@goodmis.org) wrote:
> > > On Wed, 2010-10-06 at 15:04 -0400, Mathieu Desnoyers wrote:
> > >
> > > > For reference, here is the use-case: The user-space daemon runs typically one
> > > > thread per cpu, each with a handle on many file descriptors. Each thread waits
> > > > for data to be available using poll(). In order to follow the poll semantic,
> > > > when data becomes available on a file descriptor, the kernel wakes up all
> > > > threads at once, but in my case only one of them will successfully consume the
> > > > data (all other thread's splice or read will fail with -ENODATA). With many
> > > > threads, these useless wakeups add an unwanted overhead and scalability
> > > > limitation.
> > >
> > > Mathieu, I'm curious to why you have multiple threads reading the same
> > > fd. Since the threads are per cpu, does the fd handle all CPUs?
> >
> > The fd is local to a single ring buffer (which is per-cpu, transporting a group
> > of events). The threads consuming the file descriptors are approximately per
> > cpu, modulo cpu hotplug events, user preferences, etc. I would prefer not to
> > make that a strong 1-1 mapping (with affinity and all), because a typical
> > tracing scenario is that a single CPU is heavily used by the OS (thus producing
> > trace data), while other CPUs are idle, available to pull the data from the
> > buffers. Therefore, I strongly prefer not to affine reader threads to their
> > "local" buffers in the general case. That being said, it could be kept as an
> > option, since it might make sense in some other use-cases, especially with tiny
> > buffers, where it makes sense to keep locality of reference in the L2 cache.
>
> I never mention affinity. As with trace-cmd, it assigns a process per
> CPU, but those processes can be on any CPU that the scheduler chooses. I
> could probably do it with a single process reading all the CPU fds too.
> I might add that as an option.
Your scheme works fine because you have only one stream (and thus one fd) per
cpu. How would you map that with many streams per cpu ?
Also, you might want to consider using threads rather than processes, to save
the unnecessary VM swaps.
>
> >
> > > Or do you have an fd per event per CPU, in which case the threads should just
> > > poll off of their own fds.
> >
> > I have one fd per per-cpu buffer, but there can be many per-cpu buffers, each
> > transporting a group of events. Therefore, I don't want to associate one thread
> > per event group, because this would be a resource waste. Typically, only a few
> > per-cpu buffers will be very active, and others will be very quiet.
>
> Lets not talk about threads, what about fds? I'm wondering why you have
> many threads on the same fd?
That's because I have fewer threads than file descriptors. So I can choose to
either:
1) somehow assign each thread to many fds statically or
2) make each thread wait for data on all fds
Option (2) adapts much better to workloads where a lots of data would come from
many file descriptors from a single CPU: all threads can collaboratively work to
extract the data.
Thanks,
Mathieu
>
> -- Steve
>
>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH 0/3] Enabling patches for Intel MID SDHCI
From: Chris Ball @ 2010-10-07 18:07 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-mmc
In-Reply-To: <20101004142246.901.37491.stgit@localhost.localdomain>
Hi Alan,
On Mon, Oct 04, 2010 at 03:23:55PM +0100, Alan Cox wrote:
> Try again...
>
> This adds basic support for the Intel MID platform devices. It doesn't include
> the callback stuff to handle some of the errata but I'm trying to verify
> which if any of those make sense outside of Intel before resubmitting that
> bit.
Thanks, applied to mmc-next / queued for 2.6.37.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [PATCH net-next] net: percpu net_device refcount
From: Eric Dumazet @ 2010-10-07 18:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20101007103051.63b5177c@nehalam>
Le jeudi 07 octobre 2010 à 10:30 -0700, Stephen Hemminger a écrit :
> It makes sense, but what about 256 cores and 1024 Vlans?
> That adds up to 4M of memory which is might be noticeable.
>
>
Well, 256 cores and 1024 Vlan -> 1 Mbyte of memory, not 4 ;)
This seems reasonable to me.
Eventually we could use a fallback, if percpu allocation failed -> use a
static field in net_device.
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Erik Faye-Lund @ 2010-10-07 18:05 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <20101007175358.GD12130@sigill.intra.peff.net>
On Thu, Oct 7, 2010 at 7:53 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote:
>
>> Erik Faye-Lund <kusmabite@gmail.com> writes:
>>
>> > Also, fwriting like that to stdout might be a bit troublesome on
>> > Windows because the string won't end up going through our
>> > ANSI-emulation.
>>
>> I don't know which one would be most portable, but if fwrite is the
>> problem, then
>>
>> printf("%*s%c", buf.buf, buf.len, info->hdr_termination);
>>
>> should do the trick.
>
> It does work, but you have to cast the buf.len size_t to an int.
>
I'm not sure how portable it is, though. This is what K&R has to say
on the matter: "characters from the string are printed until a ´\0´ is
reached or until the number of characters indicated by the precision
have been printed". To me it's not clear if that means that either
cases can terminate the printing when the precision has been
specified.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.