date:20070625

On Tue, 19 Jun 2007 14:37:03 -0700 "Keshavamurthy, Anil S" <[EMAIL PROTECTED]> 
wrote:

> +struct pci_dev *
> +pci_find_upstream_pcie_bridge(struct pci_dev *pdev)

You didn't need a newline there, but that's what the rest of that file
does.  Hu hum.

> +{
> + struct pci_dev *tmp = NULL;
> +
> + if (pdev->is_pcie)
> + return NULL;
> + while (1) {
> + if (!pdev->bus->self)
> + break;
> + pdev = pdev->bus->self;
> + /* a p2p bridge */
> + if (!pdev->is_pcie) {
> + tmp = pdev;
> + continue;
> + }
> + /* PCI device should connect to a PCIE bridge */
> + BUG_ON(pdev->pcie_type != PCI_EXP_TYPE_PCI_BRIDGE);

I assume that if this bug triggers, we've found some broken hardware?

Going BUG seems like a pretty rude reaction to this, especially when it
would be so easy to drop a warning and then recover.


How's about this?

--- a/drivers/pci/search.c~intel-iommu-pci-generic-helper-function-fix
+++ a/drivers/pci/search.c
@@ -38,7 +38,11 @@ pci_find_upstream_pcie_bridge(struct pci
continue;
}
/* PCI device should connect to a PCIE bridge */
-   BUG_ON(pdev->pcie_type != PCI_EXP_TYPE_PCI_BRIDGE);
+   if (pdev->pcie_type != PCI_EXP_TYPE_PCI_BRIDGE) {
+   /* Busted hardware? */
+   WARN_ON_ONCE(1);
+   return NULL;
+   }
return pdev;
}
 

-
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/

2.6.22-rc6: NMI oops and long pauses during boot

2007-06-25 Thread Meelis Roos

I compiled 2.6.22-rc6 yesterday and testbooted it.

First boot hung with oops/bug dump. I did not have a camera ready but it 
was an oops-like dump that included die_nmi or something similar about 
NMI.

Second boot booted fine until INIT had started and then came a long 
pause (tens of seconds). When I pressed Ctrl-Alt-Del it became alive and 
continued the bootup until it noticed the Ctrl-Alt-Del.

Third boot was similar but the pause appeared before INIT: line and 
after mounting root and writeprotecting kernel text and readonly 
data. Ctrl-Alt-Del revived it again.

Fourth boot went OK up until chronyd was started.

When I got to chronyd startup, it waited for a long time again (tried 
this 2 times). This usually only happens because of network problems, 
this time I did not see any network problems here but there might still 
be one somewhere. So this does not have to be because of kernel - just 
mentioned it for completeness.

/proc/interrupts:
   CPU0   
  0: 53XT-PIC-XTtimer
  1:   3477XT-PIC-XTi8042
  2:  0XT-PIC-XTcascade
  6:  5XT-PIC-XTfloppy
  7:  1XT-PIC-XTparport0
  8:  1XT-PIC-XTrtc
  9:  4XT-PIC-XTacpi, Intel 82801BA-ICH2
 10:  0XT-PIC-XTuhci_hcd:usb2
 11:  49627XT-PIC-XTuhci_hcd:usb1, eth0, [EMAIL 
PROTECTED]::02:00.0
 12:   8825XT-PIC-XTi8042
 14:  20284XT-PIC-XTlibata
 15:  11801XT-PIC-XTlibata
NMI:206 
LOC:  91773 
ERR:  0
MIS:  0

lspci:
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory 
Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 02)
00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 02)
00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 02)
00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #2) (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio 
(rev 02)
01:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet 
Controller (rev 01)
02:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP

cpuinfo:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Celeron (Coppermine)
stepping: 10
cpu MHz : 897.152
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr sse
bogomips: 1795.59
clflush size: 32



dmesg:
Linux version 2.6.22-rc6 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070601 
(prerelease) (Debian 4.1.2-12)) #392 PREEMPT Mon Jun 25 10:02:02 EEST 2007
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 1ffc (usable)
 BIOS-e820: 1ffc - 1fff8000 (ACPI data)
 BIOS-e820: 1fff8000 - 2000 (ACPI NVS)
 BIOS-e820: ffb8 - ffc0 (reserved)
 BIOS-e820: fff0 - 0001 (reserved)
511MB LOWMEM available.
Entering add_active_range(0, 0, 131008) 0 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  Normal   4096 ->   131008
early_node_map[1] active PFN ranges
0:0 ->   131008
On node 0 totalpages: 131008
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 991 pages used for memmap
  Normal zone: 125921 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP 000FF980, 0014 (r0 AMI   )
ACPI: RSDT 1FFF, 0028 (r1 D815EA D815EEA2 20021106 MSFT 1011)
ACPI: FACP 1FFF1000, 0074 (r1 D815EA EA81510A 20021106 MSFT 1011)
ACPI: DSDT 1FFE, 30E4 (r1 D815E2 EA81520A   23 MSFT  10B)
ACPI: FACS 1FFF8000, 0040
ACPI: PM-Timer IO Port: 0x408
Allocating PCI resources starting at 3000 (gap: 2000:dfb8)
Built 1 zonelists.  Total pages: 129985
Kernel command line: root=/dev/sda3 ro nmi_watchdog=1 lapic
Found and enabled local APIC!
mapped APIC to d000 (fee0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c040a000 soft=c0409000
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 897.152 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table

Re: [Intel IOMMU 06/10] Avoid memory allocation failures in dma map api calls

On Wed, 20 Jun 2007 10:06:39 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:

> On Tue, 2007-06-19 at 14:37 -0700, Keshavamurthy, Anil S wrote:
> > plain text document attachment (intel_iommu_pf_memalloc.patch)
> > Intel IOMMU driver needs memory during DMA map calls to setup its internal
> > page tables and for other data structures. As we all know that these DMA 
> > map calls are mostly called in the interrupt context or with the spinlock 
> > held by the upper level drivers(network/storage drivers), so in order to 
> > avoid any memory allocation failure due to low memory issues,
> > this patch makes memory allocation by temporarily setting PF_MEMALLOC
> > flags for the current task before making memory allocation calls.
> > 
> > We evaluated mempools as a backup when kmem_cache_alloc() fails
> > and found that mempools are really not useful here because
> >  1) We don;t know for sure how much to reserve in advance
> 
> So you just unleashed an unbounded allocation context on PF_MEMALLOC?
> seems like a really really bad idea.
> 
> >  2) And mempools are not useful for GFP_ATOMIC case (as we call 
> > memory alloc functions with GFP_ATOMIC)
> 
> Mempools work as intended with GFP_ATOMIC, it gets filled up to the
> specified number of elements using GFP_KERNEL (at creation time). This
> gives GFP_ATOMIC allocations nr_elements extra items once it would start
> failing.

Yup.  Changelog is buggy.

> > With PF_MEMALLOC flag set in the current->flags, the VM subsystem avoids
> > any watermark checks before allocating memory thus guarantee'ing the 
> > memory till the last free page.
> 
> PF_MEMALLOC as is, is meant to salvage the VM from the typical VM
> deadlock. Using it as you do now is not something a driver should ever
> do, and I'm afraid I will have to strongly oppose this patch.
> 
> You really really want to calculate an upper bound on your memory
> consumption and reserve this.
> 
> So, I'm afraid I'll have to..
> 
> NACK!

err, PF_MEMALLOC doesn't actually do anything if in_interrupt(), so your
reason-for-nacking isn't legitimate.  And neither is Anil's patch ;)

So I'm thinking that if this patch passed all his testing, a patch which
didn't play these PF_MEMALLOC games would pass the same tests.

-
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] SLOB allocator imcompatible SLAB

2007-06-25 Thread Matt Mackall

On Tue, Jun 26, 2007 at 03:00:56PM +1000, Nick Piggin wrote:
> Matt Mackall wrote:
> >On Tue, Jun 26, 2007 at 02:06:15PM +1000, Nick Piggin wrote:
> >
> >>Yoshinori Sato wrote:
> >>
> >>>At Fri, 22 Jun 2007 09:56:35 -0500,
> >>>Matt Mackall wrote:
> >>>
> >>>
> On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
> 
> 
> >Because the page which SLOB allocator got does not have PG_slab,
> 
> This is for a NOMMU system?
> >>>
> >>>
> >>>Yes.
> >>>
> >>>
> >>>
> You're using an old kernel with an old version of SLOB. SLOB in newer
> kernels actually sets per-page flags. Nick, can you see any reason not
> to s/PG_active/PG_slab/ in the current code?
> >>
> >>The problem with this is that PG_private is used only for the SLOB
> >>part of the allocator and not the bigblock part.
> >
> >
> >That's fine, at least for the purposes of kobjsize. We only mark
> >actual SLOB-managed pages, kobjsize assumes the rest are alloc_pages
> >and that's indeed what they are.
> 
> OK, but that only makes it work in this case. I think we should
> either call PG_slab part of the kmem/kmalloc API and implement
> that, or say it isn't and make nommu do something else?
>
> >>We _could_ just bite the bullet and have SLOB set PG_slab, however
> >>that would encouarage more users of this flag which we should hope
> >>to get rid of one day.
> >>
> >>The real problem is that nommu wants to get the size of either
> >>kmalloc or alloc_pages objects and it needs to differentiate
> >>between them. So I would rather nommu to take its own page flag
> >>(could overload PG_swapcache, perhaps?), and set that flag on
> >>pages it allocates directly, then uses that to determine whether
> >>to call ksize or not.
> >
> >
> >I think we already established on the last go-round that the kobjsize
> >scheme was rather hopelessly broken anyway. 
> 
> I can't remember, but that would be another good reason to confine
> it to nommu.c wouldn't it?

(jogs brain)

When I last looked, we could tell statically whether pointers passed
to kobjsize were to alloc_pages or kmalloc or kmem_cache_alloc just
based on context.

But in some cases, we could actually pass in pointers to static data
structures (eg bits of init_task) and things that were in ROM and
being used for XIP or things that lived outside of the kernel's
address space. SLAB would deal with this kind of affront by checking
page flags and saying "sorry, not mine".

Beating some sense into nommu here is doable, but non-trivial.

Since we're actually fiddling with page flags at this point and
hijacking an arguably less-appropriate bit, I'm strongly tempted to
just use the SLAB bit.

-- 
Mathematics is the supreme nostalgia of our time.
-
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/2] rtc: add rtc-m41t80 driver

On Tue, 26 Jun 2007 14:15:36 +0900 (JST) Atsushi Nemoto <[EMAIL PROTECTED]> 
wrote:

> On Mon, 25 Jun 2007 21:46:20 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > + const static struct m41t80_chip_info *chip;
> > 
> > It's a bit weird that `chip' has static storage class here.  Was that
> > deliberate?
> 
> Oh the variable should not be static!
> I will send updated patch.

I'll fix it up.

> BTW, I reveived following mails:
> 
> Subject: - rtc-watchdog-support-for-rtc-m41t80-driver-take-2.patch removed 
> from -mm tree
> Subject: - rtc-add-rtc-m41t80-driver-take-2.patch removed from -mm tree
> Subject: + rtc-add-rtc-m41t80-driver.patch added to -mm tree
> Subject: + rtc-watchdog-support-for-rtc-m41t80-driver.patch added to -mm tree
> 
> Are you going back to "take 1" patches?  Why?

Stupidity, apparently.  Will restore the take2 patches.
-
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 try #3] security: Convert LSM into a static interface

2007-06-25 Thread Marcus Meissner

In article <[EMAIL PROTECTED]> you wrote:
> Convert LSM into a static interface, as the ability to unload a security
> module is not required by in-tree users and potentially complicates the
> overall security architecture.
> 
> Needlessly exported LSM symbols have been unexported, to help reduce API
> abuse.
> 
> Parameters for the capability and root_plug modules are now specified
> at boot.
> 
> The SECURITY_FRAMEWORK_VERSION macro has also been removed.
> 
> Signed-off-by: James Morris <[EMAIL PROTECTED]>

NAK.

First, such an interface should be obsoleted by first making an entry
to Documentation/feature-removal-schedule.txt and waiting for some months.

Second, security modules that cannot be loaded/unloaded can just marked
so and the LSM interface kept as-is.

You are aware of the out of tree users, like AppArmor and other security
modules and there are also several antivirus modules like dazuko, mcafee
(got riddance for the latter, but in general) using LSM.

Ciao, Marcus
-
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/2] rtc: add rtc-m41t80 driver

2007-06-25 Thread Atsushi Nemoto

On Mon, 25 Jun 2007 21:46:20 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > +   const static struct m41t80_chip_info *chip;
> 
> It's a bit weird that `chip' has static storage class here.  Was that
> deliberate?

Oh the variable should not be static!
I will send updated patch.

BTW, I reveived following mails:

Subject: - rtc-watchdog-support-for-rtc-m41t80-driver-take-2.patch removed from 
-mm tree
Subject: - rtc-add-rtc-m41t80-driver-take-2.patch removed from -mm tree
Subject: + rtc-add-rtc-m41t80-driver.patch added to -mm tree
Subject: + rtc-watchdog-support-for-rtc-m41t80-driver.patch added to -mm tree

Are you going back to "take 1" patches?  Why?

---
Atsushi Nemoto
-
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/HOWTO: update URLs of git trees

On Tue, 19 Jun 2007 23:45:58 +0200 (CEST) Stefan Richter <[EMAIL PROTECTED]> 
wrote:

> On 19 Jun, Chris Wright wrote:
> > * Stefan Richter ([EMAIL PROTECTED]) wrote:
> >> +  Other kernel trees can be found listed at http://kernel.org/git and in
> > 
> > Should be http://git.kernel.org/ these days
> 
> Right.
> 
> 
> From: Stefan Richter <[EMAIL PROTECTED]>
> Subject: Documentation/HOWTO: update URLs of git trees
> 
> Also, remove outdated 1394 tree and mention MAINTAINERS as pointer to
> development trees.
> 
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
>  Documentation/HOWTO |   28 +---
>  1 file changed, 13 insertions(+), 15 deletions(-)
> 
> Index: linux-2.6.22-rc5/Documentation/HOWTO
> ===
> --- linux-2.6.22-rc5.orig/Documentation/HOWTO
> +++ linux-2.6.22-rc5/Documentation/HOWTO
> @@ -322,39 +322,34 @@ kernel releases as described above.
>  Here is a list of some of the different kernel trees available:
>git trees:
>  - Kbuild development tree, Sam Ravnborg <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
> + git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
>  
>  - ACPI development tree, Len Brown <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> + git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
>  
>  - Block development tree, Jens Axboe <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
> + git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
>  
>  - DRM development tree, Dave Airlie <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
> + git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
>  
>  - ia64 development tree, Tony Luck <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
> -
> -- ieee1394 development tree, Jody McIntyre <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
> + git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
>  
>  - infiniband, Roland Dreier <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> + git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
>  
>  - libata, Jeff Garzik <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> + git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>  
>  - network drivers, Jeff Garzik <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
> + git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>  
>  - pcmcia, Dominik Brodowski <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
> + git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
>  
>  - SCSI, James Bottomley <[EMAIL PROTECTED]>
> - kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> -
> -  Other git kernel trees can be found listed at http://kernel.org/git
> + git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
>  

rofl.  You want git trees?  I got git trees:

git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git#8139cp
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/davej/agpgart.git
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git#mm
git+ssh://master.kernel.org/home/rmk/linux-2.6-arm.git#devel
git+ssh://master.kernel.org/home/rmk/linux-2.6-arm.git#master
git+ssh://master.kernel.org/home/rmk/linux-2.6-arm-smp.git
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git#audit.b37
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-akpm
git://www.atmel.no/~hskinnemoen/linux/kernel/avr32.git#avr32-arch
git://git.o-hand.com/linux-rpurdie-backlight#for-mm
git://git.infradead.org/users/cbou/battery2-2.6.git
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git#for-akpm
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/block.git#block-fixes
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git#cfq
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git#chelsio
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git
http://oss.oracle.com/git/ocfs2-dev.git/
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/davej/x86.git
git://lost.foo-projects.org/~dwillia2/git/iop#md-accel-2.6.20-rc5
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git#drm-mm

Re: [PATCH] fix section mismatch in chipsfb

On Wed, 20 Jun 2007 00:15:28 +0200 Olaf Hering <[EMAIL PROTECTED]> wrote:

