Re: [PATCH] Unbreak MSI on ATI devices
On Thu, 21 Dec 2006, Petr Vandrovec wrote:
> So my question is - what is real reason for disabling INTX when in MSI mode?
> According to PCI spec it should not be needed.
The PCI spec is at least not clear enough on the matter to keep nVidia
from thinking that it's the OS's responsibility to make legacy interrupts
not happen, by disabling INTX.
> None of devices in the box assert INTX while in MSI even if INTX is enabled.
I've got a forcedeth-driven ethernet card that does, and people have
reported that nVidia "Intel HDA" sound does as well.
> So I'd like to see first patch below accepted. If there are some
> devices which require INTX disabling, then apparently decision whether
> to disable it or no has to be moved to device drivers, or some
> blacklist/whitelist must be created...
PCI Express (IIRC) had the pci_intx() calls already, so it's probably
actually required by the spec (or at least common implementations) there.
I'd guess that it's more common for hardware to be unhappy with intx
enabled than to be unhappy with intx disabled, since the hardware is
supposed to not send legacy interrupts.
> I'm not sure about second one - I have it in my tree for months, but I run
> that kernel only on hardware mentioned above, so it is probably too dangerous
> until pci_enable_msi() gets answer whether MSI works or no always right.
I think it'd be better to add an module parameter, like in the later
drivers in your patch. Figuring out how to get MSI working whenever it's
available isn't going to move forward unless there's an easy way to test
it, especially since (according to rumor) Windows doesn't use it at all.
> /proc/interrupts after patch. Before patch *hci_hcd:usb* were at zero,
> IRQ21 was stuck with IRQ count at 1, and HCD complained about
> "Unlink after no-IRQ?".
Maybe the intx disable is just totally broken for your device? It
certainly shouldn't cause the delivery of *more* legacy interrupts, and if
it does with MSI enabled, I'd be surprised if it didn't without MSI. My
guess is that that device should get a quirk to just leave the INTx
disable bit alone (such that pci_intx doesn't do anything, regardless of
context).
> diff -uprdN linux/sound/pci/atiixp.c linux/sound/pci/atiixp.c
> --- linux/sound/pci/atiixp.c 2006-12-16 13:35:47.0 -0800
> +++ linux/sound/pci/atiixp.c 2006-12-16 13:57:09.0 -0800
> @@ -1442,6 +1446,11 @@ static int snd_atiixp_suspend(struct pci
> snd_atiixp_aclink_down(chip);
> snd_atiixp_chip_stop(chip);
>
> + if (chip->have_msi) {
> + pci_disable_msi(pci);
> + } else {
> + pci_intx(pci, 0);
> + }
This doesn't look right, at least for !chip->have_msi. Or is disabling
intx desirable here for non-MSI? I'd guess that devices that freak out if
you fiddle with intx are likely to be old, and therefore likely to not
support MSI.
> @@ -1532,6 +1546,11 @@ static int snd_atiixp_free(struct atiixp
> if (chip->remap_addr)
> iounmap(chip->remap_addr);
> pci_release_regions(chip->pci);
> + if (chip->have_msi) {
> + pci_disable_msi(chip->pci);
> + } else {
> + pci_intx(chip->pci, 0);
> + }
My playing with forcedeth trying to get my system working suggests that
the expected intx state for a device with no driver is "not disabled". I
think the else clause here would cause the device to not work if you used
this driver, unloaded the module, and loaded a version without the patch
(or kexeced an older kernel, or soft-rebooted into some operating system
without MSI support).
-Daniel
*This .sig left intentionally blank*
-
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] romsignature/checksum cleanup
Rene Herman wrote: Use adding __init to romsignature() (it's only called from probe_roms() which is itself __init) as an excuse to submit a pedantic cleanup. Hmm, by the way, if romsignature() needs this probe_kernel_address() thing, why doesn't romchecksum()? (Rusty in CC as author of bd472c794bbf6771c3fc1c58f188bc16c393d2fe) Rene. - 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: ebtables problems on 2.6.19.1 *and* 2.6.16.36
Christopher S. Aker wrote:
Patrick McHardy wrote:
I'm trying to reproduce this (without success so far), please send your
kernel config and your ebtables script.
You could try if 2.6.19 works, there were some ebtables changes in
2.6.19.1 that touched this code.
We're hitting this too, on both 2.6.16.36 and 2.6.19.1.
BUG: unable to handle kernel paging request at virtual address f8cec008
printing eip:
c0462272
*pde =
Oops: [#1]
SMP
Modules linked in: e1000
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.19.1-1-bigmem #1)
EIP is at translate_table+0x2b3/0xddf
eax: f8ce2000 ebx: 0004 ecx: f6d53e90 edx: f8ce2000
esi: f8cebfa0 edi: 000e ebp: esp: f6d53e08
ds: 007b es: 007b ss: 0068
Process ebtables (pid: 4788, ti=f6d52000 task=f6d51550 task.ti=f6d52000)
Stack: f6d53e40 c0540440 0007 f6d53ebc 0001 0028
0004 0fa0 0fd0 f8d38000 f8ce2000 f6d53e90
8000
0004 0014 0014
0600
Call Trace:
[] do_replace+0x113/0x6da
[] get_page_from_freelist+0x8c/0xa8
[] do_ebt_set_ctl+0x2d/0x2e
[] nf_sockopt+0xfa/0xfc
[] nf_setsockopt+0x23/0x2b
[] ip_setsockopt+0x86/0x91
[] sock_common_setsockopt+0x23/0x2f
[] sys_setsockopt+0x61/0xac
[] sys_socketcall+0x1e9/0x249
[] do_page_fault+0x0/0x664
[] sysenter_past_esp+0x56/0x79
[] svc_recv+0x9c/0x3f5
===
Code: 30 3b 28 0f 83 5c 02 00 00 8b 54 24 30 8b 74 24 24 8b 4c 24 34 8b
5c 24 4c 03 72 24 8b 79 20 89 5c 24 20 c7 44 24 1c 00 00 00 00 <8b> 56
68 8b 46 6c 29 d0 31 d2 89 44 24 14 8b 06 85 c0 0f 84 f7
EIP: [] translate_table+0x2b3/0xddf SS:ESP 0068:f6d53e08
Unable to handle kernel paging request at virtual address f8a3b00c
printing eip:
c03cce45
*pde =
Oops: [#13]
SMP
Modules linked in: e1000
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.16.36-1-bigmem #1)
EIP is at translate_table+0x47b/0xfc2
eax: d8fbbc3c ebx: 0098 ecx: c049b780 edx:
esi: f8a3afa0 edi: 000e ebp: 0001 esp: d8fbbb7c
ds: 007b es: 007b ss: 0068
Process ebtables (pid: 7917, threadinfo=d8fba000 task=e7892550)
Stack: <0>c049b75c f8a3af78 c04468f8 d8fbbbcc c049b740 0007 d8fbbc68
d30f4260
00d2 d8fba000 d30f4240 d8fba000 0028 0004
0004
0fa0 0fd0 f8a8e000 f8a38000
Call Trace:
[] do_replace+0x16b/0x887
[] copy_everything_to_user+0x21a/0x35c
[] do_ebt_set_ctl+0x40/0x42
[] nf_sockopt+0x11f/0x121
[] nf_setsockopt+0x37/0x3b
[] ip_setsockopt+0x3f9/0xb0e
[] nf_sockopt+0xad/0x121
[] nf_getsockopt+0x37/0x3b
[] ip_getsockopt+0x5bd/0x62b
[] current_fs_time+0x5d/0x78
[] touch_atime+0x7d/0xcd
[] zap_pte_range+0xf1/0x316
[] unmap_page_range+0x103/0x174
[] prio_tree_remove+0x77/0xe7
[] buffered_rmqueue+0x155/0x209
[] buffered_rmqueue+0x155/0x209
[] get_page_from_freelist+0x8c/0xa6
[] get_page_from_freelist+0x8c/0xa6
[] __alloc_pages+0x56/0x309
[] page_add_file_rmap+0x2a/0x2c
[] do_anonymous_page+0x122/0x22a
[] __handle_mm_fault+0x138/0x326
[] sock_common_setsockopt+0x33/0x37
[] sys_setsockopt+0x6c/0xb2
[] sys_socketcall+0x1f4/0x254
[] do_page_fault+0x0/0x630
[] sysenter_past_esp+0x54/0x75
Code: 24 8b bc 24 8c 00 00 00 8b 84 24 88 00 00 00 8b 54 24 64 8b 74 24
44 03 77 24 8b 78 20 c7 44 24 38 00 00 00 00 89 54 24 3c 31 d2 <8b> 4e
6c 8b 5e 68 29 d9 89 4c 24 30 8b 06 85 c0 0f 84 14 02 00
It seems to happen when flushing a user-defined ebtable, or removing a
rule -- but not every time. It leaves the ebtable userspace process in D
state on 2.6.19.1 but not on 2.6.16.36 (?).
Considering I've never had these problems before, and that both stable
(2.6.16.36) and current (2.6.19.1) exhibit this issue, I'd venture to
guess that it's something that went into both of them very recently.
Just a follow-up -- this doesn't happen with 2.6.19.
-Chris
-
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: Binary Drivers
Am Sonntag, 24. Dezember 2006 21:20 schrieb Horst H. von Brand: > It is done regularly. Current cars control the fuel injection etc > via an onboard computer, without this control the engine just won't > start. Did you get the specs for the exact fuel control algorithm > with your car? Should you be able to fool around with that, thus > violating emission control measures (this would damage not only > you, but everybody)? You won't get access to the software source code, but the car manufactors are required to document and publish the interfaces to their hardware, so that also independent car workshops are able to do maintenance and repair on it. You have ever heared of chip tuning? Chip tuning is a replacement of the original firmware with a 3rd party one, that will give higher power and torque. So your gave a perfect example from another industry, where the specs are actually published. Again: We don't want the original drivers being open sourced. All we want is access to the hardware interface documentation, so that we can develop our very own drivers. And heck: With a custom driver for some RAID controller or a graphics card you will hardly violate any regulations. There might be issues with radio hardware, but surprisingly the drivers for the good stuff (i.e. not those cheapo cards with lousy range and throughput) are open source (Prism/HostAP). I'd even say, that selling hardware without giving documentation is illegal also from a competitions law point of view. By supplying a driver only for a small range of operating systems you, as the factual owner of a piece of hardware are hindered to use it in the way you like, e.g. use it with the homebrew operating system you wrote (or a finnish student wrote in 1991 ;-)). Thus the HW manufactor delivering drivers only for a small range of operating systems can be assumed to distort the market by biasing one specific operting system manufactor _and_ hardware manufactors. Remember, that many binary only drivers for Linux are only avaliable for the x86 variant. Only few are also avaliable for x86_64 (AMD64), even fewer for IA64 and for other architectures it's getting homeopathic. This is IMHO a extreme distortion of the free market. Happy holydays Wolfgang Draxinger pgphFnTk0l3j7.pgp Description: PGP signature
Re: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
On Mon, 25 Dec 2006, Adam J. Richter wrote: Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint for several network programs running on my system: [ 156.381868] BUG: sleeping function called from invalid context at net/core/sock.c:1523 [ 156.381876] in_atomic():1, irqs_disabled():0 [ 156.381881] no locks held by kio_http/9693. [ 156.381886] [] show_trace_log_lvl+0x1a/0x2f [ 156.381900] [] show_trace+0x12/0x14 [ 156.381908] [] dump_stack+0x16/0x18 [ 156.381917] [] __might_sleep+0xe5/0xeb [ 156.381926] [] lock_sock_nested+0x1d/0xc4 [ 156.381937] [] selinux_netlbl_inode_permission+0x5a/0x8e [ 156.381946] [] selinux_file_permission+0x96/0x9b [ 156.381954] [] vfs_write+0x8d/0x167 [ 156.381962] [] sys_write+0x3f/0x63 [ 156.381971] [] syscall_call+0x7/0xb [ 156.381980] === lock_sock_nested can sleep, its BH counterpart doesn't. selinux_netlbl_inode_permission() probably needs to use the BH counterpart unconditionally. But I am not sure if that function is always called from an atomic context. Assuming it is, the attached patch should fix this. Compile tested. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> Parag --- linux-2.6/security/selinux/ss/services.c.orig 2006-12-24 18:52:42.0 -0500 +++ linux-2.6/security/selinux/ss/services.c2006-12-24 19:00:22.0 -0500 @@ -2660,9 +2660,9 @@ rcu_read_unlock(); return 0; } - lock_sock(sock->sk); + bh_lock_sock_nested(sock->sk); rc = selinux_netlbl_socket_setsid(sock, sksec->sid); - release_sock(sock->sk); + bh_unlock_sock(sock->sk); rcu_read_unlock(); return rc;
Re: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
On Mon, 25 Dec 2006 05:21:24 +0800 "Adam J. Richter" <[EMAIL PROTECTED]> wrote: > Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint > for several network programs running on my system: > > [ 156.381868] BUG: sleeping function called from invalid context at > net/core/sock.c:1523 > [ 156.381876] in_atomic():1, irqs_disabled():0 > [ 156.381881] no locks held by kio_http/9693. > [ 156.381886] [] show_trace_log_lvl+0x1a/0x2f > [ 156.381900] [] show_trace+0x12/0x14 > [ 156.381908] [] dump_stack+0x16/0x18 > [ 156.381917] [] __might_sleep+0xe5/0xeb > [ 156.381926] [] lock_sock_nested+0x1d/0xc4 > [ 156.381937] [] selinux_netlbl_inode_permission+0x5a/0x8e > [ 156.381946] [] selinux_file_permission+0x96/0x9b > [ 156.381954] [] vfs_write+0x8d/0x167 > [ 156.381962] [] sys_write+0x3f/0x63 > [ 156.381971] [] syscall_call+0x7/0xb > [ 156.381980] === > There's a glaring bug in selinux_netlbl_inode_permission() - taking lock_sock() inside rcu_read_lock(). I would again draw attention to Documentation/SubmitChecklist. In particular please always always always enable all kernel debugging options when developing and testing new kernel code. And everything else in that file, too. - 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: Binary Drivers
Rok Markovic <[EMAIL PROTECTED]> wrote: > It seems that debate around cars and drivers has gone too far (IMHO). Ditto. > I > do not think that there is a question if we have any right to demand > details about hardware from manufactorers -> we are NOT. OK. > But I think that > we have right to know how to use it. The card is designed for use with /Windows/, you get a /Windows/ driver. That your PC is able to also run, say, Plan 9, is not the manufacturer's business at all, it is /your/ choice, and /your/ problem if what the manufacturer provides doesn't help you there. The manufacturer is keeping his part of the deal. You don't like the deal, tough luck. > I will translate this to CAR > language - We have to know how to drive the car but not all the details > how is this done, so we can drive a car without the "driver". We do not > need an exact knowledge about engine, ECU, suspension,... Exactly. > Now the real question: > > Why are manufatorers afraid to give us this information? Not "afraid". It is more expensive to them: - Because they would have to pick developer's brains and write it down, make sure it is complete, check it for publishing, etc. That costs money (and ties up key developers, and...) for /very/ little gain (open source systems is something like a 5 to 10% of all systems, mostly servers where highest performance isn't asked for, so the market for current high-end cards (where the brains are there at all for picking) is /extremely/ small). - Because they would have to get permission to do so from third parties, that means paying real money for little gain - Because sometimes it is just "we tried several combinations, this one(s) happen to work, dunno why". How do you write something like that down? - Because wrong settings might break the hardware, people fiddling around would then want a replacement, a very real cost - Because you can't write any software at all without violating some patent. In this area, it is probable that everybody is violating everybody else's patents, and making that easy to find out (via source code or specs) opens you up to lawsuits. Lawyers (and common sense) will tell yo not to go there unless it is very worthwhile. And it isn't (see above) - See the bletcherous workarounds for many device bugs (or downright design braindamage) in the in-kernel drivers. They might be just embarrased by the junk they shove out the door (We all know it happens with software, right? Hardware is much the same...). And they can't just work a year or so longer to get them ironed out, by then they could be right out of business. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi!
> > > I got this nasty oops while playing with debugger. Not sure if that is
> > > related; it also might be something with bluetooth; I already know it
> > > corrupts memory during suspend, perhaps it corrupts memory in some
> > > error path?
> >
> > Okay, I spoke too soon. bluetooth & suspend memory corruption was
> > _way_ harder to reproduce than expected. Took me 5-or-so-suspend
> > cycles... so it is probably unrelated to the previous crash.
>
> can you try to reproduce this with 2.6.20-rc2 as well.
(reproduced in another mail).
_urb_queue_tail(__pending_q(husb, _urb->type), _urb);
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err) {
BT_ERR("%s tx submit failed urb %p type %d err %d",
husb->hdev->name, urb, _urb->type, err);
_urb_unlink(_urb);
~~
Do we need to remove urb from pending_q here?
_urb_queue_tail(__completed_q(husb, _urb->type), _urb);
} else
atomic_inc(__pending_tx(husb, _urb->type));
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
On Sun 2006-12-24 15:39:23, Marcel Holtmann wrote: > Hi Pavel, > > > > I got this nasty oops while playing with debugger. Not sure if that is > > > related; it also might be something with bluetooth; I already know it > > > corrupts memory during suspend, perhaps it corrupts memory in some > > > error path? > > > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > > cycles... so it is probably unrelated to the previous crash. > > can you try to reproduce this with 2.6.20-rc2 as well. Yep, here it is, reproduced on 6-th-or-so suspend. bluetooth may need to be actively used in order for this to trigger; connecting to the net over my cellphone seems to work okay. (Full logs in attachment). Pavel Linux version 2.6.20-rc2 ([EMAIL PROTECTED]) (gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)) #383 SMP Fri Dec 22 11:30:05 CET 2006 ... system 00:00: resuming pnp 00:01: resuming system 00:02: resuming pnp 00:03: resuming pnp 00:04: resuming pnp 00:05: resuming pnp 00:06: resuming pnp 00:07: resuming i8042 kbd 00:08: resuming pnp: Device 00:08 does not support activation. i8042 aux 00:09: resuming pnp: Device 00:09 does not support activation. pnp 00:0a: resuming pnp 00:0b: resuming platform bluetooth: resuming pcspkr pcspkr: resuming vesafb vesafb.0: resuming serial8250 serial8250: resuming usb usb1: resuming usb usb3: resuming ata2: SATA link down (SStatus 0 SControl 0) ata3: SATA link down (SStatus 0 SControl 0) ata4: SATA link down (SStatus 0 SControl 0) hub 1-0:1.0: resuming hub 3-0:1.0: resuming i8042 i8042: resuming atkbd serio0: resuming psmouse serio1: resuming usb usb4: resuming usb usb5: resuming hub 4-0:1.0: resuming hub 5-0:1.0: resuming usb usb2: resuming hub 2-0:1.0: resuming mmcblk mmc0:cc53: resuming sd 0:0:0:0: resuming usb 3-2: resuming usbdev3.8_ep00: PM: resume from 0, parent 3-2 still 2 usb 3-2:1.0: PM: resume from 2, parent 3-2 still 2 usb 3-2:1.0: resuming usbdev3.8_ep81: PM: resume from 0, parent 3-2:1.0 still 2 usbdev3.8_ep02: PM: resume from 0, parent 3-2:1.0 still 2 usbdev3.8_ep83: PM: resume from 0, parent 3-2:1.0 still 2 usb 3-1: resuming usbdev3.9_ep00: PM: resume from 0, parent 3-1 still 2 hci_usb 3-1:1.0: PM: resume from 2, parent 3-1 still 2 hci_usb 3-1:1.0: resuming hci0: PM: resume from 0, parent 3-1:1.0 still 2 usbdev3.9_ep81: PM: resume from 0, parent 3-1:1.0 still 2 usbdev3.9_ep82: PM: resume from 0, parent 3-1:1.0 still 2 usbdev3.9_ep02: PM: resume from 0, parent 3-1:1.0 still 2 hci_usb 3-1:1.1: PM: resume from 2, parent 3-1 still 2 hci_usb 3-1:1.1: resuming usbdev3.9_ep83: PM: resume from 0, parent 3-1:1.1 still 2 usbdev3.9_ep03: PM: resume from 0, parent 3-1:1.1 still 2 usb 3-1:1.2: PM: resume from 2, parent 3-1 still 2 usb 3-1:1.2: resuming usbdev3.9_ep84: PM: resume from 0, parent 3-1:1.2 still 2 usbdev3.9_ep04: PM: resume from 0, parent 3-1:1.2 still 2 usb 3-1:1.3: PM: resume from 2, parent 3-1 still 2 usb 3-1:1.3: resuming Restarting tasks ... <3>__tx_submit: hci0 tx submit failed urb f765d1bc type 2 err -19 usb 3-1: USB disconnect, address 9 PM: Removing info for No Bus:usbdev3.9_ep81 PM: Removing info for No Bus:usbdev3.9_ep82 PM: Removing info for No Bus:usbdev3.9_ep02 slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten [] cache_free_debugcheck+0x128/0x1d0 [] hci_usb_close+0xf3/0x160 [] kfree+0x50/0xa0 [] hci_usb_close+0xf3/0x160 [] hci_usb_disconnect+0x2e/0x90 [] usb_disable_interface+0x53/0x70 [] usb_unbind_interface+0x38/0x80 [] __device_release_driver+0x68/0xb0 [] device_release_driver+0x1e/0x40 [] bus_remove_device+0x8b/0xa0 [] device_del+0x159/0x1c0 [] usb_disable_device+0x4d/0x100 [] usb_disconnect+0x9a/0x110 [] hub_thread+0x355/0xbd0 [] schedule+0x2de/0x8f0 [] autoremove_wake_function+0x0/0x50 [] hub_thread+0x0/0xbd0 [] kthread+0xec/0xf0 [] kthread+0x0/0xf0 [] kernel_thread_helper+0x7/0x10 === f70a2720: redzone 1:0x5a5a5a5a, redzone 2:0xc0545e9e. [ cut here ] kernel BUG at mm/slab.c:2878! invalid opcode: [#1] SMP Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010012 (2.6.20-rc2 #383) EIP is at cache_free_debugcheck+0x1b2/0x1d0 eax: f70a271c ebx: f70a20f8 ecx: 00052c00 edx: 020c esi: c20df680 edi: f70a2720 ebp: 5a5a5a5a esp: c2313e30 ds: 007b es: 007b ss: 0068 Process khubd (pid: 304, ti=c2312000 task=c2257030 task.ti=c2312000) Stack: c06aedf0 f70a2720 5a5a5a5a c0545e9e c04b08d3 f70a20c0 c20df680 c20d9164 f70a2724 0286 c016b610 f653e8d8 f653e8c4 c2134ba0 000c c04b08d3 c2134b5c c2134b8c f62e0a54 c2134ad0 0001 c2134ad0 f62e0a54 c07dbee0 Call Trace: [] sock_alloc_send_skb+0x16e/0x1c0 [] hci_usb_close+0xf3/0x160 [] kfree+0x50/0xa0 [] hci_usb_close+0xf3/0x160 [] hci_usb_disconnect+0x2e/0x90 []
Re: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi! > > PM: Removing info for No Bus:usbdev3.15_ep81 > > PM: Removing info for No Bus:usbdev3.15_ep82 > > PM: Removing info for No Bus:usbdev3.15_ep02 > > slab error in verify_redzone_free(): cache `size-512': memory outside > > object was overwritten > > [] cache_free_debugcheck+0x128/0x1d0 > > [] hci_usb_close+0xf3/0x160 > > [] kfree+0x50/0xa0 > > [] hci_usb_close+0xf3/0x160 > > [] hci_usb_disconnect+0x2e/0x90 > > [] usb_disable_interface+0x53/0x70 > > [] usb_unbind_interface+0x38/0x80 > > [] __device_release_driver+0x68/0xb0 > > [] device_release_driver+0x1e/0x40 > > [] bus_remove_device+0x8b/0xa0 > > [] device_del+0x159/0x1c0 > > [] usb_disable_device+0x4d/0x100 > > [] usb_disconnect+0x9a/0x110 > > [] hub_thread+0x355/0xbd0 > > [] schedule+0x2de/0x8f0 > > [] autoremove_wake_function+0x0/0x50 > > [] hub_thread+0x0/0xbd0 > > [] kthread+0xec/0xf0 > > [] kthread+0x0/0xf0 > > [] kernel_thread_helper+0x7/0x10 > > === > > yes, this one looks like memory scribblage in bluetooth. The > buffer.c assertion failure should now be fixed, please verify. I can confirm buffer.c assertion to be fixed (yes, I was using gdb at that time). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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] romsignature/checksum cleanup
Hi Andrew.
Use adding __init to romsignature() (it's only called from probe_roms()
which is itself __init) as an excuse to submit a pedantic cleanup.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/e820.c b/arch/i386/kernel/e820.c
index f391abc..2565fac 100644
--- a/arch/i386/kernel/e820.c
+++ b/arch/i386/kernel/e820.c
@@ -156,21 +156,22 @@ static struct resource standard_io_resou
.flags = IORESOURCE_BUSY | IORESOURCE_IO
} };
-static int romsignature(const unsigned char *x)
+#define ROMSIGNATURE 0xaa55
+
+static int __init romsignature(const unsigned char *rom)
{
unsigned short sig;
- int ret = 0;
- if (probe_kernel_address((const unsigned short *)x, sig) == 0)
- ret = (sig == 0xaa55);
- return ret;
+
+ return probe_kernel_address((const unsigned short *)rom, sig) == 0 &&
+ sig == ROMSIGNATURE;
}
static int __init romchecksum(unsigned char *rom, unsigned long length)
{
- unsigned char *p, sum = 0;
+ unsigned char sum;
- for (p = rom; p < rom + length; p++)
- sum += *p;
+ for (sum = 0; length; length--)
+ sum += *rom++;
return sum == 0;
}
Re: Linux 2.6.20-rc2: forgot how to make a zImage on powerpc?
Linus Torvalds wrote: (much of the latter syntactic cleanups). And arm and powerpc updates. Hmm. I'm trying to build 2.6.20-rc2 on a little powerpc box with arch/powerpc/configs/linkstation_defconfig, and I get: [EMAIL PROTECTED] /usr/src/linux $ make zImage HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o [snip lots of buildspam] LD lib/zlib_deflate/built-in.o LD lib/zlib_inflate/built-in.o GEN .version LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map MODPOST vmlinux ln: accessing `arch/powerpc/boot/zImage': No such file or directory make[1]: *** [arch/powerpc/boot/zImage] Error 1 make: *** [zImage] Error 2 So, uh, are we forgetting to go into the right subdirectory to make the actual zImage, or what? If I'm just doing something wrong, I'd love to know what it is. I'll follow up here on lkml if I diagnose this further. Thanks, Mark - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-24 11:35]: > And if this doesn't fix it, I don't know what will.. Sorry, but it still fails (on top of plain 2.6.19). -- Martin Michlmayr http://www.cyrius.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: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
> Quoting Linus Torvalds <[EMAIL PROTECTED]>: > Subject: Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content > corruption on ext3) > > Peter, tell me I'm crazy, but with the new rules, the following condition > is a bug: > > - shared mapping > - writable > - not already marked dirty in the PTE > > because that combination means that the hardware can mark the PTE dirty > without us even realizing (and thus not marking the "struct page *" > dirty). Er. Sorry about bumping in, and I'm not sure I understand all of the discussion, but this reminded me of an old issue with COW that created what looks like a vaguely similiar data corruption on infiniband. We solved this for infiniband with MADV_DONTFORK, but I always wondered why does it not affect other parts of kernel. Small reminder from that discussion: down mmap sem get user pages up mmap sem page becomes shared, and COW (e.g. fork) process writes to first byte of page <- gets a copy Now we had a problem: struct page that we got from get user pages does not point to a correct page in our process. For example: if at some point we map this page for DMA, and hardware writes to last byte of page -> process does not see this data. So for infiniband, what we do is a combination of - prevent page from becoming COW while hardware might DMA to this page, and - ask users not to write to page if hardware might DMA to same page (even if its using different bytes). I just wandered - is there some chance something like this could be happening in the fs code? HTH, -- MST - 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: ACPI EC warnings
24 Ara 2006 Paz 23:19 tarihinde, Guillaume Chazarain şunları yazmıştı: > > Patch looks nice, > > But LKML didn't like gmail's HTML so here is it again. Hopefully this > one will pass. I think this one didn't pass either :-/ > > btw do you notice any skippy behaviour? i.e sound skips when > > I get this warning > > No, in my case I just get the message: ACPI: EC: evaluating _Q20 > > > or something else is broken and I blame ACPI because its > > flooding dmesg =) > > I happen to have at the moment some other debugging printk, flooding > my logs, and sound doesn't skip either :-) Asus V6VA - Pentium-M 2GHz here. Yeah the warning seems unrelated to skips. Regards, ismail -- 2 + 2 = 5 for very large values of 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/
selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint for several network programs running on my system: [ 156.381868] BUG: sleeping function called from invalid context at net/core/sock.c:1523 [ 156.381876] in_atomic():1, irqs_disabled():0 [ 156.381881] no locks held by kio_http/9693. [ 156.381886] [] show_trace_log_lvl+0x1a/0x2f [ 156.381900] [] show_trace+0x12/0x14 [ 156.381908] [] dump_stack+0x16/0x18 [ 156.381917] [] __might_sleep+0xe5/0xeb [ 156.381926] [] lock_sock_nested+0x1d/0xc4 [ 156.381937] [] selinux_netlbl_inode_permission+0x5a/0x8e [ 156.381946] [] selinux_file_permission+0x96/0x9b [ 156.381954] [] vfs_write+0x8d/0x167 [ 156.381962] [] sys_write+0x3f/0x63 [ 156.381971] [] syscall_call+0x7/0xb [ 156.381980] === I have 35 of these messages is my console log at the moment. The only difference that I've noticed between the messages is that they are for variety of processes: most for tor, xntpd, sendmail, procmail. The processes get to this point by sys_write, sys_send, or sys_sendto (procmail was doing a sys_sendto, so it was also doing something related to networking, even though it is not a program one normally would think of as doing any networking system calls). My system seems to work OK even with these warning messages. I can debug it futher. I just figure I should report it now, because I may have done everyone a disservice by putting off reporting it in rc1 in the hopes of finding time to debug it. Adam Richter - 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: ACPI EC warnings
Patch looks nice, But LKML didn't like gmail's HTML so here is it again. Hopefully this one will pass. btw do you notice any skippy behaviour? i.e sound skips when I get this warning No, in my case I just get the message: ACPI: EC: evaluating _Q20 or something else is broken and I blame ACPI because its flooding dmesg =) I happen to have at the moment some other debugging printk, flooding my logs, and sound doesn't skip either :-) Asus V6VA - Pentium-M 2GHz here. -- Guillaume diff -r ef50bfb54157 drivers/acpi/ec.c --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -424,7 +424,7 @@ static void acpi_ec_gpe_query(void *ec_c snprintf(object_name, 8, "_Q%2.2X", value); - printk(KERN_INFO PREFIX "evaluating %s\n", object_name); + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluating %s", object_name)); acpi_evaluate_object(ec->handle, object_name, NULL, NULL); }
Re: ACPI EC warnings
24 Ara 2006 Paz 23:02 tarihinde, Guillaume Chazarain şunları yazmıştı: > 2006/12/24, Ismail Donmez <[EMAIL PROTECTED]>: > > ACPI: EC: evaluating _Q60 > > Same thing here, I think it is caused by > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm >it;h=af3fd1404fd4f0f58ebbb52b22be4f1ca0794cda > > The attached patch restores the previous behaviour. Patch looks nice, btw do you notice any skippy behaviour? i.e sound skips when I get this warning or something else is broken and I blame ACPI because its flooding dmesg =) Regards, ismail -- 2 + 2 = 5 for very large values of 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: [patch 1/4] Add
On Dec 24 2006 12:22, Zack Weinberg wrote:
>===
>--- linux-2.6.orig/fs/proc/kmsg.c 2006-12-23 08:55:17.0 -0800
>+++ linux-2.6/fs/proc/kmsg.c 2006-12-24 11:43:14.0 -0800
>@@ -11,6 +11,7 @@
> #include
> #include
> #include
>+#include
>
> #include
> #include
>@@ -21,27 +22,28 @@
>
> static int kmsg_open(struct inode * inode, struct file * file)
> {
>- return do_syslog(1,NULL,0);
>+ return do_syslog(KLOG_OPEN, NULL, 0);
> }
>
> static int kmsg_release(struct inode * inode, struct file * file)
> {
>- (void) do_syslog(0,NULL,0);
>+ (void) do_syslog(KLOG_CLOSE, NULL, 0);
^^
I bet you can get rid of that in the process.
-`J'
--
-
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: Binary Drivers
It seems that debate around cars and drivers has gone too far (IMHO). I do not think that there is a question if we have any right to demand details about hardware from manufactorers -> we are NOT. But I think that we have right to know how to use it. I will translate this to CAR language - We have to know how to drive the car but not all the details how is this done, so we can drive a car without the "driver". We do not need an exact knowledge about engine, ECU, suspension,... Now the real question: Why are manufatorers afraid to give us this information? and Who can benefit from this? Let's that our manufactorer is not bound on licenced part of hardware. If we would know the answers on those questions we could start thinking how can we convince Them to give us information we need to develop our own drivers. Cheers Rok Markovic - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On 12/24/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: Ok, so how about this diff. I'm actually feeling good about this one. It really looks like "do_no_page()" was simply buggy, and that this explains everything. I tested with just this patch and 2.6.19 and no change. Sorry Linus, no early Christmas present :-( Gordon -- Gordon Farquharson - 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/4] Add
This patch introduces with symbolic constants for the
various sys_syslog() opcodes, and changes all in-kernel references to
those opcodes to use the constants. The header is added to the set of
user/kernel interface headers.
zw
Index: linux-2.6/include/linux/Kbuild
===
--- linux-2.6.orig/include/linux/Kbuild 2006-12-23 08:56:15.0 -0800
+++ linux-2.6/include/linux/Kbuild 2006-12-24 11:43:14.0 -0800
@@ -100,6 +100,7 @@
header-y += ixjuser.h
header-y += jffs2.h
header-y += keyctl.h
+header-y += klog.h
header-y += limits.h
header-y += lock_dlm_plock.h
header-y += magic.h
Index: linux-2.6/include/linux/klog.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6/include/linux/klog.h 2006-12-24 11:43:14.0 -0800
@@ -0,0 +1,28 @@
+#ifndef _LINUX_KLOG_H
+#define _LINUX_KLOG_H
+
+/*
+ * Constants for the first argument to the syslog() system call
+ * (aka klogctl()). These numbers are part of the user space ABI!
+ */
+enum {
+ KLOG_CLOSE = 0, /* close log */
+ KLOG_OPEN= 1, /* open log */
+ KLOG_READ= 2, /* read from log (klogd) */
+
+ KLOG_READ_HIST = 3, /* read history of log messages (dmesg) */
+ KLOG_READ_CLEAR_HIST = 4, /* read and clear history */
+ KLOG_CLEAR_HIST = 5, /* just clear history */
+
+ KLOG_DISABLE_CONSOLE = 6, /* disable printk to console */
+ KLOG_ENABLE_CONSOLE = 7, /* enable printk to console */
+ KLOG_SET_CONSOLE_LVL = 8, /* set minimum severity of messages to be
+ * printed to console */
+
+ KLOG_GET_UNREAD = 9, /* return number of unread characters */
+ KLOG_GET_SIZE= 10, /* return size of log buffer */
+
+ KLOG_OPCODE_MAX
+};
+
+#endif /* klog.h */
Index: linux-2.6/kernel/printk.c
===
--- linux-2.6.orig/kernel/printk.c 2006-12-23 08:56:15.0 -0800
+++ linux-2.6/kernel/printk.c 2006-12-24 11:43:14.0 -0800
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
@@ -163,20 +164,21 @@
__setup("log_buf_len=", log_buf_len_setup);
-/*
- * Commands to do_syslog:
+/**
+ * do_syslog - operate on the log of kernel messages
+ * @type: operation to perform
+ * @buf: user-space buffer to copy data into
+ * @len: number of bytes of space available at @buf
+ *
+ * See include/linux/klog.h for the command numbers passed as @type.
+ * The @buf and @len parameters are used with the above meanings for
+ * @type values %KLOG_READ, %KLOG_READ_HIST and %KLOG_READ_CLEAR_HIST.
+ * @len is reused with a different meaning, and @buf ignored, for
+ * %KLOG_SET_CONSOLE_LVL. Both @buf and @len are ignored for all
+ * other @type values.
*
- * 0 -- Close the log. Currently a NOP.
- * 1 -- Open the log. Currently a NOP.
- * 2 -- Read from the log.
- * 3 -- Read all messages remaining in the ring buffer.
- * 4 -- Read and clear all messages remaining in the ring buffer
- * 5 -- Clear ring buffer.
- * 6 -- Disable printk's to console
- * 7 -- Enable printk's to console
- * 8 -- Set level of messages printed to console
- * 9 -- Return number of unread characters in the log buffer
- * 10 -- Return size of the log buffer
+ * On failure, returns a negative errno code. On success, returns a
+ * nonnegative integer whose meaning depends on @type.
*/
int do_syslog(int type, char __user *buf, int len)
{
@@ -190,11 +192,11 @@
return error;
switch (type) {
- case 0: /* Close log */
+ case KLOG_CLOSE:
break;
- case 1: /* Open log */
+ case KLOG_OPEN:
break;
- case 2: /* Read from log */
+ case KLOG_READ:
error = -EINVAL;
if (!buf || len < 0)
goto out;
@@ -225,10 +227,10 @@
if (!error)
error = i;
break;
- case 4: /* Read/clear last kernel messages */
+ case KLOG_READ_CLEAR_HIST:
do_clear = 1;
/* FALL THRU */
- case 3: /* Read last kernel messages */
+ case KLOG_READ_HIST:
error = -EINVAL;
if (!buf || len < 0)
goto out;
@@ -281,16 +283,16 @@
}
}
break;
- case 5: /* Clear ring buffer */
+ case KLOG_CLEAR_HIST:
logged_chars = 0;
break;
- case 6: /* Disable logging to console */
+ case KLOG_DISABLE_CONSOLE:
console_loglevel = minimum_console_loglevel;
break;
- case 7: /* Enable logging to console
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 2006-12-24 at 12:24 -0800, Linus Torvalds wrote: > > On Sun, 24 Dec 2006, Andrei Popa wrote: > > > > Hash check on download completion found bad chunks, consider using > > "safe_sync". > > Dang. Did you get any warning messages from the kernel? > only these: ACPI: EC: evaluating _Q80 ACPI: EC: evaluating _Q80 ACPI: EC: evaluating _Q80 but I don't think has anything to do with... > Linus - 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 0/4] /proc/kmsg permissions, take four
Here's yet another revision of the /proc/kmsg permissions patch series. To recap, the point is to allow klogd to drop privileges and continue reading from /proc/kmsg (currently, even if klogd has a legitimately opened fd on /proc/kmsg, it cannot read from it unless it has CAP_SYS_ADMIN asserted). SELinux's pickier and finer-grained privilege rules for /proc/kmsg are unchanged. There are two significant changes from the previous revision. First, in keeping with the recommended style, I have eliminated the security_syslog_or_fail() macro. Instead there is a static array mapping KLOG_* opcodes to LSM_KLOG_* privilege classes. This requires slightly different coding in the security hooks but I think it's clearer overall. Second, I've incorporated Vincent Legoll's kerneldoc comment for sys_syslog (nee do_syslog) with some wording improvements and expansion to cover the klog_* functions introduced part-way through the patch. I don't think proc/kmsg.c needs kerneldoc, it's very simple after this patch series. I've been through Documentation/CodingStyle and satisfied myself that everything is now in the proper mode. I don't suppose anyone has comments on the *content* of the changes...? zw - 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 3/4] Refactor do_syslog interface
This patch breaks out the read operations in do_syslog() into their
own functions (klog_read, klog_readhist) and adds a klog_poll.
klog_read grows the ability to do a nonblocking read, which I expose
in the sys_syslog interface because there doesn't seem to be any
reason not to. do_syslog itself is folded into sys_syslog. The
security checks remain there, not in the subfunctions. I've added
kerneldoc comments for all the new functions in printk.c. The control
flow in sys_syslog is different in style but not in substance -- I
like direct returns rather than setting a local variable and returning
at the end; it lets me put a BUG() after the switch statement to catch
missed cases. [gcc4 at least can optimize it out when there aren't
any.]
kmsg.c is then changed to use those functions instead of calling
do_syslog and/or poll_wait itself.. This entails that it must call
security_syslog as appropriate itself. In this patch I preserve the
security checks exactly as they were after the changes in the "map
permissions" patch (i.e. kmsg_close() doesn't do a permission check).
Finally, I fixed some minor bugs. Error and partial read handling in
klog_read/klog_readhist were slightly off: if __put_user returns an
error, that character should not be consumed from the kernel buffer;
if it returns an error after some characters have already been copied
successfully, the read operation should return the count of
already-copied characters, not the error code; if less than the entire
buffer is read with KLOG_READ_CLEAR_HIST, we should only clear the
part that was successfully read. Seeking on /proc/kmsg has never been
meaningful, so kmsg_open() should call nonseekable_open() to enforce
that.
proc/kmsg.c declares the kernel/printk.c interfaces itself, instead of
getting them from klog.h which people want to be purely userspace-
visible constants. kmsg.c has always had private declarations of
printk.c functions (before, there were declarations of do_syslog and a
wait queue there); as it is unlikely that more users of these
functions will appear, I think this will do fine. (It might be
reasonable to put declarations in console.h.)
It was possible to prune down the set of headers included by kmsg.c
quite substantially.
zw
Index: linux-2.6/fs/proc/kmsg.c
===
--- linux-2.6.orig/fs/proc/kmsg.c 2006-12-24 11:43:14.0 -0800
+++ linux-2.6/fs/proc/kmsg.c2006-12-24 11:43:18.0 -0800
@@ -5,47 +5,42 @@
*
*/
-#include
-#include
-#include
-#include
-#include
#include
-#include
-
-#include
-#include
-
-extern wait_queue_head_t log_wait;
+#include
+#include
-extern int do_syslog(int type, char __user *bug, int count);
+/* interfaces from kernel/printk.c */
+extern int klog_read(char __user *, int, int);
+extern unsigned int klog_poll(struct file *, poll_table *);
static int kmsg_open(struct inode * inode, struct file * file)
{
- return do_syslog(KLOG_OPEN, NULL, 0);
+ int error = security_syslog(LSM_KLOG_READ);
+ if (error)
+ return error;
+ return nonseekable_open(inode, file);
}
static int kmsg_release(struct inode * inode, struct file * file)
{
- (void) do_syslog(KLOG_CLOSE, NULL, 0);
return 0;
}
static ssize_t kmsg_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
- if ((file->f_flags & O_NONBLOCK)
- && !do_syslog(KLOG_GET_UNREAD, NULL, 0))
- return -EAGAIN;
- return do_syslog(KLOG_READ, buf, count);
+ int error = security_syslog(LSM_KLOG_READ);
+ if (error)
+ return error;
+ return klog_read(buf, count, !(file->f_flags & O_NONBLOCK));
}
static unsigned int kmsg_poll(struct file *file, poll_table *wait)
{
- poll_wait(file, _wait, wait);
- if (do_syslog(KLOG_GET_UNREAD, NULL, 0))
- return POLLIN | POLLRDNORM;
- return 0;
+ int error = security_syslog(LSM_KLOG_READ);
+ if (error)
+ return error;
+ return klog_poll(file, wait);
}
Index: linux-2.6/include/linux/klog.h
===
--- linux-2.6.orig/include/linux/klog.h 2006-12-24 11:43:14.0 -0800
+++ linux-2.6/include/linux/klog.h 2006-12-24 11:43:18.0 -0800
@@ -21,6 +21,8 @@
KLOG_GET_UNREAD = 9, /* return number of unread characters */
KLOG_GET_SIZE= 10, /* return size of log buffer */
+ KLOG_READ_NONBLOCK = 11, /* read from log, don't block if empty
+ * -- new in 2.6.20 */
KLOG_OPCODE_MAX
};
Index: linux-2.6/kernel/printk.c
===
--- linux-2.6.orig/kernel/printk.c 2006-12-24 11:43:16.0 -0800
+++ linux-2.6/kernel/printk.c 2006-12-24 11:43:18.0 -0800
@@ -33,6 +33,7 @@
#include
[patch 4/4] Distinguish /proc/kmsg access from sys_syslog
Finally, add a new security class for access to /proc/kmsg, distinct
from the class used for the "read current messages" operations on
sys_syslog. The dummy and capability modules permit access to
/proc/kmsg to any user (who has somehow acquired an open fd on it);
SELinux is unchanged. This accomplishes what I was trying to do in
the first place, i.e. enable running klogd unprivileged without a root
shim, in a non-SELinux installation. Please remember that the
default DAC permissions for /proc/kmsg restrict it to root, so unless
you chmod it in your installation or modify klogd to open the file and
then drop privs, the actual restrictions are unchanged.
zw
Index: linux-2.6/fs/proc/kmsg.c
===
--- linux-2.6.orig/fs/proc/kmsg.c 2006-12-24 11:43:18.0 -0800
+++ linux-2.6/fs/proc/kmsg.c2006-12-24 11:43:19.0 -0800
@@ -15,7 +15,7 @@
static int kmsg_open(struct inode * inode, struct file * file)
{
- int error = security_syslog(LSM_KLOG_READ);
+ int error = security_syslog(LSM_KLOG_READ_PROC);
if (error)
return error;
return nonseekable_open(inode, file);
@@ -29,7 +29,7 @@
static ssize_t kmsg_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
- int error = security_syslog(LSM_KLOG_READ);
+ int error = security_syslog(LSM_KLOG_READ_PROC);
if (error)
return error;
return klog_read(buf, count, !(file->f_flags & O_NONBLOCK));
@@ -37,7 +37,7 @@
static unsigned int kmsg_poll(struct file *file, poll_table *wait)
{
- int error = security_syslog(LSM_KLOG_READ);
+ int error = security_syslog(LSM_KLOG_READ_PROC);
if (error)
return error;
return klog_poll(file, wait);
Index: linux-2.6/security/commoncap.c
===
--- linux-2.6.orig/security/commoncap.c 2006-12-24 11:43:16.0 -0800
+++ linux-2.6/security/commoncap.c 2006-12-24 11:43:19.0 -0800
@@ -311,7 +311,14 @@
int cap_syslog (int type)
{
- if ((type & ~LSM_KLOG_READHIST) && !capable(CAP_SYS_ADMIN))
+ /*
+* Reading history is allowed to any user, and so is reading
+* current messages via /proc/kmsg (by default that file is
+* only readable by root, but root is allowed to change that,
+* or open it and hand the fd to an unprivileged process).
+*/
+ if ((type & ~(LSM_KLOG_READHIST|LSM_KLOG_READ_PROC))
+ && !capable(CAP_SYS_ADMIN))
return -EPERM;
return 0;
}
Index: linux-2.6/security/selinux/hooks.c
===
--- linux-2.6.orig/security/selinux/hooks.c 2006-12-24 11:43:16.0
-0800
+++ linux-2.6/security/selinux/hooks.c 2006-12-24 11:43:19.0 -0800
@@ -1505,14 +1505,20 @@
int rc;
/* if there are any codes we don't know about, there's a bug */
- BUG_ON(type & ~(LSM_KLOG_READ|LSM_KLOG_READHIST
+ BUG_ON(type & ~(LSM_KLOG_READ|LSM_KLOG_READ_PROC|LSM_KLOG_READHIST
|LSM_KLOG_CLEARHIST|LSM_KLOG_CONSOLE));
rc = secondary_ops->syslog(type);
if (rc)
return rc;
- if (type & (LSM_KLOG_READ|LSM_KLOG_CLEARHIST))
+ /*
+* N.B. Unlike the default security model, with
+* SELinux active you have to have SYSTEM__SYSLOG_MOD
+* privilege to read current messages either with the
+* system call or from /proc/kmsg.
+*/
+ if (type & (LSM_KLOG_READ|LSM_KLOG_READ_PROC|LSM_KLOG_CLEARHIST))
rc = task_has_system(current, SYSTEM__SYSLOG_MOD);
if (rc)
return rc;
Index: linux-2.6/include/linux/security.h
===
--- linux-2.6.orig/include/linux/security.h 2006-12-24 11:43:16.0
-0800
+++ linux-2.6/include/linux/security.h 2006-12-24 11:43:19.0 -0800
@@ -97,6 +97,8 @@
#define LSM_KLOG_READHIST 2 /* read message history (dmesg) */
#define LSM_KLOG_CLEARHIST 4 /* clear message history (dmesg -c) */
#define LSM_KLOG_CONSOLE 8 /* set or query console log level */
+#define LSM_KLOG_READ_PROC 16 /* read current messages, but from /proc/kmsg
+rather than the system call */
/* forward declares to avoid warnings */
struct nfsctl_arg;
Index: linux-2.6/security/dummy.c
===
--- linux-2.6.orig/security/dummy.c 2006-12-24 11:43:16.0 -0800
+++ linux-2.6/security/dummy.c 2006-12-24 11:43:19.0 -0800
@@ -96,7 +96,13 @@
static int dummy_syslog (int type)
{
- if ((type & ~LSM_KLOG_READHIST) && current->euid)
+ /*
+* Reading history is allowed to any user, and so is reading
+*
[patch 2/4] permission mapping for sys_syslog operations
As suggested by Stephen Smalley: map the various sys_syslog operations
to a smaller set of privilege codes before calling security modules.
This patch changes the security module interface! There should be no
change in the actual security semantics enforced by dummy, capability,
nor SELinux (with one exception, clearly marked in sys_syslog).
The privilege codes are now in linux/security.h instead of
linux/klog.h, and use the LSM_* naming convention used for other such
constants in that file.
I'm now using a static table to map operations to privilege codes.
This makes it very easy to see the mapping as a whole, and prevents
security operations from cluttering up the body of do_syslog, but does
necessitate some checks to ensure that when new KLOG_* operations are
added, people don't forget to add entries to the table. If people are
not fans of the idiom I used, I will see about getting a feature added
to gcc to make it less ugly.
Note that after this patch, close() on /proc/kmsg and
sys_syslog(KLOG_CLOSE) do not do security checks; they always succeed.
(IMO close should never fail.) This was always in this patch series,
but used to be in a different stage.
zw
Index: linux-2.6/kernel/printk.c
===
--- linux-2.6.orig/kernel/printk.c 2006-12-24 11:43:14.0 -0800
+++ linux-2.6/kernel/printk.c 2006-12-24 11:43:16.0 -0800
@@ -164,6 +164,39 @@
__setup("log_buf_len=", log_buf_len_setup);
+/*
+ * This table maps KLOG_* operation codes to LSM_KLOG_* privilege classes.
+ * "unsigned char" is used just to keep it small.
+ */
+
+static const unsigned char klog_privclass[] = {
+ [KLOG_CLOSE] = 0, /* close always succeeds */
+ [KLOG_OPEN]= LSM_KLOG_READ,
+ [KLOG_READ]= LSM_KLOG_READ,
+ [KLOG_GET_UNREAD] = LSM_KLOG_READ,
+
+ [KLOG_READ_HIST] = LSM_KLOG_READHIST,
+ [KLOG_GET_SIZE]= LSM_KLOG_READHIST,
+ [KLOG_READ_CLEAR_HIST] = LSM_KLOG_READHIST|LSM_KLOG_CLEARHIST,
+ [KLOG_CLEAR_HIST] = LSM_KLOG_CLEARHIST,
+
+ [KLOG_DISABLE_CONSOLE] = LSM_KLOG_CONSOLE,
+ [KLOG_ENABLE_CONSOLE] = LSM_KLOG_CONSOLE,
+ [KLOG_SET_CONSOLE_LVL] = LSM_KLOG_CONSOLE,
+};
+
+/* It is essential that there be an entry in the above table for every
+ * KLOG_* code. The following, er, odd declarations cause compilation
+ * of this file to fail if that is not true. They do not correspond
+ * to real data objects.
+ */
+extern char klog_privclass_is_missing_an_entry[
+ ARRAY_SIZE(klog_privclass) < KLOG_OPCODE_MAX ? -1 : 1
+];
+extern char klog_privclass_has_too_many_entries[
+ ARRAY_SIZE(klog_privclass) > KLOG_OPCODE_MAX ? -1 : 1
+];
+
/**
* do_syslog - operate on the log of kernel messages
* @type: operation to perform
@@ -185,9 +218,11 @@
unsigned long i, j, limit, count;
int do_clear = 0;
char c;
- int error = 0;
+ int error;
- error = security_syslog(type);
+ if (type < 0 || type >= KLOG_OPCODE_MAX)
+ return -EINVAL;
+ error = security_syslog(klog_privclass[type]);
if (error)
return error;
Index: linux-2.6/security/commoncap.c
===
--- linux-2.6.orig/security/commoncap.c 2006-12-23 08:55:16.0 -0800
+++ linux-2.6/security/commoncap.c 2006-12-24 11:43:16.0 -0800
@@ -311,7 +311,7 @@
int cap_syslog (int type)
{
- if ((type != 3 && type != 10) && !capable(CAP_SYS_ADMIN))
+ if ((type & ~LSM_KLOG_READHIST) && !capable(CAP_SYS_ADMIN))
return -EPERM;
return 0;
}
Index: linux-2.6/security/dummy.c
===
--- linux-2.6.orig/security/dummy.c 2006-12-23 08:55:16.0 -0800
+++ linux-2.6/security/dummy.c 2006-12-24 11:43:16.0 -0800
@@ -96,7 +96,7 @@
static int dummy_syslog (int type)
{
- if ((type != 3 && type != 10) && current->euid)
+ if ((type & ~LSM_KLOG_READHIST) && current->euid)
return -EPERM;
return 0;
}
Index: linux-2.6/security/selinux/hooks.c
===
--- linux-2.6.orig/security/selinux/hooks.c 2006-12-23 08:55:16.0
-0800
+++ linux-2.6/security/selinux/hooks.c 2006-12-24 11:43:16.0 -0800
@@ -1504,29 +1504,27 @@
{
int rc;
+ /* if there are any codes we don't know about, there's a bug */
+ BUG_ON(type & ~(LSM_KLOG_READ|LSM_KLOG_READHIST
+ |LSM_KLOG_CLEARHIST|LSM_KLOG_CONSOLE));
+
rc = secondary_ops->syslog(type);
if (rc)
return rc;
- switch (type) {
- case 3: /* Read last kernel messages */
- case 10:/* Return size of the log buffer */
- rc =
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006, Andrei Popa wrote: > > Hash check on download completion found bad chunks, consider using > "safe_sync". Dang. Did you get any warning messages from the kernel? Linus - 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: Binary Drivers
David Schwartz <[EMAIL PROTECTED]> wrote: [...] > Now, let's try it another way: Are they allowed to sell a car that > incorporates a computer that uses a trade-secret algorithm for controlling > the fuel injection to get 20 more horsepower and 5% better mileage if it's > impossible to *start* the car without knowing that algorithm? It is done regularly. Current cars control the fuel injection etc via an onboard computer, without this control the engine just won't start. Did you get the specs for the exact fuel control algorithm with your car? Should you be able to fool around with that, thus violating emission control measures (this would damage not only you, but everybody)? Almost everything around you is controlled by a uP nowadays (it is much cheaper/preciser to control e.g. the washing machine that way than via the customary rotating wheels with notches). Did you get the specs for that? Can you get them? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 2006-12-24 at 11:35 -0800, Linus Torvalds wrote:
>
> On Sun, 24 Dec 2006, Gordon Farquharson wrote:
> >
> > The apt cache files (/var/cache/apt/*.bin) still get corrupted with
> > this patch and 2.6.19.
>
> Yeah, if my guess about do_no_page() is right, _none_ of the previous
> patches should have ANY effect what-so-ever. In fact, I'd say that even
> the "ext3 works in writeback mode" thing that Andrei reports is probably a
> total fluke brought on by timing changes rather than anything else.
>
> So please try the latest patch instead (on top of anything that shows
> corruption reliably - the patch should be _totally_ independent of all the
> other issues, and I think it will apply cleanly on top of 2.6.18.3 and
> 2.6.19 too, so anything that shows corruption is a fine target - but try
> to choose something that has been the "best" at corrupting things for you,
> to make the testing as good as possible).
>
> Patch included here again (although I think you were cc'd on my previous
> email too, so you should already have it, and our emails just crossed)
>
> And if this doesn't fix it, I don't know what will..
With latest git and patches:
http://lkml.org/lkml/diff/2006/12/24/56/1
http://lkml.org/lkml/diff/2006/12/24/61/1
Hash check on download completion found bad chunks, consider using
"safe_sync".
>
> Linus
>
> ---
> diff --git a/mm/memory.c b/mm/memory.c
> index 563792f..cf429c4 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2247,21 +2249,23 @@ retry:
> if (pte_none(*page_table)) {
> flush_icache_page(vma, new_page);
> entry = mk_pte(new_page, vma->vm_page_prot);
> - if (write_access)
> - entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> - set_pte_at(mm, address, page_table, entry);
> if (anon) {
> inc_mm_counter(mm, anon_rss);
> lru_cache_add_active(new_page);
> page_add_new_anon_rmap(new_page, vma, address);
> + if (write_access)
> + entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> } else {
> inc_mm_counter(mm, file_rss);
> page_add_file_rmap(new_page);
> + entry = pte_wrprotect(entry);
> if (write_access) {
> dirty_page = new_page;
> get_page(dirty_page);
> + entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> }
> }
> + set_pte_at(mm, address, page_table, entry);
> } else {
> /* One of our sibling threads was faster, back out. */
> page_cache_release(new_page);
-
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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sunday 24 December 2006 09:27, Pavel Machek wrote:
>
> perhaps printk('Binary only modules are not allowed by kernel license,
> but copyright law may still allow them in special cases. Be careful,
Come again?
> Greg is going tuo sue you at beggining of 2008 if you get it wrong.')
> would be acceptable way to educate people?
Since this message will be seen by an end-user who is likely does not
do any distribution he has nothing to fear from Greg ;)
--
Dmitry
-
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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006, Gordon Farquharson wrote:
>
> The apt cache files (/var/cache/apt/*.bin) still get corrupted with
> this patch and 2.6.19.
Yeah, if my guess about do_no_page() is right, _none_ of the previous
patches should have ANY effect what-so-ever. In fact, I'd say that even
the "ext3 works in writeback mode" thing that Andrei reports is probably a
total fluke brought on by timing changes rather than anything else.
So please try the latest patch instead (on top of anything that shows
corruption reliably - the patch should be _totally_ independent of all the
other issues, and I think it will apply cleanly on top of 2.6.18.3 and
2.6.19 too, so anything that shows corruption is a fine target - but try
to choose something that has been the "best" at corrupting things for you,
to make the testing as good as possible).
Patch included here again (although I think you were cc'd on my previous
email too, so you should already have it, and our emails just crossed)
And if this doesn't fix it, I don't know what will..
Linus
---
diff --git a/mm/memory.c b/mm/memory.c
index 563792f..cf429c4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2247,21 +2249,23 @@ retry:
if (pte_none(*page_table)) {
flush_icache_page(vma, new_page);
entry = mk_pte(new_page, vma->vm_page_prot);
- if (write_access)
- entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- set_pte_at(mm, address, page_table, entry);
if (anon) {
inc_mm_counter(mm, anon_rss);
lru_cache_add_active(new_page);
page_add_new_anon_rmap(new_page, vma, address);
+ if (write_access)
+ entry = maybe_mkwrite(pte_mkdirty(entry), vma);
} else {
inc_mm_counter(mm, file_rss);
page_add_file_rmap(new_page);
+ entry = pte_wrprotect(entry);
if (write_access) {
dirty_page = new_page;
get_page(dirty_page);
+ entry = maybe_mkwrite(pte_mkdirty(entry), vma);
}
}
+ set_pte_at(mm, address, page_table, entry);
} else {
/* One of our sibling threads was faster, back out. */
page_cache_release(new_page);
-
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: Binary Drivers
On Sun, 2006-24-12 at 09:33 -0800, David Schwartz wrote: > > On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said: > > > > You can't sell something that doesn't exist. If you sell a car > > > even though > > > you can't explain how anyone could drive it, that's fraud. > > > Are they allowed to sell a car that incorporates a computer that uses a > > trade-secret algorithm for controlling the fuel injection to get 20 more > > horsepower and 5% better mileage? > > I assume that's a rhetorical question. Of course they are. > > Now, let's try it another way: Are they allowed to sell a car that > incorporates a computer that uses a trade-secret algorithm for controlling > the fuel injection to get 20 more horsepower and 5% better mileage if it's > impossible to *start* the car without knowing that algorithm? > > Then, I think it's obvious the answer is, of course, no. If you buy the car, > they have to tell you the algorithm. > > If knowledge of the algorithm is required to use the car in a reasonable > way, even if it's not the normal expected way, then they can't keep it > secret. They can't sell something while keeping secret how to *use* it. And > that doesn't just mean the normal expected use. Buying something free and > clear allows you to use it even in unusual ways. > > Perhaps that wasn't the best example. Let's try another one. You buy a car, > and then discover that the car computer has a lockout and a code needs to be > entered on the alarm panel to start the car between 4 AM and 4:15 AM on > Tuesdays. You ask the manufacturer for that code, since you would like to > start your car between 4 AM and 4:15 AM on Tuesdays even though many people > don't. > > How many of the following answers would you consider fair: > > 1) We never wrote the code down. We knew it, but we didn't put it in a form > in which we can give it to you. Most people don't need it anyway. Sorry. > > 2) We're sorry. We know the code, but our contract with another company > prohibits us from disclosing it. > > And so on. > > Buying the car includes the right to start it between 4 AM and 4:15 AM on > Tuesdays if that's what you want to do. If the manufacturer couldn't sell > you the right or ability to do that, it couldn't sell you the car. > > Owning a video card includes the right to make it work with Linux if that's > what you want to do. If the manufacturer couldn't sell you the right or > ability to do that, it couldn't sell you the video card. > Here's my personal favourite example: You walk into a car dealership to buy a new car, because your old car is too slow to drive on the freeway; you need something faster. The salesman shows you a great vehicle. He tells you all about how this car is the pinnacle of automotive technology. It's got muscle. It's got finesse. It's got tons of state of the art bells and whistles. Your friends will be s jealous. Chicks will dig you. You have to have it. You pay the man and have it delivered to you house. When it arrives, you can't figure out how to open the door. The front windows are opaque, so you can't see inside. You: "Hey, delivery guy. How do I open the door on this thing?". Guy: "I'm not the delivery guy. I'm your driver." You: "Huh? Look, I don't need a driver, OK? I'll drive it myself. So how do I open the door?" Driver: "I'm sorry sir, but I can't tell you that. It's secret car company stuff. If I told you, then our competition might find out how we do it, and we would lose our competitive advantage." You: "Whatever. I need to get to work. Let's go." You get in the back seat, but there is an opaque barrier between you and the front of the car. Driver: "Just talk into the speaker on your left, sir, and I'll go where you tell me to." You get out on the freeway, but you're only going 30 kph. You: "What the hell is wrong with this thing? I thought this car was the fastest thing on the road. Pick it up, why don't you?" Driver: "I'm sorry sir. I don't really know how to make the car go faster than 30 kph. This is a new model, and the company hasn't yet taught us how to drive it fast. Check in with them next month. They're always training new drivers, and they might have a replacement for you by then." You: "Well that's just great. Let's get off the freeway. Take a left on Broadway, at the bottom of the off-ramp." You exit the freeway, but as you are turning left onto Broadway, your car stalls in the intersection. You: "Hey driver, WTF?" Driver: "Sorry Sir, I seem t0 baeo ++_?+CFY^K$# ekbae." The driver stumbles out of the car and starts spazzing out on the ground. After a couple of minutes he's OK and you get back on the road. There's an uncomfortable silence in the car. You don't tell him to turn left any more. Six months later, the company sends you a replacement driver. Driver2: "Sorry it took so long sir. You see, there's not much call for drivers who know the streets in this
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On 12/24/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
How about this particularly stupid diff? (please test with something that
_would_ cause corruption normally).
It is _entirely_ untested, but what it tries to do is to simply serialize
any writeback in progress with any process that tries to re-map a shared
page into its address space and dirty it. I haven't tested it, and maybe
it misses some case, but it looks likea good way to try to avoid races
with marking pages dirty and the writeback phase ..
The apt cache files (/var/cache/apt/*.bin) still get corrupted with
this patch and 2.6.19.
Gordon
diff -Naupr linux-2.6.19.orig/fs/buffer.c linux-2.6.19/fs/buffer.c
--- linux-2.6.19.orig/fs/buffer.c 2006-11-29 14:57:37.0 -0700
+++ linux-2.6.19/fs/buffer.c2006-12-21 01:16:31.0 -0700
@@ -2832,7 +2832,7 @@ int try_to_free_buffers(struct page *pag
int ret = 0;
BUG_ON(!PageLocked(page));
- if (PageWriteback(page))
+ if (PageDirty(page) || PageWriteback(page))
return 0;
if (mapping == NULL) { /* can this still happen? */
@@ -2843,17 +2843,6 @@ int try_to_free_buffers(struct page *pag
spin_lock(>private_lock);
ret = drop_buffers(page, _to_free);
spin_unlock(>private_lock);
- if (ret) {
- /*
-* If the filesystem writes its buffers by hand (eg ext3)
-* then we can have clean buffers against a dirty page. We
-* clean the page here; otherwise later reattachment of buffers
-* could encounter a non-uptodate page, which is unresolvable.
-* This only applies in the rare case where try_to_free_buffers
-* succeeds but the page is not freed.
-*/
- clear_page_dirty(page);
- }
out:
if (buffers_to_free) {
struct buffer_head *bh = buffers_to_free;
diff -Naupr linux-2.6.19.orig/fs/hugetlbfs/inode.c
linux-2.6.19/fs/hugetlbfs/inode.c
--- linux-2.6.19.orig/fs/hugetlbfs/inode.c 2006-11-29
14:57:37.0 -0700
+++ linux-2.6.19/fs/hugetlbfs/inode.c 2006-12-21 01:15:21.0 -0700
@@ -176,7 +176,7 @@ static int hugetlbfs_commit_write(struct
static void truncate_huge_page(struct page *page)
{
- clear_page_dirty(page);
+ cancel_dirty_page(page, /* No IO accounting for huge pages? */0);
ClearPageUptodate(page);
remove_from_page_cache(page);
put_page(page);
diff -Naupr linux-2.6.19.orig/include/linux/page-flags.h
linux-2.6.19/include/linux/page-flags.h
--- linux-2.6.19.orig/include/linux/page-flags.h2006-11-29
14:57:37.0 -0700
+++ linux-2.6.19/include/linux/page-flags.h 2006-12-21
01:15:21.0 -0700
@@ -253,15 +253,11 @@ static inline void SetPageUptodate(struc
struct page; /* forward declaration */
-int test_clear_page_dirty(struct page *page);
+extern void cancel_dirty_page(struct page *page, unsigned int account_size);
+
int test_clear_page_writeback(struct page *page);
int test_set_page_writeback(struct page *page);
-static inline void clear_page_dirty(struct page *page)
-{
- test_clear_page_dirty(page);
-}
-
static inline void set_page_writeback(struct page *page)
{
test_set_page_writeback(page);
diff -Naupr linux-2.6.19.orig/mm/memory.c linux-2.6.19/mm/memory.c
--- linux-2.6.19.orig/mm/memory.c 2006-11-29 14:57:37.0 -0700
+++ linux-2.6.19/mm/memory.c2006-12-24 11:04:03.0 -0700
@@ -1534,6 +1534,7 @@ static int do_wp_page(struct mm_struct *
if (!pte_same(*page_table, orig_pte))
goto unlock;
}
+ wait_on_page_writeback(old_page);
dirty_page = old_page;
get_page(dirty_page);
reuse = 1;
@@ -1832,6 +1833,33 @@ void unmap_mapping_range(struct address_
}
EXPORT_SYMBOL(unmap_mapping_range);
+static void check_last_page(struct address_space *mapping, loff_t size)
+{
+ pgoff_t index;
+ unsigned int offset;
+ struct page *page;
+
+ if (!mapping)
+ return;
+ offset = size & ~PAGE_MASK;
+ if (!offset)
+ return;
+ index = size >> PAGE_SHIFT;
+ page = find_lock_page(mapping, index);
+ if (page) {
+ unsigned int check = 0;
+ unsigned char *kaddr = kmap_atomic(page, KM_USER0);
+ do {
+ check += kaddr[offset++];
+ } while (offset < PAGE_SIZE);
+ kunmap_atomic(kaddr,KM_USER0);
+ unlock_page(page);
+ page_cache_release(page);
+ if (check)
+ printk("%s: BADNESS: truncate check %u\n",
current->comm, check);
+ }
+}
+
/**
* vmtruncate - unmap mappings "freed" by truncate() syscall
* @inode: inode of the file used
@@ -1865,6 +1893,7 @@ do_expand:
goto out_sig;
if (offset
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006, Linus Torvalds wrote:
>
> Peter, tell me I'm crazy, but with the new rules, the following condition
> is a bug:
>
> - shared mapping
> - writable
> - not already marked dirty in the PTE
Ok, so how about this diff.
I'm actually feeling good about this one. It really looks like
"do_no_page()" was simply buggy, and that this explains everything.
Please please please test. Throw all the other patches away (with the
possible exception of the "update_mmu_cache()" sanity checker, which is
still interesting in case some _other_ place does this too).
Don't do the "wait_on_page_writeback()" thing, because it changes timings
and might hide thngs for the wrong reasons. Just apply this on top of a
known failing kernel, and test.
Linus
---
diff --git a/mm/memory.c b/mm/memory.c
index 563792f..cf429c4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2247,21 +2249,23 @@ retry:
if (pte_none(*page_table)) {
flush_icache_page(vma, new_page);
entry = mk_pte(new_page, vma->vm_page_prot);
- if (write_access)
- entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- set_pte_at(mm, address, page_table, entry);
if (anon) {
inc_mm_counter(mm, anon_rss);
lru_cache_add_active(new_page);
page_add_new_anon_rmap(new_page, vma, address);
+ if (write_access)
+ entry = maybe_mkwrite(pte_mkdirty(entry), vma);
} else {
inc_mm_counter(mm, file_rss);
page_add_file_rmap(new_page);
+ entry = pte_wrprotect(entry);
if (write_access) {
dirty_page = new_page;
get_page(dirty_page);
+ entry = maybe_mkwrite(pte_mkdirty(entry), vma);
}
}
+ set_pte_at(mm, address, page_table, entry);
} else {
/* One of our sibling threads was faster, back out. */
page_cache_release(new_page);
-
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] Update Documentation/pci.txt v7
On Sat, 23 Dec 2006 23:07:26 -0700 Grant Grundler wrote:
> +10. Legacy I/O port free driver
> +~~~
That subject (and patches with similar subject) confuses me.
It's difficult to associate the adjectives correctly.
I suppose it just needs some hyphens/dashes, like:
10. Legacy-I/O-port-free driver
but that's ETOOMUCH. Maybe ?
10. Stop using legacy I/O space
> +Large servers may not be able to provide I/O port resources to all PCI
> +devices. I/O Port space is only 64KB on Intel Architecture[1] and is
> +likely also fragmented since the I/O base register of PCI-to-PCI
> +bridge will usually be aligned to a 4KB boundary[2]. On such systems,
> +pci_enable_device() and pci_request_region() will fail when
> +attempting to enable I/O Port regions that don't have I/O Port
> +resources assigned.
> +11. MMIO Space and "Write Posting"
> +~~
> +Converting a driver from using I/O Port space to using MMIO space
> +often requires some additional changes. Specifically, "write posting"
> +needs to be handled. Many drivers (e.g. tg3, acenic, sym53c8xx_2)
> +already do this. I/O Port space guarantees write transactions reach the PCI
> +device before the CPU can continue. Writes to MMIO space allow the CPU
> +to continue before the transaction reaches the PCI device. HW weenies
> +call this "Write Posting" because the write completion is "posted" to
> +the CPU before the transaction has reached its destination.
> +
> +Thus, timing sensitive code should add readl() where the CPU is
> +expected to wait before doing other work. The classic "bit banging"
> +sequence works fine for I/O Port space:
> +
> + for (i=8; --i; val >>= 1) {
Please use: i = 8;
to match CodingStyle. (and below)
> + outb(val & 1, ioport_reg); /* write bit */
> + udelay(10);
> + }
> +
> +The same sequence for MMIO space should be:
> +
> + for (i=8; --i; val >>= 1) {
> + writeb(val & 1, mmio_reg); /* write bit */
> + readb(safe_mmio_reg); /* flush posted write */
> + udelay(10);
> + }
Rest looks good to me.
---
~Randy
-
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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006, Linus Torvalds wrote:
>
> How about this particularly stupid diff? (please test with something that
> _would_ cause corruption normally).
Actually, here's an even more stupid diff, which actually to some degree
seems to capture the real problem better.
Peter, tell me I'm crazy, but with the new rules, the following condition
is a bug:
- shared mapping
- writable
- not already marked dirty in the PTE
because that combination means that the hardware can mark the PTE dirty
without us even realizing (and thus not marking the "struct page *"
dirty).
(The above is actually a valid situation for IO mappings, but not for
"real" mappings. And IO mappings should never take page faults, I think).
So, with that in mind, I wrote this stupid patch (for 32-bit x86, since I
used my Mac Mini for testing ratehr than my main machine - but the x86-64
version should be pretty much identcal)..
And you know what, Peter? It triggers for me. I get
WARNING at mm/memory.c:2274 do_no_page()
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __handle_mm_fault+0x38d/0x919
[] do_page_fault+0x1ff/0x507
[] error_code+0x7c/0x84
which seems to say that do_no_page() can be used to insert shared and
non-dirty, but still writable, pages.
But maybe my patch is just bogus, and I didn't think it through.
Peter, I realize it's Christmas Eve, but let's face it, Santa appreciates
good boys and girls, and we all want tons of loot. So please be good, and
waste some time looking at this and tell me why I'm either wrong, or
there's a real smoking gun here.. ;)
Linus
---
diff --git a/include/asm-i386/pgtable.h b/include/asm-i386/pgtable.h
index e6a4723..1389bb7 100644
--- a/include/asm-i386/pgtable.h
+++ b/include/asm-i386/pgtable.h
@@ -494,7 +494,13 @@ do {
\
* The i386 doesn't have any external MMU info: the kernel page
* tables contain all the necessary information.
*/
-#define update_mmu_cache(vma,address,pte) do { } while (0)
+#define bad_shared_pte(pte) (pte_write(pte) && !pte_dirty(pte))
+#define update_mmu_cache(vma,address,pte) do { \
+ static int __cnt; \
+ WARN_ON(((vma)->vm_flags & VM_SHARED) \
+&& bad_shared_pte(pte) \
+&& ++__cnt < 5); \
+} while (0)
#endif /* !__ASSEMBLY__ */
#ifdef CONFIG_FLATMEM
-
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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006 09:16:06 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Sun, 24 Dec 2006, Andrei Popa wrote: > > > On Sun, 2006-12-24 at 04:31 -0800, Andrew Morton wrote: > > > Andrei Popa <[EMAIL PROTECTED]> wrote: > > > > /dev/sda7 on / type ext3 (rw,noatime,nobh) > > > > > > > > I don't have corruption. I tested twice. > > > > > > This is a surprising result. Can you pleas retest ext3 > > > data=writeback,nobh? > > > > Yes, no corruption. Also tested only with data=writeback and had no > > corruption. > > Ok, so it would seem to be writeback related _somehow_. However, most of > the differences (I _thought_) in ext3 actually show up only if you have > *both* "nobh" and "data=writeback", and as far as I can tell, just a > simple "data=writeback" should still use the bog-standard > "block_write_full_page()". > > Andrew? > > Although as far as I can see, then ext2 should work as-is too (since it > too also just uses "block_write_full_page()" without anything fancy). ext2 uses the multipage-bio assembly code for writeback whereas ext3 doesn't. But ext3 doesn't use that code in data=ordered mode, of course. Still, this: --- a/fs/ext2/inode.c~a +++ a/fs/ext2/inode.c @@ -693,7 +693,7 @@ const struct address_space_operations ex .commit_write = generic_commit_write, .bmap = ext2_bmap, .direct_IO = ext2_direct_IO, - .writepages = ext2_writepages, +// .writepages = ext2_writepages, .migratepage= buffer_migrate_page, }; @@ -711,7 +711,7 @@ const struct address_space_operations ex .commit_write = nobh_commit_write, .bmap = ext2_bmap, .direct_IO = ext2_direct_IO, - .writepages = ext2_writepages, +// .writepages = ext2_writepages, .migratepage= buffer_migrate_page, }; _ will switch it off for ext2. > Strange. > > How about this particularly stupid diff? (please test with something that > _would_ cause corruption normally). > > It is _entirely_ untested, but what it tries to do is to simply serialize > any writeback in progress with any process that tries to re-map a shared > page into its address space and dirty it. I haven't tested it, and maybe > it misses some case, but it looks likea good way to try to avoid races > with marking pages dirty and the writeback phase .. > > Linus > --- > diff --git a/mm/memory.c b/mm/memory.c > index 563792f..64ed10b 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -1544,6 +1544,7 @@ static int do_wp_page(struct mm_struct *mm, struct > vm_area_struct *vma, > if (!pte_same(*page_table, orig_pte)) > goto unlock; > } > + wait_on_page_writeback(old_page); > dirty_page = old_page; > get_page(dirty_page); > reuse = 1; > @@ -2215,6 +2216,7 @@ retry: > page_cache_release(new_page); > return VM_FAULT_SIGBUS; > } > + wait_on_page_writeback(new_page); > } > } yup. Also, we could perhaps lock the target page during pagefaults.. - 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: Updated Kernel Hacker's guide to git
Jeff Garzik <[EMAIL PROTECTED]> wrote: > I refreshed my git intro/cookbook for kernel hackers, at > http://linux.yyz.us/git-howto.html Looks nice, starting to look it over. Notes: Getting started: There are RPM packages available (I think they are for latest Fedora; in case of doubt get the latest SRPM and build yourself, sometimes the distros lag /way/ behind). There are also Debian packages there, dunno about those. Basic tasks: 'git pull' should be enough, no need to give the URL each time. It is useful to tell people how to get "nonofficial" branches (via URL + branches) too. Miscellaneous debris: 'git pull' has gotten tags each time for me? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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] i386: per-cpu mmconfig map
Hi, Arjan van de Ven <[EMAIL PROTECTED]> writes: >> [ Alternatively, we could make a per-cpu mapping area or something. Not >> that it's probably worth it, but if we wanted to avoid all locking and >> instead just disable preemption, that would be the way to go. --Linus ] >> >> This patch is a draft of Linus's suggestion. This seems work for me. >> And this removes pci_config_lock in mmconfig access path, I think we >> don't need lock on this path, although we need to disable IRQ. >> >> Comment? > > I like the idea and the implementation, I have just one concern: > Does your schema still work if the Non-Maskable-Interrupt code uses > config space? It may do that I suspect to deal with ECC memory errors ;( I didn't notice the problem of NMI at all. However if NMI path use it, pci_config_lock would be deadlock already. So I think NMI can't access to PCI config... Hm... -- OGAWA Hirofumi <[EMAIL PROTECTED]> - 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: Binary Drivers
> On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said: > > You can't sell something that doesn't exist. If you sell a car > > even though > > you can't explain how anyone could drive it, that's fraud. > Are they allowed to sell a car that incorporates a computer that uses a > trade-secret algorithm for controlling the fuel injection to get 20 more > horsepower and 5% better mileage? I assume that's a rhetorical question. Of course they are. Now, let's try it another way: Are they allowed to sell a car that incorporates a computer that uses a trade-secret algorithm for controlling the fuel injection to get 20 more horsepower and 5% better mileage if it's impossible to *start* the car without knowing that algorithm? Then, I think it's obvious the answer is, of course, no. If you buy the car, they have to tell you the algorithm. If knowledge of the algorithm is required to use the car in a reasonable way, even if it's not the normal expected way, then they can't keep it secret. They can't sell something while keeping secret how to *use* it. And that doesn't just mean the normal expected use. Buying something free and clear allows you to use it even in unusual ways. Perhaps that wasn't the best example. Let's try another one. You buy a car, and then discover that the car computer has a lockout and a code needs to be entered on the alarm panel to start the car between 4 AM and 4:15 AM on Tuesdays. You ask the manufacturer for that code, since you would like to start your car between 4 AM and 4:15 AM on Tuesdays even though many people don't. How many of the following answers would you consider fair: 1) We never wrote the code down. We knew it, but we didn't put it in a form in which we can give it to you. Most people don't need it anyway. Sorry. 2) We're sorry. We know the code, but our contract with another company prohibits us from disclosing it. And so on. Buying the car includes the right to start it between 4 AM and 4:15 AM on Tuesdays if that's what you want to do. If the manufacturer couldn't sell you the right or ability to do that, it couldn't sell you the car. Owning a video card includes the right to make it work with Linux if that's what you want to do. If the manufacturer couldn't sell you the right or ability to do that, it couldn't sell you the video card. 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: [RFC] i386: per-cpu mmconfig map
On Mon, 2006-12-25 at 02:05 +0900, OGAWA Hirofumi wrote: > Hi, > > [ Alternatively, we could make a per-cpu mapping area or something. Not > that it's probably worth it, but if we wanted to avoid all locking and > instead just disable preemption, that would be the way to go. --Linus ] > > This patch is a draft of Linus's suggestion. This seems work for me. > And this removes pci_config_lock in mmconfig access path, I think we > don't need lock on this path, although we need to disable IRQ. > > Comment? Hi, I like the idea and the implementation, I have just one concern: Does your schema still work if the Non-Maskable-Interrupt code uses config space? It may do that I suspect to deal with ECC memory errors ;( Greetings, Arjan van de Ven - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006, Andrei Popa wrote: > On Sun, 2006-12-24 at 04:31 -0800, Andrew Morton wrote: > > Andrei Popa <[EMAIL PROTECTED]> wrote: > > > /dev/sda7 on / type ext3 (rw,noatime,nobh) > > > > > > I don't have corruption. I tested twice. > > > > This is a surprising result. Can you pleas retest ext3 data=writeback,nobh? > > Yes, no corruption. Also tested only with data=writeback and had no > corruption. Ok, so it would seem to be writeback related _somehow_. However, most of the differences (I _thought_) in ext3 actually show up only if you have *both* "nobh" and "data=writeback", and as far as I can tell, just a simple "data=writeback" should still use the bog-standard "block_write_full_page()". Andrew? Although as far as I can see, then ext2 should work as-is too (since it too also just uses "block_write_full_page()" without anything fancy). Strange. How about this particularly stupid diff? (please test with something that _would_ cause corruption normally). It is _entirely_ untested, but what it tries to do is to simply serialize any writeback in progress with any process that tries to re-map a shared page into its address space and dirty it. I haven't tested it, and maybe it misses some case, but it looks likea good way to try to avoid races with marking pages dirty and the writeback phase .. Linus --- diff --git a/mm/memory.c b/mm/memory.c index 563792f..64ed10b 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1544,6 +1544,7 @@ static int do_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, if (!pte_same(*page_table, orig_pte)) goto unlock; } + wait_on_page_writeback(old_page); dirty_page = old_page; get_page(dirty_page); reuse = 1; @@ -2215,6 +2216,7 @@ retry: page_cache_release(new_page); return VM_FAULT_SIGBUS; } + wait_on_page_writeback(new_page); } } - 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: Linux 2.6.20-rc2
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Yu Luming (1):
> ACPI: video: Add dev argument for backlight_device_register
Fix compilation of via-pmu-backlight.
Signed-off-by: Andreas Schwab <[EMAIL PROTECTED]>
---
drivers/macintosh/via-pmu-backlight.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.20-rc2/drivers/macintosh/via-pmu-backlight.c
===
--- linux-2.6.20-rc2.orig/drivers/macintosh/via-pmu-backlight.c 2006-11-30
23:33:39.0 +0100
+++ linux-2.6.20-rc2/drivers/macintosh/via-pmu-backlight.c 2006-12-24
17:58:18.0 +0100
@@ -147,7 +147,7 @@ void __init pmu_backlight_init()
snprintf(name, sizeof(name), "pmubl");
- bd = backlight_device_register(name, NULL, _backlight_data);
+ bd = backlight_device_register(name, NULL, NULL, _backlight_data);
if (IS_ERR(bd)) {
printk("pmubl: Backlight registration failed\n");
goto error;
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
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] i386: per-cpu mmconfig map
Hi,
[ Alternatively, we could make a per-cpu mapping area or something. Not
that it's probably worth it, but if we wanted to avoid all locking and
instead just disable preemption, that would be the way to go. --Linus ]
This patch is a draft of Linus's suggestion. This seems work for me.
And this removes pci_config_lock in mmconfig access path, I think we
don't need lock on this path, although we need to disable IRQ.
Comment?
Thanks.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
arch/i386/pci/mmconfig.c | 89 --
include/asm-i386/fixmap.h |3 +
2 files changed, 49 insertions(+), 43 deletions(-)
diff -puN include/asm-i386/fixmap.h~pci_mmcfg-per_cpu-map
include/asm-i386/fixmap.h
--- linux-2.6/include/asm-i386/fixmap.h~pci_mmcfg-per_cpu-map 2006-12-25
00:03:24.0 +0900
+++ linux-2.6-hirofumi/include/asm-i386/fixmap.h2006-12-25
00:03:25.0 +0900
@@ -84,7 +84,8 @@ enum fixed_addresses {
FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
#endif
#ifdef CONFIG_PCI_MMCONFIG
- FIX_PCIE_MCFG,
+ FIX_PCIE_MCFG_BEGIN,
+ FIX_PCIE_MCFG_END = FIX_PCIE_MCFG_BEGIN + NR_CPUS - 1,
#endif
__end_of_permanent_fixed_addresses,
/* temporary boot-time mappings, used before ioremap() is functional */
diff -puN arch/i386/pci/mmconfig.c~pci_mmcfg-per_cpu-map
arch/i386/pci/mmconfig.c
--- linux-2.6/arch/i386/pci/mmconfig.c~pci_mmcfg-per_cpu-map2006-12-25
00:03:25.0 +0900
+++ linux-2.6-hirofumi/arch/i386/pci/mmconfig.c 2006-12-25 00:03:25.0
+0900
@@ -22,11 +22,8 @@
/* Assume systems with more busses have correct MCFG */
#define MAX_CHECK_BUS 16
-#define mmcfg_virt_addr ((void __iomem *) fix_to_virt(FIX_PCIE_MCFG))
-
/* The base address of the last MMCONFIG device accessed */
-static u32 mmcfg_last_accessed_device;
-static int mmcfg_last_accessed_cpu;
+static DEFINE_PER_CPU(u32, mcfg_last_dev_base);
static DECLARE_BITMAP(fallback_slots, MAX_CHECK_BUS*32);
@@ -68,24 +65,29 @@ static u32 get_base_addr(unsigned int se
return 0;
}
-/*
- * This is always called under pci_config_lock
- */
-static void pci_exp_set_dev_base(unsigned int base, int bus, int devfn)
+static void __iomem *mcfg_map_dev_base(unsigned int base, int bus, int devfn)
{
u32 dev_base = base | (bus << 20) | (devfn << 12);
- int cpu = smp_processor_id();
- if (dev_base != mmcfg_last_accessed_device ||
- cpu != mmcfg_last_accessed_cpu) {
- mmcfg_last_accessed_device = dev_base;
- mmcfg_last_accessed_cpu = cpu;
- set_fixmap_nocache(FIX_PCIE_MCFG, dev_base);
+ int cpu, idx;
+
+ cpu = get_cpu();
+ idx = FIX_PCIE_MCFG_BEGIN + cpu;
+ if (dev_base != __get_cpu_var(mcfg_last_dev_base)) {
+ __get_cpu_var(mcfg_last_dev_base) = dev_base;
+ set_fixmap_nocache(idx, dev_base);
}
+ return (void __iomem *)__fix_to_virt(idx);
+}
+
+static inline void mcfg_unmap_dev_base(void)
+{
+ put_cpu();
}
static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 *value)
{
+ void __iomem *vaddr;
unsigned long flags;
u32 base;
@@ -98,23 +100,23 @@ static int pci_mmcfg_read(unsigned int s
if (!base)
return pci_conf1_read(seg,bus,devfn,reg,len,value);
- spin_lock_irqsave(_config_lock, flags);
-
- pci_exp_set_dev_base(base, bus, devfn);
+ local_irq_save(flags);
+ vaddr = mcfg_map_dev_base(base, bus, devfn);
switch (len) {
case 1:
- *value = readb(mmcfg_virt_addr + reg);
+ *value = readb(vaddr + reg);
break;
case 2:
- *value = readw(mmcfg_virt_addr + reg);
+ *value = readw(vaddr + reg);
break;
case 4:
- *value = readl(mmcfg_virt_addr + reg);
+ *value = readl(vaddr + reg);
break;
}
- spin_unlock_irqrestore(_config_lock, flags);
+ mcfg_unmap_dev_base();
+ local_irq_restore(flags);
return 0;
}
@@ -122,6 +124,7 @@ static int pci_mmcfg_read(unsigned int s
static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 value)
{
+ void __iomem *vaddr;
unsigned long flags;
u32 base;
@@ -132,23 +135,23 @@ static int pci_mmcfg_write(unsigned int
if (!base)
return pci_conf1_write(seg,bus,devfn,reg,len,value);
- spin_lock_irqsave(_config_lock, flags);
-
- pci_exp_set_dev_base(base, bus, devfn);
+ local_irq_save(flags);
+ vaddr = mcfg_map_dev_base(base, bus, devfn);
switch (len) {
case 1:
- writeb(value, mmcfg_virt_addr +
Re: BUG: scheduling while atomic - Linux 2.6.20-rc2-ga3d89517
"Fabio Comolli" <[EMAIL PROTECTED]> writes:
> Just found this in syslog. It was during normal activity, about 6
> minutes after resume-from-ram. I never saw this before.
It seems someone missed to check PREEMPT_ACTIVE in __resched_legal().
Could you please test the following patch?
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
kernel/sched.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff -puN kernel/sched.c~__resched_legal kernel/sched.c
--- linux-2.6/kernel/sched.c~__resched_legal2006-12-24 22:40:19.0
+0900
+++ linux-2.6-hirofumi/kernel/sched.c 2006-12-24 23:54:01.0 +0900
@@ -4619,10 +4619,11 @@ asmlinkage long sys_sched_yield(void)
static inline int __resched_legal(int expected_preempt_count)
{
-#ifdef CONFIG_PREEMPT
+#ifndef CONFIG_PREEMPT
+ expected_preempt_count = 0;
+#endif
if (unlikely(preempt_count() != expected_preempt_count))
return 0;
-#endif
if (unlikely(system_state != SYSTEM_RUNNING))
return 0;
return 1;
_
-
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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 2006-12-24 at 04:31 -0800, Andrew Morton wrote: > On Sun, 24 Dec 2006 14:14:38 +0200 > Andrei Popa <[EMAIL PROTECTED]> wrote: > > > > - mount the fs with ext2 with the no-buffer-head option. That means > > > either: > > > > > > grub.conf: rootfstype=ext2 rootflags=nobh > > > /etc/fstab: ext2 nobh > > > > ierdnac ~ # mount > > /dev/sda7 on / type ext2 (rw,noatime,nobh) > > > > I have corruption. > > > > > > > > - mount the fs with ext3 data=writeback, nobh > > > > > > grub.conf: rootfstype=ext3 rootflags=nobh,data=writeback (I hope this > > > works) > > > /etc/fstab: ext2 data=writeback,nobh > > > > ierdnac ~ # mount > > /dev/sda7 on / type ext3 (rw,noatime,nobh) > > > > ierdnac ~ # dmesg|grep EXT3 > > EXT3-fs: mounted filesystem with writeback data mode. > > EXT3 FS on sda7, internal journal > > > > I don't have corruption. I tested twice. > > This is a surprising result. Can you pleas retest ext3 data=writeback,nobh? Yes, no corruption. Also tested only with data=writeback and had no corruption. - 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: linux 2.6.20-rc1: kernel BUG at fs/buffer.c:1235!
Jiri Slaby <[EMAIL PROTECTED]> writes: > Alex Romosan wrote: >> this is on a thinkpad t40, not sure if it means anything, but here it goes: >> >> kernel: kernel BUG at fs/buffer.c:1235! >> kernel: invalid opcode: [#1] >> kernel: PREEMPT >> kernel: Modules linked in: radeon drm binfmt_misc nfs sd_mod scsi_mod nfsd >> exportfs lockd sunrpc autofs4 pcmcia firmware_class joydev irtty_sir sir_dev >> nsc_ircc irda crc_ccitt parport_pc parport ehci_hcd uhci_hcd usbcore >> aes_i586 airo nls_iso8859_1 ntfs yenta_socket rsrc_nonstatic pcmcia_core >> kernel: CPU:0 >> kernel: EIP:0060:[]Not tainted VLI >> kernel: EFLAGS: 00010046 (2.6.20-rc1 #215) > > Could you test 2.6.20-rc2? It's probably fixed there. i switched to 2.6.20-rc2 last night. we'll see if it happens again. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - 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.19.1: kobject_add failed for audio with -EEXIST
* Takashi Iwai <[EMAIL PROTECTED]> wrote: > At Tue, 12 Dec 2006 17:01:35 +0100, > markus reichelt wrote: > > > > Hi, > > > > I'm still having this prob at boot. please advise. > > It's the place trying to create OSS audio entry. > What points /sys/class/sound/audio/device ? sorry for the late answer, I totally missed your mail I'm not sure I get what you are saying but this is what's there under 2.6.19.1 ls -al /sys/class/sound/audio/ insgesamt 0 drwxr-xr-x 2 root root0 2006-12-24 16:12 . drwxr-xr-x 22 root root0 2006-12-12 17:53 .. -r--r--r-- 1 root root 4096 2006-12-24 16:12 dev lrwxrwxrwx 1 root root0 2006-12-24 16:12 subsystem -> ../../../class/sound --w--- 1 root root 4096 2006-12-24 16:12 uevent ls -al /sys/class/sound/audio1/ insgesamt 0 drwxr-xr-x 2 root root0 2006-12-24 16:12 . drwxr-xr-x 22 root root0 2006-12-12 17:53 .. -r--r--r-- 1 root root 4096 2006-12-24 16:12 dev lrwxrwxrwx 1 root root0 2006-12-24 16:12 device -> ../../../devices/pci:00/:00:0e.0/:02:0a.1 lrwxrwxrwx 1 root root0 2006-12-24 16:12 subsystem -> ../../../class/sound --w--- 1 root root 4096 2006-12-24 16:12 uevent these are the two entries /sys/class/sound/audio* the only difference between the kernels before my last mail about the issue is that with .19.1 i can use the sound hardware which was not possible beforehand; it was simply dead after the borked dmesg. if you need anything else, please dont heasitate to mail. thanks. -- left blank, right bald pgpTjf5a7di5o.pgp Description: PGP signature
bcm43xx-softmac broken on 2.6.20-rc2
This is a heads-up for anyone wishing to use bcm43xx-softmac on Linus's git
tree, which is now at
v2.6.20-rc2. There are two serious bugs in that code. Fixes are found below.
The first bug is the result of changes in work queues. The second is the result of a typo that locks
a mutex when it should unlock it.
These fixes have been pushed up stream, but neither has made it to Linus.
Larry
---
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index eec1a1d..a824852 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type,
void *context)
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(>associnfo.work.work);
}
static void
@@ -177,7 +177,7 @@ ieee80211softmac_assoc_notify_auth(struc
switch (event_type) {
case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(>associnfo.work.work);
break;
case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
Index: linux-2.6/net/ieee80211/softmac/ieee80211softmac_wx.c
===
--- linux-2.6.orig/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ linux-2.6/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -463,7 +463,7 @@ ieee80211softmac_wx_get_genie(struct net
err = -E2BIG;
}
spin_unlock_irqrestore(>lock, flags);
- mutex_lock(>associnfo.mutex);
+ mutex_unlock(>associnfo.mutex);
return err;
}
-
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: bluetooth memory corruption (was Re: ext3-related crash in 2.6.20-rc1)
Hi Pavel, > > I got this nasty oops while playing with debugger. Not sure if that is > > related; it also might be something with bluetooth; I already know it > > corrupts memory during suspend, perhaps it corrupts memory in some > > error path? > > Okay, I spoke too soon. bluetooth & suspend memory corruption was > _way_ harder to reproduce than expected. Took me 5-or-so-suspend > cycles... so it is probably unrelated to the previous crash. can you try to reproduce this with 2.6.20-rc2 as well. Regards Marcel - 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.19.1
On Sunday 24 December 2006 04:23, Chuck Ebbert wrote: [snip] > Anyway, post your complete .config. Config attached. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19.1 # Sat Dec 16 19:30:00 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set CONFIG_MVIAC3_2=y # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_REGPARM=y # CONFIG_SECCOMP is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x10 # CONFIG_COMPAT_VDSO is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options (ACPI,
Re: Linux 2.6.20-rc2
Alessandro Suardi wrote: On 12/24/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: Ok, it's a couple of days delayed, because we've been trying to figure out what is up with the rtorrent hash failures since 2.6.18.3. I don't think we've made any progress, but we've cleaned up a number of suspects in the meantime. It's a bit sad, if only because I was really hoping to make 2.6.20 an easy release, and held back on merging some stuff during the merge window for that reason. And now we're battling something that was introduced much earlier.. Now, practically speaking this isn't likely to affect a lot of people, but it's still a worrisome problem, and we've had "top people" looking at it. And they'll continue, but xmas is coming. In the meantime, we'll continue with the stabilization, and this mainly does some driver updates (usb, sound, dri, pci hotplug) and ACPI updates (much of the latter syntactic cleanups). And arm and powerpc updates. Shortlog appended. For developers: if you sent me a patch, and I didn't apply it, it was probably just missed because I concentrated on other issues. So pls re-send.. Unless I explicitly told you that I'm not going to pull it due to the merge window being over, of course ;) Linus [shortlog snipped] As already reported multiple times, including at -rc1 time... still need this libata-sff.c patch: http://marc.theaimsgroup.com/?l=linux-kernel=116343564202844=raw to have my root device detected, ata_piix probe would otherwise fail as described in this thread: http://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/0690.html I've got a patch that should work for those cases. Alan's patch contained some bugs. 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/
[PATCH 2.6.20-rc2] fix mrproper incompleteness
include/linux/utsrelease.h and include/linux/version.h aren't removed any more by mrproper in kernel 2.6.20-rc2. The patch below fixes this. The definition of MRPROPER_FILES looks weird: generated-headers looks like a misspelling of generated_headers, but that one is a Makefile target, not a variable or a file, so I don't see how including it in MRPROPER_FILES could have any effect. Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]> --- linux-2.6.20-rc2/Makefile.~1~ 2006-12-24 14:04:26.0 +0100 +++ linux-2.6.20-rc2/Makefile 2006-12-24 15:31:41.0 +0100 @@ -1040,7 +1040,7 @@ CLEAN_FILES +=vmlinux System.map \ # Directories & files removed with 'make mrproper' MRPROPER_DIRS += include/config include2 usr/include MRPROPER_FILES += .config .config.old include/asm .version .old_version \ - include/linux/autoconf.h generated-headers \ + include/linux/autoconf.h include/linux/utsrelease.h include/linux/version.h \ Module.symvers tags TAGS cscope* # clean - Delete most, but leave enough to build external modules - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Sean wrote: > On Sun, 24 Dec 2006 06:57:58 -0500 > Mark Hounschell <[EMAIL PROTECTED]> wrote: > > >> Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them >> for us. The only way that happens is if they can get in the official >> tree. I know just from monitoring this list that our drivers would never >> be acceptable for inclusion in any "functional form". We open sourced >> them purely out of respect for the way we know the community feels about >> it. > > That shows some class, thanks. > >> It would cost more for us to make them acceptable for inclusion than it >> does for us to just maintain them ourselves. I suspect that is true for >> most vendor created drivers open source or not. >> >> So kernel developers making the required changes as the kernel changes >> is NO real incentive for any vendor to open source their drivers. Sorry. >> >> If it were knowingly less difficult to actually get your drivers >> included, that would be an incentive and then you original point would >> hold as an additional incentive. > > Out of curiosity what specific technical issues in your driver code make > you think that it would be too expensive to whip them into shape for > inclusion? > > Cheers, > Sean > Well just off the top of my head, one of our drivers directly mucks with all the irq affinities (irq_desc) via a provided user land library call. This single call forces all 'other' irqs to be serviced by all the 'other' processors. I know this would never fly in kernel. User land /proc manipulation is not an option for us here. We have another that absolutely requires the Bigphysarea patch. We refuse to use "MEM=" and use a fixed address. Every installation would require a special configuration and our 'end users' would have to have some understanding of all that. We are also maintaining that patch internally also. So this product (for full functionality with our not so open source application) requires a special kernel to begin with. Other than that this one might have a chance of inclusion. It only requires the bigphysarea when used with this application. It will actually build and work (basically) with or without it. Another is actually somewhat tied to the one mentioned above in that this one has to facilitate the ability of its card being able to to PIO reads and writes to 'special locations' in userspace and to the SRAM memory of the above card. Even when on different pci busses. I've looked at some of the V4L drivers that also do this sort of thing and I'm confused by how they are doing it so I'm almost certain that what we are doing would be considered 'wrong'. Then there is probably the biggest one of all. The coding style issue. Don't get me wrong I understand and agree with what I've read about it. Our drivers were written by hardware people. Or I should say they were written by OUR hardware people. I can offend them because I am among them. No offense intended to any of you invaluable hardware guys. I see 6 months of full time work before I could even sanely ask what I needed to do for inclusion. It seems easier to just try to keep up with the changes. I'm certain our company is not the only one in this situation. I see many GPL external kernel drivers. Why? Mark - 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.19.1
On Sunday 24 December 2006 04:23, Chuck Ebbert wrote: > In-Reply-To: <[EMAIL PROTECTED]> > > On Sat, 23 Dec 2006 15:40:46 +, Alistair John Strachan wrote: > > Pretty much like clockwork, it happened again. I think it's time to take > > this seriously as a software bug, and not some hardware problem. I've ran > > kernels since 2.6.0 on this machine without such crashes, and now two of > > the same in 2.6.19.1? Pretty unlikely! > > Stranger things have happened, e.g. your system might have started > to overheat just recently. True, I've considered it, I'll replace the CPU fan. > Anyway, post your complete .config. And exactly which one of the > many Via cpus are you using? Are you using the Padlock unit? No, much older than that: [alistair] 14:38 [~] cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping: 1 cpu MHz : 999.569 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge cmov mmx fxsr sse fxsr_opt bogomips: 2000.02 > What do those java/python programs do that are running? What pipe > are they polling? > > You could try going back to 2.6.18.x for a while in the meantime. Well, I have had a thought. I recently upgraded the toolchain on the machine from binutils 2.16.x and GCC 3.4.3 (2.6.19 was built with this) to binutils 2.17 and GCC 4.1.1. It's conceivable that this is some sort of compiler bug. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Hi!
> > > > So let's come out and ban binary modules, rather than pussyfooting
> > > > around, if that's what we actually want to do.
> > >
> > > Give people 12 months warning (time to work out what they're going to do,
> > > talk with the legal dept, etc) then make the kernel load only GPL-tagged
> > > modules.
> > >
> > > I think I'd favour that. It would aid those people who are trying to
> > > obtain device specs, and who are persuading organisations to GPL their
> > > drivers.
> >
> > Ok, I have no objection to that at all. I'll whip up such a patch in a
> > bit to spit out kernel log messages whenever such a module is loaded so
> > that people have some warning.
>
> Here you go. The wording for the feature-removal-schedule.txt file
> could probably be cleaned up. Any suggestions would be welcome.
>
> thanks,
>
> greg k-h
>
> ---
> From: Greg Kroah-Hartmna <[EMAIL PROTECTED]>
> Subject: Notify non-GPL module loading will be going away in January 2008
>
> Numerous kernel developers feel that loading non-GPL drivers into the
> kernel violates the license of the kernel and their copyright. Because
> of this, a one year notice for everyone to address any non-GPL
> compatible modules has been set.
>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
>
> ---
> Documentation/feature-removal-schedule.txt |9 +
> kernel/module.c|6 +-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> --- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt
> +++ gregkh-2.6/Documentation/feature-removal-schedule.txt
> @@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI
> Who: Venkatesh Pallipadi <[EMAIL PROTECTED]>
>
> ---
> +
> +What:non GPL licensed modules will able to be loaded successfully.
> +When:January 2008
> +Why: Numerous kernel developers feel that loading non-GPL drivers into the
> + kernel violates the license of the kernel and their copyright.
> +
> +Who: Greg Kroah-Hartman <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
> +
> +---
> --- gregkh-2.6.orig/kernel/module.c
> +++ gregkh-2.6/kernel/module.c
> @@ -1393,9 +1393,13 @@ static void set_license(struct module *m
> license = "unspecified";
>
> if (!license_is_gpl_compatible(license)) {
> - if (!(tainted & TAINT_PROPRIETARY_MODULE))
> + if (!(tainted & TAINT_PROPRIETARY_MODULE)) {
> printk(KERN_WARNING "%s: module license '%s' taints "
> "kernel.\n", mod->name, license);
> + printk(KERN_WARNING "%s: This module will not be able "
> + "to be loaded after January 1, 2008 due to its "
> + "license.\n", mod->name);
> + }
> add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
> }
> }
perhaps printk('Binary only modules are not allowed by kernel license,
but copyright law may still allow them in special cases. Be careful,
Greg is going tuo sue you at beggining of 2008 if you get it wrong.')
would be acceptable way to educate people?
Pavel
--
Thanks for all the (sleeping) penguins.
-
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] change WARN_ON back to "BUG: at ..."
Hi! > I've always felt that it is wrong (or at least misleading) that WARN_ON > prints "BUG". It would have been better if it had said "WARNING", and only > BUG_ON says "BUG". > > But lots of people have now written downstream log-parsing tools which > might break due to this change, so I'm inclined to go with Ingo's patch, > and restore the old (il)logic. People should not be parsing syslog. If they do, they deserve occassional breakage. Pavel -- Thanks for all the (sleeping) penguins. - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Andrew Morton <[EMAIL PROTECTED]> [2006-12-24 00:57]: > /etc/fstab: ext2 nobh > /etc/fstab: ext3 data=writeback,nobh It seems that busybox mount ignores the nobh option but both ext2 and ext3 data=writeback work for me. This is with plain 2.6.19 which normally always fails. -- Martin Michlmayr http://www.cyrius.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: Linux 2.6.20-rc2
On 12/24/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: Ok, it's a couple of days delayed, because we've been trying to figure out what is up with the rtorrent hash failures since 2.6.18.3. I don't think we've made any progress, but we've cleaned up a number of suspects in the meantime. It's a bit sad, if only because I was really hoping to make 2.6.20 an easy release, and held back on merging some stuff during the merge window for that reason. And now we're battling something that was introduced much earlier.. Now, practically speaking this isn't likely to affect a lot of people, but it's still a worrisome problem, and we've had "top people" looking at it. And they'll continue, but xmas is coming. In the meantime, we'll continue with the stabilization, and this mainly does some driver updates (usb, sound, dri, pci hotplug) and ACPI updates (much of the latter syntactic cleanups). And arm and powerpc updates. Shortlog appended. For developers: if you sent me a patch, and I didn't apply it, it was probably just missed because I concentrated on other issues. So pls re-send.. Unless I explicitly told you that I'm not going to pull it due to the merge window being over, of course ;) Linus [shortlog snipped] As already reported multiple times, including at -rc1 time... still need this libata-sff.c patch: http://marc.theaimsgroup.com/?l=linux-kernel=116343564202844=raw to have my root device detected, ata_piix probe would otherwise fail as described in this thread: http://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/0690.html Enjoy the holiday season, --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - 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: linux 2.6.20-rc1: kernel BUG at fs/buffer.c:1235!
Alex Romosan wrote: > this is on a thinkpad t40, not sure if it means anything, but here it goes: > > kernel: kernel BUG at fs/buffer.c:1235! > kernel: invalid opcode: [#1] > kernel: PREEMPT > kernel: Modules linked in: radeon drm binfmt_misc nfs sd_mod scsi_mod nfsd > exportfs lockd sunrpc autofs4 pcmcia firmware_class joydev irtty_sir sir_dev > nsc_ircc irda crc_ccitt parport_pc parport ehci_hcd uhci_hcd usbcore aes_i586 > airo nls_iso8859_1 ntfs yenta_socket rsrc_nonstatic pcmcia_core > kernel: CPU:0 > kernel: EIP:0060:[]Not tainted VLI > kernel: EFLAGS: 00010046 (2.6.20-rc1 #215) Could you test 2.6.20-rc2? It's probably fixed there. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: ptrace() memory corruption?
Andrew Morton wrote: > On Sun, 24 Dec 2006 12:51:16 +0059 > Jiri Slaby <[EMAIL PROTECTED]> wrote: > >> [ 58.674780] EFLAGS: 00010046 (2.6.20-rc1-mm1 #207) > > please, test 2.6.20-rc2. We applied a fix for this. It's working now. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sun, 24 Dec 2006 06:57:58 -0500 Mark Hounschell <[EMAIL PROTECTED]> wrote: > Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them > for us. The only way that happens is if they can get in the official > tree. I know just from monitoring this list that our drivers would never > be acceptable for inclusion in any "functional form". We open sourced > them purely out of respect for the way we know the community feels about > it. That shows some class, thanks. > It would cost more for us to make them acceptable for inclusion than it > does for us to just maintain them ourselves. I suspect that is true for > most vendor created drivers open source or not. > > So kernel developers making the required changes as the kernel changes > is NO real incentive for any vendor to open source their drivers. Sorry. > > If it were knowingly less difficult to actually get your drivers > included, that would be an incentive and then you original point would > hold as an additional incentive. Out of curiosity what specific technical issues in your driver code make you think that it would be too expensive to whip them into shape for inclusion? Cheers, Sean - 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: Binary Drivers
Am Sonntag, 24. Dezember 2006 07:46 schrieb [EMAIL PROTECTED]: > Are they allowed to sell a car that incorporates a computer that > uses a trade-secret algorithm for controlling the fuel injection to > get 20 more horsepower and 5% better mileage? That would be a propritary fuel injection driver then. What we want however is access to the documentation, the specifications, that allows us to develop a very own driver, independently from the propritary one. We don't want source code or anything. Of course if the hardware manufactor supplies us with source code, that's great. Probably any customly written driver will be suboptimal in the first place, but OTOH there are so many skilled people around in the OSS scene, that such a driver would surely soon catch up, if not even surpass the propritary one. Happy holydays Wolfgang Draxinger -- "sooner or later we'll reverse engineer you." pgpPJ3i0IANWE.pgp Description: PGP signature
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006 14:14:38 +0200 Andrei Popa <[EMAIL PROTECTED]> wrote: > > - mount the fs with ext2 with the no-buffer-head option. That means either: > > > > grub.conf: rootfstype=ext2 rootflags=nobh > > /etc/fstab: ext2 nobh > > ierdnac ~ # mount > /dev/sda7 on / type ext2 (rw,noatime,nobh) > > I have corruption. > > > > > - mount the fs with ext3 data=writeback, nobh > > > > grub.conf: rootfstype=ext3 rootflags=nobh,data=writeback (I hope this > > works) > > /etc/fstab: ext2 data=writeback,nobh > > ierdnac ~ # mount > /dev/sda7 on / type ext3 (rw,noatime,nobh) > > ierdnac ~ # dmesg|grep EXT3 > EXT3-fs: mounted filesystem with writeback data mode. > EXT3 FS on sda7, internal journal > > I don't have corruption. I tested twice. This is a surprising result. Can you pleas retest ext3 data=writeback,nobh? - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006 14:26:01 +0200 Andrei Popa <[EMAIL PROTECTED]> wrote: > I also tested with ext3 ordered, nobh and I have file corruption... ordered+nobh isn't a possible combination. The filesystem probably ignored nobh. nobh mode only makes sense with data=writeback. - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 2006-12-24 at 14:14 +0200, Andrei Popa wrote: > On Sun, 2006-12-24 at 00:57 -0800, Andrew Morton wrote: > > On Sun, 24 Dec 2006 00:43:54 -0800 (PST) > > Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > I now _suspect_ that we're talking about something like > > > > > > - we started a writeout. The IO is still pending, and the page was > > >marked clean and is now in the "writeback" phase. > > > - a write happens to the page, and the page gets marked dirty again. > > >Marking the page dirty also marks all the _buffers_ in the page dirty, > > >but they were actually already dirty, because the IO hasn't completed > > >yet. > > > - the IO from the _previous_ write completes, and marks the buffers > > > clean > > >again. > > > > Some things for the testers to try, please: > > > > - mount the fs with ext2 with the no-buffer-head option. That means either: > > > > grub.conf: rootfstype=ext2 rootflags=nobh > > /etc/fstab: ext2 nobh > > ierdnac ~ # mount > /dev/sda7 on / type ext2 (rw,noatime,nobh) > > I have corruption. > > > > > - mount the fs with ext3 data=writeback, nobh > > > > grub.conf: rootfstype=ext3 rootflags=nobh,data=writeback (I hope this > > works) > > /etc/fstab: ext2 data=writeback,nobh > > ierdnac ~ # mount > /dev/sda7 on / type ext3 (rw,noatime,nobh) > > ierdnac ~ # dmesg|grep EXT3 > EXT3-fs: mounted filesystem with writeback data mode. > EXT3 FS on sda7, internal journal > > I don't have corruption. I tested twice. > I also tested with ext3 ordered, nobh and I have file corruption... > > > > if that still fails we can rule out buffer_head funnies. > > - 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: ptrace() memory corruption?
On Sun, 24 Dec 2006 12:51:16 +0059 Jiri Slaby <[EMAIL PROTECTED]> wrote: > [ 58.674780] EFLAGS: 00010046 (2.6.20-rc1-mm1 #207) please, test 2.6.20-rc2. We applied a fix for this. - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 2006-12-24 at 00:57 -0800, Andrew Morton wrote: > On Sun, 24 Dec 2006 00:43:54 -0800 (PST) > Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > I now _suspect_ that we're talking about something like > > > > - we started a writeout. The IO is still pending, and the page was > >marked clean and is now in the "writeback" phase. > > - a write happens to the page, and the page gets marked dirty again. > >Marking the page dirty also marks all the _buffers_ in the page dirty, > >but they were actually already dirty, because the IO hasn't completed > >yet. > > - the IO from the _previous_ write completes, and marks the buffers clean > >again. > > Some things for the testers to try, please: > > - mount the fs with ext2 with the no-buffer-head option. That means either: > > grub.conf: rootfstype=ext2 rootflags=nobh > /etc/fstab: ext2 nobh ierdnac ~ # mount /dev/sda7 on / type ext2 (rw,noatime,nobh) I have corruption. > > - mount the fs with ext3 data=writeback, nobh > > grub.conf: rootfstype=ext3 rootflags=nobh,data=writeback (I hope this > works) > /etc/fstab: ext2 data=writeback,nobh ierdnac ~ # mount /dev/sda7 on / type ext3 (rw,noatime,nobh) ierdnac ~ # dmesg|grep EXT3 EXT3-fs: mounted filesystem with writeback data mode. EXT3 FS on sda7, internal journal I don't have corruption. I tested twice. > > if that still fails we can rule out buffer_head funnies. > - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
James Courtier-Dutton wrote: > > I agree with Linus on these points. The kernel should not be enforcing > these issues. Leave the lawyers to do that bit. If companies want to > play in the "Grey Area", then it is at their own risk. Binary drivers > are already difficult and expensive for the companies because they have > to keep updating them as we change the kernel versions. If they do open > source drivers, we update them for them as we change the kernel > versions, so it works out cheaper for the companies involved. > Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them for us. The only way that happens is if they can get in the official tree. I know just from monitoring this list that our drivers would never be acceptable for inclusion in any "functional form". We open sourced them purely out of respect for the way we know the community feels about it. It would cost more for us to make them acceptable for inclusion than it does for us to just maintain them ourselves. I suspect that is true for most vendor created drivers open source or not. So kernel developers making the required changes as the kernel changes is NO real incentive for any vendor to open source their drivers. Sorry. If it were knowingly less difficult to actually get your drivers included, that would be an incentive and then you original point would hold as an additional incentive. My humble $.02 worth Regards Mark - 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: ptrace() memory corruption?
Jiri Slaby wrote: > Pavel Machek wrote: >>> Is there something wrong with gdb? >> Yep. If I do gdb /bin/bash, run; I'll get similar oops. Am I alone >> seeing this? > > Nope, I have this nasty thing here too and will post oopses in the afternoon, > just before Jezisek comes :). Ok, I captured this through netconosle: [8.499155] usb 3-2: new low speed USB device using uhci_hcd and address 2 [8.721946] usb 3-2: new device found, idVendor=045e, idProduct=00f0 [8.722016] usb 3-2: new device strings: Mfr=1, Product=2, SerialNumber=0 [8.722081] usb 3-2: Product: Microsoft � Laser Mouse 6000 [8.722145] usb 3-2: Manufacturer: Microsoft Corporation [8.722344] usb 3-2: configuration #1 chosen from 1 choice [8.753100] input: Microsoft Corporation Microsoft � Laser Mouse 6000 as /class/input/input4 [8.753310] input: USB HID v1.11 Mouse [Microsoft Corporation Microsoft � Laser Mouse 6000] on usb-:00:1d.1-2 [ 58.672510] WARNING (!__warned) at /home/l/latest/xxx/kernel/softirq.c:137 local_bh_enable() [ 58.672562] [] show_trace_log_lvl+0x1a/0x30 [ 58.672682] [] show_trace+0x12/0x14 [ 58.672787] [] dump_stack+0x16/0x18 [ 58.672893] [] local_bh_enable+0x8c/0x9b [ 58.672998] [] lock_sock_nested+0xa3/0xab [ 58.673107] [] sock_fasync+0x3e/0x145 [ 58.673216] [] sock_close+0x19/0x3d [ 58.673322] [] __fput+0xa6/0x161 [ 58.673432] [] fput+0x22/0x3b [ 58.673538] [] filp_close+0x41/0x67 [ 58.673646] [] sys_close+0x67/0xaf [ 58.673753] [] syscall_call+0x7/0xb [ 58.673855] === [ 58.674091] [ cut here ] [ 58.674158] kernel BUG at /home/l/latest/xxx/fs/buffer.c:1244! [ 58.674224] invalid opcode: [#1] [ 58.674286] SMP [ 58.674414] last sysfs file: /devices/platform/i2c-9191/9191-0290/fan3_min [ 58.674478] Modules linked in: eth1394 floppy ohci1394 ieee1394 ide_cd cdrom [ 58.674778] CPU:1 [ 58.674779] EIP:0060:[]Not tainted VLI [ 58.674780] EFLAGS: 00010046 (2.6.20-rc1-mm1 #207) [ 58.674971] EIP is at __find_get_block+0x165/0x171 [ 58.675035] eax: 0092 ebx: f78e6ec0 ecx: 1000 edx: 8025 [ 58.675101] esi: 0001 edi: 1000 ebp: f76efc6c esp: f76efc34 [ 58.675166] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 58.675232] Process bash (pid: 1595, ti=f76ee000 task=c1a40560 task.ti=f76ee000) [ 58.675297] Stack: c1b31ac0 f7df7e3c 003a c1b31bd0 f76efc74 c0181bb4 0001 [ 58.675693]f7df7e3c f76efc74 c0181544 f78e6ec0 0001 1000 f76efc9c c0181fc2 [ 58.676083]f76efcb4 c0181eab 8025 c1b31ac0 f74e5d40 f76efcb8 c01aa46a f78e6ec0 [ 58.676476] Call Trace: [ 58.676594] [] show_trace_log_lvl+0x1a/0x30 [ 58.676692] [] show_stack_log_lvl+0xa5/0xca [ 58.676789] [] show_registers+0x1d3/0x2b8 [ 58.676887] [] die+0x121/0x243 [ 58.676984] [] do_trap+0x76/0x9c [ 58.677083] [] do_invalid_op+0x97/0xa1 [ 58.677181] [] error_code+0x7c/0x84 [ 58.677278] [] __getblk+0x16/0x20a [ 58.677375] [] __ext3_get_inode_loc+0x139/0x332 [ 58.677476] [] ext3_get_inode_loc+0x14/0x16 [ 58.677575] [] ext3_reserve_inode_write+0x20/0x6c [ 58.677674] [] ext3_mark_inode_dirty+0x20/0x37 [ 58.62] [] ext3_dirty_inode+0x6b/0x6d [ 58.677871] [] __mark_inode_dirty+0x2a/0x170 [ 58.677969] [] touch_atime+0xb4/0xe8 [ 58.678067] [] __link_path_walk+0x91e/0xcb6 [ 58.678164] [] link_path_walk+0x46/0xc3 [ 58.678262] [] do_path_lookup+0x86/0x1b0 [ 58.678359] [] __path_lookup_intent_open+0x44/0x7f [ 58.678457] [] path_lookup_open+0x21/0x27 [ 58.678555] [] open_namei+0x62/0x5cb [ 58.678653] [] do_filp_open+0x26/0x43 [ 58.678750] [] do_sys_open+0x41/0xca [ 58.678847] [] sys_open+0x1c/0x1e [ 58.678943] [] syscall_call+0x7/0xb [ 58.679040] === [ 58.679101] Code: 45 d0 e8 b6 f5 ff ff e9 22 ff ff ff 89 d8 e8 aa f5 ff ff eb 8c 89 ce 8d 4e ff 8b 04 8f 89 04 b7 85 c9 75 f1 89 1f e9 f6 fe ff ff <0f> 0b eb fe 0f 0b eb fe 0f 0b eb fe 55 89 e5 57 56 53 83 ec 1c [ 58.681386] EIP: [] __find_get_block+0x165/0x171 SS:ESP 0068:f76efc34 [ 58.681545] after gdb /bin/bash (gdb) run regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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 6/6] containers: BeanCounters over generic process containers
On 12/23/06, Herbert Poetzl <[EMAIL PROTECTED]> wrote:
On Fri, Dec 22, 2006 at 06:14:48AM -0800, Paul Menage wrote:
> This patch implements the BeanCounter resource control abstraction
> over generic process containers. It contains the beancounter core
> code, plus the numfiles resource counter. It doesn't currently contain
> any of the memory tracking code or the code for switching beancounter
> context in interrupts.
I don't like it, it looks bloated and probably
adds plenty of overhead (similar to the OVZ
implementation where this seems to be taken from)
Yes - perhaps I should have been clearer in the patch description.
It's basically code taken from the OpenVZ bean counters patches that
have been posted recently, but with the filesystem and process
tracking code ripped out (since it's implemented over the generic
containers).
The main point of this patch is to demonstrate that UBC can be
implemented effectively over generic containers, rather than to be a
proposal in favour of UBC versus any of the other potential resource
control mechanisms.
Most of your comments are about code taken pretty much directly from
the UBC patches, so I won't address them.
> +int bc_file_charge(struct file *file)
> +{
> + int sev;
> + struct beancounter *bc;
> +
> + task_lock(current);
why do we lock current? it won't go away that
easily, and for switching the bc, it might be
better to use RCU or a separate lock, no?
The locking model (taken originally from the Cpusets code) in generic
containers is that while you can use RCU to guarantee that a pointer
read from current->container remains valid until you exit the RCU
critical section, if you want to make consistent changes to data
referenced from a task P's container, you need to hold either
P->alloc_lock or one of the two container mutexes (manage_mutex and/or
callback_mutex).
In this particular case (sorry, not on the VPN right now to be able to
figure out the potential code changes) the fact that the call to
css_get_current() uses atomic operations (currently a spinlock, but I
suspect I could optimize it to be a cmpxchg) could mean that we can
skip the task_lock(), at the cost of occasionally accounting a file to
the container that the task had just left.
Paul
-
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: evading ulimits
On Dec 23 2006 19:42, John Richard Moser wrote: >Jan Engelhardt wrote: >> >> Note that trying to kill all shells is a race between killing them all first >> and them spawning new ones everytime. To stop fork bombs, use killall -STOP >> first, then kill them. > >Yes I know; the point, though, is that they should die automatically >when the process count hits 4096. They do with the first fork bomb; >they keep growing with the second, well past what they should. They don't just all die when you hit 4096. If you do nothing, 4096 +/- n will stay around. -`J' -- - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Linus Torvalds wrote: On Wed, 13 Dec 2006, Greg KH wrote: Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Btw, I really think this is shortsighted. It will only result in _exactly_ the crap we were just trying to avoid, namely stupid "shell game" drivers that don't actually help anything at all, and move code into user space instead. What was the point again? Was the point to alienate people by showing how we're less about the technology than about licenses? Was the point to show that we think we can extend our reach past derived work boundaries by just saying so? The silly thing is, the people who tend to push most for this are the exact SAME people who say that the RIAA etc should not be able to tell people what to do with the music copyrights that they own, and that the DMCA is bad because it puts technical limits over the rights expressly granted by copyright law. Doesn't anybody else see that as being hypocritical? So it's ok when we do it, but bad when other people do it? Somehow I'm not surprised, but I still think it's sad how you guys are showing a marked two-facedness about this. The fact is, the reason I don't think we should force the issue is very simple: copyright law is simply _better_off_ when you honor the admittedly gray issue of "derived work". It's gray. It's not black-and-white. But being gray is _good_. Putting artificial black-and-white technical counter-measures is actually bad. It's bad when the RIAA does it, it's bad when anybody else does it. If a module arguably isn't a derived work, we simply shouldn't try to say that its authors have to conform to our worldview. We should make decisions on TECHNICAL MERIT. And this one is clearly being pushed on anything but. I agree with Linus on these points. The kernel should not be enforcing these issues. Leave the lawyers to do that bit. If companies want to play in the "Grey Area", then it is at their own risk. Binary drivers are already difficult and expensive for the companies because they have to keep updating them as we change the kernel versions. If they do open source drivers, we update them for them as we change the kernel versions, so it works out cheaper for the companies involved. The open source community tends to be able to reverse engineer all drivers eventually anyway in order to ensure compatibility with all kernel versions and also ensure that the code is well reviewed and therefore contains fewer security loopholes, e.g. Atheros Wireless open source HAL. This also tends to make it rather pointless for companies to do binary drivers, because all it does is delay the open source version of the driver and increase the security risk to users. One other example I have, is that I reverse engineered a sound card driver so that we had an open source driver for it. Once I had manually documented the sound card, so we had details of all the registers and how to use them, the manufacturer finally sent the datasheet to me! A bit late really, but it certainly did encourage the manufacturer to pass datasheets to developers. I now have a large array of datasheets from this manufacturer that save me having to reverse engineer other sound cards in their range. Making binary drivers is therefore not a viable way to protect IP. We are slowly removing the excuses that companies can hide behind as reasons for not releasing datasheets to open source driver developers. James - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006, Andrew Morton wrote: > > > I now _suspect_ that we're talking about something like > > > > - we started a writeout. The IO is still pending, and the page was > >marked clean and is now in the "writeback" phase. > > - a write happens to the page, and the page gets marked dirty again. > >Marking the page dirty also marks all the _buffers_ in the page dirty, > >but they were actually already dirty, because the IO hasn't completed > >yet. > > - the IO from the _previous_ write completes, and marks the buffers clean > >again. > > Some things for the testers to try, please: > > - mount the fs with ext2 with the no-buffer-head option. That means either: [ snip snip ] This is definitely worth testing, but the exact schenario I outlined is probably not the thing that happens. It was really meant to be more of an exmple of the _kind_ of situation I think we might have. That would explain why we didn't see this before: we simply didn't mark pages clean all that aggressively, and an app like rtorrent would normally have caused its flushes to happen _synchronously_ by using msync() (even if the IO itself was done asynchronously, all the dirty bit stuff would be synchronous wrt any rtorrent behaviour). And the things that /did/ use to clean pages asynchronously (VM scanning) would always actually look at the "young" bit (aka "accessed") and not even touch the dirty bit if an application had accessed the page recently, so that basically avoided any likely races, because we'd touch the dirty bit ONLY if the page was "cold". So this is why I'm saying that it might be an old bug, and it would be just the new pattern of handling dirty bits that triggers it. But avoiding buffer heads and testing that part is worth doing. Just to remove one thing from the equation. Linus - 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 v4 01/13] Linux RDMA Core Changes
> diff --git a/drivers/infiniband/hw/mthca/mthca_cq.c
> b/drivers/infiniband/hw/mthca/mthca_cq.c
> index 283d50b..15cbd49 100644
> --- a/drivers/infiniband/hw/mthca/mthca_cq.c
> +++ b/drivers/infiniband/hw/mthca/mthca_cq.c
> @@ -722,7 +722,8 @@ repoll:
> return err == 0 || err == -EAGAIN ? npolled : err;
> }
>
> -int mthca_tavor_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify)
> +int mthca_tavor_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify,
> +struct ib_udata *udata)
> {
> __be32 doorbell[2];
>
> @@ -739,7 +740,8 @@ int mthca_tavor_arm_cq(struct ib_cq *cq,
> return 0;
> }
>
> -int mthca_arbel_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify)
> +int mthca_arbel_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify,
> +struct ib_udata *udata)
> {
> struct mthca_cq *cq = to_mcq(ibcq);
> __be32 doorbell[2];
> diff --git a/drivers/infiniband/hw/mthca/mthca_dev.h
> b/drivers/infiniband/hw/mthca/mthca_dev.h
> index fe5cecf..6b9ccf6 100644
> --- a/drivers/infiniband/hw/mthca/mthca_dev.h
> +++ b/drivers/infiniband/hw/mthca/mthca_dev.h
> @@ -493,8 +493,8 @@ void mthca_unmap_eq_icm(struct mthca_dev
>
> int mthca_poll_cq(struct ib_cq *ibcq, int num_entries,
> struct ib_wc *entry);
> -int mthca_tavor_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify);
> -int mthca_arbel_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify);
> +int mthca_tavor_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify, struct
> ib_udata *udata);
> +int mthca_arbel_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify, struct
> ib_udata *udata);
> int mthca_init_cq(struct mthca_dev *dev, int nent,
> struct mthca_ucontext *ctx, u32 pdn,
> struct mthca_cq *cq);
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 8eacc35..e3e1a2c 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -941,7 +941,8 @@ struct ib_device {
> struct ib_wc *wc);
> int(*peek_cq)(struct ib_cq *cq, int wc_cnt);
> int(*req_notify_cq)(struct ib_cq *cq,
> - enum ib_cq_notify
> cq_notify);
> + enum ib_cq_notify cq_notify,
> + struct ib_udata *udata);
> int(*req_ncomp_notif)(struct ib_cq *cq,
> int wc_cnt);
> struct ib_mr * (*get_dma_mr)(struct ib_pd *pd,
> @@ -1373,7 +1374,7 @@ int ib_peek_cq(struct ib_cq *cq, int wc_
> static inline int ib_req_notify_cq(struct ib_cq *cq,
> enum ib_cq_notify cq_notify)
> {
> - return cq->device->req_notify_cq(cq, cq_notify);
> + return cq->device->req_notify_cq(cq, cq_notify, NULL);
> }
>
> /**
Can't say I like this adding overhead in data path operations (and note this
can't be optimized out). And kernel consumers work without passing it in, so it
hurts kernel code even for Chelsio. Granted, the cost is small here, but these
things do tend to add up.
It seems all Chelsio needs is to pass in a consumer index - so, how about a new
entry point? Something like void set_cq_udata(struct ib_cq *cq, struct ib_udata
*udata)?
--
MST
-
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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006 00:43:54 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: > I now _suspect_ that we're talking about something like > > - we started a writeout. The IO is still pending, and the page was >marked clean and is now in the "writeback" phase. > - a write happens to the page, and the page gets marked dirty again. >Marking the page dirty also marks all the _buffers_ in the page dirty, >but they were actually already dirty, because the IO hasn't completed >yet. > - the IO from the _previous_ write completes, and marks the buffers clean >again. Some things for the testers to try, please: - mount the fs with ext2 with the no-buffer-head option. That means either: grub.conf: rootfstype=ext2 rootflags=nobh /etc/fstab: ext2 nobh - mount the fs with ext3 data=writeback, nobh grub.conf: rootfstype=ext3 rootflags=nobh,data=writeback (I hope this works) /etc/fstab: ext2 data=writeback,nobh if that still fails we can rule out buffer_head funnies. - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006, Gordon Farquharson wrote: > > Is there any way to provide any debugging information that may help > solve the problem ? I think we have people working on this. I know I'm trying to even come up with an idea of what is going on. I don't think we know yet. > Would it help to know the nature of the corruption e.g. an analysis > of the corruption in the file ? I actually think we know that, because Andrei already gave details. The corruption seems to be basically a few pages that get zeroes at the end rather than the expected contents. That's consistent with the page being written out once, but then _not_ getting written out again despite being dirtied some more. But if you see ay other pattern, please holler, because that would be interesting. > BTW, I decided to try Linus's test program [1] on ARM (I don't think > that anybody had tried it on ARM before). You get the expected results, and in fact, I'd be very surprised if you didn't. It's something subtler than that going on. I now _suspect_ that we're talking about something like - we started a writeout. The IO is still pending, and the page was marked clean and is now in the "writeback" phase. - a write happens to the page, and the page gets marked dirty again. Marking the page dirty also marks all the _buffers_ in the page dirty, but they were actually already dirty, because the IO hasn't completed yet. - the IO from the _previous_ write completes, and marks the buffers clean again. And no, thatr's not actually what is going on. The thing is, we actually clear the buffer dirty bits when we start the IO, not when we end it, but I think it is going to be this _kind_ of situation, where we missed something, and marked it clean too late, and thus cleared a dirty bit. I don't think it's a page table issue any more, it just doesn't look likely with the ARM UP corruption. It's also not apparently even on a cacheline boundary, so it probably is really a dirty bit that got cleared wrogn due to some race with IO. But right now we're all clueless. I personally suspect it's not even a new bug: it's probably an old bug that simply didn't matter before. Linus - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On 12/22/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-22 14:25]:
> > and it failed.
> Since you are on ARM you might want to try with the page_mkclean_one
> cleanup patch too.
I've already tried it and it didn't work. I just tried it again
together with Linus' patch and the two from Andrew and it still fails.
(For reference, the patch is attached.)
I can confirm this behaviour with 2.6.19 and the patches mentioned
above (cumulative patch for 2.6.19 appended to the end of this email).
Is there any way to provide any debugging information that may help
solve the problem ? Would it help to know the nature of the corruption
e.g. an analysis of the corruption in the file ? I have previously
asked apt developers if they wanted to look at the corrupted cache
files, but there were no takers then.
BTW, I decided to try Linus's test program [1] on ARM (I don't think
that anybody had tried it on ARM before).
Since we see file corruption with 2.6.18 + [PATCH] mm: tracking shared
dirty pages [2], I ran Linus's program on machines with the following
setups:
2.6.18 + the following patches
mm: tracking shared dirty pages [2]
mm: balance dirty pages [3]
mm: optimize the new mprotect() code a bit [4]
mm: small cleanup of install_page() [5]
mm: fixup do_wp_page() [6]
mm: msync() cleanup [7]
$ ./mm-test | od -x
000
020
040
050
2.6.18 (no mm patches)
$ ./mm-test | od -x
000
020
040
050
I don't know if this helps at all.
Gordon
[1] http://lkml.org/lkml/2006/12/19/200
[2]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d08b3851da41d0ee60851f2c75b118e1f7a5fc89
[3]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=edc79b2a46ed854595e40edcf3f8b37f9f14aa3f
[4]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c1e6098b23bb46e2b488fe9a26f831f867157483
[5]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e88dd6c11c5aef74d8b74a062767add53315533b
[6]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ee6a6457886a80415db209e87033b63f2b06558c
[7]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=204ec841fbea3e5138168edbc3a76d46747cc987
diff -Naupr linux-2.6.19.orig/fs/buffer.c linux-2.6.19/fs/buffer.c
--- linux-2.6.19.orig/fs/buffer.c 2006-11-29 14:57:37.0 -0700
+++ linux-2.6.19/fs/buffer.c2006-12-21 01:16:31.0 -0700
@@ -2832,7 +2832,7 @@ int try_to_free_buffers(struct page *pag
int ret = 0;
BUG_ON(!PageLocked(page));
- if (PageWriteback(page))
+ if (PageDirty(page) || PageWriteback(page))
return 0;
if (mapping == NULL) { /* can this still happen? */
@@ -2843,17 +2843,6 @@ int try_to_free_buffers(struct page *pag
spin_lock(>private_lock);
ret = drop_buffers(page, _to_free);
spin_unlock(>private_lock);
- if (ret) {
- /*
-* If the filesystem writes its buffers by hand (eg ext3)
-* then we can have clean buffers against a dirty page. We
-* clean the page here; otherwise later reattachment of buffers
-* could encounter a non-uptodate page, which is unresolvable.
-* This only applies in the rare case where try_to_free_buffers
-* succeeds but the page is not freed.
-*/
- clear_page_dirty(page);
- }
out:
if (buffers_to_free) {
struct buffer_head *bh = buffers_to_free;
diff -Naupr linux-2.6.19.orig/fs/hugetlbfs/inode.c
linux-2.6.19/fs/hugetlbfs/inode.c
--- linux-2.6.19.orig/fs/hugetlbfs/inode.c 2006-11-29
14:57:37.0 -0700
+++ linux-2.6.19/fs/hugetlbfs/inode.c 2006-12-21 01:15:21.0 -0700
@@ -176,7 +176,7 @@ static int hugetlbfs_commit_write(struct
static void truncate_huge_page(struct page *page)
{
- clear_page_dirty(page);
+ cancel_dirty_page(page, /* No IO accounting for huge pages? */0);
ClearPageUptodate(page);
remove_from_page_cache(page);
put_page(page);
diff -Naupr linux-2.6.19.orig/include/linux/page-flags.h
linux-2.6.19/include/linux/page-flags.h
--- linux-2.6.19.orig/include/linux/page-flags.h2006-11-29
14:57:37.0 -0700
+++ linux-2.6.19/include/linux/page-flags.h 2006-12-21
01:15:21.0 -0700
@@ -253,15 +253,11 @@ static inline void SetPageUptodate(struc
struct page; /* forward declaration */
-int test_clear_page_dirty(struct page *page);
+extern void cancel_dirty_page(struct page *page, unsigned int account_size);
+
int test_clear_page_writeback(struct
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On 12/22/06, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Peter Zijlstra [EMAIL PROTECTED] [2006-12-22 14:25]:
and it failed.
Since you are on ARM you might want to try with the page_mkclean_one
cleanup patch too.
I've already tried it and it didn't work. I just tried it again
together with Linus' patch and the two from Andrew and it still fails.
(For reference, the patch is attached.)
I can confirm this behaviour with 2.6.19 and the patches mentioned
above (cumulative patch for 2.6.19 appended to the end of this email).
Is there any way to provide any debugging information that may help
solve the problem ? Would it help to know the nature of the corruption
e.g. an analysis of the corruption in the file ? I have previously
asked apt developers if they wanted to look at the corrupted cache
files, but there were no takers then.
BTW, I decided to try Linus's test program [1] on ARM (I don't think
that anybody had tried it on ARM before).
Since we see file corruption with 2.6.18 + [PATCH] mm: tracking shared
dirty pages [2], I ran Linus's program on machines with the following
setups:
2.6.18 + the following patches
mm: tracking shared dirty pages [2]
mm: balance dirty pages [3]
mm: optimize the new mprotect() code a bit [4]
mm: small cleanup of install_page() [5]
mm: fixup do_wp_page() [6]
mm: msync() cleanup [7]
$ ./mm-test | od -x
000
020
040
050
2.6.18 (no mm patches)
$ ./mm-test | od -x
000
020
040
050
I don't know if this helps at all.
Gordon
[1] http://lkml.org/lkml/2006/12/19/200
[2]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d08b3851da41d0ee60851f2c75b118e1f7a5fc89
[3]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=edc79b2a46ed854595e40edcf3f8b37f9f14aa3f
[4]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c1e6098b23bb46e2b488fe9a26f831f867157483
[5]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e88dd6c11c5aef74d8b74a062767add53315533b
[6]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ee6a6457886a80415db209e87033b63f2b06558c
[7]
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=204ec841fbea3e5138168edbc3a76d46747cc987
diff -Naupr linux-2.6.19.orig/fs/buffer.c linux-2.6.19/fs/buffer.c
--- linux-2.6.19.orig/fs/buffer.c 2006-11-29 14:57:37.0 -0700
+++ linux-2.6.19/fs/buffer.c2006-12-21 01:16:31.0 -0700
@@ -2832,7 +2832,7 @@ int try_to_free_buffers(struct page *pag
int ret = 0;
BUG_ON(!PageLocked(page));
- if (PageWriteback(page))
+ if (PageDirty(page) || PageWriteback(page))
return 0;
if (mapping == NULL) { /* can this still happen? */
@@ -2843,17 +2843,6 @@ int try_to_free_buffers(struct page *pag
spin_lock(mapping-private_lock);
ret = drop_buffers(page, buffers_to_free);
spin_unlock(mapping-private_lock);
- if (ret) {
- /*
-* If the filesystem writes its buffers by hand (eg ext3)
-* then we can have clean buffers against a dirty page. We
-* clean the page here; otherwise later reattachment of buffers
-* could encounter a non-uptodate page, which is unresolvable.
-* This only applies in the rare case where try_to_free_buffers
-* succeeds but the page is not freed.
-*/
- clear_page_dirty(page);
- }
out:
if (buffers_to_free) {
struct buffer_head *bh = buffers_to_free;
diff -Naupr linux-2.6.19.orig/fs/hugetlbfs/inode.c
linux-2.6.19/fs/hugetlbfs/inode.c
--- linux-2.6.19.orig/fs/hugetlbfs/inode.c 2006-11-29
14:57:37.0 -0700
+++ linux-2.6.19/fs/hugetlbfs/inode.c 2006-12-21 01:15:21.0 -0700
@@ -176,7 +176,7 @@ static int hugetlbfs_commit_write(struct
static void truncate_huge_page(struct page *page)
{
- clear_page_dirty(page);
+ cancel_dirty_page(page, /* No IO accounting for huge pages? */0);
ClearPageUptodate(page);
remove_from_page_cache(page);
put_page(page);
diff -Naupr linux-2.6.19.orig/include/linux/page-flags.h
linux-2.6.19/include/linux/page-flags.h
--- linux-2.6.19.orig/include/linux/page-flags.h2006-11-29
14:57:37.0 -0700
+++ linux-2.6.19/include/linux/page-flags.h 2006-12-21
01:15:21.0 -0700
@@ -253,15 +253,11 @@ static inline void SetPageUptodate(struc
struct page; /* forward declaration */
-int test_clear_page_dirty(struct page *page);
+extern void cancel_dirty_page(struct page *page, unsigned int account_size);
+
int
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006, Gordon Farquharson wrote: Is there any way to provide any debugging information that may help solve the problem ? I think we have people working on this. I know I'm trying to even come up with an idea of what is going on. I don't think we know yet. Would it help to know the nature of the corruption e.g. an analysis of the corruption in the file ? I actually think we know that, because Andrei already gave details. The corruption seems to be basically a few pages that get zeroes at the end rather than the expected contents. That's consistent with the page being written out once, but then _not_ getting written out again despite being dirtied some more. But if you see ay other pattern, please holler, because that would be interesting. BTW, I decided to try Linus's test program [1] on ARM (I don't think that anybody had tried it on ARM before). You get the expected results, and in fact, I'd be very surprised if you didn't. It's something subtler than that going on. I now _suspect_ that we're talking about something like - we started a writeout. The IO is still pending, and the page was marked clean and is now in the writeback phase. - a write happens to the page, and the page gets marked dirty again. Marking the page dirty also marks all the _buffers_ in the page dirty, but they were actually already dirty, because the IO hasn't completed yet. - the IO from the _previous_ write completes, and marks the buffers clean again. And no, thatr's not actually what is going on. The thing is, we actually clear the buffer dirty bits when we start the IO, not when we end it, but I think it is going to be this _kind_ of situation, where we missed something, and marked it clean too late, and thus cleared a dirty bit. I don't think it's a page table issue any more, it just doesn't look likely with the ARM UP corruption. It's also not apparently even on a cacheline boundary, so it probably is really a dirty bit that got cleared wrogn due to some race with IO. But right now we're all clueless. I personally suspect it's not even a new bug: it's probably an old bug that simply didn't matter before. Linus - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006 00:43:54 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: I now _suspect_ that we're talking about something like - we started a writeout. The IO is still pending, and the page was marked clean and is now in the writeback phase. - a write happens to the page, and the page gets marked dirty again. Marking the page dirty also marks all the _buffers_ in the page dirty, but they were actually already dirty, because the IO hasn't completed yet. - the IO from the _previous_ write completes, and marks the buffers clean again. Some things for the testers to try, please: - mount the fs with ext2 with the no-buffer-head option. That means either: grub.conf: rootfstype=ext2 rootflags=nobh /etc/fstab: ext2 nobh - mount the fs with ext3 data=writeback, nobh grub.conf: rootfstype=ext3 rootflags=nobh,data=writeback (I hope this works) /etc/fstab: ext2 data=writeback,nobh if that still fails we can rule out buffer_head funnies. - 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 v4 01/13] Linux RDMA Core Changes
diff --git a/drivers/infiniband/hw/mthca/mthca_cq.c
b/drivers/infiniband/hw/mthca/mthca_cq.c
index 283d50b..15cbd49 100644
--- a/drivers/infiniband/hw/mthca/mthca_cq.c
+++ b/drivers/infiniband/hw/mthca/mthca_cq.c
@@ -722,7 +722,8 @@ repoll:
return err == 0 || err == -EAGAIN ? npolled : err;
}
-int mthca_tavor_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify)
+int mthca_tavor_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify,
+struct ib_udata *udata)
{
__be32 doorbell[2];
@@ -739,7 +740,8 @@ int mthca_tavor_arm_cq(struct ib_cq *cq,
return 0;
}
-int mthca_arbel_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify)
+int mthca_arbel_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify,
+struct ib_udata *udata)
{
struct mthca_cq *cq = to_mcq(ibcq);
__be32 doorbell[2];
diff --git a/drivers/infiniband/hw/mthca/mthca_dev.h
b/drivers/infiniband/hw/mthca/mthca_dev.h
index fe5cecf..6b9ccf6 100644
--- a/drivers/infiniband/hw/mthca/mthca_dev.h
+++ b/drivers/infiniband/hw/mthca/mthca_dev.h
@@ -493,8 +493,8 @@ void mthca_unmap_eq_icm(struct mthca_dev
int mthca_poll_cq(struct ib_cq *ibcq, int num_entries,
struct ib_wc *entry);
-int mthca_tavor_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify);
-int mthca_arbel_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify);
+int mthca_tavor_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify, struct
ib_udata *udata);
+int mthca_arbel_arm_cq(struct ib_cq *cq, enum ib_cq_notify notify, struct
ib_udata *udata);
int mthca_init_cq(struct mthca_dev *dev, int nent,
struct mthca_ucontext *ctx, u32 pdn,
struct mthca_cq *cq);
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 8eacc35..e3e1a2c 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -941,7 +941,8 @@ struct ib_device {
struct ib_wc *wc);
int(*peek_cq)(struct ib_cq *cq, int wc_cnt);
int(*req_notify_cq)(struct ib_cq *cq,
- enum ib_cq_notify
cq_notify);
+ enum ib_cq_notify cq_notify,
+ struct ib_udata *udata);
int(*req_ncomp_notif)(struct ib_cq *cq,
int wc_cnt);
struct ib_mr * (*get_dma_mr)(struct ib_pd *pd,
@@ -1373,7 +1374,7 @@ int ib_peek_cq(struct ib_cq *cq, int wc_
static inline int ib_req_notify_cq(struct ib_cq *cq,
enum ib_cq_notify cq_notify)
{
- return cq-device-req_notify_cq(cq, cq_notify);
+ return cq-device-req_notify_cq(cq, cq_notify, NULL);
}
/**
Can't say I like this adding overhead in data path operations (and note this
can't be optimized out). And kernel consumers work without passing it in, so it
hurts kernel code even for Chelsio. Granted, the cost is small here, but these
things do tend to add up.
It seems all Chelsio needs is to pass in a consumer index - so, how about a new
entry point? Something like void set_cq_udata(struct ib_cq *cq, struct ib_udata
*udata)?
--
MST
-
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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006, Andrew Morton wrote: I now _suspect_ that we're talking about something like - we started a writeout. The IO is still pending, and the page was marked clean and is now in the writeback phase. - a write happens to the page, and the page gets marked dirty again. Marking the page dirty also marks all the _buffers_ in the page dirty, but they were actually already dirty, because the IO hasn't completed yet. - the IO from the _previous_ write completes, and marks the buffers clean again. Some things for the testers to try, please: - mount the fs with ext2 with the no-buffer-head option. That means either: [ snip snip ] This is definitely worth testing, but the exact schenario I outlined is probably not the thing that happens. It was really meant to be more of an exmple of the _kind_ of situation I think we might have. That would explain why we didn't see this before: we simply didn't mark pages clean all that aggressively, and an app like rtorrent would normally have caused its flushes to happen _synchronously_ by using msync() (even if the IO itself was done asynchronously, all the dirty bit stuff would be synchronous wrt any rtorrent behaviour). And the things that /did/ use to clean pages asynchronously (VM scanning) would always actually look at the young bit (aka accessed) and not even touch the dirty bit if an application had accessed the page recently, so that basically avoided any likely races, because we'd touch the dirty bit ONLY if the page was cold. So this is why I'm saying that it might be an old bug, and it would be just the new pattern of handling dirty bits that triggers it. But avoiding buffer heads and testing that part is worth doing. Just to remove one thing from the equation. Linus - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Linus Torvalds wrote: On Wed, 13 Dec 2006, Greg KH wrote: Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Btw, I really think this is shortsighted. It will only result in _exactly_ the crap we were just trying to avoid, namely stupid shell game drivers that don't actually help anything at all, and move code into user space instead. What was the point again? Was the point to alienate people by showing how we're less about the technology than about licenses? Was the point to show that we think we can extend our reach past derived work boundaries by just saying so? The silly thing is, the people who tend to push most for this are the exact SAME people who say that the RIAA etc should not be able to tell people what to do with the music copyrights that they own, and that the DMCA is bad because it puts technical limits over the rights expressly granted by copyright law. Doesn't anybody else see that as being hypocritical? So it's ok when we do it, but bad when other people do it? Somehow I'm not surprised, but I still think it's sad how you guys are showing a marked two-facedness about this. The fact is, the reason I don't think we should force the issue is very simple: copyright law is simply _better_off_ when you honor the admittedly gray issue of derived work. It's gray. It's not black-and-white. But being gray is _good_. Putting artificial black-and-white technical counter-measures is actually bad. It's bad when the RIAA does it, it's bad when anybody else does it. If a module arguably isn't a derived work, we simply shouldn't try to say that its authors have to conform to our worldview. We should make decisions on TECHNICAL MERIT. And this one is clearly being pushed on anything but. I agree with Linus on these points. The kernel should not be enforcing these issues. Leave the lawyers to do that bit. If companies want to play in the Grey Area, then it is at their own risk. Binary drivers are already difficult and expensive for the companies because they have to keep updating them as we change the kernel versions. If they do open source drivers, we update them for them as we change the kernel versions, so it works out cheaper for the companies involved. The open source community tends to be able to reverse engineer all drivers eventually anyway in order to ensure compatibility with all kernel versions and also ensure that the code is well reviewed and therefore contains fewer security loopholes, e.g. Atheros Wireless open source HAL. This also tends to make it rather pointless for companies to do binary drivers, because all it does is delay the open source version of the driver and increase the security risk to users. One other example I have, is that I reverse engineered a sound card driver so that we had an open source driver for it. Once I had manually documented the sound card, so we had details of all the registers and how to use them, the manufacturer finally sent the datasheet to me! A bit late really, but it certainly did encourage the manufacturer to pass datasheets to developers. I now have a large array of datasheets from this manufacturer that save me having to reverse engineer other sound cards in their range. Making binary drivers is therefore not a viable way to protect IP. We are slowly removing the excuses that companies can hide behind as reasons for not releasing datasheets to open source driver developers. James - 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: evading ulimits
On Dec 23 2006 19:42, John Richard Moser wrote: Jan Engelhardt wrote: Note that trying to kill all shells is a race between killing them all first and them spawning new ones everytime. To stop fork bombs, use killall -STOP first, then kill them. Yes I know; the point, though, is that they should die automatically when the process count hits 4096. They do with the first fork bomb; they keep growing with the second, well past what they should. They don't just all die when you hit 4096. If you do nothing, 4096 +/- n will stay around. -`J' -- - 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 6/6] containers: BeanCounters over generic process containers
On 12/23/06, Herbert Poetzl [EMAIL PROTECTED] wrote:
On Fri, Dec 22, 2006 at 06:14:48AM -0800, Paul Menage wrote:
This patch implements the BeanCounter resource control abstraction
over generic process containers. It contains the beancounter core
code, plus the numfiles resource counter. It doesn't currently contain
any of the memory tracking code or the code for switching beancounter
context in interrupts.
I don't like it, it looks bloated and probably
adds plenty of overhead (similar to the OVZ
implementation where this seems to be taken from)
Yes - perhaps I should have been clearer in the patch description.
It's basically code taken from the OpenVZ bean counters patches that
have been posted recently, but with the filesystem and process
tracking code ripped out (since it's implemented over the generic
containers).
The main point of this patch is to demonstrate that UBC can be
implemented effectively over generic containers, rather than to be a
proposal in favour of UBC versus any of the other potential resource
control mechanisms.
Most of your comments are about code taken pretty much directly from
the UBC patches, so I won't address them.
+int bc_file_charge(struct file *file)
+{
+ int sev;
+ struct beancounter *bc;
+
+ task_lock(current);
why do we lock current? it won't go away that
easily, and for switching the bc, it might be
better to use RCU or a separate lock, no?
The locking model (taken originally from the Cpusets code) in generic
containers is that while you can use RCU to guarantee that a pointer
read from current-container remains valid until you exit the RCU
critical section, if you want to make consistent changes to data
referenced from a task P's container, you need to hold either
P-alloc_lock or one of the two container mutexes (manage_mutex and/or
callback_mutex).
In this particular case (sorry, not on the VPN right now to be able to
figure out the potential code changes) the fact that the call to
css_get_current() uses atomic operations (currently a spinlock, but I
suspect I could optimize it to be a cmpxchg) could mean that we can
skip the task_lock(), at the cost of occasionally accounting a file to
the container that the task had just left.
Paul
-
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: ptrace() memory corruption?
Jiri Slaby wrote: Pavel Machek wrote: Is there something wrong with gdb? Yep. If I do gdb /bin/bash, run; I'll get similar oops. Am I alone seeing this? Nope, I have this nasty thing here too and will post oopses in the afternoon, just before Jezisek comes :). Ok, I captured this through netconosle: [8.499155] usb 3-2: new low speed USB device using uhci_hcd and address 2 [8.721946] usb 3-2: new device found, idVendor=045e, idProduct=00f0 [8.722016] usb 3-2: new device strings: Mfr=1, Product=2, SerialNumber=0 [8.722081] usb 3-2: Product: Microsoft � Laser Mouse 6000 [8.722145] usb 3-2: Manufacturer: Microsoft Corporation [8.722344] usb 3-2: configuration #1 chosen from 1 choice [8.753100] input: Microsoft Corporation Microsoft � Laser Mouse 6000 as /class/input/input4 [8.753310] input: USB HID v1.11 Mouse [Microsoft Corporation Microsoft � Laser Mouse 6000] on usb-:00:1d.1-2 [ 58.672510] WARNING (!__warned) at /home/l/latest/xxx/kernel/softirq.c:137 local_bh_enable() [ 58.672562] [c0103f1b] show_trace_log_lvl+0x1a/0x30 [ 58.672682] [c01045d5] show_trace+0x12/0x14 [ 58.672787] [c010465c] dump_stack+0x16/0x18 [ 58.672893] [c0126ccc] local_bh_enable+0x8c/0x9b [ 58.672998] [c030a499] lock_sock_nested+0xa3/0xab [ 58.673107] [c03080e1] sock_fasync+0x3e/0x145 [ 58.673216] [c0309056] sock_close+0x19/0x3d [ 58.673322] [c0165baf] __fput+0xa6/0x161 [ 58.673432] [c0165e25] fput+0x22/0x3b [ 58.673538] [c016358a] filp_close+0x41/0x67 [ 58.673646] [c01645f3] sys_close+0x67/0xaf [ 58.673753] [c0102fe4] syscall_call+0x7/0xb [ 58.673855] === [ 58.674091] [ cut here ] [ 58.674158] kernel BUG at /home/l/latest/xxx/fs/buffer.c:1244! [ 58.674224] invalid opcode: [#1] [ 58.674286] SMP [ 58.674414] last sysfs file: /devices/platform/i2c-9191/9191-0290/fan3_min [ 58.674478] Modules linked in: eth1394 floppy ohci1394 ieee1394 ide_cd cdrom [ 58.674778] CPU:1 [ 58.674779] EIP:0060:[c0181fa0]Not tainted VLI [ 58.674780] EFLAGS: 00010046 (2.6.20-rc1-mm1 #207) [ 58.674971] EIP is at __find_get_block+0x165/0x171 [ 58.675035] eax: 0092 ebx: f78e6ec0 ecx: 1000 edx: 8025 [ 58.675101] esi: 0001 edi: 1000 ebp: f76efc6c esp: f76efc34 [ 58.675166] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 58.675232] Process bash (pid: 1595, ti=f76ee000 task=c1a40560 task.ti=f76ee000) [ 58.675297] Stack: c1b31ac0 f7df7e3c 003a c1b31bd0 f76efc74 c0181bb4 0001 [ 58.675693]f7df7e3c f76efc74 c0181544 f78e6ec0 0001 1000 f76efc9c c0181fc2 [ 58.676083]f76efcb4 c0181eab 8025 c1b31ac0 f74e5d40 f76efcb8 c01aa46a f78e6ec0 [ 58.676476] Call Trace: [ 58.676594] [c0103f1b] show_trace_log_lvl+0x1a/0x30 [ 58.676692] [c0103fd6] show_stack_log_lvl+0xa5/0xca [ 58.676789] [c01041ce] show_registers+0x1d3/0x2b8 [ 58.676887] [c01043d4] die+0x121/0x243 [ 58.676984] [c010456c] do_trap+0x76/0x9c [ 58.677083] [c0104dcf] do_invalid_op+0x97/0xa1 [ 58.677181] [c038a7e4] error_code+0x7c/0x84 [ 58.677278] [c0181fc2] __getblk+0x16/0x20a [ 58.677375] [c019ec64] __ext3_get_inode_loc+0x139/0x332 [ 58.677476] [c019ee71] ext3_get_inode_loc+0x14/0x16 [ 58.677575] [c019ee93] ext3_reserve_inode_write+0x20/0x6c [ 58.677674] [c019eeff] ext3_mark_inode_dirty+0x20/0x37 [ 58.62] [c01a1cd0] ext3_dirty_inode+0x6b/0x6d [ 58.677871] [c017e7c4] __mark_inode_dirty+0x2a/0x170 [ 58.677969] [c0176d3c] touch_atime+0xb4/0xe8 [ 58.678067] [c016ce4d] __link_path_walk+0x91e/0xcb6 [ 58.678164] [c016d22b] link_path_walk+0x46/0xc3 [ 58.678262] [c016d46f] do_path_lookup+0x86/0x1b0 [ 58.678359] [c016df00] __path_lookup_intent_open+0x44/0x7f [ 58.678457] [c016dfb3] path_lookup_open+0x21/0x27 [ 58.678555] [c016e088] open_namei+0x62/0x5cb [ 58.678653] [c01638d2] do_filp_open+0x26/0x43 [ 58.678750] [c0163930] do_sys_open+0x41/0xca [ 58.678847] [c01639f1] sys_open+0x1c/0x1e [ 58.678943] [c0102fe4] syscall_call+0x7/0xb [ 58.679040] === [ 58.679101] Code: 45 d0 e8 b6 f5 ff ff e9 22 ff ff ff 89 d8 e8 aa f5 ff ff eb 8c 89 ce 8d 4e ff 8b 04 8f 89 04 b7 85 c9 75 f1 89 1f e9 f6 fe ff ff 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 55 89 e5 57 56 53 83 ec 1c [ 58.681386] EIP: [c0181fa0] __find_get_block+0x165/0x171 SS:ESP 0068:f76efc34 [ 58.681545] after gdb /bin/bash (gdb) run regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
James Courtier-Dutton wrote: I agree with Linus on these points. The kernel should not be enforcing these issues. Leave the lawyers to do that bit. If companies want to play in the Grey Area, then it is at their own risk. Binary drivers are already difficult and expensive for the companies because they have to keep updating them as we change the kernel versions. If they do open source drivers, we update them for them as we change the kernel versions, so it works out cheaper for the companies involved. Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them for us. The only way that happens is if they can get in the official tree. I know just from monitoring this list that our drivers would never be acceptable for inclusion in any functional form. We open sourced them purely out of respect for the way we know the community feels about it. It would cost more for us to make them acceptable for inclusion than it does for us to just maintain them ourselves. I suspect that is true for most vendor created drivers open source or not. So kernel developers making the required changes as the kernel changes is NO real incentive for any vendor to open source their drivers. Sorry. If it were knowingly less difficult to actually get your drivers included, that would be an incentive and then you original point would hold as an additional incentive. My humble $.02 worth Regards Mark - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 2006-12-24 at 00:57 -0800, Andrew Morton wrote: On Sun, 24 Dec 2006 00:43:54 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: I now _suspect_ that we're talking about something like - we started a writeout. The IO is still pending, and the page was marked clean and is now in the writeback phase. - a write happens to the page, and the page gets marked dirty again. Marking the page dirty also marks all the _buffers_ in the page dirty, but they were actually already dirty, because the IO hasn't completed yet. - the IO from the _previous_ write completes, and marks the buffers clean again. Some things for the testers to try, please: - mount the fs with ext2 with the no-buffer-head option. That means either: grub.conf: rootfstype=ext2 rootflags=nobh /etc/fstab: ext2 nobh ierdnac ~ # mount /dev/sda7 on / type ext2 (rw,noatime,nobh) I have corruption. - mount the fs with ext3 data=writeback, nobh grub.conf: rootfstype=ext3 rootflags=nobh,data=writeback (I hope this works) /etc/fstab: ext2 data=writeback,nobh ierdnac ~ # mount /dev/sda7 on / type ext3 (rw,noatime,nobh) ierdnac ~ # dmesg|grep EXT3 EXT3-fs: mounted filesystem with writeback data mode. EXT3 FS on sda7, internal journal I don't have corruption. I tested twice. if that still fails we can rule out buffer_head funnies. - 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: ptrace() memory corruption?
On Sun, 24 Dec 2006 12:51:16 +0059 Jiri Slaby [EMAIL PROTECTED] wrote: [ 58.674780] EFLAGS: 00010046 (2.6.20-rc1-mm1 #207) please, test 2.6.20-rc2. We applied a fix for this. - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 2006-12-24 at 14:14 +0200, Andrei Popa wrote: On Sun, 2006-12-24 at 00:57 -0800, Andrew Morton wrote: On Sun, 24 Dec 2006 00:43:54 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: I now _suspect_ that we're talking about something like - we started a writeout. The IO is still pending, and the page was marked clean and is now in the writeback phase. - a write happens to the page, and the page gets marked dirty again. Marking the page dirty also marks all the _buffers_ in the page dirty, but they were actually already dirty, because the IO hasn't completed yet. - the IO from the _previous_ write completes, and marks the buffers clean again. Some things for the testers to try, please: - mount the fs with ext2 with the no-buffer-head option. That means either: grub.conf: rootfstype=ext2 rootflags=nobh /etc/fstab: ext2 nobh ierdnac ~ # mount /dev/sda7 on / type ext2 (rw,noatime,nobh) I have corruption. - mount the fs with ext3 data=writeback, nobh grub.conf: rootfstype=ext3 rootflags=nobh,data=writeback (I hope this works) /etc/fstab: ext2 data=writeback,nobh ierdnac ~ # mount /dev/sda7 on / type ext3 (rw,noatime,nobh) ierdnac ~ # dmesg|grep EXT3 EXT3-fs: mounted filesystem with writeback data mode. EXT3 FS on sda7, internal journal I don't have corruption. I tested twice. I also tested with ext3 ordered, nobh and I have file corruption... if that still fails we can rule out buffer_head funnies. - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006 14:26:01 +0200 Andrei Popa [EMAIL PROTECTED] wrote: I also tested with ext3 ordered, nobh and I have file corruption... ordered+nobh isn't a possible combination. The filesystem probably ignored nobh. nobh mode only makes sense with data=writeback. - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Sun, 24 Dec 2006 14:14:38 +0200 Andrei Popa [EMAIL PROTECTED] wrote: - mount the fs with ext2 with the no-buffer-head option. That means either: grub.conf: rootfstype=ext2 rootflags=nobh /etc/fstab: ext2 nobh ierdnac ~ # mount /dev/sda7 on / type ext2 (rw,noatime,nobh) I have corruption. - mount the fs with ext3 data=writeback, nobh grub.conf: rootfstype=ext3 rootflags=nobh,data=writeback (I hope this works) /etc/fstab: ext2 data=writeback,nobh ierdnac ~ # mount /dev/sda7 on / type ext3 (rw,noatime,nobh) ierdnac ~ # dmesg|grep EXT3 EXT3-fs: mounted filesystem with writeback data mode. EXT3 FS on sda7, internal journal I don't have corruption. I tested twice. This is a surprising result. Can you pleas retest ext3 data=writeback,nobh? - 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: Binary Drivers
Am Sonntag, 24. Dezember 2006 07:46 schrieb [EMAIL PROTECTED]: Are they allowed to sell a car that incorporates a computer that uses a trade-secret algorithm for controlling the fuel injection to get 20 more horsepower and 5% better mileage? That would be a propritary fuel injection driver then. What we want however is access to the documentation, the specifications, that allows us to develop a very own driver, independently from the propritary one. We don't want source code or anything. Of course if the hardware manufactor supplies us with source code, that's great. Probably any customly written driver will be suboptimal in the first place, but OTOH there are so many skilled people around in the OSS scene, that such a driver would surely soon catch up, if not even surpass the propritary one. Happy holydays Wolfgang Draxinger -- sooner or later we'll reverse engineer you. pgpPJ3i0IANWE.pgp Description: PGP signature
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sun, 24 Dec 2006 06:57:58 -0500 Mark Hounschell [EMAIL PROTECTED] wrote: Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them for us. The only way that happens is if they can get in the official tree. I know just from monitoring this list that our drivers would never be acceptable for inclusion in any functional form. We open sourced them purely out of respect for the way we know the community feels about it. That shows some class, thanks. It would cost more for us to make them acceptable for inclusion than it does for us to just maintain them ourselves. I suspect that is true for most vendor created drivers open source or not. So kernel developers making the required changes as the kernel changes is NO real incentive for any vendor to open source their drivers. Sorry. If it were knowingly less difficult to actually get your drivers included, that would be an incentive and then you original point would hold as an additional incentive. Out of curiosity what specific technical issues in your driver code make you think that it would be too expensive to whip them into shape for inclusion? Cheers, Sean - 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: ptrace() memory corruption?
Andrew Morton wrote: On Sun, 24 Dec 2006 12:51:16 +0059 Jiri Slaby [EMAIL PROTECTED] wrote: [ 58.674780] EFLAGS: 00010046 (2.6.20-rc1-mm1 #207) please, test 2.6.20-rc2. We applied a fix for this. It's working now. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: linux 2.6.20-rc1: kernel BUG at fs/buffer.c:1235!
Alex Romosan wrote: this is on a thinkpad t40, not sure if it means anything, but here it goes: kernel: kernel BUG at fs/buffer.c:1235! kernel: invalid opcode: [#1] kernel: PREEMPT kernel: Modules linked in: radeon drm binfmt_misc nfs sd_mod scsi_mod nfsd exportfs lockd sunrpc autofs4 pcmcia firmware_class joydev irtty_sir sir_dev nsc_ircc irda crc_ccitt parport_pc parport ehci_hcd uhci_hcd usbcore aes_i586 airo nls_iso8859_1 ntfs yenta_socket rsrc_nonstatic pcmcia_core kernel: CPU:0 kernel: EIP:0060:[c016ad06]Not tainted VLI kernel: EFLAGS: 00010046 (2.6.20-rc1 #215) Could you test 2.6.20-rc2? It's probably fixed there. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: Linux 2.6.20-rc2
On 12/24/06, Linus Torvalds [EMAIL PROTECTED] wrote: Ok, it's a couple of days delayed, because we've been trying to figure out what is up with the rtorrent hash failures since 2.6.18.3. I don't think we've made any progress, but we've cleaned up a number of suspects in the meantime. It's a bit sad, if only because I was really hoping to make 2.6.20 an easy release, and held back on merging some stuff during the merge window for that reason. And now we're battling something that was introduced much earlier.. Now, practically speaking this isn't likely to affect a lot of people, but it's still a worrisome problem, and we've had top people looking at it. And they'll continue, but xmas is coming. In the meantime, we'll continue with the stabilization, and this mainly does some driver updates (usb, sound, dri, pci hotplug) and ACPI updates (much of the latter syntactic cleanups). And arm and powerpc updates. Shortlog appended. For developers: if you sent me a patch, and I didn't apply it, it was probably just missed because I concentrated on other issues. So pls re-send.. Unless I explicitly told you that I'm not going to pull it due to the merge window being over, of course ;) Linus [shortlog snipped] As already reported multiple times, including at -rc1 time... still need this libata-sff.c patch: http://marc.theaimsgroup.com/?l=linux-kernelm=116343564202844q=raw to have my root device detected, ata_piix probe would otherwise fail as described in this thread: http://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/0690.html Enjoy the holiday season, --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - 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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Andrew Morton [EMAIL PROTECTED] [2006-12-24 00:57]: /etc/fstab: ext2 nobh /etc/fstab: ext3 data=writeback,nobh It seems that busybox mount ignores the nobh option but both ext2 and ext3 data=writeback work for me. This is with plain 2.6.19 which normally always fails. -- Martin Michlmayr http://www.cyrius.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/
