Re: That whole "Linux stealing our code" thing

[Valdis . Kletnieks]

On Sun, 02 Sep 2007 01:09:18 EDT, "Constantine A. Murenin" said:

> The idea here is that no patching was needed in the first place --
> most of the files are/were BSD-licensed, because they were forked from
> OpenBSD.

Oh, silly me.  For some reason, I had it in my head that Jiri's original
patch actually included some real live *code* in addition to the parts that
changed the licensing text... ;)


pgprleStwYKWh.pgp
Description: PGP signature

Re: 2.6.23-rc4-mm1 OOPS in forcedeth?

[thunder7]

From: Satyam Sharma <[EMAIL PROTECTED]>
Date: Sun, Sep 02, 2007 at 06:24:29AM +0530
> 
> The dmesg you posted below doesn't cover the messages from this oops
> itself. As you mentioned you can reproduce this oops easily, please do so,
> and post the *full* oops log (if it doesn't get logged to disk, you can
> try taking digicam photo, or write down *all* the messages and post here).
> I built an x86_64 kernel as per your .config, but don't see any memory
> dereference at nv_napi_poll+0x108 -- could be toolchain differences.
> 
> Else, can you run:
> $ gdb ./vmlinux
> 
> and then:
> (gdb) l *nv_napi_poll+0x108
> 
> and send us the output?
> 
That seems to be the easier option:

AMD64 :gdb /usr/src/linux-2.6.23-rc4-mm1/vmlinux
GNU gdb 6.6-debian
(gdb) l *nv_napi_poll+0x108
0x80418f28 is in nv_napi_poll (drivers/net/forcedeth.c:2470).
2465if ((flags & NV_RX2_CHECKSUMMASK) == 
NV_RX2_CHECKSUMOK2)/*ip and tcp */ {
2466skb->ip_summed = CHECKSUM_UNNECESSARY;
2467} else {
2468if ((flags & NV_RX2_CHECKSUMMASK) == 
NV_RX2_CHECKSUMOK1 ||
2469(flags & NV_RX2_CHECKSUMMASK) == 
NV_RX2_CHECKSUMOK3) {
2470skb->ip_summed = 
CHECKSUM_UNNECESSARY;
2471}
2472}
2473
2474/* got a valid packet - forward it to the 
network core */
(gdb) q

as for toolchain differences: this is Debian Unstable, up-to-date as of
yesterday morning.

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux middle 2.6.23-rc1-mm2 #1 SMP Wed Aug 1 14:58:22 CEST 2007 x86_64 GNU/Linux
 
Gnu C  4.1.3
Gnu make   3.81
binutils   Binutils
util-linux 2.13
mount  2.13
module-init-tools  3.3-pre11
e2fsprogs  1.40.2
reiserfsprogs  3.6.19
Linux C Library6.1
Dynamic linker (ldd)   2.6.1
Procps 3.2.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.97
Modules Loaded nf_nat_ftp nf_nat_irc nf_conntrack_irc nf_conntrack_ftp 
ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT ipt_LOG xt_limit nf_conntrack_ipv4 
xt_state xt_tcpudp iptable_filter ip_tables x_tables snd_emu10k1_synth 
snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_seq_dummy 
snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq snd_rawmidi snd_ac97_codec 
ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_device snd_timer 
snd_page_alloc snd_util_mem snd_hwdep snd soundcore k8temp it87 hwmon_vid hwmon 
i2c_nforce2

Good luck,
Jurriaan
-- 
His pride could withstand anything. He simply wouldn't care.
Melanie Rawn - Skybowl
Debian (Unstable) GNU/Linux 2.6.23-rc1-mm2 2x2010 bogomips load 0.43
the Jack Vance Integral Edition: http://www.integralarchive.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net/ipv4/af_inet.c: use ARRAY_SIZE macro from kernel.h instead

[Robert P. J. Day]

On Sun, 2 Sep 2007, Denis Cheng wrote:

> Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
> ---
>  net/ipv4/af_inet.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index e681034..d5e8b67 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -939,7 +939,7 @@ static struct inet_protosw inetsw_array[] =
> }
>  };
>
> -#define INETSW_ARRAY_LEN (sizeof(inetsw_array) / sizeof(struct inet_protosw))
> +#define INETSW_ARRAY_LEN ARRAY_SIZE(inetsw_array)
>
>  void inet_register_protosw(struct inet_protosw *p)
>  {

denis:

if you're planning on doing this ARRAY_SIZE cleanup fairly rigorously,
here's an overview of what you're looking (based on a fairly dumb
scanning script that undoubtedly generates some false positives).  of
course, the respective subsystem maintainers are welcome to deal with
them first, of course.

p.s.  and when you submit those patches, it's necessary to submit them
to only the appropriate subsystem mailing lists, not to the LKML in
general.


= Where ARRAY_SIZE() might be used ...

./Documentation/CodingStyle:  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
./Documentation/hpet.txt:   for (i = 0; i < (sizeof (hpet_command) / sizeof 
(hpet_command[0])); i++)
./Documentation/spi/spidev_test.c:#define ARRAY_SIZE(a) (sizeof(a) / 
sizeof((a)[0]))
./include/acpi/acmacros.h:#define ACPI_ARRAY_LENGTH(x)(sizeof(x) / 
sizeof((x)[0]))
./include/linux/netfilter/xt_sctp.h:#define ELEMCOUNT(x) 
(sizeof(x)/sizeof(x[0]))
./include/linux/kernel.h:#define ARRAY_SIZE(arr) (sizeof(arr) / 
sizeof((arr)[0]) + __must_be_array(arr))
./include/asm-parisc/mmzone.h:  BUG_ON(i >= sizeof(pfnnid_map) / 
sizeof(pfnnid_map[0]));
./include/asm-sh/hw_irq.h:#define _INTC_ARRAY(a) a, sizeof(a)/sizeof(*a)
./include/video/sgivw.h:#define DBE_VT_SIZE  
(sizeof(dbeVTimings)/sizeof(dbeVTimings[0]))
./include/net/ip_vs.h:#define IP_VS_INIT_HASH_TABLE(t) ip_vs_init_hash_table(t, 
sizeof(t)/sizeof(t[0]))
./kernel/compat.c:  for (j = 0; j < sizeof(m)/sizeof(um); j++) {
./kernel/compat.c:  for (j = 0; j < sizeof(m)/sizeof(um); j++) {
./arch/m68k/amiga/amisound.c:#define DATA_SIZE  
(sizeof(sine_data)/sizeof(sine_data[0]))
./arch/i386/boot/compressed/relocs.c:#define ARRAY_SIZE(x) (sizeof(x) / 
sizeof((x)[0]))
./arch/x86_64/kernel/smpboot.c: for (i = 0; i < sizeof(regs) / sizeof(*regs); 
i++) {
./arch/mips/au1000/common/dbdma.c:#define DBDEV_TAB_SIZE (sizeof(dbdev_tab) / 
sizeof(dbdev_tab_t))
./arch/cris/arch-v10/kernel/setup.c:if (revision >= sizeof cpu_info/sizeof 
*cpu_info)
./arch/cris/arch-v10/kernel/setup.c:info = _info[sizeof 
cpu_info/sizeof *cpu_info - 1];
./arch/um/include/user.h:#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
./arch/um/kernel/tt/ptproxy/ptrace.c:   for (i = 0; i < 
sizeof(regs)/sizeof(regs[0]); i++)
./arch/um/kernel/tt/ptproxy/ptrace.c:   for (i = 0; i < 
sizeof(regs)/sizeof(regs[0]); i++)
./arch/um/kernel/tt/ptproxy/ptrace.c:   for (i = 0; i < 
sizeof(regs)/sizeof(regs[0]); i++)
./arch/um/kernel/tt/ptproxy/ptrace.c:   for (i = 0; i < 
sizeof(regs)/sizeof(regs[0]); i++)
./arch/um/kernel/tt/ptproxy/ptrace.c:   for (i = 0; i < 
sizeof(regs)/sizeof(regs[0]); i++)
./arch/um/kernel/tt/ptproxy/ptrace.c:   for (i = 0; i < 
sizeof(regs)/sizeof(regs[0]); i++)
./arch/arm/kernel/dma-isa.c:for (i = 0; i < sizeof(dma_resources) / 
sizeof(dma_resources[0]); i++)
./arch/avr32/mach-at32ap/time-tc.c: int divs_size = sizeof(divs) / 
sizeof(*divs);
./arch/powerpc/platforms/celleb/scc_sio.c:  for(i = 0; i < 
sizeof(txx9_scc_tab)/sizeof(txx9_scc_tab[0]); i++) {
./arch/powerpc/boot/types.h:#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
./scripts/mod/file2alias.c:#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
./drivers/char/synclink_gt.c:   static unsigned int count = 
sizeof(patterns)/sizeof(patterns[0]);
./drivers/mtd/nand/excite_nandflash.c: sizeof 
partition_info / sizeof partition_info[0]);
./drivers/message/fusion/mptbase.c: if (u16cnt < 
sizeof(ioc->hs_reply) / sizeof(ioc->hs_reply[0]))
./drivers/serial/mcfserial.c:   
(sizeof(mcfrs_baud_table)/sizeof(mcfrs_baud_table[0]))
./drivers/serial/68328serial.c:#define BAUD_TABLE_SIZE 
(sizeof(baud_table)/sizeof(baud_table[0]))
./drivers/serial/68328serial.c: for (i = 0; i < sizeof(baud_table) / 
sizeof(baud_table[0]); i++)
./drivers/serial/68328serial.c: if (i >= sizeof(baud_table) / 
sizeof(baud_table[0])) {
./drivers/zorro/names.c:#define MANUF( manuf, name ){ 0x##manuf, 
sizeof(__prods_##manuf) / sizeof(struct zorro_prod_info), __manufstr_##manuf, 
__prods_##manuf },
./drivers/media/video/saa7134/saa7134-tvaudio.c:#define TVAUDIO 
(sizeof(tvaudio)/sizeof(struct saa7134_tvaudio))
./drivers/media/video/tveeprom.c:#define STRM(array,i) (i < 
sizeof(array)/sizeof(char*) ? array[i] : 

Re: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Sun, 02 Sep 2007 03:55:37 +0200, Adrian Bunk said:
>
> > Jiri's patch would have wrongly not only removed the BSD statement from
> > dual licenced files but also from not dual licenced files.
> >
> > This was a mistake in this patch (that was never merged into the tree)
> > neither Jiri nor Alan noticed.
>
> You know, we *could* have solved this a *hell* of a lot easier if people quit
> flaming about it, and we did something *productive* instead.
>
> Like submit a corrected patch. :)

Dear Valdis,

The idea here is that no patching was needed in the first place --
most of the files are/were BSD-licensed, because they were forked from
OpenBSD.

It is beneficial for the atmosphere of both projects to keep the
licence compatible. If Linux tries to GPL future modifications to
Reyk's code, then OpenBSD would not be able to take back the changes.
But this would not be the case if all modifications to Reyk's code are
continued to be BSD-licensed. This is what this whole issue is about.

My understanding, is that Nick Kossifidis never had a problem with
licensing his changes with a BSD-license, although Jiri Slaby always
used GPLv2.

With the last patch posted by Luis [0], Jiri actually recalled his
original patch and relicensed all of his GPLv2 work under BSD (!);
however, at the very same time, Nick changed his mind, and decided to
relicense his BSD code under GPLv2 (!). (Surprise! Yes, it appears
that both Nick and Jiri decided to switch their licensing positions,
and mutually relicense their work under each other's respective
licence. :) Is everyone ready going to go back and forth now? Does
this whole story still makes any sense to you? :)

I hope that both Nick Kossifidis and Jiri Slaby can agree on licensing
their HAL code with a BSD licence, so that the code remains
licence-compatible with OpenBSD. If there are any unresolved licensing
questions, I personally would be more than happy to answer any such
questions as much as I can, and yes -- I am not a lawyer. :)

Nick, Jiri -- since much of the work on OpenHAL is based on Reyk's
HAL, could you please be so kind as to both agree to licence you
changes in OpenHAL with the same licence as Reyk does in OpenBSD's
ath(4) HAL? This step will be very welcome in the OpenBSD community at
large.

Best regards,
Constantine.

[0] http://marc.info/?l=linux-wireless=118857712529898=2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net/ipv4/af_inet.c: use ARRAY_SIZE macro from kernel.h instead

[Denis Cheng]

Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
 net/ipv4/af_inet.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index e681034..d5e8b67 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -939,7 +939,7 @@ static struct inet_protosw inetsw_array[] =
}
 };
 
-#define INETSW_ARRAY_LEN (sizeof(inetsw_array) / sizeof(struct inet_protosw))
+#define INETSW_ARRAY_LEN ARRAY_SIZE(inetsw_array)
 
 void inet_register_protosw(struct inet_protosw *p)
 {
-- 
1.5.3.rc7

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc4-mm1: unpingable box and NULL dereference at tcp_rto_min()

[Satyam Sharma]

On Sun, 2 Sep 2007, Alexey Dobriyan wrote:
> 
> Unable to handle kernel NULL pointer dereference at 0039 RIP: 
>  [] tcp_rto_min+0xc/0x20

tcp_rto_min() lacks a check-for-NULL. You want 5c127c58ae9bf196 from
the net-2.6.git tree -- so this will be gone in -rc6.

> P.S.: uh-oh, it's "[TCP] Allow minnimum RTO ..." aka 05bb1fad1cde

Yup, it came from this last commit in net-2.6 before -rc5.

[ Considering it's pretty core code (and thus the oops fairly easily
  reproducible), I initially thought this must've come from net-2.6.24.
  I suspect lot of testers might hit this, so would be wise to put that
  patch up as a hot-fix ? ]


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [1/1] Block device throttling [Re: Distributed storage.]

[Daniel Phillips]

On Friday 31 August 2007 14:41, Alasdair G Kergon wrote:
> On Thu, Aug 30, 2007 at 04:20:35PM -0700, Daniel Phillips wrote:
> > Resubmitting a bio or submitting a dependent bio from
> > inside a block driver does not need to be throttled because all
> > resources required to guarantee completion must have been obtained
> > _before_ the bio was allowed to proceed into the block layer.
>
> I'm toying with the idea of keeping track of the maximum device stack
> depth for each stacked device, and only permitting it to increase in
> controlled circumstances.

Hi Alasdair,

What kind of circumstances did you have in mind?

Regards,

Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [jffs2] [rfc] fix write deadlock regression

[Nick Piggin]

On Sat, Sep 01, 2007 at 12:06:03PM -0700, Jason Lunz wrote:
> 
> It introduced a wait to read_cache_page, as well as a
> read_cache_page_async function equivalent to the old read_cache_page
> without any callers.
> 
> Switching jffs2_gc_fetch_page to read_cache_page_async for the old
> behavior makes the deadlocks go away, but maybe reintroduces the
> use-before-uptodate problem? I don't understand the mm/fs interaction
> well enough to say.
> 
> Someone more knowledgable should see if similar deadlock issues may have
> been introduced for other read_cache_page callers, including the other
> two in jffs2.

Hmm, thanks for that. It does sound like it is deadlocking via
commit_write(). OTOH, it seems like it could be using the page
before it is uptodate -- it _may_ only be dealing with uptodate
data at that point... but if so, why even read_cache_page at
all?

However, it is a regression. So unless David can come up with a
more satisfactory approach, I guess we'd have to go with your
patch.



> 
> Signed-off-by: Jason Lunz <[EMAIL PROTECTED]>
> 
> ---
>  fs/jffs2/fs.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
> index 1d3b7a9..8bc727b 100644
> --- a/fs/jffs2/fs.c
> +++ b/fs/jffs2/fs.c
> @@ -627,7 +627,7 @@ unsigned char *jffs2_gc_fetch_page(struct jffs2_sb_info 
> *c,
>   struct inode *inode = OFNI_EDONI_2SFFJ(f);
>   struct page *pg;
>  
> - pg = read_cache_page(inode->i_mapping, offset >> PAGE_CACHE_SHIFT,
> + pg = read_cache_page_async(inode->i_mapping, offset >> PAGE_CACHE_SHIFT,
>(void *)jffs2_do_readpage_unlock, inode);
>   if (IS_ERR(pg))
>   return (void *)pg;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in 2.6.23-rc5

[Herbert Xu]

Christian Kujau <[EMAIL PROTECTED]> wrote:
> 
> today I switched from 2.6.22.3 to 2.6.23-rc5 (skipped quite a few -rc 
> versions due to lack of time), and the box keeps panicking under certain 
> circumstances. I suspected disk related problems, because: when the box 
> is up, I usually resume ~10 bittorrent files. When doing this, each
> file (~200MB...1GB) is checked and disk activity is pretty high (20MB/s
> or so), and after 1 minute of doing so the box panicks. Every time.

You want this patch (by davem).

Unfortunately people are travelling so I'm not sure when it'll
get picked up by Linus.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
From: [EMAIL PROTECTED] (David Miller)

> ip is at tcp_rto_min+0x20/0x40

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1ee7212..bbad2cd 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk)
struct dst_entry *dst = __sk_dst_get(sk);
u32 rto_min = TCP_RTO_MIN;
 
-   if (dst_metric_locked(dst, RTAX_RTO_MIN))
+   if (dst && dst_metric_locked(dst, RTAX_RTO_MIN))
rto_min = dst->metrics[RTAX_RTO_MIN-1];
return rto_min;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc4-mm1

[Mats Johannesson]

On 2007-09-01 16:07:48 Torsten Kaiser wrote:
[...]
> The good:
>> +hpet-force-enable-on-vt8235-37-chipsets.patch
>> +hpet-force-enable-on-vt8235-37-chipsets-fix.patch
>
> Kernel 2.6.23-rc4-mm1 works on one of my systems with:
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host
> Bridge (rev 01)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge
> [K8T800/K8T890 South]

And glory, glory, my Acer Aspire 1520 (1524) AMD64 notebook with the
old vt8235 chipset got a good kick in the behind as well. I didn't
even enable anything hpet related in the .config:

[EMAIL PROTECTED]:~# grep -i hpet /var/log/kern.log
Sep  2 05:36:59 sleipner kernel: Force enabled HPET at base address
0xfed0
Sep  2 05:36:59 sleipner kernel: hpet clockevent registered
Sep  2 05:37:13 sleipner kernel: Time: hpet clocksource has been
installed.

[EMAIL PROTECTED]:~# cat /proc/timer_list
[...]
Tick Device: mode: 1
Clock Event Device: hpet
 max_delta_ns:   149983015715
 min_delta_ns:   3352
 mult:   61496110
 shift:  32
 mode:   1
 next_event: 9223372036854775807 nsecs
 set_next_event: 
 set_mode:   
 event_handler:  
tick_broadcast_mask: 
tick_broadcast_oneshot_mask: 

For the benefit of Andreas Mohr (and other interested parties) I now
follow the instructions in "HPET force-enable investigations on Via
VT8235 (was: Re: extra"
http://marc.info/?l=linux-kernel=118643307224094=2

Diff for easy comparison:

--- lspci-d-1106-3177-xxx-23-rc4.txt
+++ lspci-d-1106-3177-xxx-23-rc4-mm1.txt
@@ -5,10 +5,10 @@
 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
 40: 44 80 f0 0b a0 0b 10 00 8c 20 00 00 04 00 00 08
 50: 01 08 09 00 00 00 00 00 43 9e 00 0a 10 fe 00 fe
-60: 00 00 60 00 01 60 0b 04 00 00 00 00 00 00 00 00
+60: 00 00 60 00 01 60 0b 04 80 00 d0 fe 00 00 00 00
 70: 06 11 77 31 00 00 00 00 00 00 00 00 20 00 00 00
 80: 00 84 59 00 da 40 00 00 01 40 00 00 00 18 00 00
-90: 00 75 0f 00 90 c1 07 00 00 3d 0f 00 00 00 00 00
+90: 00 75 0f 00 90 c1 07 00 00 3d 10 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00

Full dumps:

(On 2.6.23-rc4): lspci -d 1106:3177 -xxx
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00: 06 11 77 31 87 00 10 02 00 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 77 31
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
40: 44 80 f0 0b a0 0b 10 00 8c 20 00 00 04 00 00 08
50: 01 08 09 00 00 00 00 00 43 9e 00 0a 10 fe 00 fe
60: 00 00 60 00 01 60 0b 04 00 00 00 00 00 00 00 00
70: 06 11 77 31 00 00 00 00 00 00 00 00 20 00 00 00
80: 00 84 59 00 da 40 00 00 01 40 00 00 00 18 00 00
90: 00 75 0f 00 90 c1 07 00 00 3d 0f 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 44 00 00 00 00 00 00 00 04 00 00 00
f0: 00 00 00 00 00 00 1b 00 00 00 00 00 01 00 00 00

(On 2.6.23-rc4-mm1): lspci -d 1106:3177 -xxx
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00: 06 11 77 31 87 00 10 02 00 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 77 31
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
40: 44 80 f0 0b a0 0b 10 00 8c 20 00 00 04 00 00 08
50: 01 08 09 00 00 00 00 00 43 9e 00 0a 10 fe 00 fe
60: 00 00 60 00 01 60 0b 04 80 00 d0 fe 00 00 00 00
70: 06 11 77 31 00 00 00 00 00 00 00 00 20 00 00 00
80: 00 84 59 00 da 40 00 00 01 40 00 00 00 18 00 00
90: 00 75 0f 00 90 c1 07 00 00 3d 10 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 44 00 00 00 00 00 00 00 04 00 00 00
f0: 00 00 00 00 00 00 1b 00 00 00 00 00 01 00 00 00

And a full "lspci -nn":

00:00.0 Host bridge [0600]: VIA Technologies, Inc. K8M800 Host Bridge
[1106:0204]
00:00.1 Host bridge [0600]: VIA Technologies, Inc. K8M800 Host Bridge
[1106:1204]
00:00.2 Host bridge [0600]: VIA Technologies, Inc. K8M800 Host Bridge
[1106:2204]
00:00.3 Host bridge [0600]: VIA Technologies, Inc. K8M800 Host Bridge
[1106:3204]
00:00.4 Host bridge [0600]: VIA Technologies, Inc. K8M800 Host Bridge
[1106:4204]
00:00.7 Host bridge [0600]: VIA Technologies, Inc. K8M800 Host Bridge
[1106:7204]
00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8237 PCI bridge
[K8T800/K8T890 South] [1106:b188]
00:0a.0 Ethernet controller [0200]: Linksys, A Division of Cisco
Systems [AirConn] INPROCOMM IPN 2220 Wireless LAN Adapter (rev 01)
[17fe:2220]
00:0b.0 CardBus bridge [0607]: Texas Instruments PCI7420 CardBus
Controller [104c:ac8e]
00:0b.1 CardBus bridge [0607]: Texas Instruments 

Re: [Bugme-new] [Bug 8961] New: BUG triggered by oidentd in netlink code

[Herbert Xu]

Patrick McHardy <[EMAIL PROTECTED]> wrote:
> 
> Thanks. I'm not sure either, it would require two concurrent requests
> to be processed, but AFAICS oidentd only uses a single netlink socket.
> Perhaps multiple running instances or something else using the inet_diag
> interface?

Since identd serves requests from the outside world it is
quite possible for two identd instances to run simultaneously
serving two requests.

I'm not familiar with oidentd but this is certainly pidentd
works.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] Use macros instead of TASK_ flags

[Matthew Wilcox]

On Sat, Sep 01, 2007 at 08:35:06PM -0700, Daniel Walker wrote:
> Does it take task->state or task ?

task.  Clearly I didn't test on ia64.  (There was an iteration where it
took task->state, and I guess I missed one).  Thanks for pointing out
this oops, I'll fix it for round three.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: intel-rng on modern hardware