> Maybe this is the correct fix:
> 
> WARNING: drivers/built-in.o(.text+0x8742a): Section mismatch: reference to 
> .init.data:chipsfb_fix (between 'chipsfb_pci_init' and 'chipsfb_set_par')
> WARNING: drivers/built-in.o(.text+0x87432): Section mismatch: reference to 
> .init.data:chipsfb_fix (between 'chipsfb_pci_init' and 'chipsfb_set_par')
> WARNING: drivers/built-in.o(.text+0x87442): Section mismatch: reference to 
> .init.data:chipsfb_var (between 'chipsfb_pci_init' and 'chipsfb_set_par')
> WARNING: drivers/built-in.o(.text+0x8744a): Section mismatch: reference to 
> .init.data:chipsfb_var (between 'chipsfb_pci_init' and 'chipsfb_set_par')
> 
> init_chips is only called from chipsfb_pci_init
> chipsfb_fix and chipsfb_var are only referenced from init_chips
> 
> Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
> 
> --- a/drivers/video/chipsfb.c
> +++ b/drivers/video/chipsfb.c
> @@ -292,7 +292,7 @@ static void __init chips_hw_init(void)
>   write_fr(chips_init_fr[i].addr, chips_init_fr[i].data);
>  }
>  
> -static struct fb_fix_screeninfo chipsfb_fix __initdata = {
> +static struct fb_fix_screeninfo chipsfb_fix __devinitdata = {
>   .id =   "C 65550",
>   .type = FB_TYPE_PACKED_PIXELS,
>   .visual =   FB_VISUAL_PSEUDOCOLOR,
> @@ -309,7 +309,7 @@ static struct fb_fix_screeninfo chipsfb_
>   .smem_len = 0x10,   /* 1MB */
>  };
>  
> -static struct fb_var_screeninfo chipsfb_var __initdata = {
> +static struct fb_var_screeninfo chipsfb_var __devinitdata = {
>   .xres = 800,
>   .yres = 600,
>   .xres_virtual = 800,
> @@ -330,7 +330,7 @@ static struct fb_var_screeninfo chipsfb_
>   .vsync_len = 8,
>  };
>  
> -static void __init init_chips(struct fb_info *p, unsigned long addr)
> +static void __devinit init_chips(struct fb_info *p, unsigned long addr)
>  {
>   memset(p->screen_base, 0, 0x10);
>  

It looks like the correct fix to me.
-
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] Fix for bad lock balance in Containers

2007-06-25 Thread Dhaval Giani

Hi,

I have been going through the containers code and trying it out. I tried
mounting the same hierarchy at two different points and I got a bad
locking balance warning.

=
[ BUG: bad unlock balance detected! ]
-
mount/4467 is trying to release lock (>s_umount_key) at:
[] vfs_kern_mount+0x5b/0x70
but there are no more locks to release!

other info that might help us debug this:
no locks held by mount/4467.

stack backtrace:
 [] show_trace_log_lvl+0x19/0x2e
 [] show_trace+0x12/0x14
 [] dump_stack+0x14/0x16
 [] print_unlock_inbalance_bug+0xcc/0xd6
 [] check_unlock+0x6f/0x75
 [] __lock_release+0x1e/0x51
 [] lock_release+0x4c/0x64
 [] up_write+0x16/0x2b
 [] vfs_kern_mount+0x5b/0x70
 [] do_new_mount+0x85/0xe6
 [] do_mount+0x185/0x199
 [] sys_mount+0x71/0xa6
 [] sysenter_past_esp+0x5f/0x99
 ===

Going through the code, I realised this is because when the container is
already mounted at one point, when being remounted, it just does a
simple_set_mnt which does not update s_umount which causes the warning
to come. This also cause umount to hang the second time.

The correct method would be allocate the superblock using sget (or a
variant) which would call grab_super correctly and set these locks.
Seeing the code which is there, some part of grab_super is already done
in container_get_sb where the root->sb->s_active is updated. So I have
called down_write there as well to get the locking balance. However I
believe that this is not the correct approach.

There are a few questions I had with respect to the current code,

Why is the increment of s_active dependent on the return value of
simple_set_mnt? All the other functions which I have seen (fs ones),
grab_super (which increments s_active) is called followed by a
simple_set_mnt.

What should be the correct approach to get the locking balance? As far
as I can see, the correct method would be to call sget which would then
correctly handle everything. But that would require a test function. I
saw functionality similar to a test function in the beginning of
container_get_sb(). Should that be seperated and put in a seperate test
function so that sget can be called?

Another possible approach would be to call grab_super directly (since we
know the test function is going to return true), but this cannot be done
since grab_super is static right now. Or maybe we could duplicate
grab_super's functionality.

In the meantime a temporary fix.

Thanks and regards
Dhaval

Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]>


--- linux-2.6.22-rc4/kernel/container.c 2007-06-13 15:38:32.0 +0530
+++ old/kernel/container.c  2007-06-25 00:55:03.0 +0530
@@ -995,6 +995,7 @@ static int container_get_sb(struct file_
BUG_ON(ret);
} else {
/* Reuse the existing superblock */
+   down_write(&(root->sb->umount));
ret = simple_set_mnt(mnt, root->sb);
if (!ret)
atomic_inc(>sb->s_active);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2/2] HFS+: Add custom dentry hash and comparison operations

On Mon, 25 Jun 2007 14:17:19 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]> 
wrote:

> +/*
> + * Hash a string to an integer as appropriate for the HFS+ filesystem.
> + * Composed unicode characters are decomposed and case-folding is performed
> + * if the appropriate bits are (un)set on the superblock.
> + */
> +int hfsplus_hash_dentry(struct dentry *dentry, struct qstr *str)
> +{
> + struct super_block *sb = dentry->d_sb;
> + const char *astr;
> + const u16 *dstr;
> + int casefold, decompose, size, dsize, len;
> + unsigned long hash;
> + wchar_t c;
> + u16 c2;
> +
> + casefold = (HFSPLUS_SB(sb).flags & HFSPLUS_SB_CASEFOLD);
> + decompose = !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE);
> + hash = init_name_hash();
> + astr = str->name;
> + len = str->len;
> + while (len > 0) {
> + size = asc2unichar(sb, astr, len, );
> + astr += size;
> + len -= size;
> +
> + if (decompose && (dstr = decompose_unichar(c, ))) {
> + do {
> + c2 = *dstr++;
> + if (!casefold || (c2 = case_fold(c2)))
> + hash = partial_name_hash(c2, hash);
> + } while (--dsize > 0);

Are you really sure that we cannot start this loop with dsize==0?  This isn't
obviously true to these bleary eyes.

> + } else {
> + c2 = c;
> + if (!casefold || (c2 = case_fold(c2)))
> + hash = partial_name_hash(c2, hash);
> + }
> + }
> + str->hash = end_name_hash(hash);
-
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] SLOB allocator imcompatible SLAB


Matt Mackall wrote:

On Tue, Jun 26, 2007 at 02:06:15PM +1000, Nick Piggin wrote:


Yoshinori Sato wrote:


At Fri, 22 Jun 2007 09:56:35 -0500,
Matt Mackall wrote:



On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:



Because the page which SLOB allocator got does not have PG_slab,


This is for a NOMMU system?



Yes.




You're using an old kernel with an old version of SLOB. SLOB in newer
kernels actually sets per-page flags. Nick, can you see any reason not
to s/PG_active/PG_slab/ in the current code?


The problem with this is that PG_private is used only for the SLOB
part of the allocator and not the bigblock part.



That's fine, at least for the purposes of kobjsize. We only mark
actual SLOB-managed pages, kobjsize assumes the rest are alloc_pages
and that's indeed what they are.


OK, but that only makes it work in this case. I think we should
either call PG_slab part of the kmem/kmalloc API and implement
that, or say it isn't and make nommu do something else?



We _could_ just bite the bullet and have SLOB set PG_slab, however
that would encouarage more users of this flag which we should hope
to get rid of one day.

The real problem is that nommu wants to get the size of either
kmalloc or alloc_pages objects and it needs to differentiate
between them. So I would rather nommu to take its own page flag
(could overload PG_swapcache, perhaps?), and set that flag on
pages it allocates directly, then uses that to determine whether
to call ksize or not.



I think we already established on the last go-round that the kobjsize
scheme was rather hopelessly broken anyway. 


I can't remember, but that would be another good reason to confine
it to nommu.c wouldn't it?

--
SUSE Labs, Novell Inc.
-
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] SLOB allocator imcompatible SLAB

2007-06-25 Thread Matt Mackall

On Tue, Jun 26, 2007 at 02:06:15PM +1000, Nick Piggin wrote:
> Yoshinori Sato wrote:
> >At Fri, 22 Jun 2007 09:56:35 -0500,
> >Matt Mackall wrote:
> >
> >>On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
> >>
> >>>Because the page which SLOB allocator got does not have PG_slab,
> >>
> >>This is for a NOMMU system?
> >
> >
> >Yes.
> > 
> >
> >>You're using an old kernel with an old version of SLOB. SLOB in newer
> >>kernels actually sets per-page flags. Nick, can you see any reason not
> >>to s/PG_active/PG_slab/ in the current code?
> 
> The problem with this is that PG_private is used only for the SLOB
> part of the allocator and not the bigblock part.

That's fine, at least for the purposes of kobjsize. We only mark
actual SLOB-managed pages, kobjsize assumes the rest are alloc_pages
and that's indeed what they are.

> We _could_ just bite the bullet and have SLOB set PG_slab, however
> that would encouarage more users of this flag which we should hope
> to get rid of one day.
> 
> The real problem is that nommu wants to get the size of either
> kmalloc or alloc_pages objects and it needs to differentiate
> between them. So I would rather nommu to take its own page flag
> (could overload PG_swapcache, perhaps?), and set that flag on
> pages it allocates directly, then uses that to determine whether
> to call ksize or not.

I think we already established on the last go-round that the kobjsize
scheme was rather hopelessly broken anyway. 

-- 
Mathematics is the supreme nostalgia of our time.
-
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/2] rtc: add rtc-m41t80 driver

On Thu, 21 Jun 2007 02:09:34 +0900 (JST) Atsushi Nemoto <[EMAIL PROTECTED]> 
wrote:

> This is a new-style i2c driver for ST M41T80 series RTC chip, derived
> from works by Alexander Bigga <[EMAIL PROTECTED]> who wrote the original
> rtc-m41txx.c based on drivers/i2c/chips/m41t00.c driver.
> 
> This driver supports M41T8[0-4] and M41ST8[457].  The old m41t00
> driver supports M41T00, M41T81 and M41T85(M41ST85).  While the M41T00
> chip is now supported by rtc-ds1307 driver, this driver does not
> include support for the chip.
> 
> Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
> Signed-off-by: Alexander Bigga <[EMAIL PROTECTED]>
> Acked-by: Mark A. Greer <[EMAIL PROTECTED]>
>
> ...
>
> +static int m41t80_probe(struct i2c_client *client)
> +{
> + int i, rc = 0;
> + struct rtc_device *rtc = NULL;
> + struct rtc_time tm;
> + struct m41t80_platform_data *pdata = client->dev.platform_data;
> + const static struct m41t80_chip_info *chip;

It's a bit weird that `chip' has static storage class here.  Was that
deliberate?


> + struct m41t80_data *clientdata = NULL;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C
> +  | I2C_FUNC_SMBUS_BYTE_DATA)) {
> + rc = -ENODEV;
> + goto exit;
> + }
> +
> + dev_info(>dev,
> +  "chip found, driver version " DRV_VERSION "\n");
> +
> + chip = NULL;
> + for (i = 0; i < ARRAY_SIZE(m41t80_chip_info_tbl); i++) {
> + if (!strcmp(m41t80_chip_info_tbl[i].name, client->name)) {
> + chip = _chip_info_tbl[i];
> + break;
> + }
> + }
> + if (!chip) {
> + dev_err(>dev, "%s is not supported\n", client->name);
> + rc = -ENODEV;
> + goto exit;
> + }
> +
> + clientdata = kzalloc(sizeof(*clientdata), GFP_KERNEL);
> + if (!clientdata) {
> + rc = -ENOMEM;
> + goto exit;
> + }
> +
> + rtc = rtc_device_register(client->name, >dev,
> +   _rtc_ops, THIS_MODULE);
> + if (IS_ERR(rtc)) {
> + rc = PTR_ERR(rtc);
> + rtc = NULL;
> + goto exit;
> + }
> +
> + clientdata->rtc = rtc;
> + clientdata->chip = chip;
> + i2c_set_clientdata(client, clientdata);
> +
> + /* If asked, disable SQW, set SQW frequency & re-enable */
> + if (pdata && pdata->sqw_freq) {
> + rc = i2c_smbus_read_byte_data(client, M41T80_REG_ALARM_MON);
> + if (rc < 0)
> + goto sqw_err;
> + if (i2c_smbus_write_byte_data(client, M41T80_REG_ALARM_MON,
> +   rc & ~0x40) < 0 ||
> + i2c_smbus_write_byte_data(client, M41T80_REG_SQW,
> +   pdata->sqw_freq) < 0 ||
> + i2c_smbus_write_byte_data(client, M41T80_REG_ALARM_MON,
> +   rc | 0x40) < 0)
> + goto sqw_err;
> + }
> +
> + /* Make sure HT (Halt Update) bit is cleared */
> + rc = i2c_smbus_read_byte_data(client, M41T80_REG_ALARM_HOUR);
> + if (rc < 0)
> + goto ht_err;
> +
> + if (rc & M41T80_ALHOUR_HT) {
> + if (chip->features & M41T80_FEATURE_HT) {
> + m41t80_get_datetime(client, );
> + dev_info(>dev, "HT bit was set!\n");
> + dev_info(>dev,
> +  "Power Down at "
> +  "%04i-%02i-%02i %02i:%02i:%02i\n",
> +  tm.tm_year + 1900,
> +  tm.tm_mon + 1, tm.tm_mday, tm.tm_hour,
> +  tm.tm_min, tm.tm_sec);
> + }
> + if (i2c_smbus_write_byte_data(client,
> +   M41T80_REG_ALARM_HOUR,
> +   rc & ~M41T80_ALHOUR_HT) < 0)
> + goto ht_err;
> + }
> +
> + /* Make sure ST (stop) bit is cleared */
> + rc = i2c_smbus_read_byte_data(client, M41T80_REG_SEC);
> + if (rc < 0)
> + goto st_err;
> +
> + if (rc & M41T80_SEC_ST) {
> + if (i2c_smbus_write_byte_data(client, M41T80_REG_SEC,
> +   rc & ~M41T80_SEC_ST) < 0)
> + goto st_err;
> + }
> +
> + rc = m41t80_sysfs_register(>dev);
> + if (rc)
> + goto exit;
> +
> + return 0;
> +
> +st_err:
> + rc = -EIO;
> + dev_err(>dev, "Can't clear ST bit\n");
> + goto exit;
> +ht_err:
> + rc = -EIO;
> + dev_err(>dev, "Can't clear HT bit\n");
> + goto exit;
> +sqw_err:
> + rc = -EIO;
> + dev_err(>dev, "Can't set SQW Frequency\n");
> +
> +exit:
> + if (rtc)
> + rtc_device_unregister(rtc);
> + kfree(clientdata);
> + return rc;
> +}

-
To unsubscribe from

Re: [PATCH 1/3] Make struct jprobe.entry a void *

On Tue, 2007-06-26 at 09:29 +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote:
> > ---
> > 
> > It isn't obvious where kprobes patches should go, is anyone "the" 
> > maintainer?
> > Instead I've just sent this to everyone who'd touched the code lately, or
> > might be otherwise interested.
> 
> There isn't a single maintainer for the kprobes infrastructure as it
> contains quite a bit of low level arch specific code. The working model
> currently is that the patches are sent to lkml with a cc to the
> maintainers listed, as you've rightly done.

OK, no worries. I guess that's a bit messy to put into a MAINTAINERS entry.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person


signature.asc
Description: This is a digitally signed message part

Re: Patent or not patent a new idea

On Tuesday June 26, [EMAIL PROTECTED] wrote:
> 
> Thanks for the brief howto there. I'll install the mdadm suite and
> experiment. It seems like a userspace driver?

mdadm is a userspace tool for managing the 'md' driver which is in the
linux kernel.

> > I don't know what you mean by '2'.
> 
> 2 meant in the way that a driver for a PC raid card is not much use on
> a Sparc.

Ahh... That is one of the great things about Linux.  You code in C,
and the driver works on every architecture (providing you are
reasonably careful, and the arch actually supports the hardware). :-)

NeilBrown
-
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] IOATDMA: fix section mismatches

2007-06-25 Thread Sam Ravnborg

On Mon, Jun 25, 2007 at 02:51:47PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Rename struct pci_driver data so that false section mismatch
> warnings won't be produced.
> 
> Sam, ISTM that depending on variable names is the weakest & worst part of
> modpost section checking.  Should __init_refok work here?  I got build
> errors when I tried to use it, probably because the struct pci_driver
> probe and remove methods are not marked "__init_refok".

Relying on naming is obviously a bad thing but without doing so
we would have tons of warnings from drivers/

__init_refok is for functions. For this case __initdata_refok
could have worked but to be consistent the renaming is much
better.

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

Re: [PATCH try #2] security: Convert LSM into a static interface

2007-06-25 Thread Kyle Moffett


Oops, typo:

On Jun 26, 2007, at 00:09:24, Kyle Moffett wrote:
This sounds suspiciously like "The mere fact that the Linux-2.6-VM  
cannot be built as a module is a rather weak argument for disabling  
VFS modules as a whole"


Meant to say: "...disabling VM modules as a whole."

Cheers,
Kyle Moffett

-
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: Patent or not patent a new idea

2007-06-25 Thread Graeme Sheppard


Neil Brown wrote:

???
(reads original description in more detail).

So... the filesystem images are identical in both copies, and the
"interesting" bit is that the image is just a file on some filesystem.

So could I implement your idea by:

  dd if=/dev/zero of=/1/bigfile count=lotsandlots
  dd if=/dev/zero of=/2/bigfile count=lotsandlots
  losetup /dev/loop1 /1/bigfile
  losetup /dev/loop2 /2/bigfile
  mdadm -C /dev/md0 --level=raid1 --raid-disks=2 /dev/loop1 /dev/loop2
  mkfs /dev/md0
  mount /dev/md2 /space

??

Why would you bother?  Well, I do it a lot of code testing, but I
would be hard pressed to make a case for that sort of config in
production.


Thanks for the brief howto there. I'll install the mdadm suite and
experiment. It seems like a userspace driver?


You said:

 1) the disks need
   not be the same size or from the same manufacturer; 2) the supporting code
   would be cross-platform.


md/raid already works happily with different sized drives from
different manufacturers (for raid1, it only uses as much space as the smaller
drive provides, For raid0 it uses it all).
I don't know what you mean by '2'.


2 meant in the way that a driver for a PC raid card is not much use on
a Sparc.


So I still cannot see anything particularly new.  What am I missing?


I think it's what I missed. Thanks for the heads-up. If the above is
a good technique it could suit me well.

-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-25 Thread Al Boldi

