04 Mar, 2010

1 commit


03 Mar, 2010

1 commit


02 Mar, 2010

1 commit

  • The System RAM walk shall skip partial RAM pages and avoid calling
    func() on them. So that page_is_ram() return 0 for a partial RAM page.

    In particular, it shall not call func() with len=0.
    This fixes a boot time bug reported by Sachin and root caused by Thomas:

    > >>> WARNING: at arch/x86/mm/ioremap.c:111 __ioremap_caller+0x169/0x2f1()
    > >>> Hardware name: BladeCenter LS21 -[79716AA]-
    > >>> Modules linked in:
    > >>> Pid: 0, comm: swapper Not tainted 2.6.33-git6-autotest #1
    > >>> Call Trace:
    > >>> [] ? __ioremap_caller+0x169/0x2f1
    > >>> [] warn_slowpath_common+0x77/0xa4
    > >>> [] warn_slowpath_null+0xf/0x11
    > >>> [] __ioremap_caller+0x169/0x2f1
    > >>> [] ? acpi_os_map_memory+0x12/0x1b
    > >>> [] ioremap_nocache+0x12/0x14
    > >>> [] acpi_os_map_memory+0x12/0x1b
    > >>> [] acpi_tb_verify_table+0x29/0x5b
    > >>> [] acpi_load_tables+0x39/0x15a
    > >>> [] acpi_early_init+0x60/0xf5
    > >>> [] start_kernel+0x397/0x3a7
    > >>> [] x86_64_start_reservations+0xa5/0xa9
    > >>> [] x86_64_start_kernel+0xe1/0xe8
    > >>> ---[ end trace 4eaa2a86a8e2da22 ]---
    > >>> ioremap reserve_memtype failed -22

    The return code is -EINVAL, so it failed in the is_ram check, which is
    not too surprising

    > BIOS-provided physical RAM map:
    > BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
    > BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
    > BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
    > BIOS-e820: 0000000000100000 - 00000000cffa3900 (usable)
    > BIOS-e820: 00000000cffa3900 - 00000000cffa7400 (ACPI data)

    The ACPI data is not starting on a page boundary and neither does the
    usable RAM area end on a page boundary. Very useful !

    > ACPI: DSDT 00000000cffa3900 036CE (v01 IBM SERLEWIS 00001000 INTL 20060912)

    ACPI is trying to map DSDT at cffa3900, which results in a check
    vs. cffa3000 which is the relevant page boundary. The generic is_ram
    check correctly identifies that as RAM because it's in the usable
    resource area. The old e820 based is_ram check does not take
    overlapping resource areas into account. That's why it works.

    CC: Sachin Sant
    CC: Thomas Gleixner
    CC: KAMEZAWA Hiroyuki
    Signed-off-by: Wu Fengguang
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Wu Fengguang
     

01 Mar, 2010

1 commit

  • * 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86, mm: Unify kernel_physical_mapping_init() API
    x86, mm: Allow highmem user page tables to be disabled at boot time
    x86: Do not reserve brk for DMI if it's not going to be used
    x86: Convert tlbstate_lock to raw_spinlock
    x86: Use the generic page_is_ram()
    x86: Remove BIOS data range from e820
    Move page_is_ram() declaration to mm.h
    Generic page_is_ram: use __weak
    resources: introduce generic page_is_ram()

    Linus Torvalds
     

23 Feb, 2010

3 commits


18 Feb, 2010

1 commit


02 Feb, 2010