[Henrique de Moraes Holschuh]

On Sat, 01 Sep 2007, Jeff Garzik wrote:
> Shane wrote:
>> Just wondering if there is a newer version of intel-rng out
>> of tree or whether modern Intel chipsets have a usable RNG. I haven't been 
>> able to get intel-rng loading (no such
>> device) on anything from the p965, p975 or p35 chipsets.
>
> No modern ICH chipset has an RNG, AFAIK.

No ICH ever had one.

The i810 era Intel RNG is in the FWH (the firmware hub, aka BIOS FLASH
chip).  You can have it anywhere someone uses an original Intel 82802AB or
82802AC FWH, no matter the chipset (the FWH is a LPC device).

But you have to be lucky enough to get a Intel FWH, and one that has the RNG
inside working.  I doubt Intel is producing them anymore, but you could ask
them.  The last board I know of that had those *if you were lucky* was the
D875PBZ.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc4-mm1

[Herbert Xu]

On Sun, Sep 02, 2007 at 08:22:42AM +0530, Satyam Sharma wrote:
>
> So what finally got exported out of crypto/ to the rest of the kernel
> was just the crypto_alloc_xxx() wrapper. That resolves to a call to
> crypto_alloc_base() in crypto/api.c, which first loads the specific
> low-level algo modules, and then proceeds to crypto_init_ops(), which
> itself may, say, resolve to a crypto_init_digest_ops() -- the only
> interface exported from digest.c.

The mid-level code such as digest.c are only built-in because
they are legacy code.  All the new mid-level code such as
blkcipher/hash are registered dynamically.

Once all the digest stuff have been converted to hash digest.c
will be removed.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Valdis . Kletnieks]

On Sun, 02 Sep 2007 03:55:37 +0200, Adrian Bunk said:

> Jiri's patch would have wrongly not only removed the BSD statement from 
> dual licenced files but also from not dual licenced files.
> 
> This was a mistake in this patch (that was never merged into the tree) 
> neither Jiri nor Alan noticed.

You know, we *could* have solved this a *hell* of a lot easier if people quit
flaming about it, and we did something *productive* instead.

Like submit a corrected patch. :)


pgp9uMUk6CutD.pgp
Description: PGP signature

Re: [PATCH 2/5] Use macros instead of TASK_ flags

[Daniel Walker]

