headers
Ingo Oeser | 1 Jan 2007 01:07
Picon

Re: [PATCH 4/8] KVM: Implement a few system configuration msrs

Hi,

On Thursday, 28. December 2006 11:11, Avi Kivity wrote:
> Index: linux-2.6/drivers/kvm/svm.c
> ===================================================================
> --- linux-2.6.orig/drivers/kvm/svm.c
> +++ linux-2.6/drivers/kvm/svm.c
>  <at>  <at>  -1068,6 +1068,9  <at>  <at>  static int emulate_on_interception(struc
>  static int svm_get_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 *data)
>  {
>  	switch (ecx) {
> +	case 0xc0010010: /* SYSCFG */
> +	case 0xc0010015: /* HWCR */
> +	case MSR_IA32_PLATFORM_ID:
>  	case MSR_IA32_P5_MC_ADDR:
>  	case MSR_IA32_P5_MC_TYPE:
>  	case MSR_IA32_MC0_CTL:

What about just defining constants for these?
Then you can rip out these comments.

Same for linux-2.6/drivers/kvm/vmx.c

Regards

Ingo Oeser

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amit Choudhary | 1 Jan 2007 01:17
Picon

[PATCH] include/linux/slab.h: new KFREE() macro.

Description: new KFREE() macro to set the variable NULL after freeing it.

Signed-off-by: Amit Choudhary <amit2030 <at> gmail.com>

diff --git a/include/linux/slab.h b/include/linux/slab.h
index 1ef822e..28da74c 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
 <at>  <at>  -75,6 +75,12  <at>  <at>  void *__kzalloc(size_t, gfp_t);
 void kfree(const void *);
 unsigned int ksize(const void *);

+#define KFREE(x)		\
+	do {			\
+		kfree(x);	\
+		x = NULL;	\
+	} while(0)
+
 /**
  * kcalloc - allocate memory for an array. The memory is set to zero.
  *  <at> n: number of elements.
Permalink | Reply | 3 comments |
headers
Ingo Oeser | 1 Jan 2007 01:43
Picon

Re: [PATCH] [DISCUSS] Make the variable NULL after freeing it.

On Sunday, 31. December 2006 14:38, Bernd Petrovitsch wrote:
> That depends on the decision/definition if (so called) "double free" is
> an error or not (and "free(NULL)" must work in POSIX-compliant
> environments).

A double free of non-NULL is certainly an error.
So the idea of setting it to NULL is ok, since then you can
kfree the variable over and over again without any harm.

It is just complicated to do this side effect free.

Maybe one should check for builtin-constant and take the address,
if this is not an builtin-constant.

sth, like this

#define kfree_nullify(x) do { \
	if (__builtin_constant_p(x)) { \
		kfree(x); \
	} else { \
		typeof(x) *__addr_x = &x; \
		kfree(*__addr_x); \
		*__addr_x = NULL; \
	} \
} while (0)

Regards

Ingo Oeser
(Continue reading)

Permalink | Reply | 7 comments |
headers
YOSHIFUJI Hideaki / 吉藤英明 | 1 Jan 2007 02:05
X-Face
Gravatar

Re: [PATCH] [DISCUSS] Make the variable NULL after freeing it.

In article <200701010143.02870.ioe-lkml <at> rameria.de> (at Mon, 1 Jan 2007 01:43:00 +0100), Ingo Oeser
<ioe-lkml <at> rameria.de> says:

> On Sunday, 31. December 2006 14:38, Bernd Petrovitsch wrote:
> > That depends on the decision/definition if (so called) "double free" is
> > an error or not (and "free(NULL)" must work in POSIX-compliant
> > environments).
> 
> A double free of non-NULL is certainly an error.
> So the idea of setting it to NULL is ok, since then you can
> kfree the variable over and over again without any harm.

I dislike (or, say, I hate) this idea; people should fix up
such broken code paths.

--yoshfuji
Permalink | Reply | 0 comments |
headers
Linus Torvalds | 1 Jan 2007 02:19

Happy New Year (and v2.6.20-rc3 released)


In order to not get in trouble with MADR ("Mothers Against Drunk 
Releases") I decided to cut the 2.6.20-rc3 release early rather than wait 
for midnight, because it's bound to be new years _somewhere_ out there. So 
here's to a happy 2007 for everybody.

The big thing at least for me personally is that nasty shared mmap 
corruption fix, but there's a number of other changes in here, many of 
them just documentation (and some media and network drivers). Shortlog and 
diffstat appended..

The git trees have been updated, and the tar-tree and patches seem to have 
finisged crawling out my poor DSL connection too.

As usual, mirroring might take a while, although the delay has not been 
all that horrible lately, so it's probably going to be up-to-date by the 
time the hangovers are mostly gone.

At which point the first thing on any self-respecting geek's mind should 
obviously be: "is there a new kernel release for me to try?"

Right?

			Linus

----
Adrian Bunk (2):
      V4L/DVB (4959): Usbvision: possible cleanups
      V4L/DVB (4991): Cafe_ccic.c: fix NULL dereference
(Continue reading)

Permalink | Reply | 20 comments |
headers
Pierre Ossman | 1 Jan 2007 02:33

Re: [PATCH 2.6.20-rc2] Add a quirk to allow at least some ENE PCI SD card readers to work again

Darren Salt wrote:
> 
> (BTW, is there a version of Thunderbird which preserves Mail-Followup-To in
> followups? I ask because I see that that header got lost...)
> 

No idea, I'm just a user. ;)

Its handling of Mail-Followup-To is generally rather annoying. It doesn't strip out my own email from the
list, so a "Reply All" includes myself in the to list.

Rgds
--

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
Permalink | Reply | 0 comments |
headers
Gene Heskett | 1 Jan 2007 02:39
Picon

Re: Happy New Year (and v2.6.20-rc3 released)

On Sunday 31 December 2006 20:19, Linus Torvalds wrote:
>In order to not get in trouble with MADR ("Mothers Against Drunk
>Releases") I decided to cut the 2.6.20-rc3 release early rather than
> wait for midnight, because it's bound to be new years _somewhere_ out
> there. So here's to a happy 2007 for everybody.
>
>The big thing at least for me personally is that nasty shared mmap
>corruption fix, but there's a number of other changes in here, many of
>them just documentation (and some media and network drivers). Shortlog
> and diffstat appended..
>
>The git trees have been updated, and the tar-tree and patches seem to
> have finisged crawling out my poor DSL connection too.
>
>As usual, mirroring might take a while, although the delay has not been
>all that horrible lately, so it's probably going to be up-to-date by the
>time the hangovers are mostly gone.
>
>At which point the first thing on any self-respecting geek's mind should
>obviously be: "is there a new kernel release for me to try?"
>
>Right?
>
Right.  Have a Happy New Year yourself, Linus.

>			Linus
>
>----
>Adrian Bunk (2):
>      V4L/DVB (4959): Usbvision: possible cleanups
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Davidsen | 1 Jan 2007 02:59

Re: Linux disk performance.

Phillip Susi wrote:
> Bill Davidsen wrote:
>> Quite honestly, the main place I have found O_DIRECT useful is in 
>> keeping programs doing large i/o quantities from blowing the buffers 
>> and making the other applications run like crap. If you application is 
>> running alone, unless you are very short of CPU or memory avoiding the 
>> copy to an o/s buffer will be down in the measurement noise.
>>
>> I had a news (usenet) server which normally did 120 art/sec (~480 
>> tps), which dropped to about 50 tps when doing large file copies even 
>> at low priority. By using O_DIRECT the impact essentially vanished, at 
>> the cost of the copy running about 10-15% slower. Changing various 
>> programs to use O_DIRECT only helped when really large blocks of data 
>> were involved, and only when i/o clould be done in a way to satisfy 
>> the alignment and size requirements of O_DIRECT.
>>
>> If you upgrade to a newer kernel you can try other i/o scheduler 
>> options, default cfq or even deadline might be helpful.
> 
> I would point out that if you are looking for optimal throughput and 
> reduced cpu overhead, and avoid blowing out the kernel fs cache, you 
> need to couple aio with O_DIRECT.  By itself O_DIRECT will lower 
> throughput because there will be brief pauses between each IO while the 
> application prepares the next buffer.  You can overcome this by posting 
> a few pending buffers concurrently with aio, allowing the kernel to 
> always have a buffer ready for the next io as soon as the previous one 
> completes.

A good point, but in this case there was no particular urgency, other 
than not to stop the application while doing background data moves. The
(Continue reading)

Permalink | Reply | 0 comments |
headers
Folkert van Heusden | 1 Jan 2007 02:59
Gravatar

Re: replace "memset(...,0,PAGE_SIZE)" calls with "clear_page()"?

> > regarding alignment that don't allow clear_page() to be used
> > copy_page() in the memcpy() case), but it's going to need a lot of

Maybe these optimalisations should be in the coding style docs?

Folkert van Heusden

--

-- 
Ever wonder what is out there? Any alien races? Then please support
the seti <at> home project: setiathome.ssl.berkeley.edu
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
Permalink | Reply | 6 comments |
headers
Jan Engelhardt | 1 Jan 2007 03:00
Picon

chaostables 0.2

Hi list(s),

chaostables is a small package containing some nice netfilter magic:
a module xt_portscan which matches the nmap scan types (including -sS) 
and more, and a xt_CHAOS module which slows down network scanners by 
triggering their codepaths for handling slow-working/'broken' operating 
systems.

Documentation is not yet fully complete, but it explains the details 
behind the portscan match and how it can be implemented without using 
the xt_portscan.ko module. By looking at the code and some example 
files, it should be possible to figure out how to use these (obviously, 
-m portscan [types] and -j CHAOS -- but a little self-experimenting is 
always good, too.)

http://jengelh.hopto.org/f/chaostables/chaostables-0.2.tar.bz2
(it is a remake of what was previously known, and now inaccessible, as 
AS_IPFW)

I happily take comments on anything.

Thanks and, FWIW, happy  new Year(),
Jan
--

--
Permalink | Reply | 0 comments |

Gmane