07 Nov, 2008

1 commit

  • The LPT may have gaps in it because initially empty LEBs
    are not added by mkfs.ubifs - because it does not know how
    many there are. Then UBIFS allocates empty LEBs in the
    reverse order that they are discovered i.e. they are
    added to, and removed from, the front of a list. That
    creates a gap in the middle of the LPT.

    The function dirtying the LPT tree (for the purpose of
    small model garbage collection) assumed that a gap could
    only occur at the very end of the LPT and stopped dirtying
    prematurely, which in turn resulted in the LPT running
    out of space - something that is designed to be impossible.

    Signed-off-by: Adrian Hunter

    Adrian Hunter
     

06 Nov, 2008

4 commits

  • We print 'ino_t' type using '%lu' printk() placeholder, but this
    results in many warnings when compiling for Alpha platform. Fix
    this by adding (unsingned long) casts.

    Fixes these warnings:

    fs/ubifs/journal.c:693: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/journal.c:1131: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/dir.c:163: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/tnc.c:2680: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/tnc.c:2700: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
    fs/ubifs/replay.c:1066: warning: format '%lu' expects type 'long unsigned int', but argument 7 has type 'ino_t'
    fs/ubifs/orphan.c:108: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/orphan.c:135: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/orphan.c:142: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/orphan.c:154: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/orphan.c:159: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/orphan.c:451: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/orphan.c:539: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/orphan.c:612: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/orphan.c:843: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/orphan.c:856: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/recovery.c:1438: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/recovery.c:1443: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/recovery.c:1475: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/recovery.c:1495: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:105: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
    fs/ubifs/debug.c:105: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
    fs/ubifs/debug.c:110: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
    fs/ubifs/debug.c:110: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
    fs/ubifs/debug.c:114: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
    fs/ubifs/debug.c:114: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
    fs/ubifs/debug.c:118: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
    fs/ubifs/debug.c:118: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'ino_t'
    fs/ubifs/debug.c:1591: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1671: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1674: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
    fs/ubifs/debug.c:1680: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1699: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
    fs/ubifs/debug.c:1788: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
    fs/ubifs/debug.c:1821: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
    fs/ubifs/debug.c:1833: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
    fs/ubifs/debug.c:1924: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1932: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1938: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1945: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1953: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1960: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1967: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1973: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1988: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'ino_t'
    fs/ubifs/debug.c:1991: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'ino_t'
    fs/ubifs/debug.c:2009: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'ino_t'

    Reported-by: Randy Dunlap
    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     
  • Noticed by sparse:
    fs/ubifs/file.c:75:2: warning: restricted __le64 degrades to integer
    fs/ubifs/file.c:629:4: warning: restricted __le64 degrades to integer
    fs/ubifs/dir.c:431:3: warning: restricted __le64 degrades to integer

    This should be checked to ensure the ubifs_assert is working as
    intended, I've done the suggested annotation in this patch.

    fs/ubifs/sb.c:298:6: warning: incorrect type in assignment (different base types)
    fs/ubifs/sb.c:298:6: expected int [signed] [assigned] tmp
    fs/ubifs/sb.c:298:6: got restricted __le64 [usertype]
    fs/ubifs/sb.c:299:19: warning: incorrect type in assignment (different base types)
    fs/ubifs/sb.c:299:19: expected restricted __le64 [usertype] atime_sec
    fs/ubifs/sb.c:299:19: got int [signed] [assigned] tmp
    fs/ubifs/sb.c:300:19: warning: incorrect type in assignment (different base types)
    fs/ubifs/sb.c:300:19: expected restricted __le64 [usertype] ctime_sec
    fs/ubifs/sb.c:300:19: got int [signed] [assigned] tmp
    fs/ubifs/sb.c:301:19: warning: incorrect type in assignment (different base types)
    fs/ubifs/sb.c:301:19: expected restricted __le64 [usertype] mtime_sec
    fs/ubifs/sb.c:301:19: got int [signed] [assigned] tmp

    This looks like a bugfix as your tmp was a u32 so there was truncation in
    the atime, mtime, ctime value, probably not intentional, add a tmp_le64
    and use it here.

    fs/ubifs/key.h:348:9: warning: cast to restricted __le32
    fs/ubifs/key.h:348:9: warning: cast to restricted __le32
    fs/ubifs/key.h:419:9: warning: cast to restricted __le32

    Read from the annotated union member instead.

    fs/ubifs/recovery.c:175:13: warning: incorrect type in assignment (different base types)
    fs/ubifs/recovery.c:175:13: expected unsigned int [unsigned] [usertype] save_flags
    fs/ubifs/recovery.c:175:13: got restricted __le32 [usertype] flags
    fs/ubifs/recovery.c:186:13: warning: incorrect type in assignment (different base types)
    fs/ubifs/recovery.c:186:13: expected restricted __le32 [usertype] flags
    fs/ubifs/recovery.c:186:13: got unsigned int [unsigned] [usertype] save_flags

    Do byteshifting at compile time of the flag value. Annotate the saved_flags
    as le32.

    fs/ubifs/debug.c:368:10: warning: cast to restricted __le32
    fs/ubifs/debug.c:368:10: warning: cast from restricted __le64

    Should be checked if the truncation was intentional, I've changed the
    printk to print the full width.

    Signed-off-by: Harvey Harrison
    Signed-off-by: Artem Bityutskiy

    Harvey Harrison
     
  • Remove the "UBIFS background thread ubifs_bgd0_0 started" message.
    We kill the background thread when we switch to R/O mode, and
    start it again whan we switch to R/W mode. OLPC is doing this
    many times during boot, and we see this message many times as
    well, which is irritating. So just kill the message.

    Signed-off-by: Artem Bityutskiy

    Artem Bityutskiy
     