On Sat, 2007-09-01 at 22:46 -0400, Matthew Wilcox wrote:
> */
> if (task == current) return 0;
>  
> -   if ((task->state != TASK_STOPPED) && (task->state !=
> TASK_TRACED)) {
> +   if (!is_task_stopped_or_traced(task->state)) {
> DPRINT(("cannot attach to non-stopped task [%d] state=
> -   if ((task->state != TASK_STOPPED) && (task->state !=
> TASK_TRACED)) {
> +   if (!is_task_stopped_or_traced(task)) {
> DPRINT(("[%d] task not in stopped state\n",
> task->pid));
> return -EBUSY;
> } 

Does it take task->state or task ?

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: the Linux kernel, testsuites, and maybe *you*

[Mike Frysinger]

On 9/1/07, Bill Davidsen <[EMAIL PROTECTED]> wrote:
> If you want to test that stuff and run it on the current code in the
> kernel, how about a kernel module? You could "modprobe sanitytest" or
> something and report to syslog at module load time. And maybe have a
> parameter which does something drastic if something core is so hosed
> that filesystem damage is likely. Or just optional init code run by a
> kernel option, perhaps sanity testing after boot is not a great idea.

i'm fully capable of doing my own testing right now; that isnt the
point of this thread ... the point is for everyone to benefit, not
just the Blackfin architecture
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] Use macros instead of TASK_ flags

[Matthew Wilcox]

On Sat, Sep 01, 2007 at 10:46:51PM -0400, Matthew Wilcox wrote:
> Abstracting away direct uses of TASK_ flags allows us to change the
> definitions of the task flags more easily.
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -259,7 +259,7 @@ static int has_stopped_jobs(struct pid *pgrp)
>   struct task_struct *p;
>  
>   do_each_pid_task(pgrp, PIDTYPE_PGID, p) {
> - if (p->state != TASK_STOPPED)
> + if (is_task_stopped(p))

Funny how I can't spot these things before I send them.

Fixed locally; I'll see if anyone else spots a problem before I send out
a v3.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] Make wait_on_retry_sync_kiocb killable

[Matthew Wilcox]

Use TASK_KILLABLE to allow wait_on_retry_sync_kiocb to return -EINTR.
All callers then check the return value and break out of their loops.

Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
 fs/read_write.c |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/fs/read_write.c b/fs/read_write.c
index 507ddff..b1a52d5 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -218,14 +218,15 @@ Einval:
return -EINVAL;
 }
 
-static void wait_on_retry_sync_kiocb(struct kiocb *iocb)
+static int wait_on_retry_sync_kiocb(struct kiocb *iocb)
 {
-   set_current_state(TASK_UNINTERRUPTIBLE);
+   set_current_state(TASK_KILLABLE);
if (!kiocbIsKicked(iocb))
schedule();
else
kiocbClearKicked(iocb);
__set_current_state(TASK_RUNNING);
+   return fatal_signal_pending(current) ? -EINTR : 0;
 }
 
 ssize_t do_sync_read(struct file *filp, char __user *buf, size_t len, loff_t 
*ppos)
@@ -242,7 +243,9 @@ ssize_t do_sync_read(struct file *filp, char __user *buf, 
size_t len, loff_t *pp
ret = filp->f_op->aio_read(, , 1, kiocb.ki_pos);
if (ret != -EIOCBRETRY)
break;
-   wait_on_retry_sync_kiocb();
+   ret = wait_on_retry_sync_kiocb();
+   if (ret)
+   break;
}
 
if (-EIOCBQUEUED == ret)
@@ -300,7 +303,9 @@ ssize_t do_sync_write(struct file *filp, const char __user 
*buf, size_t len, lof
ret = filp->f_op->aio_write(, , 1, kiocb.ki_pos);
if (ret != -EIOCBRETRY)
break;
-   wait_on_retry_sync_kiocb();
+   ret = wait_on_retry_sync_kiocb();
+   if (ret)
+   break;
}
 
if (-EIOCBQUEUED == ret)
@@ -466,7 +471,9 @@ ssize_t do_sync_readv_writev(struct file *filp, const 
struct iovec *iov,
ret = fn(, iov, nr_segs, kiocb.ki_pos);
if (ret != -EIOCBRETRY)
break;
-   wait_on_retry_sync_kiocb();
+   ret = wait_on_retry_sync_kiocb();
+   if (ret)
+   break;
}
 
if (ret == -EIOCBQUEUED)
-- 
1.4.4.2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] Use macros instead of TASK_ flags

[Matthew Wilcox]

Abstracting away direct uses of TASK_ flags allows us to change the
definitions of the task flags more easily.

Also restructure do_wait() a little

Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
 arch/ia64/kernel/perfmon.c |4 +-
 fs/proc/array.c|9 +---
 fs/proc/base.c |2 +-
 include/linux/sched.h  |   15 +++
 include/linux/wait.h   |   11 +++--
 kernel/exit.c  |   90 +++
 kernel/power/process.c |7 +--
 kernel/ptrace.c|8 ++--
 kernel/sched.c |   15 +++
 kernel/signal.c|6 +-
 kernel/wait.c  |2 +-
 11 files changed, 83 insertions(+), 86 deletions(-)

diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 14b8e5a..75a99ee 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -2637,7 +2637,7 @@ pfm_task_incompatible(pfm_context_t *ctx, struct 
task_struct *task)
 */
if (task == current) return 0;
 
-   if ((task->state != TASK_STOPPED) && (task->state != TASK_TRACED)) {
+   if (!is_task_stopped_or_traced(task->state)) {
DPRINT(("cannot attach to non-stopped task [%d] state=%ld\n", 
task->pid, task->state));
return -EBUSY;
}
@@ -4797,7 +4797,7 @@ recheck:
 * the task must be stopped.
 */
if (PFM_CMD_STOPPED(cmd)) {
-   if ((task->state != TASK_STOPPED) && (task->state != 
TASK_TRACED)) {
+   if (!is_task_stopped_or_traced(task)) {
DPRINT(("[%d] task not in stopped state\n", task->pid));
return -EBUSY;
}
diff --git a/fs/proc/array.c b/fs/proc/array.c
index ee4814d..6a3c876 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -140,13 +140,8 @@ static const char *task_state_array[] = {
 
 static inline const char *get_task_state(struct task_struct *tsk)
 {
-   unsigned int state = (tsk->state & (TASK_RUNNING |
-   TASK_INTERRUPTIBLE |
-   TASK_UNINTERRUPTIBLE |
-   TASK_STOPPED |
-   TASK_TRACED)) |
-   (tsk->exit_state & (EXIT_ZOMBIE |
-   EXIT_DEAD));
+   unsigned int state = (tsk->state & TASK_REPORT) |
+   (tsk->exit_state & (EXIT_ZOMBIE | EXIT_DEAD));
const char **p = _state_array[0];
 
while (state) {
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 19489b0..3155ef1 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -196,7 +196,7 @@ static int proc_root_link(struct inode *inode, struct 
dentry **dentry, struct vf
(task == current || \
(task->parent == current && \
(task->ptrace & PT_PTRACED) && \
-(task->state == TASK_STOPPED || task->state == TASK_TRACED) && \
+(is_task_stopped_or_traced(task)) && \
 security_ptrace(current,task) == 0))
 
 static int proc_pid_environ(struct task_struct *task, char * buffer)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f4e324e..ea509e9 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -176,6 +176,21 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq 
*cfs_rq)
 #define TASK_NONINTERACTIVE64
 #define TASK_DEAD  128
 
+/* Convenience macros for the sake of wake_up */
+#define TASK_NORMAL(TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
+#define TASK_ALL   (TASK_NORMAL | TASK_STOPPED | TASK_TRACED)
+
+/* get_task_state() */
+#define TASK_REPORT(TASK_RUNNING | TASK_INTERRUPTIBLE | \
+TASK_UNINTERRUPTIBLE | TASK_STOPPED | \
+TASK_TRACED)
+
+#define is_task_traced(task)   ((task->state & TASK_TRACED) != 0)
+#define is_task_stopped(task)  ((task->state & TASK_STOPPED) != 0)
+#define is_task_stopped_or_traced(task)\
+   ((task->state & (TASK_STOPPED | TASK_TRACED)) != 0)
+#define is_task_loadavg(task)  ((task->state & TASK_UNINTERRUPTIBLE) != 0)
+
 #define __set_task_state(tsk, state_value) \
do { (tsk)->state = (state_value); } while (0)
 #define set_task_state(tsk, state_value)   \
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 0e68628..0a410a4 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -152,14 +152,15 @@ int FASTCALL(out_of_line_wait_on_bit(void *, int, int 
(*)(void *), unsigned));
 int FASTCALL(out_of_line_wait_on_bit_lock(void *, int, int (*)(void *), 
unsigned));
 wait_queue_head_t *FASTCALL(bit_waitqueue(void *, int));
 
-#define wake_up(x) __wake_up(x, TASK_UNINTERRUPTIBLE | 
TASK_INTERRUPTIBLE, 1, NULL)
-#define wake_up_nr(x, nr)  __wake_up(x, TASK_UNINTERRUPTIBLE | 
TASK_INTERRUPTIBLE, nr, NULL)

[PATCH 4/5] Add lock_page_killable

[Matthew Wilcox]

and associated infrastructure such as sync_page_killable and
fatal_signal_pending.  Use lock_page_killable in do_generic_mapping_read()
to allow us to kill `cat' of a file on an NFS-mounted filesystem.

Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
 include/linux/pagemap.h |   14 ++
 include/linux/sched.h   |9 -
 kernel/signal.c |5 +
 mm/filemap.c|   25 +
 4 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 8a83537..8b4f533 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -154,6 +154,7 @@ static inline pgoff_t linear_page_index(struct 
vm_area_struct *vma,
 }
 
 extern void FASTCALL(__lock_page(struct page *page));
+extern int FASTCALL(__lock_page_killable(struct page *page));
 extern void FASTCALL(__lock_page_nosync(struct page *page));
 extern void FASTCALL(unlock_page(struct page *page));
 
@@ -168,6 +169,19 @@ static inline void lock_page(struct page *page)
 }
 
 /*
+ * lock_page_killable is like lock_page but can be interrupted by fatal
+ * signals.  It returns 0 if it locked the page and -EINTR if it was
+ * killed while waiting.
+ */
+static inline int lock_page_killable(struct page *page)
+{
+   might_sleep();
+   if (TestSetPageLocked(page))
+   return __lock_page_killable(page);
+   return 0;
+}
+
+/*
  * lock_page_nosync should only be used if we can't pin the page's inode.
  * Doesn't play quite so well with block device plugging.
  */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6769179..e6f20da 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1769,7 +1769,14 @@ static inline int signal_pending(struct task_struct *p)
 {
return unlikely(test_tsk_thread_flag(p,TIF_SIGPENDING));
 }
-  
+
+extern int FASTCALL(__fatal_signal_pending(struct task_struct *p));
+
+static inline int fatal_signal_pending(struct task_struct *p)
+{
+   return signal_pending(p) && __fatal_signal_pending(p);
+}
+
 static inline int need_resched(void)
 {
return unlikely(test_thread_flag(TIF_NEED_RESCHED));
diff --git a/kernel/signal.c b/kernel/signal.c
index 986ba10..2b4fe29 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1003,6 +1003,11 @@ void zap_other_threads(struct task_struct *p)
}
 }
 
+int fastcall __fatal_signal_pending(struct task_struct *tsk)
+{
+   return sigismember(>pending.signal, SIGKILL);
+}
+
 /*
  * Must be called under rcu_read_lock() or with tasklist_lock read-held.
  */
diff --git a/mm/filemap.c b/mm/filemap.c
index 90b657b..235f092 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -170,6 +170,12 @@ static int sync_page(void *word)
return 0;
 }
 
+static int sync_page_killable(void *word)
+{
+   sync_page(word);
+   return fatal_signal_pending(current) ? -EINTR : 0;
+}
+
 /**
  * __filemap_fdatawrite_range - start writeback on mapping dirty pages in range
  * @mapping:   address space structure to write
@@ -574,6 +580,14 @@ void fastcall __lock_page(struct page *page)
 }
 EXPORT_SYMBOL(__lock_page);
 
+int fastcall __lock_page_killable(struct page *page)
+{
+   DEFINE_WAIT_BIT(wait, >flags, PG_locked);
+
+   return __wait_on_bit_lock(page_waitqueue(page), ,
+   sync_page_killable, TASK_KILLABLE);
+}
+
 /*
  * Variant of lock_page that does not require the caller to hold a reference
  * on the page's mapping.
@@ -975,7 +989,8 @@ page_ok:
 
 page_not_up_to_date:
/* Get exclusive access to the page ... */
-   lock_page(page);
+   if (lock_page_killable(page))
+   goto readpage_eio;
 
/* Did it get truncated before we got the lock? */
if (!page->mapping) {
@@ -1003,7 +1018,8 @@ readpage:
}
 
if (!PageUptodate(page)) {
-   lock_page(page);
+   if (lock_page_killable(page))
+   goto readpage_eio;
if (!PageUptodate(page)) {
if (page->mapping == NULL) {
/*
@@ -1014,15 +1030,16 @@ readpage:
goto find_page;
}
unlock_page(page);
-   error = -EIO;
shrink_readahead_size_eio(filp, );
-   goto readpage_error;
+   goto readpage_eio;
}
unlock_page(page);
}
 
goto page_ok;
 
+readpage_eio:
+   error = -EIO;
 readpage_error:
/* UHHUH! A synchronous read error occurred. Report it */
desc->error = error;
-- 
1.4.4.2

-
To unsubscribe from this list: send the line "unsubscribe 

[PATCH 3/5] Add TASK_WAKEKILL

[Matthew Wilcox]

Set TASK_WAKEKILL for TASK_STOPPED and TASK_TRACED, add TASK_KILLABLE and
use TASK_WAKEKILL in signal_wake_up()

Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
 include/linux/sched.h |   22 ++
 kernel/signal.c   |8 
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index ea509e9..6769179 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -167,28 +167,34 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq 
*cfs_rq)
 #define TASK_RUNNING   0
 #define TASK_INTERRUPTIBLE 1
 #define TASK_UNINTERRUPTIBLE   2
-#define TASK_STOPPED   4
-#define TASK_TRACED8
+#define __TASK_STOPPED 4
+#define __TASK_TRACED  8
 /* in tsk->exit_state */
 #define EXIT_ZOMBIE16
 #define EXIT_DEAD  32
 /* in tsk->state again */
 #define TASK_NONINTERACTIVE64
 #define TASK_DEAD  128
+#define TASK_WAKEKILL  256
+
+/* Convenience macros for the sake of set_task_state */
+#define TASK_KILLABLE  (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)
+#define TASK_STOPPED   (TASK_WAKEKILL | __TASK_STOPPED)
+#define TASK_TRACED(TASK_WAKEKILL | __TASK_TRACED)
 
 /* Convenience macros for the sake of wake_up */
 #define TASK_NORMAL(TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
-#define TASK_ALL   (TASK_NORMAL | TASK_STOPPED | TASK_TRACED)
+#define TASK_ALL   (TASK_NORMAL | __TASK_STOPPED | __TASK_TRACED)
 
 /* get_task_state() */
 #define TASK_REPORT(TASK_RUNNING | TASK_INTERRUPTIBLE | \
-TASK_UNINTERRUPTIBLE | TASK_STOPPED | \
-TASK_TRACED)
+TASK_UNINTERRUPTIBLE | __TASK_STOPPED | \
+__TASK_TRACED)
 
-#define is_task_traced(task)   ((task->state & TASK_TRACED) != 0)
-#define is_task_stopped(task)  ((task->state & TASK_STOPPED) != 0)
+#define is_task_traced(task)   ((task->state & __TASK_TRACED) != 0)
+#define is_task_stopped(task)  ((task->state & __TASK_STOPPED) != 0)
 #define is_task_stopped_or_traced(task)\
-   ((task->state & (TASK_STOPPED | TASK_TRACED)) != 0)
+   ((task->state & (__TASK_STOPPED | __TASK_TRACED)) != 0)
 #define is_task_loadavg(task)  ((task->state & TASK_UNINTERRUPTIBLE) != 0)
 
 #define __set_task_state(tsk, state_value) \
diff --git a/kernel/signal.c b/kernel/signal.c
index 53cbac4..986ba10 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -459,15 +459,15 @@ void signal_wake_up(struct task_struct *t, int resume)
set_tsk_thread_flag(t, TIF_SIGPENDING);
 
/*
-* For SIGKILL, we want to wake it up in the stopped/traced case.
-* We don't check t->state here because there is a race with it
+* For SIGKILL, we want to wake it up in the stopped/traced/killable
+* case. We don't check t->state here because there is a race with it
 * executing another processor and just now entering stopped state.
 * By using wake_up_state, we ensure the process will wake up and
 * handle its death signal.
 */
mask = TASK_INTERRUPTIBLE;
if (resume)
-   mask |= TASK_STOPPED | TASK_TRACED;
+   mask |= TASK_WAKEKILL;
if (!wake_up_state(t, mask))
kick_process(t);
 }
@@ -623,7 +623,7 @@ static void handle_stop_signal(int sig, struct task_struct 
*p)
 * Wake up the stopped thread _after_ setting
 * TIF_SIGPENDING
 */
-   state = TASK_STOPPED;
+   state = __TASK_STOPPED;
if (sig_user_defined(t, SIGCONT) && 
!sigismember(>blocked, SIGCONT)) {
set_tsk_thread_flag(t, TIF_SIGPENDING);
state |= TASK_INTERRUPTIBLE;
-- 
1.4.4.2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Jonathan Gray]

On Sat, Sep 01, 2007 at 08:36:24PM -0400, Jason Dixon wrote:
>
> On Sep 1, 2007, at 5:52 PM, Adrian Bunk wrote:
>
>> OK, I begin to understand this, there seem to be three different types
>> of files changed by Jiri's patch:
>> 1. dual licenced files planned to make GPL-only
>> 2. previously dual licenced files with a too recent version used planned
>>to make GPL-only
>> 3. never dual licenced files planned to make GPL-only
>>
>> For files under 1. and 2. Reyk did contribute to dual licenced code
>> without touching the licence, but I missed that there's also code unter 3.
>>
>> So there is a problem, but not with the code under 1. (unless you plan
>> to change the semantics of the word "alternatively"), the problem is
>> with some headers under 2. plus the code under 3.
>
> The BSD license plainly states:
>
> "Permission to use, copy, modify, and/or distribute this software for any
> purpose with or without fee is hereby granted, provided that the above
> copyright notice and this permission notice appear in all copies."
>
> Once the grantor (Reyk) releases his code under that license, it must 
> remain.  You are free to derive work and redistribute under your license, 
> but the original copyright and license permission remains intact.  Many 
> other entities (Microsoft, Apple, Sun, etc) have used BSD code and have no 
> problem understanding this.  Why is this so difficult for the Linux brain 
> share to absorb?
>
> As a former Linux advocate and current OpenBSD user/developer, I'm appalled 
> that fellow open-source developers would see fit to cavalierly disregard 
> the rights of the original copyright holder.  You wield the GPL when it 
> suits you, and trample the courtesies of non-GPL developers just because 
> you [think you] can.  As bad as Jiri's offense was, it pales to the 
> impudence displayed by Alan Cox, one of the so-called defenders of free 
> software.

>From http://www.mac.linux-m68k.org/docs/macpaper.php

"Always be the second operating system port to an undocumented platform.
The sterling work done by the OpenBSD/Mac team was a huge help to the
Linux project. I'm also happy to say that while half of the world may
sit on usenet advocacy groups throwing manure the relationship between
the Linux and BSD Macintosh teams has always been one of mutual
co-operation. Together we advance our detective work and knowledge of
the Macintosh platforms to the good of all Macintosh users dumped"

Alan Cox circa 1999.

http://lists.freedesktop.org/archives/xorg/2007-August/027419.html

"well I'd be quite happy to see X go GPL but I'm aware
thats not the intention of the project ;)"

Alan Cox circa 2007.

What changed? Why are you guys setting out to break all of the
work underpinning UNIX and the Internet done in the 80s at
Berkeley? The reason the protocols and infrastructure took
off in the first place is due to liberal licenses that let everyone
be involved, not wrapping things up in more restrictions and lawyers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] Use wake_up_locked() in eventpoll

[Matthew Wilcox]

Replace the uses of __wake_up_locked with wake_up_locked

Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
 fs/eventpoll.c |   11 ---
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 77b9953..72e4cb4 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -657,8 +657,7 @@ is_linked:
 * wait list.
 */
if (waitqueue_active(>wq))
-   __wake_up_locked(>wq, TASK_UNINTERRUPTIBLE |
-TASK_INTERRUPTIBLE);
+   wake_up_locked(>wq);
if (waitqueue_active(>poll_wait))
pwake++;
 
@@ -781,7 +780,7 @@ static int ep_insert(struct eventpoll *ep, struct 
epoll_event *event,
 
/* Notify waiting tasks that events are available */
if (waitqueue_active(>wq))
-   __wake_up_locked(>wq, TASK_UNINTERRUPTIBLE | 
TASK_INTERRUPTIBLE);
+   wake_up_locked(>wq);
if (waitqueue_active(>poll_wait))
pwake++;
}
@@ -855,8 +854,7 @@ static int ep_modify(struct eventpoll *ep, struct epitem 
*epi, struct epoll_even
 
/* Notify waiting tasks that events are available */
if (waitqueue_active(>wq))
-   __wake_up_locked(>wq, TASK_UNINTERRUPTIBLE |
-TASK_INTERRUPTIBLE);
+   wake_up_locked(>wq);
if (waitqueue_active(>poll_wait))
pwake++;
}
@@ -979,8 +977,7 @@ errxit:
 * wait list (delayed after we release the lock).
 */
if (waitqueue_active(>wq))
-   __wake_up_locked(>wq, TASK_UNINTERRUPTIBLE |
-TASK_INTERRUPTIBLE);
+   wake_up_locked(>wq);
if (waitqueue_active(>poll_wait))
pwake++;
}
-- 
1.4.4.2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] TASK_KILLABLE version 2

[Matthew Wilcox]

Here's the second version of TASK_KILLABLE.  A few changes since version 1:

 - Don't split up TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE.
   TASK_WAKESIGNAL and TASK_LOADAVG were pretty much equivalent, and since
   we had to keep __TASK_{UN,}INTERRUPTIBLE anyway, splitting them made
   little sense.
 - Instead, I've added some is_task_*() predicates.  I think they
   achieve what Linus wanted without consuming flag bits and without
   checking a metric tonne of code to see whether it wanted
   TASK_UNINTERRUPTIBLE or __TASK_UNINTERRUPTIBLE.
 - Renamed try_lock_page() to lock_page_killable() and change the sense.
   I had envisioned uses being like spin_trylock(), but that turned out
   not to make sense.
 - Fix the bug Trond noticed in wait_on_retry_sync_kiocb() by having the
   callers handle it returning -EINTR
 - Fix the bug I noticed in sync_pages_killable() by adding the new
   function fatal_signal_pending()
 - Audit a lot of uses of TASK_*.  A few seemed dubious and were fixed.

I'd like to see this spend a bit of time in the -mm tree.  I've wasted
a couple of days trying to track down why my machine no longer does
much after starting init, so clearly I'm tampering with stuff I don't
quite understand.

Having said that, I ditched that version of the code and started again
with a much more minimalist approach.  I've also split the patch into
five independent pieces, each of which accomplishes a logical step,
for ease of bisection.

I think patch 1/5 is clearly Right and should be merged ASAP.  Patch 2/5
and 3/5 carry some risk.  4/5 and 5/5 seem less risky to me (and are
independent of each other; both rely on 1-3 being applied first)

I obviously haven't covered every place that can result in a process
sleeping uninterruptibly while attempting an operation.  But sync_page
(patch 4/5) covers about 90% of the times I've attempted to kill cat,
and I hope that by providing the two examples, I can help other people
to fix the cases that they find interesting.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc4-mm1

[Satyam Sharma]

On Sun, 2 Sep 2007, Herbert Xu wrote:
> 
> On Sun, Sep 02, 2007 at 02:39:15AM +0530, Satyam Sharma wrote:
> > 
> > Tangential, but I've often wondered what are the upsides of keeping
> > CONFIG_CRYPTO_ALGAPI as a separate config option in the first place? Every
> > single item in crypto/ ends up "select"ing it (directly or transitively)
> > so it makes all sense to just do away with it and keep it == CONFIG_CRYPTO
> > in the Makefile, thusly:
> 
> NACK.  ALGAPI exists so that it can be built as a module, as
> opposed to CRYPTO which is always built-in.

I had already noticed that, and was even *expecting* you to reply with
*exactly* this ;-)

[ BTW CRYPTO is _not_ always built-in -- but only when CONFIG_CRYPTO=y ]

Anyway, the natural follow-up to your argument is -- why is the other
stuff in CRYPTO always built-in too ?

Take the crypto_alloc_xxx() callchain for example (I chose it because
it is the _first_ call any cryptoapi user ever has to make, and hence
it's the one that deals with module-loading stuff).

So what finally got exported out of crypto/ to the rest of the kernel
was just the crypto_alloc_xxx() wrapper. That resolves to a call to
crypto_alloc_base() in crypto/api.c, which first loads the specific
low-level algo modules, and then proceeds to crypto_init_ops(), which
itself may, say, resolve to a crypto_init_digest_ops() -- the only
interface exported from digest.c.

The point is, because the module-loading (if necessary) already takes
place before the call to digest.c is made, there is _no_ reason why
even digest.c can't be made modular -- or _any_ of the other CRYPTO
stuff (with the exception of api.c itself, of course) that "always
gets built-in" as you mentioned above.

And so caring about the optimization of making ALGAPI modular rather
than simply built-in with rest of "core" crypto stuff such as digest.c
(which could _also_ have been made modular by the same logic but wasn't)
sounds like a bogus argument to me. [ BTW did you notice that the
__crypto_alloc_tfm() has been EXPORT_SYMBOL'ed _only_ because of one
solitary modular-callsite in algapi.c ? ]


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Jason Dixon]

On Sep 1, 2007, at 9:58 PM, Casey Dahlin wrote:

Suppose you saw some other variant of *nix that had some code you  
wanted to use, but there was a gaping security hole in it. Wouldn't  
you patch it before you incorporated it? and would it be your fault  
if this fix made the code not work with the original?


We took the code and fixed a gaping security vulnerability that  
appeared within the opening comment. We DO care who does what with  
our code, and we fully intend to cover our balls.


Since when is this *your* code?  Oh that's right, when Jiri decided  
to steal it by deleting Reyk's copyright and license.  Oh wait,  
that's already been corrected.  What was your point again?


The problem is yours to fix. If you actually care, use a license  
that SAYS you care. Right now there's a big /* I don't give a shit  
*/ on top of every BSD file. We took you at your word and assumed  
you didn't. Now its too late and you suddenly care, don't you?


The BSD license, in effect, says that we care about good code.  We  
allow anyone to use it.  The only stipulation is that the copyright  
and license permissions must remain intact.


Are you trying to be hateful, or are you really this ignorant?

---
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: the Linux kernel, testsuites, and maybe *you*

[Bill Davidsen]

Mike Frysinger wrote:

is there any sort of standard for testing and integration into
mainline ?  in the Blackfin world, we've been developing little
external kernel modules and adding them to our own testsuite, but
often times these things are not Blackfin specific.  case in point,
we're integrating a string testsuite to make sure all of the fun str*
and mem* functions are sane and operate as they expected, but rather
than having just Blackfin benefit here, i'd like to see this pushed
upstream ...

i'm fully aware of LTP (as i work on it), but i feel that serves a
great purpose for exercising the API/ABI exposed to userspace either
directly through the kernel or indirectly through the system libc ...
it isnt a very good tool for testing kernel internals, especially as
the kernel changes and evolves.

is there a framework already in place i'm not aware of ?  should there
be ?  should this all live in LTP ?  i wouldnt mind an option under
kernel hacking "Enable testsuites" ... as far as i can tell, the
testing process is really based extensively on feedback from people,
nothing really automated.

If you want to test that stuff and run it on the current code in the 
kernel, how about a kernel module? You could "modprobe sanitytest" or 
something and report to syslog at module load time. And maybe have a 
parameter which does something drastic if something core is so hosed 
that filesystem damage is likely. Or just optional init code run by a 
kernel option, perhaps sanity testing after boot is not a great idea.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE/RFC] Really Fair Scheduler

[Bill Davidsen]

Roman Zippel wrote:

Hi,

On Fri, 31 Aug 2007, Ingo Molnar wrote:

Maybe I should explain for everyone else (especially after seeing some of 
the comments on kerneltrap), why I reacted somewhat irritated on what 
looks like such an innocent mail.
The problem is without the necessary background one can't know how wrong 
such statements as this are, the level of confidence is amazing though:



Peter's work fully solves the rounding corner-cases you described as:


I'd expect Ingo to know better, but the more he refuses to answer my 
questions, the more I doubt it, at least than it comes to the math part.


The "math part" is important if you're doing a thesis defense, but 
demonstrating better behavior under some realistic load would probably 
be a better starting point. Maybe Ingo missed something in your math, 
and maybe he just didn't find a benefit.


The ck and sd schedulers developed over a long time of public use and 
redefinition of goals. The cfs developed faster, but still had months of 
testing and the benefit of rt experience. Your scheduler is more of a 
virgin birth, no slow public discussion before, no time yet for people 
to run it under real loads, you're seeing first impressions.


You dropped this on the world two days before a major US holiday, at the 
end of the summer when those of us not on vacation may be covering for 
those who are, did you expect Ingo to drop his regular work to look at 
your stuff? And do you think there are many people who can look at your 
math, and look at your code, and then have any clue how well it works in 
practice? I bet there aren't ten people in the world who would even 
claim to do that, and half of them are kidding themselves.


So give people a few weeks to see if the rounding errors you eliminated 
mean anything in practice. Faster context is nice, but it's not 
something most people count as their major problem. I did a *lot* of cfs 
vs. sd testing, not just all the glitch1 tests I posted here, lots of 
stuff I just send to Ingo, and lots of tests like IPCbench and NNTP 
server loading showed nothing. (That's good, it means cfs isn't worse 
than the old scheduler for those loads.) I played with the tuning, I 
even diddled the code a bit, without finding meaningful improvement, so 
your possibly better math may not change the overall behavior much.


I will wait until I post actual test results before I say any more.

--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Al Viro]

On Sat, Sep 01, 2007 at 09:58:26PM -0400, Casey Dahlin wrote:
> Suppose you saw some other variant of *nix that had some code you wanted 
> to use, but there was a gaping security hole in it. Wouldn't you patch 
> it before you incorporated it? and would it be your fault if this fix 
> made the code not work with the original?
> 
> We took the code and fixed a gaping security vulnerability that appeared 
> within the opening comment. We DO care who does what with our code, and 
> we fully intend to cover our balls.

Who's "we" and would you mind showing your contributions to the tree?
git doesn't seem to find them in 2.5.0-to-current for some reason...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Jeff Garzik]

Constantine A. Murenin wrote:

Indeed, it's upsetting that people like Luis Rodriguez push for the
lawyers to be involved to (fight?) an open source project. Why, may I
ask?



Is it not self-evident?  Legal review is the sane course of action, when 
legal issues are the bone of contention.


That said, Linux people are far more pragmatic than FSF people, and 
often disagree with the FSF.  I would not take an FSF lawyer's word as 
Gospel.


Theo manages to confuse "Linux" and "FSF" quite often, but that's 
characteristic of his muddled thinking and inexperience.


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Casey Dahlin]

Suppose you saw some other variant of *nix that had some code you wanted 
to use, but there was a gaping security hole in it. Wouldn't you patch 
it before you incorporated it? and would it be your fault if this fix 
made the code not work with the original?


We took the code and fixed a gaping security vulnerability that appeared 
within the opening comment. We DO care who does what with our code, and 
we fully intend to cover our balls.


The problem is yours to fix. If you actually care, use a license that 
SAYS you care. Right now there's a big /* I don't give a shit */ on top 
of every BSD file. We took you at your word and assumed you didn't. Now 
its too late and you suddenly care, don't you?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Adrian Bunk]

On Sat, Sep 01, 2007 at 08:36:24PM -0400, Jason Dixon wrote:
> On Sep 1, 2007, at 5:52 PM, Adrian Bunk wrote:
>
>> OK, I begin to understand this, there seem to be three different types
>> of files changed by Jiri's patch:
>> 1. dual licenced files planned to make GPL-only
>> 2. previously dual licenced files with a too recent version used planned
>>to make GPL-only
>> 3. never dual licenced files planned to make GPL-only
>>
>> For files under 1. and 2. Reyk did contribute to dual licenced code
>> without touching the licence, but I missed that there's also code unter 3.
>>
>> So there is a problem, but not with the code under 1. (unless you plan
>> to change the semantics of the word "alternatively"), the problem is
>> with some headers under 2. plus the code under 3.
>
> The BSD license plainly states:
>
> "Permission to use, copy, modify, and/or distribute this software for any
> purpose with or without fee is hereby granted, provided that the above
> copyright notice and this permission notice appear in all copies."
>
> Once the grantor (Reyk) releases his code under that license, it must 
> remain.  You are free to derive work and redistribute under your license, 
> but the original copyright and license permission remains intact.  Many 
> other entities (Microsoft, Apple, Sun, etc) have used BSD code and have no 
> problem understanding this.  Why is this so difficult for the Linux brain 
> share to absorb?
>
> As a former Linux advocate and current OpenBSD user/developer, I'm appalled 
> that fellow open-source developers would see fit to cavalierly disregard 
> the rights of the original copyright holder.  You wield the GPL when it 
> suits you, and trample the courtesies of non-GPL developers just because 
> you [think you] can.  As bad as Jiri's offense was, it pales to the 
> impudence displayed by Alan Cox, one of the so-called defenders of free 
> software.
> 
> Shame on you all.

Jiri's patch would have wrongly not only removed the BSD statement from 
dual licenced files but also from not dual licenced files.

This was a mistake in this patch (that was never merged into the tree) 
neither Jiri nor Alan noticed.


The only disagreement is about the following:

Theo claimed boldly in the email that started this thread on 
linux-kernel it would "break the law" to choose one licence for dual 
licenced code like the following:


/*  $OpenBSD: ath.c,v 1.63 2007/05/09 16:41:14 reyk Exp $  */
/*  $NetBSD: ath.c,v 1.37 2004/08/18 21:59:39 dyoung Exp $*/

/*-
 * Copyright (c) 2002-2004 Sam Leffler, Errno Consulting
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer,
 *without modification.
 * 2. Redistributions in binary form must reproduce at minimum a disclaimer
 *similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
 *redistribution must be conditioned upon including a substantially
 *similar Disclaimer requirement for further binary redistribution.
 * 3. Neither the names of the above-listed copyright holders nor the names
 *of any contributors may be used to endorse or promote products derived
 *from this software without specific prior written permission.
 *
 * Alternatively, this software may be distributed under the terms of the
 * GNU General Public License ("GPL") version 2 as published by the Free
 * Software Foundation.
 *
 * NO WARRANTY
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
 * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
 * THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
 * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
 * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
 * THE POSSIBILITY OF SUCH DAMAGES.
 */


> Jason Dixon

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Al Viro]

On Sat, Sep 01, 2007 at 09:42:54PM -0400, Luis R. Rodriguez wrote:
 
> We asked SFLC to work with us to make sure that everyone's copyrights
> were respected in the right places, and that the licenses various developers
> wanted for their copyrights were implemented correctly.  The patch I sent
> implements SFLC's suggestions in that regard.

You know, I'm rapidly losing any respect to both sides of that.  Eben
Moglen as source of advice in "is it OK to convert to GPL-only"?  And
you seriously rely on morality of that?  Theo's rants aside, if you
have to rely on SFLC for licensing decisions...  Ouch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Theo de Raadt <[EMAIL PROTECTED]> wrote:
> When companies have taken our wireless device drivers, many many of
> them have given changes and fixes back.  Some maybe didn't, but that
> is OK.
>
> When Linux took our changes back, they immediately locked the door
> against changes moving back, by putting a GPL license on guard.
>
> Why does our brother Linux take a file that is 90% BSD licensed,
> and refuse to let us see the 10% he adds?

Indeed, it's upsetting that people like Luis Rodriguez push for the
lawyers to be involved to (fight?) an open source project. Why, may I
ask?

Why Luis puts the phrase "legal hell" next to entirely free software?
[0] Why is he trying to go against the BSD community, which gave him
the entire HAL framework for the driver in question?

Best regards,
Constantine.

[0] http://marc.info/?l=linux-wireless=118857712529898=2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc4-mm1

[Herbert Xu]

On Sun, Sep 02, 2007 at 02:39:15AM +0530, Satyam Sharma wrote:
> 
> Tangential, but I've often wondered what are the upsides of keeping
> CONFIG_CRYPTO_ALGAPI as a separate config option in the first place? Every
> single item in crypto/ ends up "select"ing it (directly or transitively)
> so it makes all sense to just do away with it and keep it == CONFIG_CRYPTO
> in the Makefile, thusly:

NACK.  ALGAPI exists so that it can be built as a module, as
opposed to CRYPTO which is always built-in.  It's already
invisible to the user so I don't see why you have a problem
with it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Jeff Garzik]

Constantine A. Murenin wrote:

On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:

Jason Dixon wrote:

Once the grantor (Reyk) releases his code under that license, it must
remain.  You are free to derive work and redistribute under your
license, but the original copyright and license permission remains
intact.  Many other entities (Microsoft, Apple, Sun, etc) have used BSD
code and have no problem understanding this.  Why is this so difficult
for the Linux brain share to absorb?

Why is it so difficult to understand dual licensing?


Maybe because Reyk's code was never dual-licensed?


And yet a good portion of Theo's response, in particular his accusations 
of Alan Cox exhorting people to break the law, were directly related to 
dual licensing.


Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Luis R. Rodriguez]

On 9/1/07, Constantine A. Murenin <[EMAIL PROTECTED]> wrote:
> On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > Jason Dixon wrote:
> > > Once the grantor (Reyk) releases his code under that license, it must
> > > remain.  You are free to derive work and redistribute under your
> > > license, but the original copyright and license permission remains
> > > intact.  Many other entities (Microsoft, Apple, Sun, etc) have used BSD
> > > code and have no problem understanding this.  Why is this so difficult
> > > for the Linux brain share to absorb?
> >
> > Why is it so difficult to understand dual licensing?
>
> Maybe because Reyk's code was never dual-licensed?

We asked SFLC to work with us to make sure that everyone's copyrights
were respected in the right places, and that the licenses various developers
wanted for their copyrights were implemented correctly.  The patch I sent
implements SFLC's suggestions in that regard.

  Luis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Jason Dixon wrote:
> > Once the grantor (Reyk) releases his code under that license, it must
> > remain.  You are free to derive work and redistribute under your
> > license, but the original copyright and license permission remains
> > intact.  Many other entities (Microsoft, Apple, Sun, etc) have used BSD
> > code and have no problem understanding this.  Why is this so difficult
> > for the Linux brain share to absorb?
>
> Why is it so difficult to understand dual licensing?

Maybe because Reyk's code was never dual-licensed?

C.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: That whole "Linux stealing our code" thing

[Jeff Garzik]

Jason Dixon wrote:
Once the grantor (Reyk) releases his code under that license, it must 
remain.  You are free to derive work and redistribute under your 
license, but the original copyright and license permission remains 
intact.  Many other entities (Microsoft, Apple, Sun, etc) have used BSD 
code and have no problem understanding this.  Why is this so difficult 
for the Linux brain share to absorb?


Why is it so difficult to understand dual licensing?

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Adrian Bunk]

On Sat, Sep 01, 2007 at 06:02:26PM -0600, Bob Beck wrote:
> >As a free software user and developer, the question I have is how come
> >the Linux community feels that they can take the BSD code that was
> >reverse-engineered at OpenBSD, and put a more restrictive licence onto
> >it, such that there will be no possibility of the changes going back
> >to OpenBSD, given that the main work on the code has happened at
> >OpenBSD? (Obviously, such a scenario it is permitted by the licence,
> >but my question is an ethical one -- after all, most components of
> >OpenHAL were specifically based on the OpenBSD's ath(4) HAL code.)
> >
> >You can see that Christoph Hellwig agrees with this ethical problem,
> >as in the message below.
> >
> >C.
> >
> >
> >>On 28/08/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >> On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
> >> > ath5k, license is GPLv2
> >> >
> >> > The files are available only under GPLv2 since now.
> >>
> >> Is this really a good idea?  Most of the reverse-engineering was
> >> done by the OpenBSD folks, and it would certainly be helpful to
> >> work together with them on new hardware revisions, etc..
> 
> I couldn't agree more. The point is, while we BSD license fans know and
> expect people from private industry to take our stuff and use it, at
> least private industry does not come to the table with "hey, let's
> cooperate" - we know who the corporate whores are, and we act accordingly. 
> 
> However, when a linux developer comes to us and say "hey lets cooperate"
> usually there is a thought of "this is a kindred spirit who understands
> what our mutual goals are and won't stab us in the back".  My concern
> is that this situation will change if this is not rectified. 
> 
> I think the community needs to decide, should cooperation be based on
> morals and trust, or does the Linux community need to be regarded with
> less trust than a Corporation, something to be avoided, as while
> corporations can be counted on to act without morals, the knife is up
> front and visible. They do not come to you with one hand of
> cooperation extended and a knife kept behind their back.

Theo explicitely accused Alan that telling people that it was OK to 
choose one licence for dual licenced code was "advising people to break 
the law".

I hope you agree when talking about "cooperation [...] based on morals 
and trust" that such accusations should either be proven correct or the 
moral position of the person who made such accusations becomes quiet 
weak.

>  -Bob 

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Adrian Bunk]

On Sat, Sep 01, 2007 at 06:36:36PM -0600, Theo de Raadt wrote:
> When companies have taken our wireless device drivers, many many of
> them have given changes and fixes back.  Some maybe didn't, but that
> is OK.
> 
> When Linux took our changes back, they immediately locked the door
> against changes moving back, by putting a GPL license on guard.
> 
> Why does our brother Linux take a file that is 90% BSD licensed,
> and refuse to let us see the 10% he adds?

Theo, the primary claim you made in your email that was forwarded to 
linux-kernel was:

<--  snip  -->

In http://lkml.org/lkml/2007/8/29/183, Alan Cox managed to summarize
what Jiri Slaby and Luis Rodriguez were trying to do by proposing a
modification of a Dual Licenced file without the consent of all the
authors.  Alan asks "So whats the problem ?".  Well, Alan, I must
caution you -- your post is advising people to break the law.

<--  snip  -->

It is a quite heavy accusation against Alan that saying it was OK to 
change dual licenced code to one of the offered licences would advise
to break the law.

There's nothing about goodwill or other ethical questions in your 
statement, this statement you made can be verified or falsified by 
lawyers.

If it is true, all ethical questions about this are anyway moot because 
it was illegal as you claim.

If you wrongly accused Alan, you owe Alan an apology.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -mm] net/sched/sch_cbq.c: Shut up uninitialized variable warning

[Satyam Sharma]

net/sched/sch_cbq.c: In function 'cbq_enqueue':
net/sched/sch_cbq.c:383: warning: 'ret' may be used uninitialized in this 
function

has been verified to be a bogus case. So let's shut it up.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>

---

 net/sched/sch_cbq.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.23-rc4-mm1/net/sched/sch_cbq.c~fix2007-09-02 
06:45:08.0 +0530
+++ linux-2.6.23-rc4-mm1/net/sched/sch_cbq.c2007-09-02 06:44:37.0 
+0530
@@ -380,7 +380,7 @@ cbq_enqueue(struct sk_buff *skb, struct 
 {
struct cbq_sched_data *q = qdisc_priv(sch);
int len = skb->len;
-   int ret;
+   int uninitialized_var(ret);
struct cbq_class *cl = cbq_classify(skb, sch, );
 
 #ifdef CONFIG_NET_CLS_ACT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PATCH - Pktgen srcmac fix - Kernel 2.6.22.6

[Adit Ranadive]

diff -urNp linux-orig/net/core/pktgen.c linux-mod/net/core/pktgen.c
--- linux-orig/net/core/pktgen.c2007-08-31 02:21:01.0 -0400
+++ linux-mod/net/core/pktgen.c 2007-09-01 20:51:22.0 -0400
@@ -111,6 +111,9 @@
  *
  * 802.1Q/Q-in-Q support by Francesco Fondelli (FF)
<[EMAIL PROTECTED]>
  *
+ * Fixed src_mac command to set source mac of packet to value specified in
+ * command by Adit Ranadive <[EMAIL PROTECTED]>
+ *
  */
 #include 
 #include 
@@ -1415,7 +1418,9 @@ static ssize_t pktgen_if_write(struct fi
}
if (!strcmp(name, "src_mac")) {
char *v = valstr;
+   unsigned char old_smac[ETH_ALEN];
unsigned char *m = pkt_dev->src_mac;
+   memcpy(old_smac, pkt_dev->src_mac, ETH_ALEN);

len = strn_len(_buffer[i], sizeof(valstr) - 1);
if (len < 0) {
@@ -1445,6 +1450,10 @@ static ssize_t pktgen_if_write(struct fi
}
}

+   /* Set up Src MAC */
+   if (compare_ether_addr(old_smac, pkt_dev->src_mac))
+   memcpy(&(pkt_dev->hh[6]), pkt_dev->src_mac, ETH_ALEN);
+
sprintf(pg_result, "OK: srcmac");
return count;
}


-- 
Adit Ranadive
MS CS Candidate
Georgia Institute of Technology,
Atlanta, GA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: r.kernel.org

[Jeff Garzik]

Bob Beck wrote:



I urge developers to not bait into this and just leave this alone.
Those involved know what they are doing and have a strong team of
attorneys watching their backs. Any *necessary* discussions are be
done privately.

 Luis


What? when we talk about the ethics of cooperating development
and sharing code the response is "we have lawyers watching your backs"
and "we know what we are doing and have a plan"

What is this? a concerted attack by some organization on
the BSD projects? Would that be the FSF? or freesoftware.org?  


What kind of crap is this? that Free Software developers can't
respect each others project goals and work together, but instead should
beware of organizations with hidden agendas to abscond with their work. 


What a crock. I urge any developers involved to decide if
you really want to work in an environment of this sort of amoral baloney.


Your BSD software appears to have a bug in it.  Your email's CC line was 
truncated at "[EMAIL PROTECTED]", with the rest spilling into your email's 
subject line.


I'll wager this bug also triggered a buffer overflow on your side, 
leading to an unwanted public spew of anti-Linux conspiracy theories.


But don't worry, we find them entertaining nonetheless.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] good job guys with the anti-spam !

[Oleg Verych]

On Sun, Sep 02, 2007 at 02:39:36AM +0200, Bj?rn Steinbrink wrote:
[]
> 
> Ehrm, you want everyone who wants to start a new thread to:
> 
>  - send an email
>  - await response from the mail server
>  - send the same email again as a reply to the first one

No. Send a ticket request and then organize patch bomb with gotten ticket
in `references:' or `in-reply-to'. New discussion thread: be organized
have a pull of tickets, care about what you post, how you post, etc.

Those new posters will get current footer with more info -- no problem.

People in thread need no work at all. Linus, Andrew, Jeff, DaveM etc.
are likely to be in white list with no additional work also.

It's anti-spam thing, but maybe it can be kind of netiquette, which is
forgotten in modern XML Internet world. I didn't live in that time, but
that's my impression. In case if efficient algo/logic will be implemented
it will save CPU power, because all processing is done in header part of
the message and it's a token lookup. Switch on your imagination and
think, what can be done in another way, why not? 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [EMAIL PROTECTED]: I respect the GPL immensely,really I do - but I believe this type of action weakens us all.]

[David Schwartz]

> You miss the whole point of dual licencing:
> 
> Sam has stated in the licence that the code can be distributed under the 
> terms of the BSD licence, or alternatively it can be distributed under 
> the terms of the GPLv2.
> 
> Noone removed Sam's licence.
> 
> Sam has offered a choice, and if you choose one of the two offered 
> licences when distributing his code that complies with what he stated
> in his copyright notice.
> 
> IANAL, but if reyk contributed to dual licenced code keeping the file 
> dual licenced it's hard to argue that he did not make the changes he 
> made available dual licenced.

I think that there needs to be some general understanding about what the policy 
has to be when dual-licensed or BSD-licensed code is incorporated into the 
Linux kernel. Unfortunately, I don't think it's practical keep dual-licensed or 
BSD-licensed code in the Linux kernel because it prevents GPLv2 code from being 
incorporated into that file.

For example, if I make a file 'foo.c' available under a dual license, and it 
winds up in the Linux kernel, what happens? Suppose someone decides my locking 
is not optimal, and they cut/paste a few lines of code from another file, GPLv2 
only, into 'foo.c'. Did they just put someone's GPLv2 code under a dual 
license? Of course not.

I think the policy should be:

1) If BSD-only code is incorporated into the Linux kernel, the BSD license must 
not be removed, as this is prohibited by the BSD license. However, a note 
should be included that only the original work is offered under the BSD license 
and that the license does not apply to the new elements that may have been 
added to that file. The file, as it presently sits, is likely only offered 
under the GPLv2.

2) If dual-licensed code is added to the Linux kernel, one of two things has to 
happen.

 A) If the code is relatively self-contained, it should stay dual-licensed. A 
warning should be placed in the file (with a pointer to a more detailed 
explanation) that GPLv2-only code cannot be spliced into this file without 
removing the dual-license.

 B) If the code is not relatively self-contained, or can no longer stay as A 
