Switch branches/tags
Commits on Apr 21, 2011
  1. Linux

    gregkh committed Apr 21, 2011
  2. ip: ip_options_compile() resilient to NULL skb route

    Eric Dumazet committed with gregkh Apr 14, 2011
    commit c65353d upstream.
    Scot Doyle demonstrated ip_options_compile() could be called with an skb
    without an attached route, using a setup involving a bridge, netfilter,
    and forged IP packets.
    Let's make ip_options_compile() and ip_options_rcv_srr() a bit more
    robust, instead of changing bridge/netfilter code.
    With help from Hiroaki SHIMODA.
    Reported-by: Scot Doyle <>
    Tested-by: Scot Doyle <>
    Signed-off-by: Eric Dumazet <>
    Cc: Stephen Hemminger <>
    Acked-by: Hiroaki SHIMODA <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  3. bridge: reset IPCB in br_parse_ip_options

    Eric Dumazet committed with gregkh Apr 12, 2011
    commit f8e9881 upstream.
    Commit 462fb2a (bridge : Sanitize skb before it enters the IP
    stack), missed one IPCB init before calling ip_options_compile()
    Thanks to Scot Doyle for his tests and bug reports.
    Reported-by: Scot Doyle <>
    Signed-off-by: Eric Dumazet <>
    Cc: Hiroaki SHIMODA <>
    Acked-by: Bandan Das <>
    Acked-by: Stephen Hemminger <>
    Cc: Jan Lübbe <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
  4. perf tool: Fix gcc 4.6.0 issues

    jkkm committed with gregkh Jan 24, 2011
    commit fb7d0b3 upstream.
    GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf
    due to the -Werror=unused-but-set-variable flag.
    I've gone through and annotated some of the assignments that had side
    effects (ie: return value from a function) with the __used annotation,
    and in some cases, just removed unused code.
    In a few cases, we were assigning something useful, but not using it in
    later parts of the function.
    kyle@dreadnought:~/src% gcc --version
    gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3)
    Cc: Ingo Molnar <>
    LKML-Reference: <>
    Signed-off-by: Kyle McMartin <>
    [ committer note: Fixed up the annotation fixes, as that code moved recently ]
    Signed-off-by: Arnaldo Carvalho de Melo <>
    [Backported to by deleting unused but set variables]
    Signed-off-by: Thomas Meyer <>
    Signed-off-by: Greg Kroah-Hartman <>
  5. Bluetooth: Fix HCI_RESET command synchronization

    Gustavo F. Padovan committed with gregkh Mar 16, 2011
    commit f630cf0 upstream.
    We can't send new commands before a cmd_complete for the HCI_RESET command
    shows up.
    Reported-by: Mikko Vinni <>
    Reported-by: Justin P. Mattock <>
    Reported-by: Ed Tomlinson <>
    Signed-off-by: Gustavo F. Padovan <>
    Tested-by: Justin P. Mattock <>
    Tested-by: Mikko Vinni <>
    Tested-by: Ed Tomlinson <>
  6. radeon: Fix KMS CP writeback on big endian machines.

    Michel Dänzer committed with gregkh Apr 7, 2011
    commit dc66b32 upstream.
    This is necessary even with PCI(e) GART, and it makes writeback work even with
    AGP on my PowerBook. Might still be unreliable with older revisions of UniNorth
    and other AGP bridges though.
    Signed-off-by: Michel Dänzer <>
    Reviewed-by: Alex Deucher <>
    Signed-off-by: Dave Airlie <>
    Signed-off-by: Greg Kroah-Hartman <>
  7. USB: Fix unplug of device with active streams

    Matthew Wilcox committed with gregkh Sep 28, 2010
    commit b214f19 upstream.
    If I unplug a device while the UAS driver is loaded, I get an oops
    in usb_free_streams().  This is because usb_unbind_interface() calls
    usb_disable_interface() which calls usb_disable_endpoint() which sets
    ep_out and ep_in to NULL.  Then the UAS driver calls usb_pipe_endpoint()
    which returns a NULL pointer and passes an array of NULL pointers to
    I think the correct fix for this is to check for the NULL pointer
    in usb_free_streams() rather than making the driver check for this
    situation.  My original patch for this checked for dev->state ==
    USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is
    conditional, so not all drivers would want this check.
    Note from Sarah Sharp: This patch does avoid a potential dereference,
    but the real fix (which will be implemented later) is to set the
    .soft_unbind flag in the usb_driver structure for the UAS driver, and
    all drivers that allocate streams.  The driver should free any streams
    when it is unbound from the interface.  This avoids leaking stream rings
    in the xHCI driver when usb_disable_interface() is called.
    This should be queued for stable trees back to 2.6.35.
    Signed-off-by: Matthew Wilcox <>
    Signed-off-by: Sarah Sharp <>
    Signed-off-by: Greg Kroah-Hartman <>
  8. USB: xhci - also free streams when resetting devices

    Dmitry Torokhov committed with gregkh Apr 13, 2011
    commit 2dea75d upstream.
    Currently, when resetting a device, xHCI driver disables all but one
    endpoints and frees their rings, but leaves alone any streams that
    might have been allocated. Later, when users try to free allocated
    streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
    ep->ring is NULL.
    Let's free not only rings but also stream data as well, so that
    calling free_streams() on a device that was reset will be safe.
    This should be queued for stable trees back to 2.6.35.
    Reviewed-by: Micah Elizabeth Scott <>
    Signed-off-by: Dmitry Torokhov <>
    Signed-off-by: Sarah Sharp <>
    Signed-off-by: Greg Kroah-Hartman <>
  9. USB: xhci - fix math in xhci_get_endpoint_interval()

    Dmitry Torokhov committed with gregkh Mar 24, 2011
    commit dfa49c4 upstream.
    When parsing exponent-expressed intervals we subtract 1 from the
    value and then expect it to match with original + 1, which is
    highly unlikely, and we end with frequent spew:
    	usb 3-4: ep 0x83 - rounding interval to 512 microframes
    Also, parsing interval for fullspeed isochronous endpoints was
    incorrect - according to USB spec they use exponent-based
    intervals (but xHCI spec claims frame-based intervals). I trust
    USB spec more, especially since USB core agrees with it.
    This should be queued for stable kernels back to 2.6.31.
    Reviewed-by: Micah Elizabeth Scott <>
    Signed-off-by: Dmitry Torokhov <>
    Signed-off-by: Sarah Sharp <>
    Signed-off-by: Greg Kroah-Hartman <>
  10. USB: xhci - fix unsafe macro definitions

    Dmitry Torokhov committed with gregkh Mar 20, 2011
    commit 5a6c2f3 upstream.
    Macro arguments used in expressions need to be enclosed in parenthesis
    to avoid unpleasant surprises.
    This should be queued for kernels back to 2.6.31
    Signed-off-by: Dmitry Torokhov <>
    Signed-off-by: Sarah Sharp <>
    Signed-off-by: Greg Kroah-Hartman <>
  11. USB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices

    Dmitry Torokhov committed with gregkh Mar 19, 2011
    commit 2868a2b upstream.
    Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
    for decoding bInterval values as HighSpeed ones so adjust the code
    Also bandwidth reservation for SuperSpeed matches highspeed, not
    low/full speed.
    Signed-off-by: Dmitry Torokhov <>
    Signed-off-by: Greg Kroah-Hartman <>
  12. USB: EHCI: unlink unused QHs when the controller is stopped

    AlanStern committed with gregkh Apr 5, 2011
    commit 94ae497 upstream.
    This patch (as1458) fixes a problem affecting ultra-reliable systems:
    When hardware failover of an EHCI controller occurs, the data
    structures do not get released correctly.  This is because the routine
    responsible for removing unused QHs from the async schedule assumes
    the controller is running properly (the frame counter is used in
    determining how long the QH has been idle) -- but when a failover
    causes the controller to be electronically disconnected from the PCI
    bus, obviously it stops running.
    The solution is simple: Allow scan_async() to remove a QH from the
    async schedule if it has been idle for long enough _or_ if the
    controller is stopped.
    Signed-off-by: Alan Stern <>
    Reported-and-Tested-by: Dan Duval <>
    Signed-off-by: Greg Kroah-Hartman <>
  13. usb: qcserial add missing errorpath kfrees

    hardys committed with gregkh Apr 4, 2011
    commit cb62d65 upstream.
    There are two -ENODEV error paths in qcprobe where the allocated private
    data is not freed, this patch adds the two missing kfrees to avoid
    leaking memory on the error path
    Signed-off-by: Steven Hardy <>
    Signed-off-by: Greg Kroah-Hartman <>
  14. usb: qcserial avoid pointing to freed memory

    hardys committed with gregkh Apr 4, 2011
    commit 99ab3f9 upstream.
    Rework the qcprobe logic such that serial->private is not set when
    qcprobe exits with -ENODEV, otherwise serial->private will point to freed
    memory on -ENODEV
    Signed-off-by: Steven Hardy <>
    Signed-off-by: Greg Kroah-Hartman <>
  15. usb: Fix qcserial memory leak on rmmod

    hardys committed with gregkh Apr 4, 2011
    commit 10c9ab1 upstream.
    qcprobe function allocates serial->private but this is never freed, this
    patch adds a new function qc_release() which frees serial->private, after
    calling usb_wwan_release
    Signed-off-by: Steven Hardy <>
    Signed-off-by: Greg Kroah-Hartman <>
  16. powerpc/perf_event: Skip updating kernel counters if register value s…

    khers committed with gregkh Apr 15, 2011
    commit 86c74ab upstream.
    Because of speculative event roll back, it is possible for some event coutners
    to decrease between reads on POWER7.  This causes a problem with the way that
    counters are updated.  Delta calues are calculated in a 64 bit value and the
    top 32 bits are masked.  If the register value has decreased, this leaves us
    with a very large positive value added to the kernel counters.  This patch
    protects against this by skipping the update if the delta would be negative.
    This can lead to a lack of precision in the coutner values, but from my testing
    the value is typcially fewer than 10 samples at a time.
    Signed-off-by: Eric B Munson <>
    Signed-off-by: Benjamin Herrenschmidt <>
    Signed-off-by: Greg Kroah-Hartman <>
  17. powerpc: Fix oops if scan_dispatch_log is called too early

    antonblanchard committed with gregkh Apr 7, 2011
    commit 84ffae5 upstream.
    We currently enable interrupts before the dispatch log for the boot
    cpu is setup. If a timer interrupt comes in early enough we oops in
    Unable to handle kernel paging request for data at address 0x00000010
    The patch below adds a check to scan_dispatch_log to ensure the
    dispatch log has been allocated.
    Signed-off-by: Anton Blanchard <>
    Signed-off-by: Benjamin Herrenschmidt <>
    Signed-off-by: Greg Kroah-Hartman <>
  18. proc: do proper range check on readdir offset

    torvalds committed with gregkh Apr 18, 2011
    commit d8bdc59 upstream.
    Rather than pass in some random truncated offset to the pid-related
    functions, check that the offset is in range up-front.
    This is just cleanup, the previous commit fixed the real problem.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  19. next_pidmap: fix overflow condition

    torvalds committed with gregkh Apr 18, 2011
    commit c78193e upstream.
    next_pidmap() just quietly accepted whatever 'last' pid that was passed
    in, which is not all that safe when one of the users is /proc.
    Admittedly the proc code should do some sanity checking on the range
    (and that will be the next commit), but that doesn't mean that the
    helper functions should just do that pidmap pointer arithmetic without
    checking the range of its arguments.
    So clamp 'last' to PID_MAX_LIMIT.  The fact that we then do "last+1"
    doesn't really matter, the for-loop does check against the end of the
    pidmap array properly (it's only the actual pointer arithmetic overflow
    case we need to worry about, and going one bit beyond isn't going to
    [ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ]
    Reported-by: Tavis Ormandy <>
    Analyzed-by: Robert Święcki <>
    Cc: Eric W. Biederman <>
    Cc: Pavel Emelyanov <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  20. USB: option: Added support for Samsung GT-B3730/GT-B3710 LTE USB modem.

    mkotsbak committed with gregkh Mar 21, 2011
    commit 80f9df3 upstream.
    Bind only modem AT command endpoint to option.
    Signed-off-by: Marius B. Kotsbak <>
    Signed-off-by: Greg Kroah-Hartman <>
  21. USB: ftdi_sio: add ids for Hameg HO720 and HO730

    Paul Friedrich committed with gregkh Mar 18, 2011
    commit c53c2fa upstream.
    usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720
    and HO730
    Signed-off-by: Greg Kroah-Hartman <>
  22. USB: ftdi_sio: add PID for OCT DK201 docking station

    jhovold committed with gregkh Apr 8, 2011
    commit 11a31d8 upstream.
    Add PID 0x0103 for serial port of the OCT DK201 docking station.
    Reported-by: Jan Hoogenraad <>
    Signed-off-by: Johan Hovold <>
    Signed-off-by: Greg Kroah-Hartman <>
  23. USB: ftdi_sio: Added IDs for CTI USB Serial Devices

    simonswine committed with gregkh Mar 28, 2011
    commit 5a9443f upstream.
    I added new ProdutIds for two devices from CTI GmbH Leipzig.
    Signed-off-by: Christian Simon <>
    Signed-off-by: Greg Kroah-Hartman <>
  24. usb: musb: temporarily make it bool

    Felipe Balbi committed with gregkh Mar 22, 2011
    commit 7a180e7 upstream.
    Due to the recent changes to musb's glue layers,
    we can't compile musb-hdrc as a module - compilation
    will break due to undefined symbol musb_debug. In
    order to fix that, we need a big re-work of the
    debug support on the MUSB driver.
    Because that would mean a lot of new code coming
    into the -rc series, it's best to defer that to
    next merge window and for now just disable module
    support for MUSB.
    Once we get the refactor of the debugging support
    done, we can simply revert this patch and things
    will go back to normal again.
    Signed-off-by: Felipe Balbi <>
    Signed-off-by: Greg Kroah-Hartman <>
  25. brk: COMPAT_BRK: fix detection of randomized brk

    Jiri Kosina committed with gregkh Apr 14, 2011
    commit 4471a67 upstream.
    5520e89 ("brk: fix min_brk lower bound computation for COMPAT_BRK")
    tried to get the whole logic of brk randomization for legacy
    (libc5-based) applications finally right.
    It turns out that the way to detect whether brk has actually been
    randomized in the end or not introduced by that patch still doesn't work
    for those binaries, as reported by Geert:
    : /sbin/init from my old m68k ramdisk exists prematurely.
    : Before the patch:
    : | brk(0x80005c8e)                         = 0x80006000
    : After the patch:
    : | brk(0x80005c8e)                         = 0x80005c8e
    : Old libc5 considers brk() to have failed if the return value is not
    : identical to the requested value.
    I don't like it, but currently see no better option than a bit flag in
    task_struct to catch the CONFIG_COMPAT_BRK && randomize_va_space == 2
    Signed-off-by: Jiri Kosina <>
    Tested-by: Geert Uytterhoeven <>
    Reported-by: Geert Uytterhoeven <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  26. vmscan: all_unreclaimable() use zone->all_unreclaimable as a name

    kosaki committed with gregkh Apr 14, 2011
    commit 929bea7 upstream.
    all_unreclaimable check in direct reclaim has been introduced at 2.6.19
    by following commit.
    	2006 Sep 25; commit 408d854; oom: use unreclaimable info
    And it went through strange history. firstly, following commit broke
    the logic unintentionally.
    	2008 Apr 29; commit a41f24e; page allocator: smarter retry of
    				      costly-order allocations
    Two years later, I've found obvious meaningless code fragment and
    restored original intention by following commit.
    	2010 Jun 04; commit bb21c7c; vmscan: fix do_try_to_free_pages()
    				      return value when priority==0
    But, the logic didn't works when 32bit highmem system goes hibernation
    and Minchan slightly changed the algorithm and fixed it .
    	2010 Sep 22: commit d190836: vmscan: check all_unreclaimable
    				      in direct reclaim path
    But, recently, Andrey Vagin found the new corner case. Look,
    	struct zone {
    	        int                     all_unreclaimable;
    	        unsigned long           pages_scanned;
    zone->all_unreclaimable and zone->pages_scanned are neigher atomic
    variables nor protected by lock.  Therefore zones can become a state of
    zone->page_scanned=0 and zone->all_unreclaimable=1.  In this case, current
    all_unreclaimable() return false even though zone->all_unreclaimabe=1.
    This resulted in the kernel hanging up when executing a loop of the form
    1. fork
    2. mmap
    3. touch memory
    4. read memory
    5. munmmap
    as described in
    Is this ignorable minor issue?  No.  Unfortunately, x86 has very small dma
    zone and it become zone->all_unreclamble=1 easily.  and if it become
    all_unreclaimable=1, it never restore all_unreclaimable=0.  Why?  if
    all_unreclaimable=1, vmscan only try DEF_PRIORITY reclaim and
    a-few-lru-pages>>DEF_PRIORITY always makes 0.  that mean no page scan at
    Eventually, oom-killer never works on such systems.  That said, we can't
    use zone->pages_scanned for this purpose.  This patch restore
    all_unreclaimable() use zone->all_unreclaimable as old.  and in addition,
    to add oom_killer_disabled check to avoid reintroduce the issue of commit
    d190836 ("vmscan: check all_unreclaimable in direct reclaim path").
    Reported-by: Andrey Vagin <>
    Signed-off-by: KOSAKI Motohiro <>
    Cc: Nick Piggin <>
    Reviewed-by: Minchan Kim <>
    Reviewed-by: KAMEZAWA Hiroyuki <>
    Acked-by: David Rientjes <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  27. sched: Fix erroneous all_pinned logic

    Ken Chen committed with gregkh Apr 8, 2011
    commit b30aef1 upstream.
    The scheduler load balancer has specific code to deal with cases of
    unbalanced system due to lots of unmovable tasks (for example because of
    hard CPU affinity). In those situation, it excludes the busiest CPU that
    has pinned tasks for load balance consideration such that it can perform
    second 2nd load balance pass on the rest of the system.
    This all works as designed if there is only one cgroup in the system.
    However, when we have multiple cgroups, this logic has false positives and
    triggers multiple load balance passes despite there are actually no pinned
    tasks at all.
    The reason it has false positives is that the all pinned logic is deep in
    the lowest function of can_migrate_task() and is too low level:
    load_balance_fair() iterates each task group and calls balance_tasks() to
    migrate target load. Along the way, balance_tasks() will also set a
    all_pinned variable. Given that task-groups are iterated, this all_pinned
    variable is essentially the status of last group in the scanning process.
    Task group can have number of reasons that no load being migrated, none
    due to cpu affinity. However, this status bit is being propagated back up
    to the higher level load_balance(), which incorrectly think that no tasks
    were moved.  It kick off the all pinned logic and start multiple passes
    attempt to move load onto puller CPU.
    To fix this, move the all_pinned aggregation up at the iterator level.
    This ensures that the status is aggregated over all task-groups, not just
    last one in the list.
    Signed-off-by: Ken Chen <>
    Signed-off-by: Peter Zijlstra <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
  28. RTC: add missing "return 0" in new alarm func for rtc-bfin.c

    vapier committed with gregkh Mar 18, 2011
    commit 8c122b9 upstream.
    The new bfin_rtc_alarm_irq_enable function forgot to add a "return 0" to
    the end leading to the build warning:
    	drivers/rtc/rtc-bfin.c: In function 'bfin_rtc_alarm_irq_enable':
    	drivers/rtc/rtc-bfin.c:253: warning: control reaches end of non-void function
    CC: Thomas Gleixner <>
    CC: Alessandro Zummo <>
    Signed-off-by: Mike Frysinger <>
    Signed-off-by: John Stultz <>
    Signed-off-by: Greg Kroah-Hartman <>
  29. i2c-algo-bit: Call pre/post_xfer for bit_test

    Alex Deucher committed with gregkh Apr 17, 2011
    commit d3b3e15 upstream.
    Apparently some distros set i2c-algo-bit.bit_test to 1 by
    default.  In some cases this causes i2c_bit_add_bus
    to fail and prevents the i2c bus from being added.  In the
    radeon case, we fail to add the ddc i2c buses which prevents
    the driver from being able to detect attached monitors.
    The i2c bus works fine even if bit_test fails.  This is likely
    due to gpio switching that is required and handled in the
    pre/post_xfer hooks, so call the pre/post_xfer hooks in the
    bit test as well.
    Signed-off-by: Alex Deucher <>
    Signed-off-by: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
  30. ARM: 6864/1: hw_breakpoint: clear DBGVCR out of reset

    wildea01 committed with gregkh Apr 5, 2011
    commit e89c0d7 upstream.
    The DBGVCR, used for configuring vector catch debug events, is UNKNOWN
    out of reset on ARMv7. When enabling monitor mode, this must be zeroed
    to avoid UNPREDICTABLE behaviour.
    This patch adds the zeroing code to the debug reset path.
    Reported-by: Stepan Moskovchenko <>
    Signed-off-by: Will Deacon <>
    Signed-off-by: Russell King <>
    Signed-off-by: Greg Kroah-Hartman <>
  31. vfs: Fix absolute RCU path walk failures due to uninitialized seq number

    pdxChen committed with gregkh Apr 15, 2011
    commit c153001 upstream.
    During RCU walk in path_lookupat and path_openat, the rcu lookup
    frequently failed if looking up an absolute path, because when root
    directory was looked up, seq number was not properly set in nameidata.
    We dropped out of RCU walk in nameidata_drop_rcu due to mismatch in
    directory entry's seq number.  We reverted to slow path walk that need
    to take references.
    With the following patch, I saw a 50% increase in an exim mail server
    benchmark throughput on a 4-socket Nehalem-EX system.
    Signed-off-by: Tim Chen <>
    Reviewed-by: Andi Kleen <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  32. x86, amd: Disable GartTlbWlkErr when BIOS forgets it

    Joerg Roedel committed with gregkh Apr 15, 2011
    commit 5bbc097 upstream.
    This patch disables GartTlbWlk errors on AMD Fam10h CPUs if
    the BIOS forgets to do is (or is just too old). Letting
    these errors enabled can cause a sync-flood on the CPU
    causing a reboot.
    The AMD BKDG recommends disabling GART TLB Wlk Error completely.
    This patch is the fix for

    on my machine.
    Signed-off-by: Joerg Roedel <>
    Tested-by: Alexandre Demers <>
    Signed-off-by: H. Peter Anvin <>
    Signed-off-by: Greg Kroah-Hartman <>
  33. x86, AMD: Set ARAT feature on AMD processors

    ostr committed with gregkh Mar 15, 2011
    commit b87cf80 upstream.
    Support for Always Running APIC timer (ARAT) was introduced in
    commit db954b5. This feature
    allows us to avoid switching timers from LAPIC to something else
    (e.g. HPET) and go into timer broadcasts when entering deep
    AMD processors don't provide a CPUID bit for that feature but
    they also keep APIC timers running in deep C-states (except for
    cases when the processor is affected by erratum 400). Therefore
    we should set ARAT feature bit on AMD CPUs.
    Tested-by: Borislav Petkov <>
    Acked-by: Andreas Herrmann <>
    Acked-by: Mark Langsdorf <>
    Acked-by: Thomas Gleixner <>
    Signed-off-by: Boris Ostrovsky <>
    LKML-Reference: <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
  34. UBIFS: fix oops when R/O file-system is fsync'ed

    Artem Bityutskiy committed with gregkh Apr 13, 2011
    commit 78530bf upstream.
    This patch fixes severe UBIFS bug: UBIFS oopses when we 'fsync()' an
    file on R/O-mounter file-system. We (the UBIFS authors) incorrectly
    thought that VFS would not propagate 'fsync()' down to the file-system
    if it is read-only, but this is not the case.
    It is easy to exploit this bug using the following simple perl script:
    use strict;
    use File::Sync qw(fsync sync);
    die "File path is not specified" if not defined $ARGV[0];
    my $path = $ARGV[0];
    open FILE, "<", "$path" or die "Cannot open $path: $!";
    fsync(\*FILE) or die "cannot fsync $path: $!";
    close FILE or die "Cannot close $path: $!";
    Thanks to Reuben Dowle <> for reporting about this
    Signed-off-by: Artem Bityutskiy <>
    Reported-by: Reuben Dowle <>
    Signed-off-by: Greg Kroah-Hartman <>

    Randy Dunlap committed with gregkh Apr 14, 2011
    commit d00ebea upstream.
    Drop Chris Wright from STABLE maintainers.  He hasn't done STABLE release
    work for quite some time.
    Signed-off-by: Randy Dunlap <>
    Acked-by: Chris Wright <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>