1. 29 Apr, 2015 22 commits
  2. 19 Apr, 2015 18 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.19.5 · a96a0302
      Greg Kroah-Hartman authored
      a96a0302
    • Igor Mammedov's avatar
      kvm: avoid page allocation failure in kvm_set_memory_region() · 002d8e07
      Igor Mammedov authored
      commit 74496134 upstream.
      
      KVM guest can fail to startup with following trace on host:
      
      qemu-system-x86: page allocation failure: order:4, mode:0x40d0
      Call Trace:
        dump_stack+0x47/0x67
        warn_alloc_failed+0xee/0x150
        __alloc_pages_direct_compact+0x14a/0x150
        __alloc_pages_nodemask+0x776/0xb80
        alloc_kmem_pages+0x3a/0x110
        kmalloc_order+0x13/0x50
        kmemdup+0x1b/0x40
        __kvm_set_memory_region+0x24a/0x9f0 [kvm]
        kvm_set_ioapic+0x130/0x130 [kvm]
        kvm_set_memory_region+0x21/0x40 [kvm]
        kvm_vm_ioctl+0x43f/0x750 [kvm]
      
      Failure happens when attempting to allocate pages for
      'struct kvm_memslots', however it doesn't have to be
      present in physically contiguous (kmalloc-ed) address
      space, change allocation to kvm_kvzalloc() so that
      it will be vmalloc-ed when its size is more then a page.
      Signed-off-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      002d8e07
    • Daniel Vetter's avatar
      drm/i915: Push vblank enable/disable past encoder->enable/disable · d5d51dd4
      Daniel Vetter authored
      commit f9b61ff6 upstream.
      
      It is platform/output depenedent when exactly the pipe will start
      running. Sometimes we just need the (cpu) pipe enabled, in other cases
      the pch transcoder is enough and in yet other cases the (DP) port is
      sending the frame start signal.
      
      In a perfect world we'd put the drm_crtc_vblank_on call exactly where
      the pipe starts running, but due to cloning and similar things this
      will get messy. And the current approach of picking the most
      conservative place for all combinations also doesn't work since that
      results in legit vblank waits (in encoder->enable hooks, e.g. the 2
      vblank waits for sdvo) failing.
      
      Completely going back to the old world before
      
      commit 51e31d49
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Mon Sep 15 12:36:02 2014 +0200
      
          drm/i915: Use generic vblank wait
      
      isn't great either since screaming when the vblank wait work because
      the pipe is off is kinda nice.
      
      Pick a compromise and move the drm_crtc_vblank_on right before the
      encoder->enable call. This is a lie on some outputs/platforms, but
      after the ->enable callback the pipe is guaranteed to run everywhere.
      So not that bad really. Suggested by Ville.
      
      v2: Same treatment for drm_crtc_vblank_off and encoder->disable: I've
      missed the ibx pipe B select w/a, which also has a vblank wait in the
      disable function (while the pipe is obviously still running).
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5d51dd4
    • Dave Chinner's avatar
      xfs: ensure truncate forces zeroed blocks to disk · 363d91b0
      Dave Chinner authored
      commit 5885ebda upstream.
      
      A new fsync vs power fail test in xfstests indicated that XFS can
      have unreliable data consistency when doing extending truncates that
      require block zeroing. The blocks beyond EOF get zeroed in memory,
      but we never force those changes to disk before we run the
      transaction that extends the file size and exposes those blocks to
      userspace. This can result in the blocks not being correctly zeroed
      after a crash.
      
      Because in-memory behaviour is correct, tools like fsx don't pick up
      any coherency problems - it's not until the filesystem is shutdown
      or the system crashes after writing the truncate transaction to the
      journal but before the zeroed data in the page cache is flushed that
      the issue is exposed.
      
      Fix this by also flushing the dirty data in memory region between
      the old size and new size when we've found blocks that need zeroing
      in the truncate process.
      Reported-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      363d91b0
    • Omar Sandoval's avatar
      ext4: fix indirect punch hole corruption · db8a9ac5
      Omar Sandoval authored
      commit 6f30b7e3 upstream.
      
      Commit 4f579ae7 (ext4: fix punch hole on files with indirect
      mapping) rewrote FALLOC_FL_PUNCH_HOLE for ext4 files with indirect
      mapping. However, there are bugs in several corner cases. This fixes 5
      distinct bugs:
      
      1. When there is at least one entire level of indirection between the
      start and end of the punch range and the end of the punch range is the
      first block of its level, we can't return early; we have to free the
      intervening levels.
      
      2. When the end is at a higher level of indirection than the start and
      ext4_find_shared returns a top branch for the end, we still need to free
      the rest of the shared branch it returns; we can't decrement partial2.
      
      3. When a punch happens within one level of indirection, we need to
      converge on an indirect block that contains the start and end. However,
      because the branches returned from ext4_find_shared do not necessarily
      start at the same level (e.g., the partial2 chain will be shallower if
      the last block occurs at the beginning of an indirect group), the walk
      of the two chains can end up "missing" each other and freeing a bunch of
      extra blocks in the process. This mismatch can be handled by first
      making sure that the chains are at the same level, then walking them
      together until they converge.
      
      4. When the punch happens within one level of indirection and
      ext4_find_shared returns a top branch for the start, we must free it,
      but only if the end does not occur within that branch.
      
      5. When the punch happens within one level of indirection and
      ext4_find_shared returns a top branch for the end, then we shouldn't
      free the block referenced by the end of the returned chain (this mirrors
      the different levels case).
      Signed-off-by: default avatarOmar Sandoval <osandov@osandov.com>
      Cc: Chris J Arges <chris.j.arges@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db8a9ac5
    • Preeti U Murthy's avatar
      timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in idle loop · 1a6fe5b6
      Preeti U Murthy authored
      commit a127d2bc upstream.
      
      The hrtimer mode of broadcast queues hrtimers in the idle entry
      path so as to wakeup cpus in deep idle states. The associated
      call graph is :
      
      	cpuidle_idle_call()
      	|____ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, ....))
      	     |_____tick_broadcast_set_event()
      		   |____clockevents_program_event()
      			|____bc_set_next()
      
      The hrtimer_{start/cancel} functions call into tracing which uses RCU.
      But it is not legal to call into RCU in cpuidle because it is one of the
      quiescent states. Hence protect this region with RCU_NONIDLE which informs
      RCU that the cpu is momentarily non-idle.
      
      As an aside it is helpful to point out that the clock event device that is
      programmed here is not a per-cpu clock device; it is a
      pseudo clock device, used by the broadcast framework alone.
      The per-cpu clock device programming never goes through bc_set_next().
      Signed-off-by: default avatarPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: linuxppc-dev@ozlabs.org
      Cc: mpe@ellerman.id.au
      Cc: tglx@linutronix.de
      Link: http://lkml.kernel.org/r/20150318104705.17763.56668.stgit@preeti.in.ibm.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a6fe5b6
    • Majd Dibbiny's avatar
      IB/mlx4: Saturate RoCE port PMA counters in case of overflow · 6531f38e
      Majd Dibbiny authored
      commit 61a3855b upstream.
      
      For RoCE ports, we set the u32 PMA values based on u64 HCA counters. In case of
      overflow, according to the IB spec, we have to saturate a counter to its
      max value, do that.
      
      Fixes: c3779134 ('IB/mlx4: Support PMA counters for IBoE')
      Signed-off-by: default avatarMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: default avatarHadar Hen Zion <hadarh@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6531f38e
    • Uwe Kleine-König's avatar
      clk: divider: fix calculation of maximal parent rate for a given divider · 033dc8f0
      Uwe Kleine-König authored
      commit da321133 upstream.
      
      The rate provided at the output of a clk-divider is calculated as:
      
      	DIV_ROUND_UP(parent_rate, div)
      
      since commit b11d282d (clk: divider: fix rate calculation for
      fractional rates). So to yield a rate not bigger than r parent_rate
      must be <= r * div.
      
      The effect of choosing a parent rate that is too big as was done before
      this patch results in wrongly ruling out good dividers.
      
      Note that this is not a complete fix as __clk_round_rate might return a
      value >= its 2nd parameter. Also for dividers with
      CLK_DIVIDER_ROUND_CLOSEST set the calculation is not accurate. But this
      fixes the test case by Sascha Hauer that uses a chain of three dividers
      under a fixed clock.
      
      Fixes: b11d282d (clk: divider: fix rate calculation for fractional rates)
      Suggested-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarMichael Turquette <mturquette@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      033dc8f0
    • Uwe Kleine-König's avatar
      clk: divider: fix selection of divider when rounding to closest · 765c2045
      Uwe Kleine-König authored
      commit 26bac95a upstream.
      
      It's an invalid approach to assume that among two divider values
      the one nearer the exact divider is the better one.
      
      Assume a parent rate of 1000 Hz, a divider with CLK_DIVIDER_POWER_OF_TWO
      and a target rate of 89 Hz. The exact divider is ~ 11.236 so 8 and 16
      are the candidates to choose from yielding rates 125 Hz and 62.5 Hz
      respectivly. While 8 is nearer to 11.236 than 16 is, the latter is still
      the better divider as 62.5 is nearer to 89 than 125 is.
      
      Fixes: 774b5143 (clk: divider: Add round to closest divider)
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Acked-by: default avatarMaxime Coquelin <maxime.coquelin@st.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      765c2045
    • Hans Verkuil's avatar
      vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop() · 4858bcfd
      Hans Verkuil authored
      commit 0e661006 upstream.
      
      Stopping the vb2 thread (as used by several DVB devices) can result
      in an 'UNBALANCED' warning such as this:
      
      vb2: counters for queue ffff880407ee9828: UNBALANCED!
      vb2:     setup: 1 start_streaming: 1 stop_streaming: 1
      vb2:     wait_prepare: 249333 wait_finish: 249334
      
      This is due to a race condition between stopping the thread and
      calling vb2_internal_streamoff(). While I have not been able to deduce
      the exact mechanism how this race condition can produce this warning,
      I can see that the way the stream is stopped is likely to lead to a
      race somewhere.
      
      This patch simplifies how this is done by first ensuring that the
      thread is completely stopped before cleaning up the vb2 queue. It
      does that by setting threadio->stop to true, followed by a call to
      vb2_queue_error() which will wake up the thread. The thread sees that
      'stop' is true and it will exit.
      
      The call to kthread_stop() waits until the thread has exited, and only
      then is the queue cleaned up by calling __vb2_cleanup_fileio().
      
      This is a much cleaner sequence and the warning has now disappeared.
      Reported-by: default avatarJurgen Kramer <gtmkramer@xs4all.nl>
      Tested-by: default avatarJurgen Kramer <gtmkramer@xs4all.nl>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4858bcfd
    • Sakari Ailus's avatar
      vb2: Fix dma_dir setting for dma-contig mem type · 52c681ce
      Sakari Ailus authored
      commit 4879785e upstream.
      
      The last argument of vb2_dc_get_user_pages() is of type enum
      dma_data_direction, but the caller, vb2_dc_get_userptr() passes a value
      which is the result of comparison dma_dir == DMA_FROM_DEVICE. This results
      in the write parameter to get_user_pages() being zero in all cases, i.e.
      that the caller has no intent to write there.
      
      This was broken by patch "vb2: replace 'write' by 'dma_dir'".
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52c681ce
    • Geert Uytterhoeven's avatar
      soc-camera: Fix devm_kfree() in soc_of_bind() · 2a9a8392
      Geert Uytterhoeven authored
      commit 8e48a2d5 upstream.
      
      Unlike scan_async_group(), soc_of_bind() doesn't allocate its
      soc_camera_async_client structure using devm_kzalloc(), but has it
      embedded inside the soc_of_info structure.  Hence on failure, it must
      free the whole soc_of_info structure, and not just the embedded
      soc_camera_async_client structure, as the latter causes a warning, and
      may cause slab corruption:
      
          soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
          ------------[ cut here ]------------
          WARNING: CPU: 0 PID: 1 at drivers/base/devres.c:887 devm_kfree+0x30/0x40()
          CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-shmobile-08386-g37feb0d093cb2d8e #128
          Hardware name: Generic R8A7791 (Flattened Device Tree)
          Backtrace:
          [<c0011e7c>] (dump_backtrace) from [<c0012024>] (show_stack+0x18/0x1c)
           r6:c05a923b r5:00000009 r4:00000000 r3:00204140
          [<c001200c>] (show_stack) from [<c048ed30>] (dump_stack+0x78/0x94)
          [<c048ecb8>] (dump_stack) from [<c002687c>] (warn_slowpath_common+0x8c/0xb8)
           r4:00000000 r3:00000000
          [<c00267f0>] (warn_slowpath_common) from [<c0026980>] (warn_slowpath_null+0x24/0x2c)
           r8:ee7d8214 r7:ed83b810 r6:ed83bc20 r5:fffffffa r4:ed83e510
          [<c002695c>] (warn_slowpath_null) from [<c025e0cc>] (devm_kfree+0x30/0x40)
          [<c025e09c>] (devm_kfree) from [<c032bbf4>] (soc_of_bind.isra.14+0x194/0x1d4)
          [<c032ba60>] (soc_of_bind.isra.14) from [<c032c6b8>] (soc_camera_host_register+0x208/0x31c)
           r9:00000070 r8:ee7e05d0 r7:ee153210 r6:00000000 r5:ee7e0218 r4:ed83bc20
          [<c032c4b0>] (soc_camera_host_register) from [<c032e80c>] (rcar_vin_probe+0x1f4/0x238)
           r8:ee153200 r7:00000008 r6:ee153210 r5:ed83bc10 r4:c066319c r3:000000c0
          [<c032e618>] (rcar_vin_probe) from [<c025c334>] (platform_drv_probe+0x50/0xa0)
           r10:00000000 r9:c0662fa8 r8:00000000 r7:c06a3700 r6:c0662fa8 r5:ee153210
           r4:00000000
          [<c025c2e4>] (platform_drv_probe) from [<c025af08>] (driver_probe_device+0xc4/0x208)
           r6:c06a36f4 r5:00000000 r4:ee153210 r3:c025c2e4
          [<c025ae44>] (driver_probe_device) from [<c025b108>] (__driver_attach+0x70/0x94)
           r9:c066f9c0 r8:c0624a98 r7:c065b790 r6:c0662fa8 r5:ee153244 r4:ee153210
          [<c025b098>] (__driver_attach) from [<c025984c>] (bus_for_each_dev+0x74/0x98)
           r6:c025b098 r5:c0662fa8 r4:00000000 r3:00000001
          [<c02597d8>] (bus_for_each_dev) from [<c025b1dc>] (driver_attach+0x20/0x28)
           r6:ed83c200 r5:00000000 r4:c0662fa8
          [<c025b1bc>] (driver_attach) from [<c025a00c>] (bus_add_driver+0xdc/0x1c4)
          [<c0259f30>] (bus_add_driver) from [<c025b8f4>] (driver_register+0xa4/0xe8)
           r7:c0624a98 r6:00000000 r5:c060b010 r4:c0662fa8
          [<c025b850>] (driver_register) from [<c025ccd0>] (__platform_driver_register+0x50/0x64)
           r5:c060b010 r4:ed8394c0
          [<c025cc80>] (__platform_driver_register) from [<c060b028>] (rcar_vin_driver_init+0x18/0x20)
          [<c060b010>] (rcar_vin_driver_init) from [<c05edde8>] (do_one_initcall+0x108/0x1b8)
          [<c05edce0>] (do_one_initcall) from [<c05edfb4>] (kernel_init_freeable+0x11c/0x1e4)
           r9:c066f9c0 r8:c066f9c0 r7:c062eab0 r6:c06252c4 r5:000000ad r4:00000006
          [<c05ede98>] (kernel_init_freeable) from [<c048c3d0>] (kernel_init+0x10/0xec)
           r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c048c3c0 r4:00000000
          [<c048c3c0>] (kernel_init) from [<c000eba0>] (ret_from_fork+0x14/0x34)
           r4:00000000 r3:ee04e000
          ---[ end trace e3a984cc0335c8a0 ]---
          rcar_vin e6ef1000.video: group probe failed: -6
      
      Fixes: 1ddc6a6c ("[media] soc_camera: add support for dt binding soc_camera drivers")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a9a8392
    • Hans Verkuil's avatar
      cx23885: fix querycap · 5ddff4d7
      Hans Verkuil authored
      commit 6b46211f upstream.
      
      cap->device_caps wasn't set in cx23885-417.c causing a warning from
      the v4l2-core.
      Reported-by: default avatarJoseph Jasi <joe.yasi@gmail.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ddff4d7
    • Marek Szyprowski's avatar
      media: s5p-mfc: fix mmap support for 64bit arch · c80fa6bc
      Marek Szyprowski authored
      commit 05b676ab upstream.
      
      TASK_SIZE is depends on the systems architecture (32 or 64 bits) and it
      should not be used for defining offset boundary for mmaping buffers for
      CAPTURE and OUTPUT queues. This patch fixes support for MMAP calls on
      the CAPTURE queue on 64bit architectures (like ARM64).
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarKamil Debski <k.debski@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c80fa6bc
    • Hans Verkuil's avatar
      sh_veu: v4l2_dev wasn't set · 8d73f670
      Hans Verkuil authored
      commit ab312030 upstream.
      
      The v4l2_dev field of struct video_device must be set correctly.
      This was never done for this driver, so no video nodes were created
      anymore.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d73f670
    • Mike Christie's avatar
      iscsi target: fix oops when adding reject pdu · cb32abbc
      Mike Christie authored
      commit b815fc12 upstream.
      
      This fixes a oops due to a double list add when adding a reject PDU for
      iscsit_allocate_iovecs allocation failures. The cmd has already been
      added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call
      iscsit_reject_cmd.
      
      Note that for ERL0 the reject PDU is not actually sent, so this patch
      is not completely tested. Just verified we do not oops. The problem is the
      add reject functions return -1 which is returned all the way up to
      iscsi_target_rx_thread which for ERL0 will drop the connection.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cb32abbc
    • Al Viro's avatar
      ioctx_alloc(): fix vma (and file) leak on failure · 2cdb954e
      Al Viro authored
      commit deeb8525 upstream.
      
      If we fail past the aio_setup_ring(), we need to destroy the
      mapping.  We don't need to care about anybody having found ctx,
      or added requests to it, since the last failure exit is exactly
      the failure to make ctx visible to lookups.
      
      Reproducer (based on one by Joe Mario <jmario@redhat.com>):
      
      void count(char *p)
      {
      	char s[80];
      	printf("%s: ", p);
      	fflush(stdout);
      	sprintf(s, "/bin/cat /proc/%d/maps|/bin/fgrep -c '/[aio] (deleted)'", getpid());
      	system(s);
      }
      
      int main()
      {
      	io_context_t *ctx;
      	int created, limit, i, destroyed;
      	FILE *f;
      
      	count("before");
      	if ((f = fopen("/proc/sys/fs/aio-max-nr", "r")) == NULL)
      		perror("opening aio-max-nr");
      	else if (fscanf(f, "%d", &limit) != 1)
      		fprintf(stderr, "can't parse aio-max-nr\n");
      	else if ((ctx = calloc(limit, sizeof(io_context_t))) == NULL)
      		perror("allocating aio_context_t array");
      	else {
      		for (i = 0, created = 0; i < limit; i++) {
      			if (io_setup(1000, ctx + created) == 0)
      				created++;
      		}
      		for (i = 0, destroyed = 0; i < created; i++)
      			if (io_destroy(ctx[i]) == 0)
      				destroyed++;
      		printf("created %d, failed %d, destroyed %d\n",
      			created, limit - created, destroyed);
      		count("after");
      	}
      }
      Found-by: default avatarJoe Mario <jmario@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2cdb954e
    • Al Viro's avatar
      ocfs2: _really_ sync the right range · a48078e1
      Al Viro authored
      commit 64b4e252 upstream.
      
      "ocfs2 syncs the wrong range" had been broken; prior to it the
      code was doing the wrong thing in case of O_APPEND, all right,
      but _after_ it we were syncing the wrong range in 100% cases.
      *ppos, aka iocb->ki_pos is incremented prior to that point,
      so we are always doing sync on the area _after_ the one we'd
      written to.
      
      Spotted by Joseph Qi <joseph.qi@huawei.com> back in January;
      unfortunately, I'd missed his mail back then ;-/
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a48078e1