above due to the desire to splice in code from other modules are add GPLv2-only 
code, the GPL license should be removed.

I honestly wish that it would be possible to offer more code back to the 
BSD-licensed versions. If you know who I am, you know I'm a strong critic of 
the GPL license and much prefer the BSD license. However, I think Linux as a 
project suffers if it includes files available under different licenses. It's 
much harder to work with the code, modify it, and contribute to it.

Almost any consistent license is better than different files being under 
different licenses such that you are burdened with compliance issues when you 
try to move improvements from one file into another.

Imagine if every file system were under a different license and someon adds a 
new file system hook that every filesystem benefits from implementing. Suppose 
the original author submits an implementation for ext2 and it's under GPLv2. 
Think about the burdens if you then tried to implement that hook for three 
other filesystems, each with their own license, and you can't cut/paste the 
ext2 hook in.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE/RFC] Really Fair Scheduler

[Daniel Walker]

On Fri, 2007-08-31 at 04:05 +0200, Roman Zippel wrote:
> Hi,
> 
> I'm glad to announce a working prototype of the basic algorithm I
> already suggested last time.
> As I already tried to explain previously CFS has a considerable
> algorithmic and computational complexity. This patch should now make it
> clearer, why I could so easily skip over Ingo's long explanation of all
> the tricks CFS uses to keep the computational overhead low - I simply
> don't need them. The following numbers are based on a 2.6.23-rc3-git1 UP
> kernel, the first 3 runs are without patch, the last 3 runs are with the
> patch:

Out of curiosity I was reviewing your patch .. Since you create
kernel/sched_norm.c as a copy of kernel/sched_fair.c it was hard to see
what had changed .. So I re-diffed your patch to eliminate
kernel/sched_norm.c and just make the changes to kernel/sched_fair.c .. 

The the patch is near the end of this email..  The most notable thing
about the rediff is the line count,

 4 files changed, 323 insertions(+), 729 deletions(-)

That's impressive (assuming my rediff is correct). Although I don't know
for certain how that line reduction is achieved..

I also ran hackbench (in a haphazard way) a few times on it vs. CFS in
my tree, and RFS was faster to some degree (it varied).. 

> (1)   time = sum_{t}^{T}(time_{t})
> (2)   weight_sum = sum_{t}^{T}(weight_{t})

I read your description, but I was distracted by this latex style
notation .. Could you walk through in english what these two equation
are doing ..

The patch below is on top of my tree (2.6.23-rc5-dw1) ,
ftp://source.mvista.com/pub/dwalker/rt/

Daniel

---
 include/linux/sched.h |   21 -
 kernel/sched.c|  186 ---
 kernel/sched_debug.c  |   26 -
 kernel/sched_fair.c   |  819 +-
 4 files changed, 323 insertions(+), 729 deletions(-)