03 Nov, 2008

11 commits

  • Linus Torvalds
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6:
    ide-gd: re-get capacity on revalidate
    tx4938ide: Avoid underflow on calculation of a wait cycle
    tx4938ide: Do not call devm_ioremap for whole 128KB
    tx4938ide: Check minimum cycle time and SHWT range (v2)
    ide: Switch to a common address
    ide-cd: fix DMA alignment regression

    Linus Torvalds
     
  • We need to re-get a removable media's capacity when revalidating the
    disk so that its partitions get rescanned by the block layer.

    Signed-off-by: Borislav Petkov
    Cc: Tejun Heo
    Cc: axboe@kernel.dk
    Signed-off-by: Bartlomiej Zolnierkiewicz

    Borislav Petkov
     
  • Make 'wt' variable signed while it can be negative during calculation.

    Suggested-by: Sergei Shtylyov
    Signed-off-by: Atsushi Nemoto
    Cc: sshtylyov@ru.mvista.com
    Signed-off-by: Bartlomiej Zolnierkiewicz

    Atsushi Nemoto
     
  • Call devm_ioremap() for CS0 and CS1 separetely.
    And some style cleanups.

    Suggested-by: Sergei Shtylyov
    Signed-off-by: Atsushi Nemoto
    Cc: ralf@linux-mips.org
    Acked-by: Sergei Shtylyov
    Signed-off-by: Bartlomiej Zolnierkiewicz

    Atsushi Nemoto
     
  • SHWT value is used as address valid to -CSx assertion and -CSx to -DIOx
    assertion setup time, and contrarywise, -DIOx to -CSx release and -CSx
    release to address invalid hold time, so it actualy applies 4 times and
    so constitutes -DIOx recovery time. Check requirement of the recovery
    time and cycle time. Also check SHWT maximum value.

    Suggested-by: Sergei Shtylyov
    Signed-off-by: Atsushi Nemoto
    Cc: ralf@linux-mips.org
    Acked-by: Sergei Shtylyov
    Signed-off-by: Bartlomiej Zolnierkiewicz

    Atsushi Nemoto
     
  • Signed-off-by: Alan Cox
    Signed-off-by: Bartlomiej Zolnierkiewicz

    Alan Cox
     
  • e5318b531b008c79d2a0c0df06a7b8628da38e2f ("ide: use the dma safe check for
    REQ_TYPE_ATA_PC") introduced a regression which caused some ATAPI drives to
    turn off DMA for REQ_TYPE_BLOCK_PC commands while burning and thus degrading
    performance and ultimately causing an excessive amount of underruns.

    The issue is documented also in:
    http://bugzilla.kernel.org/show_bug.cgi?id=11742.

    Signed-off-by: Borislav Petkov
    Cc: FUJITA Tomonori
    Tested-by: Valerio Passini
    [bart: fixup patch description per comments from Sergei Shtylyov]
    Signed-off-by: Bartlomiej Zolnierkiewicz

    Borislav Petkov
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
    sparc64: Fix PCI resource mapping on sparc64
    sparc64: Kill annoying warning when building compat_binfmt_elf.o
    sparc32: kernel/trace/trace.c wants DIE_OOPS
    sparc64: Fix __copy_{to,from}_user_inatomic defines.

    Linus Torvalds
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (33 commits)
    af_unix: netns: fix problem of return value
    IRDA: remove double inclusion of module.h
    udp: multicast packets need to check namespace
    net: add documentation for skb recycling
    key: fix setkey(8) policy set breakage
    bpa10x: free sk_buff with kfree_skb
    xfrm: do not leak ESRCH to user space
    net: Really remove all of LOOPBACK_TSO code.
    netfilter: nf_conntrack_proto_gre: switch to register_pernet_gen_subsys()
    netns: add register_pernet_gen_subsys/unregister_pernet_gen_subsys
    net: delete excess kernel-doc notation
    pppoe: Fix socket leak.
    gianfar: Don't reset TBISerDes link if it's already up
    gianfar: Fix race in TBI/SerDes configuration
    at91_ether: request/free GPIO for PHY interrupt
    amd8111e: fix dma_free_coherent context
    atl1: fix vlan tag regression
    SMC91x: delete unused local variable "lp"
    myri10ge: fix stop/go mmio ordering
    bonding: fix panic when taking bond interface down before removing module
    ...

    Linus Torvalds
     
  • s/user/used/

    Signed-off-by: Jeff Garzik
    Signed-off-by: Linus Torvalds

    Jeff Garzik
     

02 Nov, 2008

24 commits

  • There is a problem discovered in recent versions of ATI Mach64 driver
    in X.org on sparc64 architecture. In short, the driver fails to mmap
    MMIO aperture (PCI resource #2).

    I've found that kernel's __pci_mmap_make_offset() returns EINVAL. It
    checks whether user attempts to mmap more than the resource length,
    which is 0x1000 bytes in our case. But PAGE_SIZE on SPARC64 is 0x2000
    and this is what actually is being mmaped. So __pci_mmap_make_offset()
    failed for this PCI resource.

    Signed-off-by: Max Dmitrichenko
    Signed-off-by: David S. Miller

    Max Dmitrichenko
     
  • GCC warns because some tests against 32-bit values never evaluate to
    true due to how TASK_SIZE is defined.

    I always wanted to mimick powerpc's definition of TASK_SIZE, which
    is simply TASK_SIZE_OF(current) and that also fixes the warning.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • Signed-off-by: Al Viro
    Signed-off-by: David S. Miller

    Al Viro
     
  • Alexander Beregalov reports oops in __bzero() called from
    copy_from_user_fixup() called from iov_iter_copy_from_user_atomic(),
    when running dbench on tmpfs on sparc64: its __copy_from_user_inatomic
    and __copy_to_user_inatomic should be avoiding, not calling, the fixups.

    Signed-off-by: Hugh Dickins
    Signed-off-by: David S. Miller

    Hugh Dickins
     
  • fix problem of return value

    net/unix/af_unix.c: unix_net_init()
    when error appears, it should return 'error', not always return 0.

    Signed-off-by: Jianjun Kong
    Signed-off-by: David S. Miller

    Jianjun Kong
     
  • Signed-off-by: Alexander Beregalov
    Signed-off-by: David S. Miller

    Alexander Beregalov
     
  • Current UDP multicast delivery is not namespace aware.

    Signed-off-by: Eric Dumazet
    Acked-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Eric Dumazet
     
  • Commit 04a4bb55bcf35b63d40fd2725e58599ff8310dd7 ("net: add
    skb_recycle_check() to enable netdriver skb recycling") added a
    method for network drivers to recycle skbuffs, but while use of
    this mechanism was documented in the commit message, it should
    really have been added as a docbook comment as well -- this
    patch does that.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: Lennert Buytenhek
    Signed-off-by: David S. Miller

    Stephen Hemminger
     
  • Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • cirrusfb_zorro_unmap() may be called both from __devexit and (on
    cleanup path) from __devinit. So it needs to be a normal function,
    same as for cirrusfb_pci_unmap()

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • Insufficient dependency - we really want CONFIG_RTC_CLASS=y there.
    That will give us CONFIG_RTC_LIB=y, so the old dependency can be
    simply replaced.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • We broke O_NONBLOCK handling in OSS dmasound_core in 2.3.11-pre3 - the
    original code copied f_flags to open_mode and then checked for
    O_NONBLOCK in there, but that got changed to copying f_mode and
    O_NONBLOCK has not reached that field in any kernel version.

    Since we do not care for any other bits, the fix is obvious...

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • …git/tip/linux-2.6-tip

    * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86: fix AMDC1E and XTOPOLOGY conflict in cpufeature
    x86: build fix

    Linus Torvalds
     
  • Removed duplicated #include in init/do_mounts_md.c.

    The same compile error ("error: implicit declaration of function
    'msleep'") got fixed twice:

    - f8b77d39397e1510b1a3bcfd385ebd1a45aae77f ("init/do_mounts_md.c:
    msleep compile fix")

    - 73b4a24f5ff09389ba6277c53a266b142f655ed2 ("init/do_mounts_md.c must
    #include ")

    by people adding the include in two slightly different
    places. Andrew's quilt scripts happily ignore the fuzz, and will
    re-apply the patch even though they had conflicts.

    Signed-off-by: Huang Weiyi
    Signed-off-by: Linus Torvalds

    Huang Weiyi
     
  • This makes the late e820 resources use 'insert_resource_expand_to_fit()'
    instead of doing a 'reserve_region_with_split()', and also avoids
    marking them as IORESOURCE_BUSY.

    This results in us being perfectly happy to use pre-existing PCI
    resources even if they were marked as being in a reserved region, while
    still avoiding any _new_ allocations in the reserved regions. It also
    makes for a simpler and more accurate resource tree.

    Example resource allocation from Jonathan Corbet, who has firmware that
    has an e820 reserved entry that covered a big range (e0000000-fed003ff),
    and that had various PCI resources in it set up by firmware.

    With old kernels, the reserved range would force us to re-allocate all
    pre-existing PCI resources, and his reserved range would end up looking
    like this:

    e0000000-fed003ff : reserved
    fec00000-fec00fff : IOAPIC 0
    fed00000-fed003ff : HPET 0

    where only the pre-allocated special regions (IOAPIC and HPET) were kept
    around.

    With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
    resource tree looked like this:

    e0000000-fe7fffff : reserved
    fe800000-fe8fffff : PCI Bus 0000:01
    fe800000-fe8fffff : reserved
    fe900000-fe9d9aff : reserved
    fe9d9b00-fe9d9bff : 0000:00:1f.3
    fe9d9b00-fe9d9bff : reserved
    fe9d9c00-fe9d9fff : 0000:00:1a.7
    fe9d9c00-fe9d9fff : reserved
    fe9da000-fe9dafff : 0000:00:03.3
    fe9da000-fe9dafff : reserved
    fe9db000-fe9dbfff : 0000:00:19.0
    fe9db000-fe9dbfff : reserved
    fe9dc000-fe9dffff : 0000:00:1b.0
    fe9dc000-fe9dffff : reserved
    fe9e0000-fe9fffff : 0000:00:19.0
    fe9e0000-fe9fffff : reserved
    fea00000-fea7ffff : 0000:00:02.0
    fea00000-fea7ffff : reserved
    fea80000-feafffff : 0000:00:02.1
    fea80000-feafffff : reserved
    feb00000-febfffff : 0000:00:02.0
    feb00000-febfffff : reserved
    fec00000-fed003ff : reserved
    fec00000-fec00fff : IOAPIC 0
    fed00000-fed003ff : HPET 0

    and because the reserved entry had been split and moved into the
    individual resources, and because it used the IORESOURCE_BUSY flag, the
    drivers that actually wanted to _use_ those resources couldn't actually
    attach to them:

    e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
    HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]

    with this patch, the resource tree instead becomes

    e0000000-fed003ff : reserved
    fe800000-fe8fffff : PCI Bus 0000:01
    fe9d9b00-fe9d9bff : 0000:00:1f.3
    fe9d9c00-fe9d9fff : 0000:00:1a.7
    fe9d9c00-fe9d9fff : ehci_hcd
    fe9da000-fe9dafff : 0000:00:03.3
    fe9db000-fe9dbfff : 0000:00:19.0
    fe9db000-fe9dbfff : e1000e
    fe9dc000-fe9dffff : 0000:00:1b.0
    fe9dc000-fe9dffff : ICH HD audio
    fe9e0000-fe9fffff : 0000:00:19.0
    fe9e0000-fe9fffff : e1000e
    fea00000-fea7ffff : 0000:00:02.0
    fea80000-feafffff : 0000:00:02.1
    feb00000-febfffff : 0000:00:02.0
    fec00000-fec00fff : IOAPIC 0
    fed00000-fed003ff : HPET 0

    ie the one reserved region now ends up surrounding all the PCI resources
    that were allocated inside of it by firmware, and because it is not
    marked BUSY, drivers have no problem attaching to the pre-allocated
    resources.

    Reported-and-tested-by: Jonathan Corbet
    Cc: Yinghai Lu
    Cc: Ingo Molnar
    Cc: Robert Hancock
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • This one apparently doesn't generate any warnings, because the function
    is only used during system bootup, when the warnings are disabled. But
    it's still very wrong.

    The __reserve_region_with_split() function is called with the
    resource_lock held for writing, so it must only ever do GFP_ATOMIC
    allocations.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • * 'link_removal' of git://www.jni.nu/cris:
    [CRIS] Remove links from CRIS build
    [CRIS] Merge asm-offsets.c for both arches into one file.

    Linus Torvalds
     
  • * 'cris_move' of git://www.jni.nu/cris:
    [CRIS] Move header files from include to arch/cris/include.
    [CRISv32] Remove warning in io.h

    Linus Torvalds
     
  • …s/security-testing-2.6

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
    SELinux: properly handle empty tty_files list

    Linus Torvalds
     
  • The file(s) below do not use LINUX_VERSION_CODE nor KERNEL_VERSION.
    drivers/leds/leds-hp-disk.c
    drivers/misc/panasonic-laptop.c

    This patch removes the said #include .

    Signed-off-by: Huang Weiyi
    Signed-off-by: Linus Torvalds

    Huang Weiyi
     
  • As it is, all instances of ->release() for files that have ->fasync()
    need to remember to evict file from fasync lists; forgetting that
    creates a hole and we actually have a bunch that *does* forget.

    So let's keep our lives simple - let __fput() check FASYNC in
    file->f_flags and call ->fasync() there if it's been set. And lose that
    crap in ->release() instances - leaving it there is still valid, but we
    don't have to bother anymore.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • While Linux doesn't honor setuid on scripts. However, it mistakenly
    behaves differently for file capabilities.

    This patch fixes that behavior by making sure that get_file_caps()
    begins with empty bprm->caps_*. That way when a script is loaded,
    its bprm->caps_* may be filled when binfmt_misc calls prepare_binprm(),
    but they will be cleared again when binfmt_elf calls prepare_binprm()
    next to read the interpreter's file capabilities.

    Signed-off-by: Serge Hallyn
    Acked-by: David Howells
    Acked-by: Andrew G. Morgan
    Signed-off-by: Linus Torvalds

    Serge Hallyn