* Re: [PATCH] tg3: add amd8131 to "write reorder" chipsets
From: Michael Chan @ 2006-07-07 21:22 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, davem
John W. Linville wrote:
> Obviously it is between you and Dave to decide what is best. We are
> carrying this patch in RHEL4 at the moment, so I didn't want to hold
> it back from upstream. If you think you have a better solution then
> "it's on you"... :-)
>
Since 2.6.18 already has the recovery logic in place, we can probably
holdoff merging this patch upstream.
If e1000 is having similar problems with a similar AMD chipset, it
must be a fairly widespread problem. It might be a good idea to
push this patch to -stable.
^ permalink raw reply
* Re: [patch] spinlocks: remove 'volatile'
From: linux-os (Dick Johnson) @ 2006-07-07 21:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Krzysztof Halasa, Ingo Molnar, Andrew Morton, Linux kernel, arjan
In-Reply-To: <Pine.LNX.4.64.0607071318570.3869@g5.osdl.org>
On Fri, 7 Jul 2006, Linus Torvalds wrote:
>
>
> On Fri, 7 Jul 2006, linux-os (Dick Johnson) wrote:
>>
>> Now Linus declares that instead of declaring an object volatile
>> so that it is actually accessed every time it is referenced, he wants
>> to use a GNU-ism with assembly that tells the compiler to re-read
>> __every__ variable existing im memory, instead of just one. Go figure!
>
> Actually, it's not just me.
>
> Read things like the Intel CPU documentation.
>
> IT IS ACTIVELY WRONG to busy-loop on a variable. It will make the CPU
> potentially over-heat, causing degreaded performance, and you're simply
> not supposed to do it.
This is a bait and switch argument. The code was displayed to show
the compiler output, not an example of good coding practice.
Furthermore, I'm still waiting for the new spin-friction that's
supposed to cause the increased heat. It doesn't exist and furthermore
no Intel processor instruction manual (that is available for public
inspection) claims that busy-waiting increases any heating, only that
some processors that __can__ fall back into a low-power mode will not
do so if they are spinning (naturally). But this is just another
bait-and-switch as well because I only wrote about volatile and
I even provided references.
>
>> Reference:
>> /usr/src/linux-2.6.16.4/include/linux/compiler-gcc.h:
>> #define barrier() __asm__ __volatile__("": : :"memory")
>
> Actually, for your kind of stupid loop, you should use
>
> - include/asm-i386/processor.h:
> #define cpu_relax() rep_nop()
>
Again, I didn't propose to do that. In fact, your spin-lock
code already inserts "rep nops" and I never implied that they
should be removed. I said only that "volatile" still needs to
be used, not some macro that tells the compiler that everything
in memory probably got trashed. Read what I said, not what you
think some idiot might have said.
> where rep_nop() is
>
> /* REP NOP (PAUSE) is a a good thing to insert into busy-wait loops. */
> static inline void rep_nop(void)
> {
> __asm__ __volatile__("rep;nop": : :"memory");
> }
>
> on x86, and can be other things on other CPU's. On ppc64 it is
>
> #define cpu_relax() do { HMT_low(); HMT_medium(); barrier(); } while (0)
>
> where those HMT macros adjust thread priority.
>
Not either of these things have anything to do with the topic and
I never even implied that they did. Again, I spoke only of the
well known volatile keyword. Nothing else.
> In other words, you just don't know what you're talking about. "volatile"
> is simply not useful, and the fact that you cannot seem to grasp that is
> _your_ problem.
>
Well, in fact I do know what I'm talking about. Your bait-and-switch
arguments just won't work with me.
> Repeat after me (or just shut up about things that you not only don't know
> about, but are apparently not willing to even learn):
>
> "'volatile' is useless. The things it did 30 years ago are much
> more complex these days, and need to be tied to much more
> detailed rules that depend on the actual particular problem,
> rather than one keyword to the compiler that doesn't actually
> give enough information for the compiler to do anything useful"
>
> Comprende?
>
> Linus
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: 2.6.17-mm6 libata stupid question...
From: Valdis.Kletnieks @ 2006-07-07 21:22 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
In-Reply-To: <1152288721.20883.12.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
On Fri, 07 Jul 2006 17:12:01 BST, Alan Cox said:
> The fact you get the same response with drivers/ide rather suggests that
> in this case the problem is cable detection. Tweak ata_piix to print out
> the cable type it detects. If it thinks its a 40 pin cable you know
> where to start
I tried instrumenting ich_pata_cbl_detect(), but it turns out that
the chipset is an ICH3M (lspci ID 8086:248A), which ends up down in
piix_pata_prereset which forces a 40-pin:
ap->cbl = ATA_CBL_PATA40;
Guess that explains that, unless the chipset actually *can* do 80-pin
and has an 80-pin cable (which would be surprising because apparently
none of the other piix variants can...)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: skge error; hangs w/ hardware memory hole
From: Andi Kleen @ 2006-07-07 21:28 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Martin Michlmayr, netdev, linux-kernel, 341801, asd, kevin
In-Reply-To: <20060707141843.73fc6188@dxpl.pdx.osdl.net>
On Friday 07 July 2006 23:18, Stephen Hemminger wrote:
> On Mon, 3 Jul 2006 22:52:38 +0200
> Martin Michlmayr <tbm@cyrius.com> wrote:
>
> > We received the following bug report at http://bugs.debian.org/341801
> >
> > | I have a Asus A8V with 4GB of RAM. When I turn on the hardware memory
> > | hole in the BIOS, the skge driver prints out this message:
> > | skge hardware error detected (status 0xc00)
> > | and then does not work. Setting debug=16 doesn't really show anything.
Is that a board with VIA chipset?
VIA doesn't seem to support PCI accesses with addresses >4GB and they also
don't have a working GART IOMMU.
It will likely work with iommu=force
I've been pondering to force this, but was still waiting for more reports.
-Andi
^ permalink raw reply
* Re: ext4 features
From: Pavel Machek @ 2006-07-07 21:30 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: Bill Davidsen, Benny Amorsen, linux-kernel
In-Reply-To: <m38xn58g26.fsf@defiant.localdomain>
On Fri 07-07-06 19:45:21, Krzysztof Halasa wrote:
> Pavel Machek <pavel@ucw.cz> writes:
>
> > It *was* done. mc supports undelete on ext2.
>
> How does it do that? Directly accessing the device?
Yes. I used it once or twice, and was not happy when ext3 broke it.
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply
* Re: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
From: Stephen Hemminger @ 2006-07-07 21:33 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Stefan Rompf, Ben Greear, Linux Netdev List
In-Reply-To: <44AE2FCC.6020207@trash.net>
On Fri, 07 Jul 2006 11:56:28 +0200
Patrick McHardy <kaber@trash.net> wrote:
> Stefan Rompf wrote:
> > Am Donnerstag 06 Juli 2006 09:42 schrieb Patrick McHardy:
> >
> >
> >>>I believe this link-state logic was added by someone else. I'm not
> >>>sure exactly what these flags are supposed to do, so I am not sure if
> >>>they should be propagated to the VLAN or not.
> >>
> >>I looked into this. The present flag used to get propagated from the
> >>real device until this patch, presumably to make sure no operations
> >>on the vlan device will be passed through to the underlying device
> >>when it is not present.
> >
> >
> > The present flag is changed by netif_device_attach() and
> > netif_device_detach(), and these functions do not emit a
> > netdev_state_change() afterwards. So there is a good chance that
> > vlan_device_event() won't be called and cannot transfer the flag.
> > netif_device_detach() also sets __LINK_STATE_XOFF implicitely.
>
> True.
>
> > Ok, let's see who cares for netif_device_present():
> >
> > -SIOCSIFMAP, dev->set_config() (change media type)
> > -dev_open()
> > -dev_set_mtu()
> > -dev_set_mac_address()
> > -dev_watchdog()
> > ->not implemented by VLAN / does not call through to underlying device
> >
> > -multicast ioctls
> > ->calls dev_mc_upload() of the underlying device sooner or later, this
> > function checks whether the device is present or not. However, if you change
> > the multicast list on a VLAN while the real device is not present,
> > dev_mc_upload() won't be called on netif_device_attach(). Good thing is that
> > most drivers setup multicast list after attach. Fishy.
> >
> > -several private ioctls
> > ->vlan_dev_ioctl() checks whether the real device is present before passing
> > an ioctl
> >
> > So I'd rather drop the __LINK_STATE_PRESENT transfer part, because not
> > guaranteed to be called anyway and mostly unneeded. Ok, let me look through
> > the history now to find who added transferring it (hope this happened after
> > the bitkeeper->git move)
>
> I tend to agree with you, it doesn't seem to work properly. It was
> introduced by Stephen (before the move), lets hope he can tell us more.
>
Not really. The flag code last major change was to do the dormant
stuff that HDLC wanted.
IMHO VLAN device's should mirror the state of the underlying physical
device.
I can't really follow the thread well. What is broken?
--
Stephen Hemminger <shemminger@osdl.org>
Quis custodiet ipsos custodes?
^ permalink raw reply
* Re: 2.6.17-mm6 libata stupid question...
From: Alan Cox @ 2006-07-07 21:51 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
In-Reply-To: <200607072122.k67LMjfL004124@turing-police.cc.vt.edu>
Ar Gwe, 2006-07-07 am 17:22 -0400, ysgrifennodd Valdis.Kletnieks@vt.edu:
> ap->cbl = ATA_CBL_PATA40;
>
> Guess that explains that, unless the chipset actually *can* do 80-pin
> and has an 80-pin cable (which would be surprising because apparently
> none of the other piix variants can...)
Thats a bug. ich_pata_100: 3 should have port_ops of ich_port_ops. Try
with that fixed.
Alan
^ permalink raw reply
* Re: 2.6.17-mm6
From: Andrew Morton @ 2006-07-07 21:38 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel
In-Reply-To: <44AECEDD.201@reub.net>
Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>
> >
> > The core slab data structures were wrecked. For kmalloc(), no less.
> > Something secretly destroyed your kernel, and it could be anything. Nice.
>
> Having now turned on slab debugging, is it possibly related to this message
> which appeared in my log when I booting up earlier?
>
> Jul 8 02:49:39 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode.
> Jul 8 02:49:39 tornado kernel: Adding 497972k swap on /dev/sdc9. Priority:-1
> extents:1 across:497972k
> Jul 8 02:49:40 tornado kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
> Jul 8 02:49:40 tornado kernel: Netfilter messages via NETLINK v0.30.
> Jul 8 02:49:40 tornado kernel: ip_conntrack version 2.4 (4060 buckets, 32480
> max) - 288 bytes per conntrack
> Jul 8 02:49:40 tornado kernel: Slab corruption: start=ffff81003efd7000, len=4096
> Jul 8 02:49:40 tornado kernel: 170: ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b
> Jul 8 02:49:40 tornado kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000
> Mbps Full Duplex
> Jul 8 02:49:40 tornado kernel: GRE over IPv4 tunneling driver
>
Yikes! Until we fix that there's no point in looking at anything else.
CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't
implement the damn thing :(
So if this is repeatable it would be of some value if you can work out what
causes it - start by disabling netfilter.
But to fix it for real we'll probably need to twiddle thumbs until an x86
person can hit it.
^ permalink raw reply
* bmap question (probably stupid)
From: Rafael J. Wysocki @ 2006-07-07 21:38 UTC (permalink / raw)
To: LKML
Hi,
I'd like to use something like bmap() from the user space. I've found the
BMAP_IOCTL, but it's marked as obsolete, so my question is what's the
recommended way of doing this?
Thanks in advance,
Rafael
^ permalink raw reply
* Re: swsusp / suspend2 reliability
From: Pavel Machek @ 2006-07-07 21:39 UTC (permalink / raw)
To: Olivier Galibert, grundig, Avuton Olrich, jan, linux-kernel,
suspend2-devel
In-Reply-To: <20060707174424.GA9913@dspnet.fr.eu.org>
On Fri 07-07-06 19:44:24, Olivier Galibert wrote:
> On Fri, Jul 07, 2006 at 06:09:39PM +0200, grundig wrote:
> > You may ask "why not merge suspend2", but from an objective
> > POV it's perfectly fine that some people asks "why don't
> > suspend2 people try to improve swsusp instead of rewritting
> > it? It may be easier to fix swsusp than replacint it with
> > suspend2"
>
> Suspend2 is an improvement on swsusp. What Pavel wants is something
> completely different and even less tested that suspend2 called
> uswsusp.
...which is already merged in 2.6.17, BTW. So what Pavel wants can be
translated as 'please use already merged code, it can already do what
you want without further changing kernel'.
Pavel
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply
* Re: 2.6.17-mm6
From: J.A. Magallón @ 2006-07-07 21:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Randy.Dunlap, akpm, linux-kernel
In-Reply-To: <44AECE1B.5020502@garzik.org>
On Fri, 07 Jul 2006 17:11:55 -0400, Jeff Garzik <jeff@garzik.org> wrote:
> J.A. Magallón wrote:
> > for each controller
> > sata_init
> > for each controller
> > pata_init
>
>
> There is never a 'for each controller' operation.
>
I know, what would happen when a module loads ?
But you could always do something like
ata_piix_init()
{
if (libata.pata_first)
pata_init()
sata_init()
else
sata_init()
pata_init()
}
> The current layering is as it should be.
>
This is what I like of many developers. It's like it is and it's
the best. Until 2.8 opens.
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply
* Re: 2.6.17-mm6
From: Martin Bligh @ 2006-07-07 21:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Reuben Farrelly, linux-kernel
In-Reply-To: <20060707143854.4a8fd106.akpm@osdl.org>
> Yikes! Until we fix that there's no point in looking at anything else.
>
> CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't
> implement the damn thing :(
I have an implementation, but there's some bug in it I never fixed. If
you want it, I'll update it and send it out ... maybe you can spot the
bug ;-(
M.
^ permalink raw reply
* Re: [Suspend2-devel] Re: swsusp / suspend2 reliability
From: Pavel Machek @ 2006-07-07 21:42 UTC (permalink / raw)
To: David Fox; +Cc: Rohan Dhruva, suspend2-devel, linux-kernel, Jan Rychter
In-Reply-To: <44AEA615.9040302@linspireinc.com>
Hi!
> >Why not
> >take the best from both swsusp and suspend2, and get a
> >nice
> >implementation into the kernel, that works most of the
> >times !
>
> Well, this is the ten thousand dollar question - why not
> indeed? Pavel says "Problems are in drivers, and
> drivers are shared", but suspend2 works around this by
> unloading certain drivers before suspending, and
> otherwise hacking around the difficulties. This is, I
> think, what is meant when suspend2 is said to support
> scripting.
Well, you do make same hacks with swsusp; powersaved does that for
example.
> It may not be a pleasing approach from a
> theoretical standpoint, but it seems to be the only way
...but as it is not pleasing, it can't go anywhere near mainline.
Pavel
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply
* Re: splice/tee bugs?
From: Luiz Fernando N. Capitulino @ 2006-07-07 21:43 UTC (permalink / raw)
To: Luiz Fernando N. Capitulino
Cc: Andrew Morton, Michael Kerrisk, axboe, linux-kernel,
michael.kerrisk, vendor-sec
In-Reply-To: <20060707131310.0e382585@doriath.conectiva>
On Fri, 7 Jul 2006 13:13:10 -0300
"Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> wrote:
| On Fri, 7 Jul 2006 04:07:49 -0700
| Andrew Morton <akpm@osdl.org> wrote:
|
| | On Fri, 07 Jul 2006 09:07:03 +0200
| | "Michael Kerrisk" <mtk-manpages@gmx.net> wrote:
| |
| | > c) Occasionally the command line just hangs, producing no output.
| | > In this case I can't kill it with ^C or ^\. This is a
| | > hard-to-reproduce behaviour on my (x86) system, but I have
| | > seen it several times by now.
| |
| | aka local DoS. Please capture sysrq-T output next time.
|
| If I run lots of them in parallel, I get the following OOPs in a few
| seconds:
|
| Jul 7 13:04:52 doriath kernel: [ 105.041722] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000018
| Jul 7 13:04:52 doriath kernel: [ 105.048885] printing eip:
| Jul 7 13:04:52 doriath kernel: [ 105.056095] c01790c7
| Jul 7 13:04:52 doriath kernel: [ 105.056097] *pde = 00000000
| Jul 7 13:04:52 doriath kernel: [ 105.063516] Oops: 0000 [#1]
| Jul 7 13:04:52 doriath kernel: [ 105.071116] Modules linked in: ipv6 capability commoncap snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq via_rhine mii snd_pcm_oss snd_mixer_oss af_packet snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore rfcomm l2cap bluetooth ide_cd cdrom binfmt_misc loop sata_via libata scsi_mod video thermal processor fan container button battery asus_acpi ac amd64_agp agpgart ehci_hcd uhci_hcd usbcore xfs
| Jul 7 13:04:52 doriath kernel: [ 105.129492] CPU: 0
| Jul 7 13:04:52 doriath kernel: [ 105.129494] EIP: 0060:[sys_tee+371/924] Not tainted VLI
| Jul 7 13:04:52 doriath kernel: [ 105.129494] EIP: 0060:[<c01790c7>] Not tainted VLI
| Jul 7 13:04:52 doriath kernel: [ 105.129495] EFLAGS: 00010293 (2.6.18-rc1 #8)
| Jul 7 13:04:52 doriath kernel: [ 105.170966] EIP is at sys_tee+0x173/0x39c
| Jul 7 13:04:52 doriath kernel: [ 105.185414] eax: d62bfa00 ebx: 00000000 ecx: 00000000 edx: d62bfa98
| Jul 7 13:04:52 doriath kernel: [ 105.200731] esi: d7434800 edi: d62bfa98 ebp: d5d5cfb4 esp: d5d5cf84
| Jul 7 13:04:52 doriath kernel: [ 105.216341] ds: 007b es: 007b ss: 0068
| Jul 7 13:04:52 doriath kernel: [ 105.232017] Process ktee (pid: 12605, ti=d5d5c000 task=d9cce0b0 task.ti=d5d5c000)
| Jul 7 13:04:52 doriath kernel: [ 105.233023] Stack: d5eede40 00000000 d827ac00 00000002 00000000 d62bfa00 00000000 00000000
| Jul 7 13:04:52 doriath kernel: [ 105.250147] 00000000 00000000 00000000 b7f72920 d5d5c000 c0102b7d 00000000 00000001
| Jul 7 13:04:52 doriath kernel: [ 105.267904] 7fffffff 00000000 b7f72920 bf8f37b8 0000013b 0000007b 0000007b 0000013b
| Jul 7 13:04:52 doriath kernel: [ 105.286091] Call Trace:
| Jul 7 13:04:52 doriath kernel: [ 105.321546] [show_stack_log_lvl+140/151] show_stack_log_lvl+0x8c/0x97
| Jul 7 13:04:52 doriath kernel: [ 105.321546] [<c010422c>] show_stack_log_lvl+0x8c/0x97
| Jul 7 13:04:52 doriath kernel: [ 105.340519] [show_registers+292/401] show_registers+0x124/0x191
| Jul 7 13:04:52 doriath kernel: [ 105.340519] [<c0104397>] show_registers+0x124/0x191
| Jul 7 13:04:52 doriath kernel: [ 105.359642] [die+332/617] die+0x14c/0x269
| Jul 7 13:04:53 doriath kernel: [ 105.359642] [<c0104550>] die+0x14c/0x269
| Jul 7 13:04:53 doriath kernel: [ 105.378978] [do_page_fault+1091/1310] do_page_fault+0x443/0x51e
| Jul 7 13:04:53 doriath kernel: [ 105.378978] [<c02a6521>] do_page_fault+0x443/0x51e
| Jul 7 13:04:53 doriath kernel: [ 105.398696] [error_code+57/64] error_code+0x39/0x40
| Jul 7 13:04:53 doriath kernel: [ 105.398696] [<c0103d49>] error_code+0x39/0x40
| Jul 7 13:04:53 doriath kernel: [ 105.418612] [sysenter_past_esp+86/121] sysenter_past_esp+0x56/0x79
| Jul 7 13:04:54 doriath kernel: [ 105.418612] [<c0102b7d>] sysenter_past_esp+0x56/0x79
| Jul 7 13:04:54 doriath kernel: [ 105.438935] Code: 00 00 00 89 d0 8b 55 e4 03 42 6c 83 e0 0f 6b c0 14 8d 7c 10 70 8b 46 68 89 45 e0 83 f8 0f 77 5c 8b 4f 0c 8b 5e 6c 89 fa 8b 45 e4 <ff> 51 18 03 5d e0 83 e3 0f 89 fa 6b db 14 b9 14 00 00 00 8d 5c
| Jul 7 13:04:54 doriath kernel: [ 105.506704] EIP: [sys_tee+371/924] sys_tee+0x173/0x39c SS:ESP 0068:d5d5cf84
| Jul 7 13:04:54 doriath kernel: [ 105.506704] EIP: [<c01790c7>] sys_tee+0x173/0x39c SS:ESP 0068:d5d5cf84
|
Reproducible with 2.6.17.4, can we get a CVE number for this?
--
Luiz Fernando N. Capitulino
^ permalink raw reply
* Process events: Fix biarch compatibility
From: Matt Helsley @ 2006-07-07 21:38 UTC (permalink / raw)
To: LKML; +Cc: Andrew Morton
Argh! I neglected to put linux-kernel on the cc list. Patch is
unchanged.
Andrew, I'd like to revise my request and shoot for eventual inclusion
in 2.6.18 if it's not too much to ask. What do you think?
Cheers,
-Matt Helsley
From: Matt Helsley <matthltc@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>, Guillaume Thouvenin
<guillaume.thouvenin@bull.net>, Albert Cahalan <acahalan@gmail.com>,
Chandra S. Seetharaman <sekharan@us.ibm.com>
Date: Thu, 06 Jul 2006 23:05:16 -0700
Subject: Process events: Fix biarch compatibility
Switch timestamp to two 32-bit scalars instead of two long fields of
a timespec struct. This fixes an issue with biarch systems where the kernel was
sending two 64-bit fields and a naive 32-bit userspace program was expecting
two 32-bit fields. Naive userspace applications that used the timespec directly
are broken. This allows more of the naieve apps to work correctly and all apps
that are correct to continue to work.
I submitted a different solution as an RFC earlier and have since switched to
the solution recommended by Evgeniy Polyakov.
Compiles with linux-2.6.17-mm6, boots, and tested with and without -m32 on x86-64.
Andrew, please consider this patch for inclusion in -mm.
Thanks,
-Matt Helsley
Signed-off-by: Matt Helsley <matthltc@us.ibm.com>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: Guillaume Thouvenin <guillaume.thouvenin@bull.net>
---
drivers/connector/cn_proc.c | 10 ++++++++--
include/linux/cn_proc.h | 3 ++-
2 files changed, 10 insertions(+), 3 deletions(-)
Index: linux-2.6.17/include/linux/cn_proc.h
===================================================================
--- linux-2.6.17.orig/include/linux/cn_proc.h
+++ linux-2.6.17/include/linux/cn_proc.h
@@ -55,11 +55,12 @@ struct proc_event {
/* "next" should be 0x00000400 */
/* "last" is the last process event: exit */
PROC_EVENT_EXIT = 0x80000000
} what;
__u32 cpu;
- struct timespec timestamp;
+ __u32 timestamp_sec;
+ __u32 timestamp_nsec;
union { /* must be last field of proc_event struct */
struct {
__u32 err;
} ack;
Index: linux-2.6.17/drivers/connector/cn_proc.c
===================================================================
--- linux-2.6.17.orig/drivers/connector/cn_proc.c
+++ linux-2.6.17/drivers/connector/cn_proc.c
@@ -102,18 +102,21 @@ static inline void proc_exit_connector(s
static void cn_proc_ack(int err, int rcvd_seq, int rcvd_ack)
{
struct cn_msg *msg;
struct proc_event *ev;
__u8 buffer[CN_PROC_MSG_SIZE];
+ struct timespec ts;
if (atomic_read(&proc_event_num_listeners) < 1)
return;
msg = (struct cn_msg*)buffer;
ev = (struct proc_event*)msg->data;
msg->seq = rcvd_seq;
- ktime_get_ts(&ev->timestamp);
+ ktime_get_ts(&ts);
+ ev->timestamp_sec = ts.tv_sec;
+ ev->timestamp_nsec = ts.tv_nsec;
ev->cpu = -1;
ev->what = PROC_EVENT_NONE;
ev->event_data.ack.err = err;
memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
msg->ack = rcvd_ack + 1;
@@ -155,10 +158,11 @@ static void cn_proc_mcast_ctl(void *data
* generation function.
*/
static int cn_proc_watch_task(struct notifier_block *nb, unsigned long val,
void *t)
{
+ struct timespec ts;
struct task_struct *task = t;
struct cn_msg *msg;
struct proc_event *ev;
__u8 buffer[CN_PROC_MSG_SIZE];
int rc = NOTIFY_OK;
@@ -189,11 +193,13 @@ static int cn_proc_watch_task(struct not
break;
}
if (rc != NOTIFY_OK)
return rc;
get_seq(&msg->seq, &ev->cpu);
- ktime_get_ts(&ev->timestamp); /* get high res monotonic timestamp */
+ ktime_get_ts(&ts); /* get high res monotonic timestamp */
+ ev->timestamp_sec = ts.tv_sec;
+ ev->timestamp_nsec = ts.tv_nsec;
memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
msg->ack = 0; /* not used */
msg->len = sizeof(*ev);
cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
/* If cn_netlink_send() fails, drop data */
^ permalink raw reply
* Re: [PATCH 1/2] srcu-3: RCU variant permitting read-side blocking
From: Paul E. McKenney @ 2006-07-07 21:47 UTC (permalink / raw)
To: Matt Helsley
Cc: Alan Stern, Andrew Morton, dipankar, Ingo Molnar, tytso,
Darren Hart, oleg, Jes Sorensen, LKML
In-Reply-To: <1152306686.21787.2163.camel@stark>
On Fri, Jul 07, 2006 at 02:11:26PM -0700, Matt Helsley wrote:
> On Fri, 2006-07-07 at 15:59 -0400, Alan Stern wrote:
> > On Fri, 7 Jul 2006, Paul E. McKenney wrote:
>
> <snip>
>
> > > So, a fourth possibility -- can a call from start_kernel() invoke some
> > > function in yours and Matt's code invoke init_srcu_struct() to get a
> > > statically allocated srcu_struct initialized? Or, if this is part of
> > > a module, can the module initialization function do this work?
> > >
> > > (Hey, I had to ask!)
> >
> > That is certainly a viable approach: just force everyone to use dynamic
> > initialization. Changes to existing code would be relatively few.
>
> Works for me. I've been working on patches for Andrew's multi-chain
> proposal and I could use an init function there anyway. Should be faster
> too -- dynamically-allocated per-cpu memory can take advantage of
> node-local memory whereas, to my knowledge, statically-allocated cannot.
Sounds very good to me! ;-)
> > I'm not sure where the right place would be to add these initialization
> > calls. After kmalloc is working but before the relevant notifier chains
> > get used at all. Is there such a place? I guess it depends on which
> > notifier chains we convert.
> >
> > We might want to leave some chains using the existing rw-semaphore API.
> > It's more appropriate when there's a high frequency of write-locking
> > (i.e., things registering or unregistering on the notifier chain). The
> > SRCU approach is more appropriate when the chain is called a lot and
> > needs to have low overhead, but (un)registration is uncommon. Matt's task
> > notifiers are a good example.
>
> Yes, it is an excellent example.
Good!!! Please let me know how it goes. I will shelve the idea of
statically allocated per-CPU data for srcu_struct for the moment.
If some other application shows up that needs it, I will revisit.
Thanx, Paul
^ permalink raw reply
* Re: [uml-devel] [PATCH 1/19] UML - Clean up address space limits code
From: Andrew Morton @ 2006-07-07 21:50 UTC (permalink / raw)
To: Jeff Dike; +Cc: tyler, linux-kernel, user-mode-linux-devel
In-Reply-To: <200607070033.k670XXqc008662@ccure.user-mode-linux.org>
Jeff Dike <jdike@addtoit.com> wrote:
>
> I was looking at the code of the UML and more precisely at the functions
> set_task_sizes_tt and set_task_sizes_skas. I noticed that these 2
> functions take a paramater (arg) which is not used : the function is
> always called with the value 0.
>
> I suppose that this value might change in the future (or even can be
> configured), so I added a constant in mem_user.h file.
>
> Also, I rounded CONFIG_HOST_TASk_SIZE to a 4M.
>
> Signed-off-by: Tyler <tyler@agat.net>
> Signed-off-by: Jeff Dike <jdike@addtoit.com>
I'll assume this patch was authored by Tyler <tyler@agat.net>
Please use a "From: " line right at the start of the email/changelog to indicate
authorship, thanks.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: [PATCH 1/19] UML - Clean up address space limits code
From: Andrew Morton @ 2006-07-07 21:50 UTC (permalink / raw)
To: Jeff Dike; +Cc: linux-kernel, user-mode-linux-devel, tyler
In-Reply-To: <200607070033.k670XXqc008662@ccure.user-mode-linux.org>
Jeff Dike <jdike@addtoit.com> wrote:
>
> I was looking at the code of the UML and more precisely at the functions
> set_task_sizes_tt and set_task_sizes_skas. I noticed that these 2
> functions take a paramater (arg) which is not used : the function is
> always called with the value 0.
>
> I suppose that this value might change in the future (or even can be
> configured), so I added a constant in mem_user.h file.
>
> Also, I rounded CONFIG_HOST_TASk_SIZE to a 4M.
>
> Signed-off-by: Tyler <tyler@agat.net>
> Signed-off-by: Jeff Dike <jdike@addtoit.com>
I'll assume this patch was authored by Tyler <tyler@agat.net>
Please use a "From: " line right at the start of the email/changelog to indicate
authorship, thanks.
^ permalink raw reply
* Re: [BUG] 2.6.18-rc1 broke resume from APM suspend on Latitude CPi
From: Pavel Machek @ 2006-07-07 21:47 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: linux-kernel
In-Reply-To: <200607071901.k67J1Q5s023842@harpo.it.uu.se>
Hi!
> Kernel 2.6.18-rc1 broke resume from APM suspend (to RAM)
> on my old Dell Latitude CPi laptop. At resume the disk
> spins up and the screen gets lit, but there is no response
> to the keyboard, not even sysrq. All other system activity
> also appears to be halted.
>
> I did the obvious test of reverting apm.c to the 2.6.17
> version and fixing up the fallout from the TIF_POLLING_NRFLAG
> changes, but it made no difference. So the problem must be
> somewhere else.
driver model changes?
Can you retry with minimum drivers loaded, init=/bin/bash?
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply
* Re: [patch] spinlocks: remove 'volatile'
From: Chase Venters @ 2006-07-07 21:48 UTC (permalink / raw)
To: linux-os \\(Dick Johnson\\)
Cc: Linus Torvalds, Krzysztof Halasa, Ingo Molnar, Andrew Morton,
Linux kernel, arjan
In-Reply-To: <Pine.LNX.4.61.0607071657580.15580@chaos.analogic.com>
On Fri, 7 Jul 2006, linux-os \(Dick Johnson\) wrote:
> Again, I didn't propose to do that. In fact, your spin-lock
> code already inserts "rep nops" and I never implied that they
> should be removed. I said only that "volatile" still needs to
> be used, not some macro that tells the compiler that everything
> in memory probably got trashed. Read what I said, not what you
> think some idiot might have said.
>
Dude, are you even paying attention? "volatile" very much does not need to
be used (and as Linus points out, it is _wrong_). Since we're using GCC's
inline asm syntax _already_, it is perfectly sufficient to use the same
syntax to tell GCC that memory should be considered invalid.
Locks are supposed to be syncronization points, which is why they ALREADY
HAVE "memory" on the clobber list! "memory" IS NECESSARY. The fact
that "=m" is changing to "+m" in Linus's patches is because "=m" is in
fact insufficient, because it would let the compiler believe we're just
going to over-write the value. "volatile" merely hides that bug -- once
that bug is _fixed_ (by going to "+m"), "volatile" is no longer useful.
(It wasn't useful before, it just _papered over_ a problem).
If "volatile" is in use elsewhere (other than locks), it's still
probably wrong. In these cases, you can use a barrier, a volatile cast, or
an inline asm with a specific clobber.
Thanks,
Chase
^ permalink raw reply
* Re: [uml-devel] [PATCH 4/19] UML - timer initialization cleanup
From: Andrew Morton @ 2006-07-07 21:55 UTC (permalink / raw)
To: Jeff Dike; +Cc: linux-kernel, user-mode-linux-devel
In-Reply-To: <200607070033.k670XaAg008677@ccure.user-mode-linux.org>
Jeff Dike <jdike@addtoit.com> wrote:
>
> + err = request_irq(TIMER_IRQ, um_timer, SA_INTERRUPT, "timer", NULL);
SA_INTERRUPT is deprecated - I'll change this to IRQF_DISABLED.
We have a compatibility layer for now, but we need to start getting used to
using INTF_*.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: [PATCH 4/19] UML - timer initialization cleanup
From: Andrew Morton @ 2006-07-07 21:55 UTC (permalink / raw)
To: Jeff Dike; +Cc: linux-kernel, user-mode-linux-devel
In-Reply-To: <200607070033.k670XaAg008677@ccure.user-mode-linux.org>
Jeff Dike <jdike@addtoit.com> wrote:
>
> + err = request_irq(TIMER_IRQ, um_timer, SA_INTERRUPT, "timer", NULL);
SA_INTERRUPT is deprecated - I'll change this to IRQF_DISABLED.
We have a compatibility layer for now, but we need to start getting used to
using INTF_*.
^ permalink raw reply
* [patch] acpi: init dock notifier list
From: Kristen Accardi @ 2006-07-07 22:06 UTC (permalink / raw)
To: linux-acpi; +Cc: len.brown, akpm, linux-kernel
Initialize the atomic notifier list
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
---
drivers/acpi/dock.c | 1 +
1 file changed, 1 insertion(+)
--- 2.6-mm.orig/drivers/acpi/dock.c
+++ 2.6-mm/drivers/acpi/dock.c
@@ -627,6 +627,7 @@ static int dock_add(acpi_handle handle)
INIT_LIST_HEAD(&dock_station->hotplug_devices);
spin_lock_init(&dock_station->dd_lock);
spin_lock_init(&dock_station->hp_lock);
+ ATOMIC_INIT_NOTIFIER_HEAD(&dock_notifier_list);
/* Find dependent devices */
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
^ permalink raw reply
* Re: [PATCH -rt] catch put_task_struct RCU handling up to mainline
From: Esben Nielsen @ 2006-07-07 22:56 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: mingo, oleg, linux-kernel, dino, tytso, dvhltc
In-Reply-To: <20060707192955.GA2219@us.ibm.com>
On Fri, 7 Jul 2006, Paul E. McKenney wrote:
> Hello!
>
> Due to the separate -rt and mainline evolution of RCU signal handling,
> the -rt patchset now makes each task struct go through two RCU grace
> periods, with one call_rcu() in release_task() and with another
> in put_task_struct(). Only the call_rcu() in release_task() is
> required, since this is the one that is associated with tearing down
> the task structure.
>
> This patch removes the extra call_rcu() in put_task_struct(), synching
> this up with mainline. Tested lightly on i386.
>
The extra call_rcu() has an advantage:
It defers work away from the task doing the last put_task_struct().
It could be a priority 99 task with hard latency requirements doing
some PI boosting, forinstance. The extra call_rcu() defers non-RT work to
a low priority task. This is in generally a very good idea in a real-time
system.
So unless you can argue that the work defered is as small as the work of
doing a call_rcu() I would prefer the extra call_rcu().
Esben
> CC: Oleg Nesterov <oleg@tv-sign.ru>
> Signed-off-by: Paul E. McKenney <paulmck@us.ibm.com>
> ---
>
> include/linux/sched.h | 10 ----------
> kernel/fork.c | 21 ---------------------
> 2 files changed, 31 deletions(-)
>
> diff -urpNa -X dontdiff linux-2.6.17-rt5/include/linux/sched.h linux-2.6.17-rt5-2RCU/include/linux/sched.h
> --- linux-2.6.17-rt5/include/linux/sched.h 2006-07-02 12:37:14.000000000 -0700
> +++ linux-2.6.17-rt5-2RCU/include/linux/sched.h 2006-07-06 18:11:49.000000000 -0700
> @@ -1105,15 +1105,6 @@ static inline int pid_alive(struct task_
> extern void free_task(struct task_struct *tsk);
> #define get_task_struct(tsk) do { atomic_inc(&(tsk)->usage); } while(0)
>
> -#ifdef CONFIG_PREEMPT_RT
> -extern void __put_task_struct_cb(struct rcu_head *rhp);
> -
> -static inline void put_task_struct(struct task_struct *t)
> -{
> - if (atomic_dec_and_test(&t->usage))
> - call_rcu(&t->rcu, __put_task_struct_cb);
> -}
> -#else
> extern void __put_task_struct(struct task_struct *t);
>
> static inline void put_task_struct(struct task_struct *t)
> @@ -1121,7 +1112,6 @@ static inline void put_task_struct(struc
> if (atomic_dec_and_test(&t->usage))
> __put_task_struct(t);
> }
> -#endif
>
> /*
> * Per process flags
> diff -urpNa -X dontdiff linux-2.6.17-rt5/kernel/fork.c linux-2.6.17-rt5-2RCU/kernel/fork.c
> --- linux-2.6.17-rt5/kernel/fork.c 2006-07-02 12:37:15.000000000 -0700
> +++ linux-2.6.17-rt5-2RCU/kernel/fork.c 2006-07-07 07:44:36.000000000 -0700
> @@ -120,26 +120,6 @@ void free_task(struct task_struct *tsk)
> }
> EXPORT_SYMBOL(free_task);
>
> -#ifdef CONFIG_PREEMPT_RT
> -void __put_task_struct_cb(struct rcu_head *rhp)
> -{
> - struct task_struct *tsk = container_of(rhp, struct task_struct, rcu);
> -
> - BUG_ON(atomic_read(&tsk->usage));
> - WARN_ON(!(tsk->flags & PF_DEAD));
> - WARN_ON(!(tsk->exit_state & (EXIT_DEAD | EXIT_ZOMBIE)));
> - WARN_ON(tsk == current);
> -
> - security_task_free(tsk);
> - free_uid(tsk->user);
> - put_group_info(tsk->group_info);
> -
> - if (!profile_handoff_task(tsk))
> - free_task(tsk);
> -}
> -
> -#else
> -
> void __put_task_struct(struct task_struct *tsk)
> {
> WARN_ON(!(tsk->exit_state & (EXIT_DEAD | EXIT_ZOMBIE)));
> @@ -154,7 +134,6 @@ void __put_task_struct(struct task_struc
> if (!profile_handoff_task(tsk))
> free_task(tsk);
> }
> -#endif
>
> void __init fork_init(unsigned long mempages)
> {
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: swsusp / suspend2 reliability
From: Olivier Galibert @ 2006-07-07 21:56 UTC (permalink / raw)
To: Pavel Machek; +Cc: grundig, Avuton Olrich, jan, linux-kernel, suspend2-devel
In-Reply-To: <20060707213916.GC5393@ucw.cz>
On Fri, Jul 07, 2006 at 09:39:17PM +0000, Pavel Machek wrote:
> ...which is already merged in 2.6.17, BTW.
Sure. It's a stupid approach, but since you have your name in the
MAINTAINERS file, you don't have to care. Meanwhile, those who would
like a reliable suspend are out of luck.
> So what Pavel wants can be
> translated as 'please use already merged code, it can already do what
> you want without further changing kernel'.
Like we'd want to use unreviewed, extremely new and risky code for
something that happily destroy filesystems.
OG.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.