Alexandre Oliva wrote:
> Consider this scenario: vendor tivoizes Linux in the device, and
> includes the corresponding sources only in a partition that is
> theoretically accessible using the shipped kernel, but that nothing in
> the software available in the machine will let you get to.  Further,
> sources (like everything else on disk) are encrypted, and you can only
> decrypt it with hardware crypto that is disabled if the boot loader
> doesn't find a correct signature for the boot partition, or maybe the
> signature is irrelevant, given that everything on disk is encrypted in
> such a way that, if you don't have the keys, you can't update the
> kernel properly anyway.  The vendor refuses to give customers other
> copies of the sources.  To add insult to the injury, the vendor
> configures the computer to set up the encrypted disk partition
> containing the sources as a swap device, such that the shared-secret
> key used to access that entire filesystem is overwritten upon the
> first boot, rendering the entire previous contents of the partition
> holding the source code into an incomprehensible stream of bits.
>
> Does anyone think this is permitted by the letter of GPLv2?

Yes.

> Is it in the spirit of GPLv2?

No, but that's besides the point.

You can only hold people responsible for the letter, lest there be chaos.

If there is a specific usage spirit you want to protect, then you must 
formulate it in letter.

> How are the sources passed on in this way going to benefit the user or the
> community?

They still have to provide the source by other GPL means of their choosing.

> Is this still desirable by the Linux developers?

Looks undesirable to me, but still valid.


Thanks!

--
Al

-
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: mm snapshot broken-out-2007-06-20-10-12.tar.gz uploaded

On Wed, 20 Jun 2007 21:14:22 -0400 "Bob Picco" <[EMAIL PROTECTED]> wrote:

> Randy Dunlap wrote:   [Wed Jun 20 2007, 09:07:11PM EDT]
> > On Wed, 20 Jun 2007 20:51:22 -0400 Bob Picco wrote:
> > 
> > > [EMAIL PROTECTED] wrote:  [Wed Jun 20 2007, 01:14:34PM EDT]
> > > [snip]
> > > 
> > > Build breakage. pci_mmcfg_late_init is for i386.
> > 
> > then you want CONFIG_X86_32 instead of CONFIG_X86.
> > CONFIG_X86 is set/true for both X86_32 and X86_64.
> Then what I stated within the patch description is incorrect. pci.h which is 
> the
> required include for the declaration is conditionally for CONFIG_X86. So it is
> both I guess?

(reads code and config files, works out that the breakage must have been ia64)

Really the header file should take care of this, and conditional inclusion
is evil.

So let's give this a whizz?


From: Andrew Morton <[EMAIL PROTECTED]>

drivers/acpi/bus.c: In function `acpi_init':
drivers/acpi/bus.c:760: warning: implicit declaration of function 
`pci_mmcfg_late_init'

Fix this by always including pci.h in drivers/acpi/bus.c.

Also remove unneeded inclusion of asm/pci.h (linux/pci.h did that)

Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Jesse Barnes <[EMAIL PROTECTED]>
Cc: Linus Torvalds <[EMAIL PROTECTED]>
Cc: Rajesh Shah <[EMAIL PROTECTED]>
Cc: Robert Hancock <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 drivers/acpi/bus.c |3 +--
 linux/pci.h|0 
 2 files changed, 1 insertion(+), 2 deletions(-)

diff -puN 
drivers/acpi/bus.c~mmconfig-validate-against-acpi-motherboard-resources-fix-2-3 
drivers/acpi/bus.c
--- 
a/drivers/acpi/bus.c~mmconfig-validate-against-acpi-motherboard-resources-fix-2-3
+++ a/drivers/acpi/bus.c
@@ -34,9 +34,8 @@
 #include 
 #ifdef CONFIG_X86
 #include 
-#include 
-#include 
 #endif
+#include 
 #include 
 #include 
 
_

-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

2007-06-25 Thread Jan Harkes

On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote:
> Consider this scenario: vendor tivoizes Linux in the device, and
> includes the corresponding sources only in a partition that is
> theoretically accessible using the shipped kernel, but that nothing in
> the software available in the machine will let you get to.  Further,
> sources (like everything else on disk) are encrypted, and you can only

Interesting scenario, it seems to comply with GPLv2 on the surface.

If that kernel doesn't actually allow access and wipes the source
partition to use it as swap on first boot, then no machine is actually
capable of reading the source. So it isn't really machine readable.
Another gripe is that encrypted media are not customarily used for
software interchange. So that's 2 (minor) strikes where this method of
distribution doesn't seem to match the language of section 3a.

You also cannot interpret the encrypted partition as source code because
a bit further down in section 3, it defines source code as,
  "The source code for a work means the preferred form of the work for
  making modifications to it."

So now we get to section 6. The recipient receives a license to copy,
distribute or modify. You may not impose further restrictions on
these rights granted herein.

You could argue that they do not restrict copying, distribution
and modification of the sources in general, only of the specific copy
they distribute. However here we go back to section 2 which states that
their modified copy is a derived work which must be licensed under the
GPLv2, so that would make it specific enough that recipients have in
fact been granted the right to copy, distribute and modify the copy of
the source of that corresponds to the distributed binaries, which is
restricted because of the encryption which prevents the user to copy,
distribute or modify the source code.

> Does anyone think this is permitted by the letter of GPLv2?

No.

> How are the sources passed on in this way going to benefit the user or
> the community?

Not a really interesting question if the method of distribution violates
the letter of the GPLv2, is it? They get sued for copyright infringement
because they are not in compliance with section 3 and the sources are
released as a result.

Jan

-
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 try #2] security: Convert LSM into a static interface

2007-06-25 Thread Kyle Moffett


On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote:

On Monday 25 June 2007 06:33, James Morris wrote:
Convert LSM into a static interface, as the ability to unload a  
security module is not required by in-tree users and potentially  
complicates the overall security architecture.


It's useful for some LSMs to be modular, and LSMs which are y/n  
options won't have any security architecture issues with unloading  
at all. The mere fact that SELinux cannot be built as a module is a  
rather weak argument for disabling LSM modules as a whole, so   
please don't.


Here are a few questions for you:

  1)  What do you expect to happen to all the megs of security data  
when you "rmmod selinux"?  Do you maintain a massive linked list of  
security data (with all the locking and performance problems) so that  
you can iterate over it calling kfree()? What synchronization  
primitive do we have right now which could safely stop all CPUs  
outside of security calls while we NULL out and free security data  
and disable security operations?  Don't say "software suspend" and  
"process freezer", since those have whole order-of-magnitude- 
complexity problems of their own (and don't always work right either).


  2)  When you "modprobe my_custom_security_module", how exactly do  
you expect that all the processes, files, shared memory segments,  
file descriptors, sockets, SYSV mutexes, packets, etc will get  
appropriate security pointers?  This isn't even solvable the same way  
the "rmmod" problem is, since most of that isn't even accessible  
without iterating over the ENTIRE dcache, icache, every process,  
every process' file-descriptors, every socket, every unix socket,  
every anonymous socket, every SYSV shm object, every currently-in- 
process packet.


  3)  This sounds suspiciously like "The mere fact that the  
Linux-2.6-VM cannot be built as a module is a rather weak argument  
for disabling VFS modules as a whole".  We don't do "pluggable  
fundamental infrastructure" in Linux.  If it's fundamental  
infrastructure then you eliminate as many differences as possible and  
leave the rest to CONFIG options (or delete it entirely).



So... Do you have a proposal for solving those rather fundamental  
design gotchas?  If so, I'm sure everybody here would love to see  
your patch; though maybe not if it's a 32MB patch-zilla-of-doom (AKPM  
beware, the merge-conflict-from-hell is on its way).  On the other  
hand, if you accept that these problems basically can't be solved and  
we make things static and rip out a bunch of code, we can probably  
improve our performance under larger security models (like SELinux/ 
AppArmor/TOMOYO/MagicSecurityFlavorOfTheWeek(TM)) by a percent or two.


Cheers,
Kyle Moffett

-
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] SLOB allocator imcompatible SLAB


Yoshinori Sato wrote:

At Fri, 22 Jun 2007 09:56:35 -0500,
Matt Mackall wrote:


On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:


Because the page which SLOB allocator got does not have PG_slab,


This is for a NOMMU system?



Yes.
 


You're using an old kernel with an old version of SLOB. SLOB in newer
kernels actually sets per-page flags. Nick, can you see any reason not
to s/PG_active/PG_slab/ in the current code?


The problem with this is that PG_private is used only for the SLOB
part of the allocator and not the bigblock part.

We _could_ just bite the bullet and have SLOB set PG_slab, however
that would encouarage more users of this flag which we should hope
to get rid of one day.

The real problem is that nommu wants to get the size of either
kmalloc or alloc_pages objects and it needs to differentiate
between them. So I would rather nommu to take its own page flag
(could overload PG_swapcache, perhaps?), and set that flag on
pages it allocates directly, then uses that to determine whether
to call ksize or not.

--
SUSE Labs, Novell Inc.
-
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 try #2] security: Convert LSM into a static interface

2007-06-25 Thread Serge E. Hallyn

Quoting James Morris ([EMAIL PROTECTED]):
> On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:
> 
> > It's useful for some LSMs to be modular, and LSMs which are y/n options 
> > won't 
> > have any security architecture issues with unloading at all. 
> 
> Which LSMs?  Upstream, there are SELinux and capabilty, and they're not 
> safe as loadable modules.
> 
> > The mere fact 
> > that SELinux cannot be built as a module is a rather weak argument for 
> > disabling LSM modules as a whole, so  please don't.
> 
> That's not the argument.  Please review the thread.

The argument is 'abuse', right?

Abuse is defined as using the LSM hooks for non-security applications,
right?

It seems to me that the community is doing a good job of discouraging
such abuse - by redirecting the "wrong-doers" to implement proper
upstream solutions, i.e. taskstats, the audit subsystem, etc.

Such encouragement seems a far better response than taking away freedoms
and flexibility from everyone.

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

Re: [PATCH 1/3] Make struct jprobe.entry a void *

2007-06-25 Thread Ananth N Mavinakayanahalli

On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote:
> ---
> 
> It isn't obvious where kprobes patches should go, is anyone "the" maintainer?
> Instead I've just sent this to everyone who'd touched the code lately, or
> might be otherwise interested.

There isn't a single maintainer for the kprobes infrastructure as it
contains quite a bit of low level arch specific code. The working model
currently is that the patches are sent to lkml with a cc to the
maintainers listed, as you've rightly done.

Ananth
-
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] fsblock


David Chinner wrote:

On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:


I'm announcing "fsblock" now because it is quite intrusive and so I'd
like to get some thoughts about significantly changing this core part
of the kernel.



Can you rename it to something other than shorthand for
"filesystem block"? e.g. When you say:



- In line with the above item, filesystem block allocation is performed



What are we actually talking aout here? filesystem block allocation
is something a filesystem does to allocate blocks on disk, not
allocate a mapping structure in memory.

Realistically, this is not about "filesystem blocks", this is
about file offset to disk blocks. i.e. it's a mapping.


Yeah, fsblock ~= the layer between the fs and the block layers.
But don't take the name too literally, like a struct page isn't
actually a page of memory ;)



 Probably better would be to
 move towards offset,length rather than page based fs APIs where everything
 can be batched up nicely and this sort of non-trivial locking can be more
 optimal.



If we are going to turn over the API completely like this, can
we seriously look at moving to this sort of interface at the same
time?


Yeah we can move to anything. But note that fsblock is perfectly
happy with <= PAGE_CACHE_SIZE blocks today, and isn't _terrible_
at >.



With a offset/len interface, we can start to track contiguous
ranges of blocks rather than persisting with a structure per
filesystem block. If you want to save memory, thet's where
we need to go.

XFS uses "iomaps" for this purpose - it's basically:

- start offset into file
- start block on disk
- length of mapping
	- state 


With special "disk blocks" for indicating delayed allocation
blocks (-1) and unwritten extents (-2). Worst case we end up
with is an iomap per filesystem block.


I was thinking about doing an extent based scheme, but it has
some issues as well. Block based is light weight and simple, it
aligns nicely with the pagecache structures.



If we allow iomaps to be split and combined along with range
locking, we can parallelise read and write access to each
file on an iomap basis, etc. There's plenty of goodness that
comes from indexing by range


Some operations AFAIKS will always need to be per-page (eg. in
the core VM it wants to lock a single page to fault it in, or
wait for a single page to writeout etc). So I didn't see a huge
gain in a one-lock-per-extent type arrangement.

If you're worried about parallelisability, then I don't see what
iomaps give you that buffer heads or fsblocks do not? In fact
they would be worse because there are fewer of them? :)

But remember that once the filesystems have accessor APIs and
can handle multiple pages per fsblock, that would already be
most of the work done for the fs and the mm to go to an extent
based representation.



FWIW, I really see little point in making all the filesystems
work with fsblocks if the plan is to change the API again in
a major way a year down the track. Let's get all the changes
we think are necessary in one basket first, and then work out
a coherent plan to implement them ;)


The aops API changes and the fsblock layer are kind of two
seperate things. I'm slowly implementing things as I go (eg.
see perform_write aop, which is exactly the offset,length
based API that I'm talking about).

fsblocks can be implemented on the old or the new APIs. New
APIs won't invalidate work to convert a filesystem to fsblocks.



- Large block support. I can mount and run an 8K block size minix3 fs on
 my 4K page system and it didn't require anything special in the fs. We
 can go up to about 32MB blocks now, and gigabyte+ blocks would only
 require  one more bit in the fsblock flags. fsblock_superpage blocks
 are > PAGE_CACHE_SIZE, midpage ==, and subpage <.



My 2c worth - this is a damn complex way of introducing large block
size support. It has all the problems I pointed out that it would
have (locking issues, vmap overhead, every filesystem needs needs
major changes and it's not very efficient) and it's going to take
quite some time to stabilise.


What locking issues? It locks pages in pagecache offset ascending
order, which already has precedent and is really the only sane way
to do it so it's not like it precludes other possible sane lock
orderings.

vmap overhead is an issue, however I did it mainly for easy of
conversion. I guess things like superblocks and such would make
use of it happily. Most other things should be able to be
implemented with page based helpers (just a couple of bitops
helpers would pretty much cover minix). If it is still a problem,
then I can implement a proper vmap cache.

But the major changes in the filesystem are not for vmaps, but for
page accessors. As I said, this allows blkdev to move out of
lowmem and also closes CPU cache coherency problems. (as well as
not having to carry around a vmem pointer of course).



If this is the only real feature that

Re: [PATCH 007 of 8] knfsd: nfsd4: vary maximum delegation limit based on RAM size

On Thu, 21 Jun 2007 14:31:12 +1000 NeilBrown <[EMAIL PROTECTED]> wrote:

> 
> From: "J. Bruce Fields" <[EMAIL PROTECTED]>
> 
> 
> Our original NFSv4 delegation policy was to give out a read delegation
> on any open when it was possible to.
> 
> Since the lifetime of a delegation isn't limited to that of an open, a
> client may quite reasonably hang on to a delegation as long as it has
> the inode cached.  This becomes an obvious problem the first time a
> client's inode cache approaches the size of the server's total memory.
> 
> Our first quick solution was to add a hard-coded limit.  This patch
> makes a mild incremental improvement by varying that limit according to
> the server's total memory size, allowing at most 4 delegations per
> megabyte of RAM.
> 
> My quick back-of-the-envelope calculation finds that in the worst case
> (where every delegation is for a different inode), a delegation could
> take about 1.5K, which would make the worst case usage about 6% of
> memory.  The new limit works out to be about the same as the old on a
> 1-gig server.
> 
> ...
>  
> +static void
> +set_max_delegations()
> +{
> + struct sysinfo sys;
> +
> + si_meminfo();
> + sys.totalram *= sys.mem_unit;
> + sys.totalram >>= (18 - PAGE_SHIFT);
> + max_delegations = (unsigned int) sys.totalram;
> +}

Please put yourself in the position of the reader who happens across this
code and wonders why it is that way.

They could of course go hunt it out of the git repo but I do think it's
quite a bit more reader-friendly to explain the thinking in code comments.

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

Re: [PATCH 1/3] Make struct jprobe.entry a void *

2007-06-25 Thread Ananth N Mavinakayanahalli

On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote:
> Currently jprobe.entry is a kprobe_opcode_t *, but that's a lie. On some
> platforms it doesn't point to an opcode at all, it points to a function
> descriptor.
> 
> It's really a pointer to something that the arch code can turn into a
> function entry point. And that's what actually happens, none of the
> generic code ever looks at jprobe.entry, it's only ever dereferenced
> by arch code.
> 
> So just make it a void *.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>

Tested on powerpc. Ack to all three patches plus Andrew's declaration
fixup.

Thanks Michael for the patches.

Acked-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>

> ---
> 
> It isn't obvious where kprobes patches should go, is anyone "the" maintainer?
> Instead I've just sent this to everyone who'd touched the code lately, or
> might be otherwise interested.
> 
> 
>  include/linux/kprobes.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> index 23adf60..f4e53b7 100644
> --- a/include/linux/kprobes.h
> +++ b/include/linux/kprobes.h
> @@ -116,7 +116,7 @@ struct kprobe {
>   */
>  struct jprobe {
>   struct kprobe kp;
> - kprobe_opcode_t *entry; /* probe handling code to jump to */
> + void *entry;/* probe handling code to jump to */
>  };
> 
>  DECLARE_PER_CPU(struct kprobe *, current_kprobe);
> -- 
> 1.5.1.3.g7a33b
-
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: Patent or not patent a new idea

On Tuesday June 26, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> > 
> > Sounds a lot like "RAIF" - ask google for details.
> 
> I did not know about RAIF. RAIF "merges" separate filesystems? That is a
> good idea in itself.
> 
> My idea is for driver that provides a filesystem from image files it
> controls. Because it knows these resources it uses access in tandem to
> attain performance.

???
(reads original description in more detail).

So... the filesystem images are identical in both copies, and the
"interesting" bit is that the image is just a file on some filesystem.

So could I implement your idea by:

  dd if=/dev/zero of=/1/bigfile count=lotsandlots
  dd if=/dev/zero of=/2/bigfile count=lotsandlots
  losetup /dev/loop1 /1/bigfile
  losetup /dev/loop2 /2/bigfile
  mdadm -C /dev/md0 --level=raid1 --raid-disks=2 /dev/loop1 /dev/loop2
  mkfs /dev/md0
  mount /dev/md2 /space

??

Why would you bother?  Well, I do it a lot of code testing, but I
would be hard pressed to make a case for that sort of config in
production.

You said:
>  1) the disks need
>not be the same size or from the same manufacturer; 2) the supporting code
>would be cross-platform.