2 commits

  • Use __weak instead of __attribute__((weak)).

    Cc: Wu Fengguang
    Signed-off-by: Andrew Morton
    Signed-off-by: H. Peter Anvin

    Andrew Morton
     
  • It's based on walk_system_ram_range(), for archs that don't have
    their own page_is_ram().

    The static verions in MIPS and SCORE are also made global.

    v4: prefer plain 1 instead of PAGE_IS_RAM (H. Peter Anvin)
    v3: add comment (KAMEZAWA Hiroyuki)
    "AFAIK, this "System RAM" information has been used for kdump to
    grab valid memory area and seems good for the kernel itself."
    v2: add PAGE_IS_RAM macro (Américo Wang)

    Cc: Chen Liqin
    Cc: Lennox Wu
    Cc: Américo Wang
    Cc: linux-mips@linux-mips.org
    Cc: Yinghai Lu
    Acked-by: Ralf Baechle
    Reviewed-by: KAMEZAWA Hiroyuki
    Signed-off-by: Wu Fengguang
    LKML-Reference:
    Cc: Andrew Morton
    Signed-off-by: H. Peter Anvin

    Wu Fengguang
     

22 Dec, 2009

1 commit

  • The second parameter to alignf() in allocate_resource() must
    reflect what new resource is attempted to be allocated, else
    functions like pcibios_align_resource() (at least on x86) or
    pcmcia_align() can't work correctly.

    Commit 1e5ad9679016275d422e36b12a98b0927d76f556 broke this by
    setting the "new" resource until we're about to return success.
    To keep the resource untouched when allocate_resource() fails,
    a "tmp" resource is introduced.

    Signed-off-by: Dominik Brodowski
    Acked-by: Bjorn Helgaas
    Cc: Yinghai Lu
    Cc: Jesse Barnes
    Signed-off-by: Linus Torvalds

    Dominik Brodowski
     

05 Nov, 2009

1 commit

  • When "allocate_resource(root, new, size, ...)" fails, we currently
    clobber "new". This is inconvenient for the caller, who might care
    about the original contents of the resource.

    For example, when pci_bus_alloc_resource() fails, the "can't allocate
    mem resource %pR" message from pci_assign_resources() currently contains
    junk for the resource start/end.

    This patch delays the "new" update until we're about to return success.

    Acked-by: Linus Torvalds
    Acked-by: Yinghai Lu
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     

23 Sep, 2009

1 commit

  • Originally, walk_memory_resource() was introduced to traverse all memory
    of "System RAM" for detecting memory hotplug/unplug range. For doing so,
    flags of IORESOUCE_MEM|IORESOURCE_BUSY was used and this was enough for
    memory hotplug.

    But for using other purpose, /proc/kcore, this may includes some firmware
    area marked as IORESOURCE_BUSY | IORESOUCE_MEM. This patch makes the
    check strict to find out busy "System RAM".

    Note: PPC64 keeps their own walk_memory_resouce(), which walk through
    ppc64's lmb informaton. Because old kclist_add() is called per lmb, this
    patch makes no difference in behavior, finally.

    And this patch removes CONFIG_MEMORY_HOTPLUG check from this function.
    Because pfn_valid() just show "there is memmap or not* and cannot be used
    for "there is physical memory or not", this function is useful in generic
    to scan physical memory range.

    Signed-off-by: KAMEZAWA Hiroyuki
    Cc: Ralf Baechle
    Cc: Benjamin Herrenschmidt
    Cc: WANG Cong
    Cc: Américo Wang
    Cc: David Rientjes
    Cc: Roland Dreier
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     

01 Jul, 2009

1 commit

  • When the 32-bit signed quantities get assigned to the u64 resource_size_t,
    they are incorrectly sign-extended.

    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13253
    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9905

    Signed-off-by: Zhang Rui
    Reported-by: Leann Ogasawara
    Cc: Pierre Ossman
    Reported-by:
    Tested-by:
    Cc:
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zhang Rui
     

19 Apr, 2009

1 commit

  • This function is not actually used right now, since the original use
    case for it was done with insert_resource_expand_to_fit() instead.

    However, we now have another usage case that wants to basically do a
    "reserve IO resource, splitting around existing resources", however that
    one doesn't actually want the "recurse into the conflicting resource"
    logic at all.

    And since recursing into the conflicting resource was the most complex
    part, and isn't wanted, just remove it. Maybe we'll some day want both
    versions, but we can just resurrect the logic then.

    Tested-by: Yinghai Lu
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