Index: linux-2.6.22/include/linux/sched.h
===
--- linux-2.6.22.orig/include/linux/sched.h
+++ linux-2.6.22/include/linux/sched.h
@@ -1046,40 +1046,29 @@ struct load_weight {
  *
  * Current field usage histogram:
  *
- * 4 se->block_start
  * 4 se->run_node
- * 4 se->sleep_start
- * 4 se->sleep_start_fair
  * 6 se->load.weight
- * 7 se->delta_fair
- *15 se->wait_runtime
  */
 struct sched_entity {
-   longwait_runtime;
-   unsigned long   delta_fair_run;
-   unsigned long   delta_fair_sleep;
-   unsigned long   delta_exec;
-   s64 fair_key;
+   s64 time_key;
struct load_weight  load;   /* for load-balancing */
struct rb_node  run_node;
-   unsigned inton_rq;
+   unsigned inton_rq, queued;;
+   unsigned intweight_shift;
 
u64 exec_start;
u64 sum_exec_runtime;
u64 prev_sum_exec_runtime;
-   u64 wait_start_fair;
-   u64 sleep_start_fair;
+   s64 time_norm;
+   s64 req_weight_inv;
 
 #ifdef CONFIG_SCHEDSTATS
-   u64 wait_start;
u64 wait_max;
s64 sum_wait_runtime;
 
-   u64 sleep_start;
u64 sleep_max;
s64 sum_sleep_runtime;
 
-   u64 block_start;
u64 block_max;
u64 exec_max;
 
Index: linux-2.6.22/kernel/sched.c
===
--- linux-2.6.22.orig/kernel/sched.c
+++ linux-2.6.22/kernel/sched.c
@@ -230,18 +230,24 @@ struct cfs_rq {
 
s64 fair_clock;
u64 exec_clock;
-   s64 wait_runtime;
u64 sleeper_bonus;
unsigned long wait_runtime_overruns, wait_runtime_underruns;
 
+   u64 prev_update;
+   s64 time_norm_base, time_norm_inc;
+   u64 run_start, run_end;
+   u64 run_end_next, run_end_curr;
+   s64 time_sum_max, time_sum_off;
+   unsigned long inc_shift, weight_sum;
+
struct rb_root tasks_timeline;
-   struct rb_node *rb_leftmost;
struct rb_node *rb_load_balance_curr;
-#ifdef CONFIG_FAIR_GROUP_SCHED
/* 'curr' points to currently running entity on this cfs_rq.
 * It is set to NULL otherwise (i.e when none are currently running).
 */
-   struct sched_entity *curr;
+   struct sched_entity *curr, *next;
+   struct sched_entity *rb_leftmost;
+#ifdef CONFIG_FAIR_GROUP_SCHED
struct rq *rq;  /* cpu runqueue to which this cfs_rq is attached */
 
/* leaf cfs_rqs are those that hold tasks (lowest schedulable entity in
@@ -278,12 +284,16 @@ struct rq {
 */
unsigned long nr_running;

Re: That whole "Linux stealing our code" thing

[Jason Dixon]

On Sep 1, 2007, at 5:52 PM, Adrian Bunk wrote:


OK, I begin to understand this, there seem to be three different types
of files changed by Jiri's patch:
1. dual licenced files planned to make GPL-only
2. previously dual licenced files with a too recent version used  
planned

   to make GPL-only
3. never dual licenced files planned to make GPL-only

For files under 1. and 2. Reyk did contribute to dual licenced code
without touching the licence, but I missed that there's also code  
unter 3.


So there is a problem, but not with the code under 1. (unless you plan
to change the semantics of the word "alternatively"), the problem is
with some headers under 2. plus the code under 3.


The BSD license plainly states:

"Permission to use, copy, modify, and/or distribute this software for  
any

purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies."

Once the grantor (Reyk) releases his code under that license, it must  
remain.  You are free to derive work and redistribute under your  
license, but the original copyright and license permission remains  
intact.  Many other entities (Microsoft, Apple, Sun, etc) have used  
BSD code and have no problem understanding this.  Why is this so  
difficult for the Linux brain share to absorb?


As a former Linux advocate and current OpenBSD user/developer, I'm  
appalled that fellow open-source developers would see fit to  
cavalierly disregard the rights of the original copyright holder.   
You wield the GPL when it suits you, and trample the courtesies of  
non-GPL developers just because you [think you] can.  As bad as  
Jiri's offense was, it pales to the impudence displayed by Alan Cox,  
one of the so-called defenders of free software.


Shame on you all.

---
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: recent nfs change causes autofs regression

[Bill Davidsen]

Trond Myklebust wrote:

On Thu, 2007-08-30 at 20:49 -0700, Linus Torvalds wrote:
Please send in a fix. If the fix involves making "nosharecache" the 
default, then that is better than making policy decisions like this in the 
kernel. The kernel should do what the user asks and not put in unnecessary 
roadblocks.


The best I can do given the constraints appears to be to have the kernel
first look for a superblock that matches both the fsid and the
user-specified mount options, and then spawn off a new superblock if
that search fails. The attached patch does just that.

I'm glad I read the whole thread, because when I saw it earlier and 
didn't respond, this was the question I had, why not replace the error 
with forcing "nosharecache" on, which is essentially what you have done.



Note that this is not the same as specifying nosharecache everywhere
since nosharecache will never attempt to match an existing superblock.

Finally, for the record: I still feel very uncomfortable about not being
able to report the state of the client setup back to the sysadmin.
AFAIK, the only way to do so is to stat the mountpoints, and compare the
device ids.

Since clients may not know the server setup, and it may change for 
policy or error recovery reason, I think this patch is needed.


The cases I think are common are:

1 - single export, multiple client mounts

export /base - rw

mount /base/share - ro  [ client enforces r/o or not ]
mount /base/upload - rw

2 - export parts of a filesystem (/base) [ server enforces access ]

export /base/share - ro [ hopefully really r/o on client ]
export /base/upload - rw[ should work for write ]

3 - mount the same f/s with different permissions on client

export /base - rw

mount /base on point1 - rw  [ hopefully really r/w ]
mount /base on point2 - ro  [ hopefully r/o ]

I consider this *really* bad practice, but I have seen it in enough 
places to know others don't agree. It assumes the client will protect 
the r/o data.


4 - export f/s and part of f/s

export /base/ - ro
export /base/upload - rw

clients may mount one or both, with the upload directory as part of base 
or elsewhere. What will happen here?



Trond



--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] netlink: use the macro min(x,y) provided by instead

[rae l]

On 9/2/07, David Newall <[EMAIL PROTECTED]> wrote:
> Denis Cheng wrote
> > + order = get_bitmask_order(min(max, (unsigned long)UINT_MAX)) - 1;
> >
>
> Why doesn't this clash with the max define, also in linux/kernel.h?
They indeed don't clash,
the cpp included by gcc is intelligent enough, it know the
function-style definition of max in kernel.h, that's different from
the auto variable max here, so they don't clash with each other,

But I think the variable name "max" here is ambiguous, I changed it to
"limit", see my following patch [PATCH 2/3].

-- 
Denis Cheng
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 01, 2007 at 07:29:39PM -0400, Constantine A. Murenin wrote:
> > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > On Sat, Sep 01, 2007 at 05:27:03PM -0400, Constantine A. Murenin wrote:
> > > > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > > > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin 
> > > > > wrote:
> > > > > > On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > > > > > > Constantine A. Murenin wrote:
> > > > > > > > This will hopefully help diminish certain myths about the code 
> > > > > > > > licensing.
> > > > > > >
> > > > > > > What myth?  The myth that Theo understands dual licensing?
> > > > > >
> > > > > > Reyk's code was never dual licensed, so it's not like it even 
> > > > > > matters
> > > > > > to the original dispute.
> > > > >
> > > > > It's no longer dual licenced in the FreeBSD tree because the FreeBSD
> > > > > people removed the GPL choice of the dual licenced code 3 months ago.
> > > >
> > > > FreeBSD doesn't have Reyk's ath(4) HAL, which OpenHAL is based on.
> > > >
> > > > FreeBSD has a driver written by Sam, and a binary-only HAL, also 
> > > > written by Sam.
> > > >
> > > > > So all of Theo's accusations of people breaking the law by making this
> > > > > dual licenced code GPL-only apply as well to the FreeBSD people...
> > > >
> > > > How? FreeBSD doesn't have Reyk's ath(4) HAL from OpenBSD, so there are
> > > > no possible licensing accusations and violations.
> > >
> > > OK, I begin to understand this, there seem to be three different types
> > > of files changed by Jiri's patch:
> > > 1. dual licenced files planned to make GPL-only
> > > 2. previously dual licenced files with a too recent version used planned
> > >to make GPL-only
> > > 3. never dual licenced files planned to make GPL-only
> > >
> > > For files under 1. and 2. Reyk did contribute to dual licenced code
> > > without touching the licence, but I missed that there's also code unter 3.
> > >
> > > So there is a problem, but not with the code under 1. (unless you plan
> > > to change the semantics of the word "alternatively"), the problem is
> > > with some headers under 2. plus the code under 3.
> > >
> > > It's funny how Theo missed the part of Jiri's patch that actually is a
> > > copyright violation and instead complains about the part that is OK...
> >
> > I'm not sure how you conclude that Theo missed the relevant parts --
> > there were many messages posted to [EMAIL PROTECTED] mailing list and
> > to The OpenBSD Journal in the last few days, and to me it appears as
> > all of the problems were discussed ad nauseam.
> >...
>
> Then it's your fault that you forwarded the wrong email - in the email
> you forwarded the only action for which Theo accused the Linux
> developers of breaking the law was for choosing one licence when using
> dual licenced code.

For the sake of the discussion, at the time I forwarded the message,
the obvious licensing problems (e.g. the original infamous patch by
Jiri) were already addressed.

Personally, these problems were so obvious -- entirely changing the
licence under Reyk's Copyright notice -- that I didn't even take them
for real when they first came across.

BTW, I've now once again re-read the original message that I've
forwarded, and it does contain Theo's reiteration of his response that
the original re-licensing patch had clear violations. E.g. re-read
this part of his message:

- If you receive ISC or BSD licensed code, you may not delete the
 license.  Same principle, since the notice says so.  It's the law.
 Really.

> > After the obvious copyright violations were addressed, I think the
> > problem started being an ethical one.
> >
> > As a free software user and developer, the question I have is how come
> > the Linux community feels that they can take the BSD code that was
> > reverse-engineered at OpenBSD, and put a more restrictive licence onto
> > it, such that there will be no possibility of the changes going back
> > to OpenBSD, given that the main work on the code has happened at
> > OpenBSD? (Obviously, such a scenario it is permitted by the licence,
> > but my question is an ethical one -- after all, most components of
> > OpenHAL were specifically based on the OpenBSD's ath(4) HAL code.)
> >
> > You can see that Christoph Hellwig agrees with this ethical problem,
> > as in the message below.
>
> Is it a legal problem or is it "only" an ethical problem?

I don't particularly like to repeat myself -- after the obvious
licensing issues were addressed, it has indeed become an ethical
problem: why do you think that you as the Linux community has to act
ruder to the *BSD community than the supposed corporations that we
always hear about in the BSD/GPL licensing arguments?

I really like the response that Bob Beck gave on this question:
http://lkml.org/lkml/2007/9/1/197

> If choosing one licence when using dual licenced code is not a legal
> 

Re: [PATCH -mm] drivers/acpi/tables/tbutils.c: Shut up bogus uninitialized variable warning

[Satyam Sharma]

On Sun, 2 Sep 2007, Adrian Bunk wrote:
> 
> On Sun, Sep 02, 2007 at 05:12:14AM +0530, Satyam Sharma wrote:
> > 
> > drivers/acpi/tables/tbutils.c: In function 'acpi_tb_parse_root_table':
> > drivers/acpi/tables/tbutils.c:403:
> > warning: 'rsdt_address' may be used uninitialized in this function
> > 
> > has been verified to be a bogus warning. Let's just initialize the
> > variable to zero and shut this up.
> >...
> 
> Please use uninitialized_var() instead.

On Sun, 2 Sep 2007, Satyam Sharma wrote:
> [...]
> I didn't use uninitialized_var() here because drivers/acpi/ is dual-licensed
> stuff and used elsewhere, where that macro may be unavailable (?)


Len, would it be okay to use uninitialized_var() in drivers/acpi/ code?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] seekwatcher v0.3 IO graphing an animation

[Oleg Verych]

* Fri, 27 Jul 2007 21:20:57 -0400
>
[]
> Here's a sample of the smoother graphs (creating 20 kernel trees):
>
> http://oss.oracle.com/~mason/seekwatcher/ext3_vs_btrfs_vs_xfs.png

It seems, that making log for XFS on different physical device can
boost performance. Will it be reliable, is a question, isn't it?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Theo de Raadt]

When companies have taken our wireless device drivers, many many of
them have given changes and fixes back.  Some maybe didn't, but that
is OK.

When Linux took our changes back, they immediately locked the door
against changes moving back, by putting a GPL license on guard.

Why does our brother Linux take a file that is 90% BSD licensed,
and refuse to let us see the 10% he adds?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc4-mm1 OOPS in forcedeth?

[Satyam Sharma]

Hi Jurriaan,


> [EMAIL PROTECTED] wrote:
> > From: Andrew Morton <[EMAIL PROTECTED]>
> > Date: Fri, Aug 31, 2007 at 09:58:22PM -0700
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
> > > 
> > On this machine (Athlon 64 X2 4600, 4 GiB memory, lots of disks),
> > 2.6.23-rc1-mm2 runs fine. 2.6.23-rc4-mm1 reproducably dies within seconds of
> > starting
> > a rsync session on another PC against this machine.
> > 
> > NULL pointer dereference
> > code:   nv_napi_poll+0x108
> > trace:  net_rx_action+0xab
> > __do_softirq+0x74
> > call_softirq+0x1c
> > do_softirq+0x3d
> > irq_exit+0x85
> > do_IRQ+0x85
> > ret_from_intr+0x0

The dmesg you posted below doesn't cover the messages from this oops
itself. As you mentioned you can reproduce this oops easily, please do so,
and post the *full* oops log (if it doesn't get logged to disk, you can
try taking digicam photo, or write down *all* the messages and post here).
I built an x86_64 kernel as per your .config, but don't see any memory
dereference at nv_napi_poll+0x108 -- could be toolchain differences.

Else, can you run:
$ gdb ./vmlinux

and then:
(gdb) l *nv_napi_poll+0x108

and send us the output?


Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] good job guys with the anti-spam !

[Björn Steinbrink]

On 2007.09.02 02:36:18 +0200, Oleg Verych wrote:
> * Tue, 31 Jul 2007 23:40:11 +0200
> >
> []
> > eventhough people often write only when they have something to complain
> > about, I for once would like to congratulate Matti and David, our mail
> > admins, for the wonderful job they've done with the spams lately. This
> > month, I might have seen maybe one or two instead of perhaps 30 per day
> > earlier. While it did not bother me that much earlier, I can say that
> > the list is more pleasant to read every day, and I think that's great.
> >
> > Kudos guys !
> >
> > Willy
> >
> > PS: please do not start another one of those long useless threads from now 
> > on
> >
> 
> Instead let me share an idea and see what will happen (if any).
> The mailing list policy:
> 
> 1. sent mails must have in-reply-to (rfc2821 SHOULD) with valid, i.e.
>existing in archives, message-id;
> 
> 2. otherwise sender gets response about creating new thread. Replying
>to that message will enable (1).

Ehrm, you want everyone who wants to start a new thread to:

 - send an email
 - await response from the mail server
 - send the same email again as a reply to the first one

Did I get that right? If so, good luck running from anyone who doesn't
send his patch series as a bunch of replies to a 00/XX message.

Although it would likely be fun to see the next guy that sends a 600
emails patch bomb getting buried alive in "Please confirm that you want
to create a new thread" emails.

Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] good job guys with the anti-spam !

[Oleg Verych]

* Tue, 31 Jul 2007 23:40:11 +0200
>
[]
> eventhough people often write only when they have something to complain
> about, I for once would like to congratulate Matti and David, our mail
> admins, for the wonderful job they've done with the spams lately. This
> month, I might have seen maybe one or two instead of perhaps 30 per day
> earlier. While it did not bother me that much earlier, I can say that
> the list is more pleasant to read every day, and I think that's great.
>
> Kudos guys !
>
> Willy
>
> PS: please do not start another one of those long useless threads from now on
>

Instead let me share an idea and see what will happen (if any).
The mailing list policy:

1. sent mails must have in-reply-to (rfc2821 SHOULD) with valid, i.e.
   existing in archives, message-id;

2. otherwise sender gets response about creating new thread. Replying
   to that message will enable (1).

I don't know how performance of ever increasing anti-spam
rules/software grow vs message-id lookup will be affected.

Gmane shows good performance on load, which is times bigger than LKML's.
News server requires unique ids, so...

Ah, if spammers will become smart and will reply with appropriate headers
set up, everything will fall apart.

Finally. What i see:
* no spam,
* big patch-bombs in one thread (easy to skip)
* more order, if useless/obsolete footers removed, but such info is
  sent in (2).

* easy blacklisting if rules are not obeyed since day X

  Oh, no, don't say we value bug reports. Reports must be organized in
  other way, one of which i've described as development tracking system.
  Such e-mail policy is unavoidable part of this it. E-mail is everything
  it requires. Of course some html, css, javascript, perl guys will be
  free to implement any web-face they like. But story if git-web have
  something to learn instead.
--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -mm] drivers/acpi/tables/tbutils.c: Shut up bogus uninitialized variable warning

[Adrian Bunk]

On Sun, Sep 02, 2007 at 05:12:14AM +0530, Satyam Sharma wrote:
> 
> drivers/acpi/tables/tbutils.c: In function 'acpi_tb_parse_root_table':
> drivers/acpi/tables/tbutils.c:403:
> warning: 'rsdt_address' may be used uninitialized in this function
> 
> has been verified to be a bogus warning. Let's just initialize the
> variable to zero and shut this up.
>...

Please use uninitialized_var() instead.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

r.kernel.org

[Bob Beck]

>I urge developers to not bait into this and just leave this alone.
>Those involved know what they are doing and have a strong team of
>attorneys watching their backs. Any *necessary* discussions are be
>done privately.
>
>  Luis

What? when we talk about the ethics of cooperating development
and sharing code the response is "we have lawyers watching your backs"
and "we know what we are doing and have a plan"

What is this? a concerted attack by some organization on
the BSD projects? Would that be the FSF? or freesoftware.org?  

What kind of crap is this? that Free Software developers can't
respect each others project goals and work together, but instead should
beware of organizations with hidden agendas to abscond with their work. 

What a crock. I urge any developers involved to decide if
you really want to work in an environment of this sort of amoral baloney.

I think you all should decide if you want to work in an environment
where developers can cooperate on a handshake and respect each others
differnet goals, or whether discoveries in each camp need to be hidden
from each other and fought over by lawyers.  You're all being talked
to by a bunch of zealots who put zealotry above morals.

-Bob




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Luis R. Rodriguez <[EMAIL PROTECTED]> wrote:
> I urge developers to not bait into this and just leave this alone.
> Those involved know what they are doing and have a strong team of
> attorneys watching their backs. Any *necessary* discussions are be
> done privately.

Err...

I don't understand why you need a lawyer to interpret this document:

/* $OpenBSD: ar5210.c,v 1.39 2007/04/10 17:47:55 miod Exp $*/