md/raid already works happily with different sized drives from
different manufacturers (for raid1, it only uses as much space as the smaller
drive provides, For raid0 it uses it all).
I don't know what you mean by '2'.

So I still cannot see anything particularly new.  What am I missing?

NeilBrown
-
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] trim memory not covered by WB MTRRs

2007-06-25 Thread Jesse Barnes

On Monday, June 25, 2007 8:29:35 pm Jesse Barnes wrote:
> Is there an is_cpu() check to differentiate between those?  Anyway I'd
> rather not enable it unless we see reports though...  So far I've only seen
> reports of this problem on some recent Intel based systems.

Oh, and FYI I've seen new systems with a default mapping type of WB, with a 
few uncached holes for MMIO.  That means PAT will be absolutely required on 
those systems if we want to use WC for the framebuffer or other memory.  I 
hope it's ready for mainline soon...

Jesse
-
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] trim memory not covered by WB MTRRs

2007-06-25 Thread Jesse Barnes

On Monday, June 25, 2007 5:54:49 pm Eric W. Biederman wrote:
> Jesse Barnes <[EMAIL PROTECTED]> writes:
> > On Monday, June 25, 2007 4:34:33 Andi Kleen wrote:
> >> > This patch fixes a bug in the last patch that caused the code to
> >> > run on non-Intel machines (AMD machines apparently don't need it
> >>
> >> Actually the problem can happen on AMD too, but the symptoms can
> >> be different and there can be more wrong than just the MTRRs.
> >
> > I should have been more specific in the changelog.  My understanding is
> > that AMD systems don't need it for memory above 4G, and since the code
> > doesn't handle holes (no test systems, nor any real reports that I've
> > seen), it's not that useful for finding problems below 4G.  We can
> > always change that later if needed though.
>
> For the K7 and K8 cores AMD systems are exactly like Intel systems
> with respect to MTRRs (although AMD systems also have additional registers)
> For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there
> is an additional mechanism that makes everything above 4G write-back
> cacheable without using any MTRRs.
>
> So only on the very latest AMD cpus would this code not be applicable.

Is there an is_cpu() check to differentiate between those?  Anyway I'd rather 
not enable it unless we see reports though...  So far I've only seen reports 
of this problem on some recent Intel based systems.

Jesse


-
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: vm/fs meetup in september?

2007-06-25 Thread Andreas Dilger

On Jun 26, 2007  12:35 +1000, Nick Piggin wrote:
> Leaving my opinion of higher order pagecache aside, this _may_ be an
> example of something that doesn't need a lot of attention, because it
> should be fairly uncontroversial from a filesystem's POV? (eg. it is
> more a relevant item to memory management and possibly block layer).
> OTOH if it is discussed in the context of "large blocks in the buffer
> layer is crap because we can do it with higher order pagecache", then
> that might be interesting :)

FWIW, being able to have large (8-64kB) blocksize would be great for
ext2/3/4.  We'd sort of been betting on this by limiting the on-disk
extent format to 48-bit physical block numbers, and to have 2 patches
to implement this in as many weeks is excellent.

To me the mechanism doesn't matter, whether through fsblock or high-order
PAGE_SIZE.  I'll let the rest of you duke it out as long as at least one
of them makes it into the kernel.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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: Patent or not patent a new idea

2007-06-25 Thread Graeme Sheppard


Neil Brown wrote:

On Tuesday June 26, [EMAIL PROTECTED] wrote:

Posting it here seems the best thing to do.

To the inventor goes naming privilege and I'm calling this one softer raid.
It is a form of storage raid implemented in software, as contrasted to
software and hardware raid which are dependent on using required hardware.

To create a loop filesystem is straight forward. The commands are dd,
mkfs.*, mount -o loop. Basically what I propose is that the image file is
copied to another harddisk (in the case of ide not on the same cable) and
it too is mounted in conjunction of the original with cooperation. When a
read request for a block of say 100k is made, the kernel pulls 50k from
each disk - maybe a simple doubling of throughput.


Sounds a lot like "RAIF" - ask google for details.


I did not know about RAIF. RAIF "merges" separate filesystems? That is a
good idea in itself.

My idea is for driver that provides a filesystem from image files it
controls. Because it knows these resources it uses access in tandem to
attain performance.

-
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 16/16] fix handling of integer constant expressions

2007-06-25 Thread Josh Triplett

Al Viro wrote:
> On Sun, Jun 24, 2007 at 10:31:06PM -0700, Josh Triplett wrote:
>> Al Viro wrote:
>>> Joy.  OK, folks, disregard 16/16 in the current form; everything prior
>>> to it stands on its own.
>> Acknowledged.  The rest of the patches look good to me, so I'll merge 1-15
>> soon, and ignore 16.
>>
>> Do you have those patches in public git somewhere, or would you like me to
>> just apply the patches from mail?
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/sparse.git/ misc

No changes to validation output at any point in the series.  Merged.  Thanks!

- Josh Triplett




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] hw_random: add quality categories

2007-06-25 Thread Matt Mackall

On Sun, Jun 24, 2007 at 03:55:22PM +0200, Michael Buesch wrote:
> This adds quality categories for hardware random number generators.
> 
...
> +
> +/**
> + * enum hwrng_quality - Quality identifier for RNG hardware
> + * @HWRNG_QUAL_HIGH: High quality RNG. Higher quality than
> + *   what is found on the usual PC mainboards.
> + *   Use that for special dedicated RNG
> + *   extension boards.
> + * @HWRNG_QUAL_NORMAL:   PC-onboard-RNG devices.
> + * @HWRNG_QUAL_LOW:  Low quality RNG devices. Use this for
> + *   devices which gather the entropy from possibly
> + *   bad sources, like the network.
> + * @HWRNG_QUAL_PSEUDO:   Pseudo RNG device. Use this for devices
> + *   which are not RNG devices by definition, but
> + *   could be used as such. For example various
> + *   hardware sensors, like a motion sensor.
> + */

I don't think these definitions are very useful.

There are basically three ways of measuring RNG quality:

a) does it generate a good spectrum based on an unpredictable physical
process like Schott noise or free-running oscillator beat patterns?

b) can the end-user trust that the design is implemented as described?

c) does it output lots of bits fast?

Anything that fails (a) belongs in the PSEUDO class. This applies to
RNGs where the implementation is undocumented too. (There's not much
excuse for this as it costs negligible silicon to do this right.)

Anything that passes (b) is something that the end-user built
themselves while wearing their tinfoil hat.

Anything that claims to be significantly better than the trivial
circuit and whitening on a typical PC is probably marketing hype. 

Which brings us down to (c). And basically all hardware RNGs are
plenty fast enough.

So that's basically three orthogonal axes: "real", "trusted", and
"fast". And "trusted" trumps "real", which trumps "fast".

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

Re: [patch 1/3] add the fsblock layer


Neil Brown wrote:

On Tuesday June 26, [EMAIL PROTECTED] wrote:


Chris Mason wrote:


The block device pagecache isn't special, and certainly isn't that much
code.  I would suggest keeping it buffer head specific and making a
second variant that does only fsblocks.  This is mostly to keep the
semantics of PagePrivate sane, lets not fuzz the line.


That would require a new inode and address_space for the fsblock
type blockdev pagecache, wouldn't it? I just can't think of a
better non-intrusive way of allowing a buffer_head filesystem and
an fsblock filesystem to live on the same blkdev together.



I don't think they would ever try to.  Both filesystems would bd_claim
the blkdev, and only one would win.


Hmm OK, I might have confused myself thinking about partitions...


The issue is more of a filesystem sharing a blockdev with the
block-special device (i.e. open("/dev/sda1"), read) isn't it?

If a filesystem wants to attach information to the blockdev pagecache
that is different to what blockdev want to attach, then I think "Yes"
- a new inode and address space is what it needs to create.

Then you get into consistency issues between the metadata and direct
blockdevice access.  Do we care about those?


Yeah that issue is definitely a real one. The problem is not just
consistency, but "how do the block device aops even know that the
PG_private page they have has buffer heads or fsblocks", so it is
an oopsable condition rather than just a plain consistency issue
(consistency is already not guaranteed).

--
SUSE Labs, Novell Inc.
-
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] fsblock

2007-06-25 Thread David Chinner

On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
> 
> I'm announcing "fsblock" now because it is quite intrusive and so I'd
> like to get some thoughts about significantly changing this core part
> of the kernel.

Can you rename it to something other than shorthand for
"filesystem block"? e.g. When you say:

> - In line with the above item, filesystem block allocation is performed

What are we actually talking aout here? filesystem block allocation
is something a filesystem does to allocate blocks on disk, not
allocate a mapping structure in memory.

Realistically, this is not about "filesystem blocks", this is
about file offset to disk blocks. i.e. it's a mapping.

>   Probably better would be to
>   move towards offset,length rather than page based fs APIs where everything
>   can be batched up nicely and this sort of non-trivial locking can be more
>   optimal.

If we are going to turn over the API completely like this, can
we seriously look at moving to this sort of interface at the same
time?

With a offset/len interface, we can start to track contiguous
ranges of blocks rather than persisting with a structure per
filesystem block. If you want to save memory, thet's where
we need to go.

XFS uses "iomaps" for this purpose - it's basically:

- start offset into file
- start block on disk
- length of mapping
- state 

With special "disk blocks" for indicating delayed allocation
blocks (-1) and unwritten extents (-2). Worst case we end up
with is an iomap per filesystem block.

If we allow iomaps to be split and combined along with range
locking, we can parallelise read and write access to each
file on an iomap basis, etc. There's plenty of goodness that
comes from indexing by range

FWIW, I really see little point in making all the filesystems
work with fsblocks if the plan is to change the API again in
a major way a year down the track. Let's get all the changes
we think are necessary in one basket first, and then work out
a coherent plan to implement them ;)

> - Large block support. I can mount and run an 8K block size minix3 fs on
>   my 4K page system and it didn't require anything special in the fs. We
>   can go up to about 32MB blocks now, and gigabyte+ blocks would only
>   require  one more bit in the fsblock flags. fsblock_superpage blocks
>   are > PAGE_CACHE_SIZE, midpage ==, and subpage <.

My 2c worth - this is a damn complex way of introducing large block
size support. It has all the problems I pointed out that it would
have (locking issues, vmap overhead, every filesystem needs needs
major changes and it's not very efficient) and it's going to take
quite some time to stabilise.

If this is the only real feature that fsblocks are going to give us,
then I think this is a waste of time. If we are going to replace
buffer heads, lets do it with something that is completely
independent of filesystem block size and not introduce something
that is just a bufferhead on steroids.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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] CFS scheduler, -v18

On Sat, 23 Jun 2007 00:20:36 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:

> 
> * S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
> 
> > > kernel/sched.c:745:28: sched_idletask.c: No such file or directory
> > 
> > Ahh and this happens with [1], grabbing sched_idletask.c from .18 one 
> > solves 
> > the problem...
> 
> oops, indeed - i've fixed up the -git patch:
> 
>   http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-git-v18.patch
> 

So I locally generated the diff to take -mm up to the above version of CFS.


- sys_sched_yield_to() went away?  I guess I missed that.

- Curious.  the simplification of task_tick_rt() seems to go only
  halfway.  Could do

if (p->policy != SCHED_RR)
return;

if (--p->time_slice)
return;

/* stuff goes here */

- dud macro:

#define is_rt_policy(p) ((p) == SCHED_FIFO || (p) == SCHED_RR)

  It evaluates its arg twice and could and should be coded in C.

  There are a bunch of other don't-need-to-be-implemented-as-a-macro
  macros around there too.  Generally, I suggest you review all the
  patchset for macros-which-don't-need-to-be-macros.

- Extraneous newline:

enum cpu_idle_type
{

- Style thing:

struct sched_entity {
struct load_weight load;/* for nice- load-balancing purposes */
int on_rq;
struct rb_node run_node;
unsigned long delta_exec;
s64 delta_fair;

u64 wait_start_fair;
u64 wait_start;
u64 exec_start;
u64 sleep_start, sleep_start_fair;
u64 block_start;
u64 sleep_max;
u64 block_max;
u64 exec_max;
u64 wait_max;
u64 last_ran;

s64 wait_runtime;
u64 sum_exec_runtime;
s64 fair_key;
s64 sum_wait_runtime, sum_sleep_runtime;
unsigned long wait_runtime_overruns, wait_runtime_underruns;
};