16 Jan, 2009

1 commit


08 Jan, 2009

1 commit

  • Device drivers that use pci_request_regions() (and similar APIs) have a
    reasonable expectation that they are the only ones accessing their device.
    As part of the e1000e hunt, we were afraid that some userland (X or some
    bootsplash stuff) was mapping the MMIO region that the driver thought it
    had exclusively via /dev/mem or via various sysfs resource mappings.

    This patch adds the option for device drivers to cause their reserved
    regions to the "banned from /dev/mem use" list, so now both kernel memory
    and device-exclusive MMIO regions are banned.
    NOTE: This is only active when CONFIG_STRICT_DEVMEM is set.

    In addition to the config option, a kernel parameter iomem=relaxed is
    provided for the cases where developers want to diagnose, in the field,
    drivers issues from userspace.

    Reviewed-by: Matthew Wilcox
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Jesse Barnes

    Arjan van de Ven
     

17 Dec, 2008

1 commit

  • Impact: reduce false positives in iomem_map_sanity_check()

    Some drivers (vesafb) only map/reserve a portion of a resource.
    If then some other driver comes in and maps the whole resource,
    the current code WARN_ON's. This is not the intent of the checks
    in iomem_map_sanity_check(); rather these checks want to
    warn when crossing *hardware* resources only.

    This patch skips BUSY resources as suggested by Linus.

    Note: having two drivers talk to the same hardware at the same
    time is obviously not optimal behavior, but that's a separate story.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Ingo Molnar

    Arjan van de Ven
     

02 Nov, 2008

1 commit


29 Oct, 2008

1 commit

  • Impact: avoid false-positive WARN_ON()

    Andi Kleen reported:
    > When running x86info on a 2.6.27-git8 system I get
    >
    > resource map sanity check conflict: 0x9e000 0x9efff 0x10000 0x9e7ff System RAM
    > ------------[ cut here ]------------
    > WARNING: at /home/lsrc/linux/arch/x86/mm/ioremap.c:226 __ioremap_caller+0xf2/0x2d6()
    > ...

    Some of the pages below the 1MB ISA addresses will be shared typically by both
    BIOS and system usable RAM. For example:
    BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
    BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)

    x86info reads the low physical address using /dev/mem, which internally
    uses ioremap() for accessing non RAM pages. ioremap() of such low
    pages conflicts with multiple resource entities leading to the
    above warning.

    Change the iomem_map_sanity_check() to allow mapping a page spanning multiple
    resource entities (minimum granularity that one can map is a page anyhow).

    Signed-off-by: Suresh Siddha
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     

24 Oct, 2008

1 commit


17 Oct, 2008

2 commits

  • * 'core-v28-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    do_generic_file_read: s/EINTR/EIO/ if lock_page_killable() fails
    softirq, warning fix: correct a format to avoid a warning
    softirqs, debug: preemption check
    x86, pci-hotplug, calgary / rio: fix EBDA ioremap()
    IO resources, x86: ioremap sanity check to catch mapping requests exceeding, fix
    IO resources, x86: ioremap sanity check to catch mapping requests exceeding the BAR sizes
    softlockup: Documentation/sysctl/kernel.txt: fix softlockup_thresh description
    dmi scan: warn about too early calls to dmi_check_system()
    generic: redefine resource_size_t as phys_addr_t
    generic: make PFN_PHYS explicitly return phys_addr_t
    generic: add phys_addr_t for holding physical addresses
    softirq: allocate less vectors
    IO resources: fix/remove printk
    printk: robustify printk, update comment
    printk: robustify printk, fix #2
    printk: robustify printk, fix
    printk: robustify printk

    Fixed up conflicts in:
    arch/powerpc/include/asm/types.h
    arch/powerpc/platforms/Kconfig.cputype
    manually.

    Linus Torvalds
     
  • No functional change. Just return NULL for kzalloc failure immediately,
    rather than wrapping the whole function body in the body of an "if".

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

