From: Rusty Russell <rusty@rustcorp.com.au>
To: Richard Gooch <rgooch@ras.ucalgary.ca>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: bit ops on unsigned long?
Date: Mon, 25 Mar 2002 15:27:56 +1100 [thread overview]
Message-ID: <E16pM5N-0000zb-00@wagner.rustcorp.com.au> (raw)
In-Reply-To: Your message of "Sun, 24 Mar 2002 19:45:26 PDT." <200203250245.g2P2jQa20821@vindaloo.ras.ucalgary.ca>
In message <200203250245.g2P2jQa20821@vindaloo.ras.ucalgary.ca> you write:
> Rusty Russell writes:
> > Richard: 3 bugs in devfs. Particularly note that the memset was
> > bogus. I can't convince myself that your memcpy & memset stuff is
> > right anyway, given that you can ONLY treat them as unsigned longs
> > (ie. bit 31 will be in byte 0 or byte 3, depending on endianness).
>
> Yes, the memset is bogus because I didn't cast the pointer to a
> char * or void *.
Yes.
> The memcpy should be fine, though. And so should
> everything else, because the bitfield array is allocated in 16 byte
> multiples.
No:
struct major_list
{
spinlock_t lock;
- __u32 bits[8];
+ unsigned long bits[256 / BITS_PER_LONG];
};
/* Block majors already assigned:
@@ -212,7 +212,7 @@
struct minor_list
{
int major;
- __u32 bits[8];
+ unsigned long bits[256 / BITS_PER_LONG];
struct minor_list *next;
};
These changed are required because otherwise you try to do set_bit on
something not aligned as a long on all archs.
(Turning to the gallery) I assert: if you're going to do bitops on it,
make it a "unsigned long".
> So there should be no issues with big vs. little endian,
> since memset/memcpy operations are done in blocks of sufficient
> alignment.
I think you're right, as long as length is always a multiple of
sizeof(long). This is not obvious from this hunk of code alone, which
is why I queried it...
if (space->num_free < 1)
{
if (space->length < 16) length = 16;
else length = space->length << 1;
if ( ( bits = vmalloc (length) ) == NULL )
{
up (&space->semaphore);
return -ENOMEM;
}
if (space->bits != NULL)
{
memcpy (bits, space->bits, space->length);
vfree (space->bits);
}
space->num_free = (length - space->length) << 3;
space->bits = bits;
memset (bits + space->length, 0, length - space->length);
space->length = length;
}
Thanks!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2002-03-25 4:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-16 0:52 Rusty Russell
2002-03-16 0:58 ` Linus Torvalds
2002-03-16 3:08 ` Rusty Russell
2002-03-25 2:45 ` Richard Gooch
2002-03-25 4:27 ` Rusty Russell [this message]
2002-03-25 6:21 ` Richard Gooch
2002-03-25 7:07 ` Rusty Russell
2002-03-25 7:12 ` Richard Gooch
2002-03-18 4:08 ` David S. Miller
2002-03-18 6:03 ` Jeff Garzik
2002-03-18 6:43 ` David S. Miller
2002-03-18 9:13 ` Rusty Russell
2002-03-16 1:00 ` Anton Blanchard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E16pM5N-0000zb-00@wagner.rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=rgooch@ras.ucalgary.ca \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®