/*
 * Copyright (c) 2004, 2005, 2006, 2007 Reyk Floeter <[EMAIL PROTECTED]>
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

If you want to add more code to it, and your contribution is
significant, simply add you name next to Reyk's. Where's the problem?

I don't know how licensing could be any simpler than this. Please,
notice, that there are no additional documents (other than the
copyright law) to read here -- _this is the complete licence_! (And
you have to read the copyright law even if you use the GNU GPL.)

C.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Oops in 2.6.23-rc5

[Christian Kujau]

Hi,

today I switched from 2.6.22.3 to 2.6.23-rc5 (skipped quite a few -rc 
versions due to lack of time), and the box keeps panicking under certain 
circumstances. I suspected disk related problems, because: when the box 
is up, I usually resume ~10 bittorrent files. When doing this, each

file (~200MB...1GB) is checked and disk activity is pretty high (20MB/s
or so), and after 1 minute of doing so the box panicks. Every time.

However, I could not reproduce it while generating disk-io with say tar 
or rsync to the same fs. It always panicked when the torrent client(s) 
start up. As the box would not log anything via remote-syslog before 
halting, I connected a vga display. As I don't have a digital camera, I 
tried to write down some stuff: http://ww.nerdbynature.de/bits/2.6.23-rc5/
(I'll try to write down the full oops to this place, or what was still 
visible from it, because the first few(?) lines where lost, display 
scrollback was not working, only sysrq was).


The backtrace mentions do_page_fault, error_code, tcp_rtt_estimator, 
tcp_ack_saw_timestamp, tcp_ack, tcp_rcv_established, tcp_v4_do_rcv, 
tcp_v4_rcv, ip_local_delimiter, netif_receive_skb, process_backlog, 
net_rcv_activate, __do_softirq, do_softirq - in that order. As said, the 
correct addresses will be put on above's url (Q: do I really need *all* 
the numbers? Or just a few?). These snippets made me suspect network 
related issues, because: aside from disk-io, the bittorrent clients will 
establish quite a few (~50 in total) connections to all the peers.


The box is a amd-k7, 2 NICs (forcedeth, 3c59x), 2 GB RAM, ACPI 
disabled, gcc-4.1


Thanks for looking into this,
Christian.
--
BOFH excuse #335:

the AA battery in the wallclock sends magnetic interference
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Adrian Bunk]

On Sat, Sep 01, 2007 at 07:29:39PM -0400, Constantine A. Murenin wrote:
> On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Sat, Sep 01, 2007 at 05:27:03PM -0400, Constantine A. Murenin wrote:
> > > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote:
> > > > > On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > > > > > Constantine A. Murenin wrote:
> > > > > > > This will hopefully help diminish certain myths about the code 
> > > > > > > licensing.
> > > > > >
> > > > > > What myth?  The myth that Theo understands dual licensing?
> > > > >
> > > > > Reyk's code was never dual licensed, so it's not like it even matters
> > > > > to the original dispute.
> > > >
> > > > It's no longer dual licenced in the FreeBSD tree because the FreeBSD
> > > > people removed the GPL choice of the dual licenced code 3 months ago.
> > >
> > > FreeBSD doesn't have Reyk's ath(4) HAL, which OpenHAL is based on.
> > >
> > > FreeBSD has a driver written by Sam, and a binary-only HAL, also written 
> > > by Sam.
> > >
> > > > So all of Theo's accusations of people breaking the law by making this
> > > > dual licenced code GPL-only apply as well to the FreeBSD people...
> > >
> > > How? FreeBSD doesn't have Reyk's ath(4) HAL from OpenBSD, so there are
> > > no possible licensing accusations and violations.
> >
> > OK, I begin to understand this, there seem to be three different types
> > of files changed by Jiri's patch:
> > 1. dual licenced files planned to make GPL-only
> > 2. previously dual licenced files with a too recent version used planned
> >to make GPL-only
> > 3. never dual licenced files planned to make GPL-only
> >
> > For files under 1. and 2. Reyk did contribute to dual licenced code
> > without touching the licence, but I missed that there's also code unter 3.
> >
> > So there is a problem, but not with the code under 1. (unless you plan
> > to change the semantics of the word "alternatively"), the problem is
> > with some headers under 2. plus the code under 3.
> >
> > It's funny how Theo missed the part of Jiri's patch that actually is a
> > copyright violation and instead complains about the part that is OK...
> 
> I'm not sure how you conclude that Theo missed the relevant parts --
> there were many messages posted to [EMAIL PROTECTED] mailing list and
> to The OpenBSD Journal in the last few days, and to me it appears as
> all of the problems were discussed ad nauseam.
>...

Then it's your fault that you forwarded the wrong email - in the email 
you forwarded the only action for which Theo accused the Linux 
developers of breaking the law was for choosing one licence when using 
dual licenced code.

> After the obvious copyright violations were addressed, I think the
> problem started being an ethical one.
> 
> As a free software user and developer, the question I have is how come
> the Linux community feels that they can take the BSD code that was
> reverse-engineered at OpenBSD, and put a more restrictive licence onto
> it, such that there will be no possibility of the changes going back
> to OpenBSD, given that the main work on the code has happened at
> OpenBSD? (Obviously, such a scenario it is permitted by the licence,
> but my question is an ethical one -- after all, most components of
> OpenHAL were specifically based on the OpenBSD's ath(4) HAL code.)
> 
> You can see that Christoph Hellwig agrees with this ethical problem,
> as in the message below.

Is it a legal problem or is it "only" an ethical problem?

If choosing one licence when using dual licenced code is not a legal 
problem then Theo repeatedly talking about it would "break the law" in 
the email you forwarded was very unethical and the worst he could do
for his cause.

> C.
>...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Bob Beck]

>As a free software user and developer, the question I have is how come
>the Linux community feels that they can take the BSD code that was
>reverse-engineered at OpenBSD, and put a more restrictive licence onto
>it, such that there will be no possibility of the changes going back
>to OpenBSD, given that the main work on the code has happened at
>OpenBSD? (Obviously, such a scenario it is permitted by the licence,
>but my question is an ethical one -- after all, most components of
>OpenHAL were specifically based on the OpenBSD's ath(4) HAL code.)
>
>You can see that Christoph Hellwig agrees with this ethical problem,
>as in the message below.
>
>C.
>
>
>>On 28/08/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>> On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
>> > ath5k, license is GPLv2
>> >
>> > The files are available only under GPLv2 since now.
>>
>> Is this really a good idea?  Most of the reverse-engineering was
>> done by the OpenBSD folks, and it would certainly be helpful to
>> work together with them on new hardware revisions, etc..

I couldn't agree more. The point is, while we BSD license fans know and
expect people from private industry to take our stuff and use it, at
least private industry does not come to the table with "hey, let's
cooperate" - we know who the corporate whores are, and we act accordingly. 

However, when a linux developer comes to us and say "hey lets cooperate"
usually there is a thought of "this is a kindred spirit who understands
what our mutual goals are and won't stab us in the back".  My concern
is that this situation will change if this is not rectified. 

I think the community needs to decide, should cooperation be based on
morals and trust, or does the Linux community need to be regarded with
less trust than a Corporation, something to be avoided, as while
corporations can be counted on to act without morals, the knife is up
front and visible. They do not come to you with one hand of
cooperation extended and a knife kept behind their back.

 -Bob 






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [EMAIL PROTECTED]: I respect the GPL immensely, really I do - but I believe this type of action weakens us all.]

[Adrian Bunk]

On Sat, Sep 01, 2007 at 04:41:12PM -0600, Bob Beck wrote:
> - Forwarded message from Bob Beck <[EMAIL PROTECTED]> -
> 
> From: Bob Beck <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: I respect the GPL immensely, really I do - but I believe this type 
> of action weakens us all.
> X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on 
> bofh.cns.ualberta.ca
> X-Spam-Level: 
> X-Spam-Status: No, score=-2.8 required=3.0 tests=AWL,BAYES_00,
>   DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.8
> Date: Sat, 1 Sep 2007 16:22:43 -0600
> User-Agent: Mutt/1.5.12-2006-07-14
> 
>  [ A copy of this is going to the linux kernel mailing list, regarding the
> recent license modifications to reyk's files]
> 
> >Oh, and if you look at the OpenBSD CVS you see versions 4 months old 
> >with dozens of contributions by Reyk and with:
> >
> >/*  $OpenBSD: ath.c,v 1.63 2007/05/09 16:41:14 reyk Exp $  */
> >/*  $NetBSD: ath.c,v 1.37 2004/08/18 21:59:39 dyoung Exp $*/
> >/*-
> > * Copyright (c) 2002-2004 Sam Leffler, Errno Consulting
> > * All rights reserved.
> 
>Of course you do! because some of reyk's work used some of Sam's
> work, and unlike what it seems a portion of the Linux community seems
> to be willing to do in their Zealotry for the GPL, reyk is not
> *removing and modifying* the licenses granted by the original authors.
> That's the point. He's not saying he wrote this piece, and he's not
> *changing* the conditions under which Sam distributed the code in the
> first place. However what scares me more is the seeming willingness to
> make the authors of a derivative work appear to be the primary authors
> of something, and a willingness to change an authors copyright
> statement (on reyk's code) without his permission. 
>...

You miss the whole point of dual licencing:

Sam has stated in the licence that the code can be distributed under the 
terms of the BSD licence, or alternatively it can be distributed under 
the terms of the GPLv2.

Noone removed Sam's licence.

Sam has offered a choice, and if you choose one of the two offered 
licences when distributing his code that complies with what he stated
in his copyright notice.

IANAL, but if reyk contributed to dual licenced code keeping the file 
dual licenced it's hard to argue that he did not make the changes he 
made available dual licenced.

>I seriously hope that saner more mature and forward thinking heads
> inside the Linux community will stop bashing the things that Theo and
> the rest of our community is saying just because it's coming from
> Theo, and he's a great target to bash, and start thinking about what
> you are doing to free software as a whole. I think you are on the
> verge of doing irreparable damage that will seriously weaken the
> ability for all of our projects to move forward, and protect our
> rights as code authors in the future.

The funny thing is that it seems Jiri's patch contained copyright 
violations - and the parts of his patch Theo attacks are the parts
that are OK...

>   -Bob

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Luis R. Rodriguez]

I urge developers to not bait into this and just leave this alone.
Those involved know what they are doing and have a strong team of
attorneys watching their backs. Any *necessary* discussions are be
done privately.

  Luis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

kconfig/kbuild rewite (Re: What's up with CONFIG_BLK_DEV?)

[Oleg Verych]

* Sun, 26 Aug 2007 01:08:28 -0500
* Organization: Boundaries Unlimited
>
[]
> Also "here's a symbol, show me a menu containing everything else that is 
> either required by or enabled by this symbol..."  That sounds like a more 
> powerful abstraction, since the previous one is "show me everything that 
> depends on CONFIG_BLOCK".
>
> (I wonder if this would be a largeish rewrite of the menuconfig 
> infrastructure?  Hmmm...)

Yess. I'm doing this, actually. Sam, Andrew and Linus have got an email
half a year ago about my intent. Tried to release 2.6.20-j4f, but that
was just a dream. Now i did some training in non-kernel related stuff and
always catch (30k, 14k) LKML backlogs to stay in tune. Some bits i 
get are here ftp://flower.upol.cz/Linux/info-LKML/tools/

So, ideas: UI, organization, efficiency, simplicity, etc. are welcome.

Maybe in one month i'll get something to show (base is 2.6.22).
Imagination plays very well, the thing must be ground shaking, but i'll
see how it will fit reality. Yours one in consideration from very
beginning, don't bother :)

Another problem that i have to solve before any publishing (it's
completely another tree, logic, interface), is the work tracking system,
i was describing in June. This is important, because i sick of current
chaos and manual organizing work in-tree or in regression tracking.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: read-only /sys/block/sda/device/queue_depth

[Robert Hancock]

Yan Seiner wrote:

I'm running into the same issue reported here:



I am using the ata_piix module.  If I read the docs correctly, I should 
be able to use ahci as well; I need to rebuild the kernel though (debian 
insists on putting ata_piix into the initrd)


dionysus:~# ls -l /sys/block/sd[abcde]/device/queue_depth
-r--r--r-- 1 root root 4096 2007-09-01 06:00 
/sys/block/sda/device/queue_depth
-r--r--r-- 1 root root 4096 2007-09-01 06:00 
/sys/block/sdb/device/queue_depth
-r--r--r-- 1 root root 4096 2007-09-01 06:00 
/sys/block/sdc/device/queue_depth
-r--r--r-- 1 root root 4096 2007-09-01 06:00 
/sys/block/sdd/device/queue_depth
-r--r--r-- 1 root root 4096 2007-09-01 06:00 
/sys/block/sde/device/queue_depth


If I change the perms to rw, I get an Input/Output error.  AFAICT, the 
drives support queueing, but it's disabled.


ata_piix does not support NCQ. You have to use AHCI mode for that.

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 01, 2007 at 05:27:03PM -0400, Constantine A. Murenin wrote:
> > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote:
> > > > On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > > > > Constantine A. Murenin wrote:
> > > > > > This will hopefully help diminish certain myths about the code 
> > > > > > licensing.
> > > > >
> > > > > What myth?  The myth that Theo understands dual licensing?
> > > >
> > > > Reyk's code was never dual licensed, so it's not like it even matters
> > > > to the original dispute.
> > >
> > > It's no longer dual licenced in the FreeBSD tree because the FreeBSD
> > > people removed the GPL choice of the dual licenced code 3 months ago.
> >
> > FreeBSD doesn't have Reyk's ath(4) HAL, which OpenHAL is based on.
> >
> > FreeBSD has a driver written by Sam, and a binary-only HAL, also written by 
> > Sam.
> >
> > > So all of Theo's accusations of people breaking the law by making this
> > > dual licenced code GPL-only apply as well to the FreeBSD people...
> >
> > How? FreeBSD doesn't have Reyk's ath(4) HAL from OpenBSD, so there are
> > no possible licensing accusations and violations.
>
> OK, I begin to understand this, there seem to be three different types
> of files changed by Jiri's patch:
> 1. dual licenced files planned to make GPL-only
> 2. previously dual licenced files with a too recent version used planned
>to make GPL-only
> 3. never dual licenced files planned to make GPL-only
>
> For files under 1. and 2. Reyk did contribute to dual licenced code
> without touching the licence, but I missed that there's also code unter 3.
>
> So there is a problem, but not with the code under 1. (unless you plan
> to change the semantics of the word "alternatively"), the problem is
> with some headers under 2. plus the code under 3.
>
> It's funny how Theo missed the part of Jiri's patch that actually is a
> copyright violation and instead complains about the part that is OK...

I'm not sure how you conclude that Theo missed the relevant parts --
there were many messages posted to [EMAIL PROTECTED] mailing list and
to The OpenBSD Journal in the last few days, and to me it appears as
all of the problems were discussed ad nauseam.

After the obvious copyright violations were addressed, I think the
problem started being an ethical one.

As a free software user and developer, the question I have is how come
the Linux community feels that they can take the BSD code that was
reverse-engineered at OpenBSD, and put a more restrictive licence onto
it, such that there will be no possibility of the changes going back
to OpenBSD, given that the main work on the code has happened at
OpenBSD? (Obviously, such a scenario it is permitted by the licence,
but my question is an ethical one -- after all, most components of
OpenHAL were specifically based on the OpenBSD's ath(4) HAL code.)

You can see that Christoph Hellwig agrees with this ethical problem,
as in the message below.

C.


On 28/08/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
> > ath5k, license is GPLv2
> >
> > The files are available only under GPLv2 since now.
>
> Is this really a good idea?  Most of the reverse-engineering was
> done by the OpenBSD folks, and it would certainly be helpful to
> work together with them on new hardware revisions, etc..

( from http://lkml.org/lkml/2007/8/28/178 )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -mm] drivers/acpi/tables/tbutils.c: Shut up bogus uninitialized variable warning

[Satyam Sharma]

drivers/acpi/tables/tbutils.c: In function 'acpi_tb_parse_root_table':
drivers/acpi/tables/tbutils.c:403:
warning: 'rsdt_address' may be used uninitialized in this function

has been verified to be a bogus warning. Let's just initialize the
variable to zero and shut this up.

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>

---

I didn't use uninitialized_var() here because drivers/acpi/ is dual-licensed
stuff and used elsewhere, where that macro may be unavailable (?)

 drivers/acpi/tables/tbutils.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.23-rc4-mm1/drivers/acpi/tables/tbutils.c~fix  2007-09-02 
05:07:02.0 +0530
+++ linux-2.6.23-rc4-mm1/drivers/acpi/tables/tbutils.c  2007-09-02 
05:07:14.0 +0530
@@ -400,7 +400,7 @@ acpi_tb_parse_root_table(acpi_physical_a
u32 table_count;
struct acpi_table_header *table;
acpi_physical_address address;
-   acpi_physical_address rsdt_address;
+   acpi_physical_address rsdt_address = 0;
u32 length;
u8 *table_entry;
acpi_status status;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC + PATCH] signalfd simplification

[Davide Libenzi]

While I was in vacation, I noticed that more "tsk == current" check were 
added to the signal logic because of the way signalfd fetches other task 
signals.
I'm playing at the moment with this patch, that recall Ben's idea  of 
attaching to the sighand only during read/poll, and calling dequeue_signal()
only with "current". This simplifies the signalfd logic quite a bit.
If this patch is applied, a task calling signalfd can read its own private 
signals, and its own group signals.
Comments?



- Davide



---
 fs/exec.c |3 
 fs/signalfd.c |  186 +++---
 include/linux/init_task.h |2 
 include/linux/sched.h |2 
 include/linux/signalfd.h  |   29 ---
 kernel/exit.c |9 --
 kernel/fork.c |2 
 kernel/signal.c   |8 -
 8 files changed, 40 insertions(+), 201 deletions(-)

Index: linux-2.6.mod/fs/signalfd.c
===
--- linux-2.6.mod.orig/fs/signalfd.c2007-09-01 10:37:39.0 -0700
+++ linux-2.6.mod/fs/signalfd.c 2007-09-01 12:33:37.0 -0700
@@ -11,8 +11,10 @@
  *  Now using anonymous inode source.
  *  Thanks to Oleg Nesterov for useful code review and suggestions.
  *  More comments and suggestions from Arnd Bergmann.
- * Sat May 19, 2007: Davi E. M. Arnaut <[EMAIL PROTECTED]>
+ *  Sat May 19, 2007: Davi E. M. Arnaut <[EMAIL PROTECTED]>
  *  Retrieve multiple signals with one read() call
+ *  Sun Jul 15, 2007: Davide Libenzi <[EMAIL PROTECTED]>
+ *  Attach to the sighand only during read().
  */
 
 #include 
@@ -27,102 +29,20 @@
 #include 
 
 struct signalfd_ctx {
-   struct list_head lnk;
-   wait_queue_head_t wqh;
sigset_t sigmask;
-   struct task_struct *tsk;
 };
 
-struct signalfd_lockctx {
-   struct task_struct *tsk;
-   unsigned long flags;
-};
-
-/*
- * Tries to acquire the sighand lock. We do not increment the sighand
- * use count, and we do not even pin the task struct, so we need to
- * do it inside an RCU read lock, and we must be prepared for the
- * ctx->tsk going to NULL (in signalfd_deliver()), and for the sighand
- * being detached. We return 0 if the sighand has been detached, or
- * 1 if we were able to pin the sighand lock.
- */
-static int signalfd_lock(struct signalfd_ctx *ctx, struct signalfd_lockctx *lk)
-{
-   struct sighand_struct *sighand = NULL;
-
-   rcu_read_lock();
-   lk->tsk = rcu_dereference(ctx->tsk);
-   if (likely(lk->tsk != NULL))
-   sighand = lock_task_sighand(lk->tsk, >flags);
-   rcu_read_unlock();
-
-   if (!sighand)
-   return 0;
-
-   if (!ctx->tsk) {
-   unlock_task_sighand(lk->tsk, >flags);
-   return 0;
-   }
-
-   if (lk->tsk->tgid == current->tgid)
-   lk->tsk = current;
-
-   return 1;
-}
-
-static void signalfd_unlock(struct signalfd_lockctx *lk)
-{
-   unlock_task_sighand(lk->tsk, >flags);
-}
-
 /*
- * This must be called with the sighand lock held.
+ * This must be called with the "tsk" sighand lock held.
  */
 void signalfd_deliver(struct task_struct *tsk, int sig)
 {
-   struct sighand_struct *sighand = tsk->sighand;
-   struct signalfd_ctx *ctx, *tmp;
-
-   BUG_ON(!sig);
-   list_for_each_entry_safe(ctx, tmp, >signalfd_list, lnk) {
-   /*
-* We use a negative signal value as a way to broadcast that the
-* sighand has been orphaned, so that we can notify all the
-* listeners about this. Remember the ctx->sigmask is inverted,
-* so if the user is interested in a signal, that corresponding
-* bit will be zero.
-*/
-   if (sig < 0) {
-   if (ctx->tsk == tsk) {
-   ctx->tsk = NULL;
-   list_del_init(>lnk);
-   wake_up(>wqh);
-   }
-   } else {
-   if (!sigismember(>sigmask, sig))
-   wake_up(>wqh);
-   }
-   }
-}
-
-static void signalfd_cleanup(struct signalfd_ctx *ctx)
-{
-   struct signalfd_lockctx lk;
-
-   /*
-* This is tricky. If the sighand is gone, we do not need to remove
-* context from the list, the list itself won't be there anymore.
-*/
-   if (signalfd_lock(ctx, )) {
-   list_del(>lnk);
-   signalfd_unlock();
-   }
-   kfree(ctx);
+   wake_up(>sighand->signalfd_wqh);
 }
 
 static int signalfd_release(struct inode *inode, struct file *file)
 {
-   signalfd_cleanup(file->private_data);
+   kfree(file->private_data);
return 0;
 }
 