26 Sep, 2008

2 commits

  • fix this build error:

    kernel/resource.c: In function 'iomem_map_sanity_check':
    kernel/resource.c:842: error: implicit declaration of function 'r_next'
    kernel/resource.c:842: warning: assignment makes pointer from integer without a cast

    r_next() was only available if CONFIG_PROCFS was enabled.

    and fix this build warning:

    kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
    kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'
    kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
    kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'resource_size_t'

    resource_t can be 32 bits.

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • Go through the iomem resource tree to check if any of the ioremap()
    requests span more than any slot in the iomem resource tree and do
    a WARN_ON() if we hit this check.

    This will raise a red-flag, if some driver is mapping more than what
    is needed. And hopefully identify possible corruptions much earlier.

    Signed-off-by: Suresh Siddha
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     

05 Sep, 2008

2 commits

  • Andrew Morton noticed that the printk in kernel/resource.c was buggy:

    | start and end have type resource_size_t. Such types CANNOT be printed
    | unless cast to a known type.
    |
    | Because there is a %s following an incorrect %lld, the above code will
    | crash the machine.

    ... and it's probably quite unneeded as well, so remove it.

    Reported-by: Andrew Morton
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • add reserve_region_with_split() to not lose e820 reserved entries if
    they overlap with existing IO regions:

    with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 -
    we get:
    e0000000-efffffff : PCI MMCONFIG 0
    e0000000-efffffff : reserved

    and in /proc/iomem we get:
    found conflict for reserved [dd800000, efffffff], try to reserve with split
    __reserve_region_with_split: (PCI Bus #80) [dd000000, ddffffff], res: (reserved) [dd800000, efffffff]
    __reserve_region_with_split: (PCI Bus #00) [de000000, dfffffff], res: (reserved) [de000000, efffffff]
    initcall pci_subsys_init+0x0/0x121 returned 0 after 381 msecs
    in dmesg

    various fixes and improvements suggested by Linus.

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

03 Sep, 2008

1 commit


30 Aug, 2008

1 commit


31 Jul, 2008

1 commit

  • Avoid one-off errors by introducing a resource_size() function.

    Signed-off-by: Magnus Damm
    Cc: Ben Dooks
    Cc: Jean Delvare
    Cc: Paul Mundt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Magnus Damm
     

29 Apr, 2008

1 commit


21 Apr, 2008

1 commit

  • Done per Linus' request and suggestions. Linus has explained that
    better than I'll be able to explain:

    On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
    > Actually, before we go any further, there might be a less intrusive
    > alternative: add just a couple of flags to the resource flags field (we
    > still have something like 8 unused bits on 32-bit), and use those to
    > implement a generic "resource_alignment()" routine.
    >
    > Two flags would do it:
    >
    > - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
    > resources)
    >
    > - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
    > during probing)
    >
    > and then the case of both flags zero (or both bits set) would actually be
    > "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
    > actually allocate the resource (so that we don't use the "start" field as
    > alignment incorrectly when it no longer indicates alignment).
    >
    > That wouldn't be totally generic, but it would have the nice property of
    > automatically at least add sanity checking for that whole "res->start has
    > the odd meaning of 'alignment' during probing" and remove the need for a
    > new field, and it would allow us to have a generic "resource_alignment()"
    > routine that just gets a resource pointer.

    Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.

    Signed-off-by: Ivan Kokshaysky
    Cc: Linus Torvalds
    Cc: Gary Hade
    Signed-off-by: Greg Kroah-Hartman

    Ivan Kokshaysky
     

08 Feb, 2008