  I think the one-definition-per-line style is better than the `unsigned
  long foo,bar,zot,zit;' thing.  Easier to read, easier to read subsequent
  patches and it leaves more room for a comment describing what the field
  does.

- None of these fields have comments describing what they do ;)

- __exit_signal() does apparently-unlocked 64-bit arith.  Is there some
  implicit locking here or do we not care about the occasional race-induced
  inaccuracy?

  (ditto, lots of places, I expect)

  (Gee, there's shitloads of 64-bit stuff in there.  Does it all _really_
  need to be 64-bit on 32-bit?)

- weight_s64() (what does this do?) looks too big to inline on 32-bit.

- update_stats_enqueue() looks too big to inline even on 64-bit.

- Overall, this change is tremendously huge for something which is
  supposedly ready-to-merge.  Looks like a lot of that is the sched_entity
  conversion, but afaict there's quite a lot besides.

- Should "4" in

(sysctl_sched_features & 4)

  be enumerated?

- Maybe even __check_preempt_curr_fair() is too porky to inline.

- There really is an astonishing amount of 64-bit arith in here...

- Some opportunities for useful comments have been missed ;)

#define NICE_0_LOAD SCHED_LOAD_SCALE
#define NICE_0_SHIFTSCHED_LOAD_SHIFT

  

- Should any of those new 64-bit arith functions in sched.c be pulled out
  and made generic?

- update_curr_load() is huge, inlined and has several callsites?

- lots more macros-which-dont-need-to-be-macros in sched.c:
  load_weight(), PRIO_TO_load_weight(), RTPRIO_TO_load_weight(), maybe
  others.  People are more inclined to comment functions than they are
  macros, for some reason.

- inc_load(), dec_load(), inc_nr_running(), dec_nr_running(): these will
  generate plenty of code on 32-bit and they're all inlined with multiple
  callsites.

- overall, CFS takes sched.o from 41157 of .text up to 48781 on x86_64,
  which at 18% is rather a large bloat.  Hopefully a lot of this is the new
  debug stuff.

- On i386 sched.o went from 33755 up to 43660 which is 29% growth. 
  Possibly acceptable, but why did it increase a lot more than the x86_64
  version?  All that 64-bit arith, I assume?

- style (or the lack thereof):

p->se.sum_wait_runtime = p->se.sum_sleep_runtime = 0;
p->se.sleep_start = p->se.sleep_start_fair = p->se.block_start = 0;
p->se.sleep_max = p->se.block_max = p->se.exec_max = p->se.wait_max = 0;
p->se.wait_runtime_overruns = p->se.wait_runtime_underruns = 0;

  bit of an eyesore?

- in sched_init() this looks funny:

rq->ls.load_update_last = sched_clock();
rq->ls.load_update_start = sched_clock();

  was it intended that these both get the same value?


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

Re: [patch 1/3] add the fsblock layer

On Tuesday June 26, [EMAIL PROTECTED] wrote:
> Chris Mason wrote:
> > 
> > The block device pagecache isn't special, and certainly isn't that much
> > code.  I would suggest keeping it buffer head specific and making a
> > second variant that does only fsblocks.  This is mostly to keep the
> > semantics of PagePrivate sane, lets not fuzz the line.
> 
> That would require a new inode and address_space for the fsblock
> type blockdev pagecache, wouldn't it? I just can't think of a
> better non-intrusive way of allowing a buffer_head filesystem and
> an fsblock filesystem to live on the same blkdev together.

I don't think they would ever try to.  Both filesystems would bd_claim
the blkdev, and only one would win.

The issue is more of a filesystem sharing a blockdev with the
block-special device (i.e. open("/dev/sda1"), read) isn't it?

If a filesystem wants to attach information to the blockdev pagecache
that is different to what blockdev want to attach, then I think "Yes"
- a new inode and address space is what it needs to create.

Then you get into consistency issues between the metadata and direct
blockdevice access.  Do we care about those?


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

Re: [patch 1/3] add the fsblock layer


Chris Mason wrote:

On Sun, Jun 24, 2007 at 03:46:13AM +0200, Nick Piggin wrote:


Rewrite the buffer layer.



Overall, I like the basic concepts, but it is hard to track the locking
rules.  Could you please write them up?


Yeah I will do that.

Thanks for taking a look. One thing I am thinking about is to get
rid of the unmap_underlying_metadata calls from the generic code.
I found they were required for minix to prevent corruption, however
I don't know exactly what metadata is interfering here (maybe it
is indirect blocks or something?). Anyway, I think I will make it
a requirement that the filesystem has to already handle this before
returning a newly allocated block -- they can probably do it more
efficiently and we avoid the extra work on every block allocation.



I like the way you split out the assoc_buffers from the main fsblock
code, but the list setup is still something of a wart.  It also provides
poor ordering of blocks for writeback.


Yeah, I didn't know how much effort to put in here because I don't
know whether modern filesystems are going to need to implement their
own management of this stuff or not.

I haven't actually instrumented this in something like ext2 to see
how much IO comes from the assoc buffers...



I think it makes sense to replace the assoc_buffers list head with a
radix tree sorted by block number.  mark_buffer_dirty_inode would up the
reference count and put it into the radix, the various flushing routines
would walk the radix etc.

If you wanted to be able to drop the reference count once the block was
written you could have a back pointer to the appropriate inode.


I was actually thinking about a radix-tree :) One annoyance is that
unsigned long != sector_t :P rbtree would probably be OK.

--
SUSE Labs, Novell Inc.
-
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: vm/fs meetup in september?


Christoph Hellwig wrote:

On Sun, Jun 24, 2007 at 06:23:45AM +0200, Nick Piggin wrote:


I'd just like to take the chance also to ask about a VM/FS meetup some
time around kernel summit (maybe take a big of time during UKUUG or so).



I won't be around until a day or two before KS, so I'd prefer to have it
after KS if possible.


I'd like to see you there, so I hope we can find a date that most
people are happy with. I'll try to start working that out after we
have a rough idea of who's interested.



I don't want to do it in the VM summit, because that kind of alienates
the filesystem guys. What I want to talk about is anything and everything
that the VM can do better to help the fs and vice versa.  I'd like to
stay away from memory management where not too applicable to the fs.



As more of a filesystem person I wouldn't mind it being attached to a VM
conf.  In the worst case we'll just rename it VM/FS conference.  When and
where is it scheduled?


I'll just cc Martin, however the VM conference I think is pretty short
on filesystem people. I'd also like to avoid a lot of VM topics and
hopefully have enough time for a topic of interest or so from each fs
maintainer who has something to talk about.

But I'm open to ideas that will make it work better. FWIW, Anton has
offered to try arranging conference facilities at the university, so
I think we should be covered there.



- the address space operations APIs, and their page based nature. I think
 it would be nice to generally move toward offset,length based ones as
 much as possible because it should give more efficiency and flexibility
 in the filesystem.

- write_begin API if it is still an issue by that date. Hope not :)

- truncate races

- fsblock if it hasn't been shot down by then



Don't forget high order pagecache please.



Leaving my opinion of higher order pagecache aside, this _may_ be an
example of something that doesn't need a lot of attention, because it
should be fairly uncontroversial from a filesystem's POV? (eg. it is
more a relevant item to memory management and possibly block layer).
OTOH if it is discussed in the context of "large blocks in the buffer
layer is crap because we can do it with higher order pagecache", then
that might be interesting :)

Anyway, I won't say no to any proposal, so keep the ideas coming. We
can talk about whatever we find interesting on the day.



- how to make complex API changes without having to fix most things
 yourself.



More issues:


Thanks Christoph, sounds good.

--
SUSE Labs, Novell Inc.

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

Re: [patch 1/3] add the fsblock layer


Chris Mason wrote:

On Mon, Jun 25, 2007 at 05:41:58PM +1000, Nick Piggin wrote:


Neil Brown wrote:



Why do you think you need PG_blocks?


Block device pagecache (buffer cache) has to be able to accept
attachment of either buffers or blocks for filesystem metadata,
and call into either buffer.c or fsblock.c based on that.

If the page flag is really important, we can do some awful hack
like assuming the first long of the private data is flags, and
those flags will tell us whether the structure is a buffer_head
or fsblock ;) But for now it is just easier to use a page flag.



The block device pagecache isn't special, and certainly isn't that much
code.  I would suggest keeping it buffer head specific and making a
second variant that does only fsblocks.  This is mostly to keep the
semantics of PagePrivate sane, lets not fuzz the line.


That would require a new inode and address_space for the fsblock
type blockdev pagecache, wouldn't it? I just can't think of a
better non-intrusive way of allowing a buffer_head filesystem and
an fsblock filesystem to live on the same blkdev together.

--
SUSE Labs, Novell Inc.
-
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/1] Add a prototype for arch_deref_entry_point()

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 include/linux/kprobes.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index bd89285..51464d1 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -214,6 +214,7 @@ int longjmp_break_handler(struct kprobe *, struct pt_regs 
*);
 int register_jprobe(struct jprobe *p);
 void unregister_jprobe(struct jprobe *p);
 void jprobe_return(void);
+unsigned long arch_deref_entry_point(void *);
 
 int register_kretprobe(struct kretprobe *rp);
 void unregister_kretprobe(struct kretprobe *rp);
-- 
1.5.1.3.g7a33b

-
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.22-rc5-yesterdaygit with VM debug: BUG in mm/rmap.c:66: anon_vma_link ?


Hugh Dickins wrote:

On Mon, 25 Jun 2007, Petr Vandrovec wrote:


Hello,
 to catch some memory corruption bug in our code I've modified malloc to do
mmap + mprotect - which has unfortunate effect that it creates thousands and
thousands of VMAs.  Everything works (though rather slowly on kernel with
CONFIG_VM_DEBUG) until application does fork() - kernel crashes on fork()
because copy_process()'s anon_vma_link complains that it could not find anon
vma after walking through 10 elements of anon list - which seems strange,
as I did not touch system wide limit (which is 65536 vmas), and mprotect()s
started failing after creating 65536 vmas, as expected.

Full output of test program and full kernel dmesg are at
http://buk.vc.cvut.cz/linux/rmap.



Thanks for finding that, Petr.  Patch below just solves the problem
by removing validate_anon_vma; but in the past both Nick and Andrea
have been less eager to delete old debug code than I am, so it would
be rude to put this patch in without an Ack from at least one of them
- they may prefer to tinker with the limit instead, but removing the
whole function is my preference.

You were puzzled by the numbers.  What happens is that the parent
builds up to 65536 vmas, and from that point on is not allowed to
split vmas any more, so the mprotects fail as you expected and
observed.  But further mmaps succeed, up to your own 131072 limit,
because each added area can simply extend the last vma.

All the vmas of interest here (i.e. not the executable, libs, stack
etc.), for better or worse, share the same anon_vma: so that if
mprotect were later used to undo the difference between neighbouring
vmas, they could be merged together - assigning different anon_vmas
would obstruct that merge (but yes, we've a guessed tradeoff there).

So the parent has around 65500 vmas all linked to the same anon_vma;
and in the course of its fork, links the child's dup vmas one by one
to that same anon_vma, until it hits the validate_anon_vma's 10
BUG_ON.  It's very much the nature of the anon_vma, to be shared
between parent and child: anon pages may be shared between both.

If we raised the 10 limit to 2*sysctl_max_map_count, then your
program would be safe (setting aside changes to that max_map_count),
but another program in which the child also forked would then BUG.



[PATCH] kill validate_anon_vma to avoid mapcount BUG


Fine by me. I had been meaning to get rid of that so DEBUG_VM is more
useful to be turned on in betas or even production kernels.

--
SUSE Labs, Novell Inc.
-
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, v2.6.22-rc6] sys_time() speedup

2007-06-25 Thread Stephen Rothwell

On Mon, 25 Jun 2007 15:15:08 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Mon, 25 Jun 2007 23:09:46 +0200
> Roman Zippel <[EMAIL PROTECTED]> wrote:
> 
> > On Monday 25 June 2007, Ingo Molnar wrote:
> > 
> > > the patch improves the sysbench OLTP macrobenchmark significantly:
> > 
> > Has that any real practical relevance?
> 
> Interesting question.  The patch adds a new test-n-branch to gettimeofday()
> so if gettimeofday() is used much more frequently than time(), we lose.

Isn't gettimeofday() called *lots* by the X server and programs - one of
the reasons we bother putting it in the VDSO.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpY3pi0tpKy6.pgp
Description: PGP signature

Re: Patent or not patent a new idea

On Tuesday June 26, [EMAIL PROTECTED] wrote:
> Posting it here seems the best thing to do.
> 
> To the inventor goes naming privilege and I'm calling this one softer raid.
> It is a form of storage raid implemented in software, as contrasted to
> software and hardware raid which are dependent on using required hardware.
> 
> To create a loop filesystem is straight forward. The commands are dd,
> mkfs.*, mount -o loop. Basically what I propose is that the image file is
> copied to another harddisk (in the case of ide not on the same cable) and
> it too is mounted in conjunction of the original with cooperation. When a
> read request for a block of say 100k is made, the kernel pulls 50k from
> each disk - maybe a simple doubling of throughput.

Sounds a lot like "RAIF" - ask google for details.

NeilBrown
-
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: [BUG] Lockdep warning with XFS on 2.6.22-rc6

2007-06-25 Thread David Chinner

On Mon, Jun 25, 2007 at 11:01:11PM +0200, Ingo Molnar wrote:
> 
> * Satyam Sharma <[EMAIL PROTECTED]> wrote:
> 
> > [ Ok, so we know that XFS wants to lock inodes in ascending inode 
> > number order and not strictly the parent-first-child-second order that 
> > rest of the fs/ code does, so that makes it difficult to teach lockdep 
> > about this kind of lock ordering ... ]

It does both - parent-first/child-second and ascending inode # order,
which is where the problem is. standing alone, these seem fine, but
they don't appear to work when the child has a lower inode number
than the parent.

> hm, there's a recent API addition to lockdep that should help with this: 
> have you looked into the patch below, could it be used to solve the XFS 
> problem? Basically when you are one step deeper into a recursive locking 
> scenario you can use lock_set_subclass() on the held lock to reset it 
> one level higher.

Peter Zijlstra already pointed me at that patch, Ingo ;). I'm looking
into it at the moment. Not being a lockdep expert, it's taking me a
little time to understand exactly what is needed here.

At first I wasn't sure that this would work, but now I've seen the
patch that used it, I suspect that it can be used. That patch
(http://lkml.org/lkml/2007/1/28/88) has three cases enumerated
(prev,cur,next) to match the three node types in the list and that
the "next" got set back to "cur" via lock_set_subclass() when
walking the list so that lockdep always sees cur -> next
transistions when walking the list. Have I read this correctly?

Reading this, it seems to me that the xfs_lock_inodes() code needs
to set the lock subclass of the first inode to "parent" (and lock it
as a parent) and then as it walks across the remining inodes it sets
the previous inode to a parent and locks the current inode as a
child.

It seems that I'd also need to make sure that this is done on the
normal parent/child lock ordering as well.

Does this make any sense?  lockdep is not something I've paid much
attention to up to this point (someone else did the current notation
and now on leave for a couple more months), so I'm trying to pick up
the pieces as quickly as possible...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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] Check files' signatures before doing suid/sgid [2/4]

2007-06-25 Thread Satyam Sharma

On 6/26/07, Alexander Wuerstlein
<[EMAIL PROTECTED]> wrote:

[...]
Nope. I unluckily wrote 'userspace' where I should have said something else:
Chain-of-trust is handled in what I would label 'Adminspace' (Where we do the
signing as in points 1 and 2). There is a very small number of signatures (in
our example one) known to the kernel and only those are trusted, and those are
applied to the binaries by the administrator in your point 2. The kernel does
and should never rely on userspace to tell it which signatures are trustworthy.
Only the administrator may do so by means of the signatures directly compiled
into the kernel.

So in short: Chain-of-trust is handled by the administrator in his secure
central location.

Ok, so the "trust chain" you're talking about is simply the decision of the
admin to compile-in the (verified and trusted) public keys of known trusted
entities into the kernel at build time. That is not really scalable, but I guess
you might just as well impose such a restriction for sake of simplicity.

[ I initially thought a scenario where a given binary is signed by an
entity whose
corresponding public key is _not_ present in the kernel, but who does possess
a signature -- over its name, id and public key -- by another entity whose
corresponding public key _is_ built into the kernel). Then at the time of
verification there's really no other alternative to *build* the entire
chain at the
_point of verification_ (in-kernel) itself ... but this obviously
introduces huge and
ugly complexities that you'd have a hard time bringing into the kernel :-) That
"signature over name, id and public key" could be a _certificate_ (if you care
about following standards), and building their chains in-kernel ... well. But if
you really want to differentiate between kernel and userspace from security
perspective, and want to give such functionality, I don't see any easy
way out. ]

>> So far for the initial idea. Perhaps it would be useful to have more than
>> one
>> key or some more complex scheme for obtaining the keys and checking their
>> validity.  But as all of this would need to be part of the kernel we
>> decided to
>> rather keep it as simple as possible, anything complex is better and more
>> flexibly done in userspace.
>
> Well, if you're trusting (privileged) userspace already, I'm suddenly not so
> sure as to what new is this patchset bringing to the table in the first place
> ...

We do not trust any userspace application, see above.

> could you also describe the attack vectors / threats that you had in mind
> that get blocked with the proposed scheme?

We focus on attacks where an attacker may alter some executable file, for
example by altering a mounted nfs-share, manipulating disk-content by simply
pulling a disk, mounting it and writing to it, etc.

This relies on the kernel beeing trustworthy of course, so one would need to
take special measures to protect the kernel-image from beeing similarly
altered. One (somewhat not-so-secure method) would be supplying kernel images
by PXE and forbidding local booting, another measure would be using a TPM
and an appropriate bootloader to check the kernel for unwanted modifications.

Kernel-userspace differentiation from security perspective is always tricky
(so this is why I pointed you to the discussions whenever such stuff, such
as asymmetric crypto and modsign etc are proposed to be merged). It's
definitely not impossible to compromise a _running_ kernel from privileged
userspace, if it really wanted to do so ...

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

Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

2007-06-25 Thread Dan Williams

On 6/25/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:

On Mon, 2007-06-25 at 18:46 -0700, Dan Williams wrote:
>
> Context switches on this platform flush the L1 cache so bouncing
> between a workqueue and the MD thread is painful.

Why is context switches between two kernel threads flushing the L1
cache?  Is this a flaw in the ARM arch?  I would think the only thing
that needs to be done between a context switch of two kernel threads (or
even a user thread to a kernel thread) is update the general regs and
stack. The memory access (page_tables or whatever ARM uses) should stay
the same.

Yes you are right, ARM does not flush L1 when prev==next in switch_mm.

Perhaps something else is at fault here.

I'll try and dig a bit deeper...
-
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 3/3] Make jprobes a little safer for users

On Mon, 2007-06-25 at 19:00 -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 11:48:51 +1000 (EST) Michael Ellerman <[EMAIL PROTECTED]> 
> wrote:
> 
> > I realise jprobes are a razor-blades-included type of interface, but
> > that doesn't mean we can't try and make them safer to use. This guy I
> > know once wrote code like this:
> > 
> > struct jprobe jp = { .kp.symbol_name = "foo", .entry = "jprobe_foo" };
> > 
> > And then his kernel exploded. Oops.
> > 
> > This patch adds an arch hook, arch_deref_entry_point() (I don't like it 
> > either)
> > which takes the void * in a struct jprobe, and gives back the text address
> > that it represents.
> > 
> > We can then use that in register_jprobe() to check that the entry point
> > we're passed is actually in the kernel text, rather than just some random
> > value.
> > 
> > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> > ---
> >  arch/ia64/kernel/kprobes.c|7 ++-
> >  arch/powerpc/kernel/kprobes.c |   11 ---
> >  kernel/kprobes.c  |9 +
> 
> We're missing a declaration of arch_deref_entry_point() in some header file?

Yeah I guess. It's declared weak in kernel/kprobes.c, but there should
be a definition somewhere to make sure the three versions don't get out
of sync. I'll send a patch.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person


signature.asc
Description: This is a digitally signed message part

Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

2007-06-25 Thread Steven Rostedt

On Mon, 2007-06-25 at 18:46 -0700, Dan Williams wrote:
> 
> Context switches on this platform flush the L1 cache so bouncing
> between a workqueue and the MD thread is painful.

Why is context switches between two kernel threads flushing the L1
cache?  Is this a flaw in the ARM arch?  I would think the only thing
that needs to be done between a context switch of two kernel threads (or
even a user thread to a kernel thread) is update the general regs and
stack. The memory access (page_tables or whatever ARM uses) should stay
the same.

Perhaps something else is at fault here.

Thanks for testing!

-- Steve

-
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 3/3] Make jprobes a little safer for users

On Tue, 26 Jun 2007 11:48:51 +1000 (EST) Michael Ellerman <[EMAIL PROTECTED]> 
wrote:

> I realise jprobes are a razor-blades-included type of interface, but
> that doesn't mean we can't try and make them safer to use. This guy I
> know once wrote code like this:
> 
> struct jprobe jp = { .kp.symbol_name = "foo", .entry = "jprobe_foo" };
> 
> And then his kernel exploded. Oops.
> 
> This patch adds an arch hook, arch_deref_entry_point() (I don't like it 
> either)
> which takes the void * in a struct jprobe, and gives back the text address
> that it represents.
> 
> We can then use that in register_jprobe() to check that the entry point
> we're passed is actually in the kernel text, rather than just some random
> value.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> ---
>  arch/ia64/kernel/kprobes.c|7 ++-
>  arch/powerpc/kernel/kprobes.c |   11 ---
>  kernel/kprobes.c  |9 +

We're missing a declaration of arch_deref_entry_point() in some header file?

-
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/3] Make jprobes a little safer for users

I realise jprobes are a razor-blades-included type of interface, but
that doesn't mean we can't try and make them safer to use. This guy I
know once wrote code like this:

struct jprobe jp = { .kp.symbol_name = "foo", .entry = "jprobe_foo" };

And then his kernel exploded. Oops.

This patch adds an arch hook, arch_deref_entry_point() (I don't like it either)
which takes the void * in a struct jprobe, and gives back the text address
that it represents.

We can then use that in register_jprobe() to check that the entry point
we're passed is actually in the kernel text, rather than just some random
value.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/ia64/kernel/kprobes.c|7 ++-
 arch/powerpc/kernel/kprobes.c |   11 ---
 kernel/kprobes.c  |9 +
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/arch/ia64/kernel/kprobes.c b/arch/ia64/kernel/kprobes.c
index 5bc46f1..5dc98b5 100644
--- a/arch/ia64/kernel/kprobes.c
+++ b/arch/ia64/kernel/kprobes.c
@@ -936,10 +936,15 @@ static void ia64_get_bsp_cfm(struct unw_frame_info *info, 
void *arg)
return;
 }
 
+unsigned long arch_deref_entry_point(void *entry)
+{
+   return ((struct fnptr *)entry)->ip;
+}
+
 int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
 {
struct jprobe *jp = container_of(p, struct jprobe, kp);
-   unsigned long addr = ((struct fnptr *)(jp->entry))->ip;
+   unsigned long addr = arch_deref_entry_point(jp->entry);
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
struct param_bsp_cfm pa;
int bytes;
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 0c96611..440f5a8 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -492,6 +492,13 @@ int __kprobes kprobe_exceptions_notify(struct 
notifier_block *self,
return ret;
 }
 
+#ifdef CONFIG_PPC64
+unsigned long arch_deref_entry_point(void *entry)
+{
+   return (unsigned long)(((func_descr_t *)entry)->entry);
+}
+#endif
+
 int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
 {
struct jprobe *jp = container_of(p, struct jprobe, kp);
@@ -500,11 +507,9 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct 
pt_regs *regs)
memcpy(>jprobe_saved_regs, regs, sizeof(struct pt_regs));
 
/* setup return addr to the jprobe handler routine */
+   regs->nip = arch_deref_entry_point(jp->entry);
 #ifdef CONFIG_PPC64
-   regs->nip = (unsigned long)(((func_descr_t *)jp->entry)->entry);
regs->gpr[2] = (unsigned long)(((func_descr_t *)jp->entry)->toc);
-#else
-   regs->nip = (unsigned long)jp->entry;
 #endif
 
return 1;
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 9e47d8c..3e9f513 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -675,9 +675,18 @@ static struct notifier_block kprobe_exceptions_nb = {
.priority = 0x7fff /* we need to be notified first */
 };
 
+unsigned long __weak arch_deref_entry_point(void *entry)
+{
+   return (unsigned long)entry;
+}
 
 int __kprobes register_jprobe(struct jprobe *jp)
 {
+   unsigned long addr = arch_deref_entry_point(jp->entry);
+
+   if (!kernel_text_address(addr))
+   return -EINVAL;
+
/* Todo: Verify probepoint is a function entry point */
jp->kp.pre_handler = setjmp_pre_handler;
jp->kp.break_handler = longjmp_break_handler;
-- 
1.5.1.3.g7a33b

-
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/3] Remove JPROBE_ENTRY()

AFAICT now that jprobe.entry is a void *, JPROBE_ENTRY doesn't do
anything useful - so remove it ..

I've left a do-nothing version so that out-of-tree jprobes code will still
compile without modifications.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 Documentation/kprobes.txt |8 +---
 include/asm-i386/kprobes.h|1 -
 include/asm-ia64/kprobes.h|2 --
 include/asm-powerpc/kprobes.h |2 --
 include/asm-s390/kprobes.h|2 --
 include/asm-sparc64/kprobes.h |1 -
 include/asm-x86_64/kprobes.h  |1 -
 include/linux/kprobes.h   |3 +++
 net/dccp/probe.c  |2 +-
 net/ipv4/tcp_probe.c  |2 +-
 10 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index da5404a..cb12ae1 100644
--- a/Documentation/kprobes.txt
+++ b/Documentation/kprobes.txt
@@ -247,12 +247,6 @@ control to Kprobes.)  If the probed function is declared 
asmlinkage,
 fastcall, or anything else that affects how args are passed, the
 handler's declaration must match.
 
-NOTE: A macro JPROBE_ENTRY is provided to handle architecture-specific
-aliasing of jp->entry. In the interest of portability, it is advised
-to use:
-
-   jp->entry = JPROBE_ENTRY(handler);
-
 register_jprobe() returns 0 on success, or a negative errno otherwise.
 
 4.3 register_kretprobe
@@ -518,7 +512,7 @@ long jdo_fork(unsigned long clone_flags, unsigned long 
stack_start,
 }
 
 static struct jprobe my_jprobe = {
-   .entry = JPROBE_ENTRY(jdo_fork)
+   .entry = jdo_fork
 };
 
 static int __init jprobe_init(void)
diff --git a/include/asm-i386/kprobes.h b/include/asm-i386/kprobes.h
index 8774d06..06f7303 100644
--- a/include/asm-i386/kprobes.h
+++ b/include/asm-i386/kprobes.h
@@ -42,7 +42,6 @@ typedef u8 kprobe_opcode_t;
? (MAX_STACK_SIZE) \
: (((unsigned long)current_thread_info()) + THREAD_SIZE - (ADDR)))
 
-#define JPROBE_ENTRY(pentry)   (kprobe_opcode_t *)pentry
 #define ARCH_SUPPORTS_KRETPROBES
 #define  ARCH_INACTIVE_KPROBE_COUNT 0
 #define flush_insn_slot(p) do { } while (0)
diff --git a/include/asm-ia64/kprobes.h b/include/asm-ia64/kprobes.h
index 6382e52..067d9de 100644
--- a/include/asm-ia64/kprobes.h
+++ b/include/asm-ia64/kprobes.h
@@ -82,8 +82,6 @@ struct kprobe_ctlblk {
struct prev_kprobe prev_kprobe[ARCH_PREV_KPROBE_SZ];
 };
 
-#define JPROBE_ENTRY(pentry)   (kprobe_opcode_t *)pentry
-
 #define ARCH_SUPPORTS_KRETPROBES
 #define  ARCH_INACTIVE_KPROBE_COUNT 1
 
diff --git a/include/asm-powerpc/kprobes.h b/include/asm-powerpc/kprobes.h
index b0e40ff..3481ade 100644
--- a/include/asm-powerpc/kprobes.h
+++ b/include/asm-powerpc/kprobes.h
@@ -73,12 +73,10 @@ typedef unsigned int kprobe_opcode_t;
}   \
 }
 
-#define JPROBE_ENTRY(pentry)   (kprobe_opcode_t *)((func_descr_t *)pentry)
 #define is_trap(instr) (IS_TW(instr) || IS_TD(instr) || \
IS_TWI(instr) || IS_TDI(instr))
 #else
 /* Use stock kprobe_lookup_name since ppc32 doesn't use function descriptors */
-#define JPROBE_ENTRY(pentry)   (kprobe_opcode_t *)(pentry)
 #define is_trap(instr) (IS_TW(instr) || IS_TWI(instr))
 #endif
 
diff --git a/include/asm-s390/kprobes.h b/include/asm-s390/kprobes.h
index 830fe4c..340ba10 100644
--- a/include/asm-s390/kprobes.h
+++ b/include/asm-s390/kprobes.h
@@ -46,8 +46,6 @@ typedef u16 kprobe_opcode_t;
? (MAX_STACK_SIZE) \
: (((unsigned long)current_thread_info()) + THREAD_SIZE - (ADDR)))
 
-#define JPROBE_ENTRY(pentry) (kprobe_opcode_t *)(pentry)
-
 #define ARCH_SUPPORTS_KRETPROBES
 #define ARCH_INACTIVE_KPROBE_COUNT 0
 
diff --git a/include/asm-sparc64/kprobes.h b/include/asm-sparc64/kprobes.h
index a331b7b..7f6774d 100644
--- a/include/asm-sparc64/kprobes.h
+++ b/include/asm-sparc64/kprobes.h
@@ -10,7 +10,6 @@ typedef u32 kprobe_opcode_t;
 #define BREAKPOINT_INSTRUCTION_2 0x91d02071 /* ta 0x71 */
 #define MAX_INSN_SIZE 2
 
-#define JPROBE_ENTRY(pentry)   (kprobe_opcode_t *)pentry
 #define arch_remove_kprobe(p)  do {} while (0)
 #define  ARCH_INACTIVE_KPROBE_COUNT 0
 
diff --git a/include/asm-x86_64/kprobes.h b/include/asm-x86_64/kprobes.h
index cf53178..7db8254 100644
--- a/include/asm-x86_64/kprobes.h
+++ b/include/asm-x86_64/kprobes.h
@@ -41,7 +41,6 @@ typedef u8 kprobe_opcode_t;
? (MAX_STACK_SIZE) \
: (((unsigned long)current_thread_info()) + THREAD_SIZE - (ADDR)))
 
-#define JPROBE_ENTRY(pentry)   (kprobe_opcode_t *)pentry
 #define ARCH_SUPPORTS_KRETPROBES
 #define  ARCH_INACTIVE_KPROBE_COUNT 1
 
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index f4e53b7..bd89285 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -119,6 +119,9 @@ struct jprobe {
void *entry;/* probe handling code to jump to */
 };
 
+/* For backward compatibility with old code using JPROBE_ENTRY() */
+#define JPROBE_ENTRY(handler)  (handler)
+

[PATCH 1/3] Make struct jprobe.entry a void *

Currently jprobe.entry is a kprobe_opcode_t *, but that's a lie. On some
platforms it doesn't point to an opcode at all, it points to a function
descriptor.

It's really a pointer to something that the arch code can turn into a
function entry point. And that's what actually happens, none of the
generic code ever looks at jprobe.entry, it's only ever dereferenced
by arch code.

So just make it a void *.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---

It isn't obvious where kprobes patches should go, is anyone "the" maintainer?
Instead I've just sent this to everyone who'd touched the code lately, or
might be otherwise interested.


 include/linux/kprobes.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index 23adf60..f4e53b7 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -116,7 +116,7 @@ struct kprobe {
  */
 struct jprobe {
struct kprobe kp;
-   kprobe_opcode_t *entry; /* probe handling code to jump to */
+   void *entry;/* probe handling code to jump to */
 };
 
 DECLARE_PER_CPU(struct kprobe *, current_kprobe);
-- 
1.5.1.3.g7a33b

-
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: Limiting load of certain processes

2007-06-25 Thread Maxim Levitsky

On Thursday 21 June 2007 22:11, Jan Engelhardt wrote:
> On Jun 21 2007 21:00, Jan Kandziora wrote:
> >I know it's a crude idea for everyday Linux processes, but for
> >dosemu driven applications, which behave badly in a multitasking OS
> >*and* for which source code isn't available, it may be worth to
> >discuss.
>
> Would dosbox do? (it does busy-loops too, but at least, it's got
> source)
>
>
>   Jan

Hi.

Try  to set $_hogthreshold = (1) in dosemu.conf

This helps a lot for me.

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

Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

2007-06-25 Thread Dan Williams


so how about the following, different approach: anyone who has a tasklet
in any performance-sensitive codepath, please yell now. We'll also do a
proactive search for such places. We can convert those places to
softirqs, or move them back into hardirq context. Once this is done -
and i doubt it will go beyond 1-2 places - we can just mass-convert the
other 110 places to the lame but compatible solution of doing them in a
global thread context.



I have a driver / testcase that reacts negatively to a workqueue
conversion.  This is with the iop-adma driver on an ARM based platform
re-syncing a degraded raid5 array.  The driver is currently in -mm and
it uses tasklets to run a short callback routine upon completion of an
offloaded memcpy or xor operation.  Quick tests show that
write-throughput does not go down too much, but resync speed, as
reported by /proc/mdstat, drops from ~50MB/s to ~30MB/s.

Context switches on this platform flush the L1 cache so bouncing
between a workqueue and the MD thread is painful.

The conversion patch is attached.

--
Dan
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index 5d8a6cf..7e89003 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -41,6 +41,8 @@
 #define tx_to_iop_adma_slot(tx) \
 	container_of(tx, struct iop_adma_desc_slot, async_tx)
 
+static struct workqueue_struct *iop_adma_workqueue;
+
 /**
  * iop_adma_free_slots - flags descriptor slots for reuse
  * @slot: Slot to free
@@ -273,9 +275,11 @@ iop_adma_slot_cleanup(struct iop_adma_chan *iop_chan)
 	spin_unlock_bh(_chan->lock);
 }
 
-static void iop_adma_tasklet(unsigned long data)
+static void iop_adma_work_routine(struct work_struct *work)
 {
-	struct iop_adma_chan *chan = (struct iop_adma_chan *) data;
+	struct iop_adma_chan *chan =
+		container_of(work, struct iop_adma_chan, work);
+
 	__iop_adma_slot_cleanup(chan);
 }
 
@@ -370,7 +374,7 @@ retry:
 		goto retry;
 
 	/* try to free some slots if the allocation fails */
-	tasklet_schedule(_chan->irq_tasklet);
+	queue_work(iop_adma_workqueue, _chan->work);
 
 	return NULL;
 }
@@ -704,7 +708,7 @@ iop_adma_prep_dma_zero_sum(struct dma_chan *chan, unsigned int src_cnt,
 static void iop_adma_dependency_added(struct dma_chan *chan)
 {
 	struct iop_adma_chan *iop_chan = to_iop_adma_chan(chan);
-	tasklet_schedule(_chan->irq_tasklet);
+	queue_work(iop_adma_workqueue, _chan->work);
 }
 
 static void iop_adma_free_chan_resources(struct dma_chan *chan)
@@ -785,7 +789,7 @@ static irqreturn_t iop_adma_eot_handler(int irq, void *data)
 
 	dev_dbg(chan->device->common.dev, "%s\n", __FUNCTION__);
 
-	tasklet_schedule(>irq_tasklet);
+	queue_work(iop_adma_workqueue, >work);
 
 	iop_adma_device_clear_eot_status(chan);
 
@@ -798,7 +802,7 @@ static irqreturn_t iop_adma_eoc_handler(int irq, void *data)
 
 	dev_dbg(chan->device->common.dev, "%s\n", __FUNCTION__);
 
-	tasklet_schedule(>irq_tasklet);
+	queue_work(iop_adma_workqueue, >work);
 
 	iop_adma_device_clear_eoc_status(chan);
 
@@ -1244,8 +1248,6 @@ static int __devinit iop_adma_probe(struct platform_device *pdev)
 		ret = -ENOMEM;
 		goto err_free_iop_chan;
 	}
-	tasklet_init(_chan->irq_tasklet, iop_adma_tasklet, (unsigned long)
-		iop_chan);
 
 	/* clear errors before enabling interrupts */
 	iop_adma_device_clear_err_status(iop_chan);
@@ -1268,11 +1270,13 @@ static int __devinit iop_adma_probe(struct platform_device *pdev)
 
 	spin_lock_init(_chan->lock);
 	init_timer(_chan->cleanup_watchdog);
-	iop_chan->cleanup_watchdog.data = (unsigned long) iop_chan;
-	iop_chan->cleanup_watchdog.function = iop_adma_tasklet;
+	iop_chan->cleanup_watchdog.data = (unsigned long) _chan->work;
+	iop_chan->cleanup_watchdog.function = iop_adma_work_routine;
 	INIT_LIST_HEAD(_chan->chain);
 	INIT_LIST_HEAD(_chan->all_slots);
 	INIT_RCU_HEAD(_chan->common.rcu);
+	INIT_WORK(_chan->work, iop_adma_work_routine);
+
 	iop_chan->common.device = dma_dev;
 	list_add_tail(_chan->common.device_node, _dev->channels);
 
@@ -1443,6 +1447,10 @@ static struct platform_driver iop_adma_driver = {
 
 static int __init iop_adma_init (void)
 {
+	iop_adma_workqueue = create_workqueue("iop-adma");
+	if (!iop_adma_workqueue)
+		return -ENODEV;
+
 	/* it's currently unsafe to unload this module */
 	/* if forced, worst case is that rmmod hangs */
 	__unsafe(THIS_MODULE);
diff --git a/include/asm-arm/hardware/iop_adma.h b/include/asm-arm/hardware/iop_adma.h
index 8eb5990..7d8742b 100644
--- a/include/asm-arm/hardware/iop_adma.h
+++ b/include/asm-arm/hardware/iop_adma.h
@@ -67,7 +67,7 @@ struct iop_adma_chan {
 	struct list_head all_slots;
 	struct timer_list cleanup_watchdog;
 	int slots_allocated;
-	struct tasklet_struct irq_tasklet;
+	struct work_struct work;
 };
 
 /**

Re: [PATCH] MTRR: Fix race causing set_mtrr to go into infinite loop

2007-06-25 Thread Loic Prylli

On 6/25/2007 6:34 PM, Andi Kleen wrote:
> On Tuesday 26 June 2007 00:05:17 Chuck Ebbert wrote:
>   
>> On 06/25/2007 05:38 PM, Loic Prylli wrote:
>>
>> [cc: Andi]
>>
>> 
>>> Processors synchronization in set_mtrr requires the .gate field
>>> to be set after .count field is properly initialized. Without an explicit
>>> barrier, the compiler was reordering those memory stores. That was sometimes
>>> causing a processor (in ipi_handler) to see the .gate change and
>>> decrement .count before the latter is set by set_mtrr() (which
>>> then hangs in a infinite loop with irqs disabled).
>>>   
>
> Hmm, perhaps we should just put the smp_wmb into atomic_set().
> Near all other atomic operations have memory barriers too. I think
> that would be the better fix.
>
> -Andi
>   

In Documentation/atomic_ops.txt atomic_set/atomic_read are described as
nothing more than a type-safe assignement or reading, without any extra
semantics. For other atomic operations, the rule is that any atomic
operation that doesn't return a value doesn't come with a barrier (and
any operation that returns the atomic value must have memory barriers).

So I guess you are suggesting to change the doc and the implementation
for all arches.

I should admit I did not knew a number of atomic operations did not
imply memory-barriers before. But maybe the extra cost might not be
completely negligible, especially if, for consistency with other
"barrier-implied" atomic operations, a new memory barrier is put before
and after,

Are you suggested changing just atomic_set(), or also other barrier-free
atomic operations :"atomic_dec", "atomic_inc", "atomic_add", "atomic_sub" ?

Independently of what is done to atomic, what about not making the .gate
field an atomic_t, but a simple "int" in the mttr code, since the only
operations done on it are atomic_read and atomic_set?

Loic

-
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: Patent or not patent a new idea

2007-06-25 Thread Graeme Sheppard


Posting it here seems the best thing to do.

To the inventor goes naming privilege and I'm calling this one softer raid.
It is a form of storage raid implemented in software, as contrasted to
software and hardware raid which are dependent on using required hardware.

To create a loop filesystem is straight forward. The commands are dd,
mkfs.*, mount -o loop. Basically what I propose is that the image file is
copied to another harddisk (in the case of ide not on the same cable) and
it too is mounted in conjunction of the original with cooperation. When a
read request for a block of say 100k is made, the kernel pulls 50k from
each disk - maybe a simple doubling of throughput.

That example is a raid 1 scenario. Other raid levels I don't think would be
so simple to achieve. Of course more than 2 disks could be harnessed.

The two big advantages I see over normal raid setups are 1) the disks need
not be the same size or from the same manufacturer; 2) the supporting code
would be cross-platform.

It allows users to more freely create and change partitions (which hold
softer raid images) and their sizes.

The downside is that softer raid would be slower than traditional raid
techniques on the right hardware, as softer raid goes through another
filesystem. Softer raid could be optimized for contiguous image files
perhaps.

Using softer raid could also provide sufficient throughput of flash devices
making for a great combo with low latency.

I am not versed enough to suggest how a kernel would implement the storage
access, in 512 or 4096 byte blocks or in what way the reassembling of
pieces would be done efficiently. Therefore I'm not completely sure of any
performance gains.

Is this a good idea or have I overlooked a catch and got lost?

-
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] trim memory not covered by WB MTRRs

2007-06-25 Thread Eric W. Biederman

Jesse Barnes <[EMAIL PROTECTED]> writes:

> On Monday, June 25, 2007 4:34:33 Andi Kleen wrote:
>> > This patch fixes a bug in the last patch that caused the code to
>> > run on non-Intel machines (AMD machines apparently don't need it
>>
>> Actually the problem can happen on AMD too, but the symptoms can
>> be different and there can be more wrong than just the MTRRs.
>
> I should have been more specific in the changelog.  My understanding is 
> that AMD systems don't need it for memory above 4G, and since the code 
> doesn't handle holes (no test systems, nor any real reports that I've 
> seen), it's not that useful for finding problems below 4G.  We can 
> always change that later if needed though.

For the K7 and K8 cores AMD systems are exactly like Intel systems
with respect to MTRRs (although AMD systems also have additional registers)
For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there
is an additional mechanism that makes everything above 4G write-back
cacheable without using any MTRRs.

So only on the very latest AMD cpus would this code not be applicable.

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

Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

2007-06-25 Thread Steven Rostedt

On Mon, 2007-06-25 at 18:00 -0600, Jonathan Corbet wrote:
> A couple of days ago I said:
> 
> > The cafe_ccic (OLPC) camera driver uses a tasklet to move frames out of
> > the DMA buffers in the streaming I/O path
> > 
> > Obviously some testing is called for here.  I will make an attempt to do
> > that testing
> 
> I've done that testing - I have an OLPC B3 unit running V2 of the
> tasklet->workqueue patch, and all seems well.  30 FPS to the display and
> no dropped frames.  The tasklets/0 process is running 3-5% CPU, in case
> that's interesting.  For whatever reason, I see about 3% *more* idle
> time when running just mplayer than I did without the patch.
> 
> Consider my minor qualms withdrawn, there doesn't seem to be any trouble
> in this area.

Jon, thanks a lot!

This is great news. I wonder if converting tasklets to work queues also
helps with other softirqs.  Before, softirqs could not preempt a
tasklet, since tasklets run as a softirq. With tasklets as work queues,
what's left as a softirq can now preempt tasklets. Perhaps this can even
help with performance.

-- Steve
  

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

Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

2007-06-25 Thread Steven Rostedt

On Tue, 2007-06-26 at 01:36 +0200, Stefan Richter wrote:

> I can't speak for Kristian, nor do I have test equipment for isochronous
> applications, but I know that there are people out there which do data
> acquisition on as many FireWire buses as they can stuff boards into
> their boxes.  There are also FireWire cards with 2 or 4 controllers per
> board; and each controller can receive or transmit on several channels.
> 
> Depending on the buffering scheme, there may be one (?) interrupt per
> channel and isochronopus cycle.  Or an interrupt when the buffer is
> full.  Some application programmers use large buffers; others want small
> buffers.  An isochronous cycle is 125us.
> 
> Asynchronous I/O can even produce much higher interrupt rates.  I think
> IP over 1394 might indeed cause interrupt rates that are moderately
> higher than 1/125us during normal traffic.  SBP-2 ( = 1394 storage) is
> not as much affected because the bulk of data is transferred without
> interrupts.  So I suppose some eth1394 bandwidth tests with this patch
> series might make sense... alas I'm short of spare time.  (Would be
> interesting to see whether the old ohci1394 driver is blown to bits with
> the patch series; it's an old driver with who-knows what assumptions in
> there.)

Hi, any testing of the patches would be much appreciated. I don't have
access to any boxes that might have problems with running tasklets as
work queues. So if you know others with this equipment, and can pass the
patches off to them. It will hopefully help us know if this patch helps,
hurts, or just doesn't make a difference.

> 
> > Workqueue priority can be set, and your handler should 
> > probably be SCHED_FIFO.
> 
> Does this cooperate nicely with a SCHED_FIFO thread of a userspace data
> acquisition program or audio server or the like?

Well, if you put the prio of the work queue higher, it won't be any
different than a tasklet. A tasklet runs at an even higher priority than
any thread on the system.

-- Steve


-
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] RFC: have tcp_recvmsg() check kthread_should_stop() and treat it as if it were signalled

2007-06-25 Thread Jeff Layton

On Tue, 26 Jun 2007 03:39:23 +0530
"Satyam Sharma" <[EMAIL PROTECTED]> wrote:

> Hi Jeff,
> 
> [ Trimmed netdev from Cc: list, added Christoph. ]
> 
> On 6/26/07, Jeff Layton <[EMAIL PROTECTED]> wrote:
> > On Tue, 26 Jun 2007 01:11:20 +0530
> > "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> > > [...]
> > > Yes, why not embed a send_sig(SIGKILL) just before the wake_up_process()
> > > in kthread_stop() itself?
> > >
> > > Looking at some happily out-of-date comments in the kthread code, I can
> > > guess that at some point of time (perhaps very early drafts) Rusty 
> > > actually
> > > *did* implement the whole kthread_stop() functionality using signals, but
> > > I suspect it might've been discarded and the kthread_stop_info approach
> > > used instead to protect from spurious signals from userspace. (?)
> > >
> > > So could we have signals in _addition_ to kthread_stop_info and change
> > > kthread_should_stop() to check for both:
> > >
> > > kthread_stop_info.k == current && signal_pending(current)
> > >
> > > If !kthread_should_stop() && signal_pending(current) => spurious signal,
> > > so just flush and discard (in the kthread).
> > > [...]
> > > Why is it wrong for kthreads to let signals through? We can ignore out
> > > all signals we're not interested in, and flush the spurious ones ...
> > > otherwise there really isn't much those kthreads can do that get blocked
> > > in such functions, is there?
> >
> > Yes, after I wrote that I began to question that assumption too. I was
> > pretty much going on a statement by Christoph Hellwig on an earlier
> > patch that I did:
> 
> Ok, I found both the threads / patches you referred to ...
> 
> > -[snip]--
> > The right way to fix this is to stop sending signals at all and have
> > a kernel-internal way to get out of kernel_recvmsg.  Uses of signals by
> > kernel thread generally are bugs.
> > -[snip]--
> >
> > Though this makes no sense to me. I don't see any reason why kthreads
> > can't use signals, and hacking support for breaking out of sleeping
> > functions seems redundant.
> 
> Right, signals _are_ the "signalling" mechanism all through kernel code
> already, anything else would clearly be redundant.
> 
> But I've listened / participated in other discussions about kthreads and
> signals and the general feeling is that (somebody correct me if I'm wrong)
> kernel threads are a kernel _implementation detail_ after all, and good
> design must ensure that userspace be unaware of even their existence.
> And I agree with that, but the real ugly uses of signals by kernel threads
> are those cases where we want to export a full signals-based interface to
> our kthread to userspace (such cases do exist in mainline, I think).
> But that's clearly not the case with the usage here.
> 
> > My latest patch for cifsd has it block all signals from userspace
> > and uses force_sig() instead of send_sig() when trying to stop the
> > thread. This seems to work pretty well and  still insulates the thread
> > from userspace signals.
> 
> Thanks, I find this solution much cleaner too, so now we avoid any
> sort of spuriousness getting in from userspace (and pretty much takes
> care of all the checking-if-spurious-and-flushing business I referred to
> earlier).
> 
> But how about making this part of kthreads proper? Functions such as
> skb_recv_datagram etc are pretty standard (and others such would also
> exist or get added in due time) and it is not exactly intuitive for a 
> developer
> to add a force_sig(SIGKILL) before the kthread_stop() to ensure that the
> kthread using such functions does exit properly. [ I can foresee cases in
> the future when such functions are added to kthreads that did not have
> them previously, and suddenly someone reports a regression that the
> kthread stops exiting cleanly. ]
> 
> Satyam

I have no issue with it. I just didn't feel confident enough  to know
whether that might have harmful side effects.  Right offhand I don't
see why adding a force_sig() to kthread_stop() would be an issue. It
seems like if you're wanting to stop the thread anyway then a signal
probably wouldn't hurt anything.

-- 
Jeff Layton <[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: [patch -mm 22/28] x86_64: Convert to cleckevents

On Sat, 23 Jun 2007 13:32:47 -
Thomas Gleixner <[EMAIL PROTECTED]> wrote:

> Convert x86_64 to the clockevents code. Share code with i386 for
> hpet and PIT.
> 
> Build and whitespace fixups from:
>  Venki Pallipadi <[EMAIL PROTECTED]>
> and
>  Chris Wright <[EMAIL PROTECTED]>

semi-fixes.

> if (no_ctr_free) {
> -   i = 3;
> -   rdmsrl(MSR_K7_EVNTSEL3, evntsel3);
> -   wrmsrl(MSR_K7_EVNTSEL3, 0);
> -   rdmsrl(MSR_K7_PERFCTR3, pmc3);
> +i = 3;
> +rdmsrl(MSR_K7_EVNTSEL3, evntsel3);
> +wrmsrl(MSR_K7_EVNTSEL3, 0);
> +rdmsrl(MSR_K7_PERFCTR3, pmc3);
> } else {
> -   reserve_perfctr_nmi(MSR_K7_PERFCTR0 + i);
> -   reserve_evntsel_nmi(MSR_K7_EVNTSEL0 + i);
> +reserve_perfctr_nmi(MSR_K7_PERFCTR0 + i);
> +reserve_evntsel_nmi(MSR_K7_EVNTSEL0 + i);
> }
> local_irq_save(flags);
> /* start meauring cycles, incrementing from 0 */
> @@ -275,119 +236,38 @@ static unsigned int __init tsc_calibrate
> wrmsrl(MSR_K7_EVNTSEL0 + i, 1 << 22 | 3 << 16 | 0x76);
> rdtscl(tsc_start);
> do {
> -   rdmsrl(MSR_K7_PERFCTR0 + i, pmc_now);
> -   tsc_now = get_cycles_sync();
> +rdmsrl(MSR_K7_PERFCTR0 + i, pmc_now);
> +tsc_now = get_cycles_sync();
> } while ((tsc_now - tsc_start) < TICK_COUNT);
>  
> local_irq_restore(flags);
> if (no_ctr_free) {
> -   wrmsrl(MSR_K7_EVNTSEL3, 0);
> -   wrmsrl(MSR_K7_PERFCTR3, pmc3);
> -   wrmsrl(MSR_K7_EVNTSEL3, evntsel3);
> +wrmsrl(MSR_K7_EVNTSEL3, 0);
> +wrmsrl(MSR_K7_PERFCTR3, pmc3);
> +wrmsrl(MSR_K7_EVNTSEL3, evntsel3);
> } else {
> -   release_perfctr_nmi(MSR_K7_PERFCTR0 + i);
> -   release_evntsel_nmi(MSR_K7_EVNTSEL0 + i);
> +release_perfctr_nmi(MSR_K7_PERFCTR0 + i);
> +release_evntsel_nmi(MSR_K7_EVNTSEL0 + i);
> }

There's still bulk whitespace bustage in here.

(However checkpatch only says

Use #include  instead of 
#1913: FILE: arch/x86_64/kernel/tsc.c:11:
+#include 
)


-
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] Check files' signatures before doing suid/sgid [2/4]

2007-06-25 Thread Alexander Wuerstlein

On 070626 01:56, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On 6/25/07, Alexander Wuerstlein
> <[EMAIL PROTECTED]> wrote:
>> On 070622 21:40, Satyam Sharma <[EMAIL PROTECTED]> wrote:
>> > [...]
>> We decided against
>> altering the file itself for that and some other reasons.
>> The limitation to suid/sgid was only due to a limited amount of time we 
>> had for
>> implementing our patch. For the future we are planning further uses like
>> setting capabilities only for signed binaries.
>
> Ok, effectively what you have there is a signature on an entire file stored
> in one of its extended attributes, so I suspect you could think of few other
> applications for something like this too.

Yes, for example one could sign Java's classfiles and employ a special trusted
Java VM which checks the signatures before execution. Also, this is a more
general case of signing kernel modules (as you mentioned below). There are
really numerous applications one could imagine, we just don't really know which
ones are practical. We definitely appreciate further ideas on this.

Also the signature-in-ELF can be used complementary to our approach: for
example NFS is currently unable to handle real extended attributes (nfs does
only posix acls). So for binaries delivered over NFS our approach wouldn't
work.

> Ok, so:
>
> 1. Admin is trusted. [ This need not mean the same as: "superuser
> _account_ is trusted", but let's stay in the real world in for now. ]
> 2. Signing happens at some central, assumed-to-be-secure location (and say
> the private key never leaves that central secure location). And let's say the
> admin *repackages* the packages, this time such that the signed files get the
> signature-carrying-extended-attributes with them, so the installation
> automatically copies them correctly. => nothing wrong with this assumption.
> 3. Kernel verifies signatures at runtime. => kernel is trusted.
> 4. Public key needs to be *compiled into* the kernel ... so this is not 
> getting into mainline, but fair enough as something site administrators would
> patch in and build.

Correct up to here.

> 5. Chain-of-trust handled in userspace. => userspace is trusted.

Nope. I unluckily wrote 'userspace' where I should have said something else:
Chain-of-trust is handled in what I would label 'Adminspace' (Where we do the
signing as in points 1 and 2). There is a very small number of signatures (in
our example one) known to the kernel and only those are trusted, and those are
applied to the binaries by the administrator in your point 2. The kernel does
and should never rely on userspace to tell it which signatures are trustworthy.
Only the administrator may do so by means of the signatures directly compiled
into the kernel.

So in short: Chain-of-trust is handled by the administrator in his secure
central location.

>> So far for the initial idea. Perhaps it would be useful to have more than 
>> one
>> key or some more complex scheme for obtaining the keys and checking their
>> validity.  But as all of this would need to be part of the kernel we 
>> decided to
>> rather keep it as simple as possible, anything complex is better and more
>> flexibly done in userspace.
>
> Well, if you're trusting (privileged) userspace already, I'm suddenly not so
> sure as to what new is this patchset bringing to the table in the first place
> ...

We do not trust any userspace application, see above.

> could you also describe the attack vectors / threats that you had in mind
> that get blocked with the proposed scheme?

We focus on attacks where an attacker may alter some executable file, for
example by altering a mounted nfs-share, manipulating disk-content by simply
pulling a disk, mounting it and writing to it, etc.

This relies on the kernel beeing trustworthy of course, so one would need to
take special measures to protect the kernel-image from beeing similarly
altered. One (somewhat not-so-secure method) would be supplying kernel images
by PXE and forbidding local booting, another measure would be using a TPM
and an appropriate bootloader to check the kernel for unwanted modifications.

> Have a look at modsign (signed kernel modules) project too (just the key
> management part, specifically the asymmetric crypto and DSA implementation
> that they've already ported to the kernel). You could also go through the 
> lkml archives for whenever that was proposed for inclusion in mainline ...

We already thought about that. Using some existing code is definitely preferable
to inventing DSA again :)

Ciao,

Alexander Wuerstlein.

pgpqh98zrD0Th.pgp
Description: PGP signature

Re: [patch, v2.6.22-rc6] sys_time() speedup

2007-06-25 Thread Mark Lord

Ingo Molnar wrote:

Subject: [patch] sys_time() speedup
From: Ingo Molnar <[EMAIL PROTECTED]>

improve performance of sys_time(). sys_time() returns time in seconds, 
but it does so by calling do_gettimeofday() and then returning the 
tv_sec portion of the GTOD time. But the data structure "xtime", which 
is updated by every timer/scheduler tick, already offers HZ granularity 
time.

How well synchronized is xtime with real-time ?

Programs invoking sys_time() do expect it to be as accurate
as gettimeofday(), even if only at 1-second boundaries.

Cheers
-
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 10/28] highres: Improve debug output

On Sat, 23 Jun 2007 13:32:35 -
Thomas Gleixner <[EMAIL PROTECTED]> wrote:

>   if (!dev || !(dev->features & CLOCK_EVT_FEAT_ONESHOT) ||
> - !tick_device_is_functional(dev))
> + !tick_device_is_functional(dev)) {
> +
> + printk(KERN_INFO "Clockevents: "
> +"could not switch to one-shot mode:");
> + if (!dev) {
> + printk(" no tick device\n");
> + } else {
> + if (!tick_device_is_functional(dev))
> + printk(" %s is not functional.\n", dev->name);
> + else if (!(dev->features & CLOCK_EVT_FEAT_ONESHOT))
> + printk(" %s does not support one-shot mode.\n",
> +dev->name);
> + }

There is a logic path through here where the printk doesn't get its \n
termination?  And it will fail to print the reason for the failure, too.

Maybe that's a can't-happen, in which case the CLOCK_EVT_FEAT_ONESHOT test
is superfluous?

-
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 09/28] Tick management: spread timer interrupt

On Sat, 23 Jun 2007 13:32:34 -
Thomas Gleixner <[EMAIL PROTECTED]> wrote:

> From: john stultz <[EMAIL PROTECTED]>
> 
> After discussing w/ Thomas over IRC, it seems the issue is the sched
> tick fires on every cpu at the same time, causing extra lock contention.
> 
> This smaller change, adds an extra offset per cpu so the ticks don't
> line up. This patch also drops the idle latency from 40us down to under
> 20us.
> 
> Signed-off-by: john stultz <[EMAIL PROTECTED]>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> 
> ---
>  kernel/time/tick-sched.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6.22-rc4-mm/kernel/time/tick-sched.c
> ===
> --- linux-2.6.22-rc4-mm.orig/kernel/time/tick-sched.c 2007-06-23 
> 14:38:56.0 +0200
> +++ linux-2.6.22-rc4-mm/kernel/time/tick-sched.c  2007-06-23 
> 14:38:58.0 +0200
> @@ -573,6 +573,7 @@ void tick_setup_sched_timer(void)
>  {
>   struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);
>   ktime_t now = ktime_get();
> + u64 offset;
>  
>   /*
>* Emulate tick processing via per-CPU hrtimers:
> @@ -581,8 +582,12 @@ void tick_setup_sched_timer(void)
>   ts->sched_timer.function = tick_sched_timer;
>   ts->sched_timer.cb_mode = HRTIMER_CB_IRQSAFE_NO_SOFTIRQ;
>  
> - /* Get the next period */
> + /* Get the next period (per cpu) */
>   ts->sched_timer.expires = tick_init_jiffy_update();
> + offset = ktime_to_ns(tick_period) >> 1;
> + do_div(offset, NR_CPUS);

With CONFIG_NR_CPUS=128 on a 2-way this'll be a pretty lumpy spreading? 
Perhaps it woud be better to use num_possible_cpus() here?


> + offset *= smp_processor_id();
> + ts->sched_timer.expires = ktime_add_ns(ts->sched_timer.expires, offset);
>  
>   for (;;) {
>   hrtimer_forward(>sched_timer, now, tick_period);
> 
> -- 
-
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: Patent or not patent a new idea

2007-06-25 Thread Bryan Henderson

>If your only purpose is to try generate a defensive patent, then just
>dumping the idea in the public domain serves the same purpose, probably
>better.
>
>I have a few patents, some of which are defensive. That has not prevented
>the USPTO issuing quite a few patents that are in clear violation of 
mine.

That's not what a defensive patent is.  Indeed, patenting something just 
so someone else can't patent it is ridiculous, because publishing is so 
much easier.

A defensive patent is one you file so that you can trade rights to it for 
rights to other patents that you need.


-
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: vm/fs meetup in september?

2007-06-25 Thread Jared Hulbert


A few things I'd like to talk about are:

- the address space operations APIs, and their page based nature. I think
  it would be nice to generally move toward offset,length based ones as
  much as possible because it should give more efficiency and flexibility
  in the filesystem.

- write_begin API if it is still an issue by that date. Hope not :)

- truncate races

- fsblock if it hasn't been shot down by then

- how to make complex API changes without having to fix most things
  yourself.


I'd like to add:

-revamping filemap_xip.c

-memory mappable swap file (I'm not sure if this one is appropriate
for the proposed meeting)
-
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] atl1: disable 64bit DMA

2007-06-25 Thread Jay Cliburn

On Mon, 25 Jun 2007 17:57:20 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:

> Jay L. T. Cornwall wrote:
> > Chris Snook wrote:
> > 
> >> What boards have we seen this on?  It's quite possible this is:
> > 
> > I can reproduce on an Asus P5K with a Core 2 Duo E6600.
> > 
> > lspci identifies the controller as:
> >   02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
> >   Ethernet Adapter (rev b0)
> > 
> > dmesg notes the PCI-DMA mapping implementation:
> >   PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> > 
> 
> I had a hunch this was on Intel.  I'd rather just disable this when
> swiotlb is in use, unless we get more complaints.  It's probably
> ultimately a BIOS quirk anyway.

So far we have reports from both camps:

Asus M2N8-VMX (AM2):1 report of lockup
http://sourceforge.net/mailarchive/forum.php?thread_name=46780384.063603.26165%40m12-15.163.com_name=atl1-devel

Asus P5K (LGA775):  2 reports of lockups
http://sourceforge.net/mailarchive/forum.php?thread_name=467E7E34.4010603%40gmail.com_name=atl1-devel
http://lkml.org/lkml/2007/6/25/107

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

Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

2007-06-25 Thread Jonathan Corbet

A couple of days ago I said:

> The cafe_ccic (OLPC) camera driver uses a tasklet to move frames out of
> the DMA buffers in the streaming I/O path
> 
> Obviously some testing is called for here.  I will make an attempt to do
> that testing

I've done that testing - I have an OLPC B3 unit running V2 of the
tasklet->workqueue patch, and all seems well.  30 FPS to the display and
no dropped frames.  The tasklets/0 process is running 3-5% CPU, in case
that's interesting.  For whatever reason, I see about 3% *more* idle
time when running just mplayer than I did without the patch.

Consider my minor qualms withdrawn, there doesn't seem to be any trouble
in this area.

Thanks,

jon

Jonathan Corbet / LWN.net / [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/

[2.6.22 patch] kconfig help: recommend SLAB

2007-06-25 Thread Adrian Bunk

During "make oldconfig", the help text only said
  This option allows to select a slab allocator.

This patch adds an
  If unsure, choose SLAB.
which is the safe choice for users wanting to avoid regressions.

It also inckudes an indentation fix.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.22-rc6/init/Kconfig.old   2007-06-26 01:29:41.0 +0200
+++ linux-2.6.22-rc6/init/Kconfig   2007-06-26 01:30:07.0 +0200
@@ -556,7 +556,9 @@
prompt "Choose SLAB allocator"
default SLAB
help
-  This option allows to select a slab allocator.
+ This option allows to select a slab allocator.
+ 
+ If unsure, choose SLAB.
 
 config SLAB
bool "SLAB"

-
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] Check files' signatures before doing suid/sgid [2/4]

2007-06-25 Thread Satyam Sharma

On 6/25/07, Alexander Wuerstlein
<[EMAIL PROTECTED]> wrote:

On 070622 21:40, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> [...]
> But first: Have you checked the digsig project? It's been doing
> (for some time) what your current patchset proposes -- and
> it uses public key cryptosystems for the key management,
> which is decidedly better than using secret-keyed hashes
> (HMAC, XCBC). Also, digsig aims to protect executable
> binaries in general, and not just suid / sgid ones.

We have not heard about digsig before, thanks for pointing it out. After a
short look over the source (correct me if I'm wrong): The most important
difference between our project and digsig is that digsig relies on storing
signatures inside the ELF file structure. Therefore a handmade binary-loader or
just COFF binaries could be used to circumvent digsig.

Yes, that's correct.

We decided against
altering the file itself for that and some other reasons.
The limitation to suid/sgid was only due to a limited amount of time we had for
implementing our patch. For the future we are planning further uses like
setting capabilities only for signed binaries.

Ok, effectively what you have there is a signature on an entire file stored in
one of its extended attributes, so I suspect you could think of few other
applications for something like this too.

> Second: Can we have some discussion on the security model /
> threat model / trust model / cryptographic key management
> scheme of your signing mechanism? [I had read through the
> [0/4] mail you had sent yesterday, but found no relevant
> discussion on these aspects there.]
[...]
An admin would verify the to-be-installed binaries (e.g. by reading the source,
checking the distribution's package signatures), sign them in a central
location.  He then distributes those signatures along with the installation
packages onto his computers. There should only be one key in use at a site the
public part of which is compiled into the kernel. Any kind of chain-of-trust
should be handled in userspace by signing or not signing with the site-wide
key depending on the earlier signatures in the chain.

Ok, so:

1. Admin is trusted. [ This need not mean the same as: "superuser
_account_ is trusted", but let's stay in the real world in for now. ]
2. Signing happens at some central, assumed-to-be-secure location (and say
the private key never leaves that central secure location). And let's say the
admin *repackages* the packages, this time such that the signed files get the
signature-carrying-extended-attributes with them, so the installation
automatically copies them correctly. => nothing wrong with this assumption.
3. Kernel verifies signatures at runtime. => kernel is trusted.
4. Public key needs to be *compiled into* the kernel ... so this is not getting
into mainline, but fair enough as something site administrators would patch in
and build.
5. Chain-of-trust handled in userspace. => userspace is trusted.

Let me know if I got the trust model / key management wrong.

So far for the initial idea. Perhaps it would be useful to have more than one
key or some more complex scheme for obtaining the keys and checking their
validity.  But as all of this would need to be part of the kernel we decided to
rather keep it as simple as possible, anything complex is better and more
flexibly done in userspace.

Well, if you're trusting (privileged) userspace already, I'm suddenly
not so sure
as to what new is this patchset bringing to the table in the first
place ... could
you also describe the attack vectors / threats that you had in mind that get
blocked with the proposed scheme?

> From the patchset, it appears you use a *common* secret key
> for _all_ signed binaries, and it is set at kernel build-time itself:
> [...]
> Anyway, this is *totally* insecure and broken. Do you realize anybody
> who lays hands on the kernel image can now _trivially_ extract the
> should-have-been-a-secret key from it and use it to sign his own
> binaries?

We do realize that this is really really ugly, broken and nasty and nobody
would or should ever want to use it for anything but playing around as it is
atm. ;)

We only used HMAC because it was already available inside the kernel, for
implementing real asymetric cryptography there was simply no time. Of course
our next objective is to implement that.

Have a look at modsign (signed kernel modules) project too (just the key
management part, specifically the asymmetric crypto and DSA implementation
that they've already ported to the kernel). You could also go through the lkml
archives for whenever that was proposed for inclusion in mainline ...

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

Re: [PATCH] ALSA: fix ice1712 section mismatch

2007-06-25 Thread Randy Dunlap

On Mon, 25 Jun 2007 16:41:10 -0700 Andrew Morton wrote:

> On Mon, 25 Jun 2007 16:17:39 -0700 Randy Dunlap <[EMAIL PROTECTED]>
> wrote:
> 
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> > 
> > Cannot mix const and __initdata:
> > sound/pci/ice1712/prodigy192.c:708: error: ak4114_controls causes a section 
> > type conflict
> > 
> 
> This is a fatal compilation error, isn't it?

Yes.

> > ---
> >  sound/pci/ice1712/prodigy192.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- linux-2.6.22-rc6.orig/sound/pci/ice1712/prodigy192.c
> > +++ linux-2.6.22-rc6/sound/pci/ice1712/prodigy192.c
> > @@ -705,7 +705,7 @@ static int ak4114_input_sw_put(struct sn
> >  }
> >  
> >  
> > -static const struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
> > +static struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
> > {
> > .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
> > .name = "MIODIO IEC958 Capture Input",
> 
> That patch is already in the alsa git tree (has been there for five days),
> so I would of course prefer that the alsa guys merge it into 2.6.22.

OK, I admit that I never look there.

> However alsa merges are a bit spotty, so I'll queue this up anyway and will
> merge it in a day or three if nothing else happens, OK?


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ALSA: fix ice1712 section mismatch

On Mon, 25 Jun 2007 16:17:39 -0700 Randy Dunlap <[EMAIL PROTECTED]>
wrote:

> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Cannot mix const and __initdata:
> sound/pci/ice1712/prodigy192.c:708: error: ak4114_controls causes a section 
> type conflict
> 

This is a fatal compilation error, isn't it?

> ---
>  sound/pci/ice1712/prodigy192.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-2.6.22-rc6.orig/sound/pci/ice1712/prodigy192.c
> +++ linux-2.6.22-rc6/sound/pci/ice1712/prodigy192.c
> @@ -705,7 +705,7 @@ static int ak4114_input_sw_put(struct sn
>  }
>  
>  
> -static const struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
> +static struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
>   {
>   .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
>   .name = "MIODIO IEC958 Capture Input",

That patch is already in the alsa git tree (has been there for five days),
so I would of course prefer that the alsa guys merge it into 2.6.22.

However alsa merges are a bit spotty, so I'll queue this up anyway and will
merge it in a day or three if nothing else happens, OK?

-
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] atl1: disable 64bit DMA

2007-06-25 Thread Chris Snook

Jeff Garzik wrote:

Jay Cliburn wrote:

On Mon, 25 Jun 2007 17:57:20 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:

Jay L. T. Cornwall wrote:

Chris Snook wrote:

What boards have we seen this on? It's quite possible this is:

I can reproduce on an Asus P5K with a Core 2 Duo E6600.

lspci identifies the controller as:
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
Ethernet Adapter (rev b0)

dmesg notes the PCI-DMA mapping implementation:
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)

I had a hunch this was on Intel. I'd rather just disable this when
swiotlb is in use, unless we get more complaints. It's probably
ultimately a BIOS quirk anyway.

So far we have reports from both camps:

Asus M2N8-VMX (AM2):1 report of lockup
http://sourceforge.net/mailarchive/forum.php?thread_name=46780384.063603.26165%40m12-15.163.com_name=atl1-devel

Asus P5K (LGA775):2 reports of lockups
http://sourceforge.net/mailarchive/forum.php?thread_name=467E7E34.4010603%40gmail.com_name=atl1-devel

http://lkml.org/lkml/2007/6/25/107

The common denominator in these reports is 4GB RAM.

Although its possible this device doesn't really support 64-bit, it's
more likely that this is a platform problem of some sort, or a driver
bug of some sort. In the driver, maybe it has a problem when you
-cross- a 4GB boundary, which is not uncommon.

Jeff

I'm going on the record to say I don't trust the chipsets on these boards, and
I'd like anyone having these problems to let us
([EMAIL PROTECTED]) know if they encounter similar problems with
any other hardware. That said, I'm not going to stand in the way of stability
just because it *might* be someone else's fault. I don't think limiting
ourselves to dma32, at least while we track this down, is much of a loss on
current hardware.

Acked-By: Chris Snook <[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: [RFC PATCH 0/6] Convert all tasklets to workqueues

2007-06-25 Thread Stefan Richter

Ingo Molnar wrote:
> regarding workqueues - would it be possible for you to test Steve's 
> patch and get us performance numbers? Do you have any test with tons of 
> tasklet activity that would definitely show the performance impact of 
> workqueues?

I can't speak for Kristian, nor do I have test equipment for isochronous
applications, but I know that there are people out there which do data
acquisition on as many FireWire buses as they can stuff boards into
their boxes.  There are also FireWire cards with 2 or 4 controllers per
board; and each controller can receive or transmit on several channels.

Depending on the buffering scheme, there may be one (?) interrupt per
channel and isochronopus cycle.  Or an interrupt when the buffer is
full.  Some application programmers use large buffers; others want small
buffers.  An isochronous cycle is 125us.

Asynchronous I/O can even produce much higher interrupt rates.  I think
IP over 1394 might indeed cause interrupt rates that are moderately
higher than 1/125us during normal traffic.  SBP-2 ( = 1394 storage) is
not as much affected because the bulk of data is transferred without
interrupts.  So I suppose some eth1394 bandwidth tests with this patch
series might make sense... alas I'm short of spare time.  (Would be
interesting to see whether the old ohci1394 driver is blown to bits with
the patch series; it's an old driver with who-knows what assumptions in
there.)

> Workqueue priority can be set, and your handler should 
> probably be SCHED_FIFO.

Does this cooperate nicely with a SCHED_FIFO thread of a userspace data
acquisition program or audio server or the like?
-- 
Stefan Richter
-=-=-=== -==- ==-=-
http://arcgraph.de/sr/
-
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] trim memory not covered by WB MTRRs

2007-06-25 Thread Jesse Barnes

On Monday, June 25, 2007 4:34:33 Andi Kleen wrote:
> > This patch fixes a bug in the last patch that caused the code to
> > run on non-Intel machines (AMD machines apparently don't need it
>
> Actually the problem can happen on AMD too, but the symptoms can
> be different and there can be more wrong than just the MTRRs.

I should have been more specific in the changelog.  My understanding is 
that AMD systems don't need it for memory above 4G, and since the code 
doesn't handle holes (no test systems, nor any real reports that I've 
seen), it's not that useful for finding problems below 4G.  We can 
always change that later if needed though.

Thanks,
Jesse
-
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] trim memory not covered by WB MTRRs

2007-06-25 Thread Andi Kleen

> This patch fixes a bug in the last patch that caused the code to
> run on non-Intel machines (AMD machines apparently don't need it

Actually the problem can happen on AMD too, but the symptoms can
be different and there can be more wrong than just the MTRRs.

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

Re: Please release a stable kernel Linux 3.0

2007-06-25 Thread Chuck Ebbert

On 06/25/2007 07:20 PM, Rafael J. Wysocki wrote:
> Still, I know that, for example, the Fedora 2.6.21-1.3193.fc8 kernel is in 
> fact
> 2.6.22-rc3 (see http://bugzilla.kernel.org/show_bug.cgi?id=7988#c11).  Is 
> there
> a straightforward way to 'decode' such names? ;-)
> 

http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?annotate=HEAD=extras

Then scroll down to the changelog. :)

I started putting the CVS version in FC6 changelogs but that doesn't
have this kind of churn.
-
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] hw_random: add quality categories