@@ -130,23 +50,15 @@
 {
struct signalfd_ctx *ctx = file->private_data;
unsigned int events = 0;
-   struct signalfd_lockctx lk;
 
- 

Re: 2.6.23-rc4-mm1 "no CRC" MODPOST warnings

[Sam Ravnborg]

On Sun, Sep 02, 2007 at 03:36:08AM +0530, Satyam Sharma wrote:
> 
> 
> On Fri, 31 Aug 2007, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
> 
> Got these on an i386 build with CONFIG_MODVERSIONS=y ...
> 
> WARNING: "div64_64" [net/netfilter/xt_connbytes.ko] has no CRC!
> WARNING: "div64_64" [net/ipv4/tcp_cubic.ko] has no CRC!

As Adrian already commented it is fixed in kbuild.git.
It happes bacause genksyms did not know __extension__ and error recovery
in the parser were bad. I only managed to add support for __extension__ but
the error receovery are not fixed :-(

kbuild.git is not part of this -mm due to me fucking up the above fix.
That is corrected now so it will be in next -mm.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[EMAIL PROTECTED]: I respect the GPL immensely, really I do - but I believe this type of action weakens us all.]

[Bob Beck]

- Forwarded message from Bob Beck <[EMAIL PROTECTED]> -

From: Bob Beck <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: I respect the GPL immensely, really I do - but I believe this type of 
action weakens us all.
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on bofh.cns.ualberta.ca
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 required=3.0 tests=AWL,BAYES_00,
DNS_FROM_RFC_ABUSE,FORGED_RCVD_HELO autolearn=no version=3.1.8
Date: Sat, 1 Sep 2007 16:22:43 -0600
User-Agent: Mutt/1.5.12-2006-07-14

 [ A copy of this is going to the linux kernel mailing list, regarding the
recent license modifications to reyk's files]

>Oh, and if you look at the OpenBSD CVS you see versions 4 months old 
>with dozens of contributions by Reyk and with:
>
>/*  $OpenBSD: ath.c,v 1.63 2007/05/09 16:41:14 reyk Exp $  */
>/*  $NetBSD: ath.c,v 1.37 2004/08/18 21:59:39 dyoung Exp $*/
>/*-
> * Copyright (c) 2002-2004 Sam Leffler, Errno Consulting
> * All rights reserved.

   Of course you do! because some of reyk's work used some of Sam's
work, and unlike what it seems a portion of the Linux community seems
to be willing to do in their Zealotry for the GPL, reyk is not
*removing and modifying* the licenses granted by the original authors.
That's the point. He's not saying he wrote this piece, and he's not
*changing* the conditions under which Sam distributed the code in the
first place. However what scares me more is the seeming willingness to
make the authors of a derivative work appear to be the primary authors
of something, and a willingness to change an authors copyright
statement (on reyk's code) without his permission. 

   I have always immensely respected the GPL - it has very noble
goals, they are very appropriate in some cases, they don't happen to
be mine, but that's fine, I don't release my code under it - but
that's fine, it's my choice.  Just like many smart people who I know
and respect do their work in GPL land, and this is great too. However,
when it comes time to be looking at someone else's work above all we
have to respect the various authors choice of how they want their hard
work shared with the community. 

  To me, this seems like a portion of the Linux community seems to be
wanting to make their own rules, chosing to rewrite a license at any
time they choose without the original author's agreement. This appalls
and scares me. Why? not only does it show a huge lack of respect for
someone who has worked very hard to produce something the whole
community can use, but seriously undermines software freedom as a
whole. This is a slippery slope. If one community starts modifying the
others licenses for no purpose other than zealotry, I see only two
consequences:

   1) a hugh rift of mistrust between the developers of both camps,
meaning no cooperating to make the world a better place.

   2) A weakening of the respect for licensing on all sides of the
community, which weakens the credibility of both BSD *AND* the GPL
license when tested from the outside. Frankly, this scares the hell
out of me and dismays me. 

   I seriously hope that saner more mature and forward thinking heads
inside the Linux community will stop bashing the things that Theo and
the rest of our community is saying just because it's coming from
Theo, and he's a great target to bash, and start thinking about what
you are doing to free software as a whole. I think you are on the
verge of doing irreparable damage that will seriously weaken the
ability for all of our projects to move forward, and protect our
rights as code authors in the future.

-Bob


- End forwarded message -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Thinking outside the box on file systems

[Oleg Verych]

* Date: Sun, 19 Aug 2007 03:57:58 +0100

>> don't forget the ACPI interpreter.
>
> YAProof that bogons follow Boze statistics...

or bugons, then.

Why big minds didn't do rdev-like binary patching of the kernel image
with binary ACPI data? Getting such data in (any) userspace would be the
only thing in the install process of a modern distro, otherwise it's just
a boring decompressing with copying.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -mm] softlockup-improve-debug-output.patch fix

[Satyam Sharma]

kernel/softlockup.c: In function 'softlockup_tick':
kernel/softlockup.c:125: warning: 'regs' is used uninitialized in this function

So let's fix softlockup-improve-debug-output.patch to actually work,
and do what it claimed in the changelog :-)

Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>

---

 softlockup.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- kernel/softlockup.c~fix 2007-09-02 04:23:49.0 +0530
+++ kernel/softlockup.c 2007-09-02 04:34:45.0 +0530
@@ -80,7 +80,7 @@ void softlockup_tick(void)
int this_cpu = smp_processor_id();
unsigned long touch_timestamp = per_cpu(touch_timestamp, this_cpu);
unsigned long print_timestamp;
-   struct pt_regs *regs;
+   struct pt_regs *regs = get_irq_regs();
unsigned long now;
 
if (touch_timestamp == 0) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bugme-new] [Bug 8961] New: BUG triggered by oidentd in netlink code

[Patrick McHardy]

Athanasius wrote:

On Sat, Sep 01, 2007 at 06:38:23PM +0200, Patrick McHardy wrote:


You might be able to trigger it without this patch by running
"while true; do ss -tn; done" while doing ident queries, but
just running the while loop a couple of times in parallel
doesn't seem to trigger it here.


  I went for setting up a dummy listener in inetd, using tcpd, and
setting hosts.allow to specify [EMAIL PROTECTED]  Then a few while loops
spamming it with connections using nc.

  Anyway, on the old kernel that managed to trigger the BUG twice in
about 30 minutes.  I'm now on 2.6.22.6 plus your patch and coming up on
an hour (55+ mins) of the same and no sign of the BUG.

  So that looks like fixed to me.  I'll weigh in again if the daily
logcheck throws up another.



Thanks a lot for testing, I'll send a version for current -rc
upstream tommorrow.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: the Linux kernel, testsuites, and maybe *you*

[Mike Frysinger]

On 9/1/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> On Fri 31 Aug 2007 17:22, Mike Frysinger pondered:
> > is there any sort of standard for testing and integration into
> > mainline ?  in the Blackfin world, we've been developing little
> > external kernel modules and adding them to our own testsuite, but
> > often times these things are not Blackfin specific.  case in point,
> > we're integrating a string testsuite to make sure all of the fun str*
> > and mem* functions are sane and operate as they expected, but rather
> > than having just Blackfin benefit here, i'd like to see this pushed
> > upstream ...
>
> I know there have been some discussions at past OLS about some testing that
> Martin was working on.
>
> http://www.linuxsymposium.org/2006/view_abstract.php?content_key=13
>
> But I think this was more functional tests, less unit tests that what you are
> talking/asking about.
>
> http://test.kernel.org/functional/index.html
>
> Also - If I remember - most of the existing tests were for a self hosted
> environment - and might not be well suited to embedded (like Blackfin) which
> requires cross compile, and pretty thin runtime environment (uClibc +
> busybox's msh as shell).

i flipped through the autotest code a bit but i dont think this can do
what i'm looking for.  it appears to be a mix of LTP provides and what
we have for our Blackfin test infrastructure -- iow, all userspace
stuff and no real way of exercising kernel internals.
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: the Linux kernel, testsuites, and maybe *you*

[Mike Frysinger]

On 02 Sep 2007 00:08:57 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> BTW string functions are best tested in user space. That's
> a relatively bad example.

in theory, maybe ... in reality, i really dont think so

the string implementations are spread out over the kernel ... there's
implementations in lib/, include/asm-*/, and arch/*/lib/ ... so any
test code that would use these sources is going to be an ugly hack to
make sure it grabs all the right pieces from all the right places.

then there's the issue of API ... compiling code that is designed to
be in the kernel and nowhere else is going to require a mighty bit of
crappy glue logic in order for it to compile properly in userspace

but let's cheat and just use the kernel build system to produce .o's
for us ... then there's the issue of ABI.  there is no guarantee the
ABI the kernel uses internally is the same as the ABI userspace uses
(and in fact, on some architectures it is simply not possible).  so
you're left with a solution that may work for some, but not for
others.

or we put one common piece of C test code right into the kernel and be
done.  no worrying about the tested API/ABI/environment being
different from the actual runtime the kernel itself has.
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86/x86-64 PCI domain support

[Jeff Garzik]

Andi Kleen wrote:
The second function is redundant? 

No, it's a hook we must implement, when CONFIG_PCI_DOMAINS is enabled.


Then the other function is redundant.


No, both functions are required by the interface.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc4-mm1 "no CRC" MODPOST warnings

[Adrian Bunk]

On Sun, Sep 02, 2007 at 03:36:08AM +0530, Satyam Sharma wrote:
> 
> 
> On Fri, 31 Aug 2007, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
> 
> Got these on an i386 build with CONFIG_MODVERSIONS=y ...
> 
> WARNING: "div64_64" [net/netfilter/xt_connbytes.ko] has no CRC!
> WARNING: "div64_64" [net/ipv4/tcp_cubic.ko] has no CRC!
>...

That's expected since the fix is in git-kbuild.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] i386: fix a hang on stuck nmi watchdog

[Daniel Walker]

On Sat, 2007-09-01 at 23:45 +0200, Andi Kleen wrote:
> On Saturday 01 September 2007 22:54:17 Daniel Walker wrote:
> > In the case when an nmi gets stucks the endflag stays equal to zero. This
> > causes the busy looping on other cpus to continue, even tho the nmi test
> > is done.
> > 
> > On my machine with out the change below the system would hang right after
> > check_nmi_watchdog(). The change below just sets endflag prior to checking
> > if the test was successful or not.
> > 
> > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
> 
> Added thanks. I guess it's .23 material.

putting it in 2.6.23 seems appropriate .. Stephane's patch might be good
for 2.6.23 too .. 

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-image-2.6.23-rc4-amd64: Ethernet not functioning on Nvidia MCP51

[Philippe Bourcier]

Package: linux-image-2.6.23-rc4-amd64
Version: 2.6.23~rc4-1~experimental.1~snapshot.9433
Followup-For: Bug #438663


see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438663

/var/log/dmesg
- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
Linux version 2.6.23-rc4-amd64 (Debian 
2.6.23~rc4-1~experimental.1~snapshot.9433) ([EMAIL PROTECTED]) (gcc version 
4.1.3 20070718 (prerelease) (Debian 4.1.2-14+1)) #1 SMP Sat Sep 1 00:55:23 UTC 
2007
Command line: root=/dev/sdb2 ro video=nvidiafb:ywrap,mtrr vga=791
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 77fc (usable)
 BIOS-e820: 77fc - 77fce000 (ACPI data)
 BIOS-e820: 77fce000 - 77ff (ACPI NVS)
 BIOS-e820: 77ff - 7800 (reserved)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fef0 (reserved)
 BIOS-e820: ff78 - 0001 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 491456) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000FB5A0, 0014 (r0 ACPIAM)
ACPI: RSDT 77FC, 0030 (r1 A M I  OEMRSDT   8000630 MSFT   97)
ACPI: FACP 77FC0200, 0084 (r2 A M I  OEMFACP   8000630 MSFT   97)
ACPI: DSDT 77FC0440, 6087 (r1  A0588 A05880000 INTL 20060113)
ACPI: FACS 77FCE000, 0040
ACPI: MCFG 77FC0400, 003C (r1 A M I  OEMMCFG   8000630 MSFT   97)
ACPI: OEMB 77FCE040, 0060 (r1 A M I  AMI_OEM   8000630 MSFT   97)
Scanning NUMA topology in Northbridge 24
CPU has 2 num_cores
No NUMA configuration found
Faking a node at -77fc
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 491456) 1 entries of 3200 used
Bootmem setup node 0 -77fc
Zone PFN ranges:
  DMA 0 -> 4096
  DMA324096 ->  1048576
  Normal1048576 ->  1048576
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0:0 ->  159
0:  256 ->   491456
On node 0 totalpages: 491359
  DMA zone: 56 pages used for memmap
  DMA zone: 1045 pages reserved
  DMA zone: 2898 pages, LIFO batch:0
  DMA32 zone: 6663 pages used for memmap
  DMA32 zone: 480697 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x508
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: ASUS MPTABLE: Product ID:  MPTABLE: APIC at: 0xFEE0
Processor #0 (Bootup-CPU)
Processor #1
I/O APIC #2 at 0xFEC0.
Setting APIC routing to flat
Processors: 2
swsusp: Registered nosave memory region: 0009f000 - 000a
swsusp: Registered nosave memory region: 000a - 000e
swsusp: Registered nosave memory region: 000e - 0010
Allocating PCI resources starting at 8000 (gap: 7800:86c0)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 35176 bytes of per cpu data
Built 1 zonelists in Node order.  Total pages: 483595
Policy zone: DMA32
Kernel command line: root=/dev/sdb2 ro video=nvidiafb:ywrap,mtrr vga=791
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Marking TSC unstable due to TSCs unsynchronized
time.c: Detected 2210.125 MHz processor.
Console: colour dummy device 80x25
console [tty0] enabled
Checking aperture...
CPU 0: aperture @ c27000 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Memory: 1927924k/1965824k available (2066k kernel code, 37512k reserved, 977k 
data, 304k init)
Calibrating delay using timer specific routine.. 4424.07 BogoMIPS (lpj=8848148)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
ACPI: setting ELCR to 0200 (from 8ca0)
ExtINT not setup in hardware but reported by MP table
Using local APIC timer interrupts.
result 12557531
Detected 12.557 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4420.40 BogoMIPS (lpj=8840808)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: 

Re: Fwd: That whole "Linux stealing our code" thing

[Adrian Bunk]

On Sat, Sep 01, 2007 at 03:03:36PM -0700, Sam Leffler wrote:
> Adrian Bunk wrote:
>> On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote:
>>   
>>> On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>>> 
 Constantine A. Murenin wrote:
   
> This will hopefully help diminish certain myths about the code 
> licensing.
> 
 What myth?  The myth that Theo understands dual licensing?
   
>>> Reyk's code was never dual licensed, so it's not like it even matters
>>> to the original dispute.
>>> 
>>
>> It's no longer dual licenced in the FreeBSD tree because the FreeBSD 
>> people removed the GPL choice of the dual licenced code 3 months ago.
>>
>> So all of Theo's accusations of people breaking the law by making this 
>> dual licenced code GPL-only apply as well to the FreeBSD people...
>>   
>
> Sigh, why actually check the facts when you can make them up.   The code in 
> question is my code.  It has my copyright (modulo bits shared with onoe-san 
> who was consulted on the switch from dual-bsd/gpl to bsd only in freebsd).  

The latter is the code by Video54 Technologies?

> Of course what was amusing was how after I changed the license on the 
> current code in freebsd certain folks retroactively applied the license 
> changes to code that was 3 years old.
>
> But is there a point to all this nonsense?  I dual-licensed the code so 
> folks could adopt and use it however they saw fit.  As I've said before I 
> don't care what people do with the work I give away so long as they don't 
> claim it's their own.

Fully agreed.  :-)

>>> That said, I don't see what exact wording you consider inaccurate.
>>> 
>>
>> Both the FreeBSD and Linux people draw the logical conclusion that this 
>> "Alternatively" means everyone can always choose to remove one of the two 
>> choices alternatively offered.
>>
>> According to Theo, that is "breaking the law"...
>
> I've yet to see "FreeBSD people" speak up so again you're just spouting 
> jibberish.  I am speaking up as the author of the code that set the dual 
> license in place.  I have the definitive say and I have said that any of my 
> code that is dual-licensed can be made gpl only.

Sorry, this has been a thinko on my side:

If noone except you and onoe-san made any contributions to this code 
that were non-trivial enough for automatically giving its author a 
copyright on his contributions (whatever this means in various 
jurisdictions...) it was indeed an author-only change.

>Sam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-image-2.6.22-2-amd64: Ethernet not functioning on Nvidia MCP51

[Philippe Bourcier]

Package: linux-image-2.6.22-2-amd64
Followup-For: Bug #438663


see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438663

/var/log/dmesg
- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
Linux version 2.6.22-2-amd64 (Debian 2.6.22-4snapshot.9420) ([EMAIL PROTECTED]) 
(gcc version 4.1.3 20070718 (prerelease) (Debian 4.1.2-14+1)) #1 SMP Fri Aug 31 
08:43:40 UTC 2007
Command line: root=/dev/sdb2 ro video=nvidiafb:ywrap,mtrr vga=791
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 77fc (usable)
 BIOS-e820: 77fc - 77fce000 (ACPI data)
 BIOS-e820: 77fce000 - 77ff (ACPI NVS)
 BIOS-e820: 77ff - 7800 (reserved)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fef0 (reserved)
 BIOS-e820: ff78 - 0001 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 491456) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000FB5A0, 0014 (r0 ACPIAM)
ACPI: RSDT 77FC, 0030 (r1 A M I  OEMRSDT   8000630 MSFT   97)
ACPI: FACP 77FC0200, 0084 (r2 A M I  OEMFACP   8000630 MSFT   97)
ACPI: DSDT 77FC0440, 6087 (r1  A0588 A05880000 INTL 20060113)
ACPI: FACS 77FCE000, 0040
ACPI: MCFG 77FC0400, 003C (r1 A M I  OEMMCFG   8000630 MSFT   97)
ACPI: OEMB 77FCE040, 0060 (r1 A M I  AMI_OEM   8000630 MSFT   97)
Scanning NUMA topology in Northbridge 24
No NUMA configuration found
Faking a node at -77fc
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 491456) 1 entries of 3200 used
Bootmem setup node 0 -77fc
Zone PFN ranges:
  DMA 0 -> 4096
  DMA324096 ->  1048576
  Normal1048576 ->  1048576
early_node_map[2] active PFN ranges
0:0 ->  159
0:  256 ->   491456
On node 0 totalpages: 491359
  DMA zone: 56 pages used for memmap
  DMA zone: 1020 pages reserved
  DMA zone: 2923 pages, LIFO batch:0
  DMA32 zone: 6663 pages used for memmap
  DMA32 zone: 480697 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x508
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: ASUS MPTABLE: Product ID:  MPTABLE: APIC at: 0xFEE0
Processor #0 (Bootup-CPU)
Processor #1
I/O APIC #2 at 0xFEC0.
Setting APIC routing to flat
Processors: 2
swsusp: Registered nosave memory region: 0009f000 - 000a
swsusp: Registered nosave memory region: 000a - 000e
swsusp: Registered nosave memory region: 000e - 0010
Allocating PCI resources starting at 8000 (gap: 7800:86c0)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 37896 bytes of per cpu data
Built 1 zonelists.  Total pages: 483620
Kernel command line: root=/dev/sdb2 ro video=nvidiafb:ywrap,mtrr vga=791
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Marking TSC unstable due to TSCs unsynchronized
time.c: Detected 2210.074 MHz processor.
Console: colour dummy device 80x25
Checking aperture...
CPU 0: aperture @ c27000 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Memory: 1928072k/1965824k available (2009k kernel code, 37364k reserved, 945k 
data, 296k init)
Calibrating delay using timer specific routine.. 4423.95 BogoMIPS (lpj=8847910)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
ACPI: setting ELCR to 0200 (from 8ca0)
ExtINT not setup in hardware but reported by MP table
Using local APIC timer interrupts.
result 12557241
Detected 12.557 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4420.50 BogoMIPS (lpj=8841009)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 01
Brought up 2 CPUs
migration_cost=317
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: BIOS Bug: MCFG area at e000 is not 

Re: [PATCH] x86/x86-64 PCI domain support

[Andi Kleen]

> > The second function is redundant? 
> 
> No, it's a hook we must implement, when CONFIG_PCI_DOMAINS is enabled.

Then the other function is redundant.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Track accurate idle time with tick_sched.idle_sleeptime

[Andi Kleen]

Venki Pallipadi <[EMAIL PROTECTED]> writes:
>  
> +void tick_nohz_stop_idle(int cpu)
> +{
> + struct tick_sched *ts = _cpu(tick_cpu_sched, cpu);
> +
> + if (ts->idle_active) {
> + ktime_t now, delta;
> + now = ktime_get();

That could be PM timer read costing thousands of cycles.

For going into idle it's probably not a real problem, but it could
seriously affect out of idle latencies.

You would really need a cheaper per CPU timer that doesn't
stop in idle (which rules out sched_clock). It's all unfortunately
quite messy.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: speeding up swapoff

[Andi Kleen]

Daniel Drake <[EMAIL PROTECTED]> writes:
> 
> It's more-or-less a real life problem. We have an interactive
> application which, when triggered by the user, performs rendering tasks
> which must operate in real-time. In attempt to secure performance, we
> want to ensure everything is memory resident and that nothing might be
> swapped out during the process. So, we run swapoff at that time.

If the system gets under serious memory pressure it'll happily discard
your text pages too (and later reload them from disk). The same
for any file data you might need to access.

swapoff will only affect anonymous memory, but not all the other
memory you'll need as well.

There's no way around mlock/mlockall() to really prevent this.

Still even with that you could still lose dentries/inodes etc which
can also cause stalls. The only way to keep them locked
is to keep the files always open.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sysctl: Deprecate sys_sysctl in a user space visible fashion.

[Andi Kleen]

Rob Landley <[EMAIL PROTECTED]> writes:
> 
> A lot of embedded people like to configure /proc out of the kernel for space 
> reasons.  This would make that noticeably more painful.

I had a patch for a sysctl_name(2) for this a long time ago.
If it was a serious issue that could be reintroduced.

BTW sysctl(2) only needs to be quiet for a single sysctl used
by glibc.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: XFS Fails Quality Assurance Tests on ARM

[Andi Kleen]

David Miller <[EMAIL PROTECTED]> writes:

> From: Byron Bradley <[EMAIL PROTECTED]>
> Date: Fri, 31 Aug 2007 03:12:46 + (UTC)
> 
> > Anybody got any ideas of how we fix this?
> 
> I don't know how much testing XFS gets on ARM, but one thing that some
> ARM chips have is D-cache aliasing problems and one thing XFS uses a
> lot is virtual remapping of various data structures via vmap().
> 
> This might be what is causing the problems.

AFAIK XFS uses vmap() mainly during log replay. If David's theory
was true then the failures must be seen during tests that do 
this.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 1/6] Storing ipcs into IDRs

[Andi Kleen]

[EMAIL PROTECTED] writes:

> This patch introduces ipcs storage into IDRs. The main changes are:
>   . This ipc_ids structure is changed: the entries array is changed into a
> root idr structure.
>   . The grow_ary() routine is removed: it is not needed anymore when adding
> an ipc structure, since we are now using the IDR facility.
>   . The ipc_rmid() routine interface is changed:
>. there is no need for this routine to return the pointer passed in as
>  argument: it is now declared as a void
>. since the id is now part of the kern_ipc_perm structure, no need to
>  have it as an argument to the routine
> 

Thanks for doing this work. It was long overdue.

Do you have any data how this changes memory consumption with 
many objects? 

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -mm] Hibernation: Check if ACPI is enabled during restore in the right place

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

The following scenario leads to total confusion of the platform firmware on
some boxes (eg. HPC nx6325):
* Hibernate with ACPI enabled
* Pass "acpi=off" to the boot kernel

To prevent this from happening it's necessary to check if ACPI is enabled (and
enable it if that's not the case) _right_ _after_ control has been transfered
from the boot kernel to the image kernel, before device_power_up() is called
(ie. with interrupts disabled).  Enabling ACPI after calling device_power_up()
turns out to be insufficient.

For this reason, introduce new hibernation callback ->leave() that will be
executed before device_power_up() by the restored image kernel.  To make it
work, it also is necessary to move swsusp_suspend() from swsusp.c to disk.c
(it's name is changed to "create_image", which is more up to the point).

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 drivers/acpi/sleep/main.c |7 -
 include/linux/suspend.h   |7 +
 kernel/power/disk.c   |   58 +-
 kernel/power/power.h  |1 
 kernel/power/swsusp.c |   33 --
 5 files changed, 70 insertions(+), 36 deletions(-)

Index: linux-2.6.23-rc4-mm1/drivers/acpi/sleep/main.c
===
--- linux-2.6.23-rc4-mm1.orig/drivers/acpi/sleep/main.c
+++ linux-2.6.23-rc4-mm1/drivers/acpi/sleep/main.c
@@ -231,13 +231,17 @@ static int acpi_hibernation_enter(void)
return ACPI_SUCCESS(status) ? 0 : -EFAULT;
 }
 
-static void acpi_hibernation_finish(void)
+static void acpi_hibernation_leave(void)
 {
/*
 * If ACPI is not enabled by the BIOS and the boot kernel, we need to
 * enable it here.
 */
acpi_enable();
+}
+
+static void acpi_hibernation_finish(void)
+{
acpi_leave_sleep_state(ACPI_STATE_S4);
acpi_disable_wakeup_device(ACPI_STATE_S4);
 
@@ -267,6 +271,7 @@ static struct platform_hibernation_ops a
.finish = acpi_hibernation_finish,
.prepare = acpi_hibernation_prepare,
.enter = acpi_hibernation_enter,
+   .leave = acpi_hibernation_leave,
.pre_restore = acpi_hibernation_pre_restore,
.restore_cleanup = acpi_hibernation_restore_cleanup,
 };
Index: linux-2.6.23-rc4-mm1/include/linux/suspend.h
===
--- linux-2.6.23-rc4-mm1.orig/include/linux/suspend.h
+++ linux-2.6.23-rc4-mm1/include/linux/suspend.h
@@ -156,6 +156,12 @@ extern void mark_free_pages(struct zone 
  * Called after the nonboot CPUs have been disabled and all of the low
  * level devices have been shut down (runs with IRQs off).
  *
+ * @leave: Perform the first stage of the cleanup after the system sleep state
+ * indicated by @set_target() has been left.
+ * Called right after the control has been passed from the boot kernel to
+ * the image kernel, before the nonboot CPUs are enabled and before devices
+ * are resumed.  Executed with interrupts disabled.
+ *
  * @pre_restore: Prepare system for the restoration from a hibernation image.
  * Called right after devices have been frozen and before the nonboot
  * CPUs are disabled (runs with IRQs on).
@@ -170,6 +176,7 @@ struct platform_hibernation_ops {
void (*finish)(void);
int (*prepare)(void);
int (*enter)(void);
+   void (*leave)(void);
int (*pre_restore)(void);
void (*restore_cleanup)(void);
 };
Index: linux-2.6.23-rc4-mm1/kernel/power/disk.c
===
--- linux-2.6.23-rc4-mm1.orig/kernel/power/disk.c
+++ linux-2.6.23-rc4-mm1/kernel/power/disk.c
@@ -93,6 +93,17 @@ static int platform_pre_snapshot(int pla
 }
 
 /**
+ * platform_leave - prepare the machine for switching to the normal mode
+ * of operation using the platform driver (called with interrupts disabled)
+ */
+
+static void platform_leave(int platform_mode)
+{
+   if (platform_mode && hibernation_ops)
+   hibernation_ops->leave();
+}
+
+/**
  * platform_finish - switch the machine to the normal mode of operation
  * using the platform driver (must be called after platform_prepare())
  */
@@ -129,6 +140,51 @@ static void platform_restore_cleanup(int
 }
 
 /**
+ * create_image - freeze devices that need to be frozen with interrupts
+ * off, create the hibernation image and thaw those devices.  Control
+ * reappears in this routine after a restore.
+ */
+
+int create_image(int platform_mode)
+{
+   int error;
+
+   error = arch_prepare_suspend();
+   if (error)
+   return error;
+
+   local_irq_disable();
+   /* At this point, device_suspend() has been called, but *not*
+* device_power_down(). We *must* call device_power_down() now.
+* Otherwise, drivers for some devices (e.g. interrupt controllers)
+* become 

Re: the Linux kernel, testsuites, and maybe *you*

[Andi Kleen]

"Mike Frysinger" <[EMAIL PROTECTED]> writes:

> is there any sort of standard for testing and integration into
> mainline ?  

Everybody does their own.

> in the Blackfin world, we've been developing little
> external kernel modules and adding them to our own testsuite, but
> often times these things are not Blackfin specific.  case in point,
> we're integrating a string testsuite to make sure all of the fun str*
> and mem* functions are sane and operate as they expected, but rather
> than having just Blackfin benefit here, i'd like to see this pushed
> upstream ...

I would like to see this too. I wrote a couple of unit tests
during x86-64 development too and they would be handy
to have in a central place.

The SUSE kernel also has a crasher module that exercises the
allocators and is pretty useful to stress code in general.

Disadvantage is that test code tends to be hackish and ugly
and very specialized and will probably not pass standard review procedures.

Also the rt people seem to have pushed a couple of tests in already, 
but I always hated it that they're in the standard directories.
RCU also has, in fact they added a "eat all my CPU in tests"
CONFIG option. Just making that dependent on a CONFIG_UNIT_TESTS
would be a good change in itself. And then there are the slab
failure inducers of course.

BTW string functions are best tested in user space. That's
a relatively bad example.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DeskOpt - on fly task, i/o scheduler optimization

[Andi Kleen]

Michal Piotrowski <[EMAIL PROTECTED]> writes:

> Here is something that might be useful for gamers and audio/video editors
> http://www.stardust.webpages.pl/files/tools/deskopt/

To make it double cool combine that with the generic genetic 
optimizer for parameters that was posted a couple of months ago.

> 
> You can easily tune CFS/CFQ scheduler params
> 
> sched_batch_wakeup_granularity_ns
> sched_latency_ns
> sched_min_granularity_ns
> sched_runtime_limit_ns
> sched_stat_granularity_ns
> sched_wakeup_granularity_ns
> 
> back_seek_max
> back_seek_penalty
> fifo_expire_async
> fifo_expire_sync
> quantum
> slice_async
> slice_async_rq
> slice_idle
> slice_sync
> 

You should probably add the device queue length too. That seems
to often have a large impact on IO scheduling because on modern
long queue controllers the Linux IO scheduler often doesn't
have much to do because the device queue just eats it all up quickly.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Adrian Bunk]

On Sat, Sep 01, 2007 at 05:51:49PM -0400, Constantine A. Murenin wrote:
> On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Sat, Sep 01, 2007 at 10:54:57PM +0200, Adrian Bunk wrote:
> > > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote:
> > > > On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > > > > Constantine A. Murenin wrote:
> > > > > > This will hopefully help diminish certain myths about the code 
> > > > > > licensing.
> > > > >
> > > > > What myth?  The myth that Theo understands dual licensing?
> > > >
> > > > Reyk's code was never dual licensed, so it's not like it even matters
> > > > to the original dispute.
> >
> > Oh, and if you look at the OpenBSD CVS you see versions 4 months old
> > with dozens of contributions by Reyk and with:
> >
> > /*  $OpenBSD: ath.c,v 1.63 2007/05/09 16:41:14 reyk Exp $  */
> > /*  $NetBSD: ath.c,v 1.37 2004/08/18 21:59:39 dyoung Exp $*/
> >
> > /*-
> >  * Copyright (c) 2002-2004 Sam Leffler, Errno Consulting
> >  * All rights reserved.
> >  *
> >  * Redistribution and use in source and binary forms, with or without
> >  * modification, are permitted provided that the following conditions
> >  * are met:
> >  * 1. Redistributions of source code must retain the above copyright
> >  *notice, this list of conditions and the following disclaimer,
> >  *without modification.
> >  * 2. Redistributions in binary form must reproduce at minimum a disclaimer
> >  *similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
> >  *redistribution must be conditioned upon including a substantially
> >  *similar Disclaimer requirement for further binary redistribution.
> >  * 3. Neither the names of the above-listed copyright holders nor the names
> >  *of any contributors may be used to endorse or promote products derived
> >  *from this software without specific prior written permission.
> >  *
> >  * Alternatively, this software may be distributed under the terms of the
> >  * GNU General Public License ("GPL") version 2 as published by the Free
> >  * Software Foundation.
> >  *
> >  * NO WARRANTY
> >  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> >  * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> >  * LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
> >  * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
> >  * THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
> >  * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> >  * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> >  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
> >  * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 
> > OTHERWISE)
> >  * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> >  * THE POSSIBILITY OF SUCH DAMAGES.
> >  */
> 
> Where exactly do you see Reyk's copyright in the above quote?
>...

He has automatically a copyright on his contributions if they are 
non-trivial.

> C.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86/x86-64 PCI domain support

[Jeff Garzik]

Andi Kleen wrote:
 
+config PCI_DOMAINS

+   bool "PCI domain support"
+   depends on PCI


I don't think this should be a config option.


CONFIG_PCI_DOMAINS is referenced in arch-neutral code, so the symbol 
_must_ be defined.


It can be hidden, perhaps, if that makes our x86 maintainer happy :)



But there should be a pci=... option with Documentation to turn it off at 
runtime


OK



+static inline int pci_proc_domain(struct pci_bus *bus)
+{
+   return pci_domain_nr(bus);
+}


The second function is redundant? 


No, it's a hook we must implement, when CONFIG_PCI_DOMAINS is enabled.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Sam Leffler]

Adrian Bunk wrote:

On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote:
  

On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:


Constantine A. Murenin wrote:
  

This will hopefully help diminish certain myths about the code licensing.


What myth?  The myth that Theo understands dual licensing?
  

Reyk's code was never dual licensed, so it's not like it even matters
to the original dispute.



It's no longer dual licenced in the FreeBSD tree because the FreeBSD 
people removed the GPL choice of the dual licenced code 3 months ago.


So all of Theo's accusations of people breaking the law by making this 
dual licenced code GPL-only apply as well to the FreeBSD people...
  


Sigh, why actually check the facts when you can make them up.   The code 
in question is my code.  It has my copyright (modulo bits shared with 
onoe-san who was consulted on the switch from dual-bsd/gpl to bsd only 
in freebsd).  Of course what was amusing was how after I changed the 
license on the current code in freebsd certain folks retroactively 
applied the license changes to code that was 3 years old.


But is there a point to all this nonsense?  I dual-licensed the code so 
folks could adopt and use it however they saw fit.  As I've said before 
I don't care what people do with the work I give away so long as they 
don't claim it's their own.


  

That said, I don't see what exact wording you consider inaccurate.



Both the FreeBSD and Linux people draw the logical conclusion that this 
"Alternatively" means everyone can always choose to remove one of the 
two choices alternatively offered.


According to Theo, that is "breaking the law"...

  


I've yet to see "FreeBSD people" speak up so again you're just spouting 
jibberish.  I am speaking up as the author of the code that set the dual 
license in place.  I have the definitive say and I have said that any of 
my code that is dual-licensed can be made gpl only.


   Sam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86/x86-64 PCI domain support

[Andi Kleen]

>  
> +config PCI_DOMAINS
> + bool "PCI domain support"
> + depends on PCI

I don't think this should be a config option.

But there should be a pci=... option with Documentation to turn it off at 
runtime


> +static inline int pci_proc_domain(struct pci_bus *bus)
> +{
> + return pci_domain_nr(bus);
> +}

The second function is redundant? 


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc4-mm1 "no CRC" MODPOST warnings

[Satyam Sharma]

On Fri, 31 Aug 2007, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/

Got these on an i386 build with CONFIG_MODVERSIONS=y ...

WARNING: "div64_64" [net/netfilter/xt_connbytes.ko] has no CRC!
WARNING: "div64_64" [net/ipv4/tcp_cubic.ko] has no CRC!

Full .config at: http://www.cse.iitk.ac.in/users/ssatyam/config-mm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Adrian Bunk]

On Sat, Sep 01, 2007 at 05:27:03PM -0400, Constantine A. Murenin wrote:
> On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote:
> > > On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > > > Constantine A. Murenin wrote:
> > > > > This will hopefully help diminish certain myths about the code 
> > > > > licensing.
> > > >
> > > > What myth?  The myth that Theo understands dual licensing?
> > >
> > > Reyk's code was never dual licensed, so it's not like it even matters
> > > to the original dispute.
> >
> > It's no longer dual licenced in the FreeBSD tree because the FreeBSD
> > people removed the GPL choice of the dual licenced code 3 months ago.
> 
> FreeBSD doesn't have Reyk's ath(4) HAL, which OpenHAL is based on.
> 
> FreeBSD has a driver written by Sam, and a binary-only HAL, also written by 
> Sam.
> 
> > So all of Theo's accusations of people breaking the law by making this
> > dual licenced code GPL-only apply as well to the FreeBSD people...
> 
> How? FreeBSD doesn't have Reyk's ath(4) HAL from OpenBSD, so there are
> no possible licensing accusations and violations.

OK, I begin to understand this, there seem to be three different types 
of files changed by Jiri's patch:
1. dual licenced files planned to make GPL-only
2. previously dual licenced files with a too recent version used planned 
   to make GPL-only
3. never dual licenced files planned to make GPL-only

For files under 1. and 2. Reyk did contribute to dual licenced code 
without touching the licence, but I missed that there's also code unter 3.

So there is a problem, but not with the code under 1. (unless you plan 
to change the semantics of the word "alternatively"), the problem is 
with some headers under 2. plus the code under 3.

It's funny how Theo missed the part of Jiri's patch that actually is a 
copyright violation and instead complains about the part that is OK...

> > > That said, I don't see what exact wording you consider inaccurate.
> >
> > Both the FreeBSD and Linux people draw the logical conclusion that this
> > "Alternatively" means everyone can always choose to remove one of the
> > two choices alternatively offered.
> >
> > According to Theo, that is "breaking the law"...
> 
> FreeBSD's ath(4) code, both the driver and the HAL, is entirely
> written by Sam Leffler, who can licence it in whichever way he seems
> reasonable. The driver part of Sam's code is also present in OpenBSD,
> but the HALs in OpenBSD and FreeBSD are entirely different.

Sam also changed the licence of a file additionally containing an
  Copyright (c) 2004 Video54 Technologies, Inc.

> C.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: That whole "Linux stealing our code" thing

[Constantine A. Murenin]

On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 01, 2007 at 10:54:57PM +0200, Adrian Bunk wrote:
> > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote:
> > > On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > > > Constantine A. Murenin wrote:
> > > > > This will hopefully help diminish certain myths about the code 
> > > > > licensing.
> > > >
> > > > What myth?  The myth that Theo understands dual licensing?
> > >
> > > Reyk's code was never dual licensed, so it's not like it even matters
> > > to the original dispute.
>
> Oh, and if you look at the OpenBSD CVS you see versions 4 months old
> with dozens of contributions by Reyk and with:
>
> /*  $OpenBSD: ath.c,v 1.63 2007/05/09 16:41:14 reyk Exp $  */
> /*  $NetBSD: ath.c,v 1.37 2004/08/18 21:59:39 dyoung Exp $*/
>
> /*-
>  * Copyright (c) 2002-2004 Sam Leffler, Errno Consulting
>  * All rights reserved.
>  *
>  * Redistribution and use in source and binary forms, with or without
>  * modification, are permitted provided that the following conditions
>  * are met:
>  * 1. Redistributions of source code must retain the above copyright
>  *notice, this list of conditions and the following disclaimer,
>  *without modification.
>  * 2. Redistributions in binary form must reproduce at minimum a disclaimer
>  *similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
>  *redistribution must be conditioned upon including a substantially
>  *similar Disclaimer requirement for further binary redistribution.
>  * 3. Neither the names of the above-listed copyright holders nor the names
>  *of any contributors may be used to endorse or promote products derived
>  *from this software without specific prior written permission.
>  *
>  * Alternatively, this software may be distributed under the terms of the
>  * GNU General Public License ("GPL") version 2 as published by the Free
>  * Software Foundation.
>  *
>  * NO WARRANTY
>  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>  * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>  * LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
>  * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
>  * THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
>  * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>  * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
>  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
>  * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>  * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
>  * THE POSSIBILITY OF SUCH DAMAGES.
>  */

Where exactly do you see Reyk's copyright in the above quote?

http://www.openbsd.org/cgi-bin/man.cgi?query=ath=4#AUTHORS

C.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/