1 commit

  • walk_memory_resource() verifies if there are holes in a given memory
    range, by checking against /proc/iomem. On x86/ia64 system memory is
    represented in /proc/iomem. On powerpc, we don't show system memory as
    IO resource in /proc/iomem - instead it's maintained in
    /proc/device-tree.

    This provides a way for an architecture to provide its own
    walk_memory_resource() function. On powerpc, the memory region is
    small (16MB), contiguous and non-overlapping. So extra checking
    against the device-tree is not needed.

    Signed-off-by: Badari Pulavarty
    Acked-by: KAMEZAWA Hiroyuki
    Cc: Dave Hansen
    Cc: Benjamin Herrenschmidt
    Cc: Kumar Gala
    Signed-off-by: Andrew Morton
    Signed-off-by: Paul Mackerras

    Badari Pulavarty
     

15 Nov, 2007

1 commit

  • i386 and x86-64 registers System RAM as IORESOURCE_MEM | IORESOURCE_BUSY.

    But ia64 registers it as IORESOURCE_MEM only.
    In addition, memory hotplug code registers new memory as IORESOURCE_MEM too.

    This difference causes a failure of memory unplug of x86-64. This patch
    fixes it.

    This patch adds IORESOURCE_BUSY to avoid potential overlap mapping by PCI
    device.

    Signed-off-by: Yasunori Goto
    Signed-off-by: Badari Pulavarty
    Cc: Luck, Tony"
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yasunori Goto
     

17 Oct, 2007

1 commit

  • A clean up patch for "scanning memory resource [start, end)" operation.

    Now, find_next_system_ram() function is used in memory hotplug, but this
    interface is not easy to use and codes are complicated.

    This patch adds walk_memory_resouce(start,len,arg,func) function.
    The function 'func' is called per valid memory resouce range in [start,pfn).

    [pbadari@us.ibm.com: Error handling in walk_memory_resource()]
    Signed-off-by: KAMEZAWA Hiroyuki
    Signed-off-by: Badari Pulavarty
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     

29 Apr, 2007

1 commit

  • Both old-IDE and libata should be able handle all controllers and
    devices found using normal resource reservation methods.

    This eliminates the awful, low-performing split-driver configuration
    where old-IDE drove the PATA portion of a PCI device, in PIO-only mode,
    and libata drove the SATA portion of the /same/ PCI device, in DMA mode.
    Typically vendors would ship SATA hard drive / PATA optical
    configuration, which would lend itself to slow (PIO-only) CD-ROM
    performance.

    For Intel users running in combined mode, it is now wholly dependent on
    your driver choice (potentially link order, if you compile both drivers
    in) whether old-IDE or libata will drive your hardware.

    In either case, you will get full performance from both SATA and PATA
    ports now, without having to pass a kernel command line parameter.

    Signed-off-by: Jeff Garzik

    Jeff Garzik
     

15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

10 Feb, 2007

1 commit

  • Implement device resource management, in short, devres. A device
    driver can allocate arbirary size of devres data which is associated
    with a release function. On driver detach, release function is
    invoked on the devres data, then, devres data is freed.

    devreses are typed by associated release functions. Some devreses are
    better represented by single instance of the type while others need
    multiple instances sharing the same release function. Both usages are
    supported.

    devreses can be grouped using devres group such that a device driver
    can easily release acquired resources halfway through initialization
    or selectively release resources (e.g. resources for port 1 out of 4
    ports).

    This patch adds devres core including documentation and the following
    managed interfaces.

    * alloc/free : devm_kzalloc(), devm_kzfree()
    * IO region : devm_request_region(), devm_release_region()
    * IRQ : devm_request_irq(), devm_free_irq()
    * DMA : dmam_alloc_coherent(), dmam_free_coherent(),
    dmam_declare_coherent_memory(), dmam_pool_create(),
    dmam_pool_destroy()
    * PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
    * iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
    devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
    pcim_iomap(), pcim_iounmap()

    Signed-off-by: Tejun Heo
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

08 Dec, 2006

1 commit


03 Oct, 2006

1 commit